Как мне избежать хранения пароля базы данных в виде открытого текста в исходном коде?
В разрабатываемом веб-приложении я использую наивное решение при подключении к базе данных:
Connection c = DriverManager.getConnection("url", "username", "password");
Это довольно небезопасно. Если злоумышленник получает доступ к исходному коду, он также получает доступ к самой базе данных. Как мое веб-приложение может подключиться к базе данных, не сохраняя пароль базы данных в виде открытого текста в исходном коде?
Ответы 6
Вы можете сохранить строку подключения в файле Web.config или App.config и зашифровать раздел, в котором она находится. Вот очень хорошая статья, которую я использовал в предыдущем проекте для шифрования строки подключения:
http://www.ondotnet.com/pub/a/dotnet/2005/02/15/encryptingconnstring.html
Я могу порекомендовать эти техники .NET-программистам:
- Зашифровать пароль \ строку подключения в файле конфигурации
- Настроить доверенное соединение между клиентом и сервером (например, использовать Windows auth и т. д.)
Вот полезные статьи от CodeProject:
В .NET принято хранить строки подключения в отдельном файле конфигурации.
На этом основании файл конфигурации может быть зашифрован.
Если вы используете Microsoft SQL Server, все это становится неактуальным, если вы используете учетную запись домена для запуска приложения, которое затем использует доверенное соединение с базой данных. В этом случае строка подключения не будет содержать никаких имен пользователей и паролей.
Если я не упустил момент, соединение должно управляться сервером через пул соединений, поэтому учетные данные для подключения хранятся на сервере, а не в приложении.
В дальнейшем я обычно использую соглашение, согласно которому интерфейсное веб-приложение (в DMZ) общается с БД только через веб-службу (в домене), тем самым обеспечивая полное разделение и повышенную безопасность БД.
Кроме того, никогда не давайте учетной записи db привилегии сверх необходимых.
Альтернативный подход - выполнять все операции через хранимые процедуры и предоставлять пользователю приложения доступ только к этим процедурам.
Предполагая, что вы используете MS SQL, вы можете воспользоваться преимуществами проверки подлинности Windows, которая не требует имени пользователя / пароля в исходном коде. В противном случае мне пришлось бы согласиться с другими плакатами, рекомендующими шифрование app.config +.
- Создать пользователя O / S
- Поместите пароль в переменную среды O / S для этого пользователя
- Запустите программу от имени этого пользователя
Преимущества:
- Только root или этот пользователь могут просматривать переменные среды O / S этого пользователя
- Переживает перезагрузку
- Вы никогда не проверяете случайно пароль в системе управления версиями
- Вам не нужно беспокоиться о том, чтобы испортить права доступа к файлам
- Вам не нужно беспокоиться о том, где вы храните ключ шифрования
- Работает x-platform