Kanada ITSG-33 und KI: Erfüllung des Sicherheitskontrollrahmens des CSE in agentischen Umgebungen

Kanadische Bundesbehörden, deren Auftragnehmer sowie private Unternehmen, die mit staatlich klassifizierten Informationen arbeiten, setzen KI-Agents in der Dokumentenverarbeitung, in Bürgerdienst-Workflows, bei regulatorischen Prüfungen und in der Programmverwaltung ein.

Viele dieser Workflows betreffen Protected A- und Protected B-Informationen – Kanadas Klassifizierungen für sensible Regierungsdaten, deren unbefugte Offenlegung Einzelpersonen, Organisationen oder Regierungsabläufe erheblichen Schaden zufügen könnte.

Damit fallen KI-Agent-Implementierungen eindeutig in den Geltungsbereich von ITSG-33, dem Information Technology Security Guidance Framework des Canadian Centre for Cyber Security.

ITSG-33 ist Kanadas Rahmenwerk für das Management von IT-Sicherheitsrisiken, das eng an NIST 800-53 angelehnt ist und als Grundlage für Cloud-Sicherheitsaudits, Anforderungen des Contract Security Program und FedRAMP-äquivalente Cloud-Autorisierung im kanadischen Bundeskontext dient.

Wie seine US-Pendants sieht ITSG-33 keine Ausnahmen für KI-Agents oder automatisierte Systeme vor, die auf geschützte Informationen zugreifen. Die Zugriffskontrollen, Prüfprotokoll-Anforderungen, Verschlüsselungspflichten und Vorgaben zum Incident Response, die für den Zugriff menschlicher Mitarbeiter auf Protected B-Daten gelten, gelten gleichermaßen für KI-Agenten.

Dieser Beitrag erläutert, welche Anforderungen ITSG-33 an KI-gestützte Workflows mit geschützten Regierungsinformationen stellt, identifiziert Compliance-Lücken, die durch agentische Implementierungen im kanadischen Kontext entstehen, skizziert Best Practices für die Steuerung des KI-Agent-Zugriffs auf Protected A- und B-Daten und begründet, warum Governance auf Datenebene die Architektur ist, die die Sicherheitskontrollanforderungen von ITSG-33 für agentische Systeme erfüllt.

Executive Summary

Kernaussage: Die Sicherheitskontrollen von ITSG-33 – Zugriffskontrolle, Audit und Verantwortlichkeit, Identifikation und Authentifizierung, System- und Kommunikationsschutz sowie Incident Response – gelten für KI-Agents, die auf Protected A- und Protected B-Informationen zugreifen. Kanadische Regierungsbehörden und Auftragnehmer, die KI in geschützten Informationsworkflows einsetzen, ohne ihre Sicherheitskontrollen auf KI-Agents auszuweiten, weisen Compliance-Lücken auf, die das Treasury Board Secretariat und das Canadian Centre for Cyber Security zunehmend prüfen werden.

Warum das relevant ist: Organisationen, die mit Protected B-Daten arbeiten, riskieren den Ausschluss von Bundesvergaben, verpflichtende Meldungen bei Datenschutzverstößen gemäß PIPEDA und Bußgelder bis zu 10 Mio. CAD nach Quebecs Gesetz 25 bei nicht konformer Datenverarbeitung. Das Contract Security Program prüft Organisationen und deren Sicherheitsniveau, bevor Zugang zu Protected B-Daten gewährt wird – KI-Implementierungen ohne die von ITSG-33 geforderten Data-Governance-Kontrollen stellen ein Compliance-Risiko für jeden Regierungsauftrag dar, den das Unternehmen hält.

Wichtige Erkenntnisse

