NZISM: Cloud-Dienste, Auslagerung und fremde Endgeräte, und was ein deutscher Cloud- oder SaaS-Anbieter einer neuseeländischen Regierungsstelle erwarten muss

Problem in der Praxis

Ein deutsches SaaS-Haus gewinnt eine neuseeländische Behörde als Kunden. Die Plattform läuft in Frankfurt, Sicherungen liegen in einer zweiten europäischen Region, der Support sitzt in Deutschland und an einem weiteren Standort. Auf den Sicherheitsfragebogen antwortet der Vertrieb mit ISO-27001-Zertifikat, EU-Hosting und DSGVO-Konformität. Die Behörde braucht etwas anderes. Sie muss vor der Einführung eine Risikobewertung nach den Vorgaben des Government Chief Digital Officer (GCDO) durchführen, sie muss Vertrauensgrenzen (trust boundaries) und die Verteilung der Verantwortung je Dienst festlegen, alle Speicher- und Verarbeitungsorte einschließlich Replikaten und Sicherungen ermitteln und die Rechtsraumrisiken förmlich durch ihre Leitung und ihre Accreditation Authority annehmen lassen. Fehlen die Angaben des Anbieters, bleibt die Bewertung offen.

Zweiter Fall: Ein Managed-Service-Anbieter administriert den Mandanten einer Behörde in einer großen öffentlichen Cloud. Seine Administratoren melden sich über das Identitätssystem des Dienstleisters an und arbeiten auf Firmen-Notebooks. Beides hat Folgen, die selten im Angebot stehen. Wird der Zugriff auf eine Behördeninstanz über mehrere Identitätssysteme unter verschiedenen Sicherheitsrichtlinien gesteuert, ist diese Instanz nach 23.1.54 als eigene Sicherheitsdomäne zu behandeln. Und für Geräte, die nicht zugleich unmittelbar im Eigentum und unter der Kontrolle der Behörde stehen, muss die Behörde nach 22.1.12 den vollen Satz der BYOD-Maßnahmen anwenden.

Dritter Fall: Die Behörde möchte das Produkt auch für CONFIDENTIAL eingestufte Vorgänge nutzen. Bei einem öffentlichen oder im Ausland gehosteten Dienst ist das nach dem NZISM ausgeschlossen, gleich wie gut die Maßnahmen des Anbieters sind.

CISO-Einordnung

Wirkungsweg. Nach NZISM 1.2.6 ist die Befolgung des NZISM kraft Gesetzes nicht vorgeschrieben; die Controls könnten durch Gesetz oder Kabinettsanweisung verbindlich gemacht werden. Es gilt für Informationen und Systeme, die von oder im Auftrag („on behalf of“) der dort genannten Regierungsstellen betrieben werden (1.2.3); wann das einen Dienstleister erfasst, behandelt nzism-002. In den hier behandelten Abschnitten sind Adressaten fast durchweg die Behörden. Eine Ausnahme mit Blick auf Anbieter steht in 2.2.3: Cloud Computing ist danach eine Form der Auslagerung, und die Auslagerungsanforderungen des Abschnitts 2.2 gelten gleichermaßen für Anbieter von Cloud-Diensten. Was der Anbieter davon tatsächlich schuldet, entscheidet sein Vertrag.

Verbindlichkeitssprache. MUST und MUST NOT bezeichnen Baseline-Controls (baseline controls, also Mindestmaßnahmen); ihre Nichtanwendung muss der Accreditation Authority, der für die Akkreditierung eines Systems zuständigen Stelle oder Person, im Zertifizierungsprozess nachvollziehbar begründet werden, bevor eine Ausnahme genehmigt wird (1.1.45, 1.1.46). SHOULD und SHOULD NOT bezeichnen gute und empfohlene Praxis; auch deren Nichtanwendung verlangt eine dokumentierte Abwägung, und das Restrisiko erkennt die Accreditation Authority an (1.1.47 bis 1.1.49). Jede Control trägt außerdem einen Einstufungsbereich. Das ist im Cloud-Abschnitt 20.1 wichtig: Die Muss-Control, nach der die Behörde sicherstellt, dass Cloud-Anbieter die Maßnahmen des NZISM auf ihre Systeme anwenden, trägt nur die Einstufungen CONFIDENTIAL, SECRET und TOP SECRET. Für alle Einstufungen steht daneben die Soll-Control, eine förmliche Zusicherung (formal assurance) einzuholen, dass der Anbieter diese Maßnahmen anwendet (20.1.20). Zertifizierung und Akkreditierung gelten auch für Cloud-Dienste (23.1.10); Einzelheiten in nzism-003.

