Categories
Database Backup

** Learn how to protect enterprise database archives from ransomware using immutable storage. Discover technical implementation steps for AWS S3 Object Lock, ZFS, PostgreSQL, and SQL Server.

W nowoczesnym krajobrazie zagrożeń oprogramowanie ransomware ewoluowało od oportunistycznego szyfrowania do wysoce ukierunkowanych kampanii wielokrotnego wymuszania okupu. Zaawansowane zagrożenia typu APT (Advanced Persistent Threats) oraz syndykaty ransomware aktywnie poszukują infrastruktury kopii zapasowych i archiwów baz danych podczas czasu przebywania w sieci (dwell time). Jeśli atakujący przejmie kontrolę nad Twoją główną bazą danych i jednocześnie usunie lub zaszyfruje repozytoria kopii zapasowych, Twoja organizacja stanie w obliczu katastrofalnej utraty danych.

Dla administratorów baz danych (DBA) i inżynierów DevOps tradycyjna strategia tworzenia kopii zapasowych 3-2-1 nie jest już wystarczająca. Aby zagwarantować przetrwanie danych, zespoły infrastrukturalne muszą przyjąć zasadę 3-2-1-1, gdzie ostatnia „1” oznacza niezmienny magazyn danych (immutable storage).

Niniejszy artykuł stanowi kompleksowe, techniczne omówienie projektowania, wdrażania i zarządzania niezmiennym magazynem danych dla archiwów baz danych, aby zapewnić absolutną odporność na oprogramowanie ransomware.

Mechanizmy niezmiennego magazynu danych

Niezmienny magazyn danych opiera się na architekturze WORM (Write-Once-Read-Many – zapisz raz, odczytaj wiele razy). Gdy dane zostaną zapisane w niezmiennym miejscu docelowym, nie mogą zostać zmodyfikowane, zaszyfrowane ani usunięte przez żadnego użytkownika – w tym administratorów z uprawnieniami root lub przejęte konta serwisowe – aż do wygaśnięcia matematycznie wymuszonej blokady czasowej.

Tryb zgodności (Compliance Mode) a tryb zarządzania (Governance Mode)

Podczas wdrażania niezmienności, szczególnie w chmurowych magazynach obiektowych, takich jak AWS S3, Azure Blob czy lokalne macierze SAN kompatybilne z S3, należy zrozumieć różnicę między trybami retencji:

  • Tryb zarządzania (Governance Mode): Zapobiega usuwaniu lub modyfikowaniu obiektów przez standardowych użytkowników. Jednak użytkownicy z określonymi uprawnieniami IAM (np. s3:BypassGovernanceRetention) mogą obejść blokadę. Jest to przydatne do testów, ale niewystarczające do ochrony przed ransomware, ponieważ atakujący często eskalują uprawnienia do poziomu administratora domeny lub roota.
  • Tryb zgodności (Compliance Mode): Złoty standard w obronie przed ransomware. Gdy obiekt zostanie zablokowany w trybie zgodności, okres jego retencji nie może zostać skrócony, a obiekt nie może zostać usunięty przez nikogo, w tym przez konto root AWS. Blokada jest wymuszana na poziomie klastra pamięci masowej.

Projektowanie niezmiennego potoku kopii zapasowych

Solidna architektura archiwizacji baz danych oddziela aktywne operacje bazodanowe od warstwy niezmiennego archiwum. Nie można zastosować niezmienności do aktywnych plików baz danych (takich jak .mdf/.ldf w SQL Server lub katalog pg_data w PostgreSQL), ponieważ bazy danych wymagają ciągłego dostępu do odczytu/zapisu.

Zamiast tego niezmienność stosuje się do:
1. Pełnych i różnicowych plików kopii zapasowych: Bazowych migawek bazy danych.
2. Dzienników transakcji / plików WAL: Ciągłego strumienia zmian w bazie danych wymaganego do odzyskiwania do punktu w czasie (PITR).

Cele przechowywania dla niezmienności

Niezmienny magazyn danych można wdrożyć w różnych warstwach infrastruktury:
* Chmurowy magazyn obiektowy: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Lokalny magazyn obiektowy: MinIO, Cloudian lub Pure Storage FlashBlade obsługujące interfejsy API S3 Object Lock.
* Magazyn blokowy/plikowy: ZFS z migawkami tylko do odczytu i delegowaną administracją lub atrybutami plików systemu Linux.

Wdrażanie niezmiennego magazynu danych: Przewodniki techniczne

1. Chmurowy magazyn obiektowy: AWS S3 Object Lock

Aby chronić zrzuty baz danych i dzienniki transakcji w AWS, należy włączyć funkcję Object Lock w momencie tworzenia zasobnika (bucket).

Najpierw utwórz zasobnik z włączoną funkcją Object Lock:

aws s3api create-bucket 
    --bucket prod-db-archive-immutable 
    --region us-east-1 
    --object-lock-enabled-for-bucket

