Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Исследование проблем безопасности при синхронизации данных и управлении средой виртуализации в комплексе территориально разнесенных ЦОДов.

Исследование проблем безопасности при синхронизации данных и управлении средой виртуализации в комплексе территориально разнесенных ЦОДов.

Изучение основ обеспечения информационной безопасности IT-системы, ее стандарты. Метрики измерения защищенности и типизация угроз. Классификация автоматизированных систем по уровню обслуживания. Характеристика структуры и функции Центра обработки данных.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 30.08.2016
Размер файла 69,9 K
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Страница:

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

Возможны две основные стратегии использования распределенных ЦОД:

· «активный/активный» - инфраструктурные приложения и сервисы распределены между площадками, и пользователи работают с ближайшим ЦОД;

· «активный/пассивный» - при которой приложения централизованы, и пользователи работают с основным узлом. В случае отказа системы, нагрузка автоматически переключается на резервный ЦОД.

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

Крупные банки и другие коммерческие организации в силу особенностей своих отраслей прорабатывают стратегию защиты в масштабах страны. Лучшие практики описываются формулой 2СЗС: 2 сities, 3 сenters. Это означает, что в городе основного базирования находятся два ЦОД в метро-радиусе (т. е. нескольких десятков километров), дублирующих друг друга в синхронном режим, а в другом городе, на расстоянии не менее нескольких сотен километров, располагается третий ЦОД на случай региональной катастрофы в городе основного базирования.

Переключение между двумя основными площадками может быть быстрым и автоматическим, а переключение на удаленную площадку - медленным и ручным. Это связано с тем, что соединения между площадками должны иметь очень низкие показатели задержек (Latency), так как большие задержки отрицательно сказываются на производительности всей системы. А поскольку с увеличением расстояния задержки увеличиваются, расстояние между ЦОД не должно превышать 100 км. Иначе уже не возможно использовать технологию синхронной репликации. Ключевые транзакционные данные на основных площадках поддерживаются в синхронном состоянии, а на удаленной площадке, скорее всего, будет некоторое отставание. (см. подробнее раздел «Синхронизация данных в комплексе ЦОДов»).

Механизмы обеспечения надежности и защищенности сфере катастрофоустойчивости

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

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

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

Наибольшее влияние на механизмы обеспечения надежности и защищенности оказали следующие технологии:

· серверная виртуализация, позволяющая свести восстановление "упавшего" сервера к копированию файла с его образом из одного места в другое вместо восстановления физического сервера путем замены его сбойных компонентов или полной замены. Это уменьшает время восстановления в разы, а в случае плановых манипуляций с сервером - до нуля за счет Live Migration, позволяющей переносить продуктивную нагрузку с одного виртуального сервера на другой вообще без прерывания сервиса;

· виртуализация систем хранения данных - обеспечение с помощью аппаратных или программных виртуализаторов СХД одинаковой (параллельной) видимости дисковых ресурсов и файлов для серверов, расположенных как в главном, так и в резервном вычислительных центрах. С учетом того, что виртуальный продуктивный сервер обычно представляет собой файл, применение виртуализатора позволяет существенно упростить общую конструкцию системы, повышает надежность и упрощает взаимодействие продуктивной и резервной систем;

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

Важная оставляющая обеспечения защищенности - планы аварийного восстановления как со стороны ИТ (Disaster Reсovery Plan[4],) так и со стороны бизнеса (Business Сontinuity Plan[5]). Последний предполагает наличие плана действий в случае утраты бизнесом основного инструмента. Оба плана должны периодически тестироваться согласно разработанному в организации регламенту.

Специфика территориально разнесенных ЦОДов

Основные отличия катастрофоустойчивого ЦОД от традиционного заключаются в том, что:

· Он создается на базе двух или более территориально удаленных друг от друга площадок, которые объединены высоконадежными каналами связи.

· Требуется внедрение целого ряда специализированных решений, например системы репликации данных и механизма аварийного восстановления информационных систем.

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

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

При проектировании нужно помнить о пропускной способности каналов связи - они должны обеспечивать оперативную передачу данных между ЦОД, соответствующую требованиям SLA в части потери данных и сроков восстановления. Помимо этого должна быть разработана детальная программа эксплуатации дата-центра, которая должна включать:

· поиск, подбор и должное обучение персонала объекта,

· наличие хорошо работающих поставщиков,

· безопасность и охрану труда,

· аварийные и рабочие процедуры,

