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

Last updated: August 09, 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 (v2.0.67).

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
  • 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

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 override,          │         │  (222 tables, 3,410 fields)            │
│   optional)                  │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        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   │         └─────────────────────────────────────────┘
        └──────────────────────┘  ← 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.23.2 SharePoint Online / Teams do cliente Interface do utilizador para todas as funções
Teams App Teams manifest v1.19, versão sincronizada com a solução SPFx e ApiVersion.Current (carimbada pela CI) 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 (~103 controladores, ~124 interfaces de serviço) 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 (221 tabelas, 3.410 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, mais pesquisa vetorial semântica (documentos + índice de casos); aprovisionado apenas quando deployAiSearch=true
Azure OpenAI (opcional) Azure OpenAI Service Subscrição Azure do cliente AI Assist — elaboração de rascunhos fundamentada, sugestões, pesquisa semântica, assistente de caso (Ask AccessPoint); autenticação por identidade gerida (sem chaves de API), aprovisionado apenas quando o AI Assist está implantado
Document Intelligence (opcional) Azure AI Document Intelligence (prebuilt-read) Subscrição Azure do cliente OCR para digitalizações apenas como imagem, alimentando a pesquisa de conteúdo, a deteção de duplicados, os resumos e as sugestões de redação; autenticação por identidade gerida, aprovisionado apenas quando deployDocumentIntelligence=true

O Que o Editor Opera

Serviço Finalidade
Realizer Platform Validação de licença, proxy de notificações Teams, descoberta do URL da API para o SPFx, o router inteligente do separador pessoal do Teams, e a página Finish Setup pós-implantação (sem transmissão de dados de caso do cliente)
AppSource Listing Distribuição do pacote SPFx
Modelo de implantação Modelo Bicep/ARM para o backend do Azure, implantado com um clique a partir do portal do Azure na assinatura do cliente
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 Jurisdicionais.

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, pastas, famílias de email, acompanhamento de leitura, vistas guardadas, deteção de duplicados baseada em decisões, pré-visualização Syncfusion, pipeline de redação com isenções e round-trip XFDF, padrões de localizar e redigir, sugestões de redação baseadas em regras e por IA, reutilização de redações de pedidos anteriores, preparação do pacote de resposta com mesclagem de papel timbrado.
Requerentes / Contactos Identidade de requerente reutilizável de primeira classe, controlo do fluxo de receção, espaço de trabalho de conduta frívola-e-vexatória, 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, atribuição de secção, 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 orientado por catálogo (dashboards do Report Studio), relatórios estatísticos anuais, painéis de SLA/gestão, livro-razão de auditoria em cadeia de hash e exportações de auditoria de caso prontas para tribunal.
AI Assist (opcional) Sugestões e elaboração de rascunhos com base em Azure OpenAI: resumos, sugestões de redação, elaboração de rascunhos fundamentada, triagem de admissão, sugestões para custodians, pré-preenchimento e verificações de consistência de avaliações, pesquisa semântica e duplicados, um assistente de caso sensível ao estatuto — Ask AccessPoint (citações clicáveis, preparação de rascunhos, conversas guardadas) — mais um assistente de carteira/portefólio (modo A Minha Carteira), um guia de procedimentos da jurisdição alimentado por pacotes jurisdicionais, relatórios do Ask AccessPoint, resumo diário e resumo de acompanhamento, portefólio de riscos e análise de conduta. Comutadores de tenant por funcionalidade; registo apenas com metadados (o assistente pode adicionalmente guardar transcrições privadas do proprietário).
Configuração e Plataforma Importação de pacotes jurisdicionais (1 pacote Universal Baseline + 106 pacotes jurisdicionais, incluindo estados automáticos de recusa presumida delimitados por tipo e fundamentação de IA opcional), 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, além dos recursos opcionais AI Search / Azure OpenAI / Document Intelligence) 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 ───────┼──────────────────────────│
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 O emissor de qualquer tenant Entra — são validados os formatos https://login.microsoftonline.com/{tenantId}/v2.0 (v2) e https://sts.windows.net/{tenantId}/ (v1); a claim tid do token determina o âmbito por tenant
Registo da Aplicação Aplicação multi-tenant operada pelo editor, consentida por cada tenant de cliente (sem registo de aplicação por cliente para gerir ou rodar); âmbito exposto access_as_user; sem segredo de cliente. O isolamento entre tenants de clientes é garantido pela claim tid validada, mais uma verificação de licença/subscrição

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 de IA opcionais (AI Search, Azure OpenAI, Document Intelligence) — apenas por identidade gerida, com autenticação local/por chave desativada

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.

