Livre blanc. Assurer la sécurité des systèmes logiciels dans le cloud

Transcription

1 Livre blanc Assurer la sécurité des systèmes logiciels dans le cloud

2 La plupart des discussions relatives à la sécurité dans le cloud se sont jusqu'ici concentrées sur ce que les fournisseurs de cloud peuvent faire, sur ce qu'ils ne peuvent pas faire et sur ce qu'ils pourraient faire si vous les payez assez cher. Ces discussions sont axées sur des thèmes tels que la virtualisation, l'hébergement et le stockage de données. Cependant, à l'heure où l'industrie logicielle a compris que mettre des catégories fantaisistes sur le réseau ne suffisait pas à améliorer de mauvais logiciels, le cloud concentre l'attention sur les risques liés aux logiciels déployés. Ce livre blanc détaille les risques liés au logiciels déployés dans le cloud. Certains risques ont le même impact sur la sécurité quels que soient le lieu et le type d'hébergement des logiciels. Cependant, de nombreux risques existants prennent une nouvelle importance lorsque les logiciels passent en mode cloud. Les attaques qui exploitent l'environnement logiciel, les services et les systèmes sur lesquels sont basés les logiciels ainsi que les canaux de communication utilisés par les logiciels pour communiquer ont une nouvelle signification dans le cloud. Les choix liés au contrôle de l'authentification et de l'accès, les algorithmes de cryptage et les stratégies relatives aux données confidentielles doivent également être revus. Nous allons traiter les préoccupations qui prévalent dans tous ces domaines et décrire une approche d'évaluation afin de déterminer si un système logiciel est prêt à être déployé dans le cloud. Gérer le risque dans le cloud Grâce à la promesse de la réduction des coûts, du temps de disponibilité plus long, de la flexibilité accrue et du déploiement rapide, le cloud computing a suscité un vif intérêt dans le monde de la haute technolo gie. Au vu des bénéfices mis en avant, la plupart des services informa tiques examinent actuellement si le cloud computing répond aux besoins de leur entreprise et, si tel est le cas, comment migrer leur infrastructure sur site actuelle. Le cloud computing comprend le logiciel en tant que service (SaaS), la plateforme en tant que service (PaaS) et l'infrastructure en tant que service (IaaS). Le SaaS et la PaaS conviennent très bien à de nouveaux programmes spécialement créés pour le cloud. L'IaaS offre la meilleure opportunité de tirer profit du cloud sans écrire une énorme quantité de codes. Les services informatiques sont généralement surtout préoccupés par la disponibilité de l'infrastructure, la facilité de gestion, la sécurité et le coût. Les préoccupations liées à la sécurité les plus fréquemment étudiées sont axées sur la sécurité offerte par le fournisseur de cloud proprement dit. Alors que la sécurité côté fournisseur est une préoccupation à prendre en compte, la sécurité des programmes qui seront déployés dans le cloud et les modifications générées par la migration vers le cloud sont souvent négligées. Ce livre blanc décrit certains des risques spécifiques liés au déplacement de logiciels vers un fournisseur de cloud, la manière dont des risques existants en matière de sécurité peuvent se modifier lorsque des programmes sont migrés vers un fournisseur de cloud et comment ces soucis de sécurité peuvent être traités pour réduire le risque lors du déploiement chez un fournisseur de cloud. Il se concentre sur les risques de sécurité liés à une migration de l'iaas plutôt que sur les capacités ou les API spécifiques aux fournisseurs de cloud. Les thèmes mentionnés ici concernent donc de nombreux systèmes logiciels déployés dans de grands datacenters privés virtualisés, ainsi que dans l'ensemble du cloud. Dans la partie suivante, nous décrivons des risques de sécurité liés aux canaux de communication, aux systèmes externes, au cryptage et à l'environnement utilisés par un programme. Nous y évoquons également des mesures spécifiques que le propriétaire du programme peut prendre pour réduire ces risques. Les problèmes tels que la classification des données, les stratégies de rétention et de destruction des données ainsi que les problèmes de conformité liés à la possession de données de tiers et les problèmes de confidentialité doivent tous être examinés mais dépassent le cadre de ce document. Sécurité : vous ne pouvez pas l'emporter avec vous Votre datacenter réduit probablement les vulnérabilités de votre code. Le passage en mode cloud peut interrompre cette réduction et vous rendre vulnérable aux attaques. Une des plus grandes différences entre le déploiement de logiciels vers un fournisseur de cloud par rapport à un datacenter privé est l'absence d'une infrastructure réseau d'entreprise. Au fil du temps, les entreprises créent des couches complexes d'infrastructure réseau et prennent en charge des systèmes incluant le DNS, le routage, les parefeu, la détection des intrusions, la gestion des correctifs d'entreprise, l'analyse des journaux et les systèmes d'alerte. Ceci permet de fournir des solutions à l'échelle de l'organisation. Cette infrastructure répond aux besoins des groupes de développement avec des solutions sur mesure pour l'entreprise. Les développeurs peuvent ainsi se concentrer sur la sécurité du code qu'ils écrivent plutôt que sur l'infrastructure sur laquelle est basé ce code. Le déplacement d'un programme d'un datacenter interne doté d'une infrastructure spécialisée vers un fournisseur de cloud modifie généralement le modèle de risque du programme dans les domaines suivants : Canaux de communication Infrastructure de journalisation Stockage de données Cryptage Influences environnementales Cette partie évoque les préoccupations spécifiques à chacun de ces domaines et décrit comment réduire les risques impliqués. Reconsidérer votre manière de communiquer En sortant d'un datacenter interne, vous renoncez à la protection offerte par le pare-feu de l'entreprise et les mécanismes internes de routage du réseau. Le fait de renoncer à l'infrastructure spécialisée oblige en particulier les développeurs à reconsidérer la manière dont leurs codes traitent les éléments suivants : Communication cryptée/non cryptée Adresses IP codées en dur Noms d'hôtes codés en dur Les stratégies de classification de la plupart des entreprises détaillent les stratégies de communication concernant l'envoi d'informations via des réseaux externes ; un programme existant créé pour une utilisation interne n'aura cependant pas tenu compte de la transmission externe. Par exemple, la communication en texte clair de certaines classifications de données peut être autorisée dans des réseaux internes mais nécessiter une protection accrue lors du transfert via un réseau externe. Suite à cette modification du contrôle de l'infrastructure réseau, les programmes déployés dans le cloud doivent assurer toute la communication entre les composants par le biais de canaux cryptés. Les programmes créent et utilisent des canaux de communication de multiples manières, mais certaines garanties de communication cryptée peuvent être appliquées dans l'ensemble d'un programme. Java et.net offrent par exemple des possibilités de forcer l'interaction Web via des transports SSL. 2

