Zones de sécurité de réseau en nuage - ITSP.80.023

Vue d'ensemble

Le présent document décrit les modèles et les architectures de zones de sécurité de réseau en nuage et offre des conseils techniques sur la mise en œuvre des zones de sécurité de réseau en nuage.

L’orientation qu’il fournit est destinée aux solutions de technologie de l’information (TI) au sein du gouvernement du Canada s’exécutant au niveau NON CLASSIFIÉ, PROTÉGÉ A et PROTÉGÉ B (c'est-à-dire, dont le niveau de sensibilité est faible ou partiel). Il convient de noter que les systèmes utilisés dans les domaines PROTÉGÉ C ou classifiés (c'est-à-dire, hautement sensibles) pourraient nécessiter d’autres considérations de conception qui dépassent la portée du présent document. Pour les organisations non gouvernementales, les conseils fournis dans le présent document sont destinés aux solutions de TI dont les ressources sont faiblement ou partiellement sensibles. Les systèmes traitant des niveaux de classification des données plus élevés nécessitent des considérations de conception supplémentaires qui dépassent la portée du présent document. Vous pouvez communiquer avec le Centre d’appel par courriel ou par téléphone pour obtenir des conseils sur les solutions cryptographiques pour les domaines PROTÉGÉ C ou classifiés.

Il incombe à votre organisation de définir les objectifs en matière de sécurité qu’il convient de fixer pour protéger ses services et ses données. Suivre les conseils formulés dans le présent document ne suffit pas pour sécuriser adéquatement un environnement informatique.

Ce document est destiné aux praticiens des TI qui sont familiers avec les principes, les normes et la terminologie de l’ingénierie des réseaux.

1 Introduction

Ce document présente des détails et des concepts ayant trait à la segmentation réseau et à l’établissement de zones qui s’appliquent aux environnements en nuages. Il s’agit d’un complément à l’ITSP.80.022, Exigences de base en matière de sécurité pour les zones de sécurité de réseau^{Notes de bas de page 2} du Centre pour la cybersécurité, et à ses annexes. Vous devriez vous familiariser avec les concepts présentés dans l’ITSP.80.022 avant de lire et de mettre en œuvre les conseils de la présente publication.

L’établissement de zones réseau pose les bases d’une stratégie et d’une architecture de sécurité réseau reposant sur une défense en profondeur qui peut prendre en charge toute une gamme de solutions de sécurité répondant aux exigences opérationnelles de votre organisation. Pour de plus amples renseignements sur l’approche de sécurité réseau reposant sur une défense en profondeur, consultez l’l’ITSG-38, Établissement des zones de sécurité dans un réseau – Considérations de conception relatives au positionnement des services dans les zones^{Notes de bas de page 3} et l’ITSP.80.022^{Notes de bas de page 2} publiés par le Centre pour la cybersécurité. Ces zones proposent également une infrastructure réseau commune pour assurer la prise en charge de la prestation électronique de services, de l’interconnectivité et de l’interopérabilité. Si votre organisation partage une infrastructure commune pour la prestation électronique de services ou d’autres fins, vous devez vous conformer à toutes les normes de sécurité établies pour l’infrastructure en question.

Le présent document décrit les principes de conception d’architecture et de mise en œuvre de la segmentation d’un environnement en nuage en différentes zones de sécurité réseau. De plus, il explique en détail la façon dont ces principes sont adaptés et leur pertinence pour l’établissement de zones réseau sur site traditionnelles. Les conseils s’appliquent principalement à l’utilisation d’une infrastructure-service (IaaS pour Infrastructure as a Service) et d’une plateforme-service (PaaS pour Platform as a Service). Ce document offre, par exemple, des conseils sur l’utilisation des microservices et des modèles d’interface de programmation d’applications (API pour Application Programming Interface).

Il incombe au fournisseur de services infonuagiques (FSI) d’établir les zones réseau de l’environnement en nuage d’un logiciel-service (SaaS pour Software as a Service). Un environnement PaaS est une plateforme multilocataire pouvant être sujette à l’établissement de zones réseau par le FSI. Votre organisation est responsable de s’assurer que les applications SaaS et PaaS respectent la stratégie de sécurité établie, en particulier en ce qui concerne l’établissement de zones réseau. Les exigences de sécurité devant être respectées par les applications d’entreprise sont tirées de la stratégie de sécurité ou du cadre de gestion des risques de votre organisation. On peut également utiliser l’ITSG-33, Gestion des risques liés à la sécurité : Une méthode axée sur le cycle de vie^{Notes de bas de page 4} du Centre pour la cybersécurité à titre de cadre de gestion des risques afin de déterminer les contrôles de sécurité devant être mis en œuvre par votre organisation. La modélisation des menaces, ce qui comprend l’identification de menaces particulières, doit faire partie du cadre de gestion des risques de votre organisation.

Remarque : Les conseils formulés dans le présent document évolueront au fil du temps en fonction des changements technologiques. Par exemple, les conseils mentionnés à la section 6 sur les différents modèles d’utilisation suivront l’évolution des technologies infonuagiques.

Si vous mettez en œuvre des solutions de TI et que votre organisation est un ministère ou un organisme du Gouvernement du Canada (GC), vous devez respecter toutes les politiques du Conseil du Trésor (SCT), dont les suivantes :

• Politique sur les services et le numérique^{Notes de bas de page 5}
• Politique sur la sécurité du gouvernement^{Notes de bas de page 6}
• Directive sur la gestion de la sécurité^{Notes de bas de page 7}

Les ministères et les organismes du GC doivent également consulter l’orientation relative à la résidence des données électroniques^{Notes de bas de page 8} du SCT pour des détails sur les exigences présentées dans le Livre blanc : Directive sur les services et le numérique (PDF)^{Notes de bas de page 9}. Si votre organisation n’est pas un ministère ou organisme du GC, vous pouvez vous reporter à ces politiques pour obtenir de plus amples renseignements.

2 Facteurs à considérer en ce qui concerne le nuage

Les charges de travail des organisations migrent de plus en plus vers le nuage et le périmètre dépasse désormais l’environnement sur site. Votre organisation doit donc repenser la façon dont elle protège et surveille les environnements en nuages. Il est également essentiel de comprendre comment les principes de zone de sécurité réseau, comme ceux définis dans l’ITSP.80.022^{Notes de bas de page 2}, se transposent dans l’établissement des zones de sécurité de vos réseaux en nuage.

Les principes présentés dans l’ITSP.80.022^{Notes de bas de page 2} sont pertinents tant pour les centres de données traditionnels que pour les environnements en nuages. Dans un environnement en nuage, la réseautique a évolué et utilise désormais des réseaux à définition logicielle (SDN pour Software-Defined Network). Comparativement à un réseau traditionnel, un réseau SDN présente différentes caractéristiques et capacités qu’il faut prendre en considération lors de la segmentation d’un environnement en nuage en différentes zones de sécurité réseau.

Voici certaines des différences importantes par rapport à un réseau traditionnel :

• dissociation du plan de contrôle du plan de données des appareils physiques;
• point de provisionnement et de gestion centralisé et unique des configurations;
• point de contrôle centralisé pour une réglementation rigoureuse de l’information relative à la sécurité et aux politiques.

Vous devez savoir que même si le FSI offre un accès à la gestion et au plan de contrôle de son réseau SDN, cet accès est offert en faisant appel à l’abstraction des ressources et à une couche de contrôle similaire à celle employée dans le modèle SaaS. Le FSI ne fournit pas un accès direct à ses réseaux SDN ni à leur mise en œuvre, peu importe s’il est question de composants logiciels, de matériel ou d’une partie de la structure informatique du FSI.

Les environnements de centres de données traditionnels et en nuage partagent tous deux les mêmes principes de base pour ce qui est de contrôler et de restreindre les accès et le trafic des communications de données à certains composants ou utilisateurs. Ces deux types d’environnements établissent les périmètres du réseau et la défense en profondeur des frontières connexes au moyen des fonctions suivantes :

• définir les entités qui occupent les zones;
• déterminer les points d’entrée et de sortie distincts;
• filtrer le trafic réseau aux points d’entrée et de sortie;
• surveiller l’état du réseau;
• authentifier l’identité des dispositifs réseau, des utilisatrices et des utilisateurs;
• surveiller le trafic réseau aux points d’entrée et de sortie.

L’ITSP.80.022^{Notes de bas de page 2} définit plusieurs types de zones. Votre organisation doit comprendre comment convertir ces zones dans un environnement en nuage. Le tableau ci-dessous présente une mise en correspondance qui sera abordée en détail dans les sections suivantes.

Tableau 1 : Mise en correspondance des zones

3 Point d’interface de zone (PIZ)

L’ITSP.80.022^{Notes de bas de page 2} définit un point d’interface de zone (PIZ) comme étant un système bidirectionnel entre deux zones. La différenciation entre les zones se nomme la frontière. La frontière contient des PIZ qui représentent les seuls points de connexion entre les zones. Toutes les données doivent être transmises d’une zone à une autre par un PIZ, lequel connecte exclusivement ces deux zones et crée un chemin de communication distinct.

Le PIZ en nuage est le concept logique servant à décrire l’interface contrôlée qui relie deux zones. D’autres mécanismes de séparation logiques peuvent être employés dans un environnement en nuage. Même s’ils ne répondent pas nécessairement à toutes les exigences fonctionnelles de sécurité (voir le tableau 2) d’un PIZ, ces mécanismes peuvent jouer un rôle dans l’établissement de zones dans les réseaux.

Remarque : On compte deux types de PIZ : les PIZ connectés à une ZG et les PIZ de chemin de données. Prière de consulter l’ITSP.80.022, Annexe F^{Notes de bas de page 2}, pour plus de détails sur ces deux types de PIZ. Le glossaire (section 7.2) fournit également la définition des deux types de PIZ.

Certains concepts de la présente section s’appliquent à la façon dont les FSI mettent en œuvre la sécurité comparativement aux méthodes sur site patrimoniales. Ces concepts font toutefois partie d’une stratégie de défense en profondeur qui est typiquement non disponible dans un environnement réseau traditionnel ou décrite dans l’ITSP.80.022^{Notes de bas de page 2}. Dans les environnements natifs en nuage, une posture de sécurité forte est étroitement liée à la gestion des identités et de l’accès (GIdA). Le service de GIdA d’une ZG en nuage exige que les organisations mettent en œuvre un contrôle d’accès basé sur les rôles (RBAC pour Role-Based Access Control) pour contrôler les autorisations des utilisatrices, des utilisateurs et des ressources. Le contrôle d’accès basé sur les rôles devrait être structuré de façon à appliquer le principe du droit d’accès minimal. S’il est appliqué adéquatement, le principe du droit d’accès minimal permet d’améliorer grandement la sécurité et de réduire les risques. L’objectif du droit d’accès minimal est de s’assurer que toutes les utilisatrices et tous les utilisateurs se connectent au moyen de leur compte d’utilisateur avec les autorisations minimales absolues nécessaires à la réalisation de leurs tâches, et rien de plus.

Dans un environnement en nuage, le service de GIdA de la ZG offre le niveau le plus élevé de séparation logique sous la forme d’un compte de niveau supérieur. Un compte de niveau supérieur est semblable au concept d’administrateur de domaine ou à un compte de niveau racine dans un environnement sur site. Le compte de niveau supérieur peut ensuite fournir les sous-comptes nécessaires pour organiser les RBAC du nuage en une hiérarchie similaire à celle utilisée pour les groupes dans un service d’annuaire. La structure peut servir à faire respecter la stratégie en fonction des sous-comptes ou des groupes de sous-comptes dans la hiérarchie. Elle peut fournir des fonctions de sécurité de base, comme le contrôle de l’accès, l’authentification et les filtres de trafic.

Dans un compte de niveau supérieur (construction d’un réseau en nuage de base), l’établissement de zones logiques est assuré par le réseau virtuel. Ces réseaux virtuels exigeront des services de sécurité, comme l’appairage de réseaux virtuels et les passerelles réseau, pour ce qui est du filtrage du trafic et du contrôle de l’accès.

Le tableau suivant présente les définitions des fonctions de sécurité associées à un PIZ, tel qu’il est stipulé dans l’ITSP.80.022^{Notes de bas de page 2}.

Tableau 2 : Fonctions de sécurité des PIZ

Fonction de sécurité

Description

Contrôle d’accès

Contrôle le trafic en fonction des adresses sources et de destination et le type de service.

Authentification de l’entité

Valide l’authenticité des entités (comptes d’entité, qu’il s’agisse d’une personne ou non) et établit une association de sécurité entre elles.

Authentification de l’origine des données

Valide l’authenticité des entités prenant part à l’association de sécurité.

Vérification de l’intégrité des données

Vérifie que le trafic réseau n’a pas été modifié ou retransmis.

Filtres de trafic

Filtre ou blocage du trafic basé sur des propriétés des flux de données de communication, dont les suivantes :

• état du protocole TCP (Transmission Control Protocol);
• source et destination, conformité avec les protocoles de communication autorisés;
• types de données intégrés aux flux de données de communication;
• contenu des flux de données de communication.

Soutien à la détection des intrusions et à la vérification

Fournit les services et les attributs nécessaires pour soutenir la mise en œuvre de fonctions de sécurité comme la détection des intrusions, la vérification et l’intervention en cas d’incident. Comme les FSI fournissent cette capacité dans leur environnement en nuage, elle ne se limite pas au PIZ.

Encapsulation des ressources

Désigne les mécanismes permettant à la zone de masquer sa structure interne. Ces mécanismes comprennent la traduction d’adresses réseau, la traduction d’adresses de port et le mappage des services. L’encapsulation des ressources prend en charge le contrôle de l’accès et la survivance.

Dans un environnement en nuage, il existe plusieurs constructions de sécurité qui répondent à certaines ou à toutes les fonctions et exigences de sécurité. Selon le FSI choisi, on peut s’attendre à ce que les constructions et les capacités varient. Votre organisation doit consulter la documentation technique du FSI. Voici quelques exemples courants de services de sécurité natifs en nuage que l’on peut intégrer aux règles de politique du FSI :

• frontières géographiques;
• authentification multifacteur (AMF);
• emplacements autorisés ou bloqués;
• contrôles de la confiance des partenaires;
• détection avancée des risques liés à l’identité et protection;
• appareils autorisés ou bloqués;
• logiciels autorisés ou bloqués;
• systèmes d’exploitation autorisés ou bloqués;
• points d’entrée définis pour le nuage.