Następnie skonfiguruj domyślną politykę retencji. Dla archiwów baz danych 30-dniowa blokada zgodności jest standardową bazą, zapewniającą miesiąc niezmiennych kopii zapasowych.

aws s3api put-object-lock-configuration 
    --bucket prod-db-archive-immutable 
    --object-lock-configuration '{
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "COMPLIANCE",
                "Days": 30
            }
        }
    }'

Gdy skrypt lub agent kopii zapasowej bazy danych przesyła plik do tego zasobnika, S3 automatycznie oblicza datę Retain Until Date na podstawie znacznika czasu utworzenia obiektu plus 30 dni.

2. Lokalna niezmienność: ZFS i atrybuty systemu Linux

Jeśli archiwizujesz bazy danych na lokalnym serwerze kopii zapasowych z systemem Linux, możesz osiągnąć pseudo-niezmienność za pomocą polecenia chattr lub prawdziwą niezmienność za pomocą migawek ZFS.

Użycie chattr w systemie Linux:
Flaga +i (immutable) zapobiega modyfikacji, usunięciu lub zmianie nazwy pliku.

# Zrzut bazy danych
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Uczynienie kopii zapasowej niezmienną
sudo chattr +i /backups/mydb_$(date +%F).dump

# Weryfikacja atrybutu
lsattr /backups/mydb_$(date +%F).dump
# Wynik: ----i---------e------- /backups/mydb_2023-10-27.dump

Uwaga: Chociaż chattr zatrzymuje podstawowe skrypty ransomware, wyrafinowany atakujący z dostępem roota może po prostu uruchomić chattr -i. Dlatego należy to łączyć ze ścisłą kontrolą RBAC i odizolowanymi sieciami kopii zapasowych.

Użycie migawek ZFS:
ZFS zapewnia znacznie silniejszą obronę. Poprzez wykonanie migawki i nałożenie na nią „blokady” (hold), uniemożliwiasz jej usunięcie.

# Wykonanie migawki zbioru danych kopii zapasowych
zfs snapshot tank/db_backups@archive_$(date +%F)

# Nałożenie blokady na migawkę, aby zapobiec usunięciu
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Nawet root nie może usunąć tej migawki bez zwolnienia blokady
zfs destroy tank/db_backups@archive_$(date +%F)
# Wynik: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Strategie archiwizacji specyficzne dla baz danych

Aby osiągnąć odzyskiwanie do punktu w czasie (PITR), musisz stale archiwizować dzienniki transakcji w swoim niezmiennym magazynie.

Archiwizacja WAL w PostgreSQL za pomocą pgBackRest

pgBackRest to wysoce niezawodne narzędzie do tworzenia kopii zapasowych dla PostgreSQL, które natywnie obsługuje magazyny kompatybilne z S3. Aby chronić swoje dzienniki zapisu (WAL), skonfiguruj pgBackRest tak, aby przesyłał je bezpośrednio do niezmiennego zasobnika S3.

W pliku pgbackrest.conf:

[global]
repo1-type=s3
repo1-s3-bucket=prod-db-archive-immutable
repo1-s3-region=us-east-1
repo1-s3-endpoint=s3.amazonaws.com
repo1-s3-key=AKIAIOSFODNN7EXAMPLE
repo1-s3-key-secret=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# Upewnij się, że retencja jest zgodna z konfiguracją S3 Object Lock
repo1-retention-full=2
repo1-retention-archive=2

[prod_cluster]
pg1-path=/var/lib/postgresql/14/main

Kluczowa uwaga: Jeśli Twój zasobnik S3 wymusza 30-dniową blokadę zgodności, a pgBackRest próbuje wygasić i usunąć pliki WAL po 14 dniach na podstawie repo1-retention-archive, wywołania API usuwania zakończą się niepowodzeniem. Musisz upewnić się, że polityka retencji Twojego oprogramowania do kopii zapasowych jest większa lub równa niezmiennej blokadzie na poziomie magazynu.

Microsoft SQL Server: Backup to URL

SQL Server obsługuje natywne kopie zapasowe bezpośrednio do magazynu obiektów kompatybilnego z S3. Możesz skonfigurować zadanie SQL Server Agent, aby zapisywało pliki .bak i .trn bezpośrednio do niezmiennego zasobnika.

