Надежное хранение ключей API: среда против JSON - PullRequest
Новая
       15

Надежное хранение ключей API: среда против JSON

0 голосов
/ 17 октября 2018

Мне известно, что стандартный способ хранения конфиденциальных данных - это переменные среды, в частности вне git-репо.

Есть много постов, обсуждающих эту тему, повторяя это как стандартную практику, но яДо сих пор неясно, в чем плюсы и минусы хранения паролей / ключей на самом деле в качестве переменных среды, а не просто в виде JSON где-то в домашнем каталоге пользователя вне репозитория?

Если я не ошибаюсь, если сервер будет скомпрометирован,и переменные окружения, и произвольный файл JSON одинаково открыты для тех, кто имеет доступ к машине.

Два метода кажутся удивительно похожими, если учесть, что для постоянных переменных среды ключи и секреты, вероятно, будут храниться в любом подходящем сценарии, например .profile.

1 Ответ

0 голосов
/ 17 октября 2018

Если вы храните ключи API и что-то / кто-то получает права доступа, такие как у программы, которая обычно использует эти ключи, теоретически игра окончена.Тем не менее, практически есть игры, в которые вы можете играть, чтобы усложнить жизнь противнику (и вам самим, к сожалению):

  • Локально запутать ключ ... сделать резервную копию ключа (зашифрованного) в хранилище с парольной фразойи только когда-либо использовать ключ в скомпилированной программе, которая использует массивы символов вместо строк (зависит от языка ofc).Возможно, передайте эту программу в обфускатор, что затруднит реверс-инжиниринг.
  • Создайте локально зашифрованное хранилище ключей, которое только выкашливает ключ для программ, которые каким-то образом «проверяют» как легитимные.
  • используйте «медовый» ключ, который вы активно отслеживаете для любого использования, которое кажется реальным ключом, но вы храните реальный ключ обфусцированным образом где-то хитро в кодовой базе.
  • Храните ключ удаленно (в«более безопасный» сервер) и принудительно направляет вызов через удаленный сервис, который каким-то образом проверяет правильность сообщения, IP-адрес вызывающего сервера, mac-адрес и т. д., вставляет ключ и передает запрос, выступая в качестве прокси-сервера.своего рода.

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

...