Zum Inhalt springen
Saiku Cloud

Sicherheits- & Trust-Posture

Enterprise-Beschaffungsteams müssen wissen, wo ein Anbieter bei Sicherheit steht, noch bevor sie überhaupt auf das Produkt schauen. Diese Seite ist die ehrliche Version — was bereits vorhanden ist, was in Arbeit ist und was wir bewusst noch nicht getan haben. Aktuell gehalten; zuletzt geprüft Juli 2026.

Drittanbieter-Attestierungen

AttestierungStatusAnmerkungen
SOC 2 Type IZiel Q4 2026Scoping abgeschlossen; Auditor ausgewählt. Pre-Audit-Gap-Remediation in Arbeit.
SOC 2 Type IIZiel Q3 2027Folgt auf Type I, sobald das Beobachtungsfenster abgeschlossen ist.
ISO 27001Nicht auf der aktuellen RoadmapNeupriorisierung auf Anfrage für große europäische Verträge.
HIPAA BAAAuf AnfrageAuf Pro-Kunden-Basis für Healthcare-Deployments unterzeichnet.
DPA (DSGVO)Auf AnfrageStandard-DPA verfügbar; Kundenänderungen werden erwogen.

Wir veröffentlichen keine Attestierungen, die wir nicht halten. Wenn Sie „SOC 2 compliant” auf der Seite eines Anbieters ohne Report-Datum sehen, fragen Sie ihn nach dem Report — mehrere Wettbewerber liefern das Label ohne den Papierkram.

Datenhandhabung

Wo Ihre Daten leben.

  • Saiku Cloud läuft auf europäischer Infrastruktur (Scaleway, Niederlande). US-Regionen auf Anfrage verfügbar für Tenants mit Datenresidenz-Anforderungen.
  • Warehouse-Daten selbst verlassen nie Ihr Warehouse. Saiku ist eine Semantikebene — Abfragen werden zu SQL kompiliert und an Ihre Datenbank dispatcht; Ergebnisse transitieren unsere Plattform zum Rendern in der UI, werden aber standardmäßig nicht serverseitig persistiert.
  • Metadaten, die GESPEICHERT werden: Cube-Definitionen, gespeicherte Workbooks, Abfragehistorie für Audit, Nutzerkonten, Abonnement-Informationen. Alle pro Tenant beschränkt (siehe Tenant-Isolation).

Verschlüsselung.

  • Im Transit: TLS 1.3 für alle kundenzugewandten Endpunkte (cloud.saiku.bi, demo.saiku.bi, api.saiku.bi). HSTS durchgesetzt mit einer Ein-Jahres-max-age.
  • Im Ruhezustand: Datenbankvolumes auf Cloud-Provider-Ebene verschlüsselt (LUKS / dm-crypt-Äquivalent). Warehouse-Anmeldedaten mit Per-Tenant-Schlüsseln verschlüsselt.
  • Secrets: Operator-Secrets (API-Keys, DB-Passwörter) werden nie in Logs geschrieben. Siehe das Audit-Log für das, was AUFGEZEICHNET wird.

Aufbewahrung & Löschung.

  • Audit-Events: 90 Tage im Standard-Plan, bis zu 7 Jahre im Enterprise.
  • Workbooks + gespeicherte Abfragen: aufbewahrt, bis Sie sie löschen; Hard-Delete bei Kontoschließung innerhalb von 30 Tagen.
  • Abfrageergebnis-Cache: Standard 30 Minuten, tenant-konfigurierbar.
  • Backups: nächtlich voll + stündlich inkrementell; 30 Tage aufbewahrt; im Ruhezustand verschlüsselt.

