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 (v2.1.0).

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
• Registos de vídeo e áudio — gravações revistas no mesmo espaço de trabalho de documentos: carregamentos retomáveis até 2 GB, transcrições e legendas, redação baseada em tempo (caixa, desfoque, pixelização, silêncio, sinal sonoro, distorção de voz, ocultação) com uma isenção em cada marca, deteção e rastreio de rostos dentro do tenant, e cópias divulgadas MP4/MP3 queimadas com um manifesto de hash
• 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
• AI Assist (opcional) — sugestões e elaboração de rascunhos com base em Azure OpenAI, executadas inteiramente na própria subscrição do cliente: resumos de documentos, sugestões de redação por IA, elaboração de rascunhos fundamentada, triagem de admissão, pré-preenchimento de respostas de avaliação, pesquisa semântica e deteção de duplicados, um assistente por caso sensível ao estatuto (Ask AccessPoint — citações clicáveis, conversas guardadas, um modo A Minha Carteira), respostas de dados "Ask AccessPoint", um guia de procedimentos da jurisdição que fundamenta respostas de processo, tradução automática e um resumo diário — tudo opt-in por tenant, registado apenas com metadados, com divulgação de atividade de IA por registo

Todos os módulos são controlados por pacotes jurisdicionais, 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
• Instantes em UTC, dias de calendário no fuso do utilizador — cada marca temporal é armazenada como um instante UTC, mas os factos de calendário estatutários (data de receção, data limite, atraso, dias restantes) são calculados no calendário local de quem consulta, a partir do fuso horário que o web part envia com cada pedido

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    │
│                              │         │    └─ AccessPoint document engine      │
│                              │         │                                         │
│  SharePoint Tenant Storage   │         │  Azure SQL Database                     │
│  (API URL override,          │         │  (224 tables, 3,474 fields)            │
│   optional)                  │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Documents, converted PDFs, renditions)│
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.ReadBasic.All  │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         │  (opt-in) Azure OpenAI                  │
        │  Calendars.Read      │         │  (opt-in) Azure Document Intelligence   │
        │  AiEnterprise…Read   │         │  (opt-in) Azure AI Speech               │
        │  OnlineMeeting…Read  │         │  (opt-in) Defender for Storage          │
        │                      │         │  (opt-in) Container Apps media job      │
        │                      │         └─────────────────────────────────────────┘
        └──────────────────────┘  ← M365 record capture (delegated + app-only Copilot)

Inventário de Componentes

O Que o Editor Opera

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 Jurisdicionais.

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, além das opções opcionais AI Search, Azure OpenAI, Document Intelligence, Azure AI Speech, Defender for Storage, processamento de media, isolamento de rede e contentor de provas WORM) 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. Uma escolha obrigatória de tipo de implantação protege as reimplantações: Nova instalação cria o servidor SQL com prioridade Entra (o principal que efetua a implantação torna-se o administrador Entra inicial, com autenticação exclusiva do Entra desde o início — nunca existe qualquer credencial SQL), enquanto Atualizar instalação existente preserva as definições de aplicação do operador e não altera o acesso à base de dados. 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, reafirma a autenticação exclusiva do Entra no SQL (uma salvaguarda — o modelo já a aplica), concede permissões Microsoft Graph à identidade gerida (a alternativa com script à página Finish Setup do editor), configura a substituição opcional do URL da API através da storage entity do SharePoint, e aprova os pedidos de permissão da API SPFx. Cada etapa pode ser omitida de forma independente.

As permissões do Graph são normalmente concedidas através da página Finish Setup do editor — a implantação emite um output finishSetupUrl que um administrador Entra do cliente abre para conceder todas as permissões da identidade gerida numa única passagem idempotente (executar novamente após atualizações, para obter as novas permissões).

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, HTTP/2 ativado, e o Microsoft Defender for SQL ativado por predefinição (com opção de exclusão). 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 jurisdicional.

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. PermissionService:   │
     │                              │     resolve roles +      │
     │                              │     permission grants    │
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│

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 exclusiva do Entra (o servidor é criado com prioridade Entra; nunca existe qualquer credencial SQL)
• Azure Blob Storage — DefaultAzureCredential (identidade gerida em produção)
• Microsoft Graph API — ManagedIdentityCredential com permissões de aplicação
• Recursos opcionais (AI Search, Azure OpenAI, Document Intelligence, Azure AI Speech, as Storage Queues do trabalho de media) — apenas por identidade gerida, com autenticação local/por chave desativada; a conta Speech e o trabalho de media têm cada um a sua própria identidade gerida para acesso ao armazenamento, e uma imagem de trabalhador espelhada pelo cliente é obtida com a identidade do trabalho através de uma concessão AcrPull

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

Autorização e RBAC

O AccessPoint implementa um modelo de permissões granular e configurável por tenant, armazenado no Azure SQL e aplicado na camada da API em cada pedido: um catálogo, definido pelo produto, de códigos de permissão atómicos (por exemplo, request.modify, document.view, redaction.approve, request.view.pii) é agrupado em funções, e cada ação do controlador é condicionada a um código de permissão.

Pontos de aplicação:

1. Atributos [RequirePermission(code)] — um fornecedor de políticas dinâmico associa cada ação do controlador a um código de permissão do catálogo
2. PermissionService — resolve as permissões efetivas do autor do pedido (funções permanentes unidas às concessões de relação por alvo), com verificações delimitadas ao objeto, ao nível de pedido/documento/atribuição/tarefa
3. Verificações de propriedade ao nível do recurso — por exemplo, um Contributor só pode aceder às suas próprias tarefas; um Custodian apenas às suas próprias atribuições
4. PiiFilterMiddleware — remove os campos de PII do requerente das respostas JSON para qualquer autor de pedido que não detenha a permissão view-requestor-PII

