De quels domaines ArcGIS Online a-t-il besoin dans une liste d’autorisation de pare-feu ?
Une carte touche des points de terminaison de portail, de fond de carte, de données et de stockage. Construisez la liste à partir des exigences de domaine actuelles d’Esri, pas d’une seule réponse DNS.
Une réponse DNS vous indique vers quelle adresse un nom d’hôte s’est résolu au moment de votre requête. Elle ne dit pas que l’adresse est permanente et n’énumère pas tout ce que la carte touche. Cette distinction compte surtout lorsque la sortie est limitée à une courte liste d’autorisation que quelqu’un a saisie à partir d’une seule recherche. Partez du flux de travail, puis dérivez la liste à partir des exigences actuelles du fournisseur. L’exemple récurrent est un client SIG d’entreprise qui atteint ArcGIS Online par une sortie VPN restreinte.
Énumérez chaque composant que l’opération de carte touche
Décomposez l’opération : le portail de l’organisation et l’accès aux éléments, les tuiles de fond de carte, les services hébergés d’entités ou d’analyse et tout téléchargement d’éléments. Chacun peut se trouver derrière un point de terminaison différent. Une carte qui référence un service ArcGIS Enterprise externe ou un point de terminaison OGC ajoute une dépendance dont l’équipe réseau n’a jamais entendu parler. Notez tout cela avant que quiconque dépose une demande de liste d’autorisation. Un composant absent de cet inventaire échoue plus tard d’une manière qui ressemble à un problème d’identifiants.
| Component | Example host family | Form | Who owns it |
|---|---|---|---|
| Portal and item access | *.arcgis.com | Wildcard | Esri, under the organization subdomain |
| Basemaps and static tiles | *.arcgisonline.com | Wildcard | Esri |
| Hosted feature and analysis services | *.arcgis.com | Wildcard | Esri, same revision |
| Item downloads and regional storage | storage hosts named in the current revision | Revision-specific | Esri |
| ArcGIS Enterprise service | gis.example.com | FQDN | Your organization |
| OGC or third-party endpoint | provider host | FQDN | The provider |
| Custom domain in front of the portal | maps.example.com | FQDN | Your organization |
The Domain and FQDN Requirements document is where those families come from, and two of them carry most of the workflow: *.arcgis.com covers the organization portal, its items and the hosted services behind them, while *.arcgisonline.com serves basemaps and static tiles. Everything else is organization-specific, because an ArcGIS Enterprise service you host, an OGC endpoint or a custom domain in front of the portal has to be added by name. Take those entries from the same revision you read, since the regional storage hosts change between versions.
La réussite de la connexion au portail est une preuve faible. Elle prouve que le point de terminaison du portail est joignable depuis le chemin approuvé, et rien sur les tuiles, l’analyse ou les téléchargements.
Choisissez wildcard ou FQDN dans le document actuel
Esri publie Domain and FQDN Requirements, et la révision compte car les entrées de stockage régional changent d’une version à l’autre. Le document actuel propose à la fois une approche wildcard au niveau du domaine et un inventaire plus strict au niveau du nom d’hôte. Il signale aussi les hôtes de stockage régionaux et avertit que les systèmes externes et les domaines personnalisés ajoutent des entrées propres à l’organisation. Copiez dans le journal des changements la révision que vous avez réellement lue, date comprise.
Une liste plus stricte coûte du temps de maintenance ; une autorisation plus large coûte de la surface de sécurité. Cet arbitrage appartient au propriétaire du réseau, et il devrait être tranché par rapport au document plutôt que par rapport à un ensemble d’adresses que quelqu’un a capturées une fois pendant une session de travail.
Gardez l’option de fond de carte statique étroite
La FAQ pare-feu d’Esri indique que la livraison accélérée des fonds de carte peut renvoyer des adresses dynamiques. La même entrée documente un arrangement à IP statique spécifiquement pour les fonds de carte, qui quitte le chemin d’accélération et peut réduire les performances. Aucune des deux affirmations ne transforme le portail, les données hébergées et les hôtes de stockage en une seule adresse statique. Si une politique n’autorisant que les adresses IP est obligatoire, obtenez l’arrangement pris en charge auprès d’Esri au lieu d’élargir une plage que vous avez devinée.
Une ancienne réponse DNS n’est pas un arrangement pris en charge, et elle pourrira.
Séparez la route de l’autorisation
Une route VPN choisit un chemin ; les règles de sortie décident si ce chemin peut atteindre la destination. Ce sont des contrôles différents, et un tunnel sain ne dit rien du second. C’est pourquoi une carte peut échouer pour un utilisateur sur un réseau et fonctionner pour un autre utilisateur du même compte. Vérifiez la règle et la route séparément avant de blâmer le service.
Les deux peuvent être corrects alors que le flux de travail échoue encore, si l’inventaire est incomplet.
Vérifiez composant par composant, puis donnez un propriétaire à la liste
Reproduisez l’opération qui échoue et notez quel composant a échoué : portail, tuile, service d’entités, téléchargement ou service externe. Puis modifiez un élément de politique et répétez. Un changement qui répare les tuiles ne vous dit rien des services d’analyse. Cet enregistrement par composant est aussi ce qui transforme la prochaine mise à jour régionale en changement de dépendance plutôt qu’en un nouveau cycle de suppositions. Examinez les URL de diagnostic avant de les coller quelque part, car la chaîne de requête peut transporter des jetons et des identifiants d’éléments.
Donnez à la liste des exigences un propriétaire et une date de revue liée à la révision du document. Quand Esri ajoute une région de stockage ou un hôte de service, ce propriétaire relance l’inventaire au lieu de découvrir la lacune pendant un incident.