BLOG

    AWS Security Best Practices

    La seguridad en la nube encabeza la lista de prioridades dentro de Amazon Web Services, su hardware y data centers están resguardados bajos los más rigurosos estándares y protocolos de seguridad, garantizando en todo momento la más alta fiabilidad, disponibilidad, durabilidad y accesibilidad a la nube.

    Sin embargo, como usuarios de AWS debemos mantenernos informados sobre las mejores prácticas de seguridad en la nube para obtener el más alto provecho de sus beneficios y tener la mayor tranquilidad y confiabilidad mientras hacemos uso de los servicios. En este blog repasaremos los apartados clave dentro de las buenas prácticas de seguridad en Amazon Web Services.

    Modelo de responsabilidad compartida

    Cuando se trata de buenas prácticas de seguridad en AWS, se debe tener muy presente el modelo de responsabilidad compartida, mejor conocido como Shared Responsibility Model. En este se dictamina que toda la infraestructura en la nube es responsabilidad de AWS, mientras que, nosotros como usuarios somos responsables de todo aquello que usamos y conectamos a la nube.

    Para ayudar a comprender mejor ambas responsabilidades, este modelo define la responsabilidad de los usuarios como “Responsabilidad de seguridad EN la nube”, mientras que define la responsabilidad de AWS como “Responsabilidad de seguridad DE la nube”.

    Además, AWS provee de manera gráfica este modelo englobando todos sus componentes: 

    AWS best practices-1

    Así, observamos que como parte de la responsabilidad de los “clientes” o usuarios se encuentran:

    • Integridad de los datos e información que se almacena y transita en la nube.
    • Las plataformas y aplicaciones que se alojan o conectan con la nube, así como la gestión de identidad y accesos (Identity Access Management).
    • Configuración de firewalls, redes y sistemas operativos que se monten en la nube.
    • Encriptamiento tanto de lado del cliente como del lado del servidor (client-side y server-side).
    • Protección del tráfico de red (encriptamiento, integridad e identidad).

    Por otro lado y dentro de la responsabilidad propia de AWS, se define:

    A nivel de software:

    • Cómputo.
    • Almacenamiento.
    • Bases de datos.
    • Redes.

    A nivel de hardware e infraestructura global:

    • Regiones.
    • Zonas de disponibilidad (Availability zones).
    • Edge Locations.

    El primer paso a seguir para implementar las mejores prácticas de seguridad en AWS, es ubicar nuestras responsabilidades de acuerdo a este modelo y a partir de ello, mantener las mejores acciones dentro de cada uno de estos componentes.

    AWS modelo de seguridad compartida

     

    Seguridad a nivel de cuenta

    Toda la infraestructura, recursos y servicios que usamos de la nube, se encuentran centralizados en nuestra cuenta de AWS; lo que significa que alguna brecha de seguridad en ella directamente podría poner en riesgo todos nuestros recursos. Para evitar esto, es imprescindible mantener su seguridad siguiendo las mejores prácticas.


    Usuario raíz

    aws user policy

    Se le llama usuario raíz al usuario propietario de nuestra cuenta de AWS. A través de este usuario se puede crear un usuario de IAM. La mejor práctica es no usar este usuario cotidianamente; se recomienda utilizar en su lugar usuarios de IAM con privilegios de administrador, y en caso de ser necesario contar con los máximos privilegios. Es muy importante evitar compartir las credenciales del usuario raíz para asegurar su integridad y utilizar una contraseña altamente segura.
    Además, este usuario tiene privilegios únicos (realizar actividades que sólo pueden llevarse a cabo a través del usuario raíz). Desde luego, estas son actividades críticas, como editar la configuración de la cuenta, cambiar el plan de soporte e incluso eliminar la cuenta. Esto reafirma la importancia de evitar compartir este usuario y sólo utilizarlo para ejecutar este tipo de actividades.

     

    Contraseñas

    AWS SECURITY

    Como en cualquier otro sitio donde se utilicen credenciales de usuario, AWS recomienda utilizar contraseñas seguras. Que tengan una longitud adecuada y usando las combinaciones de caracteres apropiadas. Al igual que el usuario raíz, se recomienda evitar compartir la contraseña de cualquier usuario y resguardarla en un lugar seguro. En caso de necesitar que varios individuos tengan acceso a la cuenta con los mismos privilegios o similares, se recomienda que cada uno de ellos tenga su propio usuario con su contraseña única y privada.

     

    Autenticación Multifactor (MFA)

    SSO-SignIn-MFA-Generic

    La autenticación multifactor es una segunda capa de seguridad para acceder a nuestra cuenta de AWS. Cuando se activa esta autenticación, al momento de querer acceder a nuestra cuenta y se ingrese la contraseña correcta, se solicitará un token (que suele componerse de 6 dígitos), el cual tiene un tiempo de expiración corto y se puede verificar desde la aplicación en nuestro dispositivo móvil con la cual se haya configurado nuestro MFA. Ejemplo de estas aplicaciones son: Microsoft Authenticator y Autenticador de Google, entre otros.


    Así, cuando activamos MFA en nuestra cuenta, el acceso por medio de nuestro usuario requiere de la combinación de algo que sabemos (en este caso, nuestra contraseña) y algo que poseemos (en este caso nuestro dispositivo). La mejor práctica es activar MFA en nuestros usuarios como sea posible, pero sobre todo, se recomienda altamente que el usuario raíz cuente sí o sí con esta autenticación multifactor. De esta manera, aunque se hiciera un uso inadecuado de nuestra contraseña o algún atacante la consiguiera, se enfrentaría inmediatamente con el segundo factor de autenticación que depende directamente del dispositivo que nosotros poseemos.

     

    Access Keys y Key Pairs

    AWS ACCESS KEYS

    Otro tipo de credenciales que suelen utilizarse dentro de nuestra cuenta de AWS son: Las Access Keys que proveen acceso programático para acceder, ya sea a la línea de comandos de AWS (CLI), a la API o SDK. Las Key Pairs que proveen acceso a las instancias de EC2 por medio de SSH.  En ambos casos, estas credenciales se descargan en archivos (XLSX en el caso de las Access Keys) y archivos PEM en el caso de las Key Pairs.

    Debido a que estas credenciales conceden acceso directamente a recursos dentro de nuestra cuenta de AWS, la integridad y protección de estas llaves es esencial. Se debe tener un control de dónde se almacenan estas credenciales y con qué individuos son compartidas estas mismas.

    En el caso de las Access Keys, una buena práctica de seguridad es realizar una rotación de llaves (Rotating Keys) de manera periódica, lo que disminuye el riesgo de que se emplee un mal uso de antiguas llaves que ya hayan sido compartidas con otros usuarios. La forma correcta de rotar las Access Keys es la siguiente:

    1. Crear una nueva Access Key de usuario.
    2. Reconfigurar todas las aplicaciones con la nueva Access Key.
    3. Deshabilitar la Access Key antigua (es crucial sólo deshabilitarla en este punto y no eliminarla aún).
    4. Verificar que todas las aplicaciones operen correctamente con la nueva Access Key.
    5. Una vez comprobado el funcionamiento de todas las aplicaciones, eliminar la Access Key antigua.

     

    Principio del mínimo privilegio

    La gestión de usuarios y accesos dentro de nuestra cuenta de AWS se realiza a través del servicio Identity Access Management (IAM). Este servicio nos permite otorgar privilegios tanto a usuarios como a aplicaciones, esto por medio de roles que contienen políticas, las cuales son documentos en formato JSON que especifican de manera más granular, qué tipo de acciones puede realizar la entidad sobre uno o varios recursos específicos y bajo determinadas condiciones. AWS ofrece una amplia lista de roles y políticas predeterminadas.

    Sin embargo, nosotros podemos crear nuestros propios roles customizados con políticas que nosotros mismos definamos, según nuestros requerimientos.

     

    LoPL

    Con base en esto, se establece el principio del Least Privilege Principle, el cual es una buena práctica de seguridad que propone que tanto usuarios como aplicaciones, obtengan justo los privilegios necesarios para realizar sus operaciones y no tengan más de lo necesario. Esto limita las acciones que pueden llevar a cabo las entidades y disminuye importantemente la posibilidad de que acciones sean realizadas sin autorización.

    Por otra parte, si en una cuenta existieran varios usuarios de IAM, y a todos ellos se les otorgara rol de administrador innecesariamente, se estaría sujeto a que cualquiera de estos usuarios realizara acciones críticas dentro de la cuenta que pudieran tener un verdadero impacto negativo.

     

    Aseguramiento de disponibilidad en servicios

    Dentro de las buenas prácticas de seguridad en la nube, es muy importante contemplar la integridad de la información y componentes que residen en AWS. Muchos de los servicios en AWS (como lo es S3, EC2 o RDS), ofrecen replicación en múltiples regiones y zonas de disponibilidad.

    De aquí surge la buena práctica de distribuir nuestras aplicaciones a través de más de una Availability Zone, que permite mantener la resiliencia en caso de fallas en uno de los data centers de Amazon, incluyendo posibles desastres naturales o errores de sistema, y así evitar la pérdida de información que impacte críticamente en nuestro negocio.

    AWS Availability Zone

     

    El seguimiento de todas estas prácticas, mejoran en gran medida la seguridad de nuestra infraestructura en AWS. Tanto nuestros recursos, aplicaciones, usuarios y cuentas pueden estar propensos a ataques y usos inadecuados, lo cual puede disiparse aplicando estas buenas prácticas en los componentes que nos corresponden dentro del modelo de responsabilidad compartida.

     


    ¡Te invito a agendar una asesoría con nuestros expertos certificados para asegurar el buen rendimiento de tu consola!

    CTA AWS-01


    Descubre otros artículos interesantes en nuestro blog:

    Luis Manuel Juárez
    Escrito por Luis Manuel Juárez

    Ingeniero en Cloud, Analista de datos y Product Owner.