Ce billet de blog, deuxième partie d’une série, explique comment renforcer la sécurité d’une application au-delà du contrôle d’accès (RBAC) pour répondre aux exigences SOC 2. L’auteur propose une architecture à trois bases de données distinctes (données, audit et clés) pour isoler physiquement les informations sensibles, garantissant ainsi l’intégrité des logs et une gestion sécurisée des clés de chiffrement. L’isolation physique et logique des bases de données limite les risques de compromission globale en cas d’attaque ciblée.
Pour assurer l’intégrité des logs, l’auteur recommande l’utilisation du Outbox Pattern combiné à Symfony Messenger. Cette méthode enregistre les intentions de journalisation dans une table dédiée au sein de la base de données principale, puis les transfère de manière asynchrone vers la base de logs (audit.db) via un worker. Cela résout les problèmes de performance et d’atomicité, évitant les incohérences entre les actions enregistrées et les logs.
Enfin, la gestion des clés de chiffrement est externalisée via un Key Management Service (KMS) avec un système de Master Key Sharding. Les clés maîtresses sont chiffrées et stockées séparément, et leur rotation est gérée de manière à limiter l’impact d’une éventuelle compromission. Cette approche renforce la sécurité de l’infrastructure tout en respectant les principes de SOC 2.
Cet article explore les limites du contrôle d'accès basé sur les rôles (RBAC) et du chiffrement au repos pour répondre aux exigences SOC 2, soulignant que ces méthodes ne protègent pas contre les accès non autorisés une fois l'application ou les identifiants compromis. L'auteur propose une approche plus robuste avec le chiffrement au niveau applicatif, utilisant une stratégie hybride combinant chiffrement symétrique (AES-256-GCM) pour les données et asymétrique (RSA avec OAEP) pour les clés, afin d'isoler cryptographiquement les enregistrements.
L'architecture repose sur le modèle d'enveloppe, où chaque document est chiffré avec une clé unique (DEK), elle-même chiffrée avec la clé publique du destinataire. Ce système garantit que même en cas de fuite des identifiants de la base de données, les données restent inaccessibles sans la clé privée correspondante. L'article insiste sur l'importance des modes de chiffrement authentifiés (GCM) et des mécanismes de rembourrage sécurisés (OAEP) pour prévenir les attaques par modification ou oracle.
Enfin, l'auteur détaille la modélisation des données avec Symfony et Doctrine, où chaque utilisateur possède une paire de clés asymétriques, la clé privée étant gérée par un coffre-fort ou un HSM. Cette approche permet une isolation cryptographique au niveau des enregistrements, renforçant ainsi la conformité SOC 2 en matière de traçabilité et de protection des données.