Documentation sur Oracle Cloud Infrastructure

Groupes de sécurité de réseau

Le service Réseau offre deux fonctions de pare-feu virtuel pour contrôler le trafic au niveau du paquet :

  • Groupes de sécurité de réseau : Décrits dans cette rubrique. Les groupes de sécurité de réseau sont pris en charge uniquement pour des services spécifiques.
  • Listes de sécurité : Type de pare-feu virtuel d'origine proposé par le service de réseau. Voir Listes de sécurité.

Ces deux fonctions utilisent des règles de sécurité. Pour des informations importantes sur le fonctionnement des règles de sécurité et une comparaison générale des listes de sécurité et des groupes de sécurité de réseau, voir Règles de sécurité.

Note

Vous pouvez utiliser le routage de paquets avec confiance zéro (ZPR) avec ou à la place de groupes de sécurité de réseau pour contrôler l'accès au réseau aux ressources OCI en leur appliquant des attributs de sécurité et en créant des politiques ZPR pour contrôler la communication entre elles. Pour plus d'informations, voir Routage de paquets Zéro confiance.
Attention

Si un point d'extrémité a un attribut de sécurité ZPR, le trafic vers le point d'extrémité doit satisfaire aux règles ZPR ainsi qu'à toutes les règles de groupe de sécurité de réseau et de liste de sécurité. Par exemple, si vous utilisez déjà des groupes de sécurité de réseau et que vous appliquez un attribut de sécurité à un point d'extrémité, dès que l'attribut est appliqué, tout le trafic vers le point d'extrémité est bloqué. À partir de là, une politique ZPR doit autoriser le trafic vers le point d'extrémité.

Points saillants

  • Les groupes de sécurité de réseau (NSG) agissent comme un pare-feu virtuel pour les instances de calcul et d'autres types de ressources. Un groupe NSG est composé d'un jeu de règles de sécurité entrantes et sortantes qui s'appliquent uniquement à un jeu de cartes vNIC dans un seul réseau VCN (par exemple, toutes les instances de calcul qui servent de serveurs Web dans le niveau Web d'une application multiniveau dans un réseau VCN).
  • Par rapport aux listes de sécurité, les groupes NSG vous permettent de séparer l'architecture de sous-réseau d'un réseau VCN des exigences de sécurité de l'application. Voir Comparaison des listes de sécurité et des groupes de sécurité de réseau.
  • Vous pouvez utiliser des groupes de sécurité de réseau (NSG) avec certains types de ressource. Pour plus d'informations, voir Prise en charge des groupes de sécurité de réseau.
  • Les règles de sécurité de groupe NSG fonctionnent comme des règles de liste de sécurité. Cependant, pour la source (des règles de trafic entrant) ou la destination (des règles de trafic sortant) d'une règle de sécurité de groupe NSG, vous pouvez spécifier un groupe NSG au lieu d'un bloc CIDR. Vous pouvez donc facilement écrire des règles de sécurité pour contrôler le trafic entre deux groupes NSG du même réseau VCN ou au sein d'un seul groupe de sécurité. Voir Parties d'une règle de sécurité.
  • Contrairement aux listes de sécurité, le réseau VCN ne dispose pas de groupe NSG par défaut. Par ailleurs, chaque groupe NSG que vous créez est vide au départ. Il n'a aucune règle de sécurité par défaut.
  • Les limites des groupes de sécurité de réseau sont distinctes et différentes de celles des listes de sécurité. Voir Limites de liste de sécurité.

Prise en charge des groupes de sécurité de réseau

Il est possible de créer et d'utiliser des groupes de sécurité. Cependant, ils ne sont pas encore pris en charge par tous les services Oracle Cloud Infrastructure pertinents.

