steelmorgan/security

Безопасность 1С: секреты, аутентификация, криптография

Этот навык — карта тем по безопасности прикладного кода 1С. Конкретика по платформенным API вынесена в references/. Здесь — границы доверия, типовые ошибки и stop-rules, которые должен соблюдать любой агент (architect / developer-code / reviewer) при работе с чувствительными данными.

Безопасность в 1С — не отдельная подсистема, а сквозное свойство кода:

• Секреты живут в БезопасноеХранилище, а не в коде/конфигурации/логах.
• Криптография идёт через МенеджерКриптографии + явный провайдер (CryptoPro CSP / ViPNet) с явной версией ГОСТ.
• Аутентификация (OpenID / OAuth / basic / клиентский сертификат) — это контракт с явными режимами ошибок, а не «получилось/не получилось».
• Привилегированный режим — точечный инструмент, а не «выключатель прав» на весь модуль.

---

Когда применять

| Триггер | Действие | |---------|----------| | Видишь работу с паролем/токеном/секретом в параметре процедуры или в строке кода | Прочитай references/secrets.md, перенеси в БезопасноеХранилище, проверь маскирование в логах | | Видишь работу с МенеджерКриптографии, СертификатКриптографии, ХранилищеСертификатовКриптографии, ПараметрамиПодписиCMS | Прочитай references/crypto.md, проверь провайдера, версию ГОСТ, контекст (клиент/сервер) и lifecycle закрытого ключа | | Видишь HTTP-вызов внешнего API, OpenID/OAuth, basic-auth, клиентский TLS-сертификат | Прочитай references/auth.md, проверь error semantics и хранение учётных данных | | Делаешь ревью кода, который трогает права, RLS, привилегированный режим или внешние интеграции | Используй references/review-checklist.md как обязательный фильтр перед финальным ответом | | Нужно спроектировать новую интеграцию/сервис с аутентификацией | Сначала определи trust boundary (см. ниже), потом выбирай API |

---

Границы доверия (trust boundaries)

Перед тем как писать или ревьюить код, явно определи, какую границу он пересекает:

1. Пользователь → сервер 1С — аутентификация платформы, роли, RLS, разделение данных.
2. Клиент 1С → сервер 1С — параметры процедур пересекают сетевую границу (см. stop-rule про пароли).
3. Сервер 1С → внешний API — HTTPСоединение, OpenID/OAuth, клиентский сертификат, TLS.
4. Сервер 1С → ОС / провайдер криптографии — МенеджерКриптографии, CryptoPro CSP / ViPNet, доступ к хранилищу сертификатов под учёткой rphost/srv1cv8.
5. Сервер 1С → постоянное хранилище секрета — БезопасноеХранилище, либо внешний vault через коннектор.

Если граница не названа — навык применён неверно: вернись к этапу проектирования.

---

Темы и куда смотреть

1. Секреты и БезопасноеХранилище → references/secrets.md

• БезопасноеХранилище.УстановитьДанные(Владелец, Данные[, Ключ]) и ПрочитатьДанные(Владелец[, Ключ]).
• Владелец — обычно ссылка справочника учётных записей; никогда не строка-константа.
• Все вызовы — на сервере, под УстановитьПривилегированныйРежим(Истина) точечно (не на весь модуль).
• Жизненный цикл секрета: источник → запись → чтение → ротация → отзыв.
• Маскирование в логах, журнале регистрации и в ответе агента.

2. Криптография и ЭЦП → references/crypto.md

• МенеджерКриптографии(ИмяПровайдера, ТипПровайдера) — провайдер выбирается явно (CryptoPro CSP, ViPNet CSP).
• СертификатКриптографии, ХранилищеСертификатовКриптографии, ПараметрыПодписиCMS.
• ГОСТ Р 34.10-2012 (256/512 бит) — текущий стандарт; ГОСТ Р 34.10-2001 — только для проверки старых подписей.
• Закрытый ключ: контейнер на сервере, доступ под учёткой rphost; никогда не в общем модуле, не в реквизите справочника, не в Хранилище.Значение.
• БСП «Электронная подпись» (ЭлектроннаяПодпись, ЭлектроннаяПодписьСлужебный) — предпочтительный путь, если БСП в конфигурации есть.

