Mapowanie kontroli ITSG-33, zgodność z GC Cloud Guardrails oraz referencja SA&A dla kanadyjskich departamentów rządu federalnego
Last updated: August 06, 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 oraz domyślnie włączonym Microsoft Defender for SQL.
- 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; 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 oraz Document Intelligence, które są wdrażane we własnej subskrypcji 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. 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. 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 oraz Azure AI Document Intelligence, 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) |