ITSG-33-Kontroll-Mapping, GC Cloud Guardrails-Compliance und SA&A-Referenz für kanadische Bundesbehörden
Last updated: August 06, 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 wird Entra-first erstellt, mit ausschließlicher Entra-Authentifizierung – es existiert nie eine SQL-Anmeldeinformation, sodass es nichts zu speichern, zu rotieren oder zu deaktivieren gibt.
- Zugriffssteuerung – granulare, berechtigungsbasierte Zugriffssteuerung, serverseitig an jedem API-Endpunkt durchgesetzt: Ein produktseitig definierter Katalog atomarer Berechtigungscodes wird zu mandantenkonfigurierbaren Rollen gruppiert, und eine PII-Filter-Middleware entfernt die PII des Antragstellers aus Antworten für jeden Aufrufer, der nicht über die Berechtigung zur Anzeige von Antragsteller-PII verfügt.
- 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 mit gerichtsfesten Fall-Audit-Exports je Antrag (vormals „Beweispakete"); ein optionaler WORM-Blob-Container (Write-once) kann exportierte Nachweise auf der Speicherebene unveränderlich machen. Telemetrie in Application Insights / Log Analytics mit standardmäßigen Metrikwarnungsregeln, sowie Microsoft Defender for SQL standardmäßig aktiviert.
- Herausgebergrenze – die Lizenzvalidierung authentifiziert sich mit einem Entra-Token der verwalteten Identität (der
tid-Anspruch des Tokens identifiziert den Mandanten) und übermittelt nur die Mandanten-ID, die API-Version und die eigene Basis-URL der API; die Antwort enthält zudem die zuletzt veröffentlichte AccessPoint-Version, damit die Einrichtung einen Hinweis „Update verfügbar" anzeigen kann (nur Versionsnummern — keine Nutzungs- oder Falldaten). Es werden keine Kunden-Falldaten an den Herausgeber übertragen oder von ihm gespeichert. Der einzige optionale Datenabfluss ist die Nutzlast der Teams-Aktivitätsfeed-Benachrichtigung (Routing-GUIDs sowie standardmäßig Benachrichtigungstitel/-vorschau und der Name der handelnden Person — niemals PII des Antragstellers), die über die mandantenübergreifende App des Herausgebers weitergeleitet wird, weil Graph verlangt, dass die manifestbesitzende App sie sendet. Eine Behörde kann sie minimieren (ein Umschalter entfernt Namen und Freitext und lässt nur Routing-Kennungen übrig) oder sie vollständig eliminieren (die Weiterleitung selbst hosten, sodass nichts den Herausgeber erreicht); E-Mail und der In-App-Feed liefern dieselben Hinweise mandantenintern. Siehe Teams-Datenfreigabe für Benachrichtigungen.
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 | Granulare, berechtigungsbasierte Zugriffssteuerung, serverseitig auf der API-Ebene bei jeder Anfrage durchgesetzt: atomare Berechtigungscodes, gruppiert zu Rollen, wobei Administrator die einzige integrierte Rolle ist (ein serverseitiger Schutz verhindert das Entfernen des letzten aktiven Administrators). Operative Rollen sind mandantenkonfigurierbar und von Administrator getrennt, und Rollenzuweisungen können zeitlich befristet werden. Der App Service authentifiziert sich über eine systemseitig zugewiesene verwaltete Identität ohne gespeicherte Anmeldeinformationen, und Azure SQL wird Entra-first erstellt, mit ausschließlicher Entra-Authentifizierung (es existiert nie eine SQL-Anmeldeinformation). 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) – einschließlich der optionalen Ressourcen AI Search, Azure OpenAI und Document Intelligence, die im eigenen Abonnement der Behörde bereitgestellt werden. Die Lizenzvalidierung übermittelt nur die Mandanten-ID (über ein Entra-Token der verwalteten Identität), die API-Version und die eigene Basis-URL der API – es werden keine Kunden-Falldaten an den Herausgeber übertragen oder von ihm gespeichert. Der eine optionale Datenabfluss, die Nutzlast der Teams-Aktivitätsfeed-Benachrichtigung, enthält keine PII des Antragstellers und kann auf Routing-Kennungen minimiert oder durch das Selbst-Hosting der Weiterleitung eliminiert werden; E-Mail und der In-App-Feed liefern dieselben Hinweise mandantenintern. Siehe Datenresidenz und Souveränität und Teams-Datenfreigabe für Benachrichtigungen. |
| 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. Die Vorlage bietet eine integrierte Härtungsoption (deployNetworkIsolation=true), die SQL und Blob Storage hinter ein virtuelles Netzwerk stellt, das nur vom App Service erreichbar ist; Behörden können zudem Private Endpoints, WAF (Application Gateway / Front Door) und NSG-Regeln hinzufügen. |
| 10 – Cyber-Verteidigungsdienste | Microsoft Defender for SQL ist standardmäßig auf dem logischen SQL-Server aktiviert. 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 mit Fall-Audit-Exports je Antrag; ein optionaler WORM-Blob-Container macht exportierte Nachweise auf der Speicherebene write-once. 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
- Die optionalen Ressourcen Azure AI Search, Azure OpenAI und Azure AI Document Intelligence, sofern bereitgestellt (alle im eigenen Abonnement der Behörde mit ausschließlicher Authentifizierung per verwalteter Identität)
- 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) |