Открыть список
Как стать автором
Обновить
177,58
Рейтинг
DataLine
Экосистема ИТ-сервисов

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

Блог компании DataLineИнформационная безопасностьОблачные сервисы

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

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

Теги:enisaсмббезопасность облакабезопасность облачных приложений
Хабы: Блог компании DataLine Информационная безопасность Облачные сервисы
Всего голосов 16: ↑15 и ↓1 +14
Просмотры1.6K

Комментарии 1

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Похожие публикации

Лучшие публикации за сутки