Asignación de controles ITSG-33, cumplimiento de las GC Cloud Guardrails y referencia de SA&A para los departamentos del gobierno federal canadiense
Last updated: July 12, 2026 by Steve
Referencia de controles de seguridad de GC
Esta página es para departamentos del gobierno federal canadiense que realizan una Evaluación y Autorización de Seguridad (SA&A) para AccessPoint. Asigna los controles de seguridad de AccessPoint al marco ITSG-33, a las GC Cloud Guardrails y a los requisitos relacionados del TBS/CCCS.
Para conocer la arquitectura técnica completa, consulte la página Arquitectura técnica.
Resumen de la arquitectura para evaluadores
AccessPoint se ejecuta enteramente dentro del propio inquilino de Microsoft 365 y Azure del departamento. Los hechos relevantes para la seguridad que sustentan las asignaciones siguientes son:
- Backend — una API web de ASP.NET Core en Azure App Service (Linux), Azure SQL Database y Azure Blob Storage, todo implementado en la propia suscripción de Azure del departamento.
- Identidad — Microsoft Entra ID es el único proveedor de identidad (tokens portadores JWT). El App Service se autentica ante los servicios de backend con una identidad administrada asignada por el sistema; Azure SQL utiliza autenticación exclusiva de Entra (la autenticación por contraseña de SQL está deshabilitada), por lo que no se almacenan credenciales en la aplicación.
- Control de acceso — RBAC a nivel de aplicación, del lado del servidor, en cada punto de conexión de la API, además de un middleware de filtrado de información personal que elimina la información personal del solicitante de las respuestas para los roles restringidos.
- Cifrado — TLS 1.3 en la puerta de enlace del App Service (TLS 1.2+ en Azure SQL y Blob Storage); TDE en la base de datos y SSE AES-256 en Blob Storage en reposo.
- Auditoría — un registro de auditoría inmutable a nivel de campo, además de un libro mayor de auditoría de solo adición, encadenado por hash (SHA-256); telemetría en Application Insights / Log Analytics con reglas de alerta de métricas predeterminadas.
- Límite del editor — la validación de licencia transmite únicamente el ID del inquilino y la clave de licencia; no se transmiten ni almacenan datos del cliente en el editor.
Alineación con el marco de seguridad de GC
| Marco | Cómo se alinea AccessPoint |
|---|---|
| ITSG-33 (perfil PBMM) | Controles de seguridad asignados a todas las familias de ITSG-33. Consulte la Asignación de familias de controles ITSG-33 a continuación. |
| GC Cloud Guardrails | Se abordan las 13 barreras de seguridad obligatorias. Consulte la tabla de Cumplimiento de las GC Cloud Guardrails. |
| Política sobre Seguridad del Gobierno | Sistema diseñado para una SA&A formal. El límite de autorización se define en la sección Límite de autorización a continuación. |
| Directiva sobre Gestión de la Seguridad | El registro de auditoría, el control de acceso y las capacidades de monitoreo continuo respaldan el cumplimiento continuo. |
| Directiva sobre Servicio y Digital | Arquitectura nativa de la nube, alineada con la directiva de prioridad a la nube del GC. Se implementa enteramente dentro del inquilino de M365 y Azure existente del departamento. |
| Gestión de riesgos de seguridad en la nube del CCCS | Responsabilidad compartida documentada. Las regiones canadienses de Azure han sido evaluadas por el CCCS para PBMM. |
Residencia de datos en Canadá
Para las implementaciones del Gobierno de Canadá, AccessPoint se implementa en regiones canadienses de Azure (Canada Central o Canada East). Todos los datos — incluidos los registros de solicitudes, los documentos cargados, los registros de auditoría y la telemetría — residen dentro de la región canadiense seleccionada. Ningún dato se transmite ni se almacena en regiones fuera de Canadá, a menos que el departamento configure explícitamente la replicación geográfica de Azure para hacerlo.
Las regiones canadienses de Microsoft Azure han sido evaluadas por el Centro Canadiense para la Ciberseguridad (CCCS) y están aprobadas para cargas de trabajo PBMM (Protegido B, Integridad Media, Disponibilidad Media).
Qué significa PBMM para AccessPoint
- Protegido B — AccessPoint gestiona información personal del solicitante (nombre, correo electrónico, teléfono, dirección) y registros gubernamentales potencialmente sensibles. El middleware de filtrado de información personal de la aplicación, el control de acceso basado en roles y los controles de cifrado están diseñados para datos de Protegido B.
- Integridad Media — Todas las modificaciones de datos se capturan en un registro de auditoría inmutable, reforzado por un libro mayor de auditoría encadenado por hash. Las restricciones de la base de datos y la validación a nivel de API protegen contra modificaciones no autorizadas.
- Disponibilidad Media — La aplicación no tiene estado, con todo el estado en Azure SQL y Blob Storage. Los acuerdos de nivel de servicio (SLA) de la plataforma Azure y la redundancia configurable por el cliente respaldan los requisitos de disponibilidad media.
Asignación de familias de controles ITSG-33
La tabla siguiente asigna cada familia de controles de ITSG-33 a las secciones pertinentes de la página Arquitectura técnica. Utilícela como punto de partida al evaluar AccessPoint frente al perfil de controles de seguridad PBMM de su departamento.
| Familia de ITSG-33 | Área de control | Dónde se aborda |
|---|---|---|
| AC — Control de acceso | Autenticación, autorización, privilegio mínimo, RBAC del lado del servidor, filtrado de información personal, gestión de sesiones | Autenticación e identidad, Autorización y RBAC, Privacidad desde el diseño |
| AU — Auditoría y rendición de cuentas | Registro, registro de auditoría inmutable, libro mayor encadenado por hash, monitoreo, retención de registros | Registro, monitoreo y auditoría |
| CA — Evaluación y autorización de seguridad | Proceso de SA&A, límite del sistema, monitoreo continuo | Límite de autorización (esta página); Descripción general de la plataforma; monitoreo continuo mediante Registro, monitoreo y auditoría |
| CM — Gestión de configuración | Configuración de referencia, control de cambios, valores predeterminados de fortalecimiento | Modelo de implementación (valores predeterminados de fortalecimiento, migraciones aditivas de DacPac) |
| CP — Planificación de contingencias | Copia de seguridad, recuperación ante desastres, continuidad del negocio | App Service sin estado (todo el estado en Azure SQL y Blob Storage); copias de seguridad de SQL administradas por Azure y redundancia de Blob configuradas por el departamento; consulte Modelo de implementación |
| IA — Identificación y autenticación | Proveedor de identidad Entra ID, MFA, identidad administrada, autenticación de SQL exclusiva de Entra | Autenticación e identidad |
| IR — Respuesta a incidentes | Gestión de incidentes, notificación, informes al CCCS | El registro de auditoría inmutable, el libro mayor encadenado por hash y Log Analytics respaldan la investigación; consulte Registro, monitoreo y auditoría. Los departamentos informan los eventos cibernéticos al CCCS conforme a los requisitos del GC. |
| MP — Protección de medios | Cifrado de datos en reposo, saneamiento de medios | Cifrado, Residencia y soberanía de datos |
| PE — Protección física y ambiental | Seguridad física de la infraestructura | Responsabilidad del CSP de Azure; cubierta por la evaluación del CCCS a Microsoft para PBMM |
| PL — Planificación | Planes de seguridad, límite de autorización del sistema | Descripción general de la plataforma; Límite de autorización (esta página) |
| RA — Evaluación de riesgos | Evaluación de amenazas/riesgos, análisis de vulnerabilidades | VAPT y TRA realizados por el departamento (consulte Documentos clave para solicitar); análisis de la plataforma Azure por parte de Microsoft |
| SA — Adquisición de sistemas y servicios | Cadena de suministro, dependencias de terceros, prácticas del proveedor | Inventario de componentes, Qué opera el editor; inventario completo de dependencias disponible a solicitud |
| SC — Protección de sistemas y comunicaciones | Cifrado en tránsito, aislamiento de inquilinos, protección perimetral | Cifrado, Residencia y soberanía de datos. Implementación de un solo inquilino con recursos dedicados; los departamentos pueden agregar puntos de conexión privados, integración de VNet y WAF. |
| SI — Integridad de sistemas e información | Aplicación de parches, gestión de vulnerabilidades, integridad de entradas | Modelo de implementación (valores predeterminados de fortalecimiento, migraciones aditivas). El sistema operativo/runtime lo aplica Azure; el código de la aplicación y las dependencias los aplica el editor. |
Cumplimiento de las GC Cloud Guardrails
La siguiente tabla asigna los controles de AccessPoint a las GC Cloud Guardrails, las configuraciones de seguridad mínimas obligatorias para la adopción de la nube por parte del GC.
| Barrera de seguridad | Cómo la aborda AccessPoint |
|---|---|
| 01 — Proteger las cuentas de administrador raíz/global | AccessPoint no utiliza ni requiere cuentas de administrador global en tiempo de ejecución. Los roles de administrador dentro de la aplicación son independientes de los roles de administrador de Azure/M365. La implementación inicial requiere permisos de administrador; la operación continua no. |
| 02 — Gestión de privilegios administrativos | RBAC a nivel de aplicación con seis roles distintos, aplicados del lado del servidor en la capa de la API en cada solicitud. El rol de Administrador es independiente de los roles operativos. El App Service se autentica mediante una identidad administrada asignada por el sistema sin credenciales almacenadas, y Azure SQL utiliza autenticación exclusiva de Entra (autenticación por contraseña de SQL deshabilitada). Consulte Autorización y RBAC. |
| 03 — Acceso a la consola de la nube | AccessPoint no accede al Azure Portal ni a ninguna consola de administración en la nube en tiempo de ejecución. La gestión de recursos de Azure sigue siendo responsabilidad del departamento. |
| 04 — Cuentas de monitoreo empresarial | Toda la telemetría se almacena en el área de trabajo de Application Insights y Log Analytics del cliente. Los departamentos pueden otorgar acceso de solo lectura al CCCS/SSC según sus procedimientos estándar. Consulte Registro, monitoreo y auditoría. |
| 05 — Ubicación de los datos | Todos los datos residen en el inquilino de Azure del cliente en la región canadiense que este seleccione (Canada Central o Canada East). La validación de licencia transmite únicamente el ID del inquilino y la clave de licencia; no se transmiten ni almacenan datos del cliente en el editor. Consulte Residencia y soberanía de datos. |
| 06 — Protección de los datos en reposo | TDE de Azure SQL y SSE de Azure Blob Storage (AES-256) habilitados de forma predeterminada. Se admiten claves administradas por el cliente (CMK). Consulte Cifrado. |
| 07 — Protección de los datos en tránsito | TLS 1.3 aplicado en la puerta de enlace del App Service (se rechazan TLS 1.0/1.1/1.2); TLS 1.2+ en Azure SQL y Blob Storage. Sin puntos de conexión en texto sin formato. Consulte Cifrado. |
| 08 — Segmentar y separar | Implementación de un solo inquilino con recursos dedicados por cliente; sin cómputo, almacenamiento ni base de datos compartidos. Las rutas de Blob y las consultas de base de datos están delimitadas por inquilino. Se puede agregar segmentación de red (puntos de conexión privados, integración de VNet). Consulte Residencia y soberanía de datos. |
| 09 — Servicios de seguridad de red | La implementación predeterminada utiliza puntos de conexión públicos de Azure PaaS con protección perimetral administrada por la plataforma. Los departamentos pueden agregar puntos de conexión privados, integración de VNet, WAF (Application Gateway / Front Door) y reglas de NSG. |
| 10 — Servicios de ciberdefensa | Los datos de Application Insights y Log Analytics están disponibles para integrarse con los sensores de ciberdefensa del GC y el SIEM departamental. Consulte Registro, monitoreo y auditoría. |
| 11 — Registro y monitoreo | Registro de auditoría inmutable a nivel de campo en Azure SQL, además de un libro mayor de auditoría de solo adición, encadenado por hash. Application Insights captura toda la telemetría de la API, con reglas de alerta de métricas predeterminadas (HTTP 5xx, latencia). Log Analytics con retención configurable (30 a 730 días). Consulte Registro, monitoreo y auditoría. |
| 12 — Configuración de los mercados en la nube | El componente web de SPFx y la aplicación de Teams se distribuyen a través de Microsoft AppSource. El backend de Azure se implementa mediante una plantilla Bicep/ARM: con un clic desde Azure Portal o mediante un script de PowerShell. Los departamentos aprueban las instalaciones a través de sus procesos estándar de Catálogo de aplicaciones y gobernanza de Azure. Consulte Modelo de implementación. |
| 13 — Planificar para la continuidad | Las copias de seguridad automatizadas de Azure SQL, las opciones de redundancia de Blob Storage y un App Service sin estado permiten una reimplementación rápida (la API incluye su esquema y lo aplica al iniciar). Consulte Modelo de implementación. |
Orientación sobre el proceso de SA&A
Al realizar una Evaluación y Autorización de Seguridad para AccessPoint, los departamentos deben considerar lo siguiente.
Categorización del sistema
AccessPoint normalmente se categoriza como PBMM cuando se utiliza para el procesamiento de solicitudes de ATIP. El sistema gestiona:
| Categoría de datos | Clasificación | Justificación |
|---|---|---|
| Información personal del solicitante (nombre, correo electrónico, dirección) | Protegido B | Información personal; lesión grave si se divulga |
| Registros y descripciones de solicitudes | Protegido B | Puede describir un tema sensible |
| Documentos pertinentes cargados | Hasta Protegido B | La clasificación depende del contenido del documento |
| Decisiones de exención y justificación | Protegido B | La divulgación podría revelar procesos deliberativos |
| Registro de auditoría y libro mayor de auditoría | Protegido B | Contienen referencias a información personal y detalles de la solicitud |
| Configuración de la aplicación | Interno | Sin datos sensibles en la configuración |
| Telemetría y registros | Interno | Datos de rendimiento, sin información personal en la telemetría |
Límite de autorización
El límite de autorización de AccessPoint comprende:
- El Azure App Service y su código de aplicación implementado
- La base de datos Azure SQL y todos los datos de la aplicación
- La cuenta de Azure Blob Storage y todos los documentos almacenados
- El área de trabajo de Application Insights y Log Analytics
- Azure AI Search, cuando se implementa la función opcional de búsqueda de texto completo
- El registro de aplicaciones de Entra ID y la identidad administrada del App Service
- El componente web de SPFx implementado en SharePoint Online y el paquete de la aplicación de Teams
- Todos los flujos de datos entre estos componentes
Lo siguiente queda fuera del límite de autorización de AccessPoint y corresponde a la SA&A más amplia de Azure/M365 del departamento:
- La configuración de la suscripción de Azure y del grupo de recursos
- Las políticas del inquilino de Entra ID (MFA, acceso condicional, cumplimiento de dispositivos)
- La configuración de red (VNet, NSG, puntos de conexión privados)
- Los servicios de la plataforma Azure administrados por Microsoft
Aprovechamiento de evaluaciones existentes
- Los controles de la plataforma Azure (PE, partes de SC y CP) están cubiertos por la evaluación del CCCS a Microsoft para PBMM. Los departamentos pueden hacer referencia a la evaluación del proveedor de servicios en la nube del CCCS para Azure en lugar de reevaluar los controles a nivel de plataforma.
- Los controles de Entra ID y M365 están cubiertos por la SA&A de M365 existente del departamento. AccessPoint hereda la MFA, el acceso condicional y la gobernanza de identidad de la configuración del inquilino del departamento.
- Los controles a nivel de aplicación de AccessPoint (AC, AU, la capa de aplicación de IA/CM/SI, e IR) deben ser evaluados por el departamento. La página Arquitectura técnica proporciona la documentación detallada de los controles.
Documentos clave para solicitar
Al evaluar AccessPoint, su equipo de SA&A puede querer solicitar:
| Documento | Finalidad |
|---|---|
| Esta página + Arquitectura técnica | Documentación de controles de seguridad |
| Resultados de la Evaluación de Vulnerabilidades y Pruebas de Penetración (VAPT) | Pruebas de seguridad de la aplicación |
| Guía de implementación | Procedimiento de implementación y fortalecimiento posterior a la implementación |
| Inventario de dependencias | Evaluación de riesgos de la cadena de suministro (consulte Inventario de componentes; inventario completo de dependencias disponible a solicitud) |
| Procedimientos de respuesta a incidentes | Compromisos de IR del proveedor (disponibles del editor a solicitud) |
| Evaluación de Impacto en la Privacidad | Flujos de información personal y controles de privacidad (consulte la Evaluación de Impacto en la Privacidad de GC) |
| Diagramas de flujo de datos | Movimiento de datos (consulte el Diagrama de arquitectura y Residencia y soberanía de datos) |