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

В контексте облачных вычислений часто бывает так, что ненадежными внешними сетями являются сеть Интернет или другие сети доступа к облачным средам (см. 13.2). Доверенные защищенные сети — это сети, используемые для внутриоблачных сетевых подключений (см. 13.3).

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

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

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

Что касается прикладных облачных сервисов, поставщик облачной службы, как правило, предоставляет функциональные возможности межсетевого экрана как часть облачного сервиса [из 15.2 Межсетевые экраны ГОСТ Р 70860—2023]

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

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

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

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

[из 15.4 Управление идентификацией и доступом пользователей ГОСТ Р 70860—2023]

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

Функциональные возможности управления ключами часто предоставляются в виде облачных сервисов для интеграции с ресурсами, которые могут быть сами облачными сервисами или ресурсами, развернутыми потребителем облачной службы в облачных сервисах. Облачные сервисы по управлению ключами часто основаны на использовании поставщиком облачной службы аппаратных модулей безопасности для обеспечения надежной защиты ключей шифрования, которыми они управляют. Некоторые облачные сервисы управления ключами сами генерируют и хранят ключи, в то время как другие поддерживают концепцию создания собственных ключей (BYOK), в рамках которой потребитель облачной службы может генерировать необходимые ключи и передавать их облачному сервису для хранения и использования. Эту концепцию можно эффективно использовать при развертывании нескольких облаков, когда требования к шифрованию распространяются на несколько различных облачных сервисов. Примером может служить ситуация, когда реплика некоторых зашифрованных данных хранится в облачном сервисе, который отличается от исходного облачного сервиса (возможно, у другого поставщика облачной службы) [из 15.6 Управление ключами ГОСТ Р 70860—2023]