Conformité

La page d'accueil indique “piste d'audit &mdash ; intégrée.” Cette page est ce que cette phrase doit survivre : le mécanisme réel, le code réel, et un outil qu'un auditeur peut exécuter sans nous demander de faire confiance à un tableau de bord.

L'enregistrement d'audit : chaînage de hachages, activé par défaut

Chaque événement d'audit qu'Odysseus écrit est chaîné à celui qui le précède. Chaque ligne stocke entry_hash = SHA-256(prev_hash || canonical_json(event)), de sorte que la modification ou la suppression d'une ligne casse le hachage de tout ce qui a été écrit après &mdash ; pas seulement de cette ligne.

Ce n'est pas une fonctionnalité optionnelle que vous devez vous souvenir d'activer. Le propre commentaire de documentation de HashChainConfig le déclare clairement : “La chaîne est ACTIVÉE PAR DÉFAUT &mdash ; la valeur zéro (Disabled: false) &hellip ; omet le bloc HashChain obtient un audit inviolable sans étape de configuration supplémentaire” (pkg/audit/hash_chain.go:19-23). Le plan de contrôle l'annonce au démarrage : “Audit hash chain enabled (default-on; set HashChain.Disabled=true to opt out)” (pkg/audit/postgres_logger.go:247). Le désactiver est une action délibérée et journalisée, et non un comportement par défaut que vous devez découvrir.

Ancrage et un témoin externe — tous deux facultatifs, tous deux enfichables

En plus de la chaîne, Odysseus peut périodiquement ancrer un hachage à deux endroits pour lesquels vous n'avez pas à nous faire confiance :

• Signature via Vault Transit. Lorsque HashChainConfig.VaultTransitKey est défini, le hachage d'entrée de chaque ancrage est signé via l'endpoint transit/sign/{key} de Vault avant d'être stocké (pkg/audit/hash_chain.go:43-46, pkg/audit/postgres_logger.go:850-861). Laissez la clé non définie et aucune signature n'est effectuée — c'est facultatif, pas une dépendance cachée.
• Un témoin externe. Le éditeur d'ancrage accepte tout témoin implémentant une petite interface — Consul KV, un compartiment S3 WORM, ou un autre magasin de votre choix — et y reflète l'ancrage après qu'il a été écrit localement de manière durable. Un témoin nil désactive simplement le miroir externe ; l'intégrité locale n'en dépend pas (pkg/audit/hash_chain.go:51-56, pkg/audit/postgres_logger.go:863-889).

Un outil, pas une capture d'écran

odysseus-audit-verify est un binaire autonome &mdash ; son propre paquet main à cmd/odysseus-audit-verify/main.go, construit et livré séparément du plan de contrôle. Fournissez-lui les identifiants pour la base de données d'audit et il parcourt chaque ligne dans l'ordre sequence_num, recalcul chaque hachage et vérifie chaque ancre. Il ne passe pas par l'API Odysseus, le tableau de bord ou quoi que ce soit que la plateforme elle-même rend. Il se connecte directement à Postgres, ce n'est donc pas un outil à réseau zéro, mais il est indépendant du plan de contrôle en cours d'exécution : un auditeur peut le pointer vers une réplica de base de données et obtenir une réponse que personne chez Delta Telematics ne peut influencer.

Il signale un code de sortie distinct pour chaque classe de problème, documenté dans le commentaire d'en-tête du binaire lui-même :

Code de sortie	Signification
0	Chaîne intacte, toutes les ancres correspondent
1	Défaut d'intégrité de la chaîne — lien rompu, hachage incohérent, entrée manquante
2	Échec de vérification de l'ancre — hachage de l'ancre incohérent ou signature invalide
3	Erreur opérationnelle — base de données inaccessible, ligne malformée, etc.

Source : cmd/odysseus-audit-verify/main.go, lignes 12–18 (comportement documenté) et 56–59 (les constantes de code de sortie elles-mêmes).

Isolement des locataires que la base de données applique, pas seulement l'application

Trois limites distinctes, chacune vérifiable indépendamment dans le code :

• Sécurité au niveau des lignes Postgres, échec à la fermeture. La table d'audit s'exécute avec ENABLE ROW LEVEL SECURITY et FORCE ROW LEVEL SECURITY tous deux définis — un test dédié affirme que les deux sont true et explique pourquoi : sans eux, “chaque test ici réussirait tandis que les locataires liraient le journal d'audit des uns et des autres” (pkg/audit/postgres_rls_test.go:197). Si le contexte de sécurité du locataire ne peut pas être défini pour une requête, la requête ne s'exécute pas — le chemin du code est étiqueté // Fail-closed: if we can't set RLS context, don't proceed with the query (pkg/audit/postgres_logger.go:1067).
• Chemins Vault par locataire. Les secrets de chaque locataire se trouvent sous tenants/<tenantID>/, et la validation des chemins rejette tout ce qui est en dehors de ce préfixe (pkg/vault/validation.go:25,51,61).
• Réseaux Docker par locataire. Les réseaux internes sont nommés <tenantID>-<network>, et le réseau par défaut d'un locataire est odysseus-<tenantID>-default &mdash ; il n'y a pas de réseau interne partagé sur lequel les conteneurs d'un locataire atterrissent par défaut (pkg/docker/client.go:1647-1652,1697-1700).

Où nous en sommes réellement

Nous ne détenons pas de certification, et nous n'en suggérons pas une. Ce que nous avons est un mapping documenté et auto-évalué de nos contrôles par rapport à cinq frameworks, contenu dans le document d'audit de l'équipe sécurité plutôt que dans le contenu marketing :

Cadre	Prêt en interne	Notes
SOC 2 Type II	85%	Contrôle d'accès, journalisation d'audit
ISO 27001	80%	Contrôles de sécurité de l'information
RGPD	75%	Contrôles de protection des données
PCI DSS	70%	Ne gère pas les données de paiement
HIPAA	60%	Pas notre cas d'usage principal

Source : docs/security/02-owasp-security-audit.md, tableau “Compliance Mapping”, lignes 490–498.

Pour l'audit qui a produit la posture de sécurité sur laquelle reposent ces contrôles, voir la page audit de sécurité. Pour l'architecture de sécurité quotidienne &mdash ; authentification, secrets, durcissement de l'infrastructure &mdash ; voir Sécurité.