Как хранить учетные данные безопасности в базе данных

Я работаю над приложением, подобным CMDB, где я должен хранить наши учетные данные безопасности (имена пользователей и пароли серверов, ...).

Я ищу лучший способ безопасно хранить их с этими ограничениями:

  • Большинство пользователей НЕ будут иметь доступ ко всем учетным данным (в зависимости от роли пользователя)
  • Мы не хотим, чтобы все пароли были зашифрованы одним и тем же ключом (уже пробовали: когда пользователь покидает компанию, менять ключ сложно...)
  • Действительно, мы не хотим, чтобы какой-либо закрытый ключ был жестко записан в исходном коде приложения или даже хранился где-либо (в нашей предыдущей версии закрытый ключ хранился между нашими ушами...)
  • Нам нужно реализовать аудит надежности паролей (т.е. анализировать расшифрованные пароли из скрипта)
  • Не должно быть случаев, когда мы больше не можем получить доступ к нашим учетным данным (потерянный ключ, ...) => мы не хотим, чтобы посторонние лица смотрели на них, но мы также не хотим их терять => решение для этого ограничением может быть обычный экспорт в физический шкафчик...

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

Я знаю, что прошу какое-то волшебное решение, но я хочу знать, существует ли оно ;о)


person Gauthier Delacroix    schedule 24.07.2012    source источник
comment
системы управления учетными данными бесполезны, если у вас есть явные недостатки безопасности в вашей системе в целом.   -  person rook    schedule 24.07.2012
comment
Просто: пользователи входят в систему с собственным паролем и получают доступ в зависимости от ACL.   -  person tc.    schedule 24.07.2012
comment
@тс. Конечно, они будут (с аутентификацией LDAP), но, как я уже сказал, я прошу не о безопасности на стороне приложения, а на стороне хранилища.   -  person Gauthier Delacroix    schedule 24.07.2012
comment
@Rook Я полностью согласен, но доверие к более высоким уровням не является лучшей практикой безопасности ...   -  person Gauthier Delacroix    schedule 24.07.2012
comment
Каждая служба должна просто использовать ваш сервер аутентификации/авторизации, чтобы решить, имеет ли пользователь доступ. Если вы имеете в виду хранение паролей для внешних сервисов (например, учетной записи компании в Twitter), то система кажется достаточно сложной, чтобы люди просто вставляли их в текстовый файл.   -  person tc.    schedule 25.07.2012


Ответы (1)


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

Именно из-за этой проблемы существуют системы федеративной идентификации (Kerberos/Active Directory/и т. д.), позволяющие центральному компьютеру аутентифицировать пользователей, не раскрывая секреты указанным пользователям. Но использование федеративной системы идентификации требует взаимодействия между системой, в которой выполняется вход, и службой идентификации.

person Billy ONeal    schedule 25.07.2012
comment
Очень хорошее рассуждение от вас и в связанной статье. Конечно, безопасность никогда не может быть полной, но она должна быть максимально возможной на каждом уровне (я не буду хранить учетные данные в электронной таблице, потому что безопасность не может быть полной!). Меня успокаивает мысль о том, что хорошим решением может быть сохранение «неписаного» уникального принципа ключа, но только для нескольких людей, с необходимостью устанавливать ключ при каждом перезапуске приложения (и решать, как делиться ключом между потоками...) . Ключ присутствует только в памяти потоков. Чтобы посмотреть ключ, вы должны изменить код, включая перезапуск приложения, включая потерю ключа. - person Gauthier Delacroix; 25.07.2012
comment
@GauthierDelacroix Чтобы посмотреть ключ, вам просто нужно прикрепить отладчик/дамп памяти. Если это слишком сложно, вы можете просто заменить двоичный файл на тот, в котором происходит утечка ключа, и притвориться, что приложение разбилось. - person tc.; 25.07.2012
comment
@тс. Да, память можно сбрасывать, но я не буду заходить так далеко. Незашифрованные учетные данные также будут храниться в памяти. Вы не можете полностью защитить то, что вам нужно отобразить... Тем не менее, я думаю, что есть разрыв между извлечением ключа из файла и из памяти... - person Gauthier Delacroix; 25.07.2012