Mapowanie kontroli ITSG-33, zgodność z GC Cloud Guardrails oraz referencja SA&A dla kanadyjskich departamentów rządu federalnego
Last updated: July 12, 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 korzysta z uwierzytelniania wyłącznie przez Entra (uwierzytelnianie hasłem SQL jest wyłączone), dzięki czemu w aplikacji nie są przechowywane żadne poświadczenia.
- Kontrola dostępu — RBAC na poziomie aplikacji, egzekwowane po stronie serwera na każdym punkcie końcowym API, wraz z oprogramowaniem pośredniczącym filtrującym dane osobowe, które usuwa dane osobowe wnioskodawcy z odpowiedzi dla ról o ograniczonym dostępie.
- 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); telemetria w Application Insights / Log Analytics z domyślnymi regułami alertów metrycznych.
- Granica wydawcy — walidacja licencji przesyła wyłącznie identyfikator dzierżawy i klucz licencyjny; żadne dane klienta nie są przesyłane do wydawcy ani przez niego przechowywane.
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 | RBAC na poziomie aplikacji z sześcioma odrębnymi rolami, egzekwowane po stronie serwera na warstwie API przy każdym żądaniu. Rola Administrator jest oddzielona od ról operacyjnych. App Service uwierzytelnia się za pomocą tożsamości zarządzanej przypisanej przez system, bez przechowywanych poświadczeń, a Azure SQL korzysta z uwierzytelniania wyłącznie przez Entra (uwierzytelnianie hasłem SQL wyłączone). 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). Walidacja licencji przesyła wyłącznie identyfikator dzierżawy i klucz licencyjny — żadne dane klienta nie są przesyłane do wydawcy ani przez niego przechowywane. Zobacz Rezydencja i suwerenność danych. |
| 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ę. Departamenty mogą dodać Private Endpoints, integrację VNet, WAF (Application Gateway / Front Door) oraz reguły NSG. |
| 10 — Usługi cyberobrony | 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. 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
- Azure AI Search, gdy wdrożona jest opcjonalna funkcja wyszukiwania pełnotekstowego
- 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) |