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

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

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

Alle Module werden durch Konfigurationspakete 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 + 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)
        └──────────────────────┘

Komponenteninventar

Komponente Technologie Bereitgestellt in Zweck
SPFx Web Part TypeScript, React 17, Fluent UI 8, SPFx 1.22.1 SharePoint Online / Teams des Kunden Benutzeroberfläche für alle Rollen
Teams App Teams-Manifest v1.19, App-Version 1.0.0 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 (~87 Controller, ~88 Services) Azure App Service (Linux) des Kunden Geschäftslogik, Datenzugriff, Dokumentverarbeitung
Datenbank SQL Server (DacPac) Azure SQL Database des Kunden Relationaler Datenspeicher (~186 Tabellen, ~2.900 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; nur bereitgestellt, wenn deployAiSearch=true

Was der Herausgeber betreibt

Dienst Zweck
Realizer Platform Ausstellung und Validierung von Lizenzschlüsseln (keine Kundendaten übertragen)
AppSource Listing Verteilung des SPFx-Pakets
Azure Marketplace Listing Bereitstellungsvorlage für die Azure-Infrastruktur
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 Konfigurationspakete 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, E-Mail-Familien, Leseverfolgung, gespeicherte Ansichten, Syncfusion-Vorschau, Schwärzungspipeline mit Ausnahmen und XFDF-Roundtrip, Antwortzusammenstellung.
Antragsteller / Kontakte Vollwertige, wiederverwendbare Antragsteller-Identität, Steuerung des Erfassungsablaufs, Gebühren & Verifizierung, Zusammenführung; Konsultationen; Korrespondenz-Editor mit PII-Firewall.
Datenschutzbewertungen Konfigurierbare PIA-/AIA-/Sicherheits-Engine: Vorlagen, Vorprüfungen, Abschnittsdelegation, 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 / Datenschutzsubjekte 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, benutzerdefinierter Report-Builder, statistische Jahresberichte, SLA-/Management-Dashboards, hash-verkettetes Audit-Ledger und gerichtsverwertbare Beweispakete.
Konfiguration & Plattform Import von Konfigurationspaketen, 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) ü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. 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, konfiguriert die ausschließlich Entra-basierte SQL-Authentifizierung, gewährt der verwalteten Identität Microsoft Graph-Berechtigungen, konfiguriert die SharePoint-Mandanten-Speicherentitäten und genehmigt SPFx-API-Berechtigungsanforderungen. Jeder Schritt kann unabhängig übersprungen werden.

Die Bereitstellung ist standardmäßig sicherheitsgehärtet: TLS 1.3, FTPS deaktiviert, SCM/FTP-Basisauthentifizierung deaktiviert und HTTP/2 aktiviert. 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 rechtsraumspezifisches Konfigurationspaket.

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. RoleAuthorization:   │
     │                              │     Check UserRoles table│
     │                              │                          │
     │     ◄── 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 https://login.microsoftonline.com/{tenantId}/v2.0 und https://sts.windows.net/{tenantId}/
App-Registrierung Einzelmandant (AzureADMyOrg); bereitgestellter Scope access_as_user; kein Client Secret

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 (SQL-Passwort-Authentifizierung ist deaktiviert)
  • Azure Blob Storage – DefaultAzureCredential (verwaltete Identität in der Produktion)
  • Microsoft Graph API – ManagedIdentityCredential mit Anwendungsberechtigungen

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

Autorisierung und RBAC

AccessPoint implementiert eine rollenbasierte Zugriffssteuerung auf Anwendungsebene, die in Azure SQL gespeichert und bei jeder Anfrage auf der API-Ebene durchgesetzt wird.

Rolle Sieht PII des Antragstellers Verwaltet Anträge Verwaltet Zuweisungen Reicht Dokumente ein Typischer Benutzer
Administrator Ja Nur Konfiguration Nein Nein IT-Administrator, Systemverantwortlicher
SAO Ja Ja Ja Nein Informationszugangs- und Datenschutzbeauftragter
Reviewer Ja Nur lesen Nur lesen Nein Rechtsberater, QS
Custodian Nein Nein Eigene Zuweisungen Nein Schriftgutverantwortlicher der Abteilung
Contributor Nein Nein Nein Eigene Aufgaben Fachexperte
Reader Nein Nur lesen Nur lesen Nein Aufsicht, Audit

Durchsetzungspunkte:

  1. API-Autorisierungsrichtlinien – ASP.NET Core-Attribute [Authorize(Policy = "...")] an jeder Controller-Aktion
  2. RoleAuthorizationHandler – prüft die UserRoles-Tabelle auf die Rollenmitgliedschaft des authentifizierten Benutzers
  3. ResourceOwnerAuthorizationHandler – validiert die Eigentümerschaft auf Ressourcenebene (z. B. kann ein Contributor nur auf seine eigenen Aufgaben zugreifen)
  4. PiiFilterMiddleware – entfernt PII-Felder des Antragstellers aus JSON-Antworten für eingeschränkte Rollen (Custodian, Contributor, Reader)

Alle API-Schreibendpunkte setzen Rollen 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). Rollen haben einen Geltungsbereich und können auf bestimmte Ressourcen beschränkt werden (globaler, Antrags-, Zuweisungs- oder Aufgabengeltungsbereich). Der erste Benutzer, der auf das System zugreift, wird mit den Rollen Administrator und SAO initialisiert.

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
Mandantenkonfiguration (API-URL, Client-ID) SharePoint-Mandanten-Speicherentitäten M365-Mandant des Kunden

Was Mandantengrenzen überschreitet

Datenfluss Richtung Was übertragen wird Zweck
Lizenzvalidierung API → Herausgeber-Plattform Lizenzschlüssel (opake Zeichenkette), Mandanten-ID Aktives Abonnement validieren
E-Mail-Benachrichtigungen API → Microsoft Graph E-Mail-Inhalt über Mail.Send Benachrichtigungen aus freigegebenem Postfach senden
Teams-Benachrichtigungen API → Herausgeber-Plattform → Microsoft Graph Aktivitätstyp, Vorschautext, Empfänger-ID, Vorlagenparameter Teams-Aktivitätsfeed-Benachrichtigungen senden (über die mandantenübergreifende Unternehmensanwendung des Herausgebers geleitet, da sendActivityNotification von der App aufgerufen werden muss, die das Teams-Manifest besitzt)
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

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 PII-Felder für Benutzer mit eingeschränkten Rollen (Custodian, Contributor, Reader) serverseitig, unabhängig davon, was der Client anfordert. Entfernte Felder: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

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 gerichtsverwertbares Beweispaket exportiert 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

Wenn Datensätze gemäß der Aufbewahrungsrichtlinie gelöscht werden, entfernt die Löschung zusätzlich zu den Datenbankdatensätzen auch Dokument-Blobs, konvertierte PDFs, Anmerkungen und Exportpakete aus Blob Storage. Die Tabelle RetentionPurgeLog zeichnet auf, was, wann und von wem gelöscht wurde – ein revisionssicherer Nachweis, der die Datenlöschung überdauert.

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
→