Mapowanie kontroli ITSG-33, zgodność z GC Cloud Guardrails oraz referencja SA&A dla kanadyjskich departamentów rządu federalnego
Last updated: September 03, 2026 by Steve
Referencja kontroli bezpieczeństwa GC
Ta strona jest przeznaczona dla kanadyjskich departamentów rządu federalnego przeprowadzających ocenę i autoryzację bezpieczeństwa (Security Assessment and Authorization, SA&A) dla AccessPoint. Mapuje kontrole bezpieczeństwa AccessPoint na framework ITSG-33, GC Cloud Guardrails oraz powiązane wymagania TBS/CCCS.
Pełna architektura techniczna znajduje się na stronie Architektura techniczna.
Podsumowanie architektury dla audytorów
AccessPoint działa w całości w ramach własnej dzierżawy Microsoft 365 i Azure departamentu. Fakty istotne z punktu widzenia bezpieczeństwa, na których opierają się poniższe mapowania, to:
- Backend — ASP.NET Core Web API na Azure App Service (Linux), Azure SQL Database oraz Azure Blob Storage, wszystkie wdrożone we własnej subskrypcji Azure departamentu.
- Tożsamość — Microsoft Entra ID jest jedynym dostawcą tożsamości (tokeny bearer JWT). App Service uwierzytelnia się wobec usług backendowych za pomocą tożsamości zarządzanej przypisanej przez system; Azure SQL jest tworzony w trybie Entra-first z uwierzytelnianiem wyłącznie przez Entra — żadne poświadczenie SQL nigdy nie istnieje, więc nie ma nic do przechowywania, rotowania ani wyłączania.
- Kontrola dostępu — granularna kontrola dostępu oparta na uprawnieniach, egzekwowana po stronie serwera na każdym punkcie końcowym API: zdefiniowany przez produkt katalog atomowych kodów uprawnień jest grupowany w konfigurowalne na poziomie dzierżawy role, a oprogramowanie pośredniczące filtrujące PII usuwa dane osobowe wnioskodawcy z odpowiedzi dla każdego wywołującego, który nie posiada uprawnienia do podglądu PII wnioskodawcy.
- Szyfrowanie — TLS 1.3 na front doorze App Service (TLS 1.2+ na Azure SQL i Blob Storage); TDE w bazie danych oraz AES-256 SSE na Blob Storage w spoczynku.
- Audyt — niezmienny ślad audytu na poziomie pól wraz z wyłącznie dopisywalnym rejestrem audytowym zabezpieczonym łańcuchem skrótów (SHA-256), z gotowymi do postępowania sądowego eksportami audytu sprawy (dawniej „pakietami dowodowymi") dla poszczególnych wniosków; opcjonalny kontener blob WORM (write-once) może uczynić wyeksportowane dowody niezmiennymi na poziomie magazynu. Telemetria w Application Insights / Log Analytics z domyślnymi regułami alertów metrycznych, domyślnie włączonym Microsoft Defender for SQL oraz opcjonalnym skanowaniem antywirusowym przy przesyłaniu Microsoft Defender for Storage, które blokuje oznaczony plik przed podglądem, odtwarzaniem, pobraniem i ujawnieniem.
- Opcjonalne procesory — Azure AI Speech (transkrypcja), Azure AI Document Intelligence (OCR i tekst na ekranie) oraz skalowalne do zera zadanie mediów Container Apps wdrażają się we własnej subskrypcji departamentu z dostępem wyłącznie przez tożsamość zarządzaną i wyłączonymi kluczami. Wykrywanie twarzy i śledzenie obszaru na potrzeby redakcji wideo działają wewnątrz App Service bez żadnego wywołania zewnętrznego. Obraz kontenera zadania mediów zawiera wyłącznie kod; departamenty lustrzą go we własnym Azure Container Registry na potrzeby produkcji, dzięki czemu żadne pobranie w czasie działania nie zależy od wydawcy.
- Granica wydawcy — walidacja licencji uwierzytelnia się tokenem tożsamości zarządzanej Entra (roszczenie identyfikatora dzierżawy tokenu identyfikuje dzierżawę) i przesyła wyłącznie identyfikator dzierżawy, wersję API oraz własny adres URL API; odpowiedź niesie również najnowszą opublikowaną wersję AccessPoint, dzięki czemu panel Konfiguracja początkowa może wyświetlić powiadomienie „Dostępna aktualizacja" (wyłącznie numery wersji — żadne dane użycia ani sprawy). Żadne dane spraw klienta nie są przesyłane do wydawcy ani przez niego przechowywane. Jedynym opcjonalnym wyjściem danych jest ładunek danych powiadomienia w kanale aktywności Teams (identyfikatory GUID na potrzeby routingu, a domyślnie także tytuł/podgląd powiadomienia i nazwisko działającego użytkownika — nigdy dane osobowe wnioskodawcy), przekazywany przez wielodzierżawcową aplikację wydawcy, ponieważ Graph wymaga, aby wysłała je aplikacja będąca właścicielem manifestu. Departament może go zminimalizować (przełącznik usuwa nazwiska i dowolny tekst, pozostawiając wyłącznie identyfikatory routingu) lub całkowicie wyeliminować (samodzielnie hostując przekaźnik, dzięki czemu nic nie dociera do wydawcy); e-mail oraz kanał w aplikacji przekazują te same powiadomienia w obrębie dzierżawy. Zobacz Udostępnianie danych w powiadomieniach Teams.
Zgodność z ramami bezpieczeństwa GC
| Framework | Jak AccessPoint się dostosowuje |
|---|---|
| ITSG-33 (profil PBMM) | Kontrole bezpieczeństwa zmapowane do wszystkich rodzin ITSG-33. Zobacz Mapowanie rodzin kontroli ITSG-33 poniżej. |
| GC Cloud Guardrails | Wszystkie 13 obowiązkowych zabezpieczeń (guardrails) uwzględnionych. Zobacz tabelę Zgodność z GC Cloud Guardrails. |
| Policy on Government Security | System zaprojektowany z myślą o formalnym procesie SA&A. Granica autoryzacji jest zdefiniowana w sekcji Granica autoryzacji poniżej. |
| Directive on Security Management | Ślad audytu, kontrola dostępu oraz możliwości ciągłego monitorowania wspierają bieżącą zgodność. |
| Directive on Service and Digital | Architektura natywna dla chmury, zgodna z dyrektywą GC „cloud-first”. Wdrażana w całości w ramach istniejącej dzierżawy M365 i Azure departamentu. |
| CCCS Cloud Security Risk Management | Udokumentowany model współodpowiedzialności. Kanadyjskie regiony Azure zostały ocenione przez CCCS dla poziomu PBMM. |
Kanadyjska rezydencja danych
W przypadku wdrożeń Government of Canada, AccessPoint jest wdrażany w kanadyjskich regionach Azure (Canada Central lub Canada East). Wszystkie dane — w tym rekordy wniosków, przesłane dokumenty, ślady audytu i telemetria — znajdują się w wybranym kanadyjskim regionie. Żadne dane nie są przesyłane do regionów poza Kanadą ani w nich przechowywane, chyba że departament jawnie skonfiguruje w tym celu replikację geograficzną Azure.
Kanadyjskie regiony Microsoft Azure zostały ocenione przez Canadian Centre for Cyber Security (CCCS) i są zatwierdzone dla obciążeń PBMM (Protected B, Medium Integrity, Medium Availability).
Co PBMM oznacza dla AccessPoint
- Protected B — AccessPoint przetwarza dane osobowe wnioskodawcy (imię i nazwisko, e-mail, telefon, adres) oraz potencjalnie wrażliwe dokumenty rządowe. Oprogramowanie pośredniczące filtrujące dane osobowe, kontrola dostępu oparta na rolach oraz mechanizmy szyfrowania aplikacji są zaprojektowane z myślą o danych na poziomie Protected B.
- Medium Integrity — Wszystkie modyfikacje danych są rejestrowane w niezmiennym śladzie audytu, wzmocnionym przez rejestr audytowy zabezpieczony łańcuchem skrótów. Ograniczenia bazy danych oraz walidacja na poziomie API chronią przed nieautoryzowaną modyfikacją.
- Medium Availability — Aplikacja jest bezstanowa, a cały stan przechowywany jest w Azure SQL i Blob Storage. Umowy SLA platformy Azure oraz konfigurowalna przez klienta redundancja wspierają wymagania dotyczące średniej dostępności.
Mapowanie rodzin kontroli ITSG-33
Poniższa tabela mapuje każdą rodzinę kontroli ITSG-33 do odpowiednich sekcji strony Architektura techniczna. Wykorzystaj ją jako punkt wyjścia przy ocenie AccessPoint względem profilu kontroli bezpieczeństwa PBMM Twojego departamentu.
| Rodzina ITSG-33 | Obszar kontroli | Gdzie jest uwzględniona |
|---|---|---|
| AC — Access Control | Uwierzytelnianie, autoryzacja, zasada najmniejszych uprawnień, RBAC po stronie serwera, filtrowanie danych osobowych, zarządzanie sesjami | Uwierzytelnianie i tożsamość, Autoryzacja i RBAC, Prywatność od podstaw |
| AU — Audit and Accountability | Logowanie, niezmienny ślad audytu, rejestr zabezpieczony łańcuchem skrótów, monitorowanie, retencja logów | Logowanie, monitorowanie i audyt |
| CA — Security Assessment and Authorization | Proces SA&A, granica systemu, ciągłe monitorowanie | Granica autoryzacji (ta strona); Przegląd platformy; ciągłe monitorowanie przez Logowanie, monitorowanie i audyt |
| CM — Configuration Management | Konfiguracja bazowa, kontrola zmian, domyślny hardening | Model wdrożenia (domyślny hardening, addytywne migracje DacPac) |
| CP — Contingency Planning | Kopie zapasowe, odtwarzanie po awarii, ciągłość działania | Bezstanowy App Service (cały stan w Azure SQL i Blob Storage); kopie zapasowe SQL zarządzane przez Azure oraz redundancja Blob konfigurowane przez departament — zobacz Model wdrożenia |
| IA — Identification and Authentication | Dostawca tożsamości Entra ID, MFA, tożsamość zarządzana, uwierzytelnianie SQL wyłącznie przez Entra | Uwierzytelnianie i tożsamość |
| IR — Incident Response | Obsługa incydentów, powiadamianie, raportowanie do CCCS | Niezmienny ślad audytu, rejestr zabezpieczony łańcuchem skrótów oraz Log Analytics wspierają dochodzenie — zobacz Logowanie, monitorowanie i audyt. Departamenty raportują zdarzenia cybernetyczne do CCCS zgodnie z wymaganiami GC. |
| MP — Media Protection | Szyfrowanie danych w spoczynku, sanityzacja nośników | Szyfrowanie, Rezydencja i suwerenność danych |
| PE — Physical and Environmental Protection | Bezpieczeństwo fizyczne infrastruktury | Odpowiedzialność Azure CSP — objęte oceną CCCS Microsoft dla PBMM |
| PL — Planning | Plany bezpieczeństwa, granica autoryzacji systemu | Przegląd platformy; Granica autoryzacji (ta strona) |
| RA — Risk Assessment | Ocena zagrożeń/ryzyka, skanowanie podatności | VAPT i TRA przeprowadzane przez departament (zobacz Kluczowe dokumenty do zażądania); skanowanie platformy Azure przez Microsoft |
| SA — System and Services Acquisition | Łańcuch dostaw, zależności od stron trzecich, praktyki dostawców | Inwentarz komponentów, Co obsługuje wydawca; pakiet API zweryfikowany integralnościowo; obraz workera mediów możliwy do zlustrzenia; pełny inwentarz zależności dostępny na życzenie |
| SC — System and Communications Protection | Szyfrowanie w transmisji, izolacja dzierżawy, ochrona granic | Szyfrowanie, Rezydencja i suwerenność danych. Wdrożenie jednodzierżawcowe z dedykowanymi zasobami; departamenty mogą dodać Private Endpoints, integrację VNet oraz WAF. |
| SI — System and Information Integrity | Łatanie, zarządzanie podatnościami, integralność danych wejściowych | Model wdrożenia (domyślny hardening, addytywne migracje). System operacyjny/środowisko uruchomieniowe łatane przez Azure; kod aplikacji i zależności łatane przez wydawcę. |
Zgodność z GC Cloud Guardrails
Poniższa tabela mapuje kontrole AccessPoint na GC Cloud Guardrails — obowiązkowe minimalne konfiguracje bezpieczeństwa dla adopcji chmury przez GC.
| Zabezpieczenie (guardrail) | Jak AccessPoint je realizuje |
|---|---|
| 01 — Ochrona kont root/administratora globalnego | AccessPoint nie używa i nie wymaga kont Global Admin w czasie działania. Role administratora w aplikacji są oddzielone od ról administratora Azure/M365. Wdrożenie początkowe wymaga uprawnień administratora; bieżąca eksploatacja — nie. |
| 02 — Zarządzanie uprawnieniami administracyjnymi | Granularna kontrola dostępu oparta na uprawnieniach, egzekwowana po stronie serwera na warstwie API przy każdym żądaniu: atomowe kody uprawnień grupowane w role, przy czym Administrator jest jedyną wbudowaną rolą (zabezpieczenie po stronie serwera uniemożliwia usunięcie ostatniego aktywnego administratora). Role operacyjne są konfigurowalne na poziomie dzierżawy i oddzielone od roli Administrator, a przypisania ról mogą być ograniczone czasowo. App Service uwierzytelnia się za pomocą tożsamości zarządzanej przypisanej przez system, bez przechowywanych poświadczeń, a Azure SQL jest tworzony w trybie Entra-first z uwierzytelnianiem wyłącznie przez Entra (żadne poświadczenie SQL nigdy nie istnieje). Zobacz Autoryzacja i RBAC. |
| 03 — Dostęp do konsoli chmury | AccessPoint nie uzyskuje dostępu do portalu Azure ani żadnej konsoli zarządzania chmurą w czasie działania. Zarządzanie zasobami Azure pozostaje odpowiedzialnością departamentu. |
| 04 — Konta monitorowania przedsiębiorstwa | Cała telemetria jest przechowywana w instancji Application Insights i obszarze roboczym Log Analytics klienta. Departamenty mogą przyznać CCCS/SSC dostęp tylko do odczytu zgodnie ze swoimi standardowymi procedurami. Zobacz Logowanie, monitorowanie i audyt. |
| 05 — Lokalizacja danych | Wszystkie dane znajdują się w dzierżawie Azure klienta, w wybranym kanadyjskim regionie (Canada Central lub Canada East) — w tym opcjonalne zasoby AI Search, Azure OpenAI, Document Intelligence, Azure AI Speech, Defender for Storage oraz zasoby przetwarzania multimediów Container Apps, które są wdrażane we własnej subskrypcji departamentu. Nagrania, transkrypcje i udostępnione kopie pozostają na własnym koncie magazynu departamentu. Walidacja licencji przesyła wyłącznie identyfikator dzierżawy (za pomocą tokenu tożsamości zarządzanej Entra), wersję API oraz własny adres URL API — żadne dane spraw klienta nie są przesyłane do wydawcy ani przez niego przechowywane. Jedyne opcjonalne wyjście danych, ładunek danych powiadomienia w kanale aktywności Teams, nie zawiera danych osobowych wnioskodawcy i można je zminimalizować do identyfikatorów routingu lub wyeliminować, samodzielnie hostując przekaźnik; e-mail oraz kanał w aplikacji przekazują te same powiadomienia w obrębie dzierżawy. Zobacz Rezydencja i suwerenność danych oraz Udostępnianie danych w powiadomieniach Teams. |
| 06 — Ochrona danych w spoczynku | Azure SQL TDE oraz Azure Blob Storage SSE (AES-256) włączone domyślnie. Obsługiwane klucze zarządzane przez klienta (CMK). Zobacz Szyfrowanie. |
| 07 — Ochrona danych w transmisji | TLS 1.3 egzekwowane na front doorze App Service (połączenia TLS 1.0/1.1/1.2 odrzucane); TLS 1.2+ na Azure SQL i Blob Storage. Brak punktów końcowych w tekście jawnym. Zobacz Szyfrowanie. |
| 08 — Segmentuj i separuj | Wdrożenie jednodzierżawcowe z dedykowanymi zasobami na klienta — brak współdzielonej mocy obliczeniowej, magazynu ani bazy danych. Ścieżki Blob i zapytania bazodanowe są ograniczone do zakresu dzierżawy. Można dodać segmentację sieci (Private Endpoints, integracja VNet). Zobacz Rezydencja i suwerenność danych. |
| 09 — Usługi bezpieczeństwa sieciowego | Domyślne wdrożenie wykorzystuje publiczne punkty końcowe Azure PaaS z ochroną granic zarządzaną przez platformę. Szablon oferuje wbudowaną opcję hardeningu (deployNetworkIsolation=true), która umieszcza SQL i Blob Storage za wirtualną siecią dostępną wyłącznie dla App Service; departamenty mogą również dodać Private Endpoints, WAF (Application Gateway / Front Door) oraz reguły NSG. |
| 10 — Usługi cyberobrony | Microsoft Defender for SQL jest domyślnie włączony na logicznym serwerze SQL, a skanowanie antywirusowe przy przesyłaniu Microsoft Defender for Storage można włączyć na koncie dokumentów (deployDefenderForStorage=true), z werdyktami egzekwowanymi przez aplikację, zanim jakikolwiek plik zostanie wyświetlony w podglądzie, odtworzony, pobrany lub udostępniony. Dane Application Insights i Log Analytics są dostępne do integracji z czujnikami cyberobrony GC oraz departamentowym SIEM. Zobacz Logowanie, monitorowanie i audyt. |
| 11 — Logowanie i monitorowanie | Niezmienny ślad audytu na poziomie pól w Azure SQL wraz z wyłącznie dopisywalnym rejestrem audytowym zabezpieczonym łańcuchem skrótów, z eksportami audytu sprawy dla poszczególnych wniosków; opcjonalny kontener blob WORM czyni wyeksportowane dowody zapisywalnymi tylko raz (write-once) na poziomie magazynu. Application Insights rejestruje całą telemetrię API, z domyślnymi regułami alertów metrycznych (HTTP 5xx, opóźnienie). Log Analytics z konfigurowalną retencją (30–730 dni). Zobacz Logowanie, monitorowanie i audyt. |
| 12 — Konfiguracja rynków chmurowych | Składnik web SPFx i aplikacja Teams są dystrybuowane przez Microsoft AppSource. Backend Azure jest wdrażany za pomocą szablonu Bicep/ARM — jednym kliknięciem z portalu Azure lub skryptem PowerShell — z pakietem API zweryfikowanym względem jego opublikowanego skrótu SHA-256. Opcjonalny obraz workera mediów jest domyślnie pobierany z rejestru wydawcy i powinien zostać zlustrzony we własnym Azure Container Registry departamentu (mediaWorkerImage + mediaWorkerRegistryResourceId), dzięki czemu zadanie pobiera obraz swoją tożsamością zarządzaną ze źródła kontrolowanego przez departament. Departamenty zatwierdzają instalacje w ramach swoich standardowych procesów App Catalog i zarządzania Azure. Zobacz Model wdrożenia. |
| 13 — Planuj ciągłość działania | Automatyczne kopie zapasowe Azure SQL, opcje redundancji Blob Storage oraz bezstanowy App Service umożliwiają szybkie ponowne wdrożenie (API dołącza swój schemat i stosuje go przy starcie). Zobacz Model wdrożenia. |
Wskazówki dotyczące procesu SA&A
Podczas przeprowadzania oceny i autoryzacji bezpieczeństwa (SA&A) dla AccessPoint departamenty powinny rozważyć następujące kwestie.
Kategoryzacja systemu
AccessPoint jest zazwyczaj kategoryzowany jako PBMM, gdy jest wykorzystywany do przetwarzania wniosków ATIP. System obsługuje:
| Kategoria danych | Klasyfikacja | Uzasadnienie |
|---|---|---|
| Dane osobowe wnioskodawcy (imię i nazwisko, e-mail, adres) | Protected B | Dane osobowe — poważna szkoda w przypadku ujawnienia |
| Rekordy i opisy wniosków | Protected B | Mogą opisywać wrażliwą tematykę |
| Przesłane dokumenty odpowiedzi | Do poziomu Protected B | Klasyfikacja zależy od treści dokumentu |
| Decyzje o wyłączeniach i uzasadnienie | Protected B | Ujawnienie mogłoby odsłonić procesy deliberacyjne |
| Ślad audytu i rejestr audytowy | Protected B | Zawierają odniesienia do danych osobowych i szczegółów wniosków |
| Konfiguracja aplikacji | Wewnętrzna | Brak wrażliwych danych w konfiguracji |
| Telemetria i logi | Wewnętrzna | Dane dotyczące wydajności, brak danych osobowych w telemetrii |
Granica autoryzacji
Granica autoryzacji AccessPoint obejmuje:
- Azure App Service oraz wdrożony na nim kod aplikacji
- Azure SQL Database oraz wszystkie dane aplikacji
- Konto Azure Blob Storage oraz wszystkie przechowywane dokumenty
- Obszar roboczy Application Insights i Log Analytics
- Opcjonalne zasoby Azure AI Search, Azure OpenAI, Azure AI Document Intelligence oraz Azure AI Speech, plan Defender for Storage na koncie dokumentów oraz kolejki Storage Queues, środowisko Container Apps i zadanie do przetwarzania multimediów, gdy są wdrożone (wszystkie we własnej subskrypcji departamentu, z uwierzytelnianiem wyłącznie tożsamością zarządzaną)
- Rejestracja aplikacji Entra ID oraz tożsamość zarządzana App Service
- Składnik web SPFx wdrożony do SharePoint Online oraz pakiet aplikacji Teams
- Wszystkie przepływy danych między tymi komponentami
Poniższe elementy znajdują się poza granicą autoryzacji AccessPoint i podlegają szerszej ocenie SA&A Azure/M365 departamentu:
- Subskrypcja Azure i konfiguracja grupy zasobów
- Polityki dzierżawy Entra ID (MFA, Conditional Access, zgodność urządzeń)
- Konfiguracja sieci (VNet, NSG, Private Endpoints)
- Usługi platformy Azure zarządzane przez Microsoft
Wykorzystanie istniejących ocen
- Kontrole platformy Azure (PE, części SC i CP) są objęte oceną CCCS Microsoft dla PBMM. Departamenty mogą powoływać się na ocenę dostawcy usług chmurowych CCCS dla Azure zamiast ponownie oceniać kontrole na poziomie platformy.
- Kontrole Entra ID i M365 są objęte istniejącą oceną SA&A departamentu dla M365. AccessPoint dziedziczy MFA, Conditional Access oraz zarządzanie tożsamością z konfiguracji dzierżawy departamentu.
- Kontrole na poziomie aplikacji AccessPoint (AC, AU, warstwa aplikacji IA/CM/SI oraz IR) muszą zostać ocenione przez departament. Strona Architektura techniczna zawiera szczegółową dokumentację kontroli.
Kluczowe dokumenty do zażądania
Podczas oceny AccessPoint Twój zespół SA&A może chcieć zażądać:
| Dokument | Cel |
|---|---|
| Ta strona + Architektura techniczna | Dokumentacja kontroli bezpieczeństwa |
| Wyniki oceny podatności i testów penetracyjnych (VAPT) | Testowanie bezpieczeństwa aplikacji |
| Przewodnik wdrożenia | Procedura wdrożenia i hardening po wdrożeniu |
| Inwentarz zależności | Ocena ryzyka łańcucha dostaw (zobacz Inwentarz komponentów; pełny inwentarz zależności dostępny na życzenie) |
| Procedury reagowania na incydenty | Zobowiązania IR dostawcy (dostępne od wydawcy na życzenie) |
| Privacy Impact Assessment (PIA) | Przepływy danych osobowych i kontrole prywatności (zobacz Ocena skutków dla prywatności GC) |
| Diagramy przepływu danych | Przepływ danych (zobacz Diagram architektury i Rezydencja i suwerenność danych) |