Restic: Soporta copias de seguridad asimétricas

Un breve resumen de la discusión anterior:

• Útil para copias de seguridad de servidores de correo electrónico o copias de seguridad remotas de datos de registro en caso de que dicho servidor se vea comprometido. Los datos confidenciales que se han triturado del servidor pueden estar presentes en la copia de seguridad y puede ser útil poder denegar a un atacante el acceso a dichos datos históricos. Simultáneamente se discutió que podría ser útil tener un "servidor de red blob" con un sistema de capacidad que le permita configurar el acceso de solo adición / solo lectura / lectura-escritura según corresponda. Tener la criptografía asimétrica en su lugar eliminaría la necesidad de tener _todo otro_ conjunto de claves simétricas para emitir capacidades, y probablemente también simplificaría la implementación de un sistema de capacidades.
• En un entorno con varias máquinas, se puede usar _una_ clave de respaldo para acceder a varios conjuntos de datos de respaldo sin tener que administrar una multitud de claves simétricas. Si se usa un criptosistema como el Curve25519 de Daniel Bernstein, dicha clave puede derivarse de una frase de contraseña, lo que significa que puede usar una frase de contraseña maestra para administrar las copias de seguridad creadas por una cantidad (potencialmente grande) de dominios de seguridad diferentes. Aunque, por supuesto, se puede lograr algo similar con n claves simétricas y un almacenamiento de claves cifradas.

@heipei FYI, es posible que desee suscribirse a este problema

Bueno, el caso de uso más obvio y urgente es que un atacante que haya irrumpido en su sistema de producción (cliente de copia de seguridad) no borre las copias de seguridad y sepa cómo usar restic desde allí.

Eso es casi imposible con solo usar criptografía asimétrica. El punto aquí es que el contenido antiguo de la copia de seguridad (no necesariamente los metadatos) no debería estar disponible para un atacante que haya entrado en un servidor.

La confidencialidad de los datos ( write-only ) se podría lograr para estos escenarios con la implementación de criptografía asimétrica.

La integridad de los datos es una bestia ligeramente diferente:
Si bien puede usar criptografía asimétrica (y un esquema de firma de una sola vez) para demostrar que un conjunto de datos determinado no ha sido alterado, no puede evitar su eliminación o reemplazo completo. Ese es un problema que requiere un sistema de almacenamiento que sea append-only (y read-only , para algunas partes).
Gracias al control de acceso discrecional que es relativamente sencillo de implementar en * nix con un backend como ssh (usando comandos como chmod , chown , chattr +i , chattr +a para configurar las políticas de acceso). append-only copias append-only ni siquiera necesitan estar encriptadas para evitar que los atacantes las lean (eso es parte de lo que hace rsyslog , por ejemplo), pero eso de repente convierte al servidor de copia de seguridad en un objetivo interesante, y La clonación de datos confidenciales en más dispositivos no mejora exactamente las probabilidades de mantener la confidencialidad de los datos .

Tener una criptografía asimétrica implementada permitiría a las personas hacer este tipo de copias de seguridad en sistemas tontos y que no son de confianza, una de las cosas que se trata restic (aparte de la deduplicación mejorada y todas las otras características agradables). Espero que esta elaboración aclare un poco mi punto.

Esto nos interesa para los dos casos descritos en https://github.com/restic/restic/issues/187#issuecomment -101974306. Me suscribo a este hilo para estar atento a esto.

Con respecto a la integridad de los datos : AFAIK, puede lograr el comportamiento de append-only en Amazon S3 solo otorgando a sus credenciales de IAM los permisos PutObject y GetObject , pero reteniendo los DeleteObject permiso.

Con respecto a la confidencialidad de los datos , quería mencionar un escenario de ataque que está habilitado por el uso de criptografía simétrica:
Si un atacante tiene control sobre la cuenta de usuario de una víctima en un momento en el que la víctima usa restic para realizar una copia de seguridad, puede:

• robar la llave restic la víctima
• robar las credenciales IAM de la víctima / inicio de sesión sftp / ...

