Copia de seguridad segura fuera del sitio, incluso en el caso de acceso raíz de hackers

Estoy buscando una manera de implementar una forma más segura de hacer una copia de seguridad fuera del sitio que también proteja mis datos contra la situación en la que un pirata informático malicioso ha obtenido acceso de root a mi servidor. A pesar de que la posibilidad de que eso ocurra es menor que otros tipos de riesgos si SSH y la seguridad de contraseña se configuran correctamente y el sistema se mantiene actualizado, la cantidad de daño que se puede hacer de forma permanente es realmente alta y, por lo tanto, yo Me gustaría encontrar una solución para limitar eso.

Ya he probado dos formas de copias de seguridad externas:

• un simple montaje webdav de escritura raíz (y configurado en fstab) donde se copian los datos respaldados. Problema : no es realmente una copia de seguridad externa porque la conexión, y además el acceso, a la ubicación externa se deja constantemente abierta como una carpeta en el sistema de archivos. Esta es una protección suficiente contra muchos tipos de ataques si el montaje tiene privilegios de acceso limitados (acceso de solo lectura de root), pero no protege contra una persona maliciosa con acceso de root.

• Borg copia de seguridad a través de SSH con autenticación de clave. Problema : la conexión a ese servidor externo se puede realizar con la clave que está almacenada en el host si el usuario malintencionado tiene acceso de root al host.

Como solución, estoy pensando en estas posibles formas, pero no sé cómo y con qué:

• Las copias de seguridad solo se pueden escribir o agregar al destino, pero no se pueden eliminar.
• El uso de software de respaldo que maneja los respaldos externos y no admite la eliminación masiva de los respaldos externos del primer host.

Soluciones que no son realmente interesantes en mi situación:

• Un trabajo de copia de seguridad adicional en el host externo que los transfiere a una ubicación a la que no puede acceder el primer host (debido a limitaciones técnicas).

¿Alguien puede dar consejos sobre cómo implementar una copia de seguridad externa adecuada para mi caso?

Todas sus sugerencias actualmente tienen una cosa en común: la fuente de respaldo hace el respaldo y tiene acceso al destino de respaldo. Ya sea que monte la ubicación o use herramientas como SSH o rsync, el sistema fuente de alguna manera tiene acceso a la copia de seguridad. Por lo tanto, un compromiso en el servidor también puede comprometer sus copias de seguridad.

¿Qué sucede si la solución de respaldo tiene acceso al servidor? El sistema de respaldo puede hacer su trabajo con un acceso de solo lectura , por lo que cualquier compromiso en el sistema de respaldo probablemente no comprometerá al servidor. Además, el sistema de copia de seguridad podría dedicarse solo para ese propósito, haciendo que el contenido de la copia de seguridad sea el único vector de ataque. Eso sería muy poco probable y necesitaría un ataque realmente sofisticado.

Para evitar sobrescribir las copias de seguridad con contenido alterado o dañado, realice copias de seguridad incrementales que le permitan restaurar cualquier estado anterior dentro del período de restauración definido.

Almacenamiento inmutable

Una buena opción es hacer que su almacenamiento de respaldo sea inmutable, o al menos proporcionar versiones confiables que le permitan una inmutabilidad efectiva. Para ser claros: inmutable significa que no se puede cambiar, o permanente.

Existen múltiples servicios que pueden hacer esto por usted. AWS S3, BackBlaze B2 y sospecho que Azure y Google ofrecen un servicio similar. Probablemente podría configurar un servidor para hacer esto, pero no estoy seguro de cómo.

Cuando tiene un repositorio inmutable / controlado por la versión, puede restaurar su copia de seguridad en cualquier punto, por lo que si su host está en peligro, puede restaurarlo como en cualquier momento.

* AWS S3 **

Estoy más familiarizado con AWS S3. S3 proporciona almacenamiento encriptado versionado, con un alto nivel de durabilidad.

S3 admite el control de versiones, lo que le brinda una inmutabilidad efectiva. Puede elegir usar reglas de ciclo de vida para eliminar la versión anterior de los archivos después de un período de tiempo que puede configurar. También puede archivar versiones en almacenamiento en frío (glacier cold archive), que cuesta alrededor de $ 1 / TB / mes.

