Cloud compliance
Last updated
Was this helpful?
Last updated
Was this helpful?
Продолжаем знакомить вас с аспектами информационной безопасности при использовании услуг облачных провайдеров в нашей серии статей.
В предыдущей публикации мы начали рассказывать, как выполнить требования по информационной безопасности, если нужно разместить свою систему в облаке.
В этой статье ответим на такие вопросы:
Где проходит граница между зонами ответственности клиента и провайдера?
Можно ли ее двигать и как ее закрепить?
Как выбрать облачного провайдера и конечный перечень услуг, чтобы быть уверенным в выполнении требований стандартов и законов в должной степени?
Покупая облачные сервисы, клиент рассчитывает, что он не будет заниматься непрофильной для него деятельностью, а вся работа по поддержанию инфраструктуры ляжет на облачного провайдера. Аналогичное допущение для услуг по информационной безопасности, к сожалению, не работает.
Пока все идет хорошо клиент ИБ-системы воспринимает ее по принципу «работает — и хорошо», но, в случае взлома, он сразу заявляет, что ожидал гарантий безопасности. Некоторые даже могут сразу требовать от провайдера обеспечить абсолютную невзламываемость облачного решения.
Поэтому иногда очень большой проблемой становится доступно объяснить заказчику, что абсолютной невзламываемости не бывает. Во многих случаях провайдер может обеспечить работоспособность ИБ-системы, но не может сам придумать логику ее работы и правила защиты.
Безусловно, облачный провайдер занимается безопасностью собственного облака, но в традиционных IТ-системах показателями качества являются работоспособность и скорость работы. От информационной безопасности же ожидают отсутствия инцидентов и соответствия требованиям законодательства и стандартов.
Но инциденты ИБ – это не деградация производительности, которую сравнительно легко измерить, или отключение системы (хотя и так бывает); они в конечном итоге, связаны с данными или процессом их обработки. И измерять их критичность, да и просто понять, что является просто лог-записью, а что инцидентом — тяжело. Например, антивирус среагировал на вредоносный вирус или на легитимный скрипт? Если это был вирус, а антивирус его заблокировал — это же хорошо. А если не заблокировал, то сколько компьютеров заразилось, и кто несет ответственность за то, что специальное средство защиты от вирусов не справилось?
Кроме того, законодательство и стандарты вводят понятие финансовой ответственности за несоблюдение требований по ИБ. Поэтому услуги по информационной безопасности сложны измерением их качества и ответственностью, которая может наступить не только за случившиеся инциденты ИБ, но и за несоответствие требованиям даже при отсутствии реальных взломов.
Кроме того, абсолютной защищенности не бывает: даже теоретически невозможно гарантировать полное отсутствие взломов системы. Поэтому при взаимодействии с облачным провайдером очень важно определить и юридически закрепить – кто за что отвечает: что входит в зону ответственности провайдера, а что – в зону ответственности клиента.
Ответ на этот вопрос зависит от вида самой услуги и ее практической реализации.
Базово здесь применима такая логика:
Все то, что контролирует облачный провайдер и что не может контролировать клиент облака – должно находиться в зоне ответственности облачного провайдера.
Все то, что контролирует клиент облака и не может контролировать облачный провайдер – должно находиться в зоне ответственности клиента.
На практике же есть еще несколько дополнительных факторов:
Провайдер может предлагать дополнительные услуги, требующие обеспечения безопасности или услуги ИБ.
«Серые зоны». Услуги или технические решения, контролировать которые может как провайдер, так и исполнитель.
С услугами, находящимися на стыке зон ответственности, применим подход «кто принимает решения – тот и отвечает за реализацию».
Провайдер предоставляет виртуальные мощности для развертывания услуги. При этом он не создает виртуальные машины и не имеет контроля над их содержимым.
Таким образом, провайдер контролирует:
Помещения, в которых расположено облако (ЦОД). И отвечает за физическую защиту этих помещений;
Техническую сеть, обеспечивающую жизнедеятельность облака и коннекты с провайдерами и Интернетом;
Среду виртуализации, и служебные системы, обеспечивающие жизнедеятельность облака. И отвечает за защиту среды виртуализации; доверенную загрузку виртуальных машин; антивирусную защиту служебных компонент облака; а также защиту от несанкционированного доступа к служебным компонентам облака.
Управление доступом собственных администраторов;
Защиту рабочих мест собственных администраторов;
Сбор и хранение логов, созданных компонентами облака.
Также облачный провайдер своими силами обеспечивает процессы обновления, выявления и устранения уязвимостей на уровне облака.
Клиент получает виртуальные мощности, на которых разворачивает свои виртуальные машины, устанавливает свое ПО и пускает туда своих пользователей.
Таким образом, именно клиент контролирует:
Сегментирование и защиту доступа в интернет;
Антивирусную защиту ВМ;
Обновленность ВМ;
Контроль и устранение уязвимостей в ВМ;
Авторизацию и настройку доступа к ОС и к ПО;
Защищенность приложений: их обновленность, отсутствие уязвимостей;
Управление доступом своих сотрудников. В том числе выдача права сотрудникам оставлять заявки в службе технической поддержки провайдера.
Настройки логирования в приложениях. Выявление и анализ инцидентов ИБ.
Защиту данных в движении. Фактически – действия легальных пользователей.
Шифрование данных, при необходимости.
Самое сложное – с серой зоной. Она чаще всего возникает либо по технологическим причинам, либо как какой-то дополнительный сервис от провайдера. В серой зоне обычно действует логика «тот, кто может знать как нужно – тот и отвечает».
В серой зоне оказываются следующие меры защиты:
Управление доступом сотрудников клиента в ЦОД. Если у сотрудника был пропуск в ЦОД, и сотрудник уволился, а пропуск забыли отозвать – то провайдер не может узнать о факте увольнения.
Межсетевое экранирование.
С технологической точки зрения, провайдер автоматически предоставляет клиентам какой-то межсетевой экран.
Но, во-первых, этот межсетевой экран может не обладать каким-то функционалом, требующимся для стандарта: например, базовый межсетевой экран VMWare NSX Edge не умеет работать как IPS. А стандарт PCI DSS требует наличия IPS.
Во-вторых, этот межсетевой экран может не обладать каким-либо сертификатом ФСТЭК, требующимся клиенту. И это не тот же самый межсетевой экран, которым провайдер защищает само облако – клиенту нужен свой межсетевой экран.
В-третьих, кто-то должен на этом межсетевом экране настраивать правила доступа. И придумать эти правила может только клиент – провайдер просто не знает, какими сетевыми портами приложения клиента могут пользоваться легитимно.
Резервное копирование. Провайдер его обычно умеет делать, но именно клиент должен сказать – что именно нужно копировать, как часто, и как долго хранить.
Хранение и обработка логов. Многие провайдеры могут предоставлять услугу хранения логов. Это востребованная услуга, так как логи способны занимать достаточно большие объемы дискового пространства, а хранить их требуется долго.
Но между хранением логов и анализом инцидентов ИБ есть большая разница: анализ инцидентов ИБ производится с использованием логов, и знания о том, какие события и в каких системах выглядят подозрительно или неправильно.
Шифрование жестких дисков виртуальных машин. Так как с одной стороны – шифрование нужно для того, чтобы провайдер гарантировано не смог увидеть данные, а с другой стороны – гипервизор должен иметь возможность запустить виртуальную машину. Т.е. в гипервизор, обслуживаемый провайдером, придется загрузить ключи расшифровки.
Защита доступа к данным при оказании услуги администрирования виртуальной машины или приложений в облаке.
Провайдер может оказывать услуги администрирования ОС или ПО на виртуальных машинах, размещенных в облаке. Но тут есть два нюанса. Первый — не факт, что процесс доступа сотрудников провайдера к ресурсам клиента нужно приводить в соответствие требованиям 152-ФЗ. Второй - под достаточно простым словом «администрирование» может скрываться множество сложных процессов: например, должен ли администратор следить за актуальностью версий ОС, или просто обновлять по запросу? Если администратор должен самостоятельно следить за актуальностью – то может ли он просто обновлять ОС, или должен как-то тестировать совместимость с ПО, работающем на обновляемом сервере? Если ПО не совместимо – то что делать с обновлением? Может ли и должен ли администратор следить за составом ПО и системных сервисов на администрируемом сервере? Если да, то как он понимает, какие сервисы и ПО являются разрешенными? И что делать, если ПО не совместимо с обновлением ОС?
Часто клиенты спрашивают:
Что же такого сложного в передаче услуги по обновлению ОС, или в выполнении мер по контролю конфигураций?
Контроль конфигураций фактически сводится к анализу обновленности: контролю установленного ПО, установленной версии, доступных обновлений и статуса успешности установки этих обновлений, а также настроек этого ПО, и к приведению их в соответствие с документами. А пример со сложностью процесса обновления мы уже рассмотрели выше.
Провайдер предоставляет клиенту виртуальные мощности, на которых уже развернута и настроена какая-то платформа работы с данными или с приложениями.
Наиболее распространенные примеры: DBaaS, сервис контейнеризации, S3.
Провайдер контролирует:
Все, что было описано для IaaS;
Защищенность доступа собственных администраторов к администрированию платформы (антивирусная защита, обновленность и т.д.);
Защищенность предоставляемой платформы: обновленность, контроль и устранение уязвимостей;
Актуальность созданных учетных записей пользователей клиентов и соответствие их паролей политикам сложности и обновляемости паролей;
Сбор и хранение логов платформы
Клиент контролирует:
Корректность настроек и конфигураций того, что работает внутри платформы: нода в случае с контейнеризацией; логической структуры БД в случае с DBaaS; настроек публичного доступа в случае с S3.
Управление доступом своих сотрудников. В том числе – выдача права сотрудникам оставлять заявки в службе технической поддержки провайдера.
Настройки логирования в приложениях. Выявление и анализ инцидентов ИБ.
Защиту данных в движении. Фактически – действия легальных пользователей
В серой зоне оказываются следующие меры защиты:
Межсетевое экранирование. По уже описанным причинам
Резервное копирование. По тем же причинам.
Обработка логов. И с ней становится сложнее: настройка сбора логов обычно осуществляется на уровне платформы. А вот как клиент хочет анализировать логи, и что ему важно видеть в логах – может сильно варьироваться.
Применение необязательных средств защиты, установка которых требуется на уровне ОС (вне контроля пользователя). Например, нужен ли антивирус для S3? Не всем, и не обязательно его реализовывать на уровне S3.
В случае с PaaS наиболее распространенной проблемой является как раз обновление и установка патчей безопасности: по большому счету, провайдер либо поддерживает единую конфигурацию всех копий платформы, либо позволяет настраивать каждую копию платформы под различные запросы клиентов.
Но если все копии платформы настроены единообразно, то есть шанс, что клиенты, использующие legacy-ПО или legacy-методы рано или поздно столкнутся с несовместимостью своего ПО и платформы. А если провайдер настраивает каждую отдельную копию платформы под потребности клиента, то снова возникает необходимость описывать процесс обновлений, и определять кто несет ответственность, если обновиться нет возможности.
В этом случае провайдер берет на себя вообще все IТ- и ИБ-части работы и предлагает клиентам возможность просто использовать приложение: web-диск, или 1С, и тому подобное.
С точки зрения пользователя все просто – все контролирует провайдер.
Но для провайдера это сложно, поэтому клиенту желательно выяснять, как провайдер это реализует.
Можно, но заказчику нужно к этому подготовиться.
Фактически, при любом увеличении ответственности провайдера, клиент должен провайдеру описать, как именно нужно работать.
Если провайдер должен контролировать обновленность, то:
Каких пакетов (только ОС, или еще какое-то ПО)?
Что провайдер должен делать с выявленными не обновленными машинами?
Если провайдер должен их обновлять – должен ли он тестировать совместимость с ПО? И как?
Если ПО не совместимо с обновлениями – что должен сделать провайдер.
Аналогично для управления уязвимостями, контролем конфигураций, целостности и даже антивирусом.
Фактически – необходимо описать процедуры управления ИБ, состоящие из:
Определения «правильного» состояния;
Определения зоны действия. Например, все обновлять, или только ОС;
Определения мер контроля выполнения и метрик;
Определения пути информирования о случившихся событиях, в случае, если работы прошли по плану
Определения пути информирования о случившихся негативных событиях (т.е. когда что-то пошло не по плану)
Способа согласования исключений. Например, как согласовать невозможность обновить ОС под каким-то специфическим ПО, да еще и так, чтобы с одной стороны не пытаться обновить ОС каждую неделю, а с другой стороны помнить, что проблема существует – просто ее отложили на потом.
На практике, клиенту нужно выбрать облако, обеспечивающее достаточный уровень качества, быстродействия и соответствия нужным требованиям по ИБ. И вот с последним есть некоторое количество хитростей. Их проще описать на примерах.
Во-первых, стандарты PCI DSS и ГОСТ Р 57580.1 значительно более продвинутые, чем 152-ФЗ. Так что облака, соответствующие этим стандартам, при прочих равных можно считать более защищенными.
Во-вторых, для каждого из стандартов существуют свои способы подтверждения соответствия.
Соответствие может быть подтверждено двумя способами: оценкой соответствия или аттестацией.
Оценку соответствия облачный провайдер может провести как самостоятельно (менее распространенный вариант), так и с привлечением аудиторов, имеющих лицензию ФСТЭК ТЗКИ.
В результате оценки соответствия, облачный провайдер приводит свои процессы в соответствие требованиям, предъявляемым для защиты персональных данных указанного в оценке уровня защищенности, и устанавливает требуемые средства защиты на уровне облака. Все.
Главное – клиенту не забыть с таким провайдером подписать поручение на обработку персональных данных и разработать собственную систему защиты «внутри» облака вместе с соответствующими документами.
Аттестация – это отдельная процедура, и она не является обязательной. При аттестации сначала облачный провайдер самостоятельно, или с помощью специальных аудиторов приводит себя в соответствие требованиям для определенного уровня защищенности, а потом компания, обладающая специальной лицензией ФСТЭК снова проверяет, что все настроено и описано корректно – и выдает аттестат.
Сложность в том, что аттестат не позволяет изменять аттестованное облако. А при изменениях в облаке – аттестат необходимо получать заново.
Еще одна сложность в том, что если клиент хочет аттестовать свою систему (что, кстати, совершенно не обязательно), то и облако нужно аттестованное. Аттестовать систему, размещенную в облаке с оценкой соответствия – будет очень тяжело.
Стандарт PCI DSS описывает разные типы компаний, подпадающих под действие стандарта, и разные уровни соответствия.
Облачные провайдеры попадают в тип “service providers”, и для публичного облака актуален уровень Level 1. Он требует проведение сертификационного аудита.
В результате, у облачного провайдера должны быть следующие документы:
Сертификат соответствия
Документ AOC. В этом документе описано – какие именно услуги провайдера прошли сертификацию.
Это достаточно важно понимать, потому что сертификат, выданный, например, для услуги Co-location (т.е. размещения оборудования в ЦОД) никак не поможет клиенту, размещающему виртуальные машины в облаке.
Еще нужно не забывать, что услуги S3, администрирование ресурсов в облаке, DBaaS и т.д. – это все отдельные от самого облака (хостинга виртуальных ресурсов) услуги, и они должны быть отражены в AOC.
И перед размещением систем, клиенту нужно подписать с провайдером соглашение о разделении зон ответственности – это стандартный для PCI DSS документ, по сути подобный поручению в 152-ФЗ.
Привести себя в соответствие провайдер может и самостоятельно, а вот подтвердить соответствие должна сторонняя компания, имеющая лицензию ФСТЭК ТЗКИ.
А вот стандарта такого подтверждения пока нет. Есть стандарт проверки – ГОСТ Р 57580.2-2017, но он был написан для использования в банках, и для облачных провайдеров несколько избыточен.
Перед размещением систем, клиенту традиционно нужно закрепить разделение зон ответственности. Шаблона этого документа пока не существует, поэтому вид документа может отличаться у разных провайдеров.
Стандарт является абсолютно добровольным, и области действия сертификата о соответствии стандарту обязательно указывается, к каким процессам он применен в каждом конкретном случае. Процессы, приводимые в соответствие, провайдер выбирает самостоятельно – и они должны быть указаны в сертификате.
Легкую неразбериху вносит то, что есть оригинальный стандарт – ISO\IEC 27001:2013, а есть его переводная версия: ГОСТ Р ИСО\МЭК 27001. Оба стандарта действующие, но Российская версия является локализацией устаревшего стандарта ISO 27001:2005.
Так что можно сказать, что, при прочих равных, сертификат на соответствие оригинальному стандарту ISO – несколько сложнее получить.
Самые важные вещи:
С технической точки зрения, провайдер обеспечивает два основных параметра облака: надежность и быстродействие.
С точки зрения информационной безопасности, провайдер может подтверждать соответствие каким-то законодательным требованиям по ИБ или стандартам.
Также, с точки зрения ИБ, провайдер может подтвердить качество своих собственных процессов управления защищенностью с помощью сертификата соответствия требованиям стандарта ISO 27001:2013 (версия стандарта ISO 27001:2005 уже, к сожалению, сильно устарела).
В следующей статье мы рассмотрим, как же совместить все эти стандарты и зоны ответственности вместе, и сделать так, чтобы при размещении в облаке система была защищена. Не переключайтесь!