El atacante puede borrar inmediatamente cualquier rastro de su ataque del sistema de la víctima, haciendo que la detección sea menos probable. Dado que ha robado la clave restic y las credenciales para el sistema de almacenamiento remoto, la víctima le entregará convenientemente cualquier información futura (respaldada): nuestro atacante solo necesita descargar y descifrar nuevas copias de respaldo del sistema de almacenamiento remoto de vez en cuando tiempo.

La criptografía asimétrica podría ayudar a prevenir esto al permitir que la víctima almacene la clave para restaurar copias de seguridad fuera de línea.

Con respecto a la integridad de los datos: AFAIK, puede lograr un comportamiento de solo adición en Amazon S3 otorgando solo a sus credenciales de IAM los permisos PutObject y GetObject, pero reteniendo el permiso DeleteObject.

Desafortunadamente, PutObject también le da privilegios para sobrescribir un archivo previamente cargado. Entonces, ¿tal vez no sea la integridad total de los datos?

La criptografía asimétrica también permitiría el uso de una clave OpenPGP como yubikey o algo así.

Hoy me di cuenta de que realmente no quiero soporte para el cifrado asimétrico en restic, sino soporte para NO almacenar la clave en el repositorio. Entiendo que usar el cifrado asimétrico de manera eficiente significaría que restic puede cargar nuevas copias de seguridad sin la capacidad de leer el repositorio, lo cual es bastante complicado.

Entonces, para mí, estaría bien si pudiera manejar la clave simétrica sin restic, y no se cargara de ninguna manera en el repositorio, sin importar qué KDF complejo se use.

Mi caso de uso es como administrador de sistemas para varios servidores.

Las copias de seguridad asimétricas son la única forma de proteger las copias de seguridad en el escenario de un compromiso del servidor donde un atacante destruye maliciosamente (o el ransomware cifra) todos los datos (incluidas las copias de seguridad).

Esto necesita soporte del lado del servidor a través de una capa de almacenamiento de solo agregar o un demonio de servidor similar a la forma en que rdiff-backup tiene la opción --restrict-update-only. Actualmente soluciono esto usando instantáneas de solo lectura del repositorio de respaldo en el servidor de respaldo (al que se accede a través de sftp).

(Quizás relevante): Sólo se puede agregar en Linux a través del indicador append-only en un directorio (que deshabilita la desvinculación) junto con el indicador immutable en los archivos. Los comandos responsables de configurar esos indicadores son chattr +a /path/to/directory y chattr +i /path/to/directory/myfile01 , respectivamente.

mi caso de uso aquí es el n. ° 533: copias de seguridad desatendidas. como se indica allí, la criptografía asimétrica es solo una de las formas de hacer esto, pero parece la primera solución obvia al problema.

En un escenario donde el repositorio está en un servidor remoto, solo los comandos locales en el repositorio deberían poder olvidarse / podarse.

La copia de seguridad restic debe conectarse con una clave única para ese sistema con privilegios de restauración / copia de seguridad únicamente.

En un escenario donde el repositorio está en un servidor remoto, solo los comandos locales en el repositorio deberían poder olvidarse / podarse.

Esto debe lograrse restringiendo el acceso para eliminar / modificar archivos en el nivel de repositorio. Creo que está fuera de alcance (y ni siquiera seguro) para que Restic administre estos permisos. Después de todo, alguien podría eliminar el repositorio o incluso las claves, haciendo que todo el repositorio sea inútil, independientemente de si el cliente resticuloso permitió esa acción.

En cuanto a evitar que los datos de respaldo sean destruidos por alguien que hackea el servidor: rest-server ha ganado recientemente un "modo de solo agregar" con PR https://github.com/restic/rest-server/pull/28 que previene exactamente esto.

Mi caso de uso es tener muchos sistemas respaldados en el mismo repositorio, obteniendo la ventaja de la deduplicación en todas esas máquinas, pero el compromiso de un sistema (y su script de respaldo) no permite que el atacante lea los respaldos de los otros sistemas.