3 Dans Java, ceci peut être appliqué en ajoutant des informations au fichier de configuration de l'application Web web.xml pour l'option des problèmes de sécurité et en mettant la garantie de transport sur CONFIDENTIEL comme suit : <security-constraint> <web-resource-collection> <web-resource-name>restricted URLs</web-resource-name> <url-pattern>/</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>confidential</transport-guarantee> </user-data-constraint> </security-constraint> Les demandes de Microsoft.NET peuvent être forcées à utiliser le protocole SSL en vérifiant si l'objet HttpContext.Current.Request est le reflet d'une connexion sécurisée, puis en redirigeant la demande via SSL si la connexion n'est pas sécurisée. L'extrait de code suivant d'un fichier global. asax.cs permettra d'obtenir l'effet désiré : protected void Application_ BeginRequest(Object sender, EventArgs e) { if (HttpContext.Current.Request. IsSecureConnection.Equals(false)) { Response.Redirect( + Request.ServerVariables[ HTTP_HOST ] + HttpContext.Current. Request.RawUrl); } } Les adresses IP de réseau codées en dur s'avèrent imprévisibles pour un programme déployé dans le cloud. De même que l'absence de règles pour le routage interne au réseau peut rendre des informations sensibles vulnérables pendant leur transmission, des adresses IP codées en dur peuvent être à l'origine de la livraison d'informations sensibles à une destination erronée. Dans le meilleur des cas, un programme peut ne pas arriver à se connecter à l'adresse IP codée en dur (règles du pare-feu, adresse interne etc.). Mais, dans le pire des cas, l'adresse IP codée en dur peut être routable dans le nouvel environnement et amener le programme à se connecter au mauvais ordinateur. Par exemple, si un fournisseur de cloud utilise des adresses IP d'un réseau privé pour des clients du cloud, un programme migré d'un datacenter interne vers le cloud pourra diriger le trafic sortant, par exemple la connexion à Syslog, vers un autre client. Dans des circonstances ordinaires, les fuites de données ne seraient pas très préoccupantes puisque l'adresse IP se trouve sur le réseau privé interne. Cependant, en se déplaçant sur un réseau différent, le programme enverra des messages Syslog à tous les hôtes ayant l'adresse Les noms d'hôtes codés en dur constituent donc un risque pour les programmes déployés dans le cloud. Bien que les noms d'hôtes puissent servir d'abstraction précieuse entre des hôtes et leurs adresses IP sousjacentes, la sécurité de cette abstraction est basée sur la fiabilité des serveurs DNS utilisés pour résoudre le nom d'hôte. Alors que la plupart des entreprises contrôlent directement leurs serveurs DNS, ce contrôle est souvent confié au fournisseur de cloud lorsqu'un programme est migré. Si des pirates peuvent compromettre le serveur DNS du fournisseur, ils peuvent également modifier ses enregistrements DNS. Le programme communiquera alors involontairement avec un système contrôlé par les pirates. Le code suivant utilise une recherche DNS pour déterminer si une demande entrante vient d'un hôte de confiance. Si un pirate peut empoisonner le cache, il pourra obtenir un statut de confiance. String ip = request.getremoteaddr(); InetAddress addr = InetAddress. getbyname(ip); if (addr.getcanonicalhostname(). endswith( trustme. com )) { trusted = true; } Il ne sert à rien d'éliminer l'utilisation de noms d'hôtes lors de la communication avec des hôtes externes. Les références à des hôtes externes doivent cependant être stockées dans des fichiers de configuration et non codées en dur dans la source du programme, et le programme doit authentifier les hôtes externes lorsqu'il ouvre une connexion. Un certificat SSL du client est une manière d'effectuer cette authentification. Le protocole SSL peut servir non seulement de sécurité de transport mais encore, de mécanisme d'authentification d'hôte. Les meilleures pratiques suggérant la communication via des connexions SSL pour garantir la sécurité du transport, l'authentification d'hôte doit être simple sur la mise en œuvre existante. La configuration suivante envoie des messages de journal au serveur Syslog de l'entreprise à l'adresse IP log4j.appender.syslog. sysloghost=

