Когда некрупные компании выбирают облачные ИТ-сервисы, они сразу смотрят на экономию времени и денег. Но вот оценить безопасность сервиса “на глаз” без опыта обычно не получается. Даже если компании внимательно читают соглашение с облачным провайдером, они не всегда знают, на что обращать внимание.
Европейское агентство по сетевой и информационной безопасности (ENISA) решило помочь небольшим компаниям и создало Cloud Security Guide for SMEs. Этот гайд описывает риски ИБ для среднего и малого бизнеса, помогает сформулировать правильные вопросы к облачному провайдеру и проверить соглашение об уровне обслуживания (SLA). Не все из этого списка можно проверить наверняка, но какие-то пункты вполне подтверждаются сертификатами и лицензиями.
Сегодня смотрим внимательнее на список вопросов к провайдеру. Оценим его свежим взглядом, дополним примерами из российской практики и выясним, какие доказательства от провайдера действительно могут гарантировать защиту данных в облаке.
1. Как провайдер в целом управляет рисками информационной безопасности?
В ответ на этот вопрос мы найдем верхнеуровневую информацию по безопасности выбранного облака. Заодно поймем, кто именно отвечает за ИБ и есть ли с кого спрашивать в случае инцидентов.
Хороший знак, если у провайдера есть:
политика по управлению информационной безопасностью;
выделенное контактное лицо для решения запросов по ИБ;
результаты аудитов безопасности. Как минимум, это могут быть итоги самопроверки провайдера по известным стандартам, например, по матрице оценки облачных рисков Cloud Controls Matrix от Cloud Security Alliance, по стандарту ISO/IEC 27017:2015 или реестру безопасности, доверия и гарантий (STAR). Еще лучше, если соответствие этим стандартам подтверждают внешние аудиторские компании.
сертификаты по стандартам управления ИБ, например, ISO/IEC 27001. В этом случае смотрим в сертификате, какие именно сервисы попали в скоуп.
2. Какие задачи по ИБ берет на себя провайдер, а какие инциденты остаются под ответственностью клиента?
Если эти вопросы включены в договор, то ответственность провайдера за защиту данных можно будет обсуждать в правовом поле.
Ответ на вопрос будет зависеть от типа сервиса и включенных в него активов. ENISA предлагают пользоваться такой упрощенной схемой:
Чем больше компонентов включает облачный сервис, тем больше вопросов может возникнуть. Например, в случае с SaaS возможен вариант, что хостинг сервиса принадлежит одной компании, а сам программный продукт — другой. Тогда дополнительно смотрим, как ответственность распределяется между компаниями.
Хороший знак, если у провайдера:
в договоре есть отдельный список задач по ИБ, которые выполняет провайдер. Например, для облака с сертификатом по стандарту PCI DSS такой список есть в соглашении об ответственности сторон за выполнение требований стандарта. Вот как это может выглядеть:
Кто за что отвечает, указано в таблице. описаны конкретные примеры, как провайдер реагирует на инциденты безопасности и расследует их;
обязанности по защите информации прописаны в SLA;
в соглашении указаны конкретные показатели: время реагирования на инцидент ИБ и сроки его решения, прописана ответственность за нарушение обязательств.
3. Как облачный сервис защищен от катастроф и ЧС, какие данные и где бэкапятся в этом случае?
Физическая безопасность серверов в дата-центре может повлиять на информационную безопасность.
На Западе принята точка зрения, что сначала компании нужно обеспечить непрерывность бизнеса и минимизировать риск отказа процессов, а затем переходить к вопросам ИБ. Но для многих компаний ИТ становится основным активом, и значимость ИБ растет. Поэтому часто оба риска рассматривают в комплексном DR-плане, где каждая компания сама расставляет приоритеты.
Так что смотрим на надежность облака с точки зрения стандартов проектирования и эксплуатации дата-центров. Следование им не касается ИБ напрямую, но демонстрирует, что у провайдера есть план на случай катастрофы.
Хороший знак, если:
дата-центр, в котором размещено облако, сертифицирован по стандартам Uptime Institute;
для дата-центра указан уровень резервирования основных инженерных систем, описаны возможности георезервирования и зоны доступности для облака;
у провайдера есть план послеаварийного восстановления, и он может предложить инструменты послеаварийного восстановления клиенту;
в соглашении с провайдером указаны конкретные показатели на случай аварий, например, показатели допустимого простоя сервисов и допустимой потери данных (RTO и RPO).
4. Как провайдер гарантирует доступность сервиса на случай административных и юридических конфликтов?
На доступ к данным в облаке могут повлиять юридические аспекты работы провайдера. Если в отношении провайдера идет судебный процесс, решения суда могут затронуть его имущество, в том числе оборудование с данными клиента. Проблемы с доступом к данным могут возникнуть и в результате конфликтов — за примерами далеко ходить не надо.
Смотрим в договоре, предусмотрен ли порядок действий на этот случай.
Хороший знак, если в соглашении:
есть условия предоставления сервиса на случай административных конфликтов, банкротства, влияния новых нормативно-правовых актов и решений судов;
прописаны гарантии выгрузки данных в случае юридических конфликтов.
5. Как провайдер гарантирует, что сотрудники соблюдают меры ИБ?
Сотрудники провайдера могут иметь доступ к клиентским данным: их высокая грамотность снижает риск непреднамеренных утечек. Например, если сотрудники внимательно настраивают права доступа и следуют парольной политике, то сложнее взломать их учетки и украсть данные.
Проверяем, что провайдер рассказывает про квалификацию своих специалистов в области ИБ.
Хороший знак, если провайдер:
составил внутреннюю политику по ИБ для сотрудников;
регулярно проводит для сотрудников обучение по ИБ, а ключевые специалисты подтверждают свой уровень сертификатами;
проводит внутренние пентесты и может показать их результаты (например, как здесь);
разработал отдельные процедуры для тех, кто имеет доступ к чувствительной информации.
6. Как данные клиента защищены от несанкционированного доступа?
Разобрались с внутренними угрозами, теперь спросим про защиту от внешних атак. Данные должны быть защищены физически и программно, чтобы злоумышленники не могли атаковать сервис или физически пробраться в дата-центр к конкретному серверу.
Хороший знак, если у провайдера:
есть сертификат по стандарту ISO/IEC 27001;
есть сертификат по стандарту PCI DSS;
используются механизмы многофакторной аутентификации;
внедрена система контроля доступа или управления учетными данными (IdM), есть иерархия ролей, привилегий.
7. Как провайдер обеспечивает безопасность используемого ПО?
В облачном сервисе провайдер может предложить как собственные, так и сторонние программные продукты. Смотрим, как провайдер заботится о безопасности стороннего ПО и нет ли здесь “слепых зон”, за которые никто не отвечает. Специалисты ENISA делают акцент на том, что у программного продукта в облаке должна быть вендорская техподдержка, которая несет ответственность за решение инцидентов ИБ.
Хороший знак, если:
в сервисе используется актуальное ПО последней версии, оно регулярно обновляется, и есть ответственные за обновление;
программисты провайдера используют безопасные практики разработки ПО и регулярно проходят обучение по информационной безопасности;
в компании есть практики управления уязвимостями: в поддержке ПО выделены сотрудники для быстрой реакции на инциденты ИБ, время их реакции регламентировано, провайдер проводит сканирование сервиса на уязвимости и предоставляет отчеты о сканировании;
используемое ПО прошло независимый аудит безопасности.
8. Как провайдер защищает доступ к API и другим служебным интерфейсам?
Доступ к облачным сервисам в интернете может быть открыт с помощью веб-интерфейсов или API. Стараемся убедиться, что наружу не торчит ничего лишнего, а все интерфейсы защищены от несанкционированного доступа.
Хороший знак, если:
используются методы многофакторной аутентификации к общедоступным и служебным интерфейсам;
провайдер разграничивает роли и привилегии для менеджмент-сегмента;
интерфейс администратора защищается отдельными средствами.
9. Как клиент может следить за работой сервиса, какие события записываются в журнал, как к ним предоставляется доступ?
У клиента должна быть информация о событиях безопасности в виде отчетов, логов или графиков. В случае инцидента эти данные помогут расследовать причины случившегося.
Хороший знак, если у провайдера есть:
система мониторинга и логирования для клиентов;
система оповещений о событиях безопасности для клиента;
обязательства по ведению истории событий, прописанные в SLA.
10. Какие стандарты обеспечивают совместимость облачных платформ и сервисов?
Даже если с выбранным облаком все хорошо, всегда продумываем риск миграции в другое место. Это не должно вызывать сложностей из-за необычного формата хранения данных или запутанных сценариев выгрузки.
Хороший знак, если провайдер:
использует общепринятые или распространенные форматы и стандарты интерфейсов для GUI, API, языка разработки;
обеспечивает возможность экспорта виртуальных машин и данных.
11. Как провайдер управляет возрастающими и пиковыми нагрузками на сервис, и каковы связанные с этим риски?
Этим вопросом получим информацию о риске переподписки. Переподписка возникает, если провайдер бронирует за клиентами больше ресурсов, чем есть физически. Это нормальная практика, так как ресурсы бронируются с запасом. На рынке есть допустимые коэффициенты переподписки, которые облачные провайдеры выяснили опытным путем.
Клиентов должно интересовать, что провайдер следит за переподпиской и будет готов предложить варианты на случай резкого роста потребления.
Хороший знак, если у провайдера есть:
калькуляторы для сайзинга сервиса;
примеры сценариев масштабирования;
журналы производительности и расхода ресурсов;
пункты в SLA, которые регламентируют условия доступности сервиса при росте нагрузки.
12. Какому национальному законодательству подчиняется провайдер и как выполняет требования по локализации?
Клиент может хранить в облаке пользовательские данные и попадать под действие закона “О персональных данных”. По требованиям 152-ФЗ персональные данные должны быть локализованы в России, так что смотрим на физические адреса серверов для выбранного облака.
Что проверить:
географическое расположение дата-центров;
где зарегистрировано юридическое лицо;
ссылается ли провайдер в своих документах на Закон о персональных данных.
В целом, чек-лист ENISA кажется нам актуальным. Давайте в комментариях обсудим ваши варианты, какой список вопросов к провайдеру предложили бы вы?
