Les révélations d’Edward Snowden – concernant le programme confidentiel de surveillance PRISM opéré par l’Agence de Sécurité Nationale (NSA) des Etats Unis – ne font que renforcer et mettre en lumière que le domaine des télécommunications, au sens large du terme, revêt une importance géostratégique de premier plan. Une importance telle, qu’à partir du moment où les moyens existent, on ne peut présupposer de l’absence de volonté d’exploiter ces moyens à des fins non clairement communiqués.
Certes, les révélations liées à PRISM renforcent la criticité de la dimension sécurité (pourtant déjà élevée) dans les logiques de transformation des systèmes d’information vers le modèle Cloud, mais cela ne change rien au fait que les initiatives Cloud, sont menées dans un cadre de réduction des coûts, dans la considération des bénéfices en terme de couverture et de flexibilité. A ce titre, la sécurité est souvent considérée comme un centre de coût, en contradiction avec le bénéfice escompté.
Cette actualité particulière a donné lieu à l’émergence d’une notion de Cloud Souverain, qui tendrait à considérer la nationalité du fournisseur de service Cloud et/ou la localisation des infrastructures et des équipes soutenant ce service, comme un facteur prépondérant d’un point de vue sécurité. Ne nous voilons pas la face, le principe d’un contrôle étatique par défaut des communications n’est pas un singularisme américain. C’est une voie sur laquelle s’est engagée la Chine (Great Firewall of China) et sur laquelle nous nous engageons. La récente promulgation de la Loi de Programmation Militaire (au Journal Officiel du 19/12/2013) et son article 20, si controversé (assouplissement des conditions d’accès administratif aux données de connexion avec la suppression de la nécessité de l’intervention de l’autorité judiciaire), l’illustrent.
Alors, finalement, quel bilan factuel sur les entreprises françaises ?
En premier lieu, pas ou peu d’impact sur les contrats en cours. Lors des derniers mois, pratiquement aucune société ayant souscris discrètement ou globalement à des offres de cloud de fournisseurs américains n’a dénoncé son contrat. Ce peut être dû à plusieurs paramètres: réversibilité potentiellement complexe, engagement de baisse de coût, charge et aléas d’une rupture contractuelle….
Personnellement, je pense que si les contrats n’ont pas été dénoncés, c’est qu’ils ne comportent potentiellement pas de clauses permettant au client de le rompre unilatéralement sur la base des révélations liées à PRISM. En effet, toutes les entreprises américaines interrogées ont toujours été claires sur le fait qu’elles ne pouvaient se soustraire aux injonctions de leur gouvernement, concernant le Patriot Act par exemple.
Ce point permet de souligner et de comprendre l’importance du cadre juridique sur les services Cloud, induisant un engagement requis du RSSI dans la négociation et la gouvernance contractuelle du service à rapprocher du modèle « Plan d’Assurance Sécurité » commun dans les services d’externalisation.
Donc pas d’impact visible sur les contrats en cours… L’impact est donc sur la partie immergée, c’est à-dire sur les nouveaux contrats pour lesquels le critère de localisation des services et la nationalité du fournisseur prennent une importance croissante dans les critères de décision.
Dans la pratique, quelles sont les applications en entreprise ?
Considérant les offres de Cloud type « Infrastructure as a Service » ou « Platform as a Service », les cas d’usage public, majoritairement rencontrés au sein des entreprises françaises, portent essentiellement sur des systèmes ne comportant pas de données critiques ( des systèmes de développement ou de pré-production par exemple). Une approche privée ou privative semble
rencontrer plus de succès dans une optique production plus critique. Typiquement, on ne voit pas ou peu de clients qui installent leur Siebel ou leur SAP sur des Cloud publics.
En revanche, les approches « Software as a Service », que ce soit sur des briques de communication, collaboration (messagerie, agenda, collaboration…) ou sur des périmètres plus métier (Gestion de la Relation Client), apparaissent beaucoup plus développées. Le fait que le service Cloud porte un engagement global est un gage de succès.
L’état du marché laisse à penser que l’on passe d’un modèle où les pourvoyeurs d’innovation (développeurs de logiciels) portaient leur solution auprès des divisions métiers qui ensuite s’appuyaient sur leur équipe IT pour la mise en place pratique de cette innovation, vers un modèle « direct » ou l’innovation est « vendue » sous forme de service.
Cette transformation expliquerait notamment le vif succès des offres « Infrastructure as a Service » et « Platform as a Service » auprès des éditeurs.
Mais la sécurité dans tout ça… quel choix pour les entreprises ?
Aujourd’hui, ne pas intégrer l’évaluation de modèle Cloud dans une stratégie IT constitue une faute et positionner la sécurité comme un frein, une erreur. Comme pour tout changement, le modèle Cloud doit être pesé dans un cadre dépassionné et rationnel de gestion du risque pour les entreprises françaises.
Ce que l’on peut espérer comme conséquence positive de l’affaire PRISM, c’est que les nuages se dissipent pour permettre d’éclairer cette gestion du risque. Cette transparence permettrait à chacun d’évaluer les contrôles fournis par chaque service, chaque contrôle étant pondéré en regard de la criticité métier propre à chaque cas de figure, tendant à des logiques actuarielles.
Ce type d’approche commence à se décliner pour aboutir à une inclusion du modèle au niveau de la politique de sécurité. Cette inclusion est permise par la définition d’un niveau de contrôle requis en fonction de la criticité des applications et données considérées.
Au-delà, la question interpelle également sur la manière dont le sujet sécurité est traité au travers du Cloud. La nature même du modèle fait qu’il peut s’avérer difficile de le rendre conforme aux exigences, ou à la stratégie sécurité du client, sur la base d’un modèle « tout inclus ». Ce problème renvoie à la flexibilité des solutions de Cloud :
- A supporter des contrôles de sécurité en production :
- Suis-je capable de positionner mon dispositif de sécurité système d’entreprise et le gérer ?
- Est-il possible de provisionner mon Cloud avec mes propres solutions et services de sécurité réseaux ?
- A être intégrées de manière transparente dans les modèles de gestion du risque en continu, de conformité et de gouvernance:
- Comment collecter et intégrer les logs de mon ou mes cloud(s) dans mon système de cyber surveillance ? Et quels types de logs suis-je capable de collecter ?
- Comment puis-je m’assurer que les contrôles de sécurité sont conformes à ma politique de sécurité (règles de firewall, couverture anti-virus, gestion des vulnérabilités et des correctifs…) ?
C’est à ce niveau, à mon sens, que se situe le débat le plus intéressant, renvoyant à des principes de séparation des responsabilités et de spécialisation sur le sujet sécurité dans l’intégralité de ses dimensions.