Хранение секретов в Hashicorp Vault для 1С

30.05.24

Администрирование - Информационная безопасность

Все еще храните пароли в базе? Тогда мы идем к вам! Безопасное и надежное хранение секретов. JWT авторизация. Удобный интерфейс. Демо конфигурация. Бесплатно.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование SM По подписке [?]
Хранение секретов в Hashicorp Vault для 1С: демо конфигурация
.cf 136,39Kb
33
33
0 SM
Скачать
Хранение секретов в Hashicorp Vault для 1С: исходники
.zip 90,59Kb
28
28
0 SM
Скачать

Оглавление

1. В чем проблема

2. Как лечить

3. Все в одной корзине?

4. Один секрет вместо многих

5. Описание JWT аутентификации в Vault для 1С простыми словами

6. Небольшой экскурс в криптографию

7. Описание JWT аутентификации в Vault для 1С сложными словами

8. План работ

9. Технические дебри

10. Публикация открытого ключа (JWKS)

11. Настройка Vault

12. Подключение к Vault из 1С с помощью демонстрационной конфигурации

13. И самое главное

14. Благодарности

 

В чем проблема

Существует проблема такая - пароли лежат где попало. В программном коде, в справочниках, в файлах на диске, прилеплены на монитор. И это плохо. С листочком на мониторе, правда, нам побороться не удастся.

Предлагаю сразу же отойти от понятия "пароль" и использовать "секрет". Потому что чувствительная информация может быть не только паролем, но и строкой подключения, сертификатом, логином, токеном, какими-то реквизитами - чем угодно.

Чем опасен такой подход хранения секретов? Тем, что благодаря хранению секретов в базе, угроза может распространяться на другие участки ИТ-ландшафта вашей компании. Если секреты есть в программном коде - они начинают распространяться по репозиториям. Новости последних лет говорят о множестве утечек баз с персональными и платежными данными, адресами, даже кодами домофонов. Сейчас речь не про хитрые взломы, злых хакеров и квантовые компьютеры. В реальной жизни все проще - воруют бэкапы. Далее из этого бэкапа можно достать все секреты и начать исследовать корпоративную флору и фауну на предмет ценных данных. А это означает, что такую уязвимость необходимо устранить. В бэкапах не должно быть секретов.

Кстати, правительство занимается вопросом ужесточения ответственности за утечки данных.

 

Как лечить

Куда вынести секреты? В отдельную систему, специально разработанную для этого.

Я выбрал для этого Hashicorp Vault.

Кроме того, что в Спортмастере он уже давно используется, есть еще некоторые критерии выбора:

  • opensource https://github.com/hashicorp/vault
  • бесплатная версия, покрывающая много потребностей
  • хранилище секретов (база данных) зашифровано
  • множество методов аутентификации
  • удобный web-интерфейс управления
  • система ролей и прав
  • написан на golang, быстро работает
  • большое сообщество
  • Hashicorp - известный производитель ПО (Terraform, Consul, Nomad, Vagrant...)
  • частые обновления

 

Все в одной корзине?

Первая мысль, возникающая при идее перенести куда-то все секреты из базы, выражается как "Сложить все яйца в одну корзину". В случае с Vault так ли это? Да, именно так. Однако, это надежная, отказоустойчивая, безопасная и быстрая корзина.

Про скорость уже была ссылка выше. Golang известен своим быстродействием.

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

Так же с базой данных Vault можно производить резервное копирование и восстановление в автоматическом режиме через API.

Безопасность Vault главным образом осуществляется тем, что Vault при включении требует очень длинный ключ для доступа к своей БД. Процесс называется "запечатывание" и "распечатывание" (seal и unseal). Этот ключ Vault хранит в ОЗУ, а не на диске. При перезагрузке машины или сервиса нужно обязательно ввести этот ключ, чтобы Vault мог взаимодействовать со своей БД. Поэтому если кто-то унесет с собой БД Vault - ничего страшного, ее просто не получится расшифровать.

 

Один секрет вместо многих

Вторая мысль, возникающая при идее перенести куда-то все секреты из базы, выражается как "У нас будет один секрет от всех наших секретов". В контексте данной статьи это не совсем так, хотя немного похоже. У нашего секрета будут содержащиеся в нем время жизни и цифровая подпись асимметричным ключом.

Предлагаю воспользоваться одним из методов аутентификации в Vault под названием JSON Web Token (JWT).

