мы оцениваем использование службы агента веб-развертывания msdeploy для автоматического развертывания на наших производственных серверах.
Единственное, о чем мы не можем узнать, - это потенциальное воздействие на безопасность.
Во-первых, наши веб-серверы, конечно, защищены (за брандмауэрами и балансировщиками нагрузки), поэтому извне разрешен только HTTP-трафик.
Тем не менее, агент веб-развертывания работает интегрированно с IIS (единственное, что находится снаружи), поскольку он доступен через http (s). Поэтому мы опасаемся, что потенциально возможно получить доступ к агенту через веб-сайты, размещенные на этом IIS, и тем самым получить доступ для чтения и записи ко всем нашим веб-сайтам.
Насколько безопасен msdeploy для использования в производственных средах?
Обновление: производственный веб-сервер работает под управлением IIS7.
Прошло некоторое время с тех пор, как я использовал его, и я использовал его только с IIS 6, который не включает часть веб-управления. Вы можете изменить URL-адрес и порт удаленного управления и заблокировать его на внешнем брандмауэре. Посмотри это: Настройка и защита удаленного сервиса. Его основным механизмом безопасности, по-видимому, является безопасность учетной записи пользователя, но, как вы сказали, все это в IIS, поэтому уязвимость IIS может сделать меры безопасности бесполезными, пока не будет исправлено. Только по этой причине я бы не решился разрешить обновление веб-контента из Интернета, но это зависит от требований безопасности вашей организации и потребностей вашего веб-разработчика.
Чтобы избежать раскрытия службы веб-развертывания в Интернете, вы можете сделать следующее:
Если по-прежнему необходимо иметь функциональность веб-развертывания, доступную непосредственно из Интернета, скажите, все ли ваши веб-разработчики работали удаленно (я не могу представить, зачем это было бы необходимо прямо с широко распространенным использованием VPN), у вас может быть двухэтапный процесс развертывания, в котором вы настраиваете изолированную DMZ с полем IIS 7 с поддержкой веб-развертывания в нем (отдельно от DMZ вашей веб-фермы) и позволяете вашим веб-разработчикам подключитесь только к этой DMZ из Интернета для удаленного развертывания изменений. Затем вы можете внутренне подключиться к этому узлу и развернуть его на остальных своих веб-серверах после проверки изменений, тестирования и т. Д. Даже этот метод небезопасен - злоумышленник может в конечном итоге поставить под угрозу функциональность веб-развертывания, введя некоторые вредоносный код без вашего ведома, и вы можете бессознательно внедрить его в производственную среду.
Простой ответ. ДА, все, что запущено на любом компьютере, открывает векторы атак. Всегда следует предполагать, что в программном обеспечении есть уязвимости. Снижение риска является ключевым фактором, ограничивающим доступ к сетям, пользователям, компьютерам, IP-адресам и т. Д. Также проверьте физический доступ.
Вы также можете ограничить время, в которое могут происходить обновления, если ваш брандмауэр может обрабатывать правила для определенного времени дня.
Я бы рекомендовал ограничить количество пользователей на вашем веб-сервере (ах), то есть тех, кто может выполнять обновление. (Вы, вероятно, уже сделали это). Затем я бы использовал брандмауэры, чтобы ограничить, какие сети (IP-адреса) имеют доступ к интерфейсу управления. Тогда, если бы поддерживалась поддержка, я разрешил бы обрабатывать обновления только в рабочее время (через правило брандмауэра). Обратите внимание, что вы всегда можете попросить администратора брандмауэра изменить правило для экстренного обновления. Наконец, я бы стал следить за известными уязвимостями в агенте веб-развертывания и устранять их в дальнейшем или отключать до тех пор, пока исправление не будет реализовано.