Почему вы не должны позволять разработчикам приближаться к паролям root? [дубликат]
На этот вопрос уже есть ответ здесь:
Я только что наткнулся на Что-то горит в серверной; как я могу быстро определить, что это такое? . В комментариях я нашел следующую цитату:
you don't let a developer anywhere near your root passwords
Как разработчик, но также как человек, очень интересующийся вещами системного администратора, мне интересно, есть ли в этой фразе что-то большее, чем просто стандарт для всех - то есть не разглашать пароли? Комментатор заявляет, что это довольно хорошо известно сообществу системных администраторов. Это?
Я не говорю, что системные администраторы идеальны, но есть огромное количество примеров разработчиков , которые даже не должны быть разработчиками. Не говоря уже о том, чтобы иметь root-доступ к системам с критически важными данными.
Но в любом случае в основном речь идет о принятии на себя ответственности за сделанные изменения. Многим системным администраторам кажется, что разработчики будут делать что-то на серверах, и тогда они не несут ответственности за то, что сделали. Разработчики часто сосредоточены только на выполнении единственной программы / задачи, над которой они работают, и не тратят время на то, чтобы обдумывать общую картину или долгосрочное состояние системы, с которой они работают. Они не усвоили привычек о том, как безопасно вносить изменения.
Это верно не для всех разработчиков, безусловно, есть некоторые отличные разработчики, которые могут отлично поддерживать системы. Просто часто кажется, что это верно в 95% случаев.
Такие привычки, как:
- Не вносите изменения в систему, не протестировав сначала системы разработки
- Не вносите изменений, которые вы не делаете понимать (слепо гуглить и делать то, чего вы не понимаете)
- Не вносите изменения, не убедившись, что вы знаете, что системы резервного копирования работают, и как откатить все, что вы делаете.
- Не вносите изменений, которые усложнят обслуживание системы в долгосрочной перспективе. (т. е. не добавляйте технический долг)
- Не ставьте под угрозу безопасность системы
- Не изменяйте систему таким образом, чтобы это увеличило потенциальный нормативный риск (см. PCI-DSS, HIPPA, FERPA и т. Д.)
Это чрезмерное упрощение общей проблемы в ИТ-индустрии. Для одного человека просто слишком много, чтобы знать все, поэтому люди специализируются на своих знаниях. В идеале это должны делать только те, кто обладает специальными знаниями для выполнения задачи.
В реальном мире нас часто просят «носить несколько шляп» со стороны управленческих структур, которые до сих пор не знают всех сложностей работы ИТ и имеют дело со сложностями работы компании и финансами, которые они знают (а часто ИТ-персонал не знает).
Это часто приводит к такому отношению, о котором спрашивает ОП, когда две из этих ИТ-областей перекрываются. Подобно этому отношению, как сетевой человек, я знаю, насколько легко иметь подобные мысли о сисадминах, ведь часто сисадминов также просят управлять сетью.
В относительно небольшом количестве случаев они делают отличную работу, а в других относительно небольшом количестве случаев они делают ужасную работу. В большинстве случаев они делают достойную работу где-то посередине. Однако запоминаются не великие работы, а ужасные работы и, в меньшей степени, достойные работы.
Когда сетевой человек включается в микс (либо консультант по определенной причине / проект или потому что ИТ-персонал расширился и теперь включает один), они часто обнаруживают, что игнорируемые рекомендуемые передовые методы, неправильная конфигурация, дыры в безопасности и т. д. тратят много времени, пытаясь выяснить, как пустые вещи стали такими, какими они были , устранение неполадок, которые не должны возникать, и исправление неправильных конфигураций и проблем.
Но это работает в обоих направлениях и включает в себя ряд пересекающихся дисциплин. Что касается моего примера, я как сетевой человек знаю, что я не могу настроить сервер так быстро, как знающий системный администратор, и / или что, вероятно, будет ряд вещей, которые я бы пропустил или сделал неправильно (или, по крайней мере, не в лучшем путь). Дайте мне достаточно времени, и я смогу выполнить, по крайней мере, довольно приличную работу, но часто работа / работа не дают этого времени. Если у меня есть выбор, я легко предпочитаю передать его хорошему системному администратору.
но часто работа / работа не дает этого времени. Если у меня есть выбор, я легко предпочитаю передать его хорошему системному администратору. но часто работа / работа не дает этого времени. Если у меня есть выбор, я легко предпочитаю передать его хорошему системному администратору.Этот совет кажется немного устаревшим; Это происходит из эпохи, когда непослушные разработчики, у которых был пароль root, входили и вносили изменения в действующую систему.
В наши дни никто не должен вносить изменения в действующую систему, ни разработчик ] и системный администратор. Внесение изменений на сервере - это работа такой системы, как Chef или Puppet. Наша отрасль вышла за рамки концепции единственного сервера , который можно настроить вручную несколько лет назад. Теперь нам нужна либо возможность иметь множество идентично настроенных серверов одновременно, либо, по крайней мере, возможность надежно перестроить любой отдельный сервер в любой момент. Это исключает возможность внесения изменений в сервер кем-либо с паролем root, независимо от того, в какой шляпе он находится.
Итак, вернемся к вопросу: должны ли разработчики иметь пароль root? Да! Должны ли системные администраторы иметь пароль root? Да! Почему? Потому что сложные системы не могут быть эффективно диагностированы без умных универсалов, которые понимают их от начала до конца - или, по крайней мере, команды, состоящей из разработчиков, а также системных администраторов. И часть диагностики не может быть выполнена без входа на сервер и наличия прав на проверку того, что происходит (например, разработчику может потребоваться запустить strace или dtrace, чтобы понять, что на самом деле веб-сервер все время использует). Только помни - смотри, не трогай!
Должны ли системные администраторы иметь пароль root? Да! Почему? Потому что сложные системы не могут быть эффективно диагностированы без умных универсалов, которые понимают их от начала до конца - или, по крайней мере, команды, состоящей из разработчиков, а также системных администраторов. И часть диагностики не может быть выполнена без входа на сервер и наличия прав на проверку того, что происходит (например, разработчику может потребоваться запустить strace или dtrace, чтобы понять, что на самом деле веб-сервер все время использует). Только помни - смотри, не трогай! Должны ли системные администраторы иметь пароль root? Да! Почему? Потому что сложные системы не могут быть эффективно диагностированы без умных универсалов, которые понимают их от начала до конца - или, по крайней мере, команды, состоящей из разработчиков, а также системных администраторов. И часть диагностики не может быть выполнена без входа на сервер и наличия прав на проверку того, что происходит (например, разработчику может потребоваться запустить strace или dtrace, чтобы понять, что на самом деле веб-сервер все время использует). Только помни - смотри, не трогай!I have worked with a good number of developers who (rightly) have no interest in being sysadmins - they just want to Make Their Software Work. They'll take the fastest route to that end, which can often entail e.g. fixing permissions errors with chmod 777 -R .
This is, needless to say, A Bad Thing.
Поскольку эксплуатационная ответственность производственной системы обычно принадлежит системному администратору, только системный администратор должен иметь полный административный доступ к системе - это так просто.
Теперь вы можете сказать. «Ну, иногда мы вносим изменения в код, которые требуют перенастройки системы, разве у нас не должно быть доступа для соответствующей перенастройки систем?»
НЕТ
Если изменения вашего кода требуют перенастройки системы, вы должны быть в состоянии объяснить системному администратору, какие у вас требования. Таким образом, системный администратор может проверить ваши требования к изменениям и остановить их, если они могут иметь операционные последствия, которые вы - как разработчик - могли не предвидеть.
В ответ на @NathanLong я понимаю, что в небольших компаниях это иногда бывает дело. В этих ситуациях там, где администраторы и разработчики являются одними и теми же пользователями, альтернативой является разделение владения системой между несколькими людьми и обеспечение того, чтобы никто - я имею в виду НИКТО - не вносит свои собственные изменения конфигурации. Попросите другого разработчика проверить ваши изменения, а третий выполнит реконфигурацию.
Всякий раз, когда возникают сомнения, начните с планирования и анализа изменений - все остальное может составить ужасное управление изменениями
Я советую перевернуть это и поставить себя в положение другой стороны.
Итак, в том же духе:
Почему системные администраторы не должны иметь полный доступ для изменения исходный код?
Я считаю, что разработчики не должны иметь root-доступ, потому что они не обязательно знают, что они делают с точки зрения системного администрирования, и не знают (или не должен) нуждаться в этом, поэтому предоставление root существенно увеличивает риск возникновения проблем без всякой пользы. Администрирование систем - это чья-то работа.
Точно так же, как системные администраторы не должны вносить изменения в код по тем же причинам.
Попробую объяснить с помощью метафоры (я разработчик, кстати, иногда занимаюсь системным администратором)
Художник и декоратор интерьера
Допустим, разработчик - художник , и создает множество фантастических картин. Хорошо, может быть, они не фантастические, но он сделал то, что попросил его работодатель. У него это хорошо получается, так что все картины получаются хорошими.
Теперь картины нужно разместить внутри соответствующих зданий. Художник знает все о краске, но не знает, как правильно что-то закрепить на стене. Если художник все равно решит попробовать (потому что может), декоратор интерьера (системный администратор) может прийти через несколько недель и ответить следующим образом: "Что, черт возьми, здесь произошло ...?" «Все криво, это .. это должно было идти по потолку! Как, черт возьми, это прикреплено к ва .. ЭТО ЭТО КЛЕЙ!?»
Излишне говорить, что декоратор интерьера мог бы сделать лучше. Он знал, куда что поставить и как это установить. Он постоянно использовал одни и те же винты и случайные провода. Он делал это тысячу раз раньше и мог, в значительной степени, делать это с закрытыми глазами.
Короче говоря: Системный администратор знает, как обращаться со своим оборудованием лучше, чем разработчик (по крайней мере, он должен). Он будет поддерживать свою систему в чистоте и организованности и знать, как все это работает. Кроме того, многие разработчики привыкли делать вещи сисадминами (например, дома), и они БУДУТ пытаться сделать это сами, если смогут, потому что это экономит их время.
Я не могу говорить от имени сообщества системных администраторов, но могу по опыту.
Хотя они, кажется, знают свое дело, они, похоже, не уделяют внимания необходимым деталям, и случайные вещи устанавливаются / изменяются, например, в другой месяц я узнал, что на одном из наших производственных веб-серверов был установлен KVM / QEMU!
Еще меня раздражает то, что они склонны смешивать роли серверов, поэтому хост гипервизора внезапно также становится сервером мониторинга и веб-сервером. Также, похоже, отсутствует согласованность, например, 3 сервера, выполняющие одну и ту же роль, которые должны быть настроены одинаково, будут настроены 3 совершенно разными способами.
Конечно, комментатор мог просто иметь в виду, что они должны использовать SSH ключи вместо паролей :)
Обычно это делается для разделения ответственности. Введение такого лимита требуется в некоторых средах в целях безопасности. Он может принести пользу для бизнеса, отображая информацию о приложениях, которая в противном случае была бы недоступна.
Разделение обязанностей и контроль изменений.
Разделение обязанностей означает что у вас никогда не бывает ни одного человека, ответственного за одну задачу. Лучший способ реализовать это - убедиться, что ни один человек не МОЖЕТ выполнить единственную задачу в одиночку.
Что касается управления изменениями, чтобы правильно его реализовать, вы должны убедиться, что все изменения в производственных системах полностью задокументированы. Наилучший способ добиться этого - попросить разработчика выполнить раздаточный материал для системных администраторов, передать им код и документацию и позволить им выполнить развертывание.