Introduction
La sécurité joue un rôle important dans le processus de conception de l'architecture d'entreprise. Les politiques de sécurité varient entre les organisations, et différents modèles de déploiement sont nécessaires pour répondre à ces exigences et contraintes. Dans cet article, je vais essayer d'aborder certaines des contraintes de sécurité les plus courantes, et suggérer des modèles de déploiement pour les satisfaire.
Ce n'est en aucun cas une liste exhaustive de toutes les exigences de sécurité disponibles et des modèles d'architecture de sécurité.
Cet article se concentrera sur les modèles d'architecture pour exposer les ressources sécurisées ArcGIS Enterprise aux clients externes, c'est-à-dire les systèmes devant être accessibles en dehors du réseau interne de l'organisation, via un DMZ, par exemple pour permettre l'accès aux travailleurs sur le terrain sans VPN.
Il y a des considérations supplémentaires qui interviennent dans la décision du modèle à utiliser, que cet article ne couvrira pas, telles que le nombre de ressources, par exemple matériel, licences et personnel, qui seront nécessaires pour chaque modèle.
Pour simplifier et se concentrer sur l'aspect sécurité du modèle d'architecture, toutes les architectures présentées dans cet article ne sont pas hautement disponibles, mais chacune peut être ajustée pour une architecture hautement disponible sans changer le modèle.
Proxy inverse DMZ
Commençons par le modèle de déploiement système ArcGIS Enterprise externe le plus courant, utilisant un proxy inverse dans la DMZ.
Figure 1 - Proxy inverse DMZ
Dans ce modèle, tous les composants ArcGIS Enterprise sont hébergés dans le réseau interne, derrière le pare-feu, et un proxy inverse (cela peut être un proxy inverse commercial, tel que F5 ou NetScaler, un proxy inverse open-source tel que Nginx ou HAProxy, ou un second ensemble d'ArcGIS Web Adaptors), est déployé dans la DMZ, et transmet les requêtes externes à ArcGIS Enterprise.
Le portail ArcGIS Enterprise supporte uniquement un DNS pour l'URL publique du portail (l'URL du contexte web), et pour supporter l'accès externe, un nom DNS résolvable depuis l'extérieur pour l'URL du contexte web du portail, par exemple https://gis.company.com/portal, doit être utilisé.
Dans la plupart des cas, le modèle ci-dessus inclura la mise en œuvre d'un système DNS fractionné (Split DNS), c'est-à-dire que les requêtes internes vers le DNS ArcGIS Enterprise (par exemple gis.company.com) seront résolues vers l'adresse IP de la machine des web adaptors internes, donc les utilisateurs internes resteront derrière le pare-feu, et les requêtes externes vers le DNS ArcGIS Enterprise seront résolues vers l'adresse IP du proxy inverse DMZ.
L'utilisation d'un pare-feu applicatif web (WAF) devant le proxy inverse DMZ est une bonne pratique de sécurité, car elle ajoute des contrôles de sécurité supplémentaires. Esri maintient un document (connexion organisationnelle requise) sur https://trust.arcgis.com avec une liste des points de terminaison qui peuvent être filtrés en toute sécurité depuis l'accès externe afin de refuser l'accès externe aux ressources potentiellement sensibles dans votre site ArcGIS Enterprise.
Contraintes de sécurité spéciales
Pas d'accès non authentifié au réseau interne
Dans un système ArcGIS Enterprise fédéré, le portail est responsable de l'authentification et de l'autorisation des utilisateurs. Dans le modèle ci-dessus, lorsqu'un utilisateur fait une requête à ArcGIS Enterprise, ArcGIS Enterprise vérifiera d'abord si la requête vers la ressource sécurisée (par exemple un service) contient une information d'authentification valide, et sinon, ArcGIS Enterprise renverra une réponse de redirection au client pour s'authentifier auprès du fournisseur d'identité configuré, par exemple SAML ou OpenID Connect.
Dans l'architecture ci-dessus, une requête non authentifiée provenant d'un client externe est transmise du proxy inverse DMZ à un web adaptor interne, puis du web adaptor au portail ou serveur ArcGIS Enterprise, avant qu'ArcGIS Enterprise ne renvoie une réponse de redirection au client.
Certaines politiques de sécurité interdisent l'accès non authentifié à la zone intranet, donc l'architecture ci-dessus ne répond pas à cette contrainte.
Pas d'accès HTTPS / Seul l'accès à la base de données est autorisé du DMZ vers le réseau interne
La plupart des politiques de sécurité autorisent l'accès entrant depuis la DMZ vers le réseau interne, mais peuvent limiter le type d'accès autorisé par protocoles ou ports. Par exemple ne pas autoriser l'accès HTTPS (Hypertext Transfer Protocol Secure) depuis la DMZ vers l'intranet ou n'autoriser que l'accès base de données via des ports personnalisés.
Dans l'architecture ci-dessus le proxy inverse DMZ transmet les requêtes à ArcGIS Enterprise en utilisant HTTPS via le port 443, ce qui ne respecte pas cette contrainte.
Pas d'accès entrant du DMZ vers le réseau interne
Dans certains cas, les politiques de sécurité interdisent tout type d'accès entrant depuis la DMZ vers le réseau interne et n'autorisent que des connexions non persistantes depuis l'intranet vers la DMZ.
Modèles d'architecture de sécurité
Considérons les modèles d'architecture de sécurité ci-dessous et examinons comment chaque modèle répond à certaines ou toutes les contraintes de sécurité que nous avons passées en revue ci-dessus.
Portail ArcGIS Enterprise DMZ et services enregistrés
Figure 2 - Proxy portail ArcGIS Enterprise
<\/span><\/P> <\/DIV>Dans la figure 2 ci-dessus, il y a un portail ArcGIS Enterprise dans la DMZ, et un serveur ArcGIS Enterprise dans le réseau interne. Le serveur autonome interne n'est pas fédéré avec le portail – les services sont publiés directement sur le serveur autonome, configuré comme sécurisé dans le serveur en utilisant un compte d'application (compte d'application intégré ArcGIS Enterprise server ou compte de service Active Directory / LDAP), puis ajoutés au portail en tant qu'éléments depuis le web avec des identifiants stockés. Lorsque le service sécurisé ArcGIS Enterprise server est enregistré dans le portail avec des identifiants stockés, le portail crée une URL proxy pour ce service, et toutes les requêtes vers ce service passeront par le portail avant d'être transmises au serveur autonome interne. Le portail ArcGIS Enterprise vous permet également de définir une limite de débit et des référents spécifiques pouvant accéder au service.<\/P>L'utilisation du modèle ci-dessus respecte la contrainte de ne pas avoir d'accès non authentifié au réseau interne, car toutes les requêtes externes doivent passer par le portail dans la DMZ, qui authentifiera et autorisera d'abord l'utilisateur, puis effectuera une requête au service dans le réseau interne. Sachez que puisque toutes les requêtes du portail vers le serveur sont effectuées en utilisant les identifiants stockés, vous perdez la capacité de suivi des éditeurs.<\/P>L'architecture de ce modèle peut être développée pour inclure un système fédéré orienté interne d'ArcGIS Enterprise avec portail, serveur hébergeur et serveur(s) fédéré(s), comme illustré à la figure 3.<\/P> <\/P>Figure 3 - ArcGIS Enterprise Portal Proxy Développé<\/H3> <\/P>
<\/span><\/P>Géodatabase Répliquée Interne<\/H2> <\/P>Les politiques de sécurité de certaines organisations n'autorisent pas l'accès HTTPS depuis la DMZ vers l'intranet, et n'autorisent que l'accès à la base de données, généralement via des ports non standards, et dans de nombreux cas n'autorisent pas non plus l'accès externe à une base de données principale de production, exigeant l'utilisation d'une base de données distincte.<\/P>Dans la figure 4 ci-dessous, ArcGIS Enterprise est déployé dans la DMZ, et une géodatabase d'entreprise répliquée interne est utilisée comme source de données enregistrée pour le serveur cartographique. Soit la réplication Esri geodatabase soit la réplication RDBMS peut être utilisée.<\/P> <\/P>Figure 4 - Réplication de Base de Données<\/H3> <\/P>
<\/span><\/P> <\/DIV>La figure 5 ci-dessous présente une architecture développée qui inclut un système ArcGIS Enterprise orienté interne dans le réseau interne et un système ArcGIS Enterprise orienté externe dans la DMZ.<\/P> <\/P>Figure 5 - Réplication de Base de Données Développée<\/H3> <\/P>
<\/span><\/P> <\/DIV>Publication et Collaboration des Services<\/H2> <\/P>Enfin, pour ceux qui n'autorisent aucun accès entrant depuis la DMZ vers l'intranet, la figure 6 ci-dessous illustre un ArcGIS Enterprise orienté externe dans la DMZ, et un ArcGIS Enterprise orienté interne dans l'intranet, avec :<\/P>Services publiés sur le système ArcGIS Enterprise DMZ en tant que couches hébergées, et tâches automatisées s'exécutant selon un calendrier (par exemple nocturne ou hebdomadaire) pour écraser les données hébergées avec des données mises à jour provenant du système ArcGIS Enterprise interne<\/LI>Les couches d'entités sont partagées par copie du système ArcGIS Enterprise interne vers le système ArcGIS Enterprise DMZ via collaboration distribuée avec édition partagée bidirectionnelle (introduite à la version 10.9)<\/LI><\/OL> <\/P>Figure 6 - Publication et Collaboration des Services<\/H3> <\/P>
<\/span><\/P> <\/DIV>Restreindre l'Accès des Applications Externes à ArcGIS Enterprise<\/H1> <\/P>Dans certains cas, les organisations utilisent ArcGIS Enterprise pour prendre en charge des applications intégratrices externes et souhaitent restreindre l'accès des applications externes en filtrant les requêtes externes, autorisant uniquement les requêtes provenant soit d'une liste spécifique ou plage d'adresses IP, soit de domaines spécifiques.<\/P> <\/P>Proxy ArcGIS Online<\/H2> <\/P>Similaire au modèle Portail ArcGIS Enterprise DMZ et Services Enregistrés (figure 2 ci-dessus), ArcGIS Online agit également comme proxy lorsque vous enregistrez des services sécurisés soit depuis un serveur autonome ArcGIS Enterprise soit depuis un système fédéré ArcGIS Enterprise. Dans la figure 7 ci-dessous, les services d'un système ArcGIS Enterprise interne sont enregistrés dans ArcGIS Online avec identifiants stockés, ArcGIS Online peut accéder aux services via le proxy inverse DMZ, et le proxy inverse est configuré pour autoriser uniquement les requêtes provenant du domaine ArcGIS Online, bloquant les requêtes provenant d'autres sources. L'application web ou mobile du système intégrateur peut être enregistrée auprès d'ArcGIS Online en utilisant OAuth 2.0 et Identité ArcGIS, ainsi seuls les utilisateurs authentifiés et autorisés peuvent accéder aux services enregistrés. Puisqu'ArcGIS Online accède aux services en utilisant les identifiants stockés, le suivi des éditeurs ne fonctionnera pas. Comme pour le portail, vous pouvez définir une limite de débit et des référents spécifiques pouvant accéder aux services.<\/P> <\/P>Figure 7 - ArcGIS Online et Services Enregistrés<\/H3> <\/P>
<\/span><\/P> <\/P>Proxy Serveur<\/H2> <\/P>Une autre approche serait d'utiliser un site serveur autonome ArcGIS Enterprise et un proxy serveur pour accéder aux services sécurisés depuis une application web intégratrice.<\/P>Dans la figure 8 ci-dessous, les clients applicatifs web du système intégrateur sont configurés pour envoyer les requêtes SIG à un proxy hébergé sur le serveur applicatif du système intégrateur. Le serveur applicatif intégrateur est responsable de sécuriser l'accès au proxy, c'est-à-dire autoriser uniquement les utilisateurs authentifiés par l'application à accéder au proxy, et protéger (chiffrer) les identifiants du serveur ArcGIS Enterprise. Le proxy gère la sécurité du jeton du serveur ArcGIS Enterprise au nom du client, utilisant un compte d'application intégré au serveur ou un compte de service Active Directory / LDAP, et envoie la requête au site serveur autonome interne ArcGIS Enterprise via le proxy inverse DMZ. Le proxy inverse est configuré pour autoriser uniquement les requêtes provenant des IPs (liste ou plage) du(des) serveur(s) applicatif(s) intégrateur(s), bloquant les requêtes provenant d'autres sources.<\/P> <\/P>Figure 8 - Proxy Serveur Application Web Intégratrice<\/H3> <\/P>
<\/span><\/P> <\/P>
.png)
