Вопрос по java, mysql, passwords – Лучшая практика для хранения пароля базы данных

15

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

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

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

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

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

Какие-либо предложения? Я чувствую, что упускаю что-то простое.

Спасибо

Если вы не введетеpassphrase каждый раз, когда вы запускаете сервер, Mr. Evil также не будет этого делать, что означает, что любой, имеющий доступ к физическому расположению серверов, сможет получить доступ. byrondrossos
Таким образом, вы хотите, чтобы ваше приложение имело доступ к учетным данным, а хакеру, получившему root-доступ к этой машине, было отказано в доступе? liquorvicar

Ваш Ответ

3   ответа
3

Build API, to query the authentication details from a foreign domain. Use public key, and private key to read through the details.

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

подобно

guest can only to SELECT mod can only CREATE, INSERT, UPDATE, DELETE

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

With the combination of users and session, I have been able to escape the threats so far. But ofcourse the code vulnerability have to be tested thoroughly.

5

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

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

2

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

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

Application server Console

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

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

Профилактика, выявление, исправление и восстановление имеют первостепенное значение.

Похожие вопросы