Règles de sécurité

À propos des cartes vNIC et des ressources parents

Une carte virtuelle est un composant du service de réseau qui permet à une ressource en réseau, telle qu'une instance de calcul, de se connecter à un réseau en nuage virtuel (VCN). La carte vNIC détermine comment l'instance se connecte à des points d'extrémité à l'intérieur et à l'extérieur du réseau VCN. Chaque carte vNIC réside dans un sous-réseau d'un VCN.

Quand vous créez une instance de calcul, une carte vNIC est automatiquement générée pour celle-ci dans son sous-réseau. L'instance est considérée comme la ressource parent de la carte vNIC. Vous pouvez ajouter des cartes vNIC supplémentaires (secondaires) à une instance de calcul. Pour cette raison, les cartes vNIC d'une instance sont mises en évidence parmi les ressources associées à une instance de calcul dans la console.

Il existe d'autres types de ressource parent dont la création entraîne automatiquement celled'une carte vNIC. Par exemple, lorsque vous créez un équilibreur de charge, le service Équilibreur de charge génère automatiquement des cartes vNIC pour le trafic d'équilibre dans le jeu dorsal. De plus, lorsque vous créez un système de base de données, le service de base de données génère automatiquement des cartes vNIC sous forme de noeuds de ce système. Ces services créent et gèrent ces cartes vNIC pour vous. Pour cette raison, ces cartes vNIC ne sont pas aussi évidentes dans la console qu'elles le sont pour les instances de calcul.

Pour utiliser un groupe de sécurité de réseau, placez dedans les cartes vNIC de votre choix. Toutefois, c'est généralement avec la ressource parent que vous travaillez lorsque vous ajoutez une carte vNIC au groupe, et non avec la carte elle-même. Par exemple, lorsque vous créez une instance de calcul, vous pouvez éventuellement lui spécifier un groupe de sécurité de réseau. Même si théoriquement vous placez l'instance dans le groupe, c'est sa carte vNIC principale que vous mettez en fait dans le groupe de sécurité de réseau. Les règles de sécurité du groupe s'appliquent à cette carte vNIC, et non à l'instance. En outre, si vous ajoutez une carte vNIC secondaire à l'instance, vous pouvez lui affecter un groupe de sécurité de réseau. Les règles s'appliquent alors à cette carte, et non à l'instance. Notez que toutes les cartes vNIC d'un groupe de sécurité de réseau donné doivent se trouver dans le réseau en nuage virtuel auquel ce groupe appartient.

De même, lorsque vous placez un équilibreur de charge dans un groupe de sécurité de réseau, vous mettez théoriquement l'équilibreur dans le groupe. Mais ce sont en fait les cartes vNIC gérées par le service Équilibreur de charge que vous placez dans le groupe.

La gestion de l'appartenance d'une carte vNIC à un groupe NSG s'effectue au niveau de la ressource parent et non à celui du groupe lui-même. Autrement dit, pour ajouter une ressource parent à un groupe de sécurité de réseau, vous exécutez l'action sur la ressource (en indiquant les groupes auxquels elle doit être ajoutée). Vous ne pouvez pas exécuter l'action sur le groupe de sécurité de réseau (en spécifiant les cartes vNIC ou les ressources parents à lui ajouter). De même, pour retirer une carte vNIC d'un groupe, vous exécutez cette action en mettant à jour la ressource parent et non le groupe. Par exemple, pour ajouter la carte vNIC d'une instance de calcul à un groupe de sécurité de réseau, vous mettez à jour les propriétés de la carte et spécifiez le groupe. Par exemple, avec l'API REST, vous appelez UpdateVnic. Dans la console, vous affichez l'instance, puis la carte vNIC qui vous intéresse, puis y modifiez les propriétés de cette dernière.

Pour obtenir la liste des ressources parents qui prennent en charge l'utilisation des NSG, voir Prise en charge des groupes de sécurité de réseau.

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

L'écriture des règles de sécurité pour des NSG diffère grandement de celle des listes de sécurité.

