Pages - Menu

Страницы

13.4.16

Облачная ИБ, российские требования по локализации и точка бифуркации

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

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

Пример инфраструктуры обновления информации об угрозах у одного из мировых средств защиты
А отправка файлов для анализа их вредоносности? Она тоже идет с использованием облаков. А проверка хешей файлов или репутации сайтов? Опять через облака. А как мобильные пользователи используют защищенное подключение к Интернет? Снова облака. Да тот же VPN-as-s-Service или DDoS-as-a-Service - это тоже облако, имеющее свои точки присутствия в разных точках Земли и в разных часовых поясах. Ключевой признак такой "облачности" - распределенность. Именно в ней заключается преимущество многих современных технологий ИБ. Нет единой точки отказа, повышение надежности, рост скорости обработки, снижение задержек, учет часовых поясов... Если провести блиц-анализ рынка ИБ, то мы увидим, что точка бифуркации в этом вопросе уже давно пройдена и представить на современном этапе развития технологий ИБ чисто локальные решения уже невозможно.

И вот тут на пути победного шествия облачной ИБ в России возникает наше законодательство и явные и неявные планы по его "совершенствованию", которые рассматривают такую распределенность в мировых масштабах как угрозу национальной безопасности и государственному суверенитету. Про требование локализации баз данных ПДн россиян слышали все. А про запрет нахождение технических средств информационных систем госорганов за рубежом? Тоже многие. А про требование наличие доверенного источника обновления решающих правил для антивирусов и средств обнаружения вторжений при сертификации средств защиты информации? А какой же доверенный источник может быть на серверах в США или Европе? Вопрос риторический, конечно.

Требование локализации, которое в последнее время все чаще звучит применительно к тем или иным Интернет-сервисам или продуктам, к сожалению, не всегда положительно сказывается на обеспечении информационной безопасности. Представьте на минуточку, что ФСБ решит в рамках развития ГосСОПКА создать собственную систему Threat Intelligence, к которой смогут обращаться не только организации с территории России, но и наши партнеры по ШОС и ОДКБ (а может и БРИКС). Китай, Бразилия, Индия, Южная Африка, Белоруссия, Азербайджан будут "ходить" за этой информацией в Россию? Оптимальный ли это вариант? И готовы ли к "потере суверенитета" наши партнеры по военным и экономическим блокам?

Как влияют требования по локализации на средства ИБ (сравните с картинкой выше)
А вдруг российский чиновник поедет в Венесуэлу на переговоры и его православный антивирус, разработанный в России, должен будет получать новые сигнатуры? Откуда? Из России, до которой тысячи километров и десятки провайдеров связи или от ближайшего сервера обновлений, расположенного в какой-нибудь Бразилии? А наши загранучереждения, которые тоже нуждаются в защите своих информационных активов? Им куда "ходить" за обеспечением ИБ? В даль дальнюю или туда, куда быстрее?

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

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


И это только одна часть проблемы, вытекающей из требования по явной или неявной локализации сервисов ИБ на территории России. А ведь есть и другие. Хотя в текущих геополитических условиях на это мало кто обращает внимания (или есть указание не обращать), но стоит задать себе простой вопрос - что делать с иностранными (западными, ближневосточными, азиатскими) вендорами, производящими средства защиты? У них ведь нет в России своих площадок, которые можно было бы назвать доверенными и которые могли бы использоваться для обновления средств защиты или предоставления сервиса. И не факт, что появятся.

Эта проблема никак не связана с санкциями и запретом со стороны иностранных государств. Она никак не связана с выпуском продуктов на территории России (локальным производством). Она никак не связана с раскрытием исходных кодов и сертификацией на отсутствие НДВ. Просто в России отсутствует нормальный Интернет и достаточное количество адекватной инфраструктуры ЦОДов для работы таких площадок и многие зарубежные компании не готовы (возможно пока не готовы) менять существующие годами процессы обновления своих средств защиты. И если запустить ЦОД по предоставлению услуг фильтрации или VPN-as-a-Service на территории России еще можно теоретически (хотя требования СОРМ и последние инициативы депутатов по хранению всех передаваемых данных в течение трех лет в интересах правоохранительных органов не добавляют оптимизма), то с серверами обновления решающих правил ситуация не столь "простая".

