Przegląd architektury technicznej dla zespołów IT oceniających AccessPoint

Last updated: July 12, 2026 by Steve

Architektura techniczna

Ten dokument zawiera techniczny przegląd platformy AccessPoint przeznaczony dla architektów rozwiązań, inżynierów cyberbezpieczeństwa i dyrektorów IT oceniających produkt dla swojej organizacji. Opracowano go na podstawie dokumentu AccessPoint Solution Architecture Guide (wersja 1.4.1).

Przegląd platformy

AccessPoint to platforma do zarządzania dostępem do informacji i ochroną prywatności zbudowana na Microsoft 365 i Azure. Powstała jako narzędzie do zarządzania wnioskami o dostęp do danych osobowych (subject access request, SAR), a z czasem rozwinęła się w zintegrowany pakiet biura ATIP/prywatności obejmujący pełny cykl życia wniosku oraz otaczający go program ochrony prywatności. Działa w całości w ramach własnej dzierżawy Microsoft 365 i Azure Twojej organizacji: nie istnieją żadne zewnętrzne serwery, bazy danych ani zależności od chmur stron trzecich w czasie działania, a wszystkie dane pozostają w Twoim środowisku, pod Twoją kontrolą.

Platforma jest zorganizowana w moduły, które współdzielą jeden wspólny szkielet tożsamości, RBAC, powiadomień, audytu i raportowania:

  • Wnioski o dostęp — przyjmowanie wniosków ATI/FOIA/GDPR, zlecanie zadań roli Custodian, przegląd i redakcja dokumentów, pakowanie odpowiedzi oraz raportowanie ustawowe
  • Oceny ochrony prywatności — konfigurowalny silnik ocen PIA/AIA/Security
  • Incydenty prywatności i naruszenia — przyjmowanie zgłoszeń, ograniczanie skutków, ocena ryzyka szkody oraz przepływy powiadomień o naruszeniach
  • Skargi i odwołania — cykl życia skargi obejmujący strony postępowania, ustawowe terminy oraz dochodzenie
  • Rejestr ryzyka w zakresie prywatności — ryzyka w stylu ISO 31000, plany postępowania z ryzykiem oraz kluczowe wskaźniki ryzyka
  • Rejestry czynności przetwarzania (ROPA) — rejestry zgodne z GDPR Article 30 oraz eksport rejestru
  • Rejestr zobowiązań — śledzone zobowiązania w zakresie prywatności wraz z częstotliwością i punktami kontrolnymi

Wszystkie moduły są sterowane pakietami konfiguracyjnymi, bez statycznych danych początkowych.

Kluczowe cechy:

  • Natywna dla dzierżawy — wdrażana jako rozwiązanie SharePoint Framework (SPFx) oraz usługi Azure PaaS w ramach istniejącej dzierżawy
  • Brak zależności od Power Platform — nie wymaga licencji Dataverse, Power Automate ani Power Apps
  • Suwerenność danych — wszystkie dane znajdują się w skonfigurowanej geografii Twojej dzierżawy Azure
  • Brak dostępu wydawcy w czasie działania — wydawca nie może uzyskać dostępu do Twoich danych podczas normalnej eksploatacji
  • Licencjonowanie ryczałtowe — licencjonowanie departamentowe bez pomiaru według liczby użytkowników
  • Prywatność od podstaw (privacy by design) — role Custodian i Contributor są strukturalnie odizolowane od danych osobowych wnioskodawcy i osoby, której dane dotyczą
  • Konfiguracja zamiast kodu — typy wniosków, kody wyłączeń i pola wyboru są sterowane danymi
  • Wielojęzyczność od podstaw — trzypoziomowy system tłumaczeń obsługujący 11 języków

Diagram architektury

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)
        └──────────────────────┘

Inwentarz komponentów