4 Protection de l'infrastructure de journalisation Les pistes de journalisation et d'audit permettent aux entreprises de diagnostiquer les problèmes logiciels et de fournir des preuves légales utiles après une attaque. Par ailleurs, de nombreuses entreprises sont soumises à des obligations externes, qui leur sont imposées en fonction de ce qui doit être enregistré, des personnes ayant accès à ces journaux et de l'endroit où ils sont stockés. Beaucoup de ces obligations sont remplies grâce à une liaison étroite entre la stratégie d'entreprise et l'infrastructure interne. Les stratégies d'enregistrement sont très spécifiques à une organisation mais, indépendamment des détails, déplacer un programme vers un fournisseur de cloud nécessite une réévaluation de la posture de journalisation du programme. Un des plus grands risques liés à l'enregistrement dans un environnement de cloud est que les journaux peuvent être interceptés ou qu'il peut y avoir des fuites vers un hôte non approuvé. Le débogage d'entrées de journaux peut fournir à un pirate un plan de nombreux aspects internes d'un programme, et les journaux sont souvent utilisés par des pirates pour se concentrer sur des opérations vulnérables. En raison du risque accru de compromission des messages de journaux, les programmes déployés dans le cloud ne devraient jamais permettre de les déboguer. Par exemple, un programme utilisant les messages de débogage de journaux de l'infrastructure log4j devrait être revu pour s'assurer qu'il ne contient pas d'entrée de configuration telle que : log4j.rootlogger=debug #unsafe in the cloud Dans de nombreuses infrastructures, l'enregistrement de débogage peut également être activé par le programme, par exemple avec un appel explicite à Logger.setLevel(Level.DEBUG). L'infrastructure d'enregistrement log4net utilise une entrée similaire à log4j afin d'activer les entrées du journal de débogage : <!-- Setting root logger level to DEBUG == unsafe in the cloud --> <root> <level value= DEBUG />... <root> Les entrées de configuration ou les instructions du programme permettant de déboguer l'enregistrement devraient être modifiées pour définir un niveau de journalisation plus restrictif, afin que le programme ne puisse pas enregistrer des informations sensibles. 4

