De la virtualisation sécurisée aux Clouds privés sécurisés

à mesure que les entreprises passent de la virtualisation de leurs datacenters à la mise en œuvre d'infrastructures de Cloud Computing privé, la sécurité doit évoluer en conséquence. Bien que les principes fondamentaux de la sécurité des informations restent les mêmes, l'approche des entreprises en matière de conception et de déploiement des services de sécurité doit être réformée. Cette étude met en avant les fonctionnalités fondamentales requises, pour passer d'une infrastructure de sécurité d'entreprise à un environnement de Cloud Computing privé sécurisé.

• Les stratégies liées aux attributs physiques, les points d'exécution de la stratégie de sécurité intégrés aux appareils physiques et l'utilisation de mesures d'isolation (ou « air gap ») constituent un frein à l'adoption des nuages privés.
• La virtualisation des contrôles de sécurité constitue une étape importante en matière de sécurisation des clouds privés, mais d'autres fonctionnalités sont requises.
• La reconnaissance du contexte, notamment la prise en compte des applications, des identités et des contenus, est essentielle à la mise en place d'un environnement de Cloud Computing privé sécurisé.
• Sous peine d'échec, la sécurisation d'un cloud privé ne peut se restreindre au seul aspect technologique. Des changements doivent aussi intervenir au niveau des processus et des approches.
• Les impératifs en matière de sécurité ne doivent pas être négligés, ni intégrés plus tard lors de la transition vers le Cloud Computing privé.

• Changez votre approche concernant la sécurité des informations. Envisagez-la plutôt comme un ensemble de services adaptatifs déployés par le biais d'une infrastructure programmable et contrôlés par des stratégies contextuelles basées sur des attributs logiques, lesquels permettent de créer des zones d'approbation adaptatives au moyen d'un plan de contrôle configurable distinct.
• Faites pression sur vos fournisseurs de sécurité habituels afin qu'ils proposent des contrôles de sécurité sous forme virtualisée, et ce afin que vous puissiez répondre plus aisément aux spécifications liées à la sécurisation d'un environnement de Cloud Computing privé.
• Lors des évaluations, mettez en avant la possibilité d'exprimer de manière unifiée une stratégie de sécurité pour les environnements physiques, virtualisés et de Cloud Computing privés. Privilégiez cette approche plutôt que d'avoir recours à des fournisseurs et à des solutions hétérogènes pour traiter chaque environnement séparément.
• Maintenez la séparation des fonctions entre l'exécution de la stratégie de sécurité et les opérations informatiques dans la phase de transition vers les centres de données virtualisés, puis vers les environnements de Cloud Computing privés.
• Passez dès maintenant à une infrastructure de sécurité contextuelle et adaptative, parallèlement à la mise à niveau et au remplacement de votre infrastructure de sécurité statique héritée, en particulier les pare-feu réseau et d'applications, les systèmes de détection des intrusions (IDS) ou systèmes anti-intrusions (IPS), et les plateformes de sécurité Web.

D'ici 2015, 40 % des contrôles de sécurité utilisés dans les centres de données d'entreprise seront virtualisés, contre moins de 5 % en 2010.

D'ici 2015, 70 % des entreprises autoriseront les charges de travail serveur de différents niveaux d'approbation à partager le même matériel physique dans leur propre datacenter, sauf interdiction explicite en cas de non-conformité à une réglementation ou suite à un audit.

Selon Gartner, le Cloud Computing (privé ou public) est un type d'informatique dans lequel des fonctions informatiques évolutives et élastiques sont fournies en tant que service à des clients utilisant des technologies Internet. Bien souvent, le terme « cloud » est employé pour faire référence aux attributs offerts aux entreprises par les architectures de Cloud Computing. Les consommateurs de services « in-the-cloud »souhaitent une consommation basée sur l'utilisation des services par le biais de technologies Internet standard et d'interfaces en libre service. Quant aux prestataires de services en nuage, ils souhaitent pouvoir être en mesure de fournir aux clients des services évolutifs, partageables, automatisés et élastiques. Ces attributs sont traités dans « Cinq attributs en vue d'améliorer le Cloud Computing public et privé ».

