Panoramica dell'architettura tecnica per i team IT che valutano AccessPoint

Last updated: August 09, 2026 by Steve

Architettura tecnica

Questo documento fornisce una panoramica tecnica della piattaforma AccessPoint per architetti di soluzioni, ingegneri di cybersicurezza e direttori IT che valutano il prodotto per la propria organizzazione. È tratto dalla AccessPoint Solution Architecture Guide (v2.0.67).

Panoramica della piattaforma

AccessPoint è una piattaforma di gestione dell'accesso all'informazione e della privacy costruita su Microsoft 365 e Azure. È nata come strumento di gestione delle richieste di accesso ai dati personali (subject access request, SAR) ed è cresciuta fino a diventare una suite integrata per gli uffici ATIP/privacy che copre l'intero ciclo di vita delle richieste e l'intero programma di privacy circostante. Viene eseguita interamente all'interno del tenant Microsoft 365 e Azure della tua organizzazione: non ci sono server esterni, database o dipendenze cloud di terze parti in fase di esecuzione, e tutti i dati rimangono nel tuo ambiente, sotto il tuo controllo.

La piattaforma è organizzata in moduli che condividono un unico nucleo comune di identità, RBAC, notifiche, audit e reportistica:

  • Richieste di accesso — acquisizione ATI/FOIA/GDPR, assegnazione ai Custodian, revisione e redazione dei documenti, predisposizione del pacchetto di risposta e rendicontazione di legge
  • Valutazioni privacy — un motore configurabile di valutazioni PIA/AIA/di sicurezza
  • Incidenti e violazioni della privacy — acquisizione, contenimento, valutazione del rischio di danno e flussi di lavoro per la notifica delle violazioni
  • Reclami e ricorsi — ciclo di vita del reclamo con parti, termini di legge e indagine
  • Registro dei rischi per la privacy — rischi in stile ISO 31000, piani di trattamento e indicatori chiave di rischio
  • Registro delle attività di trattamento (ROPA) — registrazioni ai sensi del GDPR Article 30 ed esportazione del registro
  • Registro degli impegni — impegni di privacy monitorati con cadenza e verifiche periodiche
  • AI Assist (opzionale) — suggerimenti e stesura di bozze basati su Azure OpenAI, eseguiti interamente nell'abbonamento del cliente: riepiloghi dei documenti, suggerimenti di redazione basati sull'IA, stesura di bozze basata sui dati (grounded drafting), triage dell'acquisizione, precompilazione delle risposte alle valutazioni, ricerca semantica e rilevamento duplicati, un assistente per singolo caso con base normativa (statute-aware) (Ask AccessPoint — citazioni cliccabili, conversazioni salvate, una modalità Il mio portafoglio), risposte sui dati "Ask AccessPoint", un jurisdiction playbook che fonda le risposte operative, traduzione automatica e un daily brief — il tutto opzionale per singolo tenant, con registrazione dei soli metadati e divulgazione dell'attività IA per singola registrazione

Tutti i moduli sono guidati da pacchetti giurisdizionali, senza dati statici precaricati.

Caratteristiche chiave:

  • Nativo del tenant — si distribuisce come soluzione SharePoint Framework (SPFx) e servizi PaaS di Azure all'interno del tenant esistente
  • Nessuna dipendenza da Power Platform — nessuna licenza Dataverse, Power Automate o Power Apps richiesta
  • Sovranità dei dati — tutti i dati risiedono nella geografia configurata del tenant Azure
  • Nessun accesso del fornitore in fase di esecuzione — l'editore non può accedere ai tuoi dati durante il normale funzionamento
  • Licenza a tariffa fissa — licenza dipartimentale senza misurazione per utente
  • Privacy by design — i ruoli Custodian e Contributor sono strutturalmente isolati dalla PII del richiedente e dell'interessato
  • Configurazione anziché codice — tipi di richiesta, codici di esenzione e campi di selezione sono gestiti tramite dati
  • Multilingue per progettazione — un sistema di traduzione a tre livelli che supporta 11 lingue

Diagramma dell'architettura

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)

Inventario dei componenti

