AWS Builder Center

Builder Center

Cuatro resultados posibles: cómo escribir un requisito de seguridad personalizado en AWS Continuum

El estándar de seguridad de la empresa tiene cuarenta páginas y una frase que todos citan: "las operaciones sensibles deben registrar eventos de auditoría relevantes". En cada revisión de diseño alguien pregunta qué cuenta como operación sensible, qué es un evento relevante y dónde debe quedar escrito. Cada revisor responde distinto. La frase lleva años en el documento y nunca ha detenido un diseño.

vtjean

Un requisito de seguridad personalizado en AWS Continuum obliga a contestar esas preguntas antes de que llegue la revisión. Este artículo repasa los campos del formulario, pero los organiza alrededor de otra observación: cada requisito que escribes tiene cuatro resultados posibles en una revisión de diseño, y un buen requisito se escribe pensando en los cuatro.

Dónde vive un requisito

AWS Continuum se presentó en junio 2026 como un servicio que descubre, prioriza, valida y remedia riesgos de seguridad a lo largo del ciclo de vida del software. Incluye el agente que antes se llamaba AWS Security Agent, que hace revisiones de diseño, revisiones de código, modelado de amenazas y pruebas de penetración. La consola y la documentación todavía usan el nombre AWS Security Agent, así que ese es el nombre que vas a buscar. La parte llamada AWS Continuum for code vulnerabilities está en preview con acceso por solicitud. Los requisitos de seguridad pertenecen al agente.
Un requisito de seguridad define un estándar o una política contra la que el agente evalúa tu aplicación durante las revisiones de diseño y de código. Las revisiones de código incluyen escaneos completos del repositorio y escaneos diferenciales de solo el código que cambió. Cuando un diseño o un código no cumple, el agente reporta un hallazgo.
Los requisitos viven dentro de packs. Hay dos tipos:
  • Packs administrados por AWS: ASA Base, AWS Well-Architected, NIST CSF y PCI DSS. Sus requisitos son de solo lectura y AWS los actualiza con el tiempo.
  • Packs personalizados: los creas tú, con requisitos escritos a mano, copiados de un requisito administrado o generados a partir de documentos que subes.
Dos detalles de esta estructura condicionan todo lo demás. La documentación describe los requisitos como recursos que se configuran una sola vez y se comparten con todos los Agent Spaces, que son los espacios de trabajo por aplicación. Y un requisito solo se evalúa cuando el pack que lo contiene está habilitado.

Los cuatro resultados de una revisión de diseño

En una revisión de diseño, cada requisito recibe uno de cuatro estados:
  • Compliant: el diseño cumple el requisito según el análisis.
  • Non-compliant: el diseño lo incumple o lo atiende de forma insuficiente.
  • Insufficient data: los archivos subidos no tienen información suficiente para decidir.
  • Not applicable: el requisito no aplica a ese diseño.
La documentación recomienda concentrarse en Non-compliant y en Insufficient data, porque son los que requieren acción. Para el primero se corrige el diseño. Para el segundo se completa la documentación.
Quien haya configurado alarmas reconoce el patrón. Una alarma que no distingue entre "algo está mal" y "no tengo datos" termina despertando a alguien sin motivo o callándose cuando debería avisar. Con un requisito pasa lo mismo. Si no dice qué evidencia espera, es más difícil separar un diseño que incumple de uno que simplemente no lo menciona. Si no dice cuándo no aplica, la lista puede llenarse de hallazgos que nadie va a atender.
Por eso conviene escribir cada campo pensando en el estado que controla.

Los campos, leídos por el estado que controlan

El formulario de la consola pide cinco campos:
  • Nombre: hasta 80 caracteres. Identifica el control y no se puede cambiar después de crearlo.
  • Descripción: hasta 500 caracteres. Qué revisa el requisito y qué riesgo reduce.
  • Applicability: hasta 10,000 caracteres. Cuándo se evalúa y cuándo se marca como no aplicable.
  • Compliance criteria: hasta 10,000 caracteres. Qué demuestra cumplimiento y qué indica incumplimiento.
  • Remediation guidance: opcional, hasta 10,000 caracteres. Cómo corregir y dónde están tus estándares internos.