· четкий график работ,

· управление инцидентами и изменениями на объекте,

· профилактическое обслуживание,

· компьютерные системы мониторинга и обеспечения.

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

Уязвимость территориально распределенных ЦОДов

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

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

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

Важно также учесть, что если в информационной системе компании обрабатывается информация, подлежащая обязательной защите в соответствии с российским законодательством (например, персональные данные), то необходимо использовать сертифицированные средства защиты, прошедшие процедуру оценки регуляторами - ФСБ России и ФСТЭК России.

Синхронизация данных в комплексе ЦОДов

Для синхронизации массивов данных в распределенных ЦОД применяются синхронные и асинхронные технологии репликации. В первом случае данные параллельно записываются на исходную и удаленную системы хранения. Запрос записи на исходной системе подтверждается лишь по завершении процесса записи на целевой системе. Во втором случае процессы записи на исходной и удаленной системах могут осуществляться независимо друг от друга. Среди прочих различают методы на базе снимков (Snapshot), уровне блоков и байтов. В Таблица 4 приведено сравнение технологий репликации по следующим критериям:

· RPO (Reсovery point objeсtive) - допустимая точка восстановления

· Допустимое расстояние для работы технологии

· Уровень защиты информации

· Зависимость производительности решения от расстояния/объема данных

· Необходимый уровень пропускной способности коммуникационных каналов

В среде локальных и городских сетей (Metropolitan Area Network, MAN) эти методы, как правило, функционируют очень хорошо. Проблемы появляются, когда увеличивается задержка на линиях передачи, а в распоряжении пользователя имеется только глобальная сеть с гораздо более узкой полосой пропускания по сравнению с локальной/городской сетью. [6]

Глава 3. Исследование проблем безопасности территориально распределенных ЦОДов

3.1 При синхронизации данных между центрами обработки данных

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

· Подробному анализу не будет подвержена локальная инфраструктура ЦОДа;

· Синхронизация данных будет рассматриваться на примере катастрофоустойчивых ЦОДов с межрегиональным распределением (что наложит ограничения на ряд используемых технологий);

· Предложения по решению выявленных проблем будут основываться на программно-технических или криптографических средствах защиты информационных ресурсов (правовая или физическая защита не рассматриваются)

Технологические элементы распределенного ЦОД для анализа:

· Связь сетей передачи данных (LAN);

· Связь сетей хранения данных (SAN);

· Оптимальный путь трафика.

Выбор уровня передачи данных

Первоочередной задачей является определение уровня передачи данных для дальнейшего анализа доступных на этом уровне протоколов. Традиционно в ЦОДах для организации взаимодействия серверов используются сети передачи данных второго (L2) и третьего (L3) уровней.

Единственным недостатком использования сети второго уровня для распределенных ЦОДов является отсутствие маршрутизации трафика, но беря во внимание наличие над-уровневых протоколов, позволяющих ее реализовать, выбор делается в пользу передачи данных по сетям второго уровня.

Cвязь сетей передачи данных

При выборе уровня для объединения площадок ЦОДов нужно руководствоваться следующими критериями:

· Расстояние между дата-центрами;

· Обеспечение безопасности при передаче

· Архитектура решения.

В зависимости от расстояния и архитектуры решения для коммуникаций между площадками можно использовать Ethernet, протоколы MPLS или IP. Так как для регионально распределенных ЦОДов Ethernet уже не применим, рассмотрим далее протоколы MPLS/VPLS и IP/OTV.

MPLS/VPLS

MPLS (multiprotocol label switching) - механизм передачи данных от одного узла сети к другому с помощью меток, являющийся масштарибуемым и независимым от каких-либо протоколов механизмом передачи данных. В MPLS сети пакетам данных присваиваются метки, которые служат для принятия решения о передачи пакета другому узлу на основании значения присвоенной метки без необходимости изучения самого пакета данных.

VPLS - один из способов организации связи точка-многоточка на базе IP / MPLS сетей, который позволяет объединять географически разделенные объекты/офисы в единую сеть.

В VPLS существует две реализации: одна предусматривает использование BGD протокола, вторая - установление целевых LDP сессий между PE маршрутизаторами.

Преимущества VPLS:

· ускоренный обмен файлами и сообщениями внутри сети;

· высокая безопасность передачи информации;

· совместная работа над документами и базами данных;

· доступ к корпоративным информационным http -- серверам;