Les types de ressource parent suivants prennent en charge l'utilisation de groupes NSG :

  • Service de récupération autonome (sous-réseaux pour le service de récupération) : Lorsque vous enregistrez un sous-réseau de service de récupération, vous pouvez associer un ou plusieurs groupes NSG (cinq au maximum) qui contiennent les règles de trafic entrant pour le service de récupération.
  • Instances de calcul : Lorsque vous créez une instance, vous pouvez spécifier un ou plusieurs groupes NSG pour sa carte vNIC principale. Si vous ajoutez une carte vNIC secondaire à une instance, vous pouvez spécifier un ou plusieurs groupes NSG pour cette carte. Vous pouvez également mettre à jour des cartes vNIC sur une instance afin qu'elles se trouvent dans un ou plusieurs NSG.
  • Équilibreurs de charge : Lorsque vous créez un équilibreur de charge, vous pouvez lui spécifier un ou plusieurs groupes NSG (et non pour le jeu dorsal). Vous pouvez également mettre à jour un équilibreur de charge pour qu'il utilise un ou plusieurs groupes NSG.
  • Systèmes de base de données : Lorsque vous créez un système de base de données, vous pouvez spécifier un ou plusieurs groupes NSG. Vous pouvez également mettre à jour un système de base de données pour qu'il utilise un ou plusieurs groupes NSG.
  • Bases de données autonomes : Lorsque vous créez une base de données Autonomous Database sur une infrastructure Exadata dédiée, vous pouvez spécifier un ou plusieurs groupes de sécurité de réseau pour la ressource d'infrastructure.
  • Cibles de montage : Lorsque vous créez une cible de montage pour un système de fichiers, vous pouvez spécifier un ou plusieurs groupes NSG. Vous pouvez également mettre à jour une cible de montage pour qu'elle utilise un ou plusieurs groupes NSG.
  • Point d'extrémité de résolveur DNS : Lorsque vous créez un point d'extrémité pour un résolveur DNS privé, vous pouvez spécifier un ou plusieurs groupes de sécurité de réseau. Vous pouvez également mettre à jour un point d'extrémité pour qu'il utilise un ou plusieurs groupes NSG.
  • Grappes Kubernetes : Lorsque vous créez une grappe Kubernetes à l'aide du moteur Kubernetes, vous pouvez spécifier un ou plusieurs groupes de sécurité de réseau pour contrôler l'accès au point d'extrémité de l'API Kubernetes et aux noeuds de travail. Vous pouvez également spécifier des groupes de sécurité de réseau lors de la définition d'un équilibreur de charge pour une grappe.
  • Passerelles d'API : Lorsque vous créez une passerelle d'API, vous pouvez spécifier un ou plusieurs groupes NSG pour contrôler l'accès à la passerelle d'API.
  • Fonctions : Lorsque vous configurez une application dans le service Fonctions pour OCI, vous pouvez spécifier un ou plusieurs groupes NSG pour définir des règles de trafic entrant et sortant qui s'appliquent à toutes les fonctions de cette application.
  • Déploiements GoldenGate : Lorsque vous créez un déploiement GoldenGate, vous pouvez spécifier un ou plusieurs groupes NSG pour contrôler l'accès au déploiement.
  • Redis clusters : Lorsque vous créez une grappe Redis, vous pouvez spécifier un ou plusieurs groupes NSG pour contrôler l'accès à la grappe Redis. Vous pouvez également mettre à jour une grappe pour qu'elle utilise un ou plusieurs groupes NSG

Pour les types de ressource qui ne prennent pas encore en charge de groupes NSG, continuez d'utiliser des listes de sécurité pour contrôler le trafic entrant et sortant de ces ressources parents.

Aperçu des groupes de sécurité de réseau

Un groupe de sécurité de réseau (NSG) fournit un pare-feu virtuel pour un jeu de ressources en nuage dont la situation en matière de sécurité est identique. Par exemple, un groupe d'instances de calcul qui exécutent toutes les mêmes tâches et qui doivent donc utiliser le même jeu de ports.