Dans les règles destinées à un groupe de sécurité de réseau, vous pouvez désigner celui-ci comme source (pour les règles de trafic entrant) ou comme destination (pour les règles de trafic sortant) du trafic. Pour les règles de liste de sécurité, vous spécifiez un CIDR comme source ou destination.

Étant donné que vous pouvez spécifier un NSG, vous pouvez facilement écrire des règles pour contrôler le trafic entre deux groupes de sécurité différents. Ces groupes doivent se trouver dans le même réseau en nuage virtuel.

De plus, si vous voulez contrôler le trafic entre les cartes vNIC d'un groupe de sécurité de réseau spécifique (NSG), vous pouvez écrire des règles qui indiquent le NSG de la règle comme source (pour les règles de trafic entrant) ou comme destination (pour les règles de trafic sortant).

Pour plus d'informations, voir Aperçu des groupes de sécurité de réseau.

Différences concernant l'API REST

Le modèle d'API REST pour les groupes de sécurité présente quelques différences de base avec les listes de sécurité. Pour plus d'informations, voir Utilisation de l'API.

Règles par défaut

Votre réseau en nuage virtuel 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 permettre d'utiliser immédiatement le service de réseau. Lorsque vous créez un sous-réseau, la liste de sécurité par défaut lui est associée sauf si vous spécifiez une liste personnalisée figurant déjà dans le VCN.

À titre de comparaison, le VCN NE DISPOSE PAS de groupe de sécurité de réseau par défaut.

Limites

Les deux fonctions ont des limites différentes. Voir Limites de service pour une liste des limites applicables et des instructions pour demander l'augmentation d'une limite.

Utiliser des groupes de sécurité de réseau

Oracle recommande d'utiliser des groupes de sécurité de réseau pour les composants dont la situation en matière de sécurité est identique. Par exemple, dans une architecture multiniveau, vous disposeriez d'un groupe de sécurité de réseau distinct pour chaque niveau. Les cartes vNIC d'un niveau donné appartiendraient toutes au groupe de ce niveau. Dans un niveau donné, vous auriez peut-être un sous-ensemble particulier de ses cartes vNIC dotées d'exigences de sécurité spéciales supplémentaires. Par conséquent, vous créeriez un autre groupe pour ces règles supplémentaires, puis placeriez ce sous-ensemble de cartes vNIC dans le groupe du niveau et dans le groupe supplémentaire.

Oracle recommande également d'utiliser des groupes de sécurité de réseau, car la priorité leur sera accordée par rapport aux listes de sécurité lors de la mise en oeuvre des améliorations futures.

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

Votre réseau en nuage virtuel 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 permettre d'utiliser immédiatement le service de réseau. Ces règles existent car elles activent la connectivité de base. Même si vous choisissez de ne pas utiliser de listes de sécurité ou la liste par défaut, familiarisez-vous avec les règles pour mieux comprendre les types de trafic requis par les ressources réseau en nuage. Vous pourriez souhaiter utiliser ces règles dans vos groupes de sécurité ou dans des listes de sécurité que vous avez configurées.

La liste de sécurité par défaut n'inclut pas de règles pour activer la commande ping. Si vous devez utiliser cette commande, voir Règles d'activation de la commande ping.

Ne pas supprimer les règles de sécurité par défaut sans discernement

Votre réseau en nuage 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 sans confirmer au préalable que les ressources de votre VCN n'en ont pas besoin. Sinon, vous risquez d'interrompre la connectivité de votre VCN.

Confirmer que les règles de pare-feu du système d'exploitation sont adaptées aux règles de sécurité

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

Utiliser les mesures liées aux cartes vNIC pour dépanner les paquets abandonnés à cause de règles de sécurité

Le service de réseau offre des mesures pour les cartes vNIC. Ces mesures montrent les niveaux de trafic sur la carte vNIC (paquets et octets). Deux mesures concernent les paquets entrants et sortants qui enfreignent les règles de sécurité et sont donc abandonnés. Vous pouvez utiliser ces mesures pour résoudre les problèmes liés aux règles de sécurité et déterminer si vos cartes vNIC reçoivent le trafic souhaité.

