Ключи шифрования. Сервис KMS

Кратко:

• Шифрование данных помогает сохранить их конфиденциальность и целостность.
• Современные криптографические алгоритмы обеспечивают надежную защиту информации.
• Длина ключа влияет на силу защиты, чем длиннее ключ, тем лучше защита.
• Симметричные и асимметричные алгоритмы используются для шифрования данных.
• Хранение ключей является уязвимым местом систем защиты, основанных на шифровании.
• Схема envelope encryption используется для защиты ключей шифрования.
• Сервис KMS может быть использован для управления ключами шифрования и шифрования данных.
• KMS может быть использован в различных сценариях, включая шифрование данных с помощью утилиты yc и в пользовательских приложениях.

Ключи шифрования. Сервис KMS

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

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

Существуют симметричные и асимметричные алгоритмы шифрования. В симметричных данные шифруются и расшифровываются одним и тем же ключом. Асимметричные методы построены на использовании двух ключей: открытого и закрытого (секретного). Открытый ключ нужен для шифрования, а закрытый — для расшифрования. Данные устойчивы к атакам методом перебора, если они зашифрованы с использованием ключа длиной не менее 128 бит для симметричных алгоритмов и не менее 1024 бит для асимметричных. Сами алгоритмы при этом, естественно, должны быть современными и актуальными.

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

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

Хранить ключ в открытом виде на всех серверах, где запущены сервисы, рискованно. Если злоумышленник получит доступ хотя бы к одному из них, он сможет отыскать ключ в настройках, что скомпрометирует всю систему. Более надёжный вариант — зашифровать ключ шифрования данных DEK (Data Encryption Key) c помощью ещё одного ключа KEK (Key Encryption Key). Теперь даже если злоумышленник и найдёт на взломанном сервере зашифрованный ключ DEK, то расшифровать данные в хранилище он сможет далеко не сразу. Подобная схема защиты называется envelope encryption.

Чтобы использовать такую схему, нам придётся решить две проблемы: где хранить ключ KEK, чтобы минимизировать вероятность его компрометации, и как безопасно пользоваться открытой версией ключа DEK.

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

Второй вариант — использовать специальный сервис KMS, который:

• надёжно хранит ключ KEK и никуда его не передаёт;
• после получения запроса раскодирует зашифрованный ключ DEK и отправляет его пользователю.

В общем виде схему работы этого сервиса можно изобразить следующим образом.

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

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

На этом принципе работы построен сервис управления ключами Yandex KMS (Key Management Service). Давайте рассмотрим, для чего он предназначен, подробнее.

Прежде всего KMS нужен для того, чтобы генерировать ключи шифрования. Сделать это можно через консоль управления, с помощью CLI, а также REST или gRPC API. Сервис поддерживает симметричное шифрование с алгоритмами AES-128, AES-192 и AES-256 (число в названии алгоритма обозначает длину ключа в битах).

У созданного в сервисе ключа есть следующие параметры:

• идентификатор — уникален в рамках всего Yandex Cloud и используется для работы с ключами с помощью SDK, API и CLI;
• название — может быть не уникально и используется для работы с ключами с помощью CLI (только если в каталоге есть лишь один ключ с таким названием);
• используемый алгоритм шифрования;
• период ротации — промежуток времени между автоматической сменой ключа;
• статус — состояние ключа (Creating, Active или Inactive).

Чтобы сделать защиту более надёжной, срок действия ключа ограничивают. После истечения этого срока сервис автоматически создаст новую версию ключа, то есть новый ключ с такими же параметрами (отличаться будут лишь ID версий). Этот процесс называется ротацией ключа. Ротировать ключи можно и вручную.

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

Для всех версий ключа, кроме основной, можно настроить время удаления. Когда версия ключа удалена, расшифровать данные, зашифрованные с её помощью, невозможно. Поэтому сервис удаляет версию ключа не сразу, а через определённое время (по умолчанию это два дня). Когда ключ находится в статусе Scheduled for Destruction (запланирован к удалению), воспользоваться им для расшифровки данных уже нельзя. Процесс удаления можно отменить. Кроме того, чтобы избежать потери данных, ключ можно защитить от удаления, выбрав параметр Защита от удаления.

