[Информационная безопасность, Облачные сервисы] Используем чек-лист ENISA для проверки безопасности облачного провайдера и чтения SLA

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
18-Фев-2021 14:33

Цитировать

Когда некрупные компании выбирают облачные ИТ-сервисы, они сразу смотрят на экономию времени и денег. Но вот оценить безопасность сервиса “на глаз” без опыта обычно не получается. Даже если компании внимательно читают соглашение с облачным провайдером, они не всегда знают, на что обращать внимание. Европейское агентство по сетевой и информационной безопасности (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 кажется нам актуальным. Давайте в комментариях обсудим ваши варианты, какой список вопросов к провайдеру предложили бы вы?
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_oblachnye_servisy (Облачные сервисы), #_enisa, #_smb (смб), #_bezopasnost_oblaka (безопасность облака), #_bezopasnost_oblachnyh_prilozhenij (безопасность облачных приложений), #_blog_kompanii_dataline (
Блог компании DataLine
), #_informatsionnaja_bezopasnost (
Информационная безопасность
), #_oblachnye_servisy (
Облачные сервисы
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 15:39
Часовой пояс: UTC + 5