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.

Katika mazingira ya kisasa ya vitisho, programu za ukombozi (ransomware) zimebadilika kutoka usimbaji fiche wa fursa hadi kampeni za kulenga sana na za unyang’anyi wa aina nyingi. Vitisho vya Hali ya Juu vinavyoendelea (APTs) na vikundi vya ransomware sasa vinatafuta kikamilifu miundombinu ya kuhifadhi nakala (backup) na kumbukumbu za hifadhidata wakati wa muda wao wa kukaa kwenye mfumo. Ikiwa mshambuliaji ataharibu hifadhidata yako kuu na wakati huo huo kufuta au kusimba nakala zako za akiba, shirika lako litakabiliwa na upotevu mkubwa wa data.

Kwa Wasimamizi wa Hifadhidata (DBAs) na wahandisi wa DevOps, mkakati wa kitamaduni wa 3-2-1 wa kuhifadhi nakala hautoshi tena. Ili kuhakikisha uwezo wa data kuendelea kuwepo, timu za miundombinu lazima zikubali kanuni ya 3-2-1-1, ambapo “1” ya mwisho inawakilisha hifadhi isiyoweza kubadilishwa (immutable storage).

Makala haya yanatoa uchambuzi wa kina wa kiufundi kuhusu usanifu, utekelezaji, na usimamizi wa hifadhi isiyoweza kubadilishwa kwa kumbukumbu za hifadhidata ili kuhakikisha ustahimilivu kamili dhidi ya ransomware.

Mbinu za Hifadhi Isiyoweza Kubadilishwa

Hifadhi isiyoweza kubadilishwa inategemea usanifu wa Andika-Mara-Moja-Soma-Mara-Nyingi (WORM). Data ikishaandikwa kwenye lengo lisiloweza kubadilishwa, haiwezi kurekebishwa, kusimbwa, au kufutwa na mtumiaji yeyote—pamoja na wasimamizi wenye haki za mizizi (root privileges) au akaunti za huduma zilizoharibiwa—hadi muda uliowekwa kisheria utakapokwisha.

Hali ya Uzingatiaji (Compliance Mode) dhidi ya Hali ya Utawala (Governance Mode)

Unapotekeleza kutobadilika, hasa katika hifadhi ya vitu vya wingu (cloud object storage) kama AWS S3, Azure Blob, au SANs zinazooana na S3, lazima uelewe tofauti kati ya hali za uhifadhi:

  • Hali ya Utawala (Governance Mode): Inazuia watumiaji wa kawaida kufuta au kubadilisha vitu. Hata hivyo, watumiaji walio na ruhusa maalum za IAM (k.m., s3:BypassGovernanceRetention) wanaweza kupuuza kufuli. Hii ni muhimu kwa majaribio lakini haitoshi kwa ulinzi dhidi ya ransomware, kwani washambuliaji mara nyingi hupandisha marupurupu hadi kuwa msimamizi wa kikoa au mzizi.
  • Hali ya Uzingatiaji (Compliance Mode): Kiwango cha dhahabu kwa ulinzi wa ransomware. Kitu kikishafungwa katika Hali ya Uzingatiaji, muda wake wa kuhifadhi hauwezi kufupishwa, na kitu hicho hakiwezi kufutwa na mtu yeyote, ikiwa ni pamoja na akaunti ya mzizi ya AWS. Kufuli hutekelezwa katika kiwango cha nguzo ya hifadhi.

Usanifu wa Bomba la Hifadhi Nakala Lisiloweza Kubadilishwa

Usanifu thabiti wa kuhifadhi hifadhidata hutenganisha shughuli za hifadhidata zinazotumika na kiwango cha kumbukumbu kisichoweza kubadilishwa. Huwezi kutumia kutobadilika kwa faili za hifadhidata zinazotumika (kama .mdf/.ldf katika SQL Server au saraka ya pg_data katika PostgreSQL) kwa sababu hifadhidata zinahitaji ufikiaji wa mara kwa mara wa kusoma/kuandika.

Badala yake, kutobadilika hutumika kwa:
1. Faili za Nakala Kamili na Tofauti (Full and Differential Backup Files): Picha za msingi za hifadhidata.
2. Kumbukumbu za Miamala / Faili za WAL (Transaction Logs / WAL Files): Mtiririko unaoendelea wa mabadiliko ya hifadhidata unaohitajika kwa Urejeshaji wa Pointi-kwa-Wakati (PITR).

Malengo ya Hifadhi kwa Kutobadilika

Unaweza kutekeleza hifadhi isiyoweza kubadilishwa katika viwango tofauti vya miundombinu:
* Hifadhi ya Vitu vya Wingu: AWS S3 Object Lock, Azure Blob Immutable Storage, Sera za Uhifadhi za Google Cloud Storage.
* Hifadhi ya Vitu vya Ndani (On-Premises): MinIO, Cloudian, au Pure Storage FlashBlade inayounga mkono API za S3 Object Lock.
* Hifadhi ya Kuzuia/Faili (Block/File Storage): ZFS yenye picha za kusoma-pekee na usimamizi uliokabidhiwa, au sifa za faili za Linux.

