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.

Në peizazhin modern të kërcënimeve, ransomware ka evoluar nga enkriptimi oportunist në fushata shumë të shënjestruara të zhvatjes së shumëfishtë. Kërcënimet e Avancuara të Vazhdueshme (APT) dhe sindikatat e ransomware tani kërkojnë në mënyrë aktive infrastrukturën e kopjeve rezervë (backup) dhe arkivat e bazave të të dhënave gjatë kohës së tyre të qëndrimit në sistem. Nëse një sulmues komprometon bazën tuaj kryesore të të dhënave dhe njëkohësisht fshin ose enkripton depot tuaja të backup-it, organizata juaj përballet me humbje katastrofike të të dhënave.

Për Administratorët e Bazave të të Dhënave (DBA) dhe inxhinierët DevOps, strategjia tradicionale e backup-it 3-2-1 nuk është më e mjaftueshme. Për të garantuar mbijetesën e të dhënave, ekipet e infrastrukturës duhet të adoptojnë rregullin 3-2-1-1, ku “1”-shi i fundit përfaqëson ruajtjen e pandryshueshme (immutable storage).

Ky artikull ofron një vështrim të thellë, teknik dhe gjithëpërfshirës mbi arkitekturën, zbatimin dhe menaxhimin e ruajtjes së pandryshueshme për arkivat e bazave të të dhënave, për të siguruar rezistencë absolute ndaj ransomware.

Mekanizmat e Ruajtjes së Pandryshueshme

Ruajtja e pandryshueshme mbështetet në një arkitekturë “Shkruaj Njëherë, Lexo Shumë” (WORM). Pasi të dhënat shkruhen në një destinacion të pandryshueshëm, ato nuk mund të modifikohen, enkriptohen ose fshihen nga asnjë përdorues—përfshirë administratorët me privilegje root ose llogaritë e shërbimit të komprometuara—derisa të skadojë një bllokim kohor i zbatuar matematikisht.

Mënyra e Pajtueshmërisë (Compliance Mode) kundrejt Mënyrës së Qeverisjes (Governance Mode)

Kur zbatoni pandryshueshmërinë, veçanërisht në ruajtjen e objekteve në cloud si AWS S3, Azure Blob, ose SAN-et on-premises të pajtueshme me S3, duhet të kuptoni dallimin midis mënyrave të mbajtjes (retention modes):

  • Mënyra e Qeverisjes (Governance Mode): Parandalon përdoruesit standardë nga fshirja ose ndryshimi i objekteve. Megjithatë, përdoruesit me leje specifike IAM (p.sh., s3:BypassGovernanceRetention) mund ta anashkalojnë bllokimin. Kjo është e dobishme për testim, por e pamjaftueshme për mbrojtjen nga ransomware, pasi sulmuesit shpesh përshkallëzojnë privilegjet në administrator domeni ose root.
  • Mënyra e Pajtueshmërisë (Compliance Mode): Standardi i artë për mbrojtjen nga ransomware. Pasi një objekt bllokohet në Mënyrën e Pajtueshmërisë, periudha e mbajtjes së tij nuk mund të shkurtohet dhe objekti nuk mund të fshihet nga askush, përfshirë llogarinë root të AWS. Bllokimi zbatohet në nivelin e grupit të ruajtjes (storage cluster).

Arkitektimi i një Tubacioni të Pandryshueshëm të Backup-it

Një arkitekturë e fuqishme e arkivimit të bazave të të dhënave ndan operacionet aktive të bazës së të dhënave nga shtresa e arkivit të pandryshueshëm. Ju nuk mund të aplikoni pandryshueshmërinë në skedarët aktivë të bazës së të dhënave (si .mdf/.ldf në SQL Server ose direktorinë pg_data në PostgreSQL) sepse bazat e të dhënave kërkojnë akses të vazhdueshëm për lexim/shkrim.

Në vend të kësaj, pandryshueshmëria aplikohet në:
1. Skedarët e Backup-it të Plotë dhe Diferencial: Snapshot-et bazë të bazës së të dhënave.
2. Regjistrat e Transaksioneve / Skedarët WAL: Rrjedha e vazhdueshme e ndryshimeve të bazës së të dhënave që kërkohet për Rikuperimin në një Pikë në Kohë (PITR).

Destinacionet e Ruajtjes për Pandryshueshmëri

Ju mund të zbatoni ruajtjen e pandryshueshme nëpër shtresa të ndryshme të infrastrukturës:
* Cloud Object Storage: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* On-Premises Object Storage: MinIO, Cloudian, ose Pure Storage FlashBlade që mbështesin API-të S3 Object Lock.
* Block/File Storage: ZFS me snapshot-e “read-only” dhe administrim të deleguar, ose atribute të skedarëve në Linux.

Zbatimi i Ruajtjes së Pandryshueshme: Udhëzues Teknik

1. Cloud Object Storage: AWS S3 Object Lock

