Atestación C5: prepare las evidencias de aseguramiento en la nube

Un cliente de servicios en la nube quiere saber qué protecciones gestiona el proveedor y cuáles siguen siendo responsabilidad suya. La Oficina Federal de Seguridad de la Información de Alemania (BSI) publica el Cloud Computing Compliance Criteria Catalogue, C5, como base estructurada para examinar ese aseguramiento. Para un CTO, prepararse significa hacer inspeccionables el perímetro del servicio, la implantación de los controles y los registros operativos, no limitarse a reunir políticas.

C5 es un catálogo de criterios que se utiliza para una atestación independiente, no una certificación al estilo ISO. La documentación del BSI sobre C5 es la referencia principal. Empiece por acordar con el auditor independiente la edición aplicable, el objetivo de aseguramiento y el alcance del examen.

Defina con exactitud qué servicio cubrirá el informe

Describa el servicio en la nube, las ubicaciones operativas, los límites organizativos y las dependencias. Un informe que cubre un servicio no cubre automáticamente todos los productos de la misma marca. Identifique los componentes de producción, las interfaces de gestión, las operaciones de soporte y los servicios externos que pueden afectar a las afirmaciones de aseguramiento.

La descripción del sistema debe permitir que una persona ajena entienda cómo entran los datos de los clientes en el servicio, cómo circulan por él y cómo salen. Incluya las vías de administración, los procesos de despliegue, la monitorización de seguridad, las copias de seguridad y el reparto de responsabilidades entre equipos. Explique las características del servicio y las condiciones operativas pertinentes en lugar de sustituir el relato por diagramas de arquitectura.

Resuelva estas cuestiones de alcance antes de recopilar evidencias:

• ¿Qué productos, regiones y entornos están incluidos?
• ¿Qué equipos administran la producción o pueden acceder a la información de los clientes?
• ¿Qué proveedores subyacentes dan soporte al servicio y cómo se tratan sus controles?
• ¿Qué configuraciones y tareas de seguridad siguen correspondiendo a los clientes?
• ¿Qué cambios significativos se produjeron, o están previstos, durante el periodo de examen?

Dé a las exclusiones una justificación explícita. Si se excluye un despliegue heredado, asegúrese de que las declaraciones dirigidas a los clientes no den a entender que está cubierto. El entregable es una descripción del sistema versionada y respaldada por registros de arquitectura, dependencias y responsabilidades.

Elija el tipo de informe antes de fijar el calendario de evidencias

El aseguramiento C5 se expresa por lo general mediante un informe de atestación del auditor. El tipo 1 aborda el diseño y la implantación de los controles en un momento dado. El tipo 2 examina además la eficacia operativa a lo largo de un periodo especificado.

El tipo 1 puede ser un hito útil al establecer un entorno de control, pero no responde a la misma pregunta que el tipo 2. Confirme lo que los clientes exigen realmente antes de elegir un informe provisional.

Acuerde con el auditor el periodo y las expectativas sobre las evidencias. No suponga una duración de observación universal. Un procedimiento redactado hacia el final de un periodo no puede acreditar que el control funcionara antes. Del mismo modo, una prueba actual satisfactoria no borra un fallo histórico.

Construya las evidencias en torno a la responsabilidad y la ejecución

Como método práctico de preparación, elabore un registro de evidencias que vincule cada criterio aplicable con el control implantado, el responsable, el perímetro del servicio, la fuente de las evidencias, la frecuencia de revisión y las carencias sin resolver. Registre las decisiones de aplicabilidad y su justificación; evite marcar un criterio como no pertinente solo porque su implantación sería difícil.

Separe tres preguntas: qué debería ocurrir, qué está implantado y qué ocurrió realmente. Una política responde a la primera. Los registros de configuración pueden respaldar la segunda. Los tickets, los registros de eventos, las aprobaciones y los resultados de pruebas respaldan la tercera.

