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.

Nykypäivän uhkaympäristössä kiristyshaittaohjelmat ovat kehittyneet opportunistisesta salauksesta erittäin kohdistetuiksi, moninkertaisen kiristyksen kampanjoiksi. Kehittyneet jatkuvat uhat (APT) ja kiristyshaittaohjelmaryhmät etsivät nykyään aktiivisesti varmuuskopioinfrastruktuuria ja tietokanta-arkistoja sisäänpääsynsä aikana. Jos hyökkääjä vaarantaa ensisijaisen tietokantasi ja samalla poistaa tai salaa varmuuskopioarkistosi, organisaatiosi kohtaa katastrofaalisen tietojen menetyksen.

Tietokannan ylläpitäjille (DBA) ja DevOps-insinööreille perinteinen 3-2-1-varmuuskopiostrategia ei ole enää riittävä. Tietojen säilyvyyden takaamiseksi infrastruktuuritiimien on otettava käyttöön 3-2-1-1-sääntö, jossa viimeinen ”1” edustaa muuttumatonta tallennustilaa (immutable storage).

Tämä artikkeli tarjoaa kattavan, teknisen syväsukelluksen tietokanta-arkistojen muuttumattoman tallennustilan suunnitteluun, toteutukseen ja hallintaan, jotta varmistetaan ehdoton sietokyky kiristyshaittaohjelmia vastaan.

Muuttumattoman tallennustilan mekaniikka

Muuttumaton tallennustila perustuu WORM-arkkitehtuuriin (Write-Once-Read-Many). Kun tiedot on kirjoitettu muuttumattomaan kohteeseen, kukaan – mukaan lukien pääkäyttäjän oikeudet omaavat ylläpitäjät tai vaarantuneet palvelutilit – ei voi muokata, salata tai poistaa niitä ennen kuin matemaattisesti valvottu aikalukko umpeutuu.

Vaatimustenmukaisuustila vs. hallintotila

Kun toteutat muuttumattomuutta, erityisesti pilvipohjaisessa objektitallennustilassa, kuten AWS S3, Azure Blob tai S3-yhteensopivat paikalliset SAN-ratkaisut, sinun on ymmärrettävä säilytystilojen välinen ero:

  • Hallintotila (Governance Mode): Estää tavallisia käyttäjiä poistamasta tai muuttamasta objekteja. Käyttäjät, joilla on tietyt IAM-oikeudet (esim. s3:BypassGovernanceRetention), voivat kuitenkin ohittaa lukituksen. Tämä on hyödyllistä testaamiseen, mutta riittämätöntä kiristyshaittaohjelmien torjuntaan, sillä hyökkääjät nostavat usein käyttöoikeuksiaan verkon ylläpitäjiksi tai pääkäyttäjiksi.
  • Vaatimustenmukaisuustila (Compliance Mode): Kiristyshaittaohjelmien torjunnan kultainen standardi. Kun objekti on lukittu vaatimustenmukaisuustilassa, sen säilytysaikaa ei voi lyhentää, eikä kukaan voi poistaa objektia, ei edes AWS-pääkäyttäjä. Lukitus on pakotettu tallennusklusterin tasolla.

Muuttumattoman varmuuskopiointiputken suunnittelu

Vankka tietokantojen arkistointiarkkitehtuuri erottaa aktiiviset tietokantatoiminnot muuttumattomasta arkistotasosta. Muuttumattomuutta ei voi soveltaa aktiivisiin tietokantatiedostoihin (kuten SQL Serverin .mdf/.ldf-tiedostot tai PostgreSQL:n pg_data-hakemisto), koska tietokannat vaativat jatkuvaa luku- ja kirjoitusoikeutta.

Sen sijaan muuttumattomuutta sovelletaan seuraaviin:
1. Täydet ja differentiaaliset varmuuskopiotiedostot: Tietokannan perusotokset.
2. Transaktiolokit / WAL-tiedostot: Jatkuva tietokantamuutosten virta, joka tarvitaan ajankohtaan perustuvaan palautukseen (PITR).

Muuttumattomuuden tallennuskohteet

Voit toteuttaa muuttumattoman tallennustilan eri infrastruktuuritasoilla:
* Pilvipohjainen objektitallennus: AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
* Paikallinen objektitallennus: MinIO, Cloudian tai Pure Storage FlashBlade, jotka tukevat S3 Object Lock -rajapintoja.
* Lohko-/tiedostotallennus: ZFS, jossa on vain luku -tilannevedokset ja delegoitu hallinta, tai Linux-tiedostomääritteet.

Muuttumattoman tallennustilan toteutus: Tekniset läpikäynnit

1. Pilvipohjainen objektitallennus: AWS S3 Object Lock