Verantwortung bleibt bei der Behörde. Das NZISM sagt an mehreren Stellen dasselbe: Betrieb, Verwaltung und Pflege von Maßnahmen lassen sich an einen Anbieter auslagern, die Rechenschaft für den Schutz der Daten nicht, nach 2.3.16 ausdrücklich auch nicht bei Stilllegung oder Vertragsende (ebenso 20.1.9). Governance lässt sich nach 23.2.5 nie auslagern, die Behörde trägt nach 23.2.6 und 23.2.16 die Risiken und muss sicherstellen, dass der Anbieter angemessene Schutzmaßnahmen hat. Für den Anbieter folgt daraus, dass die Behörde Nachweise nicht als Höflichkeit erbittet, sondern für ihre eigene Risikoannahme braucht.

Einstufungsgrenzen. Öffentliche Cloud: höchstens RESTRICTED (23.1.30); Behörden dürfen öffentliche Cloud-Dienste nicht für CONFIDENTIAL, SECRET oder TOP SECRET akkreditieren und nicht für NZEO-Informationen (23.2.16). Nach Darstellung des NZISM richtet die Kabinettsanweisung CAB Min (13) 37/6B, dass keine Daten über RESTRICTED in einer öffentlichen Cloud gehalten werden, gleich ob im Inland oder im Ausland gehostet (20.1.8, 23.1.11); der Wortlaut der Anweisung liegt nicht vor. Für CONFIDENTIAL und höher gilt nach 20.1.20: Die Nutzung von Cloud-Diensten und -Infrastrukturen muss der GCSB genehmigen, und öffentliche, hybride mit öffentlichem Anteil und andere externe Cloud-Dienste scheiden aus; im Ausland gehostete Dienste scheiden nach 20.1.22 ebenfalls aus. NZEO ist eine Zusatzkennzeichnung, die nach 13.4.7 auf jeder Einstufungsstufe zusätzlichen Schutz verlangt; für sie gelten die Verbote für öffentliche und hybride Cloud mit öffentlichem Anteil und für Auslandshosting bei allen Einstufungen. Auf welche Dienste sich Kapitel 23 bezieht, beschreibt 23.1.16 anhand von Merkmalen wie fremder Infrastruktur, Mandantenfähigkeit mit Erreichbarkeit aus dem Internet, automatisierter Bereitstellung durch den Kunden und einer definierten Verantwortungsmatrix; eine einheitliche Definition gibt es nach 23.1.15 nicht. Kapitel 23 erfasst öffentliche Cloud-Elemente unabhängig vom primären Bereitstellungsmodell, also auch eine Private Cloud auf öffentlicher Infrastruktur sowie Multi- und Hybrid-Cloud (23.1.13, 23.1.14).