Komponent Technologia Wdrażany do Przeznaczenie
Składnik web SPFx TypeScript, React 17, Fluent UI 8, SPFx 1.22.1 SharePoint Online / Teams klienta Interfejs użytkownika dla wszystkich ról
Aplikacja Teams Manifest Teams w wersji 1.19, wersja aplikacji 1.0.0 Teams Admin Center klienta Aplikacja osobista, konfigurowalna karta, powiadomienia w kanale aktywności z głębokimi linkami
Web API C# / ASP.NET Core 10, .NET 10 (~87 kontrolerów, ~88 usług) Azure App Service (Linux) klienta Logika biznesowa, dostęp do danych, przetwarzanie dokumentów
Baza danych SQL Server (DacPac) Azure SQL Database klienta Relacyjne przechowywanie danych (~186 tabel, ~2900 pól)
Blob Storage Azure Blob Storage Konto Azure Storage klienta Przechowywanie plików dokumentów
Monitorowanie Application Insights + Log Analytics Subskrypcja Azure klienta Telemetria, diagnostyka, alerty
AI Search (opcjonalnie) Azure AI Search Subskrypcja Azure klienta Pełnotekstowe wyszukiwanie treści dokumentów; provisionowane wyłącznie, gdy deployAiSearch=true

Co obsługuje wydawca

Usługa Przeznaczenie
Realizer Platform Wydawanie i walidacja kluczy licencyjnych (żadne dane klientów nie są przesyłane)
AppSource Listing Dystrybucja pakietu SPFx
Azure Marketplace Listing Szablon wdrożenia infrastruktury Azure
Teams App Package Dystrybucja manifestu Teams (ładowanie boczne lub sklep aplikacji organizacji)

Żadne dane klientów nie są przesyłane do ani przechowywane przez żadną usługę obsługiwaną przez wydawcę.

Moduły funkcjonalne

Wszystkie moduły działają wewnątrz jednego Web API / składnika web SPFx i współdzielą jeden wspólny szkielet tożsamości, RBAC, komentarzy, powiadomień, Mojego dnia, audytu, godzin, przepływu przeglądu i raportowania. Każdy z nich jest sterowany danymi za pomocą pakietów konfiguracyjnych.

Moduł Podsumowanie
Wnioski (ATIP/SAR) Przyjęcie wniosku → zlecenie zadań roli Custodian → zbieranie dokumentów → odpowiedź. Konfigurowalne typy, statusy, numeracja, kalendarze i SLA.
Dokumenty i redakcja Fasetowy obszar roboczy dokumentów: tagi, rodziny e-maili, śledzenie odczytu, zapisane widoki, podgląd Syncfusion, potok redakcji z wyłączeniami i wymianą XFDF, pakowanie odpowiedzi.
Wnioskodawcy / Kontakty W pełni zintegrowana, wielokrotnego użytku tożsamość wnioskodawcy, kontrola przepływu przyjęcia, opłaty i weryfikacja, scalanie; konsultacje; kreator korespondencji z zaporą chroniącą dane osobowe.
Oceny ochrony prywatności Konfigurowalny silnik PIA/AIA/Security: szablony, kwestionariusze przesiewowe, delegowanie sekcji, punktacja/poziomowanie, rejestr ryzyka, podsumowania zamknięcia/dla regulatora.
Incydenty prywatności / Naruszenia Przyjmowanie zgłoszeń incydentów, ograniczanie skutków, ocena ryzyka szkody, reguły powiadamiania o naruszeniach według reżimu prawnego, działania naprawcze.
Skargi i odwołania Cykl życia skargi: strony postępowania, ustawowe terminy, dopuszczalność, dochodzenie, przegląd stanowisk stron.
Ryzyko i zobowiązania Rejestr ryzyka zgodny z ISO 31000 z apetytem na ryzyko, KRI i zadaniami postępowania z ryzykiem; rejestr zobowiązań z częstotliwością i punktami kontrolnymi.
ROPA / Podmioty danych Wielokrotnego użytku programy/systemy z rejestrami zgodnymi z GDPR Article 30 oraz eksportem rejestru.
Przeglądy Konfigurowalny silnik przeglądu i zatwierdzania sekwencyjnego/równoległego, wykorzystywany we wszystkich encjach spraw.
Raportowanie i audyt Gotowe raporty, kreator raportów niestandardowych, statystyczne raporty roczne, pulpity SLA/zarządcze, rejestr audytowy zabezpieczony łańcuchem skrótów oraz pakiety dowodowe gotowe do postępowania sądowego.
Konfiguracja i platforma Import pakietów konfiguracyjnych, ustawienia dzierżawy, niestandardowe role/uprawnienia, przełączniki funkcji, pola niestandardowe, tabele tłumaczeń dla 11 języków.

