Sécurisation du service de réseau : VCN, équilibreurs de charge et DNS

Recommandations en matière de sécurité

Le service de réseau offre un ensemble de fonctions pour l'application du contrôle d'accès au réseau et la sécurité du trafic de réseau VCN. Ces fonctions sont présentées dans le tableau suivant.


Fonctionnalité de VCN	Description de la sécurité
Sous-réseaux publics et privés	Votre réseau en nuage virtuel peut être partitionné en sous-réseaux. Historiquement, les sous-réseaux étaient propres à un domaine de disponibilité, mais ils peuvent maintenant être régionaux (couvrant tous les domaines de disponibilité d'une région). Les instances dans des sous-réseaux privés ne peuvent pas avoir d'adresses IP publiques. Les instances dans des sous-réseaux publics peuvent avoir des adresses IP publiques, à votre discrétion.
Règles de sécurité	Les règles de sécurité offrent de capacités de pare-feu avec état et sans état pour contrôler l'accès réseau à vos instances. Pour mettre en oeuvre des règles de sécurité dans votre réseau VCN, vous pouvez utiliser des groupes de sécurité de réseau ou des listes de sécurité. Pour plus d'informations, voir Comparaison des listes de sécurité et des groupes de sécurité de réseau.
Passerelles	Les passerelles permettent à des ressources dans un réseau VCN de communiquer avec des destinations extérieures au réseau VCN. Les passerelles sont les suivantes : Passerelle Internet : Pour la connectivité Internet (pour les ressources avec adresses IP publiques dans des sous-réseaux publics) Passerelle NAT : Pour une connectivité Internet sans exposer les ressources aux connexions Internet entrantes (pour les ressources dans des sous-réseaux privés) Dynamic routing gateway (DRG): for connectivity to networks outside the VCN's region (for example, your on-premises network by way of a Site-to-Site VPNor FastConnect, or a peered VCN in another region) Passerelle de service : Pour la connectivité privée aux services Oracle, par exemple Stockage d'objets Passerelle d'appairage locale : Pour la connectivité à un réseau VCN appairé dans la même région
Règles de table de routage	Les tables de routage contrôlent l'acheminement du trafic depuis vos sous-réseaux VCN vers des destinations en dehors du réseau VCN. Les cibles d'acheminement peuvent être des passerelles VCN ou une adresse IP privée dans le réseau VCN.
Politiques GIA pour virtual-network-family	Les politiques GIA spécifient l'accès et les actions que les groupes GIA peuvent effectuer sur les ressources dans un réseau VCN. Par exemple, des politiques GIA peuvent accorder des privilèges d'administration aux administrateurs de réseau qui gèrent les réseaux en nuage virtuels et des autorisations réduites aux utilisateurs ordinaires.

Oracle recommande de surveiller périodiquement les journaux d'Oracle Cloud Infrastructure Audit pour vérifier les modifications apportées aux groupes de sécurité de réseau VCN, aux listes de sécurité, aux règles de table de routage et aux passerelles VCN.

Segmentation de réseau : Sous-réseaux VCN

Formulez une stratégie de sous-réseaux à plusieurs niveaux pour le réseau VCN, afin de contrôler l'accès au réseau. Un schéma de conception commun présente les niveaux de sous-réseau suivants :
1. Sous-réseau DMZ pour les équilibreurs de charge
2. Sous-réseau public pour les hôtes accessibles de l'extérieur, tels que les instances NAT, les instances de détection d'intrusion et les serveurs d'applications Web
3. Sous-réseau privé pour les hôtes internes, par exemple les bases de données
Aucun routage spécial n'est requis pour que les instances des différents sous-réseaux puissent communiquer. Vous pouvez toutefois contrôler les types de trafic entre les différents niveaux en utilisant les groupes de sécurité de réseau ou les listes de sécurité du réseau VCN.
Les instances du sous-réseau privé ont uniquement des adresses IP privées et ne peuvent être atteintes que par d'autres instances dans le réseau VCN. Oracle recommande de placer les hôtes sensibles à la sécurité (système de base de données, par exemple) dans un sous-réseau privé et d'utiliser des règles de sécurité pour contrôler le type de connectivité aux hôtes dans un sous-réseau public. En plus des règles de sécurité de réseau VCN, configurez des pare-feu basés sur l'hôte, tels que iptables, pare-feu pour le contrôle d'accès au réseau, comme mécanisme de défense en profondeur.
Vous pouvez ajouter une passerelle de service à votre réseau VCN pour permettre aux systèmes de base de données dans le sous-réseau privé d'être sauvegardés directement dans le stockage d'objets sans passer par Internet. Pour cela, vous devez configurer les règles de routage et de sécurité. Pour plus d'informations sur les systèmes de base de données sans système d'exploitation ou de machine virtuelle, voir Configurer le réseau. Pour plus d'informations sur les systèmes de base de données Exadata, voir Configuration du réseau pour les instances Exadata Cloud Service.

Contrôle de l'accès au réseau : Règles de sécurité de réseau VCN

Utilisez les règles de sécurité de votre réseau VCN pour restreindre l'accès réseau aux instances. Une règle de sécurité est avec état par défaut, mais peut également être configurée pour être sans état. Une pratique commune consiste à utiliser des règles sans état pour les applications haute performance. Dans le cas où le trafic réseau correspond à la fois à des listes de sécurité avec état et sans état, la règle sans état a préséance. Pour plus d'informations sur la configuration de règles de sécurité de réseau VCN, voir Règles de sécurité.
Pour éviter les accès non autorisés ou les attaques sur les instances de calcul, Oracle recommande d'utiliser une règle de sécurité de réseau VCN pour autoriser l'accès SSH ou RDP à partir de blocs CIDR autorisés uniquement plutôt que de laisser les instances ouvertes sur Internet (0.0.0.0/0). Pour une sécurité accrue, vous pouvez activer temporairement l'accès SSH (port 22) ou RDP (port 3389) au besoin à l'aide de l'API VCN UpdateNetworkSecurityGroupSecurityRules (si vous utilisez des groupes de sécurité de réseau) ou UpdateSecurityList (si vous utilisez des listes de sécurité). Pour plus d'informations sur l'activation de l'accès RDP, voir Pour activer l'accès RDP sous Création d'une instance. Pour effectuer des vérifications d'état des instances, Oracle recommande de configurer des règles de sécurité de réseau VCN pour autoriser les commandes ping ICMP. Pour plus d'informations, voir Règles pour activer Ping.
Les hôtes bastions sont des entités logiques qui fournissent un accès public sécurisé aux ressources cibles dans le nuage que vous ne pouvez pas atteindre autrement à partir d'Internet. Les hôtes bastions résident dans un sous-réseau public et établissent l'infrastructure de réseau nécessaire pour connecter un utilisateur à une ressource cible dans un sous-réseau privé.
Les groupes de sécurité de réseau VCN et les listes de sécurité permettent d'assurer un contrôle essentiel de l'accès réseau sécurisé aux instances de calcul, et il est important d'empêcher toute modification involontaire ou non autorisée des groupes de sécurité de réseau et des listes de sécurité. Pour empêcher les modifications non autorisées, Oracle recommande d'utiliser des politiques IAM pour autoriser uniquement les administrateurs de réseau à apporter des modifications au groupe de sécurité de réseau et à la liste de sécurité.

Connectivité sécurisée : Passerelles VCN et appairage FastConnect

Les passerelles VCN fournissent une connectivité externe (Internet, sur place ou réseau VCN appairé) aux hôtes du réseau VCN. Voir le tableau plus haut dans cette rubrique pour la liste des types de passerelle. Oracle recommande l'utilisation d'une politique GIA pour autoriser uniquement les administrateurs de réseau à créer ou à modifier des passerelles VCN.
Évaluez soigneusement la nécessité de donner un accès Internet à une instance quelconque. Par exemple, vous ne voulez pas permettre un accès Internet accidentel aux instances de base de données sensibles. Pour qu'une instance dans un VCN soit accessible publiquement à partir d'Internet, vous devez configurer les options de réseau VCN suivantes :
- L'instance doit être dans un sous-réseau public du réseau VCN.
- Le réseau VCN qui contient l'instance doit disposer d'une passerelle Internet activée et configurée comme cible de routage pour le trafic sortant.
- Une adresse IP publique doit être affectée à l'instance.
- La liste de sécurité VCN du sous-réseau de l'instance doit être configurée pour autoriser le trafic entrant depuis 0.0.0.0/0. Ou si vous utilisez des groupes de sécurité de réseau, l'instance doit se trouver dans un groupe qui autorise ce trafic.
Un RPV IPSec assure une connectivité entre le réseau sur place et le réseau VCN du client. Vous pouvez créer deux tunnels IPSec pour une haute disponibilité. Pour plus d'informations sur la création de tunnels RPV pour connecter la passerelle de routage dynamique de VCN aux CPE du client, voir RPV site à site.
L'appairage FastConnect vous permet de connecter votre réseau sur place à votre réseau VCN avec un circuit privé afin que le trafic ne passe pas par le réseau Internet public. Vous pouvez configurer un appairage privé (pour connexion à des adresses IP privées) ou un appairage public (pour connexion aux points d'extrémité publics d'Oracle Cloud Infrastructure, comme pour le service de stockage d'objets). Pour plus d'informations sur les options d'appairage FastConnect, voir FastConnect.

