Шифрование данных в облаке: Как выбрать облачное хранилище и защитить данные

• • Что такое облачное шифрование?
  • Важность облачного шифрования в 2021 году
  Ключевые методы
  • , используемые в облачном шифровании
  • 8 лучших практик управления облачным шифрованием в 2021 году

Что такое облачное шифрование?

Облачное шифрование — это процесс кодирования и преобразования данных перед их передачей в облако. Этот процесс преобразует данные открытого текста в зашифрованный текст с использованием математических алгоритмов и делает данные нечитаемыми, тем самым защищая их от неавторизованных и потенциально злонамеренных пользователей.

Облачное шифрование — это простой, но эффективный метод предотвращения доступа к конфиденциальным облачным данным в случае взлома. Даже если данные в конечном итоге будут украдены, киберпреступники не смогут прочитать содержимое зашифрованных файлов. Многие эксперты считают шифрование успешным и эффективным подходом к надежной защите данных.

Проще говоря, шифрование зашифровывает содержимое бизнес-баз данных, систем и файлов, делая его расшифровку невозможной без правильного ключа дешифрования. Облачное хранилище становится самым популярным способом хранения корпоративных данных и обеспечения передовой доступности и резервирования. Комбинируя шифрование с облачным хранилищем, предприятия могут защитить ключи шифрования и получить полный контроль над доступом к конфиденциальным данным.

Возможно, самое большое преимущество зашифрованных облачных данных заключается в том, что даже в случае кражи или иного доступа к ним они остаются в нечитаемом состоянии без надлежащей авторизации. Это означает, что он бесполезен, если сторона с незаконным доступом также не имеет правильного ключа дешифрования. Поставщики зашифрованных облачных хранилищ шифруют информацию и передают ключи шифрования своим компаниям-клиентам. Когда данные необходимо расшифровать, эти ключи можно использовать для безопасного доступа к информации и ее передачи по мере необходимости. Ключи расшифровки преобразуют зашифрованные данные в удобочитаемую форму.

Как правило, облачные решения для шифрования имеют несколько приложений. К ним относятся:

• • Шифрование соединений между облаком и конечной точкой
  • Ограниченное шифрование конфиденциальной информации
  • Сквозное шифрование всех данных от начала до хранения

Все модели обычно требуют, чтобы поставщики облачных хранилищ шифровали информацию при получении и передавали ключи шифрования клиентам для облегчения безопасной расшифровки данных.

Читайте также: Cloud Vs. Локальное сравнение: основные различия и сходства

Важность облачного шифрования в 2021 году

Если все сделано правильно, внедрение облачного шифрования может быть простым процессом. Облачное шифрование может помочь организациям повысить конфиденциальность данных, обеспечить гибкость удаленной работы и обеспечить соблюдение нормативных требований — проблемы, которые вышли на первый план в 2021 году. Давайте рассмотрим некоторые преимущества облачного шифрования.

Важность облачного шифрования

1. Обеспечивает круглосуточную защиту данных

Как правило, корпоративные данные подвергаются наивысшему уровню риска при передаче или хранении в сторонней среде, например облачный сервер. Облачное шифрование обеспечивает безопасность как для данных в состоянии покоя, так и для данных в движении.

По мере того, как структура рабочих процессов становится более гибкой, а сотрудники растягивают свои смены и перетасовывают свои устройства или места, данные должны быть защищены круглосуточно и без выходных. В противном случае высока вероятность того, что к нему получат доступ недобросовестные элементы, стремящиеся нанести ущерб предприятию.

Решения для облачного шифрования сразу же начинают действовать и защищают данные независимо от того, хранятся они или передаются. Независимо от процесса, через который проходят данные, облачные решения для шифрования предотвращают несанкционированный доступ.

2. Снижает внутреннюю угрозу

Внешние элементы — не единственный фактор риска для безопасности данных организации, особенно во время удаленной работы, когда контроль ограничен, а мониторинг не всегда эффективен. Сотрудники, деловые партнеры и подрядчики со злыми намерениями могут нанести еще больший ущерб, чем киберпреступник, не связанный с организацией, если они решат это сделать.

Однако это не всегда преднамеренно. Сотрудник, который не очень разбирается в технологиях, может совершить непреднамеренные ошибки, которые могут оставить данные организации открытыми для несанкционированного доступа и нанести ущерб предприятию.

Хотя облачное шифрование не является заменой небрежности или отсутствия обучения, оно, безусловно, помогает передать контроль над корпоративными данными опытному и заслуживающему доверия поставщику облачных услуг. Это вводит новый уровень безопасности и помогает предотвратить причинение сотрудниками какого-либо ущерба компании.

3. Преодоление небезопасных API-интерфейсов

Организации, работающие в облачной среде, часто полагаются на API-интерфейсы для управления различными элементами своей онлайн-инфраструктуры. API-интерфейсы встроены в мобильные или веб-приложения и могут получать доступ к облачным данным извне (для клиентов и подрядчиков) или изнутри (для сотрудников).

Внешние или внутренние API-интерфейсы со слабыми протоколами безопасности могут представлять угрозу безопасности в облаке, особенно при передаче данных. Например, небезопасный внешний API может служить шлюзом, который предлагает несанкционированный доступ киберпреступникам, стремящимся украсть данные.

Облачные службы шифрования, особенно комплексные, которые шифруют данные до начала процесса загрузки, могут помочь снизить риски, связанные с небезопасными API, и предотвратить попадание конфиденциальных данных в чужие руки, даже в случае утечки.

4. Поддерживает организационную целостность

В 2021 г. по-прежнему наблюдается рост частоты кибератак, особенно в сфере здравоохранения, банковского дела и финансов, образования и государственного сектора. Это можно объяснить переходом на хранение данных в облаке, а не в локальных базах данных, к которым больше не могут получить доступ сотрудники, работающие удаленно.

Облачные базы данных связаны с помощью проводных и беспроводных технологий и представляют собой простой способ хранения больших объемов данных, включая информацию о сотрудниках, клиентах, продажах и финансовые отчеты. Однако рост популярности удаленных рабочих мест предоставил киберпреступникам гораздо больше возможностей использовать недостатки платформ облачных вычислений.