Есть ли решение данной проблемы? Увы. Пока все развивается вялотекуще - требования есть, но нет процедуры их контроля. Мы вплотную подступили к точке бифуркации в этом вопросе и в ближайшей перспективе (2-3 года) станет понятно, вернемся ли мы к хаосу или выйдем на качественно новый уровень. Пока же у нас полная неопределенность в этом вопросе...

9 комментариев:

  1. Алексей, сертифицированные продукты должны про требованиям обновляться с особых зон, отдельных от зон обновлений несертифицированных продуктов. Посему большей части описанных вами проблем просто не существует

    ОтветитьУдалить
  2. Vvm25, пардоньте, а что это даст?
    Приведу пример. В одной 3-х буквенной организации был установлен порядок оьновления Антивируса, таким образом, что надо было ездить и забирать правильные сигнатуры. И вот как-то поехал боец, ему выдали акт и диск, на просьбу дать файлик, товарищ майор взял диск степлером присобачил к акту. Боец вернулся и отдал экземпляр руководителю. Больше никто никуда не ездил, а просто качали обновления дома, приносили на диске и скармливали системе. Через какое-то время приехала правильная проверка, ибо никто за обновлениями не ездил, а следовательно обороноспособность страны была под угрозой. Широкий спец с засаленными волосами выгрузил все файлы, посчитал md5 и сравнил с "секретной" распечаткой. В итоге сформулировалась ещё одна претензия: мало того, что никто не ездил по правильному маршруту за правильными сигнатурами, так ещё и все сигнатуре оказались верными! Как? Почему? Не порядок!
    Все претензии закончились сразу же, как только шеф изъял из сейфа перфоманс от майора.

    ОтветитьУдалить
  3. Наоборот. Проблема как раз существует. Ибо даже если представить, что вендор предоставит возможность забирать с его сайта как-то обновления (с периодичностью один раз в 3-5 минут, как, например, у нас), то ИЛ такой же процесс обеспечить не сможет и обновления пойдут с серьезными задержками. А если вспомнить, что заявителем у нас сегодня может быть ЛЮБАЯ компания, то ситуация еще хуже.

    ОтветитьУдалить
  4. Еще одна трехбуквенная организация прекрасно осуществляет обновления в загранучреждения из собственного центра по защищенным каналам

    ОтветитьУдалить
  5. Я не стал писать про то, что все эти трехбуквенные организации благополучно забивают болт на законодательство, когда им нужно

    ОтветитьУдалить
  6. VPN-as-a-Service - на сертифицированных СКЗИ? правда? :)
    Раз уж речь про законодательство - все клиенты должны будут быть учтены в журнале учета СКЗИ :) ПКЗ-2005. Иностранные фамилии в такой журнал писать нельзя, все перевести на русский :)
    А про сигнатуры - так у нас же есть правильные конторы, которые их перепроверяют, ну и что, что раз в полгода 1 сигнатуру для SURICATA наконец проанализируют, главное ж по правильному.
    Алексей, сейчас тренд локализация и импортозамещение, зачем вы опережаете российский рынок на 3-4 года, мы только к 2020 году пойдем в Мир нести облака свои с облачными сервисами.

    ОтветитьУдалить
  7. VaaS на православных СКЗИ бывают. Сам в проекте участвовал

    ОтветитьУдалить
  8. S-Terra в Cisco as a Service?
    Да ладно, чего "вокруг ходить", я тоже VaaS предоставлял. Правда ПКЗ2005 при этом выполнить удалось (я про журнал), по моему мнению, но с долей лукавства, так как клиент=СКЗИ (хоть, наверно и этому опровержители найдутся), выданы они были уважаемым людям и что считать уникальным номером не до конца понятно, поэтому просто вписывали лицензию на все клиенты вендора с количеством штук.Собрать подписи с уважаемых людей за клиентов не реально, поэтому взяли ответственного за эксплуатацию СКЗИ.
    Все можно, но на грани...

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.