Ochrona danych i odporność enterprise: backupy, ciągłość i klasyfikacja

Atakujący nie gonią diagramów VLAN — gonią rekordy. Regulatorzy i klienci nie przejmą się sprytną regułą firewall, jeśli dane payroll wychodzą drzwiami. Outage karze z innej strony: brak backupów, brak planu ciągłości, brak testowanego restore — i ransomware staje się końcem biznesu zamiast złym tygodniem.

SY0-701 Domena 3 oczekuje ochrony danych w każdym stanie, poprawnej klasyfikacji i utrzymania operacji przy awariach. Ten wpis łączy te wątki ze scenariuszami, słownictwem ciągłości i pułapkami egzaminu.

Stany danych: rest, transit i use

Kontrolki muszą pasować do stanu danych w momencie zastosowania. Kontrola at rest może nic nie dać in transit lub gdy analityk ma otwarty arkusz.

Data at rest

Data at rest leży na dysku, taśmie, object storage, bazach, urządzeniach mobilnych, targetach backupu. Typowe kontrolki:

• FDE i szyfrowanie wolumenu/pliku
• Szyfrowanie bazy (TDE) z separacją kluczy
• Tokenizacja i data masking tam, gdzie nie powinno być live PAN/SSN
• ACL, RBAC, bezpieczeństwo fizyczne nośników

Znaczenie: Stemy ze skradzionym laptopem testują FDE + silną autentykację — nie samo „zmień hasło po kradzieży” przy nieszyfrowanym dysku.

Data in transit

Data in transit porusza się po sieci — sesje WWW, API, e-mail, tunele VPN, replikacja między site. Kontrolki: TLS 1.2+, IPsec VPN, SSH, secure email gateways, walidacja certyfikatów (bez ślepego zaufania self-signed w produkcji).

Pułapka: „Używamy HTTPS”, podczas gdy east-west wewnętrznie plaintext na płaskiej sieci — intruz po pivot nadal czyta.

Data in use

Data in use jest aktywnie przetwarzana — rejestry CPU, pamięć, pipeline analityczne, współdzielone ekrany. Kontrolki trudniejsze, średnia głębokość egzaminu:

• Least privilege — tylko konieczne procesy dotykają wrażliwych pól
• DLP na endpointach i w chmurze blokujący paste/export
• Browser isolation dla ryzykownych workflow WWW
• Confidential computing (TEE/enclaves) — izolacja HW do przetwarzania w niezaufanej infrastrukturze chmurowej

Scenariusz: Agent supportu ogląda rekordy klienta w web app. Mitygacje: autoryzacja RBAC w aplikacji, timeout sesji, DLP blokujący download na urządzenie osobiste, logowanie dostępu — nie samo VPN do app.

Każdy wiersz: „co psuje się, gdy szyfrujemy tylko at rest?” — często nadużycie insider i session hijack na żywo.

Klasyfikacja steruje obsługą

Data classification etykietuje informacje wg wrażliwości i wymogów prawnych — typowe poziomy public, internal, confidential, restricted/secret (nazwy zależą od polityki). Klasyfikacja odpowiada:

• Kto może mieć dostęp lub przechowywać
• Czy szyfrowanie jest obowiązkowe
• Czy dane mogą opuścić geografię
• Retencja i secure deletion
• Czy stosować DLP

Przykład: Publiczne broszury marketingowe vs oceny pracownicze. Te drugie confidential/internal — nie na consumer cloud sync bez CASB/DLP i umów.

Scenariusz: Executive wysyłają decki zarządu przez personal webmail. Błędy: brak narzędzi sankcjonowanych, brak DLP, słabe szkolenie, brak klasyfikacji. Ścieżka: zatwierdzona platforma współpracy, DLP blokujący external send oznaczonych dokumentów, coaching executive — nie „blokuj cały e-mail”.

Prywatność i regulacje

Cele GDPR-style dominują w Domenie 5, ale architektura umożliwia compliance: szyfrowanie, logi dostępu, limity retencji, workflow right-to-erasure, data minimization w design. Bez mapy danych w systemach nie usuniesz ani nie ochronisz PII.

Pułapka: „Szyfruj wszystko”, gdy stem pyta o data minimization lub redukcję retencji — szyfrowanie chroni poufność; nie redukuje nielegalnej kolekcji.

Słownictwo ciągłości na egzaminie

RTO (Recovery Time Objective) — maksymalny akceptowalny downtime przed powrotem usługi.

RPO (Recovery Point Objective) — maksymalna akceptowalna utrata danych w czasie (jak świeże backupy).

Scenariusz: Payroll w 24 h; utrata >1 h edycji payroll niedopuszczalna. RTO = 24h, RPO = 1h. Częstotliwość backupu i hot standby wynikają z liczb — nie odwrotnie.

Pułapka: Mylenie RTO z RPO. Mnemotechnika: RPO o punktach danych (ile tracisz); RTO o czasie powrotu online.

Backupy jako kontrola bezpieczeństwa

Backupy bronią przed ransomware, przypadkowym usunięciem, korupcją — ale tylko z właściwościami, które egzamin teraz podkreśla:

1. Regularne testowane restore — nietestowane backupy to wishful thinking
2. Offline lub immutable copies — ransomware nie szyfruje tego, czego nie sięga
3. Access control na infrastrukturę backup — admini backupu to cele high-value
4. Oddzielne creds/domena — nie trzymaj backupów tam, gdzie kompromitacja domeny je też niszczy
5. Retencja zgodna z RPO i legal hold

Reguła 3-2-1 (trzy kopie, dwa media, jedna offsite) — common sense; egzamin może pchać immutable object storage, air-gap taśma, replikacja ze snapshot isolation.

