Security

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

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

Мы перепрофилировали существующую машину класса рабочей станции, добавили 24 ГБ RAM и RAID-10, и все шло хорошо, пока мы не попытались добавить машину в домен.

Теперь мы начали борьбу за локальный контроль над средой разработки и тестирования. Сетевые и ИТ-администраторы высказали ряд опасений, начиная от «ESX Server это стандарт предприятия» до «серверам не разрешено находиться в клиентских виртуальных локальных сетях» и заканчивая «это не тот набор навыков, которым в настоящее время обладает местная или корпоративная ИТ-организация».

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

  1. Какие аргументы, приведенные вашими разработчиками, убедили вас в том, что вы разрешаете существование этих типов изолированных сред на предприятиях, где действуют стандартные сетевые политики и политики безопасности, которые в целом (и по понятным причинам) исключают такой тип инфраструктуры, не управляемой централизованно?

  2. Является ли это просто вопросом того, что разработчики делают техническое или бизнес-обоснование и обеспечивают управление исправлениями и AV, или это больше политическая борьба за контроль и владение?

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

  4. Если вы успешно заблокировали разработчикам возможность локального управления «серверами-изгоями» в вашей инфраструктуре, разработчики просто смирились с этим или они (или вы) перенесли среду разработки в отсоединенную виртуальную локальную сеть/совершенно отдельную сеть?

Пара предположений, чтобы ограничить рамки этого вопроса:

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

  2. Это не разночтения между Hyper-V и ESX (нас устроит любой из них, но Hyper-V был выбран, поскольку он «бесплатный» с MSDN для этих целей [да, у VMWare тоже есть бесплатные инструменты, но хорошие инструменты управления обычно не бесплатны] и им будет легче управлять местным разработчикам в «магазине Microsoft»), поэтому аргументы за или против любого из них выходят за рамки данного вопроса.

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

Ответ 1

Прежде всего, я вижу несколько причин, по которым ваши администраторы правы в том, что они так отступают:

  1. ИТ-отдел также отвечает за отчетность по таким вещам, как управление исправлениями, антивирусное ПО, соответствие стандартам pci, ежегодные (или более частые) аудиты безопасности и т. д. Дело не только в том, чтобы быть уверенным, что об этом позаботились, но и в том, чтобы иметь возможность доказать это посторонним.

  2. В качестве примера: я управляю сетью в небольшом колледже, и у нас есть физическая лаборатория с несколькими машинами для сбора данных для студенческих экспериментов. Единственное, что они делают, это собирают данные с научного прибора и распечатывают результаты (на подключенном напрямую принтере), чтобы студент мог их проанализировать и сдать преподавателю. Они никогда не выходят в интернет даже антивирусные программы и обновления Windows применяются через локальную сеть. Единственная причина, по которой они подключены к сети и на них вообще запущено антивирусное программное обеспечение, это явная цель сообщить моей программе мониторинга, что они все еще существуют и актуальны. Это глупо, поскольку на самом деле было бы более безопасно удалить сетевое подключение, но они были впервые оплачены за счет образовательного гранта, поэтому таковы мои требования к отчетности.

  3. Нравится вам это или нет, но ваш сервер dev является производственной системой с точки зрения разработчиков. Дайте ему месяц, и разработчики будут испытывать трудности с выполнением работы, если он выйдет из строя из-за процессов, которые вы установите, предполагая, что сервер доступен. Избежание/ограничение ситуаций, когда работники простаивают из-за технологических сбоев, является важной причиной, по которой предприятия все еще используют централизованные ИТ-отделы.

  4. Если «ESX Server является стандартом предприятия», вам нужно следовать этому. На данный момент существуют значительные различия между тем, как работают hyper-v, vmware, xen и другие, и нельзя полагать, что машина, созданная для одной из них, будет хорошо работать на другой. Если вы собираетесь это сделать, ИТ-специалистам в какой-то момент понадобится помощь в управлении и они не захотят переводить ее на vmware после того, как на машине будет куча мусора, который может вызвать проблемы.

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

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

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

Кроме того, похоже, что вы пытаетесь бежать раньше, чем идти. Вы хотите перестроить свой процесс разработки. Как бывший разработчик, я думаю, что это здорово. Но не стоит просто выбрасывать кучу виртуальных машин и «окружений» (т. е. dev, stage, qa и т. д.). Спланируйте, как будут выглядеть новые процессы как разработчики будут выполнять работу. Будете ли вы использовать непрерывную интеграцию? Автоматизированные сборки? Какое программное обеспечение будет использоваться для их поддержки? Будет ли разработчикам разрешено перемещать код в production или staging, или такая возможность будет только у QA? Нужен ли вам отдельный staging? Как насчет двух ветвей dev (одна для vNext, другая для исправления ошибок с vCurrent)?

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

Ответ 2

1) Какие аргументы, приведенные вашими разработчиками, убедили вас в том, что вы разрешаете существование этих типов изолированных сред на предприятиях, где действуют стандартные сетевые политики и политики безопасности, которые в целом (и по понятным причинам) исключают такой тип инфраструктуры, не управляемой централизованно?

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

