Mapa de controles · Trust Services Criteria (2017)
SOC 2
Evidencia de código para los criterios de acceso, perímetro y datos confidenciales en cada pull request, y evidencia de proceso para las aprobaciones de cambios desde cada fusión.
Evidencia de código
6criterios comprobados en cada pull requestActivo (proceso)
1de fusiones, aprobaciones, cambios de reglas y despliegues y releases registrados por GitHubPlanificado
8se puede evidenciar desde el código o GitHub; aún no construidoCriterios de nivel organizativo
Políticas, personas, proveedores, seguridad física y similares, enumerados más abajo.Gestionados por los procesos de su organizaciónUn informe SOC 2 Tipo II comprueba si los controles operaron durante todo un periodo. Las aprobaciones de cambios suelen ser donde los equipos de ingeniería dedican más tiempo a la auditoría, reuniendo tickets y capturas de pantalla de una muestra de cambios.
El blueprint de SOC 2 aporta evidencia de código para los criterios de acceso, perímetro y datos confidenciales en cada pull request. Cada pull request fusionado en la rama por defecto se sella como un registro de cambio con sus aprobaciones, checks y firmas: evidencia para CC8.1. El mapa completo está más abajo, con los criterios de nivel organizativo a continuación.
Toevan aporta evidencia para controles; nunca los certifica ni afirma que un marco esté cubierto. Si la evidencia es suficiente lo juzga su auditor. Los controles se muestran por id con los nombres cortos propios de Toevan; los títulos oficiales y el texto de los requisitos pertenecen al editor del marco.
Evidencia de código6
Sellada en cada pull request. Siempre parcial: el control también exige cosas fuera del código. Las reglas del blueprint SOC 2 comprueban parte de cada uno en cada pull request.
CC6.1Diseño de límites de accesoCC6 Protección del accesoCC6.3Cambios de permisos por rolCC6 Protección del accesoCC6.6Defensa frente a amenazas externasCC6 Protección del accesoCC6.7Límites al movimiento de datosCC6 Protección del accesoC1.1Marcado de datos confidencialesC1 Datos confidencialesC1.2Eliminación de datos confidencialesC1 Datos confidenciales
Activo (proceso)1
Pull requests fusionados, aprobaciones, checks obligatorios, protección de ramas, rulesets y bypasses, y despliegues y releases registrados por GitHub, cada uno sellado.
CC8.1Aprobaciones de cambiosCC8 Gestión de cambiosEvidencia de proceso: cada pull request fusionado en la rama por defecto se sella como un registro de cambio con sus aprobaciones sobre el commit final, los checks obligatorios al fusionar, quién lo fusionó, sus firmas y los veredictos de código que llevaba.
Registro de cambio rec_5b81d4e
datos de ejemploPlanificado8
Se puede evidenciar desde el código o GitHub. Todavía ninguna regla los comprueba; cada uno está planificado y ninguno cuenta hoy como evidencia.
CC6.2Emisión de credenciales de usuarioCC6 Protección del accesoCC7.1Vigilancia de desvíos de debilidadesCC7 Operaciones de seguridadCC7.2Vigilancia de anomalíasCC7 Operaciones de seguridadA1.2Salvaguardas de copias de seguridadA1 Capacidad y copias de seguridadPI1.2Entradas completas y exactasPI1 Exactitud del tratamientoPI1.3Errores de pérdida en el tratamientoPI1 Exactitud del tratamientoP4.2Conservación de datos personalesP4 Uso y conservaciónP4.3Eliminación de datos personalesP4 Uso y conservación
Criterios de nivel organizativo
Los controles de nivel organizativo (políticas, personas, proveedores, seguridad física y similares) siguen en manos del propio proceso de su organización; Toevan no se ocupa de ellos.
Mostrar la lista
CC1 Conducta de la dirección
CC2 Intercambio de información
CC3 Revisión de riesgos
CC4 Monitorización de controles
CC5 Selección de controles
CC6 Protección del acceso
CC7 Operaciones de seguridad
CC9 Riesgo de proveedores
A1 Capacidad y copias de seguridad
PI1 Exactitud del tratamiento
P1 Deberes de aviso
P2 Deberes de elección
P3 Deberes de recogida
P4 Uso y conservación
P5 Solicitudes individuales
P6 Deberes de comunicación
P7 Calidad de los datos
P8 Gestión de reclamaciones
Cómo usarlo en una auditoría
- Tome la población de los registros de cambio
Cada pull request fusionado en la rama por defecto y cada push a una rama protegida que ningún pull request fusionado explique, en el periodo, capturados de GitHub en el momento, es un registro sellado que puede exportar para el muestreo. Puede repetir la población de la rama por defecto a partir del historial de git; las ramas de producción designadas están planificadas.
- Lea la evidencia de código del periodo
Cada pull request lleva resultados de código sellados frente a las reglas del blueprint, fijados al commit y a la versión del conjunto de reglas vigente.
- Pruebe una muestra
Para cada registro muestreado, compruebe sus resultados y luego verifíquelo sin conexión con la clave publicada, con openssl y la shell: obtenga la evidencia, confirme la clave, compruebe el registro. Para repetir toda la cadena, Toevan facilita el comando toevan a petición; aún no es público.
- Recalculado
- Toevan lo calculó a partir del propio código o del historial de git.
- Informado + sellado
- GitHub lo informó; Toevan lo capturó en el evento y lo firmó.
- Declarado + sellado
- La organización lo declaró, como un cambio en lo que se comprueba; Toevan firmó la declaración y su historial.
- Registro de Toevan, sin sellar
- Guardado en la base de datos de Toevan pero no sellado en el libro, como una exención hoy. Ninguna firma lo protege.
- Consumido
- Tomado de los registros de despliegue y de release de GitHub y enlazado por commit o digest.
- No capturado
- No había una fuente fiable. Toevan no lo infiere.
Recalculado listado desde el historial de git y cotejado con los registros sellados
Pruebe el mapeo en una auditoría real.
Traiga un repositorio y una auditoría próxima. Configuraremos el blueprint y guiaremos a su auditor en la verificación.
- Un repositorio, un marco
- Evidencia desde el primer pull request
- Verificable sin una cuenta de Toevan