Типовая конфигурация: терминалы

Этот раздел показывает, как Tessera разворачивается на парке терминалов и кто из инженеров что сможет делать на устройстве. Адресован инженерам сопровождения и специалистам по информационной безопасности заказчика: после прочтения видно, как устроен доступ, какие есть роли и границы прав ещё до пилота.

Конкретные значения (роли, сроки, группы) — пример одного безопасного профиля, а не единственно возможный. Полный справочник параметров — configuration.md; режимы входа — pam-integration.md; мандатный контроль на Astra — mac-integrity.md.

1. Картина развёртывания

Терминал — устройство без управляющей сети (zero-egress): в момент входа инженера обращение к серверу невозможно. Поэтому вся проверка доступа — локальная, на самом устройстве.

На терминале:

Tessera Engine — проверяет удостоверение и применяет права (enforcement; объём в v0.4.0 — см. врезку «Статус» ниже);
Tessera Login (PAM-модуль) — точка входа в ОС;
monitord — следит за носителем (извлекли флешку — сессия закрывается);
локальная база ролей в /var/lib/tessera/roles/;
корневой сертификат удостоверяющего центра в /etc/tessera/.

Инженер приносит удостоверение с собой — сертификат на USB-носителе под PIN или на аппаратном токене (Rutoken, JaCarta). Сервер (Tessera Control) при наличии связи доставляет обновления ролей и списков отзыва, но в момент входа не нужен.

2. Кто входит и под какой ролью

«Роль» в Tessera — именованный набор прав ОС, активируемый на сессию при входе. Людей называем по должности; роль — это про права, не про человека. Один инженер может входить под разными ролями, если они разрешены его удостоверением.

Типовой профиль терминального парка — три роли:

oper — оператор: повседневное обслуживание (замена расходников, просмотр журналов, перезагрузка). Минимум прав.
serv — сервисный инженер: наладка, диагностика, доступ к служебным командам через sudo, повышенные лимиты ресурсов.
admin — администратор (на Astra — с мандатным контролем целостности): высокий уровень доступа, короткий срок сессии.

3. Матрица «операция × роль»

Что каждая роль разрешает на терминале. «✓» — разрешено правами роли, «—» — недоступно. Прикладное ПО терминала (драйверы периферии, терминальное приложение, служба мониторинга) Tessera не заменяет: роль выдаёт сессии группы и sudo-правила, по которым ОС пускает инженера к этому ПО и его служебным операциям.

Статус в v0.4.0. Матрица описывает целевой профиль. Сегодня Tessera применяет к сессии личность, срок (TTL) и — на Astra, через коммерческий МКЦ-адаптер — маску целостности mac_mask. Группы, sudo-правила и лимиты определены форматом роли и валидируются, но к сессии пока не применяются: OS-enforcement для них в разработке (linux-session-enforcement).

Операция	`oper`	`serv`	`admin`
Вход на устройство по удостоверению	✓	✓	✓
Просмотр журналов и состояния	✓	✓	✓
Обслуживание периферии, расходники	✓	✓	✓
Перезагрузка устройства	✓	✓	✓
Доступ к служебным операциям прикладного ПО	—	✓	✓
Команды наладки через `sudo`	—	✓	✓
Изменение системной конфигурации	—	—	✓
Управление учётными правами на устройстве	—	—	✓
Отключение защитных рубежей (ЗПС, МКЦ, контроль запуска ПО)	—	—	—
Срок сессии (TTL)	8 ч	4 ч	2 ч

TTL — верхняя граница сессии: по истечении инженер входит заново. Чем выше права, тем короче сессия.

4. Что несёт удостоверение инженера

Сертификат — не просто пропуск «свой/чужой». В нём зашиты:

личность инженера — субъект сертификата; попадает в каждую запись журнала;
привязка к устройству (host-binding) — сертификат выписан на конкретный терминал; украденная флешка бесполезна на соседнем устройстве парка;
разрешённые роли — под какими ролями инженеру можно войти;
срок жизни (TTL) — часы или смена, не бессрочно.

Проверка всех четырёх — на устройстве, без сети.

5. Жизненный цикл сессии

Инженер входит в ролевую учётную запись (ssh oper@device или выбор учётной записи в экране входа) — этим и выбирается роль, — вставляет носитель и вводит PIN.
Engine проверяет локально: подпись сертификата по цепочке доверия → host-binding (это устройство) → срок → разрешена ли запрошенная роль.
При успехе открывается сессия на запрошенной роли по принципу наименьших привилегий — даже если сертификат разрешает больше.
monitord следит за носителем. Извлекли флешку — сессия завершается (для терминалов: немедленно).
По истечении TTL вход нужно повторить.

