> Pregunta 1: la máquina de control
En Userify (divulgación completa: en realidad ofrecemos software para administrar claves ssh), nos ocupamos de esto todo el tiempo, ya que también tenemos el mayor almacén de claves SSH. En general, recomendamos la instalación local en lugar de usar la nube, ya que tiene un mayor control, reduce su área de superficie, realmente puede bloquearlo en redes confiables recién conocidas.
Lo importante para recordar es que, en un sistema correctamente construido como este, realmente no debería haber secretos significativos que puedan ser filtrados a un atacante. Si alguien conduce una carretilla elevadora a su centro de datos y se va con su servidor, no obtendrá mucho, excepto algunas contraseñas con muchos hash, probablemente algunos archivos muy encriptados y algunas claves públicas sin sus correspondientes claves privadas. En otras palabras, no tanto.
Como usted señala, los vectores de amenazas reales aquí son lo que sucede si un atacante obtiene el control de esa máquina y la usa para implementar sus propias cuentas de usuario y claves (públicas). Este es un riesgo para prácticamente todas las plataformas en la nube (ej .: Linode). Debería concentrarse más en evitar el acceso al plano de control, lo que significa minimizar la superficie de ataque (solo exponer algunos puertos y bloquear esos puertos tanto como sea posible) y preferiblemente usar un software que esté reforzado contra la escalada de privilegios y varios ataques ( Inyección SQL, XSS, CSRF, etc.) Habilite el acceso 2FA / MFA al plano de control y concéntrese en bloquear ese plano de control tanto como sea posible.
Entonces, ¿es mejor tener una máquina de control dedicada en el centro de datos o una máquina de control remoto (como mi computadora portátil conectada remotamente al centro de datos)?
Es definitivamente mejor tener una máquina de control dedicado en un centro de datos seguro, porque se puede aislar y bloqueo hacia abajo para evitar / minimizar el riesgo de robo o acceso no autorizado.
Si la mejor práctica es usar mi computadora portátil (que podría ser robada, por supuesto, pero podría tener mis claves públicas guardadas de forma segura en línea en la nube o sin conexión en un dispositivo cifrado portátil), ¿qué pasa si necesito usar algunas interfaces web con ¿Ansible, como Ansible Tower, Semaphore, Rundeck o Foreman que debe instalarse en una máquina centralizada en el centro de datos?
No necesita ejecutar NINGUNA interfaz web o plano de control secundario para administrar sus claves (incluso Userify) hasta que sea lo suficientemente grande como para comenzar a meterse en problemas de administración debido a un mayor número de usuarios y diferentes niveles de autorización entre servidores o necesita más mano para sus usuarios que pueden no tener conocimiento o acceso a Ansible para actualizar claves. Userify al principio no era mucho más que un montón de scripts de shell (¡hoy serían Ansible, probablemente!) Y no hay nada de malo en eso, hasta que comience a necesitar control de administración adicional y formas fáciles para que las personas administren / roten sus llaves propias (¡Por supuesto, eche un vistazo a Userify si llega a ese punto!)
¿Cómo asegurarlo y evitar que se convierta en un "único punto de ataque"?
Bueno, por supuesto, revise todos los recursos en la red para bloquear las cosas, pero lo más importante es comenzar con una base segura:
1. Diseñe su solución teniendo en cuenta la seguridad desde el principio. Elija la tecnología (es decir, la base de datos o los idiomas) que tradicionalmente han tenido menos problemas y luego codifique con seguridad desde el principio. Desinfecte todos los datos entrantes, incluso de usuarios confiables. La paranoia es una virtud.
2. Eventualmente, todo se rompe. Minimice el daño cuando eso ocurra: como ya señaló, intente minimizar el manejo de material secreto.
3. Mantenlo simple. No haga las últimas cosas exóticas a menos que esté seguro de que aumentará su seguridad de manera medible y demostrable. Por ejemplo, seleccionamos X25519 / NaCl (libsodium) sobre AES para nuestra capa de encriptación (encriptamos todo, en reposo y en movimiento), porque fue originalmente diseñado y escrito por alguien en quien confiamos (DJB et al) y fue revisado por world investigadores reconocidos como Schneier y el equipo de seguridad de Google. Use cosas que tienden a la simplicidad si son más nuevas, ya que la simplicidad hace que sea más difícil ocultar errores profundos.
4. Cumplir con los estándares de seguridad. Incluso si no cae en un régimen de seguridad como PCI o la Regla de Seguridad de HIPAA, lea esos estándares y descubra cómo cumplirlos o al menos controles compensatorios muy fuertes. Esto ayudará a garantizar que realmente cumpla con las 'mejores prácticas'.
5. Traiga pruebas de penetración externas / independientes y ejecute recompensas de errores para asegurarse de que está siguiendo esas mejores prácticas de forma continua. Todo se ve muy bien hasta que algunas personas inteligentes y altamente motivadas lo golpean ... una vez que haya terminado, tendrá mucha confianza en su solución.
Pregunta 2: las claves SSH ¿Cuál es la mejor opción? Deje que Ansible use el usuario raíz (con su clave pública guardada en ~/.ssh/authorized_keys/ deje que el usuario de Ansible ejecute todos los comandos a través de sudo especificando una contraseña (que es única para cada administrador de sistemas) que usa Ansible para controlar esos servidores)
Intente evitar usar contraseñas en los servidores, incluso para sudo. Se trata de secretos y, en última instancia, socavará su seguridad (realmente no puede variar esa contraseña de sudo entre máquinas muy fácilmente, tiene que almacenarla en algún lugar, la contraseña significa que realmente no puede hacer la automatización de servidor a servidor, que es exactamente de qué se trata. Además, si deja SSH en sus valores predeterminados, esas contraseñas pueden ser forzadas, lo que hace que las claves no tengan sentido. Además, evite el uso del usuario root para cualquier propósito, y especialmente el inicio de sesión remoto.
Cree un usuario sin privilegios dedicado para Ansible con acceso a sudo / permita que el usuario de Ansible ejecute todos los comandos a través de sudo sin especificar ninguna contraseña
Exactamente. Un usuario sin privilegios que puede auditar de nuevo a ansible, con roles de sudo. Idealmente, cree un usuario estándar dedicado a las comunicaciones de servidor a servidor / ansible con acceso a sudo (sin contraseña).
... NB, si estuviera utilizando Userify, la forma en que sugeriría hacerlo sería crear un usuario Userify para ansible (también puede dividir esto por proyecto o incluso grupo de servidores si tiene varias máquinas de control ansible), generar una clave SSH en el servidor de control y proporcione su clave pública en su página de perfil de Userify. (Este cuadro de texto se convierte esencialmente /home/ansible/.ssh/authorized_keys). Debe mantener la cuenta del sistema ansible separada de otras cuentas del sistema de servidor a servidor, como una cuenta de respaldo remota, administración secreta, etc. Luego invite a sus humanos y ellos también podrán crear y administrar sus propias claves y todo permanecerá separado. Pero, al igual que al bloquear un servidor de control Ansible, intente bloquear su servidor Userify (o cualquier solución que implemente) de la misma manera.
alguna otra pista?
Creo que definitivamente está haciendo esto de la manera correcta y haciendo las preguntas correctas. Si desea hablar sobre este tipo de cosas, envíeme un correo electrónico (primer punto, apellido en userify) y estaré encantado de tener una conversación, sin importar la dirección que elija. ¡Buena suerte!