Cómo limitar el acceso a nuestros recursos en AWS con nuevas claves condicionales

El pasado 27 de abril, AWS daba a conocer a sus usuarios nuevas claves condicionales que hacen más simple controlar el acceso a los recursos de la cuenta de AWS dentro de los límites de una organización. En la publicación de hoy, os explicaremos en qué consiste esta nueva característica de seguridad.

Cuando hablamos de controles de acceso en AWS, uno de los primeros servicios en los que pensamos (o deberíamos pensar) es AWS Identity and Access Management, más comúnmente conocido como IAM por sus siglas en inglés. Las nuevas claves condicionales a las que hacíamos mención al principio de esta publicación están directamente relacionadas con este servicio, y son:

• aws:ResourceOrgID: se trata del ID de organización de los recursos o recurso que se va a acceder.
• aws:ResourceOrgPaths: ruta de la organización del recurso o recurso al que se va a acceder.
• aws:ResourceAccount: ID de la cuenta de AWS que contiene los recursos o recurso que se va a acceder.

Con estas tres condiciones es posible controlar el acceso a los recursos de AWS basándonos en nuestra organización, unidades de organización (OU, por sus siglas en inglés), o nuestra cuenta de AWS. Haciendo uso de ellas garantizamos, de manera más sencilla, que tan solo usuarios y roles de nuestra organización puedan acceder a los recursos presentes dentro de la misma. Además, estas nuevas implementaciones se pueden combinar con las características ya conocidas de IAM para restringir el acceso «a» y «desde» cuentas de AWS que no forman parte de nuestra organización.

Imaginemos que queremos evitar que ciertos usuarios en nuestra organización añadan objetos a un bucket S3 que no pertenece a la misma, con el objetivo de reforzar las medidas de seguridad destinadas a evitar fugas de información sensible. Para lograr esto, tan solo se necesitará configurar una política de IAM que prohíba el acceso a acciones relacionadas con S3 a no ser que la condición aws:ResourceOrgID coincida con el ID de nuestra organización (el cual, recordemos, es único). Debido a que la política hace referencia a toda nuestra organización y no solo a un único bucket, es posible mantener de manera más cómoda un mayor nivel de seguridad en todos los recursos a los que dicha política se aplique.

Esta política se puede asociar tanto a un usuario o rol IAM de manera individual, o se puede utilizar en combinación con las políticas de control de servicio (SCPs, por sus siglas en inglés) a nivel de organización en AWS para que la nueva regla se aplique en todas las cuentas de AWS presentes en nuestra organización.

Además, considerando que también podemos evitar que usuarios ajenos a nuestra organización añadan objetos a nuestro bucket, estaríamos implementando una barrera más frente ataques del tipo Cross-Site Scripting, por ejemplo, ya que si los permisos de un bucket S3 no están debidamente configurados, un usuario anónimo o autenticado en AWS, sin necesidad de pertenecer a nuestra organización, podría llegar a subir archivos maliciosos.

Otro caso adicional, ya para finalizar esta publicación, podría ser una situación en la que quisiéramos restringir el acceso a recursos de AWS dentro de nuestra unidad organizacional, es decir, que, por ejemplo, el departamento de Marketing tan solo pueda ver los recursos que le corresponden y no aquellos pertenecientes al departamento de Administración, Auditoría, etc.

Más información

How to control access to AWS resources based on AWS account, OU, or organization

La entrada Cómo limitar el acceso a nuestros recursos en AWS con nuevas claves condicionales se publicó primero en Una al Día.