Aller au contenu
Saiku Cloud

Posture de sécurité et de confiance

Les équipes d’achats en entreprise ont besoin de savoir où se situe un fournisseur sur le plan de la sécurité avant même de regarder le produit. Cette page est la version honnête — ce qui est déjà en place, ce qui est en cours et ce que nous n’avons délibérément pas encore fait. Tenu à jour ; dernière révision en juillet 2026.

Attestations tierces

AttestationStatutNotes
SOC 2 Type ICible T4 2026Cadrage terminé ; auditeur sélectionné. Remédiation des écarts pré-audit en cours.
SOC 2 Type IICible T3 2027Suit le Type I une fois la fenêtre d’observation terminée.
ISO 27001Pas sur la feuille de route actuelleRepriorisé sur demande pour les grands contrats européens.
HIPAA BAASur demandeSigné au cas par cas pour les déploiements dans le secteur de la santé.
DPA (RGPD)Sur demandeDPA standard disponible ; les amendements clients sont étudiés.

Nous ne publions pas d’attestations que nous ne détenons pas. Si vous voyez « conforme SOC 2 » sur la page d’un fournisseur sans date de rapport, demandez-lui le rapport — plusieurs concurrents affichent l’étiquette sans les justificatifs.

Traitement des données

Où vos données résident.

  • Saiku Cloud tourne sur une infrastructure européenne (Scaleway, Pays-Bas). Des régions américaines sont disponibles sur demande pour les tenants ayant des exigences de résidence des données.
  • Les données de l’entrepôt elles-mêmes ne quittent jamais votre entrepôt. Saiku est une couche sémantique — les requêtes sont compilées en SQL et envoyées à votre base de données ; les résultats transitent par notre plateforme pour s’afficher dans l’UI mais ne sont pas persistés côté serveur par défaut.
  • Les métadonnées qui SONT stockées : définitions de cubes, classeurs sauvegardés, historique des requêtes pour l’audit, comptes utilisateurs, informations d’abonnement. Le tout cantonné par tenant (voir Isolation des tenants).

Chiffrement.

  • En transit : TLS 1.3 pour tous les endpoints exposés aux clients (cloud.saiku.bi, demo.saiku.bi, api.saiku.bi). HSTS imposé avec un max-age d’un an.
  • Au repos : volumes de base de données chiffrés au niveau du fournisseur cloud (équivalent LUKS / dm-crypt). Identifiants d’entrepôt chiffrés avec des clés par tenant.
  • Secrets : les secrets opérateur (clés d’API, mots de passe de base de données) ne sont jamais écrits dans les logs. Voir le journal d’audit pour ce qui EST enregistré.

Rétention et suppression.

  • Événements d’audit : 90 jours sur le plan par défaut, jusqu’à 7 ans sur Enterprise.
  • Classeurs et requêtes sauvegardées : conservés jusqu’à ce que vous les supprimiez ; suppression définitive à la clôture du compte sous 30 jours.
  • Cache des résultats de requêtes : 30 minutes par défaut, configurable par tenant.
  • Sauvegardes : complète chaque nuit + incrémentale chaque heure ; conservées 30 jours ; chiffrées au repos.

Contrôle d’accès

  • SSO — SAML 2.0 pris en charge sur le plan Team et au-dessus. OIDC / OAuth 2.0 sur le plan Enterprise.
  • MFA — imposée pour le compte opérateur (administrateur root). Les administrateurs de tenant peuvent l’imposer à leurs propres membres.
  • Accès basé sur les rôles — voir Membres et rôles. La sécurité au niveau des lignes (RLS) au niveau du cube arrive dans Saiku 4.6.
  • Gestion des sessions — délai d’expiration configurable ; ré-authentification forcée après 24 heures par défaut.
  • Comptes de service / clés d’API — cantonnés, révocables et apparaissant dans le journal d’audit.

Sécurité applicative

  • Analyse de vulnérabilités : chaque push vers development lance Snyk contre l’arbre de dépendances ; chaque release lance OWASP Dependency-Check via mvn -P security verify. Les découvertes au-dessus de CVSS 7.0 bloquent la release.
  • Analyse de secrets : l’analyse de secrets GitHub est activée sur chaque branche ; les commit hooks rejettent tout ce qui correspond aux motifs d’identifiants courants.
  • Sécurité CI : les builds tournent sur des runners éphémères hébergés par GitHub ; aucun secret persistant en dehors des secrets GitHub Actions. La clé de signature pour la publication des artefacts vit dans un environnement durci séparé.
  • Hygiène des dépendances : chaque dépendance ajoutée à un POM passe par le Sonatype OSS Index pour les vulnérabilités connues + la détection de paquets malveillants avant le merge.

Réponse aux incidents

  • Astreinte : heures ouvrées (UK) pour le plan Team ; 24/7 pour Enterprise.
  • Cible de notification : les clients Enterprise sont notifiés sous 24 heures suivant une violation de données confirmée ; le plan Team est notifié sous 72 heures.
  • Page de statut : status.saiku.bi — abonnable par e-mail ou RSS.
  • Post-mortems : publiés pour tout incident durant plus de 30 minutes sur les plans Enterprise. Post-mortems publics caviardés pour les incidents plus larges sur le changelog.

L’histoire de l’auto-hébergement

Pour les clients qui ne peuvent envoyer leurs données via aucune plateforme hébergée, Saiku fournit un build auto-hébergé sous la même licence Apache 2.0 que la version Cloud. La posture de sécurité y est de la responsabilité de l’opérateur, mais Saiku est livré avec :

  • Des valeurs par défaut fail-closed (voir le garde AiPolicy — en production, le défaut est schema-only pour les endpoints d’IA)
  • Un refus des identifiants d’administrateur par défaut (Saiku refuse de servir en production tant que les identifiants admin/admin livrés ne sont pas changés)
  • OpenTelemetry en opt-in pour que les événements de sécurité affluent vers votre SIEM existant
  • Aucun phone-home ; aucune télémétrie hors de la machine sauf si vous la configurez

Voir le guide d’auto-hébergement pour des conseils de durcissement.

Ce que nous n’avons délibérément pas fait

La transparence sur les lacunes vaut plus qu’une check-list marketing.

  • FedRAMP : aucun plan. Ce n’est pas un marché que nous servons.
  • PCI-DSS : non certifié. Saiku est une plateforme de couche sémantique, pas un processeur de paiement — nous ne stockons pas de données de porteurs de carte. Si votre cas d’usage BI touche à des données de porteurs de carte, il vous faut un contrôle compensatoire côté entrepôt.
  • Localisation des données RGPD pour les régions edge : UE uniquement aujourd’hui. Les régions Asie-Pacifique + États-Unis sont disponibles sur demande mais ne sont pas le défaut.
  • Bug bounty : nous n’en menons pas actuellement. Divulgation responsable gérée directement via security@saiku.bi.

Contact