Boîtiers de sécurité virtuels dans un réseau VCN

Le service de réseau vous permet de mettre en oeuvre des fonctions de sécurité de réseau telles que la détection d'une intrusion, des pare-feu au niveau de l'application et la traduction d'adresses de réseau (bien que vous puissiez utiliser à la place une passerelle NAT avec votre réseau VCN). Pour ce faire, vous devez router tout le trafic de sous-réseau vers un hôte de sécurité de réseau en utilisant des règles de table de routage qui utilisent une adresse IP privée VCN locale comme destination. Pour plus d'informations, voir Utilisation d'une adresse IP privée comme cible d'acheminement. Pour une haute disponibilité, vous pouvez affecter à l'hôte de sécurité de la passerelle une adresse IP privée secondaire, que vous pouvez déplacer vers une carte vNIC sur un hôte de secours en cas de défaillance de l'hôte principal. La saisie complète des paquets de réseau ou des journaux de flux de réseau sur les instances NAT est possible à l'aide de tcpdump. Les journaux peuvent être chargés périodiquement dans un seau de stockage d'objets.
Les boîtiers de sécurité virtuels peuvent être exécutés en tant que machines virtuelles sur un modèle d'hyperviseur de client sur une instance sans système d'exploitation. Les machines virtuelles de boîtier de sécurité virtuel s'exécutant sur l'instance sans système d'exploitation du client ont chacune leur propre carte vNIC secondaire, ce qui assure une connectivité directe à d'autres instances et services dans le réseau VCN de la carte vNIC. Pour plus d'informations sur l'activation de l'utilisation d'un point de vente (BYOH) sur une instance sans système d'exploitation à l'aide d'un hyperviseur KVM à code source libre, voir Utilisation de votre propre système d'exploitation invité d'hyperviseur.
Les boîtiers de sécurité virtuels peuvent également être installés sur les machines virtuelles de calcul, où des images VMDK ou QCOW2 de boîtiers de sécurité peuvent être importées à l'aide de la fonction d'utilisation d'images personnelles. Toutefois, en raison de dépendances de l'infrastructure, la fonction d'utilisation d'images personnelles peut ne pas fonctionner pour certains boîtiers, auquel cas le modèle d'utilisation d'hyperviseur personnel serait une autre option. Pour plus d'informations sur l'importation d'images de boîtier dans Oracle Cloud Infrastructure, voir Utiliser sa propre image (BYOI).

