Tessera Access · вход по сертификатам

Офлайн-вход по сертификатам с управляемым делегированием

Персонализированный и подотчётный вход инженеров и подрядчиков на любые устройства под Astra Linux и другими Linux: от операторских АРМ и банкоматов до POS-терминалов и промышленных контроллеров. Все права — внутри сертификата, вся проверка — на самом устройстве. Сеть в момент доступа не нужна вообще.

Офлайн устройство само проверяет сертификат, срок, отзыв и рамки — без сети
Личность каждый вход привязан к конкретному инженеру — даже входы подрядчиков
В эксплуатации уже в промышленной эксплуатации в банкоматных сетях
Разработано в России Astra Linux SE: МКЦ и ЗПС ГОСТ · Rutoken / JaCarta PAM-модуль с открытым ядром Windows — в планах

01 · Как работает

Пять шагов — от политики до отзыва

  1. Выпуск

    Администратор задаёт, под какими ролями инженер может войти и на какое устройство или группу устройств. Удостоверяющий центр (УЦ) выпускает короткоживущий сертификат с этими правами внутри — на флешку под PIN.

  2. Вход

    Инженер вставляет флешку, вводит PIN и выбирает роль. PAM-модуль на устройстве сам проводит аутентификацию по сертификату и открывает сессию — без единого запроса в сеть.

  3. Сессия

    Открывается ровно под запрошенной ролью — минимум прав (least privilege), даже если сертификат разрешает больше. Личность инженера зафиксирована в удостоверении.

  4. Носитель под контролем

    Вынул флешку — сессия завершается. Система следит за носителем: нет носителя — нет сессии.

  5. Отзыв

    Администратор отзывает доступ через список отзыва (CRL) — можно завершить и уже открытые сессии или закрыть вход на устройство целиком. Если список до устройства не доехал, сертификат всё равно истечёт сам: часы или смена, не месяцы.

Пять вопросов, на которые устройство отвечает само

  • Пропуск настоящий? — подпись удостоверяющего центра
  • Выписан именно для этого устройства? — привязка записана в сертификате
  • Ещё действует? — срок не истёк и доступ не отозван
  • Роль разрешает запрошенный уровень?
  • Входящий владеет ключом? — устройство требует подпись, а не просто показать сертификат

ни одного запроса в сеть

fig. 1 — вход по сертификату: все проверки на самом устройстве

02 · Делегирование

Делегирование: каждое звено может только сузить права

Владелец парка выдаёт обслуживающей организации сертификат с жёсткими рамками. Организация выдаёт инженеру ещё более узкий сертификат смены. Выйти за рамки невозможно.

Владелец парка

Банк, промпредприятие, КИИ-субъект. Корень доверия — только он решает, кому и что можно.

права: весь парк

Сертификат организации

  • устройства: только регион «Север»
  • роли: только «обслуживание»
  • срок выдаваемых: ≤ 30 дней

права сужены до рамок подрядчика

Обслуживающая организация

Подрядчик. Сам выдаёт удостоверения своим инженерам — но только внутри полученных рамок.

права: регион · 1 роль

Сертификат смены инженера

  • устройство: только ATM-0042
  • роль: «обслуживание»
  • срок действия: 8 часов

права сужены до одной смены

Инженер

Приезжает на объект с сертификатом на флешке или токене. Сеть ему не нужна.

права: 1 устройство · 8 ч

least privilege на входе

Устройство

Любое устройство под Linux / Astra Linux. Проверяет подписи, рамки, срок и отзыв — без единого обращения в сеть.

офлайн-проверка

Гарантия — на самом устройстве. Даже если центр выдачи подрядчика скомпрометирован, он не выпустит рабочий сертификат за пределами своих рамок: южный банкомат отвергнет сертификат «северного» подрядчика сам, офлайн, по собственным подписанным данным.

Как устроена модель: состав удостоверения, порядок проверок на устройстве, процессы выпуска, отзыв прав и меры ГОСТ Р 57580. Подробнее →

