⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

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

Redakcja Clarysec
18 min read
Schemat blokowy przedstawiający trójfazowy proces CISO dotyczący wdrażania zabezpieczeń kompensujących dla szyfrowania danych w spoczynku, obejmujący ocenę ryzyka, warstwowe zabezpieczenia (DLP, maskowanie danych, kontrolę dostępu) oraz dokumentację audytową w ramach ISO 27001, GDPR i NIST.

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 audytowaWymagane dowodyTypowy test audytowy
ISO/IEC 27001Wpisy w rejestrze ryzyk, rejestr odstępstw od polityki, reguły DLP, inwentarze nośników danychPrzegląd logów ryzyka/odstępstw, żądanie logów działań DLP; prześledzenie cyklu życia nośników.
GDPRProcedury maskowania danych, gotowość do zgłoszenia naruszenia, zapisy usuwania danychPrzegląd przykładowych zbiorów danych (maskowane vs. niemaskowane), test wyzwalaczy DLP, symulacja scenariusza naruszenia.
NIS2/DORAWyniki testów kopii zapasowych/odtwarzania, oceny bezpieczeństwa dostawców, ćwiczenia reagowania na incydentySymulacja próby eksportu danych; przegląd procesów postępowania z kopiami zapasowymi; test kontroli DLP na danych krytycznych.
NIST/COBITLogi monitorowania technicznego, dokumentacja integracji polityk, wywiady z personelemSymulacja 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.

RyzykoPodstawowe zabezpieczenie (niewykonalne)Strategia zabezpieczeń kompensującychZasób ClarysecDowody dla audytora
Nieuprawnione ujawnienie danych w spoczynkuSzyfrowanie 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 nieprodukcyjnychSzyfrowanie kopii danych testowychMaskowanie 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.

RamyKluczowa klauzula/odniesienieJak uznawane są zabezpieczenia kompensujące
ISO/IEC 27001:20228.24, 7.10, 8.12, 8.11, 5.12Podejście oparte na ryzyku pozwala stosować alternatywne zabezpieczenia, takie jak DLP, zarządzanie nośnikami danych i maskowanie danych, jeżeli jest to uzasadnione.
GDPRArt. 5(1)(f), 25, 32Wymaga „odpowiednich” środków technicznych; pseudonimizacja, kontrole dostępu i DLP mogą spełnić ten wymóg, jeżeli szyfrowanie nie jest wykonalne.
NIS2Art. 21, 23Wymaga 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.
DORAArt. 5, 9, 10, 28Kł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-53SC-28, MP-2 to MP-7, AC-3/4, SI-4Dopuszcza 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.
COBITDSS05, APO13, MEA03Koncentruje 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:


Frequently Asked Questions

About the Author

Igor Petreski

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

Share this article

Related Articles

Od chaosu konfiguracji w chmurze do środowiska gotowego do audytu: projektowanie programu bezpieczeństwa chmury zgodnego z ISO 27001:2022 z wykorzystaniem zestawu narzędzi Zenith od Clarysec

Od chaosu konfiguracji w chmurze do środowiska gotowego do audytu: projektowanie programu bezpieczeństwa chmury zgodnego z ISO 27001:2022 z wykorzystaniem zestawu narzędzi Zenith od Clarysec

Dyrektorzy ds. bezpieczeństwa informacji, menedżerowie ds. zgodności i architekci chmury: zobaczcie, jak operacjonalizować zabezpieczenia ISO 27001:2022 dla środowisk chmurowych, aby utrzymywać ciągłą zgodność. Praktyczne scenariusze, techniczne tabele mapowania i użyteczne plany działania od Clarysec łączą bezpieczeństwo, ład organizacyjny i gotowość audytową w wielu ramach zgodności.