sheelamohanachandran - Fotolia
Cloud : des responsabilités souvent trop diluées
Les RSSI garantissent que les services Cloud qu’ils valident sont conformes aux politiques de sécurité et de gestion du risque. Mais qui a la responsabilité de superviser technologies et données en mode Cloud ?
Les entreprises veulent utiliser des services et applications Cloud. Dès lors, les équipes de sécurité ont besoin d’évaluer les risques associés et de proposer les mécanismes de contrôle appropriés. Résumé ainsi, cela peut paraître simple. Mais sécuriser les actifs Cloud peut présenter de nombreux défis, entre contrôles qui s’y adaptent mal et manque de transparence des fournisseurs de services. Et l’une des principales préoccupations du RSSI en découle : pousser à une plus grande appropriation des risques liés au Cloud au sein de l’entreprise.
Les RSSI doivent jongler avec de nombreuses responsabilités, dont la supervision des équipes projets techniques et la communication, auprès des directions, sur les risques liés au Cloud et les possibilités de remédiation.
Malheureusement, une idée reçue erronée veut que l’organisation chargée de la sécurité informatique soit responsable des risques associés aux projets informatiques, qu’ils soient en interne ou en mode Cloud. Pour les RSSI qui veulent jouer la carte de la flexibilité et s’adapter aux exigences métiers changeantes, il est trop facile de de passer ce problème sous silence lors des discussions, avec les autres personnes impliquées, sur les fournisseurs de services Cloud, les contrôles de sécurité ou encore les scénarios de déploiement.
Le moment est venu pour les RSSI d’orientation la conversation vers l’évaluation du risque et son examen afin que les responsables métiers comprennent effectivement les risques liés au Cloud et les assument – eux, pas l’organisation en charge de la sécurité informatique.
Une évaluation mature du risque
Dans de nombreuses organisations, les équipes de sécurité peinent encore à développer et mettre en œuvre des processus matures d’évaluation et d’examen du risque pour les projets Cloud. Les raisons en sont nombreuses : manque de ressources au sein des équipes de sécurité, apathie des directions, adoption lente du changement, réticence des équipes DevOps, etc. L’implication des équipes de gestion des fournisseurs et des achats, avec les équipes du juridique, est également critique pour évaluer le risque dans les contrats. Les responsables de la sécurité devraient de leur côté profiter des remontées de chacune de ces équipes pour fournir des recommandations objectives de contrôle du risque. Il est important de s’assurer que les responsables métiers comprennent les points suivants :
- Déporter des actifs dans le Cloud n’absout pas de ses responsabilités en matière de protection des systèmes, des applications et des données.
- Les fournisseurs Cloud ne sont pas complètement transparents sur leurs propres contrôles de sécurité et leurs pratiques et processus internes en la matière. Toute discussion sur le risque, de même que l’acceptation du risque, doit s’accompagner de l’avertissement que toutes les parties impliquées prendront probablement leurs décisions avec un niveau d’information limité.
- Les impératifs de conformité devront être examinés attentivement avant tout déploiement Cloud. Et cela nécessitera des ressources supplémentaires. Qui plus est, pour des données soumises à réglementation, le fournisseur de services Cloud devra répondre à certaines exigences.
- Les équipes de gestion des fournisseurs et du juridique devront examiner scrupuleusement les contrats. Ce qui nécessitera des ressources supplémentaires. Tout nouveau fournisseur Cloud devra être étudié précisément avant qu’un métier n’adopte ses applications ou services.
- Il est hautement probable que tous les contrôles de sécurité internes ne fonctionnent pas dans l’environnement Cloud. Ce qui est susceptible de pénaliser l’état de conformité ou d’augmenter les risques liés à l’utilisation du Cloud de manière significative.
- Des produits et services supplémentaires sont susceptibles d’être requis pour créer la parité avec le niveau de sécurité interne existant. Là encore, l’étude des options possibles va demander temps et ressources. Et il est hautement probable que des coûts additionnels seront induits. Ces coûts devront être intégré aux projections financières.
Politique de sécurité pour le Cloud
Dans toute organisation, le conseil d’administration et le Pdg vont au final porter la responsabilité des risques induits par les nouveaux projets IT. Mais il revient aux RSSI de s’assurer que les directeurs métiers aient conscience du fait que, en réalité, ce sont eux les porteurs de ces risques. Trop souvent, l’idée reçue veut que les équipes IT, dépositaires des données, sont responsables des risques induits par de nouveaux projets Cloud. Un excellent point de départ pour remédier à cela est de développer une politique de sécurité complète pour le Cloud, en y intégrant les points suivants :
- Un sponsor clairement identifié : sans le soutien d’un membre de la direction, il est peu probable qu’une politique de sécurité pour le Cloud puisse être appliquée dans l’organisation. Il faut également spécifier clairement qui validera les projets Cloud. Le DSI ?
- Types de données et niveaux de sensibilité qui sont acceptés pour le Cloud ou pas, voire avec quels contrôles de sécurité additionnels.
- Impératifs de conformité requis, le cas échéant.
Les RSSI devraient s’assurer que l’utilisation de services Cloud est conforme avec les législations en vigueur, les pratiques de sécurité de référence ainsi que les politiques de gestion du risque. Et cela vaut également pour toutes les lois de protection de la vie privée. Il est important de s’assurer qu’un dirigeant ou une équipe valide explicitement chaque recours au Cloud après avoir été dûment informé des résultats documents des analyses de risque. Tant que ce processus n’est pas accepté dans l’organisation, la propriété du risque ne se trouve pas là où elle le devrait : entre les mains des cadres de direction et des propriétaires des données.
Adapté de l’anglais.
