Автор: Алексей Спирин. Рубрики: Безопасность. Опубликовано: Июнь 16th, 2009

Вчера общался с очередным кастомером, разговор зашел про сетевую архитектуру вообще и необходимость выделенного модуля управления в частности. Хотя обычно специалисты заказчика верят, что Cisco SAFE — наше всё, но большинство все-таки хотели бы услышать четкие доводы «за» разделение сети на модули с соответствующим увеличением количества оборудования и т.д.
Если говорить про модуль управления (МУ), то какие варианты у нас есть?
1) Не делать выделенный МУ и не защищать сервера управления. Я думаю риски и недостатки этого «метода» всем очевидны
2) Совмещать МУ с ЦОД или фермой серверов, защищая таким образом все сервера одним межсетевым экраном.
3) Выделить МУ в отдельный сетевой модуль, с парой отказоустойчивых межсетевых экранов, как рекомендует SAFE
Что дает нам последний вариант? Итак:
1) Решает проблему с безопасным управлением. Актуально, когда рабочее место администратора находится в офисной сети и трафик до серверов управления проходит через условно недоверенную среду. Есть такая вещь, как требования безопасности по защите управляющего трафика. Классический telnet, SNMP, некоторые другие протоколы не шифруют управляющие команды, поэтому использовать их в распределенной сети не рекомендуется, учитывая возможность прослушивания трафика или Man-in-the-Middle атак (например dns- или arp-спуфинг). Решением может быть либо организация Out-of-Band управления, что дорого, малореализуемо и ничего не гарантирует, либо использование VPN-доступа в модуль управления. Да, да. VPN-доступ внутри корпоративной сети. Звучит, как минимум, непривычно, но если посмотреть как это работает и учесть преимущества данного варианта, то можно оценить элегантность решения. На межсетевых экранах модуля управления настраивается обычный ezVPN (для Cisco), на рабочей станции администраторов устанавливается VPN-клиент. Для начала работы нужно просто щелкнуть по ярлыку и ввести пароль, хотя можно и без последнего обойтись и, вуаля, трафик управления идет безопасным способом в МУ через виртуальную сетевую карту VPN-соединения, офисный трафик работает через обычную сетевую карту.
3) Решает проблему с резервированием управления серверной фермой. Обычно «правильные» сервера имеют интерфейсы удаленного OOB-управления (iLO в случае HP и RSA у IBM), которые рекомендуется подключать к другому сетевому оборудованию, нежели основные интерфейсы. Таким образом, если по какой-либо причине серверная ферма не будет доступна, вы можете получить доступ к серверам через OOB-интерфейсы в модуле управления и разобраться, что происходит.
4) Упрощает change management:
a) оборудование серверной фермы/ядра и оборудование МУ разнесено, соответственно шансы «уронить» критичные информационные системы в процессе рядовой переконфигурации значительно меньше. Те, кому-когда либо приходилось править большие списки доступа меня поймут, вероятность сделать механическую ошибку в написании IP-адресов достаточно велика, даже для опытных инженеров.
б) если вы подключаете сервера управления к тому же МЭ, что и остальные сервера, или даже просто к центральному коммутатору, то вы не можете создавать списки доступа на «входе» (с точки зрения классической идеологии настройки МЭ), у вас просто нет этого входа. Вам приходится настраивать ACL на «выходе» интерфейсов, смотрящих в сегменты управления. А если этих сегментов и, соответственно, интерфейсов десятки? Удовольствие поддерживать такую конфигурацию тоже не велико. В случае с выделенным МЭ вы можете работать с одним единственным списоком доступа, что с использованием object-group достаточно удобно.
5) Можно упомянуть и прочие «стандартные» достоинства такой схемы — отличную масштабируемость, безопасность (поддерживать безопасность для каждого модуля в отдельности проще и эффективней, чем пытаться обеспечить безопасность для всей сети сразу), отказоустойчивость и т.д. и т.п.
По этой теме пока все, если есть вопросы по сетевой архитектуре — задавайте :)

Поделиться

Опубликовать в Facebook
Опубликовать в Google Buzz
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Мой Мир
Опубликовать в Одноклассники
Опубликовать в Яндекс

Мы в социальных сетях

Читать ProITClub в TwitterЧитать ProITClub в RSSЧитать ProITClub в п&##1086;чтовой подпискеЧитать ProITClub в Живом ЖурналеЧитать ProITClub в LinkedInЧитать ProITClub в LinkedIn
Вы можете оставить комментарий, или поставить трэкбек со своего сайта.

Написать комментарий

Вы должны войти чтобы добавить сообщение.