Gateway de acceso SSH para muchos servidores

Gestión de múltiples servidores, más de 90 actualmente con 3 devops a través de Ansible. Todo funciona muy bien, sin embargo, hay un gran problema de seguridad en este momento. Cada devop está utilizando su propia clave ssh local para obtener acceso directamente a los servidores. Cada devop usa una computadora portátil, y cada computadora portátil podría verse comprometida, lo que abriría toda la red de servidores de productos hasta un ataque.

Estoy buscando una solución para administrar el acceso de forma centralizada y, por lo tanto, bloquear el acceso a cualquier clave. No es diferente a cómo se agregan las claves a Bitbucket o Github.

Supongo que la solución sería un túnel desde una máquina, la puerta de enlace, al servidor de productos deseado ... al pasar la puerta de enlace, la solicitud tomaría una nueva clave y la usaría para obtener acceso a la unidad. servidor. El resultado sería que podemos eliminar el acceso de manera rápida y eficiente para cualquier devop en cuestión de segundos simplemente negando el acceso a la puerta de enlace.

¿Es esta buena lógica? ¿Alguien ha visto una solución por ahí para frustrar este problema?

Eso es demasiado complicado (verificar si una clave tiene acceso a un servidor específico). Use el servidor de puerta de enlace como host de salto que acepta todas las claves válidas (pero puede eliminar fácilmente el acceso a una clave específica que elimina el acceso a todos los servidores) y luego agregue solo las claves permitidas a cada servidor respectivo. Después de eso, asegúrese de que puede alcanzar el puerto SSH de cada servidor solo a través del host de salto.

Este es el enfoque estándar.

Los ingenieros no deben ejecutar ansible directamente desde su computadora portátil, a menos que este sea un entorno de desarrollo / prueba.

En su lugar, tenga un servidor central que extraiga los runbooks de git. Esto permite controles adicionales (cuatro ojos, revisión de código).

Combine esto con un bastión o host de salto para restringir aún más el acceso.

Netflix implementó su configuración y lanzó un software gratuito para ayudar a esa situación.

Vea este video https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-access o esta presentación en https://speakerdeck.com/rlewis/how-netflix-gives- All-its-ingenieros-ssh-access-to-instance-running-in-production con el punto central:

Revisaremos nuestra arquitectura de bastión SSH, que en esencia utiliza SSO para autenticar a los ingenieros, y luego emite credenciales por usuario con certificados de corta duración para la autenticación SSH del bastión en una instancia. Estas credenciales de corta duración reducen el riesgo asociado a su pérdida. Cubriremos cómo este enfoque nos permite auditar y alertar automáticamente después del hecho, en lugar de reducir la velocidad de los ingenieros antes de otorgar acceso.

Su software está disponible aquí: https://github.com/Netflix/bless

Algunas ideas interesantes incluso si no implementa su solución completa:

• usan certificados SSH en lugar de solo claves; puede poner muchos más metadatos en el certificado, lo que permite muchas restricciones por requisitos y también permite auditorías más simples
• usando la validez de certificados a muy corto plazo (como 5 minutos) (las sesiones SSH permanecen abiertas incluso después de que expire el certificado)
• usar 2FA para dificultar también las secuencias de comandos y obligar a los desarrolladores a encontrar otras soluciones
• un submódulo específico, fuera de su infraestructura y debidamente asegurado a través de los mecanismos de seguridad ofrecidos por la nube donde se ejecuta, maneja la generación de certificados dinámicamente para que cada desarrollador pueda acceder a cualquier host

OneIdentity (ex-Balabit) SPS es exactamente lo que necesita en este escenario. Con este dispositivo, puede administrar las identidades de los usuarios en prácticamente cualquier máquina, rastrear el comportamiento del usuario, monitorear y alertar, e indexar lo que los usuarios hagan para revisiones posteriores.

Mi sugerencia es no permitir el acceso SSH desde las máquinas de los usuarios.

En cambio deberías

1. Alojar libros de jugadas en Git.
2. Convierta el "servidor de acceso" en un servidor Jenkins.
3. Grant solo necesitaba el acceso de Jenkins a los usuarios devops.
4. Ejecute juegos de Ansible en Jenkins sobre trabajos de compilación a través de HTTP.
5. Como medida de seguridad adicional, desactive la CLI de Jenkins si es necesario.

El modelo de ejecución de muestra,

1. Complemento de Jenkins Ansible: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

O

2. Shell clásico - Ejecutar tipo de trabajo. Agregue sus pasos de compilación manualmente, incluido el pago de git.

Si está limitado con los recursos del servidor, el mismo servidor Jenkins también puede alojar Git (scm-manager), aunque existe un riesgo de seguridad adicional si una de las máquinas del desarrollador está infectada. Es posible que pueda mitigar esto desconectando el servidor Jenkins de Internet y resolviendo las dependencias Ansible localmente.