Un groupe de sécurité de réseau est composé de deux types d'élément :

  • Cartes vNIC : Une ou plusieurs cartes (par exemple, les cartes associées au jeu d'instances de calcul ayant la même situation en matière de sécurité). Toutes les cartes vNIC doivent figurer dans le même réseau VCN que le groupe NSG. Voir aussi Comparaison des listes de sécurité et des groupes de sécurité de réseau.
  • Règles de sécurité : Règles de sécurité du groupe NSG qui définissent les types de trafic autorisés à entrer et à sortir des cartes vNIC du groupe. Par exemple :Trafic SSH du port TCP 22 entrant depuis une source particulière.

Si vous avez des ressources avec des postures de sécurité différentes dans le même réseau VCN, vous pouvez écrire des règles de sécurité NSG pour contrôler le trafic entre les ressources d'une situation par rapport à une autre. Par exemple, dans le diagramme suivant, NSG1 a des cartes vNIC qui s'exécutent sur un niveau d'application à plusieurs niveaux. NSG2 a des cartes vNIC s'exécutant sur un deuxième niveau. Les deux groupes NSG doivent appartenir au même réseau VCN. L'hypothèse est que les deux groupes NSG doivent démarrer des connexions à l'autre.

Pour NSG1, vous configurez des règles de sécurité de trafic sortant qui spécifient NSG2 comme destination, et des règles de sécurité de trafic entrant qui spécifient NSG2 comme source. De même pour NSG2, vous configurez des règles de sécurité de trafic sortant qui spécifient NSG1 comme destination, et des règles de sécurité de trafic entrant qui spécifient NSG1 comme source. Cet exemple suppose que les règles sont avec état.

Vous pouvez configurer des règles de sécurité pour contrôler le trafic entre deux groupes de sécurité de réseau.

Le diagramme précédent suppose que chaque NSG doit démarrer des connexions à l'autre.

Le diagramme suivant suppose que vous souhaitez autoriser uniquement les connexions démarrées par NSG1 vers NSG2. Pour ce faire, supprimez la règle de trafic entrant de NSG1 et la règle de trafic sortant de NSG2. Les autres règles n'autorisent pas les connexions démarrées de NSG2 à NSG1.

Ces règles de sécurité permettent les connexions démarrées dans une seule direction : de NSG1 à NSG2.

Le diagramme suivant suppose que vous voulez contrôler le trafic entre cartes vNIC du même groupe NSG. Pour cela, définissez comme source (pour le tarif entrant) ou comme destination (pour le trafic sortant) de la règle le propre groupe NSG de celle-ci.

Vous pouvez configurer des règles de sécurité pour contrôler le trafic entre des cartes vNIC du groupe NSG.

Une carte vNIC peut se trouver dans cinq groupes NSG au maximum. Un paquet est autorisé si une règle des groupes NSG de la carte vNIC permet le trafic (ou si le trafic fait partie d'une connexion faisant l'objet d'un suivi), à moins que les listes contiennent à la fois des règles de sécurité avec état et sans état qui couvrent le même trafic. Pour plus d'informations, voir Comparaison de l'état aux règles sans état.

Les groupes de sécurité de réseau sont des entités régionales. Pour connaître les limites associées aux groupes de sécurité de réseau, voir Comparaison des listes de sécurité et des groupes de sécurité de réseau.

Pour plus d'informations sur les limites, voir Limites de groupe de sécurité de réseau et Demande d'une augmentation de limite de service.

Utilisation de l'API

Pour plus d'informations sur l'utilisation de l'API et sur les demandes de signature, voir la documentation de l'API REST et Données d'identification de sécurité. Pour plus d'informations sur les trousses SDK, voir Trousses SDK et interface de ligne de commande.

Pour plus d'informations sur l'utilisation de l'API et sur les demandes de signature, voir la documentation de l'API REST et Données d'identification de sécurité. Pour plus d'informations sur les trousses SDK, voir Trousses SDK et interface de ligne de commande.

Différences entre le modèle d'API REST pour les groupes NSG et les listes de sécurité :

  • Les listes de sécurité ont un objet IngressSecurityRule et un objet EgressSecurityRule distinct. Les groupes de sécurité de réseau n'ont qu'un objet SecurityRule et l'attribut direction de l'objet indique si la règle concerne le trafic entrant ou sortant.
  • Dans le cas des listes de sécurité, les règles font partie de l'objet SecurityList et, pour les utiliser, vous appelez les opérations de la liste de sécurité (comme UpdateSecurityList). Dans le cas des groupes NSG, les règles ne font pas partie de l'objet NetworkSecurityGroup. Vous utilisez plutôt des opérations distinctes pour utiliser les règles d'un groupe NSG particulier (exemple : UpdateNetworkSecurityGroupSecurityRules).
  • Le modèle pour la mise à jour de règles de sécurité existantes est différent entre les listes de sécurité et les groupes NSG. Chaque règle d'un groupe NSG particulier a un identificateur unique affecté par Oracle (par exemple, 04ABEC). Lorsque vous appelez UpdateNetworkSecurityGroupSecurityRules, vous fournissez les ID des règles spécifiques à mettre à jour. Pour la comparaison, avec les listes de sécurité, les règles n'ont pas d'identificateur unique. Lorsque vous appelez UpdateSecurityList, vous devez transmettre la liste complète des règles, y compris les règles qui ne sont pas mises à jour lors de l'appel.
  • La limite est de 25 règles lors de l'appel des opérations d'ajout, de suppression ou de mise à jour.

Utilisation de groupes de sécurité de réseau

Processus général d'utilisation des groupes de sécurité de réseau

  1. Créez un groupe NSG.
  2. Ajoutez-lui des règles de sécurité.
  3. Ajoutez au groupe de sécurité de réseau des ressources parents (telles que des cartes vNIC). Vous pouvez effectuer cette opération lorsque vous créez la ressource parent ou vous pouvez mettre à jour la ressource parent et l'ajouter à au moins un groupe de sécurité de réseau. Lorsque vous créez une instance de calcul et que vous l' ajoutez à un groupe NSG, la carte VNIC principale de l'instance l'est également. Par ailleurs, vous pouvez créer des cartes vNIC secondaires et, si nécessaire, les ajouter aux groupes NSG.

Suppression de groupes NSG

Pour supprimer un groupe NSG, il ne doit pas contenir de carte vNIC ou de ressource parent. Lorsqu'une ressource parent (ou une carte VNIC d'instance de calcul) est supprimée, elle est automatiquement retirée des groupes NSG où elle figurait. Vous n'êtes peut-être pas autorisé à supprimer une ressource parent particulière. Communiquez avec l'administrateur de la location pour déterminer qui est responsable d'une ressource particulière.

Politique GIA requise

Pour utiliser Oracle Cloud Infrastructure, un administrateur doit être membre d'un groupe auquel l'accès de sécurité est accordé dans une politique par un administrateur de location. Cet accès est requis que vous utilisiez la console ou l'API REST avec une trousse SDK, l'interface de ligne de commande ou un autre outil. Si vous obtenez un message indiquant que vous ne disposez pas de l'autorisation requise, vérifiez auprès de l'administrateur de la location quel type d'accès vous avez et dans quel compartiment votre accès fonctionne.

Pour les administrateurs : La politique sous Autoriser les administrateurs de réseau à gérer un réseau en nuage décrit la gestion de tous les composants du service de réseau, notamment les groupes NSG.

Si vos administrateurs de sécurité doivent gérer des groupes NSG mais pas d'autres composants du service de réseau, vous pouvez écrire une politique plus restrictive : 

Allow group NSGAdmins to manage network-security-groups in tenancy
			
Allow group NSGAdmins to manage vcns in tenancy 
      where ANY {request.operation = 'CreateNetworkSecurityGroup',
                 request.operation = 'DeleteNetworkSecurityGroup'}

Allow group NSGAdmins to read vcns in tenancy

Allow group NSGAdmins to use VNICs in tenancy

Le premier énoncé permet au groupe NSGAdmins de créer et de gérer des groupes NSG et leurs règles de sécurité.

Le deuxième énoncé est nécessaire car la création ou la suppression d'un NSG affecte le VCN dans lequel il se trouve. Cet énoncé restreint les autorisations liées au VCN uniquement à celles qui sont nécessaires pour créer ou supprimer un NSG. L'énoncé ne permet pas au groupe NSGAdmins de créer ou de supprimer des réseaux en nuage virtuels, ni d'utiliser des ressources dans un VCN, à l'exception des groupes de sécurité de réseau.

Le troisième énoncé est requis pour lister les VCN, ce qui est un préalable à la création ou la suppression d'un NSG dans un VCN. Pour savoir pourquoi le deuxième et le troisième énoncés sont requis, voir Conditions.

Le quatrième énoncé est obligatoire si le groupe NSGAdmins doit placer des cartes vNIC dans un NSG. La personne qui crée la ressource parent de la carte VNIC (par exemple, une instance de calcul) doit déjà avoir ce niveau d'autorisation.

Pour plus d'informations sur les politiques du service de réseau, voir Politiques IAM pour le service de réseau.