Всем привет!
И снова животрепещущая тема управления секретами!
Сегодня, в рубрике For Dummies, покажем пример использования, наглядно демонстрирующий пользу от систем Secret management и механизм их работы. Пример приведён с использованием продукта CyberArk Central Credential Provider (группа продуктов Application Access Manager), о котором ранее рассказали
🍩Вводные:
У нас есть монолитное, не контейнерное приложение, работающее на сервере приложений и имеющее зашитый в коде пароль в открытом, текстовом виде. Например, пароль для подключения к БД
🍩Проблема:
При удачной атаке на приложение этот пароль может стать доступен нарушителю, который с его помощью получит доступ к БД. Дальше ничего хорошего...
🍩Решение:
Заменить открытый пароль функцией вызова к системе управления секретами.
🍩 Что мы делаем?
1. Вместо пароля мы добавляем в код функцию обращения к системе управления и запроса секрета (пример на скриншоте)
2. В переменных функции (строка 10) мы указываем заранее определенные адрес хранилища, каталог с нужным секретом в нем, идентификатор приложения и идентификатор конкретного секрета.
3. Настраиваем параметры аутентификации приложения (разрешения на уровне системы управления секретами) по одному или нескольким параметрам: идентификатор конкретного приложения, контрольная сумма, ip адрес сервера приложения, пользователя, под которым оно запускается и т.д.
🍩Что в итоге получим:
1. Пароль из кода исчезнет
2. За конкретным паролем приложение через агента сделает запрос в хранилище, идентифицировав при этом себя.
3. Хранилище сверит с какого сервера, от какого приложения, каким агентом, к какому секрету пришел запрос. Если все условия получения соблюдены, хранилище в зашифрованном виде вернет секрет, который будет записан в переменную вызова.
Таким образом, в коде приложения сам пароль никогда не будет виден, нарушитель не сможет его получить. При этом даже если он получит доступ к коду приложения и попытается выполнить запрос к хранилищу, оно не выдаст значение секрета, потому что настроенная политика разрешает выдачу только и только непосредственно приложению.
Та-дам!
И снова животрепещущая тема управления секретами!
Сегодня, в рубрике For Dummies, покажем пример использования, наглядно демонстрирующий пользу от систем Secret management и механизм их работы. Пример приведён с использованием продукта CyberArk Central Credential Provider (группа продуктов Application Access Manager), о котором ранее рассказали
🍩Вводные:
У нас есть монолитное, не контейнерное приложение, работающее на сервере приложений и имеющее зашитый в коде пароль в открытом, текстовом виде. Например, пароль для подключения к БД
🍩Проблема:
При удачной атаке на приложение этот пароль может стать доступен нарушителю, который с его помощью получит доступ к БД. Дальше ничего хорошего...
🍩Решение:
Заменить открытый пароль функцией вызова к системе управления секретами.
🍩 Что мы делаем?
1. Вместо пароля мы добавляем в код функцию обращения к системе управления и запроса секрета (пример на скриншоте)
2. В переменных функции (строка 10) мы указываем заранее определенные адрес хранилища, каталог с нужным секретом в нем, идентификатор приложения и идентификатор конкретного секрета.
3. Настраиваем параметры аутентификации приложения (разрешения на уровне системы управления секретами) по одному или нескольким параметрам: идентификатор конкретного приложения, контрольная сумма, ip адрес сервера приложения, пользователя, под которым оно запускается и т.д.
🍩Что в итоге получим:
1. Пароль из кода исчезнет
2. За конкретным паролем приложение через агента сделает запрос в хранилище, идентифицировав при этом себя.
3. Хранилище сверит с какого сервера, от какого приложения, каким агентом, к какому секрету пришел запрос. Если все условия получения соблюдены, хранилище в зашифрованном виде вернет секрет, который будет записан в переменную вызова.
Таким образом, в коде приложения сам пароль никогда не будет виден, нарушитель не сможет его получить. При этом даже если он получит доступ к коду приложения и попытается выполнить запрос к хранилищу, оно не выдаст значение секрета, потому что настроенная политика разрешает выдачу только и только непосредственно приложению.
Та-дам!