Architectures de référence d'une application protégée

Lors de l'intégration d'applications avec Access Gateway, il existe plusieurs façons de s'assurer que les ressources en back-end sont non seulement protégées, mais aussi inaccessibles depuis l'Internet externe normal. Les architectures suivantes décrivent les différentes méthodes qui peuvent être utilisées pour garantir que les ressources Web protégées ne sont pas accessibles depuis Internet.

Approche

Lors de l'intégration d'applications dans Access Gateway, les éléments suivants doivent être pris en compte :

  • DNS : comment le DNS sera-t-il servi à Access Gateway ?
  • Comment les pare-feu seront-ils implémentés ?
  • Existe-t-il des restrictions spécifiques liées aux adresses IP ?
  • Existe-t-il d'autres exigences spécifiques à l'intégration ?

Architectures d'applications protégées

Les installations d'intégrations d'applications Access Gateway peuvent être déployées selon un nombre illimité de combinaisons possibles. Dans toutes les architectures, l'URL utilisée pour accéder à l'application est la même. En d'autres termes, les accès au réseau interne et externe dépendent du même nom d'application (app.example.com).

Les architectures courantes de protection d'intégration d'applications incluent :

Non protégé Point de départ initial pour toutes les architectures d'application Web protégées. Par définition, fournit peu ou pas de protection pour l'accès externe aux ressources Web protégées.
DNS masqué Une extension de l'architecture Aucun qui ajoute un serveur DNS interne secondaire, utilisé par Access Gateway, qui résout le nom de la ressource Web protégée, mais qui est différente de l'URL des applications externes.
Pare-feu Une extension de l'architecture DNS fractionnée qui place les pare-feu dans des endroits stratégiques refusant le routage des requêtes d'adresses IP sur l'Internet utilisé en interne.
IP protégée Une extension de l'architecture Pare-feu, Adresse IP protégée (ou restreinte), ajoute des restrictions basées sur l'adresse IP autorisant ou refusant l'accès aux ressources en fonction de l'adresse IP du demandeur.
Challenge de certificat Une extension des architectures Pare-feu ou Adresse IP protégée, l'architecture de challenge du certificat qui installe des certificats personnalisés utilisés pour autoriser ou refuser l'accès aux ressources Web protégées en fonction du fait que le demandeur puisse répondre correctement à un challenge de certificat ou non.

Décomposition des zones fonctionnelles de l'architecture

Les architectures sont composées des zones fonctionnelles suivantes :

Internet externe L'Internet externe représente les clients qui accèdent aux applications, ainsi que votre Org Okta.
DMZ La DMZ héberge un cluster Access Gateway, ainsi que des composants associés, pour permettre l'accès aux applications depuis l'Internet externe.
Interne Le réseau interne héberge les applications protégées par Access Gateway ainsi que d'autres composants nécessaires à la disponibilité de ces applications.

Notez que dans tous les diagrammes d'architecture, les lignes en pointillés représentent des chemins autour d'Access Gateway, qui sont censés être refusés. Chaque architecture décrit le processus utilisé pour refuser ces chemins.