Nouveau : le pare-feu IA surveille chaque module et explique chaque incident en termes simples. Découvrez comment ça marche

Comment Hermetry protège vos données

Isolation par organisation dans la base de données, régions distinctes, stockage des secrets et des clés, moindre privilège pour chaque processus, sessions et ce qui y met fin.

Cette page décrit les protections toujours actives, quelle que soit votre configuration. Elle est destinée aux revues de sécurité et aux questionnaires. Les contrôles que vous configurez vous-même se trouvent dans les autres pages de cette section.

Isolation entre organisations

Chaque client est une organisation (un locataire). La séparation est appliquée à trois niveaux :

NiveauFonctionnement
Base de donnéesChaque table qui contient des données d’organisation est protégée par une sécurité au niveau des lignes (row-level security). Une session de base de données est liée à une seule organisation et ne peut lire et écrire que les lignes de cette organisation, même si le code applicatif en demande davantage.
ApplicationChaque requête est rattachée à une seule organisation et à une seule adhésion. Un membre d’une organisation n’a aucun droit dans une autre, et le rôle d’une même personne est recherché pour chaque organisation.
AppareilsUn appareil appartient à une seule organisation. Ses identifiants, ses topics et ses commandes lui sont liés ; il ne reçoit jamais les messages d’un autre appareil.

Les tâches de fond qui travaillent sur plusieurs organisations (rétention, comptage d’usage, facturation) listent les organisations par un chemin unique et protégé, puis travaillent à l’intérieur de la frontière propre à chaque organisation.

Régions

Hermetry fonctionne sous forme de déploiements distincts dans l’Union européenne, aux États-Unis et en Türkiye. Les données de votre organisation restent dans sa région d’origine. L’annuaire global qui route les requêtes ne connaît que la région et le nœud sur lesquels se trouve une organisation ; il ne contient ni nom, ni adresse, ni propriétaire, ni paramètre. L’accès d’urgence des opérateurs Hermetry à un nœud exige deux signatures, est limité dans le temps et est signalé dans votre journal d’audit. Voir Régions et résidence des données.

Secrets et clés

SecretMode de conservation
Mots de passeHaché avec une fonction de hachage lente ; jamais stocké ni affiché en clair.
Jetons d’accès des appareils et mots de passe MQTTAffichés une seule fois à l’émission ; seul un haché est stocké.
Clés d’APIAffichées une seule fois ; seul un haché est stocké.
Secrets dans les paramètres (comptes de messagerie et SMS, secrets client OAuth, mots de passe des points de terminaison, clés privées SAML)Chiffrés au repos ; jamais réaffichés après l’enregistrement et jamais écrits dans les journaux.
Secrets des applications d’authentificationScellés sous une clé propre à chaque personne.
Clés privées des certificats d’appareilsNe quittent jamais l’appareil. Hermetry stocke le certificat et son empreinte.
Clés de l’autorité de certificationClés racines hors ligne ; clés de signature en ligne scellées et détenues par un processus isolé unique. Voir L’autorité de certification des appareils.

Les secrets n’apparaissent jamais dans les exports, les lignes d’audit, les webhooks ni les textes de notification.

Moindre privilège pour les processus

Hermetry est découpé en processus, et chacun n’obtient que ce dont il a besoin :

  • La passerelle d’appareils, qui termine MQTT et HTTP des appareils, se connecte à la base de données avec son propre identifiant, qui ne peut appeler que quelques fonctions étroites. Elle ne détient aucune clé de l’autorité de certification.
  • Le signataire de certificats est le seul processus capable de désceller les clés de signature.
  • Le worker de provisionnement répond aux demandes de provisionnement des appareils sans aucune clé de signature.
  • Les scripts des flux s’exécutent dans des bacs à sable isolés, avec des limites de temps et sans accès au réseau, aux fichiers ni aux identifiants.

Une défaillance dans un processus ne remet donc pas à un attaquant les clés d’un autre.

Sessions

  • Une connexion crée une session avec des jetons d’accès de courte durée, qui sont renouvelés. Un jeton de rafraîchissement utilisé deux fois met fin à toutes les sessions de cette personne, car cela signifie qu’un jeton a été copié.
  • Les sessions prennent fin après une période d’inactivité et après une durée de vie absolue.
  • Un changement de rôle, une suspension ou une suppression met immédiatement fin aux sessions de la personne dans l’organisation. Les sessions et les connexions d’appareils d’une organisation suspendue prennent fin immédiatement.

Voir Sessions, verrouillage et appareils de confiance.

Protection contre les abus

ContrôleEffet
Limites de débitLes routes d’API, la connexion et les appareils ont des limites de requêtes ; au-delà, les requêtes sont refusées (429) ou les messages des appareils sont écartés.
Verrouillage de compte et CAPTCHADes échecs répétés de connexion verrouillent le compte pendant un certain temps.
Bannissement d’adressesLes adresses qui continuent d’échouer sur plusieurs comptes sont bannies pendant un certain temps.
Le pare-feu IASurveille les signaux de sécurité et ouvre des incidents qui expliquent ce qu’il a observé. Voir Le pare-feu IA.
LeurresFausses clés, fausses données et faux chemins que personne d’autorisé n’utilise ; y toucher déclenche un signal critique.

Connexions sortantes

Les webhooks, les blocs HTTP des flux et les points de terminaison interrogés se connectent depuis Hermetry vers l’extérieur. Ils refusent les adresses privées, de boucle locale et internes après résolution du nom, afin de ne pas pouvoir servir à atteindre le réseau interne d’Hermetry. Un webhook ne peut atteindre une cible interne que par une liste d’autorisation explicite ajoutée par un administrateur. Voir Webhooks et Connexions et secrets.

Preuves

Les actions sensibles sont inscrites dans un journal d’audit chaîné par hachage que l’application ne peut pas modifier. Voir Ce qui est audité.

Vos responsabilités

  • Les personnes que vous ajoutez comme membres, et avec quel rôle.
  • Les second facteurs et l’authentification unique (SSO) pour vos collaborateurs.
  • Profils d’appareils : TLS, réseaux autorisés, identifiants.
  • Clés d’API : leurs permissions, leurs réseaux et leur expiration.
  • Vos propres copies des données exportées.