Utekelezaji wa Hifadhi Isiyoweza Kubadilishwa: Mwongozo wa Kiufundi

1. Hifadhi ya Vitu vya Wingu: AWS S3 Object Lock

Ili kulinda utupaji wa hifadhidata na kumbukumbu za miamala katika AWS, lazima uwezeshe Object Lock wakati wa kuunda ndoo (bucket).

Kwanza, unda ndoo ikiwa Object Lock imewezeshwa:

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

Ifuatayo, sanidi sera ya msingi ya uhifadhi. Kwa kumbukumbu za hifadhidata, kufuli ya uzingatiaji ya siku 30 ni msingi wa kawaida, kuhakikisha una mwezi mmoja wa nakala za akiba zisizoweza kubadilishwa.

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

Wakati hati yako ya nakala ya hifadhidata au wakala anapopeleka faili kwenye ndoo hii, S3 huhesabu kiotomatiki Retain Until Date kulingana na muhuri wa muda wa kuundwa kwa kitu pamoja na siku 30.

2. Kutobadilika kwa Ndani (On-Premises): ZFS na Sifa za Linux

Ikiwa unahifadhi hifadhidata kwenye seva ya nakala ya Linux ya ndani, unaweza kufikia kutobadilika kwa pseudo kwa kutumia amri ya chattr, au kutobadilika kwa kweli kwa kutumia picha za ZFS.

Kutumia Linux chattr:
Bendera ya +i (immutable) inazuia urekebishaji wa faili, kufuta, au kubadilisha jina.

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

# Make the backup immutable
sudo chattr +i /backups/mydb_$(date +%F).dump

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

Kumbuka: Ingawa chattr inazuia hati za msingi za ransomware, mshambuliaji mwenye uzoefu na ufikiaji wa mzizi anaweza tu kuendesha chattr -i. Kwa hivyo, hii lazima ichanganywe na RBAC kali na mitandao ya nakala iliyotengwa.

Kutumia Picha za ZFS:
ZFS hutoa ulinzi wenye nguvu zaidi. Kwa kuchukua picha na kuweka “hold” juu yake, unazuia picha hiyo kuharibiwa.

# Take a snapshot of the backup dataset
zfs snapshot tank/db_backups@archive_$(date +%F)

# Place a hold on the snapshot to prevent deletion
zfs hold keep_30_days tank/db_backups@archive_$(date +%F)

# Even root cannot destroy this snapshot without releasing the hold
zfs destroy tank/db_backups@archive_$(date +%F)
# Output: cannot destroy 'tank/db_backups@archive_...': dataset is busy

Mikakati ya Kuhifadhi ya Hifadhidata Maalum

Ili kufikia Urejeshaji wa Pointi-kwa-Wakati (PITR), lazima uweke kumbukumbu za miamala kila mara kwenye hifadhi yako isiyoweza kubadilishwa.

Uwekaji Kumbukumbu wa PostgreSQL WAL na pgBackRest

pgBackRest ni zana ya kuaminika sana ya kuhifadhi nakala kwa PostgreSQL inayounga mkono hifadhi inayooana na S3. Ili kulinda Kumbukumbu zako za Andika-Kabla (WAL), sanidi pgBackRest kusukuma moja kwa moja kwenye ndoo yako ya S3 isiyoweza kubadilishwa.

Katika pgbackrest.conf yako:

