Comprendre la conformité SOC 2 pour les containers et le cloud

Si vous participez à la gestion ou à la sécurisation d’environnements cloud ou en containers, vous n’êtes probablement pas impatient de préparer des rapports SOC 2. La conformité à la norme SOC 2 peut sembler fastidieuse.

Toutefois, lorsque vous considérez que le respect des règles SOC 2 vous permet d’éviter les pénalités et les amendes qui peuvent résulter de la violation d’autres règles de conformité, la valeur du temps et des efforts requis pour la conformité SOC 2 devient évidente. En fournissant des alertes précoces sur les problèmes de conformité potentiels, les rapports SOC 2 vous permettent d’anticiper les problèmes avant qu’ils ne fassent boule de neige et ne deviennent des risques de conformité plus importants.

Dans cet article, nous expliquons ce qu’il faut savoir sur la conformité SOC 2 lorsqu’on travaille spécifiquement avec des environnements basés sur le cloud et les containers. Comme nous le verrons, bien que les règles SOC 2 ne fournissent pas de directives spécifiques sur la manière de sécuriser les données dans ces environnements, il existe certaines bonnes pratiques de base que les équipes devraient adopter lorsqu’elles se préparent au reporting et à la conformité SOC dans ces contextes.

Qu’est-ce que le SOC 2 ?

SOC 2 est un ensemble de critères que les entreprises doivent respecter lorsqu’elles gèrent les données des clients. Il fait partie du dispositif législatif System and Organization Controls (SOC) développé par l’Institut américain des comptables publics certifiés (AICPA).

Il existe trois contrôles SOC : SOC 1, qui traite de l’information financière, SOC 2, et SOC 3, qui se concentre sur la disponibilité et la sécurité des systèmes. Cependant, parmi les trois contrôles SOC, le SOC 2 est devenu de plus en plus important dans le contexte de l’informatique cloud moderne, car il a des implications importantes pour les architectures centrées sur le cloud, comme le SaaS, qui, par nature, impliquent le stockage ou le traitement des données des clients sur une infrastructure tierce ou avec des applications tierces.

Quelles sont les exigences de la norme SOC 2 ?

La conformité à la norme SOC 2 s’articule autour de cinq critères dits de services de confiance : sécurité, disponibilité, intégrité du traitement, confidentialité et vie privée.

Pour se conformer à la norme SOC 2, les organisations doivent donc être en mesure de démontrer qu’elles respectent les règles suivantes :

Sécurité : elles mettent en œuvre des mesures de sécurité raisonnables dans les applications, les réseaux et l’infrastructure.
Disponibilité : en utilisant des techniques et des pratiques comme la reprise après sinistre, elles maintiennent la disponibilité des systèmes.
Intégrité du traitement : elles contrôlent le traitement des données pour en garantir l’exactitude et traitent les problèmes de qualité des données.
Confidentialité : elles assurent la sécurité des données sensibles (c’est-à-dire qu’elles les protègent contre une mauvaise utilisation, une manipulation ou un abus) en utilisant des méthodes telles que le contrôle d’accès et le chiffrement.
Confidentialité : elles préservent la confidentialité des données (ce qui signifie que seuls les utilisateurs qui devraient être autorisés à y accéder peuvent le faire) en utilisant l’authentification, les contrôles d’accès et le chiffrement.

Pour obtenir tous les détails sur les critères des services Trust SOC 2, consultez la documentation sur les critères des services Trust de l’AICPA. La documentation précise un certain nombre de « contrôles » que les entreprises doivent mettre en œuvre pour répondre aux critères des services Trust.

Comment fonctionnent les rapports SOC 2 ?

Pour démontrer leur conformité à la norme SOC 2, les organisations préparent un rapport qui s’attache à démontrer comment leurs architectures informatiques et leurs processus de gestion sont conformes aux cinq critères des services Trust.

Toutefois, contrairement à de nombreux autres dispositifs législatifs de conformité, le SOC 2 est célèbre pour son manque de précision quant aux informations qui doivent figurer dans les rapports de conformité. Il laisse essentiellement aux organisations le soin d’interpréter la manière dont les critères des services Trust doivent être appliqués à leurs environnements.

Qui doit se conformer à la norme SOC 2 ?

Étant donné que la norme SOC 2 est élaborée par une organisation indépendante plutôt que par une agence de réglementation, il n’existe pas d’obligation légale de s’y conformer. Il n’existe pas non plus de sanctions en cas de non-conformité à la norme SOC 2.

