L’isolation entre clients imposée
par la base de données.

Voyez le bloc mis en évidence au-dessus du sommaire. La suite de cet article explique pourquoi la distinction entre une isolation imposée par la base de données et une isolation imposée par l’application est la question que devrait poser la revue TI d’une compagnie aérienne, et ce qu’elle change pour l’approvisionnement.

Un système de gestion de la sécurité détient les données opérationnelles les plus sensibles que produit une compagnie aérienne. Des comptes rendus d’événements confidentiels. Des constatations d’enquête. Des registres des dangers. L’évaluation honnête des points faibles de l’exploitation et de ce qui n’a pas encore été corrigé. Ce ne sont pas des données marketing. C’est le relevé des endroits où votre exploitation pourrait être atteinte.

Dans une plateforme multilocataire, vos données et celles d’un concurrent vivent dans le même système. C’est normal et efficace, c’est ainsi que les logiciels modernes sont construits. La question qui compte n’est pas de savoir si les données partagent une infrastructure. C’est ce qui empêche un exploitant de jamais voir les lignes d’un autre. Pour des données de sécurité aérienne, cette réponse est une assurance concurrentielle : une seule divulgation accidentelle de comptes rendus confidentiels entre exploitants serait irrémédiable, tant pour les compagnies concernées que pour la culture de signalement dont dépendent ces données.

La bonne question d’approvisionnement est donc précise : où se situe exactement la frontière entre mes données et celles de tous les autres, et que se passe-t-il si un développeur commet une erreur ? Un fournisseur qui répond « nous avons des contrôles en place » n’y a pas répondu. Un fournisseur capable de nommer la couche où la frontière est imposée, si.

Une plateforme multilocataire peut tracer la frontière à deux endroits, et toute l’histoire tient dans cette différence.

L’isolation dans le code applicatif. C’est le schéma courant. Chaque requête que la plateforme exécute doit penser à ajouter une clause qui dit « uniquement les lignes de cette organisation ». Quand elle est présente, les données sont séparées. Le piège tient au mot penser : une plateforme compte des milliers de requêtes, et un nouveau point d’accès, une tâche de fond, un rapport écrit à la main ou une refonte peuvent livrer un chemin de requête qui oublie tout simplement la clause. Un seul filtre manquant, et une requête renvoie les lignes d’un autre exploitant. Les données ne sont jamais qu’à une erreur de franchir la frontière entre clients, et l’erreur reste invisible jusqu’à la fuite.

L’isolation imposée par la base de données. La frontière est déplacée sous tout cela. eAviora applique la sécurité au niveau des lignes à chaque table partagée, si bien que la base de données elle-même refuse de renvoyer des lignes qui n’appartiennent pas à l’organisation à l’origine de la requête. Une requête qui arrive sans le contexte de l’organisation renvoie zéro ligne à la frontière de la base de données : ni résultat partiel, ni données d’un autre, rien. L’application n’est plus le dernier rempart. C’est la base de données qui l’est.

Voici l’affirmation porteuse, énoncée simplement : dans eAviora, une requête à laquelle manque le contexte de votre organisation renvoie zéro ligne, sur 253 tables propres à une organisation, si bien qu’un seul bogue applicatif ne peut pas exposer les données d’un autre exploitant. La protection ne dépend pas de chaque développeur, ni de chaque fonction future, pensant à ajouter un filtre. Elle dépend de la base de données, qui n’oublie rien.

Pour que cette garantie reste vraie à mesure que le produit grandit, un contrôle d’intégration continue bloque tout nouveau point d’accès ou toute nouvelle table dépourvus du filtre client. Ce contrôle s’exécute automatiquement avant que le code puisse être fusionné. Deux couches indépendantes travaillent donc ensemble : le code qui contourne l’isolation n’est jamais fusionné, et s’il l’était malgré tout, la base de données ne renverrait toujours rien. Les deux couches échouent dans des directions opposées, et c’est précisément le but.

Une revue de sécurité TI ou du RSSI portant sur une plateforme de sécurité est, au fond, la recherche du point unique où une erreur devient une violation. L’isolation entre clients imposée par la base de données place ce point à l’endroit le plus sûr possible. Voici ce qu’il faut demander, et à quoi ressemble une réponse honnête.

• « Montrez-moi où la frontière entre clients est imposée. » La réponse est : dans la base de données, pas dans un chemin de code. Une isolation imposée par la base de données signifie que la frontière tient même quand le code applicatif se trompe.
• « Que se passe-t-il si un développeur oublie le filtre ? » La requête renvoie zéro ligne, parce que la base de données la refuse, et, de façon indépendante, le contrôle d’intégration continue aurait empêché le code d’être fusionné dès le départ.
• « L’API ou une intégration d’IA voient-elles plus qu’un utilisateur ? » Non. Chaque appel machine passe par les mêmes contrôles qu’une personne ; il n’existe aucun chemin parallèle plus faible. Une intégration ne peut pas atteindre des données qu’une personne de la même organisation ne pourrait pas atteindre.
• « Les données sont-elles dans notre juridiction ? » Les enregistrements des exploitants se trouvent dans une seule région de stockage nommée, indiquée dans l’avenant sur le traitement des données avec chaque sous-traitant et la région où il opère. AES-256 au repos, HTTPS en transit.
• « Pouvez-vous prouver ce qui a changé, et quand ? » Oui : une piste d’audit inviolable enregistre chaque modification au moment même où elle se produit, si bien que le journal ne peut pas être modifié après coup pour masquer un changement.

Le contraste à nommer lors d’une revue : de nombreuses plateformes affirment l’isolation sur une diapositive marketing et ne l’imposent que dans le code applicatif, où un seul filtre manquant fait fuir les données entre clients. « Nous avons des contrôles en place » est une posture, pas une frontière. Une requête qui renvoie zéro ligne à la frontière de la base de données est une frontière.

L’isolation imposée par la base de données est le cœur de la réponse, mais une revue veut le tableau complet. Le dispositif qui l’entoure, en bref :

• Région de stockage. Les enregistrements des exploitants se trouvent dans une seule région nommée, indiquée dans l’avenant sur le traitement des données plutôt que vendue comme une fonction.
• Chiffrement. AES-256 au repos ; HTTPS en transit.
• Piste d’audit inviolable. Chaque modification est journalisée au moment même où elle se produit, si bien que le relevé de ce qui s’est passé ne peut pas être discrètement altéré plus tard.
• Registre nominatif des sous-traitants. Les tiers qui traitent des données pour notre compte sont nommés, et non cachés derrière une clause générique.
• Un seul chemin pour chaque appelant. L’API et l’assistant IA passent par la même autorisation, la même isolation imposée par la base de données et la même piste d’audit qu’un utilisateur interactif. Aucun chemin machine n’est plus faible que celui d’une personne.
• SOC 2. Un examen SOC 2 est en préparation ; les contrôles d’architecture sur lesquels porte une revue sont en place dès aujourd’hui.

Chacun de ces points est documenté pour l’approvisionnement. Le centre de confiance couvre la résidence, le chiffrement et le registre des sous-traitants ; la fiche sécurité d’une page est le document court qu’un RSSI peut joindre à une revue ; la documentation pour développeurs décrit comment chaque appel machine est soumis aux mêmes contrôles ; et la politique de confidentialité expose la manière dont les données sont traitées. Pour dérouler une revue TI précise avec votre exploitation, écrivez-nous.