Technischer Architekturüberblick für IT-Teams, die AccessPoint evaluieren

Last updated: August 09, 2026 by Steve

Technische Architektur

Dieses Dokument bietet einen technischen Überblick über die AccessPoint-Plattform für Lösungsarchitekten, Cybersicherheitsingenieure und IT-Leiter, die das Produkt für ihre Organisation evaluieren. Es basiert auf dem AccessPoint Solution Architecture Guide (v2.0.67).

Plattformübersicht

AccessPoint ist eine Plattform für Informationszugang und Datenschutzmanagement, die auf Microsoft 365 und Azure aufbaut. Sie begann als Werkzeug zur Verwaltung von Auskunftsersuchen (subject access request, SAR) und hat sich zu einer integrierten Suite für das ATIP-/Datenschutzbüro entwickelt, die den gesamten Antragslebenszyklus und das umgebende Datenschutzprogramm abdeckt. Sie läuft vollständig innerhalb des Microsoft 365- und Azure-Mandanten Ihrer eigenen Organisation: Es gibt zur Laufzeit keine externen Server, Datenbanken oder Cloud-Abhängigkeiten von Drittanbietern, und alle Daten verbleiben in Ihrer Umgebung unter Ihrer Kontrolle.

Die Plattform ist in Module gegliedert, die sich ein gemeinsames Rückgrat aus Identität, RBAC, Benachrichtigungen, Audit und Reporting teilen:

  • Zugangsanträge – ATI-/FOIA-/GDPR-Erfassung, Beauftragung von Custodians, Dokumentenprüfung und Schwärzung, Antwortzusammenstellung und gesetzliche Berichterstattung
  • Datenschutzbewertungen – eine konfigurierbare Engine für PIA-, AIA- und Sicherheitsbewertungen
  • Datenschutzvorfälle und -verletzungen – Workflows für Erfassung, Eindämmung, Schadensrisiko und Meldung von Datenschutzverletzungen
  • Beschwerden und Widersprüche – Beschwerdelebenszyklus mit Beteiligten, gesetzlichen Fristen und Untersuchung
  • Datenschutz-Risikoregister – Risiken im Stil von ISO 31000, Behandlungspläne und wesentliche Risikoindikatoren
  • Verzeichnisse von Verarbeitungstätigkeiten (ROPA) – Datensätze gemäß GDPR Article 30 und Registerexport
  • Verpflichtungsregister – nachverfolgte Datenschutzverpflichtungen mit Turnus und Check-ins
  • AI Assist (optional) – auf Azure OpenAI gestützte Vorschläge und Entwürfe, die vollständig im eigenen Abonnement des Kunden laufen: Dokumentzusammenfassungen, KI-Schwärzungsvorschläge, faktengestütztes Entwerfen, Eingangstriage, Vorausfüllen von Bewertungsantworten, semantische Suche und Duplikaterkennung, ein gesetzesbewusster, fallbezogener Assistent (Ask AccessPoint — anklickbare Zitate, gespeicherte Unterhaltungen, ein Modus „Mein Fallbestand"), Datenantworten über „Ask AccessPoint", ein Jurisdiktions-Playbook, das Verfahrensantworten fundiert, automatische Übersetzung und ein Tagesbriefing — alles pro Mandant optional, nur mit Metadaten protokolliert, mit einer Offenlegung der KI-Aktivität pro Datensatz

Alle Module werden durch Rechtsordnungspakete gesteuert, ohne statische Seed-Daten.

Hauptmerkmale:

  • Mandantennativ – wird als SharePoint Framework (SPFx)-Lösung und Azure PaaS-Dienste innerhalb Ihres bestehenden Mandanten bereitgestellt
  • Keine Power Platform-Abhängigkeiten – keine Lizenzierung für Dataverse, Power Automate oder Power Apps erforderlich
  • Datensouveränität – alle Daten verbleiben in der konfigurierten Geografie Ihres Azure-Mandanten
  • Kein Anbieterzugriff zur Laufzeit – der Herausgeber kann während des normalen Betriebs nicht auf Ihre Daten zugreifen
  • Pauschallizenzierung – behördenweite Lizenzierung ohne nutzungsabhängige Abrechnung pro Benutzer
  • Privacy by Design – die Rollen Custodian und Contributor sind strukturell von den PII des Antragstellers und der betroffenen Person abgeschottet
  • Konfiguration statt Code – Antragstypen, Ausnahmecodes und Auswahlfelder sind datengesteuert
  • Mehrsprachig konzipiert – ein dreistufiges Übersetzungssystem mit Unterstützung für 11 Sprachen

Architekturdiagramm

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)

Komponenteninventar

