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

Last updated: August 09, 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 2.0.67).

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
  • AI Assist (opcjonalnie) — sugestie i przygotowywanie wersji roboczych oparte na Azure OpenAI, działające w całości we własnej subskrypcji klienta: podsumowania dokumentów, sugestie redakcji AI, ugruntowane przygotowywanie wersji roboczych, triage przyjęcia, wstępne wypełnianie odpowiedzi w ocenach, wyszukiwanie semantyczne i wykrywanie duplikatów, ugruntowany w przepisach asystent dla poszczególnych spraw (Ask AccessPoint — klikalne cytowania, zapisane rozmowy, tryb Mój portfel spraw), odpowiedzi na dane w ramach „Ask AccessPoint", podręcznik jurysdykcyjny ugruntowujący odpowiedzi proceduralne, automatyczne tłumaczenie oraz codzienny przegląd — wszystko opcjonalne dla poszczególnych dzierżawców, rejestrowane wyłącznie na poziomie metadanych, z ujawnieniem aktywności AI dla każdego rekordu

Wszystkie moduły są sterowane pakietami jurysdykcyjnymi, 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 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)

Inwentarz komponentów

Komponent Technologia Wdrażany do Przeznaczenie
Składnik web SPFx TypeScript, React 17, Fluent UI 8, SPFx 1.23.2 SharePoint Online / Teams klienta Interfejs użytkownika dla wszystkich ról
Aplikacja Teams Manifest Teams w wersji 1.19, wersja zgodna z rozwiązaniem SPFx i ApiVersion.Current (stemplowana przez CI) 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 (~103 kontrolerów, ~124 interfejsów 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 (221 tabel, 3410 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 oraz semantyczne wyszukiwanie wektorowe (indeks dokumentów i spraw); provisionowane wyłącznie, gdy deployAiSearch=true
Azure OpenAI (opcjonalnie) Azure OpenAI Service Subskrypcja Azure klienta AI Assist — ugruntowane przygotowywanie wersji roboczych, sugestie, wyszukiwanie semantyczne, asystent sprawy (Ask AccessPoint); uwierzytelnianie za pomocą tożsamości zarządzanej (bez kluczy API), provisionowane wyłącznie, gdy wdrożono AI Assist
Document Intelligence (opcjonalnie) Azure AI Document Intelligence (prebuilt-read) Subskrypcja Azure klienta OCR dla skanów obrazowych zasilający wyszukiwanie treści, wykrywanie duplikatów, podsumowania i sugestie redakcji; uwierzytelnianie tożsamością zarządzaną, provisionowane wyłącznie, gdy deployDocumentIntelligence=true

Co obsługuje wydawca

Usługa Przeznaczenie
Realizer Platform Walidacja licencji, przekazywanie (proxy) powiadomień Teams, wykrywanie adresu URL API dla SPFx, inteligentne przekierowanie karty osobistej Teams oraz strona Dokończ konfigurację uruchamiana po wdrożeniu (żadne dane spraw klienta nie są przesyłane)
AppSource Listing Dystrybucja pakietu SPFx
Szablon wdrożenia Szablon Bicep/ARM dla zaplecza Azure, wdrażany jednym kliknięciem z portalu Azure w subskrypcji klienta
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 jurysdykcyjnych.

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, foldery, rodziny e-maili, śledzenie odczytu, zapisane widoki, wykrywanie duplikatów na podstawie decyzji, podgląd Syncfusion, potok redakcji z wyłączeniami i wymianą XFDF, wzorce Znajdź i redaguj, sugestie redakcji oparte na regułach i AI, ponowne wykorzystanie redakcji z wcześniejszych wniosków, pakowanie odpowiedzi ze scalaniem papieru firmowego.
Wnioskodawcy / Kontakty W pełni zintegrowana, wielokrotnego użytku tożsamość wnioskodawcy, kontrola przepływu przyjęcia, obszar roboczy postępowania w sprawach bezzasadności i uciążliwości (F&V), 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, przydział 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 sterowany katalogiem (pulpity Report Studio), statystyczne raporty roczne, pulpity SLA/zarządcze, rejestr audytowy zabezpieczony łańcuchem skrótów oraz eksporty audytu sprawy gotowe do postępowania sądowego.
AI Assist (opcjonalnie) Sugestie i przygotowywanie wersji roboczych oparte na Azure OpenAI: podsumowania, sugestie redakcji, ugruntowane przygotowywanie wersji roboczych, triage przyjęcia, sugestie dla roli Custodian, wstępne wypełnianie i kontrole spójności ocen, wyszukiwanie semantyczne i duplikaty, ugruntowany w przepisach asystent sprawy — Ask AccessPoint (klikalne cytowania, przygotowanie wersji roboczej, zapisane rozmowy) — a także asystent trybu Mój portfel spraw, podręcznik jurysdykcyjny zasilany przez pakiety jurysdykcyjne, raportowanie Ask AccessPoint, codzienny przegląd i podsumowanie po powrocie, portfel ryzyka i analiza postępowania. Przełączniki dla poszczególnych funkcji na poziomie dzierżawy; rejestrowanie wyłącznie metadanych (asystent może dodatkowo zapisywać prywatne dla właściciela transkrypcje).
Konfiguracja i platforma Import pakietów jurysdykcyjnych (1 pakiet Universal Baseline + 106 pakiety jurysdykcyjne, w tym automatyczne statusy domniemanej odmowy ograniczone do typu wniosku oraz opcjonalne ugruntowanie AI), 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, a także opcjonalnych zasobów AI Search / Azure OpenAI / Document Intelligence) 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. Wymagany wybór typu wdrożenia zabezpiecza ponowne wdrożenia: Nowa instalacja tworzy serwer SQL w trybie Entra-first (podmiot wdrażający staje się początkowym administratorem Entra, z uwierzytelnianiem wyłącznie przez Entra od samego początku — żadne poświadczenie SQL nigdy nie istnieje), natomiast Aktualizacja istniejącej instalacji zachowuje ustawienia aplikacji operatora i pozostawia dostęp do bazy danych bez zmian. 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ę, ponownie wymusza uwierzytelnianie SQL wyłącznie przez Entra (zabezpieczenie dodatkowe — szablon stosuje je już wcześniej), przyznaje tożsamości zarządzanej uprawnienia Microsoft Graph (skryptowa alternatywa dla strony wydawcy Dokończ konfigurację), konfiguruje opcjonalne zastąpienie adresu URL API w encji magazynu SharePoint oraz zatwierdza żądania uprawnień API SPFx. Każdy krok można pominąć niezależnie.

Uprawnienia Graph są zwykle przyznawane za pośrednictwem strony wydawcy Dokończ konfigurację — wdrożenie zwraca dane wyjściowe finishSetupUrl, które administrator Entra klienta otwiera, aby przyznać wszystkie uprawnienia tożsamości zarządzanej w jednym idempotentnym przebiegu (uruchamianym ponownie po aktualizacjach, aby uwzględnić nowe uprawnienia).

Wdrożenie jest domyślnie zabezpieczone (security-hardened): TLS 1.3, FTPS wyłączone, podstawowe uwierzytelnianie SCM/FTP wyłączone, włączone HTTP/2 oraz domyślnie włączony Microsoft Defender for SQL (z możliwością wyłączenia). 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 jurysdykcyjny.

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. PermissionService:   │
     │                              │     resolve roles +      │
     │                              │     permission grants    │
     │                              │                          │
     │     ◄── 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) Wystawca dowolnej dzierżawy Entra — walidowane są formaty https://login.microsoftonline.com/{tenantId}/v2.0 (v2) oraz https://sts.windows.net/{tenantId}/ (v1); zakres dzierżawy określa roszczenie (claim) tid tokenu