Незашифрованные облачные данные подвержены несанкционированному доступу, поскольку хакеры маскируют вредоносные пакеты как локальный трафик и внедряют их в облачные базы данных организации незаконными методами. Кроме того, киберпреступники могут извлечь выгоду из модификации данных для совершения мошенничества. Однако, когда облачные данные зашифрованы, их кража или изменение становится почти невозможным.

5. Обеспечивает защиту нескольких устройств

Прошли те времена, когда у сотрудников была выделенная конечная точка для работы. В 2021 году удаленные работники используют любое устройство, разрешенное политикой информационной безопасности их компании. Однако некоторые из этих устройств могут быть менее безопасными, чем другие. Передача информации между устройствами создает еще один уровень уязвимости, что делает шифрование критически важным для защиты данных на нескольких устройствах.

Помимо хранимых данных, комплексные решения для облачного шифрования также могут помочь в шифровании сообщений, паролей и даже веб-трафика — элементов, которые признаны лучшими методами обеспечения безопасности данных. Независимо от того, какие данные в конечном итоге будут скомпрометированы, будь то из-за взлома на уровне конечной точки или на стороне облачного провайдера, злоумышленники получат только бесполезную для них информацию без правильного ключа дешифрования.

6. Гарантия соответствия

Удаленная работа может стать потенциальным кошмаром для соблюдения нормативных требований для организаций разных вертикалей, особенно в связи с директивами, требующими от компаний точно знать, где хранятся их данные, как они передаются и обрабатываются, стороны, которые имеют доступ к это, и как это защищено.

На уровне провайдеров нормативные акты в некоторых юрисдикциях могут требовать от поставщиков облачных решений наличия определенных учетных данных и соответствия другим требованиям кибербезопасности. Таким образом, всего один случай небрежной передачи конфиденциальных данных в облако или из облака или выбор поставщика, не соответствующего требованиям, может подвергнуть все предприятие риску привлечения к ответственности за несоблюдение требований и привести к серьезным финансовым и юридическим последствиям.

Облачное шифрование — это не только безопасное решение для обмена и сохранения данных. Он также может быть настроен для соблюдения ограничений, требуемых внутри организации, а также для соответствия требованиям соответствующих регулирующих органов, таких как Федеральный закон об управлении информационной безопасностью (FISMA), Федеральные стандарты обработки информации (FIPS), Закон о переносимости и подотчетности медицинского страхования (HIPAA). и Стандарт безопасности данных индустрии платежных карт (PCI/DSS).

Читайте также: 10 ведущих компаний по защите данных в облаке в 2021 году

Ключевые методы, используемые в облачном шифровании

В решениях облачного шифрования используются два разных метода для шифрования и дешифрования данных: симметричный и асимметричный. Эти методы, также известные как алгоритмы шифрования, объясняются ниже.

Симметричные алгоритмы

Метод облачного шифрования с симметричным алгоритмом использует одни и те же ключи для шифрования и дешифрования, что делает его идеальным для «закрытых» организационных систем. Этот метод, также известный как метод алгоритма секретного ключа, использует ключи для защиты связи всех форм. Этот метод наиболее подходит для массового шифрования данных.

Быстрая и простая аппаратная реализация и более быстрое шифрование являются основными преимуществами этого метода. Однако любой сотрудник, имеющий доступ к секретному ключу, может расшифровать зашифрованные конфиденциальные данные с помощью того же ключа, даже если эти данные не предназначены для него.

Асимметричные алгоритмы

В методе асимметричного алгоритма используются два ключа, математически связанные друг с другом — один закрытый, а другой открытый. Как следует из названия, в этом методе ключи асимметричны — хотя они и связаны друг с другом, они не совпадают. Решения для облачного шифрования передают эти закрытые ключи только соответствующим органам внутри организации, часто по защищенному каналу связи.

Эти ключи необходимо хранить в строжайшей секретности, так как их можно использовать для расшифровки всей зашифрованной информации. Однако открытые ключи передаются всем заинтересованным сторонам как внутри организации, так и за ее пределами, что позволяет шифровать данные перед передачей. См. также в 2021 году потребуются более эффективные методы защиты конфиденциальных корпоративных данных. Следующие рекомендации по шифрованию облачных данных помогают повысить уровень конфиденциальности и безопасности на всех уровнях внутри организации и за ее пределами, а также обеспечить безопасность информации компании в облаке.

Передовой опыт управления шифрованием в облаке

1. Оцените требования безопасности для развертывания в облаке

Начните с определения данных организации, требующих шифрования, и разработайте план приоритизации наиболее важных баз данных. Желательно, чтобы этот план был достаточно подробным, чтобы его можно было обсудить с выбранным поставщиком услуг облачного шифрования.

При оценке различных функций, предлагаемых поставщиками облачного шифрования, ищите доступ к интерфейсу службы, доступ к которому разрешен только для аутентифицированного и авторизованного персонала. Поставщик должен предлагать функции аутентификации и идентификации, включая имя пользователя, пароль, клиентские сертификаты TLS, двухфакторную аутентификацию и объединение удостоверений с текущим поставщиком удостоверений предприятия. Обеспечьте возможность ограничить доступ к выделенному предприятию, линии или общественной сети.

Чтобы ключи шифрования не попали в чужие руки, очень важно избегать поставщиков с небезопасной практикой аутентификации. Несоблюдение этого требования сделает системы компании уязвимыми для киберпреступников, стремящихся украсть данные, изменить информацию или запустить атаки типа «отказ в обслуживании».

Поставщик облачного шифрования не должен полагаться на электронную почту, телефон или HTTP для аутентификации, поскольку эти носители открыты для атак социальной инженерии и перехвата аутентификационных или учетных данных. Поставщик подлинного облачного шифрования обеспечит аутентификацию по безопасным каналам, таким как HTTPS, для обеспечения полной защиты.

2. Перед выбором поставщика облачных услуг (CSP) изучите более подробные сведения об услуге.

Ознакомление с пользовательским соглашением обычно позволяет компании-клиенту понять детали плана, предлагаемого поставщиком облачных услуг (CSP). Убедитесь, что это соглашение просматривается компетентным персоналом из разных отделов, и отводится достаточно времени для обмена входными данными и запросами.

В случае отсутствия какой-либо информации в пользовательском соглашении убедитесь, что запрашиваются разъяснения относительно деталей, особенно таких, как когда, как и где данные будут храниться, особенно в случае общедоступных облачных сервисов. Любой элемент пользовательского соглашения, который может привести к нарушению политики конфиденциальности предприятия или правил, которым он подчиняется, должен быть немедленно выделен.

