Як зменшити ризики доступу до геоданих в ArcGIS Enterprise
Розгорнути ArcGIS Enterprise всередині корпоративної мережі - ще не означає отримати ізольовану та захищену GIS. Для production-середовища (робочого середовища, що використовується організацією) важливо контролювати не лише місце зберігання даних, а весь ланцюжок доступу до них: автентифікацію, federation (об’єднання ArcGIS Server із Portal в єдине середовище), зовнішні запити Portal, доступ до сервісів, сертифікати, мережеві з’єднання, оновлення компонентів і сценарії відновлення.
Особливо це стосується середовищ, де ArcGIS Enterprise працює з даними критичної інфраструктури, внутрішніми operational layers (операційними шарами), інженерними мережами, містобудівною інформацією, матеріалами ДЗЗ або іншими наборами, які за політикою організації не повинні виходити за межі контрольованої інфраструктури.
Тому задача полягає не просто в тому, щоб перенести GIS з public cloud (публічної хмари) до on-premises (власного локального середовища організації). Потрібно визначити, які зовнішні залежності має Enterprise deployment (розгорнуте середовище ArcGIS Enterprise), які компоненти можуть ініціювати зовнішні запити та де проходить межа довіри між Portal, federated servers (федеративними серверами), Data Store, корпоративним identity provider (постачальником ідентифікації користувачів) і користувачами.
Почніть не з firewall, а з моделі доступу
Для вже працюючого ArcGIS Enterprise перше питання - хто фактично отримує доступ до ресурсів після автентифікації.
У federated environment (федеративному середовищі) доступ до GIS-сервісів пов’язаний з identities (обліковими записами користувачів), roles (ролями), privileges (правами доступу) і sharing model (моделлю поширення контенту) Portal. Це дозволяє централізовано керувати доступом, але створює поширену помилку: адміністратор концентрується на ролях користувачів і не перевіряє sharing (параметри поширення) уже опублікованих items (елементів) та underlying services (пов’язаних із ними сервісів).
Вимкнення anonymous access (анонімного доступу) саме по собі не робить усі сервіси приватними. Налаштування Portal контролює доступ до порталу, тоді як доступність конкретних hosted feature services (розміщених сервісів об’єктів), map services (картографічних сервісів), image services (сервісів зображень) та інших ресурсів залежить від їхніх sharing settings (налаштувань поширення). Тому після зміни security policy (політики безпеки) варто окремо провести аудит контенту та сервісів, особливо якщо середовище існує давно або пережило migration (міграцію) чи federation.
Для внутрішнього Portal anonymous access можна вимкнути через:
Organization → Settings → Security → Allow anonymous access to your portal → Off → Save.
Якщо використовується web-tier authentication (автентифікація на рівні вебсервера) через ArcGIS Web Adaptor, anonymous access необхідно також вимкнути на самому web server (вебсервері).
Перевірте зовнішні запити Portal
Portal for ArcGIS у певних workflows (робочих процесах) може виступати proxy (посередником для мережевих запитів) між користувачем і зовнішнім ресурсом. Це відбувається, наприклад, під час використання secured services (захищених сервісів) зі збереженими credentials (обліковими даними), KML або GeoRSS за URL, створення hosted layer (розміщеного шару) з CSV за URL чи роботи з окремими offline workflows (офлайн-робочими процесами).
Для Enterprise-архітектури це важлива частина attack surface (поверхні потенційної атаки): якщо Portal може звертатися до довільних адрес, його proxy capability (можливість виконувати proxy-запити) може стати небажаним каналом доступу до інших ресурсів мережі.
Починаючи з ArcGIS Enterprise 12.0, Portal обмежує proxy-запити за замовчуванням і дозволяє їх лише до хостів, визначених у списку Allowed proxy hosts (дозволених proxy-хостів). Цей підхід зберігається і в актуальній лінійці ArcGIS Enterprise. Після upgrade (оновлення версії) варто перевірити список ще раз: раніше налаштовані hosts (хости) зберігаються, а система також може додавати необхідні default hosts (хости за замовчуванням).
Перевірити список можна тут:
Organization → Settings → Security → Allowed proxy hosts.
Для додавання нового ресурсу:
Add hostname → вказати hostname → Add hostname.
Якщо потрібно дозволити всі машини певного домену, підтримується формат:
(.*).example.com
Зміни застосовуються одразу.
Для production deployment (робочого розгортання системи) варто не просто додавати hostnames (імена хостів) у міру виникнення помилок, а сформувати явний allowlist (список дозволених адрес): які зовнішні ресурси дійсно потрібні Portal і для яких workflows (робочих процесів).
CORS і trusted servers: не залишайте дозволи ширшими, ніж потрібно
У тому самому розділі Organization → Settings → Security варто перевірити ще дві групи параметрів: Allow origins (дозволені джерела запитів) та Trusted servers (довірені сервери).
Allow origins визначає, які домени можуть виконувати cross-origin requests (міждоменні запити) до ArcGIS REST API. Якщо організація використовує власні web applications (вебзастосунки), reverse proxy (зворотний proxy-сервер) або окремі домени для внутрішніх застосунків, дозволені origins (джерела запитів) повинні відповідати реальній архітектурі, а не містити зайві записи, залишені після тестування.
Trusted servers використовуються у сценаріях, де Portal має довіряти зовнішнім серверам для передавання credentials (облікових даних). Для середовища з підвищеними вимогами до безпеки список таких серверів повинен бути мінімальним і контрольованим.
Саме такі дрібні на перший погляд налаштування часто відрізняють просто внутрішню GIS від реально hardened deployment (посиленого з погляду безпеки розгортання).
HTTPS-only - базовий рівень. Важливіше, кому довіряє весь ланцюжок
ArcGIS Enterprise за замовчуванням використовує HTTPS-only communication (обмін даними виключно через HTTPS).
У production-середовищі вимикати HTTPS-only без конкретної архітектурної причини не варто. Через ці з’єднання передаються credentials (облікові дані), temporary tokens (тимчасові токени доступу) та інші дані, пов’язані з авторизацією.
Але для захищеної Enterprise GIS важливіше дивитися ширше: TLS повинен працювати коректно не тільки між browser (браузером) і Portal. Потрібно перевірити trust chain (ланцюжок довіри сертифікатів) між reverse proxy (зворотним proxy-сервером) або load balancer (балансувальником навантаження), Web Adaptor, Portal, federated ArcGIS Server sites (федеративними сайтами ArcGIS Server), Data Store та іншими компонентами.
Особливої уваги потребують self-signed certificates (самопідписані сертифікати), які часто залишаються після початкового deployment (розгортання). У production-архітектурі сертифікати та certificate authority (центр сертифікації) мають бути частиною загальної PKI-політики (політики інфраструктури відкритих ключів) організації, а не окремим GIS-налаштуванням.
Що змінилося в ArcGIS Enterprise 12.1
В ArcGIS Enterprise 12.1 спрощено керування SSL/TLS certificates (сертифікатами SSL/TLS). Термін дії внутрішніх сертифікатів скорочено до 200 днів, що відповідає тенденції до коротших certificate lifecycles (термінів дії сертифікатів).
Для більш регулярної ротації сертифікатів у Portal Admin API (адміністративному API Portal) додано операцію /update. Вона дозволяє оновити наявний SSL certificate за допомогою .pfx-файлу без необхідності перезапускати компоненти ArcGIS Enterprise.
Для адміністратора це означає, що certificate rotation (ротацію сертифікатів) варто розглядати як регулярну операційну процедуру, а не як налаштування, до якого повертаються лише після завершення терміну дії сертифіката.
ArcGIS Data Store не повинен залишатися «внутрішнім, тому безпечним»
У багатьох deployment (розгортаннях) ArcGIS Data Store прихований від кінцевого користувача, тому його security configuration (конфігурація безпеки) отримує менше уваги, ніж Portal або ArcGIS Server. Але саме relational data store (реляційне сховище даних), tile cache (сховище кешу тайлів) або object stores (об’єктні сховища) можуть містити значну частину operational GIS data (операційних GIS-даних).
На машинах Data Store доцільно дозволяти лише порти, необхідні для комунікації компонентів ArcGIS Enterprise. Окремо потрібно контролювати TLS для relational data store, регулярність backups (резервних копій) і credentials (облікові дані) системних accounts (облікових записів).
Принцип простий: те, що компонент не має публічного URL, не виключає його з security model (моделі безпеки). Якщо зловмисник або скомпрометований хост уже знаходиться всередині мережі, саме внутрішня сегментація визначає, наскільки далеко він зможе просунутися.
Disconnected deployment: відключити Internet недостатньо
Якщо політика організації забороняє зовнішній доступ, ArcGIS Enterprise може працювати у disconnected environment (ізольованому середовищі без доступу до Інтернету). Але air-gapped deployment (фізично або логічно ізольоване розгортання) - не звичайний Enterprise із заблокованим outbound traffic (вихідним мережевим трафіком).
Portal має низку функцій, які потенційно використовують ресурси ArcGIS Online або інші зовнішні endpoints (кінцеві мережеві точки). Тому після мережевої ізоляції необхідно замінити ці залежності локальними ресурсами. Для disconnected deployment (ізольованого розгортання) конфігурація включає роботу з HTTPS, external content (зовнішнім контентом), utility services (допоміжними сервісами) та software updates (оновленнями програмного забезпечення).
На практиці це означає, що перед ізоляцією потрібно відповісти щонайменше на чотири питання: звідки братимуться basemaps (базові карти), де працюватимуть geocoding (геокодування) і routing services (сервіси маршрутизації), які Living Atlas resources (ресурси Living Atlas) потрібні користувачам і як у закрите середовище потраплятимуть security patches (оновлення безпеки).
Basemap gallery потрібно перевести на локальні ресурси
Якщо організація використовує basemaps (базові карти) з ArcGIS Online, після відключення Internet вони перестануть бути доступними.
Для disconnected environment потрібно опублікувати необхідні basemaps у власному Enterprise та налаштувати локальну basemap gallery (галерею базових карт). Це краще зробити до повної ізоляції системи, щоб користувацькі web maps (вебкарти) та applications (застосунки) не залишилися із зовнішніми залежностями після переходу.
Такий самий аудит варто провести для existing maps (наявних карт): навіть якщо operational layers знаходяться всередині Enterprise, basemap або reference layer (довідковий шар) може залишатися зовнішнім.
Utility services - одна з найчастіше забутих залежностей
Geocoding, routing, printing (друк карт) та інші utility services також необхідно перевірити до переходу в disconnected mode (ізольований режим роботи).
Якщо workflow (робочий процес) користувачів залежить від online geocoding (онлайн-геокодування) або routing, просте блокування Internet призведе не до «безпечнішої GIS», а до частково непрацюючого середовища.
Для ізольованого deployment потрібні локальні alternatives (альтернативні сервіси), опубліковані у власній інфраструктурі ArcGIS Server та підключені до Portal як відповідні utility services.
Тому хороший disconnected deployment починається з inventory (інвентаризації) зовнішніх залежностей, а не з команди мережевій команді «закрити Internet».
Federation теж потрібно розглядати як security boundary
У federated ArcGIS Server (федеративному ArcGIS Server) security керується через Portal. Це спрощує identity та sharing model, але означає, що federation впливає не лише на зручність адміністрування, а й на security architecture (архітектуру безпеки).
Для вже існуючих Enterprise environments варто перевірити, чи всі Server sites (сайти ArcGIS Server), які повинні бути federated, дійсно federated, чи не залишилися stand-alone sites (автономні сайти ArcGIS Server) із власними users/roles (користувачами та ролями), і чи немає сервісів, доступ до яких контролюється за іншою моделлю, ніж очікують адміністратори Portal.
Окремої уваги потребують environments (середовища), які розвивалися поступово: спочатку stand-alone ArcGIS Server, потім Portal, потім federation. Саме в таких системах найчастіше накопичуються різні моделі доступу, legacy endpoints (застарілі кінцеві точки доступу) і services (сервіси), для яких поточна sharing policy вже неочевидна.
Patch management важливіший за сам факт ізоляції
Внутрішня мережа або disconnected deployment не є заміною security updates (оновлень безпеки). У серпні 2026 року вийшов Portal for ArcGIS 2026 Security Update 3, який усуває низку вразливостей у Portal for ArcGIS 12.1 та попередніх версіях. Оновлення є cumulative (кумулятивним), тому для його встановлення не потрібно попередньо встановлювати попередні Portal for ArcGIS security patches.
Для попередніх версій ArcGIS Server також випускалися окремі security patches. Наприклад, ArcGIS Server Security 2026 Update 2 Patch, опублікований у травні 2026 року, призначений для ArcGIS Server 12.0 та попередніх підтримуваних версій і усуває, зокрема, вразливості critical severity (критичного рівня). Це важливий нюанс: applicability (застосовність) конкретного patch потрібно перевіряти саме для встановленої версії кожного компонента. Не варто сприймати ArcGIS Enterprise як один продукт з одним update cycle (циклом оновлень) для Portal, ArcGIS Server та інших складових.
У disconnected environment процес повинен бути формалізований: перевірка доступних updates (оновлень) із дозволеного зовнішнього середовища, перевірка applicability, перенесення пакетів відповідно до внутрішньої політики, тестування та встановлення у production. Інакше ізоляція може створити протилежний ефект: deployment не має прямого доступу до Internet, але продовжує працювати з уже відомими vulnerabilities (вразливостями).
Після upgrade перевіряйте не тільки функціональність
Upgrade ArcGIS Enterprise часто перевіряють через стандартний набір сценаріїв: чи відкривається Portal, чи працюють hosted layers, чи публікується service, чи доступні web maps. Для security цього недостатньо. Наприклад, починаючи з ArcGIS Enterprise 12.0, proxy capability Portal працює за моделлю restricted by default (обмежено за замовчуванням). Після upgrade з попередньої версії існуючі allowed proxy hosts (дозволені proxy-хости) зберігаються, а система також може додати default hosts і hosts, необхідні для existing items (наявних елементів).
Тому після upgrade варто виконувати не лише functional testing (функціональне тестування), а й configuration review (перевірку конфігурації): proxy allowlist (список дозволених proxy-хостів), origins (дозволені джерела запитів), trusted servers, authentication (автентифікацію), certificates (сертифікати), federation, sharing, зовнішні URL у web maps і applications. Особливо якщо Enterprise deployment існує кілька років і проходив декілька upgrade cycles (циклів оновлення версій).
Security scan має стати регулярною перевіркою, а не разовою процедурою
ArcGIS Enterprise має окремий інструмент для пошуку типових security misconfigurations (помилок конфігурації безпеки) — portalScan.py. Він перевіряє конфігурацію Portal за набором security criteria (критеріїв безпеки) та класифікує знайдені проблеми за severity (рівнем критичності). Серед перевірок — proxy restrictions (обмеження proxy-запитів), token requests (запити токенів), HTTPS, certificates та інші параметри конфігурації.
Найбільшу цінність такий scan (сканування) має не одразу після installation (встановлення), а як регулярна контрольна точка:
до upgrade → після upgrade → після зміни authentication → після зміни reverse proxy/WAF (зворотного proxy або Web Application Firewall) → після federation нового Server site → після суттєвих змін network architecture (мережевої архітектури).
У такому випадку security configuration можна контролювати так само, як availability (доступність) або performance (продуктивність), а не перевіряти лише після інциденту.
Для критичної GIS security без recovery недостатньо
Захищене середовище повинно бути не тільки складним для несанкціонованого доступу, а й відновлюваним. ArcGIS Enterprise підтримує disaster recovery architecture (архітектуру аварійного відновлення) із standby deployment (резервним середовищем). Standby environment може бути фізично відокремлене від primary deployment (основного середовища) і навіть працювати як disconnected environment. У разі втрати primary його можна перевести в active state (активний стан).
Для організацій, де Enterprise підтримує operational workflows (операційні робочі процеси), recovery strategy (стратегію відновлення) варто тестувати так само регулярно, як backup (резервне копіювання). Наявність export-файлу сама по собі ще не гарантує, що команда зможе відновити Portal, federated servers і пов’язані ресурси в потрібний час. Тому security architecture Enterprise краще розглядати разом із reliability (надійністю), observability (спостережуваністю системи) та disaster recovery, а не як окремий набір параметрів у вкладці Security. Для enterprise GIS security є одним із взаємопов’язаних елементів поряд із reliability, performance (продуктивністю), integrations (інтеграціями), automation (автоматизацією) та observability.
Observability допомагає адміністраторам контролювати стан, продуктивність і використання ArcGIS Enterprise та виявляти проблеми до того, як вони вплинуть на користувачів. Джерело: Esri.
Що варто перевірити у вже працюючому ArcGIS Enterprise
Якщо ArcGIS Enterprise у вашій організації вже використовується, питання має звучати не «чи захищений наш Portal?», а ширше: які шляхи доступу до GIS-даних залишаються поза нашим контролем?
Перевірте sharing існуючих services після federation і migrations, allowed proxy hosts та origins, зовнішні URL у web maps і applications, certificate chain між компонентами, мережевий доступ до ArcGIS Data Store, актуальність Portal та Server security patches, а також залежність користувацьких workflows від ArcGIS Online.
Для disconnected deployment додатково варто скласти inventory всього, що Enterprise отримував із зовнішнього середовища: basemaps, utility services, Living Atlas resources, software updates та сторонні services. Саме після такого аудиту стає зрозуміло, чи deployment дійсно працює в контрольованому середовищі, чи просто фізично знаходиться у внутрішній мережі.
Потрібна технічна підтримка ArcGIS Enterprise?
ECOMM Co - офіційний партнер Esri в Україні. Надаємо абонентську технічну підтримку та консультаційний супровід систем на базі ArcGIS Enterprise.
Допомагаємо з аналізом і оптимізацією архітектури, налаштуванням Portal for ArcGIS, ArcGIS Server, ArcGIS Data Store, Web Adaptor, HTTPS/SSL, federation і прав доступу. Виконуємо оновлення версій та встановлення офіційних патчів Esri, резервне копіювання й відновлення системи, діагностику інцидентів, аналіз логів, а також надаємо рекомендації щодо продуктивності, High Availability та безпеки.
Підтримка також охоплює ArcGIS Pro та WebGIS: роботу з геоданими, публікацію сервісів, Web Maps і Web Apps, просторовий аналіз та автоматизацію задач.
Не пропустіть 13–14 жовтня - «GIS + AI: Нові горизонти розвитку», єдина конференція ArcGIS в Україні.
Реєстрація відкрита
🌐Детільніше про конференцію : https://esri2026.com.ua/