Groupes de sécurité réseau

• Les groupes de sécurité réseau agissent comme des pare-feu virtuels pour les instances Compute et d'autres types de ressources. Un groupe de sécurité réseau se compose d'un ensemble de règles de sécurité entrantes et sortantes qui s'appliquent uniquement à un ensemble de cartes d'interface réseau virtuelles dans un seul VCN (par exemple, toutes les instances Compute qui agissent en tant que serveurs Web dans le niveau Web d'une application à plusieurs niveaux dans un VCN).
• Par rapport aux listes de sécurité, les groupes de sécurité réseau vous permettent de séparer l'architecture de sous-réseau d'un VCN des exigences de sécurité des applications. Reportez-vous à Comparaison entre les listes de sécurité et les groupes de sécurité réseau.
• Vous pouvez utiliser les groupes de sécurité réseau avec certains types de ressource. Pour plus d'informations, reportez-vous à Prise en charge des groupes de sécurité réseau.
• Les règles de sécurité des groupes de sécurité réseau fonctionnent de la même manière que les règles des listes de sécurité. Toutefois, pour la source (règles entrantes) ou la destination (règles sortantes) d'une règle de sécurité de groupe de sécurité réseau, vous pouvez indiquer un groupe de sécurité réseau au lieu d'un CIDR. Cela signifie que vous pouvez facilement écrire des règles de sécurité afin de contrôler le trafic entre deux groupes de sécurité réseau au sein du même réseau cloud virtuel ou le trafic dans un seul groupe de sécurité réseau. Reportez-vous à Parties d'une règle de sécurité.
• Contrairement aux listes de sécurité, le VCN n'a pas de groupe de sécurité réseau par défaut. De même, chaque groupe de sécurité réseau que vous créez est initialement vide. Il ne contient aucune règle de sécurité par défaut.
• Les groupes de sécurité réseau présentent des limites distinctes et différentes de celles des listes de sécurité. Reportez-vous à Limites des listes de sécurité.

Vous pouvez créer et utiliser des groupes de sécurité réseau. Toutefois, ils ne peuvent pas encore être pris en charge par tous les services Oracle Cloud Infrastructure appropriés.

Les types de ressource parent suivants prennent en charge l'utilisation des groupes de sécurité réseau :

• Autonomous Recovery Service (sous-réseaux pour Recovery Service) : lorsque vous inscrivez un sous-réseau de service de récupération, vous pouvez associer des groupes de sécurité réseau (cinq au maximum) contenant les règles entrantes pour Recovery Service.
• Instances Compute : lorsque vous créez une instance, vous pouvez indiquer des groupes de sécurité réseau pour la carte d'interface réseau virtuelle principale associée. Si vous ajoutez une carte d'interface réseau virtuelle secondaire à une instance, vous pouvez indiquer des groupes de sécurité réseau pour cette carte. Vous pouvez également mettre à jour les cartes d'interface réseau virtuelles existantes sur une instance pour qu'elles se retrouvent dans des groupes de sécurité réseau.
• Equilibreurs de charges : lorsque vous créez un équilibreur de charges, vous pouvez indiquer des groupes de sécurité système pour l'équilibreur de charge (et non l'ensemble de back-ends). Vous pouvez également mettre à jour un équilibreur de charges existant pour qu'il utilise des groupes de sécurité réseau.
• Systèmes de base de données : lorsque vous créez un système de base de données, vous pouvez indiquer des groupes de sécurité réseau. Vous pouvez également mettre à jour un système de base de données existant pour qu'il utilise des groupes de sécurité réseau.
• Bases de données autonomes : lorsque vous créez une instance Autonomous Database sur une infrastructure Exadata dédiée, vous pouvez indiquer des groupes de sécurité 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 indiquer des groupes de sécurité réseau. Vous pouvez également mettre à jour une cible de montage existante pour qu'elle utilise des groupes de sécurité réseau.
• Adresse de résolution DNS : lorsque vous créez une adresse pour un résolveur DNS privé, vous pouvez indiquer des groupes de sécurité réseau ou plusieurs. Vous pouvez également mettre à jour une adresse existante pour qu'elle utilise des groupes de sécurité réseau.
• Clusters Kubernetes : lorsque vous créez un cluster Kubernetes à l'aide de Kubernetes Engine, vous pouvez indiquer des groupes de sécurité réseau pour contrôler l'accès à l'adresse d'API Kubernetes et aux noeuds de processus actif. Vous pouvez également spécifier des groupes de sécurité réseau lors de la définition d'un équilibreur de charge pour un cluster.
• Passerelles d'API : lorsque vous créez une passerelle d'API, vous pouvez indiquer des groupes de sécurité réseau pour contrôler l'accès à celle-ci.
• Fonctions : lorsque vous configurez une application dans OCI Functions, vous pouvez indiquer des groupes de sécurité réseau pour définir des règles entrantes et sortantes qui s'appliquent à toutes les fonctions de cette application.
• Déploiements GoldenGate : lorsque vous créez un déploiement GoldenGate, vous pouvez indiquer des groupes de sécurité système pour contrôler l'accès à celui-là.
• Clusters Redis : lorsque vous créez un cluster Redis, vous pouvez indiquer des groupes de sécurité réseau pour contrôler l'accès au cluster Redis. Vous pouvez également mettre à jour un cluster existant pour qu'il utilise des groupes de sécurité réseau

