Основная характеристика IP-сети — ее распределенность и отказоустойчивость, достигаемые за счет дублирования каналов, распределения нагрузки и независимого вычисления альтернативных маршрутов. У IP-сети нет единой точки отказа — все маршруты вычисляются независимо с учетом текущей ситуации, загруженности линий связи и телекоммуникационного оборудования. Идея программно-конфигурируемых сетей (Software Defined Networking, SDN) — централизация управления в рамках одного элемента (контроллера), обеспечивающего управление сетью из одной точки и определение маршрута всех пакетов через все устройства в рамках одного соединения. Конечно, контроллер так же, как и в случае IP-сетей, принимает во внимание текущую ситуацию с каналами связи и загруженностью оборудования, но не может оперативно принять решение об изменении маршрута в случае разрыва связи, особенно если это произошло между ним и управляемым им оборудованием.
Каналы или пакеты?
Сети связи, управляемые централизованно, появились еще в телефонии — архитектура телефонной сети подчиняется нумерации, в которой предусмотрены международный уровень, междугородный, номер городской АТС и номер конкретного абонента. Устанавливая соединение, телефонный коммутатор принимает решение о маршрутизации звонка по номеру конечного абонента. При переводе телефонной связи на цифровые сигналы разработчики сохранили логику выбора маршрутов по номеру абонента, поэтому каналы с синхронно-цифровой иерархией (Synchronous Digital Hierarchy, SDH) и разделение голосового и сигнального трафика (ОКС-7) также управлялись централизованно телефонными коммутаторами. Однако технологии управления каналами постепенно были вытеснены IP — спецификации мобильных сетей третьего и четвертого поколений уже полностью являются сетями коммутации пакетов. Тем не менее идеология сетей с коммутацией каналов вновь возродилась в SDN, решающих проблему оптимизации передачи большого объема данных.
Как известно, изначально IP разрабатывался для обеспечения работы сети даже в условиях многочисленных разрушений, например после ядерного взрыва, — сеть, по которой передается критически важная информация, такая как сигналы управления для войсковых соединений, должна существовать, даже если значительная часть ее узлов и соединений выведена из строя. Поэтому все передаваемые данные в IP делятся на пакеты, каждый из которых может быть послан по своему независимому маршруту, причем маршрут заранее не определен, а каждый узел принимает независимое решение о том, куда направлять пакет, руководствуясь только IP-адресом и таблицей маршрутизации, учитывающей состояние каналов связи, наличие соглашений с провайдерами и т. п. Однако обеспеченная такой ценой надежность передачи данных нередко приводит к неэффективному расходованию ресурсов: простаиванию маршрутизаторов и каналов связи и постоянному пересчету маршрута независимо для каждого пакета. Современные каналы связи достаточно надежны и позволяют передавать данные на таких скоростях, что процессоры уже не справляются с задачей маршрутизации, однако совсем не обязательно каждый раз вычислять один и тот же маршрут для каждого пакета независимо. Можно просчитать маршрут только один раз для первого пакета, а потом пользоваться сохраненными результатами, что и делают современные IP-коммутаторы.
В такой оптимизации можно пойти еще дальше — отказаться от независимого вычисления маршрутов на каждом устройстве по пути следования пакетов и жестко определять маршрут сразу для всех устройств в едином центре управления. Именно это и лежит в основе SDN — отделить процесс маршрутизации от пересылки данных. Формированием маршрута занимается не каждое устройство в отдельности, а специально выделенный для этого сетевой контроллер, передающий по протоколу OpenFlow коммутаторам результат вычисления маршрута, по которому они в дальнейшем и посылают все пакеты для данного получателя. Это позволяет снять с коммутаторов нагрузку по вычислению маршрутов, причем даже для первого пакета, сделав его простым и производительным. Однако это фактически является возвратом к технологии управления каналами, которая была реализована в телефонии. Мало того, SDN можно рассматривать и как способ для производителей устройств передачи данных бороться за рынок телекоммуникационного оборудования уровня операторов, с помощью которого сейчас обслуживаются магистральные сети. Впрочем, вполне возможно, что появится отдельный рынок сетевого оборудования для построения ЦОД, который будет частично пересекаться с рынком телекоммуникационного оборудования.
Безопасность SDN
Почему коммутация пакетов оказалась более жизнеспособной, чем коммутация каналов? Связано это в том числе и с безопасностью — вмешательство в центральный коммутатор телефонной сети или разрыв межстанционного соединения приводит к выходу из строя целого сегмента. В то же время в IP, при наличии нескольких каналов, поврежденный участок обходится автоматически и связь между абонентами сохраняется и иногда даже не прерывается. Проблема неожиданного разрыва по тем или иным причинам сетевых соединений имеется и в SDN — если какой-то канал на пути следования потока вышел из строя, то центральный контроллер этого сразу не заметит, что может привести к потере данных. Впрочем, сейчас каналы связи стали настолько надежны и высокопроизводительны, что позволяют практически без потерь передавать высокоскоростные потоки данных. В то же время возникла потребность в передаче больших объемов данных именно по фиксированному маршруту, причем в рамках собственной сети оператора, которая полностью контролируется его специалистами. Это и дало возможность отказаться от избыточности в пользу увеличения скорости. При этом наблюдается возврат к технологиям управления каналами связи, которые называются сегодня мультисервисными сетями связи, — именно с их помощью провайдеры обеспечивают управление потоками данных.
Однако не стоит забывать, что в Интернете выросла угроза постороннего вмешательства в работу сети, и похоже, что у SDN устойчивость к внешним воздействиям будет хуже, чем у классических маршрутизаторов. Кроме того, SDN существенно отличаются от мультисервисных сетей, поскольку допускают конфигурирование самими клиентами, которые потенциально могут теперь вывести из строя всю SDN неправильным изменением конфигурации.
Целенаправленные атаки способны нарушить работу программного контроллера SDN, а поскольку подсистема управления вынесена вовне, то именно она становится самым уязвимым местом всей системы. Если раньше каждый пакет маршрутизировался отдельно и не было единого центра управления, который можно было бы легко атаковать, то сейчас вывод из строя контроллера нарушит работоспособность всей сети. Ясно, что такой центр — привлекательная мишень для атакующих. Впрочем, в случае выхода из строя центрального элемента управления, коммутаторы, скорее всего, переходят в автономный режим вычисления маршрутов и начитают работать по старой технологии — хотя и медленно, но без разрыва соединения. Поэтому разработчики устройств вряд ли полностью откажутся от поддержки проверенных технологий и будут, по крайней мере на первых порах, использовать «чистый» SDN/OpenFlow.
Объектов для целенаправленной атаки в случае SDN стало больше, чем для классической IP-сети: контроллер, каналы связи между контроллером и коммутаторами, сами коммутаторы и каналы связи для передачи данных. Протокол IP ориентирован на то, чтобы маршрутизаторы самостоятельно следили за загрузкой и работоспособностью связанных с устройством каналов, а в SDN за состоянием сети следит контроллер, получающий данные о выходе из строя каналов и их загруженности «со стороны», то есть имеется задержка в получении информации и принятии решения. Это не способствует увеличению надежности.
Кроме того, сам протокол управления сетью может оказаться опасным, поскольку не предполагает «интеллекта» у коммутатора, поэтому передача нескольких команд на устройства, уже поддерживающие OpenFlow, может нарушить работоспособность сети или конкретного приложения. Возможно, что с помощью этого протокола злоумышленникам удастся вставить в маршрут передачи потока данных устройства, которые ими контролируются, что позволит перехватывать сетевой трафик и проводить атаки другого типа. Кстати, производители оборудование уже начали реализовывать поддержку протокола OpenFlow в своих продуктах, и пользователи, которые и не планировали строить свою SDN, могут оказаться незащищенными перед несанкционированным применением этой технологии, поэтому компаниям придется следить за наличием протокола OpenFlow в своей сети.
Еще одной проблемой SDN являются приложения, работающие на контроллере и позволяющие перестроить сеть под требования отдельного приложения или системы управления виртуализацией. На данный момент открыт вопрос о том, как эти приложения в режиме реального времени будут конкурировать за сетевые ресурсы — разрабатывать такие сетевые программы достаточно сложно, и есть сомнения в том, что пользователи облачных решений будут делать это оптимально. А значит, высока вероятность того, что в определенный момент какое-то приложение монополизирует сетевые ресурсы, фактически прекратив работу всех остальных приложений. Таким образом, появляется еще одна точка, где разработчики приложений могут ошибиться и неправильно реализовать алгоритм оптимизации сети. Найти такую ошибку сложно, поскольку она проявляется только при определенных условиях и высоких нагрузках. Теоретически поиск ошибок в конфигурации должно выполнять программное обеспечение, которое занимается управлением сетью, однако для этого нужно, чтобы технология SDN была поддержана производителями такого ПО. В любом случае оператор ЦОД должен контролировать работу пользовательских приложений и ограничивать их в монополизации сетевых ресурсов.
Защита SDN
Для надежной работы программно-конфигурируемых сетей нужно обеспечить защиту их главного элемента — контроллера, выделить его в отдельный сегмент, доступ к которому извне ограничен. Не исключено, что для защиты SDN будут разработаны специальные продукты, отражающие атаки на центральный контроллер, но не замедляющие передачу данных. Не стоит пренебрегать системами резервирования контроллеров, возможно, с разнесением реплик в независимые сегменты сети.
Следует отметить, что само программное обеспечение для управления SDN должно содержать компоненты, способные защитить от атак, имеющих целью несанкционированное использование ресурсов: монополизацию сети отдельными приложениями, постороннее вмешательство и др. Поэтому при выборе решения для построения SDN стоит проверить наличие в ней функций безопасного управления. Также в систему управления должны быть встроены элементы резервирования с максимально быстрым переключением системы на использование резервных ресурсов для самого контроллера и для каналов связи, которыми он управляет. При построении SDN стоит предусмотреть максимальное число дублирующих каналов как для передачи данных, так и для управляющих команд от контроллера. Причем на коммутаторах сети нужно допустить получение команд только строго с фиксированного набора IP-адресов, на которых могут быть расположены контроллеры, чтобы злоумышленник не мог извне подавать команды на изменение маршрута потока.
Надо отметить, что OpenFlow поддерживается в оборудовании самых разнообразных производителей, и хотя его поддержка по умолчанию выключена, владельцам сетей, которые не планируют использовать этот протокол и саму технологию, стоит проводить мониторинг использования всех связанных с этой технологией протоколов. То есть с помощью системы управления сетью следует блокировать несанкционированное включение этой функциональности коммутаторов.
Сегодня технология SDN будет, скорее всего, пока лишь дополнительной опцией, которую можно включить для оптимизации передачи больших объемов данных по строго фиксированному маршруту через надежные линии связи. Например, это может потребоваться при организации широковещательной трансляции видео или для обновления программного обеспечения в распределенной по всему миру сети доставки контента (Content Delivery Network, CDN). В этом случае возникает потребность в экономии ресурсов, которой можно достичь за счет более полного использования потенциала надежности.
Следует отметить, что надежную SDN можно пока построить только в рамках сети, принадлежащей одному владельцу, — неясно, как два оператора связи будут делить между собой функции централизованного управления одного контроллера. То есть весь Интернет не может быть построен на технологии SDN, поскольку Сеть существенно децентрализована. Имеет смысл разворачивать SDN в инфраструктурах, использующих виртуализацию, — передача виртуальных машин с одного узла на другой связана с пересылками больших объемов данных, а надежность в этом случае обеспечивается на уровне системы управления виртуализацией. Кроме того, SDN можно активно использовать в сильно распределенной корпоративной сети, в которой обеспечена защита периметра и выполняется надежный контроль происходящих событий. В этом случае нейтрализация целенаправленных атак выполняется средствами периметра, а само оборудование работает, как правило, достаточно надежно.
Пока неясно, как использовать SDN в коммерческих ЦОД и облаках — наличие прямого доступа из Сети позволяет организовать целенаправленные атаки на ресурсы клиента и разрушить структуры SDN, а один клиент может атаковать другого. Но если будет разработано специальное программное обеспечение для управления арендованной SDN, которое не допустит злоупотреблений клиентов, то тогда можно будет использовать программно-конфигурируемые сети. Не стоит строить SDN на базе медленных и ненадежных каналов связи, например допускающих подключения по мобильной связи. Ну и конечно, рано еще пользоваться SDN в критически важных системах, для которых надежность важнее производительности.
SDN для безопасности
Несмотря на то что технология SDN имеет определенные проблемы с безопасностью, она тем не менее позволяет реализовать операторам новые сервисы защиты, которые будут работать на уровне контроллера и дадут возможность оперативно менять конфигурацию сети в случае атак извне или внутреннего нарушения политики безопасности. Одним из примеров продуктов подобного класса является проект с открытыми кодами OpenFlowSec.org по разработке решений, позволяющих реализовать некоторые защитные сервисы при использовании SDN. В частности, в рамках этого проекта созданы три продукта, которые дают пользователям популярного контроллера с открытыми кодами NOX возможность реализовать некоторые сервисы безопасности. Так, инструмент Security Enahanced Floodlight, который является дополнительным модулем для контроллера, позволяет проверять, насколько корректно с точки зрения безопасности осуществляется управление потоками информации. Он также может блокировать соединения, нарушающие заранее определенную политику безопасности. Другой инструмент, Security Actuator, обеспечивает реагирование на внешние атаки и перестраивает SDN-сеть так, чтобы локализовать нападения и блокировать зараженные компьютеры. А компонент под названием OpenFlow BotHunter собирает информацию о работе сети, выявляет зараженные узлы, а также перенаправляет вредоносную деятельность на специальные ловушки, фиксирующие действия нападающих и анализирующие их активность.
Таким образом, SDN, с одной стороны, усложняет работу службе информационной безопасности, открывая злоумышленникам новые цели для нападения и злоупотребления, а с другой, предоставляет и новые возможности по созданию сервисов информационной безопасности.
***
Список областей, где сегодня еще не стоит использовать SDN, достаточно велик, но, возможно, со временем технология будет усовершенствована и для нее будут разработаны надежные системы управления. Вместе с тем следует отметить, что владельцы ЦОД сами обеспечивают защиту вычислительной архитектуры и целостность SDN, а программный контроллер, управляющий сетью, является частью более общей управляющей системы всего ЦОД. Проблемы могут возникнуть в случае, когда операторы ЦОД не будут заботиться о безопасности и позволят пользователям со своих виртуальных машин получить доступ к управлению внутренней сетью и хранением. Конечно, сама концепция предполагает, что технические подробности от пользователей скрыты, однако, как это часто бывает, реализация концепции может оказаться не столь идеальной и у злоумышленника появится возможность выйти за рамки виртуальности.
