Seguridad y arquitectura de microservicios en AWS

Capítulo 4. Seguridad en reposo

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Cuando se trata de microservicios, gran parte de la literatura del sector se centra en el diseño y desarrollo de los mecanismos que proporcionan servicios informáticos al usuario final. A pesar de ello, es ampliamente conocido que los microservicios requieren que cambiemos fundamentalmente nuestra forma de pensar sobre el almacenamiento. Normalmente se espera que los microservicios sean autocontenidos. Esto se aplica no sólo a su lógica, sino también a su mecanismo de almacenamiento de datos. A diferencia de los monolitos, donde centralizar el almacenamiento de forma no redundante es el principio rector, los microservicios requieren que los arquitectos piensen en la descentralización. En un entorno real de microservicios, los datos son ciudadanos de primera clase y deben tratarse de forma similar a cualquier servicio informático. Los arquitectos de microservicios fomentan la localización de los datos, en la que éstos se mantienen cerca del servicio que los necesita, para que el sistema pueda depender menos de bases de datos externas. Al evitar las bases de datos compartidas y centralizadas, un entorno de microservicios trabaja sólo con los datos disponibles dentro del contexto delimitado, garantizando así la autonomía y la escala al mismo tiempo. Además, este diseño de almacenamiento distribuido reduce la posibilidad de que los mecanismos de almacenamiento se conviertan en "puntos únicos de fallo (SPOF)".

Desde el punto de vista de la seguridad, almacenar datos puede ser muy costoso si se examinan los riesgos que conlleva. IBM y el Instituto Ponemon publican un informe anual en el que se detalla el coste medio de una violación de datos para las empresas de todo el mundo, y como puedes imaginar, hay costes elevados asociados a cada violación. El coste medio de una violación de datos, según este informe, es de 3,86 millones de dólares. Esta cifra es aún mayor si perteneces a un sector muy regulado, en el que puede haber repercusiones normativas o financieras de las violaciones de datos. Por lo tanto, el enfoque de microservicio de persistencia políglota (que utiliza múltiples mecanismos de almacenamiento de datos) requiere una atención especial a los detalles cuando se trata de la seguridad en reposo.

Las arquitecturas de microservicios suelen dar lugar a la creación de una colección de mecanismos de almacenamiento distribuidos. Estos diferentes objetos de almacenamiento están débilmente acoplados entre sí, al igual que los propios microservicios. Es habitual que estos almacenamientos distribuidos sigan las reglas de los contextos delimitados en los que residen. La Figura 4-1 ilustra un ejemplo de configuración basada en dominios con almacenamientos persistentes distribuidos que residen dentro de los contextos delimitados de los servicios.

Figura 4-1. A diferencia de los monolitos, donde los datos se crean y almacenan desde una aplicación, los microservicios están fragmentados, lo que da lugar a datos que deben separarse lógicamente unos de otros, para ajustarse a las distintas políticas de protección de datos de toda la organización.

Nota

"Almacenamiento" puede significar cualquier cosa, desde un sistema de base de datos, eventos de aplicación, archivos planos, objetos multimedia, datos en caché, objetos binarios de gran tamaño (blobs), así como imágenes de contenedor. De hecho, la mayoría de los entornos de microservicios tienden a utilizar la persistencia políglota, ya que cada dominio puede tener un requisito diferente de su plataforma de almacenamiento de datos. Algunos servicios pueden beneficiarse de una base de datos NoSQL, mientras que otros pueden preferir utilizar un sistema de gestión de bases de datos relacionales (RDBMS). Un mecanismo de almacenamiento distribuido y localizado garantiza que puedas utilizar la mejor herramienta para el trabajo.

En este capítulo, me centraré principalmente en la seguridad en reposo de los microservicios.

Como he mencionado en los capítulos anteriores, la seguridad en torno a los datos puede lograrse de dos formas:

• Impedir el acceso a estos datos a usuarios no autorizados mediante el control de acceso

• Cifrar estos datos para que la exposición no autorizada de los datos no sea legible

Para asegurar un mecanismo de almacenamiento, la primera tarea es identificar los permisos y las políticas de seguridad que rigen el acceso al mismo. Para crear estas políticas, el principio del menor privilegio (PoLP) que comenté en el Capítulo 2 es una buena regla general. Para aplicar el PoLP, AWS permite el uso de políticas de gestión de identidad y acceso (IAM) para todas sus ofertas de almacenamiento en la nube, y las utilizaré a menudo en este capítulo.

Los entornos basados en dominios, a diferencia de los monolitos tradicionales, tienen la ventaja natural de ser fáciles de asegurar mediante PoLP, puesto que los datos y las unidades de negocio ya están segregados y, por tanto, se puede agilizar el control de acceso.

Aparte del control de acceso, los datos que se almacenan en AWS también deben estar cifrados. Cifrar estos datos proporciona una capa adicional de protección contra el acceso no autorizado, además de cualquier control de acceso existente que se añada a través de las políticas de IAM. Una vez cifrados los datos, es importante controlar el acceso a las claves de cifrado. En AWS, prácticamente todo el cifrado puede ser gestionado por el Servicio de Administración de Claves (KMS) de AWS que traté en profundidad en el Capítulo 3.

Conceptos básicos de la clasificación de datos

Aunque a todos los directivos les gusta afirmar que hay que proteger todos los datos de los clientes, seamos sinceros: no todos los datos son iguales. Existe una jerarquía inherente en cuanto a la sensibilidad e importancia de los datos. Por ejemplo, los datos de identificación personal (PII), que pueden utilizarse para identificar a los clientes, son más sensibles y deben protegerse con controles más potentes que los datos de entrenamiento de aprendizaje automático anonimizados. En cuanto a los registros que conllevan el precio más alto cuando se ven comprometidos, los PII de los clientes son los más caros (150 dólares), según el Informe IBM/Ponemon sobre el coste de una filtración de datos. La clasificación de los datos es el paso de la gestión de la seguridad que ayuda a los administradores a identificar, etiquetar y realinear la seguridad de la organización para que se ajuste a las necesidades de la sensibilidad de los datos. En este proceso, se identifican los tipos de datos y los niveles de sensibilidad, junto con las consecuencias probables del compromiso, pérdida o uso indebido de los datos.

Se ha demostrado empíricamente que las organizaciones que adoptan políticas sólidas de clasificación de datos están mejor posicionadas para protegerse de posibles amenazas. Las organizaciones gubernamentales también han prescrito varios niveles de clasificación de datos en el pasado. Por ejemplo, el Esquema Nacional de Clasificación de EEUU, basado en la Orden Ejecutiva 12356, reconoce tres clasificaciones de datos: Confidencial, Secreto y Alto Secreto. El gobierno del Reino Unido también tiene tres clasificaciones: Oficial, Secreto y Alto Secreto.