Tipo de função Funções Notas
Função de sistema Administrator (a única função permanente incorporada) Resolve para todas as permissões do catálogo — calculada a partir do catálogo, e não semeada na base de dados — pelo que nunca pode ficar bloqueada; imutável e não eliminável.
Funções de relação Reviewer, Custodian, Contributor, Reader, Advisor Conjuntos de permissões definidos pelo produto, conferidos automaticamente e por alvo, através de relações de trabalho/colaboração (atribuição de custodian, tarefa de contributor, revisão, associação de advisor/reader). Não são atribuíveis diretamente, têm âmbito limitado ao registo relacionado, e nunca incluem PII do requerente.
Funções de tenant por exemplo, Request Coordinator (fornecida através do pacote Universal Baseline), além de quaisquer funções personalizadas Conjuntos de permissões totalmente editáveis, geridos em Settings > Roles & Permissions. As funções de coordenador/responsável são inteiramente definidas pelo tenant — o Request Coordinator fornecido pelo pacote é a função de facto de responsável por acesso e privacidade.
Função Vê PII do Requerente Acesso Típico Utilizador Típico
Administrator Sim Tudo (todas as permissões do catálogo) Administrador de TI, proprietário do sistema
Request Coordinator (função de tenant) Sim Gere pedidos, atribuições, redações, correspondência Responsável de acesso e privacidade
Reviewer Não Leitura + assinalar/resolver questões de redação em pedidos em revisão Assessor jurídico, QA
Advisor Não Leitura + ver/assinalar redações (nunca aplicar ou aprovar) Assessor consultor, especialista na matéria
Custodian Não Próprias atribuições e respetivos documentos Responsável de registos do departamento
Contributor Não Próprias tarefas e respetivos documentos Especialista na matéria
Reader Não Apenas leitura nos pedidos associados e documentos partilhados Supervisão, auditoria

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

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
Substituição do URL da API (opcional) SharePoint Tenant Storage Entity Tenant M365 do cliente (a descoberta principal é o endpoint de descoberta de API do editor)
Índices de pesquisa de IA, resumos, resultados de OCR (opcional) Azure AI Search / Azure SQL Subscrição Azure 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 Token de identidade gerida do Entra (a claim tid do token identifica o tenant), versão da API, e o próprio URL base da API (auto-registo para descoberta pelo web part) Validar subscrição ativa; a resposta também transporta a versão mais recente publicada do AccessPoint, para que o painel de Configuração possa mostrar um aviso de "Atualização disponível" (apenas números de versão — sem dados de utilização ou de caso)
Descoberta do URL da API SPFx → Publisher Platform Token Bearer (apenas com a claim de ID do tenant) Resolver o URL base da API do cliente quando não está definida nenhuma substituição por storage entity
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 (opcional — comutável / elimináveis) API → Publisher Platform → Microsoft Graph Tipo de atividade, GUIDs do destinatário + tenant, título/texto de pré-visualização da notificação, nome do utilizador que praticou a ação, número do pedido, id do registo (ligação direta) 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). Este é o único canal de notificação que sai do tenant — o email e o feed na aplicação entregam os mesmos avisos dentro do tenant. Consulte Partilha de Dados de Notificação do 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
  • 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:

Campo Contém Dados pessoais? Removido por Minimizar?
tenantId / recipientUserId GUIDs Entra do tenant + destinatário Não — identificadores Não (encaminhamento)
activityType Enum fixo do manifesto (por exemplo, assignmentCreated) Não Não
previewText / topicText Pré-visualização + título (nome da atribuição/tarefa, texto da notificação) Potencialmente (texto livre) Sim → indicador de espaço reservado
actorName Nome de exibição do colaborador que praticou a ação Sim — nome pessoal Sim → "AccessPoint"
requestNumber Código de referência do pedido Não — referência Não (contexto)
relatedEntity + relatedRecordId Tipo de registo + GUID (ligação direta) Não — identificadores Não (ligação direta)

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.
Modo Payload para o editor PII / texto livre sai do tenant Esforço de configuração
Relay predefinido Sim (campos acima) Nomes/títulos, salvo se minimizado Nenhum
Interruptor Minimizar Sim (apenas identificadores) Nenhum Um interruptor
Relay Direto (auto-hospedado) Nenhum Nenhum Concessão de MI + edição do manifesto
Teams desativado Nenhum Nenhum (apenas email + na aplicação) Nenhum

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 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:

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 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:

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
→