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é.

Points saillants

  • Les groupes de sécurité de réseau (NSG) servent de pare-feu virtuels à vos 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 de votre choix dans un seul réseau VCN (par exemple, toutes les instances de calcul utilisées comme serveurs Web dans le niveau Web d'une application multiniveau dans votre réseau VCN).
  • Par rapport aux listes de sécurité, les groupes NSG vous permettent d'isoler l'architecture de sous-réseau de votre réseau VCN des exigences de sécurité de votre 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é. Toutefois, ils ne sont pas encore pris en charge par tous les services Oracle Cloud Infrastructure pertinents.

Actuellement, 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 groupe NSG.
  • Équilibreurs de charge : Lorsque vous créez un équilibreur de charge, vous pouvez lui définir 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. Vous pouvez également mettre à jour une instance d'infrastructure Exadata dédiée existante pour utiliser des NSG.
  • 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 vNIC (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 ,dans le même réseau VCN, vous avez des ressources dont la situation en matière de sécurité est différente, 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 lancer 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 groupe NSG doit lancer des connexions à l'autre.

Le diagramme suivant suppose que vous souhaitez n'autoriser que les connexions lancé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 règles restantes n'autorisent pas les connexions lancées par NSG2 vers NSG1.

Ces règles de sécurité permettent les connexions lancé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). Une restriction s'applique si les listes comprennent des règles de sécurité avec état et sans état qui couvrent le même trafic. Pour plus d'informations, voir Règles avec état et 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.

Le modèle d'API REST pour les groupes NSG présente quelques différences de base avec les listes de sécurité :

  • Dans le cas des listes de sécurité, il existe un objet IngressSecurityRule et un objet EgressSecurityRule distinct. Dans le cas des groupes de sécurité de réseau, il n'existe qu'un objet SecurityRule et l'attribut direction de l'objet détermine 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 donné (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 donné 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.
  • Le nombre de règles est limité à 25 lors de l'appel des opérations d'ajout, de suppression ou de mise à jour des règles de sécurité.

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-lui des ressources parents (ou plus précisément, 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 NSG, il ne doit contenir aucune carte vNIC ou 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 pour déterminer le responsable d'une ressource donnée.

Politique GIA requise

Pour utiliser Oracle Cloud Infrastructure, un administrateur doit vous accorder un accès de sécurité au moyen d'une politique . 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 le type d'accès qui vous a été octroyé et le compartiment  à utiliser.

Pour les administrateurs : La politique sous Permettre aux administrateurs de réseau de 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. Il ne permet pas au groupe NSGAdmins de créer ou de supprimer des VCN, ni d'utiliser les ressources d'un VCN, à l'exception des NSG.

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à disposer du niveau d'autorisation nécessaire.

Pour plus d'informations sur les politiques du service de réseau, voir Politiques de gestion des identités et des accès pour le service de réseau.