ENS in der Cloud: Anforderungen und CCN-STIC-Leitfaden 823.

Kurz zusammengefasst: Ja, das ENS (spanisches nationales Sicherheitssystem) lässt sich auch in der Cloud erfüllen – aber es reicht nicht, einen „sicheren“ Anbieter zu beauftragen. Maßgeblich ist der CCN-STIC-Leitfaden 823 (Nutzung von Cloud-Diensten); die Maßnahme op.nub.1 aus Anhang II verpflichtet Sie dazu, vom Anbieter Konformität entsprechend dem Servicemodell (SaaS, PaaS, IaaS) einzufordern, während die Behörde im Modell der geteilten Verantwortung weiterhin für ihren eigenen Teil verantwortlich bleibt.

Das ENS lässt sich in der Cloud erfüllen, und immer mehr Ausschreibungsunterlagen verlangen es ausdrücklich. Das Rückgrat bilden der CCN-STIC-Leitfaden 823 und die Maßnahme op.nub.1 „Schutz der Cloud-Dienste“ aus Anhang II des Königlichen Dekrets 311/2022, die je nach Servicemodell auf die entsprechenden CCN-STIC-Leitfäden verweist. Die Regel, die sich nie ändert: Die Stelle, der die Information gehört, bleibt verantwortlich, auch wenn sie den Betrieb an einen Dritten auslagert. Hier trenne ich die beiden Perspektiven — die Verwaltung, die Cloud-Dienste nutzt, und das SaaS-Unternehmen, das an sie verkaufen will —, erkläre das Modell der geteilten Verantwortung aus ENS-Sicht, die Compliance-Profile CCN-STIC 884-887 der Hyperscaler, die Rolle des CPSTIC-Katalogs und die Schritte für einen Anbieter, der bei null anfängt.

Dieser Artikel behandelt eine konkrete Frage: wie sich das ENS in der Cloud erfüllen lässt. Das ist nicht dasselbe wie Cloud-Sicherheit im Allgemeinen. Wer wissen möchte, wie sich die Daten seines Unternehmens in der Cloud schützen lassen — Verschlüsselung, Backups, Zugriffskontrolle, DSGVO —, findet das in meinem Leitfaden zur Cloud-Sicherheit für Unternehmen. Hier geht es um etwas Spezifischeres und Anspruchsvolleres: die Erfüllung des Esquema Nacional de Seguridad, wenn der Dienst in der Cloud läuft, mit dem CCN-STIC-Leitfaden 823 als Referenz und dem öffentlichen Sektor als Auftraggeber. Ich betrachte das sowohl aus der Sicht der Behörde, die migrieren möchte, als auch aus der Sicht des SaaS-Anbieters, der in eine Ausschreibung einsteigen will.

Kann man das ENS in der Cloud erfüllen? (kurze Antwort)

Ja, und das ist keine Auslegungssache: Das ENS sieht es selbst ausdrücklich vor. Diese fünf Punkte fassen den Rest des Artikels zusammen:

• Es gibt einen eigenen Leitfaden. Der CCN-STIC-Leitfaden 823 regelt die Nutzung von Cloud-Diensten im Anwendungsbereich des ENS: Servicemodelle, Bereitstellungsmodelle und die Bedingungen, unter denen Cloud-Dienste mit Garantien genutzt werden können.
• Es gibt eine eigene Maßnahme. Die Maßnahmenfamilie op.nub aus Anhang II — konkret op.nub.1, „Schutz der Cloud-Dienste“ — gilt bereits ab der Kategorie BASIS und schreibt vor, dass der Cloud-Dienst entweder das ENS erfüllt oder die Maßnahmen des entsprechenden CCN-STIC-Leitfadens einhält.
• Die Verantwortung lässt sich nicht auslagern. Die Stelle, der die Information gehört, bleibt für die Erfüllung verantwortlich, auch wenn sie einen Dritten beauftragt.
• Die großen Anbieter haben bereits Vorarbeit geleistet. Azure, Microsoft 365 und AWS verfügen über CCN-STIC-Compliance-Profile (884, 885, 887) — die decken jedoch nur ihren eigenen Teil ab, nicht Ihren.
• Die Konformität muss nachgewiesen werden. In der Kategorie BASIS per Konformitätserklärung, in MITTEL und HOCH per Zertifizierung — mit einem Geltungsbereich, der den tatsächlich erbrachten Dienst wirklich abdecken muss.

