Composants

Access Gateway dispose de plusieurs composants et niveaux d'architecture. Le diagramme suivant présente une vue d'ensemble détaillée de l'architecture d'Access Gateway, ainsi que les ports et protocoles utilisés.

Okta Access Gateway components

Niveau supérieur

Le niveau supérieur contient l'accès à Internet traditionnel, généralement exposé via un équilibreur de charge. Les utilisateurs accèdent à l'équilibreur de charge via des URL spécifiques à chaque application. Ces URL les dirigent ensuite vers un nœud travailleur Access Gateway dans un cluster haute disponibilité.

Étant donné que le nœud de travail agit comme un proxy inverse entre le navigateur de l'utilisateur et l'application protégée, l'équilibreur de charge côté public doit utiliser des sessions persistantes.

Niveau intermédiaire

Le niveau intermédiaire contient le cluster Access Gateway, exécuté au sein d'un environnement virtuel comme Amazon EC2, Microsoft Azure ou VMWare.

Le cluster de nœuds de travail s'exécute au sein d'une zone démilitarisée (DMZ). Le nœud d'administrateur s'exécute dans un segment de réseau distinct et plus restreint, en dehors de la DMZ.

Un cluster Access Gateway comprend les composants suivants :

  • Un équilibreur de charge visible depuis l'Internet externe et le cluster Access Gateway.
  • Un nœud administrateur, en dehors de la DMZ, qui gère toutes les définitions d'application et prend en charge les infrastructures telles que les banques de données et d'autres configurations.
  • Trois nœuds travailleurs ou plus, à l'intérieur de la DMZ, qui gèrent toutes les requêtes d'applications, interagissent avec un Tenant Okta à des fins d'autorisation et fournissent des contrôles d'accès granulaires. Si Access Gateway peut fonctionner avec moins de trois nœuds travailleur, pour la haute disponibilité, la taille de cluster recommandée est de trois (plus un nœud administrateur).

Le cluster Access Gateway se trouve généralement derrière un pare-feu et est uniquement accessible au Tenant Okta, à l'équilibreur de charge, aux services de support et aux ressources d'applications Web protégées sous-jacentes. En outre, Access Gateway doit également pouvoir accéder à certains sites bien définis, tels que :

  • API Okta et dépôt Yum : utilisés pour la configuration initiale, les tests réseau et la mise à niveau de Access Gateway.
  • Un récepteur de journal système (facultatif) pour transférer les événements vers un système SIEM (Security Information and Event Management). Selon le SIEM, les nœuds de travail peuvent envoyer des événements directement.
  • D'autres ports sont nécessaires pour le DNS et d'autres services requis par les applications.

Les administrateurs doivent pouvoir accéder à la console de gestion de ligne de commande en utilisant Secure Shell (SSH) sur le port 22, et à la console des administrateurs en HTTPS sur le port 443. Généralement, ces outils sont exclusivement utilisés par les administrateurs à l'intérieur du pare-feu. N'ouvrez pas le port 22 depuis l'extérieur du pare-feu.

Niveau de l'application

Les applications Web protégées, qui s'exécutent généralement dans un centre de données client, représentent le niveau le plus bas de l'architecture. Ces applications doivent être accessibles à Access Gateway, mais ne doivent pas être accessibles au monde externe. La séparation des applications s'effectue généralement à l'aide d'un mécanisme de DNS divisé où les ressources internes, telles que les applications Web protégées, les bases de données et d'autres types de support indispensables, sont visibles uniquement par Access Gateway et les ressources nécessaires du centre de données. En outre, un pare-feu sépare généralement Access Gateway de l'équilibreur de charge au niveau de l'application. Access Gateway prend en charge l'utilisation d'interfaces réseau supplémentaires, qui peuvent être utilisées pour séparer les différents aspects du trafic du centre de données vers Access Gateway.

Rubriques connexes

À propos des équilibreurs de charge

À propos des interfaces réseau

À propos des banques de données d'application

Conditions nécessaires au déploiement Access Gateway

Technologies prises en charge