Hosting außerhalb Neuseelands. Maßgeblich für die Einordnung ist 23.2.7: Es spricht von Diensten, die außerhalb Neuseelands gehostet oder von dort aus verwaltet werden, und ordnet ihnen Rechtsraum-, Datensouveränitäts- und Datenschutzrisiken zu; einen eigenen Eintrag für „offshore“ enthält das Glossar der Begriffe (24.2) nicht. Für im Ausland gehostete Dienste muss die Behörde diese Risiken vollständig berücksichtigen und durch Agency Head oder Chief Executive (Behördenleitung) und Accreditation Authority förmlich annehmen lassen und im Vertrag sicherstellen, dass sie Eigentümerin ihrer Informationen bleibt; ist der Dienst an ressortübergreifende (All-of-Government) Systeme angebunden, braucht sie zudem eine Risikobewertung, die Annahme der Restrisiken und das vom GCDO verlangte Billigungsverfahren (20.1.22). Empfohlen ist (SHOULD NOT … unless), im Ausland gehostete Dienste nur zu nutzen, wenn die Behörde Datenschutz, Sensibilität und Wert der Informationen vollständig bewertet, eine umfassende Risikobewertung durchgeführt und Maßnahmen gegen die erkannten Risiken festgelegt hat und der Anbieter vor Nutzungsbeginn angemessen zusichern kann, dass diese Maßnahmen ordnungsgemäß umgesetzt sind. Nach den Erläuterungen in 20.1.22 lassen sich die meisten Rechtsraum-, Souveränitäts- und Datenschutzrisiken mit heute verfügbaren Maßnahmen nicht angemessen beherrschen und müssen deshalb vor der Einführung von der Behördenleitung sorgfältig abgewogen und angenommen werden. Ein Hosting in Neuseeland beseitigt das nicht vollständig: Auslandseigene Anbieter unterliegen neuseeländischem Recht, können aber zugleich ausländischen Datenschutz-, Zugriffs- und Abhörgesetzen unterliegen, die nach 23.2.7 mit neuseeländischem Recht kollidieren können; Support durch Technikpersonal im Ausland ist ein weiteres Risiko (20.1.22, 20.1.24, 23.4.4). Dazu empfiehlt das NZISM Trennungs- und Zugriffsmaßnahmen bei Support aus dem Ausland, Maßnahmen zum Erkennen und Verhindern unberechtigter sowie mehrfacher oder umfangreicher Datenübertragungen ins Ausland und die Prüfung von Verschlüsselung bei Übertragung und Speicherung (20.1.24). Der Datenort hindert für sich genommen nicht, Daten dort abzulegen (23.4.11); die Behörde muss ihn aber kennen. Außerhalb der Cloud-Abschnitte empfiehlt 2.2.5 (SHOULD NOT), keine Dienstleister für ausgelagerte IT-Leistungen außer Haus in Ländern einzusetzen, mit denen Neuseeland kein multilaterales oder bilaterales Sicherheitsabkommen zum Schutz eingestufter neuseeländischer Regierungsinformationen hat, und im Zweifel den CISO der Behörde zu fragen. Mit welchen Ländern solche Abkommen bestehen, sagt das NZISM nicht.

Risikobewertung und Freigabe bei der Behörde. Vor Einführung oder Nutzung muss die Behörde eine umfassende Risikobewertung nach den Vorgaben des GCDO durchführen und Vertrauensgrenzen festlegen; entlang dieser Grenzen muss sie bestimmen, ob die Verantwortung für Umsetzung, Verwaltung und Pflege der Maßnahmen bei ihr oder beim Anbieter liegt (2.3.27, 20.1.21). Die Cloud-Risiken muss sie durch Behördenleitung (in 20.1.21 auch deren förmlich Beauftragte) und Accreditation Authority förmlich annehmen lassen, den GCDO konsultieren und das vom GCDO verlangte Billigungsverfahren durchlaufen; bei Diensten für mehrere Behörden müssen alle Beteiligten Risiken, Maßnahmen und Restrisiken förmlich vereinbaren (20.1.21). Für öffentliche Cloud kommt hinzu, dass sie ihren Risikoprozess anpassen und für jeden Dienst eine cloudspezifische Bewertung nach dem GCDO-Verfahren durchführen muss (23.2.16). Inhalt und Fragen dieses Verfahrens stehen nicht im NZISM und liegen nicht vor. Bevor sie Einzelverträge aushandelt, muss die Behörde bestehende ressortübergreifende Verträge mit Cloud-Anbietern in Betracht ziehen (2.3.29); welche das sind, nennt das NZISM nicht. Für die Einführung öffentlicher Cloud muss sie einen Plan haben, der unter anderem Modelle geteilter Verantwortung, Wiederherstellung von Daten bei Vertragsende und eine Exit-Strategie behandeln soll (2.3.25).

Geteilte Verantwortung und Sicherheitsgrenzen. Vor der Nutzung muss die Behörde für jeden genutzten Dienst die Sicherheitsverantwortung des Anbieters und ihre eigene klar erkennen und verstehen; dokumentieren und ihre Prozesse daraufhin überprüfen soll sie (23.1.55). Ein einheitliches Modell gibt es nach 23.1.18 nicht, und es darf nach 23.1.20 keine Lücke bleiben. Die Grenzen von Einstufung, Sicherheitsdomäne und Vertrauenszone muss sie vor der Einführung kennen, und wird der Zugriff auf ihre Instanz über mehrere Identitätssysteme unter verschiedenen Sicherheitsrichtlinien gesteuert, muss sie diese Instanz als eigene Sicherheitsdomäne behandeln (23.1.54). Im erläuternden Teil weist das NZISM darauf hin, dass Dritten Zugang zu den Verwaltungsdiensten eines Mandanten gegeben werden kann, und empfiehlt dort nachdrücklich Funktionstrennung (23.1.39, 23.1.40).