3. Аутентификация и внешние API → references/auth.md

• OpenID / OpenID Connect — встроенная аутентификация платформы и в БСП («ИнтернетПользователи»).
• OAuth 2.0 — поверх HTTPСоединение/HTTPЗапрос, токен и refresh-token хранятся в БезопасноеХранилище.
• Basic / API-token — токен в БезопасноеХранилище, заголовок собирается на сервере.
• Клиентский TLS-сертификат: СертификатКлиентаФайл, СертификатКлиентаWindows, СертификатКлиентаOpenSSL в HTTPСоединение.
• Error semantics: missing credentials, expired token, invalid certificate, provider unavailable, denied rights, tenant mismatch, remote auth failure.

4. Чеклист ревью → references/review-checklist.md

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

---

Stop rules (1С-специфика)

Эти правила — жёсткие. Нарушение = блокирующий комментарий ревью и переписывание кода.

1. Пароль/токен/приватный ключ нельзя передавать через параметр процедуры, у которой есть граница «клиент ↔ сервер»

   • Запрещено: экспортная процедура общего модуля «Сервер, Вызов сервера» с параметром Пароль.
   • Правильно: на клиенте — только владелец секрета (ссылка); чтение секрета — на сервере внутри привилегированного режима.

2. Приватный ключ / контейнер криптографии не хранится в общем модуле, реквизите справочника или константе

   • Запрещено: base64-строка ключа в коде, в Константа.КлючШифрования, в макете.
   • Правильно: контейнер в хранилище ОС под учёткой сервера 1С, доступ через МенеджерКриптографии.

3. УстановитьПривилегированныйРежим(Истина) вокруг работы с БезопасноеХранилище — обязателен и точечен

   • Без УстановитьПривилегированныйРежим БезопасноеХранилище.ПрочитатьДанные упадёт по правам у обычного пользователя.
   • УстановитьПривилегированныйРежим(Ложь) обязательно ставится сразу после чтения, в том же блоке Попытка/Исключение.
   • Запрещено: оборачивать привилегированным режимом всю экспортную процедуру «на всякий случай».

4. Логи и журнал регистрации не содержат токены, пароли, приватные ключи и полные заголовки Authorization

   • В ЗаписьЖурналаРегистрации, Сообщить, ответе агента — только маскированные значения (***, последние 4 символа, fingerprint сертификата).
   • Тело HTTP-запроса/ответа логируется только после санитизации.

5. Аутентификационная ошибка отличается от валидационной и бизнес-ошибки

   • 401/403 от внешнего API не превращается в «не удалось выполнить операцию». Это отдельный тип ошибки с отдельной обработкой (refresh, повторный логин, эскалация).

---

Сценарии использования

Сценарий 1: Новый интеграционный модуль с OAuth

Контекст: Нужно вызвать внешний REST API с OAuth 2.0 (client credentials).

Шаги:

1. Назвать trust boundary: «сервер 1С → внешний API».
2. Создать справочник учётных записей; client_secret и refresh_token — в БезопасноеХранилище, владелец = ссылка элемента справочника.
3. Чтение секрета — на сервере, точечно под УстановитьПривилегированныйРежим.
4. Сборка заголовка Authorization — на сервере, заголовок не возвращается на клиент.
5. Описать error semantics: expired token → refresh, invalid client → ошибка конфигурации (не retry), provider unavailable → retry с backoff.
6. Логи: client_id — открыто, client_secret/access_token — маскировано (4 последних символа).
7. Прогнать references/review-checklist.md.

Сценарий 2: Подпись документа CMS

Контекст: Нужно подписать XML/PDF квалифицированной ЭЦП по ГОСТ Р 34.10-2012.

Шаги:

1. Trust boundary: «сервер 1С → CryptoPro CSP» (или ViPNet).
2. Если в конфигурации БСП «Электронная подпись» — использовать её модули, не писать свой МенеджерКриптографии руками.
3. Если БСП нет — МенеджерКриптографии("Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider", 80) с явным ТипПровайдера.
4. Сертификат брать по отпечатку (Отпечаток), не по «первому подходящему».
5. ПараметрыПодписиCMS (открепленная/прикреплённая, кодировка).
6. Контейнер закрытого ключа доступен под учёткой rphost — проверить в чек-листе развёртывания, не в коде.
7. Не логировать ДанныеПодписи целиком; логировать Отпечаток сертификата и идентификатор бизнес-объекта.

