Gestión de Identidades y Accesos en AWS: IAM y Políticas de Seguridad

Puedes usar los siguientes elementos para interactuar con AWS:

1. AWS MANAGMENT TOOL (GUI):  Es la interfaz web gui (grafical user interface), para administrar la consola y tomar acciones.
2. AWS COMMAND LINE INTERFACE (CLI):   Es la linea de commando instalada en las distribuciones de linux
3. SOFTWARE DEVELOPMENT KITS (SDKs): Esta herramienta es proporcionada por AWS que te ayuda a usar la infraestructura para el desarrollo de tus aplicaciones

Un especialista en seguridad de AWS necesita saber:

1. cuáles son las mejores prácticas para administrar el acceso a las cuentas de AWS y recursos.
2. Como podemos dar acceso a los usuarios solo a los recursos que necesitan.
3. Cuál es la mejor forma de administrar múltiples cuentas.

PRINCIPAL AND IDENTITIES AWS ACCOUNT ROOT USER

Cuando creas una cuenta de AWS por primera vez inicializas como usuario ROOT. Este usuario tiene acceso completo a todos los productos y servicios de la cuenta. Se puede acceder al usuario root entrando con un usuario y contraseña que son proporcionados cuando se crea la cuenta. AWS no recomienda usar la cuenta root todos los días. Se debe crear usuarios para ingresar a la infraestructura de AWS.

Se deben crear usuarios adicionales para administrar las cuentas. Deberás crear usuarios con el principio de menos privilegios. Otorga el nivel de acceso a los usuarios nada más a lo que necesiten.

Puedes crear usuarios administradores para administrar los recursos en ves de la cuenta root.

Una mejor practica también requiere colocar multi-factor (MFA) para la cuenta root. USA SOLO LA CUENTA ROOT PARA TAREAS QUE LO REQUIERAN.

IAM es un servicio web de AWS que ayuda asegurar el acceso a los recursos de AWS. Usa IAM para controlar quien esta autenticado y autorizado a usar los recursos.

Puedes administrar el acceso a AWS, creando POLÍTICAS DE SEGURIDAD.

Una identidad principal, que puedes responder a una acción u operación en un recurso de AWS. Una identidad principal también puede ser un servicio de AWS como; Amazon Elastic Compute Cloud. Etc.

Con IdP (Identity Provider), puedes administrar identidades fuera de IAM. Por ejemplo, Entrar con Amazon, Facebook o Google. Puedes dar acceso a estas identidades externas al usar recursos de AWS en tu cuenta.

Los usuarios de AWS:

1. Tienen sus propias credenciales de acceso
2. Están autorizados para realizar acciones específicas de AWS basadas en permisos.

Por default los usuarios no tienen permisos de realizar algunas acciones en AWS. Los usuarios no tienen permisos, para realizar algunas operaciones o acceder algunos recursos de AWS.

Una ventaja que tienen los usuarios individuales es asignar permisos individuales para cada usuario.

Una mejor practica requiere autenticación multi-factor (MFA) Para los usuarios IAM y configura IAM user password policy.

Proporcionan el tipo de credenciales que requieren los usuarios para acceder.

Este caso es;

• AWS Managment Console: crea una contraseña y usuario.
• AWS Command Line Inferface, SDKs: requiren (access key ID y secret key access) para el usuario.

Programmatic access da permiso a los usuarios para hacer llamadas de APIs, en AWS CLI, AWS SDKs. AWS Proporciona un SDK para programar en java Python y .net.

Cuando configuras programmatic Access, te da un par de llaves que debes usar para configurar AWS CLI, para hacer llamadas a la API.

Al permitir a los usuarios crear o modificar recursos y realizar tareas has las siguientes tareas:

1. Crea o elige IAM policies, para otorgar IAM Users permiso para acceder a recursos específicos y acciones de API que necesiten.
2. Adjunta las políticas a los IAM users o IAM groups que requieren esos permisos.