· организация между офисами высококачественной видеоконференцсвязи и видео трансляций

· Не требуется дорогостоящего пограничного оборудования.

Недостатки VPLS:

· Сложность диагностики в случае возникновения проблем.

IP/OTV

Технология OTV (Overlay Transport Virtualization) была придумана компанией Cisco для обеспечения связи распределённых сегментов L2-сети через обычную IP-сеть. С помощью OTV мы можем «растянуть» широковещательный домен между двумя и более ЦОДами. Можно сказать, что это одна из реализаций L2 VPN, работающая поверх IP-сети.

OTV реализует концепцию маршрутизации по MAС-адресам. Выглядит это следующим образом. Устройства, на которых запущена технология OTV (далее устройства OTV), используя протокол динамической маршрутизации IS-IS, обмениваются данными о MAC-адресах хостов, которые находятся за ними. Это позволяет каждому устройству OTV иметь общую таблицу маршрутизации MAC-адресов. Далее получив пакет, у которого в качестве получателя указан MAC-адрес хоста, находящегося в удалённом сегменте L2-сети, устройство OTV по таблице определяет, куда нужно переслать этот пакет. Пакету добавляется заголовок, и он пересылается сначала на удалённое устройство OTV, и далее уже на хост получателя. При передаче Ethernet-пакетов между устройствами OTV они инкапсулируются в UDP дейтаграммы.

Для передачи данных между дата-центрами используется unicast трафик для взаимодействия между OTV устройствами: одно из них настраивается как сервер соседственных связей (Adjacency Server), на всех остальных OTV устройствах указывается его адрес. Все OTV устройства устанавливают с ним соединение. Таким образом, сервер соседственных связей собирает данные обо всех OTV устройствах (в частности, узнаёт их IP-адреса) и распространяет их на все устройства. Получив эту информацию, каждое OTV устройство теперь может устанавливать связь с другими, используя unicast пакеты, так как теперь есть данные об их IP-адресах. После установления соседственных связей между OTV устройствами, начинается обмен таблицами MAC-адресов.

Для уменьшения взаимного влияния распределённых L2-сегментов друг на друга и оптимизации передаваемого трафика между ними, OTV обеспечивает их частичную изоляцию:

· Между устройствами OTV не передаются BPDU-пакеты протоколов STP. Каждый сегмент строит свою независимую STP-топологию.

· Между устройствами OTV не передаётся unknown unicast трафик. Такая логика работы исходит из предположения, что любое устройство рано или поздно передаст какие-то данные и мы узнаем его MAC-адрес.

· Оптимизируется передача ARP-сообщений. На OTV устройствах кешируют все ответы ARP, пришедшие с удалённых хостов. Таким образом, локальное устройство OTV может ответить на ARP запрос, если ранее кто-то уже посылал аналогичный.

Связь сетей хранения данных

Нередко в основе устойчивого к катастрофам ЦОД - территориально-распределенная кластерная конфигурация серверов с подключением к общей сети хранения данных (SAN). Узлы разнесенного кластера размещаются на основной и резервной площадках, образуя единую систему.

Выбор транспортной сети

При реализации взаимодействия между распределенными дата-центрами в комплексе катастрофоустойчивого ЦОДа факторы стоимости транспортной сети и технические особенности доступа к ней часто бывают решающими, или оказывающими большое влияние на конфигурацию и п остроение системы. Хотя последние стандарты Fibre Сhannel (начиная с 16GFC) и способны к передаче данных до 500 км, реальное расстояние определяется длительностью задержки в сети, которое не приводит к сбоям в работе приложений. Для синхронного реплицирования этот предел составляет 50-100 км. Несмотря на то, что синхронная репликация обеспечивает самые быстрые средства восстановления приложений, на практике при больших расстояниях она редко используется из-за высокой стоимости сетевого обеспечения связи. Для асинхронной передачи используются два вида оптоволокна: темное волокно и SONET (Synchronous Optical NETwork).

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

СWDM и DWDM - технологии спектрального уплотнения каналов, позволяющие реализовать многоканальную передачу по одному оптическому волокну на разных несущих частотах.

SONET (аналог в Европе - SDH) -стандарт транспортировки данных в публичных телекоммуникационных кольцах. Полоса пропускания в SONET определяется договором с поставщиком услуг и, как правило, допускает масштабирование. В кольцо могут быть объединены различные типы связей, таких как Ethernet и OC (Optical Carrier).

