Kryptografia to głównie obsługa kluczy.
ISO 27001:2022 A.8.24 (użycie kryptografii) dotyczy skutecznego stosowania kryptografii w celu ochrony informacji, w tym zarządzania kluczami. W kodzie sprowadza się to głównie do trzech kwestii: czy klucze są obsługiwane bezpiecznie, czy algorytmy są mocne, oraz czy konfiguracja jest poprawna. Wszystkie trzy są decyzjami podejmowanymi w pull request, a najczęstsze błędy w kodzie to raczej klucz w niewłaściwym miejscu niż słaby algorytm.
The shapes the same control failure takes.
A.8.24 słabnie, gdy klucz jest nieprawidłowo obsługiwany lub prymityw jest obniżany. Powtarzające się formy:
Klucz ląduje w kodzie
Tajemnica lub klucz prywatny jest zakodowany na sztywno lub zatwierdzony zamiast odczytywany z zarządzanego magazynu tajemnic, więc pozostaje w repozytorium i jego historii.
Wprowadzono słaby prymityw
Zmiana używa słabego lub złamanego hasha lub szyfru (np. do hashowania haseł lub podpisywania), gdzie wymagany jest mocny.
Minimalna wersja TLS spada
Obniżono minimalną wersję protokołu lub wymagania dotyczące szyfru, osłabiając kryptografię chroniącą transport.
Weryfikacja jest wyłączona
Weryfikacja certyfikatu lub podpisu jest wyłączona, więc zaszyfrowany kanał lub podpisany artefakt nie jest już faktycznie zaufany.
Rotacja klucza lub zakres jest poluzowany
Okres ważności klucza jest wydłużony w nieskończoność, lub jeden klucz zaczyna być ponownie używany w granicach, których nie powinien przekraczać.
Klucz podpisujący zakodowany na sztywno, aby naprawić wdrożenie.
Klucz do podpisywania tokenów był odczytywany z magazynu tajemnic, ale magazyn nie został skonfigurowany w nowym środowisku, a wdrożenie nie powiodło się. Szybkim rozwiązaniem było wstawienie klucza wprost do kodu, aby usługa wystartowała. Tak się stało, a klucz prywatny znalazł się w repozytorium i jego historii.
- const SIGNING_KEY = await secrets.get("jwt-signing-key")+ const SIGNING_KEY = "<the PEM private key, pasted inline>"const token = sign(claims, SIGNING_KEY)Klucz podpisujący w kodzie źródłowym pozostaje w repozytorium, jego historii oraz w każdym klonie i pamięci podręcznej CI, co uniemożliwia zarządzanie kluczami, jakiego oczekuje A.8.24. Przywróć go z magazynu tajemnic, skonfiguruj magazyn w nowym środowisku i zrotuj klucz, ponieważ klucz, który został zatwierdzony, musi zostać potraktowany jako naruszony.
Zarządzanie kluczami to część, która jest sprawdzana.
Auditor sprawdzający A.8.24 mniej interesuje się tym, który szyfr został wybrany, a bardziej tym, jak klucze są generowane, przechowywane, rotowane i wycofywane. Tajemnica znaleziona w kodzie, klucz bez rotacji lub cicha deaktywacja weryfikacji to typ znalezisk, które się pojawiają, i zwykle wchodzą przez zmianę, która miała na celu odblokowanie czegoś. Pull request to miejsce, w którym podejmowana jest kluczowa decyzja i najtańsze miejsce na jej poprawienie.
Przegląd, a nie audyt kryptograficzny.
heygrc sygnalizuje zmiany dotyczące A.8.24 i cytuje kontrolę, aby naprawa nastąpiła w pull request. Nie projektuje schematu zarządzania kluczami ani nie przeprowadza oceny. Wychwytuje moment, w którym klucz jest nieprawidłowo obsługiwany lub prymityw jest osłabiany, na poziomie diff.