Przejdź do głównej zawartości
Saiku Cloud

Postawa bezpieczeństwa i zaufania

Zespoły zaopatrzenia w przedsiębiorstwach potrzebują wiedzieć, gdzie dostawca stoi w kwestii bezpieczeństwa, zanim w ogóle spojrzą na produkt. Ta strona to uczciwa wersja — co już jest na miejscu, co jest w toku i czego celowo jeszcze nie zrobiliśmy. Utrzymywane aktualnie; ostatnio zweryfikowane lipiec 2026.

Atestacje stron trzecich

AtestacjaStatusUwagi
SOC 2 Type ICel Q4 2026Zakres ukończony; audytor wybrany. Naprawa luk przed audytem w toku.
SOC 2 Type IICel Q3 2027Następuje po Type I po zakończeniu okna obserwacji.
ISO 27001Nie na obecnej mapie drogowejRepriorytetyzacja na żądanie dla dużych kontraktów europejskich.
HIPAA BAANa żądaniePodpisywane per klient dla wdrożeń w ochronie zdrowia.
DPA (RODO)Na żądanieStandardowa DPA dostępna; poprawki klienta rozważane.

Nie publikujemy atestacji, których nie posiadamy. Jeśli widzisz „SOC 2 compliant” na stronie dostawcy bez daty raportu, poproś go o raport — kilku konkurentów wysyła etykietę bez papierologii.

Obsługa danych

Gdzie żyją twoje dane.

  • Saiku Cloud działa na europejskiej infrastrukturze (Scaleway, Holandia). Regiony USA dostępne na żądanie dla najemców z wymogami rezydencji danych.
  • Same dane hurtowni nigdy nie opuszczają twojej hurtowni. Saiku to warstwa semantyczna — zapytania są kompilowane do SQL i wysyłane do twojej bazy; wyniki przechodzą przez naszą platformę, by wyrenderować się w UI, ale nie są domyślnie utrwalane po stronie serwera.
  • Metadane, które SĄ przechowywane: definicje kostek, zapisane workbooki, historia zapytań do audytu, konta użytkowników, informacje o subskrypcji. Wszystkie ograniczone per najemca (zobacz Izolacja najemców).

Szyfrowanie.

  • W tranzycie: TLS 1.3 dla wszystkich endpointów zwróconych do klienta (cloud.saiku.bi, demo.saiku.bi, api.saiku.bi). HSTS wymuszane z rocznym max-age.
  • W spoczynku: wolumeny baz szyfrowane na poziomie dostawcy chmury (odpowiednik LUKS / dm-crypt). Poświadczenia hurtowni szyfrowane kluczami per najemca.
  • Sekrety: sekrety operatora (klucze API, hasła DB) nigdy nie zapisywane do logów. Zobacz log audytu, co JEST rejestrowane.

Retencja i usuwanie.

  • Zdarzenia audytu: 90 dni na planie domyślnym, do 7 lat na Enterprise.
  • Workbooki + zapisane zapytania: przechowywane do momentu usunięcia; twarde usunięcie przy zamknięciu konta w ciągu 30 dni.
  • Cache wyników zapytań: domyślnie 30 minut, konfigurowalny per najemca.
  • Kopie zapasowe: nocna pełna + godzinowa przyrostowa; przechowywane 30 dni; szyfrowane w spoczynku.

Kontrola dostępu

  • SSO — SAML 2.0 obsługiwany na planie Team i wyżej. OIDC / OAuth 2.0 na planie Enterprise.
  • MFA — wymuszane dla konta operatora (root admin). Administratorzy najemcy mogą wymuszać dla własnych członków.
  • Dostęp oparty na rolach — zobacz Członkowie i role. Bezpieczeństwo na poziomie wierszy (RLS) na poziomie kostki dostarczane w Saiku 4.6.
  • Zarządzanie sesją — konfigurowalny timeout; wymuszone ponowne uwierzytelnienie po 24 godzinach domyślnie.
  • Konta usługowe / klucze API — ograniczone, odwoływalne i pojawiają się w logu audytu.

Bezpieczeństwo aplikacji

  • Skanowanie podatności: każdy push do development uruchamia Snyk względem drzewa zależności; każde wydanie uruchamia OWASP Dependency-Check przez mvn -P security verify. Znaleziska powyżej CVSS 7.0 blokują wydanie.
  • Skanowanie sekretów: skanowanie sekretów GitHub włączone na każdej gałęzi; hooki commitów odrzucają cokolwiek pasującego do typowych wzorców poświadczeń.
  • Bezpieczeństwo CI: buildy działają na efemerycznych runnerach hostowanych przez GitHub; brak trwałych sekretów poza sekretami GitHub Actions. Klucz podpisujący do publikowania artefaktów żyje w osobnym utwardzonym środowisku.
  • Higiena zależności: każda zależność dodana do POM przechodzi przez Sonatype OSS Index pod kątem znanych podatności + wykrywania złośliwych pakietów przed scaleniem.

Reagowanie na incydenty

  • Dyżur: godziny pracy (UK) dla planu Team; 24/7 dla Enterprise.
  • Cel powiadomienia: klienci Enterprise powiadamiani w ciągu 24 godzin od potwierdzonego naruszenia danych; plan Team powiadamiany w ciągu 72 godzin.
  • Strona statusu: status.saiku.bi — subskrybowalna przez email lub RSS.
  • Post-mortemy: publikowane dla każdego incydentu trwającego > 30 minut na planach Enterprise. Zredagowane publiczne post-mortemy dla szerszych incydentów na changelogu.

Historia self-hosted

Dla klientów, którzy nie mogą wysyłać danych przez żadną hostowaną platformę, Saiku dostarcza build self-hosted na tej samej licencji Apache 2.0 co wersja Cloud. Postawa bezpieczeństwa tam jest odpowiedzialnością operatora, ale Saiku dostarcza z:

  • Domyślnymi ustawieniami fail-closed (zobacz gwardię AiPolicy — produkcja domyślnie ustawia schema-only dla endpointów AI)
  • Odmową niedomyślnych poświadczeń admina (Saiku odmawia serwowania na produkcji, dopóki dostarczone poświadczenia admin/admin nie zostaną zrotowane)
  • Opcjonalnym OpenTelemetry, aby zdarzenia bezpieczeństwa płynęły do twojego istniejącego SIEM
  • Brakiem phone-home; brakiem telemetrii z boxa, chyba że ją skonfigurujesz

Zobacz przewodnik po self-hostingu po porady hardeningowe.

Czego celowo nie zrobiliśmy

Transparentność co do luk jest warta więcej niż marketingowa lista.

  • FedRAMP: Brak planów. To nie rynek, który obsługujemy.
  • PCI-DSS: Niecertyfikowane. Saiku to platforma warstwy semantycznej, nie procesor płatności — nie przechowujemy danych posiadaczy kart. Jeśli twój przypadek użycia BI dotyka danych posiadaczy kart, potrzebujesz kontroli kompensacyjnej po stronie hurtowni.
  • Lokalizacja danych RODO dla regionów brzegowych: dziś tylko UE. Azja i Pacyfik + regiony USA dostępne na żądanie, ale nie domyślnie.
  • Bug bounty: Obecnie nie prowadzimy. Odpowiedzialne ujawnianie obsługiwane bezpośrednio przez security@saiku.bi.

Kontakt