Règles de sécurité

Le service Networking offre deux fonctionnalités de pare-feu virtuel utilisant des règles de sécurité pour contrôler le trafic au niveau du paquet. Ces deux fonctionnalités sont les suivantes :

  • Listes de sécurité : fonctionnalité de pare-feu virtuel d'origine du service Networking.
  • Groupes de sécurité réseau : fonctionnalité conçue par la suite pour les composants d'application ayant différents états de sécurité. Les groupes de sécurité réseau ne sont pris en charge que pour des services spécifiques.

Ces deux fonctionnalités proposent différentes manières d'appliquer des règles de sécurité à un ensemble de cartes d'interface réseau virtuelles  dans le réseau cloud virtuel.

Cette rubrique récapitule les différences de base entre les deux fonctionnalités. Elle explique également les concepts de règle de sécurité importants que vous devez comprendre. La façon dont vous créez, gérez et appliquez des règles de sécurité varie selon que vous utilisez des listes de sécurité ou des groupes de sécurité réseau. Pour plus d'informations sur l'implémentation, reportez-vous aux rubriques connexes suivantes :

Comparaison entre les listes de sécurité et les groupes de sécurité réseau

Les listes de sécurité permettent de définir un ensemble de règles de sécurité qui s'applique à toutes les cartes d'interface réseau virtuelles d'un sous-réseau complet. Pour utiliser une liste de sécurité donnée avec un sous-réseau spécifique, vous devez associer la liste de sécurité au sous-réseau lors de la création de ce dernier ou ultérieurement. Un sous-réseau peut être associé à cinq listes de sécurité au maximum. Toutes les cartes d'interface réseau virtuelles créées dans ce sous-réseau sont soumises aux listes de sécurité associées à celui-ci.

Les groupes de sécurité réseau vous permettent de définir un ensemble de règles de sécurité qui s'applique à un groupe de cartes d'interface réseau virtuelles de votre choix (ou aux ressources parent des cartes d'interface réseau virtuelles, comme les équilibreurs de charge ou les systèmes de base de données). Par exemple : les cartes d'interface réseau virtuelles qui appartiennent à un ensemble d'instances Compute ayant toutes le même état de sécurité. Pour utiliser un groupe de sécurité réseau donné, vous lui ajoutez les cartes d'interface réseau virtuelles qui vous intéressent. Toutes les cartes d'interface réseau virtuelles ajoutées à ce groupe sont soumises aux règles de sécurité de celui-ci. Une carte d'interface réseau virtuelle peut être ajoutée à cinq groupes de sécurité réseau au maximum.

Le diagramme suivant illustre ce concept.

Comparaison entre un groupe de sécurité réseau et une liste de sécurité.

Oracle recommande d'utiliser des groupes de sécurité réseau plutôt que des listes de sécurité car ils vous permettent de séparer l'architecture de sous-réseau du réseau cloud virtuel de vos exigences en matière de sécurité des applications.

En revanche, si vous le souhaitez, vous pouvez utiliser à la fois des listes de sécurité et des groupes de sécurité réseau. Pour plus d'informations, reportez-vous à Si vous utilisez à la fois des listes de sécurité et des groupes de sécurité réseau.

A propos des cartes d'interface réseau virtuelles et des ressources parent

Une carte d'interface réseau virtuelle est un composant du service Networking qui permet à une ressource mise en réseau, telle qu'une instance Compute, de se connecter à un réseau cloud virtuel. La carte d'interface réseau virtuelle détermine le mode de connexion de l'instance aux adresses situées à l'intérieur et à l'extérieur du réseau cloud virtuel. Chaque carte d'interface réseau virtuelle réside dans un sous-réseau de réseau cloud virtuel.

Lorsque vous créez une instance Compute, une carte d'interface réseau virtuelle correspondante est automatiquement créée dans le sous-réseau de l'instance. L'instance est considérée comme la ressource parent de la carte d'interface réseau virtuelle. Vous pouvez ajouter davantage de cartes d'interface réseau virtuelles (secondaires) à une instance Compute. Pour cette raison, les cartes d'interface réseau virtuelles d'une instance sont affichées clairement parmi les ressources associées d'une instance Compute dans la console.

Il existe d'autres types de ressource parent que vous pouvez créer et qui entraînent également la création automatique d'une carte d'interface réseau virtuelle. Par exemple, lorsque vous créez un équilibreur de charge, le service Load Balancing crée automatiquement des cartes d'interface réseau virtuelles pour équilibrer le trafic sur l'ensemble de back-ends. De même, lorsque vous créez un système de base de données, le service Database crée automatiquement des cartes d'interface réseau virtuelles en tant que noeuds du système de base de données. Ces services créent et gèrent les cartes d'interface réseau virtuelles pour vous. Pour cette raison, ces cartes d'interface réseau virtuelles ne sont pas affichées aussi clairement dans la console comme le sont celles des instances Compute.

Pour utiliser un groupe de sécurité réseau, vous devez ajouter les cartes d'interface réseau virtuelles de votre choix au groupe. Toutefois, vous utilisez généralement la ressource parent lorsque vous ajoutez une carte d'interface réseau virtuelle au groupe, et non la carte d'interface réseau virtuelle elle-même. Par exemple, lorsque vous créez une instance Compute, vous pouvez éventuellement spécifier un groupe de sécurité réseau pour l'instance. Bien que vous placiez conceptuellement l'instance dans le groupe, vous placez en fait la carte d'interface réseau virtuelle principale de l'instance dans le groupe de sécurité réseau. Les règles de sécurité du groupe s'appliquent à cette carte d'interface réseau virtuelle, et non à l'instance. De même, si vous ajoutez une carte d'interface réseau virtuelle secondaire à l'instance, vous pouvez éventuellement spécifier un groupe de sécurité réseau pour celle-ci. Les règles s'appliquent alors à cette carte d'interface réseau virtuelle, et non à l'instance. Toutes les cartes d'interface réseau virtuelles d'un groupe de sécurité réseau donné doivent se trouver dans le réseau cloud virtuel auquel appartient le groupe de sécurité réseau.

De même, lorsque vous placez un équilibreur de charge dans un groupe de sécurité réseau, vous le placez conceptuellement dans le groupe. Ce sont en réalité les cartes d'interface réseau virtuelles gérées par le service Load Balancing qui sont placées dans le groupe de sécurité réseau.

Vous gérez l'appartenance des cartes d'interface réseau virtuelles d'un groupe de sécurité réseau au niveau de la ressource parent, et non au niveau du groupe de sécurité réseau lui-même. En d'autres termes, pour ajouter une ressource parent à un groupe de sécurité réseau, vous exécutez l'action sur la ressource parent (en indiquant les groupes de sécurité réseau auxquels la ressource parent doit être ajoutée). Vous n'exécutez pas l'action sur le groupe de sécurité réseau (en indiquant les cartes d'interface réseau virtuelles ou les ressources parent à ajouter au groupe de sécurité réseau). De même, pour enlever une carte d'interface réseau virtuelle d'un groupe de sécurité réseau, vous exécutez cette action en mettant à jour la ressource parent, et non le groupe de sécurité réseau. Par exemple, pour ajouter la carte d'interface réseau virtuelle d'une instance Compute existante à un groupe de sécurité réseau, vous mettez à jour les propriétés de cette carte d'interface réseau virtuelle et spécifiez le groupe de sécurité réseau. Par exemple, à l'aide de l'API REST, vous appelez UpdateVnic. Dans la console, vous visualisez l'instance, puis la carte d'interface réseau virtuelle qui vous intéresse, et modifiez les propriétés de cette dernière.

Pour obtenir la liste des ressources parent qui prennent en charge l'utilisation des groupes de sécurité réseau, reportez-vous à Prise en charge des groupes de sécurité réseau.

Groupe de sécurité réseau comme source ou destination d'une règle

Il existe une différence importante dans la manière dont vous pouvez écrire des règles de sécurité pour les groupes de sécurité réseau et pour les listes de sécurité.

Lors de l'écriture de règles pour un groupe de sécurité réseau, vous pouvez spécifier un groupe de sécurité réseau en tant que source du trafic (pour les règles entrantes) ou destination du trafic (pour les règles sortantes). Pour les règles de liste de sécurité, en revanche, vous devez spécifier un CIDR en tant que source ou destination.

La possibilité de spécifier un groupe de sécurité réseau signifie que vous pouvez facilement écrire des règles pour contrôler le trafic entre deux groupes de sécurité différents. Les groupes de sécurité réseau doivent se trouver dans le même réseau cloud virtuel.

De plus, si vous souhaitez contrôler le trafic entre les cartes d'interface réseau virtuelles dans un groupe de sécurité réseau spécifique, vous pouvez écrire des règles qui spécifient le groupe de sécurité réseau propre à la règle en tant que source (pour les règles entrantes) ou destination (pour les règles sortantes).

Pour plus d'informations, reportez-vous à Présentation des groupes de sécurité réseau.

Différences de l'API REST

Le modèle de l'API REST présente quelques différences de base entre les groupes de sécurité réseau et les listes de sécurité. Pour plus d'informations, reportez-vous à Utilisation de l'API.

Règles par défaut

Votre réseau cloud virtuel comprend automatiquement une liste de sécurité par défaut qui contient plusieurs règles de sécurité par défaut afin de vous aider à utiliser le service Networking. Lorsque vous créez un sous-réseau, la liste de sécurité par défaut est associée au sous-réseau, sauf si vous indiquez une liste de sécurité personnalisée que vous avez déjà créée dans le réseau cloud virtuel. En revanche, le réseau cloud virtuel ne comporte pas de groupe de sécurité réseau par défaut.

Limites

Les deux fonctionnalités présentent des limites différentes.

Limites des listes de sécurité

Ressource

Portée

Crédits universels mensuels

Paiement à l'utilisation ou promotion

Listes de sécurité Réseau cloud virtuel 300 300
Listes de sécurité Sous-réseau 5* 5*
Règles de sécurité Liste de sécurité

200 règles entrantes*

et

200 règles sortantes*

200 règles entrantes*

et

200 règles sortantes*

* Impossible d'augmenter la limite pour cette ressource
Limites des groupes de sécurité réseau

Ressource

Portée

Crédits universels mensuels

Paiement à l'utilisation ou promotion

Groupes de sécurité réseau Réseau cloud virtuel 1 000 1 000
Cartes d'interface réseau virtuelles Groupe de sécurité réseau

Un groupe de sécurité réseau donné peut comporter autant de cartes d'interface réseau virtuelles qu'il en existe dans le réseau cloud virtuel.

Une carte d'interface réseau virtuelle donnée peut appartenir à 5 groupes de sécurité réseau au maximum.*

Un groupe de sécurité réseau donné peut comporter autant de cartes d'interface réseau virtuelles qu'il en existe dans le réseau cloud virtuel.

Une carte d'interface réseau virtuelle donnée peut appartenir à 5 groupes de sécurité réseau au maximum.*

Règles de sécurité Groupe de sécurité réseau

500 (total des règles entrantes et sortantes)*

500 (total des règles entrantes et sortantes)*

* Impossible d'augmenter la limite pour cette ressource

Meilleures pratiques pour les règles de sécurité

Utilisation des groupes de sécurité réseau

Oracle recommande d'utiliser des groupes de sécurité réseau pour les composants ayant tous le même état de sécurité. Par exemple, dans une architecture à plusieurs niveaux, vous pouvez disposer d'un groupe de sécurité réseau distinct pour chaque niveau. Les cartes d'interface réseau virtuelles d'un niveau donné appartiennent toutes au groupe de sécurité réseau de ce niveau. Au sein d'un niveau donné, des exigences de sécurité spéciales supplémentaires peuvent être contenues dans un sous-ensemble spécifique des cartes d'interface réseau virtuelles du niveau. Vous devez donc créer un autre groupe de sécurité réseau pour ces règles supplémentaires et placer ce sous-ensemble de cartes d'interface réseau virtuelles à la fois dans le groupe de sécurité réseau du niveau et dans le groupe de sécurité réseau supplémentaire.

Oracle recommande également d'utiliser des groupes de sécurité réseau car il leur donne la priorité par rapport aux listes de sécurité lors de l'implémentation des améliorations futures.

Familiarisation avec les règles de liste de sécurité par défaut

Votre réseau cloud virtuel comprend automatiquement une liste de sécurité par défaut qui contient plusieurs règles de sécurité par défaut afin de vous aider à utiliser le service Networking. Ces règles existent car elles permettent la connectivité de base. Même si vous avez choisi de ne pas utiliser les listes de sécurité ou la liste de sécurité par défaut, vous devez connaître ces règles pour mieux comprendre les types de trafic dont vos ressources cloud mise en réseau ont besoin. Vous pouvez utiliser ces règles dans vos groupes de sécurité réseau ou dans n'importe quelle liste de sécurité personnalisée que vous configurez.

La liste de sécurité par défaut n'inclut pas les règles qui permettent d'autoriser la commande ping. Si vous devez utiliser la commande ping, reportez-vous à Règles pour autoriser la commande ping.