Der Rest des Artikels vertieft jeden dieser Punkte und übersetzt ihn in konkrete Entscheidungen — je nachdem, ob Sie auf der Seite des öffentlichen Käufers oder auf der des Anbieters stehen.

Was ist der CCN-STIC-Leitfaden 823 und was regelt er?

Der CCN-STIC-Leitfaden 823, „Nutzung von Cloud-Diensten“, gehört zur 800er-Serie des Nationalen Kryptologiezentrums (CCN, Centro Criptológico Nacional) und überträgt das ENS auf Cloud-Umgebungen. Er entstand aus einem realen Problem: Anhang II wurde für Systeme konzipiert, bei denen die Organisation die Infrastruktur selbst kontrolliert — in der Cloud teilt sich diese Kontrolle mit dem Anbieter. Der Leitfaden übersetzt diese Aufteilung in operative Kriterien.

Was der Leitfaden 823 in der Praxis regelt:

• Servicemodelle. Er unterscheidet IaaS (der Kunde kontrolliert Betriebssysteme, Speicher und Anwendungen), PaaS (er kontrolliert die Anwendungen, nicht die Infrastruktur) und SaaS (er nutzt die Software, ohne die Plattform zu verwalten). Je „weiter oben“ der Dienst angesiedelt ist, desto mehr Verantwortung übernimmt der Anbieter.
• Bereitstellungsmodelle. Öffentliche, private, gemeinschaftliche und hybride Cloud — jede mit unterschiedlichen Auswirkungen auf Isolation und Kontrolle.
• Sicherheitsniveaus und -dimensionen. Der Dienst wird anhand der fünf Sicherheitsdimensionen des ENS bewertet — Verfügbarkeit, Integrität, Vertraulichkeit, Authentizität und Nachvollziehbarkeit — und erhält ein Niveau, aus dem sich die erforderlichen Maßnahmen ergeben.
• Was Sie vertraglich vom Anbieter verlangen sollten. Beschreibung des Dienstes, Sicherheitsniveaus, Standort der Daten, Verfahren für Backup und Löschung sowie Konformität mit den Maßnahmen aus Anhang II entsprechend der Kategorisierung.

Eine hilfreiche Nuance des Leitfadens: Wenn Sie die Information verschlüsseln, bevor Sie sie in die Cloud übertragen, und die Schlüssel selbst verwalten, konzentrieren sich viele der Anforderungen an den Anbieter auf die Dimension Verfügbarkeit, weil der Anbieter keinen Zugriff auf den Inhalt hat. Das beseitigt keine Pflichten, verschiebt aber den Schwerpunkt.

Die Maßnahme op.nub aus Anhang II: was sie in der Cloud vorschreibt

Mit dem Königlichen Dekret 311/2022 hielt eine neue Maßnahmenfamilie Einzug in Anhang II, innerhalb des operativen Rahmens: op.nub, Cloud-Dienste. Damit behandelt das ENS die Cloud nicht mehr als Sonderfall der „externen Dienste“, sondern gibt ihr einen eigenständigen Status.

Die Maßnahme op.nub.1, „Schutz der Cloud-Dienste“, gilt bereits ab der Kategorie BASIS — also in allen Kategorien — und besagt Folgendes: Systeme, die dem öffentlichen Sektor Cloud-Dienste bereitstellen, müssen die Sicherheitsmaßnahmen entsprechend dem Servicemodell (SaaS, PaaS, IaaS) gemäß den anwendbaren CCN-STIC-Leitfäden einhalten. Und wenn Cloud-Dienste Dritter genutzt werden, müssen die tragenden Systeme entweder mit dem ENS konform sein oder die Maßnahmen eines CCN-STIC-Leitfadens erfüllen, der unter anderem Anforderungen an Auditnachweise enthält.