03 · Выпуск сертификатов

Выпуск собственных сертификатов — за минуту, из своего кабинета

Никакой ручной криптографии и внешнего удостоверяющего центра: диспетчер выпускает сертификат в веб-кабинете, система сама держит его в рамках.

Кабинет владельца парка

Выдаёт подрядчикам сертификаты организаций с рамками: группы устройств, роли, потолок уровня и срока.

Кабинет обслуживающей организации

Диспетчер выпускает сертификаты смен своим инженерам под конкретный наряд — форма не даст выйти за рамки организации.

Сразу на носитель

Запись на флешку или токен (Rutoken / JaCarta) на рабочем месте диспетчера; короткий срок жизни — потерянный носитель сам теряет силу.

Инженер довозит обновления

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

Каждая выдача — в журнале

Кто, кому, на какое устройство и с какими правами выпустил — и кто какое обновление привёз. Для интеграций в планах — CLI и API.

04 · Механизмы

Каждое свойство — механизм, не обещание

Криптография

X.509, PKCS#11 и PAM

Вход через штатный PAM-стек Linux. Аппаратные токены Rutoken или JaCarta с ГОСТ — или PIN-контейнер на флешке. Стандартные форматы, никакой привязки к вендору (vendor lock-in).

Устройство

Host-binding

Удостоверение привязано к конкретному устройству. Украденная флешка бесполезна на соседнем банкомате — Engine откажет локально.

Время

Короткоживущие удостоверения

TTL — часы или смена. Даже без связи с центром доступ истекает сам: время работает на защиту, а не на атакующего.

Права

Роли и применение прав (enforcement)

Роль из удостоверения превращается в ограничения ОС: Astra МКЦ, группы, sudoers, systemd-лимиты. Не «доступ вообще», а ровно нужный уровень.

Отзыв

CRL и отзыв

Отзыв вечен: монотонный crlNumber защищает от подмены списка старым. Живые сессии отзываются, устройство уходит в карантин.

Аудит

Аудит с защитой от подделки (tamper-evident)

Журнал на устройстве — hash-chain: каждая запись сшита с предыдущей, подчистка обнаруживается. Для изолированных сетей (air-gapped) — экспорт курьерским носителем.

Масштаб

Делегирование выпуска

Промежуточные центры выдачи (CA) для филиалов и подрядчиков получают рамки (name constraints), которые устройство проверяет офлайн. Делегат не выйдет за границы.

Регуляторика

ГОСТ и сертификация

КриптоПро CSP и Rutoken — сертифицированные СКЗИ. Первая целевая платформа — Astra Linux SE.

Сеть

Гибридные парки

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

05 · Эксплуатация

Управляется из одного центра, живёт без него

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

Централизованное управление

Роли, политики, отзыв (CRL) и инвентарь всего парка — в одном Tessera Control; администратор ≠ аудитор. Начать можно и без сервера: роли и ключи — в образ устройства.

Tessera Control · standalone тоже можно

Astra Linux — родная платформа

Уровень прав = уровень МКЦ (мандатного контроля целостности): сессия открывается с точной меткой, проверка — битовая. Подписанные компоненты, штатная работа при включённой ЗПС (замкнутой программной среде), вход через родной экран fly-dm.

SE «Воронеж»+, МКЦ, ЗПС

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

Каждый вход, выход и отказ — событие в сцепленном журнале (hash-chain): подмена или вырезание видны. Выгрузка в Control при связности; для изолированных объектов — экспорт на носитель инженера.

tamper-evident · работает офлайн

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

Установка — пакет + файлы конфигурации; самопроверка готовности устройства (doctor). Ядро агента — открытый код: ваша служба ИБ видит, что именно работает на устройствах.

без БД · без демонов в пути входа

Отказ компонента — не дыра

Сервер недоступен? Вход по действующим сертификатам продолжает работать, истёкшие — не продлеваются. При сомнении — не пускать (fail-closed), так задумано. Безопасность одинакова с сервером и без: сервер отвечает за управление парком и актуальность данных — не за безопасность входа.