Suojataksesi tietokantavedokset ja transaktiolokit AWS:ssä, sinun on otettava Object Lock käyttöön säiliön (bucket) luontihetkellä.

Luo ensin säiliö, jossa Object Lock on käytössä:

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

Määritä seuraavaksi oletussäilytyskäytäntö. Tietokanta-arkistoille 30 päivän vaatimustenmukaisuuslukitus on vakiotaso, joka varmistaa, että käytettävissäsi on kuukauden verran muuttamattomia varmuuskopioita.

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

Kun tietokannan varmuuskopiointiskripti tai agentti siirtää tiedoston tähän säiliöön, S3 laskee automaattisesti Retain Until Date -päivämäärän objektin luontiajan ja 30 päivän perusteella.

2. Paikallinen muuttumattomuus: ZFS ja Linux-määritteet

Jos arkistoit tietokantoja paikalliselle Linux-varmuuskopiopalvelimelle, voit saavuttaa näennäisen muuttumattomuuden chattr-komennolla tai todellisen muuttumattomuuden ZFS-tilannevedoksilla.

Linux chattr -komennon käyttö:
+i (immutable) -lippu estää tiedoston muokkaamisen, poistamisen tai nimeämisen uudelleen.

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

# Tee varmuuskopiosta muuttumaton
sudo chattr +i /backups/mydb_$(date +%F).dump

# Vahvista määrite
lsattr /backups/mydb_$(date +%F).dump
# Tuloste: ----i---------e------- /backups/mydb_2023-10-27.dump

Huomautus: Vaikka chattr pysäyttää perusluontoiset kiristyshaittaohjelmat, kokenut hyökkääjä, jolla on pääkäyttäjän oikeudet, voi yksinkertaisesti ajaa chattr -i. Siksi tämä on yhdistettävä tiukkaan roolipohjaiseen pääsynhallintaan (RBAC) ja eristettyihin varmuuskopioverkkoihin.

ZFS-tilannevedosten käyttö:
ZFS tarjoaa huomattavasti vahvemman suojan. Ottamalla tilannevedoksen ja asettamalla sille ”pidon” (hold), estät tilannevedoksen tuhoamisen.

# Ota tilannevedos varmuuskopiojoukosta
zfs snapshot tank/db_backups@archive_$(date +%F)

# Aseta pito tilannevedokselle poistamisen estämiseksi
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Edes pääkäyttäjä ei voi tuhota tätä tilannevedosta vapauttamatta pitoa
zfs destroy tank/db_backups@archive_$(date +%F)
# Tuloste: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Tietokantakohtaiset arkistointistrategiat

Ajankohtaan perustuvan palautuksen (PITR) saavuttamiseksi transaktiolokit on arkistoitava jatkuvasti muuttumattomaan tallennustilaan.

PostgreSQL WAL-arkistointi pgBackRestillä

pgBackRest on erittäin luotettava varmuuskopiointityökalu PostgreSQL:lle, joka tukee natiivisti S3-yhteensopivaa tallennustilaa. Suojataksesi Write-Ahead-lokisi (WAL), määritä pgBackRest siirtämään tiedot suoraan muuttumattomaan S3-säiliöön.

Tiedostossa 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

# Varmista, että säilytys vastaa S3 Object Lock -määrityksiä
repo1-retention-full=2
repo1-retention-archive=2

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

Tärkeä huomio: Jos S3-säiliösi pakottaa 30 päivän vaatimustenmukaisuuslukituksen, mutta pgBackRest yrittää vanhentaa ja poistaa WAL-tiedostoja 14 päivän kuluttua repo1-retention-archive-asetuksen perusteella, poiston API-kutsut epäonnistuvat. Varmista, että varmuuskopiointiohjelmistosi säilytyskäytäntö on vähintään yhtä pitkä kuin tallennustason muuttumaton lukitus.

Microsoft SQL Server: Varmuuskopiointi URL-osoitteeseen

SQL Server tukee natiiveja varmuuskopioita suoraan S3-yhteensopivaan objektitallennustilaan. Voit määrittää SQL Server Agent -työn kirjoittamaan .bak– ja .trn-tiedostot suoraan muuttumattomaan säiliöön.

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

Automatisointi ja orkestrointi CloudSavella

Muuttumattomien säilytyslippujen hallinta, pääsyavainten kierrättäminen ja tietokannan säilytyskäytäntöjen sekä tallennuslukkojen synkronointi mukautetuilla skripteillä on erittäin virhealtista. Yksikin virheellinen määritys cron-työssä tai API-kutsussa voi jättää arkistosi alttiiksi tai johtaa pilvitallennuskustannusten räjähdysmäiseen kasvuun orpojen, lukittujen objektien vuoksi.

