У нас есть приложение, которое использует базу данных на моем рабочем месте. В настоящее время оно использует пароль имени пользователя для аутентификации (хотя мы могли бы использовать доверенные IP-подключения). Мы не хотим использовать доверие из-за перемещения, которое мы будем делать с IP-адресами для определенных машин, на которых находятся приложение и база данных.
В настоящее время, поскольку мы применяем имя пользователя/пароль, установленные в файлах конфигурации в приложении, у нас есть разработчики, в дополнение к моему боссу, который является администратором системы, и нам, его шести подчиненным, которые знают пароль (я являюсь начальником), поскольку каждый из нас на ротационной основе администратор, поддерживает и развертывает приложение. Таким образом, риск сохранения пароля в безопасности лежит на всех нас.
Что я наделал Недавно мы начали менять пароль чаще, но теперь я хочу, чтобы этот пароль знал только я. Я единственный, кто должен выполнять запросы к базе данных напрямую по указанию моего начальника. Даже моему начальнику не нужно знать его наизусть (может быть, в мое отсутствие и в протоколе). Я подумал о следующем:
- Создайте на сервере текстовый файл, доступный для чтения только приложению.
- Попросите разработчиков закодировать приложение так, чтобы оно обращалось к этому файлу для получения открытого текстового пароля.
- Приложение использует его для входа в систему.
Я думаю, что разработчики все равно смогут раскрыть пароль, если в приложении они сохранят код, который сделает это за них (НЕ то, что они зловещие, мы просто пытаемся коллективно оптимизировать коллективный риск)
Вопрос Есть ли лучший способ усовершенствовать этот подход, и есть ли другой способ, который я могу использовать, помимо этого?
Платформы: Linux (Ubuntu Server), PostgreSQL, Java
решение1
Старый способ Unix/Linux:
vi /etc/my_app.conf
database_ip=192.168.123.123
database_instance=db1
database_user=my_app
database_password=secret_in_plaintext
Это не решит вашу проблему немедленно, но... В будущем вы сможете развернуть точно такие же двоичные файлы приложения (war/jar)другойсерверы приложений (производство, предпроизводство, тестирование, разработка). Все они могут иметь разные базы данных (производство, предпроизводство, тестирование, разработка). Таким образом, разработчикам в конечном итоге вообще не понадобится доступ к производству.