Используем чек-лист ENISA для проверки безопасности облачного провайдера и чтения SLA

Когда некрупные компании выбирают облачные ИТ-сервисы, они сразу смотрят на экономию времени и денег. Но вот оценить безопасность сервиса  “на глаз” без опыта обычно не получается. Даже если компании внимательно читают соглашение с облачным провайдером, они не всегда знают, на что обращать внимание. 

Европейское агентство по сетевой и информационной безопасности (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 кажется нам актуальным. Давайте в комментариях обсудим ваши варианты, какой список вопросов к провайдеру предложили бы вы?