Информационная безопасность облаков: как выполнить все требования законодательства
Можно ли реализовать требования ИБ и защитить данные в публичном облаке? На ком лежит ответственность за выполнения требований закона или стандарта? Может ли клиент купить готовую облачную инфраструктуру и самостоятельно ничего не делать?
Свои проекты по информационной безопасности в части выполнения требований регуляторов мы реализовывали совместно с партнером Card Security. Вдохновившись полученными результатами, мы с коллегами решили поделиться накопленным опытом и подготовили для вас серию статей об организации безопасности в облаке. Цель — рассказать, как вовремя находить и решать проблемы, связанные с IT-безопасностью при использовании услуг облачных провайдеров.
Итак, разбираемся в этих и других вопросах законодательного регулирования ИБ в нашей первой статье.
Самые распространенные вопросы, которые возникают у большинства компаний перед переходом в облака:
Любой ли провайдер по ИБ вам подходит?
Как и какие условия обязательно нужно учесть при заказе IaaS, что можно добавить к ТЗ, а что передавать облачному провайдеру не получится?
Как обеспечить выполнение законов и стандартов при размещении в облаке?
Как все это спроектировать так, чтобы не потерять преимуществ масштабирования, изначально присущих облаку?
Следуя тенденциям рынка сейчас все больше облачных провайдеров предлагают своим клиентам широкий перечень услуг по информационной безопасности. Но на практике часто можно столкнуться со сложностями, как в организационных моментах внутри вендора, так и во взаимодействии со службами клиентов.
Предлагая клиентам облака с функциями безопасности, вендоры сталкиваются с тем, что пресейл становится очень сложным. В нем задействовано множество участников с различными компетенциями, и далеко не всегда у каждой заинтересованной стороны хватает знаний для целостного понимания картины.
Менеджер по продаже облака недостаточно разбирается в тонкостях ИБ.
IT-специалист на стороне клиента, как правило, тоже не погружен глубоко в тему ИБ.
Специалист по ИБ клиента, возможно, никогда до этого не сталкивался с облачными хранилищами и поэтому воспринимает их скептически.
Специалистов по ИБ облака мало, поэтому их не всегда хватает для того, чтобы оперативно всех консультировать и проект растягивается по времени.
В зависимости от величины масштаба бизнеса самих клиентов, кроме недостатка компетенции своих специалистов, появляются еще и дополнительные сложности:
Небольшие компании не имеют достаточного опыта для анализа стандартов и законов. Они просто покупают облако и ничего не делают в своей зоне ответственности. Такой подход в итоге приводит к различным проблемам и претензиям к вендору. Обычно это происходит после проверок работы ЦОД компетентными органами, которые выносят постановления об исправлении недочетов и выписывают штрафы.
У крупных заказчиков есть собственные специалисты по ИБ, которые исторически с недоверием относятся к облачным хранилищам, т.к. не имеют достаточного опыта именно в приземлении требований ИБ на облачные сервисы. Поэтому они в целом пытаются запретить работу с облачной инфраструктурой.
У некоторых крупных заказчиков документально не зафиксированы зоны собственной ответственности и ответственности облачного вендора в части ИБ, что часто приводит к недопониманию сторон.
Собственная инфраструктура vs. облака
Вопрос про безопасность в облаке, тем более в публичном, возникает у каждого клиента своим специфическим образом. Достаточно распространенный сценарий: компания открылась или запустила новое направление бизнеса и не хочет заниматься скучной, отнимающей массу времени, непрофильной деятельностью, а решила взять ресурсы в аренду.
Задача понятная, организации нужно, чтобы какой-то софт работал должным образом. Для запуска программы нужно выполнить массу подготовительных операций, и вложиться как в персонал, так и в покупку инфраструктуры.
Но для этого нужно:
Найти подходящее помещение, обеспечить его качественным электропитанием и кондиционированием (а в бизнес-центре это может оказаться проблемой);
Завести в это помещение надежную и быструю сеть. И если с самим подключением проблем обычно нет, то вот с надежностью — проблемы бывают, причем каждый раз в самый неподходящий момент.
Купить и поставить серверные шкафы.
Выбрать и установить множество телекоммуникационного оборудования. Смонтировать его в шкафы, а затем настроить и подключить.
Установить и подключить сами серверы.
Сделать так, чтобы серверы и телекоммуникационное оборудование работали вместе.
Поставить необходимое ПО.
Постоянно обновлять настройки, чинить поломки, подключать случайно выдернутые провода и т.д.
Как следствие — держать в штате сетевого администратора и системного администратора.
К тому же, один системный администратор поддерживать все это в работающем состоянии и на должном уровне качества банально будет не успевать, а много хороших администраторов — стоят дорого.
Кроме того, если бизнес планирует более или менее активно развиваться, то «завтра» ИТ-инфраструктура должна быть побольше, помощнее и посложнее — то есть подороже.
И ведь это все требуется только ДО работы приложения, а это непрофильная для заказчика работа, которая сама по себе не приносит денег. Автоматизация основной деятельности начнется только после того, как инфраструктура заработает. Нужен какой-то компромисс — такой, чтобы и все работало, и денег хватало.
Один из вариантов — использование облака. Облако предоставляет всю инфраструктуру как услугу: позволяет не вкладываться в собственную серверную инфраструктуру и в ее администраторов, обеспечивает отказоустойчивость и помогает наращивать мощности и функции по мере необходимости — и все это за предсказуемый ежемесячный платеж.
ИБ в облаках
Многие компании боятся даже не полностью утратить данные в облаке, а их воровства, поэтому к вопросу ИБ подходят особенно щепетильно. Одним из первых у заказчика облачных услуг возникает вопрос:
А можно ли защитить данные, хранящиеся на чужом оборудовании и администрируемые чужими специалистами?
Потребность в информационной безопасности можно условно разделить на две большие группы:
Внешняя потребность: требования законодательства, отраслевых стандартов, сертифицирующих органов, или бизнес-партнеров о соответствии какой-либо политике.
Внутренняя потребность: желание держать свои данные под контролем, а свои процессы работы с информацией — защищенными.
Реализовать требования ИБ и защитить данные в публичном облаке можно. Хотя, безусловно, использование облаков накладывает свои особенности и на процесс обеспечения безопасности, и на процесс доказательства защищенности проверяющим, и даже на выбор IaaS-провайдера и проектирование готовой системы на базе облака.
Стандарты и законодательство
Внешняя потребность в IТ-безопасности возникает несколько чаще, поэтому начнем с требований законодательства и стандартов.
У клиентов, работающих с облаками в России, потребности могут быть разными, но в 99% случаев они будут такими:
152-ФЗ. Актуально для любой компании, обрабатывающей персональные данные: магазины, сервисные компании, обслуживающие физических лиц, любые системы лояльности, да даже собственная кадровая служба — тоже обрабатывает персональные данные собственных сотрудников.
Реализовать соответствие можно самостоятельно или с помощью услуг специализированной компании.
Проверяющий орган — Роскомнадзор.
PCI DSS. Стандарт безопасности платежных карт. Актуально для всех, кто самостоятельно обрабатывает платежные карты: банки, платежные операторы и платежные шлюзы, крупные интернет-магазины.
Теоретически, платежный провайдер (провайдер онлайн-кассы) может у любого магазина потребовать соответствия требованиям PCI DSS. Но на практике, платежный провайдер понимает, что это способно осложнить взаимодействие с магазином и начинает требовать соответствия, начиная с какого-то значимого количества транзакций и объема денег в обороте магазина. Какой объем будет значимым для платежного провайдера — определяет сам провайдер.
Показывать соответствие нужно для той компании, через которую осуществляется подключение к международным платежным системам.
А вот подтвердить соответствие должна компания, обладающая специальным статусом — PCI QSA.
Требования ЦБ РФ. Применяется в первую очередь к лицензиатам ЦБ: банкам, НКО и некредитным финансовым организациям. С недавнего времени — еще и к посредникам при оказании финансовых услуг. Требований много, именуются они «Положение ЦБ №ХХХ-П»: 382-П (с 01.01.2022 будет заменено на 719-П), 672-П, 683-П и 684-П. Все эти положения в значительной степени ссылаются на положения документа ГОСТ Р 57580.1–2017.
Проверяющий орган — ЦБ РФ.
Проводить оценку может любая сторонняя организация. Самостоятельно это сделать нельзя.
Требования по защите Государственных Информационных Систем (ГИС). Они же — требования 17-го приказа ФСТЭК России. К государственным системам применяются всегда. К системам частных компаний могут быть применимы, если эту систему планируется интегрировать с ГИС.
В частности, инфраструктура медицинских организаций, в том числе частных, может попасть под требования к защите ГИС в соответствии с постановлением правительства РФ №447 от 12.04.2018.
Проверяющим органом для государственных организаций является ФСТЭК России. Но частные компании должны подтверждать это документом о соответствии — «аттестатом соответствия требованиям безопасности», который выдает специализированная компания, обладающая лицензией ФСТЭК на такую деятельность.
Для всех вышеперечисленных стандартов действует одна и та же логика применения: если компания должна выполнить стандарт (или закон) — то именно она подлежит проверке. Если же проверяемая компания привлекает для решения каких-то задач подрядчика, например, облачного провайдера или логистическую компанию или контакт-центр, — то она должна обязать подрядчика выполнять требования стандарта по договору.
При проверке компания должна показать договор с подрядчиками, в соответствии с которым они выполняет требования по безопасности и подтверждают это документально.
Таким образом, ответственность за выполнения требований закона или стандарта лежит именно на клиентах облачных провайдеров: они должны им соответствовать и для этого заключить специальное соглашение с облачными провайдерами.
Вендоры облачных решений должны обеспечить выполнение требований по безопасности на уровне инфраструктуры и доступа собственных администраторов. Они должны принять требования клиентов о защите и каким-либо образом подтвердить свое собственное соответствие.
Здесь возникает следующий вопрос:
Можно ли просто купить инфраструктуру в облаке, соответствующем какому-то стандарту или закону, и всю ответственность передать провайдеру облака –, а самостоятельно ничего не делать?
Спойлер: нет, нельзя.
Логика тут такая:
Инфраструктура клиента должна соответствовать определенным стандартам или законам.
Соответствие достигается выполнением требований закона (или стандарта) и подтверждается документами, которые в любом случае должны существовать у клиента. Их перечень зависит от конкретного состава инфраструктуры.
В требованиях стандарта или закона описывается, какие меры защиты необходимо применять для разных процессов работы с данными. Достаточно часто — это средства защиты или описание настроек ПО и оборудования.
Часть ПО и оборудования — инфраструктуру — клиент заказывает у облачного провайдера. Клиент не может самостоятельно сделать все настройки облака. Все работы, которые он отдает подрядчикам на аутсорс, необходимо документально зафиксировать.
Часть настроек своих систем может сделать только клиент, и такие работы на аутсорс передать не удастся, они остаются в зоне ответственности клиента.
Существует три уровня соответствия процессов заказчика нормам ИБ при использовании облачной инфраструктуры:
Само облако, соответствующее заданным требованиям на своем уровне (с облачным провайдером подписывается документ о необходимости защиты данных и передаче ответственности);
Документы, принадлежащие самому заказчику;
Средства защиты на уровне самого клиента. Конкретный перечень зависит от того, как работает система клиента и что написано в его документах.
ИБ: тонкая настройка на стороне клиента
Следующий популярный у клиентов вопрос:
Часто облачные провайдеры приводят список средств защиты, которые стоят в облаке. А что, их недостаточно? Обязательно нужно ставить дополнительные?
Вот тут сложнее. Проще считать, что не хватит — и проверять под свои потребности. И делать это, исходя из следующей информации.
Во-первых, любые требования ИБ — не про наличие средств защиты, а про защиту процессов обработки информации.
Во-вторых, клиент и облачный провайдер занимаются достаточно разными процессами обработки информации.
Пример:
Есть компания, у которой в штате работают два бухгалтера и два сотрудника кадровой службы. Еще есть сервер 1С, в котором рассчитываются зарплаты (персональные данные). Компания сотрудничает с облачным провайдером, предоставляющим услуги IaaS.
Организация в своих процессах собирает разные документы своего персонала: трудовые договоры, заявления на отпуск и больничный и т.д. Занимается этим кадровая служба, которая работает в том числе и с бумажными версиями этих документов. Ее сотрудники берут из заявлений нужную им информацию и заносят данные в клиент 1С, установленный на офисных компьютерах. Бухгалтеры тоже работают с клиентом 1С, откуда берут данные для своей работы.
В процессе кадрового делопроизводства задействованы как минимум: 4 сотрудника, бумажное делопроизводство, 4 офисные компьютера и сервер 1С, а также собственная офисная сеть. И все это нужно защитить средствами ИБ.
Компания решает перенести сервер 1С в облако — чтобы повысить надежность работы и сделать его мощнее. Для сотрудников компании процесс работы никак не изменился: они видят те же документы в тех же системах.
Но теперь добавился облачный провайдер и его сотрудники.
Персонал облачного провайдера, безусловно, не заинтересован в просмотре содержимого 1С, но у него есть доступ к оборудованию и гипервизору, внутри которых 1С хранится — то есть сотрудники провайдера имеют опосредованный доступ к персональным данным.
У облачного провайдера вообще много элементов инфраструктуры: помещение собственного ЦОДа, все сервера и системы хранения, на которых может оказаться виртуальная машина с данными клиента, администраторы серверов, администраторы СХД, администраторы системы виртуализации и их компьютеры, а также офисная сеть провайдера и служебная сеть облака. И все это нужно защитить — такими же средствами защиты.
Провайдер, чтобы выполнить требования стандарта, закрепленные в клиентском договоре, должен защитить компьютеры своих пользователей, свою сеть (даже две) и свои сервера.
Еще провайдер может пообещать клиенту предоставить межсетевой экран для размещаемого виртуального сервера, защищающий виртуальную сеть клиента. Сверх этого провайдер — предоставить лицензию антивируса для этого сервера.
Но провайдер никак не может защитить офисную сеть и офисные компьютеры клиента.
В результате: если провайдер предоставляет какие-то средства защиты, то клиент должен сам проверить — на что именно эти средства защиты распространяются и достаточно ли их ему для удовлетворения требований, закрепленных в его собственных документах.
Резюме
Информационную безопасность можно обеспечить в публичном облаке, если соблюсти ряд условий:
Так как ответственность за соблюдение требований лежит на клиенте облака — именно он должен составить перечень требований к облачной инфраструктуре.
Обязательство по обеспечению защиты информации должно быть формально закреплено между клиентом и облаком.
Как правило, средств, предоставляемых облаком, не хватает для защиты процессов обработки информации заказчиком — это необходимо проверять самому клиенту. Скорее всего, ему придется проектировать дополнительную систему защиты.
Важно помнить, что нельзя всю ответственность по ИБ переносить на облачного провайдера.
Как разграничить зоны ответственности между заказчиком и вендором облачного решения, мы расскажем в нашей следующей статье.