Règles avec état

Une règle de sécurité marquée avec état indique que vous voulez utiliser le suivi de connexion pour le trafic qui correspond à cette règle. Lorsqu'une instance reçoit du trafic correspondant à la règle de trafic entrant avec état, la réponse est suivie et son retour à l'hôte d'origine est autorisé automatiquement, quelles que soient les règles de trafic sortant applicables à l'instance. Et lorsqu'une instance envoie du trafic correspondant à une règle de trafic sortant avec état, la réponse entrante est automatiquement autorisée, peu importe les règles de trafic entrant.

Par exemple, vous pouvez avoir une règle de trafic entrant avec état pour une instance (instance A) qui doit recevoir du trafic HTTP de l'hôte B et y répondre. L'hôte B peut être tout hôte, que ce soit une instance ou non. L'instance A et l'hôte B communiquent car la règle de trafic entrant avec état autorise le trafic depuis n'importe quelle adresse IP source (0.0.0.0/0) vers le port de destination 80 uniquement (protocole TCP). Aucune règle de trafic sortant n'est nécessaire pour autoriser le trafic de réponse, car les réponses sont automatiquement suivies et autorisées.

Règles sans état

La figure suivante présente l'instance A et l'hôte B de l'exemple précédent, mais cette fois avec des règles de sécurité sans état. Comme la règle avec état de la section précédente, la règle de trafic entrant sans état autorise le trafic depuis toutes les adresses IP et tous les ports, sur le port de destination 80 (à l'aide du protocole TCP). Pour autoriser le trafic de réponse, une règle de trafic sortant sans état correspondante doit autoriser le trafic vers toute adresse IP de destination (0.0.0.0/0) et tout port, à partir du port source 80 (à l'aide du protocole TCP).

Si l'instance A doit plutôt lancer le trafic HTTP et obtenir la réponse, un autre jeu de règles sans état est nécessaire. Comme l'illustre la figure suivante, la règle de trafic sortant indique port source = tous et port de destination = 80 (HTTP). La règle de trafic entrant indiquerait donc : port source =  80 et port de destination = tous.

Si vous deviez utiliser une liaison de port sur l'instance A pour spécifier exactement le port d'origine du trafic HTTP, vous pourriez l'indiquer comme port source dans la règle de trafic sortant et comme port de destination dans la règle de trafic entrant.

Détails de suivi de la connexion pour les règles avec état

Oracle se sert du suivi de connexion pour autoriser les réponses au trafic qui correspond aux règles avec état (voir Règles avec état et règles sans état). Pour chaque instance, un nombre maximal de connexions concurrentes peuvent faire l'objet d'un suivi en fonction de la forme de l'instance.

Pour déterminer le trafic de réponse pour TCP, UDP et ICMP, Oracle effectue le suivi des connexions sur ces éléments pour le paquet :

• Protocole
• Adresses IP d'origine et de destination
• Ports d'origine et de destination (pour TCP et UDP uniquement)

Les connexions suivies sont maintenues tant que le trafic est reçu pour la connexion. Si une connexion est inactive suffisamment longtemps, elle expire et est supprimée. Après la suppression, les réponses à une règle de sécurité avec état sont supprimées. Le tableau suivant présente les délais d'inactivité par défaut :

Activation des messages de détection de MTU de chemin pour les règles sans état

Si vous décidez d'utiliser des règles de sécurité sans état pour permettre le trafic vers/depuis des points d'extrémité en dehors du VCN, il est important d'ajouter une règle de sécurité autorisant le trafic ICMP entrant de type 3 code 4 à partir de la source 0.0.0.0/0 et de tout port source. Cette règle permet à vos instances de recevoir les messages de fragmentation de détection de MTU de chemin. Cette règle est indispensable à l'établissement d'une connexion à vos instances. Sans elle, vous risquez de rencontrer des problèmes de connectivité. Pour plus d'informations, voir Interruption de connexion.