Architecture d'un centre de données unique et exclusivement externe

L'Access Gateway externe dans une architecture de centre de données représentant les composants nécessaires à la protection des ressources Web à l'aide d'Access Gateway. Elle étend l'architecture à instance unique d'Access Gateway en introduisant un cluster Access Gateway. Dans cette architecture, un ensemble d'applications, appelées ressources Web protégées, est fourni aux clients qui en font la demande via un cluster Access Gateway.

Cette architecture est conçue pour répondre aux exigences suivantes :

  • Accès sécurisé à un ensemble d'applications – Accessible depuis l'Internet externe, mais hébergé au sein d'un réseau interne.
  • Fournir une tolérance aux pannes – Mettre en place des instances supplémentaires d'Access Gateway, en tant que nœuds de travail du cluster, de manière à ce que, si l'un d'entre eux n'est pas disponible, le cluster continue de fonctionner normalement.
  • Gérer la capacité – Fournir des instances supplémentaires d'Access Gateway pour gérer la charge attendue.

Avantages et inconvénients

Avantages Inconvénients
  • Installation relativement simple
  • Fournit une tolérance de base aux pannes et une prise en charge des capacités
  • Peut être étendu avec des travailleurs supplémentaires si nécessaire pour ajouter une capacité supplémentaire
  • Charge équilibrée
  • Centre de données unique
  • L'équilibreur de charge situé dans la DMZ, en amont d'Access Gateway doit prendre en charge l'affinité de session (sessions persistantes).

Architecture

Composants

Emplacement

 Composant Description
Internet externe Clients Web

Le navigateur client traditionnel accède à Access Gateway en utilisant les URL connues sous le nom de [appN|consumer-app1].example.com.
URL appN.example.com non affichées URL représentant les applications qu'un client Web externe saisirait pour accéder à l'une des applications sécurisées par Access Gateway. Généralement, toutes les URL de cette nature sont fournies par l'instance Access Gateway et se résolvent vers cette dernière.
Org Okta

Votre org Okta, qui fournit des services d'identité.
Universal Directory Org Okta

Okta Universal Directory, hébergé au sein d'une org Okta, contenant des utilisateurs en dehors des autres implémentations LDAP ou Active Directory. Il s'agit généralement d'autres comptes clients, de comptes partenaires, etc.

Pare-feu

Internet externe vers DMZ

 Pare-feu traditionnel entre l'Internet externe et l'hébergement DMZ Access Gateway.
DMZ Équilibreur de charge en amont d'Access Gateway Équilibreur de charge pour le cluster Access Gateway situé dans la DMZ Positionné entre les clients externes et le cluster Access Gateway à usage externe.
Access Gateway Le cluster Access Gateway, situé dans la DMZ, est utilisé pour fournir un accès aux applications utilisées par des clients Internet externes. Il est généralement hébergé dans un environnement virtuel comme Amazon Web Services, MS Azure, Oracle OCI, etc. Consultez Gérer le déploiement Access Gateway.

Pare-feu

DMZ vers pare-feu interne

 Pare-feu traditionnel entre la DMZ et le réseau interne.
Réseau interne Administrateur Access Gateway Le nœud d'administrateur Access Gateway, dans n'importe quel centre de données qui s'occupe de la configuration, des sauvegardes de configuration, du transfert de journal, etc. Accessible par les administrateurs au sein du réseau interne.
Équilibreur de charge Access Gateway pré interne

Équilibreur de charge pour le cluster situé dans la DMZ. Il est positionné entre les clients internes et le cluster d'utilisation interne. Consulter Équilibrage de charge.
Les URL d'applications protégées ne sont pas affichées L'ensemble des ressources Web protégées, accessibles à l'aide des URL protd-N.internal-example.com. Il s'agit des applications classiques ou historiques avec lesquelles Access Gateway interagit avec le champ Ressource Web protégée dans chaque définition application .

Autres considérations

Le DNS est généralement partagé entre les domaines externes et internes. Toutes les URL externes, telles que [appN|consumer-app1].example.com, seront servies en externe et pointeront vers l'instance Access Gateway. Les URL internes utilisées par Access Gateway, comme [protd-N|consumer-app1].internal-example.com, seront servies par un DNS interne.

La plupart des architectures transfèrent les événements du journal à un composant de journal système externe. Okta recommande fortement qu'un serveur de journalisation soit configuré pour tous les environnements Access Gateway. Consultez Configurer des redirecteurs de journaux.

Cette architecture ne montre pas les centres de données où sont hébergés ses composants.

Voici une vue d'ensemble possible de l'emplacement des différents composants.

Composant Centre de données
Cluster Access Gateway externe. Équilibreur de charge en amont d'Access Gateway externe Centre de données virtuel 1 Peut être basé sur AWS, OCI ou MS Azure
Équilibreur de charge en aval d'Access Gateway externe Centre de données physique 1 Peut être colocalisé avec les applications à usage interne
Équilibreur de charge Access Gateway pré interne Peut être centre de données virtuel 2 Peut être colocalisé avec des applications internes ou Access Gateway interne
Cluster Access Gateway interne Centre de données virtuel 2 Peut être AWS, VMWare, etc.)
Applications pour usage externe Applications pour usage interne Centre de données physique 1
Serveur proxy interne Peut être dans le centre de données virtuel 2, probablement en colocalisation avec d'autres serveurs internes.