Conservation des règles de sécurité par défaut sans distinction

Votre réseau cloud virtuel peut comporter des sous-réseaux qui utilisent la liste de sécurité par défaut. Ne supprimez aucune des règles de sécurité par défaut de la liste à moins d'avoir vérifié au préalable que les ressources de votre réseau cloud virtuel n'en ont pas besoin. Dans le cas contraire, vous risquez de perturber la connectivité de votre réseau cloud virtuel.

Vérification de l'alignement des règles de pare-feu de système d'exploitation avec les règles de sécurité

Les instances exécutant des images Linux fournies par Oracle ou des images Windows comportent également des règles de pare-feu de système d'exploitation qui contrôlent l'accès à l'instance. Lors du dépannage de l'accès à une instance, assurez-vous que tous les éléments suivants sont définis correctement :

  • Règles des groupes de sécurité réseau dans lesquels l'instance se trouve
  • Règles des listes de sécurité associées au sous-réseau de l'instance
  • Règles de pare-feu de système d'exploitation de l'instance

Pour plus d'informations, reportez-vous à Images fournies par Oracle.

Si votre instance exécute Oracle Autonomous Linux 7, Oracle Linux 8 ou Oracle Linux 7, vous devez utiliser firewalld pour interagir avec les règles iptables. Pour référence, voici les commandes permettant d'ouvrir un port (1521 dans cet exemple) :

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo firewall-cmd --reload

En ce qui concerne les instances comportant un volume d'initialisation iSCSI, la commande --reload précédente peut entraîner des problèmes. Pour obtenir des détails et une solution de contournement, reportez-vous à Le système se bloque après l'exécution de firewall-cmd --reload.

Utilisation des mesures de carte d'interface réseau virtuelle pour résoudre les problèmes de paquets supprimés en raison des règles de sécurité

Le service Networking propose des mesures pour les cartes d'interface réseau virtuelles, qui indiquent les niveaux de trafic des cartes d'interface réseau virtuelles (paquets et octets). Deux des mesures concernent les paquets entrants et sortants qui violent les règles de sécurité et qui sont par conséquent supprimés. Vous pouvez utiliser ces mesures pour résoudre les problèmes liés aux règles de sécurité et pour vous assurer que vos cartes d'interface réseau virtuelles reçoivent le trafic souhaité.

Si vous utilisez à la fois des listes de sécurité et des groupes de sécurité réseau

Vous pouvez utiliser des listes de sécurité, des groupes de sécurité réseau ou les deux. Cela dépend de vos besoins en matière de sécurité.

Si vous avez des règles de sécurité à appliquer à toutes les cartes d'interface réseau virtuelles contenues dans un réseau cloud virtuel, la solution la plus simple consiste à placer les règles dans une seule liste de sécurité, puis à associer cette liste de sécurité à tous les sous-réseaux du réseau cloud virtuel. De cette façon, vous pouvez vous assurer que les règles sont appliquées, quelle que soit la personne dans votre organisation qui crée une carte d'interface réseau virtuelle dans le réseau cloud virtuel. Si vous le souhaitez, vous pouvez utiliser la liste de sécurité par défaut du réseau cloud virtuel, qui est automatiquement intégrée à celui-ci et qui contient un ensemble de règles essentielles par défaut.

Si vous choisissez d'utiliser à la fois des listes de sécurité et des groupes de sécurité réseau, l'ensemble de règles qui s'applique à une carte d'interface réseau virtuelle donnée correspond à l'union des éléments suivants :

  • Règles de sécurité des listes de sécurité associées au sous-réseau de la carte d'interface réseau virtuelle
  • Règles de sécurité de tous les groupes de sécurité réseau dans lesquels se trouve la carte d'interface réseau virtuelle

Le diagramme suivant est une illustration simple de l'idée.

Une carte d'interface réseau virtuelle est soumise aux règles de tous les groupes de sécurité réseau auxquels elle appartient et de toutes les listes de sécurité associées à son sous-réseau.

Un paquet donné est autorisé si une règle dans l'une des listes et des groupes pertinents autorise le trafic (ou si le trafic fait partie d'une connexion existante suivie). Un avertissement est émis si les listes contiennent à la fois des règles avec conservation de statut et sans conservation de statut couvrant le même trafic. Pour plus d'informations, reportez-vous à Règles avec conservation de statut et sans conservation de statut.

