Привет! Меня зовут Леонид Плетнев, я бизнес-партнер по информационной безопасности в 1С-Битрикс.
Современные онлайн-сервисы по автоматизации бизнеса позволяют быстро создать портал и получить полезный функционал: мессенджер, видеозвонки, совместная работа с документами, CRM, ИИ-помощник и многое другое. Пользователь получает доступ к инфраструктуре и функционалу, не думая о серверах и обновлениях. Вендоры прикладных облачных решений обычно обеспечивают легкий старт — пять минут и кажется, что информационная система готова к работе. Но так ли это на самом деле?
Обратимся к определению ИС из ФЗ от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»: информационная система - это совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств.
Аналогичный термин из ФЗ № 152-ФЗ «О персональных данных»: информационная система персональных данных - совокупность содержащихся в базах данных персональных данных и обеспечивающих их обработку информационных технологий и технических средств.
SaaS не является полноценной информационной системой, а только средой (environment), предоставляющей набор инструментов для автоматизации. Простыми словами, это «болванка» будущей ИС. Информационной системой в разрезе безопасности он становится только тогда, когда вы:
Провели предпроектное обследование и проектирование информационной системы (хотя бы эскизное), включая:
определение конкретных бизнес и технологических процессов обработки именно ваших корпоративных данных;
описание будущей информационной системы как объекта защиты, в том числе с учетом необходимых данных от провайдера;
квалификация данных, которые будут обрабатываться в облаке и определение применимых требований регуляторов по защите информации;
моделирование применимых угроз и сценариев действий нарушителя;
определение зон ответственности за обеспечение защиты между вашей компанией и провайдером;
формулирование организационно-технических мероприятий по противодействию актуальным угрозам на всех уровнях ответственности, определение мер, которые предпринимаются SaaS-провайдером в области его ответственности;
оформление технического проекта на информационную систему, сбор необходимой эксплуатационной документации от SaaS-вендора;
Настроили систему и осуществили необходимые интеграции: безопасное конфигурирование, обеспечили безопасность интеграций с вашими on-premise решениями, которые остаются за периметром облака, интегрировали новую информационную систему с процессами системы управления информационной безопасностью компании;
Провели приемо-сдаточные испытания и запустили ИС в эксплуатацию: начали обрабатывать корпоративные данные в SaaS в соответствии с проектной и эксплуатационной документацией.
Распространённое заблуждение среди компаний, использующих прикладные облачные сервисы, заключается в уверенности, что за информационную безопасность полностью отвечает провайдер. Действительно, в зону прямой компетенции оператора SaaS входит большой стек задач по защите информации, но и на стороне клиента также остаются организационные и технические обязанности.
При выборе SaaS решения клиенту необходимо оценить риски информационной безопасности, находящиеся в зоне ответственности провайдера.
Для этого:
проводятся интервью;
изучается документация;
запрашиваются подтверждения и заверения о принимаемых мерах защиты.
Часть из них можно провести на клиентской стороне, например, проверить используемые TLS-сертификаты, применяемое шифрование, заголовки безопасности.
В качестве свидетельств могут выступать:
сертификаты о соответствии процессов компании стандартам безопасности (например, ISO 2700x, ГОСТ Р 56939-2024);
аттестаты соответствия законодательству информационных систем провайдера;
сертификаты регуляторов на используемое программное обеспечение;
техническая и юридическая документация на сайте провайдера;
заверенные письменные ответы вендора на клиентские запросы;
результаты технических проверок (пентесты, сканирования, баг-баунти).
Оценку полезно совместить с определением вариантов выполнения применимых требований регуляторов и моделированием угроз, чтобы заодно не упустить важные аспекты. Остановимся на основных элементах, про которые средние компании часто спрашивают SaaS-вендоров.
Как отмечалось выше, клиентом облачного сервиса должен быть осмыслен объект защиты и формализовано его описание:
физические компоненты информационной системы, их расположение;
каналы связи и телекоммуникационное оборудование;
системные и прикладные составляющие;
автоматизируемые бизнес или производственные процессы;
интеграции с внешними системами;
типы пользователей;
состав обрабатываемых данных, их потоки.
Детальность описания объекта защиты определяется рамками распределения ответственности между сторонами, вариантами свидетельств от SaaS-вендора. При этом общая картина все равно должна быть формализована самим клиентом.
Следующим этапом оцениваются возможные негативные последствия от реализации угроз безопасности информации в контексте нарушения бизнес- или производственных процессов и юридических, репутационных, финансовых рисков. Также исходя из описания объекта защиты определяются объекты негативного воздействия: сетевое оборудование, серверы, АРМ и пользователи, различные виды ПО, базы данных и средства защиты. При этом необходимо учесть критичные конфигурационные файлы, элементы, хранящие данные идентификации, аутентификации, ключевую информацию API и шифрования.
Пример распределения ответственности по различным системным уровням объектов негативного воздействия указан на рисунке:
Оператор сервиса может делегировать зоны ответственности другим провайдерам. Для обеспечения высокой доступности часто используются ЦОДы, которые могут отдавать SaaS-оператору сервис на уровне co-location, IaaS или PaaS.
Дополнительно к системным уровням, по которым идет распределение ответственности, рассматриваются возможные нарушители. В зоне рисков со стороны сервис-провайдера из внешних в первую очередь, оцениваются негативные возможности хакеров, уволенного персонала, конкурентов, поставщиков ПО и дополнительных сервисов. К внутренним нарушителям относят сотрудников, обеспечивающих работу SaaS и имеющих физический доступ в контролируемую зону с размещенным оборудованием или полномочия по автоматизированному (логическому) доступу к информационным ресурсам и компонентам (работники ЦОДов, SaaS-вендора).
Например, список актуальных возможных нарушителей может включать:
1) Внешних нарушителей:
одиночных хакеров и группы преступников;
конкурентов;
2) Внутренних нарушителей на уровне провайдера:
обслуживающий персонал (администрация, охранники, инженеры климат-систем, охранной, пожарной сигнализаций);
техников, осуществляющих обслуживание оборудования на аппаратном уровне;
системных администраторов;
уволенных работников с привилегиями доступа;
3) Внутренних нарушителей на уровне сотрудников компании-пользователя SaaS:
действующих легитимных пользователей (сотрудники, клиенты) с разными ролями доступа;
уволенных работников с привилегиями доступа.
При этом следует различать негативные возможности сотрудников ЦОДов и ИТ-персонала офисных площадок SaaS-вендора, исходя из уровня доступа к различным объектам воздействия.
Следующим этапом уже смотрим какие угрозы могут быть актуальны с учетом типов нарушителей, их возможностей, вероятных способов и сценариев реализации каждой рассматриваемой угрозы. Для «комплаенса» используют соответствующие методики, типовые модели и базы данных от регуляторов, а для задачи разграничения ответственности можно работать с группами угроз.
Угрозы, связанные с авариями на уровне оборудования и инженерных систем обеспечения его работы, а также аварий из-за погодных условий, стихийных бедствий;
Угрозы несанкционированного физического доступа к оборудованию;
Угрозы непреднамеренного негативного воздействия от сотрудника сервис-провайдера на работу системы или на данные;
Угрозы несанкционированного автоматизированного (логического) доступа к настройкам, конфигурациям, данным в результате атак внутреннего нарушителя – сотрудника сервис-провайдера;
Угрозы несанкционированного автоматизированного (логического) доступа к настройкам, конфигурациям, данным в результате внешних атак.
Для каждой группы необходимо изучить реализацию процессов у сервис-провайдера, детализируя требования к ним в ходе взаимодействия с SaaS-провайдером при выборе его решения.
В части несанкционированного физического доступа и аварий на аппаратном уровне SaaS-вендор совместно с провайдером инфраструктуры несет ответственность за обеспечение физической безопасности, организации внутри-объектового и контрольно-пропускного режима доступа на площадки размещения серверной инфраструктуры и в офисы, из которых работают системные администраторы (здесь полезно уточнить варианты доступа «удаленщиков»). Плюс вопросы инженерного обеспечения, влияющие на надежность: электроснабжение, климат-контроль, пожаротушение, защита от затопления и т.п.
В части противодействия угрозам в первую очередь необходимо уточнять по каким критериям у SaaS-вендора выстроена система менеджмента информационной безопасности (СМИБ). Исходя из этой информации подготовить перечень вопросов по реализованным процессам ИБ.
Если SaaS-вендор сам использует сервис-провайдеров, то уточните как выстроены процессы управления ими, включая:
Процедуры отбора и проверки провайдеров;
Обязательства по ИБ;
Обязательства ЦОДов по обеспечению доступности;
Наличие нескольких независимых ЦОДов (при наличии соответствующих обязательств со стороны вендора);
Условия форс-мажора.
Для ЦОДов полезно уточнить организационные и технические способы изоляции инфраструктуры:
Физическая изоляция серверов;
Изоляция сервисной инфраструктуры и сетей ЦОДа от ресурсов и сетей клиентов ЦОДа;
Изоляция сервисов управления арендуемой инфраструктурой между клиентами;
В зависимости от уровня закупаемого сервиса, изоляция клиентов на уровне гипервизора, виртуальных машин, ОС, СУБД.
Помимо ЦОДов вендор облачного приложения может использовать других провайдеров, в части технической поддержки, заказной разработки ПО, смежных прикладных сервисов (например, телефонии), инфраструктурных услуг (например, antiddos) и т.п. Они также в области внимания клиента.
В рамках проверки СМИБ уточняем каким образом реализованы процессы на всех системных уровнях для каждого вида потенциального нарушителя и типа угрозы:
Безопасное конфигурирование системных компонентов;
Применение средств защиты, встроенное качество безопасности;
Процессы управления доступом, модели доступа, минимальные права доступа, разделение сред;
Процедуры идентификации, аутентификации;
Управление изменениями, обновления;
Конвейер DevSecOps;
Выявление и управление уязвимостями (сканирования, пен-тесты, баг-баунти, SBOM-анализ), выпуск хот-фисксов (экстренных обновлений);
Обеспечение непрерывности, резервирование и восстановление;
Обучение и повышение осведомленности;
Аудит, логирование, мониторинг, анализ событий (в том числе в контексте непреднамеренных действий сотрудников);
Реагирование, управление инцидентами;
Соответствие законодательству.
В вопросе соблюдения регуляторных требований продолжает действовать модель разделенной ответственности. SaaS-провайдер не может полностью гарантировать соответствие созданной на базе облачного сервиса информационной системы, которая принадлежит клиенту, так как не управляет бизнес и технологическими процессами клиента и не контролирует загрузку данных, обрабатываемых в облачном сервисе. С другой стороны, клиент не может самостоятельно обеспечить выполнение требований потому, что большинство системных уровней сервиса неподконтрольны ему и управляются провайдером.
Практика показывает, что приведение информационной системы в соответствие имеет специфику для каждого клиента. В данном случае провайдер способен предложить услуги компаний-партнеров, занимающимися лицензируемыми видами деятельности по защите информации, включая «комплаенс», а также обеспечить собственное соответствие применимым к нему требований законодательства по информационной безопасности. В части 152-ФЗ важно помнить: наличие сертификатов у провайдера не освобождает Оператора персональных данных (Клиента) от обязанности уведомить Роскомнадзор и обеспечить правовые основания обработки (согласия, договоры и т.д.).
Далее разделение ответственности между сторонами в контексте процессов СМИБ переходит в рассмотрение кто и как применяет механизмы безопасности. Пример приведен в таблице ниже.
Тип ответственности | Сторона, в чьей зоне ответственность |
Механизмы управления доступом к данным на уровне приложения (определение и настройка ролей доступа, предоставление и отзыв доступа в приложении) | Компания-клиент SaaS |
Механизмы ИБ, которые отдаются клиенту как опция в приложении (например, настройка сложности паролей, параметров сессии, ограничений доступа к адиминке и тп) | Компания-клиент SaaS |
Механизмы регистрации событий ИБ на уровне управления доступом, и логирования действий пользователей приложения (мониторинг событий, аудит действий пользователей и реагирование) | Компания-клиент SaaS |
Встроенные параметры безопасности виртуальных машин, ОС, сред исполнения, системных приложений, обязательных настроек ИБ прикладного приложения (настройка и эксплуатация согласно бенчмаркам и документации) | Вендор облачного приложения |
Средства защиты информации на уровне приложения, включая antiDDoS, WAF, контроль сеансов и сессий, шифрование, антивирусное ПО, контроль целостности и тп (настройка и эксплуатация согласно бенчмаркам и документации) | Вендор облачного приложения |
Механизмы регистрации событий ИБ на уровне виртуальных машин, ОС, сред исполнения, системных приложений, приложения, средств защиты (сбор и хранение, мониторинг и аудит системных событий/доступа персонала вендора и реагирование в дополнение к мониторингу и реагированию от клиента) | Вендор облачного приложения |
Средства защиты информации на инфраструктурном уровне L3/4, включая antiDDoS, IDS/IPS, FW, защита гипервизоров, шифрование, антивирусное ПО, контроль целостности и тп (настройка и эксплуатация согласно бенчмаркам и документации) | Вендор облачного приложения |
Механизмы регистрации событий ИБ на уровне инфраструктуры (сбор и хранение, мониторинг событий и реагирование) | Провайдеры инфраструктуры по договору с вендором облачного приложения |
Физическая безопасность оборудования | Провайдеры инфраструктуры по договору с вендором облачного приложения |
Устойчивость к стихийным бедствиям и катастрофам | Провайдеры инфраструктуры по договору с вендором облачного приложения |
Обеспечение безопасности информационной системы, созданной на базе облачного приложения не может быть достигнуто усилиями лишь одной стороны и никогда не сводится к единственному организационному или техническому решению: эта задача по своей природе многослойна и требует от клиента и провайдера чёткого понимания границ своих полномочий и зон ответственности, поскольку только их согласованное взаимодействие способно создать условия, которые по-настоящему помогают клиенту облачного сервиса экономить время и ресурсы, облегчая достижение бизнес и производственных целей.
