Amazon SCS-C02: Protección de Datos y S3 — Guía de estudio

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Forma parte de la AWS Security Specialty SCS-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

Políticas de bucket de S3, ARN de recursos y denegaciones explícitas

Una política de bucket de S3 es un documento JSON basado en recursos que se evalúa junto con las políticas basadas en identidad. Dos reglas dominan su comportamiento. Primero, un Deny explícito siempre prevalece: no importa cuántas declaraciones Allow existan, un Deny coincidente bloquea la solicitud. Segundo, el elemento Resource debe coincidir precisamente con el patrón del ARN de la acción. Las acciones a nivel de bucket como s3:ListBucket operan sobre arn:aws:s3:::my-bucket, mientras que las acciones a nivel de objeto como s3:GetObject y s3:PutObject operan sobre arn:aws:s3:::my-bucket/*. Una mala configuración común es conceder s3:GetObject sobre arn:aws:s3:::my-bucket sin el sufijo /* — la llamada a la API apunta a un ARN de objeto, ninguna declaración coincide y la solicitud es denegada por defecto.

La siguiente política deniega cualquier acceso que no sea TLS y concede lectura para un rol específico, usando ambas formas de ARN correctamente.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::reports",
        "arn:aws:s3:::reports/*"
      ],
      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
    },
    {
      "Sid": "AllowAnalyticsRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/Analytics" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::reports/*"
    }
  ]
}

Una trampa frecuente es intentar “crear” una excepción añadiendo un Allow posterior después de un Deny amplio. Las declaraciones de la política no son sensibles al orden, y la lógica de evaluación de IAM devuelve Deny en el momento en que existe una denegación coincidente. La solución correcta es acotar el Deny — por ejemplo, a través de un NotPrincipal o una Condition — en lugar de añadir una declaración permisiva debajo de él.

Reglas de ciclo de vida, vencimiento de objetos y Vault Lock

Las reglas de ciclo de vida de S3 automatizan las transiciones de clase de almacenamiento y el vencimiento de objetos. Para satisfacer los requisitos de retención — como eliminar PII 30 días después de su ingesta — adjunte una regla que haga que las versiones actuales de los objetos venzan después de 30 días y elimine permanentemente las versiones no actuales poco después. Para los metadatos relacionados escritos en DynamoDB, habilite el atributo TTL de DynamoDB para que los elementos se autoeliminen con el mismo calendario; combinar estos dos mecanismos es operacionalmente eficiente porque no se requiere Lambda, planificador o código de limpieza a medida.

LifecycleConfiguration:
  Rules:
    - Id: ExpirePIIAfter30Days
      Status: Enabled
      Filter: { Prefix: "ingest/" }
      Expiration: { Days: 30 }
      NoncurrentVersionExpiration: { NoncurrentDays: 1 }

Para datos archivados con retención regulatoria, S3 Glacier Vault Lock proporciona un control WORM separado a nivel de bóveda (vault). Una vez que la política de Vault Lock se confirma (un proceso de dos pasos de iniciar/completar dentro de 24 horas), no puede ser alterada, ni siquiera por el usuario raíz de la cuenta. Esto es distinto de Object Lock, que opera a nivel de objeto de S3.

Block Public Access y CloudFront OAC

S3 Block Public Access (BPA) es un conjunto de cuatro interruptores a nivel de cuenta y de bucket que anulan cualquier ACL o política que de otro modo otorgaría acceso público. Habilite los cuatro a nivel de cuenta y refuércelo con una SCP, como denegar s3:PutBucketPublicAccessBlock cuando relajaría la configuración. Esta defensa en profundidad evita que un ingeniero vuelva a exponer un bucket accidentalmente a través de una ACL permisiva.

Para el contenido de cara al público servido a través de CloudFront, el patrón correcto es Origin Access Control (OAC). OAC firma las solicitudes de CloudFront a S3 usando SigV4; la política del bucket entonces permite únicamente al principal de servicio (service principal) de la distribución de CloudFront. Confiar solo en CloudFront sin OAC (o el OAI heredado) deja la URL de S3 directamente accesible, anulando los controles de acceso y el WAF del CDN. El bucket debe permanecer privado, con BPA habilitado, y la política acotada al ARN de la distribución:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::site-assets/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E1ABCXYZ"
    }
  }
}

S3 Object Lock y Replicación entre Regiones

Object Lock impone una semántica WORM en objetos individuales y requiere que el versionado esté habilitado y que Object Lock se active en el momento de la creación del bucket (no se puede añadir posteriormente a un bucket existente sin contactar a AWS). Existen dos modos de retención:

• Modo Governance: los principales con privilegios con s3:BypassGovernanceRetention pueden acortar o eliminar la retención.

• Modo Compliance: ningún usuario —incluido el raíz de la cuenta de AWS— puede eliminar o sobrescribir el objeto ni reducir su período de retención hasta que este venza. Adicionalmente, se puede aplicar y eliminar una retención legal (legal hold) de forma independiente por usuarios con s3:PutObjectLegalHold.

El modo Compliance es la elección correcta cuando el requisito es la inmutabilidad absoluta frente a todas las identidades. Para extender esa garantía a través de Regiones, combine Object Lock con S3 Replication. Los objetos replicados conservan su configuración de bloqueo en el bucket de destino (que también debe tener Object Lock habilitado), por lo que un evento que afecte a toda una Región o un intento de eliminación malicioso no pueden comprometer la copia retenida.

Macie y Athena para descubrimiento e investigación

Amazon Macie utiliza identificadores de datos gestionados y personalizados para escanear objetos de S3 en busca de PII, PHI, credenciales y otros patrones de datos sensibles. Reporta los hallazgos a Security Hub y EventBridge, permitiendo la remediación automatizada, como poner en cuarentena objetos con una política de bucket restrictiva basada en etiquetas. Habilite Macie en cada Región que almacene datos de clientes y delegue la administración a través de AWS Organizations para centralizar los hallazgos.

Amazon Athena proporciona SQL sin servidor sobre datos en S3, y es la herramienta estándar para consultar eventos de datos a nivel de objeto de CloudTrail. Para investigar quién accedió a un objeto de S3 específico, habilite los eventos de datos de CloudTrail para el bucket, entregue los registros a un bucket de S3 central y consulte con Athena:

SELECT eventTime, userIdentity.arn, sourceIPAddress, requestParameters
FROM cloudtrail_logs
WHERE eventName IN ('GetObject','DeleteObject')
  AND requestParameters LIKE '%reports/q3-financials.pdf%'
  AND eventTime > '2024-01-01T00:00:00Z';

Errores comunes y sus causas raíz

• Falta de /* en los ARN de objetos: Las llamadas a la API a nivel de objeto se evalúan contra bucket/clave, no contra el ARN del bucket. Sin /*, ninguna declaración coincide y IAM devuelve una denegación implícita, lo que se manifiesta como errores 403 inesperados en GetObject incluso cuando el “bucket” parece estar permitido.

• Añadir un Allow después de un Deny explícito: La evaluación de IAM no depende del orden; cualquier Deny que coincida cortocircuita en una denegación. La solución es reducir el alcance de la denegación (mediante Condition, NotPrincipal o NotResource), no añadir declaraciones permisivas.

• CloudFront sin OAC o una política de bucket restrictiva: La URL de origen de S3 sigue siendo accesible directamente, eludiendo las URL firmadas, las reglas de WAF y las restricciones geográficas. Habilite siempre el Bloqueo de Acceso Público (BPA) en el bucket de origen y restrinja s3:GetObject al principal de servicio de CloudFront mediante AWS:SourceArn.

• Asumir que Object Lock se puede habilitar en un bucket existente: Object Lock debe configurarse en el momento de la creación del bucket. Para adaptarlo, es necesario crear un nuevo bucket con Object Lock habilitado y migrar los datos.

• Confundir el modo de gobernanza y el modo de conformidad: El modo de gobernanza no impide que un usuario con privilegios elimine la retención; solo el modo de conformidad bloquea incluso a la cuenta raíz.

Problema práctico: Escenario de caso de uso

Escenario: Meridian Financial almacena extractos de clientes, registros de transacciones y archivos de cumplimiento normativo a largo plazo en múltiples buckets de S3 en dos regiones de AWS. Su entorno utiliza CloudFront para portales de clientes, registro entre cuentas y transiciones de ciclo de vida automatizadas a clases de almacenamiento de archivo para la retención regulatoria.

Desafío: Una revisión interna reciente encontró varios buckets con políticas inconsistentes que exponían PII (Información de Identificación Personal), sin retención inmutable para los registros archivados y sin una forma centralizada de descubrir dónde residen los objetos confidenciales entre cuentas y regiones.

Enfoque recomendado:

1. Habilitar S3 Block Public Access a nivel de cuenta y de bucket e implementar CloudFront Origin Access Control (OAC); restringir la política del bucket para permitir GetObject solo desde el principal de OAC de CloudFront usando ARN de recursos precisos y añadir denegaciones explícitas para cualquier solicitud que no provenga a través del OAC.
2. Forzar el cifrado del lado del servidor con AWS KMS exigiendo kms:Encrypt/kms:GenerateDataKey en una política de bucket y añadir denegaciones explícitas para las solicitudes PutObject que no incluyan x-amz-server-side-encryption y el kms:context requerido para evitar cargas no cifradas.
3. Configurar S3 Object Lock en modo de conformidad para los buckets que deben ser inmutables y habilitar la Replicación entre Regiones (CRR) con reglas de replicación que preserven los metadatos de bloqueo de objetos para que los objetos replicados permanezcan inmutables en la región de DR (Recuperación ante Desastres).
4. Crear Reglas de Ciclo de Vida de S3 para realizar la transición de objetos antiguos a clases de almacenamiento de S3 Glacier y establecer la expiración de objetos para los períodos de retención permitidos; para los archivos que deben ser legalmente inmutables, colóquelos en cámaras de Amazon S3 Glacier y aplique políticas de Glacier Vault Lock para forzar la retención de escritura única.
5. Desplegar Amazon Macie en todas las cuentas para descubrir y clasificar PII, habilitar S3 Inventory y consultar los hallazgos con Amazon Athena para consultas de investigación, y activar la remediación automatizada (Lambda/Step Functions) para etiquetar, poner en cuarentena o mover objetos confidenciales a buckets bloqueados y cifrados.

Justificación: Este enfoque por capas impone el privilegio mínimo y el cifrado, proporciona retención inmutable y durabilidad entre regiones para el cumplimiento normativo, y utiliza Macie/Athena para el descubrimiento centralizado y la remediación automatizada, alineándose con las mejores prácticas de AWS para la protección de datos y la gestión del ciclo de vida.

Amazon Macie: Descubrimiento automatizado, trabajos de clasificación y listas de permitidos

Amazon Macie es un servicio de seguridad de datos administrado que utiliza aprendizaje automático y coincidencia de patrones para descubrir datos confidenciales —información de identificación personal (PII), números de tarjetas de pago (PAN), credenciales y tipos de datos definidos por regex personalizadas— almacenados en Amazon S3. Macie opera en dos modos complementarios que con frecuencia se confunden.

El descubrimiento automatizado de datos confidenciales es un proceso de bajo costo y en ejecución continua que muestrea objetos en cada bucket de la cuenta (o en toda una organización cuando Macie se delega a una cuenta de Seguridad). Construye una puntuación de sensibilidad e inventario por bucket. Este es el punto de partida correcto cuando tiene miles de buckets y aún no sabe dónde residen los datos confidenciales, porque minimiza el costo y la sobrecarga administrativa al muestrear en lugar de escanear cada objeto.

Los trabajos de clasificación (trabajos de descubrimiento de datos confidenciales) son escaneos profundos, únicos o programados, dirigidos a buckets específicos. Una vez que el descubrimiento automatizado marca un bucket como contenedor de datos confidenciales, se crea un trabajo de clasificación acotado a ese bucket para un análisis exhaustivo. Por lo tanto, el patrón canónico es: habilitar el descubrimiento automatizado en toda la organización y luego continuar con trabajos de clasificación solo en los buckets marcados.

Las listas de permitidos son el mecanismo para suprimir coincidencias benignas conocidas. Si un lago de datos contiene PAN de prueba sintéticos (por ejemplo, el conocido rango de tarjetas de prueba 4111 1111 1111 1111), Macie marcará cada ocurrencia. Reescribir los datos o moverlos es costoso y disruptivo; el enfoque correcto es definir una lista de permitidos de Macie —ya sea una lista de texto plano con valores exactos o una regex— y asociarla con sus trabajos de clasificación y la configuración de descubrimiento automatizado. Las coincidencias con la lista de permitidos se excluyen de los hallazgos, mientras que los PAN genuinos continúan activando alertas.

Problema práctico: Escenario de caso de uso

Escenario: Meridian Financial opera un entorno de AWS con múltiples cuentas y cientos de buckets de S3 que almacenan registros de transacciones, documentos de clientes y archivos a largo plazo movidos a S3 Glacier. Su equipo de seguridad cuenta con cifrado y registro básicos, pero no tiene un descubrimiento centralizado de datos confidenciales ni controles de retención consistentes entre las cuentas.

Desafío: Un bucket orientado al público descubierto recientemente contenía registros de clientes archivados con PII (información de identificación personal) después de una política de bucket errónea y una transición de ciclo de vida a S3 Glacier. Meridian necesita encontrar todos los datos confidenciales, remediar las exposiciones y hacer cumplir una retención de archivado que cumpla con las normativas en el futuro.

Enfoque recomendado:

1. Habilitar Amazon Macie en toda la AWS Organization y activar el descubrimiento automatizado de S3 para que Macie evalúe continuamente los buckets y objetos en busca de datos confidenciales y configuraciones de riesgo.
2. Crear trabajos de clasificación de Macie que se dirijan a todos los buckets de S3; configurar identificadores de datos confidenciales personalizados para números de seguro social (SSN) y números de cuenta, y establecer listas de admisión (allow lists) para excluir datos de prueba conocidos, archivos de proveedores y cuentas de servicio.
3. Usar S3 Inventory para enumerar objetos en S3 Glacier, luego ejecutar S3 Batch Operations para restaurar temporalmente solo los objetos marcados por el inventario para el escaneo de Macie, de modo que los trabajos de clasificación puedan inspeccionar el contenido archivado en Glacier.
4. Automatizar la remediación enviando los hallazgos de Macie a Amazon EventBridge y Security Hub; activar funciones de Lambda para aplicar políticas de bucket de S3 seguras, habilitar S3 Block Public Access, eliminar ACL públicas y etiquetar buckets para su revisión.
5. Implementar retención duradera y prevención: habilitar S3 Versioning y S3 Object Lock (modos de gobernanza/cumplimiento) en buckets críticos, hacer cumplir el cifrado SSE-KMS con CMKs a través de políticas de bucket y desplegar SCP de AWS Organizations para bloquear ACL públicas y requerir cifrado y Object Lock cuando sea aplicable.
6. Habilitar los eventos de datos de CloudTrail para S3 e integrar los hallazgos en un SIEM para alertas y programación periódica de trabajos de clasificación de Macie para garantizar una cobertura continua.

Justificación: Este enfoque utiliza Macie para el descubrimiento automatizado y la clasificación dirigida (con listas de admisión), restaura objetos de Glacier solo cuando es necesario para la inspección, automatiza la remediación a través de EventBridge/Lambda y hace cumplir la retención inmutable y el cifrado con Object Lock y KMS, alineándose con las mejores prácticas de AWS para la detección, remediación y controles preventivos.

# Example allow list (regex form) matching common test PANs
Type: Regex
Regex: '^4111[- ]?1111[- ]?1111[- ]?1111$|^5555[- ]?5555[- ]?5555[- ]?4444$'
Name: synthetic-test-pans

Tratar los hallazgos brutos de Macie como la verdad absoluta sin configurar listas de admisión o de supresión produce fatiga de alertas y puede enmascarar incidentes reales dentro del ruido de los datos sintéticos; por eso, simplemente “confiar en los hallazgos” es la respuesta incorrecta para entornos con gran cantidad de falsos positivos.

Integración de los hallazgos de Macie con EventBridge

Macie publica cada hallazgo en Amazon EventBridge en el origen aws.macie. Esto le permite enrutar los hallazgos sin tener que consultar la API de Macie. Una regla típica reenvía los hallazgos de tipo Policy a SNS para notificar al personal de guardia y envía los hallazgos de SensitiveData a AWS Security Hub para su agregación.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Los destinos de la regla son temas de SNS, Security Hub o una función Lambda para remediación personalizada (por ejemplo, aplicando automáticamente una política de bucket restrictiva en el bucket infractor).

Condiciones de políticas de bucket para límites de la organización

S3 Block Public Access (BPA) solo bloquea el acceso que se origina desde la internet pública o desde principales anónimos. No impide que un principal autenticado en una cuenta de AWS diferente o en una AWS Organization diferente acceda al bucket si una política de bucket o una ACL otorgan dicho acceso. Por lo tanto, confiar únicamente en BPA es incorrecto cuando el requisito es evitar el acceso entre organizaciones; debe combinar políticas de bucket con Políticas de Control de Servicio (SCP) a nivel de Organizations.

Dos claves de condición de IAM permiten aplicar los límites de la organización de forma precisa:

• aws:ResourceOrgID: el ID de la organización propietaria del recurso al que se accede. Se usa en políticas de identidad/SCP para denegar a los principales el acceso a recursos fuera de su organización.

• aws:PrincipalOrgID: el ID de la organización del principal que realiza la llamada. Se usa en políticas de bucket para denegar el acceso desde principales fuera de su organización.

• aws:SourceOrgPaths: la ruta de la OU del principal de origen, lo que permite limitar el alcance a una OU específica (por ejemplo, solo la OU “Producción” puede escribir en un bucket de cumplimiento).

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideOrg",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:DeleteObject"],
    "Resource": "arn:aws:s3:::acme-compliance/*",
    "Condition": {
      "StringNotEqualsIfExists": {
        "aws:PrincipalOrgID": "o-abcd1234",
        "aws:SourceOrgPaths": "o-abcd1234/r-root/ou-prod-xyz/"
      }
    }
  }]
}

Combine esto con una SCP que deniegue s3:DeleteObject* en recursos donde aws:ResourceOrgID no coincida con su organización, y la exfiltración o eliminación entre organizaciones se vuelve imposible, incluso si una política de bucket se relaja accidentalmente.

S3 Object Lock: Modo de cumplimiento y versionado

Object Lock impone una semántica de escritura única y lectura múltiple (WORM) en versiones de objetos individuales. Requiere que S3 Versioning esté habilitado en el bucket (Object Lock sin versionado no es posible; el bloqueo protege un ID de versión específico, no la clave del objeto).

• Modo de gobernanza (Governance mode): los usuarios con el permiso s3:BypassGovernanceRetention pueden acortar o eliminar la retención. Adecuado para la aplicación de políticas internas.

• Modo de cumplimiento (Compliance mode): ningún principal, incluida la cuenta raíz de AWS, puede acortar, eliminar o borrar la versión del objeto hasta que expire el período de retención. Esta es la opción correcta para los requisitos de inmutabilidad regulatoria (SEC 17a-4, FINRA, archivado de HIPAA).

La retención se puede establecer por objeto (fecha Retain-Until) o mediante una configuración de retención predeterminada a nivel de bucket. Las retenciones legales (Legal Holds) son bloqueos separados e indefinidos que persisten hasta que un principal con el permiso s3:PutObjectLegalHold los elimina explícitamente.

aws s3api put-object-retention \
  --bucket acme-audit-logs \
  --key 2024/transactions.parquet \
  --retention '{"Mode":"COMPLIANCE","RetainUntilDate":"2031-01-01T00:00:00Z"}'

S3 Glacier Vault Lock: Cómo corregir errores en la política antes de completar el bloqueo

Vault Lock en S3 Glacier impone políticas de acceso inmutables al vault. El proceso consta de dos llamadas: initiate-vault-lock pone la política en un estado en curso (in-progress) con una ventana de 24 horas, y complete-vault-lock la hace permanente. Si se descubre un error tipográfico durante la ventana de 24 horas (por ejemplo, un Principal demasiado permisivo), la solución correcta y más económica es:

aws glacier abort-vault-lock --account-id - --vault-name compliance-archive
aws glacier initiate-vault-lock --account-id - --vault-name compliance-archive \
  --policy file://corrected-policy.json

abort-vault-lock cancela el bloqueo en curso sin costo alguno, permitiéndote reiniciar el proceso con la política corregida. Las “soluciones” alternativas (como eliminar y volver a crear el vault, lo que requiere borrar todos los 10 TB de archivos y volver a subirlos, incurriendo en cargos de recuperación y transferencia), o esperar a que se complete el bloqueo para luego buscar una solución alternativa, son un desperdicio o imposibles. Una vez que se ejecuta complete-vault-lock, la política es inmutable para siempre; la anulación solo es válida durante la ventana del estado en curso.

Trampa relacionada: Cadena de confianza de DNSSEC

Una trampa común entre dominios se relaciona con DNSSEC en Route 53. Habilitar la firma DNSSEC en una zona alojada (hosted zone) para un subdominio genera una Clave de Firma de Clave (KSK) y su registro DS correspondiente. Ese registro DS debe publicarse en la zona padre; sin él, los resolvers no pueden validar la cadena de confianza y tratarán las respuestas como falsas o recurrirán a una resolución insegura, interrumpiendo el servicio de DNS para los clientes que realizan la validación. Habilitar la firma sin exportar el registro DS e insertarlo en el registrador o en la zona padre es un estado de configuración incompleta, no una implementación funcional de DNSSEC.

← Cifrado · Todos los dominios · Seguridad de Redes y VPC →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Amazon →