По технологии FCIP через отдельные коммутаторы можно организовать также асинхронное взаимодействие между ЦОД, удаленными друг от друга на тысячи километров, использовать аппаратное сжатие трафика. При использовании FCIP, пакеты Fibre Channel инкапсулируются в TCP/IP, а затем передаются через IP-туннель.

Основные характеристики канала связи:

· Пропускная способность, определяющая количество информации для транспортировки и время передачи - определяется в зависимости от технологии;

· Время ожидания, требуемое для прохождения сигнала - иными словами, задержка., которая определяется скоростью света, одинаковой для все типов связи, и составляющая 1 мс на каждый 100 миль.

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

Создание территориально-разнесенных ЦОД.

Катастрофоустойчивость все чаще является одним из основных требований к ЦОД. Однако построение территориально-разнесенных ЦОД требует решение ряда проблем:

· растягивание L2 сегментов между ЦОД;

· оптимизация трафика;

· использование statefull сервисов (межсетевых экранов);

Растягивание L2 сегментов между ЦОД

Использование распределенных кластерных решений, а также функционирование DRS в среде виртуализации требует наличие L2 связности между ЦОД. Использование традиционных решений на основе протокола STP является неприемлемым, т.к. снижает общую надежность системы.

Для решения этой задачи компанией Cisco был разработан протокол OTV (Overlay Transport Virtualization), обеспечивающий передачу Ethernet-фреймов через IP-сеть. Использование OTV позволяет изолировать STP домены в пределах каждого из ЦОД и в то же время обеспечить надежную связь между ЦОД, исключающую возникновение колец.

Оптимизация трафика

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

Исходящий трафик от хоста в сеть передается через шлюз по умолчанию (default gateway), как правило, зарезервированный с использованием соответствующего протокола, например, HSRP. Использование единой HSRP группы, растянутой между ЦОД, как раз и создает проблему, поскольку предполагает передачу исходящего трафика через VIP-адрес, активный в одном из ЦОД. Решение проблемы заключается в фильтрации HSRP и ARP пакетов между ЦОД, что позволить локализовать HSRP в каждом из ЦОД. Технология OTV, предназначенная для растягивания L2 сегментов между ЦОД, имеет встроенные механизмы фильтрации HSRP, что позволяет оптимизировать исходящий трафик без специальных настроек.

Для оптимизации входящего трафика компанией Cisco предлагается использовать технологию LISP VM Mobility, позволяющую отслеживать перемещение виртуальных машин и корректировать маршрутизацию в сети путем инжектированы хостовых маршрутов.

Использование межсетевых экранов в территориально-разнесенном ЦОД

Использование statefull сервисов, в частности межсетевых экранов, в территориально разнесенном ЦОД имеет ряд проблем:

· обеспечение непрерывности сервиса при миграции виртуальной машины;

· обеспечение идентичности конфигурации на межсетевых экранах в разных ЦОД

· Необходимость исключения ассиметричного трафика.

Решение проблемы заключается в использовании территориально-распределенного кластера межсетевых экранов. При внедрении территориально-разнесенного кластера межсетевых экранов рекомендуется также обеспечить оптимизацию входящего и исходящего трафика с использованием OTV и LISP для более эффективного использования ресурсов оборудования.

Возможные решения проблем безопасности

Безопасность протоколов стека TCP/IP

Программно-техническими средствами возможно обеспечить реализацию следующих функции? безопасности:

· Контроль ARP. Механизмы контроля ARP обеспечивают сопоставление IP-адреса шлюза по умолчанию с его MAC-адресом. Если коммутатор обнаруживает пакет ARP, в котором содержится неверная комбинация адресов, коммутатор отбрасывает этот пакет, предотвращая таким образом атаки, связанные с внесением изменении? в ARP-таблицы хостов.

· Средства URPF. Средства URPF обеспечивают проверку каждого пакета с тем, чтобы убедиться, что пакет пришел от нужного источника по соответствующему интерфеи?су. Такая проверка позволяет предотвратить подмену адреса источника пакета. В ходе проверки система проверяет соответствие записи для адреса источника в таблице маршрутизации и идентификатора интерфеи?са, с которого поступил пакет.

· Фильтрация фрагментов пакетов. Существуют коммутаторы, которые могут создавать списки ACL Cisco IOS и списки VACL, позволяющие разрешать или запрещать пересылку фрагментов пакетов. Фильтрацию фрагментов можно использовать для предотвращения атак с использованием фрагментации пакетов (например, атак, описанных в документе RFC 1858).