Codes недоступенсервер одноразовых кодов
теряемвыдача новых QR-кодов
работаетвход по серту · enforcement · аудит · TTL-отзыв — всё остальное
Control недоступенпульт управления парком
теряемактуальность CRL и ролей · команды · сводная картина парка
работаетвход · enforcement · журнал в локальный буфер (at-least-once) · TTL-backstop
Без сети месяцамиzero-egress парк
теряемонлайн-доставку (остаётся выкатка или курьер)
работаетвсё — это штатный режим, не аварийный
Атака на каналsync-доставка
теряеммаксимум — DoS доставки
работаеттранспорт не доверен: подпись + anti-rollback; возврат в офлайн-модель, не в ослабленную

Отказ серверного компонента не открывает дверь — и не запирает валидного инженера. Fail-open здесь нет.

fig. 2 — деградация: что отключилось → что продолжает работать
Нужен вход без токенов, по телефону инженера? Это Tessera Codes — включается на том же агенте, без переустановки. Подробнее → Ролевые учётные записи, группы и sudoers на этих устройствах декларативно готовит Census — открытый продукт той же платформы. Подробнее →

06 · Сценарии

Где это уже нужно

Банкоматы · zero-egress

Парк без единого исходящего соединения

Флешка → выбор роли → вход без сети. Отзыв на серверной стороне — мгновенно; на офлайн-парке — по TTL, часы–смена.

Пример конфигурации
ОПК · ЧПУ

Изолированный цех

Оператор смены входит под ролью oper, наладчик — под ролью serv: каждый по личному удостоверению, права — по роли. Tamper-evident журнал ведётся на самом устройстве; регулятору — экспорт по USB.

КИИ · ГОСТ

Регулируемые среды

Ролевые учётные записи на устройстве, вход по ГОСТ-токену. issuance_id связывает выпуск → вход → действия → завершение в одну доказуемую нить.

Сквозная корреляция по issuance_id

Выдачакто разрешил, проверки
Удостоверениекод или сертификат
Сессияopen · действия · close
Завершениетриггер

Журнал устройства — hash-chain

seq nhash(prev)
seq n+1hash(prev)
вырезаноцепь рвётся
seq n+3hash(prev)

подчистка обнаруживается — разрыв цепи виден

Анкеры → Control

  • сверка анкеров (device_id, seq, hash)
  • несостыковка → security-алерт
  • молчание дольше нормы → gap-алерт
  • air-gapped: журнал едет курьерским носителем, анкеры сверяются так же
fig. 3 — аудит: одна нить корреляции, неразрывная цепь журнала

07 · Вопросы

Частые вопросы

Можно ли выпускать собственные сертификаты для входа на АРМ?

Да, это основной сценарий: владелец парка и подрядчики выпускают сертификаты в собственных кабинетах, ключи хранятся в PKCS#11-токене или HSM. Внешний удостоверяющий центр не нужен, каждая выдача попадает в журнал.

Как проходит авторизация на АРМ по сертификату?

Инженер вставляет носитель, вводит PIN и выбирает роль. PAM-модуль на самом АРМ проверяет подпись, срок, отзыв и привязку к устройству — и открывает сессию ровно с правами роли. Сеть в момент входа не нужна.

Нужен ли домен или контроллер?

Нет. Вся проверка выполняется на самом устройстве: ни контроллера домена, ни бастиона, ни выхода в сеть. Изолированные (air-gapped) парки — штатный режим.

Какие системы поддерживаются?

Linux с PAM: первая целевая платформа — Astra Linux SE (МКЦ, ЗПС), работает и на других дистрибутивах. Windows-адаптер — в планах.

Следующий шаг — пилот на вашем парке

Несколько устройств, ваши сценарии обслуживания, ваши подрядчики — и сравнение аудита «до / после».

или напишите: tessera@tessera-access.ru