Отказано в доступе для внесения изменений непосредственно на работающий сайт

Не воспринимайте это лично или как оскорбление. Вероятно, это никак не связано с вашей компетентностью как разработчика.

Есть определенные обязанности, которые зарезервированы для менеджеров, руководителей групп и старших; основная ответственность заключается в доступе к живым/производственным системам. Предоставление доступа к критически важной системе младшему разработчику, скорее всего, противоречит политике компании и в целом не является хорошей практикой. Это хорошая идея, чтобы ваш код прошел через более старшего разработчика, просто чтобы дважды проверить код и убедиться, что ничего не сломается. Компания снижает вероятность того, что плохой код попадет в производство, ограничивая количество людей, которые могут его развернуть.

Вы предполагаете, что старший разработчик имеет право предоставить вам доступ к производственному серверу.

Во многих средах разработки это не так. Я работаю с компаниями, где ни один из разработчиков не имеет доступа к серверной части производственных серверов. Доступ к серверам на уровне SSH есть только у группы безопасности и группы системного администрирования. Разработчики могут использовать автоматизированную систему развертывания для отправки изменений на рабочие серверы, но только после того, как группа безопасности рассмотрит предложенные изменения кода и объединит соответствующую ветвь с производственной ветвью.

Золотое правило безопасности, как говорит Питер, гласит: если у вас нет доступа, вас никогда нельзя винить.

То, что (на практике) они могут предоставить вам такой доступ, не означает, что они должны это делать . Вся чушь в сторону: есть причина, по которой компании проводят различие между «младшими» и «старшими». Ожидается, что вы, как младший разработчик, сделаете много ошибок и оплошностей. Ни один из вышестоящих лиц, которых вы описываете, ни ваш руководитель, ни их боссы, ни боссы их боссов не рискнут платить по ипотечным кредитам в обмен на то, что вы почувствуете себя в большей безопасности на своем месте.

При всем уважении, любой дурак с FTP-доступом может скинуть файлы на сервер. Для этого даже не нужен технический пользователь — просто кто-то с копией Filezilla, именем хоста, именем пользователя и паролем. Многие компании сталкивались с перебоями в работе из-за того, что младшим разработчикам не терпелось проявить себя. Таким образом, они дают вам доступ к развертыванию «под запись», но что мешает вам попытаться исправить ошибки «не под запись» — вещи, которые вы, возможно, не знаете, как отменить — и сделать все еще хуже? ? Почему они должны вам доверять? Прошло всего четыре месяца, и требуется гораздо больше времени, чтобы почувствовать стиль работы сотрудника. Ни у кого действительно нет времени объяснять вам это, поэтому вы не получили ответа.

В этот момент примите успокаивающую таблетку. Делайте все возможное, выполняя возложенные на вас обязанности. Сияй тем, что у тебя уже есть. Примерно через год вы увидите, как за вашей спиной в дверь входит больше младших разработчиков; и если вы хорошо обращали внимание на работе в тех случаях, когда дерьмо бьет по вентилятору, и люди пытаются отвести от себя негативное внимание, вы поймете эту парадигму намного, намного лучше.

Как у человека, работающего в сфере ИТ-безопасности, есть очень веские причины, объясняющие поведение вашего старшего. Два наиболее важных понятия:

• Разделение обязанностей (SOD)
• Наименьшие привилегии

Распределение обязанностей

Принцип SOD гласит, что несовместимые обязанности должны выполняться двумя или более лицами , чтобы свести к минимуму сговор и уязвимости безопасности. Разработка кода (то, чем вы сейчас занимаетесь) и выпуск кода (что вы хотите делать) в большинстве случаев являются несовместимыми обязанностями. Разработчик, имевший доступ к рабочей среде, мог разработать код, внедрить вредоносный код, такой как бэкдоры или логические бомбы, в законный код, а затем выпустить код в рабочую среду, оставаясь при этом незамеченным. Такая деятельность чрезвычайно рискованна для бизнеса, и большинство компаний не может себе позволить потерю критически важных ИТ-ресурсов. Если обрабатываемые данные чрезвычайно конфиденциальны, выживание бизнеса может оказаться под вопросом.

Наименьшие привилегии

Принцип наименьших привилегий гласит, что пользователь должен иметь только минимальные привилегии, необходимые для выполнения своих рабочих обязанностей, и не более того . Эта концепция также тесно связана с триадой безопасности ЦРУ . Следование такой практике сводит к минимуму риск злоупотребления ИТ-ресурсами пользователем или получения неавторизованных прав администратора/суперпользователя над системой, где он или она может делать практически все, что захочет, например:

1. Уничтожить данные — нарушение целостности и потенциальной доступности

2. Запретить доступ законным пользователям — нарушение доступности

3. Раскрытие данных неуполномоченным сторонам - нарушение конфиденциальности

Ваша работа в качестве младшего разработчика заключается в написании исходного кода. Похоже, это не включает выпуск в PROD. Таким образом, ваш старший следует рекомендациям по безопасности, отказывая вам в доступе.