5 Protection du stockage des données Les risques liés aux données au repos deviennent encore plus complexes lorsque les données se déplacent au-delà du contrôle physique de l'entreprise. Ceci donne l'opportunité à des programmes de violer les protocoles de gestion des données proprement dits. Les entreprises doivent mettre au point des stratégies pour gérer le stockage correct et la destruction de données sensibles qui seront stockées sur le matériel d'un fournisseur de cloud. D'une manière générale, les programmes doivent crypter les données sensibles durant leur transmission et au repos. La plupart des serveurs de bases de données modernes prennent en charge le cryptage de l'instance complète. Ceci peut constituer une bonne protection contre l'exposition par inadvertance d'informations sensibles en texte clair. Les fournisseurs de bases de données peuvent mettre le cryptage en œuvre de plusieurs manières. Microsoft SQL Server et Oracle fournissent tous deux le cryptage complet de bases de données par le biais d'une fonctionnalité de cryptage transparent des données (TDE). Pour IBM DB2, la suite de cryptage des données peut être utilisée pour obtenir des effets similaires. Au-delà de la sécurisation des données au repos, les données envoyées à et récupérer depuis des bases de données et d'autres systèmes indépendants doivent également être cryptées pendant leur transmission. Java et.net permettent tous deux aux programmes d'établir des connexions avec des bases de données via SSL. Dans Java, chaque pilote JDBC fournit sa propre chaîne de connexion SSL. Une connexion Oracle JDBC via SSL peut par exemple être établie comme suit : jdbc:oracle:thin:@(description=(address=(protocol=tcps) (HOST=db1)) Dans les programmes Microsoft.NET, SSL peut être activé à l'aide d'un objet SqlConnection en ajoutant encrypt=true à la liste de paramètres utilisée dans la chaîne de connexion, comme le montre l'exemple suivant : <configuration> <connectionstrings> <add name= MyDbConn connectionstring= Server=MyServer;Data ba se=pubs; + User Id=MyUser; password=p@ssw0rd;encrypt=true providername= System.Data.SqlClient /> <connectionstrings> </configuration> 5

6 Adapter le cryptage au cloud Outre le fait qu'il nécessite une utilisation plus large du cryptage, notamment du cryptage complet de bases de données, le déploiement dans le cloud modifie également les risques liés à la manière dont le cryptage est utilisé. De même que les adresses IP codées en dur peuvent générer un comportement imprévisible des logiciels, les clés de cryptage, les jetons et les chemins d'accès à la clé codés en dur peuvent être à l'origine de défaillances lorsque des programment migrent vers le cloud. Le scénario le plus défavorable est celui où un programme est déployé sur une image virtuelle qui est un miroir exact d'une configuration de système d'exploitation existante et inclut toutes les clés de cryptage générées. Dans ce cas, la même clé existe sur plusieurs hôtes et un hôte compromis peut aisément se traduire par un cryptage compromis effectué par tous les hôtes partageant la même clé. Par ailleurs, même si seulement une instance d'une clé codée en dur existe, la modification de cette clé pour une raison quelconque, y compris une attaque réussie, sera onéreuse puisqu'elle nécessitera la mise à jour du code source du programme. Pour ces raisons, les clés de cryptage et autres artefacts doivent toujours être stockés dans une ressource externe, par exemple un fichier de configuration, qui pourra être modifiée sans mise à jour du logiciel proprement dit. Par exemple, le code Java suivant charge une clé privée depuis le système de fichiers à utiliser pour le décryptage : File privatekeyfile = new File( /etc/ mykey.pem ); Surveillance des influences environnementales Les programmes déployés à l'origine sur un système d'exploitation hôte sécurisé dans un datacenter d'entreprise sont souvent basés sur les paramètres d'environnement système sans vérification préalable. Cette confiance vient de l'idée que le système de déploiement a subi un contrôle de sécurité, et que des employés internes de confiance assureront la maintenance et la configuration de l'hôte. Ces deux suppositions ne sont plus valables lorsqu'un programme est migré vers le cloud. Le code Java suivant lit un nom de chemin d'accès depuis une propriété système et l'utilise pour construire sans sécurité une commande d'environnement à exécuter : String home = System. getproperty( APPHOME ); String cmd = home + INITCMD; java.lang.runtime.getruntime().exec(cmd); Les programmes doivent valider la lecture de données depuis l'environnement local pour garantir qu'elles contiennent des valeurs attendues et raisonnables avant de les utiliser. byte[] enckey = new byte[(int) privatekeyfile.length()]; new FileInputStream(privateKeyFile). read(enckey); // create private key PKCS8EncodedKeySpec privatekeyspec = new PKCS8EncodedKeySpec(encKey); KeyFactory kf = KeyFactory. getinstance( RSA ); PrivateKey pk = kf.generateprivate(privat ekeyspec); Enfin, étant donné que les entreprises ne contrôlent plus l'infrastructure physique sur laquelle leurs données sont stockées, il est d'autant plus important que les programmes déployés dans le cloud adhèrent aux meilleures pratiques concernant les algorithmes de cryptage et les principales clés qu'ils utilisent. HP Fortify fournit aux développeurs une orientation quant aux meilleures pratiques actuelles en matière de cryptage. 6

7 La sécurité sous un nouvel angle Comme de nombreuses technologies, le cloud computing présente des risques commerciaux et techniques. Du point de vue des risques techniques, les déploiements dans le cloud éliminent l'infrastructure de sécurité réseau existante de l'entreprise, rendent une protection en profondeur plus difficile en raison des dépendances externes et augmentent le risque de faire confiance à des ressources externes au programme alors que cela ne devrait pas être le cas. Cette combinaison de facteurs modifie l'exposition à des risques techniques des logiciels d'entreprise existants déployés dans le cloud. Les entreprises souhaitant migrer vers le cloud doivent réévaluer leur vision de la sécurité. Les canaux de communication pour la transmission interne et externe doivent être cryptés pour éviter de transmettre des informations sensibles en texte clair. Les références à des hôtes distants doivent être externalisées dans des fichiers de configuration et toutes les connexions doivent être authentifiées de manière sécurisée pour empêcher d'accorder de la confiance à tort. Les configurations de journalisation doivent être examinées pour s'assurer qu'aucune donnée sensible ne fuit vers des systèmes non approuvés. Les données n'étant plus physiquement en possession de l'entreprise, elles doivent être cryptées pour réduire le risque de perte de données, tant durant le transit qu'au repos. La clé de cryptage doit être externalisée vers des fichiers de configuration en raison du risque accru de compromission et de la probabilité que les ressources seront dupliquées dans un environnement virtualisé. Enfin, les informations lues depuis l'environnement de cloud doivent être validées au même titre que n'importe quelle autre entrée non approuvée pour s'assurer qu'elle contient bien les valeurs attendues. A propos de HP Enterprise Security HP est un des principaux fournisseurs de solutions de sécurité et de conformité pour les entreprises modernes qui veulent diminuer les risques dans leurs environnements hybrides et se protéger contre des menaces sophistiquées. Sur la base des produits phares de HP ArcSight, HP Fortify et HP TippingPoint, la plateforme HP Security Intelligence and Risk Management (SIRM) est la seule à offrir aux entreprises la corrélation, la protection des applications et la technologie de protection des réseaux qui protègent les applications et les infrastructures informatiques actuelles contre les cybermenaces. Pour en savoir plus sur la sécurité des systèmes logiciels dans le cloud, visitez le site Internet hpenterprisesecurity.com. 7

8 Connectez-vous hp.com/go/getconnected Recevoir les avis des spécialistes sur les tendances techniques, les alertes et les solutions HP. Partager avec des collègues Copyright 2012 Hewlett-Packard Development Company, L.P. Les informations contenues dans ce document sont sujettes à modification sans notification préalable. Les seules garanties relatives aux produits et services HP sont stipulées dans les énoncés de garantie expresse accompagnant ces produits et services. Aucune déclaration contenue dans ce document ne peut être interprétée comme constituant une garantie supplémentaire. HP décline toute responsabilité quant aux éventuelles erreurs ou omissions techniques ou éditoriales. Java et Oracle sont des marques déposées d'oracle et/ou de ses sociétés affiliées. Microsoft est une marque déposée de Microsoft Corporation aux Etats-Unis. 4AA4-1804FRE, créé en mai 2012 Impression numérique HP Indigo.