Кабинет владельца парка
Выдаёт подрядчикам сертификаты организаций с рамками: группы устройств, роли, потолок уровня и срока.
Tessera Access · вход по сертификатам
Персонализированный и подотчётный вход инженеров и подрядчиков на любые устройства под Astra Linux и другими Linux: от операторских АРМ и банкоматов до POS-терминалов и промышленных контроллеров. Все права — внутри сертификата, вся проверка — на самом устройстве. Сеть в момент доступа не нужна вообще.
01 · Как работает
Администратор задаёт, под какими ролями инженер может войти и на какое устройство или группу устройств. Удостоверяющий центр (УЦ) выпускает короткоживущий сертификат с этими правами внутри — на флешку под PIN.
Инженер вставляет флешку, вводит PIN и выбирает роль. PAM-модуль на устройстве сам проводит аутентификацию по сертификату и открывает сессию — без единого запроса в сеть.
Открывается ровно под запрошенной ролью — минимум прав (least privilege), даже если сертификат разрешает больше. Личность инженера зафиксирована в удостоверении.
Вынул флешку — сессия завершается. Система следит за носителем: нет носителя — нет сессии.
Администратор отзывает доступ через список отзыва (CRL) — можно завершить и уже открытые сессии или закрыть вход на устройство целиком. Если список до устройства не доехал, сертификат всё равно истечёт сам: часы или смена, не месяцы.
Пять вопросов, на которые устройство отвечает само
ни одного запроса в сеть
02 · Делегирование
Владелец парка выдаёт обслуживающей организации сертификат с жёсткими рамками. Организация выдаёт инженеру ещё более узкий сертификат смены. Выйти за рамки невозможно.
Банк, промпредприятие, КИИ-субъект. Корень доверия — только он решает, кому и что можно.
права: весь паркправа сужены до рамок подрядчика
Подрядчик. Сам выдаёт удостоверения своим инженерам — но только внутри полученных рамок.
права: регион · 1 рольправа сужены до одной смены
Приезжает на объект с сертификатом на флешке или токене. Сеть ему не нужна.
права: 1 устройство · 8 чleast privilege на входе
Любое устройство под Linux / Astra Linux. Проверяет подписи, рамки, срок и отзыв — без единого обращения в сеть.
офлайн-проверкаГарантия — на самом устройстве. Даже если центр выдачи подрядчика скомпрометирован, он не выпустит рабочий сертификат за пределами своих рамок: южный банкомат отвергнет сертификат «северного» подрядчика сам, офлайн, по собственным подписанным данным.
03 · Выпуск сертификатов
Никакой ручной криптографии и внешнего удостоверяющего центра: диспетчер выпускает сертификат в веб-кабинете, система сама держит его в рамках.
Выдаёт подрядчикам сертификаты организаций с рамками: группы устройств, роли, потолок уровня и срока.
Диспетчер выпускает сертификаты смен своим инженерам под конкретный наряд — форма не даст выйти за рамки организации.
Запись на флешку или токен (Rutoken / JaCarta) на рабочем месте диспетчера; короткий срок жизни — потерянный носитель сам теряет силу.
Рядом с сертификатом кабинет кладёт свежий список отзыва, конфигурацию и обновления — устройство применит их при входе само, проверив подпись.
Кто, кому, на какое устройство и с какими правами выпустил — и кто какое обновление привёз. Для интеграций в планах — CLI и API.
04 · Механизмы
Вход через штатный PAM-стек Linux. Аппаратные токены Rutoken или JaCarta с ГОСТ — или PIN-контейнер на флешке. Стандартные форматы, никакой привязки к вендору (vendor lock-in).
Удостоверение привязано к конкретному устройству. Украденная флешка бесполезна на соседнем банкомате — Engine откажет локально.
TTL — часы или смена. Даже без связи с центром доступ истекает сам: время работает на защиту, а не на атакующего.
Роль из удостоверения превращается в ограничения ОС: Astra МКЦ, группы, sudoers, systemd-лимиты. Не «доступ вообще», а ровно нужный уровень.
Отзыв вечен: монотонный crlNumber защищает от подмены списка старым. Живые сессии отзываются, устройство уходит в карантин.
Журнал на устройстве — hash-chain: каждая запись сшита с предыдущей, подчистка обнаруживается. Для изолированных сетей (air-gapped) — экспорт курьерским носителем.
Промежуточные центры выдачи (CA) для филиалов и подрядчиков получают рамки (name constraints), которые устройство проверяет офлайн. Делегат не выйдет за границы.
КриптоПро CSP и Rutoken — сертифицированные СКЗИ. Первая целевая платформа — Astra Linux SE.
Есть связь с сервером — агент синхронизации сам подтягивает роли и список отзыва (только скачивает, наружу ничего не отдаёт). Перебои сети влияют только на актуальность ролей и списков отзыва — модель безопасности не меняется.
05 · Эксплуатация
Парк — хоть десятки тысяч устройств: доставка подписанными файлами любым каналом, вход никогда не ждёт сеть.
Роли, политики, отзыв (CRL) и инвентарь всего парка — в одном Tessera Control; администратор ≠ аудитор. Начать можно и без сервера: роли и ключи — в образ устройства.
Tessera Control · standalone тоже можно
Уровень прав = уровень МКЦ (мандатного контроля целостности): сессия открывается с точной меткой, проверка — битовая. Подписанные компоненты, штатная работа при включённой ЗПС (замкнутой программной среде), вход через родной экран fly-dm.
SE «Воронеж»+, МКЦ, ЗПС
Каждый вход, выход и отказ — событие в сцепленном журнале (hash-chain): подмена или вырезание видны. Выгрузка в Control при связности; для изолированных объектов — экспорт на носитель инженера.
tamper-evident · работает офлайн
Установка — пакет + файлы конфигурации; самопроверка готовности устройства (doctor). Ядро агента — открытый код: ваша служба ИБ видит, что именно работает на устройствах.
без БД · без демонов в пути входа
Сервер недоступен? Вход по действующим сертификатам продолжает работать, истёкшие — не продлеваются. При сомнении — не пускать (fail-closed), так задумано. Безопасность одинакова с сервером и без: сервер отвечает за управление парком и актуальность данных — не за безопасность входа.
Отказ серверного компонента не открывает дверь — и не запирает валидного инженера. Fail-open здесь нет.
06 · Сценарии
Флешка → выбор роли → вход без сети. Отзыв на серверной стороне — мгновенно; на офлайн-парке — по TTL, часы–смена.
Пример конфигурацииОператор смены входит под ролью oper, наладчик — под ролью
serv: каждый по личному удостоверению, права — по роли.
Tamper-evident журнал ведётся на самом устройстве; регулятору —
экспорт по USB.
Ролевые учётные записи на устройстве, вход по ГОСТ-токену.
issuance_id связывает выпуск → вход → действия → завершение
в одну доказуемую нить.
Сквозная корреляция по issuance_id
Журнал устройства — hash-chain
подчистка обнаруживается — разрыв цепи виден
Анкеры → Control
07 · Вопросы
Да, это основной сценарий: владелец парка и подрядчики выпускают сертификаты в собственных кабинетах, ключи хранятся в PKCS#11-токене или HSM. Внешний удостоверяющий центр не нужен, каждая выдача попадает в журнал.
Инженер вставляет носитель, вводит PIN и выбирает роль. PAM-модуль на самом АРМ проверяет подпись, срок, отзыв и привязку к устройству — и открывает сессию ровно с правами роли. Сеть в момент входа не нужна.
Нет. Вся проверка выполняется на самом устройстве: ни контроллера домена, ни бастиона, ни выхода в сеть. Изолированные (air-gapped) парки — штатный режим.
Linux с PAM: первая целевая платформа — Astra Linux SE (МКЦ, ЗПС), работает и на других дистрибутивах. Windows-адаптер — в планах.
Несколько устройств, ваши сценарии обслуживания, ваши подрядчики — и сравнение аудита «до / после».
или напишите: tessera@tessera-access.ru