Une instance virtualisée de PIZ ne devrait pas contenir à la fois les PIZ connectés à la ZG et les PIZ des chemins de données Toute instance virtualisée d’un PIZ connecté à la ZG et tout PIZ de chemins de données doit répondre aux exigences d’assurance dérivées de la stratégie de sécurité et du cadre de gestion des risques de votre organisation. Prière de consulter le tableau 1, Mise en correspondance des zones, à la section 2 pour plus de détails sur la ZG et les autres zones.

L’établissement des zones permet de subdiviser un réseau en sous-réseaux ou en zones qui ont les mêmes stratégies et exigences de sécurité. Les organisations doivent mettre en œuvre un zonage de sécurité de réseau pour appliquer leur stratégie de sécurité réseau. Elles pourront ainsi empêcher un auteur de menace de se déplacer latéralement sur le réseau ou de nuire aux activités de tout le réseau. L’établissement de zones regroupe logiquement les données, les logiciels ou le matériel qui font l’objet de stratégies ou d’exigences de sécurité similaires.

Remarque : Par segmentation réseau, on entend une technique de réseautique qui consiste à diviser un réseau en sous-réseaux plus petits et distincts. Les organisations peuvent ainsi cloisonner les sous-réseaux et mettre en place des contrôles de sécurité et des services uniques à chacun. Les zones de sécurité de réseau sont des regroupements logiques qui sont basés sur la mise en œuvre sous-jacente de la segmentation réseau. Les contrôles de sécurité uniques qui protègent une zone sont définis dans le PIZ.

Les ressources infonuagiques sont déployées dans ces zones précises. Dans un environnement réseau traditionnel, on s’attend à trouver un PIZ à la frontière d’une zone. Dans un environnement en nuage, des capacités supplémentaires font en sorte qu’un PIZ puisse se trouver à la frontière d’une zone ou dans une zone associée à des interfaces réseau de ressources infonuagiques précises, comme une machine virtuelle ou un hôte.

Dans le présent document, un PIZ en périphérie d’une zone sera appelé une liste de contrôle d’accès réseau (NACL pour Network Access Control List) et un PIZ dans une zone sera appelé un groupe de sécurité réseau (NSG pour Network Security Group). Ces deux types de PIZ sont des constructions natives en nuage. En ce qui concerne le contrôle d’accès réseau, la NACL est considérée sans état, alors que le NSG est avec état.

Dans les déploiements en nuage, nous tenons compte des pare-feu de prochaine génération (NGFW pour Next Generation Firewall) natifs en nuage et des pare-feu de tiers qui se trouvent à la frontière d’une zone. Les organisations qui utilisent actuellement un NGFW sur site peuvent choisir de déployer la même solution NGFW au sein de l’infrastructure infonuagique afin de mettre à profit les connaissances opérationnelles, de réutiliser les outils existants et d’assurer une meilleure soutenabilité. Dans le présent document, on suppose que le NGFW peut être configuré de manière à fournir toutes les fonctions de sécurité d’un PIZ. Le NGFW se distingue du pare-feu traditionnel d’un NGFW de diverses façons. Un pare-feu traditionnel permet généralement d’effectuer une inspection dynamique de toute le trafic réseau, alors qu’un NGFW offre des fonctionnalités supplémentaires, comme la prise en compte et le contrôle des applications, la prévention intégrée des intrusions, une protection contre les menaces liées au nuage et le renseignement sur les menaces. Par exemple, un pare-feu d’applications Web (WAF) devrait servir à filtrer le trafic malveillant en direction de l’application et être placé en amont du serveur Web ou de la ZAR d’applications. Le PIZ d’une ZAR de base de données devrait inclure un dispositif d’audit et de protection de base de données (DAP pour Database Audit and Protection) afin de filtrer les requêtes SQL (Structured Query Language) malveillantes et de surveiller les activités de la base de données.

Une tendance générale veut que plusieurs fonctions de sécurité traditionnelles et exigences associées à un PIZ, comme la détection des intrusions, les audits, le contrôle des accès et les filtres de trafic, soient intégrées en mode natif dans la structure informatique du FSI et qu’elles ne soient pas simplement réservées ou associées aux PIZ. Les capacités de gestion des identités et de l’accès du FSI sont intégrées à la structure informatique et offrent une fonction de sécurité en mode natif, comme la détection des intrusions (détection des menaces) et les audits (journaux d’audit). Les fonctions de sécurité, telles l’intégrité de l’origine des données et la vérification de l’intégrité des données, sont aussi intégrées à la structure informatique du FSI dans l’ensemble de l’environnement en nuage.

Prière de consulter l’annexe A pour plus de détails sur la mise en correspondance des objectifs de sécurité des PIZ et les exigences de base en matière de sécurité des PIZ en nuage. L’annexe contient également des renseignements supplémentaires sur l’utilisation des PIZ en fonction des exigences de sécurité de votre organisation.

4 Conseils sur l’établissement de zones dans le nuage

Cette section présente des conseils sur l’établissement de zones dans le nuage, qui portent sur la zone de gestion, les conteneurs et les API d’applications.

L’établissement de zones dans le nuage doit faire appel à une stratégie globale visant à assurer un accès et une gestion sécurisés des ressources infonuagiques. La segmentation logique permet de mettre en œuvre la stratégie. Elle consiste à utiliser le zonage pour segmenter l’environnement en nuage en zones logiques distinctes, avec la possibilité qu’il soit nécessaire d’avoir recours à une segmentation physique à un niveau supérieur de sensibilité. La gestion infonuagique fait partie du plan de contrôle infonuagique. Elle vise à assurer le provisionnement et à fournir un soutien continu aux ressources du nuage, ce qui comprend la configuration des réseaux virtuels et l’établissement de zones dans ces réseaux. On peut avoir recours à des API pour réaliser les tâches de gestion dans le cadre du plan de contrôle.

La segmentation du réseau en nuage doit faire partie d’une stratégie de défense en profondeur. Prière de consulter le tableau 1, Mise en correspondance des zones, à la section 2 pour obtenir plus de détails sur les différents types de zones. Il convient d’appliquer le principe de droit d’accès minimal afin de réduire la surface d’attaque du nuage et de empêcher les auteurs de menace de se déplacer latéralement vers les autres zones.

Les communications entre les ressources infonuagiques de différentes zones doivent être limitées au trafic autorisé et être négociées par un PIZ, ce qui réduit la surface d’attaque du nuage et la zone de souffle. Une ZAP devrait être désignée comme point d’accès externe pour le trafic réseau en provenance et en direction des ressources infonuagiques. Prière de consulter la section 6, Topologies de connectivité, pour plus de détails sur les topologies qu’il est possible d’utiliser.

4.1 Segmentation

Cette section offre des conseils sur la segmentation des déploiements en nuage, dont l’établissement de zones internes et la connectivité. La segmentation des réseaux de centres de données traditionnels est une technique qui consiste à diviser un réseau en sous-réseaux distincts de plus petite taille. Les organisations peuvent ainsi compartimenter les données, les systèmes et le trafic qui y circule. L’établissement de zones de sécurité dans un réseau permet de réduire le risque associé à un réseau ouvert en segmentant les services d’infrastructure en regroupements logiques assujettis aux mêmes stratégies de sécurité et aux mêmes exigences de sécurité en matière de communication. La segmentation, que l’on appliquait jadis aux centres de données traditionnels, a évolué avec l’adoption grandissante de l’informatique en nuage. Les outils d’automatisation logiciels, comme les outils d’orchestration et les réseaux SDN, peuvent servir à mettre en œuvre une segmentation dans le cadre d’une gestion infonuagique.

La segmentation empêche les auteurs de menace de se déplacer latéralement entre les différentes zones de l’environnement en nuage. Par exemple, la compromission d’une charge de travail par un auteur de menace dans une zone donnée ne peut pas mener à la compromission d’autres charges de travail dans les autres zones de l’environnement en nuage. Il est ainsi possible de réduire la zone de souffle d’une attaque fructueuse dans le nuage.

La zone de souffle est réduite, car des zones plus granulaires sont définies et mises en œuvre. Il convient donc d’en tenir compte dans la stratégie de segmentation de votre organisation. Des ressources de calcul, de réseau et de stockage distinctes doivent être allouées à chaque zone d’un environnement en nuage. En l’occurrence, les plans de contrôle et de données doivent résider dans des zones différentes et des ressources distinctes doivent leur être allouées. Dans le cadre de la segmentation en nuage, le plan de contrôle doit faire partie d’une ZG, alors que le plan de données doit faire partie d’une ZAR liée aux données ou aux applications.

Dans le cadre d’une stratégie de défense en profondeur, la segmentation sert à restreindre l’accès aux zones infonuagiques internes de la zone publique. Une ZAP devrait être désignée comme point d’accès externe unique pour tous les flux de trafic et ces flux devraient être négociés par un PIZ. Les contrôles relatifs au flux de trafic à l’intérieur d’une zone et entre les zones sont mis en œuvre selon la stratégie de sécurité de votre organisation. Il se peut que la politique de sécurité de votre organisation fasse partie de la conception de la sécurité d’entreprise et des stratégies de sécurité de flux de données de votre organisation.

Il convient de plus d’appliquer le principe de droit d’accès minimal à la segmentation réseau. Les communications de charges de travail à l’intérieur d’une même zone et entre différentes zones doivent se limiter aux flux de trafic et aux chemins autorisés. Il est important d’appliquer ce principe au moment d’accorder les autorisations d’accès réseau aux utilisatrices et utilisateurs avec et sans accès privilégié. Par exemple, ce principe de segmentation s’applique lorsqu’on permet aux utilisatrices et utilisateurs avec accès privilégié d’accéder aux interfaces de gestion sur le plan de contrôle et que l’on permet aux utilisatrices et utilisateurs sans accès privilégié d’accéder aux charges de travail sur le plan des données.

Le réseau SDN permet de procéder à l’abstraction des ressources infonuagique et au découplage du plan de contrôle du nuage à partir du plan de données. Il est intégré à l’environnement en nuage et est invisible aux utilisatrices et utilisateurs, peu importe s’ils disposent ou non d’un accès privilégié. Sur le plan de la taille, le plan des données est beaucoup plus gros que le plan de contrôle, souvent par plusieurs ordres de grandeur. Le modèle avec adaptateur peut être utilisé dans le cadre de la segmentation pour gérer les flux de trafic entre deux plans (voir la section 6.7, Modèle avec adaptateur).

4.2 Gestion du nuage

Dans les environnements en nuage, le FSI fournit les services de gestion en mode natif à partir d’un portail SaaS. L’organisation peut ainsi configurer la ZG native en nuage de manière à ce que les paramètres de sécurité de la ZG offrent la posture de sécurité souhaitée.

La ZG traditionnelle est remplacée et intégrée à la structure informatique du FSI. De plus, les risques liés à l’utilisation d’une ZG sont atténués par des contrôles de sécurité généralement offerts par le FSI. Votre organisation devra donc configurer les contrôles de sécurité de façon à assurer la posture de sécurité souhaitée. Le fait d’accéder aux tâches de gestion par l’entremise d’une ressource du nuage permet de réduire davantage la surface d’attaque et la zone de souffre, ce qui n’est pas le cas lorsqu’on utilise une ZG pour accéder à toutes les ressources en nuage à partir d’une zone particulière.

Selon la tendance actuelle, l’accès à la gestion n’est pas fourni à partir des points terminaux publics et des ports de gestion traditionnels, ce qui permet, dans une certaine mesure, de garder l’environnement en nuage hors de la mire des auteurs de menace. À la place, une connectivité sécurisée est d’abord établie dans l’environnement du FSI vers le point terminal de gestion autorisé. Ce dernier peut alors faire appel à la connectivité réseau sécurisée précédemment établie pour exécuter des tâches de gestion sur une ressource du nuage en particulier. Il s’agit de la procédure recommandée dans un environnement en nuage.

Il est également recommandé d’avoir recours à une solution d’identité et d’accès privilégié pour sécuriser les comptes de gestion servant à la réalisation de tâches privilégiées. La solution devrait être sécurisée en ayant recours, par exemple, à l’authentification multifacteur.

4.3 Conteneurs

Dans une architecture d’applications à trois niveaux traditionnelle, une application est divisée en fonction des niveaux suivants : Web, application et base de données. Chaque niveau dispose de ses propres ressources de calcul, de réseau et de stockage dans chacune des zones distinctes. Prière de consulter l’ITSG-38^{Notes de bas de page 3} pour des conseils supplémentaires.

Dans une architecture avec microservices, une application est divisée en plusieurs sous-composants. Chaque sous-composant comporte généralement une seule fonction bien définie, qui consiste en un processus unique exécuté dans un conteneur dédié et séparé. Un processus exécuté dans un conteneur unique permet d’assurer l’isolation du processus. Par défaut, les flux de trafic entre les conteneurs ne sont pas restreints. Des conseils sur la façon de restreindre ces flux de trafic seront fournis dans la présente section.

Une des différences importantes entre les conteneurs et les machines virtuelles est que les premiers sont constitués d’un processus unique, vraisemblablement exécutés sur une machine virtuelle, alors que les seconds exécutent une application et ses dépendances (le cas échéant). En l’occurrence, un ou plusieurs conteneurs peuvent être exécutés sur une seule machine virtuelle ou dans le noyau d’un seul système d’exploitation (SE). Un conteneur qui contient des données dont le niveau de classification est élevé peut, par exemple, s’exécuter sur une machine virtuelle dédiée lorsque les zones sont établies adéquatement et que d’autres contrôles de sécurité appropriés sont mis en place, alors que plusieurs conteneurs avec des données dont le niveau de classification est peu élevé peuvent résider dans le noyau d’un système d’exploitation.

Les conteneurs isolent le noyau du SE et les ressources matérielles. Ils disposent de la logique applicative, des configurations et des dépendances nécessaires pour permettre leur exécution.

Le diagramme ci-dessous (figure 1) illustre trois conteneurs, leurs dépendances et le plan de contrôle.

Figure 1 : Conteneurs

Description détaillée - Conteneurs

La figure 1 se compose de quatre segments, chacun contenant des encadrés distincts pour représenter le traitement des conteneurs. L’image illustre trois conteneurs, leurs dépendances et le plan de contrôle. Il y a trois conteneurs étiquetés A, B et C. Chaque conteneur est relié à une bibliothèque ou un binaire distinct. Chaque conteneur est utilisé pour exécuter un processus unique, généré à partir d’une fonction bien définie.