Model wdrożenia

AccessPoint wykorzystuje podzielony model wdrożenia. Składnik web SPFx jest instalowany z Microsoft AppSource (lub z App Catalog dzierżawy), pakiet aplikacji Teams jest instalowany przez ładowanie boczne lub sklep aplikacji organizacji, a backend Azure jest wdrażany do własnej subskrypcji klienta jedną z dwóch metod:

  • Portal Azure (zalecane) — wdrożenie wszystkich zasobów Azure (App Service, SQL, Blob Storage, Application Insights) jednym kliknięciem za pomocą ARM/Bicep. API jest wdrażane metodą zipdeploy podczas wdrożenia ARM; kod jest pobierany jednorazowo z CDN wydawcy i przechowywany w App Service klienta, bez zależności zewnętrznej w czasie działania. Klient zachowuje pełną własność grupy zasobów.
  • Szablon Bicep + skrypt PowerShell (ręczne) — dla organizacji o ścisłej kontroli zmian. Przycisk Deploy to Azure lub skrypt Deploy-AccessPoint.ps1 wdraża infrastrukturę, konfiguruje uwierzytelnianie SQL wyłącznie przez Entra, przyznaje tożsamości zarządzanej uprawnienia Microsoft Graph, konfiguruje encje magazynu dzierżawy SharePoint oraz zatwierdza żądania uprawnień API SPFx. Każdy krok można pominąć niezależnie.

Wdrożenie jest domyślnie zabezpieczone (security-hardened): TLS 1.3, FTPS wyłączone, podstawowe uwierzytelnianie SCM/FTP wyłączone oraz włączone HTTP/2. API dołącza swój DacPac bazy danych i stosuje go przy starcie za pomocą usługi migracji korzystającej z DacServices.Deploy(upgradeExisting: true) — operacja ta nie robi nic, jeśli schemat jest już aktualny, a po zmianie schematu stosuje addytywną, nieniszczącą deltę (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). Wynik migracji jest udostępniany przez /api/health. Po wdrożeniu administrator udziela zgody dla aplikacji enterprise Realizer (powiadomienia Teams), konfiguruje skrzynkę nadawcy oraz importuje pakiet konfiguracyjny właściwy dla danej jurysdykcji.

Uwierzytelnianie i tożsamość

AccessPoint używa Microsoft Entra ID jako jedynego dostawcy tożsamości. Nie istnieją konta użytkowników ani hasła specyficzne dla aplikacji. Składnik web SPFx pozyskuje token JWT dla odbiorcy (audience) API za pomocą AadHttpClient; API waliduje wystawcę, odbiorcę, podpis i termin ważności przy każdym żądaniu. Polityki MFA i Conditional Access skonfigurowane w dzierżawie mają pełne zastosowanie.

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 ───────┼──────────────────────────│
Parametr Wartość
Dostawca tożsamości Microsoft Entra ID (Azure AD)
Protokół OAuth 2.0 / OpenID Connect
Typ tokenu JWT Bearer
Audience (odbiorca) api://<client-id> oraz <client-id> (akceptowane są zarówno tokeny v1, jak i v2)
Issuer (wystawca) https://login.microsoftonline.com/{tenantId}/v2.0 oraz https://sts.windows.net/{tenantId}/
Rejestracja aplikacji Jednodzierżawcowa (AzureADMyOrg); eksponowany zakres access_as_user; brak tajnego klucza klienta

Tożsamość zarządzana

