Passerelles Okta Privileged Access

Une passerelle est un serveur léger ou une machine virtuelle que vous déployez dans votre propre infrastructure pour relier Okta Privileged Access et les ressources que vous gérez. Chaque passerelle remplit l'un des deux rôles suivants, que vous attribuez lors de la création du jeton de configuration utilisé pour l'enrôler.

Rôles de passerelle

Passerelles proxy d'accès serveur

Haute disponibilité

Les passerelles proposent plusieurs mécanismes pour garantir une haute disponibilité, ce qui permet à ces passerelles de jouer le rôle d'hôte bastion sans les risques d'un point de défaillance unique. En plus de l'équilibrage de charge standard , les passerelles fournissent divers mécanismes pour garantir un accès continu à vos serveurs. Ces mécanismes comprennent des vérifications de statut intégrées et un équilibrage de charge automatique lorsque plusieurs passerelles sont inscrites avec les mêmes étiquettes. Consultez Haute disponibilité de la passerelle Okta Privileged Access.

Le comportement en matière de routage des connexions et d'équilibrage de charge décrit dans ce sujet s'applique aux passerelles jouant le rôle de proxy d'accès serveur. Les passerelles jouant le rôle d'orchestrateur d'infrastructure assurent plutôt la redondance grâce à leur appartenance à un groupe d'orchestration. Voir Groupes d'orchestration.

Sécurité

Les caractéristiques suivantes décrivent les passerelles dans le rôle de proxy d'accès serveur, où elles remplacent ou complètent les bastions SSH. Les passerelles Okta Privileged Access sont plus sécurisées que les bastions SSH en raison de leur conception, qui comprend :

• Modèle Zero Trust
• Gestion des accès logique
• Intégration native du Fournisseur d'identité (IdP)

Modèle Zero Trust

Les connexions SSH standard utilisent un certain type d'identifiants secrets (comme des mots de passe, des clés ou des certificats) pour se connecter aux serveurs. Bien que ces identifiants ne soient valides que pour une courte durée, un client ou un appareil compromis pourra donner à une personne malveillante un accès direct à un serveur cible.

Lorsque vous utilisez les passerelles Okta Privileged Access pour vos connexions SSH, le client ne reçoit jamais d'identifiants qu'il peut utiliser seul pour se connecter à un serveur via une connexion SSH. En revanche, le client reçoit une charge utile chiffrée qui est transmise à la passerelle, et seule la passerelle peut la déchiffrer. Cette méthode présente les avantages suivants :

• Un appareil client compromis ne donnera jamais à une personne malveillante l'accès aux identifiants pouvant être utilisés directement au serveur cible via une connexion SSH.
• Puisque l'accès passe par une passerelle, il est plus simple de surveiller les tentatives d'accès en utilisant un système de détection d'intrusion (IDS) ou d'autres outils de surveillance.

Gestion des accès logique

Il est parfois difficile de maintenir un contrôle d'accès approprié, même en utilisant des bastions SSH. Il est important de conserver un enregistrement des autorisations d'accès utilisateur et de la liste des bastions et des serveurs auxquels ils peuvent avoir accès. La tâche se complique lorsque différents bastions comportent des exigences de sécurité différentes en fonction des serveurs auxquels ils ont accès.

Les passerelles Okta Privileged Access permettent de faciliter les choses grâce à l'utilisation des étiquettes. Les étiquettes déterminent les passerelles utilisées pour acheminer les connexions vers les serveurs d'un projet. Vous pouvez utiliser les étiquettes pour segmenter les passerelles par région de cloud, attestation de conformité, système d'exploitation ou toute autre paire clé-valeur que vous aurez choisie. Tant que les étiquettes et les sélecteurs d'étiquettes que vous utilisez pour un projet sont corrects, la passerelle utilisée pour accéder à un serveur cible répond nécessairement à vos exigences.

Par exemple, prenons une exigence relative à la localisation des données imposant que les données ne soient pas transférées dans un autre pays. Dans un environnement bastion hérité, vous avez besoin d'auditer les serveurs cible et les serveurs bastions pour vous assurer que le seul accès au serveur passe par un serveur bastion situé au sein du pays. Lorsque vous utilisez des passerelles, vous pouvez leur attribuer des étiquettes qui indiquent leur région de fonctionnement (par exemple, leur région AWS). Ainsi, plutôt que de devoir auditer des serveurs individuels, vous ajoutez la région adéquate en tant que sélecteur de passerelle au projet dont les serveurs requièrent une telle restriction d'accès.

Les passerelles peuvent être des outils puissants que vous pouvez utiliser pour répondre aux exigences de conformité, notamment lorsqu'elles sont utilisées avec des groupes Okta Privileged Access pour gérer les utilisateurs.

Intégration native du Fournisseur d'identité (IdP)