Vertragsinhalte. Muss-Inhalte nach 20.1: Service-Level-, Verfügbarkeits-, Wiederherstellbarkeits- und Wiederanlaufregeln; Vorkehrungen für Fusion, Übernahme, Liquidation oder Insolvenz des Anbieters und eine anschließende Beendigung der Dienste; Leistungen zur Vorfallsbehandlung; ein Lösch- oder Bereinigungsprozess, der unabhängig überprüfbar sein muss (20.1.23, 20.1.25, 20.1.26); bei Auslandshosting das Eigentum der Behörde an ihren Informationen (20.1.22). Empfohlen ist eine Regelung zur sicheren Rückgabe der Daten bei Beendigung (2.3.30). Nach 23.2.10 sollen Cloud-Verträge Datenverantwortung, Datensouveränität, Rechtsraum, Speicherung und Zugriff einschließlich Sicherungen berücksichtigen; vor Abschluss ist Rechtsrat nach 23.2.12 unerlässlich. Das NZISM rechnet damit, dass Anbieter Leistung und Haftung vertraglich begrenzen (20.1.13). Eine Meldefrist des Anbieters für Vorfälle oder eine Ankündigungsfrist für Änderungen nennen die Cloud-Abschnitte nicht.

Zusicherungen. Die Behörde muss Zusicherungen einholen, dass der Anbieter Software und Betriebssysteme angemessen patcht und pflegt und dass technische Vorkehrungen die Mandanten angemessen trennen (23.2.19, 23.2.20); bei Stilllegung muss sie die Zusicherung haben, dass keine behördeneigenen Daten im Dienst verbleiben (23.4.13). Regelmäßige Prüfungen des Anbieters durch einen geeignet qualifizierten Prüfer soll sie einholen (23.2.18), und vom GCSB gebilligte Baseline-Sicherheitsvorlagen soll sie nutzen, wo anwendbar (23.2.21); deren Inhalt liegt nicht vor. 23.2.13 weist darauf hin, dass der Anbieter Plattformänderungen mit wenig oder ohne Vorankündigung vornehmen kann, die die Sicherheitslage und die Akkreditierung berühren. Unabhängige Prüfberichte als Nachweisform behandelt Abschnitt 5.8 (siehe nzism-002).

Daten, Schlüssel und Exit. Die Behörde muss sicherstellen, dass die Schutzmechanismen jedes Dienstes ihren Anforderungen genügen, und ihre Schlüsselverwaltungspläne vor der Speicherung anpassen, einschließlich der Migration aus der Ursprungsumgebung; das NZISM weist darauf hin, dass ein Wechsel Entschlüsseln und Neuverschlüsseln erfordern kann (23.4.9). Dienstendpunkte muss sie nach dem Prinzip minimaler Rechte auf Berechtigte beschränken (23.4.10). Sie muss alle Speicher- und Verarbeitungsorte einschließlich Replikaten und Sicherungen ermitteln und Risiken aus dem Datenort samt Gegenmaßnahmen vor der Einführung dokumentieren (23.4.11), Notfallpläne anpassen und cloudspezifische Wiederherstellung testen (23.4.12) und für jeden Dienst eine Exit-Strategie mit Rückholung und Löschung haben (23.4.13). 20.1.26 verlangt einen Plan für Sicherung, Wiederherstellung und Archivierung und weist darauf hin, dass automatisierte Archivierung in mehreren Ländern den Rechtsraum der Daten unbestimmbar machen kann.

