Привет, Хабр!

Меня зовут Сергей Борисов, я отвечаю за инфобезопасность в MANGO OFFICE. Сегодня хочу осветить тему отказоустойчивости облачных ИТ-систем и рассказать, как мы в компании решаем эти вопросы.

Основные уязвимости облачных IT-систем

Тут Америку не откроем. Есть два типа уязвимостей:

Возможность несанкционированного доступа к данным клиента со стороны провайдера облачного сервиса. Этим и опасно хранение чувствительных данных в публичных хранилищах. Наша компания также выступает как провайдер хранилищ, но мы в нашем продукте — Гибридной АТС, сочетающей функции облака и железной АТС — решили проблему доступа тем, что внутренний медиатрафик остается внутри сети клиента, к нам попадает только сигнальный трафик. В будущем планируем реализовать проект, где сигнальный трафик у нас тоже храниться не будет.
Вторая главная уязвимость — потеря доступности системы. Если одним словом: нет интернета, значит, нет возможности работать с облаком, в то время как On-Premise-решения работают даже без доступа к сети.

Если говорить об уязвимостях, появившихся в последнее время, то, в первую очередь, они обусловлены тем, что в большинстве случаев облачные сервисы использовали иностранные средства защиты. Уход иностранных вендоров, отсутствие возможности продлевать и докупать лицензии оставили ИТ-инфраструктуры без должной защиты до перехода на решения российских вендоров. К примеру, у нас в компании было облачное решение для исследования уязвимостей Tenable I.O. Купили мы его 1 февраля 2022 года, а уже 27 февраля нас отключили от обслуживания (без возврата денег). В итоге мы перешли на российское решение.

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

Как измеряется продукт с точки зрения безопасности

Продукт можно измерять с точки зрения безопасности следующим образом:

RTO (Recovery Time Objective) — целевое время восстановления системы после сбоя.
RPO (Recovery Point Objective) — целевая точка восстановления на шкале времени относительно сбоя, до которой требуется сохранить данные.
SLA (Service Level Agreement) — соглашение об уровне предоставления услуг. Это обязательство об уровне сервиса продукта/услуги, взятое компанией перед клиентом. Очень важна гарантированная доступность сервиса в течение года: сколько раз могут случаться сбои и какое время может быть недоступна система. Есть компании, заявляющие доступность 99,99 %, то есть в год система может не быть доступна 0,01 %.
Гарантия конфиденциальности данных. При анализе рисков конкретного продукта нужно смотреть, какую гарантию по производительности дает производитель. Никто не гарантирует 100 %, но конфиденциальность — тоже метрика, ее можно оценить (сколько было случаев потери данных у продукта). Если больше одного–двух, доверия к продуктам нет.
Целостность данных. Юзер пользуется данными, например, создавая подборку на стриминговом сервисе, а при следующем визите подборка слетает. Это показатель того, что данные повреждены. Если таких случаев не было, значит, с компания надежно их хранит.

Как SSDLC помогает предотвращать угрозы на уровне разработки продукта

SSDLS — это процесс безопасной разработки, при котором на всех этапах жизненного цикла разработки ПО учитываются риски инфобезопасности, выявляются и устраняются уязвимости в программном коде, чтобы в релиз выпускался продукт безопасный как с точки зрения кода, так и с точки зрения архитектуры логики работы.

Вот так он выглядит в нашей компании:

Основные метрики, применяемые в нашем SSDLC-процессе:

Количество выявленных и подтвержденных уязвимостей в процессе эксплуатации кода в текущих релизах продуктов. В идеале они должны стремиться к нулю. На практике, конечно, определенная уязвимость есть всегда, но если над кодом работает сильная команда и в компании есть application security, то есть человек, отвечающий за безопасность приложения, — продукты выпускаются зрелыми.
Зрелость процесса безопасной разработки по SAMM v2.0. Вычисляется для текущих команд на основе собственных исследований.
Доля автоматизации. Показатель применения автоматизированных средств анализа инфобезопасности в проектах команд в CICD-процессах.
Доля покрытия команд процессом безопасной разработки. Метрика показывает соотношение команд, которые участвуют в процессе безопасной разработки, ко всем командам (участием считается взаимодействие с командой, использование автоматизации, исправление и обсуждение вопросов).

Защита продукта во время эксплуатации

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

Для защиты продукта нужно разработать модель угроз для данного продукта, оценить вероятность их возникновения и, исходя из актуальных угроз для продукта, реализовать набор мер по его защите (технических и организационных).

Инструменты применяются различные, в зависимости от актуальной угрозы: межсетевые экраны, регулярные сканирования на уязвимости, системы мониторинга событий информационной безопасности, обнаружения сетевых атак внутри сети и во внешнем контуре, контроля и разграничения прав данных, шифрование, системы контроля утечек данных, выявления вредоносного кода, выявления атак нулевого дня (Zero day).

Атаки Zero Day — угрозы, которые только что появилось, и никто еще не знает, как от них защититься. Но есть решения, которые, используя машинную логику, выявляют такого рода атаки.

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

К чему мы стремимся

Нет предела совершенству, и мы (как и все, вероятно) стремимся к ближайшему к 100 % показателю отказоустойчивости систем. Но на практике редкие компании могут подтвердить бесперебойность 99,999 % (а это означает, что система может быть недоступна 5 минут 15 секунд в год) и только для узких наборов сервисов. Обычно это касается, к примеру, систем электропитания, которые находятся в ЦОД. Сейчас по рынку эталон — 99,95 %. В процент доступности должны входить: восстановление в случае сбоя и плановые работы. У нас в компании по некоторым услугам уровень отказоустойчивости 99,99 %, подтвержденный исторически.

Здесь нужно учитывать параметр, в котором кроется сложность: в течение какого времени мы будем восстанавливаться в случае сбоя. Система может отлично работать и падать очень редко, но когда упадет — восстанавливается час–два. И именно из-за этого некоторые компании могут проигрывать в конечных показателях доступности.

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

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

Подписывайтесь на наши соцсети:

Аккаунты Mango Office

ВКонтакте: https://vk.com/mangotelecom
Телеграм: https://t.me/mango_office

Основные метрики бесперебойности облачных IT-систем