Zugriffskontrolle

  • SSO — SAML 2.0 unterstützt im Team-Plan und darüber. OIDC / OAuth 2.0 im Enterprise-Plan.
  • MFA — für das Operator-Konto (Root-Admin) durchgesetzt. Tenant-Admins können es für ihre eigenen Mitglieder durchsetzen.
  • Rollenbasierter Zugriff — siehe Mitglieder & Rollen. Row-Level Security (RLS) auf Cube-Ebene wird in Saiku 4.6 ausgeliefert.
  • Session-Management — konfigurierbares Timeout; erzwungene Re-Auth nach standardmäßig 24 Stunden.
  • Service-Accounts / API-Keys — beschränkt, widerrufbar und erscheinen im Audit-Log.

Anwendungssicherheit

  • Vulnerability-Scanning: Jeder Push nach development führt Snyk gegen den Dependency-Tree aus; jeder Release führt OWASP Dependency-Check via mvn -P security verify aus. Findings über CVSS 7.0 blockieren den Release.
  • Secrets-Scanning: GitHub-Secret-Scanning auf jedem Branch aktiviert; Commit-Hooks weisen alles ab, was gängigen Anmeldedaten-Mustern entspricht.
  • CI-Sicherheit: Builds laufen auf ephemeren GitHub-gehosteten Runnern; keine persistenten Secrets außerhalb von GitHub-Actions-Secrets. Der Signing-Key für Artefakt-Publishing lebt in einer separaten gehärteten Umgebung.
  • Dependency-Hygiene: Jede Dependency, die einem POM hinzugefügt wird, läuft vor dem Merge durch den Sonatype OSS Index für bekannte Schwachstellen + Malicious-Package-Detection.

Incident Response

  • On-Call: Geschäftszeiten (UK) im Team-Plan; 24/7 im Enterprise.
  • Benachrichtigungsziel: Enterprise-Kunden werden innerhalb von 24 Stunden nach einem bestätigten Datenverstoß benachrichtigt; Team-Plan innerhalb von 72 Stunden.
  • Status-Seite: status.saiku.bi — abonnierbar via E-Mail oder RSS.
  • Post-Mortems: veröffentlicht für jeden Incident, der > 30 Minuten dauert, in Enterprise-Plänen. Redigierte öffentliche Post-Mortems für breitere Incidents im Changelog.

Die Self-Hosted-Story

Für Kunden, die keine Daten durch irgendeine gehostete Plattform senden können, liefert Saiku einen selbst gehosteten Build unter derselben Apache-2.0-Lizenz wie die Cloud-Version. Die Sicherheits-Posture dort liegt in der Verantwortung des Operators, aber Saiku liefert mit:

  • Fail-Closed-Standards (siehe die AiPolicy-Guard — die Produktion setzt für AI-Endpunkte standardmäßig auf schema-only)
  • Ablehnung von Nicht-Standard-Admin-Anmeldedaten (Saiku weigert sich, in der Produktion zu servieren, solange die ausgelieferten admin/admin-Anmeldedaten unrotiert sind)
  • Opt-in-OpenTelemetry, sodass Sicherheitsereignisse in Ihr bestehendes SIEM fließen
  • Kein Phone-Home; keine Telemetrie von der Box, es sei denn, Sie konfigurieren sie

Siehe den Self-Hosting-Leitfaden für Hardening-Ratschläge.

Was wir bewusst nicht getan haben

Transparenz über die Lücken ist mehr wert als eine Marketing-Checkliste.

  • FedRAMP: Keine Pläne. Kein Markt, den wir bedienen.
  • PCI-DSS: Nicht zertifiziert. Saiku ist eine Semantikebenen-Plattform, kein Zahlungsabwickler — wir speichern keine Karteninhaberdaten. Wenn Ihr BI-Use-Case Karteninhaberdaten berührt, brauchen Sie eine kompensierende Kontrolle auf der Warehouse-Seite.
  • DSGVO-Datenlokalisierung für Edge-Regionen: Heute nur EU. Asia Pacific + US-Regionen auf Anfrage verfügbar, aber nicht der Standard.
  • Bug-Bounty: Derzeit keines im Betrieb. Verantwortungsvolle Offenlegung direkt über security@saiku.bi gehandhabt.

Kontakt