BURSU PAM

Что такое BURSU PAM

BURSU PAM — шлюз привилегированного доступа (PAM, Privileged Access Management) от BURSUsofts. Это сервер, который встаёт между администраторами и серверами, которыми они управляют. Человек подключается не к целевому серверу, а к шлюзу; шлюз сам входит на целевой сервер с паролем или ключом, которого человек не видит и не знает, записывает всё, что происходит в сессии, позволяет аудитору смотреть сессию вживую и прервать её, а каждое действие заносит в журнал аудита, защищённый от незаметной правки.

Что умеет шлюз

Кто работает со шлюзом

В консоли четыре роли. Подробно они разобраны в главе «Роли»; здесь — чтобы понимать, для кого какая глава.

Как устроен шлюз

Шлюз — один процесс .NET 10 (служба bursu-pam-gateway) на вашем сервере, рядом с базой PostgreSQL. Он принимает подключения людей на своих портах, проверяет, разрешено ли подключение, сам открывает соединение с целевым сервером и пропускает сессию через себя, записывая её.

  Пользователь                                   Шлюз BURSU PAM                              Целевые серверы
 ───────────────                ──────────────────────────────────────────────           ────────────────
  BURSUcm (PAM Gateway) ─HTTPS─►  веб-консоль и API клиентов  (порт 443)
                        ─SSH───►  SSH-вход                   (порт 2222) ─── SSH ──────►  Linux, Unix
  OpenSSH, PuTTY, WinSCP ──────►      │                                   ─── Telnet ───►  сетевое оборудование
  mstsc, файл .rdp ────────────►  RDP-вход                   (порт 3389) ─── RDP ──────►  Windows
  VNC-просмотрщик ─────────────►  VNC-вход                   (порт 5900) ─── VNC ──────►  Linux, macOS
  psql / mysql / sqlcmd ───────►  входы баз данных (15432 / 13306 / 11433) ─────────────►  СУБД
                                       │
                 правила · секреты · запись · живой просмотр · аудит
                                       │
             PostgreSQL (каталог, журнал)   /var/lib/bursu-pam (ключи, записи)   SIEM (syslog)

Путь одной сессии

1. Вход. Пользователь подключается к шлюзу: из BURSUcm — после входа в консоль паролем и кодом TOTP клиент получает одноразовый билет (ticket) на одно подключение; из обычного SSH-клиента — именем вида логин:сервер, паролем и кодом TOTP.
2. Проверка правила. Шлюз проверяет, есть ли действующее правило доступа (или одобренный запрос) для этого человека, сервера и учётной записи, и что разрешено в сессии: терминал, файлы, буфер обмена.
3. Вход на цель. Шлюз расшифровывает секрет учётной записи и входит на целевой сервер сам. Для SSH он сверяет ключ хоста цели с подтверждённым администратором, для RDP и VNC — сертификат.
4. Запись и наблюдение. Всё, что проходит через сессию, записывается; аудитор видит сессию вживую и может её прервать. Команды проверяются политиками контроля команд.
5. Конец. Сессия заканчивается, когда пользователь выходит, истекает время простоя, кончается правило или аудитор прерывает её. Запись закрывается и подписывается, события попадают в журнал аудита и в SIEM.

Секреты и ключ шифрования

Пароли и ключи целевых серверов хранятся в базе в зашифрованном виде. Их шифрует мастер-ключ шлюза, который лежит в каталоге ключей /var/lib/bursu-pam/keys, а не в базе. Поэтому копия базы без каталога ключей бесполезна — ни один секрет и ни одна запись из неё не читаются. Мастер-ключ защищается одним из двух способов, который выбирается в мастере первоначальной настройки:

• Protected by the operating system (рекомендуется) — ключ лежит в файле, который может прочитать только служба шлюза; после перезагрузки шлюз запускается сам.
• Sealed with a passphrase — после каждого перезапуска службы администратор вводит парольную фразу на странице /unseal; пока шлюз «запечатан», он не работает. См. «Запечатанный режим».

На случай потери ключа или забытой фразы мастер один раз показывает ключ восстановления. Его нужно распечатать и хранить офлайн, в сейфе, — не на сервере шлюза.

Журнал аудита и записи

Каждое событие (вход, изменение настройки, начало и конец сессии, команда, передача файла…) записывается в журнал аудита. Записи связаны в цепочку хешей: каждая содержит хеш предыдущей, а шлюз регулярно ставит контрольные точки. Если кто-то изменит или удалит строку прямо в базе, проверка целостности это покажет. Записи сессий хранятся в каталоге /var/lib/bursu-pam/recordings вместе с подписанными описаниями (манифестами) и хешами.

Изоляция графических сессий

Каждая сессия RDP и VNC и каждая задача отрисовки записи (живой просмотр, плеер, экспорт MP4) выполняется в отдельном процессе-«работнике» с жёсткими ограничениями ядра Linux: своя контрольная группа (cgroup v2) с лимитами памяти, процессов и процессора, Landlock (запрет доступа к файлам) и seccomp (фильтр системных вызовов). Поэтому шлюзу нужны эти возможности ядра — см. «Требования». SSH-сессии и веб-консоль от них не зависят.

Требования

Сервер шлюза

База данных

Нужен PostgreSQL 15 или новее. Проще всего — локальный PostgreSQL 16 из архива Ubuntu: пакет подтянет его сам и создаст базу bursu_pam и роль bursu-pam, которая входит через Unix-сокет без пароля (peer-аутентификация). Можно использовать и внешний сервер PostgreSQL — тогда на шлюзе нужен только клиент PostgreSQL, и поставить его надо до пакета (иначе apt сам подтянет полный сервер PostgreSQL), а строка подключения передаётся отдельно (см. «База на другом сервере»).

Порты

Порт 22 остаётся у собственного SSH-сервера машины (для её администрирования), порт 5432 — у собственного PostgreSQL. Номера можно поменять командой bursu-pam-configure. Пакет не трогает сетевой экран — порты открываете вы, см. «Сеть и брандмауэр».

Исходящие соединения шлюза: к целевым серверам (их порты SSH, RDP, VNC, Telnet, СУБД), к контроллерам домена (LDAPS и Kerberos, если используется вход из каталога), к SMTP-серверу и адресам веб-хуков (уведомления), к приёмнику SIEM, и — только если вы сами нажмёте кнопку онлайн-активации или включите ежедневную проверку — к https://bursucm.com (см. «Лицензия»). Без интернета шлюз работает полностью; лицензия активируется кодом запроса.

Сертификат

Без настройки шлюз сам создаёт самоподписанный сертификат (ECDSA P-256, на два года), и браузер при первом входе предупредит о нём — это ожидаемо. Для работы в организации лучше выпустить сертификат вашим удостоверяющим центром на имя шлюза (например pam.example.org) — см. «Сертификат шлюза». Если включён VNC, имя, по которому клиенты обращаются к шлюзу, обязано быть в сертификате.

Рабочие места пользователей

• Браузер — любой современный, для консоли. Консоль работает и без JavaScript.
• Приложение-аутентификатор на телефоне для кодов TOTP (6 цифр, 30 секунд, SHA-1): Google Authenticator, Microsoft Authenticator, FreeOTP, Aegis и подобные.
• BURSU Connection Manager (по желанию) — Windows или Linux/macOS, режим PAM Gateway. Либо обычные клиенты: OpenSSH, PuTTY, WinSCP, FileZilla, mstsc, VNC-просмотрщик, psql, mysql, sqlcmd.

Быстрый старт: от пустого Ubuntu до первой записанной сессии

Этот путь проходится примерно за полчаса. Нужен сервер Ubuntu 24.04 (amd64) с постоянным адресом, доступ к нему по SSH с правами sudo и интернет-доступ к архиву пакетов Ubuntu (пакет подтягивает PostgreSQL и библиотеки). В примерах адрес шлюза — 192.0.2.10; подставьте свой.

1. Подготовьте сервер. Обновите систему (sudo apt update && sudo apt upgrade), проверьте время (timedatectl — строка System clock synchronized: yes) и, если будет вход по Kerberos, задайте полное имя хоста (sudo hostnamectl set-hostname pam.example.org).
2. Скопируйте пакет и проверьте его подлинность. Скопируйте на сервер всю папку выпуска, которую вы получили от BURSUsofts (в ней .deb, SHA256SUMS, SHA256SUMS.asc и ключ bursu-pam-release.gpg), и в этой папке выполните проверку из раздела «Проверка пакета».
3. Установите пакет одной командой.

   sudo apt install ./bursu-pam_1.0.0_amd64.deb

   Пакет создаст учётную запись bursu-pam, каталоги, базу bursu_pam и файл /etc/bursu-pam/gateway.json, а затем сам задаст несколько вопросов про адрес и порты. Нажимайте Enter на каждом вопросе — значения по умолчанию дают рабочий шлюз на одном сервере, — и в конце ответьте y на Apply?. Подробно — «Порты и протоколы».
4. Запишите адрес и код настройки. Последние строки установки выглядят так:

     Open in a browser:  https://192.0.2.10/setup
     Setup code:         XXXX-XXXX-XXXX

   Код одноразовый; если потеряли — sudo cat /var/lib/bursu-pam/setup-code.
5. Откройте порты. Если на сервере включён ufw, установщик напечатал готовые команды sudo ufw allow …/tcp — выполните их. Если между пользователями и шлюзом есть другой сетевой экран — откройте те же порты там. См. «Сеть и брандмауэр».
6. Пройдите мастер первоначальной настройки. Откройте https://192.0.2.10/setup в браузере, согласитесь продолжить несмотря на предупреждение о самоподписанном сертификате и пройдите 7 шагов: код настройки → язык → режим ключа → ключ восстановления (распечатайте его) → первый администратор → TOTP и коды восстановления → готово. Подробно — «Первоначальная настройка».
7. Войдите и включите лицензию. Нажмите Go to sign-in, войдите паролем и кодом из приложения, откройте Settings → Licence. Есть интернет — Start the 7-day trial online → Send this one call. Нет — Start the 7-day trial в блоке Request codes (offline), затем код вводится на bursucm.com с любого компьютера. Пока лицензии нет, шлюз не пропускает ни одной сессии и не даёт ничего менять. Подробно — «Лицензия».
8. Добавьте сервер. Servers → Create server: имя, протокол SSH, адрес и порт. На карточке сервера подтвердите ключ хоста. Подробно — «Серверы».
9. Добавьте учётную запись сервера. На карточке сервера, вкладка учётных записей (или Accounts → Add account): логин на целевом сервере и его пароль или SSH-ключ. Шлюз сохранит секрет зашифрованным; показать его потом нельзя. См. «Учётные записи и секреты».
10. Создайте пользователя. Users → Create user: логин, имя, роль User, временный пароль. При первом входе он сменит пароль и привяжет TOTP. См. «Пользователи».
11. Создайте правило доступа. Access rules → Create rule: кто (пользователь или группа), к чему (сервер и учётная запись), что разрешено (терминал, файлы). См. «Правила доступа».
12. Подключитесь. Из BURSUcm: режим хранения PAM Gateway, адрес шлюза, вход пользователя — сервер появится в каталоге, двойной щелчок открывает сессию (подробно). Или из любого терминала:

    ssh -p 2222 ivanov:web01@192.0.2.10

    где ivanov — логин пользователя шлюза, web01 — имя сервера в консоли; шлюз спросит пароль пользователя и код TOTP (подробно).
13. Посмотрите запись. Войдите в консоль администратором: Sessions показывает идущую сессию (её можно смотреть вживую и прервать), а после выхода — запись с поиском по набранному тексту. См. «Сессии и записи».

Установка пакета

Проверка пакета

Выпуск поставляется папкой, а не одним файлом. В ней лежат: пакет bursu-pam_1.0.0_amd64.deb, inputs.manifest (из чего собран пакет), lintian.txt (отчёт проверки пакета), отчёт тестов suite-report.<коммит>.txt, список контрольных сумм SHA256SUMS, его подпись SHA256SUMS.asc и открытый ключ BURSUsofts bursu-pam-release.gpg. Скопируйте на сервер всю папку и в ней выполните:

gpg --show-keys --with-colons bursu-pam-release.gpg | grep '^fpr'
gpgv --keyring ./bursu-pam-release.gpg SHA256SUMS.asc SHA256SUMS && sha256sum -c SHA256SUMS

• Первая команда печатает отпечаток ключа. Сверьте его с отпечатком, который BURSUsofts сообщила вам по другому каналу (письмом, по телефону), — а не с тем, что лежит рядом с пакетом: gpgv доверяет любому ключу из переданного ему файла.
• Вторая команда должна закончиться без ошибок: gpgv пишет Good signature, а sha256sum -c — OK у каждого из четырёх файлов. BAD signature означает, что список сумм подменён; FAILED у файла — что подменён или повреждён сам файл. В обоих случаях не устанавливайте пакет и свяжитесь с поставщиком.
• Если вы скопировали только .deb, sha256sum -c сообщит о трёх отсутствующих файлах — это не повреждение, а неполная папка.

Установка

sudo apt install ./bursu-pam_1.0.0_amd64.deb

Обязательно с ./ перед именем файла — иначе apt будет искать пакет в репозиториях. apt сам доставит зависимости из архива Ubuntu: PostgreSQL 16, библиотеки Kerberos (libgssapi-krb5-2), ICU, OpenSSL, jq и другие.

Что делает пакет

После распаковки файлов пакет запускает программу bursu-pam-setup (её можно запускать и повторно — второй запуск ничего не меняет). По порядку:

1. Учётная запись. Создаёт локальную системную учётную запись bursu-pam: без пароля, без оболочки входа, со своей группой, в которой никого больше нет, и без дополнительных групп. Если учётная запись с таким именем уже есть, но не соответствует этим требованиям (например, состоит в группе docker или имеет оболочку), установка останавливается и называет команду, которой это исправить.
2. Каталоги. /etc/bursu-pam (root:bursu-pam, 0750), /var/lib/bursu-pam (bursu-pam, 0700), /var/backups/bursu-pam (root, 0700). Содержимое существующих каталогов не трогает никогда.
3. База данных. На первом работающем локальном кластере PostgreSQL версии 15+ создаёт роль bursu-pam (только LOGIN, без пароля и без особых прав) и базу bursu_pam, которой владеет эта роль и к которой больше никто не имеет доступа. Файлы pg_hba.conf и postgresql.conf не меняет.
4. Проверка входа. Убеждается, что роль входит в свою базу через Unix-сокет по peer-аутентификации — без пароля.
5. Конфигурация. Пишет /etc/bursu-pam/gateway.json (root:bursu-pam, 0640) — только если его ещё нет. Существующий файл никогда не перезаписывается; если пакет предложил бы другое содержимое, оно кладётся рядом в gateway.json.proposed.

Затем пакет запускает проверку bursu-pam-check --quiet (печатает только предупреждения и ошибки, установку не прерывает), включает службу bursu-pam-gateway и — при новой установке в терминале — задаёт вопросы про порты (следующая глава), после чего запускает шлюз.

При первом запуске шлюз сам создаёт в базе свои таблицы, в каталоге данных — самоподписанный сертификат и файл с одноразовым кодом настройки /var/lib/bursu-pam/setup-code.

Что и где лежит

Пакет не содержит ни паролей, ни ключей, ни сертификатов, ни лицензии.

Как выглядит установка в терминале

Пример вывода новой установки на сервере с адресом 192.0.2.10 (собран по текстам установочных скриптов; строки самого apt сокращены). Ваши строки могут немного отличаться — например, набором предупреждений проверки.

$ sudo apt install ./bursu-pam_1.0.0_amd64.deb
…
Setting up bursu-pam (1.0.0) ...
bursu-pam-setup: account bursu-pam: created (system account, no login shell, no password)
bursu-pam-setup: /etc/bursu-pam: created root:bursu-pam 0750
bursu-pam-setup: /var/lib/bursu-pam: created bursu-pam:bursu-pam 0700
bursu-pam-setup: /var/backups/bursu-pam: created root:root 0700
bursu-pam-setup: PostgreSQL 16/main: role bursu-pam created (LOGIN only, no password)
bursu-pam-setup: PostgreSQL 16/main: database bursu_pam created, owned by bursu-pam, closed to PUBLIC
bursu-pam-setup: peer authentication of bursu-pam over /var/run/postgresql: ok
bursu-pam-setup: /etc/bursu-pam/gateway.json: written (root:bursu-pam 0640)
WARN hostname: the host name pam is not fully qualified; Kerberos needs the FQDN (…)
bursu-pam postinst: a few questions follow (Enter takes the default; Ctrl+C keeps the defaults; later: sudo bursu-pam-configure)
BURSU PAM gateway - listeners and ports
Press Enter to take the value in [brackets]. Nothing changes until you confirm at the end.
…  (вопросы — см. следующую главу)
  Open in a browser:  https://192.0.2.10/setup
  Setup code:         XXXX-XXXX-XXXX
  (lost it? sudo cat /var/lib/bursu-pam/setup-code)
  (the browser will warn about the self-signed certificate - expected; continue)

Установка без вопросов

Вопросы задаются, только если это новая установка, вывод идёт в терминал, systemd работает, и не задано ни DEBIAN_FRONTEND=noninteractive, ни BPAM_NO_WIZARD=1. В остальных случаях (автоматизированная установка, обновление) шлюз запускается с портами по умолчанию (консоль 443, SSH 2222; RDP, VNC и входы баз данных выключены), а вместо кода печатается только команда, которая его покажет:

sudo DEBIAN_FRONTEND=noninteractive apt install -y ./bursu-pam_1.0.0_amd64.deb
sudo bursu-pam-configure --next-steps        # адрес для браузера и код настройки

Порты можно задать позже той же командой sudo bursu-pam-configure.

База на другом сервере

Если база будет на отдельном сервере PostgreSQL (версии 15+), создайте там роль и базу сами (владелец базы — эта роль; лишних прав роли не давайте) и передайте шлюзу строку подключения Npgsql.

Строку с паролем передавайте только через стандартный ввод, чтобы она не попала в список процессов. Перенаправление < выполняет ваша оболочка, а не sudo, поэтому файл со строкой должен быть доступен вам самому: положите его в свой домашний каталог с правами только для вас.

(umask 077; nano ~/pam-connstring.txt)        # одна строка, см. ниже
sudo bursu-pam-setup --connection-string - < ~/pam-connstring.txt
rm ~/pam-connstring.txt
sudo systemctl enable --now bursu-pam-gateway
sudo bursu-pam-configure

В файле — одна строка, например:

Host=db.example.org;Port=5432;Database=bursu_pam;Username=bursu_pam;Password=…;SSL Mode=VerifyFull

Файл удаляйте сразу после записи конфигурации (вторая команда). Помните: в этом случае пароль базы хранится в gateway.json (файл читают только root и служба), а пакет не делает автоматическую копию базы перед обновлением — копию делаете вы на сервере базы.

Если при установке на хосте не оказалось работающего PostgreSQL (или не нашлось клиента), пакет сообщит provisioned except the database и не запустит шлюз — после исправления выполните sudo bursu-pam-setup ещё раз и sudo systemctl enable --now bursu-pam-gateway.

Порты и протоколы: bursu-pam-configure

bursu-pam-configure — короткий мастер в терминале, который задаёт адрес шлюза и порты. При новой установке его вызывает сам пакет; позже его можно запускать сколько угодно раз:

sudo bursu-pam-configure                 # вопросы; Enter — значение в [скобках]
sudo bursu-pam-configure --next-steps    # только: куда идти в браузере и код настройки

До ответа y на последний вопрос ничего не меняется. При повторном запуске значениями по умолчанию становятся текущие настройки.

Вопросы

Мастер не даст выбрать порт, который уже занят другой программой (назовёт её и номер процесса), порт, выбранный дважды, и порт 5432. При повторном запуске выключенный ранее протокол по умолчанию предлагается выключенным.

Если включён VNC, а самодельный сертификат шлюза не содержит выбранного адреса, мастер спросит Let the gateway make a new certificate? (the old one is kept as a .bak file). Ответ y откладывает старый сертификат в сторону (копия gateway.pfx.bak-…), и шлюз создаёт новый с этим адресом. Браузеры и клиенты BURSUcm, которые уже доверяли старому сертификату, один раз спросят подтверждение снова. При ответе n VNC остаётся записанным в настройках, но шлюз его не откроет (на Settings → VNC будет написано Address not in the certificate), пока в сертификате нет этого имени; в конце мастер напишет, что VNC пока не слушает. Если вы поставили собственный сертификат (certificatePath), этот вопрос не задаётся — имя в вашем сертификате должно быть заранее.

Что происходит после «y»

1. Текущий gateway.json копируется в /etc/bursu-pam/gateway.json.bak-<время UTC>.
2. В gateway.json записываются только ответы; все остальные параметры остаются как были.
3. Шлюз перезапускается; мастер ждёт до 20 секунд, пока ответит порт консоли (при первом запуске, пока шлюз готовит базу, — до 60 секунд и пишет об этом).
4. Если шлюз не поднялся, прежний файл (и прежний сертификат) возвращается на место, шлюз перезапускается с ним, и мастер показывает последние 30 строк журнала службы — по ним видно, что не так. Код выхода 1.
5. Если поднялся — мастер сообщает, какие порты уже слушаются. SSH, RDP, VNC и входы баз данных открываются только после завершения мастера /setup (а в запечатанном режиме — после распечатывания), поэтому до этого он пишет opens once the first-run setup in the console is finished.
6. В конце — строки проверки хоста, нумерованные следующие шаги (с готовыми командами sudo ufw allow …/tcp, если ufw включён; сам мастер сетевой экран не меняет) и адрес консоли с кодом настройки.

Пример диалога (Enter везде, кроме последнего вопроса):

1. The address people and their programs use to reach this gateway: a DNS name (pam.example.org) or an IP address.
   The console link and VNC sessions use it.
   Address [192.0.2.10]:

2. The web console (administration, and where users sign in) is served over HTTPS.
   Console HTTPS port [443]:

3. SSH: people connect their SSH client (ssh, PuTTY) to the gateway, which signs in to the target server for them.
   SSH port (not 22: the server's own SSH keeps it) [2222]:

4. Let people open RDP (Windows remote desktop) sessions through the gateway? [Y/n]:
   RDP port [3389]:

5. Let people open VNC (remote screen of Linux and macOS desktops) sessions through the gateway? [Y/n]:
   VNC port [5900]:

6. Database fronts: people connect their usual database tool to the gateway, which signs in to the database server for them.
   Port 5432 is not offered: this server's own PostgreSQL, which holds the gateway's data, uses it.
   Offer PostgreSQL through the gateway? [Y/n]:
   PostgreSQL front port [15432]:
   Offer MySQL / MariaDB through the gateway? [y/N]:
   Offer Microsoft SQL Server through the gateway? [y/N]:

Summary:
  Address                192.0.2.10
  Console (HTTPS)        https://0.0.0.0:443
  SSH                    0.0.0.0:2222
  RDP                    0.0.0.0:3389
  VNC                    192.0.2.10:5900
  PostgreSQL front       192.0.2.10:15432
  MySQL front            off
  SQL Server front       off

Apply? This restarts the gateway; open sessions are closed. [y/N]: y

Saved. The previous file is /etc/bursu-pam/gateway.json.bak-20261102T101500Z. Restarting the gateway...
The gateway runs with the new settings.
  SSH (port 2222) opens once the first-run setup in the console is finished.
  RDP (port 3389) opens once the first-run setup in the console is finished.
  VNC (port 5900) opens once the first-run setup in the console is finished.
  PostgreSQL front (port 15432) opens once the first-run setup in the console is finished.

Checking this server (bursu-pam-check --quiet):

Next steps:
  1. Open https://192.0.2.10/setup in a browser.
  2. Enter the one-time setup code (below).
  3. In the console: create the administrator, then install the licence.
  4. The firewall (ufw) is on. Let the gateway's ports in:
       sudo ufw allow 443/tcp
       sudo ufw allow 2222/tcp
       sudo ufw allow 3389/tcp
       sudo ufw allow 5900/tcp
       sudo ufw allow 15432/tcp

----------------------------------------------------------------------------------------------
  Open in a browser:  https://192.0.2.10/setup
  Setup code:         XXXX-XXXX-XXXX
  (lost it? sudo cat /var/lib/bursu-pam/setup-code)
  (the browser will warn about the self-signed certificate - expected; continue)

Когда мастер /setup уже пройден, вместо адреса /setup и кода печатается Console: https://…/.

Коды выхода

Первоначальная настройка (мастер /setup)

Пока шлюз не настроен, в нём есть только одна страница — https://<адрес>/setup; любой другой адрес ведёт на неё. Мастер из семи шагов создаёт ключ шифрования, первого администратора и основные настройки. Первым он спрашивает одноразовый код — чтобы шлюз не «захватил» тот, кто первым откроет страницу.

Шаг 1 · Setup code

Введите код из вывода установки (формат XXXX-XXXX-XXXX, 12 символов; дефисы и регистр не важны). Если вывод потерян: sudo cat /var/lib/bursu-pam/setup-code или sudo bursu-pam-configure --next-steps. Файл читают только служба и root; путь к нему пишется и в журнал службы (сам код — никогда). Неверный код: The setup code did not match. Попыток с одного адреса — не больше 10 в минуту.

Шаг 2 · Language

Default console language — язык консоли по умолчанию: English, Русский, Українська, ქართული, Deutsch, Español, Português, Português (Brasil). Каждый пользователь потом выбирает свой язык в профиле и на странице входа.

Шаг 3 · Key mode

Где хранить ключ, которым шлюз шифрует секреты учётных записей:

• Protected by the operating system (recommended) — ключ лежит в каталоге ключей, его может прочитать только служба. После перезагрузки шлюз запускается сам. Выбирайте этот вариант, если не уверены.
• Sealed with a passphrase — после каждого перезапуска службы администратор вводит парольную фразу на странице /unseal. Надёжнее при краже диска, но пока шлюз запечатан, он не работает (никто не может подключиться). Задайте Passphrase и Repeat the passphrase — не короче 12 символов.

Режим можно сменить позже в Settings → Encryption key (подробно).

Шаг 4 · Recovery key

Мастер показывает ключ восстановления — один раз. Без него секреты не восстановить, если файл ключа потеряется или забудется парольная фраза.

1. Нажмите Download .txt или Print и сохраните ключ офлайн: распечатку — в сейф, файл — на носитель, который хранится отдельно от сервера. Не храните ключ на самом шлюзе.
2. Отметьте I have saved the key in a safe place.
3. В поле Last 4 characters of the key введите последние 4 символа ключа — это проверка, что ключ действительно записан.

Шаг 5 · Administrator

Первый администратор; остальных пользователей он создаст в консоли.

Шаг 6 · Two-factor sign-in

1. Отсканируйте QR-код приложением-аутентификатором или введите ключ вручную (параметры: SHA-1, 6 цифр, 30 секунд).
2. Введите в Code from the app текущий шестизначный код и нажмите Next. The code did not match. Check the time on the phone. — проверьте время на телефоне.
3. Мастер покажет десять кодов восстановления — каждый работает один раз, на случай потери телефона. Сохраните их отдельно от телефона, отметьте I have saved the recovery codes и нажмите Next.

Шаг 7 · Done

Итог: режим ключа, администратор с настроенным вторым фактором, и Setup code — no longer valid, the file is deleted. Две кнопки: Go to sign-in — обычная страница входа, и Next: start the 7-day trial or install a licence — Settings → Licence. Шлюз не пропускает ни одной сессии, пока у него нет лицензии — сразу переходите к «Лицензии».

Если мастер прервался

Ход мастера хранится только в памяти шлюза и привязан к браузеру; через 30 минут без действий, при перезапуске службы или при вводе кода настройки заново он стирается. Если закрыть окно, откройте /setup, введите код настройки снова (он действует до конца мастера) и снова выберите язык. Дальше мастер продолжит с того места, которое определяется уже сделанным: если ключ создан, на шаге 3 появится выбор; если создан администратор — мастер сразу перейдёт к шагу 6. Не закрывайте страницу, пока не сохранили ключ восстановления: он показывается один раз и после закрытия вкладки на шаге 4 повторно не покажется. Если ключ уже был создан в прошлый раз, на шаге 3 появится выбор: Continue with this key (если вы сохранили его ключ восстановления) или Create the key again — старый ключ и его ключ восстановления удаляются; это возможно, только пока нет ни администратора, ни одного секрета. Если в каталоге ключей остались файлы от удалённого ключа, мастер назовёт их — перенесите их в другое место и повторите.

Запечатанный режим и /unseal

Страница /unseal появляется в двух случаях. Пока она открыта, консоль и подключения к серверам недоступны.

The gateway is sealed

Вы выбрали режим Sealed with a passphrase, и служба перезапустилась (перезагрузка сервера, обновление пакета, systemctl restart). Введите Passphrase и нажмите Unseal. Шлюз откроется и запустит все входы (SSH, RDP, VNC, базы данных).

Если фраза забыта, нажмите Recover with the recovery key: введите Recovery key, задайте New passphrase и Repeat the passphrase, нажмите Recover and unseal.

The encryption key is unavailable

Режим «защищён ОС», но файла ключа нет или он не подходит к этой базе (например, базу восстановили на новый сервер без каталога /var/lib/bursu-pam/keys). Введите ключ восстановления и нажмите Recover the key. Если после восстановления шлюз пишет The key was recovered и перечисляет проблемы каталога ключей — исправьте их до следующего перезапуска службы; ключ восстановления остаётся действительным.

Не больше 5 попыток в минуту с одного адреса; каждая попытка, удачная или нет, записывается в журнал аудита. Ошибки: The passphrase did not match., The recovery key did not match.

Лицензия

Шлюз лицензируется по числу активных серверов (включённых в консоли); число пользователей не ограничено. Лицензия — подписанный BURSUsofts файл (.bpl), который шлюз проверяет сам, без связи с интернетом. Она привязана к установке (Installation ID) и к этому серверу (отпечаток на основе /etc/machine-id).

Страница: Settings → Licence (/system/licence), только для Administrator. Она работает в любом состоянии лицензии. Каждое действие на ней требует свежего подтверждения: шлюз может ещё раз спросить ваш пароль и код (You may be asked for your password and code again first.).

Карточка Status

Состояния (метка в углу карточки): No licence, Trial, Active, Ends soon (у платной лицензии — до конца 7 дней и меньше), In grace (только у платной), Ended, Activated on another host, Released.

Пробная лицензия на 7 дней

Пробная лицензия даёт все функции на 7 дней и до 25 активных серверов; льготного периода после неё нет. Для одной установки пробную лицензию можно получить один раз; по условиям портала — и одна пробная лицензия на организацию (офлайн-пробная выдаётся через учётную запись bursucm.com). Метки Ends soon у пробной лицензии нет: она показывает Trial до последнего дня и затем сразу Ended, поэтому запишите дату её окончания заранее.

С интернетом — одна кнопка

1. В блоке Online — one call per click нажмите Start the 7-day trial online.
2. Окно покажет, что именно будет отправлено (What is sent): идентификатор установки, отпечаток сервера, версия шлюза, число активных серверов, время шлюза, когда завершена настройка, одноразовое число, порядковый номер лицензии и открытый ключ шлюза — с подписью шлюза. Никаких имён, адресов и данных организации.
3. Нажмите Send this one call. Через несколько секунд: The 7-day trial licence is installed.

Шлюз обращается к bursucm.com только когда вы нажимаете кнопку; в остальное время он ничего не отправляет. Если доступ в интернет только через прокси — задайте его в блоке Proxy server (см. ниже).

Без интернета — код запроса

1. В блоке Request codes (offline) нажмите Start the 7-day trial, затем Make the request code.
2. Шлюз покажет Request code и его QR-код (можно Download as .txt). Код принимается порталом один раз; шлюз запомнил запрос — пока ответа нет, на странице видно Waiting for an answer: ….
3. С любого компьютера с интернетом войдите на https://bursucm.com/pam/activate (нужна учётная запись bursucm.com), вставьте код (или отсканируйте QR телефоном) и получите файл лицензии .bpl.
4. Перенесите файл в закрытую сеть и установите его: Install a licence → Licence file (или вставьте текст в Or paste the licence) → Install. Готово: The licence was installed.

Платная лицензия

При покупке вы получаете ключ активации вида BPK- и 20 символов. Чтобы купить лицензию для конкретной установки, продавцу может понадобиться Claim code этой установки (блок Claim code на странице): он закрепляет установку за вашей организацией на bursucm.com/pam/licences. Блок виден, пока действует пробная лицензия (или лицензия без названия организации); после платной лицензии с названием организации код забывается и блока нет. Для самого пробного периода код не нужен. Храните claim code в тайне — любой, у кого он есть, может закрепить установку за собой.

• Онлайн: Activate with an activation key → введите Activation key → Send this one call → The licence from your activation is installed.
• Офлайн: Activate a paid licence → Make the request code → код вводится на https://bursucm.com/pam/activate, где вы выбираете оплаченное право (entitlement) → полученный файл ставится через Install a licence.
• Готовый файл. Если BURSUsofts прислала файл .bpl, просто установите его через Install a licence. Читается только блок между строками BEGIN и END, подпись проверяется.

Продление и ежедневная проверка

Новую лицензию (продление, больше серверов) устанавливают так же: файлом, онлайн-кнопкой Check now (одно обращение — забрать готовую лицензию, если она есть) или включив Background check-in: Turn the background check-in on — шлюз раз в сутки сам спрашивает bursucm.com о продлениях. По умолчанию проверка выключена. Если она не удаётся неделю подряд, в колокольчике появится предупреждение.

Полученная автоматически лицензия, которая хуже действующей (меньше серверов, короче срок, короче льготный период, меньше серверов-хостов, не включает этот сервер), не устанавливается сама: страница скажет The licence … was received but not installed, because it … — установите её вручную, если она действительно нужна.

Прокси

Если шлюз выходит в интернет только через HTTP-прокси, введите его в Proxy address (empty = the system's setting), например http://proxy.example.org:3128, и нажмите Save the proxy. Use the system default — вернуть системную настройку. Прокси с логином и паролем не поддерживается; адрес — только http://хост:порт или https://хост:порт.

Перенос на другой сервер

Лицензия привязана к серверу. Если вы перенесли шлюз (восстановили из копии на новую машину), состояние станет Activated on another host. Для платной лицензии действует льготный период переезда — не меньше 14 дней (или больше, если так записано в лицензии), в течение которого всё работает; страница показывает, сколько дней использовано. За это время перенесите лицензию: Move the licence to this host online (одно обращение) или офлайн-код Move the licence to this host. Число переносов ограничено условиями лицензии. После окончания льготного периода новые сессии и изменения отклоняются.

Освобождение установки

Прежде чем вывести шлюз из эксплуатации, освободите лицензию, чтобы активировать её на другом сервере: Release… → введите серийный номер действующей лицензии для подтверждения → один из вариантов:

• Release and show the release code — шлюз ничего не отправляет и показывает Release code, который вы вводите на портале сами. Код показывается только один раз — скопируйте его, прежде чем уйти со страницы.
• Release and tell bursucm.com now (one call) — освобождение сразу сообщается порталу, код не нужен.

Когда лицензия кончается: что останавливается, а что работает

Окончание лицензии — это «мягкая остановка», а не выключение. У платной лицензии за 7 дней до конца появляется метка Ends soon и предупреждение в колокольчике; после окончания действует льготный период (In grace, его длина записана в лицензии), когда всё ещё работает. У пробной лицензии нет ни метки, ни предупреждения, ни льготного периода: Trial до последнего дня, затем сразу Ended. После окончания (и льготного периода платной лицензии):

Если включено больше серверов, чем разрешает лицензия, после льготного периода сессии пропускаются только к серверам в пределах лимита, а изменения отклоняются, пока лишние серверы не будут выключены. Включить сервер сверх лимита сразу нельзя: The licence allows … active servers. Switch off a server or extend the licence.

Шлюз не доверяет своему времени

Шлюз следит за тем, чтобы лицензию нельзя было продлить переводом часов или откатом базы. Если файл состояния лицензии /var/lib/bursu-pam/licence-state.json пропал или повреждён и одновременно не сходится подписанная отметка времени в журнале аудита, если база оказалась старше файла состояния (восстановлена из старой копии), или из журнала пропали строки, страница пишет The gateway cannot trust its own time: новые сессии и изменения отклоняются, перезапуск не помогает. Выход один — лицензия, выпущенная в ответ на запрос, сделанный после начала этого состояния:

• если действует платная лицензия — Request a support licence (офлайн-код или онлайн-кнопка) и отправка его в BURSUsofts;
• иначе — запрос активации (Activate a paid licence); пробная лицензия из этого состояния не выводит.

Если часы шлюза ушли вперёд, может появиться кнопка Re-base the licence to this gateway's time — она пересчитывает лицензии под текущее время шлюза. Поэтому восстанавливайте базу вместе с каталогом /var/lib/bursu-pam из одной и той же копии (см. «Резервное копирование»).

Licences received

Таблица всех полученных лицензий: Serial, Seq, Kind, Servers, Term, Received (как получена — uploaded, online, check-in, restored from the state file; кем и когда) и Status — In force, Pending, Superseded, Released, Ended.

Все сообщения страницы лицензии и что с ними делать — в главе «Неисправности → Лицензия».

Файл gateway.json

/etc/bursu-pam/gateway.json хранит только то, что шлюзу нужно знать до подключения к базе: где база, на каких адресах и портах слушать, где сертификат и каталоги. Всё остальное настраивается в консоли и хранится в базе. Файл создаёт bursu-pam-setup, порты в нём меняет bursu-pam-configure; вручную его правят только для параметров, которых нет в мастере.

• Формат — JSON; шлюз допускает комментарии // и висячие запятые, но bursu-pam-configure и bursu-pam-check читают только чистый JSON — не добавляйте комментарии, если пользуетесь мастером.
• Неизвестный параметр шлюз отвергает и не запускается — так опечатка не превращается молча в значение по умолчанию. Имена параметров не чувствительны к регистру.
• Права: root:bursu-pam 0640 (файл может содержать пароль базы). Проверяет bursu-pam-check.
• После правки: sudo systemctl restart bursu-pam-gateway (идущие сессии оборвутся). Если шлюз не поднялся — journalctl -u bursu-pam-gateway -n 50 назовёт неверный параметр.
• Пример с комментариями: /usr/share/doc/bursu-pam/gateway.json.example.

Файл, который создаёт установка:

{
  "connectionString": "Host=/var/run/postgresql;Port=5432;Database=bursu_pam;Username=bursu-pam",
  "listenUrl": "https://0.0.0.0:443",
  "dataDirectory": "/var/lib/bursu-pam",
  "keyDirectory": "/var/lib/bursu-pam/keys",
  "sshListen": "0.0.0.0:2222",
  "rdpWorkerPath": "/opt/bursu-pam/workers/RdpWorker",
  "vncWorkerPath": "/opt/bursu-pam/workers/bursu-pam-vnc",
  "vncLauncherPath": "/opt/bursu-pam/workers/bursu-pam-vnc-launch"
}

Параметры

Сертификат шлюза

Один сертификат обслуживает консоль (HTTPS) и все TLS-входы шлюза (VNC с TLS, входы баз данных). Клиенты BURSUcm запоминают (закрепляют) сертификат шлюза при первом подключении и спрашивают подтверждение снова, если он сменился.

Самоподписанный сертификат

Если certificatePath не задан, при первом запуске шлюз создаёт /var/lib/bursu-pam/gateway.pfx: ECDSA P-256, SHA-256, имя CN=<имя машины>, срок два года; если включён VNC, в него добавляется vncAdvertisedName. Браузеры предупреждают о таком сертификате — это ожидаемо; проверьте отпечаток и продолжите. Для постоянной работы лучше сертификат вашего удостоверяющего центра.

Созданный файл шлюз дальше только читает: он не продлевает сертификат по истечении двух лет и не добавляет в него имя VNC, если VNC включили позже. Срок виден на Settings → Status. Чтобы получить новый самоподписанный сертификат (после истечения срока или после включения VNC), отложите старый файл и перезапустите службу — шлюз создаст новый:

sudo mv /var/lib/bursu-pam/gateway.pfx /var/lib/bursu-pam/gateway.pfx.old
sudo systemctl restart bursu-pam-gateway

Пользователи BURSUcm увидят новый сертификат и один раз подтвердят его.

Свой сертификат

1. Выпустите сертификат на имя шлюза (например pam.example.org; если пользователи ходят и по IP — добавьте IP в альтернативные имена). Если включён VNC — в нём обязательно должно быть имя из vncAdvertisedName.
2. Положите файлы так, чтобы их мог прочитать bursu-pam, но не другие пользователи. Каталог /etc/bursu-pam для службы только для чтения — это подходит: файл должен уже существовать.

   sudo install -d -o root -g bursu-pam -m 0750 /etc/bursu-pam/tls
   sudo install -o root -g bursu-pam -m 0640 gateway.pfx /etc/bursu-pam/tls/gateway.pfx

3. Добавьте в gateway.json вариант PKCS#12:

   "certificatePath": "/etc/bursu-pam/tls/gateway.pfx",
   "certificatePassword": "пароль-файла"

   или PEM:

   "certificatePath": "/etc/bursu-pam/tls/gateway.crt",
   "certificateKeyPath": "/etc/bursu-pam/tls/gateway.key"

   (certificatePassword — только если ключ зашифрован). Шлюз читает из .crt (и из .pfx) только первый сертификат — свой, с закрытым ключом; цепочку из файла он не собирает и клиентам не отдаёт. Поэтому клиенты должны сами доверять промежуточному центру сертификации (например, раздайте его на рабочие места групповой политикой или пакетом доверенных сертификатов).
4. sudo systemctl restart bursu-pam-gateway и откройте консоль — браузер должен показать ваш сертификат. Пользователей BURSUcm предупредите: клиент один раз попросит подтвердить новый сертификат.

Продление: замените файл тем же путём и перезапустите службу.

Сеть и брандмауэр

Пакет и мастер никогда не меняют сетевой экран сервера. Откройте порты сами.

ufw

Если ufw включён (sudo ufw status → Status: active), bursu-pam-configure печатает готовые команды для выбранных портов. Типичный набор:

sudo ufw allow 443/tcp      # консоль и клиенты BURSUcm
sudo ufw allow 2222/tcp     # SSH, SFTP, SCP, Telnet-устройства
sudo ufw allow 3389/tcp     # RDP (если включён)
sudo ufw allow 5900/tcp     # VNC (если включён)
sudo ufw allow 15432/tcp    # вход PostgreSQL (если включён)

Лучше ограничить источники сетью пользователей: sudo ufw allow from 10.20.0.0/16 to any port 2222 proto tcp. Не забудьте оставить доступ к порту 22 для администрирования самого сервера, прежде чем включать ufw (sudo ufw allow 22/tcp).

Целевые серверы

На целевых серверах разрешите служебные порты только с адреса шлюза. Пример для Linux с ufw: sudo ufw allow from 192.0.2.10 to any port 22 proto tcp и запрет остальным; для Windows — правило брандмауэра Windows для RDP (3389) с удалённым адресом шлюза. Сделайте то же для VNC, Telnet и портов СУБД.

Обратный прокси и NAT

Если перед консолью стоит обратный прокси, перечислите его адрес в trustedProxies. Если шлюз опубликован через NAT или проброс портов, задайте внешние адреса в sshPublicHost/sshPublicPort, rdpPublicHost/rdpPublicPort и dbPublicHost — их шлюз сообщает клиентам.

Обслуживание

Служба и журналы

systemctl status bursu-pam-gateway            # работает ли
sudo systemctl restart bursu-pam-gateway      # перезапуск (сессии обрываются; в запечатанном режиме — снова /unseal)
journalctl -u bursu-pam-gateway -n 100        # последние строки журнала
journalctl -u bursu-pam-gateway -f            # журнал в реальном времени
journalctl -u bursu-pam-gateway --since today

Журнал службы не содержит паролей, кодов настройки и строк подключения. Журнал аудита (кто что сделал) — в консоли, см. «Журнал аудита».

Проверка хоста: bursu-pam-check

sudo bursu-pam-check            # по строке на проверку: OK, WARN или FAIL
sudo bursu-pam-check --quiet    # только WARN и FAIL

Только читает, ничего не меняет и не ходит в сеть. Код выхода 1, если есть хотя бы один FAIL. Запускайте от root — иначе часть проверок не выполнится.

Обновление

sudo apt install ./bursu-pam_<новая версия>_amd64.deb

1. Пакет останавливает шлюз (все сессии обрываются) — проводите обновление в окно обслуживания и предупредите пользователей.
2. До замены файлов делает копию базы: /var/backups/bursu-pam/pre-upgrade-<старая версия>-<время>.dump (хранятся две последние). Нужно свободное место — вдвое больше размера базы, иначе обновление останавливается и называет оба числа.
3. Если копию сделать не удалось (нет места, база недоступна) или шлюз не остановился, обновление отменяется: вы увидите строку NOT upgrading - …, ошибку dpkg, а старая версия снова запущена.
4. Новая версия при запуске обновляет схему базы. gateway.json и данные не трогаются; вопросы про порты при обновлении не задаются.
5. В запечатанном режиме после обновления откройте /unseal.

Для удалённой базы пакет копию не делает (пишет об этом одной строкой) — сделайте копию сами до обновления.

Откат на предыдущую версию

Только для базы на этом же сервере. Всё, что записано после обновления, будет потеряно — сначала скопируйте файл копии в другое место.

Каталог /var/backups/bursu-pam и файл копии принадлежат root и закрыты для остальных, а перенаправление < выполняет оболочка того, кто набирает команду, а не sudo. Поэтому выполняйте блок от root: сначала sudo -i, дальше команды без sudo.

sudo -i
systemctl stop bursu-pam-gateway
runuser -u postgres -- psql -c 'DROP DATABASE bursu_pam'
bursu-pam-setup                                    # создаёт пустую bursu_pam с владельцем bursu-pam
runuser -u bursu-pam -- env -i PATH=/usr/sbin:/usr/bin:/sbin:/bin \
    pg_restore -h /var/run/postgresql -d bursu_pam --exit-on-error < /var/backups/bursu-pam/pre-upgrade-<старая>-<время>.dump
apt-get install -y --allow-downgrades /путь/к/bursu-pam_<старая версия>_amd64.deb
exit                                               # вернуться в свою оболочку

Резервное копирование и восстановление

Для восстановления нужны три вещи, и все три обязательны:

1. База bursu_pam — каталог, пользователи, правила, журнал аудита;
2. каталог /var/lib/bursu-pam — мастер-ключ (keys/), записи сессий, состояние лицензии, сертификат;
3. ключ восстановления из мастера /setup — офлайн, в сейфе, никогда не на этом сервере.

(   # подоболочка: umask не останется в вашей оболочке
  umask 077
  sudo runuser -u bursu-pam -- pg_dump -Fc -h /var/run/postgresql bursu_pam > bursu_pam.dump
  sudo tar -C /var/lib -czf bursu-pam-data.tar.gz bursu-pam
)

Архив содержит ключи — храните его так же надёжно, как сами ключи, отдельно от копии базы. Без мастер-ключа из keys/ ни секреты, ни записи из копии базы не читаются; копия базы без каталога данных бесполезна. Делайте обе части в одно время: база, восстановленная из более старой копии, чем файл состояния лицензии, переводит шлюз в состояние «не доверяет своему времени» (см. «Лицензия»).

Восстановление на новом сервере: установите тот же пакет, остановите службу, восстановите базу (DROP DATABASE, bursu-pam-setup, pg_restore — как в откате выше), распакуйте архив в /var/lib (владелец bursu-pam), запустите службу. Если файла ключа нет или он не подходит, шлюз откроет страницу /unseal для ключа восстановления. Лицензию затем нужно перенести на новый сервер («Перенос»).

Записи на другом диске

Служба может писать только в /var/lib/bursu-pam. Чтобы держать записи на отдельном диске:

sudo install -d -o bursu-pam -g bursu-pam -m 0700 /srv/pam-recordings
sudo systemctl edit bursu-pam-gateway
#   [Service]
#   ReadWritePaths=/srv/pam-recordings
# в gateway.json:  "recordingsDirectory": "/srv/pam-recordings"
sudo systemctl restart bursu-pam-gateway

Или проще — смонтируйте отдельный диск прямо в /var/lib/bursu-pam/recordings.

Обновления Ubuntu и перезапуски

Пакет кладёт /etc/needrestart/conf.d/bursu-pam.conf, чтобы утилита needrestart после apt upgrade не перезапускала шлюз сама (перезапуск обрывает все сессии). После обновления библиотек sudo needrestart -b покажет шлюз как ожидающий перезапуска — перезапустите его в окно обслуживания.

Удаление

sudo apt remove bursu-pam     # останавливает службу, удаляет только файлы пакета
sudo apt purge bursu-pam      # то же, плюс состояние службы; больше НИЧЕГО

Ни remove, ни purge не удаляют /var/lib/bursu-pam (ключи и записи), /etc/bursu-pam, /var/backups/bursu-pam, базу bursu_pam, роль и учётную запись bursu-pam — повторная установка подхватит их. Окончательное удаление необратимо; выполняйте его, только убедившись, что записи и ключи больше никому не нужны:

sudo runuser -u postgres -- psql -c 'DROP DATABASE bursu_pam'
sudo runuser -u postgres -- psql -c 'DROP ROLE "bursu-pam"'
sudo rm -r /var/lib/bursu-pam /etc/bursu-pam /var/backups/bursu-pam
sudo deluser --system bursu-pam

Перед выводом из эксплуатации освободите лицензию («Освобождение установки»).

Веб-консоль

Консоль — это веб-страницы самого шлюза. В ней администратор заводит пользователей, серверы и правила доступа, аудитор читает журналы, согласующий решает по запросам, а обычный пользователь смотрит, к чему у него есть доступ. Консоль открывается в браузере по адресу шлюза; адрес и сертификат задаются при установке (см. разделы Сеть и порты и Сертификат шлюза). Консоль работает и без JavaScript. Каждая форма защищена от подделки запроса, страницы не сохраняются в кэше браузера.

Что человек видит в консоли, зависит от его ролей. Роли описаны в разделе Роли; пункты меню, которых роль не может открыть, не показываются совсем (они не «серые», а скрыты).

Вход: страница «Sign in to the console»

Адрес страницы — /signin. На неё попадает каждый, кто открыл консоль без действующего сеанса. Если до этого он хотел открыть конкретную страницу, после входа шлюз вернёт его именно на неё.

Над формой может быть баннер: текст, который администратор задал в настройке Banner text (Sign-in and MFA). Обычно в нём пишут предупреждение о том, что работа ведётся под контролем.

Шлюз отвечает на ошибки входа одной и той же фразой, чтобы по ответу нельзя было узнать, есть ли такой логин: Incorrect login or password. Так отвечает и на неверный пароль, и на неизвестный логин, и на отключённого пользователя, и на человека, который не состоит ни в одной сопоставленной группе каталога. Исключение — блокировка: Account temporarily locked until {0}. (время в часовом поясе шлюза). Все тексты ошибок входа собраны в главе «Неисправности».

Шаги входа и порядок страниц

Вход состоит из нескольких шагов. Каждый следующий шаг показывается только тогда, когда он нужен.

Стартовая страница: администратор и аудитор попадают в Overview (если шлюз ещё не лицензирован, администратор сначала попадает на страницу Licence); согласующий — в Approvals; все остальные — в My profile.

Пока человек не прошёл все шаги, шлюз не пускает его никуда, кроме страницы текущего шага. Любая другая страница возвращает его на этот шаг.

Код из приложения: страница «Two-factor sign-in»

Адрес — /signin/totp. Под заголовком написан логин, под которым идёт вход. На странице:

• шесть окошек 6-digit code (цифры можно набирать подряд или вставить целиком), подсказка «Enter the 6-digit code from the authenticator app.» и кнопка Confirm;
• ссылка Enter a recovery code: страница переключается на поле Recovery code (образец xxxxx-xxxxx) и текст «Enter one of your recovery codes. Each code works once.»; обратно ведёт ссылка Enter a code from the app;
• кнопка Sign in as another user: завершает начатый вход и возвращает на страницу входа.

Код — шестизначный, из приложения-аутентификатора (RFC 6238: SHA-1, 6 цифр, шаг 30 секунд). Один и тот же код нельзя использовать дважды. Если код не подошёл, страница пишет The code did not match. Проверьте, что время на телефоне точное.

Смена временного пароля: страница «Choose your password»

Адрес — /signin/password. Показывается человеку, которому пароль выдал администратор. Текст: «The administrator gave you a temporary password. Choose your own to continue.» Поля:

Если слишком короткий: The password must be at least N characters long. Длина считается в символах после стандартной нормализации Unicode.

Пользователю каталога (доменному) эта страница вместо формы показывает заголовок Change your domain password (для LDAP — Change your directory password), текст о том, где сменить пароль, и единственную кнопку Sign out. Шлюз никогда не пишет в каталог, поэтому пароль меняется только средствами самого каталога.

Настройка TOTP: страница «Set up two-factor sign-in»

Адрес — /signin/enrol. Вход в консоль защищён вторым фактором — кодом из приложения на телефоне. Страница показывается человеку, у которого его ещё нет, если настройка Require TOTP включена (по умолчанию включена). Шаги:

1. Отсканируйте код. В блоке 1. Scan the code in the authenticator app показан QR-код. Если сканировать нечем, введите ключ вручную: он показан под подписью «Or enter the key by hand:», ниже — «Account: логин» и параметры «SHA-1, 6 digits, 30 seconds».
2. Введите код. В поле 2. Code from the app введите шесть цифр из приложения и нажмите Next. Если цифры не подошли, страница пишет The code did not match. Check the time on the phone.
3. Сохраните коды восстановления. После правильного кода показываются десять одноразовых кодов (блок Save your recovery codes). Они нужны, если телефон потерян. Каждый код работает один раз. Кнопки Download .txt (файл bursu-pam-recovery-codes.txt) и Print. Храните коды отдельно от телефона.
4. Подтвердите. Отметьте I have saved the recovery codes и нажмите Next. Без отметки кнопка не сработает.

Секрет привязан к тому сеансу, который его показал. Если одновременно открыть эту страницу ещё раз в другом окне, новый секрет заменит прежний, а на старой странице появится предупреждение: «Another session of this account started a new authenticator setup, so the code shown here before no longer works.» Если за это время настройка уже завершена в другом окне, этот вход закрывается и человек возвращается на страницу входа. После подтверждения шлюз завершает все остальные сеансы этого человека.

Вход через Windows

Кнопка Sign in with Windows ведёт на страницу /signin/windows. Браузер должен сам отправить шлюзу билет Kerberos. После билета всё равно нужен второй фактор: если у человека нет TOTP, ему сразу предлагается настройка (даже при выключенной настройке Require TOTP); если есть — ввод кода, если только браузер не «запомнен» (см. настройку One code covers Windows sign-ins for (hours)). Если вход не удался, страница возвращает на форму входа с одной из фраз; все они перечислены в главе «Неисправности». Подробно о настройке — в разделе Вход через Windows (Kerberos).

Повторное подтверждение: страница «Confirm it is you»

Адрес — /reauth. Для опасных действий шлюз просит ввести пароль и код ещё раз, даже если человек уже вошёл. Такое подтверждение действует 10 минут и привязано к текущему сеансу. После подтверждения шлюз возвращает человека на ту страницу, откуда его отправили.

Ошибка одна для пароля и кода: The password or the code did not match. Неверный пароль или неверный код считаются так же, как при входе, и приводят к блокировке учётной записи. Когда пароль и код верны, счётчик неудач сбрасывается.

Подтверждение требуется для: смены ролей, установки пароля другому человеку и сброса его второго фактора; добавления, изменения и удаления каталога и сопоставлений его групп; смены ключа шифрования и режима ключа; создания нового приложения-аутентификатора и новых кодов восстановления в профиле; ослабления настроек входа; и для ряда действий в других частях консоли (правила, лицензия, SIEM и т. п. — они описаны в своих разделах).

Выход: страница «Sign out»

Пункт Sign out в меню пользователя завершает сеанс сразу, без вопроса. Страница /signout с вопросом «End your console session?» и кнопкой Sign out открывается, только если перейти на этот адрес напрямую (например, по закладке). После выхода сеанс закрыт на шлюзе, а не только в браузере. Выход также «забывает» этот браузер для входа через Windows (запомненное устройство).

Сроки жизни сеанса

Конец сеанса не сопровождается сообщением: человека просто переносит на страницу входа, а после входа — на ту страницу, на которой он был. Идентификатор сеанса лежит в cookie __Host-bpam-session (только для HTTPS, недоступен скриптам). На каждом шаге входа шлюз выдаёт новое значение cookie.

Блокировка учётной записи

Пять неверных паролей подряд блокируют учётную запись на 15 минут. Оба числа — настройки (Failed attempts before a lockout и Lockout length, min), они читаются при каждом входе. Особенности:

• Считаются не только неверные пароли, но и неверные коды второго фактора и неудачные повторные подтверждения.
• Правильный пароль сам по себе счётчик не сбрасывает; счётчик сбрасывается, когда вход завершён полностью или когда повторное подтверждение прошло с паролем и кодом.
• Если с последней неудачи прошло больше времени, чем длится блокировка, счёт начинается заново.
• Заблокированный человек видит Account temporarily locked until {0}. Администратор может снять блокировку досрочно кнопкой Unlock в карточке пользователя.
• Блокировка пользователя каталога действует так же. Кроме того, действует и собственная блокировка каталога: она выглядит как «Incorrect login or password».

Устройство окна

Каждая страница консоли состоит из верхней панели, бокового меню и рабочей области.

Верхняя панель

• Слева: кнопка Menu (на узком экране — открывает боковое меню) и название BURSU PAM; оно ведёт на стартовую страницу.
• Alerts — колокольчик (см. Колокольчик).
• Language — выпадающий список языков. Выбор сохраняется сразу.
• Switch theme — кнопка с луной: переключает светлую и тёмную тему.
• Меню пользователя (User menu): имя человека. В нём три пункта: My profile, Language and theme и Sign out.

Боковое меню

Меню составлено по ролям и показывает только то, что человек может открыть. Кнопка Collapse menu внизу сворачивает меню. У согласующего рядом с пунктом Approvals стоит число запросов, ожидающих его решения. Пункт My profile показывается в боковом меню, только если кроме общих пунктов (My access и Help) человеку ничего не доступно, то есть у него одна роль User; всем остальным «My profile» доступен в меню пользователя сверху.

Меню и разделы настроек: английский и русский

Консоль переведена на восемь языков. На снимках и в этом руководстве показан английский интерфейс. Ниже — все пункты бокового меню и все плитки раздела Settings с английскими и русскими подписями из файлов перевода (nav.*, sethub.*, role.*) и с указанием, кто их видит.

Боковое меню

Пункты группы «Audit» и страницы «Approvals», «Command control», «Device profiles» и «Emergency access» описаны в частях руководства об аудите, запросах и ресурсах. Пункт My access — в части для пользователей.

Плитки раздела «Settings»

Названия ролей

Колокольчик «Alerts»

Колокольчик — значок в верхней панели. Число на нём — количество текущих проблем. Он есть у администратора, аудитора и согласующего, а также у любого человека, у которого есть собственные оповещения о запросах. Нажатие открывает список; если проблем нет, написано No current problems. Пункт со ссылкой ведёт на страницу, где проблему можно разобрать; человеку, которому эта страница недоступна, пункт показывается без ссылки.

Сам перечень проблем (здесь — общая картина, детали есть в разделах, к которым пункты ведут):

• Собственные записи человека: Requests waiting for your decision: {0}, Your requests that were decided: {0}, Commands waiting for your confirmation: {0}, а также об аварийном доступе (Emergency access used and not yet reviewed: {0} и Emergency access reviews overdue: {0}).
• Общие проблемы для администратора и аудитора: ключ шифрования закрыт или устарел, заблокированные пользователи за последний час, очередь локального журнала, смена ключа хоста у сервера, каталоги без наблюдения или без подтверждённого корневого сертификата, сбои записи сессий, нехватка места на диске, расхождение часов, сбой SIEM-экспорта, проблемы лицензии, нарушение цепочки журнала и другие (полный список состояний — в разделе Status).

Полосы над содержимым

• Предупреждение о лицензии. Красная или жёлтая полоса, которую видит каждый вошедший, пока лицензия закончилась, находится в льготном периоде, привязана к другому серверу или не установлена. У администратора в полосе есть ссылка Open the licence page. Тексты и действия — в разделе «Лицензия».
• Полоса аварийного доступа. Пока у человека действует его собственный аварийный доступ, на каждой странице написано: «Emergency access is active until {0}. This use is recorded and will be reviewed.»
• Результат действия. После сохранения, удаления или другого действия над страницей на короткое время показывается зелёная (успех) или жёлтая (предупреждение) полоса с сообщением: например, Saved., Deleted., Created.
• Водяной знак. Если включена настройка Watermark, по всему окну консоли диагонально повторяется «логин (Имя)» вошедшего человека.

Язык интерфейса

Язык консоли выбирается для каждого человека отдельно. Шлюз выбирает язык в таком порядке — берётся первое подходящее:

1. язык, сохранённый в профиле человека (после первого выбора в консоли);
2. cookie с языком браузера (выбор на странице входа или в верхней панели);
3. заголовок браузера Accept-Language;
4. язык по умолчанию, выбранный при первоначальной настройке шлюза;
5. английский.

Доступны восемь языков: English (en), Deutsch (de), Español (es), Português — Portugal (pt), Português — Brasil (pt-br), Русский (ru), Українська (uk), ქართული (ka). Выбор в верхней панели или на странице Language and theme записывается в профиль и в cookie (на год) и попадает в журнал аудита как «Language changed».

Страница «Language and theme»

Адрес — /preferences. Открывается из меню пользователя и доступна каждому вошедшему. Две формы:

Страница «My profile»

Адрес — /profile. Открыть её может любой вошедший. Для человека только с ролью User это вся консоль, кроме «My access» и справки. Что на странице:

Новое приложение-аутентификатор: страница «New authenticator app»

Адрес — /profile/totp (кнопка Set up again). Нужно повторное подтверждение (10 минут). Шаги: нажмите Start, отсканируйте новый QR-код, введите код из нового приложения и нажмите Confirm. До подтверждения продолжает работать прежнее приложение. После подтверждения шлюз выдаёт новые десять кодов восстановления («New recovery codes replace the old ones»), завершает все остальные сеансы человека и забывает его запомненные устройства. Кнопка Done возвращает в профиль.

Новые коды восстановления: страница «New recovery codes»

Адрес — /profile/codes (кнопка Create new ones). Нужно повторное подтверждение. Нажмите Create new codes: прежние коды перестают работать сразу, новые десять показываются один раз. Сохраните их кнопкой Download .txt или распечатайте (Print).

Общие элементы списков

Списки пользователей, групп и многих других объектов устроены одинаково:

• Quick filters — «чипы» над таблицей. У каждого справа число записей. Выбранный чип подсвечен; All снимает фильтр.
• Строка поиска (поле Search с подсказкой, например «Login, name, group»). Клавиша / переводит курсор в строку. Поиск обрезается до 200 символов; символы шаблонов не имеют особого смысла.
• Кнопка создания (например, Create user), меню Actions с групповыми действиями (появляется после отметки строк флажками), CSV (выгрузка списка целиком с учётом фильтра и поиска; выгрузка записывается в журнал аудита как «audit.export») и Refresh.
• Клик по заголовку колонки сортирует по ней; повторный клик меняет направление.
• Внизу: «Total: N», выбор Per page (15, 30, 50 или 100; по умолчанию 15) с кнопкой Apply и номера страниц.
• Групповое действие над отмеченными строками спрашивает подтверждение: «Apply this action to the selected rows?» Если ничего не отмечено — «Nothing was selected.» Если фильтр ничего не нашёл — «Nothing matches this filter.»

Подтверждения и несохранённые изменения

Опасные действия (отключение, удаление, сброс) спрашивают подтверждение в окне с кнопками Confirm и Cancel. Если JavaScript выключен, то же подтверждение показывается на самой странице, в блоке «Confirm the action». Формы с полями предупреждают, если закрыть страницу с несохранёнными изменениями. Кнопка Reset возвращает поля к тем значениям, с которыми страница открылась.

Время и часовой пояс

Шлюз хранит время в UTC, а показывает в часовом поясе, который задан в gateway.json параметром displayTimeZone (например, Asia/Tbilisi). Если параметр не задан, берётся часовой пояс операционной системы шлюза. Дата и время выводятся в формате выбранного языка. Этот пояс одинаков для всех пользователей; в профиле он не меняется. См. раздел gateway.json.

Пользователи

Раздел Users (адрес /users) — список людей, которые входят в консоль и подключаются к серверам через шлюз. Раздел доступен только администратору (Administrator). Пользователи бывают двух видов:

• Локальные. Их создаёт администратор. Логин и пароль хранятся в базе шлюза (пароль — только в виде необратимого хеша). Первый администратор создаётся мастером первоначальной настройки (см. раздел Мастер первоначальной настройки).
• Пользователи каталога (Active Directory или LDAP). Они появляются сами при первом успешном входе. У них нет пароля на шлюзе; имя, роли и членство в группах приходят из каталога (см. Каталоги).

Список пользователей

Адрес — /users. Над таблицей — быстрые фильтры (Quick filters), каждый показывает число людей:

Поиск (Login, name, group) ищет по логину, имени и названию группы. Колонки таблицы:

Сортировка есть у колонок Login, Name, Groups, State и Last sign-in. Справа в строке — кнопка Edit (у пользователей каталога её нет) и меню More actions: Open the card, Access (вкладка «Access» карточки), Log (вкладка «Log»). Кнопка CSV выгружает список с учётом фильтра и поиска; выгрузка попадает в журнал аудита.

Групповые действия. Отметьте строки флажками и откройте меню Actions: Enable и Disable. Для Disable шлюз просит подтверждение. Строки, которым действие ничего не меняет, пропускаются без записи в журнал. Если вы включили пользователя каталога, которого каталог по-прежнему отключает, шлюз предупредит: «Done for the selected rows. Users the directory disables stay disabled.»

Создание пользователя

Кнопка Create user открывает страницу /users/new («Create user»). Подсказка к странице: «A user created by an administrator changes the password and sets up TOTP at the first sign-in.»

(Звёздочка отмечает обязательные поля.)

После нажатия Create страница показывает «User {0} is created.» Если пароль сгенерирован шлюзом, ниже появляется блок Temporary password: «Give it to the user separately from the login. It is shown only now; they change it at the first sign-in.» Пароль показывается один раз; записать его нужно сразу. Кнопки: Open the card и Create user (создать ещё одного). Если вы ввели пароль сами, блока с паролем нет.

Что пишется в журнал аудита: создание пользователя (User created) с ролями, группами и признаком «пароль сгенерирован». Если группа, в которую вы добавили человека, названа в шаблоне запросов как группа согласующих, пишется и событие о новом согласующем.

Изменение пользователя

Кнопка Edit (список или карточка) открывает /users/{id}/edit («Edit user {0}»). Поля те же, что при создании, кроме логина (он только для чтения) и блока паролей. Различия:

• Roles. Флажки доступны только в течение 10 минут после повторного подтверждения. Пока подтверждения нет, под флажками написано «Changing roles needs you to confirm who you are.» со ссылкой Confirm who I am. Если роли изменены без подтверждения, форма откажет: «Confirm who you are before changing roles.»
• Temporary password. Пусто — пароль остаётся прежним («Leave empty to keep the current password.»). Если ввести пароль, нужно повторное подтверждение: «Confirm who you are before setting a password.» Новый пароль человек должен сменить при следующем входе; все его сеансы закрываются, а блокировка входа, если она была, снимается (если вы меняете пароль себе, остаётся только текущий сеанс).
• Active. Выключатель отключает или включает пользователя.
• Форма несёт номер версии записи. Если другой администратор успел изменить того же человека, сохранение откажет: «The record was changed by another administrator — open it again.»

После Save шлюз возвращает в карточку с сообщением Saved. В журнал пишется одно событие на каждое изменение: сведения о человеке, добавление и удаление групп, смена ролей (со старым и новым значением), включение или отключение, сброс пароля.

Пользователей каталога изменить здесь нельзя: кнопки Edit у них нет, а переход по адресу ведёт в карточку с пояснением «This is set by the directory for domain users and cannot be changed here.»

Карточка пользователя

Адрес — /users/{id}. В заголовке: имя, логин, метка каталога (для пользователя каталога), кнопка Edit (кроме пользователей каталога) и кнопка Disable / Enable. Вкладки: Main, Groups, Access, Tokens, Log.

Вкладка Main состоит из двух блоков.

Блок Details: Login, Name, E-mail, Roles, Groups (метки-ссылки на группы), State (для заблокированного — «until {0}»; для пользователя каталога — пояснение «disabled in the directory», «expired in the directory», «in no mapped group» или «no longer in the directory»), Two-factor sign-in (TOTP и «recovery codes left: N of 10» или Not set up), Last sign-in, Created, Change password at the next sign-in. У пользователя каталога вместо последнего — блок Source с пояснением «Roles, directory groups, name and password of a domain user come from the directory.» и ссылкой Group mappings на карточку каталога.

Блок Quick actions:

Вкладка Groups — «The user's groups»: таблица (Name, Description, Rules — число правил группы). Справа вверху — выбор группы и кнопка Add to group. Кнопка Remove спрашивает: «Remove {0} from the group {1}? The group's rules stop applying to them.» У группы, в которой человек состоит благодаря каталогу, стоит метка from the directory; если членство только от каталога, кнопки Remove нет — оно управляется сопоставлением групп каталога. Если человек не в группах: «The user is in no group.»

Вкладка Access — «Access to servers»: «From every rule in effect and every future one, directly and through groups.» Колонки: Server, Address, Accounts, How (напрямую или через группу), Rule (ссылка), Valid until. Если правил нет: «No rule gives this user access.» Это вкладка только для чтения. Напомним: ходить на серверы может только человек с ролью User.

Вкладка Tokens — «BURSUcm tokens» (входы приложения BURSUcm через шлюз): колонки Issued, Expires, State; кнопка Revoke отзывает токен немедленно («Token revoked.»). Ниже — Remembered devices (устройства, запомненные для входа через Windows) и кнопка Forget devices (нужно повторное подтверждение и подтверждение действия: «Forget every remembered device of this person? Their next Windows sign-in asks the code.»).

Вкладка Log — последние события журнала аудита по этому человеку и ссылка на весь журнал.

Пользователи каталога

• Учётная запись появляется при первом успешном входе человека, который состоит хотя бы в одной сопоставленной группе. В журнал пишется «Directory user created».
• Роли и группы шлюза такого человека определяются сопоставлениями групп (см. Сопоставление групп). Вручную в консоли можно только добавить его в группу шлюза (это отдельное, «ручное» членство, которое каталог не трогает), отключить в консоли, сбросить MFA и завершить сеансы.
• Состояние в каталоге: disabled in the directory, expired in the directory, in no mapped group, no longer in the directory. Во всех этих случаях человек не может войти. Отключение в каталоге сразу обрывает его сеансы; блокировка в каталоге не пускает на новые входы, но уже идущие сеансы не обрывает.
• Если сопоставление группы каталога называет только группу шлюза (без роли), роли у человека не появятся, а на серверы ходит только роль User (см. Роли). Чтобы человек из каталога мог подключаться к серверам, хотя бы одно из его сопоставлений должно давать роль User.
• Пароль пользователя каталога меняется в каталоге.

Группы

Группа собирает людей, чтобы одно правило доступа действовало на всех сразу — и на нынешних участников, и на тех, кто присоединится позже. Раздел Groups (адрес /groups) виден только администратору. Группа шлюза не связана с группой каталога, пока вы не сопоставите их (см. Сопоставление групп).

Список групп

Адрес — /groups. Если групп ещё нет, показан экран «No groups yet» с пояснением «A group gathers users so one access rule covers all of them, now and when people join later.» и кнопкой Create group.

Создание и изменение группы

Кнопка Create group открывает /groups/new, кнопка Edit — /groups/{id}/edit («Edit group {0}»). Форма:

Карточка группы

Адрес — /groups/{id}. Кнопки в заголовке: Edit и Delete. Вкладки:

• Main: блок Details (название, описание, число участников и правил, дата создания) и последние события журнала по группе.
• Members: выбор людей в поле Add members («New members get the group's access at once.») и кнопка Add members. В таблице участников: Login, Name, State и кнопка Remove (с подтверждением «Remove {0} from the group {1}? The group's rules stop applying to them.»). Метка from the directory стоит у участников, пришедших из каталога; если членство только от каталога, кнопки Remove нет. Пока участников нет: «The group has no members.»
• Rules: правила, в которых названа группа (Name, Valid until, State — Enabled или Disabled). Если ни одно правило не называет группу: «No rule names this group.» Правила создаются в разделе «Access rules» (см. Правила доступа).

Удаление группы

Кнопка Delete в карточке спрашивает: «Delete the group {0}? Its members ({1}) stay, but lose the access its rules ({2}) give.» Удалить нельзя, если:

• группа использована в сопоставлении каталога: The group is used by a directory mapping. Remove the mapping first.;
• на группу ссылаются политики контроля команд: Command policies still apply to this: {0}. Edit the policies first. (сначала измените политики; см. раздел Контроль команд).

При удалении люди остаются, но теряют доступ, который давали им правила этой группы. В журнал пишется «Group deleted».

Журнал аудита фиксирует: создание, изменение и удаление группы, добавление и удаление участника («Member added», «Member removed»). Если член группы благодаря этому становится согласующим, пишется ещё и событие о новом согласующем (оно же даёт пункт в колокольчике).

Роли

Роль определяет, что человек видит в консоли и что может в ней менять. У человека может быть несколько ролей. Роли задаются в форме пользователя (Users) и для пользователей каталога — в сопоставлениях групп (Directories). Названия ролей в интерфейсе: Administrator, Auditor, Approver, User.

Роли и разделы консоли

В таблице: «да» — видит и может менять; «чтение» — видит, но не меняет; «—» — раздел скрыт.

Administrator и Approver несовместимы

Один человек не может быть одновременно администратором и согласующим. Смысл правила: тот, кто управляет правилами доступа, не должен сам утверждать запросы по ним. Что происходит:

• В форме пользователя при выборе обеих ролей шлюз откажет: Approver and Administrator exclude each other: nobody approves requests while managing the rules. Choose one of the two. Ту же причину называет и общая ошибка A person cannot be both an Administrator and an Approver.
• В каталоге: если группы человека дают обе роли, роль Approver не выдаётся, а в колокольчике появляется предупреждение Directory roles refused (Administrator wins over Approver): {0}. Исключение: если у человека уже есть Approver (и нет Administrator), а сопоставления теперь дают обе, остаётся та роль, которая уже была, то есть Approver, а отклоняется Administrator. Подробнее — в разделе Сопоставление групп.

Локальный администратор («аварийный вход»)

Шлюз всегда держит хотя бы одного активного локального администратора с настроенным TOTP. Это правило проверяется при любом изменении, которое могло бы нарушить его. Роль администратора пользователя каталога в расчёт не берётся, потому что каталог может отобрать её в любой момент (например, при недоступности каталога вы всё равно должны суметь войти). Поэтому:

• нельзя убрать у себя роль администратора («You cannot remove your own Administrator role.»);
• нельзя отключить самого себя («You cannot disable yourself.»);
• нельзя отключить, лишить роли или сбросить MFA у последнего активного локального администратора с TOTP: At least one active administrator with two-factor sign-in must remain.

Администратор, созданный мастером первоначальной настройки, — локальный. Не удаляйте и не отключайте его, пока не создадите другого локального администратора с TOTP. Не путайте эту «аварийную» учётную запись с функцией Emergency access (аварийный доступ к серверу по правилу), которая описана в части о запросах (см. Аварийный доступ).

Каталоги (Active Directory и LDAP)

Каталог позволяет сотрудникам входить в шлюз своим доменным паролем, не заводя отдельную учётную запись и пароль на шлюзе. Шлюз поддерживает Active Directory и обычные LDAP-серверы (OpenLDAP, 389 Directory Server, FreeIPA). Раздел находится в Settings → Directories (адрес /system/directories) и доступен только администратору. Одновременно можно подключить несколько каталогов.

Как это работает:

• Шлюз ходит в каталог под служебной учётной записью (bind): ищет человека по логину и читает его группы. Пароль человека проверяется отдельным «bind» от его имени и нигде не сохраняется.
• Соединение только по LDAPS (шифрованное). Доверие к серверу устроено «закреплением корня»: администратор подтверждает один корневой сертификат, и шлюз принимает только серверы, чей сертификат выдан под этим корнем. Системные удостоверяющие центры не используются.
• Роли и группы шлюза человек получает через сопоставления групп: «группа каталога → роль и/или группа шлюза». Человек, не состоящий ни в одной сопоставленной группе, войти не может.
• Шлюз следит за каталогом и реагирует на изменения: отключённый в каталоге человек теряет доступ сразу, изменение членства в группах применяется за секунды.

Список каталогов

Адрес — /system/directories. Подсказка: «Active Directory domains and LDAP servers whose users sign in to the gateway. Roles and gateway groups come from the directory groups mapped here.» Если каталогов нет, написано: «No directory is connected. Only local users sign in.» Кнопка Add directory создаёт каталог.

Добавление и изменение каталога

Кнопка Add directory открывает /system/directories/new («Add directory»); кнопка Edit в карточке — /system/directories/{id}/edit («Change directory»). Обе страницы требуют повторного подтверждения (10 минут).

(Звёздочка отмечает обязательные поля.)

После Create шлюз открывает карточку с сообщением «Directory added.» В журнал пишется «Directory added» (вид, число серверов, признак «по умолчанию»); при изменении — «Directory changed» с перечнем изменённых полей, признаком сброса сертификата и признаком смены пароля (сам пароль в журнал не попадает).

Карточка каталога

Адрес — /system/directories/{id}. В заголовке: Edit и Delete (см. Удаление и отключение). Блоки карточки:

• Connection: вид, серверы, оба DN, суффиксы и NetBIOS (для AD), признак по умолчанию, Bind DN, Turned on, State, Last change seen (когда каталог в последний раз сообщил об изменении) и Gateway users from it (сколько пользователей шлюза пришли из этого каталога).
• Root certificate: подтверждённый корень (отпечаток SHA-256 или «Not confirmed yet»), кнопка Check connection, представленный сервером корень, кнопка Confirm this certificate и загрузка файла корня.
• Windows sign-in (Kerberos) — только у AD (см. Вход через Windows).
• Group mappings (см. Сопоставление групп).

Действия на карточке, которые что-то меняют (подтверждение и загрузка сертификата, сопоставления, удаление, отключение), требуют повторного подтверждения (10 минут); без него шлюз перенаправит вас на страницу подтверждения и вернёт назад. Кнопка Check connection и поиск групп повторного подтверждения не требуют. Действия, которые обращаются к каталогу, ограничены: 10 нажатий в минуту с одного адреса, поиск групп — 20 в минуту на сеанс.

Проверка подключения

Кнопка Check connection ничего не меняет. Она пробует войти под служебной записью, выполнить поиск пользователей и узнать, умеет ли сервер сообщать об изменениях, и заодно читает сертификат, который предъявляет сервер. Результат в записи журнала «Directory connection checked». Успех выглядит так: «Signed in as the service account; entries found: N.» и, ниже, «The directory reports changes.» (или «This directory does not report changes; access is re-checked at the next sign-in or connection.»). Если не удалось, показано одно из сообщений (все они перечислены и в главе «Неисправности»):

Подтверждение корневого сертификата

Пока корень не подтверждён, шлюз каталог не использует: он никогда не доверяет сертификату сервера «на слово». Подтвердить корень можно двумя способами.

1. Нажмите «Check connection». Если сервер прислал цепочку сертификатов вместе с корнем, под результатом появятся Presented root (отпечаток SHA-256) и Answered by (какой сервер ответил). Сверьте отпечаток с эталоном, полученным по независимому каналу (у владельца удостоверяющего центра), и нажмите Confirm this certificate. Шлюз прочитает цепочку ещё раз и сохранит корень, только если он тот же, что вы видели, и если сертификат каждого настроенного сервера построен под ним и называет этот сервер.
2. Загрузите файл корня. Контроллер домена Active Directory обычно присылает только свой собственный сертификат, без корня («The directory did not send its root certificate. Upload it (.cer or .pem).»). Экспортируйте корневой сертификат удостоверяющего центра домена (DER или Base-64) и загрузите его в поле Root certificate file кнопкой Upload. Принимаются файлы .cer, .crt, .pem, .der размером до 64 КБ, и только самоподписанный сертификат удостоверяющего центра.

Результат: «The certificate is confirmed.» и запись в журнале «Directory certificate confirmed». Возможные отказы:

Сопоставление групп

Блок Group mappings на карточке каталога: «A person in a mapped group signs in with the role and joins the gateway group given here. A person in no mapped group cannot sign in.» Для каждой группы каталога выбираются роль и/или группа шлюза (достаточно чего-то одного: «Choose a role or a gateway group.»). Блок доступен только после подтверждения корня («Confirm the root certificate first: until then the gateway does not search this directory.»).

1. Найдите группу. В поле Find a directory group введите часть названия (до 128 символов) и нажмите Search. Если групп нет: «No group matches.» Группа, которая уже сопоставлена, помечена already mapped. Группа поиска возвращает ограниченное число совпадений; уточняйте запрос.
2. Выберите, что она даёт. В списке Role — no role, User, Auditor, Approver или Administrator; в списке Gateway group — no group или одна из групп шлюза.
3. Нажмите «Map». Сопоставление сохранено: «Mapping saved.» Шлюз сразу заново читает людей каталога: «what the mapping gives reaches them within seconds». Если каталог в этот момент не читается: «Mapping saved. The directory cannot be read now: what the mapping no longer gives is already taken away; what it gives arrives once the directory can be read again.»

Существующее сопоставление можно изменить прямо в таблице (списки Role и Gateway group, кнопка Save) или удалить (Delete, подтверждение «Remove the mapping of {0}?»). Изменение и удаление применяются ко всем людям каталога сразу: то, что сопоставление перестало давать, отбирается немедленно; то, что оно даёт, приходит, когда каталог прочитан.

Как складываются права:

• Человек получает объединение всего, что дают сопоставления групп, в которых он состоит (в том числе во вложенных группах).
• Одна группа каталога сопоставляется только один раз. Основная группа пользователя (например, Domain Users в AD) сопоставлена быть не может: «A user's primary group (Domain Users) cannot be mapped: Active Directory does not list it as a membership.»
• Членство в группе шлюза, полученное от каталога, помечено в карточке как from the directory и снимается автоматически вместе с сопоставлением. Ручное членство (добавленное администратором в консоли) каталог не трогает.
• Администратор и согласующий несовместимы (Роли). Если сопоставления дают обе роли сразу, выдаётся Administrator, а Approver отклоняется. Если у человека уже есть Approver (и нет Administrator), а сопоставления теперь дают обе роли, остаётся Approver, а отклоняется Administrator. Отклонённая роль показывается в колокольчике: Directory roles refused (Administrator wins over Approver): {0}. Заметьте, что подсказка на карточке («A person whose groups give both Administrator and Approver gets Administrator only») описывает только первый случай.
• Группу шлюза, на которую ссылается сопоставление, удалить нельзя, пока сопоставление не снято (The group is used by a directory mapping. Remove the mapping first.).

Наблюдение и сверка

• Для каждого включённого каталога с подтверждённым корнем шлюз держит подписку на изменения в ветках пользователей и групп (уведомления Active Directory; для LDAP — syncrepl или persistent search). Изменение приходит в течение секунд. Состояние watched означает, что подписка работает.
• Кроме того, шлюз периодически заново сверяет всех людей каталога (не реже чем раз в 15 минут), а также при каждом входе человека и при проверке его билета для подключения к серверу.
• Отключение или удаление человека в каталоге, потеря им всех сопоставленных групп, смена пароля в каталоге приводят к завершению его сеансов и отзыву токенов. Блокировка в каталоге не пускает на новые входы, но уже идущие сеансы не обрывает.
• Если каталог недоступен, шлюз не «разрешает на всякий случай»: доступ, который отбирают, отбирается; доступ, который выдают, ждёт возможности прочитать каталог. Если каталог недоступен при входе, человек видит «The directory is not available. Try again later or contact the administrator.» Локальные пользователи, в том числе аварийный администратор, входят всегда.

Удаление и отключение каталога

Кнопка Delete в заголовке карточки спрашивает: «Delete directory {0}?» Она видна только тогда, когда из этого каталога ещё никто не входил. Если из каталога уже входили люди, удалить его нельзя: «Users signed in from this directory exist. Turn the directory off instead of deleting it.» Вместо этого на карточке есть кнопка Turn off с вопросом «Turn off directory {0}? Its users cannot sign in until it is turned on again.» (после неё: «Users signed in from this directory exist, so it cannot be deleted. It is turned off; turn it on again in its settings.»). Включить каталог можно в форме изменения (Turned on). В журнал пишется «Directory deleted» либо «Directory changed».

Вход через Windows (Kerberos)

Для Active Directory на странице входа можно включить кнопку Sign in with Windows: сотрудник, вошедший в домен, попадает в консоль без ввода пароля (затем шлюз всё равно просит второй фактор). Кнопка появляется на странице входа, только если хотя бы для одного включённого каталога AD всё готово (SPN, доменная учётная запись или keytab, проверка прошла).

Блок Windows sign-in (Kerberos) на карточке AD показывает, включён ли вход, SPN, номер версии ключа (kvno) и типы шифрования, и ведёт на страницу /system/directories/{id}/kerberos («Windows sign-in (Kerberos)»).

Шлюз на Linux: файл ключей (keytab)

На Linux шлюзу нужен файл keytab с ключами служебного имени HTTP/…. Блок Keytab показывает Principal (SPN и область), Key version (kvno), Encryption types, Uploaded (когда и кем) и, после замены ключа, «Previous key (kvno N) kept until» (прежний ключ остаётся ещё на 10 часов, чтобы уже выданные билеты продолжали работать). Кнопки: Upload keytab (поле выбора файла .keytab) и Remove keytab (подтверждение «Remove the keytab of {0}? Windows sign-in through this directory stops.»). Файл хранится на шлюзе зашифрованным; в консоли его содержимое не видно.

Как администратору получить keytab. Ключи должны быть «посолены» так, как солит их контроллер домена для учётной записи, на которой висит SPN. Для учётной записи пользователя соль равна ОБЛАСТЬ + sAMAccountName. Любой из трёх способов (шлюз показывает ту же подсказку на странице):

1. MIT ktutil (в Active Directory ничего менять не нужно):

   ktutil
   addent -password -p HTTP/<host>@<REALM> -k <kvno> -e aes256-cts-hmac-sha1-96 -s <REALM><account>
   addent -password -p HTTP/<host>@<REALM> -k <kvno> -e aes128-cts-hmac-sha1-96 -s <REALM><account>
   wkt gateway.keytab

   Здесь <kvno> — значение msDS-KeyVersionNumber учётной записи, <account> — её sAMAccountName (без домена).
2. msktutil. Утилита сама вычисляет нужную соль и версию ключа для служебной учётной записи; её параметры смотрите в документации утилиты.
3. ktpass с параметрами +setpass +setupn на контроллере домена. Помните, что ktpass задаёт учётной записи новый пароль и повышает версию ключа, поэтому другие keytab этой записи перестают подходить.

Требования к файлу: формат версии 0x0502 (его пишут ktpass и ktutil); хотя бы одна запись; все записи для области этого каталога и для SPN этого каталога; размер до 64 КБ; только ключи AES (RC4, DES и 3DES отклоняют весь файл). Если в файле только AES128, он принимается с предупреждением (рекомендуется AES256). После загрузки шлюз сразу проверяет ключ пробным билетом. Журнал: «Kerberos keytab changed» (без содержимого ключа).

Шлюз на Windows

На Windows keytab не нужен: служба шлюза запускается под доменной учётной записью (рекомендуется gMSA), а на ней регистрируется SPN. Страница вместо блока Keytab показывает The service runs as (под какой учётной записью работает служба) и Host joined to the domain (включён ли компьютер в домен). Для тех, кто будет входить, на компьютере шлюза должно быть право «Access this computer from the network» (доступ к компьютеру из сети); если групповая политика уровня Tier-0 его запрещает, вход через Windows у этих людей не работает.

Кнопка «Check Kerberos»

Кнопка Check Kerberos запускает проверку и показывает строки с уровнем (ok, info, warn, bad): годен ли keytab и окружение, кто держит SPN, совпадают ли kvno, не разрешены ли слабые типы шифрования, не включено ли делегирование, не состоит ли служебная запись в группах, принимается ли пробный билет с привязкой к каналу, недоступен ли порт 88 контроллера, расходятся ли часы (при расхождении 3 минуты — предупреждение, 5 минут — вход перестаёт работать). Все строки перечислены в главе «Неисправности». Проверка пишет в журнал «Directory connection checked».

Дополнительные подсказки на странице:

• Браузеры отправляют билет только тем именам, которые есть в их политике: зона «Местная интрасеть» или AuthServerAllowlist для Edge и Chrome, network.negotiate-auth.trusted-uris для Firefox. Настройте это групповой политикой.
• Вход через Windows требует, чтобы шифрованное соединение TLS заканчивалось на шлюзе (только сквозная передача TCP). Если в gateway.json указаны доверенные прокси, страница предупреждает об этом.
• Настройка Channel binding for console sign-ins (Sign-in and MFA) определяет, нужна ли привязка к каналу. Значение по умолчанию — обязательна.

Linux и переменная LDAPNOINIT

На Linux шлюз должен запускаться через свой модуль systemd (bursu-pam-gateway.service): он задаёт LDAPNOINIT=1, без которого вход через каталог не работает. Причина: без этой переменной библиотека LDAP читает системный файл /etc/ldap/ldap.conf, а там на Ubuntu указан системный набор удостоверяющих центров; тогда шлюз доверял бы любому публичному центру, а не только подтверждённому вами корню. Поэтому шлюз без переменной отказывается соединяться с каталогами (безопасный отказ):

• доменные входы отвечают «The directory is not available…»;
• колокольчик показывает каталог как «не наблюдаемый» (Directories not watched);
• Check connection пишет, что на Linux-шлюзе не задан LDAPNOINIT=1.

Решение: запускайте шлюз единицей systemd, которую ставит пакет. Локальные учётные записи, в том числе аварийный администратор, входят и так. На Windows ничего дополнительного не нужно: корень проверяется собственным механизмом шлюза. У каждого каталога на диске есть своя папка доверия <dataDirectory>/directories/<id>/, которую шлюз переписывает сам; не кладите туда файлы.

Известные ограничения входа через каталог

• Вложенные группы вне ветки групп. Члены вложенных групп находятся через цепочку (AD LDAP_MATCHING_RULE_IN_CHAIN). Но если промежуточная группа лежит вне ветки Groups base DN, её изменение не приходит уведомлением и применяется при следующей сверке (не позже чем через 15 минут) либо при следующем входе или проверке билета. Держите такие группы внутри ветки групп или укажите корень домена.
• LDAP без наложения ppolicy. Без атрибута pwdChangedTime смена пароля в каталоге не обнаруживается: старые сеансы человека не закрываются, а просроченный пароль выглядит как неверный. В обоих случаях шлюз отказывает, а не разрешает. На OpenLDAP и 389-DS включите ppolicy.
• Блокировка в каталоге не пускает на новые входы и новые билеты, но не завершает уже идущие сеансы (так же ведёт себя Windows с сеансами заблокированной учётной записи); отключение завершает.

Раздел «Settings»: настройки шлюза

Все настройки шлюза собраны на одной странице Settings (адрес /settings). Это единственный пункт бокового меню для всего, что администратор настраивает на шлюзе. Страница видна только администратору: у остальных ролей пункта Settings нет. Подсказка на странице: «Everything an administrator configures on the gateway, in one place. Each tile opens its page; changes are audited as before.»

Страница состоит из плиток, собранных в четыре группы. Каждая плитка — ссылка на страницу настройки с короткой подписью. Сами страницы по-прежнему находятся по адресам /system/…: закладки браузера и ссылки из колокольчика работают как раньше.

Общие правила для страниц настроек:

• Каждая запись настройки попадает в журнал аудита вместе со старым и новым значением.
• Настройки, которые снижают защиту (например, отключение двухфакторного входа), требуют повторного подтверждения личности (повторное подтверждение). Усиление защиты подтверждения не требует.
• Если другой администратор успел сохранить ту же страницу раньше вас, шлюз ничего не записывает и сообщает: «The record was changed by another administrator — open it again.» Откройте страницу заново и повторите изменение.
• Перед уходом со страницы с несохранёнными правками браузер предупреждает о потере изменений.

Sign-in and MFA: вход и двухфакторная защита

Страница Sign-in and MFA (адрес /system/auth, только администратор) задаёт правила входа в консоль для всех людей: обязательность кода TOTP, блокировку после неудачных попыток, длину пароля, время простоя, срок жизни токенов BURSUcm, текст на странице входа, водяной знак и параметры входа через Windows. Подсказка вверху страницы: «Every change goes into the audit log with the old and the new value.»

Все поля сохраняются одной кнопкой Save и применяются сразу (кроме уже идущих входов на промежуточных шагах). Кнопка Reset возвращает в форме значения, которые были при её открытии. После сохранения страница показывает «Saved.».

Какие изменения требуют повторного подтверждения

Изменение, которое снижает защиту, нельзя сделать только по украденному сеансу. Если вы пытаетесь снизить защиту без свежего подтверждения личности (10 минут), страница не сохраняется и рядом с каждым таким полем показывается сообщение «Confirm who you are before this change: …. It lowers sign-in protection.» (для выключения TOTP: «Confirm who you are before turning two-factor sign-in off.») со ссылкой Confirm who I am. Пройдите подтверждение и вернитесь на страницу; введённые значения придётся повторить.

• Требуют подтверждения: выключение Require TOTP, увеличение числа попыток, уменьшение длины блокировки, уменьшение минимальной длины пароля, увеличение времени простоя, увеличение срока токена, выключение водяного знака, увеличение времени «запоминания» кода Windows, переход на When the browser sends it.
• Не требуют: любое усиление, а также изменение текста баннера.

Encryption key: ключ шифрования

Шлюз хранит пароли и ключи учётных записей серверов (раздел Accounts) в зашифрованном виде. Ключом шифрования служит «главный» ключ шлюза. Страница Encryption key (адрес /system/key, только администратор) показывает его состояние и позволяет сменить сам ключ или способ его защиты. Подсказка: «The key the gateway encrypts account secrets with. Changing the key or its mode needs a fresh confirmation and a typed word.»

Первое создание ключа и режим выбираются при первоначальной настройке (Первоначальная настройка); ввод парольной фразы при каждом запуске описан в разделе «Разблокировка».

Два режима защиты ключа

Что показывает страница

Дополнительные сообщения на странице:

• Красная врезка «The encryption key was changed, and this gateway still holds the previous one in memory. Restart the gateway (a sealed gateway will need its passphrase).» — вместо кнопок действий. Пока службу не перезапустят, запись новых секретов не работает. Перезапустите службу и проверьте журнал аудита.
• Предупреждение «These key files were set aside in the key directory. One may be the old key from before a change: delete it once you are sure it is not another database's key.» со списком файлов и пояснением «The console cannot remove them: an administrator of the server's operating system can archive or delete them.» Старые файлы ключа после смены откладываются, а не удаляются: удалять их нужно вручную на сервере, убедившись, что файл не нужен.

Смена ключа (Change the key)

Страница /system/key/rotate («Change the encryption key»). Нужны повторное подтверждение (10 минут) и набранное слово. Операция не чаще 5 раз в минуту.

Блок «What happens» перечисляет последствия:

• «The gateway makes a new key and re-encrypts all N secrets with it.»
• «The old recovery key stops working; the new one is shown once.»
• «Connections are not accepted during the change (seconds).»
• «The change goes into the audit log.»

1. Откройте форму. На странице Encryption key нажмите Change the key. Если шлюз в режиме Sealed, в форме есть поле Current unseal passphrase.
2. Введите данные. Для режима Sealed — текущую парольную фразу. Затем наберите слово подтверждения в поле «Type … to continue» — оно показано в подписи поля. Слово зависит от языка интерфейса: в английском это CHANGE, в русском — СМЕНИТЬ. Набирайте его точно, заглавными буквами и на том языке, что показан на странице; пробелы по краям игнорируются.
3. Нажмите «Change the key». Шлюз создаёт новый ключ, перешифровывает все секреты и показывает блок New recovery key с предупреждением «The key is shown once. The old recovery key no longer works.»
4. Сохраните новый ключ восстановления. Кнопка Download .txt скачивает файл bursu-pam-recovery-key.txt; кнопка Print печатает ключ. Храните отдельно от сервера.
5. Отметьте «I have saved the new key» и нажмите «Done». Без отметки шлюз не продолжит: «Tick “I have saved it” first.» Результат: «The encryption key is changed.»

Смена режима (Change the mode)

Страница /system/key/mode. Режим переключается между Protected by the OS и Sealed. Нужны повторное подтверждение, ключ восстановления и набранное слово; не чаще 5 раз в минуту. Целевой режим определяется текущим: из OS-режима страница ведёт в Sealed (Switch to sealed mode), из Sealed — в OS-режим (Switch to OS-protected mode).

Тексты страниц: при переходе в Sealed — «After this every restart of the gateway needs the passphrase you set here; until then nothing can connect.»; при переходе в OS-режим — «After this the gateway opens the key at start by itself; the passphrase is no longer used.» Результат: «The key is now sealed. Keep the passphrase safe: every restart needs it.» или «The key is now protected by the OS.»

Если после смены режима остались файлы ключа, которые не удалось убрать, страница перечисляет их: «These key files hold the key without the passphrase and could not be deleted; delete them by hand:» (после перехода в Sealed) или «The key file could not be written: after a restart the gateway will ask for the recovery key. Check the key directory's permissions:» (после перехода в OS-режим). В первом случае удалите перечисленные файлы вручную на сервере; во втором проверьте права на каталог ключа.

Если режим ключа успел измениться, пока страница была открыта, шлюз ничего не делает и пишет: «The mode of the key changed after this page was opened, so nothing was done. Open the page again and check the current mode.»

Если исход смены неизвестен

Если база данных не подтвердила завершение операции, страница пишет: «The outcome of the key change is unknown — check the audit log and the key state; do not repeat the change until you are sure.» Затем следует пояснение: «If the change did happen, the key held in the gateway's memory is out of date: restart the gateway (a sealed gateway then needs its passphrase) and check the key's state on the encryption key page and in the audit log.» Кнопки на странице ведут в Encryption key и в журнал аудита (Audit log). Не повторяйте смену, пока не убедились по журналу, что она не прошла.

Status: состояние шлюза

Страница Status (адрес /system/status, только администратор) только показывает состояние шлюза и ничего не меняет. Подсказка: «Read only. The certificate, the address and the trusted proxies are changed in gateway.json, then the service is restarted.» Вверху указан путь к рабочему файлу конфигурации: «Changed in gateway.json (… on this system), then a restart of the service. There is no certificate upload through the console in the first version.» Замена сертификата — в разделе «Сертификат».

Блок «Gateway»

Ниже в том же блоке идут строки проверок. У каждой есть цвет: зелёный — в порядке, жёлтый — внимание, красный — неисправность, серый — выключено. Те же проверки видны в колокольчике (Колокольчик). Показаны только строки, которые относятся к настроенному:

Блок «Certificate»

Серверы

Сервер в BURSU PAM — это машина или устройство, к которому люди подключаются через шлюз: Linux-сервер по SSH, Windows-сервер по RDP, сетевое оборудование по Telnet или SSH, рабочий стол по VNC, база данных PostgreSQL, MySQL или SQL Server. Шлюз хранит для каждого сервера адрес, порт, протокол, папку и проверенный «отпечаток» сервера (ключ хоста или сертификат). Логины и пароли, под которыми шлюз входит на сервер, хранятся отдельно — это учётные записи.

Работа с серверами выполняется в консоли в группе меню Resources, пункт Servers (адрес /servers). Страницу видит и меняет только Administrator. Аудитору (Auditor) эти страницы не показываются; он видит только профили устройств.

Сервер должен принимать подключения только от шлюза

Шлюз не может сделать это за вас: правило межсетевого экрана настраивается у вас в сети. Консоль проверяет доступность сервера со стороны шлюза (кнопка Test the connection), но не проверяет, закрыт ли сервер для остальных. Проверьте это сами: с обычного рабочего места подключение к целевому серверу должно не проходить.

Для Telnet это особенно важно: Telnet передаёт всё, включая пароль, открытым текстом. Используйте его только в управляющей сети, куда попадает один шлюз (см. Telnet).

Список серверов и папки

Страница Servers разделена на две части. Слева — дерево папок (Folders): строка All servers и ваши папки с числом серверов в каждой. Справа — таблица серверов выбранной папки; над таблицей написан путь папки и пометка with subfolders: выбрав папку, вы видите и серверы вложенных папок.

Когда в папке нет серверов, консоль пишет, что серверы — это машины, к которым подключаются через шлюз, и предлагает создать первый сервер или перенести существующие командой Move to folder.

Папки

Папки нужны, чтобы выдавать доступ сразу группе серверов: правило на папку охватывает её подпапки и серверы, которые вы добавите позже. Папки образуют дерево любой глубины.

Меню Folder actions (три точки над деревом) создаёт папку верхнего уровня (New folder). Меню у строки папки (Actions for the folder …) содержит:

Каждое действие с папкой записывается в журнал аудита (folder.create, folder.rename, folder.move, folder.delete), а перенос и удаление ещё и заставляют шлюз заново проверить права открытых сессий.

Создание сервера: общие поля

Кнопка Create server открывает форму /servers/new. Форма изменения (/servers/<id>/edit) такая же. В ней две секции: Main и State. Часть полей появляется только для определённых протоколов — остальные скрыты.

Кнопки формы: Create (при изменении — Save), Reset (вернуть значения, с которыми форма открылась), Cancel.

Сервер SSH

Это основной случай: Linux, Unix, macOS, а также сетевое оборудование с SSH. Поля — общие (см. выше); отдельных полей у SSH нет, кроме необязательного Device profile. Выберите профиль устройства только если для учётных записей сервера нужен привилегированный режим (команда enable и т. п.): тогда нужен встроенный профиль сетевого устройства.

Что должен поддерживать целевой SSH-сервер. Шлюз подключается к целям с таким набором алгоритмов (список зафиксирован в шлюзе и не настраивается):

• ключ хоста сервера: ECDSA nistp256 / nistp384 / nistp521, RSA с SHA-512 или SHA-256 (rsa-sha2-512, rsa-sha2-256). Ключ Ed25519 шлюз не принимает: сервер, у которого есть только ключ хоста Ed25519, шлюз не сможет проверить;
• обмен ключами: ECDH nistp384 / nistp256, Diffie-Hellman group16-sha512 / group14-sha256;
• шифры: AES-256-GCM и AES-256-CTR; имитовставки HMAC-SHA2-256 и HMAC-SHA2-512; без сжатия.

Во время работы со стороны шлюза на сервер ведётся одно подключение на сессию. До подтверждения ключа хоста сессии на этот сервер не открываются: на странице сервера написано Not confirmed — sessions are refused until it is.

Подробно про получение и подтверждение ключа хоста — в подразделе Ключ хоста SSH. Входы по паролю и по закрытому ключу учётных записей описаны в разделе Учётные записи.

Сервер Telnet

Для Telnet-сервера:

• обязателен Device profile: он описывает, как шлюз распознаёт приглашения устройства и вводит логин и пароль (см. Профили устройств). Если профиль не выбран: A Telnet server needs a device profile. При выборе Telnet консоль сама подставляет профиль по умолчанию (Generic Unix);
• учётные записи входят только по паролю. Если у сервера уже есть учётные записи с закрытым ключом, переключить его на Telnet нельзя: This server has key accounts; a Telnet server signs in with a password only. Delete them first.;
• идентичности сервера у Telnet нет, поэтому ключа хоста нет и подтверждать нечего (Not checked — Telnet has none);
• для создания нужно отметить флажок The password crosses the network between the gateway and this server in clear text и подтвердить личность. Если флажок не отмечен: Tick the acknowledgement to use Telnet. Если подтверждения личности нет: Confirm who you are before making this server use Telnet. Сохранение уже существующего Telnet-сервера повторно этого не требует.

В списке и на карточке у Telnet-сервера стоит метка Not encrypted to the server.

Сервер RDP

Шлюз открывает RDP-сессию на сервере от имени учётной записи с паролем, а пользователь подключается к шлюзу своим RDP-клиентом (файл .rdp можно скачать на странице «My access», см. Мой доступ).

Отдельные поля формы:

Ещё условия:

• учётные записи RDP-сервера входят только по паролю. Если есть записи с ключом: This server has key accounts; an RDP server signs in with a password only. Delete them first.;
• RDP-сервер создаётся выключенным, пока не подтверждён его сертификат: консоль напоминает Saved, but the server is inactive: confirm the RDP server's certificate.;
• на цели должен работать RDP с TLS: шлюз использует защиту уровня TLS/CredSSP (NLA); «стандартную» защиту RDP (без TLS) шлюз не применяет. Если сервер предлагает только её, проверка скажет: The server offers no TLS: only the old RDP security, which the gateway does not use.

Подтверждение сертификата и работа кнопок описаны в подразделе Сертификаты и отпечатки. Что именно разрешено RDP-сессии (диски, буфер обмена, принтеры, USB, звук), задают правила и страница Политика файлов, буфера обмена и устройств.

Сервер VNC

Для VNC на форме обязательно выберите, как шлюз входит на сервер (поле Sign-in to the server). Значения по умолчанию нет: выбор делает человек. Шесть вариантов:

Для четырёх слабых типов (строки 3–6 таблицы) в форме появляется флажок I understand and accept this вместе с текстом о конкретной опасности. Без флажка: Tick the box to accept the weak connection to this server. Без свежего подтверждения личности: Confirm who you are before making this server use a weak connection. Если выбрать другой тип, флажок снимается.

Нужно точно знать три вещи:

• учётные записи VNC-сервера входят только по паролю; ключи не поддерживаются (This server has key accounts; a VNC server signs in with a password only. Delete them first.). Для типов «TLS, no sign-in» и «No sign-in (not encrypted)» учётная запись создаётся без пароля (тип записи No sign-in);
• если вы меняете тип входа, а существующие учётные записи ему не подходят: An account of this server does not fit the new sign-in type. Change or delete it first.;
• VNC-сервер с любым TLS-типом создаётся выключенным: A VNC server with a TLS sign-in type stays inactive until its certificate is confirmed after saving.

Подключение пользователя к шлюзу по VNC устроено иначе: клиент входит одноразовым кодом из консоли или из BURSUcm (раздел Подключение по VNC).

Серверы баз данных: PostgreSQL, MySQL, SQL Server

Для баз данных шлюз выступает прокси: пользователь подключается своим клиентом (psql, DBeaver, SSMS и т. п.) к шлюзу и вводит «пропуск» (pass) вместо пароля. Шлюз сам входит на базу с учётной записью сервера. Входит он только SQL-логином и паролем; вход Windows (SSPI), Entra ID и сертификатом не поддерживаются.

В списке протоколов база называется PostgreSQL, MySQL или SQL Server. Отдельного пункта для MariaDB нет: сервер MariaDB, говорящий на протоколе MySQL, выбирается как MySQL.

Что важно:

• шлюз всегда шифрует соединение с базой (TLS) и проверяет «отпечаток» ключа сертификата базы (SPKI SHA-256). Пока отпечаток не подтверждён, сервер неактивен: A database server stays inactive until its certificate is confirmed. Исключение — PostgreSQL с включённым «Allow an unencrypted connection»: сертификата нет и подтверждать нечего;
• учётные записи баз входят только по паролю: This server has key accounts; a database server signs in with a password only. Delete them first.;
• для доступа «только чтение» создайте на самой базе пользователя с минимальными правами и заведите его отдельной учётной записью сервера. Карточка сервера подсказывает, как (для PostgreSQL: роль только с CONNECT и SELECT; для MySQL: SELECT на схему; для SQL Server: логин с ролью db_datareader);
• логин человека, имя сервера и имя учётной записи вместе образуют имя пользователя для клиента. Если оно слишком длинное для протокола базы, пропуск выдать нельзя: The person's login, the server and the account together are too long for this database protocol. Shorten the server or account name.

Карточка сервера

Клик по имени сервера открывает карточку (/servers/<id>). В заголовке — кнопки Edit и Delete, у выключенного сервера рядом метка состояния. Вкладки:

Удаление сервера (Delete) спрашивает подтверждение: Delete the server … and its N accounts with their secrets? Rules that name it directly stop leading to it. Учётные записи и их секреты удаляются вместе с сервером, правила, называвшие сервер напрямую, перестают к нему вести (в правиле останется «Nowhere», если больше ничего не выбрано). Открытые сессии на этот сервер сразу прекращаются.

Ключ хоста SSH: как получить, подтвердить и что меняется

Ключ хоста — «паспорт» SSH-сервера. Шлюз запоминает его при первом знакомстве (метод «доверие при первом использовании», TOFU) и затем при каждом подключении проверяет, что сервер предъявил тот же ключ. Если ключ изменится (подмена сервера, переустановка), шлюз откажет в подключении, и секрет учётной записи на такой сервер не будет отправлен.

1. Откройте карточку сервера. Пока ключ не подтверждён, в блоке Host key написано Not confirmed — sessions are refused until it is, а в списке серверов у имени стоит метка Key not confirmed.
2. Нажмите «Test the connection». Шлюз подключится к адресу и порту сервера (не дольше 20 секунд), прочитает предъявленный ключ и покажет блок Connection check с отпечатком в строке Presented host key. Если вы выбрали учётную запись в списке Sign in as, шлюз попробует войти; вариант Key only, no sign-in означает «только прочитать ключ». Вход выполняется только на уже подтверждённый ключ — иначе шлюз не отправит пароль: Confirm the key first; the sign-in is tested against a confirmed key only.
3. Сверьте отпечаток. Консоль подсказывает: Before confirming, compare it with ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub on the server itself. То есть на самом сервере выполните ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub (для RSA — ssh_host_rsa_key.pub) и сравните строку SHA256:… с показанной консолью. Шлюз предпочитает ключ ECDSA; если у сервера его нет, будет показан ключ RSA — тогда сравнивайте с ssh_host_rsa_key.pub. Сравнивайте всегда с ключом того же типа, который показал шлюз.
4. Нажмите «Confirm this key». Шлюз заново подключится к серверу и сохранит ключ, только если сервер предъявит именно его. Если за это время сервер показал другой ключ: The server now presents another key than the one you checked. Check again. После успеха: Host key confirmed. Подтверждение ключа SSH не требует повторного ввода пароля, но записывается в аудит (hostkey.confirm).

Результат проверки после подтверждения читается так:

Что меняется, когда ключ сбрасывается: при изменении адреса (Address) или порта сервера подтверждённый ключ удаляется, и консоль пишет Saved. The host or port changed: confirm the host key again. Сменив адрес или порт, пройдите шаги 2–4 заново. Протокол SSH нельзя «подтвердить заранее»: ключ можно подтвердить, только увидев его.

Сертификаты и отпечатки: RDP, VNC и базы данных

Для серверов с TLS шлюз проверяет «отпечаток» сертификата так же, как ключ хоста SSH: при первом знакомстве его показывают администратору, администратор сверяет его с самим сервером и подтверждает, и после этого шлюз принимает только его. Сводка:

Подтверждение сертификата не включает сервер автоматически. После Confirm this certificate консоль пишет Certificate confirmed. Switch the server on to use it.; включите переключатель Active на карточке (кнопка Active в блоке Quick actions) или в форме изменения.

Сертификат подтверждается заново (шлюз сам об этом скажет), если вы изменили адрес, порт или протокол сервера, а для VNC — ещё и тип входа. Подтверждённая запись при этом удаляется, и сервер выключается: Saved. The address, port or protocol changed: check the connection and confirm the certificate again. (для VNC: Saved. The address, port or sign-in type changed, so the confirmed certificate was removed.). Простое изменение описания, папки или имени сертификат не трогает.

RDP

1. Разрешите NTLM для сервера. Без этого проверка отказывается: Not checked: this RDP server is not marked as allowing NTLM, and in this version an RDP server is reached with NTLM only.
2. Откройте карточку и нажмите «Test the connection». Подсказка к кнопке: Connects and shows the server's TLS certificate; no sign-in is tried. Шлюз подключается, проходит согласование защиты и TLS-рукопожатие и ничего не отправляет дальше: ни пароль, ни учётные данные. Показывается Presented certificate.
3. Сверьте отпечаток. Консоль: Before confirming, compare it with the SHA-256 fingerprint of the Remote Desktop certificate on the server itself. На Windows-сервере, например, в PowerShell:

   $c = Get-ChildItem 'Cert:\LocalMachine\Remote Desktop' | Select-Object -First 1
   ([BitConverter]::ToString([Security.Cryptography.SHA256]::Create().ComputeHash($c.RawData)) -replace '-','').ToLower()

   Сравнивайте шестнадцатеричные цифры, регистр и разделители значения не имеют. Если в хранилище несколько сертификатов, сверяйте с тем, который использует служба удалённых рабочих столов.
4. Нажмите «Confirm this certificate». Консоль попросит подтвердить личность (повторный пароль и код), затем заново подключится к серверу и сохранит сертификат, только если сервер предъявил точно его. Иначе: The server now presents another certificate than the one you checked. Check again. Событие записывается в аудит (rdp.cert.confirm).
5. Включите сервер (Active).

Результат проверки: Matches the confirmed certificate — сервер предъявил подтверждённый сертификат; Differs from the confirmed certificate … — предъявлен другой (обновление сертификата или подмена; подтвердите заново только после проверки). Ошибки проверки: The server offers no TLS: only the old RDP security, which the gateway does not use, The server did not answer as an RDP server, The TLS handshake with the server failed, The server could not be reached (см. Неисправности).

Кнопка Clear the certificate (после подтверждения личности и запроса Clear the confirmed certificate of …? The server is switched off until a certificate is confirmed again.) снимает подтверждение и выключает сервер. Используйте её, когда нужно вынужденно переподтвердить сертификат (например, на сервере выпустили новый).

VNC

Для VNC на карточке есть блок Check connection и блок Server certificate (Subject, Public key (SHA-256), Confirmed …). Если сертификат не подтверждён, написано Not confirmed. This server cannot be used until its certificate is confirmed.

1. Нажмите «Check connection». Подсказка: Shows what the server offers and its certificate; it signs in only with an account, and on a TLS server only once its certificate is confirmed. Шаги проверки перечислены в таблице ниже.
2. Сверьте сертификат с тем, что установлен на самом VNC-сервере (Before confirming, compare the certificate's SHA-256 fingerprint with the certificate on the VNC server itself.). Консоль показывает SHA-256 открытого ключа сертификата.
3. Нажмите «Confirm this certificate» (потребуется подтверждение личности). Сертификат закрепляется, если сервер предъявил точно его. Сообщение: The certificate is pinned. Switch the server on to use it.
4. Включите сервер.

Чтобы проверить ещё и вход, в списке Also sign in with the account выберите учётную запись; вариант Offered types only, no sign-in означает «только прочитать предложения сервера». Секрет учётной записи отправляется только на подтверждённый сертификат (для TLS-серверов) или на нешифрованный сервер, если вы приняли этот риск. Для слабых типов входа перед входом спрашивается подтверждение личности (Confirm who you are before the gateway signs in to this server.).

Состояние каждого шага: ok, failed, skipped, not reached. Если шаг не удался, консоль объясняет причину (список причин — в главе Неисправности). Кнопка Clear the certificate снимает закрепление и выключает сервер (The certificate pin was removed and the server switched off.).

Если рабочий процесс сессии VNC для этого сервера завершается аварийно, в карточке появляется предупреждение: The session worker for this server crashed N times in the last 24 hours.

Базы данных

На карточке сервера базы данных кнопка проверки называется Check connection (подсказка: Connects and shows the server's certificate and version; no sign-in is tried). Шлюз показывает Subject, Issuer, Valid, Key (SPKI SHA-256), Certificate SHA-256 и версию сервера (Server version). Подтверждение — кнопка Confirm this certificate (для замены уже подтверждённого — Confirm the new certificate), с повторным вводом пароля и кода. Чтобы сверить отпечаток на самом сервере по файлу сертификата, можно выполнить: openssl x509 -in server.crt -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256.

• Если сервер показывает другой ключ, чем подтверждён: The server now shows a different certificate key. Connections are refused until you confirm it.
• Если у PostgreSQL включён режим «без шифрования», а сервер действительно не предлагает шифрование: The server offers no encryption; it is reached unencrypted, as the switch on its form allows.
• SQL Server со своим «запасным» сертификатом: This is SQL Server's own fallback certificate: it changes at every service start, and each restart needs a new confirmation. Provision a certificate (mssql-conf set network.tlscert on Linux, SQL Server Configuration Manager on Windows). Установите на сервер постоянный сертификат, иначе после каждого перезапуска придётся подтверждать заново.

Кнопка Test sign-in проверяет вход выбранной учётной записи (список Sign in as). Подсказка: Signs in with the stored password of the account you choose; you are asked to confirm who you are first. Результат: The account signed in. или The account could not sign in: … с короткой причиной (список причин — в главе Неисправности). Пароль отправляется только на подтверждённый сертификат или (PostgreSQL без шифрования) в защищённом SCRAM-обмене.

Лимит лицензии на активные серверы

Лицензия шлюза ограничивает число активных серверов. Создать активный сервер, включить выключенный или сохранить форму так, что сервер стал бы активным, сверх лимита нельзя: The licence allows N active servers. Switch off a server or extend the licence. Отказ записывается в журнал аудита (licence.limit). Выключить сервер можно всегда. Состояние лицензии и её продление — на странице Licence (раздел «Лицензия»).

Если срок лицензии истёк, лицензии нет или активных серверов больше, чем разрешено, а льготный срок закончился, консоль вообще отказывает в изменениях (в том числе серверов), например: The licence has ended: changes are refused. Upload a licence on Settings → Licence. Полный список — в главе Неисправности.

Серверы, которые вы создали «про запас», лучше держать выключенными: неактивные серверы лимит не расходуют.

Что происходит с открытыми сессиями при изменении сервера

После сохранения, выключения, переноса в другую папку или удаления сервера, а также после очистки его сертификата шлюз заново проверяет права всех открытых сессий (на SSH, RDP, VNC и базы). Сессия, права которой пропали (сервер выключен или удалён, сертификат снят), закрывается с понятным пользователю сообщением. Изменение имени или описания открытые сессии не затрагивает.

Любое изменение сервера записывается в журнал аудита: server.create, server.update, server.delete, server.test (проверка соединения, с результатом), hostkey.confirm, rdp.cert.confirm, rdp.cert.clear, vnc.cert.confirm, vnc.cert.clear, server.db_tls_pin, server.db_test. В событиях нет паролей и ключей; для проверки Telnet фиксируются только достигнутые шаги.

Профили устройств

Профиль устройства — набор «подсказок» для шлюза, как войти на Telnet-сервер и как включить привилегированный режим на сетевом устройстве. Telnet не имеет единой процедуры входа: каждое устройство пишет своё приглашение («Username:», «login:», «Password:») и по-своему сообщает об ошибке. Профиль описывает, какие строки шлюз должен узнать, чтобы вовремя ввести логин и пароль.

Страницы профилей находятся в группе меню Resources, пункт Device profiles (/servers/profiles). Administrator видит и меняет профили. Auditor видит список и карточки профилей только для чтения: так аудитор может проверить, по каким правилам шлюз входит на устройства. Кнопки создания, изменения, удаления, дублирования и проверки по записи ему не показываются.

Список профилей

Таблица содержит столбцы Name (со значком Built-in у встроенных), Line end sent и Wait per step, seconds. Кнопка New profile создаёт свой профиль; кнопка Edit в строке есть только у своих профилей. Подсказка страницы: How the gateway signs in on a Telnet server, and enters privileged mode on a network device.

Встроенные профили поставляются со шлюзом, обновления их сохраняют, изменить или удалить их нельзя (Built-in profiles are kept by updates and cannot be changed; duplicate one to adapt it.). Их шесть:

Карточка профиля и копирование

Карточка профиля (/servers/profiles/<id>) показывает все его поля: Name, User name prompt, Password prompt, Signed-in prompt, Refused login, Wait per step, seconds, Line end sent, а у встроенных ещё Privileged step, User name suffix, Fixed answers. Строка Servers using it перечисляет серверы, которые используют профиль.

Кнопка Duplicate делает копию под именем «Copy of …» (если такое имя занято — «Copy of … 2», «Copy of … 3» и т. д.) и открывает её на изменение. Привилегированный шаг, суффикс имени пользователя и фиксированные ответы при копировании не переносятся: они доступны только у встроенных профилей. Консоль об этом предупреждает: Privileged mode is available only with the built-in profile. Поэтому копия подходит для обычных устройств с входом по логину и паролю; для устройства, которому нужен привилегированный режим, используйте встроенный профиль.

Кнопка Delete у своего профиля спрашивает Delete profile …?. Профиль, которым пользуется хотя бы один сервер, удалить нельзя: The profile is used by these servers: … Встроенный профиль удалить нельзя: A built-in profile cannot be changed or deleted.

Создание и изменение своего профиля

Кнопка New profile открывает форму /servers/profiles/new. Значения шаблонов — регулярные выражения. Шлюз применяет их к концу последней принятой строки и сравнивает по безопасному алгоритму, который не зависает на «тяжёлых» выражениях.

Подсказка под шаблонами: A .NET regular expression, at most 512 characters, matched at the end of the last line. Backreferences, lookarounds and atomic groups are not supported. Возможные ошибки шаблона: This is not a valid regular expression., At most 512 characters., Backreferences, lookarounds and atomic groups are not supported., This regular expression is too costly to check against device output. Simplify its repetitions. Правки при открытой форме защищены от «потерянного обновления»: если профиль изменил другой администратор, будет The record was changed by another administrator — open it again.

Проверка профиля по записи сеанса

Под формой профиля (и на карточке) находится блок Test against a transcript: вы вставляете то, что показывает устройство, а шлюз проверяет, вошёл бы он с этим профилем. Для проверки не нужно подключаться к устройству и не используются настоящие пароли. Подсказка: Paste what the device shows; mark where the gateway types with ⟨user⟩ and ⟨password⟩, or paste a TelnetProbe capture.

1. Скопируйте вывод устройства в поле Transcript: приглашения и ответы, как их видит человек.
2. Отметьте места, где шлюз вводит данные, маркерами ⟨user⟩ (имя) и ⟨password⟩ (пароль). Для привилегированного шага — ⟨privileged⟩. Перед каждым маркером шлюз выдерживает короткую паузу (200 мс).
3. Нажмите «Run the test». Шлюз проиграет запись «в виртуальном времени» и покажет таблицу: Step, Pattern, Matched text, Result по каждому шагу (User name prompt, Password prompt, Signed in, Refused, Privileged password prompt, Privileged mode, Fixed answer; рядом — номер строки записи). Результат каждого шага: Matched, Not matched, Timed out или Skipped.
4. Прочитайте итог: The gateway would sign in with this profile. или The gateway would not sign in with this profile.

Запись не может быть больше 64 КиБ (A transcript is at most 64 KiB.); пустая или не читаемая запись даёт A value was not accepted. Check the form. Ничего из проверки не сохраняется. Проверку по форме можно делать до сохранения профиля: она использует шаблоны, которые вы ввели в форме. Проверка по карточке использует сохранённые шаблоны. Запускать проверку может только Administrator.

Учётные записи

Учётная запись сервера — это логин и секрет (пароль или закрытый ключ), под которыми шлюз входит на сервер вместо человека. Человек секрета не знает и не может его узнать: шлюз подставляет секрет сам в момент подключения. У одного сервера может быть несколько учётных записей (например, root и deploy). Какие из них доступны человеку, решают правила.

Учётные записи видит и меняет только Administrator. Они доступны в двух местах: на вкладке Accounts карточки сервера (записи одного сервера) и в общем списке Accounts группы меню Resources (/accounts, записи всех серверов — удобно искать по логину).

Список учётных записей

Страница /accounts (подсказка: Every account of every server, to find one by login. Secrets are write-only.):

Создание учётной записи

Кнопка Add account на вкладке Accounts карточки сервера открывает форму /accounts/new (в общем списке /accounts кнопки создания нет — список только для поиска, замены секретов и удаления). Сервер, с карточки которого вы пришли, уже выбран.

Под полями секрета консоль пишет: The old secret cannot be viewed. The new one is stored encrypted; the change goes into the audit log. Кнопки: Create, Cancel. После создания вы возвращаетесь на вкладку Accounts карточки сервера. В аудит пишется событие account.create (логин, сервер, тип секрета, режим; сам секрет не записывается).

Закрытые ключи: какие подходят

• Типы ключей: RSA и ECDSA (nistp256/384/521). Ed25519 пока не поддерживается: Ed25519 keys are not supported yet. Use an ECDSA or RSA key. Создайте подходящий ключ: ssh-keygen -t ecdsa -b 384 или ssh-keygen -t rsa -b 4096.
• Форматы: OpenSSH (BEGIN OPENSSH PRIVATE KEY) и PEM. Зашифрованный PKCS#8 (BEGIN ENCRYPTED PRIVATE KEY) прочитать нельзя; консоль советует: Convert the key to the OpenSSH format with ssh-keygen -p -f <file> and paste it again.
• Если парольная фраза неверна или ключ другого типа: This key cannot be used: the passphrase is wrong, or it is not an RSA or ECDSA key. Если поле пустое или в нём не ключ: A private key in OpenSSH or PEM format is required.
• Ключом можно входить на SSH-серверы. Серверы Telnet, RDP, VNC и баз данных принимают только пароль (см. сообщения в разделе Серверы).

Замена секрета

Меню строки → Replace secret открывает страницу /accounts/<id>/secret (кнопка Replace). На ней показан только тип секрета и дата последней смены, сам секрет не показывается. Введите новый пароль (дважды) или новый ключ с парольной фразой по тем же правилам. После сохранения: The secret is replaced. В аудит пишется account.secret с типом секрета (password или key), без значений. Замена не прерывает уже открытые сессии: они продолжаются на старом входе, новые используют новый секрет.

У записей VNC-серверов под полем пароля есть пояснение: для типов «VNC password» значимы только первые 8 символов; для «Mac user name and password» имя и пароль — не более 63 байт каждое (For a Mac, the name and the password are each at most 63 bytes.).

Привилегированный режим сетевого устройства

На маршрутизаторах и коммутаторах после входа часто нужно ещё «повысить» привилегии: Cisco — командой enable и вторым паролем, Huawei — super. Шлюз может выполнить этот шаг сам, чтобы человек не знал второго пароля. Режим включается для учётной записи при создании или на странице /accounts/<id>/privileged (кнопка Save privileged mode) и доступен только если у сервера выбран встроенный профиль сетевого устройства (Cisco IOS / IOS-XE, Cisco NX-OS, Huawei VRP). Иначе: Privileged mode is available only with a built-in network-device profile.

Профиль сервера нельзя заменить на тот, у которого нет привилегированного шага, пока есть записи в привилегированном режиме: Accounts of this server use privileged mode: choose a built-in network-device profile, or turn their privileged mode off first. Изменение режима записывается в аудит (account.privileged: было и стало); пароль привилегированного режима не записывается.

Как учётные записи связаны с серверами и правилами

• Логин записи — это то, что правило называет в поле Logins. Правило разрешает вход «под любым из перечисленных логинов на любом из выбранных серверов».
• Если у сервера одна доступная человеку запись, он может не указывать её при подключении; если несколько — добавляет третью часть имени (логин:сервер:учётная_запись, см. главу Подключение по SSH).
• Удаление сервера удаляет его учётные записи вместе с секретами. Удаление записи не меняет правила, но они перестают разрешать вход этим логином.
• Если шлюз закрыт (ключ шифрования не открыт, см. Открытие шлюза), создать или заменить секрет нельзя: The encryption key is not available.

Правила доступа

Правило отвечает на вопрос «кому, куда, под какой учётной записью, на какой срок и с какими правами на данные». Любого доступа без правила нет: если ни одно правило не называет человека и сервер, подключиться нельзя. Формула из консоли: A rule = who × where × with which account × until when.

Правила видит и меняет только Administrator (группа меню Access, пункт Access rules, адрес /rules). Правило бывает двух типов:

• Standing access (постоянный доступ) — действует сразу и до конца срока. Подробно описан здесь.
• By request (по запросу) — человек подаёт запрос на ограниченное время, решают согласующие. Этот тип описан в разделе Запросы на доступ. Он использует тот же перечень «Кто», «Куда», «Учётные записи» и «Права на данные», что описан ниже.

Список правил

Таблица /rules показывает столбцы Name, Type, Users, Groups, Servers, Accounts (All или Specified (N)), Data (кратко: файлы, терминал, копии), Starts / Ends и State. Фильтры-чипы: In effect, Ending ≤ 7 d, Not started yet, Expired, Disabled. Поиск: Name, user, server. Кнопка Create rule создаёт правило. Групповые действия над отмеченными постоянными правилами: Enable, Disable, Delete.

Состояния правила в столбце State: In effect, Ends in N d (скоро закончится), Not started yet, Expired, Disabled. Пустой список: No access rules yet и пояснение, что правило говорит, кто может подключаться к каким серверам, с какими учётными записями и до какого срока.

Создание и изменение правила

Кнопка Create rule открывает форму /rules/new. Вверху переключатель типа: Standing access / By request (подсказка: Standing access applies at once. By request lets people ask for a limited time; approvers decide.). Тип правила выбирается при создании и потом не меняется (The type of a rule is chosen when it is created and cannot be changed.). Форма изменения (/rules/<id>/edit) — та же. Секции нумеруются по порядку:

Кнопки формы: Create / Save, Reset, Cancel. Правила времени простые: только «с» и «до». Повторяющихся окон («по будням с 9 до 18») в правилах нет; для разовых работ задайте срок, для периодических — заведите правила на нужные интервалы или используйте доступ по запросу.

Карточка правила

Клик по названию открывает карточку (/rules/<id>). Заголовок — название, метка состояния, кнопки Edit и Delete. Вкладки:

Если в правиле остались «нет никого» или «нигде» (Nobody / Nowhere) — например, группу или сервер удалили, — консоль предупреждает: This rule names nobody or nowhere (its group, user or server was deleted), so it gives no access. Edit it to name them, or delete it.

Что происходит с открытыми сессиями

Правило проверяется не только в момент входа. Шлюз заново оценивает права каждой открытой сессии, как только изменилось что-то, способное отнять доступ, и ещё в момент окончания срока правила, которое даёт сессии доступ:

• правило закончилось по сроку, отключено или удалено; отключён человек или сняты его роли; изменена или удалена группа; сервер выключен или удалён; удалена учётная запись; папка перенесена или удалена; человек сменил пароль (для прямых SSH-подключений) — сессия закрывается, человек видит сообщение (например, Your access to this server has ended. The session is closed.);
• если доступ даёт несколько правил, сессия живёт, пока действует хотя бы одно; шлюз проверяет доступ заново, а не следует «первому» правилу;
• правило сузили (убрали направление файлов или буфера обмена, выключили устройство или ввод): сужение действует сразу, открытая сессия получает новые права со следующего пакета. Если у SSH-сессии терминал выключен правилом, оболочка и команды закрываются сообщением Your access rule no longer allows a terminal on this server. The session is closed., а передача файлов остаётся доступной;
• правило расширили (добавили устройство или направление): устройство RDP, которое не было предложено при подключении, добавить в идущую сессию нельзя — расширение действует со следующего подключения (A device the session did not offer when it started cannot be added to it: a change that allows more takes effect at the next connection.);
• для доступа, выданного по запросу, человек за несколько минут до конца видит предупреждение, а при отзыве — кем отозван доступ.

Закрытие по сроку точное: у каждой сессии шлюз ставит таймер на ближайший конец правила, которое ей даёт доступ. Если база данных шлюза на время недоступна, открытые сессии продолжаются (отказ в проверке не считается «нет»), а новые не открываются.

Удаление правила (Delete) спрашивает: Delete the rule …? The access it gives ends at once. Правило по запросу, у которого уже есть запросы, удалить нельзя — его можно только отключить (A rule that has requests cannot be deleted; disable it instead.). Все изменения правил записываются в аудит (rule.create, rule.update, rule.enable, rule.disable, rule.extend, rule.delete) с описанием, что изменилось.

Политика файлов, буфера обмена и устройств

Эти права задаются в правиле доступа, в секции Data movement. Они отвечают на вопрос «что человек может унести с сервера и принести на него» и действуют на каждую сессию. Поля общие для всех протоколов; какие из них применимы к какому протоколу, показывает таблица.

Поля и значения по умолчанию

Как правила складываются

Если человеку доступ даёт несколько правил, итоговые права — объединение: направление файлов и буфера обмена — объединение направлений, Terminal, копии, запись текста буфера, устройства RDP и управление экраном — «хотя бы в одном правиле включено». Копии хранятся, если их требует любое правило, а предельный размер берётся наибольший из правил, где копии включены. Итог определяется при входе, запоминается на сессию и пересчитывается, когда правила меняются (см. Что происходит с открытыми сессиями).

USB в RDP

Перенаправление USB передаёт устройство целиком (диски в том числе) и не подчиняется правилу для файлов. Поэтому его можно включить только вместе с Upload and download: USB devices can be allowed only together with “Upload and download” for files. Подсказка к полю: USB redirection moves whole devices, drives included, and does not follow the file rule. It can be switched on only together with “Upload and download” for files.

SFTP и SCP: чем отличаются от терминала

• Передача файлов идёт отдельным каналом, который шлюз разбирает сам: каждая операция проверяется по направлению, ведётся журнал (страница Передача файлов), считается хэш переданных данных, при необходимости сохраняется копия.
• Размер файла и общий объём за сессию ограничивают настройки Sessions → File transfer (Largest file, MB, All files in one session, MB). Превышение останавливает передачу.
• Если правило не разрешает терминал, работают только sftp и scp; оболочка, команды, rsync и sftp -s отклоняются. SCP в режиме WinSCP требует оболочку на сервере и поэтому тоже отклоняется (WinSCP нужно переключить на SFTP).
• Telnet-серверам передача файлов не доступна.

Типовые схемы: только файлы — Terminal выключен, File transfer — «Upload and download» или одно направление; только оболочка — Terminal включён, файлы выключены (помните об ограничении 1); RDP без выноса данных — буфер обмена, файлы и устройства выключены (звук с сервера можно оставить).

Что видит пользователь при отказе, перечислено в главе Неисправности (группа «Передача файлов»). Как пользователю подключить SFTP и SCP, написано в разделе Подключение по SFTP и SCP.

Настройки: ключ SSH шлюза

Страница /system/ssh (меню System → Settings → плитка Gateway SSH key, группа «Security»). Видит только Administrator. Это страница для чтения: настроек на ней нет, кроме кнопок копирования. Подсказка страницы: The key SSH clients see when they connect to the gateway. BURSUcm and OpenSSH remember it on first use.

Это ключ самого шлюза (то, что видят SSH-клиенты людей), а не ключ какого-либо целевого сервера — ключи серверов описаны в разделе Серверы. Шлюз создаёт его один раз при первом открытии и использует тип ECDSA nistp256.

Если ключ шлюза изменится (например, шлюз переустановлен на чистую базу), у всех клиентов, запомнивших прежний, появится предупреждение об изменении ключа. Это нормальная защита: человек должен сверить новый отпечаток с этой страницей.

Настройки: подпись файлов .rdp

Страница /system/rdp-signing (плитка RDP file signing, группа «Security»). Видит и меняет только Administrator. Заголовок страницы — Signing of .rdp files.

Когда человек скачивает файл .rdp со страницы «My access» (см. Мой доступ), шлюз может его подписать. Подписанный файл показывает в Remote Desktop, кто его издал, а изменение любой подписанной строки ломает подпись (A signed .rdp file shows Remote Desktop who published it, and a change to any signed line breaks the signature. The certificate must be trusted on the computers that open the file.). Без подписи Remote Desktop предупреждает человека при каждом открытии файла: There is no signing key: .rdp files are not signed, and Remote Desktop warns the person who opens one.

Какой сертификат подходит. Файл не больше 64 КиБ; внутри ровно один сертификат с закрытым ключом RSA не короче 2048 бит; сертификат допускает цифровую подпись (расширение «использование ключа» либо отсутствует, либо содержит digitalSignature); срок действия уже начался и ещё не закончился. Шлюз при загрузке сам подписывает пробный файл и сверяет подпись; если ключ не подходит к сертификату, он будет отклонён сразу, а не при каждом скачивании. Причины отказа — в таблице ошибок ниже и в главе Неисправности.

Сохранение и удаление ключа записываются в журнал аудита событием rdp.signing_key (отпечаток; для отказа — причина). Скорый конец срока сертификата выносится в предупреждения на странице обзора.

Настройки: сессии

Страница /system/sessions (плитка Sessions, группа «Sessions and protocols»). Видит и меняет только Administrator. Подсказка страницы: How sessions through the gateway are recorded and how long they may stay idle. Input recording, idle time and the banner apply to new sessions only; running sessions keep theirs.

Страница — одна форма с кнопками Save и Reset. Сохраняются все значения разом; каждое изменённое значение записывается в журнал аудита событием setting.change (прежнее и новое значение). Если за время правки форму сохранил другой администратор, будет The record was changed by another administrator — open it again.; откройте страницу заново. Неверное число: Enter a whole number from … to ….

Какие изменения требуют подтверждения личности

Изменение, которое ослабляет надзор или затрагивает приватность, требует свежего подтверждения личности (повторный ввод пароля и кода, 10 минут). Ужесточающие изменения подтверждения не требуют.

• включить запись ввода SSH (Recording what people type needs your password and code again.);
• включить запись нажатий в RDP (Recording keystrokes needs your password and code again.) или индекс набранного текста (Indexing typed text needs your password and code again.);
• уменьшить срок хранения записей; увеличить время простоя SSH; увеличить или снять предел длительности RDP-сессии; увеличить время простоя RDP; увеличить или снять предел размера файла и суммы за сессию; сократить срок хранения копий;
• изменить текст баннера (any change of the banner's text), потому что любой другой текст может убрать фразу «сессия записывается».

Остальные случаи: Confirm who you are before this change: … It lowers session protection. и ссылка Confirm who I am.

Настройки: VNC

Страница /system/vnc (плитка VNC, группа «Sessions and protocols»). Видит и меняет только Administrator. Подсказка: Limits for VNC sessions through the gateway. A change applies to new sessions only; running sessions keep theirs.

Слушатель (Listener)

Первый блок показывает, готов ли шлюз принимать подключения VNC-клиентов. Он только для чтения: The listener is set in the gateway's configuration file (vncListen and vncAdvertisedName) and is changed there; it cannot be changed here. Поля: State, Host (имя, которое шлюз называет клиентам — vncAdvertisedName), Port.

Лимиты и параметры

Значение вне диапазона: Enter a whole number from … to …. Увеличение пределов, которое ослабляет защиту (число сессий, время простоя, длительность, размер буфера, ограничения рукопожатия и обновления, число экспортов, память зрителя) и выключение привязки кода к адресу требуют подтверждения личности: Confirm who you are before weakening a limit. Снятие предела длительности (0) тоже ослабление. Параметры показа и экспорта частоты кадров, длительности и размера этого списка не затрагивают. После сохранения: Saved.

Настройки: базы данных

Страница /system/databases (плитка Databases, группа «Sessions and protocols»). Видит и меняет только Administrator. Подсказка: Limits, pass lifetimes and protections for database connections through the gateway. A change applies to passes and connections made after the save; ones already open keep what they started with.

Пользователь баз данных получает на странице «My access» «пропуск» (pass) и вводит его в клиенте как пароль (см. Подключение к базам данных). Пропуск показывается один раз, но не одноразовый: им можно открыть несколько подключений в течение срока действия (по умолчанию 8 часов, не более 16 подключений), а первое подключение нужно сделать в течение 2 минут после показа. Настройки задают время жизни пропусков, число подключений и защиту.

Новые значения действуют для пропусков и подключений, созданных после сохранения; уже открытые сохраняют прежние. Изменения записываются в аудит событием db.settings (изменения и список ослаблений). Увеличение предела, продление срока, отключение защиты (channel binding, Strict), уменьшение текста запроса и смена строки версии — ослабления: These changes weaken protection and need you to confirm your password: … и ссылка Confirm who I am. При одновременной правке двумя администраторами: The record was changed by another administrator — open it again.

Запросы доступа

Не всякому человеку нужен постоянный доступ к серверу. Для редких задач удобнее, чтобы человек сам попросил доступ на ограниченное время, а решение принял другой человек (согласующий). Так устроены запросы доступа. В этом разделе описана сторона пользователя: как попросить доступ, как следить за запросом, как продлить доступ или вернуть его досрочно. Сторона согласующего описана в разделе Согласование запросов, аварийный доступ без согласования — в разделе Аварийный доступ.

Как это устроено

• Правило «По запросу» (By request) создаёт администратор в разделе Правила доступа. Само по себе оно ничего не разрешает. Оно лишь определяет: кто вправе просить, к каким серверам и учётным записям, кто согласует, сколько согласований нужно, на какой срок можно просить и сколько ждать решения.
• Запрос — это просьба конкретного человека о доступе к конкретной учётной записи конкретного сервера на указанный срок. У запроса всегда есть причина (текст) и иногда номер заявки.
• Доступ появляется, когда запрос одобрен (или одобрен автоматически, если правило так настроено). Шлюз сам записывает отдельное разрешение на этот срок. Его нельзя изменить: оно либо закончится в свой срок, либо будет отозвано.

Состояния запроса

Запрос в веб-консоли

Страница /access/requests открывается из меню My access (вкладка Access requests). Её видит любой вошедший пользователь. Страница разбита на две вкладки: Available to request и My requests.

Вкладка «Available to request»

Таблица показывает всё, что вам можно просить. Столбцы: Server, Account, Limits (наибольший срок, например Up to 8 h), Approval и Access period (окно времени, в которое правило вообще разрешает доступ, если оно ограничено).

В столбце Approval написано одно из двух:

• Approvals needed: N и ниже Approvers who can decide: M — сколько согласований требуется и сколько людей сейчас вправе их дать.
• Granted at once; the reason is recorded — правило автоматическое: доступ выдаётся в момент запроса, но причина всё равно записывается.

В конце строки — кнопка Request access. Если по этой паре у вас уже есть ожидающий запрос, вместо кнопки стоит метка Request pending. Если администратор разрешил вам аварийный доступ к этой паре, рядом есть красная кнопка Emergency access (см. Аварийный доступ).

Окно «Request access»

Окно открывается по кнопке Request access. Вверху сказано: Server …, account ….

Кнопка Send request отправляет запрос. Результат — сообщение вверху страницы: Request … sent. (ждите решения) или Request … sent and approved automatically. (правило автоматическое, доступ уже выдан).

Что проверяет шлюз при подаче

• Не больше 10 ожидающих запросов на человека. Больше — отказ You have too many requests waiting. Wait for a decision or cancel one.
• Если по этой же паре у вас уже есть ожидающий запрос, второй не создаётся: шлюз покажет сообщение You already have a request waiting for this server account. и укажет на первый.
• Если вы и так уже вправе подключаться ко всему запрошенному интервалу, запрос отклоняется: You already have access to this server account for that whole period.
• Если людей, которые могут согласовать, меньше, чем нужно для кворума, запрос не принимается: Nobody can approve this request now. Contact the administrator. Сам вы никогда не считаетесь согласующим своего запроса.
• Если на пару действует несколько правил, главным считается самое строгое: сначала по наибольшему числу нужных согласований, затем по наименьшему сроку, затем самое старое.
• Если сервер сверх числа, на которое куплена лицензия, или лицензия закончилась, запрос не принимается (сообщения This server is beyond the number of servers the gateway's licence allows. Contact the administrator. и The gateway's licence has ended. Contact the administrator.).

Отказ записывается в журнал аудита как событие request.create с исходом «отказано». Список сообщений — в главе Неисправности.

Вкладка «My requests»

Ваши запросы, новые сверху. Столбцы: No., Server, Requested, Access period, State. Под строкой видно, кто и когда решил (Decided by …), а если доступ отозван — кто и почему (Revoked by …: …). Пока запрос ждёт, показано, до какого часа ждать: Decision due by …. Пустой список: You have made no requests.

Когда вы открываете вкладку My requests, все решённые запросы отмечаются как просмотренные, и пропадает уведомление о них в колокольчике (Your requests that were decided: …).

Когда доступ заканчивается или отзывается

• В свой срок. Доступ действует ровно на согласованный интервал. По его окончании шлюз закрывает сессии, которые держались на этом доступе.
• Предупреждение. За несколько минут до конца (по умолчанию 5, настраивается на странице Notifications, 0–30; 0 отключает) шлюз пишет в открытую SSH-сессию строку Your granted access ends in … minutes. File an extension request if you need more time. Клиент BURSUcm показывает такое же предупреждение всплывающим сообщением.
• Отзыв. Вернуть доступ досрочно вправе: сам запрашивавший (Release access), администратор (страница /rules/grants, заголовок Grants) и согласующий этого правила (вкладка Active grants на странице Approvals). Сессии на этом доступе закрываются сразу, в терминал пишется Your granted access was revoked by …. The session is closed. Продления, зависевшие от отозванного доступа, отменяются (ожидающие) или тоже отзываются (одобренные).
• Правило отключили. Все ожидающие запросы по нему отменяются, о чём приходит письмо. Уже выданный доступ при этом остаётся, если администратор не отметил Also revoke access already granted from this rule.

Если вы подключаетесь по обычному SSH

Если доступа сейчас нет, но его можно запросить, шлюз отказывает в подключении и сам подсказывает путь: Access is not allowed now. You can request it in the web console: … (с адресом консоли) или, если адрес консоли не задан, … under My access, Access requests. Подайте запрос на странице /access/requests и подключитесь заново после одобрения.

Запрос из BURSUcm

Клиент BURSUcm (Windows и Universal) умеет подавать и отслеживать запросы без веб-консоли. Нужно, чтобы шлюз был подключён как источник каталога (см. BURSUcm).

• В дереве подключений появляется второй корень On request. Там перечислены серверы, к которым доступа нет, но его можно запросить. У каждой строки пояснение Access to this server is given on request. Состояние отражается значками: ожидание, Approved. Access starts … (одобрено, начнётся позже), либо until HH:mm у действующего доступа.
• Двойной щелчок или пункт Request access... открывает окно Request access (при продлении оно называется Extend access). Поля те же, что в консоли: Server (только чтение), Account (список, если учётных записей несколько), Start (When approved или At a set time с датой ГГГГ-ММ-ДД и временем ЧЧ:ММ), Duration (с вариантом Custom... и подсказкой minutes, 1 to …), Reason со счётчиком, Ticket (или Ticket (optional)) и Format: …. Кнопки: Cancel, красная Emergency access (только если разрешён аварийный доступ) и Send request.
• Под заголовком окна клиент пишет, как будет рассматриваться запрос: Approved automatically; the request is recorded. либо Approvals needed: N. People who can approve: M., и ниже Rule: ….
• После отправки то же окно превращается в панель состояния: Waiting for approval · X of Y approved · expires …, Approved · starts …, Approved · active until …, а также итоговые строки This access has ended., The request was denied., The request was cancelled., Nobody answered in time; the request expired., The access was revoked. Кнопки панели — Cancel request и Connect now (когда доступ действует). Если шлюз недоступен, панель пишет cannot reach the gateway, trying again и повторяет опрос; если опрос прекращён — The status is no longer updated. Open My access requests to see it.
• Меню File → My access requests... открывает список ваших запросов (заголовок My access requests, подсказка Your requests, newest first. A running access can be given back or extended.) со столбцами Server, Account, State, Period, Answers и кнопками Refresh, Release, Extend..., Cancel request, Close. При возврате доступа клиент спрашивает: Give this access back now? Sessions running on it end. Пустой список: You have no access requests yet. Ask for access from the On request list.
• Стадии запроса в клиенте: Waiting for approval, Scheduled, Active, Ended, Denied, Cancelled, Expired, Revoked.
• Всплывающее предупреждение перед окончанием: Your access to … as … ends at …. Extend it in My access requests. После окончания: Your access to … as … has ended. с возможностью сразу запросить доступ снова.

Клиент проверяет поля сам до отправки и выводит понятные сообщения: A reason is required., The reason must be at most 1000 characters., Enter the ticket number., The ticket number must be at most 64 characters., The duration must be from 1 minute to …, The start must be later than now., The start can be at most 7 days ahead., The period must lie inside the time this access may be requested for. Ответы шлюза показываются теми же фразами, что и в консоли (см. Неисправности).

Согласование запросов

Раздел для людей с ролью Approver. Он описывает страницу /approvals (меню Access → Approvals), на которой согласующий принимает решения по запросам доступа и подтверждает команды, задержанные контролем команд. Общий порядок рабочего дня согласующего — в разделе Роль «Approver».

Кто может согласовывать

Решать запрос может человек, который одновременно:

• включён и имеет роль Approver;
• назван в правиле «По запросу» как согласующий — лично или через группу (поле Approvers правила);
• не является автором этого запроса. Решение по собственному запросу невозможно: страница его просто не показывает.

Если запрос нельзя решать вам или его нет, страница отвечает одинаково — «не найдено» (HTTP 404). Так согласующий не узнаёт о чужих запросах, к которым не допущен. Администратор страницу Approvals не видит: роли Administrator и Approver несовместимы (подробнее — в разделе Роль «Approver»).

Вкладки страницы

Вкладки идут в таком порядке. Каждый список ограничен 100 строками.

Число на значке в боковом меню считает только запросы, ожидающие решения. Команды, ждущие подтверждения, в него не входят; о них говорят вкладка Commands и колокольчик.

Карточка запроса

Заголовок — Request №. В карточке: Requester, Server and account, Access period, Reason, Ticket, Rule, Approvals: X of Y и Decisions so far (кто уже одобрил или отказал, с комментариями; пока никого нет — None yet.). Для оценки добавлены две справки: This person's last five requests и This person's last five sessions on this server.

Если после подачи запроса условия правила изменились, над кнопками стоит предупреждение о том, что будет, когда вы одобрите: … now governs this access, so approving will cancel this request., No rule offers this access any more, so approving will cancel this request., The ticket no longer meets the rule's terms, so approving will cancel this request. или The rule now allows at most … minutes: the grant will be that long.

Одобрить или отказать

Результаты: Your approval is recorded; more approvals are needed. (кворум ещё не набран), Approved. The access is granted. (кворум набран, доступ выдан), Request denied.

Кворум. Число нужных согласований задаёт правило (от 1 до 5, от разных людей). Запрос получает доступ, когда набрано нужное число одобрений от людей, которые к этому моменту ещё вправе согласовывать. Если кого-то из проголосовавших успели лишить роли или убрать из правила, его голос не считается; в истории это видно как Vote dropped: this approver no longer qualified at the final count. Когда согласующие предложили разный срок, выдаётся самый короткий из предложенных.

Ожидание. Если запрос не решён за время, заданное правилом (по умолчанию 240 минут), он истекает.

Вкладка «Active grants»

Для каждого доступа видны человек, сервер, учётная запись и срок. Кнопка Revoke спрашивает Revoke the access of … to …? Open sessions end at once. и принимает необязательное поле Reason (kept in the log) (не более 1000 символов). Отзыв закрывает открытые сессии, а продления, зависевшие от этого доступа, отменяются или отзываются. Сообщения: Access revoked. и Access revoked, and … extension(s) that depended on it. Если доступ уже закончился или отозван, будет сказано This access has already ended or was taken back.

Подтверждение команд

Если политика контроля команд содержит правило Ask a second person, строка, набранная пользователем, задерживается, пока подтверждающий не разрешит её (см. Контроль команд). Такие строки показаны на вкладке Commands. Список обновляется сам, без перезагрузки: New commands appear here as soon as they are held. The page does not need to be reloaded. Если связь потеряна: The live connection was lost. Reload the page to see what is waiting.

• Открывая вкладку, вы переходите на подтверждение личности, если свежего подтверждения нет. Страница показывает, сколько оно ещё действует: Your confirmation is valid for another …. Когда оно истекло: Your confirmation has run out, so Allow is off until you confirm again. Команда не ждёт, пока вы подтвердитесь, поэтому сделайте это заранее.
• Карточка: Command held for confirmation, Person, сервер и учётная запись, Policy and entry, Confirmations: X of Y, Time left: … s, Command (пароли и ключи скрыты там, где их удаётся распознать).
• Памятка: You confirm a text, not a program. Aliases, functions and key bindings can make a line do something other than what it says.
• Last screen rows — последние строки экрана сессии (если политика включает Show the last screen rows to the confirmer). Они подписаны From the target: их написал сам сервер, он может подделать любой вывод, поэтому они ничего не доказывают.
• Lines read earlier in this session — прежние строки сессии. Строки, которые меняют команды или клавиши (alias, function, bind), помечены redefines a command or a key.
• Ссылка Watch live есть только у человека, который одновременно Auditor: смотреть сессию вживую может только аудитор.

Свою собственную сессию подтверждать нельзя: This is your own session. Another person has to decide. Если время вышло, команда отклонена автоматически (таймаут — это отказ). Если строка изменилась, пока ждала, подтверждение недействительно: The held line is not the one you were shown, so it was refused. Сразу после перезапуска шлюза страница не принимает решений, пока не закончится проверка ожидающих команд: The decision could not be saved. Try again.

Колокольчик и уведомления

В верхней панели консоли находится колокольчик Alerts. У согласующего он есть всегда. Обычный пользователь видит его, только если у него есть что показать. Пункты, важные для этого раздела:

• Requests waiting for your decision: … — ссылка на вкладку Waiting for me.
• Commands waiting for your confirmation: … — ссылка на вкладку Commands.
• Your requests that were decided: … — у запрашивавшего; ссылка на My requests.
• Для администратора: Rules that no one can approve now: …, New approvers without a console change: …, Directory roles refused (Administrator wins over Approver): ….

Остальные пункты колокольчика описаны в разделах Аварийный доступ, Уведомления и Контроль команд.

Аварийный доступ

Аварийный доступ (по-английски break-glass, «разбить стекло») — способ попасть на сервер без согласования, когда работа не терпит ожидания. Он устроен так, чтобы им нельзя было пользоваться незаметно: человек подтверждает себя свежим кодом приложения-аутентификатора, указывает причину, а все ответственные сразу получают оповещение. Каждое применение позже обязательно проверяет другой человек.

Как администратор включает аварийный доступ

Аварийный доступ настраивается в правиле «По запросу» (раздел Правила доступа), в двух полях:

Включить аварийный доступ можно только тогда, когда оповещение действительно дойдёт: если за последние сутки не доставил ни один канал (выгрузка в SIEM, почта или вебхук), шлюз отказывает: Cannot be switched on: no alarm channel (SIEM export, e-mail or webhook) has delivered in the last 24 hours. Set one up under System, send a test and try again. Сначала настройте каналы на странице Notifications. Расширение круга людей, серверов или учётных записей при включённом аварийном доступе требует свежего подтверждения личности.

Как человек пользуется аварийным доступом

Условия: вас отметили для этой пары «сервер — учётная запись», у вас подтверждено приложение-аутентификатор (TOTP; настраивается в профиле). Если приложения нет: Emergency access needs a confirmed authenticator app. Set one up in your profile first.

1. Откройте окно. На странице /access/requests, вкладка Available to request, нажмите красную кнопку Emergency access в строке нужной пары (в BURSUcm — кнопка Emergency access в окне запроса).
2. Прочтите предупреждение. This skips approval. You will be let in to … as … for … minutes. The use is recorded and must be reviewed afterwards. Use it only if the work cannot wait. Ниже сказано, кто будет оповещён: The moment you confirm, Approvers, Auditors and Administrators are told in the console, the emergency alarm recipients by e-mail or webhook, and the SIEM export records the event.
3. Заполните поля. Они перечислены ниже.
4. Подтвердите. Нажмите Use emergency access. При успехе: Emergency access granted until …. This use will be reviewed. Доступ действует с этого момента на срок, заданный правилом, и не продлевается.

Ограничения

• Не больше 2 применений на человека за 24 часа (в консоли это значение не меняется).
• Не больше одного действующего аварийного доступа на человека и сервер: You already have emergency access to this server account.
• Неверные коды считаются. Если учётная запись заблокирована из-за неверных кодов, форма сообщает о блокировке и времени, когда она закончится. Кроме того, на отправку формы аварийного доступа действует предел 10 попыток в минуту на человека (ответ HTTP 429).
• Применение не отклоняется из-за того, что каналы оповещения молчат: событие всё равно записывается, а в журнале сохраняется, был ли канал живым.
• Лицензия проверяется, как и для обычного запроса.

Если применение отклонено, форма возвращается с сообщением, а поле кода очищается. Возможные сообщения: Emergency access is not available to you for this server account., Emergency access needs a confirmed authenticator app. Set one up in your profile first., Write a reason of at least 20 characters., Enter the six-digit code from your authenticator app., The code is wrong or was already used., You already have emergency access to this server account., The limit of emergency accesses is reached. Contact the administrator.

Что видят все во время и после

• Человек. В консоли на каждой странице виден баннер Emergency access is active until …. This use is recorded and will be reviewed. В SSH-сессии, которая держится только на аварийном доступе, в терминале строка Emergency access: this use is recorded, the responsible people have been told, and it will be reviewed. Перед концом он получает такое же предупреждение, как и при обычном доступе; в BURSUcm оно звучит Your emergency access to … as … ends at …. It cannot be extended. Продлить аварийный доступ нельзя; кнопки Extend у него нет, есть только Release access.
• Согласующие, аудиторы и администраторы. В колокольчике появляется красный пункт Emergency access used and not yet reviewed: …; администратор дополнительно видит Emergency access reviews overdue: ….
• Адресаты аварийной тревоги (список на странице Notifications) получают письмо Emergency access was used: request #… и вебхук.
• SIEM. Применение попадает в выгрузку как отдельное событие.
• Команды. Для сессий, которые держатся только на аварийном доступе, автоматически действует встроенная политика Break-glass audit (built in): шлюз записывает каждую строку, которую удаётся прочесть. Её нельзя изменить или удалить. Пароли, набранные при запросе sudo, не сохраняются: ввод не записывается.

Проверка после применения

Каждое применение должно быть проверено в срок, который задан настройкой (по умолчанию 72 часа; изменить значение в консоли пока нельзя). Проверять вправе включённый Approver или Auditor, который не является тем, кто пользовался доступом. Один администратор проверять не может.

Страница /audit/breakglass (меню Audit → Emergency access) доступна ролям Administrator, Auditor и Approver. Три вкладки:

• Waiting for review — применения без проверки;
• All uses — все применения (по 30 на странице);
• Command list — строки команд, прочитанные шлюзом в сессиях выбранного применения.

Столбцы таблицы: Person, Server and account, Reason, Ticket, Used, Sessions, Review. Состояние проверки: Waiting for review (Review due by …), Overdue (Review overdue since …) или Reviewed (Reviewed by … on …). Ссылки Sessions и Command list видны только аудитору и администратору; согласующий видит текст команд только на этой странице. Пустая страница: Emergency access has not been used.

Кнопка проверки открывает окно Review this use:

Кнопка Close the review закрывает проверку: Review closed. Повторно закрыть нельзя (This use has already been reviewed.), свою проверку закрывать нельзя (You cannot review your own use.); тому, кто пользовался, страница сообщает: Another Approver or an Auditor reviews your use of emergency access; you cannot close the review. Проверка работает и при исчерпанной лицензии.

Уведомления

Страница /system/notifications (меню System → Settings → Notifications) — только для администратора. Здесь настраивается, как шлюз сообщает людям о запросах, решениях и аварийном доступе: электронной почтой и подписанным вебхуком. Отказ канала никогда не блокирует запрос: шлюз повторяет доставку и поднимает пункт в колокольчике.

Пароль почты и секрет вебхука только для записи: после сохранения они больше не показываются. Если значение сохранено, под полем написано A value is saved. Leave the field empty to keep it; type a new one to replace it.

Поля страницы

Проверка и состояние доставки

• Send a test e-mail отправляет пробное письмо на адрес вашей учётной записи (тема BURSU PAM test message). Тест использует уже сохранённые настройки: Save the settings first: the test uses the saved ones. Если у вашей учётной записи нет адреса: Your account has no e-mail address. Add one in your profile first.
• Send a test webhook отправляет пробное сообщение на сохранённый адрес.
• Результат: The test message was sent. или The test message was not sent: … с причиной (список причин — в главе «Неисправности»). Пока лицензия не позволяет менять настройки, тесты отклоняются.
• Карточка Delivery показывает по каналам E-mail, Webhook и SIEM export состояние и время Last delivered (Never, если ещё не доставляли; not set up, если канал не настроен).

Какие события и кому

Каждый адресат получает письмо на своём языке (язык его учётной записи), а если он не задан — на языке шлюза по умолчанию. В письме нет кнопки «одобрить»: оно ведёт в консоль и сообщает, что решать можно только после входа.

Вебхук получает каждое событие в виде JSON с полями id, event, at; если событие относится к запросу, добавляются request, state, requester, server, account, period и reason (длинная причина обрезается). Заголовки: X-Bursu-Timestamp (время в секундах Unix) и X-Bursu-Signature: v1=…, где значение — HMAC-SHA256 от строки «время, точка, тело» с вашим секретом. Принимающая сторона должна проверять подпись и отвергать старые сообщения. User-Agent — BURSU-PAM-webhook/1.

Доставка. Сообщения лежат в постоянной очереди и отправляются повторно при сбое: до 20 попыток с паузами от 1 секунды до 5 минут. Ожидание почтового сервера — 60 секунд, вебхука — 10.

Колокольчик

Пункты, связанные с этим разделом: Notifications are failing: … (канал не доставляет), No push channel (SIEM, e-mail, webhook) has delivered in the last 24 hours, so an alarm could go unheard. (тревога может остаться неуслышанной), Emergency access used and not yet reviewed: …, Emergency access reviews overdue: …. Обычный путь: открыть страницу Notifications, посмотреть карточку Delivery, отправить тест.

Контроль команд

Контроль команд — это защитный барьер и журнал для людей, которые работают на серверах через шлюз. Шлюз читает строки, которые человек вводит в терминале, и по правилам (политикам) разрешает, помечает, задерживает до подтверждения второго человека, отклоняет строку или закрывает сессию.

Где что работает

Пока действует политика, на сервер передаются только переменные окружения LANG, LC_* и TZ; остальные отбрасываются. Оболочка без терминала (ssh -T) отклоняется: нечего читать. Исключение — сессия, которая держится только на аварийном доступе: там работает лишь встроенная политика Break-glass audit (built in), и терминал не обязателен.

Страница «Command control»

Адрес /commands, меню Access → Command control. Страницу видят Administrator и Auditor; аудитор только читает, администратор изменяет. Сверху — пояснение, ссылка What command control cannot stop и счётчик Commands waiting for confirmation: …. Четыре вкладки: Policies, Pattern groups, Tester, Starter packs.

Как устроено: группы шаблонов и политики

1. Группа шаблонов (Pattern group) отвечает на вопрос «что искать»: набор шаблонов, например все варианты команды удаления.
2. Политика (Policy) отвечает на вопрос «что делать»: к кому и к каким серверам она относится и в каком порядке перечислены её записи (запись = группа шаблонов + действие). Первая подошедшая запись решает.
3. На одного человека на одном сервере может действовать несколько политик. Каждая судит отдельно, побеждает наиболее строгий результат. Добавленная позже политика может только ужесточить.

Группы шаблонов

Вкладка Pattern groups: столбцы Group, Patterns, Syntax, Used by; кнопка New group. Пустой список: No pattern groups yet.

Ссылка Try it in the tester открывает проверку. Группу, которую использует политика, удалить нельзя (A policy uses this group. Take it out of the policy first.).

Политики

Адреса: /commands/policies/new (создание), /commands/policies/{номер} (карточка), /commands/policies/{номер}/edit (правка). В карточке — Edit, переключатель включения (Enable / Disable), Delete и блок What this affects now (какие серверы и люди сейчас попадают под политику). Встроенную политику Break-glass audit (built in) изменить, выключить или удалить нельзя.

Действия записи:

При выключении политики шлюз спрашивает Switch this policy off? The commands it checks run unchecked from the next moment., при удалении — Delete this policy? Its past events stay in the audit log.

Проверка строки

Вкладка Tester (Try a command line) показывает, как шлюз прочтёт строку. Ничего не запускается и ни одна сессия не затрагивается: Nothing is run and no session is touched.

Кнопка Check the line показывает: Words (слова), Simple commands (простые команды), Without wrappers (sudo, env, nice and the like), Matching entry, Result. Возможные итоги: No entry matches., Nothing matched, so the line would run., Nothing matched, and an allow-list policy refuses what it does not list., The gateway cannot see what this line runs: …, The line is unfinished (…), This line cannot be shown safely to a confirmer, so it could not be confirmed. Лимит — 30 проверок в минуту на человека, иначе Too many checks in a minute. Wait a moment.

Готовые наборы

Вкладка Starter packs содержит 19 заготовок, сгруппированных по семействам: Linux (6), Cisco (3), Huawei (3), MikroTik (3), разовые команды (1) и базы данных (3). Каждая указывает, на что опирается (Relies on …). Кнопка Make a policy создаёт политику выключенной: Policy … was created disabled. Review it before you switch it on. Проверьте записи, задайте область и включите. Набора Allow-list для интерактивных оболочек нет: он ломает приглашения и программы.

Что видит пользователь в терминале

Шлюз пишет простым текстом в отдельной строке, без префикса, на языке шлюза по умолчанию (у SSH-сессии нет своего языка).

Нажатый и удержанный Enter не вызывает тайм-аут сессии: пока идёт проверка, сессия считается активной. Клавиши, набранные во время задержки, ставятся в очередь (до 4 КиБ) и проверяются по очереди после решения; если строку отклонили, очередь сбрасывается.

Подтверждение вторым человеком

Ждать подтверждения придётся не дольше значения Wait for a command confirmation, seconds (по умолчанию 120 секунд; задаётся на странице Notifications). Ожидание — это отказ. Подтверждающий видит команду на вкладке Commands страницы Approvals, см. Подтверждение команд. Если нет ни одного подходящего подтверждающего, команда отклоняется сразу: No second person is available to confirm this command, so it was not run. Одновременно может ждать подтверждения не больше одной команды сессии, трёх команд одного человека и пятидесяти на весь шлюз; сверх этого строка не выполняется и шлюз пишет Too many commands are waiting for confirmation on this gateway; this one was not run. Try again shortly.

Контроль команд и клиенты

BURSUcm (Windows и Universal) на сервере с контролем команд выключает свой tmux для этого подключения и не отправляет в оболочку строк интеграции. Из-за этого не работают переход панели «Files» вслед за каталогом оболочки и пометки команд у ИИ-помощника. На вкладке терминала появляется значок Command control is on с подсказкой: Command control is on: the gateway checks the commands typed on this server, and tmux is off for this connection. This app types nothing into the shell here, so Files does not follow the shell's folder and the AI assistant has no command marks.

Чего контроль не видит

• Интерпретаторы: python -c, perl -e, awk, vi :! выполняют команды, которых строка не показывает.
• Программы с выходом в оболочку: less, man, find -exec, git.
• Псевдонимы и функции, заданные раньше в сессии или в файле запуска оболочки.
• Приёмы с переменными и кавычками (команда в $x), раскрытие истории (!!), скрипт, загруженный по SFTP и запущенный.
• ssh дальше с целевого сервера на другой; stty -echo и переназначение клавиш (bind, bindkey, zle): шлюз замечает частые случаи, но не все.
• Программы, читающие команды со своего ввода (psql, mysql, sqlite3, gdb, expect, vim -es) и ввод в полноэкранных программах, редакторах и приглашениях пароля. Такие строки считаются «нечитаемыми» и учитываются.

Что шлюз записывает: прочитанная строка, совпавшая с политикой (или любая строка, если включена запись всех), попадает в список команд сессии с маскировкой паролей и ключей (маскировка не гарантирована) и удаляется вместе с записью. Журнал аудита текст команды не содержит — только отпечаток, политику и результат. Читают текст команд Auditor и Administrator; Approver — только то, что ему прислали на подтверждение, и проверки аварийного доступа.

Роль «Approver»

Роль Approver («согласующий») назначается человеку в разделе Users (или приходит из группы каталога). Согласующий не настраивает шлюз, а принимает решения: по запросам доступа, по задержанным командам и по проверкам аварийного доступа. Роль не даёт доступа к серверам сама по себе.

Несовместимость с администратором

Один и тот же человек не может быть одновременно Administrator и Approver: нельзя одобрять доступ и в то же время писать правила, по которым он выдаётся. При назначении формы выдаёт Approver and Administrator exclude each other: nobody approves requests while managing the rules. Choose one of the two. и, при записи, A person cannot be both an Administrator and an Approver. Если человек получает обе роли из групп каталога, то побеждает Administrator, роль Approver отклоняется и выводится в оповещениях (Directory roles refused (Administrator wins over Approver): …).

Администратору, которому нужно согласовывать, нужна отдельная учётная запись с ролью Approver.

Что видит и что может согласующий

Чего согласующий не видит: страниц настройки (серверы, учётные записи, правила, пользователи, система), журнала аудита, записей сессий, команд вне подтверждения. Чужие запросы, к которым он не допущен, он не видит вовсе.

Рабочий день согласующего

1. Войдите в консоль. В меню Access есть пункт Approvals с числом ожидающих запросов на значке. Колокольчик напоминает о запросах и о командах, ждущих подтверждения.
2. Подтвердите личность. Для разрешения (одобрения запроса или команды) нужно подтверждение, действует 10 минут. Подтвердите заранее, особенно если дежурите на командах: ждущая команда не останавливается ради вас.
3. Разберите «Waiting for me». Для каждого запроса прочтите причину, номер заявки, срок и посмотрите, что человек уже запрашивал и делал на этом сервере. Одобряйте, при необходимости с меньшим сроком, либо откажите с комментарием.
4. Следите за вкладкой «Commands», если вы подтверждающий политики. Решите, сверяясь с карточкой; помните, что вы подтверждаете текст, а не программу.
5. Проверьте «Active grants», если нужно досрочно отозвать доступ (человек закончил работу, подозрения, ошибка в запросе).
6. Проверьте применения аварийного доступа на странице Emergency access и закройте проверку с вердиктом и заметкой. Свои собственные применения вы закрыть не можете.

Обзор: состояние шлюза

Страница Overview (адрес /overview) — первое, что видят администратор и аудитор после входа. Она отвечает на два вопроса: «всё ли в порядке со шлюзом» и «что происходило последнее время». Страница ничего не меняет, она только показывает. Её видят роли Administrator и Auditor; пользователю с одной ролью User и согласующему (Approver) эта страница недоступна.

На все чтения страницы вместе отведено не больше пяти секунд, а каждое значение читается отдельно. Если какое-то значение прочитать не удалось или оно не успело прочитаться (например, база данных не ответила), вместо числа стоит прочерк «—» или слово unknown, а остальная страница работает как обычно. Прочерк — не ошибка шлюза, а сообщение «не удалось узнать»; через минуту обновите страницу.

Блок «Where to start»

Блок виден только администратору и только пока хотя бы один шаг не выполнен. Он перечисляет четыре шага до первого подключения: Add a server, Add a server account, Create a user, Create an access rule. Выполненный шаг отмечается галочкой сам; у невыполненного есть кнопка Open, которая ведёт на страницу создания. Счётчик справа показывает «{число выполненных} of 4». Когда все четыре шага выполнены, блок исчезает. Шаг «создать пользователя» считается выполненным, только когда есть включённый пользователь с ролью User: администратор, аудитор и отключённые учётные записи не считаются.

Карточки с числами

График входов и последние события

График Console sign-ins («Successful sign-ins and refusals per day») показывает по дням число успешных входов (Successful) и отказов (Refused) в веб-консоль. Переключатель Period — Week (7 дней, по умолчанию) или Month (30 дней). Дни считаются по часовому поясу отображения, заданному в gateway.json (displayTimeZone, см. gateway.json).

Блок Latest events — десять последних событий журнала аудита. Заголовок события — ссылка на его карточку. Кнопка Audit log открывает полный журнал.

Блок Health: что значит каждая плашка

Блок Health («Checked when the page opens (at most every 30 s)») — это самопроверка шлюза. Состояние читается при открытии страницы и не чаще чем раз в 30 секунд, поэтому после исправления неполадки плашка может позеленеть не сразу. У каждой плашки справа стоит слово состояния: fine (зелёное, в порядке), attention (жёлтое, нужно присмотреться), problem (красное, нужно действовать), off (серое, функция выключена). Слово — ссылка на страницу, где неполадку исправляют, если у вас есть право её открыть. Аудитор видит плашки, но ссылки на страницы настроек для него не работают (настройки доступны только администратору).

Всегда показываются шесть плашек:

Остальные плашки появляются, только когда соответствующая функция настроена:

Колокольчик «Alerts»

В верхней панели каждой страницы есть колокольчик Alerts. В нём собраны только текущие проблемы: все жёлтые и красные плашки блока Health плюс ещё несколько сообщений, которых в блоке Health нет. Если проблем нет, написано No current problems. Сообщения видят и администратор, и аудитор; ссылку на страницу исправления получает только тот, кто вправе её открыть.

Сессии: списки, наблюдение, завершение

Раздел Sessions группы Audit бокового меню отвечает на вопросы «кто сейчас работает на серверах» и «кто и когда работал раньше». Страницы раздела видят Administrator и Auditor. Согласующий (Approver) и обычный пользователь их не открывают. Аудитор может смотреть, искать, воспроизводить записи и завершать сессии, но ничего не настраивает (раздел «Аудитор»).

Как устроен раздел

В боковом меню у раздела один пункт — Sessions — для всех протоколов. Отдельных пунктов для SSH, RDP, VNC и баз данных нет. На каждой странице раздела заголовок один и тот же — Sessions, а под ним полоса из пяти вкладок: