Cualquier solución que no incluya el cifrado en el lado del cliente con las claves en poder del propietario no va a cumplir con el primer requisito establecido (protección / seguridad de IP): cualquier pirateo del lado del servidor revela datos sin cifrar. Esto descarta los sistemas de sincronización en la nube, como Dropbox, que posee las claves.
Para evitar alojar las claves de cifrado más importantes en el servidor del sitio web, que también es probable que sea pirateado en algún momento, esto es lo que haría:
- Servidor de respaldo interno en el propio sitio del cliente: tiene claves de cifrado y claves SSH para los otros dos servidores
- Servidor que aloja el sitio web: podría ser un host web
- Servidor o servicio de respaldo en la nube
Paso 1: el servidor (1) extrae la copia de seguridad de (2), por lo que la mayoría de los hacks del servidor del sitio web no comprometerán las copias de seguridad. El cifrado tiene lugar en este punto.
- Me gustaría utilizar rsnapshot a través de SSH usando inicio de sesión basado en clave, ya que esto tiene unos requisitos mínimos sobre la red de acogida e internos servidor de copia de seguridad - a menos que tenga una gran base de datos de copia de seguridad es muy eficiente en ancho de banda y almacena varias versiones del sitio, y también maneja la purga de copias de seguridad antiguas.
- El cifrado puede hacerse mediante cualquier herramienta de archivo a archivo, como GPG, copiando el árbol rsnapshot a otro árbol, o puede usar la duplicidad para el paso 2, ahorrando espacio en el disco.
- "Extraer" del servidor de respaldo es importante: si el servidor principal (2) tiene las contraseñas / claves para el servidor de respaldo, los piratas informáticos pueden y, a veces, eliminarán los respaldos después de piratear el servidor principal (ver más abajo). Los hacks realmente avanzados pueden instalar binarios SSH troyanos que luego podrían comprometer el servidor de respaldo, pero eso es menos probable para la mayoría de las empresas.
Paso 2: el servidor (1) empuja las copias de seguridad cifradas a (3) para que haya una copia de seguridad externa. Si las copias de seguridad se cifraron en el paso 1, puede usar un espejo rsync del árbol de rsnapshot local para el sistema remoto.
- La duplicidad sería una buena opción para encriptar y respaldar directamente el árbol rsnapshot sin cifrar en el servidor remoto. Las características de Duplicity son un poco diferentes a rsnapshot, ya que utiliza archivos tar cifrados con GPG, pero proporciona cifrado de respaldo en el host remoto y solo requiere SSH en ese host (o puede usar Amazon S3). Duplicity no admite enlaces duros , por lo que si es necesario (por ejemplo, para una copia de seguridad completa del servidor), es mejor si un script convierte el árbol rsnapshot (que admite enlaces duros) en un archivo tar (tal vez solo los archivos que tienen> 1 enlace duro, que será bastante pequeño) para que la duplicidad pueda hacer una copia de seguridad del archivo tar.
- Dado que el servidor remoto es solo un host SSH, posiblemente con rsync, podría ser un host web (pero de un proveedor de alojamiento diferente y en una parte diferente del país), o un servicio en la nube que proporciona rsync y / o SSH. esta respuesta en las copias de seguridad de rsync a la nube por su recomendación de bqbackup y rsync.net, aunque no estoy de acuerdo con la configuración de copia de seguridad mencionada.
- Puede usar Amazon S3 como servidor remoto con duplicidad, lo que le daría una disponibilidad realmente buena, aunque tal vez le costaría más para copias de seguridad grandes.
- Otras opciones para copias de seguridad cifradas remotas son Boxbackup (no tan maduro, algunas características agradables) y Tarsnap (servicio en la nube comercial basado en Amazon S3 con interfaz de línea de comandos simple, buena deduplicación y cifrado muy completo).
La seguridad de todos los distintos hosts es importante, por lo que debe ajustarse para cumplir con el perfil de seguridad del cliente, es decir, analizar las amenazas, los riesgos, los vectores de ataque, etc. Ubuntu Server no es un mal comienzo ya que tiene actualizaciones de seguridad frecuentes para 5 años, pero se requiere atención a la seguridad en todos los servidores.
Esta configuración proporciona 2 copias de seguridad independientes, una de las cuales puede ser un servicio de almacenamiento en la nube de alta disponibilidad, funciona en modo pull, por lo que la mayoría de los ataques en el sitio web no pueden destruir las copias de seguridad al mismo tiempo, y utiliza herramientas de código abierto bien probadas que no Requiere mucha administración.
- Las copias de seguridad independientes son críticas, porque los piratas informáticos a veces eliminan todas las copias de seguridad al mismo tiempo que piratean el sitio web; en el caso más reciente, los piratas informáticos destruyeron 4800 sitios web, incluidas las copias de seguridad al piratear el entorno de alojamiento web en lugar de los sitios. Vea también esta respuesta y esta .
- Restaurar es muy fácil con rsnapshot: hay un archivo en cada árbol de instantáneas para cada archivo respaldado, así que solo busque los archivos con las herramientas de Linux y rsync o regréselos al sitio web. Si el servidor de respaldo en el sitio no está disponible por alguna razón, solo use duplicidad para restaurarlo desde el servidor de respaldo en la nube, o puede usar herramientas estándar como GPG, rdiff y tar para restaurar los respaldos.
Dado que esta configuración utiliza SSH y rsync estándar, debería ser más fácil elegir un proveedor adecuado con las garantías de tiempo de actividad correctas, seguridad sólida, etc. No tiene que cerrar un contrato largo y si el servicio de respaldo tiene una catástrofe falla, aún tiene una copia de seguridad local y puede cambiar a otro servicio de copia de seguridad con bastante facilidad.