Cada clase de datos puede tener un requisito de seguridad diferente al almacenarlos. Y lo que es más importante, el acceso que tienen los empleados puede ser diferente y, por tanto, la clasificación de los datos puede dictar la estructura de gestión de identidades y control de acceso dentro de tu organización. Según mi experiencia, las empresas han adoptado formas innovadoras de clasificar sistemáticamente los recursos que almacenan datos sensibles en los centros de datos físicos. Varias empresas implantaron un código de colores en los servidores que indicaba el tipo de datos que podían almacenarse en cada servidor. Otras empresas separaron los servidores que transportaban datos sensibles y los mantuvieron en un lugar separado al que sólo tenían acceso los empleados con privilegios.

Consejo

Cuando digo "almacenamiento de datos", me refiero tanto a la persistencia intencionada como a la no intencionada de los datos. La persistencia intencionada son los datos que deseas persistir en un almacén de objetos o en una base de datos. La persistencia no intencionada incluye los datos que persisten como resultado de operaciones en tiempo de ejecución, como archivos de registro, volcados de memoria, copias de seguridad, etc. Según mi experiencia, muchos administradores tienden a pasar por alto la persistencia no intencionada cuando intentan enmarcar su política de almacenamiento de datos.

En AWS, los datos se pueden clasificar utilizando las etiquetas de AWS de las que hablé brevemente en el Capítulo 2. Las etiquetas de AWS te permiten asignar metadatos a tus recursos en la nube para que los administradores conozcan el tipo de datos que almacenan estos recursos. Utilizando estas etiquetas, se puede aplicar una lógica condicional al control de acceso para aplicar comprobaciones de autorización de seguridad al conceder el acceso. Para la validación de la conformidad, las etiquetas de AWS también pueden ayudar a identificar y rastrear los recursos que contienen datos sensibles. Desde el punto de vista de la seguridad, deberías etiquetar todos y cada uno de los recursos de tu cuenta, especialmente si almacenan datos sensibles.

Recapitulación de la encriptación de sobres mediante KMS

El cifrado de sobres es la herramienta que AWS utiliza frecuentemente para cifrar todos los datos que se almacenan en reposo. Ya he hablado en profundidad(Capítulo 3) sobre cómo funciona AWS KMS, junto con el cifrado de sobres. Pero para quienes necesiten un repaso, he aquí un rápido resumen.

En el cifrado básico, siempre que haya que cifrar datos de texto plano, puedes utilizar el algoritmo AWS-256, que requiere una clave de datos como entrada. Estos datos cifrados (también conocidos como texto cifrado) pueden ser descifrados, accedidos y leídos por un destinatario siempre que esté en posesión de la clave de datos que se utilizó para cifrar estos datos en primer lugar. La encriptación de sobres lleva este proceso un paso más allá. En la encriptación de sobres, la clave de datos que se utiliza para encriptar el texto plano se encripta aún más utilizando una clave diferente conocida como clave maestra del cliente (CMK).

Tras la encriptación, los datos del texto cifrado y la clave de los datos del texto cifrado se almacenan juntos, mientras que la clave de los datos del texto sin formato se elimina. El acceso está restringido a la CMK y sólo se proporciona al destinatario previsto de estos datos.

La Figura 4-2 ilustra bloques de datos que se almacenan utilizando la encriptación de sobres.

Figura 4-2. Los datos encriptados en sobre contienen blobs que contienen datos encriptados mediante una clave de datos junto con la clave de datos encriptada mediante la CMK.

Para leer los datos cifrados del sobre, el lector tiene que utilizar primero la CMK para descifrar la clave de los datos cifrados y obtener la clave de los datos en texto plano. Con esta clave de datos, el lector puede descifrar los blobs de datos cifrados y obtener los datos originales en texto plano que se cifraron. Así, el destinatario previsto puede descifrar los datos siempre que tenga acceso a la CMK.

Casi todos los sistemas de almacenamiento de datos cifrados en AWS tendrán tres temas comunes:

• La CMK en la que confías se almacena de forma segura, lejos de accesos no autorizados, ya sea en tus propios servidores, en AWS KMS o dentro de un módulo de seguridad de hardware (HSM).

• Confías en que el algoritmo de encriptación sea indescifrable. En la mayoría de los ejemplos de AWS, generalmente se considera que AES-256 es un algoritmo seguro.

• Existe un proceso de cifrado de datos. Esto puede incluir cifrar los datos en los servidores o permitir a los clientes cifrar estos datos antes de enviarlos a AWS. Este proceso también especifica políticas sobre cómo se almacena en caché la clave de datos en el lado del cliente. Los distintos sistemas de almacenamiento en AWS utilizan una política de almacenamiento en caché diferente para las claves de datos, que trataré en detalle en este capítulo.

Servicio de almacenamiento simple de AWS

En AWS Simple Storage Servive o Amazon Simple Storage Service (S3), los "objetos" de almacenamiento se guardan dentro de buckets. La responsabilidad más importante de todo profesional de la seguridad en el entorno S3 consiste en aplicar la PoLP a todos los objetos y buckets dentro de S3 que procedan de distintos microservicios. Esto significa que sólo se debe permitir el acceso a estos objetos a los usuarios y recursos que lo necesiten.

Dado que AWS S3 es un servicio gestionado, cualquier dato que se almacene en S3 puede compartir sus recursos físicos con otros clientes de la nube. Por lo tanto, para proteger tus datos sensibles, AWS te ofrece dos opciones, que deben utilizarse juntas para cualquier sistema de almacenamiento seguro:

• Las políticas de AWS IAM (en concreto, las políticas basadas en el principal de IAM y las políticas de bucket basadas en recursos de AWS S3), que mencioné en el capítulo 2, pueden utilizarse para controlar el acceso a estos recursos y garantizar que se aplica la PoLP.

• AWS KMS puede utilizarse para cifrar los objetos que se almacenan dentro de los buckets de AWS S3. Esto garantiza que sólo los mandantes con acceso a la clave de cifrado utilizada para cifrar estos datos puedan leer estos objetos.

El cifrado y el control de acceso desempeñan un papel igualmente importante en el mantenimiento de la seguridad de los datos; ambos métodos deben emplearse para protegerlos de accesos no autorizados. La Figura 4-3 muestra cómo puedes aprovechar las políticas de AWS KMS y AWS IAM para proteger tus datos.