Cependant, de nombreuses entreprises préparent volontairement des rapports SOC 2 afin d’identifier les risques qui pourraient entraîner des violations d’autres dispositifs législatifs de conformité. Par exemple, un audit SOC 2 peut identifier des contrôles d’accès faibles aux données des clients dans une application ou un manque de chiffrement lors du transport des données des clients sur le réseau. Des problèmes de ce type pourraient vraisemblablement devenir des violations des lois de conformité réglementaire comme l’HIPAA ou le GDPR, selon le type de données concernées. En identifiant le problème grâce à un rapport SOC 2, vous pouvez le résoudre avant qu’il ne se transforme en problème réglementaire.

Dans le même ordre d’idées, les organisations peuvent également utiliser les rapports SOC 2 pour démontrer à leurs clients ou partenaires qu’elles respectent les meilleures pratiques en matière de sécurité. Les fournisseurs de clouds publics utilisent par exemple SOC 2 à cette fin.

Contrôles SOC 2 pour les containers et le cloud

En général, seuls deux ensembles de contrôles de sécurité SOC 2 ont des implications pour les containers et le cloud. Le premier ensemble est constitué par la famille des contrôles d’accès logique et physique, et le second par la famille des contrôles d’exploitation des systèmes.

Voici un résumé de chaque famille de contrôle et de ce qu’elle signifie pour les containers et le cloud.

Famille de contrôles d’accès logiques et physiques

Cette famille de contrôles comprend six contrôles qui sont pertinents pour les environnements de containers et de cloud :

CC6.1 : dans les images de containers et dans les environnements de moteur d’exécution, des outils doivent être mis en place pour se protéger contre les événements de sécurité tels que l’élévation de privilèges. Des outils comme Kubernetes RBAC peuvent vous être utiles dans cette optique.
CC6.2 : les tentatives d’accès non autorisées doivent être détectées et bloquées. Les journaux d’audit Kubernetes sont un moyen utile de détecter de telles tentatives.
CC6.3 : empêchez les tentatives de contournement des mécanismes de contrôle d’accès. Là encore, les journaux d’audit de Kubernetes peuvent être utiles pour détecter de telles tentatives.
CC6.6 : les connexions réseau non autorisées doivent être détectées. Les outils de surveillance du réseau et les politiques réseau Kubernetes sont utiles ici. Il en va de même pour les services Mesh, qui peuvent restreindre les interactions entre les microservices.
CC6.7 : les données secrètes (telles que les mots de passe) doivent être gérées de manière sécurisée. Sécuriser Kubernetes etcd est important à cet effet, tout comme éviter les secrets codés en dur dans les images de containers ou les déploiements.
CC6.8 : détectez les logiciels malveillants dans les images de containers et empêchez leur déploiement. L’analyse des images de containers est la ressource clé pour cette tâche.

Famille de contrôle des opérations du système

Dans la famille des contrôles des opérations du système, il y a deux contrôles à suivre :

CC7.2 : détectez les anomalies qui pourraient signaler des événements de sécurité. À cette fin, collectez et analysez les journaux des containers, les journaux d’audit de Kubernetes, les journaux des OS des nœuds et d’autres sources de données similaires en temps réel.
CC7.3 : évaluez les événements de sécurité pour comprendre leur impact. La capacité à croiser diverses sources de données – telles que, là encore, les journaux de containers, les journaux d’audit Kubernetes et les journaux des serveurs de nœuds – est essentielle à cette fin, car cela vous permet d’interpréter les relations entre les événements de sécurité et d’identifier les risques de sécurité à la source.

Conclusion

Même si vous n’êtes pas légalement tenu de vous conformer aux contrôles de sécurité du SOC 2, le peu de temps et d’efforts requis pour effectuer un audit de conformité à la norme SOC 2 peut être très avantageux en vous permettant d’anticiper les problèmes de conformité qui pourraient se transformer en amendes réglementaires. SOC 2 est également un moyen précieux de démontrer à vos clients votre engagement en faveur de la sécurité et de la confidentialité des données.

Et, en ce qui concerne les containers et la sécurité, les règles SOC 2 ne sont pas particulièrement complexes ou étendues. C’est une raison supplémentaire pour laquelle la conformité à la norme SOC 2 est une proposition évidente pour toute organisation qui gère une infrastructure dans le cloud.