Applicability controla el estado Not applicable. La documentación sugiere frases explícitas como "aplica a todas las cargas que..." y "marcar como NOT_APPLICABLE si...". La documentación lo recomienda para evitar falsos positivos en cargas a las que el requisito nunca les correspondió.
Compliance criteria controla la frontera entre Compliant y Non-compliant. La recomendación es escribirlo en dos partes: qué demuestra un diseño que cumple, con indicadores técnicos, y qué patrones indican una violación. También conviene incluir los casos límite.
Insufficient data no tiene un campo propio. El agente marca ese estado cuando los documentos no traen información para decidir, y el comentario del hallazgo indica qué información falta. Ese comentario llega después de la revisión. Si el criterio de cumplimiento dice desde el principio qué evidencia espera encontrar en un diseño, el equipo de producto sabe qué escribir antes de subir el documento. Esto es una práctica de redacción, no una función documentada, pero sale directamente de cómo la documentación define ese estado.
Remediation guidance es el runbook. El detalle de cada hallazgo incluye un comentario que explica por qué el agente asignó ese estado, guía de remediación y enlaces a la documentación interna del requisito. Este campo es el lugar para esos enlaces.
Hay una recomendación más en la guía para generar requisitos desde documentos que también sirve al escribirlos a mano: describir el resultado esperado y no una única implementación. "Los datos en reposo están cifrados" produce un requisito que aplica a más diseños que una frase que nombra un servicio o una configuración concreta.

Un ejemplo completo

Volvamos a la frase del estándar de cuarenta páginas. Así puede quedar como requisito.
Nombre:
1
registrar-auditoria-en-operaciones-sensibles
Descripción:
1
Las operaciones que crean, modifican o eliminan permisos, credenciales o datos de clientes generan un evento de auditoría que permite reconstruir quién hizo qué, sobre qué recurso y con qué resultado. Reduce el riesgo de cambios no autorizados que no dejan rastro.
Applicability:
1
2
Esta regla aplica a toda carga de trabajo que exponga operaciones para crear, modificar o eliminar permisos de usuario, credenciales, llaves de acceso o datos de clientes, sea por API, interfaz web o procesos internos.
Marcar como NOT_APPLICABLE si la carga de trabajo no expone ninguna operación que cree, modifique o elimine permisos, credenciales, llaves de acceso o datos de clientes. Por ejemplo, un sitio que solo publica contenido público o un servicio de solo lectura.
Compliance criteria:
1
2
3
4
En este requisito, una operación sensible es cualquier operación que crea, modifica o elimina permisos, credenciales, llaves de acceso o datos de clientes.
Un diseño cumple si demuestra que cada operación sensible genera un evento de auditoría con identidad del actor, acción, recurso afectado, marca de tiempo y resultado de la operación, que los eventos se envían a un almacenamiento separado de la aplicación con acceso restringido, y que los eventos no incluyen secretos, contraseñas ni datos personales completos.
Un diseño no cumple si alguna operación sensible no genera evento, si el evento no permite identificar al actor o el resultado, si los eventos se guardan solo en el mismo almacenamiento que la aplicación puede modificar, o si los eventos contienen secretos o datos personales completos.
Evidencia esperada en el diseño: la lista de operaciones sensibles, el formato del evento de auditoría, el destino donde se almacena y cómo se excluyen secretos y datos personales.
Remediation guidance:
1
Identifica las operaciones que crean, modifican o eliminan permisos, credenciales, llaves de acceso o datos de clientes y define un formato de evento común con actor, acción, recurso, marca de tiempo y resultado. Envía los eventos a un destino con acceso restringido y separado de la aplicación. Enmascara o excluye secretos y datos personales antes de registrar. Consulta el estándar interno de auditoría en el enlace de tu organización.
La primera línea del criterio responde la pregunta del inicio sobre qué cuenta como operación sensible. La última le dice al equipo de producto qué tiene que aparecer en el documento de diseño para que la revisión llegue a Compliant o a Non-compliant en lugar de quedarse en Insufficient data.

Probar los cuatro estados

