Модель безопасности

Документ ведётся с первого коммита: приказ ФСТЭК России № 76 требует модель безопасности, архитектуру безопасности и функциональную спецификацию как часть процесса разработки. Реконструировать их по готовому продукту дороже, чем поддерживать по ходу.

1. Защищаемые активы

Актив	Где находится	Чем грозит компрометация
Пароли пользователей каталога	только в службе каталога	захват учётной записи
Одноразовые коды подтверждения	оперативная память, в виде хэша	обход второго фактора
Секреты TOTP	хранилище секретов инсталляции (файл 0600, запись через переименование)	обход второго фактора
Учётные данные привилегированного подключения к каталогу	конфигурация	сброс пароля любому сотруднику
Журнал событий безопасности	файл журнала	сокрытие следов атаки
Персональные данные (ФИО, телефон, адрес почты)	каталог, журнал в маскированном виде	нарушение 152-ФЗ

Продукт не хранит пароли ни в каком виде — ни открытым текстом, ни хэшем. Это осознанное архитектурное ограничение: единственным источником и хранилищем пароля остаётся служба каталога.

2. Модель нарушителя

Нарушитель	Возможности	Основной сценарий
Внешний анонимный	доступ к порталу из сети общего пользования	перебор имён и паролей, перехват сценария восстановления
Внешний с частичным знанием	знает имя сотрудника и часть персональных данных	восстановление пароля от чужого имени
Внутренний пользователь	имеет собственную учётную запись	повышение прав, смена пароля коллеги
Внутренний администратор портала	доступ к конфигурации и журналам	сокрытие собственных действий
Владелец канала доставки	контролирует SMS-трафик или SIM	перехват одноразового кода

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

3. Предположения о среде функционирования

Транспортная защита обеспечивается внешним терминатором TLS. В аттестованных контурах — сертифицированным средством криптографической защиты с алгоритмами ГОСТ. Продукт собственной криптографии для защиты канала не реализует.
Соединение со службой каталога защищено (LDAPS либо StartTLS); операции с паролями по незащищённому каналу служба каталога отвергает сама.
Узел, файл конфигурации и хранилище секретов TOTP доступны только учётной записи, от имени которой выполняется продукт.
Часы узла синхронизированы: от них зависит проверка TOTP и срок жизни кодов.

4. Угрозы и меры противодействия

Угроза	Мера	Где реализовано
Перебор пароля или кода	ограничение неудачных попыток по имени и по адресу источника, блокировка на время	`internal/ratelimit`
Разведка существующих учётных записей	единообразный ответ и время реакции независимо от существования учётной записи	обработчики портала
Подмена адреса источника для обхода ограничений	заголовки прокси учитываются только от доверенных сетей	`internal/httpx`
Перехват одноразового кода	срок жизни 5 минут, три попытки, одноразовость, приоритет TOTP над SMS	`internal/factor/sms`
Подмена номера доставки	номер берётся только из каталога, собственного справочника телефонов нет	`internal/factor/sms`
Раскрытие кода через журнал или память	хранится только хэш кода, в журнал не попадает, номер маскируется	`internal/audit`, `internal/factor/sms`
Повторное использование сеанса	ограничение параллельных сеансов, таймаут бездействия, абсолютный таймаут	`internal/session`
Сокрытие следов атаки	журнал append-only со сцеплением записей хэшами, проверка целостности	`internal/audit`
Удаление журнала вместе с узлом	копия событий уходит во внешнюю систему сбора, потери доставки видны в метриках	`internal/audit/syslog.go`
Сброс пароля произвольному сотруднику при компрометации продукта	режим без привилегированного подключения: смена выполняется от имени самого пользователя	`internal/directory/ad`
Атака по времени на сравнение кодов	сравнение постоянного времени	`internal/factor/*`
Подбор пароля даёт возможность его сменить	второй фактор в сценарии смены (`factor_on_change`)	`internal/web`
Привязка своего приложения по украденному паролю	замена подключённого приложения требует кода из прежнего	`internal/web/enroll.go`
Прерванная регистрация оставляет учётную запись без рабочего фактора	секрет сохраняется только после подтверждения кодом	`internal/web/enroll.go`
Утечка секрета через журналы прокси и историю браузера	QR формируется на сервере и встраивается в страницу, ссылка с секретом не создаётся	`internal/qr`
Потеря устройства запирает сотрудника без второго фактора	замена подтверждается запасным способом; при его отсутствии привязку снимает администратор командой на узле	`internal/web/enroll.go`, `cmd/sspr/totpcmd.go`
Скрытое снятие второго фактора администратором	снятие фиксируется в журнале вместе с именем оператора	`cmd/sspr/totpcmd.go`, `internal/admin`
Вход в управление по украденному паролю	второй фактор обязателен, права проверяются в каталоге при каждом входе	`internal/admin`
Присвоение прав администрирования	членство определяется группой каталога, а не настройкой продукта	`internal/admin`

5. Функции безопасности

Перечень соответствует мерам защиты по приказам ФСТЭК России № 17, 21 и 239.

Мера	Реализация
ИАФ.1–ИАФ.6	идентификация по имени учётной записи каталога, подтверждение вторым фактором, скрытие вводимых значений
УПД.6	ограничение числа неудачных попыток
УПД.8	оповещение о предыдущем входе
УПД.9	ограничение параллельных сеансов
УПД.10	завершение сеанса при бездействии
РСБ.1–РСБ.8	регистрация событий, защита журнала от изменения сцеплением хэшей через границы файлов при ротации, выгрузка копии в систему сбора по RFC 5424, сквозная проверка `sspr audit verify`
АНЗ.5	проверка соответствия пароля политике до обращения к каталогу
ЗИС.1	разделение интерфейсов пользователя и администратора

6. Разделение режимов работы

Продукт разворачивается в двух режимах, и это ключевое архитектурное решение:

Смена известного пароля — продукту не нужна привилегированная учётная запись в каталоге. Операция выполняется соединением, установленным от имени самого пользователя. Компрометация продукта в этом режиме не даёт возможности сменить пароль другому сотруднику.
Восстановление забытого пароля — требует привилегированного подключения. Включается явно параметром allow_reset; при его отключении соответствующий путь недоступен. «Привилегированное» здесь означает два делегированных права на подразделении с сотрудниками, а не членство в административных группах. Точный перечень прав и команды делегирования — в документе «Права в каталоге», он предоставляется по запросу.

7. Принятый риск: пароли, ожидающие подтверждения

При включённом factor_on_change введённые пароли — текущий и новый — живут в памяти процесса между отправкой формы и вводом кода.

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

Ограничения. Срок ожидания — 5 минут, заметно короче срока сценария. Хранение в байтовых срезах с затиранием сразу после применения, по истечении срока и при отмене сценария. В журналы, метрики и ответы страниц значения не попадают.

8. Разделение интерфейсов

Интерфейс	Слушатель	Кому доступен
Портал пользователя	`listen`	сотрудникам, через внешний терминатор TLS
Управление	`admin.listen`	администраторам во внутренней сети
Метрики и пробы	`observability.metrics_listen`	системе мониторинга во внутренней сети

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

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

9. Открытые вопросы

Хранение секретов TOTP в СУБД для отказоустойчивых инсталляций. Сейчас — файл на узле; двух экземпляров портала с общим состоянием не бывает.
История паролей при административном сбросе: Active Directory её не проверяет, продукт не компенсирует. Компенсация потребовала бы хранить хэши прежних паролей на стороне продукта — это новый защищаемый актив, и вводить его без запроса заказчика не следует.