La característica que estoy buscando es tener claves de "respaldo" que permitan a un sistema escribir (respaldo) y leer (restaurar) pero no puede hacer ningún administrador, (como podar, agregar claves o incluso ver la existencia de otros claves, (usuarios) o instantáneas no asociadas con $ backup_key). (Aunque un ataque de canal lateral podría ser posible comparando los tiempos de respaldo, no me importa si pueden determinar la existencia de datos, solo que no pueden ransomware mis datos y no pueden ver a otros usuarios). el titular de una clave de respaldo (única) para poder pasar su propia contraseña (s) hacia adelante. Entonces, a diferencia de la solicitud

Con esta función #ResticKillsRansomware

En general, las copias de seguridad orientadas a la extracción (a diferencia de las orientadas a la inserción) resuelven el ransomware, ¿verdad? :)

Posiblemente, pero eso luego da acceso remoto y agrega otro vector de ataque. Cómo lo diseñé, mi servidor de respaldo es para preservar datos y nunca debería tener acceso a mi entorno de producción. Demarcación clara de dominios funcionales.

Supongo que Restic no es la solución entonces, ya que está diseñado para operar directamente en repositorios de respaldo.

Tal vez podrías hacer algo con un servidor intermediario. Haga que sus máquinas de producción carguen archivos tar en un servidor, luego haga que otro sistema descargue los archivos tar, los extraiga y haga una copia de seguridad del contenido localmente. Cada lado solo tiene acceso al servidor intermedio. Eso sería bastante simple de hacer sin ninguna modificación en Restic. Probablemente también sería más seguro y más robusto, ya que cualquier error en un modo Restic de solo recepción podría hacer que las copias de seguridad sean vulnerables a los clientes de copia de seguridad comprometidos.

La característica que estoy buscando es tener claves de "respaldo" que permitan a un sistema escribir (respaldo) y leer (restaurar) pero no puede hacer ningún administrador, (como podar, agregar claves o incluso ver la existencia de otros claves, (usuarios) o instantáneas no asociadas con $ backup_key). (Aunque un ataque de canal lateral podría ser posible comparando los tiempos de respaldo, no me importa si pueden determinar la existencia de datos, solo que no pueden ransomware mis datos y no pueden ver a otros usuarios). el titular de una clave de respaldo (única) para poder pasar su propia contraseña (s) hacia adelante. Entonces, a diferencia de la solicitud de michbsd, podría administrar desde una máquina no local con una clave privilegiada. (Después de haber usado SELinux durante años, ahora soy un fanático de la granularidad de MAC) Gracias por leer. (Lo siento si esto debería tener su propio problema). Con esta función #ResticKillsRansomware

Si bien esto puede no ser exactamente lo que está pidiendo, puede echar un vistazo a rest-server . Tiene un modo de solo agregar que evita la eliminación y modificación de las copias de seguridad existentes.

Si bien esto puede no ser exactamente lo que está pidiendo, puede echar un vistazo a rest-server. Tiene un modo de solo agregar que evita la eliminación y modificación de las copias de seguridad existentes.

Ni siquiera me di cuenta de que existía. D:

Veo dos cosas estructurales (y modelos de atacantes ligeramente diferentes) que me gustaría dejar aquí.

Por el momento, restic (principalmente) interactúa con el almacenamiento "tonto" (local, s3, b2, gcs, azure, todo excepto el servidor REST con --append-only ). Puede guardar, enumerar, obtener y eliminar datos en un backend. Esto es necesario para una copia de seguridad, por lo que las credenciales necesarias para acceder al backend deben estar presentes. Por el lado positivo, restic puede usar casi cualquier almacenamiento, hay muy pocas restricciones. En el lado negativo, una vez que los atacantes obtienen acceso a un servidor, pueden extraer fácilmente las credenciales para acceder al backend y la contraseña restic, dándoles todas las posibilidades: descifrar datos históricos del repositorio, modificar datos, eliminar todo el repositorio.

