ISO 27001 w transferze plików: przewodnik wdrożeniowy

Certyfikacja ISO/IEC 27001:2022 dla systemu transferu plików oznacza wykazanie sprawnego Systemu Zarządzania Bezpieczeństwem Informacji (ISMS) obejmującego 93 kontrole z Załącznika A, ze szczególnym naciskiem na A.5.14 (transfer informacji), A.8.10 (usuwanie informacji), A.8.24 (stosowanie kryptografii) i A.8.26 (wymagania dotyczące bezpieczeństwa aplikacji). Rewizja z 2022 roku skonsolidowała wcześniejsze 114 kontroli do 93 w czterech obszarach tematycznych (organizacyjny, personalny, fizyczny, technologiczny) i dodała 11 nowych kontroli, w tym wywiad o zagrożeniach (A.5.7), gotowość ICT dla ciągłości działania (A.5.30) i bezpieczne kodowanie (A.8.28). Pierwsza certyfikacja zazwyczaj zajmuje 12–18 miesięcy i kosztuje 30–100 tys. EUR łącznie z opłatami audytowymi.

Zakres ISMS dla produktu do transferu plików

ISO 27001 wymaga zdefiniowania, co obejmuje ISMS. Zakres ISMS platformy do transferu plików zazwyczaj obejmuje: usługi przesyłania i pobierania, warstwę magazynowania obiektów, infrastrukturę zarządzania kluczami, systemy uwierzytelniania i autoryzacji, potok logowania audytu, narzędzia obsługi klienta mające dostęp do danych użytkowników oraz potok kompilacji i wdrożeń. Poza zakresem: strona marketingowa, wewnętrzne systemy HR, ogólna infrastruktura IT firmy. Zakres należy dokumentować precyzyjnie — niejednoznaczności tworzą ustalenia podczas certyfikacji.

A.5.14: kontrole transferu informacji

A.5.14 wymaga polityk i procedur dotyczących transferu informacji. Dla platformy do transferu plików jest to o tyle metapoziom, że produkt sam w sobie stanowi kontrolę dla klientów, ale potrzebne są też wewnętrzne kontrole regulujące sposób wymiany informacji przez zespół. Polityki powinny obejmować: zatwierdzone kanały transferu (sama platforma, podpisany i zaszyfrowany e-mail, SFTP dla dużych wolumenów), wymagania klasyfikacyjne (nie wysyłaj danych Poufnych przez niezatwierdzone kanały), weryfikację odbiorcy (potwierdź e-mail przed wysłaniem wrażliwych plików) oraz logowanie (każdy transfer logowany do SIEM). Należy opublikować wewnętrzną procedurę transferu i szkolić personel corocznie.

Ocena ryzyka według Klauzuli 6.1.2

ISO 27001 jest napędzane ryzykiem. Klauzula 6.1.2 wymaga udokumentowanej metodyki oceny ryzyka i rejestru ryzyk. Dla systemów transferu plików typowe ryzyka to: nieautoryzowany dostęp do przechowywanych plików, słaba kryptografia umożliwiająca odszyfrowanie, skompromitowane konta administratorów, zagrożenie wewnętrzne ze strony uprzywilejowanych operatorów, ryzyko łańcucha dostaw przez podprocesory, ataki DoS na punkty końcowe przesyłania, utrata danych z powodu awarii kopii zapasowych. Każde ryzyko należy ocenić pod kątem prawdopodobieństwa i wpływu w skali 1–5 lub 1–3. Kontrole z Załącznika A należy dobierać na podstawie wyników oceny. Deklaracja Stosowalności (SoA) dokumentuje, które z 93 kontroli mają zastosowanie i dlaczego — lub dlaczego nie.

A.8.24: wymagania dotyczące kryptografii

