Должны ли мы разрабатывать код на локальной машине в VLAN?

Question

По соображениям безопасности мы не сможем использовать IIS на наших локальных машинах. Я уверен, что многие из вас столкнулись с той же проблемой, так как вы решили ее? Вот варианты, которые мы рассматриваем:

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

2. Не использовать VLAN и использовать только сервер разработки ASP.NET, который поставляется с Visual Studio, а затем развертывать этот код на сервере разработки. Это имеет недостаток, заключающийся в невозможности репликации производственной среды во время локальной разработки. Кроме того, как минимум одному разработчику нужен IIS для разработки ГИС, поэтому он не может разрабатывать локально.

Спасибо за комментарии и предложения, которые у вас могут быть!

Answer 1

Разрабатываем на серверах с использованием удаленного рабочего стола. Предоставляет вам необходимые возможности и позволяет сразу настраивать и тестировать приложения в нужной ОС.

Answer 2

Судя по комментариям, вам кажется, что вам нужна изолированная среда. Комбинация маршрутизатора / брандмауэра и леса AD с односторонним доверием [1] должна позволить вашим (разрабатываемым) системам получать доступ к нужным вам корпоративным ресурсам, но не наоборот.

Сетевая часть может быть реализована с помощью VLAN, но если IIS представляет собой большую проблему, VLAN вряд ли будет достаточно изолирована.

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

---

[1] Т.е. Развитие AD Forest доверяет корпоративному AD Forest, а не наоборот.

Answer 3

Создание локальной виртуальной машины с использованием виртуального ПК. Не предоставляйте этой виртуальной машине сетевое соединение.

Редактировать: Обратите внимание, что виртуальная машина без сети может быть безопасно доступна по сети двумя способами:

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

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

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

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

Технически и # 1, и # 2 также делают виртуальную машину доступной по сети, но сама виртуальная машина не видит сеть (вместо этого машина, на которой размещена виртуальная машина, видит сеть).

Answer 4

Вы можете настроить IIS с ограничениями IP-адресов, в том числе на основе белого списка. Например. ограничиться кустом 127.0.0.1.

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