Точки отказа. Безопасность в облаке: кто за что отвечает
В новом выпуске шоу «Точки отказа» разбираем с тремя экспертами, кто отвечает за безопасность в облаке. Говорим про угрозы, переезд, границы ответственности и про то, что каждая сторона видит при инциденте.
В этом выпуске:
- Где заканчивается зона провайдера и начинается зона заказчика
- Что закрыть самому до переезда в облако
- Кто первым видит инцидент и кто его разбирает
Спикеры:
- Владимир Золотов, директор по информационным технологиям, «Гринатом»
- Максим Долгинин, руководитель направления развития продуктов кибербезопасности, Cloud.ru
- Владимир Зайцев, заместитель технического директора, NGENIX
Ведущий: Антон Ленский, CEO CISOCLUB
Содержание:
- Главные угрозы для облаков
- Подготовка и переезд в облако
- Зоны ответственности провайдера и заказчика
- Три ошибки заказчиков в облаке
- Страхование киберрисков и «кибераптечка»
- Боты, WAF и настройка защиты
- Сервисы безопасности, которыми пренебрегают, и AI firewall
- Команда: растить внутри или отдать на сервис
- Инцидент: кто что видит и кто его разбирает
- Требования регуляторов, КИИ и договор с провайдером
- Практические советы: технологии, процессы, люди
Смотреть:
Читать текстовую версию:
Антон Ленский: Добрый день, уважаемые зрители. Вы смотрите «Точки отказа» на CISOCLUB. Сегодня говорим про безопасность в облаке. Кто за что отвечает, что сделать до переезда в облако, кто и что видит при инциденте. Со мной в студии Владимир Зайцев, заместитель технического директора NGENIX, Максим Долгинин, руководитель направления развития продуктов кибербезопасности Cloud.ru, и Владимир Золотов, директор по информационным технологиям «Гринатома». Приветствую, коллеги.
Главные угрозы для облаков
Антон Ленский: Давайте начнём сразу с первого блока про главные угрозы для облаков. Владимир, что опаснее: объёмный DDoS или атаки на уровне приложений?
Владимир Зайцев: Объёмный DDoS, он, наверное, менее опасен с точки зрения, что он более изучен, и здесь вся проблема объёмного DDoS просто в его размере. Если у вас есть широкие аплинки, если у вас есть оборудование, то объёмный DDoS для вас становится просто, ну, какой-то рутиной, поэтому здесь вопрос просто денег.
Ваша инфраструктура должна переработать большой трафик, в том числе легитимный, а нелегитимный с помощью оборудования просто терминировать. Поэтому сейчас, в условиях того, что у нас там развиваются нейросети, развиваются боты и так далее, а бизнес-логика у всех разная, то атаки становятся прицельными, они становятся под конкретную бизнес-логику. Поэтому, допустим, с тем же самым DNS amplification можно бороться для всех плюс-минус одинаковыми настройками, то есть разграничивать там только по префиксам сети. А борьба с атаками на бизнес-логику, она уже прицельная и должна быть под конкретного заказчика. Хотя там тоже, безусловно, есть свои общие паттерны, которые можно переиспользовать на всех заказчиках.
Антон Ленский: А можно сказать, что мы на самом деле просто привыкли к DDoS и для нас это уже не проблема?
Владимир Зайцев: В какой-то степени да. Особенно с 22-го года мы находимся в такой обстановке, что это вот аналогия с организмом, который борется с инфекциями и развивает свой иммунитет. У нас иммунитет в нашей стране в ИБ, в кибербезе, мне кажется, достаточно на высоком уровне. Думаю, что коллеги подтвердят на своём опыте. И атакуют всех постоянно, поэтому в этом плане атаки на каналы, атаки сетевые, в силу того, что протоколы не меняются годами и остаются теми же самыми, поэтому там всё плюс-минус изучено. Есть просто способы увеличения ботнетов, количества устройств, и атаки отличаются в основном только количественно, да, там по величине, там по частоте и так далее.
Кого атакуют чаще: клиента или облачного провайдера
Антон Ленский: Максим, Владимир сказал, что атакуют всех. Исходя из твоего опыта, кого чаще атакуют: клиента или облачного провайдера?
Максим Долгинин: Атакуют действительно всех. Атакуют и нас, как облачного провайдера, но чаще всего, конечно, атакуют клиента, потому что атака на облачного провайдера — это скорее некий фон, наверное, для какой-то точечной атаки на клиента.
Антон Ленский: А как же вот эти вот хайповые атаки на Cloudflare, 4 Тбит/с, или это всё больше хайп?
Максим Долгинин: Мы тоже сталкиваемся с огромными DDoS-атаками, и для нас действительно это уже рутина. И скорее ребята озадачены не тем, что с этим делать, а уже насколько быстро мы можем переключиться, например, между провайдерами, насколько быстро мы можем не за 15 минут, например, а как нам сделать так, чтобы за пять минут перекинуть соединение, чтобы обеспечить доступность нашей площадки. Почему атакуют больше клиентов? Потому что, когда мы говорим про атаки на провайдера, это в основном атаки на канал. Когда мы говорим про атаки на клиентов, их на самом деле проще атаковать, потому что у них меньше инфраструктура, потому что атаки для них можно сделать менее заметными. Например, атаки на уровне приложений: там можно забомбить какой-то сайт легитимными запросами — и клиент лёг. Можно даже сделать там атаку на уровне L3, и при этом мы её даже не заметим, потому что по нашим меркам, по меркам облака, это будет совсем небольшая атака, а клиент уже может лежать. И тут, конечно, основная проблема в том, что не все клиенты это понимают, не все клиенты считают, что они должны как-то отдельно заниматься защитой от DDoS, в том числе для себя. Плюс не DDoS-ом единым. Очень часто клиентов атакуют, причём, я бы даже не сказал, что атакуют какого-то конкретного клиента. Мы встречаемся с тем, что основное количество атак — это обнаружение и эксплуатация массовых уязвимостей и мисконфигураций.
Антон Ленский: Нет конкретной цели, просто всех подряд.
Максим Долгинин: Конечно. Скорее есть поиск уязвимости, с которой ты знаешь, как работать. Сейчас есть готовые эксплойты, есть сканеры, всякие Shodan, Masscan. Ты можешь постоянно сканировать весь интернет и просто искать хосты. По нашей статистике, три минуты проходит после появления виртуалки с белым IP-шником в сети до того момента, как её начинают ломать. Три минуты. И у нас даже есть кейс, когда клиент развернул виртуалку, ушёл пить кофе, через 10 минут возвращается — там уже 100% загрузка CPU, какая-то в логах активность непонятная сетевая. Ну, как бы, не понимаю, что происходит. Пишет в поддержку, мы уже видим — там уже майнер стоит.
Владимир Зайцев: Он подумал, что он попьёт кофе и пароль на рута дефолтный поменяет потом, да?
Максим Долгинин: Да. И на самом деле вот этот вот кейс — это вообще супер сценарий, когда клиенту повезло. Что могло быть? Там могло не быть такой активности. Там мог сидеть какой-то зловред и тихо что-то делать и ждать своего часа. Там анализировать, а что он ещё там развернёт, потому что наверняка там будет доступ ко всему внутри контура клиентского. И вот этот сценарий, можно сказать, хороший, потому что клиенту повезло, но могло быть намного хуже.
Где дыра в безопасности: в самих продуктах или на стыке
Антон Ленский: В продолжение темы атак хочется у Владимира спросить: где у нас дыра в безопасности, точнее, в облаке? Как ты думаешь, в самих продуктах или на стыке между ними?
Владимир Золотов: Я буду аккуратно отвечать на этот вопрос, потому что не могу рассказывать всю подноготную, связанную с нашей инфраструктурой. Это тема такая достаточно тонкая. В целом, во-первых, уязвимости есть везде, да. В любом программном обеспечении есть, в любой инфраструктуре, инфраструктурном обеспечении, ну, есть. Вопрос, как быстро их можно обнаружить и закрыть. Если говорить про нашу инфраструктуру облачную, то мы провели полное импортозамещение в нашем облаке. Если мы раньше использовали западное и иностранное программное обеспечение, которое было хорошо известно как нашей службе эксплуатации, так и, объективно, и злоумышленникам, оно достаточно широко использовалось вообще по всему миру. В этом плане быстрее обнаруживались те самые уязвимости, дыры, готовились соответствующие патчи, применялись и так далее. В этом плане отечественное программное обеспечение, имея меньший периметр потребления, конечно, идентификация тех самых уязвимостей проходит намного сложнее. Поэтому мы используем, во-первых, сертифицированное программное обеспечение и очень большое внимание уделяем процессу управления уязвимостями и максимально оперативному их устранению. Но я хочу отметить, что самое большое внимание я лично стараюсь уделять всё-таки, в подтверждение слов коллег, — это периметральной защите. Потому что даже если у тебя есть уязвимость где-то на твоих компонентах, то до них ещё нужно добраться. И если у тебя периметральная защита выстроена правильно, это достаточно существенно усложняет инциденты информационной безопасности. Если в целом говорить про внешние облака, мне кажется — это проблематика на уровне управления учётными записями. Если администратор, владелец привилегированных каких-то доступов безалаберно относится к своей парольной защите, если отсутствует двухфакторная аутентификация, устаревшие какие-то учётные записи, то, безусловно, это потенциально, может быть, всё взломано. Опять же вопрос на уровне работоспособности API, каких-то сбоев на уровне API или доступа к виртуальной инфраструктуре для её управления также потенциально может нести угрозу. Ещё раз, периметральная защита, слабая сегментация — основные такие факторы, которые могут привести к инциденту.
Владимир Зайцев: А я хотел ещё добавить вот в тему, кого больше атакуют. Тут ещё бывает такая история, что могут атаковать клиента, но, допустим, не очень крупный облачный провайдер просто не справился с атакой на конкретного клиента — естественно, задевает всех остальных. И здесь я хотел ещё такую вещь подсветить для тех, кто выбирает, перемещаться в облако или нет, или в какое. Всё-таки в эпоху того, что сейчас в индустрии денег меньше, происходит консолидация, и идти лучше в тех провайдеров, которые крупные, которые давно на рынке, потому что мелкий провайдер, скорее всего, будет сильнее экономить. И плюс есть провайдеры, которые хостят клиентов околосерых каких-то, и нужно понимать, что, допустим, в iGaming, в каких-то таких историях там больше атак, и люди менее обращают внимание на Уголовный кодекс даже в силу возраста. Просто, если мы возьмём просто онлайн-игры, там Minecraft, то там люди просто не понимают, они не подвержены тому же самому Уголовному кодексу и могут атаками кидаться друг в друга очень сильно. Поэтому вот на это тоже нужно обращать внимание, то есть на крупность облака, в которое вы едете, потому что там консолидация компетенций происходит, у мелких провайдеров они, естественно, экономят, а ФОТ, он тоже занимает достаточно большую часть.
Подготовка и переезд в облако
Антон Ленский: Размышляя про миграцию, хочется спросить Владимира: как вообще происходит миграция в облако? У нас же, получается, так много есть различных угроз, но это и понятно, у нас там такой разнородный ландшафт угроз, а, мигрируя в облако, у нас он, получается, расширяется.
Владимир Золотов: Во-первых, что такое миграция? Миграция — это управляемый перенос информационной системы из одного ИТ-ландшафта в другой. Когда я говорю про свою инфраструктуру, то я говорю о миграции из устаревшей иностранной виртуализации, например, VMware, в импортозамещённый стек, импортозамещённое облако. И здесь следующая ситуация: есть перенос, ну то есть вопрос именно миграции самой виртуалки технически, если даже это технически можно сделать, сделать конвертер из VMware в OpenStack или в наше облако, то на самом деле, когда мы говорим про переезд, мы рассматриваем вопрос переезда в импортозамещённый ИТ-ландшафт в целом. То есть это вопрос миграции и операционной системы, это вопрос миграции и баз данных на отечественные. И в совокупности это получается не просто миграция, это целый проект по проектированию, внедрению, по сути, новой информационной системы с новой IP-адресацией, на новом ландшафте, абсолютно новая обвязка с точки зрения информационной безопасности, проектирование, внедрение, аттестация. То есть как таковой, назвав её миграцией, такого процесса, по сути, не получается. Мы через этот процесс 70% наших корпоративных информационных систем провели, перевели их на новый ландшафт, полностью импортозаместили. С точки зрения инфобеза повысили степень защищённости в полной мере, какие-то системы были даже перекатегорированы в значимый объект критической информационной инфраструктуры с выполнением соответствующих норм и требований. В основном с чем мы сталкивались по факту миграции — это, безусловно, тонкий тюнинг. Врать не буду, на первых этапах, особенно такие серьёзные ресурсоёмкие информационные системы, были проблемы с деградацией производительности. Это вопрос тонкого тюнинга как на уровне платформы виртуализации, на уровне вычислительной инфраструктуры, но с течением времени в целом привели всё в соответствие и обеспечиваем стабильность и работоспособность.
Антон Ленский: Выглядит, как будто проблема только в информационных системах. Я поясню: у нас в позапрошлом выпуске один из представителей сказал, что во время пилота он выбирает самое лучшее решение среди самых незрелых и показывает его эффективность. Насколько у нас в процессе импортозамещения реально созрели наши ИТ- и ИБ-продукты?
Владимир Золотов: Я считаю, что ИБ-продукты у нас, наверное, самые зрелые. Я больше, чем уверен, это реально передовики с точки зрения импортозамещения по технологическому стеку, и они могут и являются конкурентами мирового уровня. И, безусловно, бывают проблемы. Как раз очень много у нас, достаточно много кейсов с деградацией были связаны, к сожалению, с применением средств защиты информации, того же самого антивируса. Бывают такие ситуации, когда информационная система начинает деградировать, а причиной тому — это либо средство защиты, антивирус, либо ещё какое-то программное обеспечение, которое обеспечивает безопасность. И да, только тонким тюнингом, методом проб и ошибок, к сожалению, получается найти итоговое решение.
Что заказчик должен закрыть до покупки средств защиты
Антон Ленский: Продолжая тему миграции, мне хочется у Владимира спросить: а вот что должен сам заказчик закрыть до приобретения какого-то СЗИ, сервиса? Ведь часто бытует мнение, что сколько бы много СЗИ ни было, всё равно проблема тех же самых уязвимостей, которые можно нейтрализовать ещё до какой-либо миграции.
Владимир Зайцев: Я бы здесь на три трека разбил: технический, бизнес и риски отдельно. Технический — это банально сделать инвентаризацию, это первое, с чего нужно начать, потому что можно не переносить всё в облако, потому что за это придётся платить. Понять, какие у вас там есть банально домены, какие у вас эндпоинты. Самая частая проблема — это то, что один домен и вся бизнес-логика просто через один домен: пользователи, админка, партнёры. И даже с точки зрения статистики это разделить потом очень сложно. Маршрутизировать трафик, подключать средства защиты, количество запросов — это тоже ресурсы, за которые будет биллиться. Это всё усложняет, если нет инвентаризации. Дальше технические всякие штуки, интеграционные, — это заголовки кэширования, само кэширование, забывают про CORS очень часто, забывают про какие-то лимиты на отдельные эндпоинты. То есть какая-то техническая история, она в последнее время становится, как мне кажется, такой острой, потому что разработчик, он уже мыслит абстракциями, он не до конца понимает, как работает веб. RFC все игнорируют. Поэтому костыли у всех появляются, и когда ты начинаешь две сложные системы интегрировать, и та, и другая работают нормально, а когда ты их начинаешь интегрировать, появляются какие-то вопросы. Поэтому регрессионные тесты никто не отменял. То есть тот же самый K6, Playwright — это всё можно автоматизировать и ваше приложение протестировать заранее перед выкаткой в облако. Второе — это бизнес. То есть нужно посчитать, сколько это будет стоить. Количество запросов, другие ресурсы, объём хранения, вычислительные мощности. Что должно переехать в облако, что должно остаться у вас. То же самое кэширование влияет на количество запросов на Web Application Firewall. Если у вас не работает кэширование, вы будете платить больше за WAF или за какие-то другие ресурсы. Очень частая история — переехали в облако, а не закрыли свою инфру от всего интернета. Если напрямую атаковать приложение, оно защищено, а сбоку, пожалуйста, инфра не защищена. То есть те же самые access-листы банальные не сделали, и злоумышленник сбоку просто заходит, эксплуатирует или DDoS-ом кладёт всю инфраструктуру.
О чём провайдер спрашивает клиента до договора
Антон Ленский: Кстати, хороший пример. Мне сразу у Максима хочется спросить: есть какие-то вот вещи, которые вы как провайдер сообщаете клиенту до подписания договора на миграцию, либо на поставку услуг, условно, обрати внимание на вот эти вещи, если ты их не сделаешь, там не то что безопасности, но и доступности никакой не будет?
Максим Долгинин: Перед тем как начать вообще разговоры с клиентом о переезде непосредственно, мы, во-первых, очень много вопросов задаём — потому что надо понимать, что набор сервисов, который предоставляет облачный провайдер, он огромный. И там это не просто перетащить, условно, приложение в облако, это скорее перетаскивание инфраструктуры крупной компании. И каждый сервис, например, это IaaS, он очень сильно отличается по цене в зависимости от того, что за систему мы перевозим. Сервисы, которые потребляются клиентами, они разграничиваются по зоне ответственности между клиентом и провайдером. У инфраструктуры как сервис одна зона ответственности, мы отвечаем за физическую инфраструктуру, за сеть, за виртуализацию, но всё, что виртуальная машина, операционная система, приклад — в зоне ответственности клиента. Это очень важно прояснять, потому что далеко не всем это понятно. И когда клиент, например, использует какой-то уже платформенный сервис, например, базу данных, там мы отвечаем в том числе за инфраструктуру, на которой крутится дополнительная база данных, как к этой базе данных клиент раздаёт права, а клиент уже непосредственно пользуется сервисом с соответствующим SLA. Зона ответственности очень важна. Второе, что мы проясняем с клиентом — это какие регуляторные требования накладываются на ту инфраструктуру, которую он переводит. Например, если это организация финансового сектора, там есть всё, начиная от обычных dev-систем, к которым не предъявляются супер каких-то крупных требований, которые могут жить и в публичном облаке, например. И там есть системы, к которым предъявляются требования, например, требования к обработке персональных данных, и заказчик хочет их размещать в соответствующем сегменте, в зоне доступности облака, которая соответствует требованиям для размещения подобных систем. Обычно это отдельные зоны доступности, и обычно заказчик разделяет инфраструктуру: часть он помещает в публичное облако, часть он может поместить, например, в облако, которое аттестовано по требованиям по защите персональных данных, или, например, если это госзаказчик, аттестовано по требованиям, которые предъявляются государственным информационным системам. Почему нужно это разделение? Ответ простой. Облако, которое аттестовано, на аттестацию тратится больше денег, предъявляются выше требования к железу, больше средств защиты информации, всё должно сертифицировано, соответственно, себестоимость выше, тариф клиенту получается выше. Соответственно, чтобы эта история закрывала, ну, во-первых, все потребности с точки зрения регуляции, с точки зрения бизнеса, которые предъявляются со стороны клиентов, есть такое разделение. Плюс, чтобы это не стоило слишком много, имеет смысл не грузить всё в одну корзинку, а именно разделять. И поэтому клиенту очень важно смотреть, что провайдер делает с точки зрения безопасности своих регионов доступности. И основные документы, которые, например, клиенты просят показать, и мы с удовольствием показываем, это, например, выписка из технического паспорта на аттестованный регион, где указано общесистемное программное обеспечение, которое используется, где указаны средства защиты информации, которые применяются, плюс выписка из модели угроз, модели нарушителя. На основании этих документов что клиент может сделать? Он понимает, какие защитные меры реализованы на уровне провайдера, чтобы ему самому этого не делать, и, соответственно, он строит свою систему защиты уже с учётом тех функций безопасности, которые нами закрыты, и уже прикладывает наши документы, когда идёт аттестовать свою систему.
Антон Ленский: Типовой клиент, который обращается к провайдеру, насколько он зрелый, насколько он готов предъявлять информацию, коммуницировать, рассказывать про свои системы? Есть ли у нас скачок роста зрелости в России?
Максим Долгинин: Да, я вижу, что есть скачок роста зрелости, на самом деле. Потому что облака — тема не новая, и вообще много клиентов у себя внутри строили облака и уже используют различные облачные платформы, какие-то открытые, которые присутствуют на рынке. И при переезде в облако уже многие компании, например, средние и выше среднего, они предъявляют такие структурные требования к облачному провайдеру. У них довольно системно эти требования разложены в Excel-овском документе, тебе остаётся только их заполнять, и ты можешь прозрачно видеть, чего тебе не хватает, например, как облачному провайдеру иногда. Ну и, конечно, ты можешь обсуждать с клиентом, зачем он те или иные требования прописал. Кроме того, сейчас появилось большое количество клиентов, чей бизнес завязан на ИТ и которые являются ИТ-first, и у которых если ляжет ИТ-инфраструктура, это считай лёг бизнес, как выключили свет. Поэтому эти клиенты уже прошли этапы, когда они думали, что мы сейчас построим ИТ-инфраструктуру, а через полгодика её защитим. И начинают строить ИТ-инфраструктуру, уже изначально предъявляя требования по безопасности. Ну то есть кибербез в облаке, он уже перестал быть некой опцией дополнительной, по сути, это инфраструктурный сервис базовый, без которого клиент, может, и не поедет в облако. Потому что у нас, например, как минимум банки, у них очень жёсткие требования по безопасности. Говорят: если вы выполняете требования вот такого уровня, мы готовы dev-сегмент к вам перевести, но не далее. Если вы выполняете требования такого уровня, мы готовы чуть-чуть больше к вам заехать.
Зоны ответственности провайдера и заказчика
Антон Ленский: Продолжая тему про ответственность, у Владимира был хороший пример про WAF, что ты можешь всё защитить, а внутрянка у тебя не защищена. Вот при таком подходе, если вдруг тебя атаковали, возможно, взломали, чья это зона ответственности? Либо это предмет скандала?
Владимир Зайцев: Это всё определяется формальной какой-то историей. Всегда есть формальная, есть неформальная история. Всё описывается в договоре. И, естественно, если инфраструктура торчит наружу и она не находится в зоне ответственности облачного провайдера, то это ответственность самого клиента. Задача облака здесь — это просто подсветить риски, то есть сказать, что вот мы с вами, допустим, делаем прямое подключение, чтобы нивелировать атаки на ваш канал, но вы должны выполнить вот такие-то требования. То есть у вас должен быть разрешён доступ только с наших префиксов, отдельный сегмент сети и так далее.
Слышат ли клиенты предупреждения о рисках
Антон Ленский: А такие риски, ну, например, вы подсвечиваете, и второй сразу же вопрос: и эти риски клиенты слышат вообще?
Владимир Зайцев: В основном слышат. Так как безопасность, особенно для мелкого, среднего бизнеса — это всё-таки накладные расходы, да и для крупного это тоже накладные расходы, то хочется сэкономить. Поэтому часто бывает так, что произошла ситуация, произошёл инцидент, полежали, и тогда уже задумываются: а, надо было, да, прямой стык, купить анти-DDoS или ещё что-то. Это имеет место быть. Крупный бизнес, естественно, он уже за четыре года понял, что это стоит полежать, они теряют деньги достаточно большие, миллионы рублей, если полежать час. Поэтому для них гораздо выгоднее просто сразу заплатить, и это будет стоить меньше, чем вероятность, что они будут лежать. Потому что сейчас атаки идут, новости все читают, если вы крупный, то, скорее всего, вас будут пытаться атаковать. Или уже атакуют различными способами.
Максим Долгинин: Действительно, крупный бизнес уже наелся и очень большое внимание уделяет безопасности. И сейчас я вижу, что средний бизнес и небольшой бизнес, в основном из ИТ-сектора, ну, кстати, и не из ИТ-сектора, например, из торговли, сталкивается чаще обычного с, например, атаками шифровальщиков. И я точно знаю, что есть в интернете огромное количество материала на эту тему. У меня, условно, в двух рукопожатиях за последние полгода пять компаний, которые разрабатывают программное обеспечение, которые предпочитали удобство осторожности. Они столкнулись с шифровальщиками, ребятам на принтере распечатали вежливую просьбу заплатить выкуп, вот я со своей стороны подключался, помогал, собственно, немножко какие-то последствия митигировать всего этого. Очень хорошо отрабатывают сейчас шифровальщики, используют искусственный интеллект для того, чтобы атаки проводить, ищут бэкапы, шифруют бэкапы, а часто это всё в одном месте. Часто это какой-нибудь недорогой облачный провайдер. К сожалению, там наиболее уязвимая инфраструктура, когда заказчики, например, в колокейшн просто могут заехать, арендуют место, там вся инфра на их стороне, никто больше не отвечает, они даже никому предъявить не могут. И всё. И это прям история массовая, прям атакуют массово. И, конечно, инцидентов стало больше.
Владимир Зайцев: Я ещё вот вспомнил инцидент такой интересный, что, когда вы переехали в облако, у вас там есть, допустим, виртуальная машина, вы на ней всё закрутили, все гайки, всё там сделали, но взломать могут через провайдера, то есть там через какую-то панель администрирования, ISPmanager и так далее. То есть вы даже об этом не могли подумать, у вас нет доступа, чтобы просто даже от этого защититься, но так как провайдер просто не обновляет своё ПО, свою инфраструктуру, не обращает вообще на это внимания, потому что для него это затраты, просто взламывают провайдера и потом ломают все абсолютно виртуальные машины, и об этом могут узнать через год, просто кто-то тихо сидит, майнит или ещё что-то делает.
Три ошибки заказчиков в облаке
Антон Ленский: Раскручивая тему ответственности провайдера, Максим, как ты думаешь, что ошибочно считают зоной ответственности провайдера?
Максим Долгинин: Наверное, ошибка номер один — это то, что мы все защищены от DDoS. Ранее мы уже говорили, что на самом деле это не так работает. И провайдер, защищая свою инфраструктуру, он защищает прежде всего доступность своих сервисов в целом, личного кабинета для клиента. И у провайдера может быть всё в порядке, но клиент может лежать просто потому, что атака, которая идёт, например, на клиента, она по меркам облачного провайдера, он её даже не заметит, у него не срабатывают какие-то фильтры, по которым происходит реакция, митигация атаки. Плюс есть атаки на приклад, которые провайдер в целом не видит даже и технически не может увидеть, если клиент не поставлен на услугу по защите от DDoS-атак. А второе — провайдер контролирует всё, что происходит в инфраструктуре клиента. Наверное, тоже это не очень правильно. Я не говорю, что все так считают, просто встречаем такое. Мы видим по разделению зон ответственности. Почему вообще про зону ответственности говорим? Я со своей стороны, может быть, я в пузыре таком, облачного провайдера, мне кажется, что очень много говорим про зону ответственности и как будто уже всё понятно. Но, разговаривая с некоторыми клиентами, понимаю, что всё равно нужно постоянно это всё проговаривать, объяснять, потому что и наша зона ответственности как провайдера, если мы говорим про инфраструктуру как сервис, это физическая инфра, это виртуализация, это сеть. И вот здесь мы видим. А дальше зона ответственности клиента. И мы как провайдер клиенту предоставляем инструментарий для обеспечения безопасности, очень много есть функций безопасности. И клиент уже, исходя из своей инфраструктуры, этот инструментарий адаптирует под себя и должен настраивать свою защиту самостоятельно, чтобы избегать как раз вот этих моментов, связанных с тем, что его инфраструктуру взломали, а он считает, что это провайдер виноват. Ну и третье — про ключи шифрования. Что все ключи шифрования хранятся у провайдера, и это всё прям хорошо, провайдер знает, как с ними работать, всё с ним будет в порядке всегда. Что тоже не очень соответствует действительности. Мы, конечно, предоставляем сервис по управлению ключами шифрования, и эти ключи шифрования хранятся в облаке, но это не значит, что клиент обязательно должен этот сервис использовать, особенно если у него супер чувствительные данные. Есть прям отличный сценарий, когда клиенты приносят свои ключи шифрования, которые хранятся у них в инфраструктуре и вообще не заливают к нам в облако никакой ключ. Для чего это делается? Делается для того, чтобы в случае взлома инфраструктуры какой-то все образы были зашифрованы, и доступа к ключам не было. Потому что если, например, у клиента есть какая-то учётная запись к облаку с правами на вырост, то, получив к ней доступ, злоумышленник потенциально получает доступ ко всей инфре и ко всем ключам и может вольготно делать всё, что хочет: расшифровать любые данные, зашифровать их заново. И вот мы получаем как бы неработающую инфру.
Кто и где должен хранить ключи шифрования
Антон Ленский: Кстати, говоря о чувствительных данных. Владимир, ты как думаешь, кто и где должен хранить такие данные? Ну, например, вот те же самые ключи шифрования.
Владимир Золотов: Вопрос хороший, на самом деле. Давайте опять же коснусь себя. Госкорпорация, чтобы не задаваться таким вопросом, а как там, кто за что отвечает, за что провайдер отвечает, за что заказчик отвечает, приняла решение о том, что будет просто внутренний поставщик облачных сервисов для всей группы компаний, и мы в этом плане по-любому отвечаем не даже де-юре, а де-факто за сохранность тех данных. И ключи шифрования являются, безусловно, важнейшим компонентом инфраструктуры, поэтому отдавать их на внешнего провайдера, мы уж точно такого решения принять не можем. Для нас это один из самых защищаемых компонентов этой инфраструктуры. Я коллег поддержу: на самом деле разные сценарии бывают, если у заказчика нету соответствующей компетенции, нету соответствующего бюджета на инфраструктурные и в том числе на средства защиты информации, которые бы обеспечивали сохранность этой ключевой информации, в этом просто объективно можно принять решение отдать на сторону провайдера, и там уже дальше самое главное — правильно выверить договорные отношения, SLA и ответственность провайдера за утрату и последующую компрометацию той самой информации. Очень тонкий вопрос: как относительно ключей, так и вообще в целом передача зон ответственности — нету однозначного ответа, абсолютно точно. Это всегда различные сценарии, различные кейсы, это вопрос оценки рисков, последствий этих самых реализаций этих самых угроз и утрат.
Владимир Зайцев: Я ещё по зонам ответственности хотел сказать, что есть такая история, что те, кто научены западными сервисами, они по умолчанию пытаются переложить на облачного провайдера что-то, что у них раньше было. То есть подразумевается, что мы работали вот в этом провайдере, переехали на российского облачного провайдера, и у него по умолчанию это есть. Но, к сожалению, возвращаясь к зрелости российских решений, они, конечно, выросли, но нужно понимать, что западные облачные провайдеры работали на глобальный рынок, соответственно, больше выручка и больше возможностей реализовать что-то. Поэтому вот эти моменты нужно просто прояснять, когда вы переходите в облако, не делать это подразумеваемым. И у нас, например, это зачастую реализуется профессиональным сервисом, так называемым. То есть, когда под конкретного заказчика можно сделать конкретный сервис за отдельную стоимость. Поэтому, чтобы это не было, что мы думали, что это ваша зона ответственности, а это наша зона ответственности, и потом начинается, когда происходит какой-то инцидент, из-за этого начинается конфликт. Не потому, что там, понятно, инцидент, нужно разгребать последствия, но ещё затраты нервов и времени на выяснение, а чья же это зона ответственности, по договору, не по договору, это тоже очень много нервов и времени съедает.
Страхование киберрисков и «кибераптечка»
Антон Ленский: Максим, мне кажется, было бы прикольно страховать зоны ответственности. Есть же у нас сейчас страхование киберрисков, такое не практикуете? Либо всё-таки у нас ещё рынок незрелый киберстрахования?
Максим Долгинин: Надо сказать, что практически все крупные страховые компании сейчас предлагают страхование киберрисков. В этом году даже появилась история про такое лайтовое страхование киберрисков.
Антон Ленский: ОСАГО по ИБ?
Максим Долгинин: КАСКО по ИБ. То есть, когда ты не получаешь компенсацию за время простоя, за недополученную прибыль и прочее, то есть за потери, связанные с реализацией риска, но ты получаешь компенсацию полного восстановления инфраструктуры. Это, наверное, раз в пять снижает страховую премию для клиента. И для многих это история, когда ты можешь хотя бы восстановиться, потому что когда у тебя полностью легла инфраструктура и ты не понимаешь, что делать, у тебя сидит злоумышленник, ты не знаешь, ты его вычистил или нет, что там у тебя ещё осталось или не осталось, тебе нужно привлекать какую-то компанию, которая проведёт расследование, которая составит тебе план митигации. Скорее всего, у тебя нет людей, чтобы это всё делать. И вот эта история, она называется кибераптечка, применяется в целом.
Владимир Золотов: Но это как сервис, это не как страховка.
Максим Долгинин: Ну это как, это знаешь, как ДМС у тебя. Вот ты идёшь в стоматологию. Платишь страховку.
Антон Ленский: Ну там чаще в ДМС стоматология отдельно.
Максим Долгинин: И, ну, можешь входить, можешь не входить, да, условно. В больницу идёшь по ДМС.
Владимир Золотов: Я слышал, на самом деле, тоже такое. Но это я воспринимал на уровне шуток, на самом деле, как страховую компанию, тоже какая-то была пленарочка, закинули шутку, типа: «Давайте пострахуйте».
Максим Долгинин: Я знаю немножко перспективу с точки зрения, например, крупных вендоров по кибербезу. Они посмотрели на эту кибераптечку и говорят: «Знаете, ребята, мы как бы это и так делаем, только сейчас мы хотя бы можем это делать за деньги». Почему? Потому что, когда есть какой-то крупный взлом, естественно, в компании вендор может поступать, основной вендор, который поставляет средства защиты, к ним поступает звонок, говорят: «Ребята, помогайте».
Антон Ленский: А платим потом, сейчас решите проблему.
Максим Долгинин: Не будем платить потом.
Почему страховка не закрывает объекты КИИ
Владимир Золотов: Я почему с неким, не то чтобы скептицизмом, к этой теме отношусь, потому что всё-таки у меня тот уровень защиты и объекты, которые мы защищаем, знаешь, чем объекты какие? За них, на секундочку, уголовная ответственность. Я даже на договорной основе, де-юре не могу эту ответственность передать на провайдера. Хоть там он у тебя выполняет функцию защиты информации потенциально, всё равно ответственность у владельца КИИ. И если вот это тебя ещё страховым подталкивать.
Максим Долгинин: Нет, к ЗОКИИ вообще это не нужно применять. Конечно, это условно для компаний, для которых там важно, не знаю, вот завтра пришли люди на работу, у них 1С-ка пошифрованная.
Владимир Золотов: У них своей компетенции вообще нет от слова совсем.
Максим Долгинин: Конечно, конечно. Это же подавляющее большинство компаний.
Владимир Золотов: Малый бизнес, МСП.
Максим Долгинин: Да, да. У людей там оборот, ну не знаю, там 10–20 миллионов рублей в месяц. Ну какой там кибербез, простите. Хорошо, что если есть бэкапы.
Антон Ленский: На другом сервере.
Максим Долгинин: Я только что другу писал, вот такая же история. У него не было, я говорю, то же самое, что говорил про шифровальщиков, говорю: «Слушай, Лёха, проверь у себя, чего у тебя с бэкапами хотя бы». Он мне сказал, что у него там, да, они бэкапируются куда-то далеко.
Владимир Зайцев: У меня всё в порядке, они тоже зашифрованы.
Максим Долгинин: Они бэкапируются куда-то далеко. И он это такой, напрягся, если честно, потому что он говорит, в целом, если 1С-ка встаёт, то всё, что делать? Очень сложно потом всё это восстанавливать.
Боты, WAF и настройка защиты
Антон Ленский: Вернёмся к злоумышленникам. И у меня вопрос к Владимиру: как мы можем легитимно распределять, кто злоумышленник, кто настоящий пользователь? Ведь много пользователей сидят за VPN-ами, могут выглядеть как боты, кто-то сидит там за headless-браузерами и выглядит как настоящий человек.
Владимир Зайцев: Это одна из таких историй, которая на краю находится. И атаки на ту же самую бизнес-логику с автоматизацией с ботами — это то, что сейчас активно развивается, потому что анти-DDoS и Web Application Firewall, они появились и раньше, и они как-то более-менее изучены, а с бизнес-логикой всё сложнее. Что касается того же самого VPN, тут разницы особой нет, потому что VPN-ом сейчас пользуются все. С одной стороны, есть требования регулятора по ограничению доступа с VPN, с другой стороны, не у всех, и это уже как бы данность, что пользователь может приходить с иностранного IP-адреса, и мы принимаем это просто, что защита должна это принимать как данность, то есть анализировать, строить какие-то метрики, анализировать запросы. Что касается headless-браузеров и автоматизации, то здесь просто отдельная компетенция, отдельное направление, как это детектировать. То есть здесь огромный домен экспертизы, огромные данные используются для того, чтобы блокировать ботов. Опять же, хорошая защита, она, особенно в этом случае, она строится на взаимодействии с заказчиком, то есть на понимании его бизнес-логики. Это то, вот, кстати, возвращаясь к зонам ответственности, это опять же зона ответственности заказчика — уметь объяснить, как работает твоё приложение, потому что у облака нет доступа к коду. Нет доступа к каким-то смежным вещам, которые помогут объяснить, как то или иное действие влияет на бизнес-метрики. И зачастую иногда сталкиваемся с таким требованием, что вот мы там перевели трафик, и по умолчанию облачный провайдер должен магическую кнопку нажать и сам понять, как этот 10–15-летний легаси работает, как запросы ходят и так далее. Это просто невозможно. Поэтому только экспертиза и взаимодействие, обмен информацией. В текущем интернете, особенно с тем количеством регуляторных требований и изменений каждый день, это реально челлендж сейчас.
Антон Ленский: Жалко, нет волшебной кнопки, потому что я даже как мелкий бизнес или микробизнес, когда мы настраиваем защиту от ботов, Web Application Firewall когда настраиваем, нельзя просто взять и поставить защиту на API. Нужно на каждый endpoint, каждое своё правило. То есть ты сидишь, на это тратишь время, ресурсы, и ты можешь всё настроить, а спустя какое-то время, там два дня, если повезло, если никто не ходил по этому endpoint, спустя месяц тебе пишут: «А что у тебя личный кабинет отвалился?» Ты такой сидишь: «Где эта волшебная кнопка, которая изучит просто мои все интерфейсы?»
Как обучаются WAF и антибот
Максим Долгинин: А у меня вопрос есть ещё к Владимиру. Может, ты расскажешь? Я знаю, что перед тем, как клиента посадить на WAF, включить ему Application Firewall, есть какой-то период обучения. Ну, условно, там несколько дней, может быть, там пару недель, включается просто трафик клиентский через WAF, и WAF обучается. Можешь про это рассказать? Это как раз, я так понимаю, в тему того, как он должен быть настроен.
Владимир Зайцев: И с WAF-ом, и с антиботом, и с тем же самым анти-DDoS-ом это всё есть, и это занимает для разных систем разное количество времени и ресурсов. С WAF-ом, да, то есть мы ставим на мониторинг, либо можно сделать какую-то схему с зеркалированием трафика и, соответственно, посмотреть, отметить ложные срабатывания. Но сложнее ситуация всё равно с антиботом происходит, потому что там есть у нас период, когда мы пилотируем, смотрим, как ведёт себя приложение, как, допустим, боты копошатся, делаем какую-то разметку предварительную и потом собираем информацию, допустим, заказчика, банально о том, какие самые критичные endpoint, допустим, там checkout, там рассылка SMS, какие-то такие вещи, авторизация. И дальше уже идёт какая-то итерационная история, потому что с ботами в основном частый запрос — то, что большое количество запросов, оно расходует большое количество ресурсов, то есть платятся какие-то деньги за инфраструктуру, и, естественно, мы срезаем какое-то количество запросов, а дальше уже идёт борьба за false positive, false negative, потому что очень сильно срезать нельзя, потому что это влияет на выручку, на бизнес-показатели, поэтому, как бы, принцип Парето 80/20 с ботами так оно работает. С Web Application Firewall эта история, она давняя, то есть ставится в мониторинг, отмечается false positive и дальше переводится в блокировку.
Владимир Золотов: Обычно уже известны приложения, просто есть под них сигнатуры понятные, и там обучение в этом плане не такое.
Владимир Зайцев: Ну, все WAF в основном, да, это сигнатурный анализ и в какой-то степени тоже поведенческий анализ. Но Web Application Firewall зачастую в бизнес-логику не очень, то есть это обычно отдельное решение, да, оно бывает у того же вендора, что и Web Application Firewall, но обычно там тот же самый анализ API есть в отдельном модуле, когда анализируются просто забытые ручки, сломанная авторизация и так далее.
Сервисы безопасности, которыми пренебрегают, и AI firewall
Антон Ленский: Максим, получается, мы много сейчас поговорили про WAF, да, про анти-DDoS, антибот, а есть какие-то средства защиты, про антивирус мы там сказали, которые заказчики по какой-то причине игнорируют, а потом об этом сильно жалеют?
Максим Долгинин: Да, есть такие, и не один. Мы предоставляем большое количество функций безопасности, уже встроенных в облачную платформу, которые в целом дают заказчику инструмент себя обезопасить. И правильное их применение напрямую влияет на то, насколько инфраструктура безопасна. Но есть, конечно, сервисы, которые применяются постольку-поскольку. Номер один — это IAM. Собственно, это разграничение прав доступа к облачной инфраструктуре, даже не к инфраструктуре, а к личному кабинету, к облачным сервисам. Создаются учётные записи с широкими правами, и, пожалуйста, злоумышленник может получить доступ к этой учётной записи и, по сути, завладеть инфраструктурой облачной. Второе — это мультифакторная авторизация. Третье — это просто банально безопасные настройки виртуальной машины, которую вы разворачиваете. То есть это применение групп безопасности, это включение авторизации не по паролю, а по ключу. Потому что, как я уже говорил и приводил пример сценария: вы виртуалочку запустили, в сеть её вывели — всё, на неё три минуты, пошла атака. Поэтому это на самом деле критичная история. Что ещё из такого можно привести в пример? Это управление сертификатами, например, SSL-сертификатами, которые есть у облачного провайдера. Тоже не все применяют этот сервис, хотя многие облачные провайдеры вообще предоставляют это всё бесплатно. То есть это не то, за что нужно платить. Это просто то, что нужно применить. Потому что облачный провайдер тоже не заинтересован в том, чтобы клиентов прям очень легко ломали. Наверное, такое.
Антон Ленский: Токены, наверное, где-нибудь там ещё, да? Либо это сейчас уже не проблема.
Максим Долгинин: А, хранение секретов. Да, есть такая история про хранение секретов. Secret Manager тоже есть у всех облачных провайдеров. Ну, утечка секретов — это, наверное, третий по популярности сценарий, потому что у разработчика есть локальный репозиторий. В этом репозитории есть .env-файл, в котором хранятся интересные данные, которые вообще никто не должен видеть. И в какой-то момент разработчик решает, что я сейчас это всё запушу как бы в свою сеть, в публичный репозиторий, всё, делает git commit всех этих файлов и отправляет.
Владимир Зайцев: Вы абсолютно правы, я забыл добавить это в gitignore. Сейчас добавлю.
Максим Долгинин: Да, потом добавляет. Но история всё равно всё помнит. Поэтому менеджер сертификатов, менеджер секретов — это то, что стоит брать у облачного провайдера, чем, может быть, пренебрегают. Плюс, ну какие ещё популярные сейчас сервисы вообще в облаке? Там, наверное, номер один по росту — это сервисы, связанные с использованием искусственного интеллекта. Плюс — это сервисы, связанные с работой с контейнерами. Это контейнеры, Kubernetes. И там, конечно, происходит сейчас небольшое такое, скажем так, устаканивание бури, очень активное использование. Люди хотят быстро, быстро, быстро начинать получать какую-то value, безопасностью занимаются потом. То есть те сервисы безопасности, которые есть там, например, у Kubernetes, тот же container security, проверка конфигурации вот этих контейнеров, тоже мало кто применяет. Плюс сама по себе облачная инфраструктура, она мегаволатильна: контейнеры, виртуальные машины создаются по кнопке, через строчку в конфигурационном файле, если мы про Terraform говорим. У тебя может инфраструктура меняться в течение дня, и тебе как минимум нужно применять инструменты для того, чтобы некий контроль за этой инфраструктурой делать. Чем здесь пренебрегают? Вот этим контролем пренебрегают, то есть не используют системы, например, связанные с audit logging, с трассировкой действий в терминале, которые проходят, не применяют средства, которые позволяют в реальном времени, ну или близком к реальному времени, отслеживать конфигурацию виртуальных машин, конфигурацию контейнеров, которые создаются, и подсвечивать как прям инцидент безопасности, например, misconfig или уязвимый образ виртуальных машин, которые развёрнуты. Это важная история, потому что у нас есть уязвимый образ, он, например, торчит в интернет. Естественно, при наличии эксплойта эта уязвимость будет попробована как минимум. А может быть, и успешно реализована. И что позволяет это делать? Есть решения класса CNAPP — Cloud Native Application Protection Platform, которые как раз в себе содержат функции, которые позволяют контролировать состояние виртуальных машин, состояние защищённости инфраструктуры и показать хотя бы клиенту, где у него слабые места и что ему прямо сейчас надо сделать, чтобы эти слабые места убрать.
ИИ в облаке и AI firewall
Антон Ленский: Кстати, сейчас же все облачные провайдеры предоставляют доступ к LLM, да? А кто-нибудь из облачных провайдеров AI firewall предлагает как услугу, либо это зона ответственности заказчика?
Максим Долгинин: Я могу ответить, что, например, у нас есть такой сервис, называется AI Guardrails, через который происходит как раз взаимодействие с LLM. В целом полноценного AI firewall я пока не видел. Ну, в смысле, я вижу, что они есть и что в разработке готовятся какие-то сервисы на уровне облачного провайдера. Клиенты могут уже сами сейчас прямо внедрять и использовать, есть, например, открытые решения. И вообще использование искусственного интеллекта — это фактически большой драйвер по переезду в облако, потому что видеокарточки, потому что нужно разворачивать эти LLM-ки, не у всех есть ресурс, чтобы это делать. Поэтому мы говорим использование AI — уже подразумеваем то или иное облако. Это может быть облако какого-то зарубежного сервиса, может быть облако российского провайдера, который там аналогично зарубежным коллегам предоставляет доступ к большому количеству foundation models, вот этих моделек, которые можно использовать. Конечно, очень важно тут заниматься использованием какой-то регуляции внутри компании использования искусственного интеллекта и применять как минимум guardrails. А как максимум полноценный AI firewall, который позволит хотя бы смотреть, а что отправляется в LLM-ку, чтобы не отправляли сюда ключи шифрования те же самые, чтобы, кстати, кэшировались запросы, например. Потому что токены дорожают, наверное, продолжат дорожать, и кэширование запросов на уровне AI firewall — это прям богатая тема потенциально. Есть на рынке те решения, которые уже там предлагают такие продукты. У нас есть сервис, который называется Guardrails, этот сервис развивается как раз. Сейчас он делает такие базовые штуки, связанные с как раз контролем использования ИИ, чтобы не было там атак, связанных, атак на системный промпт и прочие вещи. И в дальнейшем будем его развивать дальше, в том числе в сторону контроля каких-то конфиденциальных данных, которые передаются, и в сторону кэширования тех же самых запросов, которые идут в сторону LLM.
Команда: растить внутри или отдать на сервис
Антон Ленский: Мы много говорим про безопасность облака, но меня мучает вопрос: как лучше защищать облако? Владимир, как ты думаешь, мы сейчас очень много говорили про сервисы, но достаточно ли нам этих сервисов? Может быть, нам лучше всё-таки растить команду внутри?
Владимир Золотов: На самом деле мы этот вопрос так или иначе немножко затрагивали, потому что всё это следствие вопроса, где нам размещать свою инфраструктуру, сервисы и так далее. Потому что та служба эксплуатации, которая тебе необходима, она как раз и определяется в части ответственности, будет находиться в той или иной части инфраструктуры. Но давайте про себя скажу. У госкорпорации «Росатом» в этом плане, опять же, вопросов не возникало, потому что для нас неприемлемо передавать свои данные на какого-то внешнего провайдера. Вот вернёмся ещё раз. Какая ИТ-функция всё-таки делегирована на сторону внешнего провайдера? Я повторю, считаю, в первую очередь надо смотреть, какие основные бизнес-процессы, core-бизнес-процессы и те функции, которые их обеспечивают, должны оставаться, на мой взгляд, как минимум у крупного бизнеса, у корпораций. Вот, поэтому ИТ-инфраструктура однозначно, да, управление этой инфраструктурой, если есть своё облако, какая-то часть, либо хотя бы просто эта инфраструктура. Инфобез — это прямо однозначно, это core, и управление данными. Отдать на внешнего провайдера можно функции, которые хорошо систематизируются, типизируются, да. Это, первое, вторая линия поддержки. Это, может быть, даже и мониторинг тот же самый в каком-то плане, как сервис можно получать. То есть те функции, которые не являются бизнес-критичными. Если у тебя отвалился мониторинг на какое-то время, это не означает, что бизнес-процессы встали, да. Управление рабочими столами или ещё чем. Моя картина мира такая.
Владимир Зайцев: Я вот хотел немножко эту тему разогнать, про переезд в облака. Мне кажется, что будущее за тем, что регулятор будет сильнее закручивать гайки, и в конечном итоге будет вот какое-то конечное количество облаков, которые могут предоставлять услуги. А вот эта история, в которой мы жили там с момента зарождения интернета, что ты можешь сам в интернете что-то опубликовать, у тебя может быть своя виртуальная машина, своя инфраструктура, с учётом того, что сейчас интернет становится всё более подконтрольным — она, мне кажется, будет всё-таки уходить, и регулятор будет стараться делать историю более предсказуемой, потому что с точки зрения безопасности сейчас есть оборотные штрафы за взлом и так далее, то есть вся эта информация, она попадает в интернет и оттуда не исчезает, и потом используется для атак на другие сервисы. Поэтому в будущем кажется, что компаниям нужно будет очень сильно уметь обосновывать необходимость постройки своей инфраструктуры. Понятно, что есть вот случаи, как с критичной инфраструктурой, а всё остальное, мне кажется, это вот прямая дорога в облако, коммодизация. И сейчас, кажется, люди начали это понимать, что дешевле пойти в облако, просто банально дешевле.
Владимир Золотов: Я абсолютно согласен, поддержу в этом плане. Безусловно, владеть собственной инфраструктурой, импортозамещённой, удовлетворяющей всем требованиям регулятора, обеспечивающей, самое главное, все процессы с точки зрения не на бумаге, а реальные процессы — это очень дорого. Согласен, что регулятор будет закручивать гайки. Это сейчас видно просто по операторам связи даже. Если буквально вчера любой мог получить лицензию операторской деятельности и оказывать доступ в интернет или ещё что-то, а сейчас видно, как регулятор делает всё возможное, чтобы количество таких операторов сокращалось. И как следствие, я думаю, что регуляторика в операторской деятельности с точки зрения облачного провайдера будет абсолютно точно такой же. И это правильно, это зрело, и это будет, в принципе, снимать, наверное, порог вхождения, передачи на доверенного какого-то провайдера своих каких-то core-бизнесов и ИТ-функций.
Антон Ленский: Ужесточение точно будет, это уже и касается и мелкого, малого бизнеса, потому что с 1 сентября этого года, если я не ошибаюсь по срокам, у нас обязательная идентификация доменных имён должна обеспечиваться через «Госуслуги». То есть распределение по зонам ответственности, про которые мы сегодня говорим, оно становится чуть более понятным.
Инцидент: кто что видит и кто его разбирает
Антон Ленский: Но вернёмся всё-таки к тому, с чего мы начали, с кибератак. У меня вопрос к Владимиру: что вы видите в первые минуты атаки, чего не видит сам провайдер, сам заказчик?
Владимир Зайцев: Так как мы работаем больше с HTTP-трафиком, то есть веб в основном, e-commerce тот же самый, видеосервисы, то в этом контексте мы видим, во-первых, уровни, которые до application layer, то есть это третий-четвёртый уровень. Соответственно, атаки могут быть комбинированными, может идти атака на L7. Допустим, защита от сетевых атак, она уже идёт по умолчанию. Если вы покупаете защиту от DDoS, то защита на сетевом уровне, она идёт по умолчанию, и заказчик может даже не знать, что у него в личном кабинете на графике запросов всё тихо, спокойно, но, допустим, была атака на его префиксы. Бывает так, что, допустим, захватили какое-то количество выделенных серверов и просто с одного сервера втупую запустили миллион запросов или больше. Соответственно, этот IP-адрес, он просто заносится в чёрный список на третьем уровне, и фактически трафик превращается просто в SYN-flood. То есть идут пакеты на установление соединений, и всё. На графиках у клиента может быть, допустим, пик по заблокированным запросам, а дальше тишина. Хотя атака на самом деле продолжается, она просто превратилась в попытки соединений. Ну а во всём остальном, что касается седьмого уровня, всю вот эту цепочку reverse proxy, которая проходит запрос, она вся видна. Кэширующий сервер, который ближе всего к пользователю обслуживает запросы, дальше, допустим, идёт второй слой кэширования, дальше идёт Web Application Firewall, антибот-система. На всей этой цепочке есть статистика по седьмому уровню, которая доступна клиенту.
Насколько глубоко провайдер заходит в инфраструктуру при расследовании
Антон Ленский: Максим, ты пару там вопросов назад приводил пример про расследование, если атака произошла, то могут попросить расследовать. В случае облачного провайдера, насколько глубоко облачный провайдер может погружаться в инфраструктуру заказчика при расследовании?
Максим Долгинин: Я, кстати, хотел ещё дополнить Владимира. Раньше была история, когда заказчики покупали WAF, и в этот WAF анти-DDoS не входил. Они условно покупали WAF в одном месте, а анти-DDoS в другом. И нередко возникала коллизия: а что происходит и что делать?
Владимир Золотов: Это на самом деле нормальная история абсолютно. Я вот по себе поясню. У нас, допустим, DDoS мы покупаем от внешнего поставщика услуг, оператора связи, потому что у него есть магистральный канал связи, и реализовывать у себя собственный анти-DDoS на третьем уровне, ну, как-то глупо, потому что ты просто забил канал и ничего не сделал. А WAF вполне мы можем получать от другого провайдера или даже реализовать его у себя.
Максим Долгинин: А мы, как облачный провайдер, сначала продавали WAF от одного поставщика, анти-DDoS — от другого. И столкнулись с какой историей, что часто во время инцидента у тебя получается две зоны ответственности, а сейчас как раз большинство провайдеров, и вы тоже, насколько я знаю — наоборот, ты сказал: «У нас анти-DDoS по умолчанию включён в WAF». Просто WAF без анти-DDoS уже не продают, потому что это одна точка отказа, и ты в одно место даёшь вопрос.
Владимир Золотов: Я поясню, в чём разница. На самом деле, когда мы говорим про анти-DDoS, это тоже разное. Есть L3 анти-DDoS, его лучше всего делать на опорном операторе связи, который максимально близко к тебе подходит. Потому что WAF реализуется как: ты через DNS перенаправляешь трафик на какого-то стороннего провайдера, где происходит очистка, и сделать одновременно тот же самый с трафиком твоим магистральным — это технологически разные подходы. То есть WAF реализует защиту от DDoS на более высоком уровне. А 3–4-й уровень обеспечивает тебе оператор связи опорный. Да, проблема может возникнуть, когда у тебя одновременно атака идёт, то есть под прикрытием DDoS на L3 у тебя происходит ещё где-нибудь там на седьмом уровне, в том числе проникновение. Может быть, в этом плане, конечно, лучше бы это всё дело протаскивать через единую систему. Но из-за того, что технологически это всё-таки разные подходы, в том числе перенаправление трафика на внешнего провайдера, зачастую именно так и происходит.
Максим Долгинин: И тут важно, чтобы у тебя на WAF уже очищенный трафик после L3.
Владимир Золотов: Ну да, но это очень сложно сделать. В этом случае как раз то, что мы сделали сейчас у нас: L3 — защита DDoS у магистралки, а WAF мы делаем свой, чтобы как раз уже от DDoS, очищенного на L3–4 уровне, мы получали уже всё.
Максим Долгинин: Да. И возвращаясь к вопросу, собственно, куда мы смотрим? У нас всё так же зоны ответственности: что инфраструктурный уровень, сетевой уровень, уровень облачной платформы. Базово мы можем предоставить логи со своих уровней, с гипервизора, с облачной платформы, с пользователей, которые в облачной платформе зарегистрированы. То есть мы видим, например, как сервис-менеджера. Я тут увидел админку нашу. Люди всё могут по кнопке делать абсолютно, любой сервис перезапустить в рамках доступа.
Антон Ленский: То есть есть всё-таки у кого-то эта волшебная красная кнопка.
Максим Долгинин: Нет, это не то, что там мы лезем в бизнес-логику заказчика или в какую-то инфраструктуру. Нет, в рамках, например, IaaS и в рамках функционала облачной платформы. Дальше всё, что касается виртуальной машины заказчика, операционных систем, его приклада и прочего, у нас туда доступа нет. Заказчик может попросить нас подключиться, и по запросу заказчика мы можем подключиться, снять необходимые логи, какие-то действия провести. Но чаще всего, когда происходит расследование, каким образом выглядит ситуация, мы даём свою телеметрию. За определённый период то, что мы видим на своём уровне, заказчик даёт на своём уровне, компания, которая делает расследование, например, инцидента, SOC, какой-то, может быть, внешний или там SOC заказчика, они уже объединяют эти данные и работают с ними.
Кто первым видит инцидент
Антон Ленский: Кстати, Владимир, а кто первым видит инцидент: заказчик или провайдер?
Владимир Золотов: Инцидент, опять же, информационной безопасности или инфраструктурный, они все немножко разные, но тем не менее. У нас, по сути, два мониторинга, верхнеуровнево. Один мониторинг — это инфраструктурный, ИТ-мониторинг, который закрывает в чате ИТ-служба, и второй мониторинг — это SOC, SOC по линии инфобеза. Мы в своём мониторинге что можем видеть? Это как раз DDoS-атаки, спуфинги различные, попытка управления ресурсами с точки зрения утилизации процессорных ресурсов, памяти или ещё что-то. Есть круглосуточные смены, которые эту информацию получают и достаточно оперативно на эту тему реагируют. То же самое по линии информационной безопасности: со средств защиты информации это всё собирается. Но реакция пользователя на недоступность сервисов, она зависит от популярности, то есть насколько этот сервис востребован, в нашем случае, насколько он широко используется, насколько в реальном масштабе времени какое количество пользователей им пользуется. В случае недоступности сервиса объективная реакция пользователя молниеносная. Наша задача, чтобы хотя бы наша служба мониторинга и дежурные смены реагировали хотя бы одновременно с пользователем. Поэтому та задача, которая у меня, например, сейчас стоит всё-таки: инфраструктуру отслеживаем, всё хорошо, все компоненты стоят на мониторинге. Но зачастую бывает такое, что, к сожалению, этого недостаточно. Ты должен видеть доступность на уровне самого бизнес-приложения, а это уже более высокий уровень мониторинга. Это надо идти в потоки данных и делать ботов, которые будут отслеживать сам бизнес-приклад, чтобы реагировать в моменте того, как он деградирует. Вот так я считаю. То есть я думаю, всё-таки быстрее пользователей на недоступный сервис среагировать достаточно сложно, но цель именно в этом и стоит, чтобы хотя бы одновременно.
Максим Долгинин: Скажем так, простые пользователи, которые встречаются в инфраструктуре, которые, в целом, вообще могут там не замечать, что у них там что-то происходит. Представьте, у пользователя угнали машинку, буду простые примеры приводить, вот, и эта машинка — часть ботнета, и она там кого-то DDoS-ит. Чей это инцидент? Чья это проблема? Начинают DDoS-ить наши IP-адреса, уже блэклисты попадают. Это пользователь, но он даже не знает. Он платит какие-то копеечки за белый IP-шник. И у нас прям есть ребята, которые это отслеживают и ведут работу.
Антон Ленский: Наказывают?
Максим Долгинин: Мы не можем ничего наказывать, никого наказывать. Мы ограничены договором и законодательством Российской Федерации, поэтому просто оповещаем, связываемся с пользователями, выходим, предупреждаем, иногда там могут какие-то действия.
Антон Ленский: Наказывать — я имею в виду, что вы останавливаете сервис, его виртуалку?
Максим Долгинин: Да, если у нас есть основания для этого, то мы можем остановить.
Владимир Золотов: На самом деле инцидент информационной безопасности, вот мы в договорах прям чётко прописываем, является основанием остановки предоставления сервиса, причём без компенсации абонентской платы, если этот инцидент произошёл со стороны самого заказчика. Это нормально. А момент скорости реакции пользователя, она зависит на самом деле не от той информационной системы, которая работает, а от критичности бизнес-процесса, который обеспечивается с помощью этой самой информационной системы. Если он критичен и интерактивен, то реакция моментальная.
Антон Ленский: Мы с вами поговорили про безопасность в облаке. Хочу перейти к последнему блоку прямых вопросов и начну с Владимира. О каком ограничении защиты заказчик узнает только во время атаки?
Владимир Зайцев: В основном с такими историями можно столкнуться с крупными заказчиками. Любая защита, она так или иначе имеет какие-то общепринятые шаблоны. То есть, если мы говорим о мелких заказчиках, которые, допустим, не приобретают те же самые пакеты управляемой безопасности, настраивают самостоятельно Web Application Firewall, настраивают самостоятельно системы, то зачастую они могут не прикладывать значительного количества времени, ресурсов к этой настройке, то они могут столкнуться, допустим, с какими-то настройками, заранее предзаданными. Банально, ограничение по количеству запросов есть в системе какое-то. Допустим, маркетинговая акция пошла, сделали рассылку в мессенджерах пользователям, допустим, нажали на ссылку, пик трафика пошёл, аномалия, какое-то количество false positive. Был такой случай, причём не раз, забыли пожать изображение в приложении, и приложение стало иметь большой размер, пользователи продолжают пользоваться сайтом как обычно, количество запросов не выросло, трафик резко скакнул вверх. Для системы это может выглядеть как аномалия. То есть изменение в бизнес-логике плюс незнание каких-то предзаданных настроек, которые есть в системе, и зачастую бывает так, особенно по антиботу, что мы приходим, спрашиваем, какая бизнес-логика, объясните. Вот у вас есть endpoint, как они работают, какие там пороги и так далее. И не могут ответить, потому что легаси, потому что разработчик ушёл и что-то такое случилось. И приходится где-то делать настройки на ощупь, и выясняется всё вот как раз-таки в момент вот таких историй, когда начинается false positive, и это всё задевает бизнес-метрики. Возвращаясь к вопросу про инциденты, то, что облачный провайдер, он ограничен в количестве метрик, и незнание бизнес-метрик на стороне приложения, оно очень ограничивает в инструментарии. С крупными заказчиками по этим вопросам коммуницируем, и у нас могут сделать отдельный доступ просто в определённые дашборды, которые мы можем мониторить оперативно и вносить изменения.
Что заказчик получит по SLA, если сервис встал
Антон Ленский: Максим, что заказчик реально получит по SLA, если из-за облачного провайдера встал его сервис?
Максим Долгинин: Какой сервис?
Антон Ленский: Пускай будет бизнес-критичный.
Максим Долгинин: Если мы говорим, что недоступность вызвана какой-то деградацией на стороне облачного провайдера, по вине облачного провайдера, то договором предусмотрена некая компенсация, которая, конечно, ограничена какими-то суммами, какими-то клиентскими платежами, которые сейчас присутствуют. Если мы говорим про сервис безопасности, перестал анти-DDoS работать или ещё что-то, или межсетевой экран отвалился, который предоставляется провайдером, за который отвечает провайдер, вот тут, конечно, очень большие вопросы к такому провайдеру могут быть, что у него сервисы безопасности так могут деградировать, потому что всё-таки к ним предъявляются намного более высокие требования, чем, например, к клиентскому прикладу. У провайдера, конечно, есть безусловная ответственность за те сервисы, которые он предоставляет. Но если, например, у клиента прилёг сайт, а у него не была подключена услуга защиты от DDoS-а плюс WAF, и клиент полагался на общую защиту от DDoS, которая есть, то там в SLA у провайдера прямо прописано, что это не является условно проблемой провайдера, которую необходимо компенсировать для клиента. Это как раз вопрос относится к клиенту. И, конечно, когда клиент размещает инфраструктуру, как мы говорили в начале, нужно с провайдером прояснить, кто за что отвечает, какие функции безопасности клиенту доступны, как он их должен применять. Это очень важная история, потому что сейчас ИТ-инфраструктура — это прям основное наше электричество.
Владимир Зайцев: Я ещё хотел добавить: важно понимать, что чем лучше SLA вы хотите, тем больше вы будете платить, потому что компенсация ограничена. И если вы хотите прям жёсткие условия по компенсации, если вы хотите 4 девятки и так далее, то платёж будет выше, и это до сих пор кого-то удивляет. Но с точки зрения рисков и экономики — это абсолютно понятная история.
Максим Долгинин: На самом деле всё идёт к бизнесу и к целям, которые компания преследует, почему она в облако переезжает или что её удерживает от переезда в облако. Мы всегда считаем экономическую целесообразность, прежде всего, всегда считаем влияние на бизнес. Это нам позволит больше зарабатывать, и это нам позволит снизить наши косты. Это всё, мне кажется, вопрос номер один.
Владимир Золотов: Если реального инцидента недоступности сервиса или инцидента информационной безопасности не произошло, то это проблема только облачного провайдера, потому что это его имиджевые риски. Если инцидент произошёл, в любом случае проблема заказчика, и тут уже вопрос, насколько критичные бизнес-процессы были, которые автоматизированы этим самым сервисом. Но самая проблема, опять же, да, вернусь к этому вопросу: если это объекты КИИ, не дай бог, то там ещё уголовная ответственность. Это точно проблема заказчика, и её переложить даже в виде договорных юридических отношений на поставщика облачного сервиса невозможно.
Максим Долгинин: Я бы так дополнил, что проблема тут возникает у всех. А вот кто ответственный? Тут есть нюансы.
Требования регуляторов, КИИ и договор с провайдером
Антон Ленский: Владимир, что по требованиям регулятора нельзя выносить во внешнее облако?
Владимир Золотов: Начну вот со своей конкретной ситуации. Для меня есть два типа регулятора. Один — это регулятор, который с точки зрения нашего российского законодательства, ФСБ, ФСТЭК и так далее, да, и наш есть внутренний регулятор отраслевой. Вот его требования намного жёстче. И в этом плане я во внешнее облако могу вынести максимум какую-то общедоступную информацию, да и то прям нежелательно. Если даже я буду защищаемую информацию выносить, то там будут такие требования к её защите, то есть я, по сути, должен буду реализовать все те требования, которые у меня должны быть в инфраструктуре реализованы, включая аттестацию, средства защиты информации, сегментацию и всё это дело даже контролировать. И в итоге это будет по косту несопоставимо дороже будет, чем это будет у меня. Если говорить в целом про обычного заказчика, который не обременён такими требованиями регуляторными, внутренними, ну, первое, да, это персональные данные. Персональные данные можно хранить в облаке только на территории Российской Федерации, тут особых таких вот ограничений нет. Второе, гостайну вообще нет. Гостайну вообще нельзя отдавать на внешнее облако. Если ГИСы. По ГИСам требования — 117-й приказ ФСТЭК России, который вышел буквально недавно. Соответственно, размещать ГИСы во внешнем облаке можно, но если этот самый ЦОД аттестован в соответствии со 117-м приказом. Таких аттестованных ЦОДов, если и есть, то очень немного, потому что требования появились только недавно, и пока даже относительно недавно никто толком-то и не знал, а что нужно сделать с точки зрения средств защиты информации, вплоть до обеспечения вычислительной техники средствами доверенной загрузки, все хосты обеспечить этим. Мы с этой задачей сейчас как раз работаем, надеюсь, что мы до конца года аттестуем. То есть непросто сейчас с ГИСами их во внешнее какое-то облако куда-то разместить. И третье, значимые объекты критической информационной инфраструктуры можно разместить во внешнем облаке, но такие требования со стороны ФСТЭК предъявляются, что их реализовать, выполнить очень сложно. То есть ты всё равно, как заказчик, как владелец этого самого объекта КИИ, ты должен контролировать всё с точки зрения эксплуатации, с точки зрения обеспечения защиты информации, процессов и так далее. И сам объект, в котором ты должен размещать, хочешь разместить свой КИИ, он должен быть категорирован как объект КИИ, причём не меньшей категории. В целом прям таких полных запретов, кроме гостайны, нет, но требования настолько существенны, что в текущем времени какие-то серьёзные объекты — ГИСы или КИИ разместить непросто.
Практические советы: технологии, процессы, люди
Антон Ленский: Коллеги, хотел закончить наш диалог практическими советами, небольшими. Про что? Естественно, технологии, люди, процессы. Начну с Владимира, практический совет по выбору технологий касательно нашей темы.
Владимир Зайцев: С 2022 года уже рассказываю, что хочется всё-таки, чтобы мы как-то завершили историю с зарубежными сервисами и всё-таки импортозаместились до конца. И это не какая-то корыстная попытка. Это важно, и интернет дальше будет сегментироваться, как мне кажется. Вот история недавняя с SSL-сертификатами, которая сейчас продолжается, она показывает важность того, что нужно наперёд думать о том, что будет, если вам просто отключат зарубежный сервис. Отличный пример, который показывает, что будет. Поэтому нужно думать наперёд. Считайте деньги, потому что, как мне кажется, в ИТ был такой период, когда было очень много денег, и деньги всё-таки не все умеют считать. То есть все привыкли тратить много, но считать не научились. Поэтому хорошо понимать свой P&L — это залог того, что вы вовремя сориентируетесь, поймёте, что относить в облако, что оставить у себя. Не говорю, что всё нужно отправлять в облако. Что-то оставьте у себя, что-то отдайте в облако, людей перенаправьте на важные работы, какие-то компетенции просто перераспределите, потому что тот же самый ФОТ — это значимая часть затрат. И делитесь компетенцией, рассказывайте про свои успехи, про неудачи в кибербезе у нас не принято по понятной причине рассказывать, это только когда в паблик всё вытекает, все узнают. Поэтому делитесь историями успеха, общайтесь, рассказывайте, что у вас получилось.
Антон Ленский: Очень много говорили про ответственность, поэтому, Максим, вопрос про процессы.
Максим Долгинин: У меня есть прям номер один практический совет, что сделать прямо сейчас со своей инфраструктурой. Я знаю, что он у вас есть, и пропатчьте ваш Confluence, который торчит в интернет. А в целом нужно очень внимательно посмотреть договор с провайдером, во-первых, смотреть, что провайдер обеспечивает, за что он отвечает. То, что касается процессов, и посмотреть, что вас там не устраивает. А так, если вы мигрируете в облачного провайдера, то это действительно процесс, как Владимир говорил, это, по сути, создание новой инфраструктуры, и у вас есть шанс сделать её безопасной по умолчанию, secure by design. Используйте его, используйте те механизмы, которые даёт облачный провайдер, по максимуму. Очень много из них бесплатно, то, что предоставляется бесплатно, мы не ценим, конечно. И помните, что принцип «удобство побеждает осторожность», он вас не доведёт до добра.
Антон Ленский: И у Владимира где-то в середине нашего диалога я спрашивал, что лучше: растить команду или отдавать сервис. Мы проговорили про людей, и поэтому хочется практический какой-то совет по росту человеческого капитала.
Владимир Золотов: Первое: серебряной пули всё равно нету, то есть нету такого вот прям конкретного, точного, чёткого варианта best practice, который взял и себе применил. В этом плане всё-таки внешний облачный провайдер, даже когда ты с ним заключаешь договор и ему делегируешь возможность управления твоими данными, твоими информационными системами, это не означает, что ты полностью на него отдал зону ответственности. Ну, конечно, нет. И поэтому у тебя всё равно должна быть как минимум команда, по сути, функция компетентного заказчика и контролёра качества как постановки задач, так и приёмки результата. От этого зависит очень много, этому нужно максимум внимания уделять, потому что не получится так, что провайдер за тебя полностью всё решил, снял с тебя все риски, такой сидишь: вот он ответит, если вдруг там будет какой-то инцидент. Нет, не ответит. Поэтому компетентные как минимум люди должны быть, которые правильно могут поставить задачу, выбрать этого самого подрядчика, определить с ним процесс взаимодействия. А в целом, если говорить про службу эксплуатации, это, безусловно, очень важная тема. И как обеспечить компетенцию этих людей, этих экспертов, особенно в текущий момент времени, потому что у нас идёт импортозамещение. На секундочку, если ещё вчера мы могли там взять сертифицированных цискарей, вэмварщиков, и ты понимаешь, что с сертификатом ты получаешь уже готового специалиста, то как сейчас, во-первых, этого человека получить, компетентного в конкретных стеках технологий импортозамещённых, дальше его дообучить и удержать — вопрос непраздный. Поэтому очень много внимания придётся уделять правильной передаче компетенций внутри, да, то есть переопылению внутри сотрудников, подходам к обучению внутренних специалистов, да, и их удержанию. Да, это серьёзная работа, но без неё, на мой взгляд, гарантированно получить результаты, стабильность функционирования своих импортозамещённых инфраструктур — практически невозможно.
Антон Ленский: Коллеги, спасибо большое за интересный диалог. Ну а вы, дорогие зрители, спасибо, что досмотрели это видео до конца. Подписывайтесь на нас в социальных сетях и следите за нашими новыми выпусками. До новых встреч.
