Как вы храните настройки, которые зашифрованы? - PullRequest
Новая
       34

Как вы храните настройки, которые зашифрованы?

4 голосов
/ 02 марта 2011

Мы внедрили шифрование для настроек в некоторых наших приложениях.

Придет день, когда мы забудем содержание этих настроек.Как правильно их хранить?К ним должны обращаться некоторые члены нашей команды.

Есть один способ, который мне не нравится: наши администраторы используют для этого вики.Эта вики доступна или нет.Нет простого способа узнать, какой член команды имеет информацию о том, какие логины.

Я могу придумать 2 варианта:

  1. Зашифровать их и сохранить их.в Subversion.Только члены команды, работающие над проектом, имеют ключ для их расшифровки.

  2. Используйте приложение, специально предназначенное для решения этой проблемы

Какой хороший способ сохранить секреты и сделать их доступными для определенных участников?

РЕДАКТИРОВАТЬ 1

Вот пример проблемы, с которой мы можем столкнуться:

У нас есть веб-приложение, которое работает на веб-сервере.Конфиг имеет некоторые важные параметры безопасности, такие как поставщики платежей.Если система дает сбой, и нам нужно перенести приложение на новый сервер, мы не можем использовать зашифрованный конфиг.Мы должны иметь один в открытом тексте и зашифровать его на новом сервере.

Невозможно восстановить конфигурацию.Мы действительно должны хранить его части в виде открытого текста в безопасном месте.

Ответы [ 3 ]

2 голосов
/ 02 марта 2011

Один из способов сделать это - зашифровать его ключом, а затем дать каждому пользователю половину ключа на USB-диске или что-то подобное.Таким образом, они не могут злоупотреблять этим и красть информацию напрямую, но им понадобится сотрудничество с кем-то еще, у кого есть другая часть ключа.И если USB-диск / файл будет украден, вся учетная запись не будет взломана.Кроме того, существует избыточность, поэтому в случае потери или кражи вы все равно можете получить доступ и повторно зашифровать данные.

1 голос
/ 17 марта 2011

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

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

0 голосов
/ 02 марта 2011

Первый и самый главный пароли НЕ ДОЛЖНЫ быть зашифрованы , поскольку это уязвимость, определенная CWE-257 .Не забывайте об «внутренней угрозе», ведь в конце концов вам придется кого-то уволить.Также пользователи затем часто используют пароли.В этом случае я бы реализовал sudo подобную функцию, где вы можете взять на себя управление учетной записью.Или, может быть, простой «забытый пароль», который есть у большинства приложений.

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

...