Figura 4-3. Los profesionales de la seguridad pueden emplear las políticas de AWS IAM para restringir el acceso a los datos dentro de los buckets de AWS S3, junto con el uso del cifrado de sobres de AWS KMS para los datos que se almacenan en estos buckets. Una solución buena y segura emplea eficazmente el cifrado y la autorización para impedir cualquier acceso no autorizado.

Cifrado en AWS S3

Primero hablaré de las técnicas que puedes utilizar para cifrar objetos de datos. Hay cuatro formas de cifrar objetos de datos en AWS S3. Cada una de estas formas proporciona cierta flexibilidad y comodidad a los usuarios finales y, por tanto, puedes elegir cualquiera de estos métodos que se adapte a las necesidades de tu organización. Son las siguientes

• Cifrado del lado del servidor de AWS (claves gestionadas por AWS SSE-S3-AWS)

• KMS de cifrado del lado del servidor de AWS (AWS SSE-KMS-claves gestionadas por el cliente)

• Cifrado del lado del servidor de AWS con claves proporcionadas por el cliente (AWS SSE-C-claves proporcionadas por el cliente)

• Encriptación del lado del cliente de AWS S3 (encriptación de datos en el cliente antes de enviarlos a AWS S3)

La Figura 4-4 muestra un práctico diagrama de flujo que puede ayudarte a determinar el tipo de encriptación que necesitas para las necesidades de tu organización.

Figura 4-4. Puedes decidir qué encriptación quieres respondiendo a las preguntas de esta tabla.

Todas las opciones de cifrado pueden utilizar AWS KMS para lograr el cifrado en AWS. Por lo tanto, una comprensión profunda y fundamental de AWS KMS puede ayudar mucho a entender el proceso de cifrado en AWS S3.

AWS SSE-S3 (claves gestionadas por AWS)

Este es el modo predeterminado de cifrar objetos de datos dentro de AWS S3. Para las organizaciones que necesitan un cifrado de objetos muy básico sin desear controlar el ciclo de vida de la CMK que se utilizó para cifrar los elementos de datos, AWS SSE-S3 proporciona una forma rápida y sencilla de introducir el cifrado en AWS. La mayor ventaja de utilizar AWS SSE-S3 es la facilidad de uso y la sencillez que proporciona a los usuarios de la nube.

AWS SSE-S3 puede habilitarse a nivel de cubo en la consola de administración de AWS, como se ve en la Figura 4-5.

Figura 4-5. Todos los objetos almacenados dentro de un bucket pueden cifrarse por defecto utilizando AWS SSE-S3 en la opción "Cifrado por defecto" y seleccionando "Cifrado del lado del servidor".

Una vez habilitado, AWS cifra todos los objetos dentro de este bucket utilizando una clave de datos. Esta clave de datos se cifra utilizando AWS KMS y una CMK que AWS mantiene, protege y rota para ti.

Consejo

Gracias a la presencia de AWS SSE-S3, la inversión necesaria para habilitar el cifrado de objetos en AWS S3 es ahora extremadamente baja. Aunque no es lo ideal (ya que confías completamente a AWS tu clave y el proceso de cifrado), la posibilidad de habilitar el cifrado con sólo pulsar un botón debería empujar a todos los usuarios a cifrar todos sus objetos de almacenamiento. No conozco ni una sola razón por la que los objetos de AWS S3 no deban cifrarse.

Por supuesto, para aquellos interesados en un mayor control, existen otras formas de cifrar los objetos que se almacenan en AWS S3.

AWS SSE-KMS

Los usuarios que prefieran un proceso de cifrado más flexible que AWS SSE-S3 pueden utilizar AWS KMS de forma más explícita para el cifrado. Puedes utilizar una clave KMS que controles en AWS KMS. De este modo, también puedes estar a cargo del ciclo de vida de la clave que se utiliza para cifrar objetos de datos en AWS.

El cifrado puede habilitarse en objetos individuales o habilitarse por defecto para cada objeto del bucket, de forma similar a como se habilitó AWS SSE-S3 en la Figura 4-5. La Figura 4-6 muestra cómo puede habilitarse AWS SSE-KMS como opción por defecto para los buckets.

Figura 4-6. AWS SSE-KMS puede habilitarse a través de la consola de administración proporcionando el ARN de la clave KMS con la que quieres que se cifren tus objetos.

AWS SSE-C (clave proporcionada por el cliente)

El último tipo de cifrado del lado del servidor en AWS S3 es el AWS SSE-C. En este proceso de cifrado, el control sobre el proceso de cifrado se traslada aún más al usuario final. En lugar de indicar a AWS S3 que utilice una clave de cifrado que está presente en AWS KMS, puedes incluir la clave de cifrado dentro de tu solicitud PutObject e indicar a AWS S3 que cifre el objeto utilizando la clave que proporciones. Esta misma clave debe proporcionarse durante la operación GetObject para descifrar y recuperar el objeto. AWS S3 utilizará la clave que proporciones, cifrará el objeto y lo almacenará en AWS S3, para después borrar la clave permanentemente. De esta forma, puedes tener total flexibilidad para controlar el acceso y asegurar la clave de descifrado de los objetos que se almacenan en AWS. Al mismo tiempo, el proceso de cifrado tiene lugar por completo en AWS S3 y, por tanto, no necesitas mantener código de cifrado o descifrado dentro de tus servicios.

Advertencia

AWS SSE-C sólo cifra el objeto S3, pero no los metadatos asociados al objeto.

Encriptación del lado del cliente de AWS

AWS proporciona muchas opciones diferentes para cifrar los datos después de que se hayan subido a AWS S3, pero puede que prefieras cifrar los datos dentro de tu aplicación incluso antes de que se transfieran a AWS. El cifrado del lado del cliente consiste en cifrar los datos antes de enviarlos a Amazon S3 y puede utilizarse para estos casos de uso. En el cifrado del lado del cliente, gestionas la CMK con la que quieres cifrar los datos. A continuación, puedes utilizar parte del kit de desarrollo de software del lado del cliente (SDK) para cifrar los datos dentro de tu aplicación y enviar estos datos a AWS para almacenarlos en la nube. Desde el punto de vista de AWS, estos datos cifrados por el cliente no difieren de cualquier otro dato que almacene. Si lo deseas, también puedes activar opcionalmente el cifrado del lado del servidor. De este modo, el cifrado del lado del cliente puede ofrecer una capa adicional de protección contra posibles amenazas. Puedes encontrar más información sobre la encriptación del lado del cliente en Amazon.

Control de acceso en Amazon S3 mediante políticas de bucket S3