Rejestracja aplikacji Aplikacja wielodzierżawcowa obsługiwana przez wydawcę, autoryzowana zgodą (consent) osobno dla każdej dzierżawy klienta (brak rejestracji aplikacji do zarządzania lub rotacji dla poszczególnych klientów); eksponowany zakres access_as_user; brak tajnego klucza klienta. Izolację między dzierżawami klientów zapewnia zwalidowane roszczenie tid w połączeniu ze sprawdzeniem licencji/subskrypcji

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 (serwer jest tworzony w trybie Entra-first; żadne poświadczenie SQL nigdy nie istnieje)
  • Azure Blob Storage — DefaultAzureCredential (tożsamość zarządzana w środowisku produkcyjnym)
  • Microsoft Graph API — ManagedIdentityCredential z uprawnieniami aplikacji
  • Opcjonalne zasoby AI (AI Search, Azure OpenAI, Document Intelligence) — uwierzytelnianie wyłącznie tożsamością zarządzaną, z wyłączonym dostępem lokalnym/kluczem

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

Autoryzacja i RBAC

AccessPoint implementuje granularny, konfigurowalny na poziomie dzierżawy model uprawnień, przechowywany w Azure SQL i egzekwowany na warstwie API przy każdym żądaniu: zdefiniowany przez produkt katalog atomowych kodów uprawnień (np. request.modify, document.view, redaction.approve, request.view.pii) jest grupowany w role, a każda akcja kontrolera jest bramkowana kodem uprawnienia.

