Règles de sécurité

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 de calcul, 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 de calcul, 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 de calcul. 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 de calcul 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 Balancer 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 de calcul.

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 de calcul, 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 Balancer 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 de calcul 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. Reportez-vous aux limites de service pour obtenir la liste des limites applicables et des instructions de demande d'augmentation de limite.

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é

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
								
sudo 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é.

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.

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

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.

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)

Les connexions suivies sont conservées tant que le trafic est reçu pour la connexion. Si une connexion est inactive pendant un certain délai, elle expire et est enlevé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 :

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.