Les conteneurs extrairont les ressources du noyau du système d’exploitation et du matériel et les exécuteront pendant l’exécution. Cela est illustré dans le diagramme du troisième segment présenté dans un encadré intitulé « Plan de contrôle – Moteur d’exécution du conteneur (outil d’orchestration) ».

Le dernier segment de l’image représente le processus dans lequel une application est divisée en niveaux Web, application et base de données. Chaque niveau dispose de ses propres ressources réseau, de calcul et de stockage dans des zones distinctes.

Les conteneurs servant à différentes fonctions doivent être répartis dans différentes ZAR en fonction de la classification et du niveau de sensibilité des données. Par exemple, les conteneurs qui hébergent une application et une base de données faisant partie intégrante d’une solution devraient être placés dans des ZAR différentes. Il est important de souligner que le présent guide ne permet pas d’assurer une sécurité à plusieurs niveaux. Un outil d’orchestration de conteneurs peut être utilisé pour gérer le déploiement des conteneurs et s’assurer que le principe de droit d’accès minimal est appliqué aux flux des trafics entrant et sortant entre les conteneurs. Considéré comme faisant partie du plan de contrôle infonuagique, cet outil sert également, en pareil cas, à renforcer les zones ayant été établies. Prière de consulter la figure 21 à l’annexe D, pour une représentation de la relation entre les plans de contrôle et de données.

Le principe de droit d’accès minimal devrait être appliqué aux flux de trafic entre les conteneurs d’un même noyau, d’une même zone réseau et de zones différentes. Par défaut, une règle explicite interdisant tout trafic devrait être mise en place et l’accès devrait être accordé en fonction des exceptions. Par exemple, les communications connues entre différents conteneurs formant un microservice devraient être autorisées.

Des zones devraient être établies pour restreindre l’accès aux conteneurs et au microservice en utilisant des contrôles d’accès granulaires. Les communications entre les conteneurs d’une même zone (ne faisant pas partie d’un même microservice) ou de zones différentes devraient être restreintes et n’autoriser que celles qui sont nécessaires. Prière de consulter la section 4.5 pour plus de détails sur le contrôle d’accès granulaire.

Il est important d’établir des zones pour les flux des trafics entrant et sortant. Il convient de limiter ces deux types de trafic en utilisant les mécanismes appropriés, comme des PIZ pour l’application des zones.

Voici trois (3) cas d’utilisation qui surviennent dans la segmentation et le zonage en conteneurs :

1. Les conteneurs devraient être segmentés en fonction de leur contexte de sécurité relatif pour veiller à ce qu’un noyau système particulier ne puisse exécuter que des conteneurs ayant le même niveau de sensibilité des données et les mêmes fonctionnalités. Par exemple, les conteneurs qui constituent un microservice unique peuvent partager les mêmes ressources de calcul, de réseau et de stockage.
2. Les conteneurs avec des fonctionnalités différentes, mais partageant un même contexte de sécurité ou une même classification de données, doivent être isolés. Dans un tel cas, les différents conteneurs devraient être regroupés dans la même zone et segmentés les uns des autres en leur allouant des ressources différentes. Par exemple, les applications publiques et internes devraient être placées dans des réseaux virtuels différents, et les communications entre les deux réseaux devraient s’effectuer à partir d’un petit nombre d’interfaces bien définies selon la stratégie de sécurité de votre organisation.
3. Vous devriez séparer les conteneurs ayant des classifications de données différentes dans des zones distinctes et utiliser des ressources de calcul, de réseau et de stockage différentes. Les conteneurs dont le niveau de classification des données est plus élevé devraient être placés dans des ZAR différentes avec des ressources différentes, comparativement aux conteneurs dont le niveau de classification des données est inférieur. Par exemple, vous pouvez utiliser un outil d’orchestration pour isoler des conteneurs dans des ensembles d’hôtes en fonction du niveau de sensibilité.

Dans la plupart des cas, vous pouvez définir des règles qui empêchent les charges de travail hautement sensibles de votre organisation de se trouver sur un hôte dont le niveau de sensibilité est inférieur. Il est possible de le faire en mettant en place des grappes distinctes et gérées individuellement pour chaque niveau de sensibilité. Vous pouvez également utiliser un outil d’orchestration pour « associer » un conteneur à un hôte, lorsque celui-ci est affecté à un hôte particulier. Il convient de savoir que l’« association » à un hôte fera en sorte de rendre le conteneur indisponible si l’hôte est aussi indisponible.

Les cas d’utilisation des conteneurs sont en constante évolution. Par exemple, le déploiement d’une base de données conteneurisée est un cas d’utilisation qui n’est pas encore tout à fait au point. Dans certains exemples particuliers, il s’agit toutefois d’une pratique acceptable. Par exemple, cette pratique peut être utilisée dans les environnements en nuage hors production, comme les environnements de tests et de développement. Dans tous les cas d’utilisation, il est nécessaire d’adopter des principes d’établissement de zones rigoureux, comme l’utilisation de conteneurs dans des ZAR de données.

4.4 Interface de programmation d’applications (API)

Le passage à un environnement en nuage et, plus particulièrement, à une architecture de microservices, fait en sorte que les microservices communiquent par l’intermédiaire d’interfaces de programmation d’applications (API pour Application Programming Interface) bien définies. La plupart, voire la totalité des composants logiciels des environnements en nuage offerts par les FSI sont basés sur des API. Ces dernières font partie des outils d’automatisation du nuage, comme les outils d’orchestration et les réseaux SDN. Vous pouvez utiliser des API pour exposer vos données et services organisationnels à des entités et à des utilisatrices et utilisateurs externes. De plus, l’accès aux API doit être sécurisé et restreint à des zones et à des charges de travail particulières.

Au sein d’un environnement en nuage, les API peuvent être déployées dans différentes zones du réseau, selon les exigences opérationnelles de votre organisation. Par exemple, des API peuvent être déployées comme services en périphérie dans la ZAP, le plan de contrôle infonuagique et le plan de données d’un environnement en nuage. Les API peuvent également être déployées dans la même zone que le microservice ou sur un réseau sur site. On peut avoir recours à des consoles Web et des outils natifs en nuage pour effectuer des appels d’API en vue de gérer les ressources de l’environnement en nuage et de soumettre des demandes à un microservice. Dans un centre de données traditionnel, les stations de travail sont parfois utilisées pour réaliser, entre autres choses, des tâches administratives sur des serveurs et des plateformes de gestion du matériel.

Vous trouverez ci-dessous quelques cas d’utilisation et de positionnement d’API visant à assurer la segmentation :

1. Les API peuvent servir à négocier les flux de trafic entre le plan de contrôle, le plan de données et l’application dorsale, comme une application patrimoniale ou une base de données en fin de vie. Dans un tel cas, l’API doit être placée dans le plan de données, aussi près que possible de la charge de travail. Prière de consulter la section 6.6, Modèle avec conteneur, pour plus de détails.
2. Les API peuvent servir à négocier les flux de trafic entre l’environnement en nuage et un réseau sur site ou la zone publique. L’API est placée dans la ZAP de l’environnement en nuage dans le cadre des services en périphérie. Il s’agit du seul point d’entrée des microservices pour toutes les demandes qui proviennent de sources externes. Prière de consulter la section 6.9, Modèle avec API, pour plus de détails.
3. Les API servent à réaliser les tâches de gestion dans le cadre du plan de contrôle. Par exemple, les utilisatrices et utilisateurs avec accès privilégié utilisent une API pour gérer les ressources de calcul, de réseau et de stockage. Prière de consulter la section 6.9.1, Modèle avec passerelle d’API, pour plus de détails.
4. Vous pouvez utiliser des API pour fournir une connectivité réseau au plan de données et une connectivité entre des composants différents sur ce plan. Par exemple, une API, en tant que mandataire, peut fournir la connectivité entre des microservices de la ZAR d’application et donner l’état opérationnel du plan de contrôle. Prière de consulter la section 6.6.2, Modèle ambassadeur, pour plus de détails.

En outre, les API peuvent être utilisées pour mettre en œuvre la stratégie de sécurité de l’organisation. Par exemple, l’API d’une stratégie de contrôle d’accès peut être utilisée afin de restreindre l’accès aux microservices. Dans un tel cas, l’API de la stratégie permet d’appliquer le contrôle d’accès aux flux des trafics entrant et sortant des microservices. Pour ce qui est du trafic entrant, l’API restreint les flux de trafic à l’intérieur du conteneur. Quant au trafic sortant, l’API est déployée en périphérie de l’environnement en nuage pour appliquer un contrôle d’accès en fonction des demandes de client. Prière de consulter la section 6.6, Modèle avec conteneur, pour plus de détails sur le contrôle d’accès du trafic entrant. On peut également consulter la section 6.6.2, Modèle ambassadeur et la section 6.9.1, Modèle avec passerelle d’API, pour plus de détails sur le contrôle d’accès du trafic sortant.

4.5 Contrôle de l’accès

L’accès aux microservices et aux API doit être restreint aux ressources, aux utilisatrices et aux utilisateurs autorisés au moyen de contrôles d’accès très précis. Les exemples de ces contrôles d’accès comprennent le recours à la segmentation, à l’authentification et à l’autorisation. Toutes les communications au sein d’une zone et entre les zones doivent être sécurisées au moyen du protocole TLS 1.2 ou une version plus récente, conformément aux directives du Centre pour la cybersécurité.

Pour sécuriser le trafic entrant entre les microservices, il convient d’utiliser l’authentification de l’entité homologue et l’authentification de demandes. L’authentification de l’entité homologue sert à assurer l’authentification entre services et à confirmer que le client a bien établi une connexion. Le client et le serveur doivent utiliser une certification TLS pour s’identifier entre eux. Ce faisant, il est également possible de protéger les communications entre les deux parties en assurant la confidentialité et l’intégrité des données. L’authentification de demandes vise à vérifier les justificatifs d’identité associés à la demande. On l’utilise lorsqu’une demande est soumise à partir du client sur le serveur au nom d’une utilisatrice finale ou d’un utilisateur final.

Toutes les demandes de service doivent être authentifiées et autorisées avant d’accorder un accès. Il convient d’utiliser des clés d’API et des normes ouvertes, comme Open Authorization 2.0 (OAuth 2.0), pour sécuriser les demandes de service. Les clés d’API devraient être stockées de manière sécurisée et leur accès devrait être restreint. Prière de consulter la Normes du gouvernement du Canada sur les API^{Notes de bas de page 9} du SCT pour plus de détails sur la façon de sécuriser les API et les services infonuagiques. Pour de plus amples renseignements, consultez l’ITSP.40.062, Conseils sur la configuration sécurisée des protocoles réseau^{Notes de bas de page 10}.

5 Conseils sur la périphérie et le périmètre du nuage

L’environnement en nuage est en train de transformer la définition traditionnelle et le rôle joué par la périphérie de réseau ou le périmètre. Il est plus décentralisé et, par extension, sa périphérie est également plus décentralisée. Par exemple, l’environnement en nuage présente plusieurs points terminaux publics associés à différents services IaaS et PaaS du FSI. On retrouve généralement plusieurs points terminaux privés qui permettent d’utiliser les services infonuagiques dans un réseau virtuel, tout en continuant d’adhérer aux principes d’établissement de zones de réseau.

Pour cette raison, la sécurisation de la périphérie ou du périmètre d’un environnement en nuage peut poser plusieurs défis et il est d’autant plus important d’établir les zones pour ce qui est des flux des trafics entrant et sortant. Ces deux types de trafic devraient être limités au moyen de mécanismes appropriés, comme des PIZ, de manière à renforcer l’établissement des zones. En outre, il est possible de tirer avantage des outils d’orchestration de conteneurs et de la technologie de réseau virtuel pour assurer l’application des stratégies de sécurité d’un ministère pour les deux flux de trafic.

Selon la topologie de connectivité utilisée, le FSI gérera la périphérie du nuage. D’autres intermédiaires (section 6.4), comme les fournisseurs de services de sécurité gérés (FSSG), peuvent également offrir des services de sécurité ou des CASB afin d’étendre davantage la périphérie ou le périmètre.

5.1 Cas d’utilisation et conseils

Dans le nuage, l’environnement est un réseau virtuel en soi. La présente section examinera la façon de tirer avantage des topologies de connectivité et d’étendre un réseau virtuel en l’intégrant à d’autres réseaux virtuels. La section suivante abordera la façon d’utiliser les topologies de connectivité dans un réseau virtuel au moment d’établir les zones du nuage.

Vous trouverez ci-dessous quelques cas d’utilisation et conseils à ce sujet :

• Cas d’utilisation : Un autre réseau virtuel dans un même compte de niveau supérieur
  • Conseils : En ce qui a trait à la connectivité réseau, il est possible d’intégrer deux réseaux virtuels appartenant au même compte de niveau supérieur de manière à tirer parti des services réseau du FSI, comme l’appairage de réseaux virtuels ou les passerelles réseau. Certains de ces services réseau proposent des fonctions de sécurité pour le filtrage du trafic réseau et le contrôle de l’accès.
  • Dans la plupart des cas, ces services réseau ne respectent pas les fonctions et les exigences de sécurité d’un PIZ et devraient être renforcés par l’intégration d’un PIZ. Le PIZ doit être associé à une ZAP sur les deux réseaux virtuels pour les flux des trafics entrant et sortant.
  • On conseille de faire appel au modèle de réseau en étoile où chaque réseau virtuel d’application se trouve dans un rayon. Le PIZ peut être mis en œuvre dans chaque réseau virtuel des rayons et le concentrateur peut reposer sur les exigences et les stratégies de sécurité de l’organisation. Prière de consulter la section 6.2, Modèle de réseau en étoile, et la figure 2 : Architecture conceptuelle, pour plus de détails sur le modèle de réseau en étoile.
• Cas d’utilisation : Un autre réseau virtuel dans un compte de niveau supérieur différent au sein d’une même région du nuage
  • Conseils : La plupart des FSI fournissent des services interrégionaux auxquels on peut avoir recours pour intégrer les réseaux virtuels qui se trouvent dans différents comptes de niveau supérieur. Par conséquent, les directives fournies dans le scénario précédent s’appliquent également à ce cas d’utilisation, notamment pour ce qui est de l’utilisation du modèle de réseau en étoile.
