Architecture de serveur Access Gateway unique

L'architecture de serveur Access Gateway unique représente les composants minimaux requis pour la protection des ressources Web à l'aide d'Access Gateway. Dans cette architecture simple, un ensemble d'applications, appelées ressources Web protégées, est fourni aux clients qui en font la demande via Access Gateway.

Remarque :

Il s'agit d'une architecture minimale généralement utilisée à des fins d'information.

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

Fournir un accès sécurisé à un ensemble d'applications, accessibles depuis l'Internet externe, mais hébergées au sein d'un réseau interne.

Avantages et inconvénients

Avantages	Inconvénients
Installation simple et minimale Base de référence pour les tests, la preuve de concept, etc.	Ne prend pas en charge la tolérance aux pannes Non destiné à la production L'accès au serveur d'administration nécessite que le port SSH 22 et le port HTTPS 443 soient ouverts. Consulter Conditions nécessaires au déploiement Access Gateway pour plus de détails.

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`.
	`appN.example.com`	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é.
Pare-feu	Internet externe vers DMZ	Pare-feu traditionnel entre l'Internet externe et l'hébergement DMZ Access Gateway.
DMZ	Access Gateway	L'instance Access Gateway, située dans la DMZ, est utilisée pour fournir un accès aux applications utilisées par des clients Internet externes. Généralement hébergés 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 Internet interne	Pare-feu traditionnel entre DMZ et le réseau interne hébergeant les ressources Web protégées référencées par Access Gateway
Réseau interne	`appN.example.com`	URL représentant l'une des applications qu'un client Web doit saisir 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.
Réseau interne	Applications protégé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 . Éventuellement précédées par Access Gateway comme équilibreur de charge. Consultez À propos de l'équilibrage de charge Access Gateway.

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.

De plus, Access Gateway lui-même est généralement géré via un accès interne uniquement. En d'autres termes, les administrateurs accès généralement à Access Gateway lui-même derrière le pare-feu. Ceci est illustré dans d'autres architectures.