Cuando agregamos criptografía asimétrica, la única diferencia para los atacantes en tal situación es que no pueden descifrar datos históricos del repositorio. Todo lo demás, especialmente eliminar todos los datos, sigue siendo posible. Entonces, "simplemente agregue criptografía asimétrica" ​​no es toda la historia.

La otra idea es no acceder al almacenamiento "tonto" directamente, sino indirectamente a través de una implementación de servidor personalizada. Hemos jugado con esta idea y hemos agregado la opción --append-only para el servidor REST , que puede verse como un "adaptador" para acceder al almacenamiento "tonto" en el disco duro local. Tengo varias ideas sobre cómo mejorar esa idea, no necesariamente con el servidor REST.

Por ejemplo, me gustaría definir un protocolo para un backend que se habla sobre un par de descriptores de archivo, por ejemplo, stdin / stdout. Luego podemos implementar esto en un programa que se ejecuta sobre SSH en una máquina remota, tal como lo hacemos para el backend sftp. La implementación del servidor puede decidir dónde almacenar los datos (local, s3, b2, lo que sea) y qué restricciones se aplican (por ejemplo, "solo agregar datos antiguos leídos o agregar nuevos datos", sin la capacidad de eliminar nada más que quizás bloquear archivos. podría, por ejemplo, iniciarse a través de ForceCommand al iniciar sesión a través de SSH con una cuenta de usuario o clave SSH en particular.

Tener un almacenamiento "no tonto" por sí solo no ayudará a que los atacantes lean datos del repositorio (al menos no sin cambiar el formato del repositorio), pero evitará eliminar todos los datos en el repositorio.

Entonces, en conclusión, para defendernos mejor contra los atacantes que se apoderan de un servidor que usa restic para las copias de seguridad, creo que necesitaríamos implementar ambos (almacenamiento no tonto y criptografía asimétrica). Ese es un objetivo a largo plazo :)

Voy a copiar este texto al primer comentario de este número para que sea más fácil de encontrar.