Typ roli Role Uwagi
Rola systemowa Administrator (jedyna wbudowana rola stała) Obejmuje wszystkie uprawnienia z katalogu — wyliczane z katalogu, a nie z zasiewu bazy danych — dzięki czemu nigdy nie można do niej stracić dostępu; niezmienna i nieusuwalna.
Role relacyjne Reviewer, Custodian, Contributor, Reader, Advisor Zdefiniowane przez produkt pakiety uprawnień nadawane automatycznie i indywidualnie dla danego celu na podstawie relacji roboczych/współpracy (przydział Custodian, zadanie Contributor, przegląd, członkostwo Advisor/Reader). Nie można ich przypisać bezpośrednio, są ograniczone zakresem do powiązanego rekordu i nigdy nie obejmują danych osobowych wnioskodawcy.
Role dzierżawcy np. Request Coordinator (dostarczana w pakiecie Universal Baseline) oraz dowolne role niestandardowe W pełni edytowalne pakiety uprawnień zarządzane w Ustawienia > Role i uprawnienia. Role koordynatora/urzędnika są całkowicie definiowane przez dzierżawcę — dostarczana w pakiecie rola Request Coordinator jest faktyczną rolą urzędnika ds. dostępu i prywatności.
Rola Widzi dane osobowe wnioskodawcy Typowy dostęp Typowy użytkownik
Administrator Tak Wszystko (wszystkie uprawnienia z katalogu) Administrator IT, właściciel systemu
Request Coordinator (rola dzierżawcy) Tak Zarządza wnioskami, przydziałami, redakcjami, korespondencją Urzędnik ds. dostępu i prywatności
Reviewer Nie Odczyt oraz oznaczanie/rozwiązywanie wątpliwości dotyczących redakcji we wnioskach w trakcie przeglądu Radca prawny, QA
Advisor Nie Odczyt oraz przeglądanie/oznaczanie redakcji (nigdy stosowanie ani zatwierdzanie) Doradzający radca prawny, ekspert merytoryczny
Custodian Nie Własne przydziały i ich dokumenty Pracownik departamentu ds. dokumentacji
Contributor Nie Własne zadania i ich dokumenty Ekspert merytoryczny
Reader Nie Tylko odczyt powiązanych wniosków i udostępnionych dokumentów Nadzór, audyt

Punkty egzekwowania:

  1. Atrybuty [RequirePermission(code)] — dynamiczny dostawca zasad (policy provider) mapuje każdą akcję kontrolera na kod uprawnienia z katalogu
  2. PermissionService — wylicza efektywne uprawnienia wywołującego (role stałe połączone z nadaniami relacyjnymi dla danego celu), z kontrolami ograniczonymi do obiektu na poziomie wniosku/dokumentu/przydziału/zadania
  3. Kontrole własności na poziomie zasobu — np. Contributor może uzyskać dostęp wyłącznie do własnych zadań; Custodian wyłącznie do własnych przydziałów
  4. PiiFilterMiddleware — usuwa pola danych osobowych wnioskodawcy z odpowiedzi JSON dla każdego wywołującego, który nie posiada uprawnienia do podglądu PII wnioskodawcy

Wszystkie punkty końcowe API do zapisu egzekwują uprawnienia 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). Przypisania ról stałych mają określony zakres (globalny, wniosku, przydziału lub zadania), mogą być opcjonalnie ograniczone czasowo, a role relacyjne nigdy nie są zapisywane jako przypisania stałe — są wyprowadzane indywidualnie dla danego celu na podstawie leżących u ich podstaw rekordów pracy. Pierwszy użytkownik, który uzyska dostęp do systemu, jest inicjowany z rolą Administrator, a zabezpieczenie po stronie serwera uniemożliwia usunięcie ostatniego aktywnego administratora.

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
Zastąpienie adresu URL API (opcjonalne) SharePoint Tenant Storage Entity Dzierżawa M365 klienta (podstawowym mechanizmem wykrywania jest punkt końcowy wykrywania API wydawcy)
Indeksy wyszukiwania AI, podsumowania, wynik OCR (opcjonalnie) Azure AI Search / Azure SQL Subskrypcja Azure klienta