Los usuarios solo tienen permiso a los que especificaste en la política.

Una mejor practica es adjuntar la política a los usuarios solo a las funciones que necesiten.

Es una colección de un grupo de usuarios, con los grupos puedes especificar permisos a múltiples usuarios las cual hace más fácil la administración.  Los usuarios pueden ser miembros de uno o más grupos.

Los miembros que están en el grupo heredan los permisos que están asignados. Casos en los que se pueden usar los permisos.

Los miembros que están en el grupo heredan los permisos que están asignados. Casos en los que se pueden usar los permisos.

Los usuarios IAM asumen roles en AWS managment console y en línea de comando. Estas acciones usan AssumeRole API. Los servicios de AWS pueden usar la misma llamada de apis para asumir roles en la cuenta de AWS.

IAM te proporciona todas las herramientas para crear y administrar todas las políticas para usuarios, grupos y roles. Puedes crear varias políticas y añadirlas a la identidad y validar.

El especialista de seguridad preguntara: como puedes dar acceso a los usuarios solo a lo que necesitan. Las políticas están adjuntas en una entidad (IAM) o en un recurso para definir permisos.

1. Identity-based policies: son asignadas a los usuarios, grupos y roles.
2.  Resource-based policies: están asignados a los recursos.

Los recursos basados en políticas son documentos JSON que controlan, acciones de usuarios, pueden realizar acciones y condiciones. También son adjuntados a los recursos como un S3

AWS tiene políticas administradas, pero También puedes crear y administrar tus propias políticas.

Las políticas basas en identidad son políticas administradas que se pueden adjuntar a múltiples usuarios, grupos y roles en AWS.

Las políticas personalizadas tu las creas y administras desde tu cuenta de AWS.

Las políticas en línea son asignadas directamente entre entidad y usuario.

Permisos explícitos: son los que en su efecto permiten las acciones a los recursos y lo demás todo lo deniegan.

Denegación explicita: Son las que en su efecto deniegan las acciones en los recursos y todo lo demás lo permiten.

Es importante saber la evaluación lógica cuando construyes políticas de AWS. De esta forma solo das acceso a los usuarios y aplicaciones solo cuando los necesitan.

Por default todas las peticiones implícitas son denegadas a excepción de la cuenta root. Esta política se llama implicit deny.

Un recurso basado en políticas esta adjuntado solo para un recurso ya sea un s3 o lamba etc.

Con un recurso basado en políticas puedes elegir quien accede al recurso y que puede realizar.

Al crear esta política debes colocar el numero de la cuenta de usuario, rol o cuenta federada a la cual quieres asignar o denegar los permisos:

El principal es el ID de la cuenta de AWS.

Esta es una estrategia para crear múltiples capas de seguridad. Puedes aprovechar múltiples controles para todas las capas.

Razones para usar múltiples cuentas.

Razones para crear estructuras de múltiples cuentas:

• Agrupas los recursos
• Mejoras la seguridad con limites lógicos

SCPs(service control policies): Servicio de control de políticas, estos no otorgan permisos, solo actúan como un filtro.

Es una característica avanzada para usar una política administrada, los límites de permisos permiten realizar acciones que permiten permisos basados en políticas. No proporcionan permisos de propiedad.

¿Cuál es la mejor forma de administrar múltiples cuentas?

Razones para usar múltiples cuentas:

Estructuras la organización, mejoras la seguridad de accesos, previenes accesos no autorizados, simplificas la administración.

Con una organización en AWS, puedes crear jerarquía de recursos dentro de la unidad organizacional OUs.

Puedes aplicar un servicio de control de políticas SCPs (Service Control Policies) para controlar el número máximo de permisos bajo OUs (unidad organizacional).

SPCs: es un tipo de política de organización que puedes usar para administrar permisos en tu organización, no otorgan permisos, solo es un filtro de recursos que se tienen en la organización.

IAM: da permisos a las identidades o grupos.

Services control policies solo se puede administrar a nivel organizacional