Die praktische Konsequenz ist zweifach. Für die Behörde macht op.nub.1 aus „Cloud beschaffen“ ein „konforme Cloud beschaffen“: Die Anforderung ist nicht mehr optional. Für den Anbieter setzt sie den Maßstab, den er nachweisen muss. Und da die Maßnahme selbst auf die CCN-STIC-Leitfäden verweist, werden der Leitfaden 823 und die plattformspezifischen Profile vom bloßen Ratschlag zum erwarteten Weg.

Geteilte Verantwortung: was Sie delegieren können und was nicht

Am Modell der geteilten Verantwortung scheitern die meisten Projekte. Der CCN-STIC-Leitfaden 823 wiederholt einen klaren Grundsatz: Die Verantwortung für die Erfüllung des ENS liegt immer bei der Stelle, der die Information gehört. Sie können den Betrieb delegieren — die Verantwortung nicht.

Wo genau die Grenze zwischen dem, was der Anbieter übernimmt, und dem, was bei Ihnen bleibt, verläuft, hängt vom Servicemodell ab:

• Bei IaaS ist der Anbieter für das Rechenzentrum, die Virtualisierung und die physische Verfügbarkeit verantwortlich; Sie sind ab dem Betriebssystem aufwärts verantwortlich: Patches, Konfiguration, Identitäten, Daten.
• Bei PaaS übernimmt der Anbieter eine Stufe mehr und verwaltet die Plattform; Sie bleiben verantwortlich für die Anwendung, deren Zugriffe und die Information.
• Bei SaaS übernimmt der Anbieter fast den gesamten technischen Stack, aber Sie bleiben stets verantwortlich für die Identitätsverwaltung, die Konfiguration des Dienstes, die Klassifizierung der Information und deren Lebenszyklus.

In allen drei Modellen gibt es eine Konstante: Identität, Konfiguration und Daten bleiben so gut wie immer auf Ihrer Seite. Der klassische Fehler ist die Annahme: „Der Anbieter hat das ENS, also erfülle ich es auch schon.“ Nein: Seine Konformität deckt nur seinen Teil der Aufteilung ab. Ihren Teil müssen Sie weiterhin selbst umsetzen und nachweisen.

Wenn Sie eine Behörde sind: wie Sie ENS-konforme Cloud-Dienste beschaffen

Wenn eine Behörde Cloud-Dienste nutzen möchte, ohne aus dem ENS auszuscheren, beginnt die Arbeit schon vor der Anbieterauswahl. Die Reihenfolge, die ich empfehle:

• Kategorisieren Sie zuerst das System. Bewerten Sie Information und Dienste in den fünf Dimensionen und legen Sie die Kategorie fest (BASIS, MITTEL oder HOCH). Diese Kategorie bestimmt, was Sie von der Cloud verlangen können.
• Übertragen Sie die Kategorie in die Ausschreibungsunterlagen. Verlangen Sie nicht „einen Anbieter mit ENS“, sondern Konformität in der entsprechenden Kategorie und mit einem Geltungsbereich, der genau den Dienst abdeckt, den Sie nutzen werden — nicht eine andere Einheit des Anbieters.
• Legen Sie den Standort der Daten fest. Verlangen Sie je nach Kategorie und Art der Information eine Verarbeitung in der EU und, wo erforderlich, auf nationalem Staatsgebiet, mit vertraglich geklärter Gerichtsbarkeit.
• Halten Sie Ihre eigenen Verantwortlichkeiten fest. Dokumentieren Sie schriftlich, welche Maßnahmen Sie selbst umsetzen (Identität, Verschlüsselung mit Schlüsseln unter eigener Kontrolle, Aktivitätsprotokollierung, Kontinuität) und welche der Anbieter übernimmt.
• Verlangen Sie auditierbare Nachweise. Konformitätsberichte, zugängliche Protokolle und Ergebnisse der Auditnachweise, die op.nub.1 selbst erwähnt.

Wenn Sie Ihren Anbietern das ENS in einer Ausschreibung vorschreiben wollen, sollten Sie vorher klären, wer das ENS erfüllen muss und unter welchen Bedingungen, um weder zu viel noch zu wenig zu verlangen.

