Aller au contenu
Hyperfluid 2.0 est disponible console.hyperfluid.cloud/signup
IAM, gouvernance & audit

Qui a accès à quoi, et qui l'a demandé.

Sécurité holistique, uniforme sur toute votre stack

Vos données méritent une sécurité qui pense comme vous : qui devrait accéder à quoi, et quand. Gérez utilisateurs, comptes de service, rôles et groupes, posez des garde-fous à l'échelle de l'organisation et fédérez vos fournisseurs d'identité (SSO, OIDC).

Demander votre accès Solution DSI →

Spécifications

IAM
Utilisateurs, comptes de service, rôles, groupes
Fédération d'identité
GitHub, Google, OIDC
Garde-fous
Règles appliquées à toute l'organisation
Zero-trust
Aucun contournement administrateur
Fenêtre horaire
Heure de début et de fin en UTC
Row-level
Labels de ligne contre attributs de compte
Multi-niveau
Organisation puis cluster SQL
Contextuel
Nationalité, type de contrat, habilitation
Configurable
Réglages par service, sans code de politique à écrire
Traçabilité
Décisions d'accès et journal d'audit dans la console

Cas d'usage

Conformité réglementaire

Des règles posées à l'échelle de l'organisation puis affinées par cluster SQL, et chaque décision d'accès reste explicable

Décisions tracées, journal d'audit

Fédération d'identité

Branchez votre fournisseur d'identité d'entreprise en OIDC, et gérez utilisateurs, groupes et comptes de service depuis la console

GitHub, Google, OIDC

Cloisonner par nationalité et par contrat

Une table portant un label de restriction géographique n'est lisible que par les comptes dont la nationalité déclarée correspond, et une donnée classée secret d'affaires reste fermée aux prestataires

Labels de donnée contre attributs de compte

En action

La fenêtre d'accès aux données sensibles

Un responsable sécurité limite l'accès aux données aux heures ouvrées et au niveau d'habilitation requis

  1. Dans les réglages de sécurité de l'organisation, la fenêtre d'heures de bureau est activée, avec une heure de début et une heure de fin en UTC
  2. Chaque cluster SQL hérite du réglage de l'organisation, ou le surcharge pour son propre périmètre
  3. Les tables sont classées par niveau de sensibilité : une requête sur une table classée au-dessus de l'habilitation de l'appelant est refusée, et la vérification des labels d'accès peut en plus descendre au niveau colonne
  4. Une requête lancée hors de la fenêtre configurée est refusée avant d'atteindre les données, et la décision est enregistrée dans le journal d'audit

Les données sensibles restent hors de portée en dehors des créneaux autorisés, et chaque refus est justifiable en audit

Les permissions ajustées au besoin réel

Une équipe marketing a besoin d'un sous-ensemble des données de ventes pour une campagne

  1. Un groupe est créé dans l'IAM et les membres de l'équipe y sont ajoutés : chacun hérite de ce qui est accordé au groupe
  2. Un rôle est lié au groupe, ou des permissions sont accordées directement sur un chemin de ressources précis plutôt que sur toute l'organisation
  3. Des attributs au format namespace::valeur sont posés sur les comptes, la région par exemple : la sécurité row-level ne renvoie que les lignes dont les labels correspondent
  4. Un garde-fou d'organisation ferme en plus le sous-arbre le plus sensible pour tout le monde, propriétaires compris

L'équipe accède au sous-ensemble dont elle a besoin, sans élévation de privilèges permanente

La revue des accès refusés

Une équipe sécurité passe en revue les décisions d'accès évaluées sur la plateforme

  1. La console affiche le flux des décisions d'accès, autorisées et refusées, sur une fenêtre de 1 heure, 24 heures ou 7 jours
  2. Un filtre isole les seules décisions refusées, ou celles d'un utilisateur donné
  3. Chaque entrée porte le motif du refus, les restrictions évaluées, l'adresse IP et le client utilisé
  4. Le journal d'audit conserve l'événement complet, filtrable par utilisateur, type d'événement et période

Un comportement d'accès anormal se lit dans la console, et chaque refus reste documenté pour l'audit

Sécurité intelligente

IAM IAM complet
Utilisateurs, comptes de service, rôles et groupes au même endroit. Un groupe reçoit un rôle ou des permissions, et chacun de ses membres en hérite.
OIDC Fédération d'identité
Branchez GitHub, Google ou n'importe quel fournisseur OIDC. L'identifiant client se règle depuis la console, le secret client n'y est jamais conservé.
Guardrail Garde-fous d'organisation
Une règle d'organisation ferme une action sur un sous-arbre de ressources pour tout le monde, propriétaires compris : l'accès est refusé tant que toutes les conditions ne sont pas réunies.
Zero-trust Mode zero-trust
Activé, il retire le contournement implicite dont bénéficient les administrateurs : chaque appel passe par l'évaluation de politique, sans exception.
Office hours Fenêtre horaire et lecture seule
La fenêtre d'accès se définit en heures UTC au niveau de l'organisation, et chaque cluster SQL en hérite ou la surcharge. Un cluster peut par ailleurs être basculé en lecture seule : toute écriture est alors refusée.
Sensitivity Niveaux de sensibilité
L'habilitation du compte doit atteindre le niveau de sensibilité porté par la table. La vérification des labels d'accès s'applique aux tables et, si vous l'activez, aux colonnes.
Context rules Règles contextuelles
Une règle confronte les labels posés sur la donnée aux attributs déclarés du compte : nationalité, type de contrat, niveau d'habilitation. Rien n'est déduit d'une adresse IP ni d'une géolocalisation.
Row-level Filtrage row-level
Activable par catalogue, par schéma ou par table. Une colonne de labels portée par la table est comparée aux attributs namespace::valeur du compte, et seules les lignes correspondantes sont renvoyées.
Audit log Décisions tracées
Chaque décision porte son motif, les restrictions évaluées, l'adresse IP et le client utilisé. La console les affiche sur 1 heure, 24 heures ou 7 jours, et le journal d'audit conserve l'événement complet.

Comment ça fonctionne

  1. La requête arrive

    Un utilisateur ou un compte de service interroge une table depuis un cluster SQL.

  2. Les règles sont évaluées

    Fenêtre horaire, mode lecture seule, niveau de sensibilité, labels de table et de colonne, règles contextuelles et garde-fous d'organisation.

  3. La décision est rendue, puis tracée

    Accès autorisé, refusé avec son motif, ou lignes filtrées par leurs labels. L'événement rejoint le journal d'audit et le flux des décisions.

Avantages clés

  • IAM complet : utilisateurs, comptes de service, rôles et groupes
  • Fédération d'identité : GitHub, Google et tout fournisseur OIDC
  • Garde-fous appliqués à toute l'organisation, propriétaires compris
  • Mode zero-trust : même les administrateurs passent par l'évaluation de politique
  • Contrôle d'accès par fenêtre horaire UTC, niveau de sensibilité et attributs de compte
  • Filtrage row-level activable par catalogue, par schéma ou par table
  • Décisions d'accès consultables dans la console sur 1 heure, 24 heures ou 7 jours

Prêt à sécuriser vos données intelligemment ?

Découvrez comment notre sécurité contextuelle peut protéger votre organisation.

Demander votre accès Vue d'ensemble du catalogue →