1. Die Sicherheitskontrollen von ITSG-33 gelten ausnahmslos für KI-Agents, die auf Protected A- und B-Informationen zugreifen. Das Framework regelt den Zugriff auf klassifizierte Regierungsinformationen, unabhängig davon, ob der Zugriff durch einen Menschen oder automatisiert erfolgt. Ein KI-Agent, der Protected B-Daten liest, verarbeitet oder überträgt, unterliegt denselben Zugriffskontroll-, Audit- und Verschlüsselungsanforderungen wie ein menschlicher Mitarbeiter mit derselben Aufgabe.
2. Protected B-Daten müssen innerhalb Kanadas verbleiben – auch bei Verarbeitung durch KI-Systeme. Cloud-Dienste zur Verarbeitung von Protected B-Daten müssen vom Canadian Centre for Cyber Security nach dem Protected B/Medium Integrity/Medium Availability (PBMM)-Profil geprüft werden. KI-Inferenzpipelines, die Protected B-Daten über nicht geprüfte Cloud-Infrastrukturen oder ohne kanadische Datenresidenz-Garantie leiten, verursachen eine Lücke bei der Datensouveränität, die ITSG-33 nicht toleriert.
3. Audit-Anforderungen nach ITSG-33 verlangen operationale Protokolle für Protected B-Zugriffe. Die AU-Kontrollfamilie des Frameworks verlangt, dass Zugriffe auf geschützte Informationen auf Operationsebene protokolliert werden – was wurde wann, von wem und mit welcher Autorisierung abgerufen. KI-Agents, die über gemeinsame Servicekonten arbeiten, erzeugen Protokolle, die keine dieser Anforderungen erfüllen. Der Audit-Trail muss jedes Protected B-Zugriffsereignis einer bestimmten autorisierten Person zuordnen, deren Identität verifizierbar ist.
4. Die Zugriffskontrollanforderungen von ITSG-33 gelten für KI-Agent-Workflows auf Operationsebene. Die AC-Kontrollfamilie verlangt, dass der Zugriff auf geschützte Informationen auf autorisierte Nutzer und Prozesse beschränkt ist, wobei rollenbasierte Zugriffskontrollen das Least-Privilege-Prinzip durchsetzen. Für KI-Agents bedeutet das: Der Zugriff muss pro Operation auf die Protected B-Daten beschränkt werden, die für die jeweilige Aufgabe erforderlich sind – nicht pauschal auf Session-Ebene über weit gefasste Servicekonten.
5. Die Bewertung Ihres KI-Einsatzes durch das Contract Security Program ist ein Beschaffungsrisiko. Organisationen, die Bundesaufträge mit Protected B-Daten anstreben, müssen nachweisen, dass ihre Informationssysteme – einschließlich KI-Systemen – die erforderlichen Sicherheitskontrollen für diese Klassifizierung erfüllen. Eine KI-Implementierung, die keine ITSG-33-konformen Zugriffskontrollen, Audit-Trails und Datenresidenz für Protected B-Daten nachweisen kann, gefährdet die Vertragsfähigkeit und stellt nicht nur eine technische Compliance-Lücke dar.

Was ITSG-33 für KI-gestützte Workflows fordert

ITSG-33 stellt einen Katalog von Sicherheitskontrollen bereit, gegliedert in technische, operative und Management-Klassen, die an NIST SP 800-53 angelehnt sind. Für die Protected B/PBMM-Compliance sind vier Kontrollfamilien bei KI-Agent-Implementierungen besonders relevant: Access Control (AC), Audit und Verantwortlichkeit (AU), Identifikation und Authentifizierung (IA) sowie System- und Kommunikationsschutz (SC). Jede dieser Familien entspricht Fähigkeiten, die viele KI-Implementierungen derzeit nicht bieten.

Access Control (AC-Familie)

Die AC-Kontrollen von ITSG-33 verlangen, dass der Zugriff auf Protected B-Informationen auf autorisierte Nutzer und Prozesse beschränkt und das Least-Privilege-Prinzip durchgesetzt wird. Für KI-Agents bedeutet das: Erstens muss der Agent eine authentifizierte, überprüfbare Identität besitzen, bevor Zugriff auf geschützte Informationen erfolgt. Zweitens muss der Zugriff auf das für die jeweilige Aufgabe absolut Notwendige beschränkt werden – ein Agent mit Leserechten für einen geschützten Dokumentenordner ist nicht automatisch berechtigt, alle Dateien herunterzuladen, Daten extern zu übertragen oder angrenzende Informationskategorien zu öffnen. Attributbasierte Zugriffskontrolle (ABAC) auf Operationsebene erfüllt diese Anforderung für agentische Systeme.

Audit und Verantwortlichkeit (AU-Familie)

Die AU-Kontrollfamilie verlangt eine umfassende Audit-Protokollierung aller Zugriffe auf Protected B-Daten, wobei die Protokolle gegen Manipulation geschützt sein müssen. Das Prüfprotokoll muss erfassen, wer auf geschützte Informationen zugegriffen hat, was abgerufen wurde, welche Operation durchgeführt wurde und wann – in einem Format, das Compliance-Audits und forensische Analysen unterstützt. KI-Agents, die über gemeinsame Servicekonten arbeiten, erzeugen Infrastrukturprotokolle, die API-Aufrufe erfassen, aber keine operationale Detailtiefe, individuelle Zuordnung oder manipulationssicheren Schutz bieten, wie es die AU-Familie fordert. Standard-KI-Inferenzprotokolle sind keine ITSG-33-konformen Audit-Trails für Protected B-Zugriffe.