Équilibreurs de charge

Les équilibreurs de charge d'Oracle Cloud Infrastructure permettent des connexions TLS de bout en bout entre les applications d'un client et son réseau VCN. Il est possible de mettre fin à la connexion TLS à un équilibreur de charge HTTP ou à un serveur dorsal au moyen d'un équilibreur de charge TCP. Les équilibreurs de charge utilisent TLS1.2 par défaut. Pour plus d'informations sur la configuration d'un module d'écoute HTTPS, voir Modules d'écoute pour les équilibreurs de charge. Vous pouvez également charger vos propres certificats TLS. Pour plus d'informations, voir Certificats SSL pour les équilibreurs de charge.
Vous pouvez configurer l'accès réseau aux équilibreurs de charge en utilisant des groupes de sécurité de réseau VCN ou des listes de sécurité. Cette méthode fournit une fonctionnalité similaire aux pare-feu d'équilibreur de charge traditionnels. Pour les équilibreurs de charge publics, Oracle recommande d'utiliser un sous-réseau public régional (par exemple, le sous-réseau DMZ) afin d'instancier les équilibreurs de charge dans une configuration haute disponibilité sur deux domaines de disponibilité différents. Vous pouvez configurer les règles de pare-feu d'équilibreur de charge en définissant les groupes de sécurité de réseau de l'équilibreur de charge ou les listes de sécurité du sous-réseau. Pour plus d'informations sur la création des listes de sécurité de l'équilibreur de charge, voir Mettre à jour les listes de sécurité de l'équilibreur de charge et autoriser le trafic Internet au module d'écoute. De même, vous devez configurer les groupes de sécurité de réseau VCN ou les listes de sécurité pour les serveurs dorsaux afin de limiter le trafic à celui en provenance des équilibreurs de charge publics seulement. Pour plus d'informations sur la configuration des listes de sécurité de serveur dorsal, voir Mettre à jour les règles pour limiter le trafic aux serveurs dorsaux.

