Что вы думаете о доступе к производственной или действующей системе для не-системных администраторов?
Считаете ли вы, что этот доступ должен быть предоставлен с номинальными именами пользователей?
Как вы думаете, следует ли разрешить доступ к файлам журналов или базам данных?
Применить Принцип наименьших привилегий. Если им нужен доступ для выполнения работы, вы предоставляете им доступ. Но вы даете только тот доступ, который им нужен. Если им не нужен доступ для выполнения работы, вы не даете им его.
Это не только защищает человека (нельзя обвинить в превышении его / ее границ), но также защищает организацию в случае взлома учетной записи пользователя.
Что касается того, почему им нельзя давать такой доступ ...
Я согласен с вышеизложенным, но хочу добавить, что общие учетные записи пользователей - это вообще не лучшая идея. Вы не можете отследить, кто что сделал, в журналах, и вы не можете контролировать, кто кому и какие пароли передает.
Настройте группу с особым контролем доступа и предоставьте каждому неадминистратору, которому нужен доступ к системам, свою собственную учетную запись, с доступом только с тем доступом, который им необходим для выполнения своей работы.
С точки зрения администраторов баз данных, доступ к производственным системам для пользователей должен быть строго ограничен, в том числе и для разработчиков. Пользователи должны иметь возможность видеть только те данные, которые им нужны, и в идеале это должно быть предоставлено через представления, а не прямой доступ к таблицам.
Разработчики также должны иметь возможность видеть данные в производственной среде, но не изменять таблицы. Любые изменения должны быть выполнены сначала в тесте (или в разработке), а затем в сценарии и запущены в производственной среде администратором баз данных.
Эвристика довольно проста:
Их уволят, если система облажается?
Вы?
Если ответы - «нет» и «да», как в большинстве организаций, то ответ очевиден.
Для разработки, если возможно, предоставьте им копию действующей системы и предоставьте способ по желанию отправить изменения базы данных обратно в разрабатываемую копию. Вы обнаружите, что многие из ваших разработчиков будут более продуктивными, имея доступ к «реальным» данным, и вы будете чувствовать себя в безопасности, зная, что у них нет доступа к действующей системе.
Я также считаю, что нет реальной причины хранить определенные конфиденциальные данные за пределами транзакции. Например, транзакции по кредитной карте ... захватить данные и отправить их в систему обработки продавца ... но не сохранять их в базе данных, вместо этого просто сохраните последние 4 цифры карты и идентификатор транзакции от продавца. система. Таким образом, когда обнаружен эксплойт и создано исправление (я знаю, что такого никогда не бывает), у вас есть уверенность в том, что никто не мог украсть какие-либо из этих данных из вашей базы данных.
Я полностью согласен с ответом Х. Брайана Келли о том, что Принцип наименьших привилегий.
Но я хотел бы отметить, что он идет рука об руку с моей домашней выпечкой. Принцип совместной ответственности за ошибки. То есть любому, у кого есть возможность администрировать сервер, также должен быть добавлен свой номер телефона в список дежурных по вызову сервера. Так что теперь этот не-системный администратор также может знать радость телефонного звонка в 2 часа ночи «что-то сломалось».
В зависимости от критичности производственного сервера, да, я думаю, что не-системный администратор должен использовать вторую привилегированную учетную запись для своего доступа к системе - точно так же, как я (например, я использую одну учетную запись для своей ежедневной электронной почты и для обычных пользователей; еще одно для моих действий системного администратора). Теперь пользователь должен явно перейти на более высокий уровень конфиденциальности, и это поможет предотвратить ошибки.
И да, есть случаи, когда должен быть разрешен доступ к журналу (только просмотр). Очевидно, когда этому человеку нужно увидеть результат, чтобы лучше выполнять свою работу, вам нужно склониться в сторону предоставления доступа. Подумайте об этом еще раз, если журнал содержит действительно конфиденциальную информацию, такую как личные или финансовые данные клиентов.
Вы можете подумать о некотором уровне формального / неформального обучения аспектам безопасности привилегированного доступа всякий раз, когда вы его предоставляете.
Да. Полный root-доступ (предоставляется через sudo ALL). И они также должны быть добавлены в ротацию по вызову.
Во многих компаниях есть один системный администратор, который круглосуточно дежурит даже по вопросам приложений. Некоторым компаниям повезло, и у них их две. Совершенно неразумно ожидать, что всю повседневную работу будет выполнять один человек. и реагировать на системные предупреждения в любое время суток.
Однако во многих компаниях есть достаточное количество разработчиков, которые несут ответственность за код приложения, работающий в системах. Многие из них могут даже иметь опыт проведения операций.
Нет, они не должны нести ответственность за почтовую систему, если она напрямую не связана с приложением, над которым они работают. Но должен быть четкий список вещей, о которых можно быстро подумать, чтобы они могли либо собрать информацию для системного администратора, либо даже решить сами, если достаточно просто.
Работа каждого - способствовать развитию бизнеса.