Como comenté en el Capítulo 2, las políticas basadas en recursos restringen el acceso a los recursos de AWS y pueden aplicarse a determinados recursos. En AWS S3, estas políticas basadas en recursos se denominan políticas de bucket. Estas políticas responden a la pregunta: ¿A qué administradores se les permite acceder a los objetos dentro de estos buckets S3 y bajo qué condiciones debe permitirse o denegarse este acceso? Las políticas de bucket pueden añadirse en la consola de administración de AWS, como se ve en la Figura 4-7.

Figura 4-7. Las políticas de bucket se pueden añadir a los buckets de AWS S3 yendo a la pestaña Permisos de la consola web de AWS.

AWS también proporciona una excelente documentación sobre las políticas de los buckets de AWS. Las dos políticas siguientes son ejemplos de formas de proteger tus buckets de S3.

Ejemplo 1: Aplicar la encriptación del servidor a todos los objetos

Como administrador de seguridad, puedes denegar las subidas no cifradas a tu bucket añadiendo una política IAM como la recomendada por AWS.

{
      "Sid": "DenyUnencryptedObjectUploads",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::awsexamplebucket1/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption": "true"
        }
      }
    }

La declaración Condition de este bloque es lo que hace efectiva esta política.

Ejemplo 2: Exigir a los usuarios que tengan MFA mientras interactúan con AWS S3

Otra política de bucket de uso común es imponer un requisito de autenticación multifactor (MFA) para cualquier solicitud que quiera interactuar con objetos del bucket:

{
    "Version": "2012-10-17",
    "Id": "123",
    "Statement": [
      {
        "Sid": "",
        "Effect": "Deny",
        "Principal": "*",
        "Action": "s3:*",
        "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/taxdocuments/*",
        "Condition": { "Null": { "aws:MultiFactorAuthAge": true }}
      }
    ]
 }

El Apéndice D proporciona un tutorial práctico que los profesionales de la seguridad en la nube pueden utilizar para aplicar PoLP a sus buckets S3.

Amazon GuardDuty

Con Amazon GuardDuty, puedes monitorear continuamente las amenazas y el comportamiento no autorizado para proteger tus datos almacenados en Amazon S3. Mediante el aprendizaje automático, la detección de anomalías y la inteligencia sobre amenazas integrada, AWS GuardDuty identifica y prioriza las amenazas potenciales. AWS CloudTrail y los registros de flujo de la nube privada virtual (VPC), así como los registros DNS, se encuentran entre las fuentes de datos de GuardDuty. GuardDuty detecta las amenazas y envía una respuesta automatizada, acelerando los tiempos de reparación y recuperación.

GuardDuty monitorea las amenazas a tu sitio Amazon S3 observando los eventos de gestión de CloudTrail S3 y los eventos de gestión de CloudTrail. Los datos que generan los clientes de GuardDuty, como los hallazgos, se cifran mientras están en reposo utilizando AWS KMS con claves maestras de AWS (CMK), que está asegurado bajo el Modelo de Responsabilidad Compartida de AWS (SRM).

No repudio mediante bloqueo de bóveda de glaciar

Para mantener el cumplimiento, a veces es necesario tener un sistema de registro (SOR ) que sea la fuente de datos autorizada para una información determinada. Este SOR no es sólo para los consumidores internos, sino también para que las partes externas, como las autoridades policiales o los auditores de cumplimiento, lo inspeccionen en caso de discrepancias. En consecuencia, este ROS debe ser algo en lo que los organismos externos puedan confiar y utilizar como prueba en caso de discrepancias en las que tu organización pueda tener un conflicto de intereses. Por tanto, una certificación de la integridad de los datos por parte de un tercero puede ser importante en una situación así.

Con AWS Glacier Vault Lock, los datos pueden almacenarse de manera que su integridad y autenticidad puedan certificarse a efectos normativos. En el centro de este proceso de integridad está la política de Bloqueo de Bóvedas de Glaciar, que controla cómo se almacenan los datos y qué controles de acceso tiene la organización sobre sus propios datos. Las políticas de bóveda pueden tener controles como escribir una vez leer muchas (WORM), que impide futuros cambios en los datos almacenados. Una vez bloqueada la política, no puede modificarse.

Puedes utilizar el bucket Glacier de AWS S3 para almacenar los datos y bloquear el bucket para demostrar a cualquier organismo regulador que decida auditarte que los datos nunca han sido alterados.

Consejo

A diferencia de una política de acceso a la cámara acorazada, una política de bloqueo de la cámara acorazada puede bloquearse para impedir que se realicen más cambios en tu cámara acorazada, garantizando así su cumplimiento.

Para iniciar el bloqueo de una cámara acorazada, debes realizar dos pasos:

1. Adjunta una política de bloqueo de bóveda a tu bóveda que establecerá el bloqueo en un estado en curso, devolviendo un ID de bloqueo. El bloqueo caducará a las 24 horas si la política no ha sido validada.

2. Si no estás satisfecho con los resultados del proceso, puedes reiniciar el proceso de bloqueo desde cero durante el periodo de validación de 24 horas.

Consejo

Las políticas de bloqueo de bóvedas pueden ayudarte a cumplir marcos normativos como la Norma 17a-4 de la SEC y la HIPAA.

Seguridad en reposo para servicios informáticos

En esta sección, hablaré de cómo puedes asegurar los servicios encargados de ejecutar tus microservicios. Antes de hablar de la seguridad de los microservicios en reposo, comentaré brevemente cómo es un proceso de desarrollo típico en una tienda de microservicios típica.

Dependiendo de las prácticas de desarrollo, puede haber ciertos cambios en pasos concretos, pero en general, el flujo se parece a lo que se ilustra en la Figura 4-8.

1. Los desarrolladores suelen escribir código en un lenguaje de su elección. Puede ser Java, Python, Go, TypeScript o cualquier otro lenguaje de su elección.

   Riesgo de seguridad: los atacantes pueden ser capaces de explotar cualquier vulnerabilidad a nivel de código o inyectar bibliotecas inseguras a nivel de código, y así poner en peligro la seguridad de toda tu aplicación.

2. Si quieres ejecutar este código en un entorno típico de contenedores, como en un clúster de Kubernetes, compila este código en una canalización de integración continua y entrega continua (CICD) y realiza varios pasos sobre él hasta que se convierta en una imagen en contenedor. Esta canalización CICD puede utilizar un sistema de almacenamiento para guardar datos persistentes como bibliotecas, archivos de configuración, etc. Si se ejecuta en una instancia de AWS Elastic Cloud Compute (EC2), un volumen de AWS Elastic Block Store (EBS ) contendrá generalmente dichos datos.

   Riesgo de seguridad: los volúmenes de EBS que se utilizan para construir la imagen pueden ser secuestrados y utilizados contra tu proceso de construcción para inyectar vulnerabilidades en la aplicación o filtrar código sensible.

