En nuestro banco de preguntas de MLA-C01, unas 40 preguntas tratan de seguridad y cumplimiento, uno de los grupos más grandes de todos. La tarea 4.3 de la guía del examen cubre roles, políticas y políticas de bucket de IAM, las funciones de seguridad y cumplimiento de SageMaker, los controles de acceso de red a los recursos de ML y la seguridad de los pipelines de CI/CD, y la tarea 1.3 añade requisitos de cumplimiento como el cifrado de datos, la clasificación, la anonimización y el enmascaramiento, la PII, la PHI y la residencia de datos. Las preguntas suelen dar condiciones como "debe cumplir HIPAA" o "no debe pasar por internet" y piden combinar varios ajustes.
Este artículo divide la seguridad de ML en cuatro capas (red, cifrado, permisos y auditoría) y ordena los ajustes de SageMaker de cada una, y después pasa al manejo de datos sensibles, a CI/CD y la gestión de secretos, y al montaje de un escenario HIPAA. La visión general de la seguridad se trató antes en Monitoreo de Modelos, Optimización de Costos y Seguridad.
---
Divide la Seguridad en Cuatro Capas
Para proteger la cámara acorazada de un banco se controla quién entra al edificio (red), se cierra la cámara (cifrado), se decide quién tiene las llaves (permisos) y todo queda grabado en las cámaras (auditoría). Si falta una, todo el sistema se debilita. Las opciones de las preguntas de seguridad suelen salir una de cada una de estas cuatro capas.
| Capa | Pregunta que responde | Ajustes típicos | |------|------|------| | Red | ¿Por qué camino viajan los datos? | VPC, endpoints de VPC, aislamiento de red, grupos de seguridad | | Cifrado | ¿Los datos robados son ilegibles? | KMS (datos en reposo), TLS y cifrado entre contenedores (en tránsito) | | Permisos | ¿Quién puede hacer qué? | Roles de ejecución de IAM, mínimo privilegio, claves de condición, políticas de bucket | | Auditoría | ¿Quién hizo qué y cuándo? | CloudTrail, CloudWatch Logs, AWS Config |
!Las cuatro capas de la seguridad de ML, red, cifrado, permisos y auditoría, con los ajustes típicos de AWS de cada una
---
Capa 1, Red: VPC, Endpoints de VPC y Aislamiento de Red
Ejecutar Trabajos de SageMaker dentro de una VPC
Al crear un trabajo de entrenamiento, un trabajo de procesamiento o un modelo (endpoint), indicar subredes privadas y grupos de seguridad en VpcConfig hace que los contenedores funcionen dentro de tu VPC. Sin salida a internet (una puerta de enlace NAT), los contenedores tampoco llegan a S3, así que hay que crear un endpoint de VPC de puerta de enlace para S3 para que puedan leer los datos de entrenamiento y escribir los artefactos del modelo.
| Requisito | Ajuste | |------|------| | Los contenedores de entrenamiento acceden a S3 sin internet | Endpoint de VPC de puerta de enlace para S3 | | Las aplicaciones de la VPC invocan el endpoint sin internet | Endpoint de interfaz de SageMaker Runtime (PrivateLink) | | Llamar a la API de SageMaker (crear trabajos, etc.) desde la VPC | Endpoint de interfaz de la API de SageMaker (PrivateLink) | | Acceso desde las instalaciones locales sin internet | Direct Connect (o VPN) + endpoints de interfaz | | El bucket solo acepta solicitudes que llegan por nuestro endpoint de VPC | Condición aws:SourceVpce en la política del bucket |
Aislamiento de Red: Cortar por Completo el Tráfico Saliente del Contenedor
Con EnableNetworkIsolation activado, los contenedores de entrenamiento e inferencia no pueden hacer llamadas salientes a ningún sitio, ni siquiera a S3, y dentro del contenedor no hay credenciales de AWS. El entrenamiento sigue funcionando, porque SageMaker descarga los datos de S3 y sube los resultados fuera del contenedor usando el rol de ejecución. Se usa para impedir la fuga de datos por código cuyo origen no se puede verificar del todo o por algoritmos de AWS Marketplace (el aislamiento es obligatorio para los recursos de Marketplace).
Cifrado del Tráfico entre Contenedores
En un entrenamiento distribuido entre varias instancias, estas intercambian información como los pesos. Si un requisito exige cifrar también ese tráfico, activa el cifrado del tráfico entre contenedores. Es una práctica recomendada en el sector sanitario, pero puede alargar el tiempo y el costo del entrenamiento distribuido de aprendizaje profundo.
Consejo: "Los datos de entrenamiento no deben pasar por internet" son subredes privadas + un endpoint de puerta de enlace para S3, "el código de entrenamiento no verificado no debe poder enviar datos fuera" es el aislamiento de red, y "cifrar también el tráfico entre los nodos del entrenamiento distribuido" es el cifrado del tráfico entre contenedores.
---
Capa 2, Cifrado: KMS y Cifrado en Tránsito
Datos en Reposo: Dónde Indicar la Clave
| Objetivo | Dónde se configura | |------|------| | Datos de entrenamiento y artefactos del modelo en S3 | Cifrado predeterminado del bucket (SSE-KMS) y la clave KMS de salida del trabajo | | Volúmenes de almacenamiento de las instancias de entrenamiento y procesamiento | La clave KMS de volumen del trabajo | | Volúmenes de almacenamiento de las instancias del endpoint | La clave KMS de la configuración del endpoint | | Feature Store | Claves KMS del almacén en línea y del almacén sin conexión (S3) |
SSE-S3 es la opción más sencilla, en la que AWS gestiona por completo las claves, mientras que SSE-KMS cifra con una clave de KMS y registra el uso de la clave en CloudTrail. Dentro de esta, una clave administrada por el cliente (CMK) permite decidir con la política de clave quién puede usarla, activar la rotación automática y desactivar la clave para bloquear al instante el acceso a los datos.
Los Permisos de KMS se Comprueban en Dos Lugares
Para leer datos cifrados con una clave administrada por el cliente, el acceso debe estar permitido tanto en la política de IAM como en la política de clave. Si un trabajo de entrenamiento falla con "AccessDenied" aunque sus permisos de S3 sean suficientes, comprueba si al rol de ejecución le falta kms:Decrypt (lectura) o kms:GenerateDataKey (escritura) y si la política de clave permite ese rol.
Cifrado en Tránsito
Las llamadas a las API de AWS y a los endpoints se cifran con TLS (HTTPS). Añadir a la política del bucket una instrucción que deniegue las solicitudes en las que aws:SecureTransport sea false bloquea el acceso sin cifrar.
Consejo: "Auditar el uso de la clave y controlar directamente su rotación y acceso" es una clave de KMS administrada por el cliente. "Los permisos de S3 están, pero no se pueden leer los objetos cifrados" significa que falta la política de clave de KMS o el permiso kms:Decrypt.
---
Capa 3, Permisos: Roles de Ejecución y Mínimo Privilegio
Separa los Roles de las Personas del Rol de SageMaker
El rol de ejecución de SageMaker es el que usan los trabajos de entrenamiento y los endpoints para acceder a S3, ECR y CloudWatch. Créalo aparte de los roles de las personas (científicos de datos, ingenieros de MLOps) y da a quienes crean trabajos solo el permiso iam:PassRole que necesitan para entregar ese rol de ejecución.
| Técnica | Qué hace | Ejemplo | |------|------|------| | Separación de roles | Solo los permisos que necesita cada persona y servicio | Los científicos de datos solo entrenan, MLOps también despliega | | Permisos a nivel de recurso | Permitir solo buckets, prefijos o modelos concretos | El equipo A solo accede a s3://data/team-a/ | | Imponer claves de condición | Denegar la creación del trabajo sin los ajustes de seguridad | sagemaker:VpcSubnets, sagemaker:VolumeKmsKey, sagemaker:NetworkIsolation | | Políticas de bucket | Restringir entidades y rutas desde el lado del bucket | Solo un rol concreto de otra cuenta, solo a través del endpoint de VPC |
Las claves de condición permiten imponer ajustes de seguridad, por ejemplo para que "no se pueda crear un trabajo de entrenamiento sin subredes de VPC y sin clave de KMS". Para aplicar la misma regla en muchas cuentas, usa las políticas de control de servicios (SCP) de AWS Organizations.
SageMaker Role Manager, que creaba roles por perfil, ya no acepta clientes nuevos. AWS propone como sustituto la combinación de las herramientas nativas de IAM, IAM Identity Center y la infraestructura como código, como CloudFormation y CDK.
Consejo: "Impedir que los científicos de datos creen trabajos de entrenamiento sin los ajustes de seguridad" son las claves de condición de SageMaker en las políticas de IAM.
---
Capa 4, Auditoría: CloudTrail, CloudWatch y AWS Config
| Herramienta | Pregunta que responde | Uso en la seguridad de ML | |------|------|------| | CloudTrail | ¿Quién llamó a qué API y cuándo? | Seguir cambios de configuración de endpoints, borrados de modelos, uso de claves | | CloudWatch Logs | ¿Qué pasó dentro del contenedor? | Registros de entrenamiento e inferencia, causas de errores | | AWS Config | ¿La configuración actual cumple las reglas? | Reglas administradas como si las configuraciones de endpoint tienen clave KMS o si los notebooks tienen acceso directo a internet |
De forma predeterminada, CloudTrail guarda los eventos de administración en su historial durante 90 días. Para conservarlos más tiempo, crea un registro de seguimiento (trail) que los envíe a S3, y si hay que impedir la manipulación, añade el bloqueo de objetos de S3 y la validación de integridad de los archivos de registro. Aquí hay una trampa del examen. Las llamadas de inferencia como InvokeEndpoint son eventos de datos, así que no se registran de forma predeterminada. Si hay que auditar las llamadas de inferencia, debes activar aparte el registro de eventos de datos, que tiene costo adicional, y el cuerpo de la solicitud (los datos de entrada) no se registra.
Consejo: "Quién cambió la configuración del endpoint" es CloudTrail, "encontrar automáticamente los recursos de SageMaker que incumplen las reglas" es AWS Config, y "los registros de auditoría no deben poder modificarse ni borrarse" es el bloqueo de objetos de S3.
--