Mapeamento de controlos ITSG-33, conformidade com GC Cloud Guardrails e referência SA&A para departamentos do governo federal canadiano
Last updated: July 12, 2026 by Steve
Referência de Controlos de Segurança do GC
Esta página destina-se a departamentos do governo federal canadiano que realizam uma Avaliação e Autorização de Segurança (SA&A) para o AccessPoint. Mapeia os controlos de segurança do AccessPoint para o framework ITSG-33, os GC Cloud Guardrails e os requisitos relacionados do TBS/CCCS.
Para a arquitetura técnica completa, consulte a página de Arquitetura Técnica.
Resumo da Arquitetura para Avaliadores
O AccessPoint funciona inteiramente dentro do próprio tenant Microsoft 365 e Azure do departamento. Os factos relevantes para a segurança que sustentam os mapeamentos abaixo são:
- Backend — uma Web API ASP.NET Core no Azure App Service (Linux), Azure SQL Database e Azure Blob Storage, todos implantados na própria subscrição Azure do departamento.
- Identidade — o Microsoft Entra ID é o único fornecedor de identidade (tokens bearer JWT). O App Service autentica-se nos serviços de backend com uma identidade gerida atribuída pelo sistema; o Azure SQL utiliza autenticação apenas por Entra (autenticação por palavra-passe SQL desativada), pelo que não são armazenadas credenciais na aplicação.
- Controlo de acesso — RBAC ao nível da aplicação e do lado do servidor em cada endpoint da API, além de middleware de filtro de PII que remove o PII do requerente das respostas para funções restritas.
- Encriptação — TLS 1.3 na front door do App Service (TLS 1.2+ no Azure SQL e Blob Storage); TDE na base de dados e SSE AES-256 no Blob Storage em repouso.
- Auditoria — um registo de auditoria imutável ao nível dos campos, além de um livro-razão de auditoria em cadeia de hash (SHA-256) e só de inserção; telemetria no Application Insights / Log Analytics com regras de alerta de métricas predefinidas.
- Limite do editor — a validação de licença transmite apenas o ID do tenant e a chave de licença; nenhum dado do cliente é transmitido ou armazenado pelo editor.
Alinhamento com o Framework de Segurança do GC
| Framework | Como o AccessPoint Se Alinha |
|---|---|
| ITSG-33 (perfil PBMM) | Controlos de segurança mapeados para todas as famílias ITSG-33. Consulte o Mapeamento de Famílias de Controlos ITSG-33 abaixo. |
| GC Cloud Guardrails | Todas as 13 guardrails obrigatórias abordadas. Consulte a tabela de Conformidade com GC Cloud Guardrails. |
| Policy on Government Security | Sistema concebido para SA&A formal. O limite de autorização está definido na secção Limite de Autorização abaixo. |
| Directive on Security Management | As capacidades de registo de auditoria, controlo de acesso e monitorização contínua apoiam a conformidade contínua. |
| Directive on Service and Digital | Arquitetura nativa da cloud alinhada com a diretiva cloud-first do GC. Implanta-se inteiramente dentro do tenant M365 e Azure existente do departamento. |
| CCCS Cloud Security Risk Management | Responsabilidade partilhada documentada. As regiões canadianas do Azure são avaliadas pelo CCCS para PBMM. |
Residência de Dados no Canadá
Para implantações do Governo do Canadá, o AccessPoint é implantado em regiões Azure canadianas (Canada Central ou Canada East). Todos os dados — incluindo registos de pedidos, documentos carregados, registos de auditoria e telemetria — residem na região canadiana selecionada. Nenhum dado é transmitido ou armazenado em regiões fora do Canadá, a menos que o departamento configure explicitamente a geo-replicação Azure para tal.
As regiões canadianas do Microsoft Azure foram avaliadas pelo Canadian Centre for Cyber Security (CCCS) e estão aprovadas para cargas de trabalho PBMM (Protected B, Medium Integrity, Medium Availability).
O Que PBMM Significa para o AccessPoint
- Protected B — O AccessPoint trata PII do requerente (nome, email, telefone, morada) e registos governamentais potencialmente sensíveis. O middleware de filtro de PII da aplicação, o controlo de acesso baseado em funções e os controlos de encriptação são concebidos para dados Protected B.
- Medium Integrity — Todas as modificações de dados são capturadas num registo de auditoria imutável, reforçado por um livro-razão de auditoria em cadeia de hash. Restrições da base de dados e validação ao nível da API protegem contra modificações não autorizadas.
- Medium Availability — A aplicação é sem estado, com todo o estado no Azure SQL e Blob Storage. Os SLAs da plataforma Azure e a redundância configurável pelo cliente suportam os requisitos de disponibilidade média.
Mapeamento de Famílias de Controlos ITSG-33
A tabela abaixo mapeia cada família de controlos ITSG-33 para as secções relevantes da página de Arquitetura Técnica. Utilize isto como ponto de partida ao avaliar o AccessPoint em relação ao perfil de controlos de segurança PBMM do seu departamento.
| Família ITSG-33 | Área de Controlo | Onde É Abordado |
|---|---|---|
| AC — Controlo de Acesso | Autenticação, autorização, privilégio mínimo, RBAC do lado do servidor, filtragem de PII, gestão de sessões | Autenticação e Identidade, Autorização e RBAC, Privacidade por Conceção |
| AU — Auditoria e Responsabilização | Registo, registo de auditoria imutável, livro-razão em cadeia de hash, monitorização, retenção de registos | Registo, Monitorização e Auditoria |
| CA — Avaliação e Autorização de Segurança | Processo SA&A, limite do sistema, monitorização contínua | Limite de Autorização (esta página); Visão Geral da Plataforma; monitorização contínua via Registo, Monitorização e Auditoria |
| CM — Gestão de Configuração | Configuração de base, controlo de alterações, predefinições de hardening | Modelo de Implantação (predefinições de hardening, migrações DacPac aditivas) |
| CP — Planeamento de Contingência | Cópia de segurança, recuperação de desastres, continuidade de negócio | App Service sem estado (todo o estado no Azure SQL e Blob Storage); cópias de segurança SQL geridas pelo Azure e redundância Blob configuradas pelo departamento — consulte Modelo de Implantação |
| IA — Identificação e Autenticação | Fornecedor de identidade Entra ID, MFA, identidade gerida, autenticação SQL apenas por Entra | Autenticação e Identidade |
| IR — Resposta a Incidentes | Tratamento de incidentes, notificação, reporte ao CCCS | O registo de auditoria imutável, o livro-razão em cadeia de hash e o Log Analytics apoiam a investigação — consulte Registo, Monitorização e Auditoria. Os departamentos reportam eventos cibernéticos ao CCCS de acordo com os requisitos do GC. |
| MP — Proteção de Suportes | Encriptação de dados em repouso, sanitização de suportes | Encriptação, Residência e Soberania dos Dados |
| PE — Proteção Física e Ambiental | Segurança física da infraestrutura | Responsabilidade do CSP Azure — coberta pela avaliação CCCS da Microsoft para PBMM |
| PL — Planeamento | Planos de segurança, limite de autorização do sistema | Visão Geral da Plataforma; Limite de Autorização (esta página) |
| RA — Avaliação de Riscos | Avaliação de ameaças/riscos, análise de vulnerabilidades | VAPT e TRA conduzidos pelo departamento (consulte Documentos Chave a Solicitar); análise da plataforma Azure pela Microsoft |
| SA — Aquisição de Sistemas e Serviços | Cadeia de fornecimento, dependências de terceiros, práticas do fornecedor | Inventário de Componentes, O Que o Editor Opera; inventário completo de dependências disponível mediante solicitação |
| SC — Proteção de Sistemas e Comunicações | Encriptação em trânsito, isolamento do tenant, proteção de fronteira | Encriptação, Residência e Soberania dos Dados. Implantação single-tenant com recursos dedicados; os departamentos podem adicionar Private Endpoints, integração VNet e WAF. |
| SI — Integridade de Sistemas e Informação | Patching, gestão de vulnerabilidades, integridade de entrada | Modelo de Implantação (predefinições de hardening, migrações aditivas). SO/runtime corrigidos pelo Azure; código da aplicação e dependências corrigidos pelo editor. |
Conformidade com GC Cloud Guardrails
A tabela seguinte mapeia os controlos do AccessPoint para os GC Cloud Guardrails — as configurações mínimas obrigatórias de segurança para a adoção de cloud do GC.
| Guardrail | Como o AccessPoint Aborda |
|---|---|
| 01 — Proteger contas root/admin global | O AccessPoint não utiliza nem requer contas Global Admin em tempo de execução. As funções de admin dentro da aplicação são separadas das funções de admin Azure/M365. A implantação inicial requer permissões de admin; a operação contínua não. |
| 02 — Gestão de privilégios administrativos | RBAC ao nível da aplicação com seis funções distintas, aplicado do lado do servidor na camada da API em cada pedido. A função Administrator é separada das funções operacionais. O App Service autentica-se através de uma identidade gerida atribuída pelo sistema, sem credenciais armazenadas, e o Azure SQL utiliza autenticação apenas por Entra (autenticação por palavra-passe SQL desativada). Consulte Autorização e RBAC. |
| 03 — Acesso à consola da cloud | O AccessPoint não acede ao Portal Azure nem a qualquer consola de gestão da cloud em tempo de execução. A gestão de recursos Azure permanece da responsabilidade do departamento. |
| 04 — Contas de monitorização empresarial | Toda a telemetria é armazenada na instância Application Insights e no espaço de trabalho Log Analytics do cliente. Os departamentos podem conceder ao CCCS/SSC acesso de leitura a estes recursos, de acordo com os seus procedimentos padrão. Consulte Registo, Monitorização e Auditoria. |
| 05 — Localização dos dados | Todos os dados residem no tenant Azure do cliente, na região canadiana selecionada (Canada Central ou Canada East). A validação de licença transmite apenas o ID do tenant e a chave de licença — nenhum dado do cliente é transmitido ou armazenado pelo editor. Consulte Residência e Soberania dos Dados. |
| 06 — Proteção de dados em repouso | Azure SQL TDE e Azure Blob Storage SSE (AES-256) ativados por predefinição. Chaves geridas pelo cliente (CMK) suportadas. Consulte Encriptação. |
| 07 — Proteção de dados em trânsito | TLS 1.3 aplicado na front door do App Service (TLS 1.0/1.1/1.2 rejeitados); TLS 1.2+ no Azure SQL e Blob Storage. Sem endpoints de texto simples. Consulte Encriptação. |
| 08 — Segmentar e separar | Implantação single-tenant com recursos dedicados por cliente — sem computação, armazenamento ou base de dados partilhados. Os caminhos Blob e as consultas à base de dados têm âmbito de tenant. Pode ser adicionada segmentação de rede (Private Endpoints, integração VNet). Consulte Residência e Soberania dos Dados. |
| 09 — Serviços de segurança de rede | A implantação predefinida utiliza endpoints públicos Azure PaaS com proteção de fronteira gerida pela plataforma. Os departamentos podem adicionar Private Endpoints, VNet Integration, WAF (Application Gateway / Front Door) e regras NSG. |
| 10 — Serviços de ciberdefesa | Os dados do Application Insights e do Log Analytics estão acessíveis para integração com sensores de ciberdefesa do GC e com o SIEM departamental. Consulte Registo, Monitorização e Auditoria. |
| 11 — Registo e monitorização | Registo de auditoria imutável ao nível dos campos no Azure SQL, além de um livro-razão de auditoria em cadeia de hash e só de inserção. O Application Insights captura toda a telemetria da API, com regras de alerta de métricas predefinidas (HTTP 5xx, latência). Log Analytics com retenção configurável (30–730 dias). Consulte Registo, Monitorização e Auditoria. |
| 12 — Configuração de marketplaces da cloud | O web part SPFx e a aplicação Teams são distribuídos via Microsoft AppSource. O backend Azure é implantado através de um modelo Bicep/ARM — num só clique a partir do portal Azure ou através de script PowerShell. Os departamentos aprovam instalações através dos seus processos padrão de App Catalog e governança Azure. Consulte Modelo de Implantação. |
| 13 — Planear a continuidade | Cópias de segurança automatizadas do Azure SQL, opções de redundância do Blob Storage e um App Service sem estado permitem uma reimplantação rápida (a API inclui o seu esquema e aplica-o no arranque). Consulte Modelo de Implantação. |
Orientação para o Processo SA&A
Ao realizar uma Avaliação e Autorização de Segurança para o AccessPoint, os departamentos devem considerar o seguinte.
Categorização do Sistema
O AccessPoint é tipicamente categorizado como PBMM quando utilizado para o processamento de pedidos ATIP. O sistema trata:
| Categoria de Dados | Classificação | Justificação |
|---|---|---|
| PII do requerente (nome, email, morada) | Protected B | Informação pessoal — dano grave se divulgada |
| Registos e descrições de pedidos | Protected B | Podem descrever matéria sensível |
| Documentos responsivos carregados | Até Protected B | A classificação depende do conteúdo do documento |
| Decisões e justificações de isenção | Protected B | A divulgação poderia revelar processos deliberativos |
| Registo de auditoria e livro-razão de auditoria | Protected B | Contêm referências a PII e detalhes dos pedidos |
| Configuração da aplicação | Interno | Sem dados sensíveis na configuração |
| Telemetria e registos | Interno | Dados de desempenho, sem PII na telemetria |
Limite de Autorização
O limite de autorização do AccessPoint compreende:
- O Azure App Service e o código da aplicação nele implantado
- O Azure SQL Database e todos os dados da aplicação
- A conta Azure Blob Storage e todos os documentos armazenados
- O Application Insights e o espaço de trabalho Log Analytics
- O Azure AI Search, quando a funcionalidade opcional de pesquisa de texto integral é implantada
- O registo de aplicação Entra ID e a identidade gerida do App Service
- O web part SPFx implantado no SharePoint Online e o pacote da aplicação Teams
- Todos os fluxos de dados entre estes componentes
Os seguintes estão fora do limite de autorização do AccessPoint e enquadram-se no SA&A mais amplo do Azure/M365 do departamento:
- A subscrição Azure e a configuração do grupo de recursos
- As políticas do tenant Entra ID (MFA, Conditional Access, conformidade de dispositivos)
- A configuração de rede (VNet, NSG, Private Endpoints)
- Os serviços da plataforma Azure geridos pela Microsoft
Aproveitamento de Avaliações Existentes
- Controlos da plataforma Azure (PE, partes de SC e CP) são cobertos pela avaliação CCCS da Microsoft para PBMM. Os departamentos podem referenciar a avaliação do fornecedor de serviços cloud CCCS para o Azure, em vez de reavaliar os controlos ao nível da plataforma.
- Controlos Entra ID e M365 são cobertos pelo SA&A existente do M365 do departamento. O AccessPoint herda o MFA, o Conditional Access e a governança de identidade da configuração do tenant do departamento.
- Controlos ao nível da aplicação do AccessPoint (AC, AU, a camada de aplicação de IA/CM/SI e IR) devem ser avaliados pelo departamento. A página de Arquitetura Técnica fornece a documentação detalhada dos controlos.
Documentos Chave a Solicitar
Ao avaliar o AccessPoint, a sua equipa de SA&A poderá querer solicitar:
| Documento | Finalidade |
|---|---|
| Esta página + Arquitetura Técnica | Documentação dos controlos de segurança |
| Resultados de Avaliação de Vulnerabilidades e Testes de Penetração (VAPT) | Testes de segurança da aplicação |
| Guia de Implantação | Procedimento de implantação e hardening pós-implantação |
| Inventário de dependências | Avaliação de risco da cadeia de fornecimento (consulte Inventário de Componentes; inventário completo de dependências disponível mediante solicitação) |
| Procedimentos de resposta a incidentes | Compromissos de IR do fornecedor (disponíveis junto do editor mediante solicitação) |
| Avaliação de Impacto na Privacidade | Fluxos de informações pessoais e controlos de privacidade (consulte a Avaliação de Impacto na Privacidade do GC) |
| Diagramas de fluxo de dados | Movimento de dados (consulte o Diagrama de Arquitetura e Residência e Soberania dos Dados) |