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 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 offrent différentes façons d'appliquer des règles de sécurité à un ensemble de cartes d'interface réseau virtuelles (VNIC) dans le réseau cloud virtuel (VCN).
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 :
Vous pouvez utiliser Zero Trust Packet Routing (ZPR) avec ou à la place des groupes de sécurité réseau pour contrôler l'accès réseau aux ressources OCI en leur appliquant des attributs de sécurité et en créant des stratégies ZPR pour contrôler la communication entre elles. Pour plus d'informations, reportez-vous à la section Zero Trust Packet Routing.
Si une adresse a un attribut de sécurité ZPR, le trafic vers l'adresse doit satisfaire les règles ZPR, ainsi que toutes les règles de groupe de sécurité réseau et de liste de sécurité. Par exemple, si vous utilisez déjà des groupes de sécurité réseau et que vous appliquez un attribut de sécurité à une adresse, dès que l'attribut est appliqué, tout le trafic vers l'adresse est bloqué. Ensuite, une stratégie ZPR doit autoriser le trafic vers l'adresse.
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 d'accès donnée avec un sous-réseau spécifique, vous associez la liste d'accès au sous-réseau lors de la création du sous-réseau 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.
Network security groups (NSGs) let you define a set of security rules that applies to a chosen group of VNICs (or the VNICs' parent resources such as load balancers or DB systems). Par exemple : les cartes d'interface réseau virtuelles qui appartiennent à un ensemble d'instances Compute ayant toutes la même posture de sécurité. Pour utiliser un groupe d'interface réseau virtuelle donné, vous ajoutez les cartes d'interface réseau virtuelles qui peuvent vous intéresser. 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 tableau suivant récapitule les différences.
| Outil de sécurité | Applicable à | Pour activer | Limites |
|---|---|---|---|
| Listes de sécurité | Toutes les cartes d'interface réseau virtuelles d'un sous-réseau utilisant la liste de sécurité | Associer la liste de sécurité au sous-réseau | Cinq listes de sécurité au maximum par sous-réseau |
| Groupes de sécurité réseau | Cartes d'interface réseau virtuelles sélectionnées du même réseau cloud virtuel | Ajouter des cartes d'interface réseau virtuelles spécifiques au groupe de sécurité réseau | Cinq groupes de sécurité réseau au maximum par carte d'interface réseau virtuelle |
Nous vous recommandons d'utiliser des groupes de sécurité réseau au lieu de listes de sécurité car les groupes de sécurité réseau vous permettent de séparer l'architecture de sous-réseau du VCN des exigences de sécurité de l'application.
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 de service Networking requis pour qu'une ressource en réseau telle qu'une instance Compute se connecte à un réseau cloud virtuel (VCN). La carte d'interface réseau virtuelle affecte la façon dont l'instance se connecte aux adresses à l'intérieur et à l'extérieur du VCN. 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 virtuelles est automatiquement créée pour l'instance 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 d'autres cartes d'interface réseau virtuelles (secondaires) à une instance Compute. Pour cette raison, les VNIC d'une instance sont affichées clairement dans le cadre des ressources associées d'une instance Compute dans la console.
Les autres types de ressource parent 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, celui-ci crée automatiquement les cartes d'interface réseau virtuelles pour l'équilibrage du 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 VNIC en tant que noeuds de 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 aussi évidentes dans la console que les cartes d'interface réseau virtuelles pour les instances Compute.
Pour utiliser un groupe de sécurité réseau, vous mettez activement des cartes d'interface réseau virtuelles dans le groupe. Une carte d'interface réseau virtuelle ne fait jamais partie d'un groupe de sécurité réseau car elle se trouve dans un certain sous-réseau. 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 d'accès réseau pour cette instance. Bien que vous placiez conceptuellement l'instance dans le groupe, vous placez-la en fait la carte d'interface réseau virtuel principale du groupe dans le réseau de sécurité. 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. Notez que toutes les cartes d'interface réseau virtuelles d'un groupe de sécurité réseau doivent se trouver dans le même VCN que le groupe de sécurité réseau.
De même, lorsque vous placez un équilibreur de main-d'oeuvre dans un groupe de sécurité réseau, vous le placez conceptuellement dans le groupe. Techniquement, vous placez les cartes d'interface réseau virtuelles gérées par le service Load Balancer dans le groupe d'interface 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. Par exemple, pour ajouter une ressource parent à un groupe de sécurité système, vous devez exécuter l'action sur la ressource parents (en indiquant à quels groupes de sécurité système la ressource parent doit été ajoutée). Vous n'effectuez 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'une sécurité réseau, vous devez exécuter cette action en mettant à jour la ressource parent, et non le groupe de sécurité système. Par exemple, pour ajouter la carte d'interface réseau virtuelle d'un instance Compute existante à un groupe de sécurité système, vous mettez à jour les propriétés de cette même carte d'interface réseau virtuelle et spécifiez le groupe. 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
Une différence importante dans la façon dont vous pouvez écrire des règles de sécurité pour des groupes de sécurité réseau par rapport aux 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 des règles entrantes) ou destination du trafic (pour des règles sortante). 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, pour contrôler le trafic entre lescartes d'interface de réseau virtuelles d'un groupe de sécurité réseau spécifique, vous pouvez écrire les règles qui spécifient le groupe de sécurité réseau propre à la règles 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 d'API REST pour les groupes de sécurité réseau présente quelques différences de base en t par rapport aux listes de sécurité. Pour plus d'informations, reportez-vous à Utilisation de l'API.
Règles par défaut
Un VCN est automatiquement fourni avec une liste de sécurité par défaut qui contient plusieurs règles de sécurité par défaut pour vous aider à commencer à 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 spécifiez une liste de sécurité personnalisée déjà créée dans le VCN.
Pour comparaison, le VCN n'a pas de groupe de sécurité réseau par défaut.
Limites
Les deux fonctionnalités présentent des limites différentes. Reportez-vous aux limites de service pour obtenir la liste des limites applicables et des instructions de demande d'augmentation de limite.
|
Ressource |
Portée |
crédits universels Oracle |
Paiement à l'utilisation ou version d'évaluation Pay As You Go |
|---|---|---|---|
| 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 | |||
| Ressource | Portée | crédits universels Oracle | Paiement à l'utilisation ou version d'évaluation Pay As You Go |
|---|---|---|---|
| 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 |
120 (total des règles entrantes et sortantes) |
120 (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
Nous vous recommandons d'utiliser des groupes de sécurité système pour des composants ayant tous le même état. Par exemple, dans une architecture multiniveaux, vous devez disposer d'un groupe réseau distinct pour chaque niveau. Les VNIC d'un niveau appartiennent toutes au groupe de sécurité réseau de ce niveau. Au sein d'un niveau particulier, des exigences de sécurité spéciales peuvent être stockées dans un sous-ensemble spécifique des cartes d'interfaces réseau virtuelles du niveau. Par conséquent, vous devez créer un autre groupe de sécurité système pour ces règles et placer ce sous-ensemble de cartes d'interface réseau virtuelles à la fois dans le groupe de sécurité système du niveau et le groupe de sécurité système supplémentaire.
Oracle recommande également d'utiliser des groupes de sécurité réseau, car Oracle hiérarchise les groupes de sécurité réseau sur les listes de sécurité lors de l'implémentation de futures améliorations.
Familiarisation avec les règles de liste de sécurité par défaut
Un VCN est automatiquement fourni avec une liste de sécurité par défaut qui contient plusieurs règles de sécurité par défaut pour vous aider à commencer à utiliser le service Networking. Ces règles existent car elles permettent la connectivité de base. Même si vous n'utilisez pas de liste de sécurité ou de liste de sécurité par défaut, familiarisez-vous avec les règles afin de mieux comprendre les types de trafic dont les ressources cloud de mise en réseau ont besoin. Vous pouvez utiliser ces règles dans les groupes de données réseau ou dans toute liste de Sécurité personnalisée que vous configurez.
La liste de sécurité par défaut n'inclut pas de règles permettant d'activer le 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
Un VCN peut avoir des sous-réseaux qui utilisent la liste de sécurité par défaut par défaut. Ne supprimez aucune des règles de sécurité par défaut de la liste, sauf si vous avez d'abord confirmé que les ressources du VCN ne les nécessitent pas. Sinon, vous risquez de perturber la connectivité du VCN.
Confirmer que les règles du pare-feu OS correspondent aux règles de sécurité
Les instances de calcul exécutant des images de plateforme comportent également des règles du pare-feu du système d'exploitation qui contrôlent l'accès à l'instance. Lors de la résolution d'un problème d'accès à une instance, assurez-vous que 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
Si une instance exécute Oracle Autonomous Linux 8.x, Oracle Autonomous Linux 7, Oracle Linux 8, Oracle Linux 7 ou Oracle Linux Cloud Developer 8, 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 --reloadEn 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 offre 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 des problèmes liés aux règles de sécurité et assurer que les cartes d'interface réseau virtuelles reçoivent le trafic approprié.
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 des besoins spécifiques 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, quel que soit l'utilisateur qui crée une carte d'interface réseau virtuelle dans le VCN. Une option consiste à utiliser la liste de sécurité par défaut du VCN, qui est fournie automatiquement avec le VCN et contient un ensemble de règles essentielles par défaut.
Si vous choisissez d'utiliser des listes de sécurité et des groupes d'interface réseau, l'ensemble de règles qui s'applique à une carte d'interface carte d'interface réseau virtuelle particulière est 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 de Venn suivant est une illustration de l'idée.
La VNIC 1 est couverte par la liste de sécurité 1, la liste de sécurité 2, le groupe de sécurité réseau A et le groupe de sécurité réseau B. Un paquet donné est autorisé si une règle de l'une des listes et groupes pertinents autorise le trafic (ou si le trafic fait partie d'une connexion existante suivie). Une mise en garde est émise si les listes contiennent à la fois des règles avec conservation de statuts et sans état couvrant le même trafic. Pour plus d'informations, reportez-vous à Par rapport avec les règles 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 l'entrée du trafic du port TCP 22 entrant pour établir des connexions SSH à l'instance (les 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.
Les règles de sécurité ne sont pas appliquées au trafic impliquant le bloc CIDR 169.254.0.0/16, qui comprend 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é disposent d'un objet
IngressSecurityRuleet d'un objetEgressSecurityRuledistinct. Ces groupes contiennent uniquement un objetSecurityRule. L'attributdirectionde l'objet indique si la règle concerne les trafics entrants ou sortants. - 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 à Compare avec conservation de statut des règles.
-
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 sélectionné.
Types de source autorisésType 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). Pour plus d'informations sur la notation CIDR, reportez-vous à RFC1817 et à RFC1519. Groupe de sécurité réseau Un groupe de sécurité réseau dans le même VCN 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. Si une passerelle de service n'est pas présente dans un VCN, le trafic provenant de l'adresse IP publique d'une adresse OSN peut être acheminé vers un VCN par le biais d'une passerelle NAT ou d'une passerelle Internet. Le trafic parcourt toujours le réseau principal OCI vers le VCN.
Le service source correspond au libellé CIDR de service qui vous intéresse.
-
Type de destination et destination (règles sortantes uniquement) : la destination spécifiée pour une règle sortante dépend du type de destination sélectionné.
Types de destination autorisésType 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). Pour plus d'informations sur la notation CIDR, reportez-vous à RFC1817 et à RFC1519. Groupe de sécurité réseau Groupe de sécurité réseau dans le même VCN 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 qui sont destinés à un service Oracle (comme Object Stockage) via une Passerelle de service. Si aucune passerelle de service n'est présente dans un VCN, le trafic destiné à l'adresse IP publique d'une adresse OSN peut être acheminé vers OSN par le biais d'une passerelle NAT ou d'une passerelle Internet. Le routage via une passerelle du service vous permet de sélectionner les adresses Oracle Services Network (OSN) vers lesquelles acheminer le trafic (choisissez Uniquement Object Storage ou Tous les services).
Le service de destination correspond au libellé CIDR de service OSN 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 ICPM : pour ICMP, vous pouvez indiquer tous les types et tous Les codes, ou un seul type ICMP avec un code facultatif. Si le type a deux 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. Cette option n'est pas prise 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.
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 VCN et, à ce stade, les informations sur le groupe de sécurité réseau de la carte d'interface réseau virtuelle ne sont pas disponibles. Par conséquent, une règles de sécurité qui spécifie le groupe de sécurité système comme source ou destination n'autorise pas ce type de trafic spécifique.
Comparaison avec les règles sans conservation de statut
Lorsque vous créez une règle de sécurité, vous indiquez s'ils s'agit d'une règle avec conservation d'état ou sans conservation d'état. 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 référence au trafic et aux instances Compute. 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.
Par exemple, vous pouvez disposer d'une règle de sécurité entrante avec conservation de statut pour une instance (instance A) qui doit recevoir le trafic HTTP de l'hôte B et y répondre. L'hôte B peut être n'importe quel hôte, qu'il s'agisse d'une instance ou non. L'instance A et l'hôte B communiquent car 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, car les réponses sont automatiquement suivies et autorisées.
Les règles avec conservation de statut stockent les informations dans une table de suivi des connexions sur chaque instance Compute. La taille de cette table est propre à la forme de calcul utilisée (reportez-vous à la page des limites de service pour Suivi de connexion). Lorsque la table de suivi des connexions est pleine, les nouvelles informations d'état ne peuvent pas être ajoutées et les nouvelles connexions subissent une perte de paquets. L'utilisation d'une forme de calcul plus grande vous permet d'avoir une table plus grande, mais cela peut ne pas suffire pour éviter la perte de paquets lors de l'utilisation de règles avec conservation de statut.
Si un sous-réseau a un volume de trafic élevé, nous vous recommandons d'utiliser des règles sans conservation de statut au lieu de règles avec conservation de statut.
Règles sans conservation de statut
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).
Si l'instance A doit initier le trafic HTTP et obtenir la réponse, vous devez disposer 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.
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.
Si, pour quelque raison que ce soit, vous utilisez des codes avec conservation d'état et des codes sans conservation d'état, et qu'un trafic correspond à La fois à Une règle avec conservation d'état et à Une règle sans conservation d'état dans une direction particulière (par exemple, l'entrée), La règle sans conservation d'état est prioritaire et la connexion n'est plus 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 qui correspond aux règles avec conservation d'état (reportez-vous à la section Règles avec conservation d'état et sans conservation d'état). Chaque instance dispose d'un nombre maximal de connexions simultanées qui peut faire l'objet d'un suivi, en fonction de la forme de l'instance.
Afin de connaître le trafic de réponse pour TCP, UDP et ICMP, Oracle effectue un 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)
Pour les autres protocoles, Oracle suit uniquement le protocole et les adresses IP, et non les ports. Cela signifie que lorsqu'une instance lance le trafic vers une autre hôte et que ce trafic est autorisé par la règle de sécurité sortante, tout trafic que l'instance reçoit ensuite par l'instance à partir de cet hôte pendant une période déterminé est considéré comme étant un trafic d'une réponse et est autorisé.
Les connexions suivies sont conservées tant que le trafic est reçu pour la connexion. Si une connexion est inactive assez longtemps, elle expire et est supprimée. Une fois la connexion enlevée, les réponses à une règle de sécurité avec conservation de statut sont supprimées. Le tableau suivant indique les délais d'inactivité par défaut :
| Protocole | Etat | Délai d'inactivité |
|---|---|---|
| TCP | Etabli | 1 jour |
| TCP | Configuration | 1 minute |
| TCP | Fermeture | 2 minutes |
| UDP | Etabli (cela signifie qu'un paquet est reçu dans les deux directions) | 3 minutes |
| UDP | Non établi (paquet reçu dans une seule direction) | 30 secondes |
| ICMP | SANS OBJET | 15 secondes |
| Autre | SANS OBJET | 5 minutes |
Autorisation des messages de repérage de MTU de chemin pour les règles sans état
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 aux instances Compute de recevoir des messages de fragmentation de repérage du MTU de chemins. Cette règle est essentielle pour établir une connexion à des instances. Sans elle, vous risquez de rencontrer des problèmes de connectivité. Pour plus d'informations, reportez-vous à Connexion bloquée.
Règles pour activer 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. Pour envoyer une commande ping vers une instance, assurez-vous qu'elles incluent une règle entrante avec conservation de statutextra permettant d'autoriser le trafic ICMP du type 8 à partir du réseau source à partir duquel vous prévoyez 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. Ne retirez 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, celui-ci 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 vous attendez des instances Compute qu'elles envoient ou reçoivent des paquets UDP volumineux, définissez les ports source et destination des règles de sécurité applicables sur ALL (au contraire d'un numéro de port spécifique).