Yn y dirwedd bygythiadau modern, mae meddalwedd wystlo (ransomware) wedi esblygu o amgryptio cyfleusgar i ymgyrchoedd aml-estyniad hynod dargedig. Mae Bygythiadau Parhaus Uwch (APTs) a syndicetau meddalwedd wystlo bellach yn chwilio’n weithredol am seilwaith wrth gefn ac archifau cronfa ddata yn ystod eu hamser preswylio. Os yw ymosodwr yn peryglu eich prif gronfa ddata ac ar yr un pryd yn dileu neu’n amgryptio eich storfeydd wrth gefn, mae eich sefydliad yn wynebu colled data drychinebus.<\/p>\n
Ar gyfer Gweinyddwyr Cronfeydd Data (DBAs) a pheirianwyr DevOps, nid yw’r strategaeth wrth gefn 3-2-1 draddodiadol yn ddigonol mwyach. Er mwyn gwarantu goroesiad data, rhaid i dimau seilwaith fabwysiadu’r rheol 3-2-1-1, lle mae’r “1” olaf yn cynrychioli storio annewidiol (immutable storage)<\/strong>.<\/p>\n Mae’r erthygl hon yn darparu trosolwg technegol cynhwysfawr o bensaern\u00efo, gweithredu, a rheoli storfa annewidiol ar gyfer archifau cronfa ddata er mwyn sicrhau gwytnwch llwyr yn erbyn meddalwedd wystlo.<\/p>\n Mae storfa annewidiol yn dibynnu ar bensaern\u00efaeth Ysgrifennu-Unwaith-Darllen-Llawer (WORM). Unwaith y caiff data ei ysgrifennu i darged annewidiol, ni ellir ei addasu, ei amgryptio, na’i ddileu gan unrhyw ddefnyddiwr\u2014gan gynnwys gweinyddwyr sydd \u00e2 breintiau gwraidd neu gyfrifon gwasanaeth sydd wedi’u peryglu\u2014nes bod clo amser wedi’i orfodi’n fathemategol yn dod i ben.<\/p>\n Wrth weithredu annewidioldeb, yn enwedig mewn storfa gwrthrychau cwmwl fel AWS S3, Azure Blob, neu SANs ar y safle sy’n gydnaws ag S3, rhaid i chi ddeall y gwahaniaeth rhwng dulliau cadw:<\/p>\n Mae pensaern\u00efaeth archifo cronfa ddata gadarn yn gwahanu gweithrediadau cronfa ddata gweithredol oddi wrth y haen archif annewidiol. Ni allwch gymhwyso annewidioldeb i ffeiliau cronfa ddata gweithredol (fel Yn lle hynny, cymhwysir annewidioldeb i: Gallwch weithredu storfa annewidiol ar draws haenau seilwaith gwahanol: I amddiffyn dympiadau cronfa ddata a logiau trafodion yn AWS, rhaid i chi alluogi Object Lock ar adeg creu’r bwced.<\/p>\n Yn gyntaf, cr\u00ebwch y bwced gyda Object Lock wedi’i alluogi:<\/p>\n Nesaf, ffurfweddwch y polisi cadw diofyn. Ar gyfer archifau cronfa ddata, mae clo cydymffurfio o 30 diwrnod yn sylfaen safonol, gan sicrhau bod gennych fis o backups na ellir eu newid.<\/p>\n Pan fydd eich sgript neu asiant wrth gefn cronfa ddata yn gwthio ffeil i’r bwced hwn, mae S3 yn cyfrifo’r Os ydych chi’n archifo cronfeydd data i weinydd wrth gefn Linux ar y safle, gallwch gyflawni annewidioldeb ffug gan ddefnyddio’r gorchymyn Defnyddio Linux Nodyn: Er bod Defnyddio Chipluniau ZFS:<\/strong> Er mwyn cyflawni Adferiad Pwynt-mewn-Amser (PITR), rhaid i chi archifo logiau trafodion yn barhaus i’ch storfa annewidiol.<\/p>\n Mae Yn eich Ystyriaeth Hanfodol:<\/em> Os yw’ch bwced S3 yn gorfodi clo Cydymffurfio o 30 diwrnod, ond bod Mae SQL Server yn cefnogi backups brodorol yn uniongyrchol i storfa gwrthrychau gydnaws ag S3. Gallwch ffurfweddu swydd SQL Server Agent i ysgrifennu ffeiliau Mae rheoli baneri cadw annewidiol, cylchdroi allweddi mynediad, a sicrhau cydamseriad rhwng polis\u00efau cadw cronfa ddata a chloeon storio trwy sgriptiau personol yn dueddol iawn o gael gwallau. Gall un camgymeriad mewn swydd cron neu alwad API adael eich archifau yn agored neu arwain at gostau storio cwmwl yn codi’n gyflym oherwydd gwrthrychau wedi’u cloi sydd wedi’u gadael ar \u00f4l.<\/p>\n Mae llwyfannau wrth gefn menter fel CloudSave yn symleiddio’r bensaern\u00efaeth hon. Mae CloudSave yn integreiddio’n frodorol ag AWS S3 Object Lock, Azure Blob Immutable Storage, ac APIs gydnaws ag S3 ar y safle.<\/p>\n Wrth ffurfweddu cynllun wrth gefn cronfa ddata yn CloudSave: Er mwyn sicrhau bod eich pensaern\u00efaeth annewidiol yn wirioneddol wydn, cadwch at yr arferion gorau peirianneg systemau canlynol:<\/p>\n Mae cloeon annewidiol wedi’u rhwymo’n fathemategol i stampiau amser. Os yw’r gwasanaeth NTP (Protocol Amser Rhwydwaith) ar eich arae storio neu weinydd wrth gefn wedi’i beryglu neu’n drifftio, gall achosi i gloeon ddod i ben yn gynamserol neu beidio byth \u00e2 dod i ben o gwbl. Sicrhewch fod eich seilwaith storio yn defnyddio ffynonellau NTP dilys a diswyddo.<\/p>\n Rhaid i’r credlythyrau a ddefnyddir i ysgrifennu i’r bwced annewidiol gael caniat\u00e2d Enghraifft o bolisi IAM lleiaf-fraint ar gyfer asiant wrth gefn cronfa ddata:<\/p>\n Peidiwch \u00e2 gosod cloeon cydymffurfio am gyfnodau hir iawn (e.e., 7 mlynedd ar gyfer cydymffurfio) ar eich haen adfer cyflym sylfaenol. Mae cronfeydd data yn cynhyrchu symiau enfawr o ddata WAL\/trafodion. Bydd cloi’r data hwn am flynyddoedd yn arwain at dwf cost storio esbonyddol. Mae annewidioldeb yn gwarantu na ellir dileu’r data, ond nid yw’n gwarantu bod y data yn rhydd o lygredd rhesymegol. Rhaid i chi awtomeiddio adferiad eich archifau cronfa ddata annewidiol i mewn i VPC neu VLAN ynysig, wedi’i ddatgysylltu (air-gapped). Rhedwch Mae amddiffyniad rhag meddalwedd wystlo yn ymarfer o ragdybio toriad. Erbyn yr amser y mae rhybudd yn tanio yn eich SIEM, mae’n debygol bod actorion bygythiad eisoes wedi ceisio peryglu eich seilwaith wrth gefn. Trwy bensaern\u00efo eich archifau cronfa ddata gan ddefnyddio storfa annewidiol yn y Modd Cydymffurfio, rydych chi’n tynnu’r ymosodwyr o’u prif b\u0175er. P’un a ydych chi’n defnyddio APIs cwmwl brodorol, daliadau ZFS, neu lwyfan trefnu menter fel CloudSave, nid yw gweithredu storfa WORM yn ddewisol mwyach\u2014mae’n biler gorfodol o weinyddiaeth cronfa ddata fodern ac adferiad ar \u00f4l trychineb.<\/p>\n","protected":false},"excerpt":{"rendered":" ** 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.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"Immutable Database Storage to Defeat Ransomware","rank_math_description":"** 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.","rank_math_focus_keyword":"immutable database storage","footnotes":""},"categories":[775],"tags":[4815,4816,4817,1379,4818,4819],"class_list":["post-6415","post","type-post","status-publish","format-standard","hentry","category-database-backup","tag-3-2-1-1-backup","tag-data-survivability","tag-database-archives","tag-enterprise-backup","tag-immutable-storage","tag-ransomware-protection"],"yoast_head":"\nMecanweithiau Storio Annewidiol<\/h2>\n
Modd Cydymffurfio vs. Modd Llywodraethu<\/h3>\n
\n
s3:BypassGovernanceRetention<\/code>) ddiystyru’r clo. Mae hyn yn ddefnyddiol ar gyfer profi ond yn annigonol ar gyfer amddiffyniad rhag meddalwedd wystlo<\/strong>, gan fod ymosodwyr yn aml yn dyrchafu breintiau i weinyddwr parth neu wraidd.<\/li>\nPensaern\u00efo Piblinell Wrth Gefn Annewidiol<\/h2>\n
.mdf<\/code>\/.ldf<\/code> yn SQL Server neu’r cyfeiriadur pg_data<\/code> yn PostgreSQL) oherwydd bod cronfeydd data angen mynediad darllen\/ysgrifennu cyson.<\/p>\n
\n1. Ffeiliau Wrth Gefn Llawn a Differol:<\/strong> Y cipluniau sylfaenol o’r gronfa ddata.
\n2. Logiau Trafodion \/ Ffeiliau WAL:<\/strong> Y llif parhaus o newidiadau cronfa ddata sydd eu hangen ar gyfer Adferiad Pwynt-mewn-Amser (PITR).<\/p>\nTargedau Storio ar gyfer Annewidioldeb<\/h3>\n
\n* Storfa Gwrthrychau Cwmwl:<\/strong> AWS S3 Object Lock, Azure Blob Immutable Storage, Google Cloud Storage Retention Policies.
\n* Storfa Gwrthrychau ar y Safle:<\/strong> MinIO, Cloudian, neu Pure Storage FlashBlade sy’n cefnogi APIs S3 Object Lock.
\n* Storfa Bloc\/Ffeil:<\/strong> ZFS gyda chipluniau darllen-yn-unig a gweinyddiaeth ddirprwyedig, neu briodweddau ffeil Linux.<\/p>\nGweithredu Storfa Annewidiol: Camau Technegol<\/h2>\n
1. Storfa Gwrthrychau Cwmwl: AWS S3 Object Lock<\/h3>\n
aws s3api create-bucket \n --bucket prod-db-archive-immutable \n --region us-east-1 \n --object-lock-enabled-for-bucket\n<\/code><\/pre>\naws s3api put-object-lock-configuration \n --bucket prod-db-archive-immutable \n --object-lock-configuration '{\n "ObjectLockEnabled": "Enabled",\n "Rule": {\n "DefaultRetention": {\n "Mode": "COMPLIANCE",\n "Days": 30\n }\n }\n }'\n<\/code><\/pre>\nRetain Until Date<\/code> yn awtomatig yn seiliedig ar stamp amser creu’r gwrthrych ynghyd \u00e2 30 diwrnod.<\/p>\n2. Annewidioldeb ar y Safle: ZFS a Priodweddau Linux<\/h3>\n
chattr<\/code>, neu annewidioldeb gwirioneddol gan ddefnyddio chipluniau ZFS.<\/p>\nchattr<\/code>:<\/strong>
\nMae’r faner +i<\/code> (annewidiol) yn atal addasu, dileu, neu ailenwi ffeiliau.<\/p>\n# Dympio'r gronfa ddata\npg_dump -U postgres -Fc mydb > \/backups\/mydb_$(date +%F).dump\n\n# Gwneud y backup yn annewidiol\nsudo chattr +i \/backups\/mydb_$(date +%F).dump\n\n# Gwirio'r briodwedd\nlsattr \/backups\/mydb_$(date +%F).dump\n# Allbwn: ----i---------e------- \/backups\/mydb_2023-10-27.dump\n<\/code><\/pre>\nchattr<\/code> yn atal sgriptiau meddalwedd wystlo sylfaenol, gall ymosodwr soffistigedig sydd \u00e2 mynediad gwraidd redeg chattr -i<\/code> yn syml. Felly, rhaid cyfuno hyn ag RBAC llym a rhwydweithiau wrth gefn ynysig.<\/em><\/p>\n
\nMae ZFS yn darparu amddiffyniad llawer cryfach. Trwy gymryd chiplun a gosod “dal” arno, rydych chi’n atal y chiplun rhag cael ei ddinistrio.<\/p>\n# Cymryd chiplun o'r set ddata wrth gefn\nzfs snapshot tank\/db_backups@archive_$(date +%F)\n\n# Gosod dal ar y chiplun i atal dileu\nzfs hold keep_30_days tank\/db_backups@archive_$(date +%F)\n\n# Ni all hyd yn oed y gwraidd ddinistrio'r chiplun hwn heb ryddhau'r dal\nzfs destroy tank\/db_backups@archive_$(date +%F)\n# Allbwn: cannot destroy 'tank\/db_backups@archive_...': dataset is busy\n<\/code><\/pre>\nStrategaethau Archifo Penodol i Gronfeydd Data<\/h2>\n
Archifo WAL PostgreSQL gyda pgBackRest<\/h3>\n
pgBackRest<\/code> yn offeryn wrth gefn hynod ddibynadwy ar gyfer PostgreSQL sy’n cefnogi storfa gydnaws ag S3 yn frodorol. I amddiffyn eich Logiau Ysgrifennu-Ymlaen (WAL), ffurfweddwch pgBackRest<\/code> i wthio’n uniongyrchol i’ch bwced S3 annewidiol.<\/p>\npgbackrest.conf<\/code>:<\/p>\n[global]\nrepo1-type=s3\nrepo1-s3-bucket=prod-db-archive-immutable\nrepo1-s3-region=us-east-1\nrepo1-s3-endpoint=s3.amazonaws.com\nrepo1-s3-key=AKIAIOSFODNN7EXAMPLE\nrepo1-s3-key-secret=wJalrXUtnFEMI\/K7MDENG\/bPxRfiCYEXAMPLEKEY\n\n# Sicrhau bod y cadw yn cyd-fynd \u00e2'ch ffurfweddiad S3 Object Lock\nrepo1-retention-full=2\nrepo1-retention-archive=2\n\n[prod_cluster]\npg1-path=\/var\/lib\/postgresql\/14\/main\n<\/code><\/pre>\npgBackRest<\/code> yn ceisio dod i ben a dileu ffeiliau WAL ar \u00f4l 14 diwrnod yn seiliedig ar repo1-retention-archive<\/code>, bydd y galwadau API dileu yn methu. Rhaid i chi sicrhau bod polisi cadw eich meddalwedd wrth gefn yn fwy na neu’n hafal i’r clo annewidiol ar lefel storio.<\/p>\nMicrosoft SQL Server: Wrth Gefn i URL<\/h3>\n
.bak<\/code> a .trn<\/code> yn uniongyrchol i fwced annewidiol.<\/p>\nCREATE CREDENTIAL [s3:\/\/prod-db-archive-immutable.s3.us-east-1.amazonaws.com]\nWITH IDENTITY = 'S3 Access Key',\nSECRET = 'AccessKeyID:SecretAccessKey';\nGO\n\nBACKUP DATABASE [ProductionDB]\nTO URL = 's3:\/\/prod-db-archive-immutable.s3.us-east-1.amazonaws.com\/ProductionDB_Full.bak'\nWITH FORMAT, COMPRESSION, STATS = 10;\nGO\n<\/code><\/pre>\nAwtomeiddio a Threfnu gyda CloudSave<\/h2>\n
\n1. Mae’r llwyfan yn trin y tawelwch VSS (Volume Shadow Copy Service) ar gyfer SQL Server neu’r API pg_start_backup()<\/code> ar gyfer PostgreSQL yn awtomatig.
\n2. Mae’n ffrydio’r data wrth gefn wedi’i ddad-ddyblygu a’i amgryptio yn uniongyrchol i’r targed storio.
\n3. Mae CloudSave yn cymhwyso’r galwadau API WORM (e.e., PutObjectRetention<\/code>) yn ddeinamig ar sail pob gwrthrych, gan alinio hyd y clo storio yn berffaith \u00e2’r amserlen gadw a ddiffiniwyd gan y polisi.
\n4. Os yw ymosodwr yn peryglu consol rheoli CloudSave, ni allant o hyd ddileu’r backups, gan fod y clo cydymffurfio yn cael ei orfodi gan y seilwaith storio sylfaenol, nid y meddalwedd wrth gefn.<\/p>\nArferion Gorau ar gyfer Archifau Cronfa Ddata Annewidiol<\/h2>\n
1. Cydamseriad NTP Llym<\/h3>\n
2. Ynysu Rolau a Chredlythyrau IAM<\/h3>\n
s3:PutObject<\/code> a s3:PutObjectRetention<\/code> yn unig. Ni ddylent byth<\/strong> gael caniat\u00e2d s3:DeleteObject<\/code> neu s3:PutBucketObjectLockConfiguration<\/code>.<\/p>\n{\n "Version": "2012-10-17",\n "Statement": [\n {\n "Effect": "Allow",\n "Action": [\n "s3:PutObject",\n "s3:GetBucketObjectLockConfiguration"\n ],\n "Resource": [\n "arn:aws:s3:::prod-db-archive-immutable",\n "arn:aws:s3:::prod-db-archive-immutable\/*"\n ]\n }\n ]\n}\n<\/code><\/pre>\n3. Maint y Cyfnod Cadw<\/h3>\n
\nYn lle hynny, defnyddiwch ddull haenog:
\n* Haen Adfer Gweithredol:<\/strong> 14 i 30 diwrnod o gadw annewidiol ar gyfer Llawn a Logiau.
\n* Haen Archifo Hirdymor:<\/strong> Backups llawn misol wedi’u symud i Glacier\/Deep Archive gyda Vault Lock am 1-7 mlynedd.<\/p>\n4. Profi Adferiad Rheolaidd mewn VPCs wedi’u Ynysu (Air-Gapped)<\/h3>\n
DBCC CHECKDB<\/code> (SQL Server) neu pg_amcheck<\/code> (PostgreSQL) ar y data a adferwyd i wirio cyfanrwydd strwythurol.<\/p>\nCasgliad<\/h2>\n