Inżynierowie przygotowujący się do pierwszej ISO 27001 często wyobrażają sobie ogromną audytę kodu lub certyfikat, który uzyskuje się tak jak testy jednostkowe. Nic z tego nie jest prawdą. ISO/IEC 27001:2022 jest standardem systemu zarządzania. Budujesz system zarządzania bezpieczeństwem informacji (polityki, zarządzanie ryzykiem, role, dostawców, incydenty i inne). Akredytowany organ certyfikujący audituje ten system i, jeśli spełnia on wymagania, wydaje certyfikat. Repozytorium GitHub nie jest przedmiotem certyfikacji.
Ta strona dotyczy małego fragmentu, który faktycznie znajduje się w repozytorium: kontrole technologiczne Załącznika A, które pull request może cicho osłabić. Jest to odpowiednik ISO 27001 dla przewodników SOC 2 i HIPAA "co rzeczywiście sprawdza". Nie jest to katalog kontroli (to jest w centrum ramki), a nie pytanie "czy istnieje aplikacja GitHub" (to jest osobna odpowiedź).
Certyfikat nie jest skanowaniem repozytorium
SOC 2 Type II report jest opinią niezależnej firmy księgowej na temat tego, czy Twoje kontrole, tak jak je opisałeś, były odpowiednio zaprojektowane i skutecznie działały w określonym okresie. Type I report dotyczy tylko projektu w określonym momencie. Akredytowany certyfikat ISO 27001 jest inny w rodzaju: akredytowany organ certyfikujący potwierdza, że Twój system zarządzania spełnia standard. Żaden z nich nie jest statycznym skanem kodu źródłowego. Żaden z nich nie jest wydawany przez GitHub App. Jeśli dostawca sugeruje, że zainstalowanie recenzenta "daje Ci ISO 27001", opisuje inny produkt niż standard.
Załącznik A ISO/IEC 27001:2022 wymienia 93 kontroli w czterech tematach (organizacyjnych, ludzkich, fizycznych, technologicznych). Nie implementujesz wszystkich 93 jako checklisty kodu. Oświadczenie o stosowności (Statement of Applicability) rejestruje kontrole, które uznano za konieczne, dlaczego są one uwzględnione, czy są one wdrożone, i dlaczego jakakolwiek kontrola z Załącznika A jest wykluczona. Załącznik A jest zestawem referencyjnym, przeciwko któremu sprawdzasz te decyzje, a nie menu 93 elementów do wdrożenia jako kod. Większość z 93 nigdy nie pojawia się w różnicy: umowy z dostawcami, biura fizyczne, rekrutacja HR, dokumentacja dotycząca leczenia ryzyka. Traktowanie 93 jako audytu repozytorium jest niewłaściwym podejściem.
Fragment Załącznika A, który znajduje się w kodzie
Temat technologiczny (A.8) ma 34 kontrole. Nawet tam tylko kilka z nich regularnie pojawia się w pull request: logowanie (A.8.15), monitorowanie (A.8.16), kryptografia i obsługa kluczy (A.8.24), ograniczanie dostępu (A.8.3), siła uwierzytelniania (A.8.5), konfiguracja pasująca do bazy (A.8.9), bezpieczne kodowanie (A.8.28), zarządzanie zmianami (A.8.32), kopia zapasowa informacji (A.8.13). Jeśli możesz rozumieć, kto może dotrzeć do czego, jak udowadniają, kim są, co jest logowane, jak są przechowywane tajne informacje i czy zmiana przeszła przez proces, który opisałeś, rozumiesz większość powierzchni związanej z kodem.
Reszta A.8 (sieci, pojemność, złośliwe oprogramowanie, zegary i tak dalej) jest realna, ale zazwyczaj jest decydowana w architekturze i operacjach, a nie w dwóch linijkach pull request aplikacji. Centrum ramki wymienia wyzwalacze. Ta strona jest modelem mentalnym: ISO 27001 w repozytorium to te kształty A.8, a nie certyfikat i nie cały list Załącznika A.
Uprawniona ścieżka, która cicho usuwa drugi czynnik
Zespół wsparcia nie może wygenerować tokenu API podczas incydentu, ponieważ droga administracyjna wymaga MFA, a telefon na warty jest w szafce. Pull request usuwa sprawdzanie drugiego czynnika i pozostawia ciasteczko sesji jako jedyną bramę. Testy pozostają zielone. Kod jest krótszy. Komentarze recenzji dotyczą odblokowania incydentu. Po zmerdżowaniu każdy, kto może uzyskać ważną sesję, może wygenerować uprawniony token bez dodatkowego czynnika, którego ścieżka wymagała.
ISO 27001:2022 A.8.5 dotyczy siły uwierzytelniania. Uprawniona akcja, która wcześniej wymagała drugiego czynnika, a teraz wymaga tylko sesji, jest słabsza po zmerdżowaniu. Czy to jest akceptowalne (dokumentowany, czasowy wyjątek incydentu w porównaniu z trwałym dziurą) to decyzja o ryzyku dla zespołu. Zadaniem recenzji jest nazywanie kontroli, aby decyzja była podejmowana celowo. A.8.3 (ograniczanie dostępu) może siedzieć obok niej, jeśli token jest sposobem, w jaki dostęp jest udzielany.
Zmiana wstecz, czyli ponowne włączenie wymagania requireMfa na trasie, lub przekierowanie generowania tokenów incydentów przez ścieżkę awaryjną, która jest rejestrowana i wygasa, jest tania w PR. Pozostawienie słabszej ścieżki w miejscu jest droższa wersja: sześć miesięcy później próbka organu certyfikującego może zapytać, jak są uwierzytelniane uprawnione działania, a kontekst jest utracony.
Gdzie heygrc się mieści i granica uczciwości
heygrc to aplikacja GitHub, która recenzuje każdy pull request w odniesieniu do wybranych przez Ciebie ram, i cytuje kontrolę Załącznika A, którą zmiana dotyczy, na przykład A.8.5 w przypadku omijania MFA powyżej, lub A.8.15, gdy uprawniona akcja przestaje być logowana. Nie certyfikuje Cię. Nie uruchamia Twojego ISMS. Nie pisze Oświadczenia o zastosowalności, nie wybiera organu certyfikującego ani nie wydaje certyfikatu. Nie heygrc, ani ISMS Copilot nie posiada certyfikatu ISO 27001. Używaj go jako recenzenta zmian, a nie jako systemu zarządzania.
Jeśli pytanie, które rzeczywiście wpisałeś, brzmiało "czy istnieje aplikacja GitHub dla ISO 27001", krótka odpowiedź brzmi tak, i znajduje się na swojej własnej stronie. Ten przewodnik jest drugą połową: co ta Aplikacja miałaby nawet sprawdzać i dlaczego większość ISO 27001 nigdy nie pojawi się w różnicy.