sí, reflexionando más sobre esto, estoy de acuerdo en que la criptografía asimétrica no es tan útil para defenderse de las adquisiciones, es más útil para las copias de seguridad desatendidas (# 533).

Tener un protocolo de comunicación nativo podría ser útil, pero no estoy seguro de lo que obtendrá con el servidor REST actual. ¿Podría ampliarlo? attic / borg fue por ese camino: hay un protocolo "propietario" de cliente a servidor (como en, específico de borg) allí y es posible implementar algunas restricciones para los clientes. y sí, esto se basa en ForceCommand y las banderas restringidas "borg serve" ... hay algunas notas relevantes en los documentos de borg sobre esto y los inconvenientes que debe tener en cuenta.

y, por supuesto, la forma más natural de proteger las copias de seguridad de un cliente comprometido es simplemente no permitir que el cliente realice las copias de seguridad por sí mismo, sino que el servidor extraiga archivos de las copias de seguridad, "al estilo bacula" ("Viene en el noche y chupa la esencia de tus ordenadores ”, para quienes recuerdan esa pegadiza frase). Tampoco parece haber una forma elegante o bien documentada de hacer esto en borg, las preguntas frecuentes apuntan a https://github.com/borgbackup/borg/issues/900 como una discusión sobre el tema. aquí, esto se rastrea en el n. ° 299, que aún no se había mencionado aquí.

En pocas palabras, mantendría el enfoque del soporte criptográfico asimétrico simple: facilitaría el almacenamiento de claves fuera del sitio y las copias de seguridad automatizadas. Hay otras formas de asegurar a los clientes comprometidos, y creo que el soporte de extracción es la más interesante. de hecho, en mis soluciones de copia de seguridad óptimas, tengo todos los clientes que empujan a sus copias de seguridad a un servidor central, a continuación, un servidor fuera del sitio tirando desde el servidor de copia de seguridad principal. Por aquí:

1. el servidor de respaldo no necesita acceso de root en todas las máquinas
2. Sin embargo, el compromiso de una máquina aún es recuperable, incluso si pueden alterar las copias de seguridad.

De hecho, me parece extraño que este problema se haya convertido en "quiero protegerme contra la adquisición del cliente"; tal vez estemos confundiendo la solución con el problema aquí. :)

Hola,

Parece que este problema no se trata solo de copias de seguridad de cifrado asimétricas, sino más bien de diferentes vectores de ataque.
No leí el código, así que realmente tengo una pregunta ingenua, pero mi caso de uso se trata principalmente de poder hacer una copia de seguridad de los datos sin revelar la clave secreta (mediante el uso de la clave pública de una clave privada fuera de línea del propietario de la copia de seguridad). Para ese caso de uso, ¿es fácil de implementar?

Mi comprensión sobre el tema es que en este momento todos los blobs están encriptados con la misma clave y funciona muy bien.
Si usáramos criptografía asimétrica como funciona OpenPGP, cada instantánea realizada generaría una clave simétrica encriptada con la clave pública y la agregaría al repositorio. Pero supongo que el problema es que para poder descubrir qué desduplicar y qué respaldar, debería poder leer la información primero, por lo tanto, también necesitaría la clave privada. ¿Está bien?
Si ese es el caso, ¿podría alguna prueba de conocimiento cero ayudar en ese sentido?

@dolanor, por favor, no agregue nuevos casos de uso o preguntas a este problema, use el foro para preguntas. Además, es demasiado pronto para hablar sobre los detalles de implementación.

Actualicé el resumen en la primera publicación. Mientras tanto, se ha agregado el backend rclone , que se puede usar como un "adaptador" como se describe anteriormente, y se puede acceder, por ejemplo, a través de SSH.

En el lado negativo, una vez que los atacantes obtienen acceso a un servidor, pueden extraer fácilmente las credenciales para acceder al backend y la contraseña restic.

Espero que esto sea un error tipográfico: ustedes men el material del archivo de claves cifrado aquí, ¿no? Es de esperar que un atacante que obtenga acceso al servidor no tenga acceso a la contraseña de texto sin formato. Lo peor que pueden hacer es intentar usar la fuerza bruta o adivinar la "contraseña de usuario" que se utiliza para descifrar las claves maestras de cifrado y autenticación del repositorio.

Si eso es correcto, le recomiendo encarecidamente que cambie el resumen nuevamente para aclarar, porque seguro que se ve mal cuando se indica de esa manera. :)

Es de esperar que un atacante que obtenga acceso al servidor no tenga acceso a la contraseña de texto sin formato. Lo peor que pueden hacer es intentar usar la fuerza bruta o adivinar la "contraseña de usuario" que se utiliza para descifrar las claves maestras de cifrado y autenticación del repositorio.

Supongo que depende del escenario exacto: si está ingresando manualmente la contraseña, correcto. Si está haciendo copias de seguridad automáticas programadas, por otro lado, la "contraseña de usuario" deberá almacenarse en algún lugar del servidor.

Y, por supuesto, un atacante podría cambiar el binario de Restic por uno que filtre la contraseña ingresada y esperar a que usted la ingrese. No puedes confiar en un sistema comprometido.

la "contraseña de usuario" deberá almacenarse en algún lugar del servidor.

por "servidor" ¿te refieres a "la máquina en la que estamos trabajando en la que guardamos los datos" o "la máquina que recibe / almacena los datos de la copia de seguridad"?

es bastante ambiguo, y la fuente de mi preocupación: no me importa que el cliente de respaldo (la máquina de la que estamos respaldando que se está ejecutando restic) tenga la contraseña en texto sin cifrar: todo el conjunto de datos está allí de todos modos, por lo que si está comprometido, los datos son comprometido de todos modos. ¡Pero espero que el servidor de respaldo no tenga acceso al texto sin cifrar!

por "servidor" ¿te refieres a "la máquina en la que estamos trabajando en la que guardamos los datos" o "la máquina que recibe / almacena los datos de la copia de seguridad"?