В итоге мы получим серверы, управляемые людьми, чей основной набор навыков не связан с управлением серверами в сети, которые не имеют представления обо всей сети и связанном с ней проблемном пространстве. Это не просто политическая проблема «защиты» территории; в качестве банального примера представьте, что происходит, когда разработчик по какой-то причине включает DHCP. В итоге мы управляем серверами команды разработчиков за них. Разработчики постоянно раздражены тем, что мы ставим заплатки (ломаем что-то, о чем они знают, но не знаем мы), или тем, что они борются за то, чтобы мы включили функции, которые по ряду веских причин мы не хотим включать. Это быстро превращается в тупик, в котором операционная команда чувствует себя обремененной и затравленной, а команда разработчиков разочарованной и игнорируемой. Это имеет и политические последствия, ведь тогда вам придется объяснять другому отделу, почему разработчики «особенные» и почему они освобождены от сетевой политики.

2) Является ли это просто вопросом того, что разработчики делают техническое или бизнес-обоснование и обеспечивают управление исправлениями и AV, или это больше политическая борьба за контроль и владение?

Я не думаю, что разработчикам нужно делать бизнес-обоснование совершенно ясно, что разработчики должны развиваться, а для этого им нужна среда разработки определенного рода. Что касается управления патчами и AV это работа, которую разработчики не могут сделать. Просто мы не верим, что вы сделаете это правильно системные администраторы остаются системными администраторами, потому что они ничего не доверяют делать правильно, так что ничего личного. Конечно, существует очевидная политическая проблема, связанная с ощущением, что кто-то другой «делает вашу работу», но это не совсем техническая проблема и, следовательно, выходит за рамки SF.

3) Если бы у вас был выбор, вы бы предпочли взять на себя владение и поддержку аппаратного обеспечения/ОС, предоставив разработчикам права локального администратора, или позволили бы им полностью управлять ею, обеспечив при этом внедрение управления исправлениями/AV и возложив на них ответственность в случае возникновения проблем?

Ни то, ни другое по причинам, изложенным выше.

4) Если вы успешно заблокировали разработчикам возможность локального управления «серверами-изгоями» в вашей инфраструктуре, разработчики просто смирились с этим или они (или вы) перенесли среду разработки в отсоединенную виртуальную локальную сеть/совершенно отдельную сеть?

Лучший способ справиться с этой ситуацией предоставить разработчикам их среду (и контроль над ней), а затем установить воздушную завесу или использовать другой надежный метод для отделения ее от сети. По сути, именно так мы поступаем с общественным Wi-Fi. Вам нужны услуги Wi-Fi? Конечно. Вы платите за подключение к сети, мы будем управлять WAPs, но они никогда не будут касаться нашей сети. Извините, ваша потребностьлишь одна из сотен. Есть и другие проблемы, которые мы должны учитывать.

Вы не захотите говорить «нет», потому что разработчики (особенно технически умные) все равно найдут способ получить то, что хотят. Поэтому предоставьте им среду, которая соответствует их потребностям, а затем найдите способ предотвратить то, что они делают в среде разработки, от воздействия на остальную часть вашей бизнес-сети.

Я бы предоставил вам сервер с любой платформой виртуализации, которую вы хотите, в отдельной физической сети или VLAN. Доступ к вашей среде разработки будет осуществляться через единственный хост-бастион, который операционная команда будет контролировать и отслеживать. Что вы будете с ним делать это ваше дело. Он не будет поддерживаться, но мы будем предоставлять консультации и помощь, если позволит время, по вопросам администрирования сервера.

Ответ 3

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

  1. Серверная VLAN вполне может быть DMZ. В DMZ вы не помещаете ничего, что не укреплено и не защищено. Это просто машина, которую вы передали им, и они понятия не имеют, что вы с ней делали. Это также означает регулярные исправления и обновления, а следовательно, централизованное управление. Я точно не собираюсь заходить на каждый неуправляемый сервер и вручную устанавливать исправления.

  2. Кто возьмет на себя ответственность, когда все рухнет? В большинстве организаций «я отдал его разработчикам, чтобы они присмотрели за ним» не пройдет.

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

  4. Таким образом, ИТ-отдел вполне оправданно не включит этот случайный компьютер в свою серверную сеть.

Однако работа ИТ-отдела заключается в том, чтобы обеспечить ВАМ возможность нормально выполнять свою работу. Они должны убедиться, что у вас есть то, что вам нужно, когда вам это нужно. Если у вас есть программное обеспечение, которое необходимо бизнесу для работы, они должны предоставить платформу, на которой оно будет работать. Это входит в их обязанности. Но вы должны убедиться, что у них есть информация, необходимая для выполнения их работы.

Если бы вы пришли ко мне, в мою организацию, и сказали, что начинаете новый проект, я бы дал вам три виртуальные машины: Dev, Live и Staging. У вас были бы полные права администратора на Dev, и мы бы обсудили, что вам нужно для выполнения вашей работы на двух других. Если бы вам нужны были полные права администратора на них и вы могли бы это обосновать, то вы бы их получили. Развертывание виртуальных машин у нас отлажено до мелочей. VMWare делает это невероятно просто на развертывание каждой ВМ уходит всего около 5 минут. Похоже, ваш ИТ-отдел страдает от того, от чего страдает практически каждый ИТ-отдел крупной компании. Как человек, который каждый день имеет дело с чужими ИТ-отделами, я вижу это постоянно. И это расстраивает.

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

Схожие статьи

Security

Как я могу использовать rsync с файловой системой FAT?

Security

Целесообразно ли компьютерам одного домена взаимодействовать друг с другом

Security

Легко ли подделать IP-адреса?

YubiKey: что это такое? Обзор аппаратного ключа безопасности
Security

YubiKey: что это такое? Обзор аппаратного ключа безопасности