3. Una vez que tienes una imagen en contenedor, como una imagen Docker, normalmente almacenas esta imagen en un repositorio Docker. Aquí tienes muchas opciones para almacenar esta imagen. AWS te proporciona AWS Elastoc Container Registry (ECR) donde puedes almacenar una imagen Docker.

   Riesgo de seguridad: un almacenamiento inseguro de imágenes construidas puede dar lugar a que actores maliciosos manipulen las imágenes de contenedores construidos e inyecten código malicioso dentro de estos contenedores. Alternativamente, puede filtrarse código fuera de un almacenamiento de contenedores no seguro.

4. La imagen Docker del Paso 2 puede promocionarse ahora a varios entornos de tu elección. De este modo, puedes tener la misma imagen ejecutándose en tu entorno de producción que en tu entorno de ensayo. Si utilizas Amazon EKS para ejecutar un clúster de Kubernetes, y si tienes tus nodos ejecutándose en AWS EC2, puedes extraer la imagen del registro ECR y promoverla a los nodos EC2. De forma similar a las canalizaciones CICD del Paso 2, estos nodos pueden emplear volúmenes EBS para almacenar datos persistentes. Es posible que los profesionales de la seguridad tengan que proteger estos volúmenes EBS.

   Riesgo de seguridad: Aunque los contenedores se ejecutan en los nodos Kubernetes, pueden utilizar volúmenes EBS para almacenar datos persistentes. De forma muy similar al Paso 2, los actores maliciosos que obtengan acceso no autorizado a estos volúmenes EBS podrían manipular los datos almacenados en ellos o filtrar datos sensibles a otras entidades externas.

5. Alternativamente, si decides ejecutar tu código en AWS Lambda, puedes implementar el código directamente en AWS Lambda y no tener que preocuparte de los Pasos 2-3.

   Riesgo de seguridad: en AWS Lambda, no se supone que tengas almacenamiento a largo plazo. Sin embargo, las variables de entorno que necesitan tus funciones pueden almacenarse en AWS y puede ser necesario protegerlas.

Todas las tiendas de microservicios siguen alguna variante de este flujo, como se ve en la Figura 4-8.

Figura 4-8. Los distintos pasos por los que fluye el código antes de ejecutarse en un entorno de microservicios.

En la siguiente sección, hablaré de las distintas herramientas de seguridad que tienes a tu disposición para mantener a salvo estos datos.

Análisis estático del código con AWS CodeGuru

El análisis estático de código es una rama emergente en el campo de la seguridad informática. Hasta hace poco, la mayor parte del análisis estático de código era difícil de realizar, debido principalmente a la naturaleza no determinista de los lenguajes informáticos. Sin embargo, con la llegada de la IA y el aprendizaje automático, las herramientas de seguridad que acaban identificando vulnerabilidades de seguridad en el código son cada vez más precisas.

AWS proporciona a los usuarios AWS CodeGuru, que utiliza el aprendizaje automático y la IA para realizar varios tipos de análisis en tu código. A continuación, AWS CodeGuru compara tu código con sus repositorios de muestras y utiliza el aprendizaje automático para identificar problemas relacionados con la seguridad, así como otras buenas prácticas en el código. Este análisis incluye la identificación de posibles fugas de recursos, exploits y vulnerabilidades de tu código.

El análisis estático del código garantiza que cualquier problema con tu base de código se identifique al principio de su ciclo de vida, antes de que se envíe a producción. La Figura 4-9 muestra un ejemplo de código en el que AWS CodeGuru recomendó cambios a nivel de código.

Figura 4-9. Se puede activar el análisis estático de código en los repositorios existentes para identificar problemas relacionados con el código Java, así como vulnerabilidades de seguridad.

Registro elástico de contenedores de AWS

AWS ECR es el repositorio que AWS te proporciona para almacenar los contenedores construidos para albergar tus microservicios. De este modo, puedes construir microservicios utilizando Docker y promover estas imágenes a otros entornos. Estas imágenes disponen de un almacenamiento seguro durante toda su vida útil. Utilizar AWS ECR para almacenar contenedores ofrece múltiples ventajas, y voy a destacar tres de las razones más importantes por las que AWS ECR es el más adecuado para este trabajo.

Control de acceso

AWS permite el uso de políticas IAM para controlar el acceso a los repositorios AWS ECR. De este modo, los distintos contextos de tu organización pueden segregarse utilizando la PoLP para decidir a qué contenedores pueden acceder las distintas entidades de tu organización. Puedes utilizar políticas basadas en identidades, así como políticas basadas en recursos, para controlar el acceso.

AWS mantiene una lista de varias políticas IAM que puedes aplicar a tus repositorios ECR. Aquí tienes un ejemplo de política IAM que permite al usuario listar y gestionar imágenes en un repositorio ECR:

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"ListImagesInRepository",
         "Effect":"Allow",
         "Action":[
            "ecr:ListImages"
         ],
         "Resource":"arn:aws:ecr:us-east-1:123456789012:repository/my-repo"
      },
      {
         "Sid":"GetAuthorizationToken",
         "Effect":"Allow",
         "Action":[
            "ecr:GetAuthorizationToken"
         ],
         "Resource":"*"
      },
      {
         "Sid":"ManageRepositoryContents",
         "Effect":"Allow",
         "Action":[
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:GetRepositoryPolicy",
                "ecr:DescribeRepositories",
                "ecr:ListImages",
                "ecr:DescribeImages",
                "ecr:BatchGetImage",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload",
                "ecr:PutImage"
         ],
         "Resource":"arn:aws:ecr:us-east-1:123456789012:repository/my-repo"
      }
   ]
}

Alternativamente, si quieres permitir que los usuarios obtengan acceso de sólo lectura a todas las imágenes, puedes utilizar las políticas gestionadas de AWS para conseguir un objetivo similar.

Cifrado en reposo

AWS ECR está respaldado por AWS S3, que también permite cifrar las imágenes en reposo utilizando técnicas muy similares a las de AWS S3. La Figura 4-10 ilustra cómo se protegen tus contenedores en AWS ECR utilizando AWS KMS. Las concesiones KMS se crean cada vez que necesitas permitir el acceso a la imagen.

Figura 4-10. Las imágenes dentro de AWS ECR se cifran utilizando AWS KMS.

Puedes habilitar el cifrado para el almacenamiento de contenedores en AWS ECR a través de la consola de administración de AWS, como se ve en la Figura 4-11.