Проверка контрактов и соглашений об уровне обслуживания потенциальных поставщиков облачного шифрования является неотъемлемой частью кибербезопасности. Эти два элемента являются самыми сильными гарантиями регресса в случае затруднительных обстоятельств. Положения, условия, приложения и приложения, которым подлежит контракт на облачное шифрование, могут серьезно повлиять на кибербезопасность компании.

Проще говоря, договор может сделать поставщика облачных услуг либо ответственным обработчиком ваших данных, либо полным владельцем ваших данных. 2019В отчете McAfee о внедрении облачных технологий и рисках говорится, что почти два из каждых трех облачных провайдеров не указывают, что клиентские данные принадлежат клиенту. Такие юридические серые зоны могут позволить поставщику облачного шифрования заявить о праве собственности на все загружаемые данные и отказаться делиться ключами в случае предполагаемого нарушения.

Помимо владения данными, важно знать, что происходит с информацией после расторжения соглашения. Когда это возможно, поставщик облачного шифрования также должен обеспечивать полную прозрачность всех событий кибербезопасности и информировать компанию-клиента о принимаемых мерах реагирования.

Если какой-либо элемент предложения услуг не соответствует потребностям предприятия, знайте, что большинство CSP оставляют место для переговоров. Однако в случае, если CSP считает пункт «не подлежащим обсуждению», определите, стоит ли согласие с ним того риска, которому он подвергает компанию. Если нет, ищите альтернативы, чтобы справиться с угрозой. К ним относятся решения для мониторинга, необлачные продукты для шифрования или вообще другой поставщик.

3. Когда это возможно, локальное резервное копирование облачных данных

Хотя большинство провайдеров облачного шифрования включают мгновенное резервное копирование и резервирование в корпоративные планы, резервное копирование критически важных данных, таких как сведения о сотрудниках, сведения о поставщиках и данные клиентов, локально на защищенном сервере всегда является хорошей идеей.

В случае повреждения или потери данных, сохраненных в облаке, или если поставщик облачных услуг по какой-либо причине ограничивает доступ, локальные резервные копии могут означать разницу между непрерывностью и нарушением. Резервное копирование данных также можно выполнить в зашифрованном облаке другого провайдера. Например, компания, использующая Google Диск в качестве основного хранилища, может также создавать резервные копии своих наиболее важных баз данных в Dropbox.

4. Используйте облачную криптографию для защиты доступа

Решения облачной криптографии защищают облачную архитектуру предприятия и обеспечивают уровень шифрования, основанный на системе «Quantum Direct Key», и обеспечивают безопасный доступ к общим облачным пользователям. Преимущества облачной криптографии включают повышенную конфиденциальность и повышенную безопасность данных за счет использования криптографических ключей.

Читайте также: 10 основных проблем безопасности облачных вычислений, которые необходимо решить в 2021 году

5. Используйте CASB для защиты данных при передаче и хранении

Брокер безопасности доступа к облаку (CASB) обеспечивает безопасные соединения между пользователями и облачными приложениями через соединители API и прокси-серверы. CASB помогают предприятиям лучше контролировать шифрование облачных данных, ключи шифрования, а также видимость и доступ к облачным приложениям.

Решения CASB играют роль посредника между предприятием и его CSP, обеспечивают прозрачность облачной среды, эффективно внедряют политики безопасности данных, обеспечивают эффективную идентификацию угроз и защиту от них, а также обеспечивают соблюдение нормативных требований. CASB быстро становятся передовой практикой облачной безопасности.

6. Выберите поставщика облачных услуг с комплексным шифрованием

Некоторые поставщики облачных услуг шифрования также предлагают шифрование на локальном уровне, что обеспечивает дополнительный уровень безопасности при создании и передаче данных. Выбирая поставщика услуг облачного шифрования, проверьте, предлагает ли он защиту данных при передаче с самого уровня конечного пользователя. При этом обеспечить реализацию сетевой защиты, предотвращающей перехват данных на уровне компании. Всегда следует отдавать предпочтение поставщику облачных услуг, который предлагает шифрование при передаче и хранении с момента создания данных.

7. Сохраняйте полную видимость и контроль

Предприятие должно иметь возможность просматривать и контролировать свои собственные данные при использовании решения для облачного шифрования. Хороший поставщик услуг предложит решение для облачного шифрования с полной видимостью загруженных данных и списка сторон, имеющих к ним доступ. Активный мониторинг этого позволяет обнаруживать изменения в безопасности и конфигурации в корпоративной экосистеме.

Убедитесь, что физическое место хранения данных, обработки и управления обсуждено, включая резервирование и резервное копирование. Хотя это, возможно, не вызывало беспокойства около десяти лет назад, сейчас это является ключевой передовой практикой благодаря внедрению национальных и международных правил, таких как Общий регламент ЕС по защите данных (GDPR).

Кроме того, обеспечение расширенной физической защиты активов данных, таких как охраняемые объекты, расположенные в геополитически стабильных регионах, также имеет решающее значение для долгосрочного контроля над видимостью и безопасностью корпоративных данных. Правильный поставщик облачного шифрования также обеспечит полное и безвозвратное удаление данных до того, как какие-либо ресурсы будут повторно предоставлены, выведены из эксплуатации или утилизированы, чтобы предотвратить случайное попадание данных в чужие руки.

8. Наконец, обеспечьте осведомленность о безопасности данных в масштабах предприятия

В 2021 году как никогда раньше безопасность данных стала зависеть от действий удаленных сотрудников в Интернете. Даже самое передовое облачное решение для шифрования не сможет обеспечить безопасность данных, если сотрудники компании-клиента используют общедоступные компьютеры или полагаются на небезопасные соединения, что делает их данные уязвимыми.

Настройка компьютеров для отключения кэширования паролей и логинов, обеспечение выхода сотрудников со всех сайтов или учетных записей после доступа к необходимым данным и просьба избегать небезопасных подключений Wi-Fi, когда это возможно, — это простые, но эффективные способы предотвращения данных. от попадания в руки хакеров.

Ключевой вывод