App Service używa tożsamości zarządzanej przypisanej przez system, aby uwierzytelniać się wobec usług backendowych, dzięki czemu w aplikacji nie są przechowywane żadne tajne klucze klienta ani certyfikaty:

  • Azure SQL Database — uwierzytelnianie wyłącznie przez Entra (uwierzytelnianie hasłem SQL jest wyłączone)
  • Azure Blob Storage — DefaultAzureCredential (tożsamość zarządzana w środowisku produkcyjnym)
  • Microsoft Graph API — ManagedIdentityCredential z uprawnieniami aplikacji

Poświadczenia tożsamości zarządzanej są automatycznie rotowane przez Azure.

Autoryzacja i RBAC

AccessPoint implementuje kontrolę dostępu opartą na rolach (RBAC) na poziomie aplikacji, przechowywaną w Azure SQL i egzekwowaną na warstwie API przy każdym żądaniu.

Rola Widzi dane osobowe wnioskodawcy Zarządza wnioskami Zarządza przydziałami Przesyła dokumenty Typowy użytkownik
Administrator Tak Tylko konfiguracja Nie Nie Administrator IT, właściciel systemu
SAO Tak Tak Tak Nie Urzędnik ds. dostępu i prywatności
Reviewer Tak Tylko odczyt Tylko odczyt Nie Radca prawny, QA
Custodian Nie Nie Własne przydziały Nie Pracownik departamentu ds. dokumentacji
Contributor Nie Nie Nie Własne zadania Ekspert merytoryczny
Reader Nie Tylko odczyt Tylko odczyt Nie Nadzór, audyt

Punkty egzekwowania:

  1. Zasady autoryzacji API — atrybuty ASP.NET Core [Authorize(Policy = "...")] na każdej akcji kontrolera
  2. RoleAuthorizationHandler — sprawdza tabelę UserRoles pod kątem przynależności uwierzytelnionego użytkownika do ról
  3. ResourceOwnerAuthorizationHandler — waliduje własność na poziomie zasobu (np. użytkownik z rolą Contributor może uzyskać dostęp wyłącznie do własnych zadań)
  4. PiiFilterMiddleware — usuwa pola danych osobowych wnioskodawcy z odpowiedzi JSON dla ról o ograniczonym dostępie (Custodian, Contributor, Reader)

Wszystkie punkty końcowe API do zapisu egzekwują role po stronie serwera na poziomie kontrolera. Przeklasyfikowanie dokumentu uwzględnia zakres — przeklasyfikować dokument może wyłącznie użytkownik, który go zebrał — a po zamknięciu wniosku modyfikacje jego grafu obiektów zwracają HTTP 409, z niewielkim zestawem celowych wyjątków (korespondencja po zamknięciu, trwałe usunięcie zgodnie z retencją oraz ponowne otwarcie). Role mają określony zakres i mogą być ograniczone do konkretnych zasobów (zakres globalny, wniosku, przydziału lub zadania). Pierwszy użytkownik, który uzyska dostęp do systemu, automatycznie otrzymuje zarówno rolę Administrator, jak i SAO.

Rezydencja i suwerenność danych

Wszystkie dane znajdują się w dzierżawie Azure klienta, w regionie wybranym podczas wdrożenia. Żadne dane nie są przesyłane do innych regionów ani w nich przechowywane, chyba że klient jawnie skonfiguruje replikację geograficzną Azure.

Kanadyjskie departamenty federalne: wymagania GC dotyczące rezydencji danych, mapowanie kontroli ITSG-33 oraz zgodność z GC Cloud Guardrails znajdziesz w dokumencie Referencja kontroli bezpieczeństwa GC.

Lokalizacje danych klienta

Typ danych Lokalizacja przechowywania Kontrolowane przez
Rekordy wniosków, dane użytkowników, ślad audytu Azure SQL Database Subskrypcja Azure klienta
Przesłane dokumenty Azure Blob Storage Subskrypcja Azure klienta
Telemetria aplikacji Application Insights / Log Analytics Subskrypcja Azure klienta
Zasoby składnika web SPFx SharePoint CDN Dzierżawa M365 klienta
Konfiguracja dzierżawy (URL API, Client ID) SharePoint Tenant Storage Entities Dzierżawa M365 klienta