Parties d'une règle de sécurité

Une règle de sécurité autorise un type de trafic spécifique vers ou depuis une carte d'interface réseau virtuelle. Par exemple, une règle de sécurité couramment utilisée autorise le trafic de port TCP 22 entrant pour établir des connexions SSH à l'instance (plus spécifiquement aux cartes d'interface réseau virtuelles de l'instance). Sans règle de sécurité, aucun trafic n'est autorisé vers et depuis les cartes d'interface réseau virtuelles dans le réseau cloud virtuel.

Remarque

Les règles de sécurité ne sont pas appliquées au trafic impliquant le bloc CIDR 169.254.0.0/16, qui inclut des services tels que des métadonnées d'instance et iSCSI.

Chaque règle de sécurité spécifie les éléments suivants :

  • Direction (entrée ou sortie) : l'entrée correspond au trafic entrant vers la carte d'interface réseau virtuelle et la sortie correspond au trafic sortant de celle-ci. Le modèle de l'API REST pour les listes de sécurité est différent de celui pour les groupes de sécurité réseau. Les listes de sécurité contiennent un objet IngressSecurityRule et un objet EgressSecurityRule distinct. Les groupes de sécurité réseau contiennent uniquement un objet SecurityRule. L'attribut direction de l'objet détermine si la règle concerne le trafic entrant ou sortant.
  • Avec ou sans conservation de statut : s'il s'agit d'une règle avec conservation de statut, le suivi de connexion est utilisé pour le trafic correspondant à la règle. S'il s'agit d'une règle sans conservation de statut, aucun suivi de connexion n'est utilisé. Reportez-vous à Règles avec conservation de statut et sans conservation de statut.
  • Type de source et source (règles entrantes uniquement) : la source que vous indiquez pour une règle entrante dépend du type de source choisi.

    Types de source autorisés
    Type de source Source autorisée
    CIDR Bloc CIDR d'où provient le trafic. Utilisez 0.0.0.0/0 pour indiquer toutes les adresses IP. Le préfixe est requis (par exemple, incluez /32 si vous indiquez une adresse IP individuelle).
    Groupe de sécurité réseau

    Groupe de sécurité réseau situé dans le même réseau cloud virtuel que le groupe de sécurité réseau de cette règle.

    Ce type de source n'est disponible que si la règle appartient à un groupe de sécurité réseau, et non à une liste de sécurité.

    Service

    Uniquement pour les paquets provenant d'un service Oracle via une passerelle de service.

    Le service source correspond au libellé CIDR de service qui vous intéresse.

  • Type de destination et destination (règles sortantes uniquement) : la destination que vous indiquez pour une règle sortante dépend du type de destination choisi.

    Types de destination autorisés
    Type de destination Destination autorisée
    CIDR Bloc CIDR auquel le trafic est destiné. Utilisez 0.0.0.0/0 pour indiquer toutes les adresses IP. Le préfixe est requis (par exemple, incluez /32 si vous indiquez une adresse IP individuelle).
    Groupe de sécurité réseau

    Groupe de sécurité réseau situé dans le même réseau cloud virtuel que le groupe de sécurité réseau de cette règle.

    Ce type de destination n'est disponible que si la règle appartient à un groupe de sécurité réseau, et non à une liste de sécurité.

    Service

    Uniquement pour les paquets destinés à un service Oracle via une passerelle de service.

    Le service de destination correspond au libellé CIDR de service qui vous intéresse.

  • Protocole IP : protocole IPv4 unique ou "tous" pour couvrir tous les protocoles.
  • Port source : port d'où provient le trafic. Pour TCP ou UDP, vous pouvez indiquer tous les ports source, ou éventuellement un numéro de port source unique ou une plage.
  • Port de destination : port auquel le trafic est destiné. Pour TCP ou UDP, vous pouvez indiquer tous les ports de destination, ou éventuellement un numéro de port de destination unique ou une plage.
  • Type et code ICMP : pour ICMP, vous pouvez indiquer tous les types et tous les codes, ou un seul type avec un code facultatif. Si le type a plusieurs codes, créez une règle distincte pour chaque code à autoriser.
  • Description (règles de groupe de sécurité réseau uniquement) : les règles de sécurité de groupe de sécurité réseau incluent un attribut facultatif dans lequel vous pouvez fournir une description conviviale de la règle. Ceci n'est actuellement pas pris en charge pour les règles de liste de sécurité.