Обладая достаточной осведомленностью, конечные пользователи могут стать самым надежным защитником облачной среды организации. Глубокое знание методов обеспечения безопасности и их применения может в конечном итоге стать разницей между защищенной корпоративной сетью и сетью, которая является легкой мишенью для кибератак.

В качестве последней передовой практики проведите обучение по вопросам безопасности для всех заинтересованных сторон, имеющих доступ к системам компании, — сотрудников, поставщиков и подрядчиков, работающих локально и удаленно.

Распространяйте информацию об обнаружении вредоносного ПО, выявлении фишинговых писем и понимании того, почему некоторые методы небезопасны. Рассмотрите возможность предоставления специализированной сертификации и обучения заинтересованным сторонам, работающим на продвинутом уровне, например администраторам облачных служб и представителям CSP.

Помогла ли вам эта статья разобраться в облачном шифровании? Сообщите нам по телефону LinkedIn , Twitter или Facebook ! Мы будем рады услышать ваши отзывы.  

Что такое облачное шифрование? Преимущества, проблемы и многое другое

Что такое облачное шифрование?

Облачное шифрование — это процесс преобразования данных из исходного простого текстового формата в нечитаемый формат, такой как зашифрованный текст, перед их передачей и сохранением в облаке.

Как и любая форма шифрования данных, облачное шифрование делает информацию неразборчивой и, следовательно, бесполезной без ключей шифрования. Это применимо, даже если данные потеряны, украдены или переданы неавторизованному пользователю.

Шифрование считается одним из наиболее эффективных компонентов стратегии кибербезопасности организации. Помимо защиты самих данных от неправомерного использования, облачное шифрование также решает другие важные вопросы безопасности, в том числе:

• Соответствие нормативным стандартам в отношении конфиденциальности и защиты данных
• Улучшенная защита от несанкционированного доступа к данным от других арендаторов публичного облака
• В отдельных случаях освобождает организацию от необходимости сообщать о нарушениях или других событиях безопасности

Как работает облачное шифрование?

Шифрование использует передовые алгоритмы для кодирования данных, что делает их бессмысленными для любого пользователя, у которого нет ключа. Авторизованные пользователи используют ключ для декодирования данных, преобразуя скрытую информацию обратно в читаемый формат. Ключи генерируются и передаются только доверенным сторонам, чья личность устанавливается и проверяется с помощью той или иной формы многофакторной аутентификации.

2022 CrowdStrike Global Threat Report

Загрузите 2022 Global Threat Report , чтобы узнать, как службы безопасности могут лучше защитить людей, процессы и технологии современного предприятия во все более зловещей среде угроз.

Загрузить сейчас

Облачное шифрование предназначено для защиты данных при их перемещении в облачные приложения и из них, а также при хранении в облачной сети. Это известно как данные в пути и данных в состоянии покоя соответственно.

Шифрование передаваемых данных

Значительная часть передаваемых данных автоматически шифруется с помощью протокола HTTPS, который добавляет уровень сокетов безопасности (SSL) к стандартному IP-протоколу. SSL кодирует все действия, гарантируя, что только авторизованные пользователи могут получить доступ к деталям сеанса. Таким образом, если неавторизованный пользователь перехватит данные, передаваемые во время сеанса, содержимое будет бессмысленным. Декодирование выполняется на уровне пользователя с помощью цифрового ключа.

Шифрование данных в состоянии покоя

Шифрование данных для информации, хранящейся в облачной сети, гарантирует, что даже если данные будут утеряны, украдены или ошибочно переданы, их содержимое практически бесполезно без ключа шифрования. Опять же, ключи доступны только авторизованным пользователям. Подобно данным в пути, шифрование/дешифрование данных в состоянии покоя управляется программным приложением.

Алгоритмы шифрования

Существует два основных алгоритма шифрования облачных данных:

Симметричное шифрование: Ключи шифрования и дешифрования одинаковы. Этот метод чаще всего используется для шифрования больших объемов данных. Хотя реализация обычно проще и быстрее, чем асимметричный вариант, он несколько менее безопасен, поскольку любой, у кого есть доступ к ключу шифрования, может декодировать данные.

Асимметричное шифрование: Использует два ключа — открытый и закрытый токен проверки подлинности — для кодирования или декодирования данных. Хотя ключи связаны, они не одинаковы. Этот метод обеспечивает повышенную безопасность, поскольку доступ к данным невозможен, если у пользователей нет как открытого общего ключа, так и личного токена.

Какие облачные платформы зашифрованы?

Каждый авторитетный поставщик облачных услуг (CSP) — компания или организация, которая владеет облаком и управляет им — предлагает базовые средства безопасности, включая шифрование. Однако пользователям облачных сред следует принять дополнительные меры для обеспечения безопасности данных.

Облачная безопасность часто следует так называемой «модели общей ответственности». Это означает, что облачный провайдер должен отслеживать и реагировать на угрозы безопасности, связанные с базовой облачной инфраструктурой. Однако конечные пользователи, в том числе частные лица и компании, несут ответственность за защиту данных и других активов, которые они хранят в облачной среде.

Для организаций, которые используют облачную модель или начинают переход на облако, важно разработать и внедрить комплексную стратегию безопасности данных, специально предназначенную для защиты облачных активов. Шифрование является одним из ключевых элементов эффективной стратегии кибербезопасности. Другие компоненты включают:

• Многофакторную аутентификацию: Подтверждение личности пользователя с помощью двух или более доказательств
• Микросегментация: Разделение облачной сети на небольшие зоны для обеспечения отдельного доступа к каждой части сети и минимизации ущерба в случае взлома
• Расширенные возможности мониторинга, обнаружения и реагирования в режиме реального времени: Использование данных, аналитики, искусственного интеллекта (ИИ) и машинного обучения (МО) для получения более точного представления о сетевой активности, лучшего обнаружения аномалий и более быстрого реагирования на угрозы

Преимущества облачного шифрования

Шифрование является одним из основных средств защиты, которые организации могут использовать для защиты своих данных, интеллектуальной собственности (ИС) и другой конфиденциальной информации, а также данных своих клиентов. Он также служит для соблюдения стандартов и правил конфиденциальности и защиты.

К преимуществам облачного шифрования относятся:

• Безопасность: Шифрование обеспечивает сквозную защиту конфиденциальной информации, включая данные клиентов, когда они находятся в движении или в состоянии покоя на любом устройстве или между пользователями
• Соответствие: Правила и стандарты конфиденциальности и защиты данных, такие как FIPS (Федеральные стандарты обработки информации) и HIPPA (Закон о переносимости и подотчетности медицинского страхования от 1996 г.), требуют, чтобы организации шифровали все конфиденциальные данные клиентов
• Целостность: Хотя злоумышленники могут изменять или манипулировать зашифрованными данными, такую ​​активность относительно легко обнаружить авторизованным пользователям
• Снижение риска: В некоторых случаях организации могут быть освобождены от раскрытия информации об утечке данных, если данные были зашифрованы, что значительно снижает риск как ущерба для репутации, так и судебных исков или других судебных исков, связанных с событием безопасности

Проблемы с облачным шифрованием

Облачное шифрование — относительно простой, но очень эффективный метод обеспечения безопасности. К сожалению, многие организации упускают из виду этот аспект стратегии кибербезопасности, вероятно, потому, что они не знают о модели общей ответственности, связанной с публичным облаком. Как обсуждалось выше, в то время как поставщик облачных услуг должен поддерживать безопасность в облачной инфраструктуре, частные пользователи несут ответственность за защиту данных и активов, хранящихся в облаке, и обеспечение их безопасной передачи в облако и из него.

Дополнительные проблемы могут включать:
Время и стоимость: Шифрование является дополнительным шагом и, следовательно, дополнительными затратами для организаций. Пользователи, которые хотят зашифровать свои данные, должны не только приобрести инструмент шифрования, но и убедиться, что их существующие активы, такие как компьютеры и серверы, могут управлять дополнительной вычислительной мощностью шифрования. Шифрование может занять некоторое время, поэтому в организации может возникнуть повышенная задержка.

Потеря данных: Зашифрованные данные практически бесполезны без ключа. Если организация потеряет или уничтожит ключ доступа, восстановить данные будет невозможно.

Управление ключами: Ни одна облачная мера безопасности не является надежной, и шифрование не является исключением. Продвинутые злоумышленники могут взломать ключ шифрования, особенно если программа позволяет пользователю выбирать ключ. Вот почему важно требовать два или более ключа для доступа к конфиденциальному контенту.

Должен ли я шифровать свое облачное хранилище?

Облачное шифрование — один из самых практичных шагов, которые организации могут предпринять для защиты своих данных, а также конфиденциальной информации о клиентах. Организации должны проконсультироваться со своим партнером по кибербезопасности, чтобы выбрать оптимальный сторонний инструмент шифрования и интегрировать его в существующий стек технологий безопасности.

Темы для обсуждения с вашим партнером по кибербезопасности о шифровании облачных хранилищ могут включать:

• Как идентифицировать данные, требующие шифрования, либо из-за их конфиденциального характера, либо в связи с соблюдением нормативных стандартов
• Когда и где данные будут зашифрованы, а также процесс, за которым они будут следовать
• Как дополнить существующие протоколы безопасности облачных провайдеров или CSP
• Как будут генерироваться и совместно использоваться ключи доступа для снижения риска, связанного со слабыми паролями
• Кто будет контролировать управление ключами и их хранение (CSP или организация)
• Как и где будут создаваться резервные копии зашифрованных данных в случае нарушения CSP
• Как брокер безопасности доступа к облаку (CASB) может координировать доступ к данным в рамках всей организации и улучшить видимость

Шифрование по умолчанию при хранении | Документация

Этот контент последний раз обновлялся в сентябре 2022 г. и отражает текущее положение дел. на момент написания. Политики и системы безопасности Google могут меняться в будущем, поскольку мы постоянно улучшаем защиту наших клиентов.

В Google наша комплексная стратегия безопасности включает шифрование при хранении, что помогает защитить контент клиента от злоумышленников. Мы шифруем все Google контент клиента в состоянии покоя, без каких-либо действий с вашей стороны, с использованием одного или нескольких механизмы шифрования. В этом документе описывается наш подход к шифрование в состоянии покоя для инфраструктуры Google и Google Cloud и как мы его используем для обеспечения большей безопасности информации о клиентах.

Этот документ предназначен для архитекторов безопасности и групп безопасности, которые в настоящее время используя или рассматривая Google. Этот документ предполагает базовое понимание шифрование а также криптографические примитивы. Дополнительные сведения о криптографии см. Введение в современную криптографию.

Шифрование в состоянии покоя — это шифрование, которое используется для защиты данных, хранится на диске (включая твердотельные накопители) или резервном носителе. Все данные, которые хранится Google, шифруется на уровне хранилища с использованием расширенного Алгоритм стандарта шифрования (AES), AES-256. Мы используем обычный криптографический библиотеку Tink, которая включает в себя наш проверенный модуль FIPS 140-2 (названный СкучноКрипто ) последовательно внедрить шифрование в Google Cloud.

Мы управляем ключами, используемыми при шифровании по умолчанию в состоянии покоя. Если вы используете Google Cloud, служба управления облачными ключами позволяет создавать собственные ключи шифрования, вы можете использовать, чтобы добавить шифрование конверта к вашим данным. Используя облачный KMS, вы можете создавать, вращать, отслеживать и удалять ключи. Для получения дополнительной информации см. Подробное описание службы управления облачными ключами.

Как шифрование при хранении помогает защитить данные

Шифрование при хранении — это часть более широкой стратегии безопасности. Шифрование имеет следующие преимущества:

• Помогает гарантировать, что если данные попадут в руки злоумышленника, злоумышленник не может прочитать данные, не имея доступа к шифрованию ключи. Даже если злоумышленники получат устройства хранения, содержащие данные, они не смогут понять или расшифровать их.
• Помогает уменьшить поверхность атаки, вырезая нижние слои аппаратно-программный стек.
• Действует как узкий проход, поскольку централизованно управляемые ключи шифрования создают единственное место, где доступ к данным обеспечивается и может быть проверен.
• Помогает уменьшить поверхность атаки, потому что вместо защиты все данные, предприятия могут сосредоточить свои стратегии защиты на ключи шифрования.
• Обеспечивает важный механизм конфиденциальности для наших клиентов. Когда данные шифруется в состоянии покоя, он ограничивает доступ, который системы и инженеры должны иметь данные

Что такое данные клиента?

Как определено в Условия использования Google Cloud, данные клиента — это данные, которые клиенты или конечные пользователи предоставляют Google через услуги под своей учетной записью. Данные о клиентах включают контент клиента и метаданные.