Pour les types de ressource qui ne prennent plus en charge de groupes de sécurité système, continuez à utiliser les listes de sécurité pour contrôler le trafic entrant et sortant de ces ressources parent.

Un groupe de sécurité réseau fournit un pare-feu virtuel pour un ensemble de ressources cloud ayant toutes la même posture de sécurité. Par exemple, un groupe d'instances Compute qui exécutent toutes les mêmes tâches, qui doivent donc utiliser le même ensemble de ports.

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

• Cartes d'interface réseau virtuelles : cartes d'interface réseau virtuelles (par exemple, les cartes d'interface réseau virtuelles attachées à l'ensemble d'instances Compute qui disposent toutes de la même posture de sécurité). Toutes les cartes d'interface réseau virtuelles doivent se trouver dans le réseau cloud virtuel du groupe de sécurité réseau. Reportez-vous également à Comparaison entre les listes de sécurité et les groupes de sécurité réseau.
• Règles de sécurité : les règles de sécurité du groupe de noeuds définissent les types de trafic autorisés vers et depuis les VNIC du groupe. Par exemple : trafic SSH entrant sur le port TCP 22 à partir d'une source particulière.

Si vous disposez de ressources avec des postures de sécurité différentes dans le même VCN, vous pouvez écrire des règles de sécurité de groupe de sécurité réseau pour contrôler le trafic entre les ressources avec une posture par rapport à une autre. Par exemple, dans le diagramme suivant, le groupe NSG1 dispose de carte d'interface réseau virtuelle exécutées dans un seul niveau d'une application avec architecture multiniveau. Le groupe NSG2 possède des cartes d'interface réseau virtuelles exécutées dans un deuxième niveau. Les deux groupes de sécurité réseau doivent appartenir au même réseau cloud virtuel. On considère que les deux groupes de sécurité réseau doivent démarrer des connexions vers l'autre groupe.

Pour NSG1, vous configurez des règles de sécurité sortantes qui indiquent NSG2 en tant que destination et des règles de sécurité entrantes qui indiquent NSG2 en tant que source. De même, pour NSG2, vous configurez des règles de sécurité sortantes qui indiquent NSG1 en tant que destination et des règles de sécurité entrantes qui indiquent NSG1 en tant que source. Dans cet exemple, les règles sont considérées comme étant des règles avec conservation de statut.

Le diagramme précédent suppose que chaque groupe de sécurité réseau doit démarrer des connexions vers l'autre groupe.

Le diagramme suivant suppose que vous voulez autoriser uniquement les connexions démarrées à partir de NSG1 vers NSG2. Pour ce faire, enlevez la règle entrante de NSG1 et la règle sortante de NSG2. Les règles restantes n'autorisent pas les connexions démarrées entre NSG2 et NSG1.

Le diagramme suivant suppose que vous souhaitez contrôler le trafic entre des cartes d'interface réseau virtuelles au sein du même groupe de sécurité réseau. Pour ce faire, définissez la source (pour l'entrée) ou la destination (pour la sortie) de la règle en tant que groupe de sécurité réseau de la règle.