A.8.24 obejmuje prawidłowe stosowanie kryptografii. Powiązane wytyczne (ISO/IEC 27002:2022) oczekują: polityki kryptograficznej, wyboru algorytmów i długości kluczy zgodnie z aktualną najlepszą praktyką oraz zarządzania kluczami obejmującego generowanie, dystrybucję, przechowywanie, używanie, rotację, odzyskiwanie i niszczenie. Dla systemu transferu plików należy udokumentować: AES-256-GCM lub XChaCha20-Poly1305 dla zawartości, RSA-4096 lub Ed25519 dla podpisów, PBKDF2-SHA-256 przy 600 000+ iteracjach lub Argon2id dla kluczy opartych na haśle, TLS 1.3 dla transportu. Przechowywanie kluczy w HSM na poziomie FIPS 140-2 Level 2 lub odpowiedniku chmurowym (AWS CloudHSM, Azure Managed HSM). Rotacja kluczy głównych corocznie.

A.5.15 i A.8.3: kontrola dostępu i ograniczenie dostępu do informacji

A.5.15 wymaga polityki kontroli dostępu. A.8.3 wymaga ograniczenia dostępu do informacji zgodnie z polityką kontroli dostępu. Dla systemów transferu plików: egzekwowanie zasady najmniejszych uprawnień przez kontrolę dostępu opartą na rolach, wymaganie MFA dla dostępu administracyjnego (preferowany FIDO2), integracja z centralnym dostawcą tożsamości (Okta, Azure AD, Google Workspace), kwartalne przeglądy dostępu z udokumentowanym zatwierdzeniem oraz logowanie wszystkich prób dostępu. Audytor ISO 27001 będzie próbkować przyznania dostępu i przeglądy — należy je ułatwić przez eksporty IdP i integrację z systemem zgłoszeń.

A.8.10: usuwanie informacji i retencja

A.8.10 (nowe w 2022 roku) wymaga usuwania informacji, gdy nie są już potrzebne, zgodnie z polityką retencji. Dla platform transferu plików oznacza to: egzekwowanie automatycznego wygaśnięcia (typowo 7–30 dni), usunięcie zweryfikowane przez logi, synchronizację usuwania kopii zapasowych z usunięciem pierwotnym oraz bezpieczne usunięcie nośników fizycznych na koniec życia (nadpisywanie według DoD 5220.22-M lub kasowanie kryptograficzne przez zniszczenie klucza). Należy udokumentować politykę retencji per kategoria danych: pliki użytkownika 7 dni, logi audytu 365 dni, kopie zapasowe 30 dni rotacyjnie, zgłoszenia wsparcia 24 miesiące, dokumenty podatkowe 7 lat.

A.5.30: gotowość ICT dla ciągłości działania

Nowe w 2022 roku. Wymaga gotowości systemów ICT do zapewnienia ciągłości działania. Przekłada się to na: przetestowany plan DR z udokumentowanymi RPO i RTO, kwartalne testowanie integralności kopii zapasowych, roczne testowanie przełączania awaryjnego, plan reagowania na incydenty zgodny z ISO 22301 i procedury komunikacji kryzysowej. Dla platformy transferu plików należy udokumentować RPO (np. 1 godzina — maksymalna tolerowana utrata danych) i RTO (np. 4 godziny — maksymalny czas odzysku). Dostawcy chmury (AWS, Azure, OVH) umożliwiają architektury multi-AZ i multi-region, które spełniają większość scenariuszy.

A.5.7 i A.5.23: wywiad o zagrożeniach i usługi chmurowe

A.5.7 (nowe) wymaga gromadzenia i analizy wywiadu o zagrożeniach. W praktyce: subskrypcja ostrzeżeń sektorowego CERT, alertów CSIRT NASK, biuletynów bezpieczeństwa dostawców (AWS Security Bulletins, Cloudflare Radar). Należy dokumentować sposób, w jaki informacje wywiadowcze zasilają zarządzanie ryzykiem i podatnościami. A.5.23 (nowe) wymaga polityk i procedur dotyczących korzystania z usług chmurowych. Dla dostawców transferu plików hostowanych na AWS, Azure lub OVH należy dokumentować: kryteria wyboru dostawcy chmury, podział odpowiedzialności (model współdzielonej odpowiedzialności), zobowiązania dotyczące lokalizacji danych i strategię wyjścia.

A.8.28: bezpieczne kodowanie

Nowe w 2022 roku. Wymaga stosowania zasad bezpiecznego kodowania. Dla kodu transferu plików: SAST w CI (Semgrep, SonarQube, Checkmarx), DAST przed wydaniem (OWASP ZAP, Burp Suite), skanowanie zależności (Snyk, Dependabot, Trivy), skanowanie sekretów (gitleaks, TruffleHog), obowiązkowy przegląd kodu z listą kontrolną skoncentrowaną na bezpieczeństwie, modelowanie zagrożeń dla głównych funkcji i roczne szkolenia z OWASP Top 10. Dowody, których audytor oczekuje: konfiguracje pipeline CI pokazujące kroki SAST/DAST, raporty skanów za okres audytu, SLA naprawy (krytyczne 7 dni, wysokie 30 dni) i rekordy ukończenia szkoleń.

Audyt wewnętrzny i przegląd zarządzania

Klauzula 9.2 wymaga programu audytu wewnętrznego. Audyty należy przeprowadzać co najmniej corocznie, obejmując pełny ISMS lub rotacyjnie przez trzyletni cykl. Klauzula 9.3 wymaga przeglądu zarządzania — zazwyczaj kwartalnie — obejmującego wydajność ISMS, trendy KPI, ustalenia audytu, zmiany rejestru ryzyk i potrzeby zasobów. Należy dokumentować protokoły i działania. Organ certyfikacyjny przejrzy rekordy audytu wewnętrznego i przeglądu zarządzania jako silne wskaźniki dojrzałości ISMS — słabe rekordy oznaczają poważne ustalenia niezależnie od technicznych kontroli.

Audyt certyfikacyjny i nadzór

Audyt Stage 1 (1–3 dni): przegląd dokumentów, ocena gotowości. Audyt Stage 2 (3–10 dni w zależności od zakresu): próbkowanie dowodów na miejscu lub zdalnie, wywiady, kontrole techniczne. Certyfikat ważny przez trzy lata, z rocznymi audytami nadzorczymi (1–3 dni każdy) i pełną recertyfikacją w roku trzecim. Poważne niezgodności muszą być usunięte przed wydaniem certyfikatu; mniejsze mogą pozostać z planami działań naprawczych. Należy wybrać akredytowany organ certyfikacyjny (BSI, DNV, TÜV SÜD, DEKRA, LRQA, SGS) — certyfikacje od nieakredytowanych organów nie są uznawane przez działy zakupów.

Budowanie architektury gotowej na ISO 27001

Platforma transferu plików wchodząca do certyfikacji ISO 27001: wdrożenie multi-AZ w UE z DR w sparowanym regionie, szyfrowanie AES-256-GCM po stronie klienta plus AES-256 po stronie serwera w spoczynku, MFA FIDO2 egzekwowane przez IdP dla każdego dostępu administracyjnego, automatyczne 7-dniowe usunięcie z kryptograficznym kasowaniem opartym na kluczach, scentralizowane logowanie do niezmiennego magazynu, kwartalne przeglądy dostępu przez IdP, roczny test penetracyjny przez firmę certyfikowaną CREST, wykrywanie zagrożeń przez SIEM, udokumentowana DPA i rejestr podmiotów przetwarzających, oraz zespół bezpieczeństwa przeszkolony z kontroli z 2022 roku. Architektura HexaTransfer jest z większością z nich zgodna od razu; mniej ustrukturyzowani konkurenci wymagają 6–12 miesięcy napraw przed certyfikacją.

ISO 27001 nagradza dyscyplinę, nie bohaterstwo. Dokumentuj co robisz, rób co dokumentujesz. Wypróbuj na hexatransfer.com — bezpłatnie, bez rejestracji, do 10 GB.