Identitäten und Protokolle. Privilegiert sind in öffentlicher Cloud Identitäten, die über Verwaltungsportale und Programmierschnittstellen Ressourcen anlegen, einsehen, ändern oder löschen (23.3.3). Sind Verwaltungsoberflächen oder -portale aus dem Internet erreichbar, müssen privilegierte Konten Mehrfaktor-Authentisierung nutzen; sind Oberflächen oder Portale des Cloud-Dienstes aus dem Internet erreichbar, ist Mehrfaktor-Authentisierung auch für Nutzerkonten empfohlen, und zwar unabhängig davon, ob die Verwaltung selbst aus dem Internet erreichbar ist (23.3.19). Privilegierte Konten sollen nicht zwischen Umgebungen synchronisiert werden (23.3.18). Austrittsprozesse müssen vor der Einführung so angepasst sein, dass sie den Entzug aller Cloud-Zugänge umfassen, und die Behörde muss sicherstellen, dass vertrauende Dienste die Echtheit der Antworten des Identitätsanbieters fortlaufend prüfen, etwa über kryptografische Signaturen (23.3.20, 23.3.21). Zur Protokollierung muss die Behörde die Protokollfähigkeiten ihres Anbieters kennen und auf Eignung prüfen, die Protokolle sammeln, schützen und ihre Integrität nachweisbar halten und die Protokolle des Anbieters zeitnah in ihre eigene Protokollierung und Alarmierung einbinden (23.5.10 bis 23.5.12). Das NZISM räumt ein, dass Protokollparameter oft nicht anpassbar sind und aus technischen oder Kostengründen nur ein Teil exportiert werden kann (23.5.5).

Zero Trust. Das NZISM empfiehlt Behörden, Zero-Trust-Grundsätze bei der Einführung öffentlicher Cloud aufzunehmen und bei Migrationen native Sicherheitsdienste der Plattform zu nutzen, statt alte Perimeterarchitekturen nachzubauen (2.3.26). Das ist eine Soll-Empfehlung, keine Muss-Vorgabe.

Verteiltes Arbeiten und fremde Endgeräte. Kapitel 22 regelt die Arbeit außerhalb des Büros und mit mobilen sowie nicht behördeneigenen Geräten. Für Mitarbeitende eines Dienstleisters schlägt 22.4.10 die Brücke: Die BYOD-Regelung der Behörde muss Vorkehrungen für Auftragnehmer und andere befugte Nichtbeschäftigte treffen, ob deren Teilnahme erlaubt wird, liegt im Ermessen der Behörde, und die Risikobewertung muss das berücksichtigen. Einen Glossareintrag für „personnel“ enthält 24.2 nicht; ob Dienstleisterpersonal unter die übrigen Personalvorgaben von Kapitel 22 fällt, klärt in der Praxis der Vertrag mit der Behörde. BYOD darf nur für Systeme bis einschließlich RESTRICTED zugelassen werden (22.4.8). Verlangt sind unter anderem eine von jeder nutzenden Person unterzeichnete Nutzungsrichtlinie, eine schriftliche Genehmigung vor der Anbindung, Verfahren zur Entfernung von Behördensoftware und -daten, wenn die Nutzung endet, und eine Vereinbarung über das Eigentum an den Daten (22.4.10). Technisch gehören dazu eine Geräteverwaltung (Mobile Device Management), die bei Verlust oder Diebstahl Behördendaten löschen kann und, wenn sie Behörden- und persönliche Daten nicht unterscheiden kann, alle Daten löscht, außerdem eine Liste zugelassener Cloud-Anwendungen und die Sperre nicht zugelassener Cloud-Anwendungen für Behördendaten (22.4.11), Verschlüsselung bei Übertragung und Speicherung, VPN ohne Split Tunnelling und nicht dauerhafte Container je Sitzung (22.4.13). Wer Geräte von der Behörde gestellt bekommt, fällt unter 22.1; dort sind etwa eine Nutzungsrichtlinie und das Abschalten von Split Tunnelling verlangt. Auf Reisen mit behördeneigenen Geräten muss das Personal die Kontrolle über Geräte und Datenträger behalten, sie also weder ins aufgegebene Gepäck geben noch unbeaufsichtigt lassen, und muss eine mögliche Kompromittierung so bald wie möglich einem ITSM (Information Technology Security Manager, siehe nzism-003) melden, wenn der Grenzschutz die Entschlüsselung verlangt oder das Gerät außer Sicht nimmt (22.2.7). Für die Arbeit von zu Hause verweist das NZISM auf die Mindestanforderungen der Protective Security Requirements (PSR) an die physische Sicherheit (22.3); diese liegen nicht vor.

