Cloud IDE, Cloud Desktop, Cloud CDN и DNS, контейнеры Kubernetes, BaaS и DBaaS — у вашего безопасника уже задергался глаз? И не только у него. Многие компании все еще не доверяют облакам. Их пугает чужая платформа, которая кажется черным ящиком. Нельзя же просто взять и переехать туда на доверии, разместив в нем критически важные бизнес-приложения?
Меня зовут Александр Лугов, я руковожу группой по обеспечению информационной безопасности облачной платформы K2 Cloud. Давайте последовательно разберемся, как выстроить доверительные отношения с провайдером и на что обратить внимание.
Что узнать в первую очередь
При выборе облачного провайдера компании сперва стоит ознакомиться с материалами на сайте платформы. Чем больше подробностей там опубликовано, тем лучше.
На что стоит обратить внимание в первую очередь:
Подтверждение соответствия требованиям стандартов
Можно попросить облачного провайдера заполнить CSA CAIQ и самостоятельно оценить уровень его защищенности, однако более надежным показателем является его соответствие ряду важных российских и международных стандартов:
21 приказ ФСТЭК (152-ФЗ);
ГОСТ Р 57580.1-2017;
PCI DSS 4.0;
ГОСТ Р ИСО/МЭК 27001-2021;
ГОСТ Р ИСО/МЭК 27017-2021.
Публичные облака не обязаны соответствовать всем этим требованиям, но их наличие сильно расширяет для провайдера возможности работы с компаниями, так как для многих клиентов эти законодательные требования являются обязательными.
Аттестаты — это не просто формальности. Они выдаются по результатам независимых проверок и вместе формируют объективную картину уровня защиты ИТ-инфраструктуры облачного провайдера. Мы испытали все эти процедуры на себе, когда проходили независимые аудиты ИБ для К2 Облака — это правда непросто, отнимает кучу времени, сил и средств. Например, ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций» содержит более 400 мер защиты информации. Нам потребовалось 3,5 месяца, чтобы получить оценку соответствия ему с коэффициентом 0,94 (из возможной 1,00). Оценка была проведена по первому из трех, самому сложному, уровню — «усиленному» (УЗ-1).
Коэффициент 1,0 означает, что компания реализовала 100% применимых к ней мер защиты информации, входящих в стандарт. Пока таких на рынке нет. Коэффициент 0,94 — один из наиболее высоких показателей на рынке публичных облаков РФ.
Обращайте внимание на содержимое документов независимых аудитов. Например, между первым и третьим уровнем защищенности финансовых операций по российскому ГОСТу лежит пропасть. Первый уровень защищенности требует выполнения гораздо большего количества мер защиты информации и обеспечивает более высокий уровень безопасности информационной системы. Также стоит обратить внимание на область действия документа — это может быть ЦОД или облачная платформа по отдельности, их сегменты или все вместе.
Наличие международных сертификатов
Наличие у провайдера сертификатов, аттестатов, заключений, подтверждающих соответствие различным стандартам ИБ, в первую очередь важно для тех компаний, на которые распространяются требования регулирующих органов. Если они хотят размещать свою инфраструктуру или данные в облаке, то оно тоже должно соответствовать всем релевантным требованиям законодательства.
Но если для компании эти требования не актуальны, то она может обратить внимание на популярные и зрелые международные стандарты безопасности. В частности, на PCI DSS. Эта сертификация является обязательной для всех организаций, работающих с данными карт международных платежных систем (Visa, MasterCard, МИР), и должна подтверждаться каждый год. Прежде всего сертификацию обязаны проходить банки, сайты электронной коммерции, розничные магазины и т. д. На рынке облаков PCI DSS считается подтверждением высокого уровня защищенности ИТ-инфраструктуры в целом. Провайдеры получают его, чтобы подтвердить свою зрелость и надежность.
На сегодняшний день актуальным является стандарт PCI DSS версии 4.0. В нем углублен и расширен базовый уровень операционных и технических требований для повышения безопасности платежей, а также прописаны современные методы для борьбы с новыми угрозами. При этом, если провайдер уже соответствует ГОСТ Р 57580.1-2017, то получить сертификат PCI DSS 4.0 ему будет проще, так как многие требования похожи.
Результаты регулярных пентестов
Стандарт PCI DSS 4.0 включает обязательное требование к облачным провайдерам проводить комплексное тестирование на проникновение не реже чем каждые полгода. В ходе такого тестирования проверяется в том числе надежность механизмов изоляции ресурсов клиентов. Помощь белых хакеров и имитация кибератак позволяют выявлять и устранять неочевидные уязвимости. Также хорошо, если руководство провайдера регулярно меняет подрядчиков, которые проводят тестирование на проникновение. Каждая такая команда имеет свои сильные и слабые стороны, поэтому ротация исполнителей обеспечивает более объективную оценку.
Техническая документация и содержание Self-Assessment
Описание стека, архитектуры и средств защиты, используемых в облаке, дадут понять, какие дополнительные средства защиты информации (СЗИ) потребуются при переезде. Кроме того, стоит обратить внимание на наличие опубликованных копий документов, подтверждающих соответствие требованиям по защите ИТ-инфраструктуры. Некоторые облачные провайдеры на словах заявляют о соответствии, но не публикуют документы. Это может вызывать дополнительные сомнения у клиентов.
Некоторые некоммерческие организации, например, Cloud Security Alliance, предлагают облачным провайдерам заполнять и публиковать опросники для самопроверки. Конечно, это не основной критерий выбора надежного облака, однако такая открытость говорит в пользу компании. Публичное заявление о наличии тех или иных защитных мер влечет за собой юридическую и репутационную ответственность.
Secure by Design
Коммерческие облака строятся на базе разных технологий и архитектур, но в действительно надежном облаке должен соблюдаться подход Secure by Design. Это лежит на поверхности, но требования к безопасной разработке трудно переоценить. Если разработчики зашивают пароли в код, заливают секреты на GitHub или используют древние дырявые библиотеки — это беда. К сожалению, это сложно проверить. Ориентируйтесь не на слова, а на результаты независимого аудита, в стандарте которого есть требования к безопасной разработке — например, PCI DSS и ГОСТ Р 57580.1-2017.
Архитектура и процесс эксплуатации облачной платформы также должны быть изначально спроектированы с оглядкой на безопасность. Хорошо, если в дизайне предусмотрены штатные СЗИ. У нас в облаке это набор из IAM (Identity and Access Management, или управление идентификацией и контролем доступа), резервного копирования, списков контроля доступа, групп безопасности, журналов действий, мониторингов и др. Тонкая настройка системного и прикладного программного обеспечения дополнительно увеличивает защищенность информационных систем.
Как понять, кто за что в ответе
Забота о защите ИТ-инфраструктуры со стороны облака не снимает ответственность с клиента, но где проходят ее границы? Большинство компаний не знает, как ответить на этот вопрос, но если устранить неопределенность, то будет гораздо проще выстроить отношения с облачным провайдером.
Проанализируйте разграничение зон ответственности
Границы зон ответственности клиента и провайдера отличаются от случая к случаю и во многом зависят от бизнес-модели, формата работы платформы. Если рассматривать модель услуг IaaS, то безопасность размещенных там сервисов — в основном забота и ответственность клиента. С PaaS эта граница сдвигается в сторону провайдера. В случае с SaaS ответственность практически полностью лежит на облачном провайдере.
Когда облачная платформа проходит аттестацию, его сотрудники подготавливают матрицу разграничения ответственности в части выполнения требований конкретного стандарта: PCI DSS, 152-ФЗ, ГОСТ Р 57580.1-2017 и так далее. Ее можно взять на сайте или запросить у провайдера, положить на свои сервисы и посмотреть, что делается со стороны облака, а какие вопросы придется закрывать самостоятельно.
У нас были кейсы, когда заказчик просил включить зоны ответственности в договор, и это не было проблемой. Особой необходимости в этом нет: они и так закреплены в документах провайдера, и мы их соблюдаем. Другое дело, если заказчик хочет внести корректировки. Такие изменения нужны, например, если он отдает администрирование своей инфраструктуры или средств защиты информации на аутсорсинг облачному провайдеру. Тогда стоит документально зафиксировать зоны ответственности и более детально подойти к описанию состава и масштаба работ, выполняемых провайдером. В конечном счете защиту инфраструктуры обеспечивают обе стороны, и это важно помнить.
Как выстроить эффективную киберзащиту
Необходимо понимать, что переезжая в облако, заказчик в той или иной степени разделяет заботы по обеспечению киберзащиты своих систем с облачным провайдером, а не отдает ему их полностью на откуп. На практике это партнерство — совместная работа по выстраиванию системы безопасности, ее поддержанию и соблюдению.
Чтобы выстроить эффективную защиту от киберугроз, нужно работать сообща. Зачастую клиенты получают СЗИ, которые еще нужно самостоятельно настроить под свои задачи. Кроме того, необходимо выбрать недостающие меры защиты, спроектировать эшелонированную оборону. Облачный провайдер может оказывать компании помощь в этом вопросе. Для того, чтобы облегчить эту работу себе и клиентам, мы разработали комплексное предложение по ИБ в облаке, которое включает более 30 услуг. Они составляют основу для построения защищенного контура информационной системы. Средства защиты подобраны таким образом, чтобы максимально использовать преимущества облачной платформы и минимизировать риски возникновения недопустимых событий. Совместно с клиентами мы обсуждаем, какие средства защиты им необходимо использовать, так как сейчас многие компании нацелены на результативную защиту своих информационных систем.
При этом никакие средства защиты не спасут облачную инфраструктуру, если системный администратор клиента по ошибке откроет публичный доступ к серверу 1С с простым паролем. Поэтому все равно придется думать о таких вещах, как кибергигиена. В реальности нельзя просто прийти к облачному провайдеру, ничего не делать и забыть о безопасности, рассчитывая, что он обо всем позаботится. Это так не работает. Просто развернуть множество СЗИ и почувствовать себя в безопасности — тоже не вариант. Нужен более вдумчивый подход.
Проектирование средств защиты
Первым делом мы рекомендуем клиентам потратить время на проектирование. В идеале перед переходом в облако заказчик должен понимать свои риски, учитывать векторы атак и слабые стороны сервисов, а также иметь актуальную модель угроз и нарушителей. В общем, рекомендуем подходить к задаче масштабно и столь же серьезно, как и к построению физической инфраструктуры.
Как ни странно, в последнее время самыми подготовленными к переезду в облако оказываются обособившиеся российские подразделения иностранных компаний. Они приходят с уже готовыми чек-листами, заготовленными под облачные платформы, с перечнем СЗИ и мерами, которые необходимо реализовать во время трансформации ИТ-инфраструктуры.
Организационные меры защиты
Следующий шаг — организационные меры защиты. Они включают в себя разработку политик, процедур, стандартов и регламентов, направленных на обеспечение безопасности информации. Все это — формализация и настройка процессов, которые позволят поддерживать ИБ на должном уровне.
Организационные меры включают обучение сотрудников по вопросам безопасности, аудиты систем безопасности, политики по регулярному обновлению программного обеспечения и мониторинг защищенности информационной среды. При их составлении важно учитывать специфику деятельности компании и особенности ее информационной инфраструктуры.
Технические меры защиты
Неважно, сами вы проектируете эшелонированную оборону или опираетесь на популярный фреймворк. Необходимо оценить, что предоставляет облако, и «примерить» это на свой проект. Если в отдельных моментах нет ясности, придите за уточнением к облачному провайдеру. Уверены — вам никто не откажет в помощи.
Также стоит иметь в виду, что далеко не все провайдеры предоставляют продвинутые услуги в части кибербезопасности. Зачастую это базовые вещи: разделение по зонам, сетевые экраны, антивирусы. Но даже они должны учитывать требования законодательства, ГОСТы и отраслевые стандарты, а также собственные требования компаний по информационной безопасности. Тогда базовые средства защиты информации существенно расширяются и появляются средства управления и реагирования на инциденты ИБ, шифрование каналов связи и дисков, системы предотвращения утечек информации и системы класса NTA. Вероятно, что-то из них облачный провайдер предоставит в качестве дополнительных Cloud Security-сервисов, остальное придется устанавливать самостоятельно.
Сочетание мер защиты
В процессе эксплуатации инфраструктуры организационные и технические меры дополняют друг друга так же, как усилия клиента и провайдера. Например, в 152-ФЗ и ГОСТ Р 57580.1-2017 уровень защищенности, выбранный для информационной системы, напрямую влияет на количество мер защиты, которые необходимо реализовать техническим способом. Но без организационных мер тоже не обойтись — они выстраивают информационную безопасность на уровне процессов и регламентов, где четко прописаны, например, требования к парольной политике, ответственные стороны за те или иные элементы инфраструктуры, требования к безопасной разработке ПО и многое другое.
Отдельно хочется упомянуть про тюнинг прикладного программного обеспечения, когда с помощью более точной настройки такого ПО мы увеличиваем время атаки на наши системы. Преднастроенные образы операционных систем, систем управления базами данных по требованиям информационной безопасности также помогают защитить вашу информацию.
В итоге получается синергетический эффект. Технические средства повышают надежность и снижают влияние человеческого фактора на безопасность, а организационные меры фиксируют требования и выстроенные процессы.
Резюмируем
Первое, что стоит сделать при выборе облачного провайдера для компании — ознакомиться с публичными материалами, документацией платформы. Узнать, как обстоят дела с соответствием законам РФ, пентестами и Self-Assessment.
Оценить базовый уровень информационной безопасности платформы и процессов у облачного провайдера, выяснить, какие СЗИ предлагает облачная платформа.
Сформулировать свои потребности в части ИБ. Проанализировать, что получится сделать самостоятельно, а какие угрозы можно закрыть при помощи аутсорсинга. Рассчитать бюджет.
Приступить к проектированию инфраструктуры внутри облака, продумать организационную и техническую безопасность — разработать полноценную стратегию защиты.
Переехать и продолжать поддерживать уровень ИБ.
Выбор подходящего облака и переезд — сложный процесс, но он станет проще, если действовать в тандеме с провайдером.
В K2 Cloud мы помогаем клиентам развертывать средства защиты облачных сред. Чтобы максимально обезопасить облачных клиентов, мы проводим аудит кибербезопасности, помогаем находить узкие места в ИТ-инфраструктуре, участвуем в разработке ИБ-стратегии и аттестовываем развернутую систему. Стараемся рассказывать, советовать, всячески помогать, чтобы снизить риски. Учитывая возросшее число атак, не стоит подходить к кибербезопасности спустя рукава.
