Arquitecto de Seguridad en la Nube

Pregunta de muestra 1

Harrow Defense Systems está construyendo una plataforma de fusión de sensores para una unidad de coalición. La plataforma debe ingerir fuentes de inteligencia de nivel Top Secret y datos tácticos de sensores de nivel Secret, y producir una única imagen operativa común de nivel Secret para comandantes en campo que cuentan únicamente con habilitaciones de nivel Secret. El diseño debe garantizar que ningún contenido Top Secret quede expuesto jamás en esa imagen descendente. Como arquitecto de seguridad en la nube, ¿qué enfoque de diseño satisface correctamente este requisito multinivel?

1. A.Ejecutar la plataforma de fusión como un solo sistema al nivel Top Secret y depender del control de acceso basado en atributos para filtrar el contenido Top Secret cada vez que un usuario con habilitación Secret consulte la imagen operativa común.
2. B.Encauzar el flujo de Top Secret a Secret mediante una guarda de dominio cruzado que inspeccione automáticamente el contenido y lo sanee con revisión humana antes de que cualquier salida llegue a la imagen Secret, bloqueando lo que no la supere.
3. C.Colocar las dos fuentes en segmentos de red separados unidos por un firewall que permita únicamente tráfico de Secret hacia Top Secret, y que los analistas vuelvan a capturar manualmente cualquier detalle Top Secret necesario en la imagen Secret.
4. D.Cifrar la fuente Top Secret en tránsito hacia la plataforma de fusión, almacenarla por separado de los datos Secret y publicar únicamente estadísticas agregadas generadas automáticamente en la imagen operativa común de nivel Secret.

Pregunta de muestra 2

Durante la auditoría de un sistema de IA en una firma de analítica en salud, el arquitecto de seguridad en la nube descubre que el mismo equipo reducido de científicos de datos puede, todo bajo una sola credencial compartida de cuenta de servicio, extraer expedientes identificables de pacientes hacia el repositorio de datos de entrenamiento, realizar el ajuste fino del modelo de resumen de notas clínicas y aprobar el modelo actualizado para producción. ¿Qué hallazgo debería priorizar el arquitecto en el informe de riesgos?

1. A.Las salidas de resumen del modelo se almacenan sin cifrado en reposo, lo que podría permitir que un atacante que obtenga acceso a nivel de red a la capa de almacenamiento lea directamente notas clínicas identificables.
2. B.La política de contraseñas del repositorio de datos de entrenamiento no exige la longitud mínima estándar de la firma, de 14 caracteres, aunque la autenticación multifactor sigue siendo obligatoria en cada intento de inicio de sesión.
3. C.El entorno carece de segregación de funciones: una sola credencial compartida permite que las mismas personas creen los datos de entrenamiento, realicen el ajuste fino del modelo y aprueben su propio despliegue, sin rendición de cuentas individual.
4. D.La cuenta de servicio compartida tiene un tiempo de expiración de sesión de ocho horas, en lugar del tiempo de inactividad de 30 minutos que la firma aplica a las cuentas interactivas de usuarios humanos en otros sistemas.

Pregunta de muestra 3

Usted es el arquitecto de seguridad en la nube de una empresa manufacturera que está modernizando su plataforma de monitoreo del piso de planta. El equipo de DevOps propone una sola identidad de servicio para el pipeline de despliegue: puede fusionar pull requests en la rama principal, ejecutar los pasos de plan y de apply de Terraform, y resguardar las credenciales de nube de larga duración que crean y modifican recursos de producción, todo con el fin de que una sola integración reduzca la complejidad del pipeline. Aplicando los principios de control de acceso, ¿cuál es la objeción más sólida que usted debe plantear antes de aprobar este diseño?

1. A.La objeción más sólida es que la identidad quedaría con privilegios excesivos, con amplios derechos permanentes para crear y modificar recursos de producción que van mucho más allá de cualquier paso individual, por lo que el diseño viola el mínimo privilegio, y acotar sus permisos únicamente a los recursos específicos de Terraform que este pipeline administra es lo que exige aplicar la separación de funciones a este diseño antes de su aprobación.
2. B.La objeción más sólida es que la identidad dependería de credenciales de nube de larga duración, de modo que un solo robo otorgaría acceso duradero, y la separación de funciones que le falta a este diseño se restablece una vez que esas credenciales se sustituyen por tokens de corta duración emitidos de nuevo y rotados automáticamente antes de cada ejecución individual del pipeline, lo cual impide que una credencial robada se reutilice entre despliegues.
3. C.La objeción más sólida es que una sola identidad concentraría tanto la autoridad para fusionar un cambio en la rama principal como la autoridad para aplicarlo a producción; esas dos funciones deben residir en identidades separadas, porque de lo contrario un solo compromiso de la identidad del pipeline, incluso a través del ejecutor de compilación, podría llevar un cambio sin revisar directamente a producción.
4. D.La objeción más sólida es que la separación de funciones está ausente en el paso de fusión, por lo que exigir que un segundo revisor independiente apruebe cada pull request antes de fusionarse aporta esa separación entre autor y aprobador, lo cual atiende la preocupación justo en el punto donde los cambios nuevos entran realmente a la rama principal que consume el pipeline de despliegue.