Bien que SSH soit un puissant protocole pour sécuriser les accès aux serveurs, sa conception est antérieure à l'avènement des Fournisseur d'identité fédérés. Par conséquent, son modèle d'autorisation est axé sur l'identité de la machine plutôt que sur l'identité humaine. SSH fonctionne avec les utilisateurs de serveurs, les clés et les certificats plutôt qu'avec les organisations, les divisions des sociétés et les rôles humains.

Ainsi, les bastions SSH sont vulnérables aux attaques par canal auxiliaire. Supposons qu'un utilisateur disposant des accès nécessaires puisse modifier la configuration d'un serveur bastion ou cible. Dans ce cas, il peut accéder aux serveurs cibles pour contourner votre Fournisseur d'identité. Par exemple, imaginons un scénario dans lequel un utilisateur disposant de l'accès administrateur à un serveur modifie la configuration sshd et installe sa clé publique pour autoriser un accès non authentifié.

Les passerelles remédient à ce problème, car elles sont étroitement liées à Okta Privileged Access et n'utilisent pas un protocole générique comme SSH. Pour passer une passerelle, les utilisateurs doivent exécuter le client Okta Privileged Access et s'identifier avec Okta. Cela garantit la protection par Okta de tous les accès aux serveurs se trouvant derrière les passerelles.

Passerelles d'orchestration des infrastructures

Les intégrations de bases de données sont gérées par une passerelle enrôlée à l'aide d'un jeton de configuration défini pour l'orchestration des infrastructures. La passerelle traite toutes les communications directes avec vos instances de base de données. Elle effectue la découverte de compte et la rotation des mot de passe en votre nom, de sorte que Okta Privileged Access ne se connecte jamais directement à une instance de base de données. Étant donné que vous exécutez les passerelles dans votre propre infrastructure, le trafic reste dans votre environnement.

L'orchestration des infrastructures n'est pas activée par défaut. Attribuez le rôle d'orchestrateur d'infrastructure au jeton de configuration, puis activez l'orchestration dans le fichier de paramètres de la passerelle. Voir Configurer la passerelle pour prendre en charge les intégrations de bases de données.

Configurez la passerelle avant d'ajouter une intégration de base de données. La création de l'intégration échoue si aucune passerelle ne peut accéder à l'instance de base de données. Pour connaître la séquence complète, consultez Configurer votre première intégration de base de données.

Groupes d'orchestration

Un groupe d'orchestration est un ensemble nommé de passerelles configurées pour l'orchestration des infrastructures. Chaque jeton de configuration crée un groupe d'orchestration. Vous nommez le groupe lors de la création du jeton de configuration de l'orchestrateur d'infrastructure, et chaque passerelle enrôlée avec ce jeton se joint à ce groupe. Voir Créer des jetons de configuration.

Lorsque vous ajoutez une intégration de base de données, vous précisez le groupe d'orchestration qu'elle utilise. Les passerelles de ce groupe effectuent la découverte de compte et la rotation des mot de passe pour cette intégration.

Contrairement aux passerelles proxy d'accès serveur, où les projets sont associés aux passerelles par les étiquettes attribuées à chaque passerelle enrôlée, une intégration de base de données est associée à ses passerelles par le groupe d'orchestration unique que vous indiquez.

Pour ajouter de la redondance, enrôlez plusieurs passerelles dans le même groupe d'orchestration. Toute passerelle du groupe peut prendre en charge le traitement d'une intégration qui lui est attribuée, ce qui permet à l'intégration de continuer à fonctionner même si une passerelle devient inaccessible. Chaque passerelle d'un groupe doit pouvoir accéder à chaque instance de la base de données utilisée par les intégrations attribuées à ce groupe. Un groupe dont les passerelles ne parviennent pas à accéder à toutes ses instances cibles provoque une dégradation de l'état de santé. Voir État de santé de l'intégration de base de données.

Exigences de réseau pour les passerelles d'orchestration

Une passerelle dans le rôle d'orchestrateur d'infrastructure nécessite l'accès réseau suivant :

• accès sortant vers Okta Privileged Access sur le port 443. Cela signifie que l'accès aux domaines de production et d'aperçu Okta Privileged Access se fait par nom DNS, et non par adresses IP particulières. Pour les domaines, voir Exigences de port Okta Privileged Access.

• Accès sortant vers chaque instance de base de données qu'il dessert, sur le port d'écoute de cette instance. Par exemple, le port 5432 pour PostgreSQL ou le port 3306 pour MySQL.

Que votre base de données soit déployée sur site, sur une infrastructure du cloud ou sur une offre de plateforme en tant que service (PaaS), elle nécessite toujours une passerelle. Voir Versions, options de déploiement et types de bases de données pris en charge et Accès au réseau par environnement.