Componente Tecnologia Distribuito in Scopo
SPFx Web Part TypeScript, React 17, Fluent UI 8, SPFx 1.23.2 SharePoint Online / Teams del cliente Interfaccia utente per tutti i ruoli
Teams App Manifesto Teams v1.19, versione allineata alla soluzione SPFx e a ApiVersion.Current (applicata dalla CI) Teams Admin Center del cliente App personale, scheda configurabile, notifiche del feed di attività con deep linking
Web API C# / ASP.NET Core 10, .NET 10 (~103 controller, ~124 interfacce di servizio) Azure App Service (Linux) del cliente Logica di business, accesso ai dati, elaborazione documenti
Database SQL Server (DacPac) Azure SQL Database del cliente Archivio dati relazionale (221 tabelle, 3.410 campi)
Blob Storage Azure Blob Storage Account di archiviazione Azure del cliente Archiviazione dei file documento
Monitoraggio Application Insights + Log Analytics Abbonamento Azure del cliente Telemetria, diagnostica, avvisi
AI Search (opt-in) Azure AI Search Abbonamento Azure del cliente Ricerca full-text nel contenuto dei documenti, con ricerca vettoriale semantica (documenti + indice dei casi); predisposta solo quando deployAiSearch=true
Azure OpenAI (opt-in) Azure OpenAI Service Abbonamento Azure del cliente AI Assist — stesura di bozze basata sui dati, suggerimenti, ricerca semantica, assistente per il caso (Ask AccessPoint); autenticazione tramite identità gestita (nessuna chiave API), predisposta solo quando AI Assist è distribuito
Document Intelligence (opt-in) Azure AI Document Intelligence (prebuilt-read) Abbonamento Azure del cliente OCR per le scansioni solo immagine, a supporto di ricerca sui contenuti, rilevamento duplicati, riepiloghi e suggerimenti di redazione; autenticazione tramite identità gestita, predisposta solo quando deployDocumentIntelligence=true

Cosa gestisce l'editore