Одна статья про JWT - https://habr.com/ru/articles/340146/

Вторая - //infostart.ru/1c/tools/2018297/

Третья - //infostart.ru/1c/articles/2049126/

Сайт с отладчиком - https://jwt.io/

Спецификация JWT - https://datatracker.ietf.org/doc/html/rfc7519

Гугл - https://www.google.ru/

Главные плюсы, которые мы возьмем из JWT:

  • Его можно подписать с помощью асимметричного ключа. Таким образом, никто за нас не сможет сделать "фейковый" токен. Произвести токен может только наша конкретная ИБ 1С.
  • В токен можно заложить время жизни (срок годности). Vault проверяет эту дату еще до проверки цифровой подписи. С помощью этого свойства мы можем не переживать о том, что токен украли. Скорее всего, к моменту утечки токен уже будет не действителен.

 

Описание JWT аутентификации в Vault для 1С простыми словами

JWT - это JSON, в котором содержится информация о том, кто его предоставляет. Например, внутри может быть имя базы 1С, которая выступает эмитентом этого токена. Эта строка JSON конвертируется в base64 строку, а уже эта base64 строка подписывается цифровой подписью и добавляется в конец токена.

Академический пример JWT с сайта https://jwt.io/:

"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"

JWT всегда разделен двумя точками на 3 части:

 

1. Техническая информация токена. В примере это eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

 
 JSON

 

2. Полезная нагрузка (там мы говорим, кто мы есть, плюс задаем срок годности токена). В примере это eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ  

 
 JSON

 

3. Подпись закрытым ключом. В примере это SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c. Здесь нет никакого понятного представления. Просто цифровая подпись первых двух частей JWT.

Представьте, что вы (1С) звоните своему другу (Vault):

1С (на первой линии): Привет, Vault! Я 1С ERP, дай мне, пожалуйста, значение секрета с именем "ОченьСтрашныйСекрет". Вот моя цифровая подпись, можешь ее проверить, перезвонив мне по телефону, который ты уже давно знаешь.

Vault (на первой линии): Привет, 1С ERP! Хорошо. Я знаю кто ты, вижу, что у тебя есть доступ к этому секрету. Сейчас я возьму твою подпись и перезвоню тебе, проверю, точно ли это ты. Если подпись подтвердится - я дам тебе одноразовый ключ для доступа к секрету.

Vault (на второй линии): 1С ERP, дай, пожалуйста, открытый ключ для проверки твоей подписи.

1С (на второй линии): держи

Vault (на первой линии): да, я проверил твою подпись твоим открытым ключом, верю, что это действительно ты, держи одноразовый ключ доступа.

1С (на первой линии): *получает секрет с одноразовым ключом*

Картинка с внутрикорпоративной презентации:

 

   

 

То есть никакого пароля нет. 1С сама себе производит пару ключей (открытый и закрытый), создает токен с заданным временем жизни (мне показалось достаточно 30 минут), подписывает токен закрытым ключом и сразу же этот закрытый ключ забывает. Токен сохраняется в базе. И в этом нет ничего страшного, так как у него ограниченное время жизни. А открытую часть ключа 1С публикует в HTTP сервис, на который смотрит Vault. Vault принимает токен, проверяет его подпись с помощью открытого ключа, на этом принимает решение об аутентификации и авторизации. Получается, что 1С как бы сама себя аутентифицирует в Vault. А Vault просто знает где взять открытый ключ для конкретной системы, с помощью которого можно проверить подпись токена, подписанную закрытым ключом.

 

Небольшой экскурс в криптографию

В статье никто не "изобретал криптографию". Вся криптография обрабатывается фреймворком .NET, который уже установлен на каждой Windows машине.

Пользоваться будем RSA.

Ссылка на Википедию

Ссылка на хорошую статью по RSA

Это алгоритм шифрования, где есть открытый и закрытый ключ. С помощью закрытого ключа сообщение расшифровывается (или подписывается). Закрытый ключ никто не должен знать. Обладая закрытым ключом, можно расшифровать сообщение или притвориться эмитентом подписи. С помощью открытого ключа сообщение можно зашифровать (или проверить подпись). Открытый ключ можно ни от кого не скрывать, с помощью него ничего страшного сделать нельзя.

Польза алгоритма шифрования RSA достигается за счет того, что открытая и закрытая часть ключа - обязательно связаны друг с другом. Это два очень больших числа. Имея подписанное сообщение и открытую часть ключа - очень трудно вычислить закрытую часть ключа. Однако же, имея подписанное сообщение и открытый ключ - очень просто проверить подпись.