Co przekracza granice dzierżawy

Przepływ danych Kierunek Co jest przesyłane Przeznaczenie
Walidacja licencji API → Publisher Platform Klucz licencyjny (nieprzejrzysty ciąg znaków), identyfikator dzierżawy Walidacja aktywnej subskrypcji
Powiadomienia e-mail API → Microsoft Graph Treść e-maila przez Mail.Send Wysyłanie powiadomień ze współdzielonej skrzynki pocztowej
Powiadomienia Teams API → Publisher Platform → Microsoft Graph Typ aktywności, tekst podglądu, identyfikator odbiorcy, parametry szablonu Wysyłanie powiadomień w kanale aktywności Teams (przekazywane przez wielodzierżawcową aplikację enterprise wydawcy, ponieważ sendActivityNotification musi być wywoływane przez aplikację będącą właścicielem manifestu Teams)
Wyszukiwanie profilu użytkownika SPFx → Microsoft Graph Zapytania wyszukiwania użytkowników Selektor osób, rozwiązywanie użytkowników

Co nigdy nie opuszcza dzierżawy

  • Rekordy wniosków i dane osobowe wnioskodawcy
  • Przesłane dokumenty
  • Historia audytu
  • Dane konfiguracyjne (typy wniosków, szablony, numeracja)
  • Przypisania ról

Szyfrowanie

W transmisji

Połączenie Protokół Minimalny TLS
Przeglądarka → App Service HTTPS (egzekwowane, httpsOnly: true) TLS 1.3
SPFx → App Service HTTPS (egzekwowane przez kontekst SharePoint) TLS 1.3
App Service → Azure SQL TDS z szyfrowaniem (Encrypt=True) TLS 1.2+
App Service → Blob Storage HTTPS (tożsamość zarządzana) TLS 1.2+
App Service → Microsoft Graph HTTPS TLS 1.2+

App Service egzekwuje TLS 1.3 jako minimum na front doorze (połączenia TLS 1.0/1.1/1.2 są odrzucane); połączenia wychodzące do usług backendowych Azure negocjują TLS 1.2 lub wyższy.

W spoczynku

Magazyn danych Szyfrowanie Zarządzanie kluczami
Azure SQL Database Transparent Data Encryption (TDE) Klucze zarządzane przez Microsoft (domyślnie) lub klucze zarządzane przez klienta (CMK)
Azure Blob Storage Storage Service Encryption (SSE), AES-256 Klucze zarządzane przez Microsoft (domyślnie) lub klucze zarządzane przez klienta (CMK)
Application Insights Szyfrowanie platformy Klucze zarządzane przez Microsoft

Na poziomie aplikacji

Funkcja Mechanizm
Tokeny przeglądarki dokumentów ASP.NET Core Data Protection (token w stylu WOPI, czas życia (TTL) 15 minut, krzyżowa weryfikacja dzierżawy przy każdym anonimowym wywołaniu przeglądarki)
Podpisy elektroniczne atestacji Skrót SHA-256 sygnatariusza i znacznika czasu przechowywany w polach audytu

Prywatność od podstaw

AccessPoint implementuje strukturalne kontrole prywatności egzekwowane na warstwie API, a nie tylko w interfejsie użytkownika.

Oprogramowanie pośredniczące filtrujące dane osobowe

Oprogramowanie pośredniczące działające na poziomie odpowiedzi przechwytuje wszystkie odpowiedzi JSON i usuwa pola danych osobowych dla użytkowników z rolami o ograniczonym dostępie (Custodian, Contributor, Reader) — po stronie serwera, niezależnie od tego, o co żąda klient. Usuwane pola: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

Maskowanie danych osobowych w powiadomieniach

