Aspectos básicos de la seguridad

Cuando crea una cuenta de AWS, comienza con lo que se conoce como usuario raíz. Este es el primer usuario de AWS que existe en su cuenta de AWS. AWS recomienda que no utilice esta cuenta para las operaciones diarias, ya que tiene acceso y control totales sobre la cuenta, y debe seguir las prácticas recomendadas para proteger al usuario raíz. Esto implica bloquear las claves de acceso de los usuarios raíz, utilizar una contraseña segura, habilitar la autenticación multifactor de AWS y crear un usuario de IAM para acceder a su cuenta. A esta cuenta se le pueden asignar privilegios de administrador y se debe usar para todas las tareas administrativas futuras.

A continuación, debe asignar contactos de seguridad alternativos a su cuenta. El contacto de seguridad alternativo recibirá notificaciones relacionadas con la seguridad, incluidas las del Equipo de confianza y seguridad de AWS. Puede obtener más información sobre la importancia de establecer esta información de contacto al principio de la configuración de la cuenta en la entrada del blog Actualice el contacto de seguridad alternativo en sus cuentas de AWS para recibir notificaciones de seguridad oportunas.

Una vez que haya confirmado sus contactos de seguridad, debe considerar las regiones de AWS en las que deberían ejecutarse sus cargas de trabajo y las regiones en las que no deberían ejecutarse. A continuación, puede bloquear las regiones no utilizadas para garantizar que no se puedan ejecutar cargas de trabajo desde esas regiones. Si bien esto ayuda a la optimización de los costos, también contribuye a la seguridad. ¿Cómo es posible? Al bloquear las regiones en las que no espera ejecutar cargas de trabajo, puede centrar sus esfuerzos de supervisión en las regiones que utiliza activamente.

En este punto, ha protegido al usuario raíz, ha creado uno o más usuarios de IAM, ha asignado contactos de seguridad y ha bloqueado las regiones en las que se pueden ejecutar las cargas de trabajo. A continuación, consideremos cómo interactuarán los usuarios con los recursos de AWS. Hay dos métodos principales de interacción: la CLI de AWS y la Consola de administración de AWS. Se recomienda configurar el inicio de sesión único para la CLI de AWS y la consola. Consulte el artículo Configuración de la CLI de AWS para utilizar AWS IAM Identity Center (sucesor de AWS Single Sign-On) para obtener más información sobre cómo gestionar de forma centralizada el acceso con AWS IAM Identity Center.

El siguiente paso para proteger su cuenta es configurar grupos de usuarios de AWS IAM para controlar el acceso. En lugar de controlar el acceso de los usuarios individuales estableciendo políticas directamente sobre el usuario, es mejor crear un grupo, asignarle los permisos necesarios y, a continuación, asignar los usuarios al grupo. Los usuarios heredarán los permisos de ese grupo. Esto ofrece una forma más escalable de proporcionar control de acceso a muchos usuarios. Es importante entender la IAM y los grupos de IAM porque abarcan varios servicios. IAM es un servicio que interactúa hasta cierto punto con todos los servicios de AWS, así que asegúrese de dedicar tiempo a familiarizarse con IAM.

Seguir estas prácticas desde el principio lo ayudará a proporcionar un acceso seguro a sus recursos de AWS. A continuación, analizaremos cómo proteger la infraestructura que crea en AWS.

A medida que desarrolle su infraestructura de nube, empezará por crear una Amazon Virtual Private Cloud (Amazon VPC). Se trata de una red virtual que usted define (se crea una red predeterminada en cada región al crear su cuenta) que le permite lanzar recursos. Una VPC se parece a una red tradicional, ya que tiene asignado un rango de direcciones IP CIDR y se subdivide mediante la creación de subredes. Las subredes se pueden usar para proporcionar aislamiento a diferentes conjuntos de recursos. Las subredes pueden ser públicas o privadas. Las subredes públicas tienen una ruta a una puerta de enlace de Internet, tienen acceso a Internet a través de esta puerta de enlace y se puede acceder a ellas desde Internet si los controles de acceso pertinentes lo permiten. Las subredes privadas también tienen una tabla de enrutamiento, pero no tienen una ruta a una puerta de enlace a Internet, por lo que, de forma predeterminada, no pueden acceder a Internet ni se puede acceder a ellas desde Internet. Para permitir que los recursos de una subred privada accedan a Internet, se necesita una puerta de enlace NAT. A nivel de subred, una lista de control de acceso (ACL) a la red permite o deniega tráfico entrante o saliente específico. Puede usar la ACL de red predeterminada para su VPC o puede crear una ACL de red personalizada para su VPC. Las ACL de red son listas numeradas, se procesan de arriba a abajo y no tienen estado. Esto significa que necesitará una regla de ACL de red entrante y saliente para permitir el tráfico bidireccional.

