Trench Tales: Реструктуризация устаревшей сети с помощью VLAN

Законодательство об Общем регламенте ЕС по защите данных (GDPR) начало по-разному влиять на предприятия и организации, и мы рассмотрели некоторые из них в этой серии статей на нашем сайте TechGenix. В то время как большая часть нашего освещения была сосредоточена на возможном влиянии GDPR на североамериканские компании, даже наши дальние соседи на европейском континенте видят последствия этого закона по-разному.

Один из наиболее интересных примеров, с которыми я столкнулся в последнее время, — это пример моего коллеги Мартина Урвалека, который проживает в Вене, Австрия, и управляет ИТ в государственной компании. Мартин работает в сфере ИТ почти два десятилетия и ранее возглавлял отдел настольных компьютеров и магазинов в компании в Гамбурге, Германия. Когда Мартин пришел на свою новую должность, он столкнулся с рядом задач, одна из которых заключалась в обеспечении соответствия их компьютерной сети требованиям GDPR, а другая — в обеспечении правильной работы их сети. Проблема, с которой он столкнулся в первую очередь, была интересной: сеть компании состояла из двух отдельных сетей, расположенных в разных местах и соединенных межсайтовым соединением, но IP-адреса обеих сетей были выделены из одного и того же класса B. пул адресов. Как мы вскоре увидим, это создало проблему с точки зрения соблюдения GDPR. Мартину было поручено найти решение, и оказалось, что оно заключается во внедрении старой, но проверенной сетевой технологии под названием VLAN, что означает виртуальная локальная сеть или виртуальная локальная сеть, и использовании этой технологии для сегментации сети компании.

Недавно я обменялся электронными письмами с Мартином, чтобы узнать больше о проблемах, с которыми он столкнулся во время своего проекта по миграции сети, и о том, как он использовал VLAN для создания подходящего решения, которое он сейчас внедряет. Я делюсь его историей здесь, чтобы читатели, столкнувшиеся с подобными проблемами, могли получить некоторые рекомендации. Поскольку компании постоянно сливаются и приобретают друг друга, вы никогда не знаете, когда вы, как ИТ-специалист, столкнетесь с такой проблемой. Обратите внимание: поскольку английский не является родным языком Мартина, мне пришлось несколько отредактировать его ответы, чтобы внести ясность.

МИТЧ: Привет, Мартин, насколько я понимаю, вы работаете над каким-то проектом миграции сети, который пытается сегментировать одну сеть класса B. Какова мотивация для принятия этого вызова?

МАРТИН: Причина двоякая. Во-первых, запуск 50 серверов и 150 клиентов в одной сети означает много основного шума из-за природы TCP/IP, поскольку все широковещательные рассылки уровня 2 распространяются на всю сеть. Кроме того, с точки зрения безопасности запуск всех клиентов и серверов в одной зоне безопасности является грубой небрежностью. Новые тенденции в сетях движутся в направлении «не доверять никому», и даже в государственной корпорации, где я работаю, которая является очень консервативной корпорацией, появляются первые облачные приложения, где мы точно не знаем, что они делают на клиент. Это увеличение риска безопасности, с которым нам нужно справиться!

МИТЧ: Итак, у вашей компании есть два сайта (назовем их А и Б), но адресация в обеих сетях назначается из одной и той же сети класса В?

МАРТИН: Именно так, и это большая проблема, поскольку трафик между сайтами проходит по темному волокну, которое не зашифровано в общедоступных местах. А GDPR требует шифрования всего трафика, выходящего из ваших собственных ресурсов.

МИТЧ: Итак, какую стратегию или процесс вы планируете использовать для выполнения этой миграции?

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

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

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

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

МИТЧ: Зачем использовать брандмауэры, а не просто маршрутизаторы на концах вашей связи между сайтами?

МАРТИН: Основная идея заключается в том, что у меня будет два сайта, соединенных через туннель IPsec, и я хочу сегментировать свою сеть с обеих сторон. Дополнительным преимуществом использования брандмауэра по сравнению с маршрутизатором является то, что я могу легко управлять межсегментным трафиком, например, разрешая всем ПК использовать все принтеры во всех сегментах, но не подключая ПК к ПК. Или заблокировать прямой клиентский трафик к базе данных, поскольку пользователи используют приложения, работающие на сервере. Другими словами, идея состоит в том, чтобы ограничить определенный трафик сегментом сети. Таким образом, если программа-вымогатель атакует, например, затрагивается только один сегмент, поскольку трафик между сегментами блокируется.

МИТЧ: Итак, как только все хосты были перемещены во виртуальные локальные сети, вы затем подключаете сайты через соединение IPsec?

МАРТИН: Нет, канал IPsec уже установлен еще до начала сегментации. Например, мы недавно создали наш первый сегмент с новым офисом, и теперь мы изучаем, что мы должны учитывать для следующих сегментов. Я надеюсь, что к концу года я сделаю 50 процентов.

МИТЧ: Есть ли другие трудности, с которыми вы ожидаете столкнуться на этом пути?

МАРТИН: Я ожидаю много интересных открытий, потому что качество нашей документации зависит от того, кто ее поддерживал. Существует множество вещей, таких как контроллеры кондиционеров, устройства безопасности, системы запирания и т. д., которые не обслуживаются ИТ; мы только что предоставили IP-адрес и добавили правило внешнего брандмауэра. Но я не ожидаю ничего, что могло бы остановить наш проект. Это может просто добавить задержки и дополнительные усилия.

МИТЧ: Какой совет вы могли бы дать сетевым администраторам, столкнувшимся с подобной проблемой миграции сети?

МАРТИН: Честно говоря, я надеюсь, что ни у кого из читающих это больше нет такого сетевого дизайна, это же 1980-е! Я бы посоветовал связаться с кем-то, у кого есть опыт в проектировании сетей, и позволить им создать новый дизайн. Как только у вас появится целевой дизайн, спланировать миграцию будет несложно. На самом деле, если бы мне не нужно было повышать нашу безопасность в рамках моего проекта, я, вероятно, мог бы делать все, используя только свое текущее оборудование, поэтому часто нет необходимости вкладывать средства в новое оборудование для чего-то подобного. Таким образом, финансовые последствия заключаются в том, чтобы просто нанять хорошего сетевого дизайнера.

МИТЧ: Спасибо, Мартин, что нашли время ответить на все мои вопросы! И удачи в завершении миграции!

МАРТИН: Добро пожаловать и спасибо.