Лучшая практика хранения пароля базы данных

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

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

Я мог хранить учетные данные в среде, но это просто безопасность через неясность. Г-н Злой может просто посмотреть в окружающую среду, чтобы найти его.

Кто-то предложил шифрование. Однако, если я храню ключ в исполняемом файле, быстро декомпилирую (мы используем Java), и я все еще обречен.

Я также хочу избежать необходимости вводить парафраз каждый раз, когда я запускаю сервер.

Любые предложения? Я чувствую, что мне не хватает чего-то простого.

Спасибо

ОТВЕТЫ

Ответ 1

Я не думаю, что вам не хватает чего-то простого. Либо сервер, о котором идет речь, может подключиться к базе данных без вашей помощи, и в этом случае он должен иметь учетные данные; или он не может подключиться без вашего обеспечения. Вы можете предпринять различные шаги, например, перечисленные вами, чтобы сделать его более трудным для уязвимого сервера, чтобы показать учетные данные в базе данных, но в конце дня, если он должен иметь эти учетные данные и предоставить их на сервер БД для соединения, они должны быть сохранены на нем где-то — или, по крайней мере, он должен будет иметь некоторые средства для их получения, и в этом смысле он будет взломан.

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

Ответ 2

Я делюсь, как я это решил.

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

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

Как

  • guest может только SELECT
  • mod может только CREATE, INSERT, UPDATE, DELETE

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

Благодаря сочетанию пользователей и сеанса, я смог избежать угроз до сих пор. Но, конечно, уязвимость кода должна быть тщательно протестирована.

Ответ 3

Заблокируйте его. Не допускайте, чтобы г-н Злой стал корнем. Я знаю, легко?

Напишите защищенное приложение и заблокируйте сервер приложений. Соблюдайте лучшие практики там, и что большая часть работы.

Когда я настраивал базы данных в защищенной среде, единственным сервером, который был в той же физической сети с сервером базы данных, был сервер приложений. Доступ к серверу базы данных возможен двумя способами:

  • Сервер приложений
  • Console

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

Итак, заблокируйте сервер приложений. Конечно, единственное, что хуже, чем быть скомпрометированным, скомпрометировано и не знает об этом. Если вы обнаружите компромисс, вам нужно исправить эту уязвимость, если она есть. Здесь важны криминалистика (включить журналы и контролировать их). Вам также нужен план восстановления.

Предотвращение, обнаружение, исправление и восстановление имеют первостепенное значение.