Un requisito es una prueba, y una prueba que nunca falló tampoco demuestra que funciona. Conviene verificar que cada estado sea alcanzable antes de que el requisito empiece a evaluar los diseños de otros equipos.
Hay una complicación. Un requisito solo se evalúa si su pack está habilitado, y los requisitos aplican a todos los Agent Spaces. Mientras dure la prueba, las revisiones nuevas de cualquier equipo también lo van a evaluar. Una opción es hacer esta etapa en una cuenta separada para pruebas. Las cuotas de packs y requisitos se cuentan por cuenta y Región, lo que sugiere que cada cuenta tiene su propio conjunto, pero la documentación no lo dice de forma explícita. Verifícalo antes de depender de esa separación. Si no tienes esa opción, avisa a los equipos que el requisito está en prueba.
Una forma práctica es preparar cuatro documentos de diseño cortos:
  1. Un diseño que cumple: lista las operaciones sensibles, define el formato del evento, el destino separado y cómo se excluyen secretos y datos personales.
  2. Un diseño que incumple: registra los cambios de permisos en la misma base de datos de la aplicación.
  3. Un diseño fuera de alcance: un sitio que solo publica contenido público.
  4. Un diseño ambiguo: menciona "registro de actividad" sin decir qué se registra ni dónde.
Si el primero sale Compliant, el segundo Non-compliant, el tercero Not applicable y el cuarto Insufficient data, el requisito distingue lo que tiene que distinguir. Si dos documentos distintos reciben el mismo estado, lee el comentario del hallazgo: explica el razonamiento del agente y ayuda a decidir qué campo ajustar.
Dos reglas de la documentación afectan esta prueba. Los cambios a un requisito, y habilitar o deshabilitar un pack, solo aplican a revisiones nuevas. Las revisiones existentes no cambian. Y una revisión de diseño no se puede volver a ejecutar. Para repetir la prueba después de editar, la opción de clonar una revisión crea una revisión nueva con los mismos documentos cargados.
La documentación no dice si dos revisiones con los mismos documentos dan siempre el mismo resultado. Como el análisis lo hace un agente, conviene clonar las revisiones y repetir la prueba antes de sacar conclusiones de una sola corrida.

Cuidar el ciclo de vida del pack

Escribir el requisito es la mitad del trabajo. La otra mitad es que siga diciendo lo mismo con el tiempo. Hay cuatro comportamientos documentados que conviene tener presentes al diseñar los packs.
Subir documentos reemplaza todo. Cuando subes documentos nuevos a un pack, el agente regenera todos sus requisitos y reemplaza los existentes, incluidos los que agregaste a mano. Una forma de evitar sorpresas es separar los requisitos generados desde documentos de los escritos a mano, cada grupo en su propio pack.
Una copia personalizada no recibe actualizaciones. Si partes de un requisito administrado, el resultado es un requisito independiente. Cuando AWS revisa el requisito original, tu copia no cambia. En sentido contrario, los packs administrados sí cambian solos: cuando AWS agrega o revisa un requisito, el cambio aplica a todas las cuentas que tienen el pack habilitado. Conviene revisar periódicamente ambos lados.
El nombre es permanente. No se puede cambiar después de crear el requisito, y en la API los requisitos se consultan y actualizan por su nombre dentro del pack. Vale la pena acordar una convención de nombres antes de crear el primero.
Borrar no borra la historia. Un requisito eliminado deja de evaluarse en revisiones futuras, pero sigue visible como resultado de solo lectura en las revisiones pasadas.

Desde la AWS CLI