Servizio Scopo
Realizer Platform Convalida della licenza, proxy per le notifiche Teams, individuazione dell'URL API per SPFx, lo smart router della scheda personale di Teams e la pagina Finish Setup successiva alla distribuzione (nessun dato di caso del cliente trasmesso)
AppSource Listing Distribuzione del pacchetto SPFx
Modello di distribuzione Modello Bicep/ARM per il backend Azure, distribuito con un clic dal portale di Azure nella sottoscrizione del cliente
Teams App Package Distribuzione del manifesto Teams (sideload o app store dell'organizzazione)

Nessun dato del cliente viene trasmesso o archiviato da alcun servizio gestito dall'editore.

Moduli funzionali

Tutti i moduli funzionano all'interno dell'unica Web API / web part SPFx e condividono un nucleo comune di identità, RBAC, commenti, notifiche, My Day, audit, ore, flusso di revisione e reportistica. Ciascuno è gestito tramite dati per mezzo dei pacchetti giurisdizionali.

Modulo Sintesi
Richieste (ATIP/SAR) Acquisizione della richiesta → assegnazione ai Custodian → raccolta → risposta. Tipi, stati, numerazione, calendari e SLA configurabili.
Documenti e redazione Area di lavoro documentale sfaccettata: tag, cartelle, famiglie di email, monitoraggio della lettura, viste salvate, rilevamento duplicati basato su decisioni, anteprima Syncfusion, pipeline di redazione con esenzioni e round-trip XFDF, pattern di ricerca e redazione (find & redact), suggerimenti di redazione basati su regole e IA, riutilizzo delle redazioni da richieste precedenti, predisposizione del pacchetto di risposta con unione della carta intestata.
Richiedenti / Contatti Identità del richiedente riutilizzabile e di prim'ordine, controllo del flusso di acquisizione, area di lavoro per le condotte pretestuose e vessatorie (F&V), tariffe e verifica, unione; consultazioni; compositore di corrispondenza con firewall PII.
Valutazioni privacy Motore configurabile PIA/AIA/di sicurezza: modelli, questionari preliminari, assegnazione delle sezioni, punteggio/classificazione, registro dei rischi, chiusura/sintesi per l'autorità di controllo.
Incidenti privacy / Violazioni Acquisizione dell'incidente, contenimento, valutazione del rischio di danno, regole di notifica delle violazioni per regime normativo, rimedio.
Reclami e ricorsi Ciclo di vita del reclamo: parti, termini di legge, ammissibilità, indagine, esame delle osservazioni.
Rischi e impegni Registro dei rischi ISO 31000 con propensione al rischio, KRI e attività di trattamento; registro degli impegni con cadenza e verifiche periodiche.
ROPA / Soggetti privacy Programmi/sistemi riutilizzabili con registrazioni ai sensi del GDPR Article 30 ed esportazione del registro.
Revisioni Motore configurabile di revisione e approvazione sequenziale/parallela, riutilizzato in tutte le entità di caso.
Reportistica e audit Report predefiniti, generatore di report personalizzati basato su catalogo (dashboard Report Studio), report statistici annuali, dashboard SLA/di gestione, registro di audit concatenato tramite hash ed esportazioni di audit del caso idonee in sede giudiziaria.
AI Assist (opzionale) Suggerimenti e stesura di bozze basati su Azure OpenAI: riepiloghi, suggerimenti di redazione, stesura di bozze basata sui dati (grounded drafting), triage dell'acquisizione, suggerimenti per i Custodian, precompilazione e controlli di coerenza delle valutazioni, ricerca semantica e duplicati, un assistente per il caso con base normativa (statute-aware) — Ask AccessPoint (citazioni cliccabili, predisposizione di una bozza, conversazioni salvate) — oltre a un assistente Il mio portafoglio, un jurisdiction playbook precaricato dai pacchetti giurisdizionali, Ask AccessPoint, daily brief e catch-up digest, analisi del portafoglio rischi e delle condotte. Attivazione per funzionalità a livello di tenant; registrazione dei soli metadati (l'assistente può inoltre salvare trascrizioni private del titolare).
Configurazione e piattaforma Importazione dei pacchetti giurisdizionali (1 Universal Baseline + 106 pacchetti giurisdizionali, inclusi gli stati automatici di rifiuto implicito con ambito per tipo e la base per l'IA facoltativa), impostazioni del tenant, ruoli/permessi personalizzati, feature toggle, campi personalizzati, tabelle di traduzione per 11 lingue.

Modello di distribuzione

AccessPoint utilizza un modello di distribuzione suddiviso in più componenti. La web part SPFx viene installata da Microsoft AppSource (o da un App Catalog del tenant), il pacchetto dell'app Teams viene installato tramite sideload o tramite l'app store dell'organizzazione, e il backend Azure viene distribuito nell'abbonamento del cliente con uno dei due metodi seguenti:

  • Portale Azure (consigliato) — distribuzione con un clic di tutte le risorse Azure (App Service, SQL, Blob Storage, Application Insights, oltre alle risorse opzionali AI Search / Azure OpenAI / Document Intelligence) tramite ARM/Bicep. L'API viene distribuita tramite zipdeploy durante la distribuzione ARM; il codice viene scaricato una sola volta dal CDN dell'editore e archiviato nell'App Service del cliente, senza alcuna dipendenza esterna in fase di esecuzione. Una scelta obbligatoria del tipo di distribuzione protegge le ridistribuzioni: Nuova installazione crea il server SQL con approccio Entra-first (il principal che esegue la distribuzione diventa l'amministratore Entra iniziale, con autenticazione solo Entra fin dall'origine — non esiste mai alcuna credenziale SQL), mentre Aggiornamento di un'installazione esistente preserva le impostazioni dell'app dell'operatore e lascia invariato l'accesso al database. Il cliente mantiene la piena proprietà del gruppo di risorse.
  • Modello Bicep + script PowerShell (manuale) — per le organizzazioni con un controllo delle modifiche rigoroso. Un pulsante Distribuisci in Azure o lo script Deploy-AccessPoint.ps1 distribuisce l'infrastruttura, riafferma l'autenticazione solo Entra per SQL (una misura di sicurezza aggiuntiva — il modello la applica già), concede i permessi di Microsoft Graph all'identità gestita (l'alternativa tramite script alla pagina Finish Setup dell'editore), configura l'override facoltativo dell'URL API tramite l'entità di archiviazione SharePoint e approva le richieste di permessi API di SPFx. Ogni passaggio può essere ignorato singolarmente.

I permessi Graph vengono normalmente concessi tramite la pagina Finish Setup dell'editore — la distribuzione emette un output finishSetupUrl che un amministratore Entra del cliente apre per concedere ogni permesso dell'identità gestita in un unico passaggio idempotente (da rieseguire dopo gli aggiornamenti per acquisire i nuovi permessi).

La distribuzione è protetta (hardened) per impostazione predefinita: TLS 1.3, FTPS disabilitato, autenticazione di base SCM/FTP disabilitata, HTTP/2 abilitato e Microsoft Defender per SQL attivo per impostazione predefinita (con possibilità di disattivazione). L'API include il proprio DacPac del database e lo applica all'avvio tramite un servizio di migrazione che utilizza DacServices.Deploy(upgradeExisting: true) — un'operazione nulla (no-op) su uno schema già aggiornato, e un delta additivo e non distruttivo dopo una modifica dello schema (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). L'esito della migrazione viene esposto tramite /api/health. Dopo la distribuzione, un amministratore concede il consenso per l'app aziendale Realizer (notifiche Teams), configura la cassetta postale del mittente e importa un pacchetto giurisdizionale.

Autenticazione e identità

AccessPoint utilizza Microsoft Entra ID come unico provider di identità. Non esistono account utente o password specifici dell'applicazione. La web part SPFx acquisisce un JWT per l'audience dell'API tramite AadHttpClient; l'API convalida l'emittente, l'audience, la firma e la scadenza a ogni richiesta. Le policy MFA e Accesso Condizionale configurate nel tenant si applicano pienamente.

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 ───────┼──────────────────────────│
Parametro Valore
Provider di identità Microsoft Entra ID (Azure AD)
Protocollo OAuth 2.0 / OpenID Connect
Tipo di token JWT Bearer
Audience api://<client-id> e <client-id> (sono accettati sia i token v1 che v2)
Emittente Emittente di qualsiasi tenant Entra — sono convalidati i formati https://login.microsoftonline.com/{tenantId}/v2.0 (v2) e https://sts.windows.net/{tenantId}/ (v1); la rivendicazione (claim) tid del token determina l'ambito del tenant
Registrazione dell'app App multi-tenant gestita dall'editore, con consenso concesso per ciascun tenant cliente (nessuna registrazione app per singolo cliente da gestire o ruotare); ambito esposto access_as_user; nessun segreto client. L'isolamento tra i tenant dei clienti è garantito dalla rivendicazione tid convalidata, unita a un controllo di licenza/abbonamento

Identità gestita

L'App Service utilizza un'identità gestita assegnata dal sistema per autenticarsi ai servizi backend, in modo che nell'applicazione non vengano archiviati segreti client o certificati:

  • Azure SQL Database — autenticazione solo Entra (il server viene creato con approccio Entra-first; non esiste mai alcuna credenziale SQL)
  • Azure Blob Storage — DefaultAzureCredential (identità gestita in produzione)
  • Microsoft Graph API — ManagedIdentityCredential con permessi applicazione
  • Risorse IA opzionali (AI Search, Azure OpenAI, Document Intelligence) — solo identità gestita, con autenticazione locale/tramite chiave disabilitata

Le credenziali dell'identità gestita vengono ruotate automaticamente da Azure.

Autorizzazione e RBAC

AccessPoint implementa un modello di permessi granulare e configurabile a livello di tenant, archiviato in Azure SQL e applicato a livello API su ogni richiesta: un catalogo di codici di permesso atomici definito dal prodotto (ad es. request.modify, document.view, redaction.approve, request.view.pii) viene raggruppato in ruoli, e ogni azione del controller è vincolata a un codice di permesso.

Tipo di ruolo Ruoli Note
Ruolo di sistema Administrator (l'unico ruolo permanente predefinito) Si risolve in ogni permesso del catalogo — calcolato dal catalogo stesso, non tramite dati precaricati nel database — quindi non può mai restare bloccato fuori dal sistema; immutabile e non eliminabile.
Ruoli di relazione Reviewer, Custodian, Contributor, Reader, Advisor Insiemi di permessi definiti dal prodotto, conferiti automaticamente e per singolo destinatario in base alle relazioni di lavoro/collaborazione (assegnazione come Custodian, compito come Contributor, revisione, appartenenza come Advisor/Reader). Non assegnabili direttamente, con ambito limitato al record correlato, e non includono mai la PII del richiedente.
Ruoli di tenant ad es. Request Coordinator (fornito tramite il Pacchetto giurisdizionale universale), oltre a eventuali ruoli personalizzati Insiemi di permessi completamente modificabili, gestiti in Impostazioni > Ruoli e permessi. I ruoli di coordinatore/funzionario sono interamente definiti dal tenant — il Request Coordinator fornito con il pacchetto è di fatto il ruolo di funzionario per l'accesso e la privacy.
Ruolo Vede PII richiedente Accesso tipico Utente tipico
Administrator Sì Tutto (ogni permesso del catalogo) Admin IT, proprietario del sistema
Request Coordinator (ruolo di tenant) Sì Gestisce richieste, assegnazioni, redazioni, corrispondenza Funzionario per l'accesso e la privacy
Reviewer No Lettura + segnalazione/risoluzione dei rilievi di redazione sulle richieste in revisione Consulente legale, QA
Advisor No Lettura + visualizzazione/segnalazione delle redazioni (mai applicazione o approvazione) Consulente esterno, esperto in materia
Custodian No Proprie assegnazioni e relativi documenti Responsabile registri del dipartimento
Contributor No Propri compiti e relativi documenti Esperto in materia
Reader No Sola lettura sulle richieste associate e sui documenti condivisi Supervisione, audit

Punti di applicazione:

  1. Attributi [RequirePermission(code)] — un provider di criteri dinamico associa ogni azione del controller a un codice di permesso del catalogo
  2. PermissionService — risolve i permessi effettivi del chiamante (ruoli permanenti uniti alle concessioni di relazione per singolo destinatario), con controlli con ambito a livello di oggetto (richiesta/documento/assegnazione/compito)
  3. Controlli di proprietà a livello di risorsa — ad esempio, un Contributor può accedere solo ai propri compiti; un Custodian solo alle proprie assegnazioni
  4. PiiFilterMiddleware — rimuove i campi PII del richiedente dalle risposte JSON per qualsiasi chiamante che non detenga il permesso di visualizzazione della PII del richiedente

Tutti gli endpoint API di scrittura applicano i permessi lato server a livello di controller. La riclassificazione dei documenti è consapevole dell'ambito — l'utente che ha raccolto un documento è l'unico che può riclassificarlo — e una volta che una richiesta è chiusa, le modifiche al suo grafo di oggetti restituiscono HTTP 409, con un piccolo insieme di eccezioni deliberate (corrispondenza successiva alla chiusura, eliminazione per conservazione e riapertura). Le assegnazioni di ruoli permanenti hanno un ambito (globale, di richiesta, di assegnazione o di compito), possono essere facoltativamente limitate nel tempo, e i ruoli di relazione non vengono mai scritti come assegnazioni permanenti — sono derivati per singolo destinatario dai record di lavoro sottostanti. Il primo utente che accede al sistema viene inizializzato con il ruolo Administrator, e una protezione lato server impedisce la rimozione dell'ultimo Administrator attivo.

Residenza e sovranità dei dati

Tutti i dati risiedono nel tenant Azure del cliente, nella regione selezionata durante la distribuzione. Nessun dato viene trasmesso o archiviato in altre regioni a meno che il cliente non configuri esplicitamente la geo-replicazione di Azure.

Dipartimenti federali canadesi: per i requisiti di residenza dei dati specifici del GC, la mappatura dei controlli ITSG-33 e la conformità ai GC Cloud Guardrails, vedere il Riferimento controlli di sicurezza GC.

Ubicazioni dei dati del cliente

Tipo di dati Ubicazione di archiviazione Controllato da
Registrazioni delle richieste, dati utente, registro di audit Azure SQL Database Abbonamento Azure del cliente
Documenti caricati Azure Blob Storage Abbonamento Azure del cliente
Telemetria dell'applicazione Application Insights / Log Analytics Abbonamento Azure del cliente
Risorse della web part SPFx CDN SharePoint Tenant M365 del cliente
Override dell'URL API (opzionale) Entità di archiviazione del tenant SharePoint Tenant M365 del cliente (il meccanismo di individuazione principale è l'endpoint di individuazione API dell'editore)
Indici di ricerca IA, riepiloghi, output OCR (opt-in) Azure AI Search / Azure SQL Abbonamento Azure del cliente

Cosa attraversa i confini del tenant

Flusso di dati Direzione Cosa viene trasmesso Scopo
Convalida della licenza API → Piattaforma dell'editore Token di identità gestita Entra (la rivendicazione tid del token identifica il tenant), versione dell'API e l'URL di base dell'API stessa (auto-registrazione per l'individuazione da parte della web part) Convalidare l'abbonamento attivo; la risposta riporta anche l'ultima versione pubblicata di AccessPoint, così che il pannello Configurazione possa mostrare un avviso "Aggiornamento disponibile" (solo numeri di versione — nessun dato di utilizzo o di caso)
Individuazione dell'URL API SPFx → Piattaforma dell'editore Token Bearer (solo rivendicazione dell'ID tenant) Risolvere l'URL di base dell'API del cliente quando non è impostato alcun override tramite entità di archiviazione
Notifiche email API → Microsoft Graph Contenuto dell'email tramite Mail.Send Inviare notifiche dalla cassetta postale condivisa
Notifiche Teams (opzionale — attivabile/disattivabile / eliminabile) API → Piattaforma dell'editore → Microsoft Graph Tipo di attività, GUID di destinatario e tenant, testo del titolo/anteprima della notifica, nome dell'utente che ha eseguito l'azione, numero di richiesta, ID del record (collegamento diretto) Inviare notifiche del feed di attività di Teams (instradate tramite l'app aziendale multi-tenant dell'editore, poiché sendActivityNotification deve essere chiamata dall'app proprietaria del manifesto Teams). Questo è l'unico canale di notifica che lascia il tenant — l'e-mail e il feed nell'app recapitano gli stessi avvisi all'interno del tenant. Vedere Condivisione dei dati delle notifiche Teams
Ricerca profilo utente SPFx → Microsoft Graph Query di ricerca utenti Selettore persone, risoluzione utenti

Cosa non lascia mai il tenant

  • Registrazioni delle richieste e PII del richiedente
  • Documenti caricati
  • Cronologia di audit
  • Dati di configurazione (tipi di richiesta, modelli, numerazione)
  • Assegnazioni dei ruoli
  • Prompt e risposte di AI Assist — quando AI Assist è distribuito, la risorsa Azure OpenAI viene eseguita nell'abbonamento e nell'area del cliente; Microsoft non addestra i modelli sul contenuto e il contenuto dei prompt/risposte non viene memorizzato (solo metadati di utilizzo, per il contatore del budget e per la divulgazione del coinvolgimento dell'IA dell'esportazione di audit del caso)
  • Notifiche nell'app ed e-mail/Outlook — il feed nell'app viene servito dalla propria API del cliente; l'e-mail viene inviata dalla propria casella di posta condivisa del cliente tramite Mail.Send. Nessuna delle due transita attraverso l'editore. Solo il feed attività di Teams, opzionale, invia dati al di fuori del tenant, e anche questo può essere ridotto al minimo o eliminato (vedere di seguito)

Condivisione dei dati delle notifiche Teams (opzionale)

Coerentemente con la promessa di sovranità dei dati, l'unico dato di tenant che esce dal perimetro per le notifiche è un payload opzionale dell'attività di Teams — ed è possibile ridurlo al minimo o rimuoverlo del tutto. Ogni notifica viene recapitata su un massimo di tre canali; due restano sempre all'interno del tenant (il feed nell'app, servito dall'API del cliente, e l'e-mail/Outlook, inviata dalla propria casella di posta condivisa del cliente). Il feed attività di Teams è una comodità: nella sua modalità predefinita, l'API del cliente invia (POST) un piccolo payload all'app multi-tenant dell'editore, che chiama Graph sendActivityNotification (che deve essere invocata dall'app proprietaria del manifesto Teams). L'editore non ne archivia alcuna parte e registra solo i GUID del destinatario e del tenant.

Campi presenti nel payload Teams predefinito (relay dell'editore) — e cosa rimuove l'interruttore Ridurre al minimo:

Campo Contenuto Dati personali? Rimosso da Ridurre al minimo?
tenantId / recipientUserId GUID Entra del tenant e del destinatario No — identificatori No (instradamento)
activityType Enumerazione fissa del manifesto (ad es. assignmentCreated) No No
previewText / topicText Anteprima + titolo (nome di assegnazione/attività, testo della notifica) Potenzialmente (testo libero) Sì → segnaposto
actorName Nome visualizzato del membro del personale che ha eseguito l'azione Sì — nome personale Sì → "AccessPoint"
requestNumber Codice di riferimento della richiesta No — riferimento No (contesto)
relatedEntity + relatedRecordId Tipo di record + GUID (collegamento diretto) No — identificatori No (collegamento diretto)

La PII del richiedente non è mai presente nel payload — non esiste alcun campo con nome/e-mail del richiedente, e le notifiche a Custodian/Contributor sono comunque private della PII a monte. Due controlli rafforzano ulteriormente questo aspetto:

  • Ridurre al minimo (Notifications:TeamsMinimalPayload, un interruttore di tenant) sostituisce previewText, topicText e actorName con segnaposto neutri, in modo che nomi, titoli e testo libero non lascino mai il tenant — solo gli identificatori di instradamento/collegamento diretto lo fanno. Non è richiesta alcuna modifica al manifesto.
  • Eliminare (Notifications:TeamsRelayMode=Direct) fa sì che l'API del cliente chiami autonomamente Graph sendActivityNotification con la propria identità gestita, in modo che nessun payload raggiunga mai l'editore. Richiede il ruolo applicativo TeamsActivity.Send sull'identità gestita dell'API e il webApplicationInfo.id del manifesto Teams puntato sulla propria app del cliente — vedere la Guida alla distribuzione.
Modalità Payload verso l'editore PII / testo libero esce dal tenant Impegno di configurazione
Relay predefinito Sì (campi sopra indicati) Nomi/titoli, salvo riduzione al minimo Nessuno
Interruttore Ridurre al minimo Sì (solo identificatori) Nessuno Un interruttore
Relay diretto (autogestito) Nessuno Nessuno Concessione MI + modifica del manifesto
Teams disattivato Nessuno Nessuno (solo e-mail + app) Nessuno

Crittografia

In transito

Connessione Protocollo TLS minimo
Browser → App Service HTTPS (applicato, httpsOnly: true) TLS 1.3
SPFx → App Service HTTPS (applicato dal contesto SharePoint) TLS 1.3
App Service → Azure SQL TDS con crittografia (Encrypt=True) TLS 1.2+
App Service → Blob Storage HTTPS (identità gestita) TLS 1.2+
App Service → Microsoft Graph HTTPS TLS 1.2+

L'App Service applica TLS 1.3 come minimo al punto di ingresso (TLS 1.0/1.1/1.2 rifiutati); le connessioni in uscita verso i servizi backend di Azure negoziano TLS 1.2 o superiore.

A riposo

Archivio dati Crittografia Gestione delle chiavi
Azure SQL Database Transparent Data Encryption (TDE) Chiavi gestite da Microsoft (predefinito) o chiavi gestite dal cliente (CMK)
Azure Blob Storage Storage Service Encryption (SSE), AES-256 Chiavi gestite da Microsoft (predefinito) o chiavi gestite dal cliente (CMK)
Application Insights Crittografia della piattaforma Chiavi gestite da Microsoft

A livello applicazione

Funzionalità Meccanismo
Token del visualizzatore documenti ASP.NET Core Data Protection (token in stile WOPI, TTL di 15 minuti, verifica incrociata del tenant a ogni chiamata anonima del visualizzatore)
Firme elettroniche di attestazione Hash SHA-256 del firmatario e marca temporale archiviati nei campi di audit

Privacy by Design

AccessPoint implementa controlli di privacy strutturali applicati a livello API, non solo nell'interfaccia utente.

Middleware di filtro PII

Un middleware a livello di risposta intercetta tutte le risposte JSON e rimuove i campi PII per qualsiasi chiamante che non detenga il permesso di visualizzazione della PII del richiedente (Custodian, Contributor, Reader, Reviewer e Advisor non lo detengono mai), lato server, indipendentemente da ciò che richiede il client. Campi rimossi: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, oltre ai campi di identità/contatto del rappresentante e alle note di verifica dell'identità.

Oscuramento della PII nelle notifiche

Quando le notifiche vengono inviate a Custodian o Contributor, la PII del richiedente viene sostituita con testo segnaposto nel contenuto stesso della notifica — anche se il modello di notifica include campi di unione con PII.

Isolamento Custodian / Contributor

  • I Custodian vedono solo le richieste loro assegnate e lavorano a partire da istruzioni sanificate
  • I Contributor vedono solo i compiti loro assegnati
  • Nessuno dei due ruoli può cercare, sfogliare o accedere a richieste al di fuori del proprio ambito

Registrazione, monitoraggio e audit

Application Insights

Tutta la telemetria API viene inviata all'istanza Application Insights del cliente:

Segnale Cosa viene rilevato
Tracce delle richieste Metodo HTTP, percorso, codice di stato, durata, ID di correlazione
Monitoraggio delle dipendenze Query SQL, operazioni Blob, chiamate Graph API (durata, esito positivo/negativo)
Eccezioni Eccezioni non gestite con stack trace
Metriche personalizzate Tempi di elaborazione delle richieste, durate di conversione dei documenti

Registro di audit

AccessPoint mantiene un registro di audit completo nella tabella AuditHistory (Azure SQL), che registra il tipo di entità, l'ID dell'entità, l'azione (Create, Update, Delete, StatusChange), il nome del campo, i valori precedenti/nuovi, un motivo di modifica facoltativo (rilevato nelle transizioni di stato come chiusura e riapertura), l'utente autenticato e una marca temporale UTC. Le registrazioni di audit sono immutabili — non possono essere modificate o eliminate tramite l'API.

Registro di audit concatenato tramite hash

Oltre al registro di audit a livello di campo, un AuditLedger a prova di manomissione e a sola aggiunta (catena di hash SHA-256) registra le azioni in tutti i moduli. L'integrità può essere verificata lato server, ed è possibile generare, per una richiesta, un'esportazione di audit del caso idonea in sede giudiziaria (in precedenza "pacchetto di prove").

Concorrenza ottimistica

Le entità ad alta contesa (Requests, Documents, CustodianAssignments) presentano ciascuna un token di concorrenza SQL Server ROWVERSION. Il client restituisce la row version in fase di aggiornamento; se un altro autore ha modificato la riga nel frattempo, il salvataggio viene rifiutato con HTTP 409 ("Concurrent edit detected") anziché sovrascrivere silenziosamente.

Registro delle eliminazioni per conservazione

Un unico motore RetentionService dispone dei record scaduti su cinque registri — richieste, valutazioni, incidenti, reclami e rischi autonomi per la privacy — guidato da una coppia RetentionPeriodMonths + RetentionStartPoint per tipo (NULL = conservare indefinitamente, l'impostazione predefinita). I record che non devono mai scadere sono esclusi per costruzione (una valutazione In vigore, un rischio Accettato, un rischio ancorato a un caso), e un record scaduto da cui dipende ancora un altro caso aperto viene rifiutato lato server; l'idoneità viene rivalutata al momento dell'eliminazione. Quando un record viene eliminato, il motore rimuove da Blob Storage i blob dei documenti, i PDF convertiti, le annotazioni e i pacchetti di esportazione, oltre ai record del database. Il RetentionPurgeLog registra cosa è stato eliminato, quando e da chi — EntityName identifica da quale registro proviene, insieme a un'istantanea del suo numero, tipo, data di chiusura e numero di documenti — una traccia di livello di conformità che sopravvive alla rimozione dei dati e non viene mai eliminata a sua volta.

Log Analytics e avvisi

Application Insights si appoggia a un workspace Log Analytics con conservazione configurabile (predefinita a 90 giorni; configurabile tra 30 e 730 giorni). I dati possono essere esportati in Microsoft Sentinel o in un SIEM esistente. La distribuzione Bicep include due avvisi sulle metriche predefiniti sull'App Service:

Avviso Gravità Condizione Finestra
Errori del server 2 (Avviso) Conteggio HTTP 5xx > 5 5 minuti
Latenza elevata 3 (Informativo) Tempo di risposta medio > 5 secondi 15 minuti

I clienti possono personalizzare le soglie e aggiungere gruppi di azioni (email, SMS, webhook) nel Portale Azure.

←
Previous Guida introduttiva ad AccessPoint
Next Riferimento controlli di sicurezza GC
→