Enregistrements et zones DNS

Les enregistrements et zones DNS sont critiques pour l'accessibilité des propriétés Web. Des mises à jour incorrectes ou des suppressions non autorisées pourraient entraîner l'interruption des services, dont l'accès se fait au moyen des noms DNS. Oracle recommande de limiter les utilisateurs IAM qui peuvent modifier les zones et les enregistrements DNS.

Politiques de pilotage pour la gestion du trafic DNS

Des mises à jour incorrectes ou des suppressions non autorisées des politiques de pilotage pour la gestion du trafic DNS pourraient entraîner une interruption des services en raison d'une mauvaise direction du trafic ou d'un échec de basculement. Oracle recommande de limiter les utilisateurs IAM qui peuvent modifier les politiques de pilotage pour la gestion du trafic DNS.

Exemples de politique de sécurité

Accorder aux utilisateurs un accès en lecture seule aux listes de sécurité

Les administrateurs de réseau sont les personnes qui doivent être en mesure de créer et de gérer des groupes de sécurité de réseau et les listes de sécurité.

Il est toutefois possible que des utilisateurs du réseau aient de connaître les règles de sécurité dans une liste de sécurité ou un groupe de sécurité de réseau particulier.

La première ligne dans l'exemple de politique suivant permet au groupe NetworkUsers de voir les listes de sécurité et leur contenu. Cette politique ne permet pas au groupe de créer, d'attacher, de supprimer ou de modifier les listes de sécurité.

La deuxième ligne permet au groupe NetworkUsers de voir les règles de sécurité dans les groupes de sécurité de réseau, ainsi que les cartes vNIC et les ressources parents dans les groupes de sécurité. La deuxième ligne ne permet pas au groupe NetworkUsers de modifier les règles de sécurité dans les groupes de sécurité de réseau.

Allow group NetworkUsers to inspect security-lists in tenancy
Allow group NetworkUsers to use network-security-groups in tenancy

Empêcher les utilisateurs de créer une connexion externe à Internet

Dans certains cas, vous pourriez avoir besoin d'empêcher les utilisateurs de créer une connexion Internet externe à leur réseau VCN. Dans l'exemple de politique suivant, le groupe NetworkUsers ne peut pas créer de passerelle Internet.

Allow group NetworkUsers to manage internet-gateways in tenancy
 where request.permission!='INTERNET_GATEWAY_CREATE'

Empêcher les utilisateurs de mettre à jour les enregistrements et zones DNS

Dans l'exemple de politique suivant, le groupe NetworkUsers ne peut pas supprimer ni mettre à jour les enregistrements et zones DNS.

Allow group NetworkUsers to manage dns-records in tenancy
 where all {request.permission!='DNS_RECORD_DELETE', 
            request.permission!='DNS_RECORD_UPDATE'} 
Allow group NetworkUsers to manage dns-zones in tenancy
 where all {request.permission!='DNS_ZONE_DELETE', 
            request.permission!='DNS_ZONE_UPDATE'}

Commandes d'interface de ligne de commande utiles

Dans tous les exemples qui suivent, les variables d'environnement $T, $C et $VCN sont réglées à l'OCID de la location, à l'OCID du compartiment et à l'OCID du réseau VCN, respectivement.

Répertorier les listes de sécurité ouvertes dans un VCN

# list open (0.0.0.0/0) security lists in VCN $VCN in compartment $C 
oci network security-list list -c $C --vcn-id $VCN | grep "source" | grep "\"0.0.0.0/0\""

Répertorier les passerelles dans un VCN

# list all internet gateways in VCN $VCN in compartment $C 
oci network internet-gateway list -c $C --vcn-id $VCN 
# list all DRGs in compartment $C 
oci network drg list -c $C 
# list all local peering gateways in vcn $VCN in compartment $C 
oci network local-peering-gateway list -c $C --vcn-id $VCN

Répertorier les règles de table de routage dans un VCN

# list route table rules in VCN $VCN in compartment $C 
oci network route-table list -c $C --vcn-id $VCN

Documentation sur Oracle Cloud Infrastructure