[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

# Ensure retention aligns with your S3 Object Lock configuration
repo1-retention-full=2
repo1-retention-archive=2

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

Uzingatiaji Muhimu: Ikiwa ndoo yako ya S3 inatekeleza kufuli ya Uzingatiaji ya siku 30, lakini pgBackRest inajaribu kumaliza muda na kufuta faili za WAL baada ya siku 14 kulingana na repo1-retention-archive, simu za API za kufuta zitashindwa. Lazima uhakikishe sera ya uhifadhi ya programu yako ya nakala ni kubwa kuliko au sawa na kufuli isiyoweza kubadilishwa ya kiwango cha hifadhi.

Microsoft SQL Server: Hifadhi Nakala kwenye URL

SQL Server inasaidia nakala za asili moja kwa moja kwenye hifadhi ya vitu inayooana na S3. Unaweza kusanidi kazi ya SQL Server Agent kuandika faili za .bak na .trn moja kwa moja kwenye ndoo isiyoweza kubadilishwa.

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

Kujiendesha na Kuratibu na CloudSave

Kusimamia bendera za uhifadhi zisizoweza kubadilishwa, kuzungusha funguo za ufikiaji, na kuhakikisha ulandanishi kati ya sera za uhifadhi wa hifadhidata na kufuli za hifadhi kupitia hati maalum ni hatari sana kwa makosa. Usanidi mmoja mbaya katika kazi ya cron au simu ya API unaweza kuacha kumbukumbu zako zikiwa wazi au kusababisha gharama kubwa za hifadhi ya wingu kutokana na vitu vilivyofungwa vilivyoachwa.

Majukwaa ya nakala ya biashara kama CloudSave hurahisisha usanifu huu. CloudSave inajumuisha asili na AWS S3 Object Lock, Azure Blob Immutable Storage, na API za ndani zinazooana na S3.

Unaposanidi mpango wa nakala ya hifadhidata katika CloudSave:
1. Jukwaa hushughulikia kiotomatiki utulivu wa VSS (Volume Shadow Copy Service) kwa SQL Server au API ya pg_start_backup() kwa PostgreSQL.
2. Inatiririsha data ya nakala iliyofutwa na kusimbwa moja kwa moja kwenye lengo la hifadhi.
3. CloudSave hutumia kwa nguvu simu za API za WORM (k.m., PutObjectRetention) kwa kila kitu, ikilinganisha kikamilifu muda wa kufuli wa hifadhi na ratiba ya uhifadhi iliyofafanuliwa na sera.
4. Ikiwa mshambuliaji ataharibu dashibodi ya usimamizi ya CloudSave, bado hawezi kufuta nakala za akiba, kwani kufuli ya uzingatiaji inatekelezwa na miundombinu ya hifadhi ya msingi, si programu ya nakala.

Mbinu Bora kwa Kumbukumbu za Hifadhidata Zisizoweza Kubadilishwa

Ili kuhakikisha usanifu wako usiobadilika ni thabiti kweli, fuata mbinu bora za uhandisi wa mifumo zifuatazo:

1. Ulandanishi Mkali wa NTP

Kufuli zisizoweza kubadilishwa zimefungwa kihisabati na mihuri ya muda. Ikiwa huduma ya NTP (Network Time Protocol) kwenye safu yako ya hifadhi au seva ya nakala itaharibiwa au kuteleza, inaweza kusababisha kufuli kuisha kabla ya wakati au kutowahi kuisha kabisa. Hakikisha miundombinu yako ya hifadhi inatumia vyanzo vya NTP vilivyothibitishwa na vya ziada.

2. Tenga Majukumu ya IAM na Vitambulisho

Vitambulisho vinavyotumiwa kuandika kwenye ndoo isiyoweza kubadilishwa lazima viwe na ruhusa za s3:PutObject na s3:PutObjectRetention pekee. Kamwe havipaswi kuwa na ruhusa za s3:DeleteObject au s3:PutBucketObjectLockConfiguration.

Mfano wa sera ya IAM ya upendeleo mdogo kwa wakala wa nakala ya hifadhidata:

{
    "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. Kupima Muda wa Uhifadhi

Usiweke kufuli za uzingatiaji kwa muda mrefu kupita kiasi (k.m., miaka 7 kwa uzingatiaji) kwenye safu yako ya msingi ya urejeshaji wa haraka. Hifadhidata huzalisha kiasi kikubwa cha data ya WAL/miamala. Kufunga data hii kwa miaka kutasababisha ukuaji wa gharama ya hifadhi kwa kasi.
Badala yake, tumia mbinu ya viwango:
* Safu ya Urejeshaji wa Uendeshaji: Siku 14 hadi 30 za uhifadhi usiobadilika kwa Kamili na Kumbukumbu.
* Safu ya Kumbukumbu ya Muda Mrefu: Nakala kamili za kila mwezi zilizohamishiwa kwenye Glacier/Deep Archive na Vault Lock kwa miaka 1-7.

4. Upimaji wa Mara kwa Mara wa Urejeshaji katika VPCs Zilizotengwa

Kutobadilika kunahakikisha data haiwezi kufutwa, lakini hakuhakikishi data haina ufisadi wa kimantiki. Lazima uendeshe kiotomatiki urejeshaji wa kumbukumbu zako za hifadhidata zisizoweza kubadilishwa kwenye VPC au VLAN iliyotengwa na iliyofungwa hewa. Endesha DBCC CHECKDB (SQL Server) au pg_amcheck (PostgreSQL) kwenye data iliyorejeshwa ili kuthibitisha uadilifu wa kimuundo.

Hitimisho

Ulinzi wa ransomware ni zoezi la kudhani uvunjaji. Wakati arifa inapoanza katika SIEM yako, watendaji wa vitisho wana uwezekano mkubwa wamejaribu kuharibu miundombinu yako ya nakala. Kwa kuunda kumbukumbu zako za hifadhidata kwa kutumia hifadhi isiyoweza kubadilishwa katika Hali ya Uzingatiaji, unawaondolea washambuliaji nguvu zao kuu. Iwe unatumia API za wingu asilia, ZFS holds, au jukwaa la kuratibu la biashara kama CloudSave, kutekeleza hifadhi ya WORM si hiari tena—ni nguzo ya lazima ya usimamizi wa kisasa wa hifadhidata na urejeshaji wa maafa.

Migawanyo