Por fin después de tanto trabajar ya dimos con la contestación de este rompecabezas que algunos los lectores de este espacio han tenido. Si tienes algún dato que aportar no dejes de aportar tu información.
Solución:
Solución 1:
El host bastión (el centro de control ansible) pertenece a una subred separada. No debería ser directamente accesible desde el exterior, no debería ser directamente accesible de los servidores gestionados!
Su computadora portátil es el dispositivo menos seguro de todos. Un correo estúpido, una vulnerabilidad flash estúpida, un Wifi invitado estúpido y se estropea.
Para los servidores, no permita el acceso de root a través de ssh en absoluto. Muchas auditorías se burlan de esto.
Para ansible, permita que cada administrador use su propia cuenta personal en cada servidor de destino y permítales sudo con contraseñas. De esta forma, no se comparte ninguna contraseña entre dos personas. Puede comprobar quién hizo qué en cada servidor. Depende de usted si las cuentas personales permiten el inicio de sesión con contraseña, solo con clave ssh o si requieren ambas.
Para aclarar ansible no requiere usar un solo nombre de inicio de sesión de destino. Cada administrador podría y debería tener un nombre de inicio de sesión de destino personal.
Una nota al margen: Trate de nunca crear una cuenta llamada alguna palabra (como “ansible” o “admin” o “clúster” o “administración” u “operador”) si tiene una contraseña. El único buen nombre para una cuenta que tiene contraseña es el nombre de un ser humano, como “jkowalski”. Solo un ser humano puede ser responsable de las acciones realizadas a través de la cuenta y responsable de asegurar indebidamente su contraseña, “ansible” no puede.
Solucion 2:
> 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 ejecutamos el almacén de claves SSH más grande. 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 solo en redes conocidas de confianza.
Lo importante a recordar es que, en un sistema correctamente construido como este, Realmente no debería haber ningún secreto importante que se pueda filtrar 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 muy codificadas, probablemente algunos archivos muy cifrados y algunas claves públicas sin sus correspondientes claves privadas. En otras palabras, no tanto.
Como señala, los vectores de amenaza reales aquí son ¿Qué sucede si un atacante obtiene el control de esa máquina? y lo utiliza para implementar sus propias cuentas de usuario y claves (públicas). Este es un riesgo para prácticamente todas las plataformas en la nube (por ejemplo, Linode). Debe concentrarse más en prevenir 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 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 dedicada en un centro de datos seguro, porque puede aislarla y bloquearla para prevenir / 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 manera segura en línea en la nube o fuera de línea 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 es necesario 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 tener problemas de administración debido a una mayor cantidad de usuarios y diferentes niveles de autorización en los servidores o que necesite un control adicional 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 comienzas a necesitar un control de administración adicional y formas fáciles para que las personas administren / roten sus propias llaves. (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, consulte todos los recursos en la red para bloquear las cosas, pero lo más importante comience con una base segura:
1. Diseñe su solución teniendo en cuenta la seguridad desde el principio. Elija tecnología (es decir, base de datos o lenguajes) que tradicionalmente hayan tenido menos problemas y luego codifique con la seguridad en primer plano. Desinfecte todos los datos entrantes, incluso los de usuarios de confianza. La paranoia es una virtud.
2. Eventualmente, todo se rompe. Minimice el daño cuando eso ocurra: como ya señaló, trate de minimizar el manejo de material secreto.
3. Hágalo 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 cifrado (ciframos todo, en reposo y en movimiento), porque originalmente fue diseñado y escrito por alguien en quien confiamos (DJB et al) y fue revisado por world -investigadores de renombre como Schneier y el equipo de seguridad de Google. Use cosas que tiendan 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 HIPAA, lea esos estándares y descubra cómo cumplirlos o al menos controles de compensación muy estrictos. Esto ayudará a garantizar que realmente cumpla con las ‘mejores prácticas’.
5. Realice 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 golpeen … una vez que esté terminado, tendrá mucha confianza en su solución.
Pregunta 2: las claves SSH ¿Cuál es la mejor opción: dejar que Ansible use el usuario root (con su clave pública guardada en
~/.ssh/authorized_keys/ dejar que el usuario de Ansible ejecute todos los comandos a través de sudo especificando una contraseña (que es única y debe ser conocida por cada administrador de sistemas que use Ansible para controlar esos servidores)
Trate de evitar el uso de contraseñas en los servidores, incluso para sudo. Eso es lidiar con secretos y, en última instancia, socavará su seguridad (realmente no puede variar esa contraseña de sudo entre máquinas con mucha facilidad, debe almacenarla en algún lugar, la contraseña significa que realmente no puede realizar 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 a Ansible con acceso sudo / deje 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 a ansible, con roles sudo. Idealmente, cree un usuario estándar dedicado a las comunicaciones de servidor a servidor / ansible con acceso sudo (sin contraseña).
… NB, si estuviera usando 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 Userify. (Este cuadro de texto se convierte esencialmente en /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 pueden crear y administrar sus propias claves y todo permanecerá separado. Pero, al igual que con el bloqueo de un servidor de control de Ansible, intente bloquear su servidor Userify (o cualquier solución que implemente) de la misma manera.
¿Alguna otra pista?
Creo que definitivamente estás haciendo esto de la manera correcta y haciendo las preguntas correctas. Si desea discutir este tipo de cosas, envíeme un correo electrónico (primer punto, apellido en userify) y me complacerá tener una charla sin importar la dirección que finalmente siga. ¡Buena suerte!
Solución 3:
Respuesta 1: la máquina de control
Un poco de ambos, puede usar su computadora portátil para conectarse a servidores a través de un host bastión. algo como:
Host private1
IdentityFile ~/.ssh/rsa_private_key
ProxyCommand ssh [email protected] -W %h:%p
Host bastion
IdentityFile ~/.ssh/bastion_rsa_key
Más sobre los hosts bastión
Donde tiene una clave para el servidor bastión y luego una clave separada para el host detrás de él. (personalmente usaría gpg-agent / ssh-agent)
Respuesta 2: Autenticación
No estoy seguro de en qué se diferencian las mejores prácticas específicas de “ansible” de otras mejores prácticas de conexión ssh. Pero no, desea ejecutar ansible como usted mismo, no como una cuenta de servicio y no como una cuenta de root.
Una combinación de las siguientes autenticaciones:
- Claves ssh por usuario (almacenadas centralmente)
- Autenticación Kerberos
- Autenticación multifactor (Yubikeys, Duo, GoogleAuth, etc.)
- Fail2ban / bloqueo de cuenta
- registro y alertas centralizados
- autenticación centralizada (FreeIPA, LDAP, IdM, MS AD)
- firmar claves ssh con un internal-ca
Otros pensamientos:
- Almacene siempre secretos / información privada en ansible-vault.
- Ansible no requiere que SUDO / Root se ejecute, a menos que lo que esté haciendo requiera sudo / root.
- Ansible puede elevar los permisos de muchas formas diferentes
Por último, no mencionaste nada sobre Windows. Así que solo puedo asumir que no estás usando esto. Sin embargo, en este caso, usaría la opción de delegado para que su computadora portátil use el host bastión (delegate_to: bastion.hostname.fqdn) y kerberos / winrm https con tickets de kerberos.
En caso de que se lo haya perdido, las mejores prácticas para la informática, nunca hagas nada como root, siempre usa cuentas con nombre