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

Last updated: July 12, 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 (v1.4.1).

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

Tutti i moduli sono guidati da pacchetti di configurazione, 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 + Client ID)       │         │  (~186 tables, ~2,900 fields)          │
│                              │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.Read.All       │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         └─────────────────────────────────────────┘
        │  Calendars.Read      │
        │  AiEnterprise…Read   │  ← M365 record capture (delegated + app-only Copilot)
        └──────────────────────┘

Inventario dei componenti

Componente Tecnologia Distribuito in Scopo
SPFx Web Part TypeScript, React 17, Fluent UI 8, SPFx 1.22.1 SharePoint Online / Teams del cliente Interfaccia utente per tutti i ruoli
Teams App Manifesto Teams v1.19, versione app 1.0.0 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 (~87 controller, ~88 servizi) 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 (~186 tabelle, ~2.900 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; predisposta solo quando deployAiSearch=true

Cosa gestisce l'editore

Servizio Scopo
Realizer Platform Emissione e convalida delle chiavi di licenza (nessun dato del cliente trasmesso)
AppSource Listing Distribuzione del pacchetto SPFx
Azure Marketplace Listing Modello di distribuzione dell'infrastruttura Azure
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 di configurazione.

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, famiglie di email, monitoraggio della lettura, viste salvate, anteprima Syncfusion, pipeline di redazione con esenzioni e round-trip XFDF, predisposizione del pacchetto di risposta.
Richiedenti / Contatti Identità del richiedente riutilizzabile e di prim'ordine, controllo del flusso di acquisizione, tariffe e verifica, unione; consultazioni; compositore di corrispondenza con firewall PII.
Valutazioni privacy Motore configurabile PIA/AIA/di sicurezza: modelli, questionari preliminari, delega 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, report statistici annuali, dashboard SLA/di gestione, registro di audit concatenato tramite hash e pacchetti di prove idonei in sede giudiziaria.
Configurazione e piattaforma Importazione dei pacchetti di configurazione, 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) 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. 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, configura l'autenticazione solo Entra per SQL, concede i permessi di Microsoft Graph all'identità gestita, configura le entità di archiviazione del tenant SharePoint e approva le richieste di permessi API di SPFx. Ogni passaggio può essere ignorato singolarmente.

La distribuzione è protetta (hardened) per impostazione predefinita: TLS 1.3, FTPS disabilitato, autenticazione di base SCM/FTP disabilitata e HTTP/2 abilitato. 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 di configurazione specifico per la giurisdizione.

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. RoleAuthorization:   │
     │                              │     Check UserRoles table│
     │                              │                          │
     │     ◄── 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 https://login.microsoftonline.com/{tenantId}/v2.0 e https://sts.windows.net/{tenantId}/
Registrazione dell'app Tenant singolo (AzureADMyOrg); ambito esposto access_as_user; nessun segreto client

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 (l'autenticazione con password SQL è disabilitata)
  • Azure Blob Storage — DefaultAzureCredential (identità gestita in produzione)
  • Microsoft Graph API — ManagedIdentityCredential con permessi applicazione

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

Autorizzazione e RBAC

AccessPoint implementa un controllo degli accessi basato sui ruoli a livello applicazione, archiviato in Azure SQL e applicato a livello API su ogni richiesta.

Ruolo Vede PII richiedente Gestisce richieste Gestisce assegnazioni Invia documenti Utente tipico
Administrator Sì Solo configurazione No No Admin IT, proprietario del sistema
SAO Sì Sì Sì No Funzionario accesso e privacy
Reviewer Sì Solo lettura Solo lettura No Consulente legale, QA
Custodian No No Solo proprie assegnazioni No Responsabile registri del dipartimento
Contributor No No No Solo propri compiti Esperto in materia
Reader No Solo lettura Solo lettura No Supervisione, audit

Punti di applicazione:

  1. Criteri di autorizzazione API — attributi ASP.NET Core [Authorize(Policy = "...")] su ogni azione del controller
  2. RoleAuthorizationHandler — verifica la tabella UserRoles per l'appartenenza ai ruoli dell'utente autenticato
  3. ResourceOwnerAuthorizationHandler — convalida la proprietà a livello di risorsa (ad esempio, un Contributor può accedere solo ai propri compiti)
  4. PiiFilterMiddleware — rimuove i campi PII del richiedente dalle risposte JSON per i ruoli con accesso limitato (Custodian, Contributor, Reader)

Tutti gli endpoint API di scrittura applicano i ruoli 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). I ruoli hanno un ambito e possono essere vincolati a risorse specifiche (ambito globale, di richiesta, di assegnazione o di compito). Al primo utente che accede al sistema vengono assegnati automaticamente i ruoli Administrator e SAO.

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
Configurazione del tenant (URL API, Client ID) Entità di archiviazione del tenant SharePoint Tenant M365 del cliente

Cosa attraversa i confini del tenant

Flusso di dati Direzione Cosa viene trasmesso Scopo
Convalida della licenza API → Piattaforma dell'editore Chiave di licenza (stringa opaca), ID del tenant Convalidare l'abbonamento attivo
Notifiche email API → Microsoft Graph Contenuto dell'email tramite Mail.Send Inviare notifiche dalla cassetta postale condivisa
Notifiche Teams API → Piattaforma dell'editore → Microsoft Graph Tipo di attività, testo di anteprima, ID destinatario, parametri del modello 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)
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

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 gli utenti che detengono ruoli con accesso limitato (Custodian, Contributor, Reader), lato server, indipendentemente da ciò che richiede il client. Campi rimossi: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

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 esportare, per una richiesta, un pacchetto di prove idoneo in sede giudiziaria.

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

Quando le registrazioni vengono eliminate in base alla politica di conservazione, l'eliminazione rimuove da Blob Storage i blob dei documenti, i PDF convertiti, le annotazioni e i pacchetti di esportazione, oltre alle registrazioni del database. La tabella RetentionPurgeLog registra cosa è stato eliminato, quando e da chi — una traccia di livello di conformità che sopravvive alla rimozione dei dati.

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
→