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'adresse publique.
Bastion est un service d'infrastructure qui peut remplacer un serveur bastion que vous créez vous-même dans Oracle Cloud Infrastructure (OCI). Les paniers sont des passerelles ou des proxies. Ce sont des entités logiques qui fournissent un accès sécurisé aux ressources dans le cloud que vous ne pouvez pas atteindre autrement à 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é.
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 bastion. L'intégration à Oracle Cloud Infrastructure Audit vous permet de surveiller les actions administratives liées au service bastion et aux sessions bastion.
Architecture
Cette architecture montre deux façons de se connecter à des sous-réseaux privés. Une façon est de se connecter via un sous-réseau cible intermédiaire, et l'autre est de se connecter directement au sous-réseau qui contient les ressources protégées.
Lorsque vous créez un service de Bastion, vous pouvez spécifier une liste d'attribution de blocs CIDR et une durée de vie maximale de session. Lors de la création du bastion, un chemin réseau est établi entre le bastion VCN et le client VCN via une connexion inverse. Les sessions sont généralement créées par des utilisateurs ou des opérateurs.
Le diagramme suivant illustre cette architecture de référence.
Description de l'illustration architecture-use-bastion-service.png
L'architecture comporte les composants suivants :
- Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient un ou plusieurs centres de données, appelés domaines de disponibilité. Les régions sont indépendantes des autres régions et de vastes distances peuvent les séparer (d'un pays à l'autre ou même d'un continent à l'autre).
- Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes et indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui permet de tolérer les pannes. Les domaines de disponibilité ne partagent pas d'infrastructure comme l'alimentation ou le refroidissement, ou le réseau de domaine de disponibilité interne. Il est donc peu probable qu'un échec dans un domaine de disponibilité affecte les autres domaines de disponibilité de la région.
- Domaines d'erreur
Un domaine de panne est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines de pannes avec alimentation et matériel indépendants. Lorsque vous distribuez des ressources dans plusieurs domaines de pannes, vos applications peuvent tolérer les pannes de serveur physique, la maintenance système et les pannes d'alimentation dans un domaine de pannes.
- Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisé et défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de datacenters traditionnels, les VCN vous donnent un contrôle complet sur votre environnement de réseau. Un VCN peut comporter plusieurs blocs CIDR sans chevauchement que vous pouvez modifier après avoir créé VCN. Vous pouvez segmenter un VCN en sous-réseaux, qui peuvent être étendus à une région ou à un domaine de disponibilité. Chaque sous-réseau comporte une plage d'adresses contiguës qui ne chevauchent pas les autres sous-réseaux de VCN. Vous pouvez modifier la taille d'un sous-réseau après la création. Un sous-réseau peut être public ou privé.
- Service de Bastion
Le service bastion existe dans une infrastructure gérée par le BEC, ce qui n'exige aucune gestion de l'infrastructure. L'infrastructure gérée est l'endroit où l'adresse publique bastion est créée, permettant aux clients externes de se connecter à l'aide des sessions précédemment définies.
- Arrière-plan du service de Bastion
Le back-end Bastion Service stocke la configuration de session et les clés publiques SSH utilisées pour accorder l'accès aux systèmes cible. Les systèmes cibles, au besoin, utilisent la passerelle de service pour accéder au back-end Bastion Service.
- Adresse privée
L'adresse privée connecte le service Bastion aux sous-réseaux cible. Le sous-réseau cible peut être un sous-réseau distinct, pour un contrôle plus granulaire ou sur le même sous-réseau des instances auxquelles vous souhaitez 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 à des sous-réseaux dans VCN. Utilisez les blocs CIDR qui se trouvent dans l'espace d'adresse 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) auquel vous avez l'intention 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 besoins en matière de flux de trafic et de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, qui peut servir de limite de sécurité.
Utilisez des sous-réseaux régionaux.
Notez que chaque bastion provisionné prend deux adresses IP 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 /30 CIDR, cela signifie que vous disposez de deux adresses utilisables et que si, dans ce CIDR, vous disposez d'une ressource cible, vous n'avez pas assez 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.
- Sécurité
Utilisez Oracle Cloud Guard pour surveiller et maintenir la sécurité de vos ressources dans Oracle Cloud Infrastructure de manière proactive. Cloud Guard utilise des recettes de détecteur que vous pouvez définir pour examiner vos ressources pour détecter les faiblesses de sécurité et surveiller les opérateurs et les utilisateurs pour détecter les activités risquées. Lorsqu'une mauvaise configuration ou une activité non sécurisée est détectée, Cloud Guard recommande des actions correctives et aide à prendre ces actions, en fonction des recettes du répondeur que vous pouvez définir.
Pour les ressources nécessitant une sécurité maximale, Oracle vous recommande d'utiliser des zones de sécurité. Une zone de sécurité est un compartiment associé à une recette définie par Oracle de stratégies de sécurité basées sur les meilleures pratiques. Par exemple, les ressources d'une zone de sécurité 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 le client. Lorsque vous créez et mettez à jour des ressources dans une zone de sécurité, Oracle Cloud Infrastructure valide les opérations par rapport aux stratégies de la recette de zone de sécurité et refuse les opérations qui violent l'une quelconque des stratégies.
- Bastion OCI
TTL au niveau du bastion assurera qu'aucune des sessions créées dans le contexte de ce bastion n'aurait TTL plus que le bastion. Vous devez définir le TTL sur la limite minimale selon votre cas d'utilisation. Le minimum est de 30 minutes et le maximum est de 3 heures. Le TTL est également configurable au niveau de la session.
Le bloc Autoriser la liste CIDR doit être aussi étroit que possible selon votre scénario. Avec cela, vous pouvez restreindre les plages d'adresses IP à partir desquelles les connexions SSH sont autorisées aux ressources cible privées.
La taille du sous-réseau cible auquel un bastion est créé doit être réfléchie. Chaque création de bastion prend 2 adresses IP. Il est donc préférable d'avoir /29 plage au moins de sorte qu'elle dispose de 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 serez pas en mesure de le créer. Rappelez-vous que le sous-réseau cible peut être le sous-réseau à partir duquel votre ressource cible est présente ou à partir duquel d'autres sous-réseaux dans VCN cible peuvent autoriser le trafic à partir de.
Recommandations de politiques de sécurité
- Les règles d'entrée sur le sous-réseau qui dispose des ressources cible devraient permettre le trafic TCP entrant à partir d'une seule adresse IP qui est l'adresse IP privée du bastion.
- Indiquez le port exact d'une destination comme 22 pour Linux, 3389 pour Windows, 33060 pour MySql, etc. Ne pas utiliser TOUTES les ports.
Utilisez des stratégies IAM spécifiques pour les scénarios d'administration et d'opérateur.
Remarques
- Région
Le Bastion est un service régional. Par exemple, les clients devraient créer un bastion dans PHX pour accéder aux ressources dans PHX. Un bastion dans PHX ne peut pas être utilisé pour accéder aux ressources d'IAD, par exemple.
- Performances
La création du panier doit se situer dans le SLO (2 minutes au cours de la création de la demande). La création/fin de session doit être comprise dans le SLO. Le transfert de port est de 1 minutes (scénario de classe de rupture) et la session SSH gérée est de 3 minutes (utilisation normale).
- Sécurité
Le trafic à partir du bastion provient de l'adresse privée sur le sous-réseau. Afin de permettre le trafic depuis les bastions, permettre le trafic entrant et sortant de ce point d'extrémité privé aux adresses IP qui doivent être accessibles via les bastions. Les politiques à grains fins qui restreignent l'accès à un sous-ensemble d'instances aident à assurer le bon niveau d'accès.
- Disponibilité
Le service devrait fournir une haute disponibilité pour créer/résilier des bastions et des sessions (en fonction du taux d'erreur API). La disponibilité cible est de 99.9 %.
- Coût
Il n'y a aucun coût pour l'utilisation d'OCI Bastion. Les clients peuvent créer jusqu'à cinq bastions par région et par location. Chaque bastion sert les ressources cible dans un VCN.
- Scénarios d'utilisation
Si le client souhaite accéder aux hôtes cible privés qui exécutent des images natives OCI, sont basés sur Linux et exécutent l'agent v2 OCA (avec le plugin bastion activé), il peut utiliser des sessions SSH gérées. Si le client souhaite accéder à des ressources cible privées qui n'ont pas l'agent en cours d'exécution, sont basées sur Windows ou l'accès à des bases de données (ATP ou MySQL), il peut utiliser des sessions SSH de transfert de port.