Identifikation und Authentifizierung (IA-Familie)

Die IA-Kontrollen von ITSG-33 verlangen, dass Nutzer und Prozesse eindeutig identifiziert und authentifiziert werden, bevor sie auf geschützte Informationen zugreifen. Für Protected B-Systeme ist Multi-Faktor-Authentifizierung Pflicht. Für KI-Agents bedeutet eindeutige Identifikation, dass jeder Agent ein eigenes Identitätszertifikat besitzen muss – kein gemeinsames Servicekonto –, das dem spezifischen Workflow und dem menschlichen Autorisierer zugeordnet ist. Teilen sich mehrere Agents Zugangsdaten oder lässt sich der Authentifizierungsnachweis nicht auf eine konkrete menschliche Entscheidung zurückführen, gelten die IA-Kontrollen als nicht erfüllt.

System- und Kommunikationsschutz (SC-Familie)

Die SC-Kontrollen verlangen, dass Protected B-Daten während der Übertragung und im ruhenden Zustand mit AES-256 verschlüsselt werden. Für KI-Agent-Implementierungen bedeutet das, dass jede Komponente der Inferenzpipeline – API-Aufrufe, Modell-Inferenzumgebungen, Vektordatenbanken, temporäre Agentenspeicher und Ausgabekanäle – Protected B-Daten mit validierten kryptografischen Verfahren verschlüsseln muss. Vertraulichkeit, Integrität und Verfügbarkeit der Protected B-Daten müssen entlang jedes Datenpfads, den der Agent berührt, gewährleistet sein – nicht nur auf Anwendungsebene.

Datenresidenz für Protected B: Die Cloud-Bewertungspflicht

Eine der operativ wichtigsten ITSG-33-Anforderungen für KI-Implementierungen ist die Pflicht zur Cloud-Service-Bewertung. Cloud-Dienste, die Protected B-Workloads verarbeiten, müssen vom Canadian Centre for Cyber Security nach dem PBMM-Profil geprüft werden.

Diese Bewertung bestätigt, dass die Cloud-Infrastruktur die Sicherheitsanforderungen für Protected B-Daten erfüllt – einschließlich Datenresidenz in Kanada. KI-Agents, die Protected B-Daten über nicht PBMM-geprüfte Cloud-Dienste oder ohne dokumentierte kanadische Datenresidenz verarbeiten, arbeiten außerhalb der zulässigen Infrastruktur für diese Klassifizierung.

Allgemeine kommerzielle Cloud-Regionen – auch kanadische Regionen großer Hyperscaler, die nicht speziell für PBMM geprüft wurden – erfüllen diese Anforderung nicht automatisch.

Wo KI-Implementierungen ITSG-33-Compliance-Lücken erzeugen

Die Compliance-Lücken, die KI-Agent-Implementierungen in ITSG-33-regulierten Umgebungen verursachen, ähneln strukturell denen anderer regulatorischer Rahmenwerke – mit einer zusätzlichen Dimension: Kanadas Anforderungen an Datenresidenz und PBMM-Cloud-Bewertung schaffen ein Infrastruktur-Risiko, das sich nicht allein durch Konfiguration auf Anwendungsebene beheben lässt.

Nicht geprüfte Cloud-Infrastruktur für Protected B-KI-Workloads

Die häufigste ITSG-33-Lücke in kanadischen KI-Implementierungen ist die Nutzung von Cloud-Infrastruktur, die nicht nach dem PBMM-Profil bewertet wurde. Große KI-Plattformen – kommerzielle LLM-Anbieter, KI-Orchestrierungsdienste und Vektordatenbankanbieter – betreiben in der Regel Multi-Region-Cloud-Infrastrukturen ohne CSE-PBMM-Bewertung für den kanadischen Regierungsbereich. Organisationen, die diese Plattformen für Protected B-Workflows einsetzen, verarbeiten staatlich klassifizierte Informationen auf Infrastruktur außerhalb des zulässigen Rahmens – unabhängig von Zugriffskontrollen auf Anwendungsebene.

Gemeinsame Servicekonten und fehlende individuelle Zuordnung

ITSG-33 kann nicht erfüllt werden, wenn KI-Agents gemeinsame Servicekonto-Zugangsdaten nutzen. Teilen sich mehrere KI-Agents ein Servicekonto, kann das Audit-Protokoll ein Protected B-Zugriffsereignis keiner bestimmten autorisierten Person zuordnen. Das Contract Security Program verlangt, dass Organisationen nachweisen, wer auf geschützte Informationen zugegriffen hat – ein Audit-Trail, der nur ein Servicekonto statt einer Person nennt, genügt für Protected B-Daten nicht.