Как сделать бизнес-кейс в качестве резервной копии для экстренных изменений в PROD

Сказав вышеизложенное, должен быть резервный человек, который может делать живые релизы в случае, если ваш старший недоступен. На непрерывность бизнеса влияет, если только 1 человек может выполнять конкретную задачу, что является важным риском для наиболее разумного управления. Однако, прежде чем представить свой случай, вы должны проверить системы ведения журналов, используемые для аудита изменений в производственной среде.. Если у вас этого нет, или если у вас есть, но это не отслеживается, или отслеживается, но без плана реагирования на инциденты, чтобы реагировать на обнаружение несанкционированных изменений в производстве, то в вашей компании есть более серьезные проблемы. Если вы можете гарантировать руководству, что запросы на экстренные изменения, сделанные разработчиками, надежно регистрируются, чтобы изменения можно было просмотреть, а несанкционированные изменения были отслежены до ответственного лица, то вероятность того, что вы получите доступ к PROD, значительно возрастет. Чтобы журнал аудита был определен как безопасный, должны быть выполнены следующие характеристики:

1. Доступ к журналу предоставляется минимальному количеству пользователей, которым необходимо знать его содержимое. - Конфиденциальность

2. Записи журнала блокируются после фиксации, поэтому последующие изменения не могут изменить ранее записанные записи журнала. - Честность

3. Уникальный идентификатор пользователя связан с каждым пользователем, который вносит изменение, вместе с отметкой времени, чтобы указать, когда было сделано изменение. - Безотказность

Чтобы лучше понять, что может произойти, когда права доступа небрежны, взгляните на то, что произошло с OP в этих двух вопросах:

1. Я сделал возможную ошибку в живом проекте на работе, как справиться с этим беспорядком?

2. Письменное предупреждение от работодателя за выполнение указаний менеджера по развертыванию исправления непосредственно в рабочей среде.

Поскольку вы все еще являетесь младшим разработчиком, ваш старший разработчик, возможно, недостаточно доверял вам, учитывая риски ошибок в реальной производственной среде. Это не следует принимать на свой счет, так как ваш опыт будет расти со временем, проведенным в вашей компании. Вам также должно быть немного утешительно знать, что без доступа, если что-то пойдет не так, вы не заподозрите себя, учитывая, что вы никогда не смогли бы получить доступ к производству, даже если бы захотели.

Это могут быть регламенты.

В моей работе разработчика мне категорически запрещено иметь доступ к производственной среде. Это мера безопасности. Те, кто создает программное обеспечение, не должны быть людьми, запускающими его в производство, потому что тогда есть вероятность конфликта интересов.

Обычно тот, у кого есть доступ, несет ответственность, если что-то пойдет не так.

В идеале, поскольку старший одобряет изменения и внедряет их, его обвинят в возникновении проблем.

Теперь он может попытаться дать вам доступ, но это не снимет с него вины. Вместо этого он позволит вам делать все, что вы хотите, и если вы облажаетесь, это все равно его вина.

Это должно объяснить, почему он не хочет давать вам доступ.

Что мне нужно учитывать, прежде чем запрашивать доступ к рабочему сайту?

Главное, что вам нужно учитывать, это риск того, что чем больше вы настаиваете на доступе, тем больше беспокойства, что вы слишком стремитесь получить его и каким-то образом злоупотребите им. Можно ли вам действительно доверять использование прямого доступа только в экстренных случаях, или вы можете начать обходить обычные проверки без необходимости?

Как сделать экономическое обоснование, чтобы мне был предоставлен доступ к PROD в качестве резервной копии на случай, если мой коллега внезапно будет недоступен в интересах обеспечения непрерывности бизнеса?

Вам нужно знать, что делать, если ваш коллега внезапно недоступен и необходимы изменения на сервере. Если вы не знаете, вы должны спросить об этом сейчас, а не ждать, пока возникнет ситуация.

Предоставление вам прямого доступа — это только один из возможных ответов, и не особенно вероятный. Например, может быть один или несколько заместителей, которые не участвуют в обычном потоке, но при необходимости могут внести изменения. А может, перемены могут подождать вашего коллегу, или замену.

Если вы попытаетесь превратить это в бизнес-кейс для прямого доступа, это может помешать решению реальной проблемы незнания того, что делать в этой ситуации.

Я думаю, вам нужно глубже вникнуть в свои рассуждения и выяснить, какую пользу это приносит клиенту. Попросите вашего начальника объяснить, что можно отложить применение обновлений. Возможно, клиенты это понимают, или природа их бизнеса не так чувствительна ко времени. Убедитесь, что ваш босс понимает риски.

В худшем случае клиент ожидает/отчаянно нуждается в исправлении. Вы должны сказать им, что этого не произойдет, потому что ваш босс недоступен? Если нет, то какую ложь он предлагает.

Кто-то в компании должен пострадать от последствий, и я не думаю, что это должны быть вы, но вы будете вестником плохих новостей.