• Cas d’utilisation : Un autre réseau virtuel dans un compte de niveau supérieur différent au sein d’une région différente du nuage
  • Conseils : La plupart des FSI fournissent des services intrarégionaux auxquels on peut avoir recours pour intégrer les réseaux virtuels qui se trouvent dans différents comptes de niveau supérieur de régions différentes. Par conséquent, les directives fournies dans le scénario précédent s’appliquent également à ce cas d’utilisation, notamment pour ce qui est de l’utilisation du modèle de réseau en étoile.
• Cas d’utilisation : Un autre réseau virtuel dans un compte de niveau supérieur différent relevant d’un autre FSI
  • Conseils : Pour le moment, les FSI n’offrent aucune connectivité réseau aux autres FSI par l’intermédiaire de leur fond de panier. Il ne reste que deux options de réseau : utiliser un réseau avec ZP ou un réseau sur site.
    • Zone publique. Il est possible de faire appel à une connectivité directe, d’Internet à Internet, ou encore à un RPV site à site. Dans ces deux cas d’utilisation, la connexion devrait s’effectuer dans la ZAP. Vous pouvez tirer avantage des conseils formulés à la section 6.2, Modèle de réseau en étoile, et à la section 6.4, Topologie de connectivité intermédiaire, et interrompre la connectivité dans la ZAP du concentrateur qui fait office de PIZ.
    • Sur site. On suppose que l’organisation a établi une connexion réseau dédiée entre son réseau sur site et deux centres de données régionaux du FSI au moyen d’un fournisseur d’accès Internet (FAI). Cette connexion réseau dédiée doit avoir recours à des fonctions de sécurité, comme un RPV IPsec, le chiffrement OSI de couche 2 et le chiffrement TLS. Il s’agit d’un élément de référence. De plus amples recherches sur les protections supplémentaires à ajouter aux systèmes de niveau supérieur pourraient s’avérer nécessaires. Prière de consulter les conseils formulés à la section 6.3, Topologie de connectivité hybride. Si le même FAI est utilisé pour les deux FSI, il pourrait être possible d’acheminer le trafic réseau directement du FAI, sans avoir d’abord à passer par le site du premier FSI (du nuage au site), puis transmettre le trafic du réseau sur site vers le deuxième FSI (du site au nuage).
• Cas d’utilisation : Réseau sur site
  • Guidance: On suppose que l’organisation a établi une connexion réseau dédiée entre son réseau sur site et deux centres de données régionaux du FSI au moyen d’un fournisseur d’accès Internet (FAI). Cette connexion réseau dédiée peut utiliser des fonctions de sécurité supplémentaires, comme IPsec, MACsec et le protocole TLS. Prière de consulter les conseils formulés à la section 6.3, Topologie de connectivité hybride.

6 Topologie de connectivité

La présente section traitera des modèles de conception infonuagique liés à la sélection et la mise en œuvre de zones auxquels on fera référence dans les sections subséquentes. Un modèle est une collection de solutions réutilisables et d’idées de conception misant sur l’utilisation des technologies pour résoudre des problèmes de conception de système courants. Il présente un flux de données de bout en bout entre les composants ou les zones d’un système.

Les modèles de conception sont utiles, puisqu’ils proposent des solutions établies à des problèmes de conception courants et sont généralement faciles à répéter. Ils sont organisés dans un format de référence normalisé et permettent d’assurer une cohérence en ce qui a trait à la conception et à la mise en œuvre des systèmes. Leur utilisation ne garantit pas que les problèmes de conception seront toujours résolus, car plusieurs facteurs peuvent entrer en ligne de compte, dont les exigences et les contraintes de sécurité des clients.

Les topologies de connectivité au nuage qui seront examinées dans la présente conviennent à tous les FSI. Les modèles couverts dans la présente section sont documentés, le cas échéant, de la façon suivante :

• Nom et brève description du modèle;
• Brève explication des difficultés pouvant être résolues au moyen de la mise en œuvre du modèle. Il peut s’agir d’une exigence;
• Visualisation de la structure du modèle, dont la solution de conception proposée par le modèle afin de résoudre le problème et de répondre aux exigences;
• Conseils sur la façon dont le modèle peut être appliqué, ce qui comprend les directives, les cas d’utilisation, les avantages et les inconvénients.

La présente section portera sur les modèles suivants :

• Modèle de réseau en étoile;
• Modèle hybride;
• Modèle intermédiaire;
• Modèle avec enclave de données;
• Modèle avec conteneur;
• Modèle avec adaptateur;
• Modèle avec API ou anti-API.

6.1 Présentation conceptuelle

Avant d’aborder les modèles individuels et d’y faire référence, il convient d’examiner les diagrammes ci-dessous, qui offre une présentation conceptuelle de certains des modèles importants et explique comment on peut les utiliser. Prière de consulter l’annexe B pour plus de détails.

Figure 2 : Architecture conceptuelle

Description détaillée - Architecture conceptuelle

La figure 2 donne une vue d’ensemble de l’architecture conceptuelle. Le diagramme montre un utilisateur en télétravail qui se connecte au lieu de travail sur site au moyen d’un réseau privé virtuel (RPV). L’icône Pare-feu se trouve sous l’icône représentant le lieu de travail sur site pour mettre en évidence le fait que le trafic passe par le pare-feu jusqu’au WAN interne qui est représenté par une icône Nuage.

Deux tubes sont connectés à l’icône Nuage WAN pour représenter le flux de trafic et de données qui transite du WAN à l’opérateur nuagique par l’intermédiaire d’un SIE/SII ou d’un point d’interconnexion Internet. Le trafic et les données continuent de circuler de l’opérateur nuagique vers le nuage SaaS d’entreprise fourni par le FSI, représenté par une icône Nuage avec un point d’entrée et de sortie sécurisé dans le diagramme. Le trafic et les données circulent du SIE/SII ou XP vers le PaaS ou l’IaaS par l’intermédiaire d’une cyberdéfense en nuage hébergée par le FSI, le tout représenté par un point d’entrée et de sortie sécurisé dans le diagramme. Le trafic provenant des plateformes nuagiques, SaaS, PaaS ou IaaS, est ensuite acheminé aux clients ou au personnel externes, qui sont représentés par l’icône d’une personne travaillant devant un ordinateur portable.

Figure 3 : Architecture conceptuelle pour le GC

Description détaillée - Architecture conceptuelle pour le GC

La figure 3 donne un aperçu de l’architecture conceptuelle au sein du GC. Le diagramme montre un utilisateur en télétravail qui se connecte au lieu de travail sur site au moyen d’un réseau privé virtuel (RPV). L’icône Pare-feu se trouve sous l’icône représentant le lieu de travail sur site pour mettre en évidence que le trafic passe par le pare-feu jusqu’au WAN interne du GC, qui est représenté par une icône Nuage.

Deux tubes sont connectés à l’icône Nuage WAN du GC pour représenter le flux de trafic et de données qui transite du WAN à l’opérateur nuagique par l’intermédiaire d’un SIE/SII ou d’un point d’interconnexion Internet. Le trafic et les données continuent de circuler de l’opérateur nuagique vers le nuage SaaS du ministère ou du GC fourni par le FSI, le tout représenté par l’icône Nuage avec un point d’entrée et de sortie sécurisé dans le diagramme. Le trafic et les données circulent du SIE/SII ou point d’interconnexion Internet vers le PAI du GC (PaaS ou IaaS) par l’intermédiaire d’une cyberdéfense en nuage hébergée par le FSI, le tout représenté par un point d’entrée et de sortie sécurisé dans le diagramme. Le trafic provenant des plateformes nuagiques, SaaS, PaaS ou IaaS, est ensuite acheminé aux clients ou au personnel externes, qui sont représentés par l’icône d’une personne travaillant devant un ordinateur portable.

La vue de l’architecture conceptuelle offre une perspective de haut niveau de certaines topologies de connectivité clés les plus courantes, comme les réseaux hybrides, intermédiaires et en étoile. Le trafic entrant et sortant de l’environnement en nuage provient des nombreux points terminaux publics du FSI. Un modèle de réseau en étoile est au cœur de l’architecture du réseau et de l’établissement de ses zones. Le concentrateur héberge les services communs ou partagés, comme la surveillance, le routage et l’inspection. Ces services peuvent être consommés par différentes charges de travail hébergées dans les rayons. De plus, le concentrateur agit à titre d’intermédiaire et inspecte tout le trafic entre la ZP, votre réseau sur site et votre environnement en nuage.

Les charges de travail du nuage de votre organisation sont déployées dans les rayons. Un rayon peut être segmenté en différentes zones, comme les niveaux s’appliquant au Web, aux applications et aux bases de données au sein des groupes de sécurité réseau (NSG) utilisés pour restreindre l’accès.

Vous trouverez ci-dessous quelques avantages découlant de l’utilisation d’un modèle de réseau en étoile :

• Vous pouvez isoler les charges de travail dans les différents rayons. Par exemple, les charges de travail présentant différentes classifications de données doivent se trouver dans des modèles différents et utiliser des ressources différentes.
• Il n’y a qu’un seul point pour le trafic entrant et sortant, le concentrateur, ce qui permet de réduire la surface d’attaque.

Voici ce que vous devez garder à l’esprit lors de la mise en œuvre d’un modèle de réseau en étoile dans votre environnement en nuage :

• Les environnements en nuages ont des implications en matière de coûts, en particulier si des frais sont imputables au trafic rayon-concentrateur-rayon. Par exemple, vous pourriez devoir payer des frais pour les flux des trafics entrant et sortant, notamment dans les cas d’utilisation à fort trafic. Votre organisation peut réduire les frais en faisant preuve d’une diligence raisonnable.

Le trafic peut provenir des installations sur site, où on retrouve un modèle hybride, ou de la ZP, où on retrouve un modèle intermédiaire. Il existe différentes formes d’intermédiaires, comme les FSSG et les CASB. Un bon exemple de FSSG est le service de connectivité hybride du GC. De plus, les services CASB peuvent être utilisés en tant que mandataire inverse pour l’application des stratégies, comme l’authentification, l’authentification unique, l’autorisation et le chiffrement. Prière de consulter le glossaire pour de plus amples renseignements sur les FSSG, les CASB et le service de connectivité hybride du GC.

Dans le contexte du gouvernement du Canada, le service de connectivité hybride du GC intègre un PIZ qui négocie tout le trafic réseau entre les installations sur site et la NACL du nuage. On peut également utiliser le PIZ pour négocier et inspecter tout le trafic réseau depuis la ZP. Certaines capacités du service de connectivité hybride du GC incluent des CASB, des NGFW, le déchiffrement TLS et des inspections approfondies des paquets.

Le modèle de réseau en étoile dans un environnement en nuage a été abordé à la section 5. La section 6 traitera des différents modèles retrouvés dans un réseau virtuel en étoile, comme les modèles avec enclave de données, avec conteneur et avec API.

6.2 Modèle de réseau en étoile

Points essentiels de ce modèle

Le modèle de réseau en étoile permet d’assurer une gestion efficace des exigences de communication et de sécurité courantes. Le concentrateur est une zone de sécurité de réseau qui contrôle et inspecte le trafic entrant ou sortant qui circule entre les zones suivantes : Internet, sur site et rayons. Par exemple, une passerelle RPV peut être déployée à titre de service commun pour fournir une connectivité sécurisée entre votre centre de données sur site et votre environnement en nuage au moyen de ce modèle. Prière de consulter la figure 4 – Topologie de connectivité du réseau en étoile pour plus de détails.

Remarque : Par défaut, les flux de trafic sont autorisés entre les rayons. Ces flux de trafic dépendent de la stratégie de sécurité et du cadre de gestion des risques de votre organisation. Prière de consulter la section 4 − Conseils sur l’établissement de zones dans le nuage pour plus de détails sur certaines des mesures d’atténuation que l’on peut appliquer à ces flux de trafic.

Le modèle de réseau en étoile propose les avantages suivants à votre organisation :

• Réseau : On peut utiliser le concentrateur pour contrôler le trafic entrant et sortant, ce qui permet d’isoler votre réseau et de réduire la zone de souffle;
• Conformité :
  • Un nouveau rayon hérite des contrôles et des exigences de sécurité de référence du concentrateur et de l’environnement dans son ensemble;
  • La séparation des rayons est basée sur des exigences environnementales différentes, comme dans le cas des environnements de production et de non-production, ou de la séparation des secteurs d’activité;
• Extensibilité : Des rayons supplémentaires peuvent être ajoutés facilement, sans incidence sur les rayons actuels. Le FSI pourrait imposer des limites selon votre mise en œuvre, notamment pour l’appairage de réseaux virtuels ou la passerelle réseau.

Figure 4 : Topologie de connectivité du réseau en étoile

Description détaillée - Topologie de connectivité du réseau en étoile

La figure 4 illustre la topologie du réseau en étoile. Il s’agit d’un diagramme avec l’icône d’un gros nuage et l’icône d’un nuage plus petit portant la mention « ZP ». Ce nuage plus petit représente la zone publique et comporte une flèche allant de la ZP à l’environnement nuagique interne IaaS ou PaaS du FSI. Il y a un rectangle entouré d’une ligne pointillée et deux rectangles supplémentaires portant les mentions « PIZ de ZP » et « PIZ de zone interne » sous le mot « Concentrateur ». Les PIZ de ZP et PIZ de zone interne relient le trafic entrant dans les sous-réseaux privés au rayon de ZAR d’application et au rayon de ZAR ou ZATR de données. On trouve du côté gauche de l’icône du gros nuage les mots « Sous-réseau public » et « Trafic sortant ».

Remarque : L’interface privée du PIZ de la zone interne et le sous-réseau privé du PIZ peuvent se trouver sur les mêmes flux des trafics entrant et sortant ou il peut s’agir d’interfaces privées et de sous-réseaux privés différents. Ce modèle s’applique également à tous les diagrammes présentés jusqu’à la fin du présent document, qui illustrent des flux des trafics entrant et sortant.

Comme l’indique le diagramme précédent, il existe une séparation logique entre les flux des trafics sortant et entrant. Le concentrateur joue ainsi une double fonction sans nécessiter une séparation entre les deux flux; il est composé d’un sous-réseau privé et d’un sous-réseau public. Les rayons sont hébergés sur des sous-réseaux privés.

Conseils