Wenn Sie ein SaaS- oder Cloud-Anbieter sind: wie Sie mit dem ENS an die Verwaltung verkaufen

Von der anderen Seite des Tisches aus stellt sich eine andere Frage: Was brauche ich, damit mich eine öffentliche Stelle beauftragen kann, ohne gegen das ENS zu verstoßen? Die kurze Antwort: Sie müssen die ENS-Konformität Ihres Dienstes in der von den Ausschreibungsunterlagen geforderten Kategorie nachweisen und den Geltungsbereich klar definieren.

Was in der Praxis meist den Unterschied macht:

• Geltungsbereich der Erklärung oder Zertifizierung. Das Zertifikat muss den Dienst abdecken, den Sie verkaufen, und die Plattform, von der aus Sie ihn erbringen. Ein echtes Zertifikat, dessen Geltungsbereich Ihr Produkt nicht einschließt, nützt Ihnen bei einer Ausschreibung nichts.
• Die passende Kategorie. BASIS lässt sich per Konformitätserklärung nachweisen; MITTEL und HOCH erfordern eine Zertifizierung durch eine akkreditierte Stelle. Richten Sie sich nach der Kategorie, die Ihre öffentlichen Kunden verlangen werden.
• Vererbung von Kontrollen. Wenn Sie sich auf einen Hyperscaler mit CCN-STIC-Profil stützen, können Sie einen Teil seiner Kontrollen übernehmen — Sie müssen aber dokumentieren, was Sie selbst zusätzlich beitragen.
• Ein vorbereitetes Audit. Der Prozess umfasst Auditnachweise; wer mit geordneter Dokumentation und Nachweisen antritt, verkürzt Fristen und Kosten. Den gesamten Ablauf beschreibe ich unter Prozess und Kosten der ENS-Zertifizierung.

Wenn Sie regelmäßig an öffentlichen Ausschreibungen teilnehmen, erkläre ich in ENS für Lieferanten der Verwaltung, wie diese Anforderung in den Ausschreibungsunterlagen auftaucht und wie sie kaskadenartig an Unterauftragnehmer weitergegeben wird.

Cloud-Dienste im CPSTIC-Katalog und die Profile CCN-STIC 884-887

Hier verlieren viele Anbieter den Überblick, weil zwei unterschiedliche Mechanismen nebeneinander bestehen.

Zum einen enthält der CPSTIC-Katalog des CCN eine Taxonomie von Cloud-Diensten: Er listet Produkte und Dienste, die für vom ENS betroffene Systeme in den Kategorien MITTEL und HOCH qualifiziert sind. Dass ein Dienst im CPSTIC geführt wird, gibt dem öffentlichen Käufer ein vom Centro selbst geprüftes Mindestvertrauen. Der Zugang zum vollständigen Katalog erfordert eine Registrierung als CCN-Nutzer.

Zum anderen gibt es die spezifischen Compliance-Profile: CCN-STIC-Leitfäden, die im Detail beschreiben, wie sich ein bestimmter Hyperscaler ENS-konform bereitstellen lässt. Diese sollten Sie kennen:

• CCN-STIC 884 — spezifisches Compliance-Profil für Azure (Corporate-Cloud-Dienst).
• CCN-STIC 885 — Profil für Microsoft 365, mit den zugehörigen Leitfäden für sichere Konfiguration.
• CCN-STIC 886 — Profil für private und gemeinschaftliche Clouds.
• CCN-STIC 887 — spezifisches Compliance-Profil für AWS (Corporate-Cloud-Dienst), mit zugehörigem Konfigurationsleitfaden.

Der Sinn dieser Profile ist, dass Sie nicht bei null anfangen: Wenn Sie auf Azure oder AWS gemäß deren Leitfaden bereitstellen, übernehmen Sie eine bereits erarbeitete Basis an Kontrollen und konzentrieren sich auf Ihren eigenen Teil. Ein Plattformprofil ist jedoch kein Zertifikat für Ihren Dienst: Es belegt, wie die Cloud konform genutzt wird — nicht, dass Ihr SaaS-Produkt konform ist. Diese Unterscheidung erspart in Verhandlungen viele Missverständnisse.