6. config.toml: безопасный профиль

Ключи приведены как в /etc/tessera/config.toml; полное описание каждого — в configuration.md. Принцип профиля — fail-closed: при сомнении доступ закрывается.

# Удостоверение в PKCS#12-контейнере на USB-носителе. Нативного мониторинга
# извлечения PKCS#11-токена пока нет, поэтому PKCS#11 не обеспечивает
# требуемую этим терминальным профилем немедленную реакцию на извлечение.
crypto_backend = "openssl"
mode = "pkcs12"
pkcs12_path_pattern = "certs/${user}.p12"

# Реакция на извлечение носителя. Для терминала — закрыть сессию сразу.
on_usb_removed = "logout"     # или "shutdown" — обесточить хост
usb_removed_grace_seconds = 0 # без отсрочки

# Отказ демона мониторинга трактуется как отказ в доступе.
monitor_fail_mode = "strict"

[trust]
# Корневой сертификат удостоверяющего центра. Минимум один.
anchors = ["/etc/tessera/ca/bundle.pem"]

[trust.revocation]
# "none"  — отзыв по сроку жизни сертификата (TTL-backstop);
# "crl"   — плюс локальный список отзыва, обновляемый при наличии связи.
mode = "crl"
crl_paths = ["/etc/tessera/crl/parkruntime.crl"]
crl_max_age_hours = 24

[host_identity]
# Источник идентичности устройства (machine-id, серийники DMI).
# fallback = "deny" — если идентичность не подтверждена, вход закрыт.
fallback = "deny"

Минимальные права файлов: корневой сертификат — 0640 root:root, каталог ролей /var/lib/tessera/roles/ — 0755 root:root, срезы ролей — 0644.

7. Вход: режим cert-only

Для терминалов рекомендуется режим cert-only — сертификат единственный фактор, без отхода на пароль. Потеря или блокировка токена означает полную недоступность входа — это осознанный выбор для необслуживаемого устройства (чек-лист перед раскаткой — operations.md).

PAM-сниппет (/etc/pam.d/tessera-only):

auth     [success=done default=die]  pam_tessera.so
account  required                    pam_tessera.so

Подключается скриптом, который ставит строки в правильном порядке и добавляет фазу сессии после common-session:

sudo /usr/share/tessera/integrate-pam.sh --mode=cert-only /etc/pam.d/login
sudo /usr/share/tessera/integrate-pam.sh --mode=cert-only /etc/pam.d/sudo

8. Роли в деталях

Роль — это файл-срез в каталоге базы ролей. База — для одной ОС: срезы Linux и Astra не смешивают в одном каталоге. Срезы проверяются перед раскаткой: tessera role lint --dir /var/lib/tessera/roles --os linux --on-device.

Флаг --on-device заявляет, что команда выполняется на том устройстве, которому принадлежит база. Только тогда линт сверяет имена срезов с местными учётными записями и ловит срез, названный именем системной УЗ (root.toml и подобные). Без флага эта сверка пропускается с пометкой в выводе: на рабочей станции она отвечала бы по чужим учётным записям — отвергала бы законный срез mail и пропускала бы системную УЗ, которая есть только на устройстве.

8.1. На ОС без мандатного контроля (Linux)

Целевая механика: права выдаются через стандартные механизмы ОС — дополнительные группы, sudo-роли, лимиты systemd на сессию. Группы Engine будет выставлять сам (не через pam_group), чтобы права нельзя было обойти через DBus или sudo.

Важно. Этот раздел описывает целевую механику. В v0.4.0 groups, sudo_role и limits разбираются и валидируются (tessera role lint), но к сессии не применяются — реализация ведётся в change linux-session-enforcement. Примеры ниже корректны как формат роли и заработают без изменений.

Оператор — минимальный профиль:

role = "oper"
version = 1
os = "linux"
name = "Operator"
level = 1

[payload]
groups = ["operators"]      # членство в группе на сессию

[session]
max_ttl_seconds = 28800     # 8 ч

Сервисный инженер — sudo и повышенные лимиты:

role = "serv"
version = 1
os = "linux"
name = "Service Engineer"
level = 5

[payload]
groups = ["service", "wheel"]
sudo_role = "service"       # правило sudoers, действующее в сессии