Gdy powiadomienia są wysyłane do użytkowników z rolą Custodian lub Contributor, dane osobowe wnioskodawcy są zastępowane tekstem zastępczym bezpośrednio w treści powiadomienia — nawet jeśli szablon powiadomienia zawiera pola scalania danych osobowych.

Izolacja ról Custodian / Contributor

  • Użytkownicy z rolą Custodian widzą wyłącznie przydzielone im wnioski i pracują na podstawie zanonimizowanych instrukcji
  • Użytkownicy z rolą Contributor widzą wyłącznie przydzielone im zadania
  • Żadna z tych ról nie może wyszukiwać, przeglądać ani uzyskiwać dostępu do wniosków spoza swojego zakresu

Logowanie, monitorowanie i audyt

Application Insights

Cała telemetria API jest wysyłana do instancji Application Insights klienta:

Sygnał Co jest rejestrowane
Ślady żądań Metoda HTTP, ścieżka, kod statusu, czas trwania, identyfikator korelacji
Śledzenie zależności Zapytania SQL, operacje Blob, wywołania Graph API (czas trwania, sukces/niepowodzenie)
Wyjątki Nieobsłużone wyjątki wraz ze śladami stosu
Metryki niestandardowe Czasy przetwarzania wniosków, czasy konwersji dokumentów

Ślad audytu

AccessPoint utrzymuje kompleksowy ślad audytu w tabeli AuditHistory (Azure SQL), rejestrując typ encji, identyfikator encji, akcję (Create, Update, Delete, StatusChange), nazwę pola, stare/nowe wartości, opcjonalny powód zmiany (rejestrowany przy przejściach statusu, takich jak zamknięcie i ponowne otwarcie), uwierzytelnionego użytkownika oraz znacznik czasu UTC. Rekordy audytu są niezmienne — nie mogą być modyfikowane ani usuwane przez API.

Rejestr audytowy zabezpieczony łańcuchem skrótów

Oprócz śladu audytu na poziomie pól, wykrywający próby manipulacji, wyłącznie dopisywalny rejestr AuditLedger (łańcuch skrótów SHA-256) rejestruje działania we wszystkich modułach. Integralność można zweryfikować po stronie serwera, a dla danego wniosku można wyeksportować pakiet dowodowy gotowy do postępowania sądowego.

Współbieżność optymistyczna

Encje o wysokiej współbieżności dostępu (Requests, Documents, CustodianAssignments) posiadają token współbieżności SQL Server ROWVERSION. Klient przekazuje z powrotem wersję wiersza przy aktualizacji; jeśli w międzyczasie inny proces zapisujący zmienił wiersz, zapis jest odrzucany z kodem HTTP 409 („Concurrent edit detected” — wykryto równoczesną edycję) zamiast być po cichu nadpisany.

Dziennik trwałego usuwania zgodnie z retencją

Gdy rekordy są trwale usuwane zgodnie z polityką retencji, operacja usuwania kasuje obiekty blob dokumentów, skonwertowane pliki PDF, adnotacje i pakiety eksportu z Blob Storage, oprócz rekordów bazy danych. Tabela RetentionPurgeLog rejestruje, co zostało usunięte, kiedy i przez kogo — ślad klasy zgodności, który przetrwa usunięcie danych.

Log Analytics i alerty

Application Insights jest wspierane przez obszar roboczy Log Analytics z konfigurowalnym okresem przechowywania (domyślnie 90 dni; konfigurowalny w zakresie 30–730 dni). Dane można eksportować do Microsoft Sentinel lub istniejącego systemu SIEM. Wdrożenie Bicep zawiera dwa domyślne alerty metryczne na App Service:

Alert Ważność Warunek Okno
Błędy serwera 2 (Ostrzeżenie) Liczba błędów HTTP 5xx > 5 5 minut
Wysokie opóźnienie 3 (Informacyjny) Średni czas odpowiedzi > 5 sekund 15 minut

Klienci mogą dostosować progi i dodać grupy akcji (e-mail, SMS, webhook) w portalu Azure.

←
Previous Pierwsze kroki z AccessPoint
Next Referencja kontroli bezpieczeństwa GC
→