Le PIZ de la ZP devrait être utilisé pour filtrer les paquets selon les caractéristiques définies par votre organisation et ne devrait avoir recours qu’aux services nécessaires pour communiquer avec la ZP. Le ou les PIZ de la zone interne du concentrateur peuvent faire office de PIZ pour les rayons s’ils respectent toutes les fonctions de sécurité et les exigences présentées à l’annexe A. Par exemple, votre organisation peut déployer un pare-feu infonuagique en mode natif, l’appliance NGFW d’une tierce partie ou un équilibreur de charge dans le concentrateur et y intégrer un module de gestion unifiée des menaces (UTM pour Unified Threat Management) pour le trafic sortant entre la ZP et le concentrateur.

Dans le cas du trafic entrant, le concentrateur peut servir de PIZ si les rayons ne comportent aucun PIZ. Si un PIZ est intégré à chaque rayon, le concentrateur peut fournir des capacités de routage réseau, dont le contrôle d’accès. Dans un tel cas, toutes les ressources du concentrateur portent la même classification de données et sont gérées concurremment.

Prière de consulter les modèles hybride et intermédiaire pour obtenir des renseignements supplémentaires sur l’intégration de ces modèles.

Vous trouverez ci-dessous trois cas d’utilisations liés au trafic entrant dans un modèle de réseau en étoile selon la stratégie de sécurité et le cadre de gestion des risques de votre organisation :

1. Les rayons d’un même concentrateur peuvent communiquer entre eux par l’intermédiaire du PIZ du concentrateur, ainsi qu’au moyen d’autres contrôles d’accès plus détaillés, ce qui peut servir à restreindre les flux de trafic, le cas échéant. Par exemple, une utilisatrice ou un utilisateur interne a accès à un portail Web qui extrait des données à propos d’un client à partir de sources différentes. Le client possède un compte personnel et un compte d’entreprise, et les données d’applications sont accessibles à partir de différentes interfaces sur des rayons différents. Chaque application a une connectivité directe aux autres applications aux fins de mise à jour, comme la modification du nom d’un client. Prière de consulter la figure 20, Exemples de passerelles d’API, de services API et de conteneurs pour plus de détails;
2. Selon les exigences de sécurité de votre organisation, iI ne doit y avoir aucune connectivité directe entre les rayons. Tout le trafic qui transite entre les rayons passe par le concentrateur. Par exemple, les rayons hébergent les charges de travail des environnements de test, de développement, de préproduction et de production de votre organisation. Prière de consulter la figure 17, Exemple de modèle de réseau en étoile à l’annexe C pour plus de détails;
3. Selon les exigences de sécurité de votre organisation, on doit retrouver une connectivité directe et non directe entre les rayons. Par exemple, un des rayons héberge la zone de travail de votre organisation, tandis que les autres hébergent les charges de travail des environnements de test, de développement, de préproduction et de production. Les environnements de production et de préproduction présentent des configurations matérielles et logicielles similaires, à part le fait que le premier soit entièrement redondant (tous les composants sont déployés en paires). La ZT dispose d’une connectivité directe aux quatre environnements et héberge les postes de travail virtuels. Il n’y a toutefois aucune connectivité directe entre les quatre environnements.
   
   Par exemple, une demande d’assistance est soumise relativement à un bogue rencontré par une utilisatrice ou un utilisateur dans l’environnement de production et est affecté à une développeuse ou un développeur. Le développeur confirmera le bogue en utilisant un ordinateur virtuel dans la ZT pour accéder à l’environnement de production. Il utilisera ensuite l’environnement de préproduction pour déboguer le problème soulevé dans la demande en ouvrant une session d’utilisateur dans la ZT. Prière de consulter la Figure 19, Troisième exemple de modèle de réseau en étoile à l’annexe C pour plus de détails.

6.3 Modèle hybride

Points essentiels de ce modèle

Le modèle hybride est un modèle de conception réseau permettant de gérer efficacement les exigences de sécurité et les communications entre un concentrateur infonuagique, les charges de travail d’un centre de données sur site et les utilisatrices et utilisateurs. Les systèmes, comme les API, et les utilisatrices ou utilisateurs peuvent accéder aux services nécessaires à partir du réseau sur site de votre organisation ou depuis l’environnement en nuage.

Le modèle hybride propose les avantages suivants à votre organisation :

• Réseau : Permet d’assurer une connectivité réseau entre le centre de données sur site de votre organisation et l’environnement en nuage;
• Conformité : Le trafic réseau passera par un réseau privé dédié;
• Extensibilité : Une bande passante dédiée supplémentaire peut être mise en place en collaboration avec votre FSI et un fournisseur d’accès Internet (FAI) intermédiaire pour ce qui est des communications.

Figure 5 : Topologie de connectivité hybride

Description détaillée - Topologie de connectivité hybride

La figure 5 est un diagramme illustrant la topologie de connectivité hybride. On trouve une icône avec trois piliers dans le haut du diagramme pour représenter le centre de données sur site. Les données circulent du centre de données sur site vers l’icône Pare-feu et l’icône de tube qui représente une connexion ou un canal sécurisé pénétrant dans l’image d’un nuage pour illustrer l’environnement IaaS ou PaaS des FSI. On trouve dans l’icône du gros nuage un rectangle avec des lignes pointillées. Celui-ci se compose de deux rectangles supplémentaires avec un badge de sécurité et une flèche pour représenter les PIZ de ZP et PIZ de zone interne. Ces deux PIZ relient le trafic entrant aux rayons de ZAR et de ZT. Les mots « Sous-réseau public » et « Trafic sortant » se trouvent à l’intérieur de l’icône Nuage, à l’extérieur du rectangle avec des lignes pointillées.

Dans le diagramme précédent, une connectivité réseau directe est établie entre le centre de données sur site de votre organisation et l’environnement en nuage.

Tout le trafic qui transite entre le centre de données sur site de votre organisation et l’environnement en nuage doit passer par le PIZ. De plus, le PIZ comprend un mandataire inverse permettant de négocier et de vérifier tout le trafic qui transite entre la ZP et vos charges de travail (hébergées dans votre centre de données sur site et l’environnement en nuage). Selon la stratégie de sécurité de votre organisation, le trafic de la ZP peut être restreint de manière à limiter l’accès aux charges de travail de votre environnement en nuage.

Conseils

Le concentrateur peut faire office de PIZ s’il répond à toutes les fonctions de sécurité et aux exigences mentionnées à l’annexe A. Par exemple, vous pouvez déployer un pare-feu infonuagique en mode natif ou l’appliance NGFW d’une tierce partie dans le concentrateur et y intégrer un module d’UTM pour le trafic réseau sortant entre le concentrateur et le centre de données sur site. Si un PIZ a été mis en œuvre sur un compte de rayon, le concentrateur peut également fournir des capacités de routage réseau, dont le contrôle d’accès.

Le trafic qui transite entre le réseau sur site et le concentrateur devrait être protégé par le protocole IPsec, selon les configurations décrites à l’ITSP.40.062^{Notes de bas de page 10}, ou le protocole MACsec, selon les configurations d’algorithmes de chiffrement décrites à l’ITSP.40.111^{Notes de bas de page 11}. À mesure que la sensibilité des données augmente, il peut être nécessaire de faire appel à des capacités supplémentaires comme, par exemple, deux tunnels RPV et des liens dédiés à partir d’un même fournisseur ou de fournisseurs différents. Les deux tunnels RPV servent au chiffrement des données, ce qui offre une meilleure protection et une redondance accrue.

6.4 Modèle intermédiaire

Points essentiels de ce modèle

Le modèle intermédiaire est une modèle de conception réseau permettant de gérer efficacement les exigences de sécurité et les communications entre un concentrateur et une ZP, comme Internet ou le concentrateur et le centre de données de votre organisation.

Le modèle intermédiaire peut être mis en œuvre par votre organisation ou un fournisseur tiers. La mise en œuvre peut être effectuée dans l’environnement virtuel du FSI, sur site ou au niveau du FAI de manière à faire partie de la connectivité réseau dédiée privée du FSI.

Le modèle intermédiaire propose les avantages suivants à votre organisation :

• Réseau : Tout le trafic réseau en provenance ou en direction de la ZP doit transiter par un intermédiaire, ce qui permet d’améliorer la gestion de la connectivité réseau avec la ZP;
• Conformité :
  • Le trafic réseau transite par un PIZ dédié qui répond à toutes les fonctions de sécurité et à toutes les exigences d’un PIZ. Le concentrateur peut ne pas offrir toutes les fonctionnalités d’un PIZ, mais celles manquantes sont prises en charge par le composant intermédiaire. Par exemple, les services courants qui sont consommés par les rayons, comme le NGFW, le système de détection d’intrusion (SDI) et le système d’adressage par domaines (DNS) sont hébergés par le concentrateur. Les services qui doivent être isolés conformément aux exigences de sécurité, comme les services de surveillance et de conformité, sont hébergés sur le composant intermédiaire;
  • Dans un contexte gouvernemental, ou dans le cas d’une grande entreprise comportant plusieurs secteurs d’activités, l’ensemble du trafic provenant des différents secteurs d’activités passe par le composant intermédiaire. Dans une telle situation, le composant intermédiaire fait office de concentrateur centralisé pour tous les autres concentrateurs des secteurs d’activités;
• Extensibilité : Une bande passante dédiée supplémentaire peut être mise en place en collaboration avec le FSI et un FAI intermédiaire pour ce qui est des communications.

Figure 6 : Topologie de connectivité intermédiaire

Description détaillée - Topologie de connectivité intermédiaire

La figure 6 montre comment fonctionne la topologie de connectivité intermédiaire. Les données et le trafic passent de l’icône Nuage ZP au haut du diagramme à l’icône Nuage intermédiaire en traversant un pare-feu. À partir de là, le trafic et les données peuvent passer par un pare-feu jusqu’au centre de données sur site représenté par une icône avec trois piliers, ou par un pare-feu distinct vers l’environnement du FSI (représenté par l’icône d’un gros nuage). L’icône Nuage contient un rectangle entouré d’une ligne pointillée. À l’intérieur de ce rectangle se trouve le concentrateur du FSI, qui comprend les PIZ de ZP et PIZ de zone interne, le tout représenté par deux rectangles avec des badges de sécurité et des flèches. Le trafic entrant passe des PIZ de ZP ou PIZ de zone interne aux ZT ou ZAR dans les sous-réseaux privés. Les mots « Sous-réseau public » et « Trafic sortant » se trouvent à gauche du rectangle avec les lignes pointillées.

Conseils

Le composant intermédiaire peut fournir les capacités d’un PIZ s’il répond à toutes les fonctions de sécurité et aux exigences mentionnées à l’annexe A. Par exemple, vous pouvez déployer un pare-feu infonuagique en mode natif ou l’appliance NGFW d’une tierce partie dans le composant intermédiaire et y intégrer un module d’UTM pour le trafic sortant entre le composant intermédiaire et le concentrateur.

Une cas d’utilisation courant pourrait prendre la forme d’une organisation qui envoie tout le trafic vers l’environnement en nuage par l’intermédiaire d’un CASB faisant office d’intermédiaire de manière à centraliser la configuration. L’organisation a recours au CASB pour consolider tous les accès vers l’environnement en nuage.

6.5 Modèle avec enclave de données

Points essentiels de ce modèle

La sécurité des données, et plus particulière l’exfiltration des données, est une des principales préoccupations des organisations. Pour aborder la sécurité des données de façon optimale, il convient de faire appel à un mécanisme de défense en profondeur multicouche auquel il est possible d’intégrer des stratégies de sécurité, la gouvernance, la GIdA, la sécurité des applications et la gestion des interventions en cas d’incident. Le modèle avec enclave de données fait partie de la couche de sécurité d’application à utiliser dans une ZAR ou une ZATR.

Le modèle avec enclave pour ZAR ou ZATR comportant des données propose les avantages suivants à votre organisation :

• Sécurité du périmètre :
  • Permet de mettre en place des contrôles du périmètre très précis. On peut atténuer les risques d’exfiltration en isolant les services multilocataires, ce qui fera en sorte d’éviter que des données soient copiées vers des sources non autorisées à l’extérieur du périmètre;
  • Périmètre de sécurité : On peut contrôler les services des FSI qui sont accessibles à partir d’un réseau virtuel;
• Contrôle de l’accès : Il convient de s’assurer que les données sensibles ne sont accessibles qu’à partir des réseaux virtuels autorisés. Ce modèle offre une couche de sécurité supplémentaire en refusant l’accès aux réseaux non autorisés, et ce, même si les stratégies de GIdA régissant les données sont mal configurées;
• Sensibilité au contexte : On peut restreindre une ressource ou un accès d’utilisateur à des adresses IP autorisées, à des identités particulières et à des dispositifs clients approuvés.

Figure 7 : Topologie de connectivité avec enclave de données

Description détaillée - Topologie de connectivité avec enclave de données

La figure 7 est un diagramme détaillant la topologie de connectivité avec enclave de données. On trouve l’icône d’un petit nuage dans le haut du diagramme pour représenter la ZP. Sous l’icône Nuage de la ZP se trouve une image de nuage plus grande pour représenter l’environnement Iaas-PaaS du FSI qui contient le sous-réseau public. Il y a un encadré avec un contour en pointillés dans l’icône Nuage du FSI qui contient deux encadrés plus petits. Le premier est intitulé « Réseau virtuel 1 – Rayon ZAR d’application » et le deuxième, « Réseau virtuel 2 – Rayon de ZAR ou ZATR de données ».

Une flèche avec un crochet au milieu connecte le réseau virtuel 1 au réseau virtuel 2. Cela représente la libre circulation des données et du trafic entre les deux réseaux virtuels. Il y a également une flèche reliant le réseau virtuel 2 à l’icône Nuage ZP. Il y a un « X » au centre pour indiquer que le trafic pourrait ne pas circuler entre le rayon de ZAR ou ZATR de données et la ZP.

Dans le diagramme précédent, les deux réseaux virtuels peuvent appartenir à un même FSI ou à des FSI différents sans connectivité directe entre eux, à l’exception du sous-réseau public (réseau virtuel 2). Les connexions directes à la ZAR de données ou au sous-réseau de la ZATR ne sont pas permises, sauf par l’intermédiaire du sous-réseau privé. Ce sous-réseau héberge les API du service infonuagique restreint. De plus, la ZAR de données ou le sous-réseau de la ZATR ne lance aucune demande de service et ne fournit aucune réponse directe à une demande de service, à moins que ça ne soit par l’intermédiaire du sous-réseau privé.

Conseils

