Usługi / Bezpieczeństwo danych
DaneProjektujemy i utrzymujemy ochronę danych, klucze i kopie
Projektujemy, wdrażamy i utrzymujemy ochronę zbiorów, kluczy i kopii. Zaczynamy od Waszych danych: które zbiory są krytyczne, gdzie leżą, kto ma klucz. Potem stawiamy szyfrowanie, KMS i dwa tory kopii. Wazuh pilnuje dostępu i integralności. Zostajemy przy restore, retencji i śladzie pod RODO.
Jak to składa się w całość
Od zbiorów do ochrony, kopii i śladu
Najpierw rozumiemy, jakie zbiory chronić i kto ma klucz. Na tej podstawie składamy platformę, backup, detekcję dostępu i raport. Proxmox Backup Server, KMS, Wazuh i Grafana służą do tej pracy na co dzień.
- Klasyfikacja danych ustala, co idzie na tor B i jaka jest retencja.
- Test restore jest wpisem w kalendarzu, z raportem dla Was i dla audytu.
Stawiamy dwa tory kopii na osobnych kontach
Dobieramy tor blisko produkcji i drugi tor poza lokalizacją do Waszych zbiorów. Proxmox Backup Server albo równoważny mechanizm, object lock, osobny klucz. Restore ćwiczymy w kalendarzu. Tory stoją na osobnych kontach.
Tor A
Blisko, krótki RTO
Snapshot i kopia w tej samej lokalizacji. Odtwarzamy system i aplikację w znanym czasie.
Tor B
Daleko, osobna tożsamość
Drugi dostawca albo tenant. Inny klucz, inna sieć. Ten tor nie używa kont produkcji.
Zakres
Bazy, wolumeny, pliki, poczta tam gdzie jest usługą, konfiguracja IaC.
Retencja
Ustawiamy ją zgodnie z RODO i umową. Skrócenie retencji to alert.
Trzymamy szyfrowanie dysku, snapshot i klucz poza aplikacją
Na Proxmox i w chmurze wolumen ma szyfrowanie, politykę snapshot i listę kto może sklonować dysk. Szablon maszyny nie wozi sekretów. Dane testowe maskujemy albo zastępujemy syntetycznymi. Snapshot podlega tej samej klasie co zbiór.
Szyfrowanie
Spoczynek i ruch. KMS albo HSM, rotacja, rozdział ról kto używa i kto administruje kluczem.
Snapshot
Ustalamy, kto może zrobić klon i gdzie ląduje. Snapshot to kopia, podlega tej samej klasie.
Środowiska
Produkcja nie zasila stage pełnym zbiorem bez potrzeby i bez maskowania.
Kasowanie
Retencja i prawo do usunięcia mają procedurę na backupie, razem z aplikacją.
Pilnujemy, kto czyta zbiór i czy plik się zmienił
Wazuh stawiamy na ścieżkach z danymi: FIM, logi dostępu do bazy i object storage, alert na masowe pobranie. To zamyka serwer i aplikację. DLP w endpointach biurowych, jeśli jest w zakresie, dokładamy osobno.
FIM
Katalogi z danymi, konfiguracja i klucze. Zmiana poza oknem ma priorytet.
Dostęp
Log logowania, grant w bazie, AssumeRole. Nietypowa pora i nowy ASN idą do dyżuru.
Eksfiltracja
Objętość na egress i nietypowa destynacja. Korelacja z analizą ruchu tam, gdzie jest wdrożona.
Ślad
Retencja logów pod audyt i wniosek osoby. Kto widział alert, co zrobiono.
Utrzymujemy wykres kopii, klucza i retencji
Nieudane zadanie kopii, błąd KMS, zbliżający się certyfikat i wzrost egress schodzą do Grafany. Dashboard służy operacji. IOD widzi ten sam status kopii i dostępu, innym językiem opisu.
Backup
Sukces, czas, objętość, wiek ostatniego udanego restore.
Klucze
Użycie KMS, błąd decrypt, próba z nieznanego konta.
RODO
Retencja, kolejka usunięć i czas realizacji wniosku, spisane jako metryka procesu.
Ludzie
IOD i engineering patrzą na ten sam status kopii i dostępu.
Jak pracujemy
Od zbiorów klienta do rytmu restore
Zaczynamy od spisu zbiorów, klas i kluczy. Potem stawiamy szyfrowanie, dwa tory kopii i FIM. Sprawdzamy pierwszy udany restore. Zostajemy przy wnioskach RODO, retencji i raporcie dla IOD.
- Spis Sprawdzamy zbiory, klasy, miejsca, kto ma klucz i jaki RPO. Ustalamy, co zostaje w serwerowni. Z tego wychodzi zakres ochrony i kopii.
- Ochrona Stawiamy szyfrowanie, KMS i ograniczenie klonów. Dane na stage maskujemy albo zastępujemy syntetycznymi.
- Kopie Stawiamy dwa tory, immutability i osobne konta. Ćwiczymy pierwszy udany restore zanim wejdziemy na rytm.
- Rytm Wazuh pilnuje FIM i dostępu. Wnioski, retencja i raport dla IOD zostają w umowie.
Rozmowa
Omówimy zbiory, klucze i restore
Na tej podstawie przygotujemy zakres: klasyfikacja, KMS, dwa tory kopii i ślad.
Skontaktuj się