Todos os endpoints de escrita da API aplicam permissõ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 atribuições de funções permanentes têm âmbito (global, do pedido, da atribuição ou da tarefa), podem ter um prazo de validade, e as funções de relação nunca são escritas como atribuições permanentes — são derivadas por alvo a partir dos registos de trabalho subjacentes. O primeiro utilizador a aceder ao sistema é inicializado com a função Administrator, e uma salvaguarda do lado do servidor impede a remoção do último Administrator ativo.

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

O Que Cruza os Limites do Tenant

O Que Nunca Sai do Tenant

• Registos de pedidos e PII do requerente
• Documentos carregados, gravações, transcrições e cópias divulgadas
• Histórico de auditoria
• Dados de configuração (tipos de pedido, modelos, numeração)
• Atribuições de funções
• Prompts e respostas do AI Assist — quando o AI Assist está implantado, o recurso Azure OpenAI é executado na própria subscrição e região do cliente; a Microsoft não treina modelos com o conteúdo, e o conteúdo dos prompts e das respostas não é armazenado (apenas metadados de utilização, para o medidor de orçamento e para a divulgação do envolvimento de IA da exportação de auditoria do caso)
• Notificações na aplicação e por email/Outlook — o feed na aplicação é servido a partir da própria API do cliente; o email é enviado a partir da própria caixa de correio partilhada do cliente via Mail.Send. Nenhuma delas transita pelo editor. Só o feed de atividades do Teams, que é opcional, envia algum dado para fora do tenant, e mesmo esse pode ser minimizado ou eliminado (abaixo)

Partilha de Dados de Notificação do Teams (Opcional)

Em consonância com a promessa de soberania de dados, o único dado do tenant que sai do limite para efeitos de notificações é um payload de atividade do Teams opcional — e este pode ser minimizado ou eliminado por completo. Cada notificação é entregue em até três canais; dois estão sempre dentro do tenant (o feed na aplicação, servido a partir da API do cliente, e o email/Outlook, enviado a partir da própria caixa de correio partilhada do cliente). O feed de atividades do Teams é uma comodidade: no seu modo predefinido, a API do cliente envia (POST) um pequeno payload para a aplicação multi-tenant do editor, que chama o sendActivityNotification do Graph (que tem de ser invocado pela aplicação que detém o manifesto do Teams). O editor não armazena nada disso e regista apenas os GUIDs do destinatário e do tenant.

Campos no payload predefinido (relay do editor) do Teams — e o que o interruptor Minimizar remove:

O PII do requerente nunca está no payload — não existe qualquer campo de nome/email do requerente, e as notificações de Custodian/Contributor têm o PII removido a montante, independentemente disso. Dois controlos restringem isto ainda mais:

• Minimizar (Notifications:TeamsMinimalPayload, um interruptor de tenant) substitui previewText, topicText e actorName por indicadores de espaço reservado neutros, para que nomes, títulos e texto livre nunca saiam do tenant — só saem os identificadores de encaminhamento/ligação direta. Não é necessária qualquer alteração ao manifesto.
• Eliminar (Notifications:TeamsRelayMode=Direct) faz com que a API do cliente chame o sendActivityNotification do Graph diretamente, com a sua identidade gerida, de modo que nenhum payload chega ao editor. Requer a função de aplicação TeamsActivity.Send na identidade gerida da API e o webApplicationInfo.id do manifesto do Teams apontado para a própria aplicação do cliente — consulte o Guia de Implantação.

Encriptação

Em Trânsito

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

Ao Nível da Aplicação

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 qualquer autor de pedido que não detenha a permissão view-requestor-PII (Custodians, Contributors, Readers, Reviewers e Advisors nunca a detêm), do lado do servidor, independentemente do que o cliente solicita. Campos removidos: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, além dos campos de identidade/contacto do representante e das notas de verificação de identidade.

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:

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 uma exportação de auditoria do caso (anteriormente "pacote de provas") pronta para tribunal relativa 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

Um único motor RetentionService elimina registos expirados em cinco registos — pedidos, avaliações, incidentes, reclamações e riscos de privacidade autónomos — orientado por um RetentionPeriodMonths + RetentionStartPoint por tipo (NULL = manter indefinidamente, a predefinição). Os registos que não devem expirar são excluídos por construção (uma avaliação Em Vigor, um risco Aceite, um risco associado a um caso), e um registo expirado de que outro caso aberto ainda dependa é recusado do lado do servidor; a elegibilidade é reavaliada no momento da purga. Quando um registo é purgado, o motor elimina os blobs de documentos, os PDFs convertidos, as anotações e os pacotes de exportação do Blob Storage, além dos registos da base de dados. O RetentionPurgeLog regista o que foi eliminado, quando e por quem — o EntityName identifica de que registo provém, juntamente com um instantâneo do seu número, tipo, data de encerramento e número de documentos — uma trilha de nível de conformidade que sobrevive à remoção dos dados e que nunca é, ela própria, purgada.

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:

Quando um endereço de email de alerta é fornecido na implantação, são criados, juntamente com estes, alertas de consulta agendada para falhas de autenticação SQL, falhas do trabalho de media e uma paragem da fila de media. Os clientes podem personalizar limiares e adicionar grupos de ação (email, SMS, webhook) no Portal Azure.