Puede usar la clase de almacenamiento inteligente en niveles para reducir costos. Elijo usar una regla de ciclo de vida para mover todos los datos estáticos a una clase de acceso poco frecuente, que es un rendimiento duradero y moderado (en caliente) pero no tiene la escalabilidad o el rendimiento del estándar S3.

S3 utiliza usuarios y políticas de IAM (gestión de acceso de identidad, es decir, gestión de usuarios). Esto le brinda un control muy granular de lo que su software de respaldo puede hacer con su almacenamiento. Puede dar permiso al usuario de respaldo para las cargas pero denegar la actualización y la eliminación. También puede requerir autenticación de múltiples factores para eliminar archivos, o incluso proporcionar un bloqueo de objeto para que los archivos no se puedan eliminar.

Software Sugerido

Creo copias de seguridad incrementales usando Restic . Restic carga los nuevos archivos a su ubicación de almacenamiento. Creo (pero podría ser incorrecto) que crea nuevos archivos, pero en general no actualiza ni elimina ningún archivo.

Borg es otra opción. Solía ​​usar Borg, pero descubrí que con mis copias de seguridad de tamaño moderado de cientos de MB, efectivamente cargaba todos mis datos todos los días de EC2 a S3. Para mí esto no es incremental, así que dejé de usarlo. Encontré documentación sobre esto, pero no tengo el enlace.

Hay docenas de piezas de software que pueden cargarse en el almacenamiento en la nube.

Almacenamiento protegido

Con algún software de respaldo, podría intentar otorgarle al usuario de IAM permiso para escribir nuevos archivos pero no actualizar los existentes. Es fácil hacer esta restricción con AWS IAM, pero según el comentario a continuación, Restic no funcionará con esos permisos. También puede tener autenticación multifactor requerida para eliminar archivos de S3.

Podría tener otro usuario de IAM, que se ejecute desde, digamos, su PC, que realiza la limpieza periódica del archivo, descartando las versiones según la política que establezca.

Borg Backup admite repositorios remotos de solo agregado . Cualquier compromiso del servidor que se está respaldando solo puede generar nuevas copias de seguridad, no sobrescribiendo solo las antiguas.

Soluciones que no son realmente interesantes en mi situación:

Un trabajo de copia de seguridad adicional en el host externo que los transfiere a una ubicación a la que no puede acceder el primer host.

El problema fundamental es que si puede acceder de forma remota a sus copias de seguridad , también puede hacerlo el hacker .

(Debido a limitaciones técnicas)

Las limitaciones técnicas están hechas para ser superadas.

¿Alguien puede dar consejos sobre cómo implementar una copia de seguridad externa adecuada para mi caso?

Las unidades de cinta han brindado protección segura fuera del sitio contra todo tipo de desastres, incluidos los piratas informáticos, durante casi 70 años.

Puede usar servicios de almacenamiento como AWS S3 (o probablemente el equivalente de Google o Azure) donde puede otorgar permisos de PUT de su cuenta raíz a su bucket pero no permisos de BORRAR. De esa manera, puede usar un modelo de inserción y el atacante no podrá eliminar la copia de seguridad.

Existen otras medidas de seguridad que puede tomar con AWS, como exigir que MFA realice DELETE en el bucket, pero permitir PUT y GET sin MFA. De esa manera, puede hacer una copia de seguridad de sus datos y recuperarlos para restaurar sus servicios sin usar su dispositivo MFA, lo que podría ser útil en algún caso extremo (y probablemente demasiado oscuro como para mencionarlo) donde el acceso al dispositivo MFA podría comprometerlo.

Además, un comentario fuera de alcance que puede encontrar interesante / útil, hay varias formas de configurar S3 y servicios similares para la conmutación por error automática en caso de que la fuente de datos principal esté fuera de línea.

Borg copia de seguridad a través de SSH con autenticación de clave. Problema: la conexión a ese servidor externo se puede hacer con la clave que está almacenada en el host si el usuario malintencionado tiene acceso de root al host.

Puede usar el comando de opción en sus claves_autorizadas. Arreglas el comando permitido en remoto.

cómo agregar comandos en ssh Authorized_keys

Incluso si un atacante recupera la raíz de inicio de sesión, no podrá hacer nada más que el comando definido.

Una técnica que puede configurar es usar la sincronización entre su servidor y un servidor de respaldo remoto, y dejar que el servidor de respaldo remoto realice instantáneas o lo que sea que tenga en su extremo para que el lado del servidor de borrado no resulte en un borrado fuera del sitio.