ITSG-33-Kontroll-Mapping, GC Cloud Guardrails-Compliance und SA&A-Referenz für kanadische Bundesbehörden
Last updated: July 12, 2026 by Steve
GC-Sicherheitskontrollen-Referenz
Diese Seite richtet sich an kanadische Bundesbehörden, die eine Security Assessment and Authorization (SA&A) für AccessPoint durchführen. Sie ordnet die Sicherheitskontrollen von AccessPoint dem ITSG-33-Rahmenwerk, den GC Cloud Guardrails und den zugehörigen TBS-/CCCS-Anforderungen zu.
Die vollständige technische Architektur finden Sie auf der Seite Technische Architektur.
Architekturzusammenfassung für Prüfer
AccessPoint läuft vollständig innerhalb des behördeneigenen Microsoft 365- und Azure-Mandanten. Die sicherheitsrelevanten Fakten, die den nachfolgenden Zuordnungen zugrunde liegen, sind:
- Backend – eine ASP.NET Core Web API auf Azure App Service (Linux), Azure SQL Database und Azure Blob Storage, die allesamt im behördeneigenen Azure-Abonnement bereitgestellt werden.
- Identität – Microsoft Entra ID ist der einzige Identitätsanbieter (JWT-Bearer-Token). Der App Service authentifiziert sich bei Backend-Diensten mit einer systemseitig zugewiesenen verwalteten Identität; Azure SQL verwendet ausschließlich Entra-Authentifizierung (SQL-Passwort-Authentifizierung deaktiviert), sodass keine Anmeldeinformationen in der Anwendung gespeichert werden.
- Zugriffssteuerung – serverseitiges RBAC auf Anwendungsebene an jedem API-Endpunkt sowie eine PII-Filter-Middleware, die PII des Antragstellers für eingeschränkte Rollen aus Antworten entfernt.
- Verschlüsselung – TLS 1.3 am Eingangspunkt des App Service (TLS 1.2+ bei Azure SQL und Blob Storage); TDE für die Datenbank und AES-256-SSE für Blob Storage im Ruhezustand.
- Audit – ein unveränderlicher Audit-Trail auf Feldebene sowie ein hash-verkettetes (SHA-256), ausschließlich anfügbares Audit-Ledger; Telemetrie in Application Insights / Log Analytics mit standardmäßigen Metrikwarnungsregeln.
- Herausgebergrenze – die Lizenzvalidierung übermittelt nur die Mandanten-ID und den Lizenzschlüssel; keine Kundendaten werden an den Herausgeber übertragen oder von ihm gespeichert.
Ausrichtung am GC-Sicherheitsrahmenwerk
| Rahmenwerk | Wie AccessPoint sich daran ausrichtet |
|---|---|
| ITSG-33 (PBMM-Profil) | Sicherheitskontrollen allen ITSG-33-Familien zugeordnet. Siehe die ITSG-33-Kontrollfamilien-Zuordnung unten. |
| GC Cloud Guardrails | Alle 13 obligatorischen Guardrails adressiert. Siehe die Tabelle GC Cloud Guardrails-Compliance. |
| Policy on Government Security | System für eine formelle SA&A konzipiert. Die Autorisierungsgrenze ist im Abschnitt Autorisierungsgrenze unten definiert. |
| Directive on Security Management | Audit-Trail, Zugriffssteuerung und Funktionen zur kontinuierlichen Überwachung unterstützen die fortlaufende Compliance. |
| Directive on Service and Digital | Cloud-native Architektur, ausgerichtet an der Cloud-First-Direktive des GC. Wird vollständig innerhalb des bestehenden M365- und Azure-Mandanten der Behörde bereitgestellt. |
| CCCS Cloud Security Risk Management | Geteilte Verantwortung dokumentiert. Die kanadischen Azure-Regionen sind vom CCCS für PBMM bewertet. |
Kanadische Datenresidenz
Für Bereitstellungen der Regierung von Kanada wird AccessPoint in kanadischen Azure-Regionen (Canada Central oder Canada East) bereitgestellt. Alle Daten – einschließlich Antragsdatensätze, hochgeladene Dokumente, Audit-Trails und Telemetrie – verbleiben innerhalb der ausgewählten kanadischen Region. Es werden keine Daten in Regionen außerhalb Kanadas übertragen oder dort gespeichert, es sei denn, die Behörde konfiguriert dafür explizit die Azure-Geo-Replikation.
Die kanadischen Regionen von Microsoft Azure wurden vom Canadian Centre for Cyber Security (CCCS) bewertet und sind für PBMM-Workloads (Protected B, Medium Integrity, Medium Availability) freigegeben.
Was PBMM für AccessPoint bedeutet
- Protected B – AccessPoint verarbeitet PII des Antragstellers (Name, E-Mail, Telefon, Adresse) und potenziell sensible behördliche Unterlagen. Die PII-Filter-Middleware der Anwendung, die rollenbasierte Zugriffssteuerung und die Verschlüsselungskontrollen sind für Protected B-Daten ausgelegt.
- Medium Integrity – Alle Datenänderungen werden in einem unveränderlichen Audit-Trail erfasst, verstärkt durch ein hash-verkettetes Audit-Ledger. Datenbankbeschränkungen und Validierung auf API-Ebene schützen vor unbefugter Änderung.
- Medium Availability – Die Anwendung ist zustandslos, der gesamte Zustand liegt in Azure SQL und Blob Storage. Azure-Plattform-SLAs und die vom Kunden konfigurierbare Redundanz unterstützen die Anforderungen an mittlere Verfügbarkeit.
ITSG-33-Kontrollfamilien-Zuordnung
Die folgende Tabelle ordnet jede ITSG-33-Kontrollfamilie den relevanten Abschnitten der Seite Technische Architektur zu. Verwenden Sie sie als Ausgangspunkt, wenn Sie AccessPoint anhand des PBMM-Sicherheitskontrollprofils Ihrer Behörde bewerten.
| ITSG-33-Familie | Kontrollbereich | Wo adressiert |
|---|---|---|
| AC – Zugriffssteuerung | Authentifizierung, Autorisierung, geringste Rechte, serverseitiges RBAC, PII-Filterung, Sitzungsverwaltung | Authentifizierung und Identität, Autorisierung und RBAC, Privacy by Design |
| AU – Audit und Rechenschaftspflicht | Protokollierung, unveränderlicher Audit-Trail, hash-verkettetes Ledger, Überwachung, Protokollaufbewahrung | Protokollierung, Überwachung und Audit |
| CA – Sicherheitsbewertung und Autorisierung | SA&A-Prozess, Systemgrenze, kontinuierliche Überwachung | Autorisierungsgrenze (diese Seite); Plattformübersicht; kontinuierliche Überwachung über Protokollierung, Überwachung und Audit |
| CM – Konfigurationsmanagement | Basiskonfiguration, Änderungssteuerung, Härtungs-Standardeinstellungen | Bereitstellungsmodell (Härtungs-Standardeinstellungen, additive DacPac-Migrationen) |
| CP – Notfallplanung | Backup, Notfallwiederherstellung, Geschäftskontinuität | Zustandsloser App Service (gesamter Zustand in Azure SQL und Blob Storage); Azure-verwaltete SQL-Backups und Blob-Redundanz von der Behörde konfiguriert – siehe Bereitstellungsmodell |
| IA – Identifikation und Authentifizierung | Entra ID als Identitätsanbieter, MFA, verwaltete Identität, ausschließlich Entra-basierte SQL-Authentifizierung | Authentifizierung und Identität |
| IR – Vorfallreaktion | Vorfallbehandlung, Benachrichtigung, Meldung an CCCS | Unveränderlicher Audit-Trail, hash-verkettetes Ledger und Log Analytics unterstützen die Untersuchung – siehe Protokollierung, Überwachung und Audit. Behörden melden Cyberereignisse gemäß den GC-Anforderungen an das CCCS. |
| MP – Medienschutz | Verschlüsselung ruhender Daten, Medienbereinigung | Verschlüsselung, Datenresidenz und Souveränität |
| PE – Physischer und umgebungsbezogener Schutz | Physische Sicherheit der Infrastruktur | Verantwortung des Azure-CSP – abgedeckt durch die CCCS-Bewertung von Microsoft für PBMM |
| PL – Planung | Sicherheitspläne, Systemautorisierungsgrenze | Plattformübersicht; Autorisierungsgrenze (diese Seite) |
| RA – Risikobewertung | Bedrohungs-/Risikobewertung, Schwachstellen-Scanning | Von der Behörde durchgeführte VAPT und TRA (siehe Anzufordernde Schlüsseldokumente); Plattform-Scanning von Azure durch Microsoft |
| SA – Beschaffung von Systemen und Diensten | Lieferkette, Drittanbieter-Abhängigkeiten, Anbieterpraktiken | Komponenteninventar, Was der Herausgeber betreibt; vollständiges Abhängigkeitsinventar auf Anfrage verfügbar |
| SC – Schutz von Systemen und Kommunikation | Verschlüsselung bei der Übertragung, Mandantenisolierung, Grenzschutz | Verschlüsselung, Datenresidenz und Souveränität. Einzelmandanten-Bereitstellung mit dedizierten Ressourcen; Behörden können Private Endpoints, VNet-Integration und WAF hinzufügen. |
| SI – Integrität von Systemen und Informationen | Patching, Schwachstellenmanagement, Eingabeintegrität | Bereitstellungsmodell (Härtungs-Standardeinstellungen, additive Migrationen). Betriebssystem/Runtime werden von Azure gepatcht; Anwendungscode und Abhängigkeiten vom Herausgeber. |
GC Cloud Guardrails-Compliance
Die folgende Tabelle ordnet die Kontrollen von AccessPoint den GC Cloud Guardrails zu – den obligatorischen Mindestsicherheitskonfigurationen für die GC-Cloud-Einführung.
| Guardrail | Wie AccessPoint es adressiert |
|---|---|
| 01 – Root-/Global-Admin-Konten schützen | AccessPoint verwendet oder erfordert zur Laufzeit keine Global-Admin-Konten. Admin-Rollen innerhalb der Anwendung sind von den Azure-/M365-Admin-Rollen getrennt. Die erstmalige Bereitstellung erfordert Admin-Berechtigungen; der laufende Betrieb nicht. |
| 02 – Verwaltung administrativer Rechte | RBAC auf Anwendungsebene mit sechs verschiedenen Rollen, serverseitig auf der API-Ebene bei jeder Anfrage durchgesetzt. Die Administrator-Rolle ist von den operativen Rollen getrennt. Der App Service authentifiziert sich über eine systemseitig zugewiesene verwaltete Identität ohne gespeicherte Anmeldeinformationen, und Azure SQL verwendet ausschließlich Entra-Authentifizierung (SQL-Passwort-Authentifizierung deaktiviert). Siehe Autorisierung und RBAC. |
| 03 – Zugriff auf die Cloud-Konsole | AccessPoint greift zur Laufzeit nicht auf das Azure-Portal oder eine andere Cloud-Verwaltungskonsole zu. Die Verwaltung der Azure-Ressourcen bleibt in der Verantwortung der Behörde. |
| 04 – Unternehmensweite Überwachungskonten | Sämtliche Telemetrie wird im Application Insights- und Log Analytics-Arbeitsbereich des Kunden gespeichert. Behörden können CCCS/SSC gemäß ihren Standardverfahren schreibgeschützten Zugriff gewähren. Siehe Protokollierung, Überwachung und Audit. |
| 05 – Datenstandort | Alle Daten verbleiben im Azure-Mandanten des Kunden in der ausgewählten kanadischen Region (Canada Central oder Canada East). Die Lizenzvalidierung übermittelt nur die Mandanten-ID und den Lizenzschlüssel – es werden keine Kundendaten an den Herausgeber übertragen oder von ihm gespeichert. Siehe Datenresidenz und Souveränität. |
| 06 – Schutz ruhender Daten | Azure SQL TDE und Azure Blob Storage SSE (AES-256) standardmäßig aktiviert. Kundenverwaltete Schlüssel (CMK) werden unterstützt. Siehe Verschlüsselung. |
| 07 – Schutz von Daten bei der Übertragung | TLS 1.3 am Eingangspunkt des App Service erzwungen (TLS 1.0/1.1/1.2 abgelehnt); TLS 1.2+ bei Azure SQL und Blob Storage. Keine Klartext-Endpunkte. Siehe Verschlüsselung. |
| 08 – Segmentieren und Trennen | Einzelmandanten-Bereitstellung mit dedizierten Ressourcen pro Kunde – keine gemeinsam genutzte Rechenkapazität, kein gemeinsamer Speicher, keine gemeinsame Datenbank. Blob-Pfade und Datenbankabfragen sind mandantenbezogen. Netzwerksegmentierung (Private Endpoints, VNet-Integration) kann hinzugefügt werden. Siehe Datenresidenz und Souveränität. |
| 09 – Netzwerksicherheitsdienste | Die Standardbereitstellung verwendet öffentliche Azure PaaS-Endpunkte mit plattformverwaltetem Grenzschutz. Behörden können Private Endpoints, VNet-Integration, WAF (Application Gateway / Front Door) und NSG-Regeln hinzufügen. |
| 10 – Cyber-Verteidigungsdienste | Die Daten aus Application Insights und Log Analytics sind für die Integration mit GC-Cyber-Verteidigungssensoren und dem behördlichen SIEM zugänglich. Siehe Protokollierung, Überwachung und Audit. |
| 11 – Protokollierung und Überwachung | Unveränderlicher Audit-Trail auf Feldebene in Azure SQL sowie ein hash-verkettetes, ausschließlich anfügbares Audit-Ledger. Application Insights erfasst sämtliche API-Telemetrie mit standardmäßigen Metrikwarnungsregeln (HTTP 5xx, Latenz). Log Analytics mit konfigurierbarer Aufbewahrung (30–730 Tage). Siehe Protokollierung, Überwachung und Audit. |
| 12 – Konfiguration von Cloud-Marktplätzen | Das SPFx-Webpart und die Teams-App werden über Microsoft AppSource verteilt. Das Azure-Backend wird über eine Bicep/ARM-Vorlage bereitgestellt – per Klick aus dem Azure-Portal oder skriptgesteuert mit einem PowerShell-Skript. Behörden genehmigen Installationen über ihre Standardprozesse für den App-Katalog und die Azure-Governance. Siehe Bereitstellungsmodell. |
| 13 – Kontinuität planen | Automatisierte Azure SQL-Backups, Redundanzoptionen für Blob Storage und ein zustandsloser App Service ermöglichen eine schnelle erneute Bereitstellung (die API bündelt ihr Schema und wendet es beim Start an). Siehe Bereitstellungsmodell. |
Leitfaden zum SA&A-Prozess
Bei der Durchführung einer Security Assessment and Authorization für AccessPoint sollten Behörden Folgendes berücksichtigen.
Systemkategorisierung
AccessPoint wird bei der Verwendung für die ATIP-Antragsverarbeitung typischerweise als PBMM kategorisiert. Das System verarbeitet:
| Datenkategorie | Klassifizierung | Begründung |
|---|---|---|
| PII des Antragstellers (Name, E-Mail, Adresse) | Protected B | Personenbezogene Daten – schwerwiegender Schaden bei Offenlegung |
| Antragsdatensätze und -beschreibungen | Protected B | Können sensible Sachverhalte beschreiben |
| Hochgeladene antwortrelevante Dokumente | Bis zu Protected B | Klassifizierung hängt vom Dokumentinhalt ab |
| Ausnahmeentscheidungen und Begründung | Protected B | Offenlegung könnte Beratungsprozesse offenbaren |
| Audit-Trail und Audit-Ledger | Protected B | Enthalten Verweise auf PII und Antragsdetails |
| Anwendungskonfiguration | Intern | Keine sensiblen Daten in der Konfiguration |
| Telemetrie und Protokolle | Intern | Leistungsdaten, keine PII in der Telemetrie |
Autorisierungsgrenze
Die AccessPoint-Autorisierungsgrenze umfasst:
- Den Azure App Service und seinen bereitgestellten Anwendungscode
- Die Azure SQL Database und alle Anwendungsdaten
- Das Azure Blob Storage-Konto und alle gespeicherten Dokumente
- Den Application Insights- und Log Analytics-Arbeitsbereich
- Azure AI Search, wenn die optionale Volltextsuchfunktion bereitgestellt wird
- Die Entra ID-App-Registrierung und die verwaltete Identität des App Service
- Das auf SharePoint Online bereitgestellte SPFx-Webpart und das Teams-App-Paket
- Alle Datenflüsse zwischen diesen Komponenten
Die folgenden Elemente liegen außerhalb der AccessPoint-Autorisierungsgrenze und fallen unter die umfassendere Azure-/M365-SA&A der Behörde:
- Die Konfiguration des Azure-Abonnements und der Ressourcengruppe
- Entra ID-Mandantenrichtlinien (MFA, Conditional Access, Gerätekonformität)
- Netzwerkkonfiguration (VNet, NSG, Private Endpoints)
- Von Microsoft verwaltete Azure-Plattformdienste
Nutzung bestehender Bewertungen
- Azure-Plattformkontrollen (PE, Teile von SC und CP) sind durch die CCCS-Bewertung von Microsoft für PBMM abgedeckt. Behörden können die CCCS-Cloud-Service-Provider-Bewertung für Azure heranziehen, anstatt Kontrollen auf Plattformebene erneut zu bewerten.
- Entra ID- und M365-Kontrollen sind durch die bestehende M365-SA&A der Behörde abgedeckt. AccessPoint erbt MFA, Conditional Access und Identity Governance aus der Mandantenkonfiguration der Behörde.
- AccessPoint-Kontrollen auf Anwendungsebene (AC, AU, die Anwendungsschicht von IA/CM/SI sowie IR) müssen von der Behörde bewertet werden. Die Seite Technische Architektur enthält die detaillierte Kontrolldokumentation.
Anzufordernde Schlüsseldokumente
Bei der Bewertung von AccessPoint möchte Ihr SA&A-Team möglicherweise Folgendes anfordern:
| Dokument | Zweck |
|---|---|
| Diese Seite + Technische Architektur | Dokumentation der Sicherheitskontrollen |
| Ergebnisse der Schwachstellenbewertung und des Penetrationstests (VAPT) | Sicherheitstests der Anwendung |
| Bereitstellungshandbuch | Bereitstellungsverfahren und Härtung nach der Bereitstellung |
| Abhängigkeitsinventar | Bewertung des Lieferkettenrisikos (siehe Komponenteninventar; vollständiges Abhängigkeitsinventar auf Anfrage verfügbar) |
| Verfahren zur Vorfallreaktion | IR-Verpflichtungen des Anbieters (auf Anfrage beim Herausgeber erhältlich) |
| Datenschutz-Folgenabschätzung | Flüsse personenbezogener Daten und Datenschutzkontrollen (siehe GC-Datenschutz-Folgenabschätzung) |
| Datenflussdiagramme | Datenbewegung (siehe Architekturdiagramm und Datenresidenz und Souveränität) |