
Tengo algunos servidores (virtuales). Hacen una copia de seguridad de sí mismos en Backblaze B2 usando una clave de aplicación.
Quiero contratar a una persona para que me ayude a administrar estos servidores.
Cuando esa persona obtiene acceso root al servidor (que quiero), también obtiene acceso a la clave de la aplicación B2. Esto significa que puede eliminar el servidor.yla copia de seguridad.
¿Cuál es un procedimiento/configuración que podría utilizar para protegerme contra este caso límite? Tengo copias de seguridad fuera de línea, pero son mensuales, mientras que las copias de seguridad B2 son diarias.
Respuesta1
En algunos entornos, simplemente divide el trabajo en dos equipos: un equipo ejecuta/protege los servidores, el otro ejecuta/protege las copias de seguridad.
la otra parte es, en mi opinión, aún más importante: si la copia de seguridad se puede escribir, especialmente desde el sistema del que se está realizando la copia de seguridad, NO es una buena copia de seguridad.
Problema sistémico en muchas herramientas como borg. Es mejor si puede (en un mundo de nube) enviar las copias de seguridad al glaciar AWS, mientras las almacena en S3 con una función que solo puede crearlas. hay cronogramas para la eliminación y nadie necesita poder hacerlo "rápidamente".
Además, no olvides que hay libros sobre este tema.
Respuesta2
He aquí cómo hacerlo:
En Backblaze B2, cree una clave de aplicación que no pueda eliminar archivos:
b2 create-key --bucket MyBucket MyKeyName listBuckets,listFiles,readFiles,writeFiles
Configure la copia de seguridad para que utilice esa clave y no intente eliminar archivos de copia de seguridad antiguos. Por ejemplo, en
duplicity
, no utiliceremove-older-than
,remove-all-but-n-full
oremove-all-inc-of-but-n-full
; enduply
, no utilicepurge
opurgeIncr
.Para eliminar copias de seguridad antiguas, establezca configuraciones de ciclo de vida personalizadas en el depósito; por ejemplo, establezca que las líneas que comienzan con
duplicity-full
se oculten después de 360 días y se eliminen después de otros 360; y así sucesivamente para archivos que comienzan conduplicity-inc
yduplicity-new
.
Actualizar:
B2 en realidad no proporciona ninguna funcionalidad para "eliminar un archivo". Cada vez que reemplaza el mismo archivo, mantiene su historial, por lo que un archivo puede tener "versiones": la más reciente normalmente es la que necesita. Lo que proporciona B2 es la funcionalidad para "ocultar" un archivo. Cuando oculta un archivo, en realidad está registrando en el historial del archivo que el archivo fue "eliminado", de alguna manera agrega una nueva versión del archivo que es el archivo oculto o eliminado.
Excepto por eso, B2 también proporciona funcionalidad para eliminar versiones de archivos. Un usuario que no tiene el permiso de eliminar archivos en realidad tiene permiso para ocultar archivos, pero no para eliminar versiones de archivos.
Me parece que la remove-...
funcionalidad de la duplicidad debería implementarse ocultando archivos. (Entonces dependería de la configuración del depósito eliminar estas versiones de archivos ocultos después de un cierto período de tiempo). Sin embargo, el backend de B2 de duplicity no hace esto; lo que hace es eliminar versiones de archivos.
Respuesta3
En la mayoría de las nubes públicas, el acceso ssh al servidor no significa que pueda eliminarlo. Existe una diferencia entre administrar en el servidor y en la cuenta de la nube. Entonces, puedes separarlos. También puede dividir bastante los permisos, especialmente en Amazon AWS. Puedes darle a alguien el permiso para reiniciar el servidor, pero no eliminarlo, por ejemplo. Y AWS tiene la opción de protección contra eliminación en las máquinas virtuales.
La mejor práctica, en estos días, es utilizar la administración de configuración como Chef/Puppet/Salt/Ansible para realizar cambios en sus servidores y no iniciar sesión en los servidores.
Además, para AWS, puede tomar instantáneas de los servidores con la frecuencia que desee y esta es la forma más eficiente de realizar copias de seguridad de ellos.