En el panorama actual de amenazas, el ransomware ha evolucionado desde el cifrado oportunista hasta campa\u00f1as altamente dirigidas de extorsi\u00f3n m\u00faltiple. Las Amenazas Persistentes Avanzadas (APT) y los sindicatos de ransomware buscan activamente infraestructuras de copia de seguridad y archivos de bases de datos durante su tiempo de permanencia. Si un atacante compromete su base de datos principal y, simult\u00e1neamente, elimina o cifra sus repositorios de copia de seguridad, su organizaci\u00f3n se enfrentar\u00e1 a una p\u00e9rdida de datos catastr\u00f3fica.<\/p>\n
Para los administradores de bases de datos (DBA) y los ingenieros de DevOps, la estrategia tradicional de copia de seguridad 3-2-1 ya no es suficiente. Para garantizar la supervivencia de los datos, los equipos de infraestructura deben adoptar la regla 3-2-1-1, donde el \u00faltimo \u00ab1\u00bb representa el almacenamiento inmutable<\/strong>.<\/p>\n Este art\u00edculo ofrece un an\u00e1lisis t\u00e9cnico exhaustivo sobre c\u00f3mo dise\u00f1ar, implementar y gestionar el almacenamiento inmutable para archivos de bases de datos, con el fin de garantizar una resiliencia absoluta frente al ransomware.<\/p>\n El almacenamiento inmutable se basa en una arquitectura WORM (Write-Once-Read-Many, o \u00abescribir una vez, leer muchas\u00bb). Una vez que los datos se escriben en un destino inmutable, ning\u00fan usuario \u2014incluidos los administradores con privilegios de root o cuentas de servicio comprometidas\u2014 puede modificarlos, cifrarlos ni eliminarlos hasta que expire un bloqueo temporal aplicado matem\u00e1ticamente.<\/p>\n Al implementar la inmutabilidad, especialmente en almacenamiento de objetos en la nube como AWS S3, Azure Blob o SAN locales compatibles con S3, debe comprender la distinci\u00f3n entre los modos de retenci\u00f3n:<\/p>\n Una arquitectura s\u00f3lida de archivo de bases de datos separa las operaciones activas de la base de datos del nivel de archivo inmutable. No se puede aplicar la inmutabilidad a los archivos activos de la base de datos (como En su lugar, la inmutabilidad se aplica a: Puede implementar almacenamiento inmutable en diferentes niveles de infraestructura: Para proteger los volcados de bases de datos y los registros de transacciones en AWS, debe habilitar Object Lock en el momento de crear el bucket.<\/p>\n Primero, cree el bucket con Object Lock habilitado:<\/p>\n A continuaci\u00f3n, configure la pol\u00edtica de retenci\u00f3n predeterminada. Para los archivos de bases de datos, un bloqueo de cumplimiento de 30 d\u00edas es una base est\u00e1ndar, lo que garantiza que dispone de un mes de copias de seguridad inalterables.<\/p>\n Cuando su script o agente de copia de seguridad de la base de datos env\u00eda un archivo a este bucket, S3 calcula autom\u00e1ticamente la Si est\u00e1 archivando bases de datos en un servidor de copia de seguridad Linux local, puede lograr una pseudo-inmutabilidad usando el comando Uso de Nota: Aunque Uso de instant\u00e1neas de ZFS:<\/strong> Para lograr la recuperaci\u00f3n en un momento dado (PITR), debe archivar continuamente los registros de transacciones en su almacenamiento inmutable.<\/p>\n En su Consideraci\u00f3n crucial:<\/em> Si su bucket de S3 aplica un bloqueo de cumplimiento de 30 d\u00edas, pero SQL Server admite copias de seguridad nativas directamente en almacenamiento de objetos compatible con S3. Puede configurar un trabajo del Agente de SQL Server para escribir archivos Gestionar los indicadores de retenci\u00f3n inmutable, rotar las claves de acceso y garantizar la sincronizaci\u00f3n entre las pol\u00edticas de retenci\u00f3n de la base de datos y los bloqueos de almacenamiento mediante scripts personalizados es muy propenso a errores. Una sola configuraci\u00f3n incorrecta en un trabajo cron o una llamada a la API puede dejar sus archivos expuestos o provocar que los costes de almacenamiento en la nube se disparen debido a objetos bloqueados hu\u00e9rfanos.<\/p>\n Las plataformas de copia de seguridad empresariales como CloudSave simplifican esta arquitectura. CloudSave se integra de forma nativa con AWS S3 Object Lock, Azure Blob Immutable Storage y API compatibles con S3 locales.<\/p>\n Al configurar un plan de copia de seguridad de base de datos en CloudSave: Para garantizar que su arquitectura inmutable sea verdaderamente resiliente, siga estas mejores pr\u00e1cticas de ingenier\u00eda de sistemas:<\/p>\n Los bloqueos inmutables est\u00e1n vinculados matem\u00e1ticamente a las marcas de tiempo. Si el servicio NTP (Network Time Protocol) de su cabina de almacenamiento o servidor de copia de seguridad se ve comprometido o se desv\u00eda, puede provocar que los bloqueos expiren prematuramente o que nunca expiren. Aseg\u00farese de que su infraestructura de almacenamiento utilice fuentes NTP autenticadas y redundantes.<\/p>\n Las credenciales utilizadas para escribir en el bucket inmutable solo deben tener permisos Ejemplo de una pol\u00edtica IAM de privilegios m\u00ednimos para un agente de copia de seguridad de base de datos:<\/p>\n No establezca bloqueos de cumplimiento por per\u00edodos excesivamente largos (por ejemplo, 7 a\u00f1os por cumplimiento) en su nivel principal de recuperaci\u00f3n r\u00e1pida. Las bases de datos generan cantidades masivas de datos de registros de transacciones\/WAL. Bloquear estos datos durante a\u00f1os provocar\u00e1 un crecimiento exponencial de los costes de almacenamiento. La inmutabilidad garantiza que los datos no se puedan eliminar, pero no garantiza que los datos est\u00e9n libres de corrupci\u00f3n l\u00f3gica. Debe automatizar la restauraci\u00f3n de sus archivos de base de datos inmutables en una VPC o VLAN aislada (air-gapped). Ejecute La defensa contra el ransomware es un ejercicio de asumir que se ha producido una brecha. Para cuando se dispara una alerta en su SIEM, es probable que los actores de amenazas ya hayan intentado comprometer su infraestructura de copia de seguridad. Al dise\u00f1ar sus archivos de base de datos mediante almacenamiento inmutable en modo de cumplimiento, despoja a los atacantes de su principal ventaja. Tanto si utiliza API nativas de la nube, retenciones de ZFS o una plataforma de orquestaci\u00f3n empresarial como CloudSave, implementar almacenamiento WORM ya no es opcional: es un pilar obligatorio de la administraci\u00f3n moderna de bases de datos y la recuperaci\u00f3n ante desastres.<\/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":[351],"tags":[4550,4551,4552,1273,4553,4554],"class_list":["post-6355","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":"\nLa mec\u00e1nica del almacenamiento inmutable<\/h2>\n
Modo de cumplimiento frente a modo de gobernanza<\/h3>\n
\n
s3:BypassGovernanceRetention<\/code>) pueden omitir el bloqueo. Esto es \u00fatil para realizar pruebas, pero insuficiente para la protecci\u00f3n contra ransomware<\/strong>, ya que los atacantes suelen escalar privilegios hasta convertirse en administradores de dominio o root.<\/li>\nDise\u00f1o de una canalizaci\u00f3n de copia de seguridad inmutable<\/h2>\n
.mdf<\/code>\/.ldf<\/code> en SQL Server o el directorio pg_data<\/code> en PostgreSQL) porque las bases de datos requieren acceso constante de lectura\/escritura.<\/p>\n
\n1. Archivos de copia de seguridad completos y diferenciales:<\/strong> Las instant\u00e1neas base de la base de datos.
\n2. Registros de transacciones \/ Archivos WAL:<\/strong> El flujo continuo de cambios en la base de datos necesarios para la recuperaci\u00f3n en un momento dado (PITR).<\/p>\nDestinos de almacenamiento para la inmutabilidad<\/h3>\n
\n* Almacenamiento de objetos en la nube:<\/strong> AWS S3 Object Lock, Azure Blob Immutable Storage, pol\u00edticas de retenci\u00f3n de Google Cloud Storage.
\n* Almacenamiento de objetos local:<\/strong> MinIO, Cloudian o Pure Storage FlashBlade compatibles con las API de S3 Object Lock.
\n* Almacenamiento de bloques\/archivos:<\/strong> ZFS con instant\u00e1neas de solo lectura y administraci\u00f3n delegada, o atributos de archivo de Linux.<\/p>\nImplementaci\u00f3n de almacenamiento inmutable: tutoriales t\u00e9cnicos<\/h2>\n
1. Almacenamiento de objetos en la nube: 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> (fecha de retenci\u00f3n) bas\u00e1ndose en la marca de tiempo de creaci\u00f3n del objeto m\u00e1s 30 d\u00edas.<\/p>\n2. Inmutabilidad local: ZFS y atributos de Linux<\/h3>\n
chattr<\/code>, o una inmutabilidad real usando instant\u00e1neas de ZFS.<\/p>\nchattr<\/code> en Linux:<\/strong>
\nEl indicador +i<\/code> (inmutable) impide la modificaci\u00f3n, eliminaci\u00f3n o cambio de nombre de archivos.<\/p>\n# Volcar la base de datos\npg_dump -U postgres -Fc mydb > \/backups\/mydb_$(date +%F).dump\n\n# Hacer que la copia de seguridad sea inmutable\nsudo chattr +i \/backups\/mydb_$(date +%F).dump\n\n# Verificar el atributo\nlsattr \/backups\/mydb_$(date +%F).dump\n# Salida: ----i---------e------- \/backups\/mydb_2023-10-27.dump\n<\/code><\/pre>\nchattr<\/code> detiene los scripts de ransomware b\u00e1sicos, un atacante sofisticado con acceso root puede simplemente ejecutar chattr -i<\/code>. Por lo tanto, esto debe combinarse con un RBAC estricto y redes de copia de seguridad aisladas.<\/em><\/p>\n
\nZFS proporciona una defensa mucho m\u00e1s fuerte. Al tomar una instant\u00e1nea y colocarle una \u00abretenci\u00f3n\u00bb (hold), se evita que la instant\u00e1nea sea destruida.<\/p>\n# Tomar una instant\u00e1nea del conjunto de datos de copia de seguridad\nzfs snapshot tank\/db_backups@archive_$(date +%F)\n\n# Colocar una retenci\u00f3n en la instant\u00e1nea para evitar su eliminaci\u00f3n\nzfs hold keep_30_days tank\/db_backups@archive_$(date +%F)\n\n# Ni siquiera root puede destruir esta instant\u00e1nea sin liberar la retenci\u00f3n\nzfs destroy tank\/db_backups@archive_$(date +%F)\n# Salida: cannot destroy 'tank\/db_backups@archive_...': dataset is busy\n<\/code><\/pre>\nEstrategias de archivo espec\u00edficas para bases de datos<\/h2>\n
Archivo de WAL de PostgreSQL con pgBackRest<\/h3>\n
pgBackRest<\/code> es una herramienta de copia de seguridad altamente fiable para PostgreSQL que admite de forma nativa el almacenamiento compatible con S3. Para proteger sus registros de escritura anticipada (WAL), configure pgBackRest<\/code> para que los env\u00ede directamente a su bucket S3 inmutable.<\/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# Aseg\u00farese de que la retenci\u00f3n se alinee con su configuraci\u00f3n de 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> intenta expirar y eliminar archivos WAL despu\u00e9s de 14 d\u00edas bas\u00e1ndose en repo1-retention-archive<\/code>, las llamadas a la API de eliminaci\u00f3n fallar\u00e1n. Debe asegurarse de que la pol\u00edtica de retenci\u00f3n de su software de copia de seguridad sea igual o superior al bloqueo inmutable a nivel de almacenamiento.<\/p>\nMicrosoft SQL Server: Copia de seguridad en URL<\/h3>\n
.bak<\/code> y .trn<\/code> directamente en un bucket inmutable.<\/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>\nAutomatizaci\u00f3n y orquestaci\u00f3n con CloudSave<\/h2>\n
\n1. La plataforma gestiona autom\u00e1ticamente la quiescencia de VSS (Volume Shadow Copy Service) para SQL Server o la API pg_start_backup()<\/code> para PostgreSQL.
\n2. Transmite los datos de copia de seguridad deduplicados y cifrados directamente al destino de almacenamiento.
\n3. CloudSave aplica din\u00e1micamente las llamadas a la API WORM (por ejemplo, PutObjectRetention<\/code>) por objeto, alineando perfectamente la duraci\u00f3n del bloqueo de almacenamiento con el programa de retenci\u00f3n definido por la pol\u00edtica.
\n4. Si un atacante compromete la consola de gesti\u00f3n de CloudSave, seguir\u00e1 sin poder eliminar las copias de seguridad, ya que el bloqueo de cumplimiento lo aplica la infraestructura de almacenamiento subyacente, no el software de copia de seguridad.<\/p>\nMejores pr\u00e1cticas para archivos de bases de datos inmutables<\/h2>\n
1. Sincronizaci\u00f3n NTP estricta<\/h3>\n
2. Aislar roles y credenciales IAM<\/h3>\n
s3:PutObject<\/code> y s3:PutObjectRetention<\/code>. Nunca<\/strong> deben tener permisos s3:DeleteObject<\/code> o 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. Dimensionamiento del per\u00edodo de retenci\u00f3n<\/h3>\n
\nEn su lugar, utilice un enfoque por niveles:
\n* Nivel de recuperaci\u00f3n operativa:<\/strong> De 14 a 30 d\u00edas de retenci\u00f3n inmutable para copias completas y registros.
\n* Nivel de archivo a largo plazo:<\/strong> Copias de seguridad completas mensuales movidas a Glacier\/Deep Archive con Vault Lock durante 1-7 a\u00f1os.<\/p>\n4. Pruebas de recuperaci\u00f3n peri\u00f3dicas en VPC aisladas (Air-Gapped)<\/h3>\n
DBCC CHECKDB<\/code> (SQL Server) o pg_amcheck<\/code> (PostgreSQL) en los datos restaurados para verificar la integridad estructural.<\/p>\nConclusi\u00f3n<\/h2>\n