Visão geral da arquitetura técnica para equipas de TI que avaliam o AccessPoint

Last updated: July 12, 2026 by Steve

Arquitetura Técnica

Este documento fornece uma visão geral técnica da plataforma AccessPoint para arquitetos de soluções, engenheiros de cibersegurança e diretores de TI que avaliam o produto para a sua organização. É elaborado a partir do AccessPoint Solution Architecture Guide (v1.4.1).

Visão Geral da Plataforma

O AccessPoint é uma plataforma de gestão de acesso à informação e privacidade construída sobre o Microsoft 365 e o Azure. Começou como uma ferramenta de gestão de pedidos de acesso do titular (SAR) e evoluiu para uma suite integrada de ATIP/gabinete de privacidade que cobre todo o ciclo de vida dos pedidos e o programa de privacidade circundante. Funciona inteiramente dentro do tenant Microsoft 365 e Azure da própria organização: não existem servidores externos, bases de dados ou dependências de cloud de terceiros em tempo de execução, e todos os dados permanecem no seu ambiente, sob o seu controlo.

A plataforma está organizada em módulos que partilham uma espinha dorsal única de identidade, RBAC, notificações, auditoria e relatórios:

  • Pedidos de acesso — receção ATI/FOIA/GDPR, atribuição de tarefas a custodians, revisão e redação de documentos, preparação do pacote de resposta e relatórios estatutários
  • Avaliações de privacidade — um motor configurável de avaliações PIA/AIA/Segurança
  • Incidentes e violações de privacidade — receção, contenção, avaliação de risco de dano e fluxos de trabalho de notificação de violações
  • Reclamações e recursos — ciclo de vida da reclamação com partes, prazos legais e investigação
  • Registo de riscos de privacidade — riscos ao estilo ISO 31000, planos de tratamento e indicadores-chave de risco
  • Registos de processamento (ROPA) — registos do Artigo 30.º do GDPR e exportação de registo
  • Registo de compromissos — compromissos de privacidade monitorizados com cadência e pontos de verificação

Todos os módulos são controlados por pacotes de configuração, sem dados estáticos pré-carregados.

Características principais:

  • Nativo do tenant — implanta-se como uma solução SharePoint Framework (SPFx) e serviços Azure PaaS dentro do seu tenant existente
  • Sem dependências do Power Platform — não é necessário licenciamento de Dataverse, Power Automate ou Power Apps
  • Soberania dos dados — todos os dados residem na geografia configurada do seu tenant Azure
  • Sem acesso do fornecedor em tempo de execução — o editor não pode aceder aos seus dados durante a operação normal
  • Licenciamento de tarifa fixa — licenciamento departamental sem medição por utilizador
  • Privacidade por conceção — as funções de custodian e contributor estão estruturalmente isoladas do PII do requerente e do titular dos dados
  • Configuração em vez de código — tipos de pedido, códigos de isenção e campos de escolha são orientados por dados
  • Multilingue por conceção — um sistema de tradução de três níveis com suporte para 11 idiomas

Diagrama de Arquitetura

Customer's Microsoft 365 Tenant          Customer's Azure Subscription
┌──────────────────────────────┐         ┌─────────────────────────────────────────┐
│                              │         │                                         │
│  SPFx Web Part               │         │  Azure App Service (Linux)              │
│  (SharePoint Online /        │──HTTPS──│  ASP.NET Core 10 Web API               │
│   Teams Personal App /       │  (JWT)  │    ├─ Entra ID JWT validation          │
│   Teams Tab)                 │         │    ├─ Role-based authorization          │
│                              │         │    ├─ PII filter middleware             │
│  Installed from AppSource    │         │    ├─ User upsert from JWT claims      │
│  or Tenant App Catalog       │         │    ├─ License validation middleware    │
│                              │         │    └─ Syncfusion document conversion   │
│                              │         │                                         │
│  SharePoint Tenant Storage   │         │  Azure SQL Database                     │
│  (API URL + Client ID)       │         │  (~186 tables, ~2,900 fields)          │
│                              │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.Read.All       │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         └─────────────────────────────────────────┘
        │  Calendars.Read      │
        │  AiEnterprise…Read   │  ← M365 record capture (delegated + app-only Copilot)
        └──────────────────────┘

Inventário de Componentes