La máquina en la que estamos ejecutando está inactiva en la que guardamos los datos.

Veo tu punto, tienes razón, es ambiguo. Mi comprensión de todo lo que sé sobre el modelo de Restic es la misma que la suya, estoy bastante seguro de eso, pero no puedo darle la confirmación definitiva que desea.

El resumen menciona la opción --append-only para el servidor REST. Quizás ese debería seguir siendo el único método recomendado oficialmente de copia de seguridad de solo anexión, pero podría ser bueno documentar qué archivos en Restic deben ser modificables para el funcionamiento normal para ayudar a descubrir cómo configurar otros enfoques.

Creo que restic backup funcionaría bien si data , index , keys y snapshots permitieran la creación de archivos pero no la modificación o eliminación ( y config también estaba protegido). Sin embargo, creo que locks necesitaría permitir la eliminación para que el repositorio no se bloquee permanentemente. Además, algunas implementaciones de solo anexión (como el atributo para sistemas de archivos ext4 y xfs) no son recursivas, por lo que los 256 subdirectorios de dos caracteres de data deberían generarse previamente y luego el atributo debería se fije en ellos.

Algunos backends como S3 no admiten la función de adición, pero sí admiten el control de versiones de objetos, lo que podría lograr el mismo efecto. Sin embargo, esto requiere una revisión cuidadosa del modelo de control de acceso. Por ejemplo, B2 tiene reglas de ciclo de vida que permiten el control de versiones de objetos, pero la clave API necesaria para hacer una copia de seguridad en B2 tiene la capacidad de modificar las reglas del ciclo de vida (B2 todavía no tiene mucho de un sistema de permisos).

Aparte: puede que me esté perdiendo algo, pero si el cifrado asimétrico solo protege los datos históricos de un atacante que ha comprometido al cliente, parece una prioridad baja. Sería bueno tenerlos, pero en la mayoría de los casos los datos actuales son más valiosos que las versiones anteriores (aunque a veces se hace una copia de seguridad, se borra pero no se purga accidentalmente de algo valioso).

@willsALMANJ buenas observaciones. Para S3, me pregunto si las versiones de objeción podrían grabarse para permitir obtener una vista coherente de los blobs necesarios para restaurar una instantánea determinada (aunque puede validarlos en función de su contenido, por lo que no es muy importante).

Re: tu último párrafo:

• El principal beneficio del cifrado asimétrico, además del escenario de "descifrar elementos históricos" que mencionaste, es poder almacenar copias de seguridad de varias máquinas independientes en el mismo repositorio de copias de seguridad sin tener que proporcionar claves individuales (lo que requiere almacenar la clave de copia de seguridad en algún lugar cada vez que instalar una nueva máquina cliente). Si usa una clave compartida, obtiene el molesto escenario de amenaza en el que el cliente1 puede leer los datos del cliente2, lo cual no es ideal.

@ fd0 Creo que tengo un esquema decente para el cifrado asimétrico usando direccionamiento HMAC con secretos compartidos derivados. También algunas ideas sobre la recolección de basura del lado del servidor sin filtrar datos, no estoy seguro si está interesado, pero si lo está, me interesaría hablar al respecto.

No sé si me pierdo algo aquí, pero estoy ejecutando restic correctamente con esta configuración de política en el almacenamiento S3. No evita que un atacante lea los datos, pero le impide eliminarlos.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::kvasir"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::backup/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::backup/locks/*"
    }
  ]
}

Los comandos de podar / olvidar se ejecutan desde un dispositivo confiable que tiene permisos de escritura. También creo dos claves en cada repositorio restic. Uno para el servidor y otro para el dispositivo de confianza, de modo que el dispositivo de confianza pueda bloquear a un atacante (pero el atacante no puede porque no puede eliminar en las claves / *).

Editar: Lo siento, pasé por alto que esto ya se ha discutido. No quería secuestrar este hilo.
PutObject es realmente capaz de sobrescribir objetos, por lo que esta no es una solución para proteger las copias de seguridad .