Une enclave de données devrait être mise en œuvre dans un réseau virtuel ou un environnement conteneurisé lorsqu’il s’agit d’une ZAR ou d’une ZATR de données. Prière de consulter l’annexe C, figure 18 – Deuxième exemple de modèle de réseau en étoile pour plus de détails.

Bien que les NACL et les NSG puissent offrir un certain niveau de protection et être utilisées avec des capacités de sécurité additionnelles, comme l’accès tenant compte du contexte, il pourrait être nécessaire de mettre en place d’autres contrôles d’accès plus précis. Les restrictions relatives aux API du service infonuagique sont un bon exemple de ces contrôles d’accès nécessaires. Prière de consulter la figure 18 – Deuxième exemple de modèle de réseau en étoile et la figure 19 – Troisième exemple de modèle de réseau en étoile à l’annexe C pour plus de détails sur la façon dont on peut utiliser les NSG pour restreindre l’accès entre des zones de sécurité au sein d’un rayon.

Prière de consulter la section 6.6 - Modèles avec conteneur, pour de plus amples renseignements sur la façon d’intégrer l’enclave des données à ces modèles.

6.6 Modèles avec conteneur

La présente section traitera de deux modèles : le modèle side-car et le modèle ambassadeur.

Points essentiels de ces modèles

Ces deux modèles avec conteneur sont utiles pour votre organisation pour les raisons suivantes :

1. renforcement de l’isolation des conteneurs;
2. restriction des flux du trafic intraconteneur dans différentes zones de l’environnement en nuage;
3. restriction des flux du trafic interconteneur entre l’environnement en nuage et le réseau sur site ou la ZP.

6.6.1 Modèle side-car

Le modèle side-car se compose de deux conteneurs permettant d’assurer l’isolation et la segmentation des processus : le conteneur auxiliaire et le conteneur principal. Le conteneur auxiliaire vise à réduire la complexité du conteneur principal. Les deux conteneurs sont co-situés dans le même noyau du SE et le conteneur auxiliaire connaît le même sort que le conteneur principal (par exemple, au démarrage et à l’arrêt). Le conteneur auxiliaire offre des fonctions courantes, comme la journalisation, la configuration et la synchronisation des fichiers. Ces fonctions sont consommées par d’autres conteneurs.

Ce modèle peut servir à traiter la connectivité des données entre le conteneur principal et les autres conteneurs qui composent le microservice ou les autres composants de la solution. Un exemple d’utilisation de ce modèle est un serveur Web (conteneur principal) offrant du contenu à des clients externes. Le conteneur principal demande au conteneur auxiliaire d’extraire le contenu demandé à partir de la base de données dorsale. Le conteneur auxiliaire extrait le contenu demandé et le renvoie au serveur Web. Le serveur achemine à son tour le contenu extrait au client externe. Prière de consulter la figure 8 ci-dessous pour plus de détails sur le modèle side-car.

Le modèle side-car appartient au plan de données.

Figure 8 : Modèle side-car

Description détaillée - Modèle side-car

La figure 8 est un diagramme représentant le modèle side-car. Le diagramme comporte l’icône d’un gros nuage qui représente l’environnement IaaS-PaaS du FSI. À l’extérieur de l’environnement du FSI, trois personnes représentent les clients externes. Une flèche les relie à un encadré dans l’environnement FSI interne qui représente le conteneur principal (application principale) dans la ZAR d’application hôte. Une autre flèche relie le conteneur principal à un autre encadré représentant le conteneur auxiliaire. Une dernière flèche relie le contenant auxiliaire dans la ZAR d’application à un encadré intitulé « Application dorsale » pour illustrer le flux de données et de trafic d’un client externe qui transite par la ZAR d’application vers l’application dorsale à l’extérieur de la ZAR de l’application hôte.

Conseils

Le modèle side-car peut être mis en œuvre dans l’environnement conteneurisé d’une ZAR d’applications ou de données. L’isolation des processus provient du fait que le conteneur auxiliaire traite à la fois les flux des trafics entrant et sortant pour le conteneur principal dans l’environnement en nuage. Ce modèle est généralement mis en œuvre pour chaque conteneur principal et les conteneurs auxiliaires communiquent entre eux. Le tout est normalement géré au moyen d’un outil d’orchestration de conteneurs faisant partie du plan de contrôle du nuage. Prière de consulter la section 6 et l’annexe D pour plus de détails sur l’outil d’orchestration de conteneurs et le plan de contrôle du nuage.

6.6.2 Modèle ambassadeur

Le modèle ambassadeur permet de gérer la connectivité des données entre le conteneur principal et les composants externes. Le modèle se compose de deux conteneurs co-situés dans le même noyau du SE : un conteneur principal et un conteneur ambassadeur. Le conteneur ambassadeur fait office de mandataire et propose une vue simplifiée du conteneur principal. Il assiste le conteneur principal pour les communications avec les autres zones dans l’environnement en nuage, sur le réseau sur site ou dans la ZP. Ce modèle appartient au plan de données.

Le conteneur ambassadeur peut servir à traiter les tâches de connectivité de client courantes, comme la surveillance, la journalisation, le routage et les requêtes sur la base de données. En règle générale, on utilise ce modèle pour interfacer avec les applications patrimoniales ou en fin de vie.

Figure 9 : Modèle ambassadeur

Description détaillée - Modèle ambassadeur

La figure 9 donne un aperçu du modèle ambassadeur. Le diagramme comporte l’icône d’un gros nuage qui représente l’environnement IaaS-PaaS du FSI. À l’extérieur de l’environnement du FSI, trois personnes représentent les clients externes. Une flèche les relie à un encadré dans l’environnement FSI interne qui représente l’ambassadeur (mandataire) dans la ZAR d’application hôte. Une autre flèche relie l’encadré Ambassadeur à un autre encadré représentant le conteneur principal (application principale). Une dernière flèche relie le contenant auxiliaire dans la ZAR d’application à un encadré intitulé « Application dorsale » pour illustrer le flux de données et de trafic d’un client externe qui transite par la ZAR d’application vers l’application dorsale à l’extérieur de la ZAR de l’application hôte.

Dans le diagramme précédent, le conteneur principal est une application Web. Le conteneur ambassadeur traite toutes les demandes de service du conteneur principal et fait office de mandataire de base de données pour les bases de données externes.

Conseils

Le modèle ambassadeur devrait être mis en œuvre dans l’environnement conteneurisé d’une ZAR d’applications ou de données. L’isolation des processus est réalisée au moyen d’un mandataire traitant les flux de trafic pour le conteneur principal. Ce modèle est généralement mis en œuvre lorsque le conteneur principal doit être indépendant de la langue, prendre en charge des applications patrimoniales ou prendre en charge de nombreuses applications et bibliothèques. Cette mise en œuvre peut fournir du soutien aux services dont l’exposition aux menaces est importante. Dans un tel cas, on recommande que des mesures d’atténuation des risques appropriées soient déployées. Prière de consulter la section 4, Conseils sur l’établissement de zones dans le nuage pour plus de détails sur les mesures d’atténuation à utiliser.

6.7 Modèle avec adaptateur

Points essentiels de ce modèle

Le modèle avec adaptateur permet de fournir une vue normalisée de l’application aux entités externes. Ce modèle se compose de deux conteneurs : un conteneur principal et un conteneur adaptateur. Le conteneur principal intègre l’application principale, tandis que le conteneur adaptateur traite toutes les demandes de service entre le conteneur principal et les applications externes. Le conteneur adaptateur traite les tâches courantes, comme l’extraction des mesures relatives à l’état opérationnel des composants du plan de données (par exemple, le conteneur principal et la mise en forme des données).

Prière de consulter la Figure 10 ci-dessous pour plus de détails.

Le modèle avec adaptateur propose les avantages suivants à votre organisation :

• Segmentation des applications externes et de la ZAR d’application ou de données;
• Isolation des processus du conteneur principal par la restriction des accès;
• Restriction du trafic sortant entre le conteneur principal et les applications externes.

Figure 10 : Modèle avec adaptateur

Description détaillée - Modèle avec adaptateur

La figure 10 donne un aperçu du modèle avec adaptateur. Le diagramme comporte l’icône d’un gros nuage qui représente l’environnement IaaS-PaaS du FSI. À l’extérieur de l’environnement du FSI, trois personnes représentent les clients externes. Une flèche les relie à un encadré dans l’environnement FSI interne qui représente l’adaptateur dans la ZAR d’application hôte. Une autre flèche relie l’encadré de l’adaptateur à un autre encadré représentant le conteneur principal (application principale).

Conseils

Le modèle avec adaptateur devrait être mis en œuvre dans un réseau virtuel ou un environnement conteneurisé. Il est généralement mis en œuvre lorsqu’il est nécessaire de connecter deux composants incompatibles, comme un conteneur principal et un logiciel tiers. Le conteneur adaptateur fournit une interface au moyen de laquelle les deux composants peuvent envoyer des requêtes et recevoir des réponses particulières.

Le conteneur adaptateur peut également servir à traiter des formats de données incompatibles.

Par exemple, le client envoie une requête ne faisant pas appel au protocole HTTP à un microservice qui n’accepte que des requêtes HTTP, version 2. Le conteneur adaptateur procédera à la conversion de protocole afin de permettre la communication entre le client et le microservice. Dans un tel cas, le conteneur adaptateur fait office de passerelle d’API reliant deux composants ou deux fonctions de nature différente. Prière de consulter la section 6.9.1, Modèle avec API − passerelle d’API, pour plus de détails.

6.8 Modèle et antimodèle avec API

La présente section portera sur deux modèles avec API : le modèle avec API et l’antimodèle avec API. On abordera également deux types de modèles avec API : les points terminaux d’API et deux exemples distincts de passerelle d’API. Ces modèles fournit les fonctionnalités nécessaires pour permettre à un client d’accéder à un service et à un service de renvoyer une réponse. Il est à noter qu’il incombe à votre organisation d’assurer la sécurité et la surveillance des API déployées.

Remarque : Prière de consulter le document Modèles d’architecture axés sur l’IPA pour la PaaS du nuage public^{Notes de bas de page 12} du SCT pour plus de détails sur les modèles et antimodèles avec API.

6.9 Modèle avec API : point terminal d’API

Points essentiels de ce modèle

Un microservice doit fournir un ensemble disparate de fonctions à différents clients, comme des appareils mobiles et des stations de travail. Certaines demandes de clients exigent plus de fonctions et de ressources, comparativement à d’autres demandes. Il peut en résulter une surcharge pour le microservice. De plus, un client pourrait devoir soumettre plusieurs demandes avant de pouvoir récupérer toutes les données requises.

La solution consiste à permettre à un point terminal d’API (ou API, pour simplifier) de traiter toutes les demandes de service entre les différents types de clients et le microservice (application principale). Ce modèle, dans sa forme la plus simple, exige que l’on insère une API entre le client et le microservice. L’API peut avoir une ou plusieurs fonctions intégrées. Prière de consulter le diagramme du modèle avec point terminal d’API ci-dessous pour plus de détails.

Le modèle avec point terminal d’API propose les avantages suivants à votre organisation :

• Réduction de la surcharge du microservice – Le microservice permet à l’API de traiter toutes les connectivités de données avec le client. Il offre ses fonctionnalités de base aux clients et décharge toutes les fonctions auxiliaires à l’API;
• Isolation des processus – Il n’y a aucun accès direct au microservice, sauf au moyen de l’API. Il est, de ce fait, isolé;
• Découplage des services courants et de la logique applicative du microservice – Par exemple, les services communs, comme l’authentification, l’autorisation et la facturation, qui sont nécessaires à la gestion des interactions entre le service et le client et qui ne font pas partie de la logique applicative du microservice;
• Contrôle de l’accès – L’API peut servir à appliquer les stratégies de sécurité organisationnelles, comme les fonctions d’authentification et d’autorisation;
• Protection contre les menaces – Permet une protection contre les attaques, comme les injections SQL, les exploits d’analyseur XML (Extensible Markup Language) et les attaques par déni de service (DoS pour Denial of Service).

Figure 11 : Modèle avec API

Description détaillée - Modèle avec API

La figure 11 illustre le modèle avec API dans un diagramme. On trouve l’icône d’un gros nuage qui représente l’environnement IaaS-PaaS du FSI. À l’extérieur de l’environnement du FSI, trois personnes représentent les clients externes. Une flèche les relie à un encadré avec l’icône Engrenage à l’intérieur dans l’environnement FSI interne, qui représente le point terminal d’API dans la ZAP. Le point terminal d’API se trouve dans un encadré plus grand qui représente le service dans la ZAP. Une clé au-dessus de l’icône du point terminal d’API et du mot Authentification démontre que le point terminal est protégé et qu’il nécessite une authentification avant que l’accès au service ne soit autorisé. À l’extérieur de la boîte ZAP, mais toujours dans l’environnement IaaS-PaaS du FSI, on retrouve du texte qui se lit « HTTPS ».

Dans le diagramme ci-dessus, le point terminal d’API peut servir à exposer les fonctions d’accès et de mise à jour des données accessibles au service client. Cette API est accessible depuis la ZP au moyen du protocole HTTPS et offre des services d’identité, comme l’authentification.

Conseils

Le point terminal d’API peut être placé dans la ZAP et servir à réaliser des fonctions en périphérie pour le microservice, comme la passerelle RPV, le routage et la surveillance. L’API peut être utilisée dans des scénarios uniformisés, comme offrir une fonction particulière. Par exemple, l’API peut servir au déchiffrement TLS d’une demande de service.

6.9.1 Modèle avec API : passerelle d’API

La passerelle d’API est un modèle plus complexe que le modèle d’API. On peut y avoir recours pour traiter les cas d’utilisation qui nécessitent un ensemble varié de fonctions, comme l’autorisation, l’authentification, le routage, la surveillance et la facturation. De façon similaire à une API, une passerelle d’API fait office d’intermédiaire entre le client et le microservice. La passerelle d’API peut également servir de mandataire inverse. Prière de consulter la figure 11, Modèle avec API, ci-dessus pour plus de détails.

La passerelle d’API permet de résoudre des problèmes similaires à un modèle d’API. Elle permet également de résoudre les problèmes suivants :

1. Transformation de demande et de réponse. Par exemple, une passerelle d’API peut modifier la demande entrante et y ajouter des paramètres de chemin d’accès avant de la transmettre au microservice. De plus, la passerelle peut modifier la réponse du microservice avant de la transmettre au client, comme le ferait une passerelle, et y ajouter un message d’erreur plus générique en cas d’erreur plutôt que le message de débogage détaillé du microservice.
2. Contrôle du trafic. Une passerelle d’API peut servir à gérer le trafic vers le microservice, comme l’équilibrage de charge.

Deux mises en œuvre de passerelle d’API seront prises en considération dans la présente : la mise en œuvre monolithique et la mise en œuvre spécialisée. Certains cas d’utilisation exigent le déploiement de différentes API dans la passerelle d’API. Par exemple, une entreprise offre une application à partir d’une ZP à laquelle on peut accéder au moyen d’appareils mobiles, d’ordinateurs et d’applications utilisant des API (connexions de système à système). Dans un tel scénario, il est plus efficace d’utiliser une API spécialisée constituée de trois API que d’avoir recours à une passerelle d’API monolithique.

Voici certains problèmes traités par les passerelles d’API spécialisées :

• Scénarios uniformisés pour les passerelles d’API monolithiques – Il est plus difficile de procéder à la maintenance informatique d’une passerelle d’API monolithique, car celle-ci présente de nombreuses fonctionnalités différentes pour les divers ensembles de services offerts. Par exemple, il est beaucoup plus facile de mettre à jour une API unique dans une API spécialisée que de mettre à jour une API monolithique;
• Efficacité et performance de l’API – Chaque API de la passerelle d’API spécialisée fournit une fonctionnalité particulière. En revanche, une passerelle d’API monolithique n’est pas optimisée à des fins d’efficacité et de performance.

Figure 12 : Modèle avec passerelle d’API monolithique

Description détaillée - Monolithic API gateway pattern

La figure 12 donne un aperçu du modèle avec passerelle d’API monolithique. Le diagramme comporte l’icône d’un gros nuage qui représente l’environnement IaaS-PaaS du FSI. À l’extérieur de l’environnement du FSI, trois personnes représentent les clients externes. Une flèche les relie à un encadré dans l’environnement FSI interne qui représente la passerelle d’API à l’intérieur de la ZAP. Une autre flèche relie la ZAP et la passerelle d’API à un autre encadré représentant le microservice (application principale) à l’intérieur de la ZAR d’application.

Figure 13 : Modèle avec passerelle d’API spécialisée

Description détaillée - Modèle avec passerelle d’API spécialisée

La figure 13 illustre le modèle avec passerelle d’API spécialisée. Le diagramme comporte l’icône d’un gros nuage qui représente l’environnement IaaS-PaaS du FSI. À l’extérieur de l’environnement du FSI, on retrouve trois encadrés étiquetés : Application de bureau, Application mobile et Application système. Chacun de ces trois encadrés comporte une flèche qui les relie à trois encadrés distincts à l’intérieur de la ZAP dans l’environnement du FSI. L’encadré Application de bureau est connecté à l’encadré API de bureau. L’encadré Application mobile est connecté à l’encadré API d’appareil mobile. L’encadré Application système est connecté à l’encadré API système. On trouve à droite des trois encadrés, sous la ZAP du FSI, un autre encadré avec une ligne pointillée qui représente la ZAR d’application. L’encadré contient le microservice (application principale).

Conseils

Contrairement à un point terminal d’API, les passerelles d’API monolithiques et spécialisées peuvent être placées dans la ZAP et être utilisées pour exécuter des fonctions en périphérie, comme la vérification du trafic sortant pour le microservice. Par exemple, une passerelle d’API peut servir à exposer de façon sélective les microservices en tant qu’API aux applications client, à vérifier toutes les demandes entrantes, ainsi qu’à les authentifier ou à les autoriser.

On peut également utiliser une passerelle d’API monolithique afin de déployer une fonctionnalité de RPV pour fournir une connectivité sécurisée entre votre centre de données sur site et votre environnement en nuage, entre autres services. Une passerelle d’API spécialisée peut servir à traiter les cas d’utilisation qui nécessitent un ensemble diversifié de fonctions, comme permettre à différents types d’utilisateurs et à d’autres entités (par exemple, des appareils) d’accéder au microservice.

6.9.2 Antimodèle avec API

Points essentiels de ce modèle

Votre organisation peut décider d’utiliser un antimodèle avec API dans des cas limités exigeant une connectivité plus directe entre le client et le microservice. Par exemple, ce cas d’utilisation peut convenir dans une architecture client-serveur, comme une connectivité de données entre une application client et une application serveur. Les deux composants sont déployés dans un environnement en nuage. Le serveur est déployé dans la ZAR d’application, alors que le client réside sur un point terminal ou un ordinateur virtuel mis en place dans la ZT. On peut envisager de faire appel à un antimodèle avec API comme solution temporaire à certains problèmes. Ce modèle peut, par exemple, résoudre les problèmes de latence entre le client et le microservice, car en raison de sa conception simple, il n’est pas nécessaire de déployer un aussi grand nombre de composants ou d’appareils. Il permet également d’apparier les composants logiciels. Il est important de noter que, lorsque cela s’avère possible, il est préférable d’utiliser un modèle avec API, plutôt qu’un antimodèle avec API. Pour plus de détails, prière de consulter la figure 14, Antimodèle avec API (exemple 1), et la figure 15, Antimodèle avec API (exemple 2), ci-dessous.

Figure 14 : Antimodèle avec API (exemple 1)

Description détaillée - Antimodèle avec API (exemple 1)

La figure 14 illustre un exemple de l’antimodèle avec API. À l’extérieur de l’environnement du FSI, trois personnes représentent les clients externes. Une flèche les relie à un encadré dans l’environnement interne IaaS-PaaS du FSI qui représente la ZT où se trouve l’application cliente. Une autre flèche relie l’encadré ZT à un autre encadré représentant la ZAR d’application qui contient l’application serveur.

L’exemple ci-dessus illustre une connectivité directe entre le client et le serveur (microservice). Les données sont regroupées en lot et transférées au moyen de l’utilitaire SCP. L’adoption de ce type de déploiement comme solution d’entreprise pose certains défis. On recommande de déployer une solution basée sur les API pour fournir des données en temps quasi réel. Par exemple, les services communs, comme l’authentification, l’autorisation et la facturation, font rarement l’objet d’une normalisation et doivent être intégrés à des services individuels au moyen de ce type de modèle.

Figure 15 : Antimodèle avec API (exemple 2)

Description détaillée - Antimodèle avec API (exemple 2)

La figure 15 illustre un autre exemple de l’antimodèle avec API. À l’extérieur de l’environnement du FSI, trois personnes représentent les clients externes. Une flèche les relie à un encadré dans l’environnement interne IaaS-PaaS du FSI qui représente la ZT où se trouve l’application cliente. Il y a trois flèches pointant de l’encadré Application cliente de la ZT vers trois encadrés distincts. La première flèche relie l’application cliente de la ZT au Service A, qui contient la facturation et la surveillance. La deuxième flèche relie l’application cliente de la ZT au Service B, qui contient l’authentification, l’autorisation et la facturation. La troisième flèche relie l’application cliente de la ZT au Service C, qui contient l’authentification et la surveillance. Ces trois flèches ont l’icône Globe terrestre avec une serrure au centre pour représenter une connexion sécurisée de la ZT aux Services A, B et C.

Dans l’exemple ci-dessus, le client communique avec chaque service individuellement. Chaque service peut exiger qu’on y intègre des services communs, comme des services organisationnels et de sécurité. On peut également demander au client d’accéder aux services individuels en utilisant des localisateurs de ressources uniformes (URL pour Unique Resource Locator) différents.

Conseils

Le client et le microservice sont placés dans des zones réseau différentes. Par exemple, le microservice est placé dans la ZAR de données et le client dans la ZT.

On peut avoir recours à des NACL et à des NSG afin de restreindre l’accès aux composants utilisant l’antimodèle avec API. Il convient de tirer avantage des capacités de sécurité supplémentaires, comme la sensibilité au contexte et un contrôle de l’accès plus précis, pour restreindre davantage le client et le microservice. Dans la mesure du possible, il est préférable d’utiliser un modèle avec API approprié, plutôt qu’un antimodèle avec API.

7 Contenu complémentaire

Annexe A : Exigences de sécurité et PIZ en nuage

Le document ITSP.80.022, Exigences de base en matière de sécurité pour les zones de sécurité de réseau − Annexe F : Point d’interface de zone, contient un ensemble d’objectifs regroupés en fonction des activités de contrôle du trafic, de l’intégrité et de la disponibilité du réseau, et de la protection des données. Une série d’exigences de base en matière de sécurité sont définies pour le PIZ à partir de ces objectifs de sécurité.

Le tableau ci-dessous illustre la mise en correspondance des objectifs et exigences de sécurité tirés de l’ITSP.80.022 avec les constructions du PIZ en nuage définies précédemment. Il est recommandé de consulter l’ITSP.80.022 pour connaître la définition détaillée associée au numéro d’exigence et au contrôle de sécurité connexe de l’ITSG-33. Il est important pour votre organisation de bien comprendre les situations où il convient de mettre en place un PIZ particulier en fonction des exigences de sécurité de ce qui est protégé et de la stratégie de sécurité organisationnelle.

Tableau 3 : Mise en correspondance des exigences de base et des PIZ en nuage

Annexe B : Accès aux charges de travail du nuage et cas d’utilisation

La présente section propose plus de détails sur les concepts évoqués à la section 4, comme le modèle de réseau en étoile. Elle fournit également quelques cas d’utilisation courants liés à l’accès aux charges de travail en nuage hébergées dans les IaaS et les PaaS du FSI selon le modèle de réseau en étoile.

Le diagramme ci-dessous présente ce qui suit :

• une utilisatrice ou un utilisateur de l’organisation accédant au réseau sur site par l’intermédiaire d’un RPV;
• une utilisatrice ou un utilisateur de l’organisation, l’administratrice ou l’administrateur de système et l’API interne accédant aux charges de travail du nuage à partir d’un réseau sur site;
• une utilisatrice ou un utilisateur externe et les API externes accédant aux charges de travail du nuage depuis la ZP.

Les charges de travail du nuage peuvent également accéder aux charges de travail du réseau sur site afin de terminer les demandes de services de l’utilisatrice ou l’utilisateur externe et de l’API. Prière de consulter le tableau 4, Accès aux charges de travail du nuage et cas d’utilisation, pour plus de détails sur les cinq cas d’utilisation illustrés dans le diagramme.

Figure 16 : Accès aux charges de travail du nuage et cas d’utilisation

Description détaillée - Accès aux charges de travail du nuage et cas d’utilisation

La figure 16 illustre un cas d’utilisation courante pour accéder aux charges de travail du nuage. L’icône de trois personnes représentant les clients externes se trouve dans le haut du diagramme. Une flèche les relie à l’icône de petit nuage représentant la ZP. À partir du nuage de la ZP, trois flèches distinctes mènent à trois environnements en nuage distincts.

La première flèche relie la ZP à l’environnement IaaS du FSI, qui est décrit en bleu par deux icônes de globe terrestre avec des serrures indiquant qu’il s’agit d’une zone sécurisée avec des connexions sécurisées à la ZP. Dans l’environnement IaaS du FSI, quatre encadrés avec une ligne pointillée représentent le concentrateur, le rayon de ZT, le rayon de ZAR et un autre rayon de ZAR. Une deuxième flèche relie l’IaaS du FSI au WAN, représenté par l’icône d’un petit nuage, pour illustrer le flux de trafic.

La deuxième flèche relie la ZP à l’environnement SaaS du FSI. Il est représenté sous forme d’icône Nuage à l’intérieur d’un encadré. Une flèche relie l’environnement SaaS au WAN. Les deux flèches comportent des icônes de globe terrestre avec des serrures pour représenter les connexions sécurisées.

La troisième flèche relie la ZP à l’environnement PaaS du FSI qui est représenté par l’icône Nuage comportant trois encadrés à l’intérieur. Les trois encadrés représentent le concentrateur, le rayon d’API et le rayon des services de sécurité. Une flèche relie l’environnement SaaS au WAN.

Depuis le WAN, le trafic peut circuler de deux façons. La première se fait par l’intermédiaire d’un pare-feu jusqu’à la succursale, qui est représentée par une icône Immeuble. La deuxième est le pare-feu du bureau principal de l’utilisateur organisationnel, qui est représenté par une icône Gratte-ciel. Le trafic passera ensuite de la succursale à l’utilisateur organisationnel, qui est représenté par l’icône d’une personne.

Les deux connexions dédiées du CXP vers les services IaaS et PaaS de FSI établies à partir du réseau étendu peuvent provenir du même fournisseur ou de fournisseurs différents. Le CASB peut servir de mandataire inverse et appliquer la stratégie de sécurité de votre organisation, comme l’authentification, l’autorisation et l’authentification unique. De plus, il est possible d’utiliser une connexion dédiée du CXP pour se connecter à un FSI (non illustré dans le diagramme ci-dessus) en fonction de la stratégie de sécurité de votre organisation.

Tableau 4 : Accès aux charges de travail du nuage et cas d’utilisation

Référence

Cas d’utilisation

A1

Un utilisateur de l’organisation accède au réseau sur site par l’intermédiaire d’un RPV à partir de la ZP. L’utilisateur, après avoir été authentifié et autorisé, peut accéder aux charges de travail du nuage IaaS et PaaS à partir du réseau sur site. Le même flux de trafic s’applique aux autres utilisatrices et utilisateurs situés sur le réseau sur site des deux succursales du bureau principal en ce qui a trait à l’accès aux charges de travail du nuage basées sur les privilèges accordés par votre organisation. Tous les flux de trafic sont sécurisés.

A2

L’administrateur de système accède aux environnements en nuages IaaS et PaaS à partir du réseau sur site pour réaliser des tâches de gestion.

A3

Une utilisatrice externe accède aux charges de travail du nuage IaaS et PaaS à partir de la ZP. À l’occasion, les charges de travail du nuage accéderont aux charges de travail sur site hébergées depuis une succursale ou le bureau principal afin de répondre à des demandes de service (selon les exigences opérationnelles relatives aux charges de travail du nuage ou les stratégies de sécurité de votre organisation). Cela est illustré par la ligne bleue pointillée allant des composants IaaS et PaaS jusqu’au WAN, puis vers le bureau principal et les deux succursales.

A4

L’interface API interne accède aux charges de travail du nuage à partir du réseau sur site. Elle est utilisée pour accéder aux services et aux données de l’organisation. Tous les flux de trafic de l’interface API sont sécurisés.

A5

