Escenario para el desarollo del trabajo

En este proyecto, trabajas como especialista en seguridad en la nube en el banco AnyCompany Financial.

La empresa tiene sucursales en todo el país. La empresa ofrece cuentas corrientes y de ahorro, tarjetas de crédito, préstamos y productos de inversión. Todos los productos requieren el uso de información personal identificable (PII), como números de cuenta, información de contacto e identificaciones personales. Su jefe, el Director de TI, le ha encargado que garantice la seguridad de los recursos de la empresa en la nube de AWS.

La empresa tiene sucursales en todo el país. La empresa ofrece cuentas corrientes y de ahorro, tarjetas de crédito, préstamos y productos de inversión. Todos los productos requieren el uso de información personal identificable (PII), como números de cuenta, información de contacto e identificaciones personales. Su gerente, el Director de TI, le ha encargado que garantice la seguridad de los recursos de la empresa en la nube de AWS.

Las áreas clave de la infraestructura de AWS que deben protegerse incluyen los buckets de S3, la red que aloja los servidores web y las claves que se utilizan para cifrar los datos. Su gerente también quiere que usted supervise y analice el acceso a estos recursos para que el banco pueda mejorar su postura de seguridad a medida que se producen cambios y posibles incidentes de seguridad.

Su tarea en este proyecto es proteger estos recursos de AWS basándose en las prácticas recomendadas de AWS asociadas con el marco bien diseñado de AWS, el principio de privilegio mínimo y las normas de TI internas de la empresa.

A lo largo del proyecto, probarás el acceso a los recursos como dos usuarios de prueba, Paulo y Mary, que son miembros del grupo de administradores de cuentas. En algunos casos, Paulo tiene acceso más privilegiado que María a determinados recursos almacenados en la cuenta de AWS. Compararás su acceso con el de María. Comparando su acceso, podrás verificar si recursos específicos han sido asegurados utilizando mecanismos más allá de las políticas de AWS Identity and Access Management (IAM).

En la fase AWS KMS del proyecto, utilizará un usuario de prueba llamado Sofia, quien es una miembro del grupo de asesoría financiera.

Fase Detalle Requisitos de la Solución
1 Asegurar datos en Amazon S3 – La solución que construyas implementará funciones de seguridad que incluyen políticas de bucket, versionado de objetos, registros de inventario y registros a nivel de objeto. R3, R7
2 Asegurar VPCs – La solución que construyas implementará funciones de seguridad que incluyen registros de flujo de VPC, configuraciones de tablas de enrutamiento, listas de control de acceso a red (ACLs) y firewalls de red. R1, R2, R3, R6
3 Asegurar recursos de AWS usando AWS KMS – La solución que construyas implementará funciones de seguridad que incluyen el uso de claves administradas por el cliente en KMS para cifrar datos almacenados en S3, cifrar volúmenes EBS de instancias EC2, usar cifrado envolvente con KMS y cifrar datos almacenados en Secrets Manager. R3, R5
4 Monitoreo y registros – La solución que construyas implementará funciones de seguridad disponibles en CloudTrail, CloudWatch y AWS Config para registrar y monitorear la actividad en tu cuenta. R4, R7, R8

Fase 1: Proteger los datos en Amazon S3

En esta fase, se le desafía a comenzar a implementar la configuración de seguridad en la cuenta de AWS. Se le ha pedido que asegure los datos PII de los clientes que se almacenan en Amazon S3. El equipo de liderazgo de AnyCompany Financial ha oído hablar de recientes violaciones de datos en otras empresas y desea proteger los datos de los clientes del acceso no autorizado. La empresa quiere hacer lo siguiente

Al final de esta fase, tendrá la arquitectura que se muestra en el siguiente diagrama:

Observe que cuando haya terminado de configurar la seguridad en el bucket, el usuario de prueba Paulo debería tener acceso a él, pero María no.

Tarea 1.1: Crear un bucket, aplicar una política de bucket y probar el acceso

En esta tarea, deberás crear un bucket, aplicarle una política de bucket y luego probar si Paulo y Mary pueden acceder al bucket.

Después de conectarte a la consola de administración de AWS, observa que has iniciado sesión con el rol IAM de voclabs. Puedes verlo en la esquina superior derecha de la consola.

Consejo: Para la mayoría de las tareas y pasos, realizarás acciones con este rol voclabs. Sin embargo, en algunos pasos, iniciarás sesión como un usuario de prueba (María, Paulo o Sofía). Cuando no estés seguro de con qué usuario has iniciado sesión, comprueba el nombre que aparece en esta zona de la consola.

En la consola de Amazon S3, observe que ya se han creado algunos buckets para usted. Copia el ID único de los nombres de los buckets (el mismo ID único se añade al final de cada nombre de bucket).

Cree un nuevo bucket denominado data-bucket- en us-east-1, donde es el valor que ha copiado del nombre del bucket existente. Acepte todos los ajustes predeterminados del bucket.

Nota: Cuando cree el bucket, observe que el cifrado del lado del servidor siempre está activado. El valor predeterminado es el cifrado del lado del servidor con claves administradas de Amazon S3 (SSE-S3).

Importante: Todas las referencias futuras a nombres de bucket en estas instrucciones utilizarán el nombre abreviado, sin el ID único. Por ejemplo, data-bucket- se denominará data-bucket, y deberás añadir el ID único para que coincida con el nombre real del bucket.

Una vez creado el nuevo bucket:

Sube un objeto al bucket de datos.

Por ejemplo, crea un archivo llamado miarchivo.txt, escribe «hola mundo» en el archivo, guárdalo y luego súbelo.

Una vez creado el documento miarchivo.txt se ingresa al bucket recién creado y se da click en cargar:

Se selecciona el documento y se carga

Cree una política de buckets para el bucket de datos y aplíquela al bucket. La política del bucket debe incluir dos declaraciones:

Nota: Tenga cuidado ya que un error común que puede causar problemas significativos durante la limpieza de recursos es aplicar una política general de denegar todo en un bucket de S3. Una vez aplicada, esta política bloqueará el acceso al bucket y su contenido a todos los usuarios y servicios. Si esto ocurre, puede ser necesario crear un nuevo bucket.

Para crear la política se ingresa a “permisos” en las opciones del bucket S3:

La primera declaración debe hacer lo siguiente:

Permitir todas las acciones del servicio Amazon S3 para todos los principales para data-bucket y todos los objetos en él.
Incluye una condición para que el ARN sea igual al ARN del rol IAM voclabs, el usuario IAM paulo o el usuario IAM sofia.

Consejo: En la condición, utilice aws:PrincipleArn.

La segunda sentencia debe hacer lo siguiente

Denegar todas las acciones del servicio Amazon S3 para todos los principales para data-bucket y todos los objetos en él.
Incluya la condición de que el ARN no sea igual al ARN del rol IAM voclabs, el usuario IAM paulo o el usuario IAM sofia.

Consejo: Para generar la política de bucket, puede utilizar el Generador de Políticas de AWS o los editores de políticas visuales o JSON en la consola de IAM. Un ejemplo de cómo utilizar el editor visual de políticas en IAM está disponible en el laboratorio de IAM para el curso de AWS Academy Cloud Architecting. También puede consultar la documentación de AWS.

Se crea la política de manera correcta:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificPrincipals",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::data-bucket2-0f1040871b30b2836",
        "arn:aws:s3:::data-bucket2-0f1040871b30b2836/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::905418218991:role/voclabs",
            "arn:aws:iam::905418218991:user/paulo",
            "arn:aws:iam::905418218991:user/sofia"
          ]
        }
      }
    },
    {
      "Sid": "DenyOthers",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::data-bucket2-0f1040871b30b2836",
        "arn:aws:s3:::data-bucket2-0f1040871b30b2836/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalArn": [
            "arn:aws:iam::905418218991:role/voclabs",
            "arn:aws:iam::905418218991:user/paulo",
            "arn:aws:iam::905418218991:user/sofia"
          ]
        }
      }
    }
  ]
}

Verifique el nivel de acceso S3 de los usuarios paulo y mary. Para ello

En una ventana de navegador de incógnito o privada, inicia sesión en la consola de administración de AWS como el usuario IAM paulo.

Consejo: Puedes encontrar el enlace de inicio de sesión de la consola de usuario IAM en la consola IAM mientras estás conectado como el rol voclabs. Para encontrar la contraseña, selecciona Detalles de AWS encima de estas instrucciones de laboratorio.

Para verificar la política vamos a la consola de IAM para identificar el enlace de inicio de sesión con IAM y el usuario paulo, la clave para paulo se encuentra en AWS Details como igw-0f1040871b30b2836

Prueba el acceso del usuario paulo a Amazon S3:

Verifica que puede acceder al data-bucket y descargar objetos de el.

Una vez se ingresa con el usuario paulo a través de una ventana de incognito, se puede corroborar que paulo tiene permiso para ingresar al bucket de S3, listar el contenido y descargar el documento “miarchivo.txt” creado y guardado previamente.

Análisis: El usuario paulo debería poder acceder al bucket de datos y a los objetos que contiene. Sin embargo, el usuario no debería poder acceder a los objetos de los demás buckets porque no tiene permisos suficientes.

Consejo para la resolución de problemas: Si el acceso del usuario paulo es diferente al descrito, vuelve a la pestaña del navegador en la que has iniciado sesión con el rol voclabs y modifica la configuración de la política de buckets. A continuación, vuelve a la pestaña del navegador en la que has iniciado sesión como usuario paulo y vuelve a realizar la prueba. Continúa este proceso hasta que consigas el nivel de acceso deseado para el usuario paulo.

Se cierra la sesión del usuario paulo en la consola. A continuación, se utiliza la misma ventana de navegador de incógnito o privada para probar el acceso del usuario mary a Amazon S3.

Prueba el acceso del usuario Mary a Amazon S3:

Comprueba que cuatro de los buckets muestran el estado de acceso Buckets y objetos no públicos, sin embargo el bucket de datos muestra el estado de acceso Error.

Preguntas para reflexionar: ¿Por qué el usuario mary ve el error «Permisos insuficientes para listar objetos»? ¿Puedes explicar por qué los usuarios mary y paulo están experimentando diferentes niveles de acceso a pesar de que tienen los mismos permisos S3 concedidos a ellos en la política IAM adjunta al grupo AccountManagerGroup IAM del que ambos son miembros?

Cuando termines las pruebas, cierra la sesión del usuario mary en la consola.

Tarea 1.2: Activar el versionado y el registro a nivel de objeto en un bucket

