Модернизация сетевой инфраструктуры: куда бежать

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

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

Когда трава была зеленее, а пропускная способность — выше

Начать хотелось бы с того, как обслуживание и обновление сетевой инфраструктуры проходили раньше. То есть: к чему все так привыкли и что, на самом деле, продолжает влиять на наши решения. Все мы помним время, когда мы могли полностью полагаться на крупных международных производителей, таких как Cisco, Huawei, Avaya, HPE и многих других. Эти компании активно развивали то, что принято называть сквозными технологиями, и предлагали использовать свои моновендорные решения для любых задач управления инфраструктурой, в том числе сетевой.

Я проработал в Cisco больше двух десятков лет и отлично помню, как появлялось и распространялось, например, решение SD-Access с его программно-управляемой микросегментацией, интеграцией управления потоками данных в локальной и территориальной сети и так далее.

Но однажды мы все проснулись и поняли, что всего этого больше нет. И тут на вечный вопрос «Что делать?» нам предлагалось два ответа: продолжать использовать «железо» ушедших вендоров или перейти на новое, более доступное.

Остаемся зимовать

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

Еще одна головная боль в случае с «железом» ушедших вендоров — покупка нового оборудования или его компонентов. Откровенно говоря, сейчас от этого страдает не только ИТ-индустрия. Сроки поставок удлинились, стоимость существенно выросла, а также есть весьма существенный риск нарваться на контрафакт. Это и раньше было серьезной проблемой. Достаточно вспомнить историю одного жителя Флориды, который за девять лет напродавал контрафактного «железа» более чем на миллиард долларов.

Про этот и другие случаи известных подделок можно почитать здесь:

Старые новые проблемы

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

Во-первых, мы сразу сталкиваемся с недостатком технической экспертизы, причем с обеих сторон. В пример могу привести свой интереснейший разговор с одним из новых производителей сетевого оборудования. Когда я спросил, какие есть функции информационной безопасности в их коммутаторах, то они (он и его коллеги) просто не поняли моего вопроса.

Во-вторых, часто заявленные функции на практике не работают. Виной тому тот же недостаток опыта или агрессивный маркетинг — не знаю. Здесь хочу вспомнить старую историю одной израильской компании, пусть это и не связано с сетевым «железом». Когда передача голоса по VoIP только входила в тренды, эта компания выпустила свой голосовой шлюз. Тогда я прочитал, что он умеет, и у меня появился только один вопрос: а почему остальные компании все еще существуют на этом рынке? То есть по заявлению вендора этот шлюз умел делать все. Спойлер: на практике работала только треть заявленных функций, и лишь к концу жизненного цикла оборудования этот показатель дотянули примерно до 60%.

Такие примеры часто касаются не только функций, заявленных в маркетинговых материалах, но и производительности. Как говорится, делайте выводы.

А что, если не выбирать вовсе?

Итак, мы где-то на середине нашего обсуждения — самое время задать вопрос: а почему эта тема вообще обсуждается? Дело в том, что мы привыкли делить внутреннюю кухню компании на сетевую инфраструктуру, центры обработки данных, системы обеспечения информационной безопасности и прочее. На самом деле, вся эта «кухня» существует с одной целью — чтобы работали процессы и приложения, критически важные для жизнедеятельности компании. С этой точки зрения задача инфраструктуры — не просто бесконечно модернизироваться, а обеспечивать работу бизнес-процессов. И здесь мы переходим к качественным характеристикам наших сетей (которые тоже можно измерить), а именно: к производительности, отказоустойчивости и качеству обслуживания.

Производительность

По моему опыту, производительность вообще слабо зависит от конкретного вендора. Неважно, с каким мы работаем «железом» — отечественным, из дружественных или не очень стран, — в большинстве случаев мы увидим внутри одни и те же чипы — Broadcom, Marvell и другие. Да и внутренняя архитектура сетевого оборудования — хорошо проработанная и известная тема.

Другое дело — сам подход к производительности сетевого оборудования. Например, как давно вы измеряли реальный поток данных в своем ЦОД? Среди моих знакомых немногие задавались этим вопросом, поскольку в большинстве случаев всем хватает этой самой производительности.

Отказоустойчивость

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

Качество обслуживания

Я не удивлюсь, если многие из вас, увидев это выражение, подумали о качестве обслуживания в магазине или кафе. На самом деле речь идет о приоритизации обслуживания различных типов трафика, каналов, борьбы с задержками и потерей сетевых пакетов. Откровенно говоря, с качеством обслуживания я наиболее плотно сталкивался около 25 лет назад, когда настраивал одновременную передачу голоса и видео для конференции по спутниковому каналу со скоростью передачи данных 256 Кбит/с. Вот тогда и приходилось тонко настраивать все параметры, что даже представляло собой некоторый вызов.

Сейчас же любой из нас без всяких проблем смотрит видео со своего смартфона и не задумывается ни о каком таком качестве обслуживания. Актуальным этот вопрос остался для низкоскоростных сетей и каналов передачи данных, в которых надо «вырезать» полосу пропускания для наиболее важных бизнес-приложений.

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

Назад в будущее

Таким образом, как мне кажется, для работы необходимых нашему конкретному бизнесу сервисов более важна контролируемость и управляемость инфраструктуры. В связи с этим хотелось бы обсудить такой подход, в рамках которого мы переносим решение проблемы на уровень выше по модели OSI. Если мы не можем решить какую-то задачу или не полностью контролируем, что происходит, например, на канальном уровне, то почему бы не попробовать реализовать все нужные функции иначе? Допустим, в итоге мы придем к несчастному протоколу IP, который может предложить нам… все то же самое.

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

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

Качество обслуживания, как я уже сказал, штука важная и полезная, но нишевая. Хотя обычно с этим сталкиваются при работе с низкоскоростными каналами: нужные для его обеспечения возможности тоже есть в самом стеке протоколов TCP/IP.

Из двух зол

Итак, если коротко — в условиях импортозамещения многие компании загоняют себя в рамки выбора между двумя стратегиями: всеми силами держаться за «железо» от зарубежных вендоров или же с головой нырять в мир новых поставщиков. Однако в первом случае есть немалый шанс остаться без лицензии или доступа к каким-то отдельным сервисам, а во втором мы рискуем столкнуться с недостатком экспертизы и, опять же, отсутствием важных для нас функций может еще быть и длительный транзитный период перехода между этими двумя состояниями.

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

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

Михаил Кадер

Архитектор решений по информационной безопасности Positive Technologies