A medida que implemente los recursos de EC2 en su VPC, asociará un grupo de seguridad a ellos. Un grupo de seguridad controla el tráfico entrante y saliente que puede llegar a los recursos de EC2. Los grupos de seguridad son similares a un firewall, pero en lugar de usar solo una lista o un rango de direcciones IP, pueden apuntar a algo denominado referencia de recursos. Una referencia de recursos es un grupo con nombre que mantiene una lista actualizada de las direcciones IP asignadas a cada recurso del grupo. Por ejemplo, si crea un grupo de escalado automático para activar las instancias de Amazon EC2, a cada instancia se le asigna una nueva IP cuando se inicia. Al añadir un grupo de seguridad a estas instancias, puede conceder acceso al grupo de seguridad del servidor de base de datos mediante el ID del grupo de seguridad de las instancias de EC2, y cualquier instancia de EC2 nueva que se lance tendrá acceso a la base de datos sin necesidad de añadir su dirección IP a la lista de permitidos.

Las reglas de los grupos de seguridad son similares a las ACL de red porque, al crearlas, coinciden en el puerto, el protocolo y las direcciones, pero tienen estado; puede pensar que son similares a un firewall con estado. Al crear una entrada para permitir un tipo específico de tráfico, no es necesario crear una regla que coincida con el tráfico de retorno; si tiene estado, se permitirá el tráfico de retorno. Para comprender mejor cómo interactúan los grupos de seguridad y las ACL, esta comparación es útil.

Para añadir una capa adicional de seguridad a la infraestructura, puede implementar el firewall de red de AWS. El Network Firewall es un servicio gestionado que implementa la protección de su Amazon VPC. Ofrece una protección más detallada que los grupos de seguridad, ya que puede incorporar el contexto de los flujos de tráfico, como el seguimiento de conexiones y la identificación de protocolos, para aplicar políticas como la de impedir que sus VPC accedan a dominios utilizando un protocolo no autorizado. Esto se hace mediante la configuración de reglas personalizadas de Suricata. Por ejemplo, puede configurar el firewall de red para protegerlo contra los ataques de malware. Para ir un paso más allá, puede implementar otro servicio administrado, AWS Shield Advanced, para protegerse contra las amenazas de DDoS.

Al crear recursos en AWS, debe tener cuidado de seguir las prácticas recomendadas de seguridad para el tipo de recurso con el que esté trabajando. En el caso de las instancias EC2, la seguridad comienza por controlar el acceso de red a las instancias, por ejemplo, mediante la configuración de la VPC y los grupos de seguridad. (Para obtener más información, consulte “Seguridad de Amazon VPC” en la sección “Proteger la infraestructura que crea”).

Otro aspecto de la seguridad de las instancias es la gestión de las credenciales utilizadas para conectarse a las instancias. Esto comienza con los permisos de usuario de IAM que asigne, pero se extiende al grupo asignado. Esto proporciona un nivel de seguridad para el usuario que trabaja con la instancia de EC2, pero no para la instancia en sí. También debes configurar las funciones de IAM que están asociadas a la instancia y los permisos asociados a esas funciones. Para acceder a una instancia EC2, en lugar de abrir el puerto para SSH o configurar un host bastion/jump, debe usar EC2 Instance Connect.

Debe asegurarse de que el sistema operativo invitado y el software implementados en la instancia estén actualizados con todas las actualizaciones del sistema operativo y los parches de seguridad. Para obtener más información, visite Seguridad en Amazon EC2.

Proteger la base de datos es un aspecto importante de su enfoque de seguridad. Como se menciona en la sección de seguridad de Amazon VPC, se recomienda implementar las bases de datos en una subred privada para impedir el acceso de terceros a través de Internet. AWS ofrece 15 bases de datos personalizadas. Cada uno está protegido de forma diferente, pero todos comparten lo siguiente en común.

