Если администратор базы данных записывает пароли для логины приложений, или это должно быть ответственностью разработчиков / аналитиков? Под логином приложения я подразумеваю логин, который приложение использует для доступа к базе данных. Обычно по одному на приложение.
Я не имею в виду пароли учетных записей пользователей, которые создаются для пользователей системы.
Мои 0,02 доллара здесь.
Администратор базы данных должен отслеживать пароли приложений. У разработчиков никогда не должно быть производственных паролей или паролей QA, если на то пошло. Администратор базы данных должен хранить все эти ключи и передавать их системному администратору, который выполняет развертывание по мере необходимости.
Лично у меня есть небольшое веб-приложение, которое я создал несколько компаний назад, и оно мне пригодилось. Это позволяет вам помещать имена пользователей и пароли в базу данных, которая хранит пароли в безопасном зашифрованном виде. Весь доступ к приложению регистрируется для аудита SOX.
Доступ к учетным записям предоставляется через приложение, так что как администратор баз данных я могу создать учетную запись и предоставить разработчикам доступ для чтения к учетной записи в приложении, чтобы они могли видеть пароль разработчика. То же самое касается системного администратора для паролей QA и Production.
Разработчики приложений обязаны отслеживать учетные данные, необходимые для доступа к базе данных. Причина в том, что приложению НУЖЕН этот пароль для выполнения своей работы, но база данных будет продолжать работать в любом случае.
Если разработчики потеряют свой пароль, задача администратора базы данных - сбросить его и предоставить новый, но им определенно не следует хранить версии с открытым текстом. Подумайте о системном администраторе и пользователях. Системный администратор не знает паролей пользователей и отвечает только за их сброс и предоставление.
На мой взгляд, администратору базы данных не должно быть необходимости знать или вводить какой-либо пароль, который ему не нужно знать для выполнения своей работы. вы можете помочь им сбросить пароль, если он забыт, напомнить им, что он не менял / не принудительно применял цикл изменения и другие подобные периферийные функции, но вы не обязаны следить за паролем. Это также открывает вам возможность знать / иметь доступ к паролю, если вы его отслеживаете.
Я бы посоветовал, чтобы у каждого приложения был администратор приложения, который выполняет эту работу для своей команды таким образом, чтобы все это управлялось «локально». Пока комбинация учетной записи / пароля отслеживается на предмет использования и никто не получает анонимный доступ к данным, все должно работать нормально.
Как и в случае с некоторыми из вышеперечисленных сообщений, администратору базы данных действительно не следует беспокоиться о пользователе / паролях. К сожалению, когда-нибудь кому-то понадобится получить эту информацию. Мы разработали небольшое приложение, которое будет создавать пароль на основе имени пользователя по нашему собственному алгоритму. У нас, администратор баз данных, есть клиентский инструмент, и если кто-то потребует пароль, мы можем его восстановить. Если в будущем приложение будет скомпрометировано, мы всегда сможем изменить алгоритм и / или сбросить пароли. Мы используем это только для учетных записей приложений.
Мы не можем дать вам однозначный ответ, потому что разные ответы будут подходить для разных организаций. Вам действительно следует провести это внутреннее обсуждение, чтобы разобраться, кто должен нести ответственность за информацию внутри ваш организация. Если вы не можете прийти к соглашению по столь тривиальному вопросу, у вас, вероятно, есть другие проблемы, которые нужно решить. В таком случае, что мы думаю, не должно иметь никакого значения.
Это хороший вопрос, и, вероятно, на него столько же ответов, сколько у администраторов баз данных Oracle. Лично я предпочитаю не вести такой список и просто установлю новый пароль по мере необходимости - и, возможно, верну исходный пароль в зашифрованном виде, когда закончу.
Думаю, могут. Я работал с компанией около 5 лет, где у нас были четко определенные роли - разработчики приложений создавали приложения и проектировали базу данных, а администраторы баз данных тестировали базы данных, используя те логины, которые приложения использовали для получения доступа к базе данных. Они убедились, что все, что делает эта учетная запись пользователя, функционирует должным образом, и проверили производительность базы данных. Они провели больше тестов, чем мы когда-либо могли. Они также позаботились о том, чтобы все остальные пользователи были заблокированы для доступа к базе данных, поэтому все, что происходило под этим пользователем, было ограничено несколькими избранными людьми.
Поэтому я действительно считаю важным разрешить администраторам баз данных иметь эти имена пользователей и пароли. Это похоже на то, как системные администраторы имеют доступ к «тестовым» учетным записям для проверки определенных функций в сети.
Администратор баз данных или кто-либо другой не должен иметь возможности получить пароли. Сбросить возможно, восстановить нет.
Пароли должны быть хешированы или зашифрованы в базе данных и во время передачи.