Clasificación de datos y Amazon Macie

Tu organización tiene 3.200 buckets de S3. Alguien de compliance hace una pregunta razonable: ¿cuáles de ellos guardan datos personales de clientes? La respuesta honesta, en la mayoría de las cuentas, es que nadie sabe.

Ese hueco no es solo un problema de auditoría. Cada control que podrías aplicar cuesta algo. Cifrar con una customer managed key, habilitar data events de CloudTrail a nivel de objeto, restringir el uso compartido entre cuentas, fijar los datos a regiones aprobadas: aplica todo eso en todos lados y la factura y la fricción se vuelven insostenibles. No apliques nada y un bucket termina arruinándole la semana a la empresa.

La clasificación de datos es la salida de esa trampa. La skill 4.2.1 del examen te pide implementar y aplicar un esquema de clasificación, y son 2 trabajos distintos. Implementarlo es definir niveles y etiquetar datos. Aplicarlo es que la etiqueta cambie de verdad lo que AWS permite.

Un nivel es un conjunto de reglas de manejo, no una calcomanía

Un esquema de clasificación son pocos niveles, cada uno atado a una línea base de controles. Una forma común se ve así:

Los nombres de los niveles importan menos que la segunda columna y la tercera. Una etiqueta sin reglas de manejo atadas es decoración. Una regla de manejo sin etiqueta a la cual atarse no tiene a qué aplicarse.

Acá es donde los equipos se equivocan de forma predecible. Da tentación clasificar todo en el nivel más alto, con la teoría de que protección de más nunca hace daño. AWS dice lo contrario sin vueltas: sobre-clasificar genera gasto injustificado en controles caros, entorpece las operaciones del negocio y desvía la atención de los datasets que sí la necesitan. Organismos como ISO y NIST recomiendan esquemas por niveles exactamente por eso y desaconsejan las prácticas que tratan todos los datos por igual. Si tu esquema mete el 90% del estate en el nivel más alto, el esquema falló aunque cada dataset esté "protegido".

Los 5 pasos, y dónde se engancha cada servicio

AWS describe la clasificación como un proceso repetible, no como un proyecto de una sola vez. Cada paso tiene un servicio que lo sostiene:

1. Establecer un catálogo de datos. Inventaria qué tipos de dato tienes, cómo se usan y cuáles caen bajo una regulación. AWS Glue Data Catalog guarda y comparte esa metadata con seguimiento de cambios de esquema.
2. Evaluar criticidad e impacto para el negocio. Para cada tipo de dato, ¿qué le pasa al negocio si se divulga, se altera o se pierde? Este es el paso que decide el nivel, y no es un paso técnico.
3. Etiquetar la información. Atar el nivel a los recursos reales. En AWS eso es tagging, y lo vemos enseguida.
4. Manejar los activos según el nivel. Los controles de esa tercera columna se vuelven políticas, keys y settings de verdad.
5. Monitorear de forma continua. Verificar que las etiquetas sigan coincidiendo con la realidad y que el manejo siga aplicado. Acá viven Macie y AWS Config.

El paso 3 y el paso 5 son el par que la mayoría de los esquemas rompe. Etiquetar es una declaración que hace quien creó el recurso. Monitorear es verificar esa declaración contra los bytes que efectivamente están guardados. Un esquema con etiquetado y sin verificación es un esquema construido sobre la esperanza.

Los tags son el mango del que agarra el esquema

En AWS la etiqueta práctica es un tag, y una sola clave de tag usada de forma consistente vale más que una taxonomía elaborada que nadie aplica. Algo como DataClassification con valores public, internal, confidential y restricted.

La razón para estandarizar en una sola clave es que el tag se vuelve una condición de política. Una bucket policy puede exigir un tag de principal que coincida:

