puisque ce partage est clairement annoncé dans les conditions générales d’utilisation,
que l’utilisateur a généralement validées sans les lire. Ainsi, sans le savoir,
l’utilisateur divulgue des informations internes à l’entreprise.
Vulnérabilités : les services de cloud ne sont pas mieux sécurisés que les autres
logiciels. Ils sont donc sujets à des vulnérabilités qui, parfois, donnent lieu à de réels
incidents de sécurité. Par exemple, il est arrivé que le système d’authentification d’un
site de partage de fichiers soit inopérant suite à une faille de sécurité, donnant ainsi un
accès libre à tous les utilisateurs du service. De plus, on ne compte plus les sites,
même prestigieux, qui se font pirater les identifiants de leurs utilisateurs, mettant ainsi
en danger leurs données.
Ces arguments montrent bien que lutter contre le cloud spontané n’est pas un acte
idéologique, promu par une DSI voyant d’un mauvais œil ces services faisant échapper
de son contrôle les utilisateurs. Au contraire, lutter contre le cloud spontané est
nécessaire pour préserver le patrimoine informationnel de l’entreprise.
Comment sécuriser ?
La question qui se pose logiquement maintenant est comment sécuriser le cloud
spontané. Plusieurs approches sont possibles.
La première réponse consiste à lutter, à proprement parler, contre les pratiques de cloud
spontané. Les moyens techniques ne manquent pas. En effet, il est très simple pour un
RSSI de bloquer les sites fournissant de tels services. Il suffit d’agir au niveau du proxy
HTTP, du pare-feu ou sur tout autre équipement en coupure entre le poste de travail et
Internet. Attention, toutefois, aux effets secondaires d’une telle réaction, car cette mesure
ne manquera pas de générer un réel mécontentement de la part des utilisateurs, qui ne se
priveront pas de chercher immédiatement des contournements. La lutte frontale contre le
cloud spontané n’est donc généralement pas une bonne option et ne se justifie que si des
risques immédiats et importants ont été identifiés.
L’interdiction des sites de cloud spontané n’est pas, en soi, à proscrire. En revanche,
toute interdiction doit s’accompagner d’une proposition de service alternative, isofonctionnelle et tout aussi pratique que celle utilisée spontanément par l’utilisateur. Le
RSSI doit donc étudier la mise en place de plates-formes de messagerie instantanée,
d’échanges de fichiers, de visioconférence ou de prise en main à distance maîtrisées et
sécurisées. Parfois, ces solutions sont déjà en production dans l’entreprise et sont tout
simplement ignorées des utilisateurs. Il suffit dans ce cas d’informer ces derniers que
telle ou telle infrastructure, proposée par la société, répond déjà aux besoins en question.
Dans d’autres cas, le recours aux clouds spontanés comble effectivement un manque. Il
sera alors nécessaire d’étudier puis de mettre en place un nouveau service répondant aux
besoins, mais maîtrisé par la DSI.
Pour résumer, si un service équivalent est déjà proposé par l’entreprise, le RSSI peut
interdire le service spontané pour imposer l’alternative. Dans le cas contraire, il sera
prudent de retarder toute interdiction jusqu’à être en mesure de proposer une alternative
satisfaisante. Naturellement, en cas de risque majeur et immédiat, le RSSI ne doit pas se
priver de bloquer tel ou tel site, et ce, qu’il y ait une alternative ou pas.
que l’utilisateur a généralement validées sans les lire. Ainsi, sans le savoir,
l’utilisateur divulgue des informations internes à l’entreprise.
Vulnérabilités : les services de cloud ne sont pas mieux sécurisés que les autres
logiciels. Ils sont donc sujets à des vulnérabilités qui, parfois, donnent lieu à de réels
incidents de sécurité. Par exemple, il est arrivé que le système d’authentification d’un
site de partage de fichiers soit inopérant suite à une faille de sécurité, donnant ainsi un
accès libre à tous les utilisateurs du service. De plus, on ne compte plus les sites,
même prestigieux, qui se font pirater les identifiants de leurs utilisateurs, mettant ainsi
en danger leurs données.
Ces arguments montrent bien que lutter contre le cloud spontané n’est pas un acte
idéologique, promu par une DSI voyant d’un mauvais œil ces services faisant échapper
de son contrôle les utilisateurs. Au contraire, lutter contre le cloud spontané est
nécessaire pour préserver le patrimoine informationnel de l’entreprise.
Comment sécuriser ?
La question qui se pose logiquement maintenant est comment sécuriser le cloud
spontané. Plusieurs approches sont possibles.
La première réponse consiste à lutter, à proprement parler, contre les pratiques de cloud
spontané. Les moyens techniques ne manquent pas. En effet, il est très simple pour un
RSSI de bloquer les sites fournissant de tels services. Il suffit d’agir au niveau du proxy
HTTP, du pare-feu ou sur tout autre équipement en coupure entre le poste de travail et
Internet. Attention, toutefois, aux effets secondaires d’une telle réaction, car cette mesure
ne manquera pas de générer un réel mécontentement de la part des utilisateurs, qui ne se
priveront pas de chercher immédiatement des contournements. La lutte frontale contre le
cloud spontané n’est donc généralement pas une bonne option et ne se justifie que si des
risques immédiats et importants ont été identifiés.
L’interdiction des sites de cloud spontané n’est pas, en soi, à proscrire. En revanche,
toute interdiction doit s’accompagner d’une proposition de service alternative, isofonctionnelle et tout aussi pratique que celle utilisée spontanément par l’utilisateur. Le
RSSI doit donc étudier la mise en place de plates-formes de messagerie instantanée,
d’échanges de fichiers, de visioconférence ou de prise en main à distance maîtrisées et
sécurisées. Parfois, ces solutions sont déjà en production dans l’entreprise et sont tout
simplement ignorées des utilisateurs. Il suffit dans ce cas d’informer ces derniers que
telle ou telle infrastructure, proposée par la société, répond déjà aux besoins en question.
Dans d’autres cas, le recours aux clouds spontanés comble effectivement un manque. Il
sera alors nécessaire d’étudier puis de mettre en place un nouveau service répondant aux
besoins, mais maîtrisé par la DSI.
Pour résumer, si un service équivalent est déjà proposé par l’entreprise, le RSSI peut
interdire le service spontané pour imposer l’alternative. Dans le cas contraire, il sera
prudent de retarder toute interdiction jusqu’à être en mesure de proposer une alternative
satisfaisante. Naturellement, en cas de risque majeur et immédiat, le RSSI ne doit pas se
priver de bloquer tel ou tel site, et ce, qu’il y ait une alternative ou pas.