В статьях “о парадоксе доверия облачным платформам” и “безопасном управлении ключами шифрования” мы отмечали, что в некоторых ситуациях ключи шифрования не следует хранить у поставщика облачных услуг. Такие ситуации, пусть и редко, но имеют место. Более того, когда такое происходит, речь, как правило, идет об очень серьезной проблеме или важных данных.
Вот этой статье мы рассмотрим 3 сценария, когда ключи необходимо хранить вне облака, несмотря на все преимущества облачной среды.
Сценарий № 1. Данные, которые лучше не хранить в облаке
Большинство организаций сегодня предпочитают обрабатывать информацию в облаке, но всегда находятся данные, для которых такой метод не подходит.Это может быть конфиденциальная информация или данные, на которые распространяются самые строгие требования внутренней безопасности.
В каждой сфере и в каждой компании есть данные, которые попадают в эту категорию. Например, в одной международной организации действуют очень строгие правила в отношении хранения ключей. Чтобы использовать для этого облачные платформы, ей необходимо получать специальное разрешение. Другая организация руководствуется собственным вариантом стандарта PCI DSS. Кроме того, у нее есть внутренние требования по управлению главными ключами с помощью аппаратного модуля безопасности в соответствии со стандартом FIPS 140-2 (уровень 3).
Учитывая риски и необходимость соблюдать правила и требования, эти данные иногда сложно или даже невозможно отправить на хранение и обработку в публичный облачный сервис. Как правило, с такими проблемами сталкиваются крупные организации, деятельность которых строго регулируется (например, медицинские, финансовые и производственные компании). У них может быть доступ к данным пациентов или сведениям о финансовых операциях.
Однако организация может согласиться на отправку данных в облако, если их зашифруют и ключи шифрования будут храниться только у нее. Таким образом, оценив риски и уровень доверия к конкретной платформе, а также выслушав мнение аудиторов, клиент может все же перенести данные в облако. Или он может оставить ключи у себя, сославшись на конкретные пункты правил.
Вы можете возразить, что некоторые данные вообще ни при каких обстоятельствах не должны храниться в облаке. Возможно. Однако общепринятая точка зрения сегодня заключается в том, что при переходе на цифровые технологии необходимо задействовать преимущества облачных платформ. Поэтому стоит искать некие компромиссные решения.
Сценарий № 2. Требования местного законодательства и проблемы, связанные с ними
С развитием облачных технологий порядок их использования во многом зависит от требований законодательства в тех или иных странах. В этом сценарии организация хочет использовать облачную платформу из другой страны, но ее не устраивает, что у поставщика услуг будут ключи шифрования для всех данных. Если в том же облаке будут обрабатываться незашифрованные данные, поставщик услуг получит доступ и к ним. Некоторые организации также не хотят хранить ключи на криптографических устройствах (например, аппаратных модулях безопасности), управляемых поставщиком услуг (физически или с помощью ПО). Они справедливо полагают, что такой подход не соответствует принципу Hold Your Own Key (HYOK).
Проблемы могут быть связаны как с требованиями законодательства, так и с описанными выше причинами. Кроме того, регулирующие органы ЕС, России, Японии, Индии, Бразилии и других стран постоянно принимают новые акты, запрещающие хранить незашифрованные данные и/или ключи шифрования за рубежом. В качестве примеров можно привести отраслевые стандарты (например, TISAX в Европе), которые указывают или подразумевают, что у поставщика облачных услуг ни при каких обстоятельствах не может быть доступа к данным, а во многих случаях и к ключам шифрования. Однако предварительные результаты опроса указывают на то, что возможны варианты, когда ключи шифрования находятся только у клиента (в то время как зашифрованные данные могут храниться за рубежом).
Другой вариант предполагает хранение ключей для данных, связанных с определенными странами, непосредственно в этих странах под контролем должностных лиц или обычных граждан. Он может применяться для банковских данных и предполагать наличие ключей шифрования для каждого набора данных, хранящегося в определенной стране. Пример: банк, который настаивает, чтобы все его ключи шифрования хранились под конкретной горой в Швейцарии. Ещё один пример: законодательные или внутренние требования, которые обязывают собирать сведения об администраторах ключей и вести внутренний журнал доступа к ключам.
По мнению Томаса Куриана, "суверенитет данных позволяет клиентам запрещать доступ к своей информации поставщикам услуг, кроме тех случаев, которые сами клиенты сочтут необходимыми. Например, платформа Google Cloud разрешает клиентам хранить и использовать ключи шифрования вне облака. Они могут предоставлять доступ к ключам только в случае крайней необходимости, будучи уверенными, что используемые данные защищены. В результате клиент может самостоятельно распоряжаться доступом к своим данным".
Таким образом, этот сценарий позволяет организациям использовать платформу Google Cloud и хранить ключи шифрования в выбранном ими месте под их физическим и административным контролем.
Сценарий № 3. Централизованное управление ключами шифрования
В этом сценарии нам не нужно учитывать никакие тайные угрозы и разбираться с непонятными нормативными требованиями. Здесь акцент делается на операционной эффективности. По мнению компании Gartner, отказ от лишних инструментов управления ключами приведет к тому, что ключи будут храниться в единой системе, охватывающей несколько облачных и локальных сред.
Как бы банально это ни звучало, но излишняя сложность часто вредит безопасности. Чем больше централизованных систем для отдельных задач, будь то управление журналами или ключами шифрования, тем больше источников потенциальных уязвимостей.
Поэтому желание использовать единую систему (облачную или локальную) для большинства ключей шифрования абсолютно понятно. Сегодня лишь немногие организации применяют облачные сервисы для всех задач, требующих шифрования. Большинство предпочитает хранить ключи в локальной среде. Дополнительное преимущество такого подхода состоит в том, что один поставщик осуществляет дополнительный контроль доступа и устанавливает правила. С одним набором ключей работать проще. А если одна система обеспечивает должный уровень безопасности и избыточности, то необходимость в дополнительных системах отпадает.
Кроме того, такой сценарий позволяет получить полный контроль над обработкой данных за счет управления доступом к ключам шифрования. Если клиент может простым нажатием кнопки отключить поставщику облачных услуг доступ к ключам, данные никто не сможет украсть.
Наконец, централизованное управление ключами позволяет пользователю облачного сервиса устанавливать правила доступа к ключам, а следовательно, и к неактивным данным.
Дальнейшие действия
Все эти сценарии подразумевают ситуацию, когда ключи шифрования не находятся под физическим и административным контролем поставщика облачных услуг. Это значит, что аппаратный модуль безопасности, которым управляет клиент, но который находится на территории поставщика облачных услуг, использовать нельзя.
Прочитайте эту статью об управлении ключами шифрования в облаке.
Оцените риски для данных с учетом уязвимостей, нормативных требований, отношений между странами и т. д.
Изучите три этих сценария и поймите, насколько они применимы для вас. Проанализируйте облачную обработку данных, используя модель угроз, и узнайте, можно вам хранить ключи в облаке или нет.
Ознакомьтесь с сервисами от Google Cloud EKM (External Key Manager) и партнеров (Ionic, Fortanix, Thales и т. д.), которые позволяют перенести управление ключами из облака в локальную среду.
Напоминаем что при первой регистрации в Google Cloud: вам доступны бонусы на сумму 300 долларов США, а более 20 бесплатных продуктов доступны всегда. Подробнее по специальной ссылке.
А так же выражаем благодарность за помощь в подготовке материала коллегам: Антон Чувакин, Иль Сон Ли, Звиад Кардава