En esta tarea, se le pedirá que active el control de versiones y el registro a nivel de objeto en el cubo de datos. Con el control de versiones activado, puede realizar un seguimiento de todos los cambios en los objetos almacenados en el bucket y revertir cualquier objeto a una versión anterior si es necesario. El registro a nivel de objeto crea una pista de auditoría detallada de los objetos almacenados en un bucket, lo que le ayuda a detectar rápidamente incidentes de seguridad.

  • Asegúrese de que está utilizando la sesión del navegador en la que ha iniciado sesión en la consola como el rol IAM de voclabs.

  • Habilite el versionado en el cubo de datos.

Sugerencia: Es posible que haya practicado esto en el curso Cloud Architecting de AWS Academy.

Se ingresa a través de editar para habilitar el control de versiones.

  • Habilitar el registro de acceso al servidor en el bucket de datos

Configure los registros para que se escriban en el bucket s3-objects-access-log.

Añada /data-bucket como prefijo al final de la ruta del cubo de destino (no es necesario que coincida con el nombre real del cubo de datos).

  • Compruebe que la política de bucket para el bucket s3-objects-access-log incluye ahora una declaración para permitir que el servicio de registro de Amazon S3 escriba objetos en el bucket.

Consejo: En este punto, aunque es posible que desee probar el versionado y el registro a nivel de objeto, le recomendamos que espere hasta que haya habilitado S3 Inventory en la siguiente tarea. De este modo, podrá probar todas las nuevas configuraciones al mismo tiempo.

Se puede visualizar la política en el bucket para los logs.

Tarea 1.3: Implementar la funcionalidad S3 Inventory en un bucket

En esta tarea, se le desafía a habilitar la función de Inventario de S3 para supervisar los cambios en los objetos que se almacenan en un bucket de S3. S3 Inventory proporciona un informe programado de los metadatos y los cambios a nivel de objeto en sus objetos y buckets de S3. Mediante el uso de la función, puede realizar un seguimiento de los cambios en los objetos almacenados y detectar posibles incidentes de seguridad.

Habilite la función Inventario de S3 en el bucket de datos.

Consejo: Puede hacerlo en la pestaña Gestión del bucket.

Utilice la siguiente configuración:

Utilice Inventario como nombre de la configuración de inventario.

Incluir todas las versiones de objetos.

Establezca el bucket s3-inventory como destino de los detalles del informe.

Establezca Apache Parquet como formato de salida.

Seleccione los seis campos adicionales de metadatos Objeto.

Nota: AWS puede tardar hasta 48 horas en entregar el primer informe de inventario.

Para configurar S3 Inventory se ingresa al bucket y se dirige a la ventana Administración

En Administración baja hasta encontrar Configuraciones de inventario y se da click en crear configuración de inventario

Después de introducir las características, queda configurado S3 Inventory.

Tarea 1.4: Confirmar que el versionado funciona como se pretendía

En esta tarea, se le pedirá que acceda a la cuenta de AWS como usuario paulo y suba un objeto al bucket de datos. A continuación, deberá confirmar que el versionado está habilitado en el objeto. También se le pedirá que pruebe el acceso como usuario mary. En la siguiente tarea, analizarás los registros a nivel de objeto para ver las acciones que realizaste como diferentes usuarios en esta tarea.

En su ordenador, cree un nuevo archivo llamado customers.csv. A continuación, copie el siguiente texto en el archivo y guarde los cambios.

Inicie sesión en la cuenta de AWS como el usuario paulo y suba el archivo customers.csv al data-bucket.

Se inicia sesión con el usuario paulo

Se carga el archivo al bucket S3

Después de subir el archivo, comprueba la configuración de cifrado del lado del servidor que se aplica al objeto. Debería estar cifrado con claves administradas de Amazon S3 (SSE-S3).

Analice cuántas versiones de customers.csv existen navegando hasta la página de detalles de customers.csv y seleccionando la pestaña Versiones.

En su ordenador, edite el archivo customers.csv y añádale más datos. Por ejemplo, añada las dos filas de datos siguientes en la parte inferior del archivo.

En la ventana del navegador en la que ha iniciado sesión como usuario paulo, cargue la nueva versión del archivo customers.csv en el bucket de datos.

Después de subir el archivo, fíjate en las versiones que están disponibles.

Desde la consola de Amazon S3, abra la versión actual del archivo customers.csv para confirmar que contiene las cuatro filas de registros.

Asimismo, prueba a abrir la versión anterior para confirmar que solo contiene dos filas de registros.

Nota: Asegúrese de probar la apertura de ambas versiones. Estas acciones ayudan a generar datos de registro.

Inicie sesión como el usuario mary y realice acciones en la consola de Amazon S3 para generar eventos de registro.

Cierre la sesión del usuario paulo en la consola y, a continuación, inicie sesión como usuario mary.

Intenta acceder a los objetos del data-bucket.

Como has visto antes, el usuario mary no puede acceder a este bucket ni a su contenido.

Importante: Desconecta al usuario mary de la consola, y cierra la ventana de incógnito o privada.

Tarea 1.5: Confirmar el registro a nivel de objeto y consultar los registros de acceso mediante Athena

En esta tarea, deberás confirmar que el registro a nivel de objeto de S3 que habilitaste anteriormente está escribiendo correctamente datos de registro en S3. También utilizarás Athena para consultar estos registros.

En la sesión del navegador en la que has iniciado sesión en la consola con el rol voclabs, observa los objetos almacenados en el bucket s3-objects-access-log. Descarga uno de los objetos, ábrelo y revisa su contenido.

Cree una tabla Athena a partir de los registros de acceso. Para ello:

Crea un bucket de S3 llamado athena-results- donde es algún número aleatorio. Acepta la configuración por defecto del bucket.

En la consola de Athena abre el editor de consultas.

Antes de ejecutar consultas, configura el bucket athena-results para que sea la ubicación de los resultados de las consultas.

Nota: consulta la documentación de Amazon Athena para obtener los detalles necesarios.

A continuación, en la pestaña Editor, pega la siguiente consulta en el área de consultas:

cat('
CREATE EXTERNAL TABLE `default.bucket_logs`(
  `bucketowner` STRING, 
  `bucket_name` STRING, 
  `requestdatetime` STRING, 
  `remoteip` STRING, 
  `requester` STRING, 
  `requestid` STRING, 
  `operation` STRING, 
  `key` STRING, 
  `request_uri` STRING, 
  `httpstatus` STRING, 
  `errorcode` STRING, 
  `bytessent` BIGINT, 
  `objectsize` BIGINT, 
  `totaltime` STRING, 
  `turnaroundtime` STRING, 
  `referrer` STRING, 
  `useragent` STRING, 
  `versionid` STRING, 
  `hostid` STRING, 
  `sigv` STRING, 
  `ciphersuite` STRING, 
  `authtype` STRING, 
  `endpoint` STRING, 
  `tlsversion` STRING,
  `accesspointarn` STRING,
  `aclrequired` STRING)
ROW FORMAT SERDE 
  \'org.apache.hadoop.hive.serde2.RegexSerDe\' 
WITH SERDEPROPERTIES ( 
  \'input.regex\'=\'([^ ]*) ([^ ]*) \\\\[(.*?)\\\\] ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) (\\"[^\\"]*\\"|-) (-|[0-9]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) (\\"[^\\"]*\\"|-) ([^ ]*)(?: ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*))?.*$\') 
STORED AS INPUTFORMAT 
  \'org.apache.hadoop.mapred.TextInputFormat\' 
OUTPUTFORMAT 
  \'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat\'
LOCATION
  \'s3://s3-objects-access-log-<UNIQUE-ID>/\'#### <UNIQUE-ID> == 0f1040871b30b2836
')

Tras ejecutar la consulta:

Consultar la tabla para descubrir los detalles de acceso.

Previsualice el contenido de la tabla bucket_logs.

Observe que aparecen filas de datos de los registros a nivel de objeto de S3. Si no aparecen datos, es posible que deba esperar más tiempo antes de ejecutar la consulta.

Ejecute la siguiente consulta.

cat('SELECT requester, operation, key, httpstatus
 FROM "default"."bucket_logs" 
 WHERE requester LIKE 'arn:aws:iam%';)

Evaluación de costos para proteger Amazon S3

En esta fase, se creó y se aplicó una política a un bucket de S3. También se habilitó el versionado, el registro de acceso a servicios y el Inventario de S3 en un bucket. Por último, se utilizó Athenat para analizar los registros de acceso.

Pregunta: En este laboratorio, ¿el uso de estas características de seguridad de Amazon S3 supone un coste adicional en la cuenta? En caso afirmativo, ¿cuánto estima que costará?

Resumen de posibles costos por uso de características de S3 y Athena
Servicio Característica usada ¿Genera costo? Estimación en entorno de laboratorio
Amazon S3 Almacenamiento de versiones ✅ Sí Muy bajo (coste por almacenamiento adicional)
Amazon S3 Server access logging ✅ Sí Bajo (coste por logs en otro bucket)
Amazon S3 S3 Inventory ✅ Sí Bajo (por informe generado y almacenado)
Amazon Athena Consulta de logs con SQL ✅ Sí Aprox. $5 por TB escaneado (puede ser $0.01 por consulta pequeña)

Fase 2: Protección de las VPC

Después de asegurar los datos en Amazon S3, el equipo de liderazgo de AnyCompany Financial quiere que se centre en asegurar la red en la nube de AWS que aloja las aplicaciones críticas de la compañía. Son conscientes de los recientes incidentes de seguridad de la red y quieren asegurarse de que su red está protegida de accesos y ataques no autorizados. Su tarea es asegurar las nubes privadas virtuales (VPC) para los servidores web de la empresa.

Un empleado inexperto de AnyCompany Financial creó la LabVPC y la instancia WebServer preexistentes en el entorno de su proyecto de laboratorio. El empleado cometió algunos errores y el resultado es que la red no está configurada correctamente. En las tareas 2.1 a 2.4 usted analizará las configuraciones existentes y hará actualizaciones para corregir la configuración de la red.

El siguiente diagrama muestra los recursos que ya existen en el entorno del laboratorio y que utilizarás para las cinco primeras tareas de esta fase:

Tarea 2.1: Revisar LabVPC y sus recursos asociados

En esta tarea, se familiarizará con los recursos que ya existen en el entorno de laboratorio.

En la consola de Amazon VPC, compruebe que está observando la región us-east-1 y analice el mapa de recursos de la LabVPC existente.

Observa que contiene los siguientes recursos

  • Una subred denominada WebServerSubnet.

  • Una tabla de rutas. Esta es la tabla de rutas principal que se crea por defecto para cualquier VPC.

  • Una puerta de enlace a Internet.

Observe que la subred no está actualmente enrutada a la puerta de enlace de Internet.

En la consola IAM, localice el rol IAM VPCFlowLogsRole. Revise los permisos otorgados a este rol.

Análisis: Utilizarás esta política en la siguiente tarea. La política permitirá que la función VPC Flow Logs escriba registros de CloudWatch en un grupo de registros cuando se produzcan eventos en la VPC, como cuando alguien accede a un servidor web a través de HTTP.

El siguiente código es el asociado a la política que concede permisos al rol de IAM VPCFlowLogsRole.

{
    "Statement": [
        {
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:Describe*",
                "logs:PutLogEvents"
            ],
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

Esta política otorga permisos para trabajar con Amazon CloudWatch Logs, permite crear y administrar grupos y flujos de logs y enviarles eventos de log.

Interpretación de campos en la política
Campo Significado
“Effect”: “Allow” Permite las acciones indicadas.
“Resource”: “*” Se aplica a todos los recursos de CloudWatch Logs (sin restricciones).
“Action” Lista de acciones que se permiten (ver abajo).
Acciones permitidas por la política
Acción Descripción
logs:CreateLogGroup Permite crear un nuevo grupo de logs.
logs:CreateLogStream Permite crear un flujo de logs dentro de un grupo.
logs:Describe* Permite consultar la configuración de los grupos y flujos de logs (DescribeLogGroups, DescribeLogStreams, etc.).
logs:PutLogEvents Permite enviar entradas (logs) al flujo correspondiente.

En la consola de Amazon EC2, observa los detalles de la instancia WebServer.

Observe lo siguiente:

  • Se ha asignado una dirección IPv4 pública.
  • Se adjunta un rol IAM.
  • Se ha asociado un grupo de seguridad denominado Webserver Security Group.
  • La instancia se ejecuta en una subred denominada WebServer Subnet, que se encuentra en LabVPC.

Tarea 2.2: Crear un registro de flujo VPC

En esta tarea, se le desafía a crear un registro de flujo de VPC para LabVPC. La función Registros de flujo de VPC puede ayudarle a comprender cómo fluye el tráfico entrante y saliente a través de la VPC. La función también proporciona información de supervisión que le dará ideas sobre cómo proteger el servidor web, las subredes y la VPC en tareas posteriores.

Al final de esta tarea, habrá configurado la arquitectura que se muestra en el siguiente diagrama:

Cree un registro de flujo VPC para LabVPC.

  • Nombre el registro de flujo LabVPCFlowLogs.
  • Configúrelo para que capture todos los tipos de tráfico y envíe todos los datos de registro a CloudWatch Logs con un intervalo de agregación máximo de 1 minuto.
  • Cuando cree el registro de flujo, defina un nuevo grupo de registro de destino llamado LabVPCFlowLogs. Haga que utilice el rol IAM que observó en la tarea anterior.

Tarea 2.3: Acceda a la instancia WebServer desde Internet y revise los registros de flujo de la VPC en CloudWatch

En esta tarea, se le desafía a utilizar su navegador web para probar el acceso a la instancia EC2 WebServer a través del puerto 80 (HTTP). También se le desafía a probar el acceso al puerto 22 (SSH) utilizando el comando netcat, que probará si se permite el tráfico entrante. A continuación, se le retará a revisar el registro de flujo de la VPC para ver cómo se registraron estos intentos.

En una nueva pestaña del navegador, intente cargar la dirección IP pública de la instancia WebServer en http://.

La página no se carga. Esto era de esperar. Recuerde que un empleado inexperto de AnyCompany Financial cometió algunos errores y el resultado es que la red no está configurada correctamente.

Utilice el IDE de AWS Cloud9 Cloud9Instance para probar el acceso a la instancia WebServer.

Nota: Dado que está probando el acceso a la dirección IPv4 pública, la prueba se realiza desde Internet.

Para intentar acceder a la instancia a través del puerto HTTP estándar (80), ejecute el siguiente comando, sustituyendo el marcador de posición por el valor correcto:

nc -vz 80

nc -vz 22

En la consola de CloudWatch, mire el flujo de registros del grupo de registros LabVPCFlowLogs para comprobar que las acciones del paso anterior han generado registros.

Observe que el campo Mensaje de todas las entradas indica «RECHAZAR».

Sugerencia: El servicio de registro de flujo normalmente entrega los registros a CloudWatch Logs en 5 minutos. Sin embargo, la entrega de registros se realiza en base al mejor esfuerzo, por lo que las acciones de netcat pueden tardar más tiempo en aparecer en el registro.

###Filtre las entradas de registro para mostrar solo los eventos que se originaron en la dirección IP pública de la instancia de AWS Cloud9 que utilizó para ejecutar comandos anteriormente en la tarea.

Consejo: Para descubrir la dirección IP pública de la instancia de AWS Cloud9, ejecute el siguiente comando en el terminal de AWS Cloud9:

curl http://169.254.169.254/latest/meta-data/public-ipv4

Se obtiene la IP pública usada por el servicio Cloude9

Con la IP pública se pueden ver los logs generados por las acciones realizadas sobre los puertos 80 y 22.

Tarea 2.4: Configurar la tabla de rutas y los grupos de seguridad

En esta tarea, deberá crear una ruta para que el tráfico de Internet acceda a la subred WebServer a través de una puerta de enlace de Internet. Esto permitirá que el tráfico HTTP entrante sea dirigido a la instancia WebServer. También deberá modificar el grupo de seguridad asociado a la instancia WebServer para permitir el tráfico entrante en los puertos 22 (SSH) y 80 (HTTP).

Al final de esta tarea, habrá configurado la arquitectura que se muestra en el siguiente diagrama:

Modifique la tabla de rutas asociada a la subred WebServerSubnet. Añada una segunda ruta a la tabla de rutas para que el tráfico hacia y desde Internet (0.0.0.0/0) se dirija a la puerta de enlace de Internet LabVPCIG existente.

Pruebe de nuevo el acceso desde el puerto 80 a la instancia WebServer. Puede utilizar el comando nc en el IDE de AWS Cloud9 o intentar cargar la siguiente dirección en un navegador web: http://.

La conexión se agota o falla.

Análisis: Aunque ahora existe una ruta desde la VPC a la puerta de enlace de Internet, falta un paso de configuración para permitir el tráfico entrante de Internet a la instancia de WebServer. En el siguiente paso, modificará la configuración del grupo de seguridad para permitir este tráfico.

Modifique las reglas de entrada del grupo de seguridad asociado a la instancia WebServer para que la página web de la instancia sea accesible desde Internet y para que se permitan determinadas conexiones SSH a la misma. Para ello

  • Elimine las reglas de entrada que ya existan, a menos que permitan el tráfico a los puertos 22 u 80.

  • Añada una regla de entrada para el tráfico HTTP. La regla debe permitir el tráfico desde cualquier lugar al puerto TCP 80.

Añada una regla de entrada para permitir el acceso SSH a la instancia WebServer desde la instancia AWS Cloud9. Configure el origen de la regla para que coincida con la dirección IP pública de la instancia de AWS Cloud9. (Recuperó esta dirección IP en una tarea anterior).

Importante: Añada /32 a la dirección IP pública de la instancia de AWS Cloud9. /32 establece el rango CIDR exactamente en una dirección IP.

Consejo: Una práctica recomendada de seguridad es no permitir el acceso desde ninguna parte a través del puerto 22. Solo debe permitir el tráfico a través de este puerto desde fuentes que planee utilizar.

Añada una regla de entrada para permitir el acceso SSH a la instancia WebServer, de modo que pueda utilizar EC2 Instance Connect para conectarse a la instancia.

Para descubrir el intervalo de direcciones IP que debe utilizarse como origen de esta regla, ejecute los siguientes comandos en su IDE de AWS Cloud9:

sudo yum install -y jq

curl https://ip-ranges.amazonaws.com/ip-ranges.json| jq -r '.prefixes[] | select(.region=="us-east-1") | select(.service=="EC2_INSTANCE_CONNECT") | .ip_prefix'

Nota: AWS publica una lista de rangos de direcciones IP de AWS. El primer comando que ejecutó desde el bloque de código anterior instaló la utilidad jq en su instancia de AWS Cloud9. Esta utilidad se utiliza para transformar los datos JSON en un formato más legible e imprimirlos en la salida estándar. El segundo comando leyó el archivo ip-ranges.json y encontró los rangos de direcciones IP que utiliza EC2 Instance Connect en la región us-east-1, donde se ejecuta la instancia WebServer.

Ahora deberías tener tres reglas de entrada definidas para este grupo de seguridad.

Utilice el comando nc para probar de nuevo el acceso desde el puerto 22 a la instancia WebServer.

La prueba debería tener éxito.

Utilice su navegador web para probar el acceso desde el puerto 80 a la página web en la instancia WebServer.

La prueba debería tener éxito. Aparecerá el mensaje «Hello world from WebServer!».

Utilice EC2 Instance Connect para acceder a la instancia WebServer.

Después de conectarse, ejecute el siguiente comando: ping -c 3 www.amazon.com

Este comando comprueba si la instancia puede acceder a Internet. (En este caso, comprueba si la instancia puede acceder al sitio web público Amazon.com). Si recibe 64 bytes de datos a cambio tres veces, la prueba se ha realizado correctamente y la instancia WebServer puede acceder a Internet.

Asegure la WebServerSubnet con una ACL de red

En esta tarea, deberá configurar una lista de control de acceso (ACL) de red para proteger la subred en la que se ejecuta el servidor web. La ACL de red proporcionará una capa adicional de seguridad más allá del grupo de seguridad que ya ha configurado.

Al final de esta tarea, habrás configurado la arquitectura que se muestra en el siguiente diagrama:

En la consola de Amazon VPC, vaya a la página de detalles de la ACL de red asociada con WebServerSubnet en LabVPC.

Importante: La regla de entrada existente con el número 100 indica que se permite el tráfico de red entrante a la WebServerSubnet asociada con esta ACL de red. Esta es la configuración predeterminada.

Para comprobar si puede acceder al puerto 22 en la instancia WebServer, modifique la regla 100 de Permitir a Denegar. A continuación, ejecute el comando nc.

La conexión falla o se agota el tiempo de espera, lo que indica que el acceso ya no está permitido. Recuerde que esta prueba se realizó correctamente en el paso 4 de la tarea anterior.

Análisis: Las reglas ACL de red pueden bloquear el acceso a la red incluso cuando las reglas de entrada del grupo de seguridad permiten el acceso. Los grupos de seguridad pueden bloquear el tráfico de red a nivel de instancia, sin embargo, las ACL de red pueden bloquear el tráfico a nivel de subred y ofrecer así una capa adicional de seguridad.

Compruebe si puede acceder a la página web en http:// donde es la dirección IPv4 pública de la instancia WebServer.

Debería fallar por la misma razón.

Modifique la regla número 100 para permitir conexiones sólo en el puerto 22. A continuación, utilice netcat para confirmar si puede acceder al puerto 22.

La prueba debería tener éxito.

Vuelva a editar las reglas de entrada para la ACL de red. Añada una nueva regla que permita el tráfico HTTP desde cualquier lugar. Utilice 90 como número de regla.

A continuación, confirme si el tráfico HTTP está permitido intentando acceder a la página web en http:// donde es la dirección IPv4 pública de la instancia WebServer.

Deberías ver el mensaje «Hello world from WebServer!».

Tarea 2.6: Revisar NetworkFirewallVPC y sus recursos asociados

En esta fase hasta ahora, usted trabajó para asegurar LabVPC actualizando una tabla de rutas, ACL de red, y grupo de seguridad.

En las tareas restantes de esta fase, se le desafía a trabajar para asegurar una VPC diferente, llamada NetworkFirewallVPC. Se le retará a asegurar la VPC utilizando AWS Network Firewall. Las características de AWS Network Firewall le proporcionan otra herramienta para asegurar su red. En este proyecto se le retará a utilizarlo para lograr un resultado similar a cómo aseguró LabVPC utilizando grupos de seguridad y NACLs.

Advertencia: El Firewall de Red de AWS puede incurrir en un costo sustancial. Se recomienda completar las Tareas 2.6-2.10 con prontitud.

Observe los recursos y configuraciones existentes de NetworkFirewallVPC.

En la consola de la VPC seleccione NetworkFirewallVPC, y elija la pestaña Resource map. Observe que la VPC contiene lo siguiente

  • Una subred WebServer2Subnet. (LabVPC contenía una subred denominada WebServerSubnet).
  • Una segunda subred, denominada FirewallSubnet. (LabVPC sólo tenía una subred).
  • Una puerta de enlace a Internet, denominada NetworkFirewallIG. La tabla de rutas predeterminada (principal) ya está configurada para enrutar el tráfico entre WebServer2Subnet e Internet.

Todavía en la consola de Amazon VPC, observa la configuración ACL de red para NetworkFirewallVPC.

Existen las reglas entrantes por defecto. La regla 100 permite todo el tráfico de todas las fuentes.

En la consola de Amazon EC2, observa la configuración de la instancia WebServer2 y copia la dirección IPv4 pública para utilizarla en el siguiente paso.

Observa que esta instancia se ejecuta en WebServer2Subnet.

Dirección IPv4 pública: 54.175.93.60

Observe que se permite el tráfico entrante desde cualquier lugar (0.0.0.0/0) a los puertos 80 (HTTP), 22 (SSH) y 8080.

Confirme el acceso a la instancia WebServer2 en los puertos 80 y 22.

  • Verifique el acceso HTTP utilizando un navegador.

Debería ver el mensaje «Hello world from WebServer2!».

  • Verifique el acceso SSH utilizando el comando nc en el terminal de AWS Cloud9.

El intento debería tener éxito.

Inicie un sitio web adicional que se ejecute en el puerto 8080 de WebServer2 y pruebe el acceso.

Utilice EC2 Instance Connect para conectarse a la instancia WebServer2.

Después de conectarse, ejecute el siguiente comando.

python3 -m http.server 8080 &

Después de ejecutar el comando, pulse Intro para volver al indicador.

Mantenga abierta la sesión de EC2 Instance Connect.

En otra pestaña del navegador, intente cargar http://:8080

El intento debería tener éxito y debería ver el mensaje «Hello world from WebServer2 port 8080!».

Actividad de diagramación

Al siguiente diagrama le faltan detalles, pero muestra lo que construirás en las tareas restantes de esta fase.

  • En la tarea 2.7, crearás el punto final del firewall.
  • En la tarea 2.8, creará todas las tablas de rutas necesarias para enrutar el tráfico hacia y desde Internet a través del punto final del firewall.
  • Después de configurar el registro del firewallbde red en la tarea 2.9, configurará las reglas del firewall de red en la tarea 2.10.

Tu reto es completar los detalles de configuración que faltan (incluyendo destinos, objetivos, protocolos, puertos, acciones y bloques CIDR para las subredes) en el diagrama. Asegúrate de rellenar las cuatro tablas y la información del bloque CIDR que falta para las dos subredes. Puedes descargar una copia del diagrama para rellenarlo. Nota: requiere que tengas acceso a Microsoft PowerPoint.

Prepárese para explicar cómo funciona la configuración de enrutamiento de la red, en términos de tráfico desde Internet enrutado a WebServer2 y tráfico desde WebServer2 enrutado a Internet.

Tarea 2.7: Crear un firewall de red

En esta tarea, debes crear un firewall de red para NetworkFirewallVPC, que aún no has utilizado en este proyecto.

En la consola de Amazon VPC, crea un firewall llamado NetworkFirewall.

  • Asócialo con NetworkFirewallVPC. Cree el firewall en la zona de disponibilidad us-east-1a para FirewallSubnet y el tipo de dirección IP IPv4.

  • Asigne a la política de firewallel nombre FirewallPolicy.

  • En Delete protection quite la marca de Enable. En Subnet change protection (Protección contra cambios de subred), quite la marca de Enable (Activar).

  • Espere a que el firewall alcance el estado Listo antes de continuar con el siguiente paso. El proceso tarda aproximadamente 3 minutos en completarse.

Consejo: Puede refrescar la pestaña del navegador periódicamente para conocer el estado más rápidamente.

Tarea 2.8: Crear tablas de enrutamiento

En esta tarea, usted deberá crear y configurar tres nuevas tablas de rutas, incluyendo una para cada subred en el NetworkFirewallVPC y una para manejar el tráfico entrante (ingress) para el gateway de internet en el NetworkFirewallVPC.

Cree una nueva tabla de rutas denominada IGW-Ingress-Route-Table en NetworkFirewallVPC.

Edite la tabla de rutas para añadir una nueva ruta.

  • Configure el destino para que sea el bloque CIDR de la subred en la que se ejecuta la instancia WebServer2.

  • Establezca el destino en el único punto final del equilibrador de carga de puerta de enlace que esté disponible.

Añada una asociación de borde a IGW-Ingress-Route-Table para que la pasarela de Internet NetworkFirewallIG esté asociada a la tabla de enrutamiento.

Cree otra tabla de rutas en NetworkFirewallVPC para FirewallSubnet.

  • Asigne a la tabla de rutas el nombre Firewall-Route-Table.

  • Añada una ruta para que el tráfico 0.0.0.0/0 se enrute a NetworkFirewallIG.

  • Cree una asociación explícita entre la subred FirewallSubnet y la tabla de enrutamiento.

Cree otra tabla de rutas en NetworkFirewallVPC para la subred Webserver2.

  • Asigne a la tabla de rutas el nombre WebServer2-Route-Table.

  • Añada una ruta para que el tráfico 0.0.0.0/0 se enrute al Gateway Load Balancer Endpoint.

  • Cree una asociación explícita entre la subred Webserver2Subnet y la tabla de rutas.

Tarea 2.9: Configurar el registro para el cortafuegos de red

En esta tarea, se le pedirá que configure el registro para el cortafuegos de red para que pueda analizar los detalles de las solicitudes de tráfico de red.

Cree un grupo de registro CloudWatch llamado NetworkFirewallVPCLogs con una configuración de retención de 6 meses.

En la configuración del NetworkFirewall que ha creado, vaya al área Detalles del firewall y configure el registro de tipo Alerta y Flujo. Configure el destino del registro para que ambos tipos de registro utilicen el grupo de registro NetworkFirewallVPCLogs CloudWatch.

Pruebe la configuración de registro intentando cargar el sitio web de la instancia WebServer2 en el puerto 80 en una nueva pestaña del navegador.

Importante: El navegador expirará cuando intente acceder a WebServer2 en la dirección IPv4 pública. Esto se debe a que la política del cortafuegos de la red aún no está configurada para permitir el tráfico HTTP en el puerto 80. Recuerde que pudo acceder al sitio web al inicio de la tarea 2.6; sin embargo, luego creó el firewall de red en la tarea 2.7.

En la consola de CloudWatch, busque eventos de registro en el grupo de registros NetworkFirewallVPCLogs. Filtre los eventos de registro por su dirección IP pública para encontrar las entradas de registro resultantes de la prueba que ejecutó en el paso anterior.

Nota: El tiempo de entrega de los registros del firewall de red varía y tiene una duración media de 3 a 6 minutos. Para obtener más información, consulte Logging Network Traffic from AWS Network Firewall en la AWS Network Firewall Developer Guide.

Consejo: Si no conoce su dirección IP pública, puede utilizar un sitio como https://www.whatismyip.com para descubrirla.

Se puede hallar a través de Cloude9 con el comando

curl https://checkip.amazonaws.com

IP pública: 54.92.193.65

Análisis: Las entradas de registro de su búsqueda deben mostrar su dirección IP pública como src_ip (para la entrada de registro de solicitud entrante) o dest_ip (para la entrada de registro de respuesta saliente). La entrada de registro de la solicitud entrante también debería mostrar tu intento de cargar el sitio web en un dest_port de puerto 80 y la entrada de registro de la respuesta saliente debería mostrar un src_port de puerto 80.

Tarea 2.10: Configurar la política del firewall y probar el acceso

Cuando creó por primera vez el firewall de red, definió una política vacía. Por defecto, la política vacía bloquea todo el tráfico, razón por la cual falló su intento de cargar el sitio web WebServer2 en la tarea anterior.

En esta tarea, se le pedirá que defina y añada un grupo de reglas de estado a la política del firewall de red. Con esta política, el tráfico hacia y desde Internet y el NetworkFirewallVPC será monitorizado y gestionado. Se permitirá el acceso a través de puertos específicos, y se denegará específicamente el acceso a través de otros puertos.

Vaya a la página de detalles del NetworkFirewall y comience a crear el grupo de reglas.

  • En el panel de navegación de la consola de Amazon VPC, seleccione Firewalls.
  • Seleccione el enlace de nombre para NetworkFirewall.
  • En la sección Descripción general de la parte superior de la página, en Paso 2, seleccione Añadir grupos de reglas > Crear grupo de reglas con estado.

Configure el grupo de reglas con estado con el nombre NetworkFirewallVPCRuleGroup y una capacidad de 100. Utilice los demás valores predeterminados.

Configure el grupo de reglas para que tenga cinco reglas con los siguientes requisitos:

  • Primera regla: Utilice el protocolo TCP. Establezca el puerto de destino en 8080 y la acción en Drop.

Importante: Tenga en cuenta que la acción para la primera regla es diferente de las otras reglas.

  • Segunda regla: Utiliza el protocolo TCP. Establezca el puerto de destino en 80 y la acción en Pasar.

  • Tercera regla: Utilice el protocolo TCP. Establezca el puerto de destino en 22 y la acción en Pasar.

  • Cuarta regla: Utilizar el protocolo TCP. Establezca el puerto de destino en 443 y la acción en Pasar.

  • Quinta regla: Utilizar el protocolo ICMP. Establezca el puerto de destino en cualquiera y la acción en Pasar.

Importante: Tenga en cuenta que el protocolo de la quinta regla es diferente al de las otras reglas.

Una vez configuradas las reglas, seleccione Crear y añadir a la política.

Pruebe las reglas del Firewall.

  • En una nueva pestaña del navegador, cargue la página web alojada en WebServer2 utilizando la dirección IP pública.

El intento debería tener éxito porque la política del firewall ahora contiene una regla que permite el tráfico en el puerto TCP 80.

  • En el IDE de AWS Cloud9, utilice el comando netcat para probar el acceso SSH (puerto 22) a WebServer2.

El intento debería tener éxito.

Utilice EC2 Instance Connect para conectarse a WebServer2. El intento debería tener éxito. Después de conectarse, ejecute los siguientes comandos en la sesión:

ping -c 3 www.amazon.com

sudo netstat -tulpn | grep -i listen

En la consola de CloudWatch, observe las entradas de registro del Firewall de red creadas por sus pruebas en el paso anterior.

Nota: Asegúrese de eliminar todos los recursos asociados con esta sección.

  • Eliminar la asociación de borde en IGW-Ingress-RouteTable
  • Eliminar IGW-Ingress-RouteTable

Eliminar la asociación de subred en Firewall-Route-Table

Eliminar Firewall-Route-Table

Eliminar asociación de subred en WebServer2-Route-Table

Eliminar WebServer2-Route-Table

Eliminar la configuración de registro de NetworkFirewall

Eliminar NetworkFirewall

Eliminar política de Firewall

Eliminar el grupo de reglas del Firewall

Eliminar logs de CloudWatch (opcional)

Costos de este proceso

Estimación de costos para proteger una VPC con un Firewall de red

AnyCompany Financial le ha solicitado una estimación del coste de implantación de un cortafuegos de red en la región us-east-1. La empresa ha facilitado la siguiente información sobre el uso previsto.

Utilice la calculadora de precios de AWS y la información de la tabla anterior para crear una estimación de precios detallada para el firewall de red.

Después de crear la estimación, expórtela:

  • Seleccione Exportar y, a continuación, elija exportar como archivo .csv o .pdf.
  • Cuando se le solicite, seleccione Aceptar y descargue el archivo.

Fase 3: Protección de los recursos de AWS mediante AWS KMS

El departamento jurídico de AnyCompany Financial recibió un aviso de la Corporación Federal de Seguros de Depósitos (FDIC) de EE. UU. de que la empresa necesita cifrar la información confidencial, como la PII, los números de tarjetas de crédito y los números de la seguridad social. El departamento jurídico se puso en contacto con su jefe, el director de TI, y le encargaron que implementara el cifrado y la tokenización para cumplir las normas reglamentarias.

En concreto, la empresa quiere hacer lo siguiente

Al final de esta fase, habrá creado la arquitectura que se muestra en el siguiente diagrama.

Tarea 3.1: Crear una clave gestionada por el cliente y configurar la rotación de claves

En esta tarea, creará una clave administrada por el cliente de AWS KMS. A continuación, configurará la rotación automática de la clave. En tareas posteriores, deberá utilizar esta clave para proteger los datos almacenados en su cuenta.

  • Cree una clave administrada por el cliente de AWS KMS con el alias (nombre) de MyKMSKey. Mantenga la configuración predeterminada, excepto la concesión de los permisos de administrador de claves y usuario de claves al rol voclabs.

  • Configure la rotación de claves de AWS KMS en la nueva clave para que se rote automáticamente cada año.

Tarea 3.2: Actualizar la política de claves de AWS KMS y analizar una política de IAM

En esta tarea, debe modificar la política de la clave AWS KMS que ha creado para que el usuario sofia esté autorizado a utilizar la clave. También debe analizar la política de IAM que controla lo que el usuario sofia puede hacer en la cuenta de AWS.

Modifique la directiva de claves para MyKMSKey de modo que permita al usuario IAM sofia utilizar la clave.

Sugerencia: La política de claves existente contiene una declaración con un valor de ID de declaración (SID) de Permitir el uso de la clave. Añada una entidad de seguridad adicional a esta declaración para que la entidad de seguridad permita tanto al rol IAM de voclabs como al usuario IAM de sofia utilizar la clave. Después de modificar la política de claves, el código dentro del elemento Principal {}, debe coincidir con lo siguiente (donde ACCOUNT-NUMBER es el número de cuenta real):

xxxxxxxxxx
"AWS": [
  "arn:aws:iam::ACCOUNT-NUMBER:role/voclabs",
  "arn:aws:iam::ACCOUNT-NUMBER:user/sofia"
]

  • Analice la política IAM PolicyForFinancialAdvisors que existe en su cuenta.

Análisis: La política permite el control total de todos los buckets de S3 dentro de la cuenta y otorga la capacidad de cifrar y descifrar objetos. Esta política se adjunta al grupo IAM FinancialAdvisorGroup, al que pertenece el usuario sofia.

Tarea 3.3: Utilizar AWS KMS para cifrar datos en Amazon S3

En esta tarea, se le desafía a utilizar la clave de AWS KMS que creó para cifrar un objeto en el bucket de S3 de data-bucket. A continuación, probará el acceso al objeto.

Modifique la configuración de cifrado en el bucket S3 de data-bucket que creó en la fase 1 para que el bucket utilice el cifrado SSE-KMS.

En su ordenador, cree un nuevo archivo denominado loan-data.csv que podrá utilizar para probar el cifrado. Después de crear el archivo en un editor de texto, pegue los siguientes datos en el archivo y guarde los cambios.

En una ventana de navegador de incógnito o privada, inicie sesión en la consola de administración de AWS como el usuario IAM sofia.

Consejo: Puede encontrar el enlace de inicio de sesión en la consola de usuario IAM mientras está conectado como el rol voclabs.

  • Para encontrar la contraseña, selecciona Detalles de AWS encima de estas instrucciones de laboratorio.

  • Después de iniciar sesión, sube el archivo loan-data.csv al data-bucket.

La carga debería realizarse correctamente.

Análisis: La carga se ha realizado correctamente porque Sofía tiene permisos para cargar objetos, concedidos a través de la política de bucket aplicada al data-bucket. También tiene permisos a través de una política de IAM para utilizar las claves de AWS KMS. Por último, la clave específica de AWS KMS que utiliza el bucket de datos para cifrar los datos que se almacenan en él tiene una política adjunta que permite al usuario sofia utilizar la clave. La combinación de las tres configuraciones de seguridad permite al usuario completar la acción.

  • En la consola de Amazon S3, seleccione el enlace del objeto loan-data.csv y analice la configuración de cifrado del lado del servidor que se le aplica.

El tipo de cifrado del objeto es SSE-KMS.

Mientras está conectado como usuario sofia, intente abrir o descargar el archivo loan-data.csv.

El intento debería tener éxito.

Cierre la sesión del usuario sofia en la consola y, a continuación, inicie sesión como usuario paulo. A continuación, intente abrir o descargar el objeto loan-data.csv.

El intento debería fallar.

Cuando termine la prueba, cierre la sesión y salga de la pestaña de incógnito del navegador.

Análisis: Esto demuestra cómo el cifrado de AWS KMS proporciona una capa adicional de seguridad más allá de la seguridad que proporcionan las políticas de bucket de S3 y las políticas de IAM. Sofía tiene permisos para abrir el archivo, pero Paulo no. Paulo sí tiene permiso para acceder al bucket y descargar otros objetos del bucket, concedido a él en la política del bucket de S3 y en la política de IAM adjunta al grupo de IAM del que es miembro. Sin embargo, la política IAM no le concede el acceso al servicio AWS KMS que tiene Sofia. En la tarea 3.2, añadiste a Sofia a la política de claves KMS utilizada por el data-bucket, pero no añadiste a Paulo a ella. Debido a estas configuraciones de seguridad combinadas, Paulo no puede ver el archivo cifrado.

Pregunta: ¿Puede imaginar un escenario en el que las políticas de seguridad que aplicó serían útiles para AnyCompany Financial?

Si. AnyCompany Financial es una gran empresa con cientos de equipos asociados. Uno de esos equipos es el de ciencia y analítica datos. Actualmente ese equipo se encuentra desarrollando una aplicación para visualizar datos de una ciudad recopilados mediante sensor y almacenados en una base de datos que se guarda en un bucket de S3. Se requiere otorgar permisos a la ingeniera de datos (sofia) para descargar la base de datos en formato (CSV), sin embargo, se requiere que el enlace de marketing (paulo) no tenga permisos para descargar esta base de datos ya que él ingresa a este bucket de S3 a descargar otra información.

Tarea 3.4: Utilizar AWS KMS para cifrar el volumen raíz de una instancia EC2.

En esta tarea, se te reta a utilizar la clave AWS KMS de nuevo, pero ahora la utilizarás para cifrar el volumen raíz de una nueva instancia EC2.

Mientras inicias sesión con el rol voclabs, crea una nueva instancia EC2. Mantenga la configuración predeterminada, excepto lo siguiente:

  • Nombra la instancia EncryptedInstance

  • Elija Amazon Linux 2 AMI como AMI y t2.micro como tipo de instancia.

Importante: Debe elegir Amazon Linux 2 (no Amazon Linux 2023) como tipo de AMI.

  • Para el par de claves, elige vockey.

  • Edite la configuración de red y despliéguela en NetworkFirewallVPC en WebServerSubnet2. Utilice el WebServer2SecurityGroup existente.

  • En Configurar opciones de almacenamiento, seleccione Avanzadas y elija cifrar el volumen raíz de la AMI mediante MyKMSKey.

  • En los detalles avanzados, asigne WebServerInstanceProfile como perfil de instancia IAM.

En la página de detalles de EncryptedInstance, seleccione la pestaña Storage y compruebe que el volumen raíz de la instancia está cifrado.

Tarea 3.5: Utilizar el cifrado de sobres de AWS KMS para cifrar datos in situ

En esta tarea, se le desafía a utilizar la interfaz de línea de comandos de AWS (CLI de AWS) para cifrar datos en el lugar utilizando la clave de AWS KMS. También se le desafía a ver cómo descifrar los datos cifrados. Para mayor comodidad, utilizará la instancia WebServer2 de la fase 2 para completar esta tarea.

Utilice EC2 Instance Connect para conectarse a WebServer2.

Para crear un archivo que luego tratará de cifrar, ejecute los siguientes comandos en la sesión de EC2 Instance Connect:

echo "Let's encrypt these file contents. Sensitive data here." > data_unencrypted.txt

cat data_unencrypted.txt

Utilice la CLI de AWS para generar una clave de datos a partir de la clave de AWS KMS.

Nota: Las instancias de Amazon Linux 2023, como WebServer2, tienen el software cliente de la CLI de AWS preinstalado. Además, el perfil de instancia (rol IAM WebServerRole) que se adjunta a la instancia WebServer2 concede los permisos de AWS KMS necesarios para completar esta tarea. Por último, una de las reglas de estado que ha definido en el firewall de red permite la comunicación a través del puerto 443, incluidas las respuestas, que es necesario para el acceso a la CLI de AWS.

En la sesión WebServer2 EC2 Instance Connect, ejecute el siguiente comando para probar el acceso a AWS KMS:

aws kms list-keys

El comando devuelve una lista de claves AWS KMS en la cuenta.

Consejo: Si no recibes respuesta, comprueba que has configurado correctamente una regla en NetworkFirewallVPCRuleGroup que permita el tráfico a través del puerto 443 (como se mencionó en la fase anterior), que es lo que necesita la CLI de AWS.

A continuación, ejecuta los siguientes comandos para generar una clave de datos para MyKMSKey, guárdala en una variable bash y, a continuación, hazte eco de los detalles de la clave de datos en un bonito formato JSON:

result=$(aws kms generate-data-key --key-id alias/MyKMSKey --key-spec AES_256)


echo $result | python3 -m json.tool

Análisis: CiphertextBlob es una clave de datos que acaba de generar. Está cifrada con la clave MyKMSKey gestionada por el cliente, que creó en la tarea 3.1. Querrá almacenar esta clave de datos de forma persistente para poder descifrar y cifrar archivos con ella. El texto sin formato es la clave de datos sin cifrar.

Guarde la clave de datos en el disco.

Para exportar el valor CiphertextBlob del resultado y guardarlo en un archivo de texto en formato codificado en base64, ejecute los siguientes comandos:

dk_cipher=$(echo $result| jq '.CiphertextBlob' | cut -d '"' -f2)

echo $dk_cipher

echo $dk_cipher | base64 --decode > data_key_ciphertext

Para comprobar que la clave de datos se almacena en formato cifrado (no legible por humanos), ejecute el siguiente comando:

cat data_key_ciphertext

Consejo: Puedes regenerar la versión en texto plano de la clave de datos a partir del texto cifrado codificado en base64 en cualquier momento, como se demuestra ejecutando el siguiente comando:

aws kms decrypt --ciphertext-blob fileb://./data_key_ciphertext --query Plaintext --output text

Ejecute de nuevo el comando anterior pero guarde también el resultado en un archivo en formato codificado en base64:

aws kms decrypt --ciphertext-blob fileb://./data_key_ciphertext --query Plaintext --output text | base64 --decode > data_key_plaintext_encrypted

Utiliza la clave de datos para cifrar el archivo que creaste anteriormente.

Para cifrar el archivo data_unencrypted.txt, que creaste en el paso anterior, ejecuta el siguiente comando:

openssl enc -aes-256-cbc -salt -pbkdf2 -in data_unencrypted.txt -out data_encrypted -pass file:data_key_plaintext_encrypted

Desgraciadamente, no es legible para los humanos.

  • Para eliminar la versión no cifrada del archivo, ejecute el siguiente comando:
rm data_unencrypted.txt

Análisis: Hasta ahora en esta tarea, has generado una clave de datos a partir de tu clave KMS y la has almacenado en un formato cifrado. A continuación, has utilizado la clave de datos para cifrar un archivo sin cifrar (datos_sin_cifrar.txt). Por último, has eliminado el archivo sin cifrar. A continuación, verás cómo descifrar el archivo que has cifrado.

  • Descifra el archivo para probar que los datos son recuperables.

Para descifrar los datos y guardarlos como un nuevo archivo llamado data_decrypted, ejecute el siguiente comando:

openssl enc -d -aes-256-cbc -pbkdf2 -in data_encrypted -out data_decrypted.txt -pass file:./data_key_plaintext_encrypted

Para imprimir los resultados y asegurarse de que los datos son ahora legibles, ejecute el siguiente comando:

cat data_decrypted.txt

  • Deberías ver el texto del archivo original data_unencrypted.txt.

Ahora has visto cómo es posible utilizar el cifrado de sobres para cifrar datos en reposo.

Tarea 3.6: Utilizar AWS KMS para cifrar un secreto de Secrets Manager.

En esta tarea, deberá crear un par clave-valor (un secreto), que cifrará con su clave de AWS KMS y almacenará en Secrets Manager. A continuación, deberá comprobar que puede recuperar el secreto mediante la CLI de AWS.

En la consola del Gestor de Secretos, crea un nuevo secreto de tipo Otro tipo de secreto.

  • Dele una clave de secreto con el valor my secret data.

  • Cífrelo con su MyKMSKey y nombre el secreto mysecret.

Sugerencia: Observe que la consola proporciona un código de ejemplo que podría utilizar para acceder a este secreto más adelante utilizando un lenguaje de programación.

Utilice EC2 Instance Connect para conectarse a la instancia WebServer2 y, a continuación, utilice la CLI de AWS para recuperar el secreto.

Consejo: Comience invocando el comando aws secretsmanager list-secrets. A continuación, utilice el comando aws secretsmanager get-secret-value para recuperar el secreto.

Deberías ver los datos del par clave-valor del secreto en los resultados.

Nota: En un escenario real, almacenarías información que es más sensible, como credenciales de bases de datos, en Secrets Manager. Si estuviera ejecutando una aplicación web en una instancia de EC2, podría implementar código en la aplicación para acceder y descifrar el secreto y, a continuación, utilizar el secreto descifrado para conectarse a la base de datos. De esta forma, si el código de tu aplicación se viera comprometido, las credenciales de la base de datos permanecerían seguras.

Evaluación de los costes de utilización de AWS KMS

En esta fase, ha creado una clave administrada por el cliente en AWS KMS, ha configurado la rotación de claves, ha configurado un bucket de S3 para utilizar la clave de AWS KMS para cifrar objetos, ha cifrado el volumen raíz de EBS de una instancia de EC2, ha utilizado el cifrado de sobres de AWS KMS y ha utilizado AWS KMS con Secrets Manager.

Pregunta: En este laboratorio, ¿el uso de AWS KMS supone un coste adicional en la cuenta? En caso afirmativo, ¿qué uso se le cobraría?

Sugerencia: Utilice la página de precios de AWS Key Management Service como ayuda para responder a la pregunta.

Sí, el uso de AWS KMS en este laboratorio puede generar cargos, especialmente por el almacenamiento de la clave administrada por el cliente y por cada operación criptográfica (encriptar, desencriptar, generar claves). El total depende de la cantidad de operaciones realizadas.Administrar una clave durante 1 mes puede costar aproximadamente 1 USD y con capacidad de tramitar gratuitamente hasta 20.000 solicitudes a la API para crear o aprovisionar claves de cifrado. A partir de allí tiene costo adicional.

Fase 4: Control y registro

El equipo directivo de AnyCompany Financial recibió informes sobre una nueva brecha de seguridad en uno de sus mayores competidores. La empresa quiere asegurarse de que está preparada para detectar y responder a cualquier incidente de seguridad futuro. El director de TI le ha pedido que implemente una solución de supervisión y registro para detectar incidentes de seguridad, de modo que la empresa pueda responder con prontitud.

La solución debe hacer lo siguiente:

La siguiente tabla describe las tareas que implementará en esta fase.

Tareas de Monitoreo y Auditoría en AWS
TAREA DETALLE
1 Crear un trail en AWS CloudTrail para registrar llamadas a la API de Amazon S3.
2 Configurar CloudWatch Logs para monitorear los logs de autenticación de la instancia WebServer.
3 Crear una alarma en CloudWatch para notificar al equipo cuando se intente acceder a la instancia WebServer.
4 Usar AWS Config para asegurar que los buckets S3 tengan habilitado el registro de objetos al ser creados.

Tarea 4.1: Utilizar CloudTrail para registrar las llamadas a la API de Amazon S3.

En esta tarea, se le pedirá que utilice CloudTrail para registrar las llamadas a la API que se realizan a los buckets de Amazon S3. Esta información proporcionará una pista de auditoría para rastrear cuándo se crean, modifican o leen objetos de S3.

Al final de esta tarea, habrá configurado la arquitectura que se muestra en el siguiente diagrama:

Cree una ruta CloudTrail con las siguientes características:

Importante: Después de cargar la consola CloudTrail, para abrir el panel de navegación, seleccione el icono de menú (). A continuación, elija Rutas y luego seleccione Crear ruta. No elija la opción para crear una ruta desde la página principal de la consola de CloudTrail. Esta opción le llevará al asistente de creación rápida de rutas, que no le dará la oportunidad de especificar algunas de las configuraciones que desee.

  • Nombre la ruta data-bucket-reads-writes

  • Almacene los registros en el bucket S3 existente cloudtrail-logs.

  • Deshabilite el cifrado SSM-KMS.

  • Registre tanto los eventos de gestión como los eventos de datos en el registro.

  • Para los eventos de datos, registre todos los eventos de S3.

En su ordenador, cree un archivo llamado customer-data.csv. A continuación, en un editor de texto, pegue los siguientes datos en el archivo y guarde los cambios.

Sube el archivo customer-data.csv a data-bucket.

Después de subir el archivo, ábralo en la consola de Amazon S3.

Nota: Las acciones que realice en este paso crearán entradas en el rastro de CloudTrail, que serán importantes para los pasos siguientes.

Utilice la consola de CloudTrail para crear una tabla Athena que describa el formato de los datos en el bucket S3 cloudtrail-logs.

Consulta la documentación de CloudTrail para saber cómo hacerlo.

Antes de crear la tabla, asegúrate de configurar la ubicación de almacenamiento para que sea el bucket cloudtrail-logs.

Análisis: Se genera una consulta de tabla CREATE EXTERNAL TABLE en Athena. Cuando ejecutes la consulta en el siguiente paso, se creará la tabla. La tabla definirá la estructura de los datos que se están escribiendo en el bucket S3 de cloudtrail-logs para que puedas consultarlos más adelante. Utilizarás Athena en esta tarea para analizar los registros de CloudTrail, de la misma forma que utilizaste Athena para analizar los registros a nivel de objeto de S3 en la fase 1.

Cree y ejecute una consulta de Athena para recuperar los datos de registro de eventos de CloudTrail para cuando subió el archivo customer-data.csv a Amazon S3.

  • En la consola de Athena, obtenga una vista previa de la tabla cloudtrail_logs que ya debería existir desde que la creó en el paso anterior.

Compruebe que aparecen 10 filas de datos en el área Resultados.

Importante: Normalmente, CloudTrail entrega eventos en los 5 minutos siguientes a una llamada a la API. Es posible que tenga que esperar unos minutos y luego intentar previsualizar la tabla de nuevo antes de que devuelva los resultados. Verifique que se devuelven los datos en la vista previa antes de continuar con el siguiente paso.

  • Ejecute la consulta que se muestra a continuación en una nueva pestaña de consulta después de sustituir por el nombre de tabla correcto:
SELECT eventtime, useridentity.principalid, requestparameters, eventname
FROM <table name>
WHERE
    eventname in ('PutObject') AND
    requestparameters LIKE '%customer-data.csv%'
limit 10;

Lamentablemente, después de múltiples intentos, no fue posible visualizar los logs en Athena.

Desafío: Cree una consulta Athena similar para recuperar la información de registro de CloudTrail para cuando abrió (o descargó) el archivo customer-data.csv. En los resultados, incluya la dirección IP del principal que recuperó el archivo y el navegador que se utilizó.

Tarea 4.2: Utilizar CloudWatch Logs para supervisar registros seguros

AnyCompany Financial ha estado trabajando con un proveedor para diseñar y gestionar su sitio web. El proveedor ha solicitado acceso SSH para diseñar y gestionar el sitio web. La política de la empresa no permite el acceso directo a través de SSH a los servidores web de producción, pero se puede proporcionar acceso a un servidor web de desarrollo llamado EncryptedInstance.

Se le ha pedido que cree una solución para monitorizar el acceso a EncryptedInstance. En esta tarea, configurará CloudWatch Logs para supervisar el acceso SSH a la instancia, de forma que su empresa pueda saber quién accede al servidor, desde dónde accede, cuándo accede y qué acciones realiza.

Al final de esta tarea, habrá configurado la arquitectura que se muestra en el siguiente diagrama.

Cree un grupo de registros de CloudWatch llamado EncryptedInstanceSecureLogs con todos los ajustes predeterminados.

Utilice EC2 Instance Connect para conectarse a EncryptedInstance.

Después de conectarse, ejecute los siguientes comandos para instalar el agente de CloudWatch y un demonio de Linux llamado collectd, que utilizará el agente de CloudWatch:

sudo yum install -y amazon-cloudwatch-agent
sudo amazon-linux-extras install -y collectd

El agente y el software collectd deberían haberse instalado correctamente.

Descargue y configure un archivo JSON que proporciona detalles de configuración para el agente de CloudWatch.

Para descargar el archivo de plantilla, ejecute el siguiente comando en la sesión de EC2 Instance Connect:

sudo wget https://aws-tc-largeobjects.s3.us-west-2.amazonaws.com/CUR-TF-200-ACCAP6-91948/capstone-6-security/s3/config.json -P /opt/aws/amazon-cloudwatch-agent/bin/

Para imprimir la plantilla de archivo y poder ver lo que especifica, ejecute el siguiente comando:

sudo cat /opt/aws/amazon-cloudwatch-agent/bin/config.json

Análisis: El archivo indica al agente de CloudWatch que recopile entradas de registro del registro seguro estándar de Linux, que se encuentra en la carpeta /var/log de la instancia de EncryptedInstance. Los registros que se encuentren allí se reenviarán al grupo de registros de CloudWatch EncryptedInstanceSecureLogs. A medida que se recopilen entradas, se escribirán en nuevos flujos de registro.

Inicia el agente CloudWatch y confirme que se está ejecutando.

  • Para iniciar el agente, ejecute el siguiente comando:
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

  • Para verificar el estado del agente de CloudWatch, ejecute el siguiente comando:
sudo service amazon-cloudwatch-agent status

  • Para confirmar que el agente de CloudWatch es capaz de alcanzar el servicio CloudWatch en su cuenta de AWS, ejecute el siguiente comando:
sudo cat /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log

  • Para seguir activamente el archivo /var/log/secure de modo que pueda supervisar los registros que se crearán en el siguiente paso, ejecute el siguiente comando:
sudo tail -f /var/log/secure

Mantenga abierta la pestaña EC2 Instance Connect y continúe con el siguiente paso.

Cree algunos registros de seguridad conectándose con éxito y luego fallando al conectarse a la EncryptedInstance sobre SSH desde su IDE de AWS Cloud9.

  • Descargue el archivo PEM desde el enlace Detalles de AWS situado encima de estas instrucciones de laboratorio.

  • Sube el archivo PEM desde tu ordenador a tu IDE de AWS Cloud9 utilizando la opción File > Upload Local Files.

Consejo: Antes de ejecutar el siguiente comando, es posible que desee organizar las pestañas del navegador para que pueda ver la sesión de EC2 Instance Connect que todavía tiene abierta desde el paso anterior.

  • En el terminal bash de AWS Cloud9, ejecuta los siguientes comandos. Sustituya EncryptedInstance-public-IP por la dirección IPv4 pública de la EncryptedInstance:
chmod 400 labsuser2.pem
ssh -i labsuser2.pem ec2-user@54.157.251.129
  • Cuando se le pregunte si está seguro de que desea conectarse, introduzca sí.

La conexión debería tener éxito. En la sesión de EC2 Instance Connect, deberías ver que se registraron líneas en el archivo /var/log/secure cuando ejecutaste los comandos anteriores.

  • En el terminal bash de AWS Cloud9, ejecuta los siguientes comandos para desconectarte de la sesión SSH y luego intentar conectarte con un nombre de usuario que no sea válido. Sustituya EncryptedInstance-public-IP por la dirección IPv4 pública de la EncryptedInstance:
exit
ssh -i labsuser2.pem ubuntu@EncryptedInstance-public-IP

El intento de conexión falla con un mensaje de «Permiso denegado».

Análisis: Ha intentado conectarse a la instancia con el nombre de usuario ubuntu, que no existe en esta instancia de Amazon Linux. El resultado es un intento de conexión fallido, que también se registra en /var/log/secure. (Debería poder ver esto cuando ejecute el comando tail en la sesión de EC2 Instance Connect para EncryptedInstance). Recuerde que el agente de CloudWatch debería estar reenviando los logs de archivos seguros al grupo de logs de CloudWatch. Lo confirmarás a continuación.

Compruebe que los registros seguros se escriben en el grupo de registros de CloudWatch.

  • Localice el grupo de registros de CloudWatch EncryptedInstanceSecureLogs.

  • Abra el último flujo de registro.

Debería ver que las acciones SSH que ha realizado se han registrado. Por ejemplo, debería ver eventos de registro similares a «Accepted publickey for ec2-user from…» e «Invalid user ubuntu from…». Expanda las entradas para ver los detalles.

Nota: El conjunto de resultados que ve también puede incluir muchas entradas de registro de intentos de registro fallidos no iniciados por usted. Esto no es infrecuente.

Tarea 4.3: Crear una alarma CloudWatch para enviar notificaciones de incidentes de seguridad.

AnyCompany Financial desea que se notifique a los miembros del equipo de seguridad de TI cuando se denieguen los intentos de acceso a la EncryptedInstance a través de SSH. En esta tarea, crearás una alarma CloudWatch para notificar a estos miembros del equipo cuando ocurra un incidente de este tipo.

Al final de esta tarea, habrás configurado la arquitectura que se muestra en el siguiente diagrama:

Vaya al grupo de registros de CloudWatch EncryptedInstanceSecureLogs y cree un filtro métrico con las siguientes características:

  • Patrón de filtro: «Usuario no válido» (Asegúrate de incluir las comillas.)

  • Nombre del filtro: Usuarios no válidos

  • Espacio de nombres de la métrica: secure

  • Nombre de la métrica: NotValidUsers

  • Valor de la métrica: 1

  • Valor por defecto: 0

  • Unidad: Recuento

Cree una alarma de CloudWatch a partir del filtro de métricas que acaba de crear.

  • En la página de detalles del grupo de registros EncryptedInstanceSecureLogs, en la pestaña Filtros de métricas, active la casilla de verificación del filtro de métricas Usuarios no válidos.

  • Cree una alarma de CloudWatch con las siguientes características:

Periodo: 1 día

Condición: Siempre que NotValidUsers sea mayor o igual a 5.

Notificación: Cree un nuevo tema de Amazon Simple Notification Service (Amazon SNS) denominado Not_valid_users_exceeding_limit y reciba notificaciones por correo electrónico. (Utilice una dirección de correo electrónico a la que tenga acceso).

  • Nombra la alarma Not valid users exceeding limit on EncryptedInstance con la siguiente descripción: Los intentos de acceso no válidos a través de SSH al servidor EncryptedInstance han superado los 4 en las últimas 24 horas.

Importante: Cuando cree la alarma por primera vez, el estado mostrará Datos insuficientes y la columna Acciones mostrará una advertencia. La advertencia aparece porque la alarma envía un mensaje a un tema de Amazon Simple Notification Service (Amazon SNS) con un punto final (la dirección de correo electrónico) que aún no se ha confirmado. La alarma no funcionará como se espera hasta que se confirme el punto final.

  • Vaya a la bandeja de entrada de la dirección de correo electrónico que introdujo en el paso anterior. Debería ver un correo electrónico de AWS Notifications. En el correo electrónico, seleccione el enlace Confirmar suscripción.

  • Para probar la alarma, vuelva al IDE de AWS Cloud9. En el terminal bash, ejecute al menos cinco intentos de acceso SSH no válidos para conectarse a la dirección IP pública de EncryptedInstance a través de SSH.

  • En la consola de CloudWatch, en el flujo de registro más reciente del grupo de registro EncryptedInstanceSecureLogs, filtre los eventos de registro para Usuario no válido.

Compruebe que se devuelven al menos cinco eventos y que todos se han producido en las últimas 24 horas. Esto indica que se ha alcanzado el umbral de alarma.

  • En el área Alarmas de la consola de CloudWatch, confirme que la alarma Usuarios no válidos tiene el estado En alarma.

Compruebe su correo electrónico para confirmar que ha recibido una notificación de que se ha superado el umbral de alarma.

Nota: pueden pasar un par de minutos antes de que cambie el estado de la alarma y antes de que reciba el correo electrónico.

Tarea 4.4: Configurar AWS Config para evaluar los ajustes de seguridad y remediar la configuración de los recursos de AWS.

A AnyCompany Financial le gustaría disponer de un mecanismo para configurar automáticamente los recursos de AWS en función de los estándares de la empresa. Un estándar es tener habilitado el registro de objetos en los buckets de S3.

En esta tarea, deberá utilizar AWS Config para informar sobre si el registro de objetos está configurado en los buckets de S3 de la cuenta de AnyCompany Financial. También deberá configurar un script de automatización para corregir el incumplimiento.

Esta solución ayudará a AnyCompany Financial a seguir cumpliendo con las normas que se han establecido para su infraestructura de TI, al tiempo que reduce la carga administrativa que se asocia con garantizar el cumplimiento de estas normas.

Al final de esta tarea, tendrá la arquitectura que se muestra en el siguiente diagrama:

Revise los recursos existentes que utilizará en esta tarea:

En la consola de IAM, revise los siguientes roles:

  • AWSConfigRole: Este rol fue creado para ti en este entorno de laboratorio. El rol otorga permisos que necesitarás para configurar AWS Config.

  • SSMAutomationRole: Este es el rol que AWS Systems Manager utilizará cuando realice acciones de remediación con una regla administrada de AWS Config que usted utilizará.

  • En la consola de Amazon S3, observa el bucket aws-config. AWS Config utilizará este bucket con fines de registro.

Cree un nuevo bucket de S3 denominado compliance-bucket-unique-ID, donde unique-ID es el ID único que contienen todos los demás buckets de la cuenta. Habilite las ACL en el bucket y créelo en la región us-east-1.

Habilite la propiedad de objetos en el bucket s3-objects-access-log.

  • Vaya a la consola de Amazon S3.

  • En la lista de buckets, seleccione el enlace del bucket s3-objects-access-log.

  • En la pestaña Permisos, desplácese hasta la sección Propiedad del objeto y, a continuación, seleccione Editar.

  • Seleccione ACL habilitadas.

  • Seleccione la casilla de verificación de la declaración que dice «Reconozco que se restaurarán las ACL» y, a continuación, seleccione Guardar cambios.

Nota: Este cambio es necesario para que la acción de corrección que realizará más adelante tenga éxito.

En la consola AWS Config, añada una regla administrada por AWS.

Cuando defina la regla, busque y seleccione la regla denominada s3-bucket-logging-enabled. Mantenga el resto de la configuración predeterminada y guárdela.

Confirme que la regla s3-bucket-logging-enabled que ha definido encuentra recursos que están dentro del ámbito. Confirme también que el cubo de conformidad está marcado como no conforme.

  • Abra la página de detalles de la regla s3-bucket-logging-enabled.

  • Espere hasta que vea los buckets de S3 en la sección Recursos en el ámbito de la página.

Nota: si no ve el bucket en la lista, es posible que tenga que esperar hasta 15 minutos antes de que aparezca. Actualice la página periódicamente hasta que lo vea antes de continuar.

  • Observe que el cubo de conformidad está marcado como No conforme.

  • Seleccione el enlace ID del cubo de conformidad y, a continuación, seleccione Gestionar recurso. En la pestaña Propiedades, compruebe que el registro de acceso al servidor está desactivado.

Esto explica por qué el bucket se ha marcado como no conforme.

Nota: Una vez activada la acción correctiva e invocada en este bucket, se activará el registro de acceso al servidor.

### Configure los ajustes de remediación manual para la regla s3-bucket-logging-enable.

  • Vuelva a la pestaña del navegador donde esté abierta la consola de AWS Config.

  • En el panel de navegación, seleccione Reglas.

  • Seleccione el enlace de la regla s3-bucket-logging-enable.

  • Seleccione Acciones > Administrar remediación y configure lo siguiente:

  • Seleccione el método de remediación: Remediación manual.

  • Seleccione la acción de remediación: Busque y seleccione AWS-ConfigureS3BucketLogging.

Nota: Al seleccionar una acción de remediación, está seleccionando un documento de Systems Manager Automation que se utilizará para actualizar los recursos. En este caso, el registro de acceso al servidor se habilitará en los buckets de S3 que elija remediar manualmente.

Consejo: Para obtener más información sobre esta automatización, incluidos los parámetros que se utilizan, consulte AWS-ConfigureS3BucketLogging en la Referencia del Runbook de AWS Systems Manager Automation.

  • Parámetro de ID de recurso: NombreDeBucket

  • PermisoConcedido: FULL_CONTROL

  • TipoDeBeneficiario: CanonicalUser

Nota: CanonicalUser se refiere a su cuenta de AWS.

  • TargetBucket: s3-objects-access-log-uniqueID (donde uniqueID es el ID único que aparece en el nombre del bucket).

Consejo: TargetBucket especifica dónde desea almacenar los registros de acceso al servidor. Para el registro, utilizará el mismo bucket que utilizó en la fase 1 al habilitar el registro en el bucket de datos.

  • GranteeId: Introduzca el ID canónico de su cuenta de AWS. Para encontrar este valor:

Abra la consola de Amazon S3 en una pestaña independiente del navegador.

Seleccione el enlace del bucket de cumplimiento.

En la pestaña Permisos, desplácese hasta la Lista de control de acceso (ACL).

Busque y copie el valor del ID canónico.

  • AutomationAssumeRole: Introduzca el ARN para SSMAutomationRole. Para encontrar este valor:

Abra la consola de IAM en una pestaña independiente del navegador.

En el panel de navegación, seleccione Roles.

Busque y seleccione SSMAutomationRole. En el área Resumen de la página, copie el valor ARN. Es similar a arn:aws:iam::ACCOUNT-ID:role/SSMAutomationRole.

  • Seleccione Guardar cambios.

La configuración de la regla debería ser similar a la siguiente imagen:

Invoque la acción de remediación de AWS Config para habilitar el registro de objetos en el bucket de cumplimiento.

  • En la página de detalles de la regla s3-bucket-logging-enabled, desplácese hacia abajo hasta la sección Recursos en el ámbito.

  • Seleccione el botón de opción del bucket de cumplimiento y luego Remediar.

El estado cambia a “Ejecución de acción en cola”. Espere unos segundos y luego seleccione el icono de actualización. Pronto, el estado cambiará a “Acción ejecutada correctamente”.

Consejo para la solución de problemas: Si la acción no se ejecuta correctamente, puede encontrar los registros relevantes en la consola de Systems Manager. En el panel de navegación, seleccione Automatización. Seleccione el enlace “ID de ejecución” del trabajo de automatización más reciente. (Tenga en cuenta que probablemente el estado sea “Error” si está solucionando problemas). En la sección “Pasos ejecutados”, seleccione el enlace del primer ID de paso con el estado “Error”. La página de detalles de ejecución puede proporcionar información sobre qué debe configurar de forma diferente para que el trabajo de remediación de AWS Config se ejecute correctamente.

Confirme que el registro de acceso al servidor esté habilitado en el contenedor de cumplimiento.

La regla de remediación que acaba de ejecutar lo habilitó.

Evaluación de costos de monitoreo y registro

Durante este laboratorio se utilizaron tres servicios clave de AWS: CloudTrail, CloudWatch y AWS Config, todos enfocados en mejorar la auditoría, la supervisión y la conformidad de los recursos, especialmente los buckets de Amazon S3. A continuación, se detallan los posibles costos asociados:

AWS CloudTrail

CloudTrail permite registrar acciones realizadas en la cuenta de AWS, como la creación, eliminación o acceso a recursos. En este laboratorio se configuró un trail para capturar eventos de administración y eventos de datos en un bucket S3.

Costo:

Los eventos de administración son gratuitos para un trail.

Los eventos de datos en S3 sí generan costos: $0.10 por cada 100,000 eventos de lectura o escritura.

Estimación: En un laboratorio básico con baja actividad (menos de 10,000 eventos/mes), el costo sería inferior a $0.01 USD/mes.

Amazon CloudWatch

CloudWatch permite recolectar métricas, generar alarmas y registrar logs. En este laboratorio se usó para:

Capturar logs del agente en una instancia EC2.

Generar una alarma de seguridad.

Costo:

Logs: $0.50 por GB de logs ingresados.

Retención de logs: $0.03 por GB por mes (si se excede el nivel gratuito).

Alarmas estándar: $0.10 por alarma por mes.

Estimación: Si el agente generó alrededor de 1 GB de logs y se creó una alarma, el costo aproximado sería de $0.60 USD/mes.

AWS Config

AWS Config permite auditar la configuración de los recursos en AWS. En el laboratorio se habilitó para monitorear buckets S3 y se ejecutó una regla de remediación para habilitar el logging de acceso en cumplimiento con una política definida.

Costo:

$0.003 por recurso evaluado por regla por mes.

En este caso, 6 buckets evaluados por una regla.

Estimación: 6 recursos × 1 regla × $0.003 = $0.018 USD/mes.

Servicio Uso principal en el laboratorio Costo estimado mensual (USD)
AWS CloudTrail Registro de eventos de datos en S3 $0.01
Amazon CloudWatch Recopilación de logs desde EC2 y alarma de seguridad $0.60
AWS Config Evaluación de conformidad de 6 buckets S3 $0.018
Total aproximado — $0.63