Umsetzungsperspektive

Der Anbieter beginnt mit der Einstufungsfrage. Er klärt mit dem Kunden, welche Einstufungen und Zusatzkennzeichnungen die Daten tragen werden, und hält schriftlich fest, dass sein Dienst als öffentlicher oder im Ausland gehosteter Dienst nicht für CONFIDENTIAL und höher und nicht für NZEO-Informationen vorgesehen ist. Die Einstufung selbst nimmt der Kunde vor, nicht der Anbieter.

Danach baut er ein Antwortpaket, das genau die Fragen bedient, die die Behörde nach 20.1 und Kapitel 23 selbst beantworten muss. Dazu gehören ein Verzeichnis der Speicher- und Verarbeitungsorte einschließlich Replikaten, Sicherungen und Archiven, die Standorte der Supportteams und ihre Zugriffswege, eine Beschreibung der geteilten Verantwortung je Dienst, Nachweise zu Patching und Mandantentrennung, eine Beschreibung der Protokollfähigkeiten samt Exportwegen und ein dokumentierter, von Dritten überprüfbarer Lösch- und Rückgabeprozess. Je klarer diese Angaben sind, desto eher kann die Behörde ihre Risikobewertung abschließen und die Risiken förmlich annehmen.

Im Vertrag rechnet er mit den Muss-Inhalten aus 20.1 und bereitet Klauseln vor, die er ohne lange Verhandlung zusagen kann: Service-Level und Wiederanlauf, Fortführung oder geordnete Beendigung bei Fusion, Übernahme oder Insolvenz, Leistungen zur Vorfallsbehandlung, Löschung mit Nachweis, Eigentum der Behörde an ihren Informationen. Wo er Haftung begrenzt, rechnet er damit, dass die Behörde nachfragt.

Für Personal mit Zugriff auf Behördensysteme entscheidet er vor Vertragsschluss, ob Geräte der Behörde oder eigene Geräte unter dem BYOD-Regime der Behörde genutzt werden, und klärt die Folgen für die eigene Geräteverwaltung. Reisen mit Behördengeräten plant er mit der Vorgabe aus 22.2.7, Entschlüsselungsverlangen oder Ansichnahme durch den Grenzschutz dem ITSM zu melden.

Rechtsfragen zu neuseeländischem Recht, zu Datenschutz in Neuseeland und zu ausländischen Zugriffsgesetzen klärt er mit neuseeländischer Rechtsberatung. Ob für personenbezogene Daten daneben die DSGVO gilt und was sie für die Übermittlung verlangt, beurteilt sich aus EU-Sicht (siehe dsgvo-005).

Typische Fehler

• EU-Hosting als Antwort auf eine neuseeländische Frage. Für das NZISM ist ein Rechenzentrum in Deutschland Auslandshosting mit Rechtsraumrisiko, nicht ein Pluspunkt.
• Soll-Vorgaben als unverbindlich abtun. Die Empfehlung, Auslandshosting nur unter vier Voraussetzungen zu nutzen, ist SHOULD NOT; eine Abweichung verlangt beim Kunden eine dokumentierte Abwägung und die Anerkennung des Restrisikos durch die Accreditation Authority.
• „NZISM-konform“ versprechen. Die Cloud-Abschnitte kennen kein Zertifikat für Anbieter; Zertifizierung und Akkreditierung sind nach 23.1.10 Vorgänge der Behörde für ihre Systeme und Dienste.
• Nur den Primärstandort nennen. Die Behörde muss Replikate und Sicherungen kennen; Archive und Supportzugriffe aus dem Ausland gehören in dieselbe Antwort.
• Löschung zusagen, ohne sie nachweisen zu können. Der Lösch- oder Bereinigungsprozess muss unabhängig überprüfbar sein.
• Fremde Identitäten anbinden, ohne die Folge zu kennen. Mehrere Identitätssysteme unter verschiedenen Richtlinien machen die Instanz zur eigenen Sicherheitsdomäne.
• Firmen-Notebooks des Dienstleisters wie Behördengeräte behandeln. Für Geräte, die nicht zugleich unmittelbar im Eigentum und unter der Kontrolle der Behörde stehen, verlangt 22.1.12 den vollen Satz der BYOD-Maßnahmen, einschließlich einer Geräteverwaltung, die bei Verlust oder Diebstahl im Zweifel alle Daten löscht.
• Querverweisen blind folgen. Einige Querverweise in 2.3, 22 und 23 nennen Nummern, die nicht zur Gliederung dieser Ausgabe passen (siehe Normreferenzen); wer nach „22.1 Cloud Computing“ sucht, landet bei mobilen Geräten.