Komponente Technologie Bereitgestellt in Zweck
SPFx Web Part TypeScript, React 17, Fluent UI 8, SPFx 1.23.2 SharePoint Online / Teams des Kunden Benutzeroberfläche für alle Rollen
Teams App Teams-Manifest v1.19, Versionsgleichstand mit der SPFx-Lösung und ApiVersion.Current (von CI gestempelt) Teams Admin Center des Kunden Persönliche App, konfigurierbare Registerkarte, Aktivitätsfeed-Benachrichtigungen mit Deep-Linking
Web API C# / ASP.NET Core 10, .NET 10 (~103 Controller, ~124 Service-Interfaces) Azure App Service (Linux) des Kunden Geschäftslogik, Datenzugriff, Dokumentverarbeitung
Datenbank SQL Server (DacPac) Azure SQL Database des Kunden Relationaler Datenspeicher (221 Tabellen, 3.410 Felder)
Blob Storage Azure Blob Storage Azure Storage Account des Kunden Dokumentdateispeicherung
Überwachung Application Insights + Log Analytics Azure-Abonnement des Kunden Telemetrie, Diagnose, Warnungen
AI Search (Opt-in) Azure AI Search Azure-Abonnement des Kunden Volltextsuche in Dokumentinhalten sowie semantische Vektorsuche (Dokumente + Fallindex); nur bereitgestellt, wenn deployAiSearch=true
Azure OpenAI (Opt-in) Azure OpenAI Service Azure-Abonnement des Kunden AI Assist — faktengestütztes Entwerfen, Vorschläge, semantische Suche, Fall-Assistent (Ask AccessPoint); Authentifizierung per verwalteter Identität (keine API-Schlüssel), nur bereitgestellt, wenn AI Assist bereitgestellt ist
Document Intelligence (Opt-in) Azure AI Document Intelligence (prebuilt-read) Azure-Abonnement des Kunden OCR für reine Bildscans, die in Inhaltssuche, Duplikaterkennung, Zusammenfassungen und Schwärzungsvorschläge einfließen; Authentifizierung per verwalteter Identität, nur bereitgestellt, wenn deployDocumentIntelligence=true

Was der Herausgeber betreibt

Dienst Zweck
Realizer Platform Lizenzvalidierung, Teams-Benachrichtigungs-Proxy, SPFx-API-URL-Ermittlung, der intelligente Router für die persönliche Teams-Registerkarte und die Seite „Einrichtung abschließen" nach der Bereitstellung (keine Kundenfalldaten übertragen)
AppSource Listing Verteilung des SPFx-Pakets
Bereitstellungsvorlage Bicep/ARM-Vorlage für das Azure-Backend, per Ein-Klick-Bereitstellung aus dem Azure-Portal in das Abonnement des Kunden
Teams App Package Verteilung des Teams-Manifests (Sideload oder Organisations-App-Store)

Es werden keine Kundendaten an einen vom Herausgeber betriebenen Dienst übertragen oder von diesem gespeichert.

Funktionsmodule

Alle Module laufen innerhalb der einzigen Web API / des SPFx-Webparts und teilen sich ein gemeinsames Rückgrat aus Identität, RBAC, Kommentaren, Benachrichtigungen, Mein Tag, Audit, Stunden, Prüf-Workflow und Reporting. Jedes ist über Rechtsordnungspakete datengesteuert.

Modul Zusammenfassung
Anträge (ATIP/SAR) Antragserfassung → Beauftragung von Custodians → Sammlung → Antwort. Konfigurierbare Typen, Status, Nummerierung, Kalender und SLAs.
Dokumente & Schwärzung Facettierter Dokumentarbeitsbereich: Tags, Ordner, E-Mail-Familien, Leseverfolgung, gespeicherte Ansichten, entscheidungsbasierte Duplikaterkennung, Syncfusion-Vorschau, Schwärzungspipeline mit Ausnahmen und XFDF-Roundtrip, Suchen-&-schwärzen-Muster, regelbasierte und KI-Schwärzungsvorschläge, Wiederverwendung von Schwärzungen aus früheren Anträgen, Antwortzusammenstellung mit Briefkopf-Zusammenführung.
Antragsteller / Kontakte Vollwertige, wiederverwendbare Antragsteller-Identität, Steuerung des Erfassungsablaufs, Arbeitsbereich für mutwillig-schikanöses Verhalten, Gebühren & Verifizierung, Zusammenführung; Konsultationen; Korrespondenz-Editor mit PII-Firewall.
Datenschutzbewertungen Konfigurierbare PIA-/AIA-/Sicherheits-Engine: Vorlagen, Vorprüfungen, Abschnittszuweisung, Scoring/Einstufung, Risikoregister, Abschluss-/Aufsichtsbehörden-Zusammenfassungen.
Datenschutzvorfälle / Verletzung Vorfallerfassung, Eindämmung, Schadensrisiko, Regeln zur Meldung von Datenschutzverletzungen je Regelwerk, Behebung.
Beschwerden & Widersprüche Beschwerdelebenszyklus: Beteiligte, gesetzliche Fristen, Zulässigkeit, Untersuchung, Prüfung von Stellungnahmen.
Risiko & Verpflichtungen ISO 31000-Risikoregister mit Risikoappetit, KRIs und Behandlungsaufgaben; Verpflichtungsregister mit Turnus und Check-ins.
ROPA / Datenschutzgegenstände Wiederverwendbare Programme/Systeme mit Datensätzen gemäß GDPR Article 30 und Registerexport.
Prüfungen Konfigurierbare Engine für sequenzielle/parallele Prüfung und Genehmigung, die über alle Fallentitäten hinweg wiederverwendet wird.
Reporting & Audit Feste Berichte, kataloggesteuerter benutzerdefinierter Berichtseditor (Report Studio-Dashboards), statistische Jahresberichte, SLA-/Management-Dashboards, hash-verkettetes Audit-Ledger und gerichtsfeste Fall-Audit-Exports.
AI Assist (optional) Auf Azure OpenAI gestützte Vorschläge und Entwürfe: Zusammenfassungen, Schwärzungsvorschläge, faktengestütztes Entwerfen, Eingangstriage, Custodian-Vorschläge, Vorausfüllen von Bewertungen und Konsistenzprüfungen, semantische Suche und Duplikate, ein gesetzesbewusster Fall-Assistent — Ask AccessPoint (anklickbare Zitate, Entwurfsvorbereitung, gespeicherte Unterhaltungen) — sowie ein Mein-Fallbestand-/Portfolio-Assistent, ein paketseitig vorbefülltes Jurisdiktions-Playbook, Ask AccessPoint für Berichte, Tagesbriefing und Catch-up-Digest, Risikoportfolio- und Verhaltensanalyse. Funktionsschalter je Mandant; ausschließlich Metadatenprotokollierung (der Assistent kann zusätzlich eigentümer-private Gesprächsprotokolle speichern).
Konfiguration & Plattform Import von Rechtsordnungspaketen (1 Universal Baseline + 106 rechtsraumspezifische Pakete, einschließlich typgebundener automatischer Status für fingierte Ablehnung und optionaler KI-Fundierung), Mandanteneinstellungen, benutzerdefinierte Rollen/Berechtigungen, Feature-Toggles, benutzerdefinierte Felder, Übersetzungstabellen für 11 Sprachen.

Bereitstellungsmodell

AccessPoint verwendet ein geteiltes Bereitstellungsmodell. Das SPFx-Webpart wird aus Microsoft AppSource (oder einem Mandanten-App-Katalog) installiert, das Teams-App-Paket wird per Sideloading oder über den App-Store der Organisation installiert, und das Azure-Backend wird über eine von zwei Methoden im eigenen Abonnement des Kunden bereitgestellt:

  • Azure-Portal (empfohlen) – Ein-Klick-Bereitstellung aller Azure-Ressourcen (App Service, SQL, Blob Storage, Application Insights, zuzüglich der optionalen AI Search-/Azure OpenAI-/Document Intelligence-Ressourcen) über ARM/Bicep. Die API wird während der ARM-Bereitstellung per zipdeploy bereitgestellt; der Code wird einmalig vom Herausgeber-CDN heruntergeladen und im App Service des Kunden gespeichert, ohne externe Abhängigkeit zur Laufzeit. Eine verpflichtende Auswahl des Bereitstellungstyps schützt vor erneuten Bereitstellungen: Neuinstallation erstellt den SQL-Server Entra-first (der bereitstellende Prinzipal wird zum anfänglichen Entra-Administrator, von Anfang an ausschließlich Entra-Authentifizierung – es existiert nie eine SQL-Anmeldeinformation), während Upgrade einer bestehenden Installation vom Betreiber vorgenommene Anwendungseinstellungen bewahrt und den Datenbankzugriff unverändert lässt. Der Kunde behält die vollständige Eigentümerschaft an der Ressourcengruppe.
  • Bicep-Vorlage + PowerShell-Skript (manuell) – für Organisationen mit strenger Änderungssteuerung. Eine Deploy to Azure-Schaltfläche oder Deploy-AccessPoint.ps1 stellt die Infrastruktur bereit, bekräftigt erneut die ausschließlich Entra-basierte SQL-Authentifizierung (ein Backstop – die Vorlage wendet ihn bereits an), erteilt der verwalteten Identität Microsoft Graph-Berechtigungen (die skriptbasierte Alternative zur Seite „Einrichtung abschließen" des Herausgebers), konfiguriert die optionale SharePoint-Speicherentität als API-URL-Override und genehmigt SPFx-API-Berechtigungsanforderungen. Jeder Schritt kann unabhängig übersprungen werden.

Graph-Berechtigungen werden normalerweise über die Seite „Einrichtung abschließen" des Herausgebers erteilt – die Bereitstellung gibt einen Output finishSetupUrl aus, den ein Entra-Administrator des Kunden öffnet, um jede Berechtigung der verwalteten Identität in einem einzigen idempotenten Durchlauf zu erteilen (nach Upgrades erneut ausführen, um neu hinzugekommene Berechtigungen zu übernehmen).

Die Bereitstellung ist standardmäßig sicherheitsgehärtet: TLS 1.3, FTPS deaktiviert, SCM/FTP-Basisauthentifizierung deaktiviert, HTTP/2 aktiviert und Microsoft Defender for SQL standardmäßig aktiviert (abwählbar). Die API bündelt ihre Datenbank-DacPac und wendet sie beim Start über einen Migrationsdienst mit DacServices.Deploy(upgradeExisting: true) an – ein No-Op bei einem bereits aktuellen Schema und ein additives, nicht-destruktives Delta nach einer Schemaänderung (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). Das Migrationsergebnis wird über /api/health sichtbar gemacht. Nach der Bereitstellung erteilt ein Administrator die Zustimmung für die Realizer-Unternehmensanwendung (Teams-Benachrichtigungen), konfiguriert das Absenderpostfach und importiert ein Rechtsordnungspaket.

Authentifizierung und Identität

AccessPoint verwendet Microsoft Entra ID als einzigen Identitätsanbieter. Es gibt keine anwendungsspezifischen Benutzerkonten oder Passwörter. Das SPFx-Webpart ruft über AadHttpClient ein JWT für die API-Zielgruppe ab; die API validiert bei jeder Anfrage Aussteller, Zielgruppe, Signatur und Ablauf. Im Mandanten konfigurierte MFA- und Conditional Access-Richtlinien gelten vollumfänglich.

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 ───────┼──────────────────────────│
Parameter Wert
Identitätsanbieter Microsoft Entra ID (Azure AD)
Protokoll OAuth 2.0 / OpenID Connect
Token-Typ JWT Bearer
Zielgruppe api://<client-id> und <client-id> (sowohl v1- als auch v2-Token akzeptiert)
Aussteller Aussteller eines beliebigen Entra-Mandanten — validiert werden die Formate https://login.microsoftonline.com/{tenantId}/v2.0 (v2) und https://sts.windows.net/{tenantId}/ (v1); der tid-Anspruch des Tokens steuert die Mandantenzuordnung
App-Registrierung Vom Herausgeber betriebene mandantenübergreifende App, pro Kundenmandant zugestimmt (keine kundenspezifische App-Registrierung zu verwalten oder zu rotieren); bereitgestellter Scope access_as_user; kein Client Secret. Die Isolation zwischen Kundenmandanten wird durch den validierten tid-Anspruch zuzüglich einer Lizenz-/Abonnementprüfung durchgesetzt

Verwaltete Identität

Der App Service verwendet eine systemseitig zugewiesene verwaltete Identität, um sich bei Backend-Diensten zu authentifizieren, sodass keine Client Secrets oder Zertifikate in der Anwendung gespeichert werden:

  • Azure SQL Database – ausschließlich Entra-Authentifizierung (der Server wird Entra-first erstellt; es existiert nie eine SQL-Anmeldeinformation)
  • Azure Blob Storage – DefaultAzureCredential (verwaltete Identität in der Produktion)
  • Microsoft Graph API – ManagedIdentityCredential mit Anwendungsberechtigungen
  • Optionale KI-Ressourcen (AI Search, Azure OpenAI, Document Intelligence) – ausschließlich verwaltete Identität, mit deaktivierter lokaler/Schlüssel-Authentifizierung

Die Anmeldeinformationen der verwalteten Identität werden von Azure automatisch rotiert.

Autorisierung und RBAC

AccessPoint implementiert ein granulares, mandantenkonfigurierbares Berechtigungsmodell, das in Azure SQL gespeichert und bei jeder Anfrage auf der API-Ebene durchgesetzt wird: Ein produktseitig definierter Katalog atomarer Berechtigungscodes (z. B. request.modify, document.view, redaction.approve, request.view.pii) wird zu Rollen gruppiert, und jede Controller-Aktion wird über einen Berechtigungscode abgesichert.

Rollentyp Rollen Anmerkungen
Systemrolle Administrator (die einzige integrierte Standardrolle) Löst jede Katalogberechtigung auf – berechnet aus dem Katalog, nicht aus Datenbank-Seeding –, sodass sie niemals ausgesperrt werden kann; unveränderlich und unlöschbar.
Beziehungsrollen Reviewer, Custodian, Contributor, Reader, Advisor Produktseitig definierte Berechtigungsbündel, die automatisch und pro Ziel durch Arbeits-/Zusammenarbeitsbeziehungen verliehen werden (Custodian-Zuweisung, Contributor-Aufgabe, Prüfung, Advisor-/Reader-Mitgliedschaft). Nicht direkt zuweisbar, auf den zugehörigen Datensatz begrenzt und enthalten niemals PII des Antragstellers.
Mandantenrollen z. B. Request Coordinator (mitgeliefert über das Paket Universal Baseline), sowie beliebige benutzerdefinierte Rollen Vollständig editierbare Berechtigungsbündel, verwaltet unter Einstellungen > Rollen & Berechtigungen. Koordinator-/Sachbearbeiterrollen sind vollständig mandantendefiniert – der paketseitig mitgelieferte Request Coordinator ist die faktische Rolle des Beauftragten für Informationszugang und Datenschutz.
Rolle Sieht PII des Antragstellers Typischer Zugriff Typischer Benutzer
Administrator Ja Alles (alle Katalogberechtigungen) IT-Administrator, Systemverantwortlicher
Request Coordinator (Mandantenrolle) Ja Verwaltet Anträge, Zuweisungen, Schwärzungen, Korrespondenz Informationszugangs- und Datenschutzbeauftragter
Reviewer Nein Lesen + Schwärzungsanliegen bei Anträgen in Prüfung kennzeichnen/klären Rechtsberater, QS
Advisor Nein Lesen + Schwärzungen einsehen/kennzeichnen (nie anwenden oder genehmigen) Beratender Rechtsanwalt, Fachexperte
Custodian Nein Eigene Zuweisungen und deren Dokumente Schriftgutverantwortlicher der Abteilung
Contributor Nein Eigene Aufgaben und deren Dokumente Fachexperte
Reader Nein Schreibgeschützt bei zugehörigen Anträgen und freigegebenen Dokumenten Aufsicht, Audit

Durchsetzungspunkte:

  1. [RequirePermission(code)]-Attribute – ein dynamischer Policy-Provider ordnet jede Controller-Aktion einem Katalog-Berechtigungscode zu
  2. PermissionService – löst die effektiven Berechtigungen des Aufrufers auf (Standardrollen vereinigt mit zielspezifischen Beziehungs-Berechtigungen), mit objektbezogenen Prüfungen auf Antrags-/Dokument-/Zuweisungs-/Aufgabenebene
  3. Eigentumsprüfungen auf Ressourcenebene – z. B. kann ein Contributor nur auf seine eigenen Aufgaben zugreifen; ein Custodian nur auf seine eigenen Zuweisungen
  4. PiiFilterMiddleware – entfernt PII-Felder des Antragstellers aus JSON-Antworten für jeden Aufrufer, der nicht über die Berechtigung zur Anzeige von Antragsteller-PII verfügt

Alle API-Schreibendpunkte setzen Berechtigungen serverseitig auf Controller-Ebene durch. Die Neuklassifizierung von Dokumenten ist geltungsbereichsabhängig – der Benutzer, der ein Dokument gesammelt hat, kann es neu klassifizieren –, und sobald ein Antrag geschlossen ist, geben Mutationen an seinem Objektgraphen HTTP 409 zurück, mit einer kleinen Anzahl bewusster Ausnahmen (Korrespondenz nach Abschluss, Aufbewahrungslöschung und Wiedereröffnung). Standardrollenzuweisungen sind geltungsbereichsbezogen (global, Antrag, Zuweisung oder Aufgabe), optional zeitlich befristet, und Beziehungsrollen werden niemals als Standardzuweisungen geschrieben – sie werden pro Ziel aus den zugrunde liegenden Arbeitsdatensätzen abgeleitet. Der erste Benutzer, der auf das System zugreift, wird mit der Rolle Administrator initialisiert, und ein serverseitiger Schutz verhindert das Entfernen des letzten aktiven Administrators.

Datenresidenz und Souveränität

Alle Daten verbleiben im Azure-Mandanten des Kunden in der bei der Bereitstellung ausgewählten Region. Es werden keine Daten in andere Regionen übertragen oder dort gespeichert, es sei denn, der Kunde konfiguriert explizit die Azure-Geo-Replikation.

Kanadische Bundesbehörden: Für GC-spezifische Datenresidenzanforderungen, ITSG-33-Kontroll-Mapping und GC Cloud Guardrails-Compliance siehe die GC-Sicherheitskontrollen-Referenz.

Kundendatenstandorte

Datentyp Speicherort Kontrolliert von
Antragsdatensätze, Benutzerdaten, Audit-Trail Azure SQL Database Azure-Abonnement des Kunden
Hochgeladene Dokumente Azure Blob Storage Azure-Abonnement des Kunden
Anwendungstelemetrie Application Insights / Log Analytics Azure-Abonnement des Kunden
SPFx-Webpart-Assets SharePoint CDN M365-Mandant des Kunden
API-URL-Override (optional) SharePoint-Mandanten-Speicherentität M365-Mandant des Kunden (primäre Ermittlung erfolgt über den API-Ermittlungsendpunkt des Herausgebers)
KI-Suchindizes, Zusammenfassungen, OCR-Ausgabe (Opt-in) Azure AI Search / Azure SQL Azure-Abonnement des Kunden

Was Mandantengrenzen überschreitet

Datenfluss Richtung Was übertragen wird Zweck
Lizenzvalidierung API → Herausgeber-Plattform Entra-Token der verwalteten Identität (der tid-Anspruch des Tokens identifiziert den Mandanten), API-Version und die eigene Basis-URL der API (Selbstregistrierung für die Web-Part-Ermittlung) Aktives Abonnement validieren; die Antwort enthält zudem die zuletzt veröffentlichte AccessPoint-Version, damit die Einrichtung einen Hinweis „Update verfügbar" anzeigen kann (nur Versionsnummern — keine Nutzungs- oder Falldaten)
API-URL-Ermittlung SPFx → Herausgeber-Plattform Bearer-Token (nur Mandanten-ID-Anspruch) Die Basis-URL der Kunden-API auflösen, wenn kein Speicherentitäts-Override gesetzt ist
E-Mail-Benachrichtigungen API → Microsoft Graph E-Mail-Inhalt über Mail.Send Benachrichtigungen aus freigegebenem Postfach senden
Teams-Benachrichtigungen (optional — umschaltbar / eliminierbar) API → Herausgeber-Plattform → Microsoft Graph Aktivitätstyp, Empfänger- + Mandanten-GUIDs, Benachrichtigungstitel/-vorschautext, Name der handelnden Person, Antragsnummer, Datensatz-ID (Deep Link) Sendet Teams-Aktivitätsfeed-Benachrichtigungen (weitergeleitet über die mandantenübergreifende Unternehmensanwendung des Herausgebers, da sendActivityNotification von der App aufgerufen werden muss, die das Teams-Manifest besitzt). Dies ist der einzige Benachrichtigungskanal, der den Mandanten verlässt — E-Mail und der In-App-Feed liefern dieselben Hinweise mandantenintern. Siehe Teams-Datenfreigabe für Benachrichtigungen
Benutzerprofilsuche SPFx → Microsoft Graph Benutzersuchanfragen Personenauswahl, Benutzerauflösung

Was den Mandanten niemals verlässt

  • Antragsdatensätze und PII des Antragstellers
  • Hochgeladene Dokumente
  • Audit-Verlauf
  • Konfigurationsdaten (Antragstypen, Vorlagen, Nummerierung)
  • Rollenzuweisungen
  • AI Assist-Prompts und -Antworten — wenn AI Assist bereitgestellt ist, läuft die Azure-OpenAI-Ressource im eigenen Abonnement und in der eigenen Region des Kunden; Microsoft trainiert keine Modelle mit den Inhalten, und Prompt-/Antwortinhalte werden nicht gespeichert (nur Nutzungsmetadaten, für die Budgetanzeige und die KI-Beteiligungsoffenlegung des Fall-Audit-Exports)
  • In-App- und E-Mail-/Outlook-Benachrichtigungen — der In-App-Feed wird von der eigenen API des Kunden bereitgestellt; E-Mails werden aus dem eigenen freigegebenen Postfach des Kunden über Mail.Send gesendet. Keines von beiden durchläuft den Herausgeber. Nur der optionale Teams-Aktivitätsfeed sendet Daten außerhalb des Mandanten, und selbst das kann minimiert oder eliminiert werden (siehe unten)

Teams-Datenfreigabe für Benachrichtigungen (optional)

Im Einklang mit dem Versprechen der Datensouveränität gilt: Die einzigen Mandantendaten, die für Benachrichtigungen die Grenze verlassen, sind eine optionale Teams-Aktivitätsnutzlast — und diese kann minimiert oder vollständig entfernt werden. Jede Benachrichtigung wird auf bis zu drei Kanälen zugestellt; zwei davon sind immer mandantenintern (der In-App-Feed, bereitgestellt von der API des Kunden, und E-Mail/Outlook, gesendet aus dem eigenen freigegebenen Postfach des Kunden). Der Teams-Aktivitätsfeed ist eine Annehmlichkeit: In seinem Standardmodus sendet die Kunden-API eine kleine Nutzlast per POST an die mandantenübergreifende App des Herausgebers, die Graph sendActivityNotification aufruft (was von der App aufgerufen werden muss, die das Teams-Manifest besitzt). Der Herausgeber speichert nichts davon und protokolliert nur die Empfänger- + Mandanten-GUIDs.

Felder in der standardmäßigen (über den Herausgeber weitergeleiteten) Teams-Nutzlast — und was der Umschalter Minimieren entfernt:

Feld Enthält Personenbezogene Daten? Durch Minimieren entfernt?
tenantId / recipientUserId Mandanten- + Empfänger-Entra-GUIDs Nein — Kennungen Nein (Routing)
activityType Feste Manifest-Aufzählung (z. B. assignmentCreated) Nein Nein
previewText / topicText Vorschau + Titel (Name der Zuweisung/Aufgabe, Benachrichtigungstext) Möglicherweise (Freitext) Ja → Platzhalter
actorName Anzeigename der handelnden Mitarbeiterin/des handelnden Mitarbeiters Ja — Personenname Ja → „AccessPoint"
requestNumber Antrags-Referenzcode Nein — Referenz Nein (Kontext)
relatedEntity + relatedRecordId Datensatztyp + GUID (Deep Link) Nein — Kennungen Nein (Deep Link)

PII des Antragstellers ist niemals in der Nutzlast enthalten — es gibt kein Feld für Name/E-Mail des Antragstellers, und Custodian-/Contributor-Benachrichtigungen sind ohnehin vorgelagert PII-bereinigt. Zwei Steuerelemente schränken dies weiter ein:

  • Minimieren (Notifications:TeamsMinimalPayload, ein Mandantenumschalter) ersetzt previewText, topicText und actorName durch neutrale Platzhalter, sodass Namen, Titel und Freitext den Mandanten niemals verlassen — nur Routing-/Deep-Link-Kennungen tun dies. Keine Manifeständerung erforderlich.
  • Eliminieren (Notifications:TeamsRelayMode=Direct) lässt die Kunden-API Graph sendActivityNotification selbst mit ihrer verwalteten Identität aufrufen, sodass überhaupt keine Nutzlast den Herausgeber erreicht. Dies erfordert die App-Rolle TeamsActivity.Send auf der verwalteten Identität der API und die auf die eigene App des Kunden ausgerichtete webApplicationInfo.id des Teams-Manifests — siehe das Bereitstellungshandbuch.
Modus Nutzlast an den Herausgeber PII/Freitext verlässt den Mandanten Einrichtungsaufwand
Standardweiterleitung Ja (obige Felder) Namen/Titel, sofern nicht minimiert Keiner
Umschalter „Minimieren" Ja (nur Kennungen) Keine Ein Umschalter
Direkte (selbst gehostete) Weiterleitung Keine Keine MI-Erteilung + Manifestbearbeitung
Teams deaktiviert Keine Keine (nur E-Mail + In-App) Keiner

Verschlüsselung

Bei der Übertragung

Verbindung Protokoll Mindest-TLS
Browser → App Service HTTPS (erzwungen, httpsOnly: true) TLS 1.3
SPFx → App Service HTTPS (durch SharePoint-Kontext erzwungen) TLS 1.3
App Service → Azure SQL TDS mit Verschlüsselung (Encrypt=True) TLS 1.2+
App Service → Blob Storage HTTPS (verwaltete Identität) TLS 1.2+
App Service → Microsoft Graph HTTPS TLS 1.2+

Der App Service erzwingt TLS 1.3 als Minimum am Eingangspunkt (TLS 1.0/1.1/1.2 abgelehnt); ausgehende Verbindungen zu Azure-Backend-Diensten handeln TLS 1.2 oder höher aus.

Im Ruhezustand

Datenspeicher Verschlüsselung Schlüsselverwaltung
Azure SQL Database Transparent Data Encryption (TDE) Von Microsoft verwaltete Schlüssel (Standard) oder kundenverwaltete Schlüssel (CMK)
Azure Blob Storage Storage Service Encryption (SSE), AES-256 Von Microsoft verwaltete Schlüssel (Standard) oder kundenverwaltete Schlüssel (CMK)
Application Insights Plattformverschlüsselung Von Microsoft verwaltete Schlüssel

Auf Anwendungsebene

Funktion Mechanismus
Dokumentviewer-Token ASP.NET Core Data Protection (Token im WOPI-Stil, 15-Minuten-TTL, Mandanten-Gegenprüfung bei jedem anonymen Viewer-Aufruf)
Attestierungs-E-Signaturen SHA-256-Hash von Unterzeichner und Zeitstempel, gespeichert in Audit-Feldern

Privacy by Design

AccessPoint implementiert strukturelle Datenschutzkontrollen, die auf der API-Ebene und nicht nur in der Benutzeroberfläche durchgesetzt werden.

PII-Filter-Middleware

Eine Middleware auf Antwortebene fängt alle JSON-Antworten ab und entfernt serverseitig PII-Felder für jeden Aufrufer, der nicht über die Berechtigung zur Anzeige von Antragsteller-PII verfügt (Custodians, Contributors, Reader und Reviewer sowie Advisors verfügen niemals darüber), unabhängig davon, was der Client anfordert. Entfernte Felder: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, zuzüglich Felder zur Identität/den Kontaktdaten von Vertretern sowie Notizen zur Identitätsverifizierung.

PII-Ausblendung in Benachrichtigungen

Wenn Benachrichtigungen an Custodians oder Contributors gesendet werden, werden PII des Antragstellers im Benachrichtigungsinhalt selbst durch Platzhaltertext ersetzt – selbst wenn die Benachrichtigungsvorlage PII-Zusammenführungsfelder enthält.

Isolation von Custodian / Contributor

  • Custodians sehen nur ihre zugewiesenen Anträge und arbeiten mit bereinigten Anweisungen
  • Contributors sehen nur ihre zugewiesenen Aufgaben
  • Keine der beiden Rollen kann Anträge außerhalb ihres Geltungsbereichs suchen, durchsuchen oder darauf zugreifen

Protokollierung, Überwachung und Audit

Application Insights

Sämtliche API-Telemetrie wird an die Application Insights-Instanz des Kunden gesendet:

Signal Was erfasst wird
Anfragetraces HTTP-Methode, Pfad, Statuscode, Dauer, Korrelations-ID
Abhängigkeitsverfolgung SQL-Abfragen, Blob-Operationen, Graph-API-Aufrufe (Dauer, Erfolg/Fehler)
Ausnahmen Nicht behandelte Ausnahmen mit Stacktraces
Benutzerdefinierte Metriken Antragsverarbeitungszeiten, Dokumentkonvertierungsdauern

Audit-Trail

AccessPoint führt einen umfassenden Audit-Trail in der Tabelle AuditHistory (Azure SQL), der den Entitätstyp, die Entitäts-ID, die Aktion (Create, Update, Delete, StatusChange), den Feldnamen, alte/neue Werte, einen optionalen Änderungsgrund (erfasst bei Statusübergängen wie Schließen und Wiedereröffnen), den authentifizierten Benutzer und einen UTC-Zeitstempel aufzeichnet. Audit-Datensätze sind unveränderlich – sie können über die API nicht geändert oder gelöscht werden.

Hash-verkettetes Audit-Ledger

Zusätzlich zum Audit-Trail auf Feldebene erfasst ein manipulationssicheres, ausschließlich anfügbares AuditLedger (SHA-256-Hash-Kette) Aktionen über alle Module hinweg. Die Integrität kann serverseitig überprüft werden, und für einen Antrag kann ein gerichtsfester Fall-Audit-Export (vormals „Beweispaket") erstellt werden.

Optimistische Nebenläufigkeit

Entitäten mit hoher Zugriffskonkurrenz (Requests, Documents, CustodianAssignments) tragen jeweils ein SQL Server-ROWVERSION-Nebenläufigkeits-Token. Der Client gibt die Zeilenversion beim Aktualisieren zurück; hat ein anderer Schreibvorgang die Zeile zwischenzeitlich geändert, wird das Speichern mit HTTP 409 („Gleichzeitige Bearbeitung erkannt") abgelehnt, anstatt stillschweigend zu überschreiben.

Aufbewahrungs-Löschprotokoll

Eine RetentionService-Engine entsorgt abgelaufene Datensätze über fünf Register — Anträge, Bewertungen, Vorfälle, Beschwerden und eigenständige Datenschutzrisiken — gesteuert durch ein typspezifisches Paar RetentionPeriodMonths + RetentionStartPoint (NULL = unbegrenzt aufbewahren, die Standardeinstellung). Datensätze, die nicht ablaufen dürfen, sind konstruktionsbedingt ausgeschlossen (eine Bewertung In Kraft, ein akzeptiertes Risiko, ein an einen Fall angehängtes Risiko), und ein abgelaufener Datensatz, von dem ein anderer offener Fall noch abhängt, wird serverseitig abgelehnt; die Eignung wird zum Zeitpunkt der Bereinigung neu bewertet. Wird ein Datensatz bereinigt, löscht die Engine zusätzlich zu den Datenbankdatensätzen auch Dokument-Blobs, konvertierte PDFs, Anmerkungen und Exportpakete aus Blob Storage. Das RetentionPurgeLog zeichnet auf, was, wann und von wem gelöscht wurde — EntityName identifiziert, aus welchem Register der Datensatz stammte, zusammen mit einer Momentaufnahme seiner Nummer, seines Typs, seines Abschlussdatums und seiner Dokumentenanzahl — ein revisionssicherer Nachweis, der die Datenlöschung überdauert und selbst nie bereinigt wird.

Log Analytics und Warnungen

Application Insights wird durch einen Log Analytics-Arbeitsbereich mit konfigurierbarer Aufbewahrung (standardmäßig 90 Tage; konfigurierbar 30–730 Tage) unterstützt. Daten können nach Microsoft Sentinel oder ein vorhandenes SIEM exportiert werden. Die Bicep-Bereitstellung enthält zwei standardmäßige Metrikwarnungen für den App Service:

Warnung Schweregrad Bedingung Zeitfenster
Serverfehler 2 (Warnung) HTTP-5xx-Anzahl > 5 5 Minuten
Hohe Latenz 3 (Informativ) Durchschnittliche Antwortzeit > 5 Sekunden 15 Minuten

Kunden können Schwellenwerte anpassen und im Azure-Portal Aktionsgruppen (E-Mail, SMS, Webhook) hinzufügen.

←
Previous Erste Schritte mit AccessPoint
Next GC-Sicherheitskontrollen-Referenz
→