Maßnahmen aus Anhang II mit Cloud-Blick: Verschlüsselung, Daten und Standort

Die Sicherheitsmaßnahmen aus Anhang II ändern sich in der Cloud nicht — wohl aber, wie sie angewendet werden und wer für jede Einzelne verantwortlich ist. Die folgende Tabelle fasst die Cloud-Lesart der Maßnahmen zusammen, die in einem realen Projekt am meisten Gewicht haben.

Die übergreifende Lesart ist wie immer in der Cloud: Der Anbieter stellt die technische Kapazität, Sie stellen die Governance. Verschlüsselung, Identität und Daten bleiben so gut wie immer Ihre Verantwortung, auch wenn die Plattform des Anbieters sie technisch ausführt.

Schritte für ein SaaS-Unternehmen, das bei null anfängt

Wenn Sie ein Produkt haben und es an die Verwaltung verkaufen möchten, sich aber noch nie mit dem ENS befasst haben, funktioniert diese Reihenfolge:

• 1. Grenzen Sie den Geltungsbereich ab. Welcher genaue Dienst soll zertifiziert werden, und auf welcher Infrastruktur läuft er? Alles Weitere hängt von dieser Antwort ab.
• 2. Kategorisieren Sie. Bewerten Sie Ihren Dienst in den fünf Dimensionen und legen Sie die Zielkategorie entsprechend den Anforderungen Ihrer potenziellen Kunden fest.
• 3. Wählen Sie Ihre Cloud-Basis. Wenn Sie sich auf einen Hyperscaler stützen, übernehmen Sie dessen CCN-STIC-Profil (884, 885, 887) und vererben Sie, was sich vererben lässt.
• 4. Risikoanalyse und Erklärung zur Anwendbarkeit. Dokumentieren Sie, welche Maßnahmen aus Anhang II gelten und wie Sie sie abdecken, wobei Sie geerbte von eigenen Maßnahmen unterscheiden.
• 5. Setzen Sie um, was fehlt. Identität, Verschlüsselung, Protokollierung, Kontinuität und Vorfallmanagement auf Ihrer Service-Ebene.
• 6. Auditieren und zertifizieren Sie. Konformitätserklärung in BASIS oder Zertifizierung durch eine akkreditierte Stelle in MITTEL und HOCH, nach bestandener Konformitätsprüfung.

Abkürzungen gibt es nicht, wohl aber eine Reihenfolge, die doppelte Arbeit vermeidet: Geltungsbereich, Kategorie, Vererbung, Dokumentation, Umsetzung und Audit. Den Geltungsbereich am Anfang zu überspringen, ist der Fehler, der am teuersten zu stehen kommt.

Fazit: Die Cloud befreit Sie nicht vom ENS, sie verändert nur die Verteilung.

Die Migration in die Cloud schwächt das ENS nicht ab — sie verteilt lediglich neu, wer was macht. Der CCN-STIC-Leitfaden 823 und die Maßnahme op.nub.1 legen die Regeln fest, die CCN-STIC-Profile und der CPSTIC-Katalog ersparen Ihnen Arbeit — aber die Verantwortung für die Information wandert auf keinen fremden Server: Sie bleibt bei Ihnen. Eine Behörde, die das versteht, beschafft besser; ein Anbieter, der das versteht, verkauft schneller.

Wenn Sie erwägen, ein öffentliches System in die Cloud zu bringen, oder ein SaaS-Produkt haben und man Ihnen gerade das ENS für eine Ausschreibung abverlangt hat, schildern Sie mir Ihren Fall, und wir besprechen ihn gemeinsam, unverbindlich.

Müssen Sie die Konformität Ihres Cloud-Dienstes nachweisen, um an die Verwaltung zu verkaufen? Erfahren Sie mehr über meine ENS-Beratung für Unternehmen, die sich an Ausschreibungen beteiligen oder Anbieter des öffentlichen Sektors werden möchten.

Häufig gestellte Fragen zum ENS in der Cloud

Muss sich ein SaaS-Unternehmen im ENS zertifizieren lassen, um an die Verwaltung zu verkaufen?