[payload.limits]
nofile = 4096               # лимит открытых файлов

[session]
max_ttl_seconds = 14400     # 4 ч
memory_max = "2G"           # systemd MemoryMax — жёсткий потолок памяти
tasks_max = 512             # systemd TasksMax

Доступ инженера к служебным операциям прикладного ПО терминала задаётся именно так: группа и sudo-правило в роли определяют, какие команды и службы устройства инженеру доступны. Где лежит и как устроено само прикладное ПО — определяет его поставщик; Tessera управляет только правами доступа к нему.

8.2. На Astra с мандатным контролем целостности (МКЦ)

На Astra Linux SE роль дополнительно несёт потолок уровня целостности (МКЦ). Сертификат инженера задаёт максимальный уровень, роль — битовую маску; эффективный уровень сессии = минимум из потолка сертификата и маски роли.

role = "admin"
version = 1
os = "astra"
name = "Administrator"
level = 63                  # отражает уровень МКЦ на Astra

[payload]
mac_mask = "0x3f"           # битовая маска МКЦ

[session]
max_ttl_seconds = 7200      # 2 ч

Важно. В открытой сборке Tessera маска mac_mask разбирается, но не применяется: адаптер enforcement через МКЦ — коммерческое расширение. На открытой сборке срез роли с mac_mask отклоняется в момент входа. Подробнее о механизме — mac-integrity.md.

9. Чего не может ни одна роль

Tessera управляет доступом: кто вошёл, под какой ролью, какие группы и sudo-правила действуют в сессии. Она не управляет защитными рубежами устройства и не выдаёт прав на их отключение. Эти рубежи — отдельный слой, действует независимо от того, кто и под какой ролью вошёл. Роль admin — высокие права в рамках ОС, но не «выключатель» защиты.

Независимые рубежи на терминале:

Замкнутая программная среда (ЗПС / DIGSIG на Astra) — ядро запускает только подписанные исполняемые файлы; неподписанный бинарь отвергается на execve/mmap. Запуск постороннего ПО невозможен независимо от роли. То же относится к иным модулям контроля запуска, если они установлены.
Мандатный контроль целостности (МКЦ) — механизм ядра PARSEC. Высокая маска целостности в роли задаёт уровень в рамках МКЦ, но не право отключить МКЦ.
Контроль целостности самой Tessera — бинарники Engine и PAM-модуля подписаны и охраняются ЗПС; инженер с ролью admin не может подменить их или конфигурацию, обойдя проверку.

Ключевой принцип безопасного профиля: роль не должна нести sudo-правил, позволяющих перевести ЗПС или МКЦ в режим без enforcement, остановить их службы или подменить ключи подписи. Переключение этих подсистем — не рядовая операция инженера, а изменение доверенного состояния устройства; оно выполняется вне обычного входа и по отдельному регламенту. Tessera здесь — не последний рубеж, а слой доступа поверх уже неизменяемой среды.

10. Отзыв и срок жизни

Доступ инженера прекращается двумя путями:

По команде (нужна связь с устройством): список отзыва (CRL) и завершение живых сессий, карантин устройства. Доходит до терминала при очередном обмене с сервером.
По сроку (работает всегда, без сети): сертификат протухает по TTL — часы или смена. Это backstop: даже на полностью изолированном терминале отозванный инженер теряет доступ после истечения срока.

Профиль с mode = "crl" сочетает оба: при связи список отзыва свежий, без связи держит TTL. На парке без связи допустим mode = "none" с опорой только на TTL.

11. Что происходит при сбоях

Событие	Поведение
Инженер вынул флешку	Сессия завершается (по профилю — сразу)
Истёк TTL сессии	Требуется повторный вход
Сервер недоступен	Вход по действующим сертификатам работает; истёкшие не продлеваются
Отзыв не доставлен (нет связи)	Сертификат всё равно протухнет по TTL
Демон мониторинга отказал	`monitor_fail_mode = "strict"` → вход закрывается
Идентичность устройства не подтверждена	`fallback = "deny"` → вход закрывается

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

12. Чек-лист безопасной раскатки

13. Дальше

configuration.md — полный справочник config.toml.
pam-integration.md — режимы входа и интеграция в PAM.
cert-issuance.md — выпуск удостоверений и расширения сертификата.
mac-integrity.md — мандатный контроль целостности на Astra.
operations.md — эксплуатация, чек-лист перед раскаткой.