Figura 4-11. El cifrado KMS puede habilitarse para AWS ECR activando la casilla "Personalizar la configuración de cifrado" y eligiendo el CMK KMS que desees utilizar.

Imagen Exploración de vulnerabilidades y exposiciones comunes

AWS ECR ofrece la posibilidad de escanear los contenedores en busca de vulnerabilidades comunes utilizando el proyecto de código abierto clair. Este escaneado garantiza que los contenedores estén protegidos frente al malware. Puedes habilitar el escaneado de vulnerabilidades comunes y exposición (CVE) por defecto para cada contenedor que se cargue en AWS ECR o escanear manualmente cada imagen de contenedor en ECR. La Figura 4-12 muestra cómo puedes habilitar CVE para todas las imágenes.

Figura 4-12. CVE puede activarse por defecto en cada imagen que se envíe a ECR.

AWS Lambda

Aunque AWS Lambda no debe utilizarse para el almacenamiento a largo plazo, a veces las variables de entrada que se proporcionan a las funciones Lambda como variables de entorno pueden contener datos sensibles. Almacenar estos datos en la nube sin cifrar puede dar lugar a una situación de seguridad no tan ideal. Por ello, AWS te permite cifrar automáticamente las variables de entorno que se almacenan para las funciones AWS Lambda.

Hay dos formas de encriptar las variables de entorno:

• Cifrado mediante CMK

• Cifrado mediante ayudantes externos

Cifrado mediante CMK

Al igual que AWS S3 y AWS ECR, las variables de entorno pueden cifrarse en el lado del servidor. Puedes permitir que AWS gestione el cifrado por ti utilizando la CMK propiedad de AWS o gestionar los permisos y el ciclo de vida en torno a la CMK proporcionando una referencia a una CMK existente. A continuación, puedes proteger esta CMK utilizando el PoLP.

Cifrado mediante ayudantes

Los ayudantes de cifrado añaden una capa adicional de protección a tus variables de entorno cifrando las variables en el lado del comando antes de añadirlas a la Lambda. Esto garantizará que las variables no sean visibles en su forma no cifrada en la consola de AWS.

Almacén de bloques elástico de AWS

Por último, si ejecutas tus servicios en EC2 (ya sea directamente o utilizando Amazon Elastic Kubernetes Service [EKS] con EC2 como nodos trabajadores), AWS KMS puede utilizarse para cifrar los volúmenes EBS de respaldo que respaldan estas instancias EC2. Como se ve en la Figura 4-13, la clave de datos del volumen EBS se almacena en caché con fines de velocidad y fiabilidad.

Figura 4-13. Las instancias EC2 descifran la clave de datos que se utiliza para descifrar los volúmenes EBS haciendo peticiones a AWS KMS. Una vez descifrada, las instancias EC2 conservan la clave de datos sin cifrar en su caché mientras la instancia esté en funcionamiento.

Dado que la clave de datos se almacena en caché dentro de la instancia EC2, una vez que una instancia se adjunta al volumen, puede acceder a los datos del volumen EBS sin realizar peticiones a la CMK basada en KMS. Cada vez que se cierra la instancia, es posible que ésta tenga que hacer una nueva petición a la CMK para volver a unirse al volumen EBS.

Unirlo todo

Ahora que he explicado por qué es importante la seguridad en reposo, hablemos de cómo las herramientas de AWS pueden ayudar a proteger el código de tu microservicio:

1. Para las vulnerabilidades a nivel de código y las fugas de recursos, AWS CodeGuru ayuda a ejecutar el código y realizar un análisis estático del mismo.

2. AWS KMS puede ayudar a cifrar los volúmenes de EBS (utilizando claves gestionadas/propias de AWS o CMK gestionadas por el cliente), lo que da lugar a un proceso de creación seguro.

3. Se pueden utilizar políticas IAM para controlar el acceso a AWS ECR. Los contenedores en ECR también se pueden cifrar utilizando el cifrado del lado del servidor. Por último, puedes utilizar escáneres de imágenes CVE para analizar los contenedores almacenados en AWS ECR en busca de vulnerabilidades comunes.

4. Los volúmenes de EBS que utilizan los nodos de Kubernetes también pueden cifrarse en AWS mediante KMS y protegerse así de accesos no autorizados.

5. Por último, las variables de entorno que se proporcionan a las Lambdas de AWS también pueden cifrarse utilizando CMK o ayudantes de cifrado.

La Figura 4-14 señala los distintos controles que nos proporciona AWS para aumentar la seguridad de todos los pasos descritos en la Figura 4-8.

Figura 4-14. Para todos los pasos que he descrito en la Figura 4-8, AWS nos proporciona controles que pueden ayudar a reducir la exposición a posibles amenazas.

Sistemas de bases de datos de microservicios

Después de explicar los diferentes servicios informáticos de AWS, hablaré de los tipos de opciones de almacenamiento que tienes para tus microservicios y de cómo AWS protege tus datos confidenciales.

Ya he hablado de la posibilidad de mecanismos de persistencia políglotas en los sistemas de microservicios. La Figura 4-15 muestra una organización típica basada en microservicios, en la que los servicios están segregados por sus dominios funcionales. Cada uno de estos dominios representa un contexto delimitado más amplio. Cada servicio habla con un almacén de datos dentro de su contexto delimitado y no con ningún almacén de datos externo. Como resultado, dependiendo de las necesidades del dominio, cada contexto delimitado puede optar por utilizar un tipo diferente de base de datos.

Figura 4-15. Tres dominios diferentes con distintas necesidades pueden optar por distintos tipos de bases de datos. El Dominio A puede necesitar datos relacionales y, por lo tanto, podría elegir AWS Relational Database Service (RDS) como almacén de datos. El dominio B puede preferir almacenar sus datos en un almacén de datos NoSQL DynamoDb, mientras que el dominio C puede almacenar sus datos en cubos de AWS S3.

AWS DynamoDB

AWS DynamoDB es un sistema de base de datos NoSQL sin servidor y totalmente administrado que puede utilizarse para el almacenamiento de datos en diversas aplicaciones.

Control de acceso en AWS DynamoDB

AWS DynamoDB admite políticas IAM como cualquier otro recurso de AWS. Sin embargo, el uso de AWS DynamoDB te permite controlar quién puede acceder a qué parte (fila o columna o ambas) de la base de datos y cuándo. La sección de condiciones de una política IAM te proporciona un control detallado de los permisos. Voy a poner un ejemplo para ilustrar mi punto de vista.

Considera una organización que almacena información sobre los empleados en una tabla DynamoDB. Cada fila contiene información diversa sobre cada empleado. Puede incluir su nombre, estado, país, salario y número de la Seguridad Social. Es posible que tengas dos tipos de usuarios que puedan acceder a esta información:

• Usuario: puede tratarse de un empleado fijo que puede necesitar acceder a su propia fila para cambiar o actualizar su dirección en el sistema. Sin embargo, no pueden acceder a su salario ni a su número de la Seguridad Social por motivos de seguridad.

• Admin: se trata de un usuario más potente que puede necesitar acceso completo a toda la tabla.

La clave primaria para obtener cada fila puede ser el Nombre de usuario.

La Figura 4-16 muestra la tabla de empleados que puede contener la información de los empleados.

Figura 4-16. "Usuario - Gaurav" sólo puede acceder y editar la fila que tiene el nombre de usuario Gaurav y sólo puede acceder a las columnas Nombre de usuario, Ciudad, Estado y País, como se ha resaltado.

Así que para el usuario IAM Gaurav, quieres permitir:

• GetItem y UpdateItem acceso

• Acceso a atributos específicos (Nombre de usuario, Ciudad, Estado y País)

• Acceso sólo para las filas cuyo nombre de usuario es Gaurav

La política IAM que puedes utilizar para una situación así se muestra en la Figura 4-17.

Figura 4-17. Esta es la política IAM que, aplicada al usuario Gaurav, dará como resultado la satisfacción de nuestro requisito. 1, 2, 3A y 3B identifican las secciones de la política IAM que ayudan a afinar la política de permisos.

Como se ve en la Figura 4-17, puedes utilizar determinados elementos de la política para afinar la política IAM:

1. Para empezar, puedes aplicar la PoLP a las operaciones que quieras permitir.

2. La clave de condición LeadingKeys puede utilizarse para especificar la clave que debe comprobarse al aplicar la política. En este ejemplo, cualquier fila que tenga la clave Gaurav será accesible para el usuario Gaurav. Alternativamente, puedes cambiar el nombre codificado "Gaurav" por ${www.amazon.com:user_id} si quieres indicar a AWS que permita al usuario autenticado en ese momento acceder a una columna con su propio nombre, como se destaca en un artículo de AWS.

3. 3A y 3B especificarán qué atributos son accesibles. Como especifico SPECIFIC_ATTRIBUTES (3B) en la declaración, sólo se permitirá que procedan las peticiones que seleccionen un subconjunto específico de los atributos especificados en 3A, mientras que se denegará cualquier escalada de privilegios.

AWS mantiene una lista de diversas condiciones que puedes utilizar para afinar dicho acceso a AWS DynamoDB. Con un uso eficaz de las condiciones clave, puedes ocultar datos a varios usuarios y seguir así la PoLP en DynamoDB.

Cifrado en DynamoDB

DynamoDB ofrece a sus usuarios un proceso de cifrado fácil de integrar, además del control de acceso. DynamoDB dispone de cifrado del lado del servidor por defecto, y no se puede desactivar. DynamoDB utiliza el cifrado envolvente para cifrar todos los elementos que se almacenan en la tabla. AWS utiliza el cifrado simétrico AES-256 para cifrar todos los datos de DynamoDB.

Cada elemento de una tabla de DynamoDB se cifra mediante una clave de cifrado de datos (DEK). A continuación, esta DEK se cifra mediante una clave de tabla. Hay una clave de tabla por tabla. Cada clave de tabla puede descifrar varias DEK. Y, por último, esta clave de tabla se cifra utilizando una CMK. La Figura 4-18 ilustra este flujo.

Figura 4-18. AWS DynamoDB utiliza un proceso de cifrado de sobres de tres pasos en el que 1) se utiliza una CMK para cifrar una clave de tabla, luego 2) la clave de tabla se utiliza para cifrar DEKs, y luego 3) las claves se utilizan para cifrar elementos dentro de DynamoDB.

Cada vez que un cliente desea leer datos de la tabla, primero tiene que hacer una solicitud a KMS y descifrar la clave de la tabla mediante KMS. Si el cliente está autorizado a descifrar la clave de la tabla, DynamoDB la descifra y la almacena en caché en nombre del cliente. Esta clave de tabla puede utilizarse entonces para descifrar cada DEK y así descifrar elementos individuales de DynamoDB. De este modo, los clientes no tienen que hacer solicitudes repetidas al KMS y, por tanto, se ahorran las tarifas del KMS.

Consejo

La clave de tabla en DynamoDb se almacena en caché por conexión durante cinco minutos. Una clave de tabla almacenada en caché evita llamadas repetidas a AWS KMS y, por tanto, se traduce en un rendimiento más rápido y costes más bajos. Para aprovechar al máximo la capacidad de almacenamiento en caché de KMS, el uso de clientes que puedan agrupar las conexiones a la base de datos puede dar lugar a un mejor rendimiento y menores costes.

Ahora que he hablado de cómo se puede utilizar AWS KMS para cifrar datos en DynamoDB, te presentaré las tres opciones que tienes para utilizar KMS. Estas opciones son similares a las que tenías en AWS S3:

• CMK propiedad de AWS

• CMK propiedad del cliente

• CMK gestionado por el cliente

Como se ve en la Figura 4-19, el tipo de CMK puede seleccionarse a través de la consola de administración de AWS:

CMK propiedad de AWS

Esta es la opción por defecto en AWS. Una CMK propiedad de AWS es una CMK compartida que utiliza AWS para cifrar la clave de tabla de tu cuenta. Estas claves no aparecen en tu cuenta. AWS gestiona y maneja toda la actividad relacionada con la CMK. Esta CMK no está bajo tu control, y no puedes rastrear ni auditar ningún acceso a esta CMK. No se requiere ningún cargo adicional por cifrar datos utilizando una CMK propiedad de AWS.

KMS-Customer managed CMK

Esta es la opción más flexible para utilizar con AWS DynamoDB. Estas claves son gestionadas completamente por el cliente, y AWS no controla ni gestiona el ciclo de vida de las mismas. Al crear una tabla, puedes especificar la CMK de AWS KMS que deseas utilizar como CMK para la tabla. Opcionalmente, puedes rotar las claves cada año.

CMK gestionado por KMS-AWS

Las CMK gestionadas por AWS son claves que están en tu cuenta y que AWS gestiona en tu nombre. Como resultado, obtienes más control sobre las claves y puedes auditar y monitorear el acceso a estas claves. AWS, por su parte, se encarga de la seguridad de la infraestructura que respalda estas claves y las rota periódicamente. Sin embargo, las claves gestionadas por AWS incurren en los cargos rutinarios de KMS por cifrado y descifrado.