Risiken und Trade-offs

Hosting in Neuseeland nimmt dem Kunden die Prüfung nach den Regeln für im Ausland gehostete Dienste ab, beseitigt aber nicht das Risiko aus ausländischem Recht, dem der Anbieter als ausländisches Unternehmen unterliegen kann, und nicht das Risiko aus Support von außerhalb. Hosting in Deutschland hält den Betrieb einfach, verlagert aber Arbeit in die Risikobewertung und Risikoannahme des Kunden.

Vom Kunden verwaltete Schlüssel stärken seine Kontrolle, binden die Daten aber an die Umgebung und erschweren den Wechsel; das NZISM verlangt deshalb, die Migration im Schlüsselplan vorzusehen.

Eine Geräteverwaltung der Behörde auf Firmengeräten des Dienstleisters gehört zum BYOD-Regime, kann aber im Verlustfall auch Daten des Dienstleisters löschen und kollidiert mit dessen eigener Geräteverwaltung. Von der Behörde gestellte Geräte vermeiden das, unterliegen dann aber 22.1.

Umfassender Protokollexport erleichtert dem Kunden die Pflicht zur Einbindung, kostet aber, und das NZISM erkennt an, dass nicht alles exportierbar ist. Was fehlt, muss der Kunde in seiner Bewertung tragen.

Häufige Plattformänderungen sind Teil des Cloud-Modells, können beim Kunden aber Zertifizierung und Akkreditierung berühren. Eine Vorankündigung erleichtert ihm das, auch wenn das NZISM keine Frist nennt.

Entscheidungspunkte

• Für welche Einstufungen bieten wir den Dienst an, und wie dokumentieren wir den Ausschluss von CONFIDENTIAL und höher sowie von NZEO?
• Hosten wir in Neuseeland, in Deutschland oder anderswo, und wo liegen Replikate, Sicherungen, Archive und Supportzugriffe?
• Welche Zusicherungen zu Patching, Mandantentrennung und Datenverbleib liefern wir, durch wen geprüft und in welchem Rhythmus?
• Wie weisen wir Löschung und Rückgabe so nach, dass ein Dritter sie überprüfen kann?
• Arbeiten unsere Administratoren mit Behördenidentitäten oder mit föderierten eigenen Identitäten, und auf welchen Geräten?
• Welche Protokolle stellen wir in welchem Format und wie schnell bereit, und zu welchen Kosten?
• Welche Vertragsregeln zu Insolvenz, Übernahme und Vertragsende sagen wir standardmäßig zu?

Praktische Empfehlungen

1. Einstufungsgrenze in den Vertrieb einbauen. Vor jedem Angebot klären, welche Einstufungen und Kennzeichnungen die Daten tragen; Anfragen für CONFIDENTIAL und höher oder NZEO bei öffentlicher oder ausländisch gehosteter Bereitstellung nicht annehmen.
2. Datenort vollständig beschreiben. Ein gepflegtes Verzeichnis aller Orte für Speicherung, Verarbeitung, Replikate, Sicherungen und Archive sowie aller Supportstandorte mit Zugriffsart.
3. Verantwortungsmatrix je Dienst liefern. Wer welche Maßnahme betreibt, ohne Lücke, abgestimmt auf die Grenzen, die der Kunde festlegen muss.
4. Exit vor dem Start beschreiben. Rückgabeformat, Ablauf der Löschung, unabhängige Überprüfbarkeit und die Schlüsselmigration.
5. Vertragsbaustein für neuseeländische Behörden vorbereiten. Mit den Muss-Inhalten aus 20.1 und dem Eigentum der Behörde an ihren Informationen; vor Abschluss neuseeländische Rechtsberatung einholen.
6. Privilegierte Zugänge härten. Mehrfaktor für alle Verwaltungszugänge (das NZISM verlangt es, wo Verwaltungsoberflächen aus dem Internet erreichbar sind), getrennte privilegierte Konten je Umgebung, zeitnaher Entzug beim Austritt, signierte Authentisierungsantworten.
7. Gerätemodell für Personal festlegen. Entweder Behördengeräte oder eigene Geräte unter dem BYOD-Regime der Behörde, mit unterschriebener Nutzungsrichtlinie und schriftlicher Genehmigung; Reiseregeln für Neuseeland-Einsätze.
8. Keine Gleichwertigkeit behaupten. ISO-27001-Zertifikat, Prüfberichte und eigene Kontrollen als Nachweise für einzelne Fragen anbieten, nicht als Erfüllung des NZISM.