С помощью KMS можно шифровать и расшифровывать данные. Если эти операции выполняются на стороне сервиса, то объём данных не может превышать 32 килобайта. Это обусловлено необходимостью ограничить нагрузку на сервис, чтобы обеспечить его высокую производительность. В качестве шифруемых данных могут выступать, например, секреты или сессионные ключи шифрования, что может быть использовано в пользовательских приложениях. Шифрование и расшифрование выполняются с помощью методов encrypt и decrypt REST API.

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

Шифрование происходит следующим образом.

1. Пользователь самостоятельно генерирует ключ DEK и шифрует им данные на своей машине.
2. Пользователь направляет в KMS запрос encrypt на шифрование DEK.
3. Ключ KMS, которым выполняется шифрование DEK, выступает в роли ключа KEK.
4. Сервис возвращает зашифрованный DEK.
5. Пользователь сохраняет зашифрованный DEK рядом с шифртекстом и уничтожает незашифрованный DEK.

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

Сервис KMS используют в следующих сценариях:

• для шифрования данных с помощью утилиты yc (CLI);
• в пользовательских приложениях через REST или gRPC API;
• для шифрования данных в объектном хранилище;
• для защиты секретов при использовании сервиса управления кластерами Kubernetes.

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

 

Проверьте себя

Каких целей информационной безопасности можно достичь с помощью сервиса KMS?

 

Правильный ответ:

• Целостность
• Конфиденциальность

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

 

Правильный ответ:

• envelope encryption

Можно ли расшифровать данные с использованием помеченной на удаление версии ключа?

 

Правильный ответ:

• Нет

Категория: Cloud Services Engineer

Просмотров: 837

ПР. Выпуск сертификата для сайта

Кратко:

• Регистрация домена и привязка к бакету в Object Storage.
• Создание публичного бакета с названием, совпадающим с полным названием домена.
• Загрузка файлов статического сайта в бакет.
• Настройка защищенного доступа к бакету с помощью Certificate Manager.
• Выпуск сертификата Let's Encrypt и подтверждение владения доменом.
• Добавление TXT- и CNAME-записей для подтверждения владения доменом.
• Настройка DNS-серверов для использования собственного домена.
• Настройка доступа к сайту по протоколу HTTPS с использованием ранее выпущенного сертификата.

Практическая работа. Выпуск сертификата для сайта

1. Проверьте на сайте доступность имени, которое вы придумали для своего домена.
   Введите имя вместе с доменом верхнего уровня, например testpracticum2022.ml, иначе при попытке зарезервировать домен сервис будет сообщать, что домен занят.
2. Если это имя доступно, добавьте домен в корзину и укажите свой email для подтверждения.
3. Проверьте почту и подтвердите регистрацию домена.
4. Обновите страницу с заказом.

5. После подтверждения регистрации домена зайдите в объектное хранилище (Object Storage) и создайте новый публичный бакет. Его название должно совпадать с полным названием домена.