Son ejemplos prácticos, no una lista de comprobación completa de C5. Utilice el catálogo y el alcance acordados para determinar la cobertura necesaria, incluidos los controles organizativos, de personal, físicos y técnicos.

Haga que las evidencias sean reproducibles

Para cada exportación o captura de pantalla, conserve el sistema de origen, la fecha de recopilación, el periodo pertinente, los filtros y la persona que la recopiló. Explique si representa la población completa o un elemento seleccionado. Los auditores necesitan entender la población de la que seleccionan las muestras; una carpeta que solo contiene ejemplos satisfactorios no es suficiente.

Dé preferencia a los registros que conservan el actor, la marca de tiempo, la acción y el resultado. Proteja las evidencias frente a modificaciones no autorizadas y evite exponer innecesariamente datos de clientes. Cuando sea necesario anonimizar u ocultar información, conserve contexto suficiente para que el revisor entienda lo que demuestra el registro.

Separe los controles heredados de las obligaciones que conserva

El aseguramiento de un proveedor de infraestructura puede respaldar la seguridad física o los controles de la plataforma subyacente. No acredita que la autorización entre inquilinos de su aplicación funcione. Documente la dependencia, el alcance del informe pertinente, el periodo, las excepciones y las responsabilidades que su equipo debe seguir cumpliendo.

Los controles complementarios de los clientes también necesitan una redacción práctica. «El cliente es responsable de la seguridad» es demasiado amplio. Especifique tareas como administrar los usuarios del inquilino, configurar la federación de identidades o revisar las políticas de acceso controladas por el cliente. Mantenga estas responsabilidades coherentes en la descripción del sistema, la documentación del servicio y los acuerdos contractuales.

Gestione la preparación como un programa de ingeniería

Empiece con una evaluación de carencias frente a los criterios acordados. Distinga la implantación ausente de las evidencias ausentes: requieren soluciones distintas. Una revisión no documentada puede requerir mejores registros; una revisión de accesos que nunca se hizo requiere un control operativo.

Asigne a cada carencia un responsable, una acción de corrección, sus dependencias y una fecha objetivo. Priorice los problemas que afectan a la separación entre inquilinos, los accesos privilegiados, los cambios en producción, la respuesta a incidentes y la recuperabilidad según los riesgos del servicio, no simplemente las tareas de documentación más fáciles.

Antes del periodo del tipo 2, compruebe que los controles recurrentes tienen calendarios viables y registros duraderos. Confirme quién los realiza en caso de ausencia o rotación de personal. En los controles basados en eventos, como la baja de cuentas, asegúrese de que puede identificarse la población que los desencadena.

Haga un recorrido de preparación con evidencias representativas. Siga un cambio desde la solicitud hasta el despliegue, un administrador que se marcha hasta la revocación y un ejercicio de recuperación hasta la acción correctiva. Así salen a la luz traspasos rotos que una revisión de políticas puede pasar por alto.

Durante el examen, mantenga un registro de solicitudes con responsables y estado de respuesta. Mantenga disponibles los registros originales, explique abiertamente las discrepancias y haga el seguimiento de las correcciones por separado de las evidencias históricas. No reescriba registros antiguos para que parezcan conformes. El auditor determina cómo afectan los hallazgos a las pruebas y a la opinión.

Ejemplo práctico: una aplicación gestionada sobre infraestructura externa

Supongamos, a título ilustrativo, que un proveedor opera una aplicación multiinquilino en una región, utiliza un proveedor de infraestructura externo y busca un aseguramiento de tipo 2. Su equipo controla las versiones de la aplicación, los permisos de los inquilinos, la administración de producción y los procedimientos de recuperación.

La descripción del alcance identifica la aplicación, la base de datos, el plano de gestión, las herramientas de soporte y la dependencia de infraestructura. Explica qué controles subyacentes se heredan y cuáles siguen correspondiendo al proveedor de la aplicación.