Para acceder a una base de datos, se requiere algún tipo de autenticación. Esto puede tomar la forma de un nombre de usuario y una contraseña, que deben rotarse de forma regular. También puede utilizar el proxy de Amazon RDS para aprovechar las funciones de IAM y gestionar el acceso a la base de datos por usted. Algunos de los servicios de bases de datos, como Amazon DynamoDB, utilizan funciones de IAM para proporcionar acceso, por lo que no es necesario que administre las credenciales usted mismo.

SSH es uno de los métodos más comunes para administrar las instancias de EC2 y Amazon EC2 Instance Connect le permite usar SSH para conectarse a las instancias de EC2 mediante claves SSH de un solo uso directamente en la consola. En los siguientes artículos se explica cómo habilitar Amazon EC2 Instance Connect y se explican los casos de uso típicos. También puede generar claves SSH al crear su instancia de EC2, descargarlas localmente y usarlas para conectarse a su instancia. Sin embargo, esto significa que debe proteger esas claves, asegurarse de que estén almacenadas en algún lugar al que no perderá el acceso y que solo puede conectarse a su instancia desde una máquina que tenga esas claves descargadas. EC2 Instance Connect proporciona el mismo acceso SSH, de forma segura, desde la consola, en todas las máquinas, de una manera fácil de usar.

Restringir el acceso a la base de datos solo a los servicios e infraestructuras que requieren acceso es una práctica recomendada. Para ello, puede configurar grupos de seguridad para las instancias de RDS, las bases de datos de Amazon Neptune o los clústeres de Amazon Redshift.

Realizar copias de seguridad y probar restauraciones

Hacer copias de seguridad de los datos y realizar restauraciones frecuentes para confirmar que las copias de seguridad funcionan correctamente debe ser una prioridad. Con AWS Backup, puede configurar y administrar fácilmente las copias de seguridad para servicios de AWS específicos, incluidos Amazon RDS, DynamoDB y Neptune, entre otros.

Para garantizar la seguridad sin servidor, debe estar familiarizado con AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon SQS e IAM. Con la seguridad sin servidor, AWS asume una mayor responsabilidad en comparación con el modelo de responsabilidad compartida, pero sigue existiendo una responsabilidad del cliente que debe tener en cuenta. En un entorno sin servidor, AWS administra la infraestructura, la computación, el entorno de ejecución y el lenguaje de ejecución. El cliente es responsable del código de función y las bibliotecas del cliente, la configuración de los recursos y la administración de identidades y accesos, como se muestra en la imagen.

En las siguientes secciones, proporcionamos detalles sobre las prácticas de seguridad que son responsabilidad del cliente. Para obtener más información, consulte Seguridad en AWS Lambda.

AWS Lambda proporciona tiempos de ejecución que ejecutan el código de su función en un entorno de ejecución basado en Amazon Linux. Sin embargo, si usa bibliotecas adicionales con su función, es responsable de actualizarlas. Asegurarse de que sus bibliotecas estén actualizadas puede ayudarle a mantener su postura de seguridad.

AWS Lambda se integra con varios recursos de AWS, como Amazon DynamoDB, Amazon EventBridge y Amazon Simple Notification Service (Amazon SNS). Seguir las prácticas de seguridad recomendadas para cada servicio que utilice como parte de su función le ayudará a reforzar su postura de seguridad. La documentación de cada servicio proporciona orientación adicional.

La ejecución de las funciones de Lambda puede requerir permisos y funciones de IAM específicos. Puede encontrar más información en la sección Permisos de la Guía para desarrolladores de AWS Lambda.

Su estrategia de seguridad también debe incluir la supervisión, el registro y la administración de la configuración. Por ejemplo, muchas organizaciones habilitan la contabilidad de sus dispositivos mediante el protocolo TACACS+, RADIUS o los registros de Active Directory. Esto ayuda a garantizar que se cree una pista de auditoría para todas las actividades administrativas. Dentro de la nube de AWS, esto se puede hacer con AWS CloudTrail. CloudTrail permite la auditoría, el monitoreo de la seguridad y la solución de problemas operativos a partir del seguimiento de la actividad del usuario y el uso de la API. El repositorio de aplicaciones sin servidor de AWS, que facilita a los desarrolladores y las empresas la búsqueda, implementación y publicación rápidas de aplicaciones sin servidor en la nube de AWS, está integrado con AWS CloudTrail. Para obtener más información, consulte la Guía para desarrolladores de repositorios de aplicaciones sin servidor de AWS.