Сценарий 3: Ревью pull request, который трогает права

Контекст: В PR появился УстановитьПривилегированныйРежим(Истина).

Шаги:

1. Найти парный УстановитьПривилегированныйРежим(Ложь) в той же области видимости и в Попытка/Исключение.
2. Проверить, что внутри привилегированного блока — только доступ к секрету/системной таблице, а не вся бизнес-логика.
3. Проверить, что результат не утекает в форму/отчёт без явной проверки прав текущего пользователя.
4. Прогнать references/review-checklist.md.

---

Примеры

Правильно

// Сервер. Чтение токена внешнего API из безопасного хранилища.
// Привилегированный режим — точечный, только вокруг чтения секрета.
Функция ПолучитьТокенДоступа(УчётнаяЗапись) Экспорт

    УстановитьПривилегированныйРежим(Истина);
    Попытка
        ДанныеСекрета = БезопасноеХранилище.ПрочитатьДанные(УчётнаяЗапись, "access_token");
    Исключение
        УстановитьПривилегированныйРежим(Ложь);
        ВызватьИсключение;
    КонецПопытки;
    УстановитьПривилегированныйРежим(Ложь);

    Если ДанныеСекрета = Неопределено Тогда
        ВызватьИсключение НСтр("ru = 'Токен не настроен для учётной записи.'");
    КонецЕсли;

    Возврат ДанныеСекрета;

КонецФункции

Неправильно

// АНТИПАТТЕРН: пароль пересекает границу клиент/сервер в открытом параметре.
// АНТИПАТТЕРН: пароль попадает в журнал регистрации.
&НаСервереБезКонтекста
Функция ОтправитьДокумент(URL, Логин, Пароль, ТелоЗапроса) Экспорт

    ЗаписьЖурналаРегистрации("Интеграция",
        УровеньЖурналаРегистрации.Информация,
        ,
        ,
        "Отправка: URL=" + URL + ", Логин=" + Логин + ", Пароль=" + Пароль);

    // ... вызов внешнего API ...

КонецФункции

---

Типичные ошибки

| Ошибка | Последствие | Как избежать | |--------|-------------|--------------| | Пароль/токен в параметре экспортной серверной процедуры | Утечка по сети, в дампах, в логах клиента | Передавать только владельца секрета (ссылку), читать секрет на сервере | | УстановитьПривилегированныйРежим(Истина) на весь модуль/функцию | Обход RLS и проверок ролей по всей бизнес-логике | Точечный блок только вокруг работы с БезопасноеХранилище | | Хранение access_token в реквизите справочника / константе / макете | Любой пользователь с правом чтения справочника получает токен | БезопасноеХранилище + владелец = ссылка элемента справочника | | МенеджерКриптографии() без явного провайдера и типа | Код работает на стенде, падает на проде с другим провайдером | Явные ИмяПровайдера + ТипПровайдера, версия ГОСТ зафиксирована | | Сертификат выбирается «первый из хранилища» | Подпись неверным сертификатом в момент ротации | Поиск строго по Отпечатку | | 401 от внешнего API → Сообщить("Ошибка при сохранении") | Невозможно отличить истёкший токен от ошибки данных | Отдельный тип ошибки аутентификации + обработка refresh | | Логирование всего тела HTTP-запроса/ответа | В журнале регистрации лежат пароли/токены/ПДн | Санитизация перед логированием, маскирование чувствительных полей |

---

Связанные ресурсы

• error-handling — общая модель ошибок, в т.ч. различение технических и бизнес-ошибок.
• integration-patterns — паттерны HTTP-сервисов и внешних интеграций, на которые навешивается аутентификация.
• ssl-patterns — модули БСП (в т.ч. «Электронная подпись», «ИнтернетПользователи»).
• coding-standards — общие правила оформления серверного кода.

---

depends_on: []