Une carte d'interface réseau virtuelle peut se trouver dans cinq groupes de sécurité réseau au maximum. Un paquet donné est autorisé si une règle dans l'un des groupes de sécurités réseau de la VNIC autorise le trafic (ou si le trafic fait partie d'une connexion existante suivie), sauf si les listes contiennent des règles de sécurités avec et sans conservation de statut qui couvrent le même trafic. Pour plus d'informations, reportez-vous à Par rapport avec les règles sans conservation de statut.

Les groupes de sécurité réseau sont des entités régionales. Pour connaître les limites relatives aux groupes de sécurité réseau, reportez-vous à Comparaison entre les listes de sécurité et les groupes de sécurité réseau.

Pour obtenir des informations sur les limites, reportez-vous à Limites des groupes de sécurité réseau et à Demande d'augmentation de limite de service.

Si vous ne connaissez pas encore les bases des règles de sécurité de groupe de sécurité réseau, reportez-vous aux sections suivantes de la rubrique Règles de sécurité :

• Parties d'une règle de sécurité
• Comparaison avec les règles sans conservation de statut

Pour plus d'informations sur l'utilisation de l'API et la signature des demandes, reportez-vous à la Documentation relative à l'API REST et à Informations d'identification de sécurité. Pour plus d'informations sur les kits SDK, reportez-vous à Kits SDK et interface de ligne de commande.

Pour plus d'informations sur l'utilisation de l'API et la signature des demandes, reportez-vous à la Documentation relative à l'API REST et à Informations d'identification de sécurité. Pour plus d'informations sur les kits SDK, reportez-vous à Kits SDK et interface de ligne de commande.

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

• Les listes de sécurité disposent d'un objet IngressSecurityRule et d'un objet EgressSecurityRule distinct. Les groupes de sécurité réseau ont uniquement un objet SecurityRule et l'attribut direction de l'objet indique si la règle concerne le trafic entrant ou sortant.
• Avec les listes de sécurité, les règles font partie de l'objet SecurityList et vous utilisez ces règles en appelant les opérations de liste de sécurité (telles que UpdateSecurityList). Avec les groupes de sécurité réseau, les règles n'appartiennent pas à l'objet NetworkSecurityGroup. Au lieu de ça, vous utilisez des opérations distinctes pour utiliser les règles d'un groupe de sécurité réseau particulier (par exemple,UpdateNetworkSecurityGroupSecurityRules).
• Le modèle de mise à jour des règles de sécurité existantes diffère entre les listes de sécurité et les groupes de sécurité réseau. Avec les groupes de sécurité système, chaque règle d'un groupe particulier dispose d'un identificateur unique affecté par Oracle (exemple : 04ABEC). Lorsque vous appelez UpdateNetworkSecurityGroupSecurityRules, vous indiquez les ID des règles spécifiques à mettre à jour. A des fins de comparaison, les règles n'ont pas d'identificateur unique dans les listes de sécurité. Lorsque vous appelez UpdateSecurityList, vous devez transmettre la liste complète des règles, y compris celle qui n'est pas mise à jour lors de l'appel.
• La sécurité règle une limite de 25 règles lors de l'appel des opérations visant à ajouter, enlever ou mettre à jour.