La documentación muestra los cinco campos con sus nombres solo en la consola. La API también tiene operaciones para crear y actualizar requisitos en lote, pero con otros campos, como se explica al final de esta sección. La AWS Command Line Interface (AWS CLI) ayuda con el resto del ciclo: preparar el pack, inventariar lo que existe y guardar una copia del contenido.
Crear el pack deshabilitado. En la API, un pack nuevo queda habilitado si no indicas otro estado, así que conviene crearlo deshabilitado mientras se escriben los requisitos. Para probarlos hay que habilitarlo, como se explica en la sección anterior:
1
aws securityagent create-security-requirement-pack --name auditoria-operaciones-sensibles --description "Requisitos de auditoria para operaciones sensibles" --status DISABLED
Listar los packs personalizados de la cuenta:
1
aws securityagent list-security-requirement-packs --filter managementType=CUSTOMER_MANAGED
Listar los nombres de los requisitos de un pack:
1
aws securityagent list-security-requirements --pack-id ID_DEL_PACK --query "securityRequirementSummaries[].name"
Exportar un requisito a un archivo que puedes guardar en control de versiones:
1
aws securityagent batch-get-security-requirements --pack-id ID_DEL_PACK --security-requirement-names registrar-auditoria-en-operaciones-sensibles > registrar-auditoria-en-operaciones-sensibles.json
Habilitar el pack, primero para la prueba y después para el uso normal:
1
aws securityagent update-security-requirement-pack --pack-id ID_DEL_PACK --status ENABLED
El mismo comando, con DISABLED, sirve para retirar el pack rápido si empieza a generar hallazgos que no corresponden. En los packs administrados por AWS solo se puede cambiar el estado.
Un aviso sobre la exportación. La API usa nombres de campo distintos a los del formulario: name, description, domain, evaluation y remediation. La documentación no explica cómo se corresponden Applicability y Compliance criteria con domain y evaluation. Por eso este artículo usa la consola para crear y editar, y la CLI para inventario, respaldo y estado del pack.

Señal, objetivo y runbook

El hilo de esta serie se aplica sin forzarlo.
La señal son los hallazgos Non-compliant e Insufficient data de los requisitos personalizados en las revisiones de diseño. El primero dice que el diseño tiene un problema. El segundo dice que el diseño todavía no se puede evaluar.
El objetivo lo pone el equipo. Una propuesta razonable es que ningún diseño pase a implementación con hallazgos Non-compliant abiertos en los requisitos personalizados y que los Insufficient data se resuelvan completando el documento, no con una excepción. Es una propuesta, no una regla del servicio.
El runbook es el campo Remediation guidance. Si queda vacío, el hallazgo pierde el contexto propio de tu organización, como los enlaces a tus estándares internos.

Limitaciones

  • Las cuotas no son ajustables: 20 packs por cuenta y Región, 30 requisitos por pack y 150 requisitos habilitados por cuenta y Región. Con un máximo de 30 requisitos por pack, agrupar los requisitos por tema de control ayuda a no llegar al tope en un solo pack.
  • Los requisitos aplican a todos los Agent Spaces. La documentación no describe una forma de asignar un pack a una aplicación concreta, así que el alcance se controla con el campo Applicability.
  • Los packs se habilitan y deshabilitan completos, y un requisito solo se evalúa si su pack está habilitado. La consola también permite crear un requisito con o sin habilitarlo, y la cuota cuenta requisitos habilitados, pero la documentación no explica cómo se combina ese estado con el del pack. Verifica el comportamiento antes de depender de un requisito deshabilitado dentro de un pack habilitado.
  • Los cambios en requisitos y packs solo afectan revisiones nuevas, el nombre de un requisito es permanente y subir documentos reemplaza todos los requisitos del pack. Los detalles están en la sección sobre el ciclo de vida del pack.
  • Los requisitos generados desde documentos se enfocan en la carga de trabajo. Temas de gobierno a nivel de organización, como la estrategia de múltiples cuentas, el manejo del usuario raíz o el registro a nivel de cuenta, no generan requisitos.
  • Los packs de marcos de cumplimiento ayudan a identificar requisitos que pueden ser relevantes para un marco, pero no evalúan tu cumplimiento ni garantizan que pases una auditoría.
  • La API usa campos distintos a los de la consola y la documentación no publica la correspondencia entre ellos.
  • Los cuatro estados son los de las revisiones de diseño. En las revisiones de código de pull requests, el agente publica hallazgos con descripción, ubicación y guía de remediación, o un comentario que indica que no encontró problemas. Si el análisis de código está configurado solo para validar requisitos y no hay al menos un requisito habilitado, no habrá hallazgos basados en requisitos.
  • La evaluación la hace un agente y la documentación no dice si es repetible con los mismos documentos. Una sola corrida no basta para validar un requisito.

Recursos

# ai-security# cloud-security# security# security-and-compliance
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article