Co przekracza granice dzierżawy

Przepływ danych Kierunek Co jest przesyłane Przeznaczenie
Walidacja licencji API → Publisher Platform Token tożsamości zarządzanej Entra (roszczenie tid tokenu identyfikuje dzierżawę), wersja API oraz własny adres URL API (samorejestracja na potrzeby wykrywania przez składnik web) Walidacja aktywnej subskrypcji; odpowiedź niesie również najnowszą opublikowaną wersję AccessPoint, dzięki czemu panel Konfiguracja może wyświetlić powiadomienie „Dostępna aktualizacja” (wyłącznie numery wersji — żadne dane użycia ani sprawy)
Wykrywanie adresu URL API SPFx → Publisher Platform Token bearer (wyłącznie roszczenie identyfikatora dzierżawy) Rozwiązanie adresu bazowego API klienta, gdy nie ustawiono zastąpienia w encji magazynu
Powiadomienia e-mail API → Microsoft Graph Treść e-maila przez Mail.Send Wysyłanie powiadomień ze współdzielonej skrzynki pocztowej
Powiadomienia Teams (opcjonalne — można je zminimalizować / wyeliminować) API → Publisher Platform → Microsoft Graph Typ aktywności, identyfikatory GUID odbiorcy i dzierżawcy, tytuł/tekst podglądu powiadomienia, nazwisko działającego użytkownika, numer wniosku, identyfikator rekordu (głęboki link) 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). To jedyny kanał powiadomień, który opuszcza dzierżawę — e-mail oraz kanał w aplikacji dostarczają te same powiadomienia w obrębie dzierżawy. Zobacz Udostępnianie danych w powiadomieniach 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
  • Prompty i odpowiedzi AI Assist — gdy AI Assist jest wdrożony, zasób Azure OpenAI działa we własnej subskrypcji i regionie klienta; Microsoft nie trenuje modeli na tej treści, a treść promptów/odpowiedzi nie jest przechowywana (przechowywane są wyłącznie metadane zużycia — na potrzeby miernika budżetu oraz oświadczenia o udziale AI w eksporcie audytu sprawy)
  • Powiadomienia w aplikacji oraz e-mail/Outlook — kanał w aplikacji jest obsługiwany z własnego API klienta; e-mail jest wysyłany z własnej współdzielonej skrzynki pocztowej klienta za pomocą Mail.Send. Żadne z nich nie przechodzą przez wydawcę. Tylko opcjonalny kanał aktywności Teams wysyła jakiekolwiek dane poza dzierżawę, a nawet to można zminimalizować lub wyeliminować (poniżej)

Udostępnianie danych w powiadomieniach Teams (opcjonalnie)

Zgodnie z obietnicą suwerenności danych, jedyne dane dzierżawcy, które opuszczają granicę na potrzeby powiadomień, to opcjonalny ładunek danych aktywności Teams — i można go zminimalizować lub całkowicie usunąć. Każde powiadomienie jest dostarczane na maksymalnie trzech kanałach; dwa zawsze pozostają w dzierżawie (kanał w aplikacji, obsługiwany z API klienta, oraz e-mail/Outlook, wysyłany z własnej współdzielonej skrzynki pocztowej klienta). Kanał aktywności Teams jest udogodnieniem: w trybie domyślnym API klienta wysyła metodą POST niewielki ładunek danych do wielodzierżawcowej aplikacji wydawcy, która wywołuje Graph sendActivityNotification (co musi zostać wywołane przez aplikację będącą właścicielem manifestu Teams). Wydawca nie przechowuje żadnej z tych danych i rejestruje wyłącznie identyfikatory GUID odbiorcy i dzierżawcy.

Pola w domyślnym ładunku danych Teams (przekazywanym przez wydawcę) — oraz to, co usuwa przełącznik Minimalizacja:

Pole Zawiera Dane osobowe? Usuwane przez Minimalizację?
tenantId / recipientUserId Identyfikatory GUID dzierżawcy i odbiorcy w Entra Nie — identyfikatory Nie (routing)
activityType Stała wartość wyliczeniowa manifestu (np. assignmentCreated) Nie Nie
previewText / topicText Podgląd i tytuł (nazwa zlecenia/zadania, treść powiadomienia) Potencjalnie (dowolny tekst) Tak → symbol zastępczy
actorName Nazwa wyświetlana działającego pracownika Tak — nazwisko osobowe Tak → „AccessPoint"
requestNumber Kod referencyjny wniosku Nie — odniesienie Nie (kontekst)
relatedEntity + relatedRecordId Typ rekordu + GUID (głęboki link) Nie — identyfikatory Nie (głęboki link)

Dane osobowe wnioskodawcy nigdy nie znajdują się w ładunku danych — nie istnieje pole nazwiska/e-maila wnioskodawcy, a powiadomienia dla Custodian/Contributor mają dane osobowe usunięte już wcześniej, niezależnie od tego. Dwa mechanizmy zaostrzają to jeszcze bardziej:

  • Minimalizacja (Notifications:TeamsMinimalPayload, przełącznik na poziomie dzierżawcy) zastępuje previewText, topicText oraz actorName neutralnymi symbolami zastępczymi, dzięki czemu nazwiska, tytuły i dowolny tekst nigdy nie opuszczają dzierżawy — opuszczają ją wyłącznie identyfikatory routingu/głębokiego linku. Nie jest wymagana żadna zmiana manifestu.
  • Eliminacja (Notifications:TeamsRelayMode=Direct) sprawia, że API klienta samodzielnie wywołuje Graph sendActivityNotification przy użyciu własnej tożsamości zarządzanej, dzięki czemu żaden ładunek danych w ogóle nie dociera do wydawcy. Wymaga to roli aplikacji TeamsActivity.Send dla tożsamości zarządzanej API oraz wskazania w webApplicationInfo.id manifestu Teams własnej aplikacji klienta — zobacz Przewodnik wdrożeniowy.
Tryb Ładunek danych do wydawcy Dane osobowe / dowolny tekst opuszczają dzierżawę Nakład pracy przy konfiguracji
Domyślny przekaźnik Tak (pola powyżej) Nazwiska/tytuły, chyba że zminimalizowano Brak
Przełącznik minimalizacji Tak (wyłącznie identyfikatory) Brak Jeden przełącznik
Przekaźnik bezpośredni (samodzielnie hostowany) Brak Brak Nadanie tożsamości zarządzanej + edycja manifestu
Teams wyłączony Brak Brak (wyłącznie e-mail i kanał w aplikacji) Brak

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 każdego wywołującego, który nie posiada uprawnienia do podglądu PII wnioskodawcy (Custodian, Contributor, Reader, Reviewer i Advisor nigdy go nie posiadają) — po stronie serwera, niezależnie od tego, o co żąda klient. Usuwane pola: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, a także pola tożsamości/kontaktu pełnomocnika oraz uwagi dotyczące weryfikacji tożsamości.

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 wygenerować gotowy do postępowania sądowego eksport audytu sprawy (dawniej „pakiet dowodowy").

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ą

Jeden silnik RetentionService trwale usuwa rekordy, które przekroczyły okres przechowywania, w ramach pięciu rejestrów — wnioski, oceny, incydenty, skargi oraz samodzielne ryzyka dotyczące prywatności — sterowany dla każdego typu ustawieniami RetentionPeriodMonths + RetentionStartPoint (NULL = przechowywanie bezterminowe, wartość domyślna). Rekordy, które nie mogą przekroczyć okresu przechowywania, są wykluczone konstrukcyjnie (ocena w statusie Obowiązująca, ryzyko Zaakceptowane, ryzyko powiązane ze sprawą), a przeterminowany rekord, od którego wciąż zależy inna otwarta sprawa, jest odrzucany po stronie serwera; kwalifikowalność jest ponownie oceniana w chwili trwałego usuwania. Gdy rekord jest trwale usuwany, silnik kasuje z Blob Storage obiekty blob dokumentów, skonwertowane pliki PDF, adnotacje i pakiety eksportu, oprócz rekordów bazy danych. Tabela RetentionPurgeLog rejestruje, co zostało usunięte, kiedy i przez kogo — pole EntityName identyfikuje, z którego rejestru pochodzi rekord, wraz z migawką jego numeru, typu, daty zamknięcia i liczby dokumentów — ślad klasy zgodności, który przetrwa usunięcie danych i sam nigdy nie jest trwale usuwany.

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
→