Unzureichende Verschlüsselung entlang der KI-Inferenzpipeline

Die SC-Kontrollen von ITSG-33 verlangen AES-256-Verschlüsselung für Protected B-Daten während der Übertragung und im ruhenden Zustand. KI-Inferenzpipelines umfassen mehrere Übertragungs- und Speicherpunkte: API-Aufrufe zum Modell, Modell-Inferenzumgebungen, Vektordatenbanken und Ausgabekanäle. Organisationen, die nur auf Anwendungsebene Verschlüsselung bestätigt haben, aber nicht an jedem Punkt der Pipeline, riskieren an jedem unverschlüsselten Segment eine SC-Kontrolllücke für alle dort durchlaufenden Protected B-Daten.

Best Practices für ITSG-33-konformen KI-Agent-Zugriff auf geschützte Informationen

1. PBMM-geprüfte Cloud-Infrastruktur für Protected B-KI-Workloads nutzen

Jede KI-Inferenzpipeline, die Protected B-Daten verarbeitet, muss auf Cloud-Infrastruktur laufen, die vom Canadian Centre for Cyber Security nach dem PBMM-Profil bewertet wurde und dokumentierte kanadische Datenresidenz bietet. Organisationen sollten von KI-Anbietern und Cloud-Providern spezifische PBMM-Bewertungsnachweise anfordern, bevor sie Protected B-Workflows implementieren – eine allgemeine FedRAMP-Moderate-Autorisierung ersetzt keine CSE-PBMM-Bewertung.

2. Jedem KI-Agent-Workflow eindeutige Identitätsnachweise zuweisen

Jeder KI-Agent, der auf Protected B-Informationen zugreift, muss mit einem eindeutigen Identitätsnachweis auf Workflow-Ebene arbeiten, der dem konkreten menschlichen Autorisierer zugeordnet ist. Gemeinsame Servicekonten und geteilte API-Schlüssel erfüllen die IA-Kontrollanforderungen von ITSG-33 nicht. Der Authentifizierungsprozess und die Delegationskette müssen in jedem Audit-Protokoll erfasst werden, um die individuelle Zuordnung sicherzustellen, wie sie das Contract Security Program und die AU-Kontrollen von ITSG-33 verlangen.

3. Zugriffskontrolle auf Operationsebene mit ABAC durchsetzen

Implementieren Sie ABAC, das jede KI-Agent-Anfrage für Protected B-Daten anhand des authentifizierten Profils des Agents, der Klassifizierung der angeforderten Daten, des Workflow-Kontexts und der konkreten Operation bewertet. Least-Privilege auf Operationsebene bedeutet: Ein Agent, der eine Protected B-Datei lesen darf, kann sie nicht automatisch herunterladen, extern weiterleiten oder auf weitere Datensätze außerhalb des Task-Scopes zugreifen.

4. Manipulationssichere Audit-Protokollierung für alle Protected B-Agent-Zugriffe implementieren

Setzen Sie operationale Audit-Protokollierung für jede KI-Agent-Interaktion mit Protected B-Daten um: authentifizierte Agentenidentität, menschlicher Autorisierer, konkret abgerufene Daten, durchgeführte Operation, Policy-Entscheidung und Zeitstempel. Protokolle müssen manipulationssicher sein, gemäß Treasury Board-Richtlinie aufbewahrt werden und in das SIEM des Unternehmens zur Echtzeit-Erkennung von Anomalien eingespeist werden.

5. Incident-Response-Pläne für KI-bezogene Protected B-Vorfälle aktualisieren

ITSG-33 verlangt Incident-Response-Pläne, die alle relevanten Cybersecurity-Ereignisse abdecken. KI-Implementierungen bringen neue Protected B-Vorfallkategorien: unbefugter Agentenzugriff, Prompt Injection mit Datenabfluss, Modellkompromittierung und Vorfälle beim Anbieter, die die kanadische Datenresidenz betreffen. Für jede Kategorie sind Erkennungskriterien, Eindämmungsmaßnahmen und Meldepflichten nach PIPEDA und Treasury Board zu definieren.

Wie Kiteworks ITSG-33-Compliance für KI-Agent-Implementierungen unterstützt

