[Seite 1]
Anforderungen an einen Clouddienst zum Austausch von vertraulichen / streng vertraulichen Informationen
- Grundsätzliche Anforderungen
Der Clouddienst darf ausschließlich nach vorheriger Freigabe für vertrauliche und streng vertrauliche Daten genutzt werden.
Eine technische und organisatorische Klassifizierungsunterstützung (z. B. Label, Wasserzeichen, verpflichtende Metadaten, Policies mit technischer Durchsetzung) MUSS vorhanden sein.
Der Dienst DARF NICHT für öffentliche oder unklassifizierte Daten konzipiert sein (kein „Consumer-Tool“ ohne Enterprise-Sicherheitsfunktionen).
Der Dienst MUSS mandantenfähig sein.
Sicherheitsrichtlinien MÜSSEN technisch erzwungen werden (Policy Enforcement).
- Informationssicherheit & Compliance
Der Anbieter MUSS ein nachweisbares Informationssicherheitsmanagementsystem (ISMS) betreiben.
Mindestens folgende Nachweise MÜSSEN vorliegen:
• ISO/IEC 27001 (zertifiziert) • ISO/IEC 27017 (Cloud Security) • ISO/IEC 27018 (Schutz personenbezogener Daten) • Aktueller Prüfbericht (nicht älter als 12 Monate)
Für KRITIS-nahe Informationen:
• BSI C5 Testat MUSS vorliegen oder gleichwertig belegt werden. • Regelmäßige unabhängige Penetrationstests und Schwachstellenanalysen sind verpflichtend. • Ein BCMS (ISO 22301) MUSS nachweisbar vorhanden sein. • Zusammenfassungen der Prüfberichte MÜSSEN dem Kunden bereitgestellt werden
- Datenhoheit & Datenlokation
Speicherung und Verarbeitung der Daten MUSS ausschließlich innerhalb der EU erfolgen.
[Seite 2]
Es DÜRFEN KEINE Datenübermittlungen in Drittländer stattfinden (möglichst auch nicht für Support, Wartung, Remote-Admin oder Telemetrie).
Der Anbieter DARF KEINEN Zugriff auf Klartextdaten haben (Zero-Knowledge-Ansatz bevorzugt).
Subunternehmer MÜSSEN vollständig transparent benannt und in der EU ansässig sein, sowie vertraglich gleichwertigen Sicherheitsanforderungen unterliegen.
Änderungen in der Subunternehmerstruktur MÜSSEN vorab angezeigt werden.
- Verschlüsselung & Kryptografie
Ende-zu-Ende-Verschlüsselung (E2EE) ist zwingend erforderlich.
Verschlüsselung MUSS erfolgen:
• bei der Übertragung (TLS 1.3 oder höher) • bei der Speicherung (AES-256 oder gleichwertig)
Kryptografische Module SOLLTEN zertifiziert sein (z. B. FIPS 140-2/3 oder gleichwertig).
Kundenseitige Schlüsselverwaltung MUSS möglich sein (BYOK / HYOK).
Schlüssel DÜRFEN NICHT ausschließlich durch den Anbieter kontrolliert werden.
Schlüsselmaterial DARF NICHT exportierbar sein.
Die Nutzung von Hardware Security Modulen (HSM) MUSS unterstützt werden.
- Identitäts- und Zugriffsmanagement (IAM)
Zugriff ausschließlich nach dem Need-to-know-Prinzip.
Mehrfaktor-Authentifizierung (MFA) ist verpflichtend für alle Benutzer – einschließlich Administratoren.
Integration in bestehende IAM-Systeme (z. B. SAML, OIDC, Azure AD) MUSS möglich sein.
Feingranulare Rollen- und Rechtekonzepte MÜSSEN unterstützt werden:
Lesen / Schreiben / Weiterleiten / Download / Löschen
Temporäre Zugriffe MÜSSEN zeitlich begrenzt werden können.
Privilegierte Konten MÜSSEN gesondert geschützt werden (PAM-Unterstützung).
Alle administrativen Tätigkeiten MÜSSEN vollständig protokolliert werden.
[Seite 3]
Conditional-Access-Mechanismen SOLLTEN unterstützt werden (z. B. Geräte-Compliance, Standortprüfung).
- Schutz vor Datenabfluss
Funktionen zur Verhinderung von Datenabfluss MÜSSEN vorhanden sein:
• Einschränkung oder Deaktivierung von Downloads
• Sperre von Weiterleitungen
• Wasserzeichen (Benutzer, Zeitstempel)
• Verhinderung unkontrollierter Massenexporte
Inhalte DÜRFEN NICHT automatisch synchronisiert oder lokal zwischengespeichert werden.
Offline-Zugriffe auf streng vertrauliche Informationen SIND NICHT zulässig.
API-Zugriffe MÜSSEN restriktiv konfigurierbar sein.
„Freigabe per öffentlichem Link“ DARF NICHT möglich sein.
Sicherheitsmechanismen SOLLTEN Fehladressierungen technisch minimieren.
- Logging, Monitoring & Nachvollziehbarkeit
Vollständige Protokollierung aller sicherheitsrelevanten Ereignisse:
• Upload
• Download
• Zugriff
• Freigabe
• Änderung
• Löschung
• Administrative Tätigkeiten
Logs MÜSSEN:
• manipulationssicher
• revisionsfähig
• exportierbar
• mindestens 12 Monate aufbewahrt werden
[Seite 4]
Eine Integration in kundenseitige SIEM-Systeme MUSS möglich sein.
Verdächtige Aktivitäten MÜSSEN automatisiert erkannt und unverzüglich gemeldet werden.
- Verfügbarkeit & Resilienz
Verfügbarkeit MUSS vertraglich zugesichert sein:
• SLA ≥ 99,95 % (für KRITIS bevorzugt ≥ 99,99 %)
Redundante Speicherung in geographisch getrennten Rechenzentren INNERHALB DER EU.
Regelmäßige, verschlüsselte Backups MÜSSEN erfolgen.
Wiederherstellungszeiten (RTO) und Datenverlustgrenzen (RPO) MÜSSEN:
• definiert
• dokumentiert
• regelmäßig getestet werden
Notfallübungen SOLLTEN dokumentiert durchgeführt werden.
- Incident- & Notfallmanagement
Ein dokumentierter Incident-Response-Prozess ist verpflichtend.
Sicherheitsvorfälle MÜSSEN unverzüglich gemeldet werden:
• spätestens innerhalb von 24 Stunden nach Bekanntwerden
Ein Incident-Report MUSS bereitgestellt werden.
Unterstützung bei:
• forensischer Analyse
• regulatorischen Meldungen
• Ursachenanalyse (Root Cause Analysis)
Notfallkontakte MÜSSEN 24/7 erreichbar sein.
Der Anbieter SOLLTE an gemeinsamen Notfallübungen teilnehmen.
- Vertrags- & Governance-Anforderungen
Ein Auftragsverarbeitungsvertrag (AVV) MUSS abgeschlossen werden.
[Seite 5]
Auditrechte für den Kunden MÜSSEN vertraglich zugesichert sein (inkl. Vor-Ort- oder Remote-Audit).
Sicherheitszertifizierungen MÜSSEN über die gesamte Vertragslaufzeit gültig bleiben.
Änderungen in Eigentümerstruktur oder Kontrollverhältnissen MÜSSEN unverzüglich gemeldet werden.
Kündigung DARF KEINE Datenverluste oder Zugriffslücken verursachen.
Bei Vertragsende:
• vollständige Herausgabe aller Daten in standardisiertem Format
• nachweisbare, revisionssichere Datenlöschung
• Löschbestätigung
- Benutzerfreundlichkeit & Sensibilisierung
Der Dienst MUSS eindeutig anzeigen, wenn mit vertraulichen oder streng vertraulichen Daten gearbeitet wird.
Klassifizierungsstufen MÜSSEN dauerhaft sichtbar sein.
Sicherheitsrelevante Aktionen (Freigabe, Download, Rechteänderung) MÜSSEN explizit bestätigt werden.
Sichere Voreinstellungen (Secure-by-Default) sind verpflichtend.
Fehlbedienungen MÜSSEN technisch minimiert werden.