5/6/2024
В ИТ хватает тем, о которые разбили сотни копий и, скорее всего, разобьют еще. Разделение зон ответственности в облачной инфраструктуре — точно входит в этот список.
Здесь как с автомобилями. Автоконцерн может вкладывать миллионы долларов в создание самой безопасной машины. Однако какой в этом смысл, если водитель отказывается соблюдать скоростной режим и ленится поставить зимнюю резину?
В этом отношении показательны прогнозы Gartner. Исследователи считают: до 2025 года включительно 99% сбоев в облачной безопасности будут происходить по вине заказчика. Некомпетентность здесь не при чем, просто технологии так быстро развиваются, что большинство не успевает приспособиться к ним. Компании с трудом оценивают всю полноту рисков, связанных с использованием облачных вычислений.
Однако разберем вопрос по порядку.
Бизнес понимают выгоду облачных технологий, но сохраняет опасения, связанные со страхом утечек данных, несанкционированного доступа к ним третьих лиц, а также потери или удаления информации. Распространение облаков само по себе вряд ли сможет победить опасения. Более того — мы наблюдаем два тренда, которые эти опасения усугубят.
В мире прослеживается глобальный запрос на рост вычислительных мощностей. Его диктуют возможности новых технологий, в первую очередь ИИ и Web3, а также потребность в хранении и обработки данных. Это выводы Gartner, однако похожие прогнозы встречаются и у «большой четверки» аудиторов.
Быстрее остальных растут облачные инфраструктурные сервисы. По мнению экспертов Gartner, к 2026 году тренд только укрепиться, и 75% организаций в мире будут выстраивать стратегию цифровой трансформации на облачном фундаменте.
Можно возразить — выводы Gartner масштабны и отражают «среднюю температуру по больнице». Справедливы ли прогнозы для России?
Отечественный облачный рынок рос и до 2022 года. Однако последние годы стали катализатором процесса перехода на отечественные решения. Помогли и меры поддержки отрасли со стороны властей, и освободившиеся после ухода иностранцев ниши.
В 2022 году российский облачный рынок увеличился почти в 1,5 раза до 86 млрд рублей, а в 2023 году — до 121 млрд рублей. Эксперты пророчат, что в 2024 году завершится основная волна миграции в российские облака. Потенциально это снизит рост выручки, но не исключит других драйверов рынка. Речь идет о потребности в новых технологиях и цифровизации в целом.
Еще пару слов о цифровой зрелости. Она составила 74%, а затраты на ИТ превысили 540 млрд рублей. Это значительно выше даже позитивных прогнозов Министерства цифрового развития.
В 2023 году рынок облачной безопасности оценили почти в 41 млрд долларов. По прогнозам, он может вырасти до 106 млрд долларов уже к 2029 году.
Безопасность — критически важный фактор, который предприятия рассматривают при принятии решения об использовании облаков. Для малого и среднего бизнеса развертывание инфраструктуры в облаке — это эффективное использование финансовых, временных и кадровых ресурсов. Существует несколько уровней обеспечения информационной безопасности, и часть этой ответственности можно переложить на плечи провайдера и избежать дополнительных немалых инвестиций в инфраструктуру безопасности.
При этом безопасность стабильно входит в топы факторов, которые стопорят переход компаний в облачную инфраструктуру. Так мы видим, как встречаются два тренда: проникновение облаков и рост запросов со стороны безопасности. В точке соприкосновения и появляются вопросы к разделению ответственности.
Ответственность — это всегда вопрос контроля, хоть и с оговорками. Вспомните, как работает обслуживание газа в многоквартирном доме. Труба до вентиля относится к поставщику, а после — уже к собственнику жилья. При этом вентиль всегда находится внутри кухни. С облаками похожая история.
В России распространена именно практика ответственности. Ее можно охарактеризовать так: кто контролирует компонент, тот за него и отвечает. При этом неверно подводить под одни стандарты IaaS, PaaS и SaaS. Все-таки они принципиально отличаются в своей основе.
Схематически это можно изобразить следующим образом:
Что включает в себя каждый компонент таблицы:
1. Пользователи. Физические или юридические лица, которые взаимодействуют с облачной инфраструктурой. Это могут быть конечные пользователи, администраторы и разработчики.
Пользователи получают доступ к облачным ресурсам для выполнения различных задач, начиная от использования приложений и заканчивая управлением и развертыванием облачных сервисов.
2. Данные. Охватывают всю информацию, которая хранится, обрабатывается и передается внутри облачной инфраструктуры.
Данные — это основный актив современного. Первое, что приходит в голову: записи о пользователях, данные приложений и системные журналы. Важной такой информации объяснять не нужно.
3. Приложения. ПО, которое работает в облачной инфраструктуре и использует его вычислительные ресурсы.
Это может быть что угодно: веб-приложения, мобильные приложения, корпоративное программное обеспечение, микросервисы и многое другое. Облачные приложения часто разрабатываются таким образом, чтобы быть масштабируемыми и распределенными, использовать возможности облака для обработки различных нагрузок и обеспечивать высокую доступность.
4. Гостевая ОС. Гостевой называют операционную систему, работающую на виртуальной машине (ВМ) в облачной инфраструктуре. Она работает поверх основной операционной системы, предоставляемой физическим оборудованием поставщика облачных услуг. Примерами гостевых ОС являются Windows Server, различные дистрибутивы Linux и другие операционные системы, которые пользователи развертывают для запуска своих приложений.
5. Виртуализация. Ключевая технология облачной инфраструктуры, которая позволяет запускать несколько виртуальных машин на одном физическом сервере. Она абстрагирует аппаратные ресурсы, обеспечивая эффективное использование и изоляцию различных рабочих нагрузок.
5. Сеть. Отвечает за взаимодействие различных компонентов в облаке, включая виртуальные машины, хранилища, приложения и пользователей. Облачные провайдеры предлагают инструменты и сервисы для управления сетевыми параметрами и их настройки в соответствии с потребностями пользователей.
6. Инфраструктура. Физические серверы, устройства хранения данных, сетевое оборудование и ПО управляющее этими ресурсами. В контексте облаков инфраструктура абстрагирована и предлагается пользователям в формате услуги (IaaS).
7. Физический уровень. Управляется поставщиком облачных услуг. Физический уровень отвечает за физические аспекты вычислений, включая питание, охлаждение, физическую безопасность и обслуживание оборудования.
Поставщик облачных услуг отвечает за управление физической инфраструктурой, уровнем виртуализации и сетевой безопасностью. Клиент, в свою очередь, отвечает за управление виртуальными машинами, операционными системами, приложениями, данными и конкретными конфигурациями безопасности.
Ответственность провайдера:
— Физическая защита инфраструктуры в центре обработки данных. При этом у провайдера может быть собственный ЦОД или партнерский.
— Управление технической сетью, которая поддерживает облачные операции и обеспечивает подключение к провайдерам и к интернету.
— Контроль среды виртуализации и связанных с ней систем, их безопасность и работоспособность.
— Управление доступом и его безопасность для администраторов провайдера.
— Защита рабочих станций администраторов.
— Журналы, созданные облачными компонентами.
— Обновление инфраструктуры и защита от уязвимостей.
Ответственность заказчика:
— Развертывание и управление виртуальными машинами.
— Безопасность доступа в интернет.
— Взаимодействие с ВМ: обновление антивирусной защиты, мониторинг уязвимостей.
— Управление авторизацией и доступом к операционной системе и ПО.
— Обеспечивает безопасность и обновление приложений, а также устраняет уязвимости.
— Контроль доступа сотрудников, включая разрешения на обращение в службу технической поддержки.
— Ведение журнала и анализ инцидентов.
— Защита данных и их шифрование (если нужно).
В модели PaaS провайдер берет на себя ответственность за управление и обеспечение безопасности базовой инфраструктуры, операционной системы, промежуточного ПО и среды выполнения. Заказчик занимается разработкой, развертыванием и управлением приложениями, а также защитой данных и конфигураций приложений.
Ответственность провайдера:
— Все, что справедливо для IaaS.
— Обеспечивает безопасный доступ для своих администраторов, включая антивирусную защиту и регулярные обновления.
— Поддерживает безопасность предоставляемой платформы путем обновления, мониторинга и устранения уязвимостей.
— Следит за тем, чтобы учетные записи пользователей клиентов были актуальными и соответствовали требованиям к сложности паролей и политике обновления.
— Собирает и хранит журналы платформы в целях мониторинга и обеспечения безопасности.
Ответственность клиента:
— Разработка, развертывание и управление собственными приложениями на платформе. Внедрение мер безопасности, таких как защита кода, устранение уязвимостей и применение исправлений на уровне приложений.
— Обеспечение безопасности своих данных в рамках платформы: шифрование, целостность данных и контроль доступа. Соблюдение отраслевых стандартов в части обращения с данными.
— Управление идентификацией и доступом (IAM). Настройка и управление доступом пользователей, ролями и разрешениями в их приложениях. Настройка среды PaaS в соответствии с их конкретными потребностями, включая настройку необходимых интеграций и сервисов.
— Мониторинг приложений и реагирование на инциденты.
Провайдер берет на себя большую часть ответственности, включая управление приложением, базовой инфраструктурой и безопасностью. Клиент же сосредоточен на управлении пользователями, данными и настройке приложения под свои нужды.
Ответственность провайдера:
— Управление ПО. Разработка, поддержка и обновление самого SaaS-приложения. Сюда входят исправления ошибок, обновления функций, безопасность платформы и общие улучшения.
— Управление физическим оборудованием, включая серверы, хранилища и сетевое оборудование, и его техническое обслуживание.
— Доступность и производительность сервисов. Обеспечение высокой доступности и надежности SaaS-приложения в соответствии с соглашением об уровне обслуживания (SLA).
— Безопасность данных, их шифрование и соблюдение требований регуляторов.
Ответственность клиента:
— Управление идентификацией и доступом (IAM). Важно корректно распределить роли и разрешения пользователей.
— Обучение пользователей правилам работы с SaaS-решением и средствами аутентификации.
Описанное разделение зон контроля в IaaS, PaaS и SaaS поможет закрыть большинство вопросов. Однако остаются «серые зоны», которые от случая к случаю могут трактоваться по-разному.
Эти «серые зоны» часто возникают из-за сложности и взаимозависимости облачных сервисов. Вот несколько примеров и пояснений:
1. Настройка параметров безопасности
Облачный провайдер обычно предлагает ряд функций и инструментов для обеспечения безопасности. Часто это шифрование, брандмауэры и службы управления идентификационными данными. Однако ответственность за правильную настройку этих инструментов лежит на клиенте. Иногда их вообще игнорируют.
2. Шифрование данных
Поставщик может гарантировать, что инфраструктура поддерживает шифрование, но заказчик должен решить, какие данные следует зашифровать, и надежно управлять ключами. Неправильное использование ключей может привести к утечке данных.
3. Управление идентификацией и доступом (IAM)
Если клиент неправильно настроит политики IAM или не будет регулярно обновлять разрешения и роли, может произойти несанкционированный доступ.
4. Управление обновлениями
Может возникнуть путаница в вопросе о том, кто отвечает за исправление в случаях, когда уязвимости охватывают как обязанности провайдера, так и заказчика. Например, если уязвимость ОС затрагивает предложение PaaS, может быть неясно, кто и что должен исправлять, особенно если исправление поставщика затрагивает клиентские приложения.
5. Соответствие нормам и юридические обязанности
Провайдер обеспечивает соответствие инфраструктуры определенным стандартам и законам и предоставляют инструменты, помогающие клиентам выполнять эти требования.
Если нормативные требования не соблюдаются, бывает сложно определить, предложил ли провайдер недостаточные инструменты и рекомендации или заказчик не смог должным образом использовать предоставленные инструменты и услуги.
6. Реакция на инциденты
В случае инцидентов, затрагивающих инфраструктуру провайдера и среду заказчика, определение границ ответственности может быть крайне запутанным. Координация и сотрудничество между обеими сторонами необходимы, но ответственность все равно может быть спорной.
Как и указал в начале статьи, полностью избежать спорных зон вряд ли получится. Однако их можно минимизировать.
Предлагайте подробную документацию и руководства, которые четко описывают обязанности провайдера и заказчика. Включайте пошаговые инструкции по настройке и управлению конфигурациями безопасности, использованию инструментов шифрования и выполнению других важных задач.
Убедитесь, что SLA четко определяет обязанности по безопасности как поставщика, так и клиента. Это должно включать в себя конкретику по шифрованию данных, управлению патчами, реагированию на инциденты и соблюдению нормативных требований.
Регулярно обновляйте SLA, чтобы учитывать изменения в услугах, практиках безопасности или нормативных требованиях.
Предоставляйте специализированные команды поддержки по безопасности, к которым клиенты могут обращаться за помощью с настройкой безопасности и решением проблем.
Проводите регулярные внутренние аудиты безопасности. Это поможет убедиться, что инфраструктура и услуги соответствуют актуальным стандартам.
При этом результаты аудитов должны находиться в открытом доступе, чтобы любой желающий мог с ними ознакомиться.
Регулярно информируйте клиентов об обновлениях безопасности, изменениях в обязанностях и новых доступных функциях или инструментах.
Установите четкие, совместные процедуры реагирования на инциденты, которые определяют, как обе стороны будут реагировать на нештатные ситуации и управлять ими. Убедитесь, что клиенты знают, как сообщать о проблемах и какую поддержку они могут ожидать.
Представленные рекомендации нельзя назвать исчерпывающими, хоть они и помогут прояснить распределение обязанностей по безопасности и снизить вероятность возникновения «серых зон» ответственности.
О ключевых факторах, определяющих развитие рынка систем безопасности, своем видении конкурентного ландшафта, а также о приоритетных направлениях развития компании в 2024 году рассказал Роман Георгиевич Паршин, руководитель направления защиты государственной тайны «Инферит Безопасность».
Архитектор Linux — кто это? Что из себя представляет дистрибутив ОС Linux и чем отличается от Windows? Что изменилось за последние 30 лет? Кому нужна эта операционная система? Как долго нужно учиться, чтобы стать архитектором? Эти и другие вопросы «Компьютерра» задала Леониду Кантеру, архитектору по интеграции ОС «МСВСфера» от «Инферит». Погружаемся в историю и узнаём, как выглядели операционные системы 30 лет назад и как Linux может стать ведущей ОС в России с уходом Microsoft с этого рынка.
Универсальные облачные решения формально подходят для любого бизнеса. Однако, в некоторых отраслях важно соблюдение особых требований — например, сертификации, соответствия ГОСТам, различным нормативам регуляторов, возможности интеграции со специализированным программным обеспечением и устройствами. Подробно тему отраслевых облаков раскрыл Виталий Ранн, директор по продукту «Инферит Облако».