Yritystason varmuuskopiointialustat, kuten CloudSave, yksinkertaistavat tätä arkkitehtuuria. CloudSave integroituu natiivisti AWS S3 Object Lockiin, Azure Blob Immutable Storageen ja paikallisiin S3-yhteensopiviin rajapintoihin.

Kun määrität tietokannan varmuuskopiointisuunnitelmaa CloudSavessa:
1. Alusta hoitaa automaattisesti VSS-valmiustilan (Volume Shadow Copy Service) SQL Serverille tai pg_start_backup()-rajapinnan PostgreSQL:lle.
2. Se suoratoistaa duplikoimattoman, salatun varmuuskopiodatan suoraan tallennuskohteeseen.
3. CloudSave soveltaa dynaamisesti WORM API -kutsuja (esim. PutObjectRetention) objektikohtaisesti, kohdistaen tallennuslukituksen keston täydellisesti käytännön määrittelemään säilytysaikatauluun.
4. Jos hyökkääjä vaarantaa CloudSave-hallintakonsolin, hän ei silti voi poistaa varmuuskopioita, koska vaatimustenmukaisuuslukitus on taustalla olevan tallennusinfrastruktuurin, ei varmuuskopiointiohjelmiston, pakottama.

Parhaat käytännöt muuttumattomille tietokanta-arkistoille

Varmistaaksesi, että muuttumaton arkkitehtuurisi on todella kestävä, noudata seuraavia järjestelmäsuunnittelun parhaita käytäntöjä:

1. Tiukka NTP-synkronointi

Muuttumattomat lukitukset on sidottu matemaattisesti aikaleimoihin. Jos tallennusjärjestelmäsi tai varmuuskopiopalvelimesi NTP-palvelu (Network Time Protocol) vaarantuu tai ajautuu epätahtiin, lukitukset voivat vanhentua ennenaikaisesti tai eivät koskaan vanhentua. Varmista, että tallennusinfrastruktuurisi käyttää todennettuja, redundantteja NTP-lähteitä.

2. IAM-roolien ja tunnistetietojen eristäminen

Muuttumattomaan säiliöön kirjoittamiseen käytetyillä tunnistetiedoilla saa olla vain s3:PutObject– ja s3:PutObjectRetention-oikeudet. Niillä ei saa koskaan olla s3:DeleteObject– tai s3:PutBucketObjectLockConfiguration-oikeuksia.

Esimerkki vähimpien oikeuksien IAM-käytännöstä tietokannan varmuuskopiointiagentille:

{
    "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. Säilytysajan mitoitus

Älä aseta vaatimustenmukaisuuslukituksia liian pitkiksi ajoiksi (esim. 7 vuotta vaatimustenmukaisuuden vuoksi) ensisijaisella nopean palautuksen tasolla. Tietokannat tuottavat valtavia määriä WAL-/transaktiolokidataa. Tämän tiedon lukitseminen vuosiksi johtaa tallennuskustannusten eksponentiaaliseen kasvuun.
Käytä sen sijaan porrastettua lähestymistapaa:
* Operatiivinen palautustaso: 14–30 päivän muuttumaton säilytys täysille varmuuskopioille ja lokeille.
* Pitkäaikainen arkistointitaso: Kuukausittaiset täydet varmuuskopiot siirretään Glacier/Deep Archive -tilaan Vault Lockilla 1–7 vuodeksi.

4. Säännöllinen palautustestaus eristetyissä VPC-verkoissa

Muuttumattomuus takaa, ettei tietoja voi poistaa, mutta se ei takaa, etteikö tiedoissa olisi loogista korruptiota. Sinun on automatisoitava muuttumattomien tietokanta-arkistojen palauttaminen eristettyyn, ilmarakoon (air-gapped) VPC- tai VLAN-verkkoon. Suorita DBCC CHECKDB (SQL Server) tai pg_amcheck (PostgreSQL) palautetulle datalle rakenteellisen eheyden tarkistamiseksi.

Johtopäätös

Kiristyshaittaohjelmien torjunta on harjoitus, jossa oletetaan tietomurto tapahtuneen. Siihen mennessä, kun SIEM-järjestelmäsi antaa hälytyksen, uhkatoimijat ovat todennäköisesti jo yrittäneet vaarantaa varmuuskopioinfrastruktuurisi. Suunnittelemalla tietokanta-arkistosi käyttämällä muuttumatonta tallennustilaa vaatimustenmukaisuustilassa, riistät hyökkääjiltä heidän ensisijaisen vipuvartensa. Käytitpä sitten natiiveja pilvirajapintoja, ZFS-pitoja tai yritystason orkestrointialustaa kuten CloudSavea, WORM-tallennustilan toteuttaminen ei ole enää valinnaista – se on modernin tietokannan hallinnan ja katastrofipalautuksen pakollinen pilari.

Kategoriat