AWS System Manager y los peligros de los permisos predeterminados

En septiembre de 2018, Amazon Web Services (AWS) anunció la incorporación de la Administrador de sesión al administrador de sistemas de AWS. El administrador de sesiones permite el acceso a nivel de shell o de escritorio remoto a sus instancias de Windows y Linux de AWS EC2, junto con otros beneficios. Esta es una gran característica nueva, pero se debe tener cuidado al habilitar esta capacidad.

Si bien el objetivo para muchos es una infraestructura inmutable implementada como código, a menudo hay casos en los que los sistemas heredados monolíticos aún deben atenderse manualmente. Además, en muchas situaciones, la depuración de problemas en una máquina en vivo es simplemente el camino más fácil a seguir.

Esto plantea la cuestión de cómo dar acceso seguro a sus instancias de computación en la nube. Algunos usuarios pueden optar por aceptar un mayor riesgo al abrir firewalls virtuales para permitir la conectividad de Internet a los activos en la nube. Otros aceptarán la mayor sobrecarga de administración de usar un host bastión con controles más estrictos.

Ahora Session Manager ofrece una nueva opción para el acceso de shell donde se otorga un acceso a la consola local dentro de su navegador web cuando inicia sesión en la consola de administración de AWS. Esto puede reducir drásticamente su tiempo para solucionar problemas y aumentar la seguridad, ya que el único punto de acceso es la consola de AWS con credenciales, que debe estar protegida por autenticación multifactor. Este punto único para el acceso a la consola está administrado por las capacidades centralizadas de administración de acceso e identidad (IAM) de AWS, incluido el registro y la auditoría de sesiones, todo sin necesidad de abrir puertos de red.

En otras palabras, usar el nuevo administrador de sesión es una especie de obviedad. Pero, ¿qué estás aceptando cuando lo habilitas? El siguiente es un ejemplo del mundo real de una confusión de permisos que ocurre comúnmente en la naturaleza.

Probablemente empezaría con el Guía de introducción del administrador de sesión. Después de instalar los requisitos previos, al paso 2, está listo para configurar los permisos de IAM para sus instancias. Notarás las siguientes instrucciones:

“En la página Adjuntar política, seleccione la casilla de verificación junto a Rol de Amazon EC2 para SSMy luego elija Adjuntar política”.

Si tiene ojo de águila y lee detenidamente todo el texto, puede notar la siguiente nota sobre el Rol de Amazon EC2 para SSM política administrada:

“La política AmazonEC2RoleforSSM proporciona comodines

acceso a los cubos de Amazon S3. Le recomendamos que revise esta política y la ajuste si es necesario”.

{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:PutObject",
"s3:GetObject",
"s3:GetEncryptionConfiguration",
"s3:AbortMultipartUpload",
"s3:ListMultipartUploadParts",
"s3:ListBucket",
"s3:ListBucketMultipartUploads"
],
"Resource": "*"
}

Si, como la mayoría de las personas, simplemente comienza a trabajar en las instrucciones, acaba de habilitar el acceso completo a todos sus recursos de S3 para cada instancia de EC2 con Session Manager. Los privilegios correspondientes de AmazonEC2RoleforSSM s3 otorgados se parecen a los siguientes: Puede ver arriba que la política predefinida AmazonEC2RoleforSSM otorga casi todos los permisos, lectura y escritura, al recurso comodín s3. Amazon proporciona instrucciones sobrecrear una política con los permisos mínimos necesarios

{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::aws-ssm-us-east-2/*",
"arn:aws:s3:::aws-windows-downloads-us-east-2/*",
"arn:aws:s3:::amazon-ssm-us-east-2/*",
"arn:aws:s3:::amazon-ssm-packages-us-east-2/*",
"arn:aws:s3:::us-east-2-birdwatcher-prod/*",
"arn:aws:s3:::patch-baseline-snapshot-us-east-2/*"
]
}

. La porción relevante de s3 de la política mínima tiene el siguiente aspecto:

El permiso mínimo necesario es en realidad solo acceso de lectura en algunos depósitos s3 específicos del administrador del sistema. Esto es mucho más restrictivo que el rol predeterminado recomendado que se muestra en la guía de inicio. Cualquiera que busque seguir el principio de privilegio mínimo querrá crear un rol personalizado con la versión de permiso mínimo dada por Amazonas

En el entusiasmo por probar nuevas funciones, es posible que se pasen por alto notas importantes sobre la seguridad y que sea tentador usar el rol predefinido en cualquier momento en el futuro cuando ya no esté leyendo la guía de inicio.

En algunos casos, los roles predefinidos pueden agregar riesgo en áreas que parecen completamente desconectadas de lo que está tratando de lograr. Cada rol utilizado debe verificarse periódicamente para garantizar que se aplique el principio de privilegio mínimo.