Para el aislamiento entre inquilinos, el equipo registra su diseño de autorización, las pruebas negativas automatizadas, los hallazgos de las pruebas de seguridad y las aprobaciones de las versiones. También conserva los registros de cambios que muestran cuándo cambió la lógica de autorización. El informe de la infraestructura es una evidencia de apoyo sobre la dependencia, no una prueba del aislamiento de la aplicación.

Para los accesos privilegiados, el equipo conserva la población de administradores, las aprobaciones de las concesiones, las decisiones de revisión y los registros de retirada. Supongamos que una revisión descubre una cuenta de soporte sin usar. El equipo registra el descubrimiento, la revocación, la evaluación de la exposición y la acción preventiva. Eso es más creíble que presentar solo la lista de cuentas ya depurada.

Para la recuperación, conserva el resultado de una prueba de restauración que muestra qué se recuperó, el tiempo transcurrido, las comprobaciones de integridad de los datos y las limitaciones sin resolver. Una tarea de copia de seguridad configurada no demuestra por sí sola la recuperabilidad. Cada conjunto de evidencias tiene un responsable y un periodo definido, de modo que el auditor puede vincular los registros con el control examinado.

Reutilice el trabajo de aseguramiento sin afirmar equivalencias

ISO/IEC 27001 se refiere a un sistema de gestión de la seguridad de la información con un alcance definido. SOC 2 es un informe de atestación con sus propios criterios y su propio contexto de información. C5 se centra en el aseguramiento de servicios en la nube conforme al catálogo del BSI.

Las evaluaciones de riesgos, los controles de acceso, los procedimientos de incidentes y los registros operativos existentes pueden servir a más de un programa. Reutilícelos mediante correspondencias específicas por versión y alcance y compruebe después las diferencias en los requisitos o en la presentación de informes. Un control compartido no supone una equivalencia automática entre marcos.

Elija la cartera de aseguramiento a partir de los requisitos reales de los clientes y de los riesgos del servicio. C5 no es obligatorio con carácter universal para todos los proveedores de nube; los requisitos de licitaciones, contratos o normativas sectoriales aplicables deben revisarse por separado. Ni un informe C5 ni otro documento de aseguramiento acreditan por sí solos el cumplimiento del RGPD o de NIS2.

Prepare el informe para las decisiones de los clientes

Los clientes necesitan la descripción del sistema, la fecha o el periodo, la opinión real, las excepciones y los límites de responsabilidad, no solo la etiqueta del informe. Al compartir informes, respete la confidencialidad contractual y aporte contexto para la evaluación del cliente.

Explique el estado de las correcciones sin dar a entender que las correcciones posteriores cambian la opinión histórica. Si el periodo del informe es anterior a un cambio importante de arquitectura, señale esa limitación. Acuerde exámenes recurrentes en función de las expectativas de los clientes y de los cambios operativos en lugar de tratar la atestación como una credencial atemporal.

Secani ayuda a los equipos a vincular la implantación de los controles y las evidencias con requisitos revisados. Modele el servicio y sus dependencias, asigne responsables y revisores, vincule los registros de apoyo y convierta las carencias de evidencias en tareas. Mantenga explícita la aprobación humana de las correspondencias y las conclusiones. El modelo de preparación para auditorías ayuda a preservar el alcance y la responsabilidad que hay detrás de cada afirmación.

Preguntas que conviene resolver antes del primer examen

¿Emite el BSI el informe?

El BSI publica el catálogo. Un auditor independiente realiza el examen y emite el informe de atestación; confirme con ese auditor el marco de aseguramiento aplicable y las condiciones del encargo.

¿Qué ocurre si no se ha producido ningún incidente real?

No invente un registro de incidente. Conserve evidencias de que el proceso se implantó y, cuando proceda, se puso a prueba en un ejercicio. Acuerde con el auditor cómo afecta la ausencia de eventos a las pruebas.

¿Qué debería hacer el equipo a continuación?

Tome un servicio de producción representativo y prepare su descripción del alcance, su matriz de responsabilidades y su registro de evidencias. Revise esos tres entregables con el futuro auditor antes de reunir un gran paquete de evidencias.