Figura 4-19. Puedes seleccionar el tipo de CMK que deseas utilizar para el cifrado en reposo en DynamoDB.

Servicio de datos relacionales de Amazon Aurora

Amazon Aurora es otro popular sistema de almacenamiento de datos que se utiliza en AWS. Aurora proporciona un reemplazo directo para motores RDBMS populares como PostgreSQL y MySQL. Al igual que AWS DynamoDB, las bases de datos de Aurora también pueden protegerse del acceso no autorizado de dos maneras:

• Utilizar la autenticación para impedir el acceso no autorizado. Esto puede dividirse a su vez en dos categorías de autenticación:

  • Autenticación de la base de datos IAM: utiliza AWS IAM para autorizar cada solicitud.

  • Autenticación por contraseña: utiliza el enfoque tradicional basado en contraseñas para autenticarse contra Aurora.

• Utilizar la encriptación para proteger los datos.

Como se ve en la Figura 4-20, puedes decidir el tipo de opción de autenticación que quieres utilizar al crear tu base de datos.

Figura 4-20. Puedes especificar tu elección de autenticación durante la creación de la base de datos.

Autenticación IAM en Amazon Aurora

En la autenticación IAM, en lugar de utilizar una contraseña para autenticarte en la base de datos, creas un token de autenticación que incluyes con tu solicitud de base de datos. Estos tokens pueden generarse fuera de la base de datos utilizando AWS Signature Version 4 (SigV4) y pueden utilizarse en lugar de la autenticación habitual.

La mayor ventaja que te proporciona la autenticación IAM es que tus identidades dentro de la base de datos se sincronizan con tus identidades dentro de tu cuenta de AWS. Esto evita que proliferen las identidades en tus recursos.

Sin embargo, la autenticación IAM tiene sus limitaciones. Puede haber una limitación en el número de conexiones que un clúster de BD puede tener por segundo, dependiendo de su clase de instancia de BD y de su carga de trabajo. Por ello, AWS recomienda utilizar la autenticación IAM sólo para el acceso personal temporal a las bases de datos.

Autenticación de contraseña

La autenticación por contraseña es el tipo tradicional de autenticación. En este caso, cada conexión a la base de datos tiene que iniciarse con el nombre de usuario y la contraseña tradicionales. Cada usuario y rol de la base de datos tiene que ser creado por un usuario administrador que exista en la base de datos. Las contraseñas suelen ser cadenas de texto que cada entidad llamante tiene que recordar e introducir al establecer la conexión. Los usuarios se crean con sentencias SQL como CREATE USER para MySQL o PostgreSQL.

Cifrado en Amazon Aurora

De forma similar a AWS DynamoDB y AWS S3, todos los datos almacenados en Amazon Aurora pueden cifrarse utilizando una CMK. Activar el cifrado es extremadamente fácil en Aurora, como se ve en la Figura 4-21.

Figura 4-21. Puedes activar la encriptación simplemente marcando la casilla "Activar encriptación" mientras creas tu base de datos. También puedes elegir la CMK que quieres utilizar para encriptar tu base de datos.

Puedes utilizar la clave gestionada por AWS para cifrar la base de datos o proporcionar una CMK existente que puedas controlar mediante KMS. Las ventajas y desventajas de utilizar una CMK administrada por el cliente frente a utilizar una CMK administrada por AWS son similares a las de utilizar AWS DynamoDB o utilizar AWS S3.

Saneamiento de soportes y borrado de datos

La eliminación de datos es un aspecto de la protección de datos que a menudo se pasa por alto y que los profesionales de la seguridad tienen que tener en cuenta. En los centros de datos físicos, después de dar de baja un servidor, los profesionales de TI tienen que realizar ciertas actividades (que detallaré más adelante) en este servidor antes de que pueda reutilizarse para cualquier otra actividad. Estas actividades dependerán de la clase de datos que se almacenaron originalmente en este servidor. Pueden incluir, entre otras, la puesta a cero de todos los datos, el reformateo de los datos, etc.

Si tu hardware almacenaba datos de alto secreto, es posible que tengas que borrar de forma segura los datos de este hardware antes de poder utilizarlo para almacenar datos no confidenciales. Este proceso se denomina limpieza de medios. No hacerlo puede hacer que los datos sean vulnerables a aplicaciones potencialmente no autorizadas que puedan acceder a estos hashes de datos.

En los sistemas en la nube, puede que no tengas un control total sobre el proceso de puesta en marcha y retirada de servidores. Este problema puede ser especialmente pronunciado en las arquitecturas de microservicios, donde es habitual poner en marcha nuevas proyecciones o darlas de baja.

Para empezar, me gustaría recordarte que cualquier dato sensible en cualquiera de tus volúmenes de almacenamiento debe estar siempre encriptado en reposo. Esto al menos disminuye la probabilidad de una fuga de datos. Por su parte, AWS asume la responsabilidad de desinfectar los medios de almacenamiento subyacentes en tu nombre, para todas sus capas de almacenamiento persistente, incluidos los volúmenes de almacenamiento respaldados por EBS (por ejemplo, Amazon Aurora, EC2 y DocumentDB), AWS desinfecta los medios por ti según lo prescrito por las normas NIST-800-88. AWS garantiza que los volúmenes de almacenamiento que utilices serán desinfectados y borrados de forma segura antes de ponerlos a disposición del siguiente cliente. Esta forma de sanear los medios hace que los volúmenes de AWS cumplan la mayoría de las normas reguladoras del sector.

Sin embargo, si trabajas en un sector muy regulado en el que el cifrado de datos y la garantía que ofrece AWS para el saneamiento de medios no son suficientes, puedes recurrir a herramientas de saneamiento de medios de terceros para borrar de forma segura tus volúmenes de almacenamiento antes de darlos de baja.

Resumen

Este capítulo ha tratado principalmente del almacenamiento de datos en AWS. Empecé exponiendo los argumentos a favor de la seguridad en torno al almacenamiento de datos, el control del acceso y el cifrado. La mayoría de los mecanismos de almacenamiento en AWS pueden protegerse de dos maneras. En primer lugar, puedes impedir el acceso no autorizado a tus datos sensibles mediante las políticas de AWS IAM. En segundo lugar, puedes cifrar los datos y asegurar la clave de cifrado, añadiendo así una capa adicional de seguridad a tu mecanismo de protección de datos.

Dado que los entornos de microservicios suelen dar lugar a mecanismos de persistencia políglotas, corresponde a los profesionales de la seguridad garantizar que cada uno de estos servicios preste especial atención a las políticas de seguridad en torno a cada almacenamiento de datos y aplique la PoLP en todos los mecanismos de almacenamiento.