Relevante Normreferenzen

• NZISM 3.9 (November 2025), Abschnitt 2.3 (Nutzung von Cloud-Diensten: Verantwortung, Einführungsplan, Zero Trust, Risikobewertung, ressortübergreifende Verträge, Rückgabe bei Beendigung); Abschnitt 20.1 im Kapitel 20 „Enterprise systems security“ (Cloud Computing: Anwendbarkeit nach Einstufung, Risikobewertung und Vertrauensgrenzen, Auslandshosting, Verfügbarkeit, unbefugter Zugriff, Vorfälle, Sicherung, Archivierung und Datenremanenz, Schulung).
• Kapitel 23 „Public Cloud Security“: 23.1 (Grundbegriffe, Merkmale öffentlicher Cloud, geteilte Verantwortung, Sicherheitsgrenzen), 23.2 (Governance, Risikobewertung und Zusicherungen), 23.3 (Identitäten und Zugriff), 23.4 (Datenschutz über den Lebenszyklus, Datenort, Exit), 23.5 (Protokollierung und Alarmierung).
• Kapitel 22 „Distributed Working“: 22.1 (behördeneigene mobile Geräte), 22.2 (Arbeit außerhalb des Büros, Reisen), 22.3 (Arbeit von zu Hause), 22.4 (nicht behördeneigene Geräte und BYOD).
• Bezugsstellen außerhalb des Zuschnitts, nur soweit zitiert: 1.1.45 bis 1.1.49 (Verbindlichkeitssprache), 1.2.3 und 1.2.6 (Geltung, Rechtsnatur), 2.2.3 und 2.2.5 (Cloud als Auslagerung, Länder ohne Sicherheitsabkommen), 13.4.7 (NZEO).
• Querverweise der Quelle: 2.3.5 verweist für Cloud Computing auf Abschnitt 22.1, der in dieser Ausgabe mobile Geräte behandelt (Cloud Computing ist 20.1); 22.1.12 verweist für BYOD auf 21.4 (in dieser Ausgabe 22.4); 22.2, 22.3 und 22.4 verweisen auf Abschnitte 21.1 und 21.3, und 2.3.4, 23.1 und 23.4 führen Datenmanagement als Kapitel 20 und verteiltes Arbeiten als Kapitel 21. Maßgeblich ist die Gliederung der Ausgabe: Kapitel 20 Enterprise systems security, 21 Data management, 22 Distributed Working, 23 Public Cloud Security.
• Abgrenzung: Das australische Gegenstück zu Auslagerung, Managed Services und Cloud steht in ism-australien-005; die NIST-Rahmenwerke selbst, darunter Zero Trust nach NIST SP 800-207 (nist-zt-019), stehen im nist-Track, während das NZISM von NIST hier nur die Cloud-Begriffe aus SP 800-145 übernimmt; das deutsche Rahmenwerk IT-Grundschutz steht im it-grundschutz-Track und die CIS Controls im cis-Track. Hier steht nur, was das NZISM selbst zu Cloud, Auslagerung und fremden Endgeräten sagt. Innerhalb dieses Tracks: Rahmenwerk und Einstufungsstufen in nzism-001, Geltung für Dienstleister, Abschnitt 2.2, Abweichungsverfahren und Prüfberichte nach 5.8 in nzism-002, Zertifizierung und Akkreditierung in nzism-003, Vorfälle und Lieferkette in nzism-004, Virtualisierung, Zugriff und Protokollierung allgemein in nzism-006.