Будем пользоваться RSA с длиной ключа 2048 бит. Меньшая длина ключа - deprecated, так как поддается различным математическим атакам на алгоритм RSA с современными вычислительными мощностями. Большую длину ключа можно сделать, но особого смысла нет.

При помощи RSA работает большая часть Интернета. Есть, конечно, всякая экзотика в виде эллиптических кривых (например https://github.com работает на EC). Но, судя по тому, какие споры об этом есть на Хабре, лучше пользоваться старым добрым RSA с доказанной эффективностью.

 

Описание JWT аутентификации в Vault для 1С сложными словами

Подпись токена будет происходить асимметричным ключом. Симметричные ключи в токенах - deprecated. Сам Vault отказался от симметричного шифрования в токенах в недавнем обновлении. Ключ и подпись в демо конфигурации осуществляется через COM объекты с помощью .NET, поэтому ничего нового на сервер устанавливать не потребуется. У кого Linux - попробуйте вызывать методы openssl. Нужен будет метод генерации ключа в виде XML и метод подписи данных с помощью этого ключа.

В 1С есть объект ТокенДоступа. И до версии 1С 8.3.24 этот ТокенДоступа формировался неправильно. Конкретно - в JSON`е токена числовые поля iat (ussued at, время создания) и exp (expiration time, время жизни) 1С формировала как строки. А это не по спецификации. Библиотека go-jose, которая используется Vault для обработки JWT, валится на таком 1Сном токене. Поэтому в демо конфигурации подпись токена происходит с помощью .NET через COM.

Тикет https://bugboard.v8.1c.ru/error/000145179

Исправлено в 8.3.23.2137, 8.3.24.1467, 8.3.25.1257.

Сервер 1С не позволяет сохранить у себя в памяти процесса некоторое значение, которое мы сможем переиспользовать из нового сеанса, при этом не записав его на диск (костыли с долго живущими HTTP сервисами просьба не предлагать). Поэтому закрытый ключ будет выкидываться сразу после подписи токена. Ключ будет новый каждый раз для каждого токена. Выглядит как расточительство, но что поделать... С другой стороны ничего страшного. Диапазон ключей огромен, формируется новый ключ очень быстро.

Итак, как выглядит демо конфигурация:

  • Справочник с настройками Vault. В демо конфигурации он не привязан к строке подключения 1С, но лучше привязать. В нем будет храниться адрес сервера Vault, имя роли (далее), токен доступа (JWT), открытый ключ и время жизни токена.
  • HTTP сервис, отображающий открытый ключ из справочника настроек.
  • Роль для доступа к HTTP сервису.
  • Регламентное задание обновления токена (JWT) по настройкам.
  • Общий модуль для обработки всего этого.

 

План работ

Нужно уметь создавать ключ RSA, формировать JWT токен, подписывать токен закрытым ключом. Подписанный токен и открытый ключ сохранять в базе. И делать это, например, раз в 30 минут. Токен будет действовать 30 минут, через это время он будет протухать, а мы делать новый токен.  Авторизовываться в Vault будем с помощью токена JWT. В Vault есть лаг в одну минуту на обновление ключа. Так что фактически токен будет действовать 31 минуту. Открытый ключ будем публиковать в HTTP сервисе. В Vault укажем адрес публикации, чтобы Vault мог проверять подпись JWT токена.

Ну и настроить Vault, само собой.

 

Технические дебри

Чтобы сформировать JWT, нам нужно получить случайную пару ключей. Получим мы ее так:

 
 Функция СлучайнаяПараКлючейХМЛ()

Выглядит костыльно. Здесь powershell вызывает конструктор RSACryptoServiceProvider из .NET и возвращает новый ключ как XML с содержанием закрытой части ключа ($true). Зато закрытый ключ на диск не пишем.

 
 Ключ будет такой

Далее нужно сделать первые 2 части JWT

 
 Первая часть всегда будет одинаковая

Превращается в такую строку c помощью преобразования в Base64Url строку: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9. Первую часть можно даже захардкодить, всегда будет одинаковая.

Примечание: не путать Base64Url и Base64. Base64Url - это Base64, но все "+" и "/" заменяются на "-" и "_" соответственно, убираются все переносы строк и все "=" в конце. В общем, преобразуется к требованиям URL строки.

 
 Функция преобразования Base64 в Base64 URL

Везде "base_name" нужно заменить на имя своей базы. Требование к имени как к переменным в коде.

 
 Вторая часть JWT будет примерно такая

Что тем же Base64 URL преобразуется в eyJzdWIiOiJiYXNlX25hbWUiLCJiYXNlX25hbWUiOiJiYXNlX25hbWUiLCJraWQiOiJiZjViZTNmNS00NDBkLTQ0ODEtODg5NS1mMTdjOGQ0ZDY3YjEiLCJpYXQiOjE3MTQ3NDM2MTksImV4cCI6MTcxNDc0NTQxOX0

Здесь "sub": "base_name". Поле subject, содержащее имя нашей базы 1С. Vault по этому полю будет определять пользователя.

"base_name": "base_name" - трудно объяснить, проще сказать "таков путь". Внутри Vault есть требование к наличию дополнительного поля в полезной нагрузке токена. Пусть будет такое. Не забываем заменять base_name на имя своей базы.

"kid": "bf5be3f5-440d-4481-8895-f17c8d4d67b1" - уникальный идентификатор открытого ключа, с помощью которого подписан токен. Просто случайный ГУИД, который надо вставить в токен. И который потом будет опубликован в HTTP сервисе с открытым ключом. Vault по этому ГУИДу будет искать открытый ключ к токену.

"iat": 1714743619 - issued at - токен выпущен 3 мая 2024 года в 16:40:19.
"exp": 1714745419 - expired at - токен действителен до 3 мая 2024 года в 17:10:19.

 

Третья часть JWT - подпись. У нас уже есть первые 2 части и выглядят они так:

 
 Первые 2 части JWT

Из этой строки необходимо получить SHA256 хеш-сумму (1С умеет ее делать) и полученную сумму подписать с помощью Cryptography.RSACryptoServiceProvider в .NET.

Функция подписи (да и формирования токена) выглядит так:

 
 Функция ПолучитьТокен

 

 
 И здесь вообще весь набор функций, который пригодится для формирования токена и публикации открытого ключа

 

 

Публикация открытого ключа (JWKS)

JWKS - JSON Web Key Set - набор ключей JSON Web

 
 Выглядит примерно так

Формируется в функции "НаборКлючей" в списке функций чуть выше. Этот ключ должен быть опубликован в http-сервисе.

Строку подключения к http-сервису необходимо сформировать с inline-авторизацией.

Шаблон:
https://<имя пользователя>:<пароль>@<имя сервера>/<имя базы>/hs/<имя публикации>

Пример:

https://vault_user:w3f21f2e4f234@my1cserver.local/base_name/hs/jwks

Само собой, роль для такого пользователя должна иметь права исключительно на чтение открытого ключа (точнее набора ключей JWKS).

 

Настройка Vault

Для начала его надо установить. Скачать для своей платформы можно с официального сайта: https://developer.hashicorp.com/vault/install?product_intent=vault

Если сайт не открывается или не стартует загрузка, то, образно говоря, кхм, попробуйте открыть и загрузить из другой локации.

С чего можно начать настройку: https://developer.hashicorp.com/vault/docs/install

Полностью установку расписывать не буду. Лишь уверю в том, что любой более-менее опытный администратор с этим справится. Я устанавливал на Ubuntu и на Windows Server. Не забудьте открыть порт и сохранить ключи для распечатывания (unseal) в надежное место (но не в сам Vault). Ключи для распечатывания необходимы для подключения Vault к файлу своей базы данных при перезапуске.

Когда настроили сервер Vault, настало время произвести настройку JWT авторизации для нашей 1С базы.

Сначала необходимо придумать смысловое имя для базы. Например, "erp_prod" или "buha_intg". Неизвестно, куда база 1С может переехать, а перенастраивать Vault лишний раз не хочется. Хотя и придется, так как публикация JWKS скорее всего переедет вместе с базой.

Далее будет использоваться имя базы test_base_name.

 
 Создание authentication method

Метод аутентификации создан. Теперь необходимо создать KV-хранилище (key - value, ключ - значение), где и будут храниться наши секреты :)

 
 Создание KV-хранилища для хранения секретов

Осталось немного, донастроить политику доступа для нашей системы:

 
 Создание policy

И создать роль:

 
 Создание роли

Vault для одной базы 1С настроен. Можно создать секрет и попытаться получить его из 1С.

 

Подключение к Vault из 1С с помощью демонстрационной конфигурации

Исходники демо конфигурации: https://github.com/infina15/1c_vault_demo

Сам CF: https://github.com/infina15/1c_vault_demo/releases/download/1.0.0/vault_demo.cf

Внутри использована консоль регламентных заданий https://github.com/kuzyara/JobsConsole2019.epf. Kuzyara, выражаю большую благодарность!

В справочнике "Vault настройка" у предопределенного элемента Vault установить адрес сервера Vault и порт (если порт не стандартный), имя роли (имя системы, для примера использовалось "test_base_name"), время жизни токена в минутах (по-умолчанию робот проставит 30 минут).

Важно: время жизни токена должно совпадать с регламентным заданием обновления ключа. По-умолчанию время жизни и время обновления составляет 30 минут.

 

 

Выполнить регламентное задание Волт_ОбновитьКлюч (в демо конфигурации есть обработка Консоль заданий 2019).

 

 

После выполнения рег. задания в справочнике "Vault настройка" должны заполниться поля ТокенДоступа и Открытый ключ.

 

 

Далее необходимо создать пользователя с необходимыми правами для обращения к HTTP-сервису Волт_ОткрытыйКлюч. Пример прав - роль Волт_ЧтениеКлюча.

Выполнить публикацию HTTP-сервиса Волт_ОткрытыйКлюч. Сформировать строку подключения в виде http(s)://<имя пользователя>:<пароль>@<имясервера>/<имя базы>/hs/jwks , где <имя пользователя> и <пароль> - имя пользователя и его пароль в ИБ 1С, а <имя сервера> - имя сервера, где произведена публикация HTTP-сервиса 1С с открытым ключом. При формировании имени пользователя и пароля необходимо учесть, что в URL-строке допустыми не все символы. Справка по символам - https://developers.google.com/maps/url-encoding?hl=ru#special-characters

В браузере будет выглядеть так:

 

 

Убедиться, что сформированная строка открывается в браузере, открытый ключ в виде json отображается (поля kty, kid, e, n, use, alg). JSON должен совпадать с полем "Открытый ключ" справочника "Vault настройка".

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

С помощью обработки "Волт тест" проверить работу подключения. Например, для пространства Vault с именем test, для его подпапки ab, для лежащего внутри секрета cd, строка пути будет /v1/test/data/ab. В поле Имя секрета нужно указать cd.

 

 

Для получения секрета в коде конфигурации необходимо использовать функцию ПолучитьСекрет(Путь, ИмяСекрета) общего модуля РаботаСВолт. По примеру из предыдущего пункта "РаботаСВолт.ПолучитьСекрет("/v1/test/data/ab", "cd")"

 

И самое главное

После переноса секретов в Vault - обязательно сменить пароли в секретах. Желательно очистить историю данных в тех структурах, где ранее хранились секреты.

 

Благодарности

Спасибо за прочтение статьи! Буду рад обсудить в комментариях.

Отдельное большое спасибо uno-c за комментарии к статье 001. Криптография и цифровая подпись RSA-sha256 на платформе 1С , без этой информации я вряд ли справился бы с этой задачей.

См. также

Информационная безопасность Системный администратор Программист Платные (руб)

AUTO VPN (portable) - автоматизация подключения пользователей к удаленному рабочему месту или сети посредством создания автоматического VPN (L2TP или L2TP/IPSEC и т.д.) подключения без ввода настроек пользователем (с возможностью скрытия этих настроек от пользователя). Программа автоматически выполняет подключение к VPN серверу и после успешного коннекта , если необходимо, подключение к серверу удаленных рабочих столов (RDP).

1200 руб.

24.03.2020    14796    24    32    

34

Информационная безопасность Программист Платформа 1С v8.3 Бесплатно (free)

Рассмотрим в статье более подробную и последовательную настройку аутентификации в 1С с использованием распространенной технологии JWT, которая пришла в программу в платформе версии 8.3.21.1302.

27.02.2024    4718    PROSTO-1C    10    

38

Информационная безопасность Программист Платформа 1С v8.3 Абонемент ($m)

Интеграционные решения стали неотъемлемой частью нашей жизни. Правилом хорошего тона в современных приложениях является не давать интегратору доступ к чувствительным данным. Device flow позволяет аутентифицировать пользователя, не показывая приложению чувствительные данные (например: логин и пароль)<br> Рассмотрим Device flow аутентификацию, в приложении, на примере OpenID провайдера Yandex.

1 стартмани

27.10.2023    2078    platonov.e    1    

23

Информационная безопасность Системный администратор Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Продукты на основе решений 1С уверенной поступью захватывают рынок учётных систем в стране. Широкое распространение программ всегда порождает большой интерес к ним со стороны злоумышленников, а пользователь 1С это одна из дверей в защищённый информационный контур предприятия. Обработка позволяет быстро и комплексно оценить настройки безопасности конкретной базы и возможности пользователя этой базы на сервере. Также можно оценить некоторые аспекты сетевой безопасности предприятия со стороны сервера 1С.

5 стартмани

24.04.2023    5858    18    soulner    7    

32

Информационная безопасность Системный администратор Программист Платформа 1С v8.3 1С:ERP Управление предприятием 2 Абонемент ($m)

1С, начиная с версии платформы 8.3.21, добавили в систему возможность двойной аутентификации. Как это работает: в пользователе информационной базы появилось свойство «Аутентификация токеном доступа» (АутентификацияТокеномДоступа во встроенном языке), если установить этот признак и осуществить ряд манипуляций на встроенном языке, то появляется возможность при аутентификации отправлять HTTP запросы, которые и реализуют этот самый второй фактор. Данное расширение позволяет организовать двухфакторную аутентификацию с помощью электронной почты или мессенджера Telegram.

2 стартмани

08.12.2022    6563    38    Silenser    12    

23

Информационная безопасность Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

От клиента клиенту, от одной системы к другой, мы вновь и вновь встречаем одни и те же проблемы и дыры в безопасности. На конференции Infostart Event 2021 Post-Apocalypse Виталий Онянов рассказал о базовых принципах безопасности информационных систем и представил чек-лист, с помощью которого вы сможете проверить свою систему на уязвимость.

26.10.2022    10004    Tavalik    46    

114
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. dsdred 3472 30.05.24 12:13 Сейчас в теме
Спасибо за статью. Пару месяцев назад тоже на это хранилище вышел.
2. DmitryKSL 156 30.05.24 13:08 Сейчас в теме
С помощью закрытого ключа сообщение шифруется (или подписывается). Закрытый ключ никто не должен знать. Обладая закрытым ключом, можно притвориться эмитентом сообщения или подписи. С помощью открытого ключа сообщение можно расшифровать (или проверить подпись). Открытый ключ можно ни от кого не скрывать, с помощью него ничего страшного сделать нельзя.

По-моему, вы тут что-то напутали...
3. kamisov 213 30.05.24 13:12 Сейчас в теме
4. DmitryKSL 156 30.05.24 13:24 Сейчас в теме
5. kamisov 213 30.05.24 13:31 Сейчас в теме
(4) да, действительно, спасибо! Я пока занимался подключением к Волту, работал только с подписями, поэтому в голове перемешалось. Получается для шифрования открытый, для расшифровки закрытый. Для производства подписи закрытый, для проверки подписи открытый.
infosoft-v; dsdred; SerVer1C; +3 Ответить
6. bgazobeton 31.05.24 05:45 Сейчас в теме
Здравствуйте. Если честно, есть сомнения, что такая схема защитит от взлома секретов с помощью бэкапа 1С.
Что насчет ситуации:
***
1С-копия из бэкапа (на первой линии): Привет, Vault! Я 1С ERP (да, та самая, а вовсе не копия), дай мне, пожалуйста, значение секрета с именем "ОченьСтрашныйСекрет". Вот моя цифровая подпись, можешь ее проверить, перезвонив мне по телефону, который ты уже давно знаешь.

Vault (на первой линии): Привет, 1С ERP! Хорошо. Я знаю кто ты, вижу, что у тебя есть доступ к этому секрету. Сейчас я возьму твою подпись и перезвоню тебе, проверю, точно ли это ты. Если подпись подтвердится - я дам тебе одноразовый ключ для доступа к секрету.

Vault (на второй линии): 1С ERP, дай, пожалуйста, открытый ключ для проверки твоей подписи.

1С (на второй линии): держи

Vault (на первой линии): да, я проверил твою подпись твоим открытым ключом, верю, что это действительно ты, держи одноразовый ключ доступа.

1С-копия из бэкапа (на первой линии): *получает секрет с одноразовым ключом*
***

Ну т.е. проблема из "украли бекап - получили все секреты" становится "украли бекап - получили доступ к хранилищу секретов".

Мне кажется тут очень не хватает отдельного криптоконтейнера, чтобы ключей в 1С вообще не было.
7. kamisov 213 31.05.24 09:31 Сейчас в теме
(6) Нет, все совсем не так. Токен JWT, который 1С предоставляет в Vault для аутентификации, обновляется каждые полчаса и каждый раз действует всего полчаса. Пара ключей, которыми подписывается и проверяется конкретный токен, каждые полчаса новая. То есть в бэкапе гарантированно лежит токен, у которого уже вышел срок действия. Плюс ни бэкап, ни сама база не хранят закрытый ключ. Только открытый.

Единственный вариант, когда копия сможет прикинуться самой базой - это если успели сделать копию за эти полчаса, когда токен и ключ обновляются. Если база такая маленькая, что можно ее за полчаса забэкапить и развернуть, то можно время обновления токена и ключа сделать меньше. Вплоть до одной минуты.
starik-2005; +1 Ответить
8. qwinter 275 31.05.24 10:42 Сейчас в теме
(6) Бекапы должны лежать где то без права чтения и записи, а сама система должна подключаться куда то и делать бекап к себе. так что такой вариант маловероятен при нормальной логике системы, а вот вариант со взломом какого даже самого незначительного пользователя и получением доступа ко всему из продакшена... Это вот в этой схеме полный попец.
9. kamisov 213 31.05.24 11:01 Сейчас в теме
(8) должны, да не всегда и у всех это выполняется. А как под незначительным пользователем вызвать функцию общего модуля и узнать еще какой путь в Vault передать? Никак, просто прав нет. И даже если есть, придется потратить время на то, чтобы понять, что секреты не хранятся в базе, а нужно вызывать какую-то функцию и какие-то пути искать :) В конце концов Vault можно запечатывать, если есть понимание, что уже кто-то в сеть залез. В запечатанный Vault не достучаться вообще никак.
10. qwinter 275 31.05.24 12:04 Сейчас в теме
(9)
А как под незначительным пользователем вызвать функцию общего модуля

Для человека отвечающего за безопасность вы задаете слишком глупые вопросы.

и узнать еще какой путь в Vault передать?

Прочесть инфостарт.
Прикрепленные файлы:
JohnyDeath; +1 Ответить
11. kamisov 213 31.05.24 12:35 Сейчас в теме
(10) благодарю за столь высокую оценку вопросов.

Внутри функции идет запрос к справочнику, так что систему прав на этом можно выстроить. Странно, что вы об этом не подумали.

В любом случае вынести секреты из базы уже прибавляет безопасности. А абсолютной безопасности добиться невозможно.

з.ы. для функции нужны параметры, которые в СКД будет неоткуда взять. В крайнем случае можно сделать процедуру, и дыра с СКД точно будет закрыта.
12. qwinter 275 31.05.24 12:48 Сейчас в теме
(11)
Внутри функции идет запрос к справочнику, так что систему прав на этом можно выстроить.
Ну выстроите? От этого у пользователей прав до него не будет? Будут. Иначе он просто не нужен. А раз используете то есть и пользователи с правами, причем чем масштабнее использование, тем больше таких пользователей.

При наличии доступа к бекапу узнать какими функциями вызывается Vault дело тоже не долгое.
13. kamisov 213 31.05.24 12:53 Сейчас в теме
(12) тут уже ситуация, когда поздно лечить царапину, если ногу оторвало. Когда у вас внутри сети есть админ-негодяй, целенаправленно делающий плохие вещи, вряд ли от него скроешься.
14. JohnyDeath 301 01.06.24 23:55 Сейчас в теме
Отличная статья с очень хорошими пояснениями и инструкциями. Спасибо!
Для тех, кто присматривался, но так и не решился, сэкономит уйму времени
15. sml 41 19.06.24 21:13 Сейчас в теме
неясно, как это поможет при похищении бэкапа базы, в котором просто удалят пользователей и зайдут в базу под Админ правами?
16. kamisov 213 20.06.24 16:04 Сейчас в теме
(15) смысл не столько в защите самой базы, сколько в защите смежных систем. Когда строки подключения к смежникам хранятся в базе, можно дальше пробовать подключаться ко всему ландшафту. Риск распространения угрозы уменьшается.

З.ы. абсолютная защита базы - это когда к ней доступа нет ни у кого вообще.
Оставьте свое сообщение