Componente Tecnologia Implantado Em Finalidade
SPFx Web Part TypeScript, React 17, Fluent UI 8, SPFx 1.22.1 SharePoint Online / Teams do cliente Interface do utilizador para todas as funções
Teams App Teams manifest v1.19, app version 1.0.0 Centro de Administração Teams do cliente Aplicação pessoal, separador configurável, notificações no feed de atividades com ligação direta
Web API C# / ASP.NET Core 10, .NET 10 (~87 controladores, ~88 serviços) Azure App Service (Linux) do cliente Lógica de negócio, acesso a dados, processamento de documentos
Base de Dados SQL Server (DacPac) Azure SQL Database do cliente Armazenamento de dados relacional (~186 tabelas, ~2.900 campos)
Blob Storage Azure Blob Storage Conta de Armazenamento Azure do cliente Armazenamento de ficheiros de documentos
Monitorização Application Insights + Log Analytics Subscrição Azure do cliente Telemetria, diagnósticos, alertas
AI Search (opcional) Azure AI Search Subscrição Azure do cliente Pesquisa de texto integral do conteúdo dos documentos; aprovisionado apenas quando deployAiSearch=true

O Que o Editor Opera

Serviço Finalidade
Realizer Platform Emissão e validação de chaves de licença (sem transmissão de dados do cliente)
AppSource Listing Distribuição do pacote SPFx
Azure Marketplace Listing Modelo de implantação de infraestrutura Azure
Teams App Package Distribuição do manifesto Teams (sideload ou loja de aplicações da organização)

Nenhum dado do cliente é transmitido ou armazenado por qualquer serviço operado pelo editor.

Módulos Funcionais

Todos os módulos funcionam dentro da mesma Web API / web part SPFx e partilham uma única espinha dorsal de identidade, RBAC, comentários, notificações, O Meu Dia, auditoria, horas, fluxo de trabalho de revisão e relatórios. Cada um é orientado por dados através de Pacotes de Configuração.

Módulo Resumo
Pedidos (ATIP/SAR) Receção do pedido → atribuição de tarefas a custodians → recolha → resposta. Tipos, estados, numeração, calendários e SLAs configuráveis.
Documentos e Redação Espaço de trabalho de documentos com facetas: etiquetas, famílias de email, acompanhamento de leitura, vistas guardadas, pré-visualização Syncfusion, pipeline de redação com isenções e round-trip XFDF, preparação do pacote de resposta.
Requerentes / Contactos Identidade de requerente reutilizável de primeira classe, controlo do fluxo de receção, taxas e verificação, fusão; consultas; compositor de correspondência com firewall de PII.
Avaliações de Privacidade Motor configurável PIA/AIA/Segurança: modelos, questionários de triagem, delegação de secções, pontuação/níveis, registo de riscos, resumos de encerramento/regulador.
Incidentes de Privacidade / Violações Receção de incidentes, contenção, risco de dano, regras de notificação de violações por regime, remediação.
Reclamações e Recursos Ciclo de vida da reclamação: partes, prazos legais, admissibilidade, investigação, revisão de alegações.
Risco e Compromissos Registo de riscos ISO 31000 com apetite de risco, KRIs e tarefas de tratamento; registo de compromissos com cadência e pontos de verificação.
ROPA / Sujeitos de Privacidade Programas/sistemas reutilizáveis com registos do Artigo 30.º do GDPR e exportação de registo.
Revisões Motor configurável de revisão e aprovação sequencial/paralela, reutilizado em todas as entidades de processo.
Relatórios e Auditoria Relatórios fixos, criador de relatórios personalizados, relatórios estatísticos anuais, painéis de SLA/gestão, livro-razão de auditoria em cadeia de hash e pacotes de provas prontos para tribunal.
Configuração e Plataforma Importação de pacotes de configuração, definições do tenant, funções/permissões personalizadas, comutadores de funcionalidades, campos personalizados, tabelas de tradução em 11 idiomas.

Modelo de Implantação

O AccessPoint utiliza um modelo de implantação dividido. O web part SPFx é instalado a partir do Microsoft AppSource (ou de um App Catalog do tenant), o pacote da aplicação Teams é instalado via sideload ou pela loja de aplicações da organização, e o backend Azure é implantado na própria subscrição do cliente através de um de dois métodos:

  • Portal Azure (recomendado) — implantação num só clique de todos os recursos Azure (App Service, SQL, Blob Storage, Application Insights) via ARM/Bicep. A API é implantada por zipdeploy durante a implantação ARM; o código é transferido uma única vez a partir do CDN do editor e armazenado no App Service do cliente, sem dependência externa em tempo de execução. O cliente mantém a propriedade total do grupo de recursos.
  • Modelo Bicep + script PowerShell (manual) — para organizações com controlo de alterações rigoroso. Um botão Deploy to Azure ou o Deploy-AccessPoint.ps1 implanta a infraestrutura, configura a autenticação apenas por Entra no SQL, concede permissões Microsoft Graph à identidade gerida, configura as entidades de armazenamento do tenant no SharePoint e aprova os pedidos de permissão da API SPFx. Cada etapa pode ser omitida de forma independente.

