В Bitrix24 разобрали, почему облачный сервис сам по себе не делает вашу систему «защищённой», и где заканчиваются обязанности провайдера. В материале — понятная логика разделения ответственности и практический список вопросов, которые стоит задать SaaS-вендору до запуска.
Облачные сервисы выглядят как «быстрый старт»: зарегистрировались, включили нужные функции — и можно работать. Но с точки зрения информационной безопасности так не бывает: SaaS даёт платформу и инфраструктуру, а защищённой информационной системой она становится только после того, как вы описали свои процессы, данные и правила доступа.
Почему «мы в облаке» ≠ «мы в безопасности»
В материале Bitrix24 проводят простую мысль: SaaS — это среда и набор инструментов для автоматизации. По-настоящему «вашей» информационной системой она становится, когда вы:
- спроектировали, какие данные и зачем обрабатываются (хотя бы на уровне эскиза);
- квалифицировали данные и поняли, какие требования применимы (в том числе регуляторные);
- смоделировали угрозы и сценарии действий нарушителя;
- зафиксировали границы ответственности между вашей компанией и провайдером;
- настроили систему и интеграции так, чтобы они не создавали новые «дырки»;
- провели приёмочные испытания и запустили работу по правилам, которые сами же описали.
Если этого нет, получается типичная ловушка: сервис удобный, данные уже «переехали», а кто за что отвечает — выясняется только после первого инцидента.
Разделённая ответственность: что проверять ещё до внедрения
Авторы отмечают распространённое заблуждение: «за безопасность полностью отвечает провайдер». На практике у провайдера действительно большой пласт задач (инфраструктура, процессы защиты, мониторинг, обновления), но у клиента остаются организационные и технические обязанности — прежде всего на уровне настройки приложения и управления пользователями.
Чтобы оценить риски на стороне SaaS-вендора, предлагается действовать прагматично:
- провести интервью (вопросы по процессам ИБ и эксплуатации);
- изучить доступную документацию;
- запросить подтверждения и заверения о мерах защиты;
- часть базовой проверки выполнить самостоятельно (например, проверить TLS-сертификаты, параметры шифрования и «заголовки безопасности»).
Какие «свидетельства» обычно просят у вендора
- сертификаты соответствия процессам стандартов (например, ISO 2700x, ГОСТ Р 56939-2024);
- аттестаты соответствия для информационных систем провайдера;
- сертификаты регуляторов на используемое ПО (если применимо);
- официальная техническая и юридическая документация;
- заверенные письменные ответы на запросы;
- результаты технических проверок: пентесты, сканирования, баг-баунти.
Кто на самом деле «провайдер»: цепочка может быть длиннее
Отдельный полезный акцент: SaaS-вендор может делегировать часть ответственности другим организациям — например, дата-центрам и поставщикам инфраструктуры (co-location, IaaS, PaaS), а также подрядчикам на смежные сервисы.
Поэтому в вопросах безопасности важно смотреть не только на «витрину» продукта, но и на то, как устроены:
- отбор и контроль подрядчиков;
- обязательства по доступности и форс-мажору;
- изоляция инфраструктуры (между клиентами и внутри сервисных контуров);
- контур управления доступом у персонала, который обслуживает площадки.
Какие угрозы учитывать: не только хакеры
В статье предлагают рассматривать и внешних нарушителей (одиночные хакеры, группы, конкуренты), и внутренних — на стороне провайдера (админы, техники, персонал с физическим доступом, бывшие сотрудники с привилегиями), и внутренних на стороне клиента (пользователи с разными ролями, в том числе уволенные).
Дальше угрозы удобно группировать, чтобы не утонуть в деталях:
- аварии и инциденты на уровне оборудования и инженерных систем;
- несанкционированный физический доступ;
- ошибочные действия сотрудников;
- внутренние атаки с логическим доступом;
- внешние атаки на настройки и данные.
Где проходит граница: короткая шпаргалка
Ключевая «земная» часть для большинства компаний — кто что делает в ежедневной эксплуатации. В статье приводится примерное распределение, и его легко приземлить на реальные сценарии.
Обычно зона клиента — это управление внутри приложения
- роли и права: кто видит сделки, документы, чаты, отчёты;
- выдача и отзыв доступа сотрудникам и внешним пользователям;
- включение опций безопасности, которые провайдер даёт «в коробке» (политика паролей, параметры сессий, ограничения на вход в админку и т.п.);
- аудит действий пользователей и реакция на подозрительные события на уровне бизнес-логики.
Обычно зона провайдера — защита платформы и инфраструктуры
- безопасная конфигурация системных компонентов;
- средства защиты на уровне приложения и инфраструктуры (включая противодействие DDoS, WAF и др. механизмы);
- управление изменениями и обновлениями, DevSecOps-подходы;
- управление уязвимостями и экстренные исправления;
- резервирование и восстановление, непрерывность;
- сбор и хранение системных событий, мониторинг и реагирование в своей зоне ответственности.
Комплаенс тоже «делится»: важный нюанс для 152-ФЗ
Авторы отдельно подчёркивают: даже если у провайдера есть сертификаты и подтверждения, это не делает ваш проект автоматически соответствующим требованиям. Провайдер не управляет вашими бизнес-процессами и содержимым данных, а клиент не контролирует многие системные уровни сервиса.
Как следствие, соответствие достигается только совместной работой — и это почти всегда «индивидуальная сборка» под конкретную компанию и её сценарии.
Практический вывод: что сделать прямо сейчас
- Составьте карту данных: какие данные вы кладёте в SaaS и кто к ним должен иметь доступ.
- Проверьте роли: минимальные права, разделение обязанностей, отдельные учётки для администрирования.
- Опишите интеграции и точки, где лежат ключи API, токены и конфигурации.
- Сформируйте список вопросов провайдеру по процессам ИБ, обновлениям, инцидентам и подрядчикам (ЦОД, antiDDoS, телефония и т.д.).
- Заранее договоритесь о коммуникации: кто и как будет действовать при инциденте, какие сроки и каналы.
Идея простая: безопасность SaaS — это не чекбокс «мы выбрали облако», а договорённость о правилах, подтверждённая настройками и процессами. Тогда сервис действительно экономит время, а не превращается в риск, который обнаруживается слишком поздно.
Источник: Хабр (блог компании Битрикс24)