· Обеспечение случаи?ного характера ISN-номера. Реализации стека TCP/IP в некоторых операционных системах генерируют ISN-номера при установлении TCP-соединения предсказуемым образом, что делает возможным захват TCP-соединении?. В прошлом эта уязвимость была обнаружена во многих операционных системах (см. CERT Advisory CA-1995.01, CERT Advisory CA-1998.13, CERT Advisory CA-2001-09, US CERT Vulnerability Note VU#498440).

· Использование TCP SYN cookies - SYN cookies представляют собои? конкретные ISN-номера TCP, выбранные серверами. SYN cookies можно использовать для защиты очереди SYN- запросов стека TCP/IP устрои?ств (сетевых устрои?ств или серверов) от переполнения посредством выбора ISN (значения cookie) с помощью алгоритма Message Digest Algorithm 5 (MD5), использующего в качестве параметров IP-адреса и номера портов источника и приемника пакета. При достижении определенного порогового значения в очереди система продолжает посылать ответы SYN/ACK (второи? пакет в трехэтапнои? схеме установления TCP-соединения), но не сохраняет информацию о состоянии соединения. При получении заключительного ответа ACK сервер вычисляет исходную информацию на основании значения ISN. SYN cookies являются эффективным механизмом защиты группы серверов от DoS-атак.

· Контроль состояния TCP-соединении? - Модули FWSM и ACE поддерживают информацию о состоянии TCP-соединении?, проходящих через них. К примеру, поддельныи? сегмент TCP, отправленныи? на маршрутизатор, подлежит пересылке точно так же, как и любои? другои? пакет IP. Модули не будут пересылать этот сегмент, т.к. поддельному сегменту не соответствует ни одно из существующих TCP-соединении?.

· Аутентификация при взаимодеи?ствии по протоколу VTP. VTP представляет собои? протокол уровня 2, предназначенныи? для обмена сообщениями, которые обеспечивают целостность конфигурации VLAN путем управления процедурами добавления, удаления и именования сетеи? VLAN в масштабе всеи? сети. Аутентификация VTP помогает обеспечить аутентификацию и целостность сообщении? VTP, передаваемых от коммутатора к коммутатору. В протоколе VTP версии 3 предусмотрен дополнительныи? механизм аутентификации первичного сервера VTP в качестве единственного устрои?ства, которому разрешено менять конфигурацию VLAN в масштабе всеи? сети.

· Аутентификация при взаимодеи?ствии маршрутизаторов. Аутентификация соседних маршрутизаторов, которую иногда называют "аутентификациеи? маршрутов", служит для удостоверения в подлинности соседних маршрутизаторов и обеспечения целостности обновлении? маршрутнои? информациеи? при распространении между маршрутизаторами (между коммутаторами уровня 3) и между хостами и маршрутизаторами (коммутаторами уровня 3). В качестве хостов могут выступать серверы уровня 3, оборудованные несколькими сетевыми адаптерами, или мэи?нфреи?мы. К числу протоколов обмена информациеи? о маршрутизации, поддерживающих этот вид аутентификации, относятся такие протоколы, как OSPF, EIGRP, IS-IS и BGP.

Безопасность доступа к хранилищу с использованием протокола IP

В конструкции сервисных модулеи? IP коммутаторов семеи?ства Cisco MDS 9000 предусмотрены порты Gigabit Ethernet, которые могут как принимать входящие соединения от хостов (инициаторов iSCSI), так и обеспечивать расширение SAN по протоколу IP (Fibre Channel over IP). Коммутаторы семеи?ства Cisco MDS 9000 поддерживают следующие функции безопасности на уровне протокола IP:

· Аутентификация iSCSI. Аутентификация инициаторов входящих сеансов iSCSI (запросы на которые поступают от инициаторов iSCSI), выполняется с помощью протокола CHAP до установления сеанса iSCSI.

· Динамическое и статическое выделение постоянных имен WWN для инициаторов iSCSI. Система позволяет динамически или статически сопоставлять инициаторов iSCSI с виртуальными инициаторами Fibre Channel посредством присваивания уникальных для данного инициатора и для даннои? сети VSAN имен nWWN и pWWN (по сути, каждыи? инициатор iSCSI представляется как "виртуальныи?" N_Port). Присваивание постоянных имен nWWN и pWWN может происходить как в статическом, так и в динамическом режиме (в последнем случае имя выбирается динамически из диапазона имен WWN, хранящихся в памяти коммутатора). Это позволяет использовать такие функции, как безопасность LUN, сопоставление LUN и маскирование LUN для массивов хранилищ среднего и корпоративного класса, т.к. они могут использовать для однозначнои? идентификации хостов, подключенных через интерфеи?с iSCSI, те же механизмы, с помощью которых выполняется идентификация хостов, подключенных к адаптеру HBA Fibre Channel.

· Средства контроля доступа iSCSI. Существуют различные способы контроля доступа, которые могут примениться к инициаторам iSCSI. Во-первых, инициатору iSCSI разрешен доступ только к тем целевым устрои?ствам Fibre Channel (виртуальным целевым устрои?ствам iSCSI), для которых этот доступ был задан явным образом. Во-вторых, инициатор iSCSI (виртуальныи? N_Port) явно указывается в качестве инициатора в рамках однои? сети VSAN. Для зонирования виртуальных портов N_Port и устрои?ств хранения можно использовать стандартные технологии зонирования Fibre Channel. Наконец, ограничения, накладываемые на интерфеи?с, позволяют выбрать режим объявления об отдельных целевых устрои?ствах iSCSI: глобальныи? (по всем интерфеи?сам Gigabit Ethernet) или только по определенным интерфеи?сам и субинтерфеи?сам Gigabit Ethernet либо сетям VLAN.

· Протокол FCIP. Протокол FCIP обеспечивает передачу данных Fibre Channel по IP-сети путем туннелирования фреи?мов Fibre Channel по паре TCP-соединении? между двумя коммутаторами. Необработанные фреи?мы Fibre Channel (содержащие полныи? заголовок Fibre Channel) инкапсулируются в TCP-сегменты при помещении в туннель и реконструируются во фреи?мы Fibre Channel при извлечении из туннеля. Технология FCIP сама по себе не предлагает какие-либо явные инструменты обеспечения безопасности, но она может использовать все существующие механизмы безопасности, доступные для "роднои?" среды Fibre Channel. Сюда относятся такие механизмы, как безопасность на уровне портов и аутентификация в соединениях между коммутаторами по протоколу FCSP DH-CHAP.

Целостность и конфиденциальность данных

Ни протокол iSCSI, ни протокол FCIP не обеспечивают защиту передаваемых данных. Таким образом, если устрои?ство злоумышленника, способное перехватывать трафик, будет установлено на маршруте его передачи, то оно сможет прослушивать все данные хранилища, передаваемые по данному соединению. Исходя из этого рабочая группа IP Storage комиссии IETF разработала концепцию обеспечения безопасности каналов связи с хранилищами, использующих протокол IP. Если сеть передачи данных не является довереннои?, комиссия IETF настоятельно рекомендует использовать для передачи данных протокол IPSec, который позволяет обеспечить шифрование и дешифрование данных IPSec с использованием алгоритмов AES и 3DES на скорости среды передачи.

3.2 При управлении средой виртуализации

Рассмотрим кратко возможные угрозы и сложности, возникающие при виртуализации приложении? и переходе к облачным средам.

· Мобильность нагрузок. Виртуализация серверов позволяет приложениям перемещаться между серверами и даже между удаленными ЦОД и облачными средами. Такая мобильность увеличивает сложность того уровня сети, который отвечает за безопасность. Обычно он работает с неподвижными ресурсами и статичными частными сетями при реализации политик безопасности. Гибкость перемещения политик безопасности в соответствии с изменением виртуальных рабочих нагрузок является сложной задачей.

· Увеличение числа точек атак. В результате виртуализации серверов возникают новые точки атаки, в частности, на уровне виртуализации, включая гипервизор, среду виртуальных машин и программные коммутаторы, заменяющие физические коммутаторы уровня контроля доступа в сети. Появление этих дополнительных слоев увеличило число уязвимых мест ЦОД. Действительно, по своеи? сути уровень виртуализации хуже защищен по сравнению с физическими устрои?ствами из-за отсутствия физического разделения и особенностеи?, связанных с большим числом пользователеи?.

· Большое число пользователеи?. В то время как в небольших распределенных центрах обработки данных размещается малое число приложении? или поддерживается одна организация, в современных консолидированных ЦОД и облачных средах часто работают разные группы пользователеи?, которым требуется полное разделение сетевого трафика и строгие политики контроля доступа, даже если их физические серверы и сетевая инфраструктура являются общими. Такие же требования относятся и к частным виртуальным центрам обработки данных и частным облачным средам, в которых внутренним пользователям необходимо разделение.

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

· Разделение обязанностеи? при администрировании ЦОД. В информационных технологиях принято строгое распределение ответственности между администраторами серверов, администраторами сетеи? и службои? безопасности. Виртуализация серверов усложнила такое разделение труда, поскольку те, кто работает с серверами, как правило, взяли на себя вопросы обслуживания сетеи? и обеспечения безопасности уровня виртуализации, закрепленного за серверами и средои? виртуальных машин. Необходимы средства, позволяющие использовать функции групп безопасности и единообразные политики безопасности на уровне виртуализации.

· Размер и сложность консолидированных ЦОД. Консолидация привела к возникновению проблем с масштабированием и сложностью, которые ограничивают ИТ-персонал при разработке и внедрении политик безопасности с соответствующими решениями, а также при организации работы с ними.

Проблемы, возникающие с виртуализациеи? ЦОД, вынудили организации пересмотреть порядок внедрения решении? для обеспечения сетевои? безопасности. Для реализации эффективного подхода по обеспечению многоуровневои? безопасности необходимо развернуть ряд дополняющих друг друга сервисов безопасности в соответствующих точках сети ЦОД. Ниже перечислены наилучшие общие подходы к проектированию сетеи? ЦОД, основные требования к решениям для обеспечения сетевои? безопасности и роли каждого из сервисов безопасности.

· Защита ЦОД от неавторизованных пользователеи? и внешних атак. Для обеспечения безопасности ЦОД сначала нужно отделить его от всего неавторизованного входящего и исходящего трафика, проходящего по локальнои? сети. Необходимо предусмотреть динамическии? межсетевои? экран перед ЦОД или большую группу ресурсов серверов общего пользования (front-end), которые могут блокировать весь трафик, идущии? из неавторизованных источников по неверным адресам в ЦОД.

· Предотвращение вторжении? и сдерживание вредоносного ПО. Нормальныи? трафик, входящии? в ЦОД, может содержать вредоносное ПО, в том числе троянские программы, вирусы и черви. Для их предупреждения можно использовать систему предотвращения вторжении? с достаточнои? производительностью и возможностью масштабирования всего трафика на входе в ЦОД или в ряде точек внутри него. Это может обоснованно гарантировать отсутствие угроз во всем трафике ЦОД и виртуальных машинах. Есть небольшая вероятность того, что такое вредоносное ПО будет атаковать другие виртуальные машины, если они будут отделены от приложении? в других надежных зонах виртуальным межсетевым экраном.

· Защита границы сети пользователеи? проверенным межсетевым экраном. Нужно использовать проверенные средства защиты для физическои? среды в виртуальных и облачных средах. Обеспечение безопасности отдельных подразделении? или зон пользователеи? мощными средствами защиты периметра повысит защищенность обмена данными между пользователями.

· Закрепление виртуальных машин за разделенными надежными зонами и реализация политик контроля доступа . Внутри ЦОД следует использовать политики безопасности, изолирующие обмен данными между группами приложении?. Это исключит доступ пользователеи? и сервисов одного приложения к приложениям в других надежных зонах при отсутствии разрешения. Такои? уровень контроля доступа и логическои? изоляции обеспечивают межсетевые экраны. Но раньше эти функции нельзя было ввести на уровне виртуальных машин, в том числе для изоляции машин, работающих на одном сервере. Межсетевые экраны физических сетеи? не воспринимали виртуальные машины в качестве отдельных элементов сети. Теперь возможно применение средств детального контроля с использованием виртуального шлюза безопасности.

· Централизованное управление политиками. Формирование профилеи? безопасности на основе шаблонов может упростить разработку и внедрение политик безопасности, а также управление ими.

· Поддержка мобильности виртуальных машин. При закреплении политик безопасности за виртуальными машинами или виртуальных машин за надежными зонами такие политики должны перемещаться внутри ЦОД, отслеживая перемещение виртуальных машин между серверами. Поскольку межсетевои? экран работает вне виртуальнои? машины, при реализации такои? мобильности возникли серьезные сложности.

· Безопасныи? доступ к виртуализированным ЦОД и приложениям. Технлогии VPN являются надежным средством подключения внешних пользователеи? напрямую к основным сервисам, особенно в общедоступнои? облачнои? среде, использующеи? серверы веб-приложении?. Обычно шлюз VPN считается надежным шлюзом для доступа пользователеи? к локальнои? сети, но он также может обеспечивать безопасныи? доступ к основным серверам и приложениям ЦОД. Решения VPN для ЦОД практически всегда используются совместно с межсетевыми экранами. Они должны обеспечить тот же уровень возможностеи? масштабирования, эффективности работы, возможностеи? подключения и надежности, что и остальные элементы инфраструктуры ЦОД. Кроме того, решения VPN обеспечивают детальныи? контроль доступа к приложениям, размещенным в частном облаке ЦОД.

· Возможность масштабирования. Современные ЦОД и облачные сети сдерживают возможности масштабирования у организации?, которые увеличивают уровень консолидации и привлечения внешних исполнителеи? для резкого снижения затрат. Эта тенденция стала заметна недавно, поскольку крупные организации только начинают переходить к использованию частных облачных сред с размещением на собственных серверах и больших общедоступных облачных сред. Проваи?деры, обеспечивающие работу больших коммерческих облачных сред, уже создали отдельные ЦОД, каждыи? из которых охватывает десятки тысяч серверов, и глобальные облака с удаленными объектами из сотен тысяч серверов.

• Полная реализация преимуществ, получаемых за счет наличия дешевых ресурсов в оптимальном месте, требует возможности масштабирования сети на уровне L2, поскольку недостаточная расширяемость ограничивает область передачи нагрузки к определенному приложению. Вопросы масштабирования имеют особую важность для определения точек реализации политик безопасности, поскольку на них не должно влиять перемещение виртуальных приложении? между серверами, центрами обработки данных и элементами облачнои? инфраструктуры. Автоматизация внедрения сервисов и политик безопасности по мере развертывания приложении? внутри ЦОД определяет успех и экономическую эффективность развертывания облачнои? среды.

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

Заключение

По результатам проведенного исследования можно сделать следующие выводы:

· Основные проблемы безопасности территориально распределенных ЦОДов связаны с ограничениями как сетевых, так и вычислительных мощностей в дата-центрах; косвенно же главным фактором является финансовая составляющая.

· Наиболее предпочтительным вариантом развертывания территориально распределенных ЦОДов является развертывание в одном L2-домене, однако данный подход имеет высокие издержки, и финансово обоснован лишь для крупных корпораций;

· Виртуализация ЦОДов имеет ряд преимуществ с точки зрения оптимизации использования вычислительных мощностей, но в случае обработки информационных ресурсов, требующих защиты, требуется разработка дополнительных мер по защите ЦОД.

Список источников

1. Сisсo Global Сloud Index: Foreсast and Methodology, 2014-2019

2. Стандарт Uptime Institute Tier Standard: Topology

3. TIA-942 Global Registry

4. Wold, Geoffrey H. (1997). "Disaster Reсovery Planning Proсess". Adapted from Volume 5 #1. Disaster Reсovery World.

5. British Standards Institution (2006). Business сontinuity management-Part 1: Сode of praсtiсe :London

6. Сlark, Jeffrey. "The Priсe of Data Сenter Availability--How muсh availability do you need?", Oсt. 12, 2011, The Data Сenter Journal

7. Томас Беле «Ускорение соединений между ЦОД» Журнал сетевых решений/LAN, № 05, 2009

8. Distributed Virtual Data Сenter for Enterprise and Serviсe Provider Сloud. Сisсo 2012

9. Resilient Data Сentre Seleсtion and Design. IBM

10. Распределенные центры обработки данных. Jet Info #5, 2006 Денис Голубев

11. А.Скороходов «Сетевая инфраструктура ЦОД с акцентом на приложениях » Журнал сетевых решений/LAN, № 05, 2014

12. «Катастрофоустойчивй ЦОД: идеи и реализации» 29 сентября 2014 Круглый стол «Астерос»

13. ГОСТ ISO/IEС 17799-2005

14. Семенов Ю.А. (ГНЦ ИТЭФ). Сервис виртуальной локальной сети VPLS (RFC-4761). [Электронный ресурс]. - Режим доступа: http://book.itep.ru/4/4/rfc4761.htm

15. Базовые сервисы технологии MPLS. [Электронный ресурс]. - Режим доступа: http://nag.ru/articles/reviews/15448/bazovye-servisy-tehnologii-mpls.html

Размещено на Allbest.ru

...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены