Szyfrowanie danych w spoczynku nie jest możliwe? Przewodnik dla CISO po skutecznych zabezpieczeniach kompensujących

Ustalenie audytowe trafiło na biurko Sarah Chen, CISO, z dobrze znanym ciężarem. Krytyczna, generująca przychody baza danych w systemie zastanym, operacyjne serce linii produkcyjnej spółki, nie obsługiwała współczesnego szyfrowania danych w spoczynku. Jej architektura bazowa miała ponad dekadę, a dostawca dawno zakończył dostarczanie poprawek bezpieczeństwa. Audytor słusznie zakwalifikował ten stan jako istotne ryzyko. Zalecenie brzmiało: „Zaszyfrować wszystkie dane wrażliwe w spoczynku przy użyciu standardowych algorytmów branżowych”.
Dla Sarah nie był to wyłącznie problem techniczny; był to kryzys ciągłości działania. Modernizacja systemu oznaczałaby miesiące niedostępności i wielomilionowe koszty, co dla zarządu było nie do zaakceptowania. Pozostawienie dużego zbioru wrażliwej własności intelektualnej bez szyfrowania również stanowiło niedopuszczalne ryzyko i oczywiste odstępstwo od systemu zarządzania bezpieczeństwem informacji (SZBI).
Ten scenariusz dobrze oddaje realia cyberbezpieczeństwa, w których idealne rozwiązania są rzadkie, a zgodności nie można „wstrzymać”. Dotyczy to sytuacji, gdy krytyczne pliki kopii zapasowych są przechowywane w systemach zastanych, gdy kluczowy dostawca SaaS powołuje się na „ograniczenia techniczne” albo gdy aplikacje o wysokiej wydajności przestają działać pod ciężarem narzutu szyfrowania. Podręcznikowa odpowiedź „po prostu to zaszyfruj” często zderza się ze złożoną rzeczywistością operacyjną.
Co zatem zrobić, gdy podstawowe, wymagane zabezpieczenie nie jest dostępne? Nie należy po prostu zaakceptować ryzyka. Należy zbudować inteligentniejszą i bardziej odporną ochronę opartą na zabezpieczeniach kompensujących. Nie chodzi o szukanie wymówek, lecz o wykazanie dojrzałego, opartego na ryzyku zarządzania bezpieczeństwem, które wytrzyma najbardziej wymagającą ocenę audytową.
Dlaczego szyfrowanie danych w spoczynku jest wymaganiem o wysokiej wadze
Szyfrowanie danych w spoczynku jest podstawowym zabezpieczeniem we wszystkich nowoczesnych ramach bezpieczeństwa, w tym ISO/IEC 27001:2022, GDPR Article 32, NIS2, DORA oraz NIST SP 800-53 SC-28. Jego cel jest prosty, ale krytyczny: sprawić, aby przechowywane dane były nieczytelne, jeżeli zawiodą zabezpieczenia fizyczne lub logiczne. Utracona taśma z kopią zapasową albo skradziony serwer zawierający niezaszyfrowane dane to nie tylko uchybienie techniczne; często jest to naruszenie ochrony danych podlegające zgłoszeniu.
Ryzyka są jasne i istotne:
- Kradzież lub utrata nośników przenośnych, takich jak dyski USB i taśmy z kopiami zapasowymi.
- Ekspozycja danych z urządzeń niezarządzanych, zapomnianych lub zastanych.
- Brak możliwości zastosowania natywnego szyfrowania dysków lub baz danych w określonych kontekstach SaaS, chmury obliczeniowej, OT lub systemów zastanych.
- Ryzyka odzyskiwania danych w przypadku utraty kluczy szyfrowania albo niewłaściwego zarządzania nimi.
Wymagania te nie mają wyłącznie charakteru technicznego; są również obowiązkami prawnymi. GDPR Article 32 oraz DORA Articles 5 and 10 wprost uznają szyfrowanie za „odpowiedni środek techniczny”. NIS2 wskazuje je jako element bazowy zapewniania integralności systemów i informacji. Gdy ta podstawowa linia obrony nie jest wykonalna, ciężar dowodu przechodzi na organizację, która musi wykazać, że jej środki alternatywne są równie skuteczne.
Od pojedynczego pola kontrolnego do obrony warstwowej
Odruchową reakcją na ustalenie audytowe podobne do przypadku Sarah bywa panika. Dobrze ustrukturyzowany SZBI przewiduje jednak takie sytuacje. Pierwszym krokiem Sarah nie był telefon do zespołu infrastruktury; otworzyła Politykę zabezpieczeń kryptograficznych swojej organizacji, dokument zbudowany na podstawie szablonów korporacyjnych Clarysec. Przeszła bezpośrednio do klauzuli, która stanowiła podstawę jej strategii.
Zgodnie z Polityką zabezpieczeń kryptograficznych, sekcja 7.2.3 wprost opisuje proces definiowania:
„Konkretnych zabezpieczeń kompensujących, które mają zostać zastosowane”
Ta klauzula jest jednym z najważniejszych narzędzi CISO. Uznaje, że uniwersalne podejście do bezpieczeństwa jest wadliwe, i zapewnia zatwierdzoną ścieżkę postępowania z ryzykiem. Polityka nie funkcjonuje w oderwaniu od pozostałych dokumentów. Jak wskazano w klauzuli 10.5, jest bezpośrednio powiązana z Polityką klasyfikacji i oznaczania informacji, która „Definiuje poziomy klasyfikacji (np. Poufne, dane regulowane), uruchamiające określone wymagania szyfrowania”.
To powiązanie ma kluczowe znaczenie. Dane w bazie systemu zastanego zostały sklasyfikowane jako „Poufne”, dlatego brak szyfrowania został oznaczony jako problem. Misja Sarah była teraz jasna: zbudować tak solidną warstwę zabezpieczeń kompensujących, aby ograniczyć ryzyko ujawnienia do akceptowalnego poziomu.
Projektowanie możliwej do obrony strategii z wykorzystaniem Zenith Blueprint
Szyfrowanie jest jednym z filarów współczesnego bezpieczeństwa, ale jak wyjaśnia Clarysec w Zenith Blueprint: An Auditor’s 30-Step Roadmap, w kroku 21, zabezpieczenie 8.24 dotyczące stosowania kryptografii nie polega jedynie na „włączeniu szyfrowania”. Chodzi raczej o „wbudowanie kryptografii w projekt organizacji, polityki i zarządzanie cyklem życia”.
Gdy jeden element projektu, czyli baza danych systemu zastanego, zawodzi, zrekompensować muszą to aspekty dotyczące polityk i cyklu życia. Zespół Sarah wykorzystał te ramy do zaprojektowania wielowarstwowej ochrony opartej na założeniu, że dane nigdy nie powinny opuścić bezpiecznego, choć niezaszyfrowanego, kontenera.
Zabezpieczenie kompensujące 1: zapobieganie wyciekom danych (DLP)
Jeżeli nie można zaszyfrować danych tam, gdzie są przechowywane, należy zapewnić, że nie będą mogły tego miejsca opuścić. Zespół Sarah wdrożył rozwiązanie do zapobiegania wyciekom danych (DLP), które pełniło funkcję cyfrowego strażnika. Nie była to prosta reguła sieciowa, lecz zaawansowane, świadome treści zabezpieczenie.
Korzystając z Zenith Controls: The Cross-Compliance Guide Clarysec, skonfigurowali system DLP na podstawie wytycznych dla zabezpieczenia ISO/IEC 27001:2022 8.12 dotyczącego zapobiegania wyciekom danych. Reguły były bezpośrednio powiązane z 5.12 Classification of information. Wszystkie dane odpowiadające wzorcom informacji „Poufnych” w bazie systemu zastanego były automatycznie blokowane przy próbie transferu przez e-mail, przesyłanie przez WWW, a nawet kopiowanie i wklejanie do innych aplikacji.
Jak wyjaśnia Zenith Controls:
„Zapobieganie wyciekom danych (DLP) zasadniczo zależy od dokładnej klasyfikacji danych. Zabezpieczenie 5.12 zapewnia oznaczanie danych zgodnie z ich wrażliwością… DLP jest wyspecjalizowaną formą ciągłego monitorowania, ukierunkowaną na przepływ danych… 8.12 może egzekwować polityki szyfrowania dla danych opuszczających organizację, zapewniając, że nawet w przypadku eksfiltracji danych pozostaną one nieczytelne dla nieuprawnionych stron”.
To zabezpieczenie jest uznawane w wielu ramach, z mapowaniem do GDPR Art. 32, NIS2 Art. 21, DORA Art. 10 oraz NIST SP 800-53 SI-4. Wdrażając je, zespół Sarah utworzył silną strefę ochronną, zapewniając izolację niezaszyfrowanych danych.
Zabezpieczenie kompensujące 2: maskowanie danych do użycia poza produkcją
Jednym z największych ryzyk związanych z danymi w systemach zastanych jest ich wykorzystywanie w innych środowiskach. Zespół programistyczny regularnie potrzebował danych z systemu produkcyjnego, aby testować nowe funkcje aplikacji. Przekazanie mu niezaszyfrowanych, poufnych danych nie wchodziło w grę.
W tym miejscu Sarah odwołała się do kroku 20 Zenith Blueprint, który obejmuje 8.11 Data masking. Przewodnik wskazuje, że audytorzy wprost zapytają: „Czy kiedykolwiek używacie rzeczywistych danych osobowych w systemach testowych? Jeśli tak, jak są chronione?”.
Zgodnie z tymi wytycznymi zespół Sarah wdrożył rygorystyczną procedurę maskowania danych. Każdy wyciąg danych zamawiany przez zespół programistyczny musiał przejść przez zautomatyzowany proces pseudonimizacji lub anonimizacji pól wrażliwych. Nazwy klientów, zastrzeżone formuły i metryki produkcyjne zastępowano realistycznymi, lecz fikcyjnymi danymi. To pojedyncze zabezpieczenie wyeliminowało znaczną część powierzchni ryzyka, zapewniając, że dane wrażliwe nigdy nie opuszczą ściśle kontrolowanego środowiska produkcyjnego w swojej oryginalnej postaci.
Zabezpieczenie kompensujące 3: wzmocnione kontrole fizyczne i logiczne
Po zaadresowaniu wycieków danych i użycia poza produkcją ostatnia warstwa ochrony skupiła się na samym systemie. Opierając się na zasadach 7.10 Storage media z Zenith Controls, zespół Sarah potraktował fizyczny serwer jako aktywo o wysokich wymaganiach bezpieczeństwa. Chociaż 7.10 często kojarzy się z nośnikami wymiennymi, jego zasady zarządzania cyklem życia i bezpieczeństwa fizycznego mają tu pełne zastosowanie.
Jak wskazuje Zenith Controls w tym obszarze:
„ISO/IEC 27002:2022 zawiera kompleksowe wytyczne w klauzuli 7.10 dotyczące bezpiecznego zarządzania nośnikami danych przez cały ich cykl życia. Norma zaleca organizacjom utrzymywanie rejestru wszystkich nośników wymiennych…”
Stosując tę logikę, serwer przeniesiono do dedykowanej, zamykanej szafy w centrum danych, dostępnej wyłącznie dla dwóch imiennie wskazanych starszych inżynierów. Dostęp fizyczny wymagał wpisu do rejestru i był monitorowany przez CCTV. Po stronie sieciowej serwer umieszczono w segmentowanej sieci VLAN „systemy zastane”. Reguły zapory sieciowej skonfigurowano zgodnie z zasadą domyślnej odmowy, z jedną jednoznaczną regułą dopuszczającą komunikację wyłącznie z wyznaczonego serwera aplikacyjnego na określonym porcie. Tak daleko idąca izolacja radykalnie ograniczyła powierzchnię ataku, czyniąc niezaszyfrowane dane niewidocznymi i niedostępnymi.
Przed audytem: prezentacja możliwej do obrony strategii z wielu perspektyw
Gdy audytor wrócił na działania następcze, Sarah nie przedstawiała wymówek. Przedstawiła kompletny plan postępowania z ryzykiem, obejmujący dokumentację, logi oraz demonstracje działania zabezpieczeń kompensujących wdrożonych przez jej zespół. Audyt nie jest pojedynczym wydarzeniem; jest rozmową prowadzoną z różnych perspektyw, a CISO musi być przygotowany na każdą z nich.
Perspektywa audytora ISO/IEC 27001: Audytor chciał zobaczyć skuteczność operacyjną. Zespół Sarah zademonstrował blokowanie nieautoryzowanej wiadomości e-mail przez system DLP, pokazał działający skrypt maskowania danych oraz przedstawił logi dostępu fizycznego powiązane ze zgłoszeniami roboczymi.
Perspektywa GDPR i prywatności: Audytor zapytał, w jaki sposób egzekwowana jest minimalizacja danych. Sarah pokazała zautomatyzowane skrypty bezpiecznego usuwania danych z pamięci podręcznej oraz proces pseudonimizacji wszystkich danych opuszczających system produkcyjny, zgodny z GDPR Article 25 (ochrona danych w fazie projektowania oraz domyślna ochrona danych). Cryptographic Controls Policy-sme wprost przypisuje DPO odpowiedzialność za to, aby „zapewniał zgodność środków szyfrowania z obowiązkami w zakresie ochrony danych wynikającymi z Article 32 GDPR”.
Perspektywa NIS2/DORA: Ta perspektywa koncentruje się na odporności operacyjnej. Sarah przedstawiła wyniki testów tworzenia kopii zapasowych i odtwarzania dla izolowanego systemu oraz aneksy bezpieczeństwa dostawcy dla oprogramowania systemu zastanego, wykazując proaktywne zarządzanie ryzykiem wymagane przez NIS2 Article 21 oraz DORA Article 9.
Perspektywa NIST/COBIT: Audytor korzystający z tych ram szuka dowodów ładu organizacyjnego i metryk. Sarah przedstawiła zaktualizowany rejestr ryzyk z formalną akceptacją ryzyka szczątkowego (COBIT APO13). Przypisała DLP do NIST SP 800-53 SI-4 (monitorowanie systemu), segmentację sieci do SC-7 (ochrona granic) oraz kontrole dostępu do AC-3 i AC-4, wykazując, że choć SC-28 (ochrona informacji w spoczynku) nie został spełniony bezpośrednio, wdrożono równoważny zestaw zabezpieczeń.
Kluczowe dowody audytowe dla zabezpieczeń kompensujących
Aby skutecznie zakomunikować swoją strategię, zespół Sarah przygotował dowody dostosowane do oczekiwań audytorów.
| Perspektywa audytowa | Wymagane dowody | Typowy test audytowy |
|---|---|---|
| ISO/IEC 27001 | Wpisy w rejestrze ryzyk, rejestr odstępstw od polityki, reguły DLP, inwentarze nośników danych | Przegląd logów ryzyka/odstępstw, żądanie logów działań DLP; prześledzenie cyklu życia nośników. |
| GDPR | Procedury maskowania danych, gotowość do zgłoszenia naruszenia, zapisy usuwania danych | Przegląd przykładowych zbiorów danych (maskowane vs. niemaskowane), test wyzwalaczy DLP, symulacja scenariusza naruszenia. |
| NIS2/DORA | Wyniki testów kopii zapasowych/odtwarzania, oceny bezpieczeństwa dostawców, ćwiczenia reagowania na incydenty | Symulacja próby eksportu danych; przegląd procesów postępowania z kopiami zapasowymi; test kontroli DLP na danych krytycznych. |
| NIST/COBIT | Logi monitorowania technicznego, dokumentacja integracji polityk, wywiady z personelem | Symulacja eksfiltracji danych, porównanie polityki z procedurą, wywiady z kluczowymi opiekunami danych i właścicielami systemów. |
Przewidując te różne perspektywy, Sarah przekształciła potencjalną niezgodność w dowód dojrzałości bezpieczeństwa.
Praktyczne podsumowanie przed kolejnym audytem
Aby strategia była jasna i możliwa do obrony, zespół Sarah przygotował tabelę podsumowującą w planie postępowania z ryzykiem. Jest to podejście, które może zastosować każda organizacja.
| Ryzyko | Podstawowe zabezpieczenie (niewykonalne) | Strategia zabezpieczeń kompensujących | Zasób Clarysec | Dowody dla audytora |
|---|---|---|---|---|
| Nieuprawnione ujawnienie danych w spoczynku | Szyfrowanie pełnodyskowe (AES-256) | 1. Zapobieganie wyciekom danych (DLP): Monitorowanie i blokowanie wszystkich nieautoryzowanych prób eksfiltracji danych na podstawie treści i kontekstu. | Zenith Controls (8.12) | Konfiguracja polityki DLP, logi alertów, procedury reagowania na incydenty. |
| 2. Rygorystyczna kontrola dostępu logicznego: Izolacja serwera w segmentowanej sieci z regułami zapory typu domyślnej odmowy oraz silnie ograniczonym dostępem kont serwisowych. | Zenith Controls (8.3) | Diagramy sieciowe, zestawy reguł zapory sieciowej, przeglądy uprawnień użytkowników, polityka danych uwierzytelniających kont serwisowych. | ||
| 3. Wzmocnione bezpieczeństwo fizyczne: Umieszczenie serwera w dedykowanej, zamykanej szafie z rejestrowanym i monitorowanym dostępem fizycznym. | Zenith Controls (7.10) | Logi dostępu do centrum danych, zapisy z monitoringu CCTV, arkusze wydania kluczy do szafy. | ||
| Wykorzystanie danych wrażliwych w środowiskach nieprodukcyjnych | Szyfrowanie kopii danych testowych | Maskowanie danych: Wdrożenie formalnej procedury pseudonimizacji lub anonimizacji wszystkich wyciągów danych przed użyciem w środowiskach testowych lub rozwojowych. | Zenith Blueprint (Step 20) | Formalny dokument procedury maskowania danych, demonstracja skryptów maskujących, przykładowy zamaskowany zbiór danych. |
Przekrojowa zgodność w skrócie
Silna strategia zabezpieczeń kompensujących jest możliwa do obrony we wszystkich głównych ramach. Zenith Controls Clarysec zapewnia mapowanie przekrojowe, które pozwala upewnić się, że zabezpieczenia są powszechnie rozumiane i akceptowane.
| Ramy | Kluczowa klauzula/odniesienie | Jak uznawane są zabezpieczenia kompensujące |
|---|---|---|
| ISO/IEC 27001:2022 | 8.24, 7.10, 8.12, 8.11, 5.12 | Podejście oparte na ryzyku pozwala stosować alternatywne zabezpieczenia, takie jak DLP, zarządzanie nośnikami danych i maskowanie danych, jeżeli jest to uzasadnione. |
| GDPR | Art. 5(1)(f), 25, 32 | Wymaga „odpowiednich” środków technicznych; pseudonimizacja, kontrole dostępu i DLP mogą spełnić ten wymóg, jeżeli szyfrowanie nie jest wykonalne. |
| NIS2 | Art. 21, 23 | Wymaga podejścia opartego na ryzyku; warstwowe zabezpieczenia, takie jak DLP, ochrona kopii zapasowych i kontrole dostawców, są prawidłowymi sposobami postępowania z ryzykiem. |
| DORA | Art. 5, 9, 10, 28 | Kładzie nacisk na odporność operacyjną; DLP, kontrola dostępu i solidne rejestrowanie są kluczowe dla ochrony danych finansowych, niezależnie od tego, czy stosowane jest szyfrowanie. |
| NIST SP 800-53 | SC-28, MP-2 to MP-7, AC-3/4, SI-4 | Dopuszcza zabezpieczenia kompensujące; DLP (SI-4), ograniczenia dostępu (AC-3) i ewidencjonowanie nośników (seria MP) mogą adresować ryzyka związane z niezaszyfrowanymi danymi. |
| COBIT | DSS05, APO13, MEA03 | Koncentruje się na ładzie organizacyjnym i pomiarze; udokumentowana akceptacja ryzyka (APO13) oraz monitorowanie zabezpieczeń kompensujących (MEA03) wykazują należytą staranność. |
Wniosek: przekształć najsłabsze ogniwo w mocną stronę
Historia bazy danych w systemie zastanym, której nie da się zaszyfrować, nie jest historią porażki. To historia dojrzałego, inteligentnego zarządzania ryzykiem. Odmawiając przyjęcia prostej odpowiedzi „tego nie da się zrobić”, zespół Sarah przekształcił istotną podatność w przykład swoich zdolności obrony w głąb. Udowodnił, że bezpieczeństwo nie polega na odhaczeniu pojedynczego pola z etykietą „szyfrowanie”. Polega na zrozumieniu ryzyka oraz zbudowaniu przemyślanej, warstwowej i możliwej do prześledzenia audytowo ochrony, która to ryzyko ogranicza.
Twoja organizacja nieuchronnie będzie mieć własną wersję takiej bazy w systemie zastanym. Gdy ją znajdziesz, nie traktuj jej jako blokady. Potraktuj ją jako okazję do zbudowania bardziej odpornego i możliwego do obrony programu bezpieczeństwa.
Chcesz zbudować własne, niezawodne i gotowe do audytu ramy zabezpieczeń? Zacznij od właściwych fundamentów.
- Przeanalizuj ekosystem polityk swojej organizacji z wykorzystaniem kompleksowych pakietów polityk Clarysec.
- Poznaj Zenith Blueprint: An Auditor’s 30-Step Roadmap, aby przeprowadzić wdrożenie krok po kroku.
- Wykorzystaj Zenith Controls: The Cross-Compliance Guide, aby upewnić się, że Twoje zabezpieczenia wytrzymają ocenę z każdej perspektywy.
Skontaktuj się z Clarysec, aby omówić warsztat dopasowany do potrzeb organizacji lub pełną ocenę przekrojowej zgodności. W dzisiejszym krajobrazie regulacyjnym przygotowanie jest bowiem jedynym zabezpieczeniem, które naprawdę ma znaczenie.
Odniesienia:
- Polityka zabezpieczeń kryptograficznych
- Cryptographic Controls Policy-sme
- Polityka klasyfikacji i oznaczania informacji
- Zenith Blueprint: An Auditor’s 30-Step Roadmap
- Zenith Controls: The Cross-Compliance Guide
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

