Utiliser le service Bastion pour accéder aux ressources d'un sous-réseau privé
Oracle Cloud Infrastructure Bastion fournit un accès SSH privé et limité dans le temps aux ressources qui n'ont pas d'adresses publiques.
Les bastions sont des passerelles ou des proxies. Il s'agit d'entités logiques qui fournissent un accès sécurisé aux ressources dans le cloud que vous ne pouvez pas atteindre à partir d'Internet. Les bastions résident dans un sous-réseau public et établissent l'infrastructure réseau nécessaire pour connecter un utilisateur à une ressource dans un sous-réseau privé. OCI Bastion est un service d'infrastructure qui peut remplacer un serveur de bastion que vous créez vous-même dans Oracle Cloud Infrastructure (OCI).
L'intégration à Oracle Cloud Infrastructure Identity and Access Management (IAM) vous permet de contrôler qui peut gérer un bastion ou une session au sein d'un service de bastion. L'intégration à Oracle Cloud Infrastructure Audit vous permet de surveiller les actions d'administration liées au service de bastion et aux sessions de bastion.
Architecture
Cette architecture présente deux façons de se connecter à des sous-réseaux privés : l'une consiste à se connecter via un sous-réseau cible intermédiaire et l'autre à se connecter directement au sous-réseau contenant les ressources protégées.
Lorsque vous utilisez OCI Bastion, vous pouvez indiquer une liste d'autorisation de bloc de routage interdomaine sans classe (CIDR) et une durée de vie maximale de session (TTL). OCI Bastion crée un chemin réseau entre le bastion VCN et le client VCN via une connexion inversée. Les sessions sont généralement créées par des utilisateurs ou des opérateurs.
Le schéma suivant illustre cette architecture de référence.
Description de l'illustration architecture-use-bastion-service.png
architecture-utilisation-bastion-service-oracle.zip
L'architecture comporte les composants suivants :
- Région OCI
Une région OCI est une zone géographique précise qui contient des centres de données, hébergeant des domaines de disponibilité. Les régions sont indépendantes les une des autres et peuvent les séparer d'un pays ou d'un continent à l'autre par de grandes distances.
- Domaine de disponibilité
Les domaines de disponibilité sont des centres de données autonomes indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées de celles des autres, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent ni infrastructure (par exemple, alimentation, système de refroidissement), ni réseau de domaine de disponibilité interne. Par conséquent, une panne sur un domaine de disponibilité ne doit pas affecter les autres domaines de disponibilité de la région.
- Domaine de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec une alimentation et un matériel indépendants. Lorsque vous répartissez des ressources entre plusieurs domaines de pannes, vos applications peuvent tolérer les pannes du serveur physique, la maintenance du système et les pannes d'alimentation au sein d'un domaine de pannes.
- Réseau cloud virtuel (VCN) et sous-réseaux
Un réseau cloud virtuel est un réseau personnalisable défini par logiciel que vous configurez dans une région OCI. Comme les Réseaux de centre de données traditionnels, les Réseaux cloud virtuels vous donnent un contrôle sur l'environnement réseau. Un VCN peut comporter plusieurs blocs de routage interdomaine sans classe (CIDR) qui ne se chevauchent pas et que vous pouvez modifier une fois le VCN créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
- OCI Bastion
Oracle Cloud Infrastructure Bastion fournit un accès sécurisé limité et limité dans le temps aux ressources qui n'ont pas d'adresses publiques et qui nécessitent des contrôles stricts d'accès aux ressources, tels que Bare Metal et les machines virtuelles, Oracle MySQL Database Service, Autonomous Transaction Processing (ATP), Oracle Cloud Infrastructure Kubernetes Engine (OKE) et toute autre ressource qui autorise l'accès au protocole SSH (Secure Shell Protocol). Avec le service OCI Bastion, vous pouvez activer l'accès aux hôtes privés sans déployer ni tenir à jour un hôte de saut. En outre, vous bénéficiez d'une meilleure posture de sécurité avec des droits d'accès basés sur les identités et une session SSH centralisée, auditée et limitée dans le temps. OCI Bastion élimine le besoin d'une adresse IP publique pour l'accès au bastion, ce qui élimine les tracas et la surface d'attaque potentielle lors de la fourniture d'un accès distant.
- Back-end du service Bastion
Le back-end Oracle Cloud Infrastructure Bastion stocke la configuration de session et les clés publiques SSH utilisées pour accorder l'accès aux systèmes cible. Si nécessaire, les systèmes cible utilisent la passerelle de service pour accéder au back-end OCI Bastion.
- Adresse privée
Une adresse privée connecte le bastion OCI aux sous-réseaux cible. Le sous-réseau cible peut être un sous-réseau distinct pour un contrôle plus détaillé ou sur le même sous-réseau des instances auxquelles vous voulez accéder.
Recommandations
Vos exigences peuvent différer de l'architecture décrite ici. Utilisez les recommandations suivantes comme point de départ.
- VCN
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher aux sous-réseaux dans le VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adressage IP privé standard.
Sélectionnez des blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur site ou un autre fournisseur cloud) sur lequel vous prévoyez de configurer des connexions privées.
Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.
Lorsque vous concevez les sous-réseaux, tenez compte de vos exigences en matière de flux de trafic et de sécurité. Associez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, ce qui peut servir de limite de sécurité.
Utilisez des sous-réseaux régionaux.
Chaque bastion provisionné prend deux adresses IP à partir du sous-réseau cible. Choisissez le bloc CIDR en fonction du nombre de bastions à provisionner sur un sous-réseau particulier. Par exemple, si vous disposez d'un sous-réseau avec un CIDR /30, cela signifie que vous disposez de deux adresses utilisables et que vous disposez d'une ressource cible au sein de ce CIDR, vous n'avez pas suffisamment d'adresses pour provisionner un bastion. Dans ce cas, le provisionnement du bastion échouera. Nous recommandons que le sous-réseau cible soit plus large que /29.
- Cloud Guard
Clonez et personnalisez les recettes par défaut fournies par Oracle pour créer des recettes personnalisées de détecteur et de répondeur. Ces recettes vous permettent d'indiquer le type de violation de sécurité qui génère un avertissement et les actions autorisées à y être effectuées. Par exemple, vous pouvez détecter les buckets OCI Object Storage dont la visibilité est définie sur Public.
Appliquez Oracle Cloud Guard au niveau de la location pour couvrir la portée la plus large et réduire la charge administrative liée à la maintenance de plusieurs configurations.
Vous pouvez également utiliser la fonctionnalité de liste gérée pour appliquer certaines configurations aux détecteurs.
- Security Zones
Pour les ressources nécessitant une sécurité maximale, Oracle recommande d'utiliser des zones de sécurité. Une zone de sécurité est un compartiment associé à une recette de stratégies de sécurité définie par Oracle basée sur les meilleures pratiques. Par exemple, les ressources d'une zone d'accès ne doivent pas être accessibles à partir du réseau Internet public et doivent être cryptées à l'aide de clés gérées par l'utilisateur. Lorsque vous créez et mettez à jour des ressources dans une zone de sécurité, OCI valide les opérations par rapport aux stratégies de la recette et empêche les opérations qui violent l'une des stratégies.
- OCI Bastion
Le fait d'indiquer la durée de vie au niveau du bastion garantit qu'aucune des sessions créées dans le contexte de ce bastion n'a une durée de vie plus longue que le bastion lui-même. Définissez la durée de vie sur la limite minimale pour votre cas d'emploi. La valeur minimale est de 30 minutes et la valeur maximale est de 3 heures. La durée de vie peut également être configurée au niveau de la session.
Le bloc CIDR utilisé pour une liste d'autorisation doit être aussi étroit que possible pour votre scénario. Cela vous permet de restreindre les plages d'adresses IP pour les connexions SSH qui peuvent accéder aux ressources cible privées.
Prenons la taille du sous-réseau cible associé à OCI Bastion et le nombre d'instances de bastion souhaitées. Chaque instance OCI Bastion prend 2 adresses IP. Donc, il est préférable d'avoir une plage /29 (au moins) pour qu'elle ait 6 adresses IP utilisables. /30 aurait 2 adresses IP mais si à l'avenir vous voulez que la deuxième instance du bastion pointe vers le même sous-réseau, vous ne pourrez pas le créer. Le sous-réseau cible peut être le sous-réseau dans lequel se trouve votre ressource cible ou d'autres sous-réseaux dans le VCN cible.
Recommandations relatives aux stratégies de sécurité :
- Les règles entrantes sur le sous-réseau qui dispose des ressources cible doivent autoriser le trafic TCP entrant à partir d'une seule adresse IP qui est l'adresse IP privée du bastion.
- Indiquez le port exact sur une destination, par exemple 22 pour Linux, 3389 pour Windows, 33060 pour MySql, etc. Ne pas utiliser ALL pour les ports.
Utilisez des stratégies IAM spécifiques pour les scénarios d'administration et d'opérateur.
Points à prendre en compte
- Région
Oracle Cloud Infrastructure Bastion est un service régional. Par exemple, vous devez créer un bastion dans la région PHX pour accéder aux ressources de la région PHX. Un bastion d'une région ne peut pas être utilisé pour accéder aux ressources d'une autre région.
- Performances
La création d'OCI Bastion doit se faire dans l'objectif de niveau de service (2 minutes au cours de la création de la demande). La création/fin de session doit se trouver dans l'objet de maintenance. Le transfert de port est de 1 minute (scénario "break-glass") et la session SSH gérée est de 3 minutes (utilisation normale).
- Sécurité
Le trafic provenant d'OCI Bastion provient de l'adresse privée sur le sous-réseau. Pour autoriser le trafic à partir de bastions, autorisez le trafic entrant et sortant de cette adresse privée vers les adresses IP auxquelles vous devez accéder à l'aide de bastions. Les stratégies détaillées qui limitent l'accès à un sous-ensemble d'instances permettent de garantir le bon niveau d'accès.
- Disponibilité
Le service doit fournir une haute disponibilité pour créer/arrêter des bastions et des sessions (en fonction du taux d'erreur d'API). La disponibilité ciblée est de 99,9 %.
- Coût
L'utilisation d'OCI Bastion est gratuite. Vous pouvez créer jusqu'à cinq bastions par région et par location. Chaque bastion sert les ressources cible au sein d'un VCN.
- Scénarios d'utilisation
Si vous souhaitez accéder aux hôtes cible privés qui exécutent des images natives OCI ou qui sont basées sur Linux et exécutent l'agent OCA v2 (avec le module d'extension de bastion activé dans celui-ci), vous pouvez utiliser des sessions SSH gérées. Si vous souhaitez accéder à des ressources cible privées qui n'ont pas l'agent en cours d'exécution, qui sont basées sur Windows ou qui nécessitent un accès aux bases de données (ATP ou MySQL), vous pouvez utiliser des sessions SSH de transfert de port.