Возможно ли реализовать требования ИБ и защитить данные в публичном облаке? На ком лежит ответственность за выполнения закона или стандарта? Может ли клиент купить готовую облачную инфраструктуру и самостоятельно ничего не делать?
Свои проекты по информационной безопасности в части выполнения требований регуляторов мы реализовывали совместно с партнером Card Security. Вдохновившись полученными результатами, мы с коллегами решили поделиться накопленным опытом и подготовили для вас серию статей об организации безопасности в облаке. Цель - рассказать, как вовремя находить и решать проблемы, связанные с IT-безопасностью при использовании услуг облачных провайдеров.
Итак, разбираемся в этих и других вопросах законодательного регулирования ИБ в нашей первой статье.
Самые распространенные вопросы, которые возникают у большинства компаний перед переходом в облака:
Предлагая клиентам облака с функциями безопасности, вендоры сталкиваются с тем, что пресейл становится очень сложным. В нем задействовано множество участников с различными компетенциями, и далеко не всегда у каждой заинтересованной стороны хватает знаний для целостного понимания картины.
Задача понятная, организации нужно, чтобы какой-то софт работал должным образом. Для запуска программы нужно выполнить массу подготовительных операций, и вложиться как в персонал, так и в покупку инфраструктуры.
Но для этого нужно:
Кроме того, если бизнес планирует более или менее активно развиваться, то «завтра» ИТ-инфраструктура должна быть побольше, помощнее и посложнее – то есть подороже.
И ведь это все требуется только ДО работы приложения, а это непрофильная для заказчика работа, которая сама по себе не приносит денег. Автоматизация основной деятельности начнется только после того, как инфраструктура заработает. Нужен какой-то компромисс — такой, чтобы и все работало, и денег хватало.
Один из вариантов — использование облака. Облако предоставляет всю инфраструктуру как услугу: позволяет не вкладываться в собственную серверную инфраструктуру и в ее администраторов, обеспечивает отказоустойчивость и помогает наращивать мощности и функции по мере необходимости – и все это за предсказуемый ежемесячный платеж.
У клиентов, работающих с облаками в России, потребности могут быть разными, но в 99% случаев они будут такими:
При проверке компания должна показать договор с подрядчиками, в соответствии с которым они выполняет требования по безопасности и подтверждают это документально.
Таким образом, ответственность за выполнения требований закона или стандарта лежит именно на клиентах облачных провайдеров: они должны им соответствовать и для этого заключить специальное соглашение с облачными провайдерами.
Вендоры облачных решений должны обеспечить выполнение требований по безопасности на уровне инфраструктуры и доступа собственных администраторов. Они должны принять требования клиентов о защите и каким-либо образом подтвердить свое собственное соответствие.
Здесь возникает следующий вопрос:
Логика тут такая:
Во-первых, любые требования ИБ – не про наличие средств защиты, а про защиту процессов обработки информации.
Во-вторых, клиент и облачный провайдер занимаются достаточно разными процессами обработки информации.
Пример:
Есть компания, у которой в штате работают два бухгалтера и два сотрудника кадровой службы. Еще есть сервер 1С, в котором рассчитываются зарплаты (персональные данные). Компания сотрудничает с облачным провайдером, предоставляющим услуги IaaS.
Организация в своих процессах собирает разные документы своего персонала: трудовые договоры, заявления на отпуск и больничный и т.д. Занимается этим кадровая служба, которая работает в том числе и с бумажными версиями этих документов. Ее сотрудники берут из заявлений нужную им информацию и заносят данные в клиент 1С, установленный на офисных компьютерах. Бухгалтеры тоже работают с клиентом 1С, откуда берут данные для своей работы.
В процессе кадрового делопроизводства задействованы как минимум: 4 сотрудника, бумажное делопроизводство, 4 офисные компьютера и сервер 1С, а также собственная офисная сеть. И все это нужно защитить средствами ИБ.
Компания решает перенести сервер 1С в облако – чтобы повысить надежность работы и сделать его мощнее. Для сотрудников компании процесс работы никак не изменился: они видят те же документы в тех же системах.
Но теперь добавился облачный провайдер и его сотрудники.
Персонал облачного провайдера, безусловно, не заинтересован в просмотре содержимого 1С, но у него есть доступ к оборудованию и гипервизору, внутри которых 1С хранится – то есть сотрудники провайдера имеют опосредованный доступ к персональным данным.
У облачного провайдера вообще много элементов инфраструктуры: помещение собственного ЦОДа, все сервера и системы хранения, на которых может оказаться виртуальная машина с данными клиента, администраторы серверов, администраторы СХД, администраторы системы виртуализации и их компьютеры, а также офисная сеть провайдера и служебная сеть облака. И все это нужно защитить – такими же средствами защиты.
Провайдер, чтобы выполнить требования стандарта, закрепленные в клиентском договоре, должен защитить компьютеры своих пользователей, свою сеть (даже две) и свои сервера.
Еще провайдер может пообещать клиенту предоставить межсетевой экран для размещаемого виртуального сервера, защищающий виртуальную сеть клиента. Сверх этого провайдер — предоставить лицензию антивируса для этого сервера.
Но провайдер никак не может защитить офисную сеть и офисные компьютеры клиента.
В результате: если провайдер предоставляет какие-то средства защиты, то клиент должен сам проверить – на что именно эти средства защиты распространяются и достаточно ли их ему для удовлетворения требований, закрепленных в его собственных документах.
Как разграничить зоны ответственности между заказчиком и вендором облачного решения, мы расскажем в нашей следующей статье.
habr.com
Свои проекты по информационной безопасности в части выполнения требований регуляторов мы реализовывали совместно с партнером Card Security. Вдохновившись полученными результатами, мы с коллегами решили поделиться накопленным опытом и подготовили для вас серию статей об организации безопасности в облаке. Цель - рассказать, как вовремя находить и решать проблемы, связанные с IT-безопасностью при использовании услуг облачных провайдеров.
Итак, разбираемся в этих и других вопросах законодательного регулирования ИБ в нашей первой статье.
Самые распространенные вопросы, которые возникают у большинства компаний перед переходом в облака:
- Любой ли провайдер по ИБ вам подходит?
- Как и какие условия обязательно нужно учесть при заказе IaaS, что можно добавить к ТЗ, а что передавать облачному провайдеру не получится?
- Как обеспечить выполнение законов и стандартов при размещении в облаке?
- Как все это спроектировать так, чтобы не потерять преимуществ масштабирования, изначально присущих облаку?
Предлагая клиентам облака с функциями безопасности, вендоры сталкиваются с тем, что пресейл становится очень сложным. В нем задействовано множество участников с различными компетенциями, и далеко не всегда у каждой заинтересованной стороны хватает знаний для целостного понимания картины.
- Менеджер по продаже облака недостаточно разбирается в тонкостях ИБ.
- IT-специалист на стороне клиента, как правило, тоже не погружен глубоко в тему ИБ.
- Специалист по ИБ клиента, возможно, никогда до этого не сталкивался с облачными хранилищами и поэтому воспринимает их скептически.
- Специалистов по ИБ облака мало, поэтому их не всегда хватает для того, чтобы оперативно всех консультировать и проект растягивается по времени.
- Небольшие компании не имеют достаточного опыта для анализа стандартов и законов. Они просто покупают облако и ничего не делают в своей зоне ответственности. Такой подход в итоге приводит к различным проблемам и претензиям к вендору. Обычно это происходит после проверок работы ЦОД компетентными органами, которые выносят постановления об исправлении недочетов и выписывают штрафы.
- У крупных заказчиков есть собственные специалисты по ИБ, которые исторически с недоверием относятся к облачным хранилищам, т.к. не имеют достаточного опыта именно в приземлении требований ИБ на облачные сервисы. У некоторых крупных заказчиков документально не зафиксированы зоны собственной ответственности и ответственности облачного вендора в части ИБ, что часто приводит к недопониманию сторон.
Собственная инфраструктура vs. облака
Вопрос про безопасность в облаке, тем более в публичном, возникает у каждого клиента своим специфическим образом. Достаточно распространенный сценарий: компания открылась или запустила новое направление бизнеса и не хочет заниматься скучной, отнимающей массу времени, непрофильной деятельностью.Задача понятная, организации нужно, чтобы какой-то софт работал должным образом. Для запуска программы нужно выполнить массу подготовительных операций, и вложиться как в персонал, так и в покупку инфраструктуры.
Но для этого нужно:
- Найти подходящее помещение, обеспечить его качественным электропитанием и кондиционированием (а в бизнес-центре это может оказаться проблемой);
- Завести в это помещение надежную и быструю сеть. И если с самим подключением проблем обычно нет, то вот с надежностью – проблемы бывают, причем каждый раз в самый неподходящий момент.
- Купить и поставить серверные шкафы.
- Выбрать и установить множество телекоммуникационного оборудования. Смонтировать его в шкафы, а затем настроить и подключить.
- Установить и подключить сами серверы.
- Сделать так, чтобы серверы и телекоммуникационное оборудование работали вместе.
- Поставить необходимое ПО.
- Постоянно обновлять настройки, чинить поломки, подключать случайно выдернутые провода и т.д.
- Как следствие – держать в штате сетевого администратора и системного администратора.
Кроме того, если бизнес планирует более или менее активно развиваться, то «завтра» ИТ-инфраструктура должна быть побольше, помощнее и посложнее – то есть подороже.
И ведь это все требуется только ДО работы приложения, а это непрофильная для заказчика работа, которая сама по себе не приносит денег. Автоматизация основной деятельности начнется только после того, как инфраструктура заработает. Нужен какой-то компромисс — такой, чтобы и все работало, и денег хватало.
Один из вариантов — использование облака. Облако предоставляет всю инфраструктуру как услугу: позволяет не вкладываться в собственную серверную инфраструктуру и в ее администраторов, обеспечивает отказоустойчивость и помогает наращивать мощности и функции по мере необходимости – и все это за предсказуемый ежемесячный платеж.
ИБ в облаках
Многие компании боятся даже не полностью утратить данные в облаке, а их воровства, поэтому к вопросу ИБ подходят особенно щепетильно. Одним из первых у заказчика облачных услуг возникает вопрос:Потребность в информационной безопасности можно условно разделить на две большие группы:
- Внешняя потребность: требования законодательства, отраслевых стандартов, сертифицирующих органов, или бизнес-партнеров о соответствии какой-либо политике.
- Внутренняя потребность: желание держать свои данные под контролем, а свои процессы работы с информацией – защищенными.
Стандарты и законодательство
Внешняя потребность в 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С хранится – то есть сотрудники провайдера имеют опосредованный доступ к персональным данным.
У облачного провайдера вообще много элементов инфраструктуры: помещение собственного ЦОДа, все сервера и системы хранения, на которых может оказаться виртуальная машина с данными клиента, администраторы серверов, администраторы СХД, администраторы системы виртуализации и их компьютеры, а также офисная сеть провайдера и служебная сеть облака. И все это нужно защитить – такими же средствами защиты.
Провайдер, чтобы выполнить требования стандарта, закрепленные в клиентском договоре, должен защитить компьютеры своих пользователей, свою сеть (даже две) и свои сервера.
Еще провайдер может пообещать клиенту предоставить межсетевой экран для размещаемого виртуального сервера, защищающий виртуальную сеть клиента. Сверх этого провайдер — предоставить лицензию антивируса для этого сервера.
Но провайдер никак не может защитить офисную сеть и офисные компьютеры клиента.
В результате: если провайдер предоставляет какие-то средства защиты, то клиент должен сам проверить – на что именно эти средства защиты распространяются и достаточно ли их ему для удовлетворения требований, закрепленных в его собственных документах.
Резюме
Информационную безопасность можно обеспечить в публичном облаке, если соблюсти ряд условий:- Так как ответственность за соблюдение требований лежит на клиенте облака – именно он должен составить перечень требований к облачной инфраструктуре.
- Обязательство по обеспечению защиты информации должно быть формально закреплено между клиентом и облаком.
- Как правило, средств, предоставляемых облаком, не хватает для защиты процессов обработки информации заказчиком — это необходимо проверять самому клиенту. Скорее всего, ему придется проектировать дополнительную систему защиты.
Как разграничить зоны ответственности между заказчиком и вендором облачного решения, мы расскажем в нашей следующей статье.
Информационная безопасность облаков: как выполнить все требования законодательства
Возможно ли реализовать требования ИБ и защитить данные в публичном облаке? На ком лежит ответственность за выполнения закона или стандарта? Может ли клиент купить готовую облачную инфраструктуру и...
habr.com