Контент клиента — это данные, которые вы создаете сами или предоставляете нам, например данные хранящиеся в облачном хранилище, моментальные снимки дисков, используемые Compute Engine, и IAM-политики. В этом документе основное внимание уделяется шифрованию по умолчанию в состоянии покоя. для контента клиента.

Метаданные клиента составляют остальные ваши данные. Метаданные клиента могут включать автоматически сгенерированные номера проектов, временные метки, IP-адреса, размер в байтах объекта в Cloud Storage или тип машины в Вычислительный движок. Метаданные защищены в степени, приемлемой для текущие показатели и операции.

Шифрование данных по умолчанию в состоянии покоя

Google шифрует все содержимое клиента, хранящееся в состоянии покоя, без каких-либо действий со стороны вас, используя один или несколько механизмов шифрования. В следующих разделах описывается механизмы, которые мы используем для шифрования контента клиентов.

Уровни шифрования

Google использует несколько уровней шифрования для защиты данных. Использование нескольких уровни шифрования добавляют избыточную защиту данных и позволяют нам выбирать оптимальный подход, основанный на требованиях приложения.

На следующей диаграмме показаны несколько уровней шифрования, которые обычно используется для защиты пользовательских данных в центрах обработки данных Google. Либо распределенный шифрование файловой системы или базы данных и хранилища файлов для всех пользователей данных, а шифрование устройства хранения используется для всех данных в Производственные центры обработки данных Google.

Шифрование на уровне оборудования и инфраструктуры

