Система ведёт реестр предоставленных доступов: кому, куда, какой доступ, на какое время и на каком основании предоставлен. Это именно учёт — записи для службы ИБ и опора для настройки реальных систем (фаервол, VPN, AD), а не сама настройка: изменение записи в реестре ничего не «прорубает» и не отзывает технически (если не настроены дополнительные внешние интеграции).
flowchart LR
TA["Временный доступ<br>(когда, основание)"] -. опционально .-> ACL
ACL["ACL<br>(куда: 1 ресурс)"] --> ACE["ACE<br>(кому и какой)"]
ACE --> T["Типы доступа<br>(+ IP-параметры)"]
Ниже — сценарии, на которые эта конструкция рассчитана.
ACL без расписания — постоянный доступ. Так фиксируются интеграции и служебные взаимодействия: «Сервис1 ходит в Сервис2 по LDAPS, TCP 939», «система мониторинга опрашивает все серверы по SNMP». Субъектом и ресурсом могут быть сервисы целиком: доступ автоматически распространяется на все узлы, обеспечивающие работу сервиса (включая дочерние сервисы).
Эти записи видны с обеих сторон — на карточке сервиса есть вкладки входящих («доступы сюда») и исходящих («доступы отсюда») доступов, так что карта взаимодействий сервисов читается прямо из реестра.
Связь через посредника. Когда сервис ходит в другой сервис через реверс-прокси или шлюз, связь записывается двумя доступами (сервис → посредник, посредник → конечный сервис) и указателем «следующий хоп» между ними — см. транзит. Собранный маршрут показывает колонка «Маршрут»: у посредника видно, какие соединения транзитные, у конечного сервиса — кто приходит к нему через посредника. Переключатель уровня над вкладками доступов оставляет либо информационный взгляд (кто к чему и каким путём), либо сетевой (узлы, адреса и порты одного хопа — то, что нужно для настройки сетевых ACL).
Публикация наружу. Проброс (NAT, реверс-прокси) — тоже запись доступа,
с галочкой «Проброс»: субъект — белый адрес входа, ресурс — узел назначения,
в параметрах порт входа -> порт назначения. Вместе с
DNS-именами на белом адресе это даёт цепочку
«внешнее имя → адрес → узел», видимую с карточек узла, адреса и имени.
Основной сценарий службы ИБ: согласованная заявка на доступ (например, удалённый доступ подрядчика — VPN + RDP к терминальному серверу + HTTPS к порталу). Оформляется одним временным доступом:
Пошагово — в руководстве «Временные доступы».
Продление — не новая заявка, а новый период в существующем временном доступе: вся история предоставлений одного и того же комплекта копится в одном месте. Досрочный отзыв — период отзыва (красный). Записи при этом не удаляются: реестр сохраняет и то, что доступ был, и то, когда его закрыли.
Когда один и тот же комплект выдаётся разным людям (типовая служебка на удалённый доступ), работает копирование: кнопка копии в заголовке формы редактирования временного доступа создаёт глубокую копию всех его ACL и записей доступа, в форме копии сразу заменяются субъекты. Периоды образца не копируются — новой выдаче задаются свои.
Из этого же получаются шаблоны: временный доступ-образец без реальных субъектов и периодов (например «Шаблон: стандартный удалённый доступ»); выдача по шаблону — копия с подменой субъектов. Подробнее — раздел «Копирование и шаблоны» руководства «Временные доступы».
У сервиса можно задать стандартные типы доступа — какие типы обычно выдаются при предоставлении доступа к нему (порталу — HTTPS, терминалам — RDP), в том числе с переопределением сетевых параметров (HTTPS на нестандартном порту — «TCP 8140»). При выборе такого сервиса ресурсом форма записи доступа предзаполняется этими типами и параметрами. Помимо ускорения ввода это документация «как ходят в этот сервис» — она видна в карточке сервиса.
Тип доступа может включать в себя другие («Удалённый доступ» = VPN + RDP): при выборе комплексного типа его дочерние отмечаются автоматически и блокируются от снятия — реестр всегда показывает полный фактический набор. Так оформляются типовые роли доступа без дублирования записей.
К кластеру, ферме или другому составному объекту доступ учитывается через сервис, а не через перечисление узлов: ACL указывает на сервис, а сервис знает свои узлы. Добавили в кластер ещё один сервер — достаточно добавить его в сервис, переделывать выданные доступы не нужно.
Доступ «откуда угодно из сегмента куда угодно в сегмент» записывается одним списком доступа: ресурс — сегмент, субъект записи — тоже сегмент. Такие доступы складываются в матрицу межсегментного доступа (меню Сети → Матрица сегментов): строки — откуда, колонки — куда, в ячейке — разрешённые типы доступа с портами. Точечные доступы к отдельным узлам и сервисам сегмента в матрицу не попадают — они видны на странице сети, вкладка «Вх. соединения».
Система не настраивает фаерволы, VPN-серверы и каталоги пользователей — реестр первичен, техническая настройка делается по нему. Поэтому записи должны отражать фактически выданное: все предзаполнения (стандартные типы сервиса, комплексные типы) — это подсказки, итоговый набор всегда можно поправить руками перед сохранением.