Pułapka: „Replikujemy na hot site”, gdy replikacja w czasie rzeczywistym kopiuje zaszyfrowane pliki — skopiowałeś też ransomware. Potrzeba point-in-time recovery i izolowanych snapshotów.

Scenariusz backupu

Stem: Ransomware szyfruje file serwery w piątek 18:00. Backupy nightly na NAS w tej samej domenie AD; snapshoty widoczne z kont adminów plików.

Błędy: Wspólne zaufanie domeny, brak offline/immutable tier, backupy na ścieżce compromise.

Silna odpowiedź: Izoluj zainfekowane systemy, zachowaj dowody jeśli wymagane, restore z czystego immutable/offline sprzed infekcji, przebuduj tożsamość jeśli domena untrusted, test sample restore przed masową recovery, komunikacja wg drzewa BCP.

Słaba: „Zapłać okup” lub „Reboot serwerów”.

Wzorce odporności poza backupami

Resilience utrzymuje usługi przy awarii komponentu — nie tylko pełnej katastrofie.

• Redundancja — dual power, NIC teaming, RAID (RAID ≠ backup)
• Clustering — active/active lub active/passive app tiers
• Load balancing — dystrybucja ruchu; health checks usuwają złe węzły
• Geographic diversity — przeżycie utraty site (trzęsienie, regionalny outage chmury)
• Failover ordering — najpierw zależności (DNS, tożsamość, bazy przed aplikacjami)

HA bez dyscypliny security duplikuje podatności — patch oba węzły, harden oba, monitor oba.

Scenariusz: Obrazowanie szpitalne musi być online. Clustering app tier, geo-redundant storage, udokumentowane manual downtime procedures przy fail automatic — dostępność jako filar CIA.

Bezpieczne techniki dla zasobów obliczeniowych

Domena 3 oczekuje secure deployment i hardening na serwerach, VM, kontenerach, aplikacjach:

• Usuń default accounts i hasła
• Wyłącz niepotrzebne usługi i porty
• Benchmarki vendora (CIS-style baselines)
• Patch w rytmie ze change control
• Bezpieczne protokoły; wycofaj TLS 1.0/1.1 i słabe szyfry
• Secrets management — nie env vars w obrazach
• Secure SDLC: walidacja wejścia, code review, skan zależności

Dla aplikacji architektura spotyka development: parameterized queries, output encoding, testy security przed prod, separacja dev/test/prod (bez real PII w dev).

Pułapka: „Air-gap dev”, gdy problem to production data in dev — minimization i masking biją fizyczną dramaturgię.

Mini-scenariusze z pełną ścieżką

1. Legacy z wolnym patchingiem

Stem: Sieć OT nie patchuje co miesiąc; vendor certyfikuje firmware raz rocznie.

Wątek: Segmentuj OT od IT, monitoruj anomalie protokołów, virtual patching/IPS na granicach, jump host z MFA, SLA vendora, udokumentowane kontrolki kompensacyjne w rejestrze ryzyka — nie obowiązkowy natychmiastowy patch.

2. Shadow cloud storage

Stem: Sprzedaż trzyma umowy klientów w personal cloud sync.

Wątek: CASB discovery, sankcjonowany SaaS, DLP blokujący upload sklasyfikowanych docs, MDM na urządzeniach firmowych, szkolenie, polityka klasyfikacji — nie tylko „zwolnij handlowca” bez kontrol prewencyjnych.

3. Audyt regulacyjny danych osobowych

Stem: Audytor pyta, jak usuwacie dane użytkownika na żądanie w CRM, data warehouse i backupach.

Wątek: Mapa/inventory danych, harmonogramy retencji, crypto-shredding lub workflow deletion, udokumentowane wyjątki legal hold, wygaśnięcie backupów wg polityki — privacy by design, nie ad hoc SQL deletes.

4. Utrata site

Stem: Powódź niszczy primary datacenter.

Wątek: Wykonaj DRP, failover na warm/hot site wg RTO/RPO, aktywuj comms BCP, waliduj integralność przywróconych danych, post-incident review — BIA priorytetyzuje kolejność (portal płatności przed wewnętrznym wiki).

Sanityzacja nośników i koniec życia

Secure disposal w celach operacji, ale architektonicznie: gdzie dane spoczywają na sprzęcie decyduje o metodzie.

• Clear — logic overwrite (ryzykowne samo dla top sensitivity)
• Purge — silniejsze logiczne lub degauz
• Destroy — fizyczna destrukcja top tiers

Zgubiony laptop z nieszyfrowanym dyskiem = awaria at rest + scenariusz utraty — FDE i remote wipe redukują wpływ.

Składanie triady

Gdy stem wspomina „architekturę” i dane, zadaj trzy pytania:

1. Gdzie żyją wrażliwe dane (w tym backupy i SaaS)?
2. Kto może je dotrzeć (tożsamość, ścieżka sieciowa, role admin)?
3. Jak przetrwamy utratę site, platformy lub weekendu systemów?

Ta triada niesie większość pytań Domeny 3 o dane i odporność. Klasyfikacja mówi jak poważne są dane. Szyfrowanie i DLP egzekwują poufność. Backupy, RTO/RPO, DRP/BCP egzekwują dostępność i recovery. Least privilege i logowanie wspierają integralność i rozliczalność.

Pułapki — recap

Drill studyjny

Dla każdego wyimaginowanego assetu (e-mail, ERP, baza PII, logi IoT) zapisz:

• Poziom klasyfikacji
• Kontrolki at rest, in transit, in use
• RTO/RPO jeśli business-critical
• Typ backupu (offline/immutable? testowany?)

Pięć minut na asset bije ponowne czytanie glosariuszy. Ochrona danych i odporność to nie osobne tematy — to dowód, że architektura zasługiwała na nazwę „secure”.