Все системы хранения Google используют одинаковую архитектуру шифрования детали реализации отличаются от системы к системе. Данные разбиты на подфайл куски для хранения; размер каждого фрагмента может достигать нескольких гигабайт. Каждый чанк шифруется на уровне хранилища с помощью индивидуального ключа шифрования данных (DEK): два фрагмента не будут иметь одинаковый DEK, даже если они принадлежат одному и тому же клиента или хранится на том же компьютере. (Фрагмент данных в Datastore, App Engine и Pub/Sub могут содержать данные нескольких клиентов.

Если блок данных обновляется, он шифруется новым ключом, а не повторное использование существующего ключа. Это разделение данных, каждое из которых использует свой ключ, ограничивает риск потенциальной компрометации ключа шифрования данных только этими данными кусок.

Google шифрует данные перед их записью в систему хранения базы данных или аппаратный диск. Шифрование присуще всем нашим системам хранения, а не добавлено позже.

Каждый фрагмент данных имеет уникальный идентификатор. Списки контроля доступа (ACL) помогают убедитесь, что каждый фрагмент может быть расшифрован только службами Google, которые работают с авторизованными ролями, которым предоставляется доступ только в данный момент времени. Этот ограничение доступа помогает предотвратить доступ к данным без авторизации, усиление безопасности и конфиденциальности данных.

Каждый фрагмент распределяется по нашим системам хранения и реплицируется в зашифрованной форме для резервного копирования и аварийного восстановления. Злоумышленник, который хочет получить доступ клиентские данные должны знать и иметь доступ к двум вещам: все куски памяти, которые соответствуют нужным им данным, и все ключи шифрования, соответствующие частям.

На следующей диаграмме показано, как данные загружаются в нашу инфраструктуру, а затем разбивается на зашифрованные куски для хранения.

Мы используем алгоритм AES для шифрования данных в состоянии покоя. Все данные на уровне хранилища шифруется DEK, которые по умолчанию используют AES-256, за исключением небольшое количество Постоянные диски которые были созданы до 2015 года и используют AES-128. AES широко используется, потому что оба AES-256 и AES-128 рекомендуются Национальный институт стандартов и технологий (NIST) для долговременного хранения, и AES часто включается как часть требования соответствия.

Шифрование на уровне запоминающих устройств

В дополнение к шифрование на уровне системы хранения, данные также шифруются на уровне устройства хранения с помощью AES-256 для жесткого диска диски (HDD) и твердотельные накопители (SSD), используя отдельный ключ на уровне устройства (который отличается от ключа, используемого для шифрования данных на уровне хранилища). Небольшое количество устаревших жестких дисков использует AES-128. SSD, используемые Google, реализуют AES-256. исключительно для пользовательских данных.

Шифрование резервных копий

Наша система резервного копирования гарантирует, что данные остаются зашифрованными на протяжении всего резервного копирования процесс. Этот подход позволяет избежать ненужного раскрытия данных открытого текста.

Кроме того, система резервного копирования самостоятельно шифрует большинство файлов резервных копий. со своим ДЭК. DEK является производным от ключа, который хранится в хранилище ключей и случайно сгенерированное начальное число для каждого файла во время резервного копирования. Другой DEK используется для всех метаданные в резервных копиях, которые также хранятся в Keystore.

Соответствие FIPS для данных в состоянии покоя

Google использует FIPS 140-2 утвержден модуль шифрования (свидетельство 3318) в нашей производственной среде.

Управление ключами

Из-за большого количества ключей в Google и необходимости малой задержки и высокая доступность, DEK хранятся рядом с данными, которые они шифруют. DEK являются зашифровано (обернуто) ключевым ключом шифрования (KEK) с использованием известного метода в качестве шифрование конверта. Эти KEK не относятся к клиентам; вместо этого существует один или несколько KEK для каждую услугу.

Эти KEK хранятся централизованно в Keystore, репозитории, созданном специально для хранение ключей. Наличие меньшего количества KEK, чем DEK, и использование центрального Keystore делает хранение и шифрование данных в нашем масштабе управляемым и позволяет нам отслеживать и контролировать доступ к данным из центральной точки.

В Google Cloud у каждого клиента могут быть общие и частные ресурсы. Примером общего ресурса является общий базовый образ в Вычислительный движок. Для общих ресурсов несколько клиентов ссылаются на единственная копия, которая зашифрована одним DEK. Неразделяемые ресурсы разделены на фрагменты данных и зашифрованы ключами, которые отделены от используемых ключей для других клиентов. Эти ключи даже отделены от тех, которые защищают другие фрагменты одних и тех же данных, принадлежащих одному и тому же клиенту. Исключения — это данные, хранящиеся в хранилище данных, App Engine или Pub/Sub, где данные нескольких клиентов могут быть зашифрованы одним и тем же DEK.

Генерация DEK

Система хранения генерирует DEK, используя общую криптографическую библиотеку Google. Как правило, DEKS затем отправляются в Keystore для переноса с этой системой хранения. KEK, а упакованные DEK возвращаются в систему хранения для хранения. фрагменты данных. Когда системе хранения необходимо извлечь зашифрованные данные, она извлекает упакованный DEK и передает его в хранилище ключей. Затем хранилище ключей проверяет, что эта служба имеет право использовать KEK и, если это так, разворачивает и возвращает открытый текст DEK службе. Затем служба использует DEK для расшифровки данных. фрагментировать в открытый текст и проверить его целостность.

Все системы хранения Google Cloud придерживаются этой модели управления ключами, но в большинстве систем также реализованы дополнительные уровни KEK на стороне хранилища для создания иерархия ключей. Это позволяет системам обеспечивать низкую задержку при использовании KEK самого высокого уровня (хранящийся в хранилище ключей) в качестве корня доверия.

Генерация ключей KEK

Большинство ключей KEK для шифрования фрагментов данных генерируются в хранилище ключей, а остальные генерируются внутри служб хранения. Для согласованности все KEK генерируется с использованием общей криптографической библиотеки Google, используя случайное число генератор (RNG), созданный Google. Этот ГСЧ основан на NIST 800-9.0Ar1 CTR-DRBG и генерирует AES-256 KEK. (Раньше это был AES-128, и некоторые из них ключи остаются активными для расшифровки данных.)

Генератор случайных чисел берется из Инструкция Intel RDRAND и RNG ядра Linux. В свою очередь, генератор случайных чисел ядра Linux берется из несколько независимых источников энтропии, включая RDRAND и энтропийные события из среды центра обработки данных (например, детальные измерения дискового время поиска и прибытия между пакетами).

DEK упакованы в KEK с использованием AES-256 или AES-128, в зависимости от Облачный сервис Google. В настоящее время мы работаем над обновлением всех KEK для Облачные сервисы Google для AES-256.

Управление KEK

Хранилище ключей было создано исключительно для управления ключами KEK. По конструкции КЕК используемые системами хранения, нельзя экспортировать из хранилища ключей; все шифрование и расшифровка с помощью этих ключей должна выполняться в хранилище ключей. Это помогает предотвратить утечек и неправильного использования, а также позволяет Keystore создавать контрольный журнал, когда ключи использовал.

Keystore может автоматически менять ключи KEK через равные промежутки времени, используя Общая криптографическая библиотека Google для создания новых ключей. Хотя мы часто относятся только к одному ключу, мы действительно имеем в виду, что данные защищены с помощью ключа set: один ключ активен для шифрования, и активен набор исторических ключей для расшифровки. Количество исторических ключей определяется ротацией ключей расписание. KEK резервируются для целей аварийного восстановления, и они бессрочно подлежит восстановлению.

Использование ключей KEK управляется списками управления доступом в хранилище ключей для каждого ключа с политика. Доступ к ключу разрешен только авторизованным службам и пользователям Google. Использование каждой клавиши отслеживается на уровне отдельной операции, требует этот ключ, поэтому каждый раз, когда пользователь использует ключ, пользователь аутентифицированы и зарегистрированы. Весь доступ пользователей к данным подлежит аудиту как часть Общая политика безопасности и конфиденциальности Google.

Процесс доступа к зашифрованным фрагментам данных

Когда служба Google получает доступ к зашифрованному фрагменту данных, происходит:

1. Служба обращается к системе хранения для получения необходимых данных.
2. Система хранения идентифицирует фрагменты, в которых хранятся эти данные. (идентификаторы фрагментов) и где они хранятся.
3. Для каждого фрагмента система хранения извлекает упакованный DEK, который хранится с этим чанком (в некоторых случаях это делает сервис) и отправляет его в хранилище ключей для распаковки.
4. Система хранения проверяет, что идентифицированному заданию разрешен доступ этот фрагмент данных на основе идентификатора задания и с использованием идентификатора фрагмента. хранилище ключей проверяет, разрешено ли системе хранения использовать KEK, связанный со службой, и развернуть этот конкретный DEK.
5. Keystore выполняет одно из следующих действий:
   • Передает развернутый DEK обратно в систему хранения, которая расшифровывает фрагмент данных и передает его сервису.
   • В некоторых редких случаях передает развернутый DEK службе. система хранения передает зашифрованный блок данных сервису, который расшифровывает фрагмент данных и использует его.

Этот процесс отличается для выделенных устройств хранения, таких как локальные твердотельные накопители, где устройство управляет и защищает DEK на уровне устройства.

На следующей диаграмме показан этот процесс. Чтобы расшифровать фрагмент данных, хранилище служба вызывает Keystore, чтобы получить развернутый DEK для этого фрагмента данных.

Иерархия ключей шифрования и корень доверия

Хранилище ключей защищено корневым ключом, называемым мастер-ключом хранилища ключей , который упаковывает все ключи KEK в хранилище ключей. Этот главный ключ хранилища ключей — AES-256 и хранится в другой службе управления ключами, которая называется Root Keystore. (В В прошлом главный ключ хранилища ключей был AES-128, и некоторые из этих ключей остаются активными. для расшифровки данных.) Корневое хранилище ключей хранит гораздо меньше ключей — примерно дюжина на регион. Для дополнительной безопасности корневое хранилище ключей не запускается на обычных производственных машинах, а запускается только на выделенных машин в каждом центре обработки данных Google.

Корневое хранилище ключей, в свою очередь, имеет собственный корневой ключ, называемый мастером корневого хранилища ключей . ключ , который также является AES-256 и хранится в одноранговой инфраструктуре, который называется распространителем главного ключа корневого хранилища ключей и который реплицирует эти ключи глобально. (Раньше главным ключом корневого хранилища ключей был AES-128, а некоторые из этих ключей остаются активными для расшифровки данных.) Мастер корневого хранилища ключей распределитель ключей хранит ключи только в ОЗУ на тех же выделенных машинах, что и Корневое хранилище ключей, и оно использует ведение журнала для проверки правильности использования. Один экземпляр Распределитель главных ключей корневого хранилища ключей работает для каждого экземпляра корневого хранилища ключей.

Когда запускается новый экземпляр распространителя главных ключей корневого хранилища ключей, он настроен со списком имен хостов уже запущенного дистрибьютора экземпляры. Затем экземпляры распространителя могут получить главный ключ корневого хранилища ключей. из других запущенных экземпляров. Помимо механизмов аварийного восстановления описано в Глобальная доступность и репликация, главный ключ корневого хранилища ключей существует только в ОЗУ на ограниченном количестве специально защищенные машины.

Для устранения сценария, когда все экземпляры главного ключа корневого хранилища ключей дистрибьютор в регионе перезагружается одновременно, мастер-ключ корневого хранилища ключей также резервные копии на защищенных аппаратных устройствах, которые хранятся в физических сейфах в строго охраняемые районы в нескольких географически распределенных местах. Этот резервное копирование потребуется только в том случае, если все экземпляры дистрибьютора в регионе будут удалены. сразу вниз. Доступ к этим сейфам имеют менее 100 сотрудников Google.

На следующей диаграмме показана иерархия ключей шифрования. Ключ шифрования иерархия защищает фрагмент данных с помощью DEK, обернутого с помощью KEK в хранилище ключей, который, в свою очередь, защищен корневым хранилищем ключей и главным ключом корневого хранилища ключей. распределитель.

Сводка по управлению ключами

В следующем списке представлены сводки по управлению ключами в Google:

• Данные разбиты на блоки и зашифрованы с помощью DEK.
• DEK зашифрованы с помощью KEK.
• KEK хранятся в хранилище ключей.
• Keystore работает на нескольких компьютерах в центрах обработки данных по всему миру.
• Ключи хранилища ключей упакованы с главным ключом хранилища ключей, который хранится в корневом хранилище ключей.
• Root Keystore намного меньше, чем Keystore, и работает только на выделенных серверах. машин в каждом центре обработки данных.
• Ключи корневого хранилища ключей упакованы с главным ключом корневого хранилища ключей, который хранится в корневом дистрибьюторе главных ключей хранилища ключей.
• Распределитель главных ключей Root Keystore является одноранговым инфраструктура, которая работает одновременно в оперативной памяти на выделенных машинах глобально. Каждая машина получает свой ключевой материал от других запущенных экземпляров. в регионе.
• В случае выхода из строя всех экземпляров распространителя в регионе мастер-ключ хранится в другом безопасном оборудовании в физических сейфах в ограниченное местоположение Google.

Глобальная доступность и репликация

На каждом уровне важна высокая доступность, низкая задержка и глобальный доступ к ключам. критический. Эти характеристики необходимы для предоставления услуг по управлению ключами. используется в Google.

По этой причине Keystore хорошо масштабируется и реплицируется на тысячи раз в наших центрах обработки данных по всему миру. Он запускается на обычных машинах в нашей производственный парк, а экземпляры Keystore работают по всему миру для поддержки Google. операции. В результате задержка любой операции с одной клавишей очень мала.

Корневое хранилище ключей запущено на нескольких машинах, предназначенных для операций безопасности, в каждого дата-центра. Распределитель главных ключей Root Keystore работает на этих же серверах. машины, один на один с Root Keystore. Мастер-ключ корневого хранилища ключей дистрибьютор обеспечивает механизм распределения, используя протокол сплетни. Через фиксированный интервал времени каждый экземпляр распространителя выбирает случайный другой экземпляр для сравнения его ключей и согласования любых различий в ключе версии. В этой модели нет центрального узла, в котором все наши зависит от инфраструктуры. Этот метод распространения позволяет нам поддерживать и защищать ключевой материал с высокой доступностью.

Общая криптографическая библиотека Google

Общая криптографическая библиотека Google Тинк, который включает в себя наш проверенный модуль FIPS 140-2, СкучнаяКрипто. Tink доступен для всех разработчиков Google. Последовательное использование общей библиотеки означает, что только небольшая команда криптографов должна плотно реализовать это контролируемый и проверенный код, что избавляет каждую команду Google от необходимости самостоятельно разрабатывать собственную криптографию. Специальная группа безопасности Google отвечает за поддержание этой общей криптографической библиотеки для всех товары.

Библиотека шифрования Tink поддерживает широкий спектр типов ключей шифрования и режимы, и они регулярно пересматриваются, чтобы убедиться, что они соответствуют последние атаки.

В настоящее время мы используем следующие алгоритмы шифрования для шифрования в состоянии покоя для ДЭКов и КЕКов. Они могут быть изменены, поскольку мы продолжаем улучшать наши возможности и безопасность.

Другие криптографические протоколы существуют в библиотеке и исторически поддерживается, но эта таблица охватывает основные виды использования в Google.

Исследования и инновации в области криптографии

Чтобы идти в ногу с развитием шифрования, у нас есть команда специалистов мирового уровня. инженеры по безопасности, которым поручено отслеживать, разрабатывать и улучшать шифрование технологии. Наши инженеры принимают участие в процессах стандартизации и поддержка широко используемого программного обеспечения для шифрования. Мы регулярно публикуем наши исследования в области шифрования, чтобы каждый, в том числе широкая общественность, мог воспользоваться нашими знаниями.

Например, в исследованиях постквантовой криптографии мы работаем в следующих областях:

• Стандартизация : Мы вносим свой вклад в постоянную стандартизацию усилия по постквантовой криптографии. Мы являемся соавторами трех криптосистем предложения, рассматриваемые NIST, которые находятся в третьем раунде Конкурс по стандартизации постквантовой криптографии. Мы являемся редакторами Международной организации по стандартизации (ISO) стандарт на подписи на основе хэшей постквантовой криптографии. Мы являемся соредакторами проекта Инженерной группы Интернета (IETF) по Кодирование JSON для подписей постквантовой криптографии.

• Включение : Недавно мы включили несколько постквантовых криптографические алгоритмы в нашем Криптографическая библиотека Tink. Это экспериментальный код, предназначенный для обучения сообщества. о плюсах и минусах каждого подхода.

• Публикации : Мы недавно опубликовали Переход организаций на постквантовую криптографию в Природа . В этой статье представлен обзор постквантовой криптографии. миграционные вызовы.

Что дальше

• Для получения информации об использовании собственных ключей шифрования в Облако Google, см. Ключи шифрования, управляемые клиентом (CMEK).

• Для получения общей информации о безопасности Google Cloud см.

  No related posts.