Le Cloud Computing privé repose intrinsèquement sur les mêmes concepts, et les clients indiquent leur désir d'introduire ces mêmes attributs dans le datacenter d'entreprise. Ici, le service informatique devient le fournisseur de services « in-the-cloud », et doit assurer le déploiement de fonctions informatiques sous forme d'un service élastique à plusieurs clients internes. Bien que l'objectif puisse varier légèrement (par exemple, si l'approvisionnement en libre service pour les clients informatiques est important, les fonctionnalités de facturation interne le sont généralement moins), les attributs désirés sont identiques. Pour la plupart des organisations, la virtualisation sert de fondation et de plateforme vers le Cloud Computing privé. Cependant, les impératifs en matière de sécurité ne doivent pas être négligés, ni intégrés plus tard lors de la transition vers le Cloud Computing privé.

Qu'il s'agisse de sécuriser des datacenters physiques, des centres de données virtualisés ou des clouds privés, les principes fondamentaux de la sécurité des informations sont les mêmes, à savoir garantir la confidentialité, l'intégrité, l'authenticité, l'accès et l'audit des informations et des charges de travail. Pour atteindre ces objectifs, la mise en place de contrôles de sécurité et de points d'exécution de la stratégie (PEP) traditionnels sont nécessaires, par exemple la protection par pare-feu, les systèmes IPS/IDS, le chiffrement, les signatures numériques, l'authentification et l'autorisation. Cependant, des changements cruciaux au niveau du mode de déploiement de la sécurité doivent être apportés. Dans le cadre d'un environnement de Cloud Computing privé, public ou les deux, la sécurité doit être adaptative, ce qui signifie qu'elle doit prendre en charge un paradigme dans lequel les charges de travail sont dissociées du matériel physique sous-jacent et allouées dynamiquement à une structure de ressources informatiques. Les stratégies liées à des attributs physiques, tels que le serveur, l'adresse IP (Internet Protocol) ou l'adresse MAC (Media Access Control), ou dans lesquelles la séparation de l'hôte physique est utilisée pour assurer l'isolement, sont vouées à l'échec pour le Cloud Computing privé. Pour de nombreuses organisations, la virtualisation des contrôles de sécurité sert de base à la sécurisation des infrastructures en cloud privé. Cependant, cette approche n'est pas à elle seule suffisante pour créer un cloud privé sécurisé.

Pour mettre en œuvre un environnement de Cloud Computing privé sécurisé, la sécurité doit faire partie intégrante de la structure du cloud privé (tout en étant configurable séparément) et doit être conçue comme un ensemble de services à la demande, élastiques et programmables. Elle doit également être configurée par des stratégies liées à des attributs logiques afin de créer des zones d'approbation adaptatives capables de séparer plusieurs locataires (voir figure 1).

Figure 1. évolution vers des clouds privés sécurisés

Source : Gartner (octobre 2010)

Dans l'idéal, les modèles de sécurité utilisés pour la prise en charge des clouds privés doivent autoriser la création d'environnements hybrides multidimensionnels qui englobent, d'une part, les charges de travail physiques et virtuelles dans le même datacenter et, d'autre part, les environnements informatiques sur site et en cloud public. Cette étude met en avant les six attributs nécessaires à une infrastructure de sécurité en nuage privé et décrit les modifications devant être apportées à la sécurité pour prendre en charge la construction de clouds privés sécurisés.

Au lieu d'assurer la sécurité par le biais d'un ensemble de produits en silo incorporés dans des appareils physiques, celle-ci doit être déployée sous forme d'un ensemble de services disponibles « à la demande » pour protéger les charges de travail et les informations à l'endroit et au moment où elles sont sollicitées. Ces services doivent être intégrés dans les processus d'approvisionnement et de gestion des clouds privés, et non greffés après coup, et doivent être accessibles à tout type de charge de travail, qu'il s'agisse d'un serveur ou d'un poste de travail (voir remarque 1). à mesure que les charges de travail sont provisionnées, déplacées, modifiées, clonées et, au bout du compte, retirées de la production, la stratégie de sécurité est associée à la charge de travail tout au long de son cycle de vie.

Bien qu'il soit possible de mettre en œuvre ce type de protection adaptative avec une infrastructure de sécurité physique et des superpositions de réseau local virtuel (VLAN) complexes, nous pensons que la plupart des entreprises utiliseront une combinaison de contrôles de sécurité physiques et virtualisés afin d'étendre leur stratégie de sécurité aux structures en cloud privé. Ceci peut s'expliquer par de nombreuses raisons, notamment la prise en charge de la perte de visibilité du trafic entre machines virtuelles dans un datacenter virtualisé, ainsi que la surcharge en entrée/sortie lorsque le trafic est routé vers le matériel physique pour l'exécution de la stratégie de sécurité. Les contrôles de sécurité virtualisés peuvent placer l'exécution de la stratégie dans l'hôte physique, plus près de la charge de travail et des informations qu'il protège, à l'endroit et au moment où elles sont sollicitées. Il en résulte des infrastructures de datacenter dynamiques, ainsi que la possibilité d'exploiter d'autres options d'approvisionnement.

Les appareils physiques continueront à être utilisés pour les applications à grande largeur de bande situées aux limites physiques des organisations. Les contrôles de sécurité virtualisés seront utilisés dans toute la structure du nuage privé pour inspecter le trafic entre les machines virtuelles et au niveau des limites logiques afin de créer des zones d'approbation pour les charges de travail avec des niveaux d'approbation variés. Pour bien faire, les contrôles de sécurité physiques et virtuels devront coordonner intelligemment leur inspection pour éviter les redondances.

D'ici 2015, 40 % des contrôles de sécurité utilisés dans les centres de données d'entreprise seront virtualisés, contre moins de 5 % en 2010.

La transition caractérisant le déploiement de la sécurité, qui passe d'un ensemble de produits à un ensemble de services, constitue un changement d'approche de taille pour les professionnels de la sécurité des informations. Pour les aider à faire face à cette évolution, ils peuvent s'appuyer sur des contrôles de sécurité virtualisés. Contrairement aux contrôles de sécurité physiques, dont l'évolution nécessite des appareils matériels de plus en plus volumineux, les points d'exécution de la stratégie de sécurité virtualisés sont exécutés dans des machines virtuelles de sécurité et peuvent être étendus en augmentant le nombre de machines virtuelles de sécurité exécutées en parallèle ; celles-ci se situent plus près des charges de travail et des informations qu'elles protègent, et tirent profit des fonctions de haute disponibilité et d'équilibrage de charge accessibles à toutes les machines virtuelles.

L'infrastructure de sécurité qui fournit les services de sécurité décrits dans la section précédente doit devenir « programmable », c'est-à-dire que les services doivent être exposés pour l'accès par programme (voir remarque 2). Par définition, l'infrastructure de Cloud Computing privé et public est consommable au moyen de normes Internet. Dans le cas d'une infrastructure de sécurité programmable, les services sont généralement exposés par le biais d'interfaces API RESTful qui sont indépendantes du langage de programmation et de la structure.

En exposant les services de sécurité par le biais d'interfaces API, l'infrastructure des points d'exécution de la stratégie de sécurité devient programmable à partir des points d'administration et de décision de la stratégie (notamment à partir des consoles opérationnelles et de gestion de la sécurité, et même à partir d'autres systèmes d'intelligence de sécurité comme les systèmes de gestion des informations et des événements de sécurité). Cette évolution en matière de capacité présente plusieurs avantages. Tout d'abord, le degré d'automatisation envisageable est considérablement plus élevé qu'avec une infrastructure de sécurité traditionnelle. à mesure que de nouvelles charges de travail sont introduites dans le nuage privé, l'infrastructure de sécurité peut être automatiquement configurée par l'intermédiaire d'interfaces en libre-service (où l'utilisateur est un système d'approvisionnement, et non un utilisateur final) pour protéger la nouvelle charge de travail en fonction de stratégies de sécurité prédéfinies, sans aucune programmation manuelle des contrôles de sécurité.

Cette évolution permet aux professionnels de la sécurité des informations de se concentrer sur la gestion des stratégies, et non sur l'infrastructure de programmation. L'infrastructure de sécurité programmable peut être modifiée en temps réel, ce qui permet aux services de sécurité de s'adapter aux charges de travail lorsqu'elles évoluent dynamiquement dans un cloud privé ou en cas de changement de leur comportement. à plus long terme, parallèlement à l'évolution de l'infrastructure des applications dans les clouds privés, les applications intègreront des modèles de stratégie de déploiement, de topologie, de gestion et de sécurité pour permettre une automatisation pilotée par la stratégie. Au final, ce sont les stratégies consommées par les consoles de gestion et d'autres points d'administration de la stratégie de sécurité qui façonneront la configuration et la programmation des aspects de sécurité et de gestion, et non les professionnels des technologies de l'information. En permettant aux professionnels de la sécurité de se concentrer sur les stratégies, cette approche a pour autre avantage de réduire le risque d'erreur humaine dans la programmation de l'infrastructure de sécurité sous-jacente.

La nature des stratégies de sécurité qui définissent la configuration automatisée de l'infrastructure programmable doit également évoluer. Dans cette phase de transition, d'abord vers les datacenters virtualisés, puis vers l'infrastructure en cloud privé, les stratégies de sécurité doivent être de plus en plus liées à des attributs logiques, et non physiques. Le découplage et l'abstraction de la pile informatique entière, combinés à l'adoption des modèles d'informatique en cloud privé et public, signifient que les charges de travail et les informations (et même des centres de données entiers avec la notion de datacenter virtuel) ne sont plus liés à des périphériques spécifiques, ni à des adresses IP ou MAC fixes, rompant de ce fait avec les stratégies de sécurité statiques basées sur les attributs physiques.

Les stratégies de sécurité doivent intégrer des attributs logiques situés « en haut de la pile », tels que l'identité, le groupe ou le rôle de la machine virtuelle protégée ; l'identité, le groupe ou le rôle de l'application ; l'identité, le groupe ou le rôle des utilisateurs ; et la sensibilité de la charge de travail et des informations traitées. Cette évolution, qui se caractérise par la prise en compte de l'identité, de l'application et du contenu, fait partie d'un mouvement plus large qui vise à faire de la sécurité des informations un processus plus contextuel et adaptatif.

Pour permettre une évaluation plus rapide et plus précise d'une action de sécurité donnée en vue de son acceptation ou de son refus, il est impératif d'incorporer une plus grande quantité d'informations contextuelles en temps réel au moment de la prise de décision. Le contexte ne se limite pas à la prise en compte de l'identité, de l'application et du contenu. Un contexte élargi inclut l'environnement (notamment l'heure et l'emplacement géographique du serveur), la fiabilité du périphérique, l'intégrité de la plateforme de virtualisation sous-jacente, la réputation de la machine virtuelle chargée, le comportement manifesté par l'utilisateur ou la machine virtuelle, etc. Le contexte doit également prendre en compte la virtualisation ; ainsi, lorsqu'une charge de travail est migrée ou clonée en direct, la sécurité associée évolue automatiquement avec la charge de travail tout au long de son cycle de vie, sans aucune intervention manuelle.

Le découplage des stratégies de sécurité des charges de travail et des informations qu'elles protègent présente plusieurs avantages. Il est notamment possible de mettre en œuvre des stratégies de sécurité composées puissantes et indépendantes de la topologie réseau, évitant ainsi la complexité des configurations VLAN et de l'infrastructure de câblage réseau. Par ailleurs, en montant dans la pile, les stratégies de sécurité peuvent être exprimées en termes plus conviviaux pour les entreprises. Par exemple, l'identification des utilisateurs et des groupes autorisés à accéder à certaines applications est une stratégie simple à composer et à certifier par les propriétaires de processus d'entreprise, d'informations et d'applications. Pour finir, en incorporant le contexte d'exécution dans les décisions de sécurité, les organisations peuvent implémenter une stratégie de sécurité adaptative basée sur le comportement de l'utilisateur ou de la charge de travail (par exemple, si une charge de travail se comporte bizarrement, attribuez-lui un contrôle d'audit plus fort ou limitez son accès au réseau).

Au lieu d'administrer plusieurs stratégies de sécurité pour différentes machines virtuelles, vous pouvez, en mettant en place des stratégies de sécurité basées sur des attributs logiques, tels que ceux décrits à la section précédente, créer des zones d'approbation. Il s'agit en fait de groupes logiques de charges de travail avec des spécifications en matière de sécurité et des niveaux d'approbation semblables. Par exemple, un niveau spécifique de la stratégie de sécurité peut être attribué aux charges de travail relatives au secteur des cartes de paiement (PCI). Du fait que les stratégies sont liées à des groupes de machines virtuelles, et non à une infrastructure physique, les zones peuvent s'adapter tout au long du cycle de vie de chaque machine virtuelle à mesure que celles-ci se déplacent et que des nouvelles charges de travail sont attribuées à la zone d'approbation et introduites dans celles-ci.

à l'heure actuelle, dans les datacenters virtualisés, il est peu fréquent que des charges de travail appartenant à différents niveaux d'approbation figurent sur le même serveur physique, ce qui constitue une entrave à la fluidité des modèles de Cloud Computing privé. De plus en plus, la capacité à prendre en charge des charges de travail de différents niveaux d'approbation est nécessaire pour générer des niveaux de rendement plus élevés au niveau de la structure de ressources partagée. En exploitant la racine émergente des mesures d'approbation pour les hyperviseurs et les hyperviseurs incorporés, les clouds privés sécurisés doivent pouvoir prendre en charge, sur le même matériel physique, des charges de travail appartenant à différents niveaux d'approbation, et ce sans recourir à des serveurs physiques distincts.

D'ici 2015, 70 % des entreprises autoriseront les charges de travail serveur de différents niveaux d'approbation à partager le même matériel physique dans leur propre datacenter, sauf interdiction explicite en cas de non-conformité à une réglementation ou suite à un audit.

Les zones d'approbation adaptatives constitueront la base des stratégies d'approbation, d'audit et de conformité. Les stratégies de sécurité varieront entre zones d'approbation, et des contrôles de sécurité seront positionnés au niveau des périmètres logiques entre les limites clés des zones d'approbation. Par exemple, une zone d'approbation de charges de travail PCI peut exiger le chiffrement de toutes les données entre les machines virtuelles de la zone d'approbation. Par ailleurs, son accès peut être limité aux utilisateurs associés au groupe PCI (l'ensemble du trafic entre les machines virtuelles peut faire l'objet d'une surveillance par un système de détection d'intrusions) et elle peut être séparée de toutes les autres zones d'approbation par le biais d'une inspection au niveau du pare-feu avec état, conformément aux exigences stipulées par PCI. En revanche, une zone d'approbation de charges de travail liées à une infrastructure de bureaux virtuels (VDI) peut être traitée comme zone non approuvée, nécessitant alors un pare-feu et une inspection IPS en ligne de tout le trafic à destination et en provenance de la zone, ainsi que le blocage de tout trafic d'égal à égal dans la zone.

Les zones d'approbation peuvent être imbriquées ; de cette façon, un même datacenter physique peut être géré et sécurisé comme plusieurs centres de données virtuels, chaque centre comprenant plusieurs périmètres logiques, et non physiques, autour des zones d'approbation. La stratégie de sécurité peut alors être appliquée selon les besoins au sein des zones et entre celles-ci. Dans la plupart des cas, plusieurs zones d'approbation sont autorisées à résider sur un hôte physique unique, l'entreprise pouvant définir le degré de séparation suffisant en matière de sécurité et de conformité. Par exemple, le stockage et la sauvegarde peuvent être isolés, tandis que le trafic réseau peut être séparé au moyen d'un système IPS et d'un pare-feu, en adéquation avec les stratégies de conformité internes ou externes.

L'infrastructure en nuage privé nécessite des services de sécurité conçus à la base pour séparer avec certitude les charges de travail appartenant à différents niveaux d'approbation. Il s'agit exactement du même type de séparation que celui requis par les fournisseurs de nuage public pour séparer et isoler les locataires de différentes organisations. Pour les entreprises établissant des clouds privés, les concepts sont identiques. Toutefois, ce sont elles, et non les locataires de différentes organisations, qui seront systématiquement responsables de la séparation des charges de travail de différents niveaux d'approbation, y compris différents services et divisions partageant la même infrastructure physique sous-jacente.

à mesure que la sécurité est virtualisée et incorporée dans des infrastructures de Cloud Computing, elle ne doit pas pour autant être affaiblie. Les contrôles et les stratégies de sécurité mentionnés précédemment ne doivent pas pouvoir être désactivés arbitrairement par le personnel opérationnel et doivent échouer en mode ouvert ou fermé conformément aux stratégies stipulées par l'entreprise. La séparation forte des fonctions/problèmes entre les opérations informatiques et la sécurité doit pouvoir être mise en place dans une infrastructure en nuage privé, au même titre que dans l'infrastructure physique et l'infrastructure virtualisée aujourd'hui.

Cette séparation se produit à plusieurs niveaux. Si des contrôles logiciels sont virtualisés, la séparation des fonctions en place dans le monde physique ne doit pas être perdue. Pour cela, les fournisseurs de plateforme de virtualisation et de Cloud Computing privé doivent offrir la possibilité de séparer la formation des stratégies de sécurité et l'exploitation des machines virtuelles de sécurité de la formation des stratégies de gestion et de l'exploitation des machines virtuelles d'autres centres de données. En général, ceci passe par l'intégration et le contrôle de l'accès aux opérations de sécurité à un niveau granulaire. Sont utilisés à cette fin le contrôle d'accès basé sur les rôles dans le système de gestion, contrôlé par l'intégration aux informations d'organisation et de groupe situées dans les répertoires d'entreprise (généralement Active Directory ou un référentiel prenant en charge LDAP), ainsi que des fonctionnalités d'administration déléguées. De même, toutes les modifications apportées aux stratégies de sécurité et les opérations exécutées sur les machines virtuelles de sécurité doivent être entièrement auditées dans des journaux inviolables et inaccessibles aux administrateurs de sécurité.

Un gestionnaire de stratégie de sécurité assure l'orchestration et la définition des stratégies de sécurité, ainsi que l'attribution de stratégies aux attributs logiques des charges de travail et des groupes de charges de travail, comme décrit précédemment, et met l'accent sur l'intégrité et le test des stratégies. Il va de soi que les machines virtuelles peuvent se voir attribuer plusieurs stratégies de sécurité et être membres de plusieurs zones d'approbation. Le système de gestion des stratégies doit prendre en charge l'attribution de plusieurs stratégies de sécurité superposées, et doit être en mesure d'identifier la stratégie résultante comportant le moins de privilèges. En outre, il doit pouvoir assurer la résolution des conflits entre stratégies. Dans l'idéal, le système doit prendre en charge la modélisation proactive des scénarios de simulation avant l'implémentation des modifications de stratégie.

Les clouds privés seront déployés de manière incrémentielle, pas d'un seul coup. Ils seront fondés sur des centres de données existants, où seule une partie des données est convertie en modèle de cloud privé. En outre, de nombreuses entreprises disposeront de charges de travail non virtualisées pendant plusieurs années à venir.

Dans l'idéal, l'infrastructure de sécurité en cloud privé doit pouvoir échanger et partager des stratégies avec d'autres infrastructures de sécurité de datacenter, à la fois virtualisées et physiques. Aucune norme n'est établie pour le partage de la stratégie de sécurité. Le passage d'une infrastructure physique à une infrastructure virtualisée obligera les entreprises à faire appel au même fournisseur pour assurer la sécurité dans les deux environnements ou à des fournisseurs différents dans chaque environnement. Il est recommandé que les contrôles de sécurité placés dans l'infrastructure physique ou virtualisée soient en mesure de coopérer intelligemment pour l'inspection des charges de travail. Par exemple, les données à destination et en provenance du datacenter seront inspectées par des appareils de sécurité physique.

Les organisations commenceront également à évaluer des fournisseurs d'infrastructure de cloud public en tant que service (IaaS) pour créer des environnements de Cloud Computing privé/public hybrides. Dans l'idéal, les stratégies de sécurité conçues pour protéger les charges de travail sur site pourront également être fédérées (avec les informations relatives à l'identité des utilisateurs) aux fournisseurs de cloud public. Aucune norme n'est pour l'instant établie à ce sujet. Cependant, l'API vCloud de VMware constitue un point de départ, au même titre que les travaux effectués par la commission DMTF (Distributed Management Task Force) pour étendre le format OVF (Open Virtualization Format) de manière à exprimer la stratégie de sécurité. En l'absence de normes et d'APl, les possibilités pour étendre la stratégie de sécurité d'entreprise resteront fragmentées, et reposeront sur une combinaison de contrôles associés à des charges de travail, ainsi que sur l'extension basée sur les réseaux privés virtuels des stratégies de sécurité réseau, la gestion des stratégies à l'aide d'une console à distance, la programmation à distance basée sur API des stratégies de prestataire de services et les engagements écrits concernant les niveaux de service de sécurité.