L’interface API externe accède aux charges de travail du nuage à partir de la ZP. Elle est utilisée pour accéder aux services et aux données de l’organisation. À l’occasion, les charges de travail du nuage se connecteront aux charges de travail sur site hébergées depuis une succursale ou le bureau principal afin de répondre à des demandes de service (selon les exigences opérationnelles des charges de travail du nuage ou des stratégies de sécurité de votre organisation). Cela est illustré par la ligne verte pointillée allant des composants IaaS et PaaS jusqu’au WAN, puis vers le bureau principal et les deux succursales.

Annexe C : Exemples de modèle de réseau en étoile

La présente section donne quelques exemples du modèle de réseau en étoile qu’il est possible de mettre en œuvre dans l’environnement en nuage de votre organisation. Ces modèles sont répertoriés selon un ordre de complexité croissant.

Le modèle de réseau en étoile se compose de deux rayons distincts où sont hébergés vos environnements de test et de développement. Il n’y a aucune connectivité directe entre les deux rayons (environnements), sauf par l’intermédiaire du concentrateur. Le concentrateur héberge les services communs et offre une connectivité externe vers le réseau sur site et la ZP.

Figure 17 : Un exemple de modèle de réseau en étoile

Description détaillée - Un exemple de modèle de réseau en étoile

La figure 17 présente un exemple de modèle de réseau en étoile. Les lettres FSI apparaissent dans le coin supérieur gauche d’un grand encadré gris. Cela représente l’environnement du FSI. En haut du diagramme, dans l’environnement du FSI, une icône Globe terrestre représente le réseau sur site. Il y a aussi une icône de nuage plus petit qui représente la ZP. Les icônes Sur site et ZP comportent des flèches qui les relient au concentrateur interne du FSI, représenté par une case. À l’intérieur du concentrateur se trouvent deux icônes représentant les charges de travail et les services communs. L’icône des charges de travail est reliée par une flèche à un encadré avec une ligne pointillée représentant l’environnement de test. On trouve dans l’encadré d’environnement de test deux icônes représentant deux VM distinctes, lesquelles représentent les charges de travail. Une flèche relie l’encadré des services communs, par l’intermédiaire de l’appairage de réseau virtuel, à l’environnement de développement, qui est représenté par un encadré avec une ligne pointillée. Dans l’environnement de développement, deux icônes représentent deux VM distinctes, qui représentent les charges de travail. Les encadrés de l’environnement de test et de l’environnement de développement sont reliés par une flèche avec un X au centre pour représenter le rayon.

Le prochain exemple consiste en un modèle de réseau en étoile hébergeant un environnement de préproduction et un environnement de production. Les deux environnements sont similaires, à l’exception que le premier est entièrement redondant. Un NSG permet de restreindre l’accès entre les différentes zones de sécurité au sein de chaque rayon. Comme dans l’exemple précédent, il n’y a aucune connectivité directe entre les deux rayons, sauf par l’intermédiaire du concentrateur. Le concentrateur offre une connectivité externe vers la ZP et le réseau local en fonction des exigences de sécurité de votre organisation. On retrouve des niveaux Web, d’application et de base de données dans chaque rayon.

Des restrictions sont également appliquées au trafic entre les trois niveaux au moyen du NSG. Le niveau de base de données n’est accessible qu’à partir du niveau d’application, alors qu’il existe une connectivité directe entre les niveaux Web et d’application. Une mise en œuvre au niveau de la base de données est un exemple robuste de modèle avec enclave de données.

Figure 18 : Deuxième exemple de modèle de réseau en étoile

Description détaillée - Deuxième exemple de modèle de réseau en étoile

La figure 18 donne un autre exemple du modèle de réseau en étoile. Les lettres FSI apparaissent dans le coin supérieur gauche d’un grand encadré gris qui représente l’environnement du FSI. L’encadré gris contient un deuxième encadré contenant les éléments du modèle de réseau en étoile. Un petit encadré représentant le concentrateur se trouve en haut du diagramme. Dans le concentrateur, on trouve les services communs, représentés par une icône Outils. Le concentrateur et les services communs sont protégés par un pare-feu. Le concentrateur permet au trafic de circuler dans toutes les directions à travers le pare-feu, le tout représenté par l’icône de quatre flèches pointant dans chaque direction.

Le concentrateur est relié à deux encadrés supplémentaires avec des lignes pointillées, les mots « Environnement de préproduction » dans un encadré et « Environnement de production » dans l’autre, représentant deux rayons distincts.

Le premier encadré du rayon contient trois couches distinctes représentant les ZAR1, ZAR2 et ZAR3. Dans la couche ZAR1, on trouve l’icône d’un serveur avec un globe terrestre pour représenter le niveau Web et l’icône d’un badge de sécurité représentant le NSG.

Dans la couche ZAR2, on trouve l’icône d’un serveur avec un nuage derrière pour représenter le niveau application, ainsi que l’icône d’un badge de sécurité représentant le NSG. Le niveau Web dans la ZAR1 et le niveau application dans la ZAR2 sont connectés par une flèche.

Dans la couche ZAR3, on trouve l’icône d’une base de données et l’icône d’un badge de sécurité représentant le NSG. Le niveau application dans la ZAR2 est connecté à la base de données dans la ZAR3 par une flèche.

Le deuxième rayon comporte également trois niveaux : ZAR1, ZAR2 et ZAR3. Dans la couche ZAR1, deux icônes d’un serveur avec un globe terrestre représentent le serveur Web et l’icône d’un badge de sécurité représentant le NSG.

Dans la couche ZAR2, deux icônes d’un serveur avec un nuage derrière représentent le niveau application, ainsi que l’icône d’un badge de sécurité représentant le NSG. Les niveaux Web dans la ZAR1 et les niveaux application dans la ZAR2 sont connectés par une flèche.

Dans la couche ZAR3, on trouve deux icônes de bases de données et l’icône de badge de sécurité représentant le NSG. Les niveaux application dans la ZAR2 sont connectés aux bases de données dans la ZAR3 par une flèche.

Le modèle de réseau en étoile suivant se compose de trois rayons, d’une zone de travail, d’un environnement de production et d’un environnement de préproduction. Le modèle est similaire à l’exemple précédent, à l’exception de la ZT, qui offre une connectivité directe aux deux environnements. Il n’y a aucune connectivité directe entre les deux environnements (préproduction et production). La ZT héberge des ordinateurs virtuels qu’il est possible de mettre en place de façon dynamique (sur demande) ou statique selon les besoins opérationnels de votre organisation.

Le concentrateur offre une connectivité externe vers la ZP et le réseau local en fonction des exigences de sécurité de votre organisation.

Figure 19 : Troisième exemple de modèle de réseau en étoile

Description détaillée - Troisième exemple de modèle de réseau en étoile

La figure 19 présente un troisième exemple de modèle de réseau en étoile. Les lettres FSI apparaissent dans le coin supérieur gauche d’un grand encadré gris qui représente l’environnement du FSI. L’encadré gris contient un deuxième encadré contenant les éléments du modèle de réseau en étoile. On trouve dans le haut du diagramme l’icône Globe terrestre avec une flèche pointant vers son centre, qui représente les portails Web. Une flèche relie le portail Web au concentrateur, qui est représenté par un encadré.

Dans le concentrateur, on trouve les services communs, représentés par une icône Outils. Le concentrateur et les services communs sont protégés par un pare-feu. Le concentrateur permet au trafic de circuler dans toutes les directions à travers le pare-feu, le tout représenté par l’icône de quatre flèches pointant dans chaque direction.

Le concentrateur est relié à trois encadrés supplémentaires avec des lignes pointillées. Les mots « Zone de travail » apparaissent dans le premier encadré, « Environnement de préproduction » dans le deuxième encadré et « Environnement de production » dans le troisième encadré, représentant trois rayons distincts.

Le premier encadré du rayon comporte trois couches distinctes, chacune avec une icône représentant une étape du flux. La première icône de la première couche est un badge de sécurité qui représente le NSG. La deuxième icône des deuxième et troisième couches contient l’icône Écran d’ordinateur avec un cube au centre pour représenter deux VM distinctes.

Le deuxième encadré du rayon contient trois couches distinctes représentant les ZAR1, ZAR2 et ZAR3. Dans la couche ZAR1, on trouve l’icône d’un serveur avec un globe terrestre pour représenter le niveau Web et l’icône d’un badge de sécurité représentant le NSG.

Dans la couche ZAR2, on trouve l’icône d’un serveur avec un nuage derrière pour représenter le niveau application, ainsi que l’icône d’un badge de sécurité représentant le NSG. Le niveau Web dans la ZAR1 et le niveau application dans la ZAR2 sont connectés par une flèche.

Dans la couche ZAR3, on trouve l’icône d’une base de données et l’icône d’un badge de sécurité représentant le NSG. Le niveau application dans la ZAR2 est connecté à la base de données dans la ZAR3 par une flèche.

Le troisième rayon comporte également trois niveaux : ZAR1, ZAR2 et ZAR3. Dans la couche ZAR1, deux icônes d’un serveur avec un globe terrestre représentent le serveur Web et l’icône d’un badge de sécurité représentant le NSG.

Dans la couche ZAR2, deux icônes d’un serveur avec un nuage derrière représentent le niveau application, ainsi que l’icône d’un badge de sécurité représentant le NSG. Les niveaux Web dans la ZAR1 et les niveaux application dans la ZAR2 sont connectés par une flèche.

Dans la couche ZAR3, on trouve deux icônes de bases de données et l’icône de badge de sécurité représentant le NSG. Les niveaux application dans la ZAR2 sont connectés aux bases de données dans la ZAR3 par une flèche.

Annexe D : Passerelles d’API, services d’API et conteneurs

Le diagramme de la présente section (figure 20 ci-dessous) offre un exemple de passerelle d’API et de différents types de services déployés, comme des services de conteneurs, d’application et d’API. Ces services sont déployés sur deux sous-réseaux privés d’IaaS et de PaaS. Les services offerts par les composants d’IaaS et de PaaS peuvent communiquer entre eux. On retrouve également une connectivité entre les composantes d’IaaS et de PaaS.

Un pare-feu, comme un WAF, et une passerelle d’API sont déployés sur un concentrateur qui offre une connectivité externe vers la ZP et le réseau sur site. On peut utiliser le WAF pour filtrer le trafic malveillant qui transite vers les services des deux rayons. La passerelle d’API fait office de mandataire inverse et peut offrir des services, comme l’authentification et l’autorisation.

Figure 20 : Exemple de passerelles d’API, de services API et de conteneurs

Description détaillée - Exemple de passerelles d’API, de services API et de conteneurs

La figure 20 présente un exemple de passerelles d’API, de services API et de conteneurs. Elle donne un exemple de passerelle d’API et de différents types de services déployés. Ces services sont déployés sur deux sous-réseaux privés d’IaaS et de PaaS.

Le diagramme comporte un grand encadré gris avec les lettres FSI dans le coin supérieur gauche pour représenter l’environnement du FSI. On trouve dans le haut du diagramme l’icône Globe terrestre sur le côté gauche représentant le réseau sur site. Une ligne avec des flèches relie le réseau sur site à l’icône Globe terrestre avec une serrure pour représenter une connexion sécurisée. La ligne se connecte ensuite à l’icône Mur de briques avec une flamme représentant le pare-feu. À droite, trois personnes représentent les clients externes. Une ligne avec une flèche relie les clients externes à l’icône Nuage représentant la ZP. Une autre ligne relie la ZP à l’icône de connexion sécurisée et se rend jusqu’à l’icône Pare-feu.

L’encadré gris comprend également un autre encadré pour représenter une zone. L’icône Pare-feu se trouve dans le haut de cet encadré et se connecte à un petit rectangle représentant le concentrateur. Le concentrateur comporte une icône avec deux portes représentant la passerelle API, ainsi que la liste des services suivants :

• Authentification
• Autorisation
• Déchiffrement TLS
• Routage
• Mandataire inverse
• Mise en cache
• Surveillance
• Facturation

L’encadré du concentrateur se connecte à deux sous-réseaux privés IaaS et PaaS, représentés par deux encadrés distincts. L’encadré IaaS comporte trois icônes avec des flèches orientées verticalement. La première icône est un engrenage et représente le rayon A (service d’API). Elle se connecte à la deuxième icône (ordinateur portable) qui représente le rayon B (application Web). La troisième icône est un panneau sur un crochet représentant le rayon C (conteneur).

L’encadré PaaS comporte également trois icônes. Les flèches sont également orientées verticalement. La première icône est la même icône de conteneur que celle utilisée dans l’encadré IaaS et elle représente le rayon D. La deuxième icône est un ordinateur portable représentant le rayon E (application Web). La troisième icône est la même que les deux conteneurs précédents et représente le rayon F.

Une flèche relie les encadrés IaaS et PaaS pour démontrer la connectivité entre les deux sous-réseaux privés.

Le diagramme ci-dessous illustre la différence entre le placement du plan de contrôle et du plan de données. Comme mentionné plus tôt, l’outil d’orchestration de conteneurs fait partie du plan de contrôle. Les deux conteneurs ou applications font partie du plan de données. Tous le flux de trafic entre le plan de contrôle et les applications du plan de données transitent par les mandataires. Les flux de trafic entre les deux applications sont sécurisés. Par ailleurs, tous les flux de trafic entre le plan de contrôle, le plan de données et les applications sont sécurisés.

Figure 21 : Relation entre les plans de contrôle et de données

Description détaillée - Relation entre les plans de contrôle et de données

La figure 21 montre la relation entre le plan de contrôle et le plan de données. Au haut du diagramme, on retrouve un encadré représentant le plan de contrôle. Il y a une ligne pointillée sous l’encadré. On trouve également sous la ligne pointillée un encadré représentant le plan de données. Deux lignes avec des flèches vont du plan de contrôle, au-dessus de la ligne pointillée, au plan de données. L’une de ces lignes se connecte à un encadré gris du côté gauche du diagramme, représentant une application. L’application contient une icône représentant l’Application 1 et une autre icône d’un serveur représentant son mandataire. La deuxième ligne se connecte à un encadré gris semblable du côté droit du diagramme, représentant une autre application. Cet encadré gris contient une icône représentant l’Application 2 et une icône d’un serveur représentant son mandataire. Une ligne avec des flèches à chaque extrémité relie les deux mandataires d’application. Au centre de la ligne, un cadenas indique que tout le trafic circule de façon sécurisée entre les deux mandataires.