Pour consulter des exemples de règles de sécurité, reportez-vous à Scénarios de configuration réseau.

Pour connaître le nombre maximal de règles que vous pouvez avoir, reportez-vous à Comparaison entre les listes de sécurité et les groupes de sécurité réseau.

Remarque

Si vous utilisez des groupes de sécurité réseau et que deux cartes d'interface réseau virtuelles se trouvant dans le même réseau cloud virtuel doivent communiquer à l'aide de leurs adresses IP publiques, vous devez utiliser l'adresse IP publique de la carte d'interface réseau virtuelle et non son groupe de sécurité réseau comme source (pour les règles entrantes) ou comme destination (pour les règles sortantes) dans les règles de sécurité pertinentes. Le paquet est acheminé vers la passerelle Internet du réseau cloud virtuel. A ce stade, les informations du groupe de sécurité réseau de la carte d'interface réseau virtuelle ne sont pas disponibles. Par conséquent, une règle de sécurité qui spécifie le groupe de sécurité réseau comme source ou destination ne permet pas d'autoriser ce type de trafic spécifique.

Règles avec conservation de statut et sans conservation de statut

Lorsque vous créez une règle de sécurité, vous indiquez s'il s'agit d'une règle avec conservation de statut ou sans conservation de statut. La différence est décrite dans les sections suivantes. La valeur par défaut est une règle avec conservation de statut. Les règles sans conservation de statut sont recommandées si vous disposez d'un site Internet volumineux (pour le trafic HTTP/HTTPS).

Cette section fait spécifiquement référence aux instances Compute et à leur trafic. Toutefois, cette discussion s'applique à tous les types de ressource associés à des cartes d'interface réseau virtuelles. Reportez-vous à Comparaison entre les listes de sécurité et les groupes de sécurité réseau.

Règles avec conservation de statut

Marquer une règle de sécurité comme étant avec conservation de statut indique que vous souhaitez utiliser le suivi de connexion pour tout trafic correspondant à cette règle. Cela signifie que lorsqu'une instance reçoit un trafic correspondant à la règle entrante avec conservation de statut, la réponse est suivie et automatiquement autorisée vers l'hôte d'origine, indépendamment des règles sortantes applicables à l'instance. De plus, lorsqu'une instance envoie un trafic correspondant à une règle sortante avec conservation de statut, la réponse entrante est automatiquement autorisée, indépendamment des règles entrantes. Pour plus de détails, reportez-vous à Règles avec conservation de statut et sans conservation de statut.