Aún tendrá que proporcionar protección contra DoS y la infraestructura hasta cierto punto para sus entornos sin servidor, lo que puede hacer con AWS Shield y AWS Shield Avanzado. La supervisión y la detección de amenazas se analizan con más detalle en la sección “Monitorización de su entorno”.

En AWS, los datos se almacenan en Amazon S3, que tiene varios controles para proteger los datos. El artículo Las 10 mejores prácticas de seguridad para proteger los datos en Amazon S3 abarca las técnicas más fundamentales. Estas incluyen el bloqueo de los buckets de S3 públicos a nivel de la organización, el uso de políticas de buckets para verificar que todos los accesos otorgados estén restringidos y sean específicos, y el cifrado y la protección de los datos.

Para el cifrado, AWS Key Management Service (AWS KMS) le permite crear y controlar las claves que se utilizan para cifrar o firmar sus datos de forma digital. Si desea cifrar sus datos en AWS, tiene varias opciones. La primera consiste en utilizar el cifrado del lado del servidor con claves de cifrado administradas por Amazon S3 (SSE-S3). Con este método, el cifrado se produce después de que los datos se envíen a AWS mediante claves administradas por AWS.

La segunda opción consiste en cifrar los datos una vez que estén en AWS, pero en lugar de utilizar las claves creadas y administradas por AWS, puede realizar el cifrado del lado del servidor con las claves maestras del cliente (CMK) almacenadas en AWS KMS (SSE-KMS).

La tercera opción para almacenar datos cifrados en AWS es utilizar el cifrado del cliente. Con este enfoque, los datos se cifran antes de transferirlos a AWS.

En la imagen se puede ver un ejemplo de cómo el cifrado del lado del cliente y el cifrado del lado del servidor benefician a los clientes.

Las VPN pueden abarcar varias tecnologías. La idea detrás de una VPN es que sus datos en tránsito mantengan su integridad y puedan intercambiarse de forma segura entre dos partes. AWS ofrece varias tecnologías que ayudan a proteger los datos en tránsito. Una de ellas es AWS PrivateLink, que proporciona conectividad privada y cifrada entre las VPC, los servicios de AWS y sus redes locales. Esto se hace sin exponer su tráfico a la Internet pública. Esto también podría considerarse una red privada virtual.

Sin embargo, en la mayoría de los casos, una discusión sobre la VPN gira en torno al uso del cifrado de datos. En función de las circunstancias, es posible que deba proporcionar un cifrado entre un cliente y sus recursos en la nube de AWS. Esta situación requeriría una VPN de cliente de AWS. Por otro lado, es posible que esté transfiriendo datos entre su centro de datos o sucursal y sus recursos de AWS. Puede lograrlo mediante túneles IPsec entre sus recursos locales y sus Amazon VPC o AWS Transit Gateway. Esta conectividad segura se conoce como VPN de sitio a sitio.

Por último, la gestión de los recursos de la nube mediante la Consola de administración de AWS también ofrece datos cifrados en tránsito. Si bien normalmente no se referiría a la conectividad con la consola como una VPN, su sesión utiliza el cifrado TLS (Transport Layer Security). Por lo tanto, sus configuraciones se mantienen confidenciales a medida que crea su arquitectura segura. TLS también se usa con la API de AWS.

AWS ofrece varios servicios gestionados para ayudar a monitorear su entorno, junto con opciones de autoservicio. Por ejemplo, puede usar los registros de flujo de la VPC para registrar y ver los flujos de tráfico de la red, o puede usar Amazon CloudWatch para analizar los registros de AWS WAF o incluso para crear alarmas para las instancias EC2. Puede obtener más información sobre Amazon CloudWatch en este taller.

Además, AWS CloudTrail monitorea y registra la actividad de las cuentas en toda la infraestructura de AWS, lo que le permite controlar las acciones de almacenamiento, análisis y corrección. Esto es esencial para crear un registro de auditoría administrativa, identificar los incidentes de seguridad y solucionar problemas operativos.

Por último, Amazon GuardDuty se puede utilizar para la detección de amenazas e incluso para ir un paso más allá al hacer que los hallazgos publicados inicien acciones de corrección automática en su entorno de AWS.

Al abordar cada una de estas áreas operativas, estará bien encaminado para establecer las funciones de seguridad esenciales para su entorno de nube.