Wenn der Dienst Information verarbeitet oder Funktionen für eine öffentliche Stelle erbringt, verlangen das immer mehr Ausschreibungsunterlagen. Der Weg dahin ist der Nachweis der ENS-Konformität des Dienstes in der vom öffentlichen Kunden geforderten Kategorie: per Konformitätserklärung in der Kategorie BASIS oder per Zertifizierung durch eine akkreditierte Stelle in MITTEL und HOCH. Der Geltungsbereich des Zertifikats muss wirklich den Dienst und die Plattform abdecken, von der aus er erbracht wird.

Was ist der CCN-STIC-Leitfaden 823?

Es ist der Leitfaden des Nationalen Kryptologiezentrums (CCN), der die Nutzung von Cloud-Diensten im Anwendungsbereich des ENS regelt. Er unterscheidet die Servicemodelle (IaaS, PaaS, SaaS) und die Bereitstellungsmodelle (öffentlich, privat, gemeinschaftlich und hybrid), bewertet den Dienst in den fünf Sicherheitsdimensionen des ENS und legt im Detail fest, was die Behörde, die Cloud-Dienste nutzt, vertraglich verlangen muss – vom Standort der Daten bis zur sicheren Löschung.

Was schreibt die Maßnahme op.nub des ENS vor?

Die Maßnahme op.nub.1, „Schutz der Cloud-Dienste“ aus Anhang II des Königlichen Dekrets 311/2022, gilt bereits ab der Kategorie BASIS und verlangt, dass der Cloud-Dienst entweder das ENS erfüllt oder die Maßnahmen des anwendbaren CCN-STIC-Leitfadens entsprechend seinem Servicemodell (SaaS, PaaS, IaaS) einhält, einschließlich der Anforderungen an Auditnachweise.

Kann ich AWS, Azure oder Google Cloud nutzen und trotzdem das ENS erfüllen?

Ja, mit Einschränkungen. Azure, Microsoft 365 und AWS verfügen über spezifische CCN-STIC-Compliance-Profile (884, 885 und 887), die erklären, wie sie ENS-konform bereitgestellt werden. Dieses Profil deckt den Teil des Anbieters ab: Prüfen Sie stets den genauen Geltungsbereich und die Region, und denken Sie daran, dass Identität, Konfiguration und Daten weiterhin Ihre eigene Verantwortung sind.

Befreit mich das ENS-Zertifikat meines Cloud-Anbieters von der eigenen Zertifizierung?

Nein. Es deckt nur den Teil des Anbieters innerhalb des Modells der geteilten Verantwortung ab. Die Behörde oder das SaaS-Unternehmen, das darauf aufbaut, bleibt für die eigenen Maßnahmen verantwortlich – Identität, Verschlüsselung, Konfiguration, Protokollierung und Betrieb – und muss die eigene Konformität nachweisen, wenn die Ausschreibungsunterlagen dies verlangen.

Wo müssen die Daten unter dem ENS in der Cloud liegen?

Das hängt von der Kategorie des Systems und der Art der Information ab. Der Trend in den Ausschreibungsunterlagen geht dahin, eine Verarbeitung in der Europäischen Union und in bestimmten Fällen auf nationalem Staatsgebiet zu verlangen, mit vertraglich geklärter Gerichtsbarkeit. Es empfiehlt sich, dies ausdrücklich festzulegen und nicht allein deshalb vorauszusetzen, weil eine europäische Region beauftragt wurde.

Quellen

• Königliches Dekret 311/2022 (ENS), Anhang II · BOE
• CCN-STIC-Leitfaden 823 · Nutzung von Cloud-Diensten
• CPSTIC-Katalog des CCN · STIC-Produkte und -Dienste
• ENS-Portal · Nationales Kryptologiezentrum (CCN)
• CCN-CERT · CCN-STIC-Compliance-Profile 884-887

Inhalt erstellt von Ángel Ortega Castro für angelortegacastro.com. Informativer Inhalt; für jede rechtliche Verpflichtung konsultieren Sie bitte den geltenden CCN-STIC-Leitfaden 823 und Anhang II des Königlichen Dekrets 311/2022.