6. Переключите доступ на чтение объектов в Публичный. Загрузите в бакет файлы статического сайта (вы можете воспользоваться файлами из практической работы курса «Хранение и анализ данных».
7. Выберите на панели управления раздел Веб-сайт, переключите бакет в режим Хостинг и нажмите Сохранить.

1. В консоли управления перейдите в сервис Certificate Manager. Для выпуска сертификата с помощью этого сервиса подтвердите владение доменом: в разделе Сертификаты нажмите кнопку Добавить сертификат и выберите Сертификат Let’s Encrypt.
   
2. В открывшемся окне задайте имя создаваемого сертификата и заполните поле с именем вашего домена. Нажмите кнопку Создать.

3. Для выпуска сертификата необходимо подтвердить статус владения доменом. Откройте страницу с деталями запроса на сертификат:

Категория: Cloud Services Engineer

Просмотров: 654

Сервис Certificate Manager

Кратко: 

• TLS-сертификаты необходимы для передачи данных в интернете с использованием протокола HTTPS.
• TLS-сертификат содержит информацию о домене, владельце, цифровой подписи центра сертификации и другие данные.
• Для передачи данных по HTTPS на сервере должен быть установлен доверенный сертификат.
• Существуют разные типы TLS-сертификатов, наиболее надежными являются EV и OV сертификаты.
• В Yandex Cloud для управления сертификатами используется сервис Certificate Manager.
• В сервисе Certificate Manager можно управлять пользовательскими и сертификатами Let's Encrypt.
• TLS-сертификаты Let's Encrypt имеют статус Domain Validation и срок действия 90 дней.
• Сертификаты от Let's Encrypt могут находиться в статусах Validating, Issued, Invalid, Renewing и Renewal_failed.

Сервис Certificate Manager

TLS-сертификаты

Делая что-либо в интернете, мы заинтересованы в том, чтобы передаваемые данные были защищены. Для этого используется протокол HTTPS (HyperText Transfer Protocol Secure) — по сути, комбинация из протокола передачи данных прикладного уровня HTTP и криптографического протокола транспортного уровня SSL (Secure Socket Layer). Современная версия SSL-протокола называется TLS (Transport Layer Security), однако сама аббревиатура SSL стала настолько привычной, что её часто употребляют до сих пор.

Когда вы используете TLS-протокол, информация передаётся внутри зашифрованной сессии. Работает это так:

1. Ваш браузер обращается к защищённому сайту (серверу) и запрашивает у него идентификационную информацию.
2. Сервер отправляет в ответ копию своего TLS-сертификата.
3. Браузер проверяет сертификат по списку доверенных центров сертификации. Если всё в порядке, то браузер создает, шифрует и отправляет серверу ключ симметричного шифрования для предстоящей сессии передачи данных.
4. Сервер расшифровывает ключ и направляет браузеру подтверждение, после чего все передаваемые между ними данные шифруются этим ключом.

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

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

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

• доменное имя сайта на совпадение с именем в сертификате;
• политику применения сертификата;
• информацию об издателе;
• срок действия сертификата и не отозван ли он.

TLS-сертификаты выдают центры сертификации (Certification Authority), которые подписывают запросы на сертификат и могут проверять информацию о владельце сайта. В зависимости от глубины такой проверки выпускаемые сертификаты бывают нескольких типов.

Самые надёжные — сертификаты с расширенной проверкой (EV, Extended Validation) и с проверкой организации (OV, Organization Validation). При выпуске таких сертификатов проверяется юридическое и физическое существование запрашивающей организации и её право на домен, а для EV-сертификатов — ещё и соответствие её деятельности представленным документам.

Для сертификатов с проверкой домена (DV, Domain Validation) всё проще — проверяется только право собственности на домен. Зато этот тип сертификата могут получить не только юридические, но и физические лица.

Управление сертификатами в Yandex Cloud

Жизненным циклом сертификатов необходимо управлять: отслеживать окончание срока их действия, вовремя запрашивать и устанавливать новые. В Yandex Cloud для этого есть сервис Certificate Manager.

Для корректной работы в этом сервисе сертификаты должны удовлетворять ряду требований:

• соответствовать стандарту X.509 v3;
• содержать публичный ключ, доменное имя сайта и информацию об издателе;
• быть актуальными на момент импорта (импортировать сертификат до начала и после окончания срока его действия нельзя);
• приватный ключ сертификата не должен быть зашифрован, то есть импортировать защищённый паролем приватный ключ нельзя;
• сертификат, цепочка промежуточных сертификатов и приватный ключ должны импортироваться в формате PEM-Encoded.

Сервис поддерживает два типа сертификатов:

1. Пользовательские, которые импортирует сам пользователь. За обновлением таких сертификатов нужно следить самостоятельно.
2. Сертификаты, которые выпускаются с помощью сервиса Let's Encrypt. Такие сертификаты управляются непосредственно сервисом Certificate Manager. Обновление сертификата запускается автоматически, однако в определенных случаях необходимо участие пользователя.

Чтобы добавить пользовательский сертификат, необходимо перейти к сервису Certificate Manager, выбрать на панели слева раздел Сертификаты, нажать кнопку Добавить сертификат и выбрать Добавить пользовательский сертификат.

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

Достоинством сервиса Certificate Manager является возможность автоматизировать выпуск TLS-сертификатов Let's Encrypt. Для этого необходимо запросить сертификат в сервисе Let's Encrypt и пройти процедуру проверки прав на домены. После этого Certificate Manager будет управлять этими сертификатами, взаимодействуя с Let's Encrypt самостоятельно.

Let's Encrypt предоставляет TLS-сертификаты со статусом Domain Validation и сроком действия 90 дней. Если нужны сертификаты с большим сроком действия или другим статусом (OV или EV), воспользуйтесь сторонним центром сертификации и используйте пользовательский тип сертификата.

После загрузки или получения сертификата Certificate Manager отображает текущий статус сертификата исходя из его жизненного цикла. Жизненный цикл и набор статусов сертификата зависит от его типа.

Импортированные пользовательские сертификаты всегда находятся в статусе Issued. Это значит, что сертификат получен и может быть использован в сервисах, интегрированных с Certificate Manager.

Сертификаты от Let's Encrypt могут находиться в следующих статусах:

• Validating — запрос на сертификат был создан, сертификат запрошен у Let's Encrypt и ожидает проверки прав на домен.
• Issued — сертификат выпущен и получен.
• Invalid — сертификат не прошёл проверку. Такое сообщение может возникнуть, если процедура проверки прав на домен со стороны Let’s Encrypt не прошла в течение одной недели или завершилась с ошибкой.
• Renewing — сертификат в процессе обновления.
• Renewal_failed — не удалось обновить сертификат.

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

 

💡 Напомним: чтобы привязать внешний домен к статическому сайту в объектном хранилище и использовать сертификат, нужно, чтобы имя домена совпадало с именем бакета, в котором хранятся файлы. Например, для сайта aibolit.ru имя бакета должно быть aibolit.ru. После того, как сертификат появился в Certificate Manager, достаточно перейти в раздел HTTPS настроек бакета и выбрать нужный сертификат в пункте Certificate Manager.

На следующем уроке вы потренируетесь в этом на практике.

 

Проверьте себя

Какие типы сертификатов поддерживает Certificate Manager?

 

Правильный ответ:

• Пользовательские
• Let’s Encrypt

Происходит ли автоматическое обновление пользовательских сертификатов с помощью сервиса Certificate Manager?

 

Правильный ответ:

• Нет

Категория: Cloud Services Engineer

Просмотров: 742

Лучшие практики обеспечения сетевой безопасности

Кратко:

• Обеспечение сетевой безопасности облачных сетей требует использования проверенных методов.
• Организация доступа администраторов к инфраструктуре по защищённому каналу с использованием SSH или VPN-шлюза.
• Использование ключей доступа и X.509-сертификатов вместо паролей.
• Защита виртуальных машин в облачной сети с помощью DMZ и других сегментов.
• Использование сетевого балансировщика нагрузки для доставки трафика в приложение.
• Использование статических публичных IP-адресов для исходящего доступа в интернет.
• Шифрование данных при передаче с использованием TLS 1.2 и выше.
• Использование систем обнаружения вторжений для записи информации о входящем и исходящем трафике.

Лучшие практики обеспечения сетевой безопасности

Доступ в инфраструктуру для администраторов

Доставка трафика в приложение и сетевая сегментация

Исходящий доступ в интернет

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

Категория: Cloud Services Engineer

Просмотров: 614