La seguridad de una plataforma comienza por quién puede realizar qué acción sobre qué recurso y bajo qué condiciones. IAM decide permisos para APIs de AWS; KMS controla operaciones sobre claves y material cifrado bajo sus políticas. La aplicación todavía debe autorizar sus acciones de negocio. Poder leer un objeto o descifrar bytes no demuestra que corresponda entregarlos a un usuario.
El objetivo es dar a cada actor el acceso necesario, hacer observable su uso y conservar una recuperación compatible con esos límites. Cifrar datos sin preservar acceso seguro a su clave también puede bloquear una restauración.
Identidades y roles
Una identidad humana y un workload necesitan caminos de acceso distintos. La federación y las credenciales temporales reducen la dependencia de claves duraderas, pero su trust y permisos deben acotarse. Una trust policy de un rol responde quién puede asumirlo y bajo qué condiciones; la permissions policy responde qué puede hacer esa sesión. Autorizar AssumeRole no concede automáticamente permiso sobre los recursos posteriores.
En un servicio con contenedores, el rol de despliegue modifica el entorno, el task execution role permite al servicio tareas como obtener imagen o ciertos secretos, y el task role representa a la aplicación frente a APIs. Sus responsabilidades deben separarse y verificarse. Compartir un rol administrador entre los tres extiende una vulnerabilidad del código a toda la plataforma.
OIDC en el pipeline permite obtener sesiones temporales con claims comprobados. Emisor, audience y subject deben corresponder al sistema real; una configuración de GitHub no se traslada a Forgejo por parecerse el YAML.
Cómo se evalúan las políticas
Las identity-based policies se adjuntan a identidades; las resource-based policies se adjuntan a recursos y pueden nombrar principals. La evaluación depende del principal, la acción, las condiciones, el recurso y si hay acceso entre cuentas. Para accesos comunes dentro de una cuenta, los permisos concedidos por identidad y recurso pueden combinarse. No debe reducirse cualquier caso a una única suma o intersección.
Una permissions boundary limita el máximo que las políticas de identidad pueden conceder; no otorga permisos por sí misma. Las session policies y controles de organización aplicables pueden restringir más. Los grants directos de una resource policy a usuarios, roles o sesiones tienen reglas diferentes respecto a denegaciones implícitas: debe comprobarse el principal concreto antes de afirmar que una boundary corta todos los caminos.
Una denegación explícita aplicable prevalece sobre un permiso. Una ausencia de Allow es una denegación implícita, con evaluación que depende del camino descrito. Least privilege requiere acciones, recursos y condiciones específicas, y revisar APIs que no admiten resource-level permissions. Añadir * para que una prueba pase puede abrir un alcance distinto al previsto.
KMS y envelope encryption
La key policy es la política de recurso regional obligatoria de una clave KMS y define su uso y administración. Un Allow en IAM aislado no habilita una clave cuya key policy no permite ese camino: debe conceder el acceso apropiado o habilitar explícitamente el uso de políticas IAM. También pueden intervenir grants y denegaciones. Administrar la clave y usarla para descifrar son responsabilidades distintas; poder cambiar su política puede afectar esa separación.
--- config: look: handDrawn --- flowchart TD caller["Identidad autorizada de la carga de trabajo"] --> auth["Autorización de la aplicación"] auth --> kms["KMS<br/>Política de clave, IAM y concesiones"] kms -->|"Clave de datos en claro<br/>para uso local"| encrypt["Cifrar datos localmente"] kms -->|"Clave de datos cifrada"| envelope["Envoltura almacenada"] encrypt -->|"Texto cifrado"| envelope context["Contexto de cifrado no secreto"] --> kms caller -->|"Permiso de descifrado + contexto coincidente"| kms kms --> audit["Registro de auditoría"]
En envelope encryption, una data key cifra el contenido localmente y la clave KMS protege esa data key. Se conserva el contenido cifrado junto a la data key cifrada y los metadatos necesarios; la copia plaintext de la data key debe protegerse y descartarse cuando deje de necesitarse. Esto evita enviar todo el contenido a KMS para cada operación y mantiene una frontera de custodia que debe diseñarse.
El encryption context, disponible en operaciones criptográficas con claves KMS de cifrado simétrico, aporta pares clave–valor como datos autenticados adicionales. La misma información debe presentarse al descifrar el material al que quedó ligada, y puede usarse en condiciones de políticas. No es un secreto: puede aparecer en logs. Debe evitar incluir PII y usar valores confiables; un identificador declarado por un cliente no prueba su autorización.
Cifrado, rotación y revocación tienen efectos diferentes. Rotar una clave no revoca automáticamente copias plaintext ni elimina datos ya entregados. Una aplicación que conserva una data key plaintext en memoria puede continuar usándola sin otra llamada a KMS; el cache de claves necesita plazo y alcance explícitos. Un fallo de KMS o permisos puede impedir nuevos descifrados aunque el objeto cifrado esté disponible.
Auditoría y recuperación
La auditoría debe vincular principal y sesión con acciones, recursos, resultados y cambios de política. CloudTrail ayuda a observar APIs; el alcance de eventos y retención debe configurarse para los servicios y operaciones que se quieren investigar. No debe suponerse que cualquier lectura de datos queda registrada con la configuración por defecto. Los logs también necesitan acceso limitado y protección frente a alteración.
RTO expresa cuánto tiempo se admite para recuperar el servicio; RPO, cuánta pérdida de datos se admite medida en tiempo respecto al incidente. Se comprueban con la aplicación y su procedimiento, incluyendo identidades, claves, backups y dependencias. Cifrado o redundancia por sí solos no fijan valores universales. Una copia sin permisos válidos para descifrarla puede no servir durante una emergencia.
Qué verificar
Se deben probar un acceso permitido y varios rechazados: otro entorno, un recurso fuera del scope, context incorrecto y una denegación explícita. También conviene evaluar un grant de recurso al principal exacto y revisar quién puede cambiar políticas. Los simuladores aportan evidencia parcial; ciertas integraciones y condiciones requieren comprobación del camino real en un entorno aislado.
El ensayo de recuperación debe restaurar una copia cifrada con identidades autorizadas y medir tiempo y datos recuperados. Las señales incluyen accesos denegados inesperados, uso de roles, operaciones de claves y cambios de políticas. El resultado es un contrato de acceso comprobable y una recuperación que conserva ese contrato.