La figure ci-dessous illustre une règle entrante avec conservation de statut pour une instance qui doit recevoir le trafic HTTP et y répondre. L'instance A et l'hôte B communiquent (l'hôte B peut être n'importe quel hôte, qu'il s'agisse d'une instance ou non). La règle entrante avec conservation de statut autorise le trafic de n'importe quelle adresse IP source (0.0.0.0/0) vers le port de destination 80 uniquement (protocole TCP). Aucune règle sortante n'est requise pour autoriser le trafic de réponse.

Règle entrante avec conservation de statut autorisant le trafic HTTP entrant et la réponse

Règles sans conservation de statut

Marquer une règle de sécurité comme étant sans conservation de statut indique que vous ne voulez pas utiliser le suivi de connexion pour tout trafic correspondant à cette règle. Cela signifie que le trafic de réponse n'est pas automatiquement autorisé. Afin d'autoriser le trafic de réponse pour une règle entrante sans conservation de statut, vous devez créer une règle sortante sans conservation de statut correspondante.

La figure suivante présente l'instance A et l'hôte B comme précédemment, mais avec des règles de sécurité sans conservation de statut. Comme pour la règle avec conservation de statut dans la section précédente, la règle entrante sans conservation de statut autorise le trafic à partir de toutes les adresses IP et de tous les ports vers le port de destination 80 uniquement (à l'aide du protocole TCP). Pour autoriser le trafic de réponse, vous avez besoin d'une règle sortante sans conservation de statut correspondante qui autorise le trafic vers n'importe quelle adresse IP de destination (0.0.0.0/0) et n'importe quel port à partir du port source 80 uniquement (à l'aide du protocole TCP).

Règles entrante et sortante sans conservation de statut autorisant le trafic HTTP entrant et la réponse

Si l'instance A doit initier le trafic HTTP et obtenir la réponse, vous avez besoin d'un autre ensemble de règles sans conservation de statut. Comme le montre la figure suivante, le port source doit correspondre à tous les ports et le port de destination à 80 (HTTP) pour la règle sortante. Pour la règle entrante, le port source doit correspondre à 80 et le port de destination à tous les ports.

Règles entrante et sortante sans conservation de statut permettant à l'instance d'initier le trafic HTTP et d'obtenir la réponse

Si vous utilisez une liaison de port sur l'instance A pour indiquer exactement le port à partir duquel le trafic HTTP doit provenir, vous pouvez la spécifier en tant que port source dans la règle sortante et en tant que port de destination dans la règle entrante.

Remarque

Si, pour une raison quelconque, vous utilisez des règles avec conservation de statut et des règles sans conservation de statut, et qu'un trafic correspond à la fois à une règle avec conservation de statut et à une règle sans conservation de statut dans une direction particulière (par exemple, l'entrée), la règle sans conservation de statut est prioritaire et la connexion n'est pas suivie. Vous aurez besoin d'une règle correspondante dans l'autre direction (par exemple, la sortie, avec ou sans conservation de statut) pour que le trafic de réponse soit autorisé.

Détails du suivi de connexion pour les règles avec conservation de statut

Oracle utilise le suivi de connexion afin d'autoriser les réponses pour le trafic correspondant aux règles avec conservation de statut (reportez-vous à Règles avec conservation de statut et sans conservation de statut). Chaque instance dispose d'un nombre maximal de connexions simultanées pouvant faire l'objet d'un suivi, en fonction de la forme  de l'instance.

Afin de déterminer le trafic de réponse pour TCP, UDP et ICMP, Oracle effectue le suivi de connexion sur les éléments suivants du paquet :

  • Protocole
  • Adresses IP source et de destination
  • Ports source et de destination (pour TCP et UDP uniquement)
Remarque

Pour les autres protocoles, Oracle suit uniquement le protocole et les adresses IP, et non les ports. Cela signifie que lorsqu'une instance lance du trafic vers un autre hôte et que ce trafic est autorisé par les règles de sécurité sortantes, tout trafic reçu ultérieurement par l'instance à partir de cet hôte pendant une période déterminée est considéré comme étant un trafic de réponse et est donc autorisé.

Autorisation des messages de repérage de MTU de chemin pour les règles sans conservation de statut

Si vous décidez d'utiliser des règles de sécurité sans conservation de statut pour autoriser le trafic vers/depuis des adresses situées en dehors du réseau cloud virtuel, il est important d'ajouter une règle de sécurité autorisant le trafic ICMP entrant de type 3 et avec le code 4 à partir de la source 0.0.0.0/0 et de n'importe quel port source. Cette règle permet à vos instances de recevoir des messages de fragmentation du repérage de MTU de chemin. Cette règle est essentielle pour établir une connexion à vos instances. Sans elle, vous risquez de rencontrer des problèmes de connectivité. Pour plus d'informations, reportez-vous à Connexion bloquée.

Règles pour autoriser la commande ping

La liste de sécurité par défaut du réseau cloud virtuel contient plusieurs règles par défaut, mais aucune ne permet d'autoriser les demandes ping. Si vous souhaitez envoyer une commande ping à une instance, assurez-vous que les listes de sécurité ou les groupes de sécurité réseau applicables de l'instance incluent une règle entrante avec conservation de statut supplémentaire permettant d'autoriser spécifiquement le trafic ICMP de type 8 à partir du réseau source qui doit envoyer la commande ping. Pour autoriser l'accès à la commande ping à partir d'Internet, utilisez 0.0.0.0/0 pour la source. Cette règle pour l'envoi d'une commande ping est distincte des règles propres à ICMP par défaut dans la liste de sécurité par défaut. N'enlevez pas ces règles.

Règles de gestion des paquets UDP fragmentés

Les instances peuvent envoyer ou recevoir le trafic UDP. Si un paquet UDP est trop volumineux pour la connexion, il est fragmenté. Toutefois, seul le premier fragment du paquet contient les informations de port et de protocole. Si les règles de sécurité qui autorisent ce trafic entrant ou sortant spécifient un numéro de port particulier (source ou de destination), les fragments qui suivent le premier sont supprimés. Si vos instances sont censées envoyer ou recevoir des paquets UDP volumineux, définissez les ports source et de destination des règles de sécurité applicables sur ALL (au lieu d'indiquer un numéro de port spécifique).