Die Steuerung des KI-Agent-Zugriffs auf Protected B-Informationen nach ITSG-33 erfordert eine Plattform, die die geforderten Sicherheitskontrollen auf Datenebene – nicht auf Modellebene – und innerhalb kanadischer Datenresidenzgrenzen durchsetzt. Das Kiteworks Private Data Network bietet kanadischen Regierungsbehörden und deren Auftragnehmern eine Governance-Architektur, die jede KI-Agent-Interaktion mit geschützten Regierungsinformationen vor dem Zugriff abfängt und für jede Operation authentifizierte Identität, ABAC-Policy, FIPS 140-3 Level 1-validierte Verschlüsselung und manipulationssichere Audit-Protokollierung erzwingt.

Eindeutige Agentenidentität und Delegationskette für ITSG-33 IA- und AU-Kontrollen

Kiteworks authentifiziert jeden KI-Agenten vor jedem Protected B-Zugriff mit einem eindeutigen Workflow-Zertifikat, das dem menschlichen Autorisierer zugeordnet ist. Die vollständige Delegationskette – Identität des Autorisierers, Identität des Agents, abgerufene Protected B-Daten, ausgeführte Operation – wird in jedem Audit-Protokolleintrag festgehalten. Damit erfüllt Kiteworks die ITSG-33-IA-Anforderungen zur individuellen Zuordnung und liefert den AU-konformen Audit-Trail, den das Contract Security Program fordert: ein manipulationssicheres Protokoll, das jedes Zugriffsereignis auf geschützte Informationen einer bestimmten autorisierten Person zuweist.

Operationale ABAC für ITSG-33-AC-Kontrollen und Least-Privilege-Prinzip

Die Data-Policy-Engine von Kiteworks prüft jede Agenten-Anfrage für Protected B-Daten anhand einer multidimensionalen Policy: authentifiziertes Agentenprofil, Klassifizierung der angeforderten Daten, Workflow-Kontext und konkrete Operation. Ein Agent, der eine Protected B-Akte lesen darf, kann sie nicht herunterladen, extern weiterleiten oder auf weitere Protected B-Daten außerhalb seines autorisierten Scopes zugreifen. Diese Durchsetzung pro Operation erfüllt die Least-Privilege-AC-Kontrollen von ITSG-33 für KI-Agent-Zugriffe und ersetzt die unzureichende Session-basierte Servicekonto-Authentifizierung, auf die viele aktuelle Implementierungen setzen.

FIPS 140-3-Verschlüsselung und SIEM-integrierter Audit-Trail

Alle über Kiteworks abgerufenen Protected B-Daten sind mit FIPS 140-3-validierter Verschlüsselung während der Übertragung und im ruhenden Zustand geschützt und erfüllen damit die SC-Kontrollanforderungen von ITSG-33 entlang des gesamten Agenten-Datenpfads. Jede Protected B-Interaktion wird in einem manipulationssicheren, operationellen Audit-Protokoll erfasst, das direkt ins SIEM des Unternehmens fließt. Wenn eine ITSG-33-Compliance- oder Breach-Notification-Prüfung Nachweise für Zugriffskontrollen bei Protected B-KI-Workflows verlangt, liefert Kiteworks einen Bericht – keine aufwändige Recherche in verschiedenen Infrastrukturprotokollen.

Flexible Bereitstellungsoptionen für kanadische Datenresidenz

Kiteworks bietet On-Premises-, Private-Cloud- und hybride Bereitstellungskonfigurationen, die Protected B-Daten innerhalb Kanadas halten – und damit die ITSG-33-Anforderungen an Datenresidenz für Protected B-Cloud-Workloads erfüllen. Organisationen können Kiteworks in von der kanadischen Regierung genehmigter Infrastruktur betreiben und so sicherstellen, dass KI-Agent-Zugriffe auf Protected B-Daten im CSE-geprüften Perimeter für diese Klassifizierung verbleiben. Sichere Bereitstellungsoptionen erweitern diese Governance-Architektur auch auf hybride Umgebungen, in denen geschützte Informationen zwischen On-Premises-Repositorys und Cloud-gehosteten KI-Workflows bewegt werden.

Für kanadische Regierungsbehörden und Auftragnehmer, die KI-Agents in Protected B-Workflows einsetzen möchten, ohne ihre ITSG-33-Compliance zu gefährden, bietet Kiteworks die Governance-Infrastruktur, die jede KI-Agent-Interaktion mit geschützten Regierungsinformationen von Grund auf absichert. Erfahren Sie mehr über Kiteworks für Behörden oder fordern Sie eine Demo an.

Weitere Ressourcen

• Blog Post
  Zero‑Trust-Strategien für kosteneffizienten KI-Datenschutz
• Blog Post
  Wie 77 % der Organisationen bei KI-Datensicherheit scheitern
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blog Post
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blog Post
  Regulierungsbehörden wollen keine KI-Policy mehr hören. Sie verlangen Beweise für deren Wirksamkeit.