{
  "Sid": "RestrictedDataNeedsMatchingClearance",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::example-data-lake/*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalTag/DataClearance": "restricted"
    }
  }
}

La misma idea funciona en una key policy de KMS, así que la key del nivel confidencial solo la pueden usar los principals que llevan el tag de clearance que corresponde. Eso es control de acceso basado en atributos aplicado a un esquema de clasificación, y es la diferencia entre una etiqueta y un control.

Dos mecanismos mantienen los tags honestos:

• Prevención. Un SCP con una condición aws:RequestTag puede negar la creación de recursos cuando falta el tag de clasificación, para los servicios que admiten tagging al crear. Esto evita que aparezcan recursos sin etiquetar.
• Detección. La regla administrada de AWS Config required-tags marca los recursos a los que les falta el tag, y puede llevar una acción de remediación automática. Esto atrapa todo lo que la prevención dejó pasar.

Ninguno de los 2 te puede decir si el tag es correcto. Un bucket etiquetado internal que va acumulando números de pasaporte en silencio pasa las dos revisiones. Ese punto ciego puntual es lo que Macie existe para cerrar.

Macie empieza con un inventario, no con un escaneo

Habilita Amazon Macie en una cuenta y lo primero que hace es generar y mantener un inventario de tus buckets general purpose de S3, y después evaluarlos y monitorearlos por seguridad y control de acceso. Todavía no lee el contenido de ningún objeto. Esta etapa es metadata: settings de acceso público, settings de cifrado, uso compartido, replicación, cantidad de objetos y cuánto del bucket podría analizar Macie si se lo pides.

Cuando los settings de un bucket cambian de forma que reducen su seguridad o su privacidad, Macie escribe un policy finding:

Una propiedad de los policy findings hace tropezar a todo el mundo, así que nombrémosla antes de que muerda: Macie genera un policy finding solo si el cambio ocurre después de habilitar Macie en la cuenta. Un bucket cuyos settings de block public access ya estaban deshabilitados cuando prendiste Macie, y que siguió así, no produce ningún finding. Macie está mirando cambios, no auditando una línea base. Para ver el estado previo lees el inventario de buckets y su desglose de acceso público, y por eso el inventario es una feature de primera clase y no un efecto secundario.

Los policy findings se guardan 90 días. Si un policy finding se repite, Macie actualiza el finding existente e incrementa el contador de ocurrencias en vez de crear uno nuevo.

Dos formas de mirar dentro de los objetos

Leer el contenido de los objetos es una actividad aparte y facturada, y Macie te da 2 métodos con trabajos genuinamente distintos.

El descubrimiento automático de datos sensibles es la opción de amplitud. Macie evalúa de forma continua tu inventario de buckets, usa muestreo para elegir objetos representativos y los analiza, con un ciclo por día. Por defecto cubre cada bucket general purpose de S3, y para un administrador de Macie eso incluye los buckets de las cuentas miembro. Lo acotas excluyendo buckets, que conviene hacer con los que solo guardan logs. Por defecto usa el conjunto de managed data identifiers que AWS recomienda para el descubrimiento automático, y puedes cambiarlo por identifiers administrados puntuales, los tuyos propios, o los dos. La salida son sensitive data findings, puntajes de sensibilidad por bucket y un heat map interactivo del estate.

Los sensitive data discovery jobs son la opción de profundidad. Defines los buckets, la profundidad de muestreo y criterios tomados de las propiedades de los objetos, y después corres el job una vez para una evaluación puntual o con un schedule recurrente.

El límite de costo conviene memorizarlo porque le da forma a la respuesta de las preguntas de escenario. Cuando habilitas Macie por primera vez, la cuenta entra en una prueba gratuita de 30 días que cubre la evaluación de buckets y, según los settings de la cuenta, el descubrimiento automático. Los discovery jobs no están incluidos en la prueba gratuita. Si una pregunta menciona un equipo que habilitó Macie, no vio cargos y después recibió una factura sorpresa, el culpable habitual es un discovery job.

Qué busca Macie, y qué ignora

Tres componentes deciden la superficie de detección:

• Los managed data identifiers son los criterios integrados de AWS, con machine learning y coincidencia de patrones. Cubren una lista grande y creciente de tipos de dato sensible de muchos países y regiones: varias clases de PII, información financiera y datos de credenciales.
• Los custom data identifiers son tuyos. Una expresión regular que define un patrón de texto, opcionalmente afinada con secuencias de caracteres y una regla de proximidad. Así detectas identificadores propietarios, nombres clave internos o un formato de número de cuenta propio de la casa.
• Las allow lists definen texto y patrones de texto que Macie debe ignorar. El uso canónico son los teléfonos públicos y los representantes con nombre de tu propia organización, o los datos de fixtures de prueba que hacen saltar los detectores de PII en cada corrida.

Las allow lists son la perilla de ajuste que la gente olvida que existe. Si un tipo de finding se dispara una y otra vez sobre datos que son públicos a propósito, el arreglo es una allow list, no reglas de supresión apiladas sobre un detector ruidoso.

Cuando Macie sí encuentra algo, escribe un sensitive data finding que nombra la categoría:

A diferencia de los policy findings, cada sensitive data finding se trata como nuevo y único, incluso para el mismo objeto entre corridas. También se guardan 90 días, y ese es un techo de retención que conviene planificar: si la evidencia tiene que durar más de 90 días, expórtala por EventBridge o Security Hub CSPM hacia almacenamiento que controles tú.

Macie en una organización

Macie se integra con AWS Organizations, y las reglas son lo bastante puntuales como para ser material de examen.

La cuenta de administración de Organizations designa un administrador delegado de Macie, y solo la cuenta de administración puede hacer, cambiar o quitar esa designación. Una organización tiene exactamente un administrador de Macie, y una cuenta no puede ser administradora y miembro al mismo tiempo.

Después viene la propiedad que hace tropezar los armados multi-región: Macie es un servicio regional, pero AWS Organizations es global. La designación del administrador es por región. Si la cuenta de administración designa un administrador en us-east-1, ese administrador puede manejar cuentas miembro solo en us-east-1. Cubrir 4 regiones significa entrar a cada una y designar el administrador 4 veces. La cuenta designada tiene que ser la misma en todas las regiones, pero la designación se repite.

Tres reglas más vale la pena llevarse:

• Un administrador de Macie puede asociarse con no más de 10.000 cuentas miembro en cada región.
• El administrador no puede habilitar Macie para la cuenta de administración de Organizations. Si quieres esa cuenta como miembro, alguien de esa cuenta tiene que habilitar Macie ahí primero.
• Una cuenta miembro no se puede desasociar sola. Solo el administrador la puede quitar, y quitarla deja Macie habilitado en la cuenta como cuenta standalone, no lo apaga.

Cerrar el círculo del finding al control

Un finding sobre el que nadie actúa es una versión más lenta de no mirar. Macie publica sus findings en Amazon EventBridge como eventos, y eso los enruta a targets como funciones Lambda y topics de SNS para procesarlos casi en tiempo real. También puedes configurar Macie para publicar findings en AWS Security Hub CSPM, que los agrega junto a los de GuardDuty, Inspector y el resto, y admite agregación entre regiones hacia una sola región.

El patrón de aplicación que satisface la skill 4.2.1 se ve así de punta a punta:

1. El descubrimiento automático de Macie encuentra SensitiveData:S3Object/Financial en un bucket etiquetado DataClassification=internal.
2. El finding aterriza en EventBridge, capturado por una regla que filtra por tipo de finding y severidad.
3. Un target Lambda re-etiqueta el bucket a confidential y abre un ticket nombrando al dueño según el tag de owner del bucket.
4. Como la bucket policy y la key policy de KMS ya están atadas a DataClassification, las reglas de manejo del nivel entran en efecto en el momento en que cambia el tag.

El paso 4 es todo el punto. Si el tag no está cableado a nada, la automatización solo le cambió el nombre a un problema.

Consejos para el examen

• La skill 4.2.1 dice implementar y aplicar. Una respuesta que solo detecta y reporta queda incompleta cuando otra opción conecta la etiqueta con un permiso.
• Sobre-clasificar es una respuesta equivocada, no una precavida. Ojo con las opciones que proponen el control más estricto para todos los datos.
• Macie analiza buckets general purpose de Amazon S3. Si una pregunta involucra contenido de RDS, EBS o DynamoDB, Macie no es la respuesta.
• Los policy findings solo se disparan por cambios hechos después de habilitar Macie. Las debilidades preexistentes se ven en el inventario de buckets, no como findings.
• Descubrimiento automático = amplio, continuo, muestreado, todos los buckets por defecto, incluido en la prueba gratuita de 30 días. Discovery job = dirigido, a demanda o con schedule, la profundidad que configures, no incluido en la prueba gratuita.
• Custom data identifier = una regex para algo que AWS no conoce. Allow list = texto para ignorar. Apuntan en direcciones opuestas.
• Las dos categorías de finding se guardan 90 días. Los policy findings se actualizan en el lugar al repetirse; los sensitive data findings siempre son nuevos.
• Macie es regional. La designación del administrador delegado, las asociaciones de miembros y la cuota de 10.000 miembros son todas por región, y solo la cuenta de administración de Organizations puede designar al administrador.
• Los findings llegan a la automatización por EventBridge, y a una vista consolidada de postura por Security Hub CSPM.

Lo único que hay que llevarse: la clasificación es lo que vuelve pagable cada control posterior de este tema. El cifrado, las key policies, el alcance de los certificados y la rotación de secretos se abaratan y se afinan cuando aplican al subconjunto correcto en vez de a todo. La próxima lección toma la regla de manejo del nivel confidencial de forma literal y la construye con KMS.