Administrar el acceso de la clave SSH a los servidores de AWS detrás del bastión

Question

Administrar el acceso de la clave SSH a los servidores de AWS detrás del bastión

#1 de Jesse Keilson (1 votos)
#2 de Alain O'Dea (1 votos)
#3 de xref (1 votos)

2

Actualmente tengo una configuración de AWS con 3 VPC, una para el bastión, luego una Dev y una VPC Prod, las dos últimas solo son accesibles mediante SSH a través del bastión (diseño de esta gran guía ). Estoy buscando la mejor manera de administrar que entre 3-5 usuarios accedan a los sistemas. A largo plazo espero tener automatización y registro externo en un lugar donde nadie tenga SSH, pero por ahora, es SSH.

Después de leer las ideas de esta pregunta sobre la administración de claves ssh Estoy pensando en configurar mi acceso de AWS de la siguiente manera:

2 cuentas en bastion, sudoable @ bastion y no sudoable @ bastion. los administradores de sistemas pasan por uno, los desarrolladores por el otro. (los desarrolladores no tienen ninguna razón para hacer nada más que pasar por el bastión)
el archivo authorized_keys en cada cuenta de bastión contiene la clave pública de los administradores de sistemas o devs, respectivamente
Cada una de las instancias de Dev / Prod VPC tiene una sola cuenta sudoable: @ devVPC y @ prodVPC.
Los desarrolladores obtienen la clave privada para las instancias @ devVPC, los administradores de sistemas obtienen la clave privada para ambas instancias de VPC.
Si alguien se une / abandona a la empresa, su clave de publicación se agrega / elimina del archivo correcto authorized_keys en el bastión.
Dado que las instancias de devVPC / prodVPC están detrás del bastión, aunque el trabajador que se fue puede tener la clave privada de esos servidores, no hay forma de acceder a ellos ya que el bastión no les permitirá pasar.

Creo que esto debería evitar que tenga que administrar cuentas de usuario / usuario individuales en cada instancia. Sin entrar en LDAP y las cosas que no querría a largo plazo de todos modos (nuevamente, espero que nadie necesite SSH en los servidores de AWS en el futuro), ¿parece esto una configuración legítima / segura para un equipo pequeño?

No lo he usado, pero también he visto AWS OpsWorks mencionado como un método para controlar SSH ¿llaves? ¿Mi situación suena como un buen caso de uso para ella?

ssh

pregunta xref 27.08.2015 - 19:36

fuente

3 respuestas

Lea otras preguntas en las etiquetas ssh

Correo electrónico hecho en Alemania. ¿Mejor que los tradicionales como Google o Yahoo? [cerrado] La cotización XSS reflejada no está codificada

score 1 · Answer 1

Hay un gran agujero en esto, y es que es difícil probar quién hizo qué acción con las cuentas compartidas. No imposible, solo mas dificil. Además, la clave privada compartida es una mala idea de una estrategia de defensa en profundidad. Puede resolver ambos problemas administrando las cuentas individualmente, lo que genera una mayor sobrecarga de administración, pero no debería ser significativo con solo 5 usuarios.

No puedo comentar en profundidad sobre la idea de opsworks, no la he usado. Basado en una lectura rápida del documento que proporcionó, realmente parece que configura cuentas en sus instancias y luego el archivo authorized_keys, que es una tarea bastante pequeña. También debe pasar el tiempo configurando a todos sus usuarios con cuentas IAM de AWS, lo que no parece ser una buena compensación.

score 1 · Answer 2

1

Use claves SSH separadas para cada usuario y cuentas de usuario separadas para cada sistema.

Creamos usuarios, les asignamos roles y habilitamos el acceso a la clave de publicación mediante el libro de cocina usuarios con Chef, que es el proyecto de código abierto en el que se basa OpsWorks.

respondido por el Alain O'Dea 26.09.2015 - 22:20

fuente

score 1 · Answer 3

Usar mi método como publicado haría que sea mucho más difícil auditar las acciones en el futuro si tuviéramos que hacerlo, como señaló Jesse, así que creo que tendré que elegir una mejor opción.

1) Mirar en OpsWorks o simplemente usar Ansible, lo que ya hacemos para el aprovisionamiento de servidores, como sugiere Alain, suena prometedor. No parece que agregaría demasiada sobrecarga.

2) También encontré el servicio Foxpass que parece que integraría la administración de claves SSH con nuestras cuentas existentes de Google Apps. Eso podría aliviar algunas de mis preocupaciones acerca de los gastos generales de los empleados de a bordo (y de baja)