Për të mbrojtur dump-et e bazës së të dhënave dhe regjistrat e transaksioneve në AWS, duhet të aktivizoni Object Lock në momentin e krijimit të bucket-it.

Së pari, krijoni bucket-in me Object Lock të aktivizuar:

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

Më pas, konfiguroni politikën e paracaktuar të mbajtjes. Për arkivat e bazave të të dhënave, një bllokim pajtueshmërie 30-ditor është një bazë standarde, duke siguruar që keni një muaj backup-e të pandryshueshme.

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

Kur skripti ose agjenti juaj i backup-it të bazës së të dhënave dërgon një skedar në këtë bucket, S3 llogarit automatikisht Retain Until Date bazuar në vulën kohore të krijimit të objektit plus 30 ditë.

2. Pandryshueshmëria On-Premises: ZFS dhe Atributet Linux

Nëse jeni duke arkivuar baza të dhënash në një server backup-i Linux on-premises, mund të arrini pseudo-pandryshueshmëri duke përdorur komandën chattr, ose pandryshueshmëri të vërtetë duke përdorur snapshot-et ZFS.

Duke përdorur chattr në Linux:
Flamuri +i (immutable) parandalon modifikimin, fshirjen ose riemërtimin e skedarit.

# Dump i bazës së të dhënave
pg_dump -U postgres -Fc mydb > /backups/mydb_$(date +%F).dump

# Bëni backup-in të pandryshueshëm
sudo chattr +i /backups/mydb_$(date +%F).dump

# Verifikoni atributin
lsattr /backups/mydb_$(date +%F).dump
# Output: ----i---------e------- /backups/mydb_2023-10-27.dump

Shënim: Ndërsa chattr ndalon skriptet bazë të ransomware, një sulmues i sofistikuar me akses root mund thjesht të ekzekutojë chattr -i. Prandaj, kjo duhet të kombinohet me RBAC strikt dhe rrjete të izoluara backup-i.

Duke përdorur Snapshot-et ZFS:
ZFS ofron një mbrojtje shumë më të fortë. Duke marrë një snapshot dhe duke vendosur një “hold” mbi të, ju parandaloni shkatërrimin e snapshot-it.

# Merrni një snapshot të dataset-it të backup-it
zfs snapshot tank/db_backups@archive_$(date +%F)

# Vendosni një hold mbi snapshot për të parandaluar fshirjen
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# As root nuk mund ta shkatërrojë këtë snapshot pa hequr hold-in
zfs destroy tank/db_backups@archive_$(date +%F)
# Output: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Strategjitë e Arkivimit Specifike për Bazat e të Dhënave

Për të arritur Rikuperimin në një Pikë në Kohë (PITR), duhet të arkivoni vazhdimisht regjistrat e transaksioneve në ruajtjen tuaj të pandryshueshme.

Arkivimi WAL i PostgreSQL me pgBackRest

pgBackRest është një mjet backup-i shumë i besueshëm për PostgreSQL që mbështet në mënyrë native ruajtjen e pajtueshme me S3. Për të mbrojtur Regjistrat Write-Ahead (WAL), konfiguroni pgBackRest që të dërgojë të dhënat direkt në bucket-in tuaj të pandryshueshëm S3.

Në pgbackrest.conf tuaj:

[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

# Sigurohuni që mbajtja të përputhet me konfigurimin tuaj të S3 Object Lock
repo1-retention-full=2
repo1-retention-archive=2

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

Konsideratë thelbësore: Nëse bucket-i juaj S3 zbaton një bllokim Pajtueshmërie 30-ditor, por pgBackRest përpiqet të skadojë dhe fshijë skedarët WAL pas 14 ditësh bazuar në repo1-retention-archive, thirrjet API të fshirjes do të dështojnë. Duhet të siguroheni që politika e mbajtjes së softuerit tuaj të backup-it të jetë më e madhe ose e barabartë me bllokimin e pandryshueshëm në nivelin e ruajtjes.

Microsoft SQL Server: Backup në URL

SQL Server mbështet backup-et native direkt në ruajtjen e objekteve të pajtueshme me S3. Mund të konfiguroni një detyrë të SQL Server Agent për të shkruar skedarët .bak dhe .trn direkt në një bucket të pandryshueshëm.

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

Automatizimi dhe Orkestrimi me CloudSave

Menaxhimi i flamujve të mbajtjes së pandryshueshme, rrotullimi i çelësave të aksesit dhe sigurimi i sinkronizimit midis politikave të mbajtjes së bazës së të dhënave dhe bllokimeve të ruajtjes përmes skripteve të personalizuara është shumë i prirur ndaj gabimeve. Një konfigurim i gabuar në një cron job ose thirrje API mund t’i lërë arkivat tuaja të ekspozuara ose të rezultojë në kosto marramendëse të ruajtjes në cloud për shkak të objekteve të mbetura dhe të bllokuara.

Platformat e backup-it të nivelit të ndërmarrjes si CloudSave thjeshtojnë këtë arkitekturë. CloudSave integrohet në mënyrë native me AWS S3 Object Lock, Azure Blob Immutable Storage dhe API-të on-premises të pajtueshme me S3.

Kur konfiguroni një plan backup-i për bazën e të dhënave në CloudSave:
1. Platforma trajton automatikisht qetësimin e VSS (Volume Shadow Copy Service) për SQL Server ose API-në pg_start_backup() për PostgreSQL.
2. Ajo transmeton të dhënat e backup-it të deduplikuara dhe të enkriptuara direkt në destinacionin e ruajtjes.
3. CloudSave aplikon në mënyrë dinamike thirrjet WORM API (p.sh., PutObjectRetention) për çdo objekt, duke përputhur në mënyrë perfekte kohëzgjatjen e bllokimit të ruajtjes me orarin e mbajtjes të përcaktuar nga politika.
4. Nëse një sulmues komprometon konsolën e menaxhimit të CloudSave, ata prapëseprapë nuk mund t’i fshijnë backup-et, pasi bllokimi i pajtueshmërisë zbatohet nga infrastruktura e ruajtjes nën-shtresë, jo nga softueri i backup-it.

Praktikat më të Mira për Arkivat e Pandryshueshme të Bazave të të Dhënave

Për të siguruar që arkitektura juaj e pandryshueshme është vërtet rezistente, ndiqni këto praktika më të mira të inxhinierisë së sistemeve:

1. Sinkronizimi Strikt i NTP

Bllokimet e pandryshueshme janë të lidhura matematikisht me vulat kohore. Nëse shërbimi NTP (Network Time Protocol) në grupin tuaj të ruajtjes ose serverin e backup-it komprometohet ose devijon, kjo mund të shkaktojë skadimin e parakohshëm të bllokimeve ose mosskadimin e tyre kurrë. Sigurohuni që infrastruktura juaj e ruajtjes përdor burime NTP të autentikuara dhe redundante.

2. Izolimi i Roleve dhe Kredencialeve IAM

Kredencialet e përdorura për të shkruar në bucket-in e pandryshueshëm duhet të kenë vetëm leje s3:PutObject dhe s3:PutObjectRetention. Ato kurrë nuk duhet të kenë leje s3:DeleteObject ose s3:PutBucketObjectLockConfiguration.

Shembull i një politike IAM me privilegje minimale për një agjent backup-i të bazës së të dhënave:

{
    "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. Përcaktimi i Madhësisë së Periudhës së Mbajtjes

Mos vendosni bllokime pajtueshmërie për periudha tepër të gjata (p.sh., 7 vjet për pajtueshmëri) në shtresën tuaj kryesore të rikuperimit të shpejtë. Bazat e të dhënave gjenerojnë sasi masive të të dhënave WAL/regjistrave të transaksioneve. Bllokimi i këtyre të dhënave për vite me radhë do të rezultojë në rritje eksponenciale të kostos së ruajtjes.
Në vend të kësaj, përdorni një qasje me shtresa:
* Shtresa e Rikuperimit Operacional: 14 deri në 30 ditë mbajtje të pandryshueshme për Backup-et e Plota dhe Regjistrat.
* Shtresa e Arkivimit Afatgjatë: Backup-et e plota mujore të zhvendosura në Glacier/Deep Archive me Vault Lock për 1-7 vjet.

4. Testimi i Rregullt i Rikuperimit në VPC të Izoluara (Air-Gapped)

Pandryshueshmëria garanton që të dhënat nuk mund të fshihen, por nuk garanton që të dhënat janë pa korrupsion logjik. Ju duhet të automatizoni restaurimin e arkivave tuaja të pandryshueshme të bazës së të dhënave në një VPC ose VLAN të izoluar (air-gapped). Ekzekutoni DBCC CHECKDB (SQL Server) ose pg_amcheck (PostgreSQL) në të dhënat e restauruara për të verifikuar integritetin strukturor.

Përfundim

Mbrojtja nga ransomware është një ushtrim i supozimit të shkeljes. Deri në momentin që një alarm aktivizohet në SIEM-in tuaj, aktorët e kërcënimit ka shumë të ngjarë të kenë tentuar tashmë të komprometojnë infrastrukturën tuaj të backup-it. Duke arkitektuar arkivat e bazës suaj të të dhënave duke përdorur ruajtjen e pandryshueshme në Mënyrën e Pajtueshmërisë, ju u hiqni sulmuesve levën e tyre kryesore. Pavarësisht nëse përdorni API-të native të cloud, ZFS holds, ose një platformë orkestrimi të ndërmarrjes si CloudSave, zbatimi i ruajtjes WORM nuk është më opsional—ai është një shtyllë e detyrueshme e administrimit modern të bazave të të dhënave dhe rikuperimit nga fatkeqësitë.

Kategori