@freswa No soy un experto en S3, por lo que no estoy seguro de que esto sea correcto, pero el punto que se mencionó anteriormente en esta discusión es que el permiso PutObject se puede usar para sobrescribir sus datos, lo cual es igual de malo como eliminarlo. En mi publicación anterior, noté que podría solucionar este problema utilizando el control de versiones de objetos (no le dé acceso al sistema de respaldo para eliminar versiones).

@andrewchambers Estoy un poco abrumado con otras cosas, ¡hablemos de tus ideas una vez que logremos implementar esto! Sí, estoy interesado ;)

Por lo tanto, este problema se trata de implementar (eventualmente) copias de seguridad asimétricas, no de la configuración de acceso para el almacenamiento de backend. ¡Gracias! :)

@ fd0 Con suerte, esto explica lo que quise decir https://packnback.github.io/blog/dedup_and_encryption/

@andrewchambers : en caso de que aún no se haya encontrado con el problema de solo escritura (que mencionó en su sitio), es https://github.com/ncw/rclone/issues/2499.

@andrewchambers gracias por escribirlo, estoy muy interesado en cómo se ve la implementación real. La publicación del blog dejó algunas partes interesantes abiertas :)

Me gusta que haya otro competidor en el espacio de los programas de copia de seguridad de software gratuitos, ¡dar a los usuarios más opciones siempre es genial!

Por lo tanto, se puede hacer un paralelo interesante con los dos mecanismos de cifrado del repositorio de git.

Por un lado, tiene git-crypt : utiliza filtros git

Por otro lado, tiene git-remote-gcrypt : que usa el protocolo de ayuda remota git para encriptar todo lo que se envía al servidor. Pero eso es muy ineficiente, porque todo el repositorio se vuelve a cifrar en cada ejecución, debido a la forma en que funcionan los controles remotos especiales.

Ahora, esos son desafíos de implementación específicos de git, pero creo que se asignan bien a los problemas que podría tener aquí. Tal vez estoy totalmente fuera de mi alcance aquí y este paralelo es irrelevante, pero pensé que podría ser de interés aquí ...

Aparte, hay un término medio que actualmente podría implementarse (probablemente) con bastante facilidad: permitir que las claves se almacenen fuera del repositorio.

Uno de los vectores de ataque que se está abordando es que el atacante tiene en sus manos una contraseña de clave y luego (dado que las claves se almacenan en el repositorio) puede descifrar una clave con facilidad.

¿Qué pasa si permitimos la especificación de un directorio de claves separado, donde se almacenan los archivos de claves? Este directorio podría almacenarse localmente en cada máquina que necesite hacer copias de seguridad, y podría respaldarse a sí mismo en un proveedor de nube diferente, o incluso en un código QR (~ 500 bytes es bastante pequeño para ser codificado en QR) para almacenamiento fuera de línea en frío. en una caja de seguridad, por ejemplo.

Si las claves cifradas nunca tocan a un proveedor de la nube, el vector de ataque desaparece por completo. Las claves tendrían que ser comprometidas desde las instalaciones físicas o exfiltradas con malware, por ejemplo.

Esto _ ya se puede hacer en Restic_ si se mantiene una copia local del repositorio; simplemente excluya el directorio de claves para que no se sincronice con el control remoto que no es de confianza al ejecutar rclone. Esto _no_ se puede hacer si no hay una copia local y Restic interactúa directamente con el control remoto que no es de confianza.

Creo que deberíamos aplicar el principio de responsabilidad única y dividir las cosas en 2 tareas:

1. Mantenga los datos a salvo del descifrado.
2. Mantenga los datos a salvo de acciones de eliminación no autorizadas.

Son dos aspectos diferentes de la seguridad de los datos. Técnicamente, no tienen que depender el uno del otro.

Para (1), obviamente podemos "simplemente agregar soporte de cifrado asimétrico". Para (2), creo que hay muchas soluciones posibles (por ejemplo, como se mencionó anteriormente, configuración de S3 solo para agregar).