A implantação é reforçada em termos de segurança por predefinição: TLS 1.3, FTPS desativado, autenticação básica SCM/FTP desativada e HTTP/2 ativado. A API inclui o seu DacPac de base de dados e aplica-o no arranque através de um serviço de migração que utiliza DacServices.Deploy(upgradeExisting: true) — uma operação nula num esquema já atualizado, e um delta aditivo e não destrutivo após uma alteração de esquema (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). O resultado da migração é exposto através de /api/health. Após a implantação, um administrador concede consentimento para a aplicação empresarial Realizer (notificações Teams), configura a caixa de correio de envio e importa um pacote de configuração específico da jurisdição.

Autenticação e Identidade

O AccessPoint utiliza o Microsoft Entra ID como o seu único fornecedor de identidade. Não existem contas de utilizador ou palavras-passe específicas da aplicação. O web part SPFx adquire um JWT para a audiência da API via AadHttpClient; a API valida o emissor, a audiência, a assinatura e a validade em cada pedido. As políticas de MFA e Conditional Access configuradas no tenant aplicam-se na íntegra.

User (Browser)                SharePoint Online           AccessPoint API
     │                              │                          │
     │  1. Load SPFx web part       │                          │
     │─────────────────────────────►│                          │
     │                              │                          │
     │  2. AadHttpClient.getClient()│                          │
     │  (SPFx acquires token for    │                          │
     │   api://<client-id> audience)│                          │
     │                              │                          │
     │  3. API call + Bearer token  │                          │
     │──────────────────────────────┼─────────────────────────►│
     │                              │                          │
     │                              │  4. Validate JWT:        │
     │                              │     - Issuer (Entra ID)  │
     │                              │     - Audience (api://)  │
     │                              │     - Signature          │
     │                              │     - Expiry             │
     │                              │                          │
     │                              │  5. UserUpsertMiddleware: │
     │                              │     Extract claims →     │
     │                              │     Upsert Users table   │
     │                              │                          │
     │                              │  6. RoleAuthorization:   │
     │                              │     Check UserRoles table│
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│
Parâmetro Valor
Fornecedor de Identidade Microsoft Entra ID (Azure AD)
Protocolo OAuth 2.0 / OpenID Connect
Tipo de Token JWT Bearer
Audiência api://<client-id> e <client-id> (ambos os tokens v1 e v2 são aceites)
Emissor https://login.microsoftonline.com/{tenantId}/v2.0 e https://sts.windows.net/{tenantId}/
Registo da Aplicação Single-tenant (AzureADMyOrg); âmbito exposto access_as_user; sem segredo de cliente

Identidade Gerida

O App Service utiliza uma identidade gerida atribuída pelo sistema para autenticação nos serviços de backend, pelo que não são armazenados segredos de cliente ou certificados na aplicação:

  • Azure SQL Database — autenticação apenas por Entra (a autenticação por palavra-passe SQL está desativada)
  • Azure Blob Storage — DefaultAzureCredential (identidade gerida em produção)
  • Microsoft Graph API — ManagedIdentityCredential com permissões de aplicação

As credenciais da identidade gerida são rotacionadas automaticamente pelo Azure.

Autorização e RBAC

O AccessPoint implementa controlo de acesso baseado em funções ao nível da aplicação, armazenado no Azure SQL e aplicado na camada da API em cada pedido.

Função Vê PII do Requerente Gere Pedidos Gere Atribuições Submete Documentos Utilizador Típico
Administrator Sim Apenas config. Não Não Administrador de TI, proprietário do sistema
SAO Sim Sim Sim Não Responsável de acesso e privacidade
Reviewer Sim Apenas leitura Apenas leitura Não Assessor jurídico, QA
Custodian Não Não Próprias atribuições Não Responsável de registos do departamento
Contributor Não Não Não Próprias tarefas Especialista na matéria
Reader Não Apenas leitura Apenas leitura Não Supervisão, auditoria

Pontos de aplicação:

  1. Políticas de autorização da API — atributos [Authorize(Policy = "...")] do ASP.NET Core em cada ação do controlador
  2. RoleAuthorizationHandler — verifica a tabela UserRoles para a pertença às funções do utilizador autenticado
  3. ResourceOwnerAuthorizationHandler — valida a propriedade ao nível do recurso (por exemplo, um Contributor só pode aceder às suas próprias tarefas)
  4. PiiFilterMiddleware — remove os campos de PII do requerente das respostas JSON para funções restritas (Custodian, Contributor, Reader)

Todos os endpoints de escrita da API aplicam funções do lado do servidor ao nível do controlador. A reclassificação de documentos é sensível ao âmbito — o utilizador que recolheu um documento é o único que o pode reclassificar — e, uma vez encerrado um pedido, as mutações no seu grafo de objetos devolvem HTTP 409, com um pequeno conjunto de exceções deliberadas (correspondência pós-encerramento, purga de retenção e reabertura). As funções têm âmbito e podem ser restringidas a recursos específicos (âmbito global, do pedido, da atribuição ou da tarefa). O primeiro utilizador a aceder ao sistema recebe automaticamente as funções Administrator e SAO.

Residência e Soberania dos Dados

Todos os dados residem no tenant Azure do cliente, na região selecionada durante a implantação. Nenhum dado é transmitido ou armazenado noutras regiões, a menos que o cliente configure explicitamente a geo-replicação Azure.

Departamentos federais canadianos: Para requisitos de residência de dados específicos do GC, mapeamento de controlos ITSG-33 e conformidade com os GC Cloud Guardrails, consulte a Referência de Controlos de Segurança do GC.

Localizações dos Dados do Cliente

Tipo de Dados Localização de Armazenamento Controlado Por
Registos de pedidos, dados de utilizadores, registo de auditoria Azure SQL Database Subscrição Azure do cliente
Documentos carregados Azure Blob Storage Subscrição Azure do cliente
Telemetria da aplicação Application Insights / Log Analytics Subscrição Azure do cliente
Recursos do web part SPFx SharePoint CDN Tenant M365 do cliente
Configuração do tenant (URL da API, Client ID) SharePoint Tenant Storage Entities Tenant M365 do cliente

O Que Cruza os Limites do Tenant

Fluxo de Dados Direção O Que É Transmitido Finalidade
Validação de licença API → Publisher Platform Chave de licença (cadeia opaca), ID do tenant Validar subscrição ativa
Notificações por email API → Microsoft Graph Conteúdo do email via Mail.Send Enviar notificações a partir da caixa de correio partilhada
Notificações Teams API → Publisher Platform → Microsoft Graph Tipo de atividade, texto de pré-visualização, ID do destinatário, parâmetros do modelo Enviar notificações no feed de atividades Teams (encaminhadas através da aplicação empresarial multi-tenant do editor, porque sendActivityNotification tem de ser chamado pela aplicação que detém o manifesto Teams)
Pesquisa de perfil de utilizador SPFx → Microsoft Graph Consultas de pesquisa de utilizadores Seletor de pessoas, resolução de utilizadores

O Que Nunca Sai do Tenant

  • Registos de pedidos e PII do requerente
  • Documentos carregados
  • Histórico de auditoria
  • Dados de configuração (tipos de pedido, modelos, numeração)
  • Atribuições de funções

Encriptação

Em Trânsito

Ligação Protocolo TLS Mínimo
Browser → App Service HTTPS (aplicado, httpsOnly: true) TLS 1.3
SPFx → App Service HTTPS (aplicado pelo contexto SharePoint) TLS 1.3
App Service → Azure SQL TDS com encriptação (Encrypt=True) TLS 1.2+
App Service → Blob Storage HTTPS (identidade gerida) TLS 1.2+
App Service → Microsoft Graph HTTPS TLS 1.2+

O App Service aplica o TLS 1.3 como mínimo na front door (TLS 1.0/1.1/1.2 rejeitados); as ligações de saída para os serviços de backend Azure negoceiam TLS 1.2 ou superior.

Em Repouso

Armazenamento de Dados Encriptação Gestão de Chaves
Azure SQL Database Transparent Data Encryption (TDE) Chaves geridas pela Microsoft (predefinição) ou chaves geridas pelo cliente (CMK)
Azure Blob Storage Storage Service Encryption (SSE), AES-256 Chaves geridas pela Microsoft (predefinição) ou chaves geridas pelo cliente (CMK)
Application Insights Encriptação da plataforma Chaves geridas pela Microsoft

Ao Nível da Aplicação

Funcionalidade Mecanismo
Tokens do visualizador de documentos ASP.NET Core Data Protection (token estilo WOPI, TTL de 15 minutos, verificação cruzada do tenant em cada chamada anónima do visualizador)
Assinaturas eletrónicas de atestação Hash SHA-256 do signatário e carimbo temporal armazenado em campos de auditoria

Privacidade por Conceção

O AccessPoint implementa controlos estruturais de privacidade que são aplicados na camada da API, não apenas na interface.

Middleware de Filtro PII

Um middleware ao nível da resposta intercepta todas as respostas JSON e remove os campos de PII para utilizadores com funções restritas (Custodian, Contributor, Reader), do lado do servidor, independentemente do que o cliente solicita. Campos removidos: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

Ocultação de PII nas Notificações

Quando as notificações são enviadas a Custodians ou Contributors, o PII do requerente é substituído por texto de espaço reservado no próprio conteúdo da notificação — mesmo que o modelo de notificação inclua campos de fusão de PII.

Isolamento de Custodian/Contributor

  • Os Custodians veem apenas os pedidos que lhes foram atribuídos e trabalham a partir de instruções desidentificadas
  • Os Contributors veem apenas as tarefas que lhes foram atribuídas
  • Nenhuma destas funções pode pesquisar, navegar ou aceder a pedidos fora do seu âmbito

Registo, Monitorização e Auditoria

Application Insights

Toda a telemetria da API é enviada para a instância Application Insights do cliente:

Sinal O Que É Capturado
Rastreios de pedidos Método HTTP, caminho, código de estado, duração, ID de correlação
Rastreio de dependências Consultas SQL, operações Blob, chamadas Graph API (duração, sucesso/falha)
Exceções Exceções não tratadas com stack traces
Métricas personalizadas Tempos de processamento de pedidos, durações de conversão de documentos

Registo de Auditoria

O AccessPoint mantém um registo de auditoria abrangente na tabela AuditHistory (Azure SQL), que regista o tipo de entidade, o ID da entidade, a ação (Create, Update, Delete, StatusChange), o nome do campo, os valores antigo/novo, um motivo de alteração opcional (capturado em transições de estado como encerramento e reabertura), o utilizador autenticado e um carimbo temporal UTC. Os registos de auditoria são imutáveis — não podem ser modificados ou eliminados através da API.

Livro-Razão de Auditoria em Cadeia de Hash

Para além do registo de auditoria ao nível dos campos, um AuditLedger à prova de adulteração e só de inserção (cadeia de hash SHA-256) regista ações em todos os módulos. A integridade pode ser verificada do lado do servidor, e é possível exportar um pacote de provas pronto para tribunal relativo a um pedido.

Concorrência Otimista

As entidades de elevada contenção (Requests, Documents, CustodianAssignments) têm cada uma um token de concorrência ROWVERSION do SQL Server. O cliente reenvia a versão da linha na atualização; se outro processo tiver alterado a linha entretanto, a gravação é rejeitada com HTTP 409 ("Concurrent edit detected") em vez de sobrescrever silenciosamente.

Registo de Purga de Retenção

Quando os registos são purgados de acordo com a política de retenção, a purga elimina blobs de documentos, PDFs convertidos, anotações e pacotes de exportação do Blob Storage, além dos registos da base de dados. A tabela RetentionPurgeLog regista o que foi eliminado, quando e por quem — um registo de nível de conformidade que sobrevive à remoção dos dados.

Log Analytics e Alertas

O Application Insights é suportado por um espaço de trabalho Log Analytics com retenção configurável (predefinição de 90 dias; configurável entre 30 e 730 dias). Os dados podem ser exportados para o Microsoft Sentinel ou para um SIEM existente. A implantação Bicep inclui dois alertas de métricas predefinidos no App Service:

Alerta Gravidade Condição Janela
Erros do Servidor 2 (Aviso) Contagem HTTP 5xx > 5 5 minutos
Alta Latência 3 (Informativo) Tempo médio de resposta > 5 segundos 15 minutos

Os clientes podem personalizar limiares e adicionar grupos de ação (email, SMS, webhook) no Portal Azure.

←
Previous Primeiros Passos com o AccessPoint
Next Referência de Controlos de Segurança do GC
→