CREATE CREDENTIAL [s3://prod-db-archive-immutable.s3.us-east-1.amazonaws.com]
WITH IDENTITY = 'S3 Access Key',
SECRET = 'AccessKeyID:SecretAccessKey';
GO

BACKUP DATABASE [ProductionDB]
TO URL = 's3://prod-db-archive-immutable.s3.us-east-1.amazonaws.com/ProductionDB_Full.bak'
WITH FORMAT, COMPRESSION, STATS = 10;
GO

Automatyzacja i orkiestracja za pomocą CloudSave

Zarządzanie flagami niezmiennej retencji, rotacja kluczy dostępu i zapewnienie synchronizacji między politykami retencji baz danych a blokadami magazynu za pomocą niestandardowych skryptów jest wysoce podatne na błędy. Pojedyncza błędna konfiguracja w zadaniu cron lub wywołaniu API może pozostawić Twoje archiwa narażone na ataki lub doprowadzić do gwałtownego wzrostu kosztów przechowywania w chmurze z powodu osieroconych, zablokowanych obiektów.

Platformy do tworzenia kopii zapasowych klasy korporacyjnej, takie jak CloudSave, upraszczają tę architekturę. CloudSave natywnie integruje się z AWS S3 Object Lock, Azure Blob Immutable Storage i lokalnymi interfejsami API kompatybilnymi z S3.

Podczas konfigurowania planu kopii zapasowej bazy danych w CloudSave:
1. Platforma automatycznie obsługuje wyciszenie VSS (Volume Shadow Copy Service) dla SQL Server lub API pg_start_backup() dla PostgreSQL.
2. Przesyła zdeduplikowane, zaszyfrowane dane kopii zapasowej bezpośrednio do miejsca docelowego.
3. CloudSave dynamicznie stosuje wywołania WORM API (np. PutObjectRetention) dla każdego obiektu, idealnie dopasowując czas trwania blokady magazynu do harmonogramu retencji zdefiniowanego w polityce.
4. Jeśli atakujący przejmie konsolę zarządzania CloudSave, nadal nie będzie mógł usunąć kopii zapasowych, ponieważ blokada zgodności jest wymuszana przez podstawową infrastrukturę pamięci masowej, a nie przez oprogramowanie do kopii zapasowych.

Najlepsze praktyki dla niezmiennych archiwów baz danych

Aby zapewnić, że Twoja niezmienna architektura jest naprawdę odporna, przestrzegaj następujących najlepszych praktyk inżynierii systemowej:

1. Ścisła synchronizacja NTP

Niezmienne blokady są matematycznie powiązane ze znacznikami czasu. Jeśli usługa NTP (Network Time Protocol) na Twojej macierzy pamięci masowej lub serwerze kopii zapasowych zostanie przejęta lub ulegnie rozsynchronizowaniu, może to spowodować przedwczesne wygaśnięcie blokad lub ich brak. Upewnij się, że Twoja infrastruktura pamięci masowej korzysta z uwierzytelnionych, redundantnych źródeł NTP.

2. Izolacja ról i poświadczeń IAM

Poświadczenia używane do zapisu w niezmiennym zasobniku muszą mieć tylko uprawnienia s3:PutObject i s3:PutObjectRetention. Nigdy nie powinny mieć uprawnień s3:DeleteObject ani s3:PutBucketObjectLockConfiguration.

Przykład polityki IAM z najmniejszymi uprawnieniami dla agenta kopii zapasowej bazy danych:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetBucketObjectLockConfiguration"
            ],
            "Resource": [
                "arn:aws:s3:::prod-db-archive-immutable",
                "arn:aws:s3:::prod-db-archive-immutable/*"
            ]
        }
    ]
}

3. Dobór okresu retencji

Nie ustawiaj blokad zgodności na zbyt długie okresy (np. 7 lat dla zgodności) w swojej głównej warstwie szybkiego odzyskiwania. Bazy danych generują ogromne ilości danych dzienników WAL/transakcyjnych. Blokowanie tych danych na lata spowoduje wykładniczy wzrost kosztów przechowywania.
Zamiast tego zastosuj podejście warstwowe:
* Warstwa odzyskiwania operacyjnego: 14 do 30 dni niezmiennej retencji dla pełnych kopii i dzienników.
* Warstwa archiwizacji długoterminowej: Miesięczne pełne kopie zapasowe przenoszone do Glacier/Deep Archive z blokadą Vault Lock na 1-7 lat.

4. Regularne testy odzyskiwania w odizolowanych sieciach (Air-Gapped VPC)

Niezmienność gwarantuje, że danych nie można usunąć, ale nie gwarantuje, że są one wolne od logicznej korupcji. Musisz zautomatyzować przywracanie swoich niezmiennych archiwów baz danych do odizolowanego, odciętego od sieci VPC lub VLAN. Uruchom DBCC CHECKDB (SQL Server) lub pg_amcheck (PostgreSQL) na przywróconych danych, aby zweryfikować ich integralność strukturalną.

Wniosek

Obrona przed ransomware to ćwiczenie z zakładania, że doszło do naruszenia. Zanim w Twoim systemie SIEM pojawi się alert, cyberprzestępcy prawdopodobnie już próbowali przejąć Twoją infrastrukturę kopii zapasowych. Projektując archiwa baz danych przy użyciu niezmiennego magazynu w trybie zgodności (Compliance Mode), odbierasz atakującym ich główny atut. Niezależnie od tego, czy korzystasz z natywnych interfejsów API chmury, blokad ZFS, czy platformy orkiestracji klasy korporacyjnej, takiej jak CloudSave, wdrożenie magazynu WORM nie jest już opcjonalne – jest obowiązkowym filarem nowoczesnej administracji bazami danych i odzyskiwania po awarii.

Kategorie