Odpowiedź.

Historia pytania:

Wymagania dotyczące bezpieczeństwa informacji są kluczowym elementem dużych projektów IT od czasów, gdy zaczęły się pojawiać pierwsze standardy audytu bezpieczeństwa (na przykład ISO 27001 lub wymagania FZ-152 w Rosji). Bez dokładnej analizy i sformalizowania wymagań bezpieczeństwo systemu może okazać się jedynie deklaratywne i niepraktyczne.

Problem:

Wymagania dotyczące bezpieczeństwa często są formułowane w sposób abstrakcyjny ("wszystko musi być chronione"), nie uwzględniają rzeczywistych procesów biznesowych i architektury, nie są podzielone na poziomy: organizacyjne, technologiczne, użytkowe. Ponadto, klienci i deweloperzy mogą różnie interpretować te same wymagania — pojawia się niezgodność między wykonalnością a normatywnością.

Rozwiązanie:

Analityk systemowy zaczyna od analizy korporacyjnych, państwowych i branżowych standardów (na przykład: GOST, RODO, PCI DSS, ISO 27001). Następnie wspólnie z architektem i specjalistami ds. bezpieczeństwa identyfikuje procesy krytyczne dla biznesu, punkty przechowywania i przekazywania danych, potencjalne zagrożenia, określa listę odpowiednich ryzyk. Na ich podstawie analityk przygotowuje szczegółową matrycę wymagań dotyczących dostępu, przechowywania, logowania i szyfrowania, a także scenariusze incydentów. Po uzgodnieniu sformalizuje je w dokumentach — tak, aby każde wymaganie można było zweryfikować podczas testowania lub w trakcie audytu.

Kluczowe aspekty:

Wymagania dotyczące bezpieczeństwa są sformalizowane z uwzględnieniem architektury, procesów biznesowych i norm RegTech.
Niezbędne jest rozróżnienie polityk bezpieczeństwa organizacyjnych, technologicznych i użytkowych.
Konieczna jest ścisła współpraca ze specjalistami ds. bezpieczeństwa, architektem, prawnikiem oraz inżynierami QA.

Pytania z podstępem.

Dlaczego nie można polegać tylko na technicznych środkach bezpieczeństwa (antywirusach, zaporach sieciowych, SIEM)?

Ponieważ bezpieczeństwo informacji to proces, a nie tylko zestaw systemów. Kluczową rolę odgrywają procedury organizacyjne, czynnik ludzki, regularne kontrole oraz szkolenia użytkowników.

Czy można uznać wymagania za spełnione, jeśli system przeszedł jedynie wewnętrzne testy?

Nie — często do spełnienia norm wymagany jest zewnętrzny audyt, certyfikacja, a czasami nawet testy obciążeniowe pod kontrolą regulatora.

Czy wystarczy po prostu przekazać w specyfikacji wymaganie "system musi być zabezpieczony zgodnie z 152-FZ"?

Nie wystarczy — konieczne jest wskazanie konkretnych środków (kontrola dostępu, przechowywanie dzienników zdarzeń, szyfrowanie danych), miejsc ich wdrożenia oraz kryteriów weryfikacji.

Typowe błędy i antywzorce

Formułowanie rozmytych lub deklaratywnych wymagań ("powinno być bezpiecznie")
Oddzielenie procesu zabezpieczeń od analizy architektonicznej i biznesowej (pracują "równolegle", nie współpracują)
Przecenianie roli środków technicznych bez uwzględnienia czynników ludzkich i procesowych
Brak regularnej weryfikacji aktualności wymagań dotyczących bezpieczeństwa informacji

Przykład z życia

Negatywny przypadek: W projekcie bankowości internetowej analityk przekazał jedynie ogólną frazę "należy spełniać wymagania 152-FZ". Wykonawcy wdrożyli standardową autoryzację i certyfikat SSL, a na etapie zewnętrznego audytu okazało się, że nie ma kontroli przechowywania danych i niechroniony log autoryzacji.

Zalety:

Szybki rozwój

Wady:

Niezadowolenie regulatora
Ryzyko zablokowania uruchomienia

Pozytywny przypadek:

Na początku projektu analityk systemowy uzgodnił z ekspertami ds. bezpieczeństwa i klientem zestaw zagrożeń, opracował szczegółowe wymagania dotyczące szyfrowania i audytu dla każdego scenariusza, określił odpowiedzialnych. W efekcie system przeszedł audyt bez uwag.