Статья по безопасной облачной архитектуре (Secure Cloud Architecture)

Введение

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

Анализ рисков, моделирование угроз и оценка поверхности атаки

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

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

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

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

• Threat Modeling Cheat Sheet
• Attack Surface Analysis Cheat Sheet
• CISA: руководство по оценке киберрисков (PDF, англ.)

Публичные и приватные компоненты

Безопасное объектное хранилище

Доступ к объектному хранилищу обычно реализуется одним из способов:

• через встроенные политики IAM (идентификация и управление доступом);
• через криптографически подписанные URL и HTTP-запросы;
• через прямой публичный доступ к хранилищу.

Доступ через IAM

Подход предполагает опосредованный доступ через управляемый или самоуправляемый сервис на эфемерной или постоянной инфраструктуре. У инфраструктуры есть постоянные учётные данные control plane IAM, с которыми сервис обращается к объектному хранилищу от имени пользователя. Метод уместен, когда у приложения есть другие пользовательские интерфейсы или системы данных, когда важно скрыть само хранилище насколько возможно, либо когда данные не должны и не будут видны конечному пользователю (метаданные). Сочетается с веб-аутентификацией и журналированием для лучшего контроля и аудита доступа к ресурсам. Ключевой риск — зависимость от кода или политик, в которых могут быть уязвимости.

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

Подписанные URL

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

Публичное объектное хранилище

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

VPC и подсети

Виртуальные частные облака (VPC) и публичные/приватные подсети позволяют разбить приложение и сеть на изолированные сегменты. В зрелой архитектуре обычно используются оба типа подсетей. Ниже — кратко о каждом элементе.

VPC

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

• разделять целые приложения в одном облачном аккаунте;
• выносить крупные части приложения в отдельные VPC с изолированными сетями;
• разделять дубликаты приложений для разных клиентов или наборов данных.

Публичные подсети

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

• публичные ресурсы (фронтенд веб-приложений);
• точки входа: балансировщики, маршрутизаторы;
• точки доступа разработчиков, например bastion (при неверной настройке часто небезопасны).

Приватные подсети

Компоненты без прямого доступа в интернет; маршрутизация обычно связывает их с публичными подсетями для контролируемого приёма внешнего трафика. Подходят для:

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

Простой пример архитектуры

На схеме ниже VPC объединяет компоненты приложения; подсеть выбирается по роли. Типичный поток:

1. Пользователь заходит через интернет-шлюз, API-шлюз или другой публичный компонент.
2. Шлюз соединяется с балансировщиком или веб-сервером в публичной подсети — они выполняют публичные функции и защищаются соответствующим образом.
3. Далее запросы идут к бэкенду (БД, серверы) в приватной подсети; доступ ограничен, что снижает риск для «мягких» внутренних систем.

Диаграмма намеренно не показывает маршрутизацию и IAM между подсетями — для простоты и независимости от конкретного провайдера.

Такая схема не выставляет напрямую в интернет менее закалённые бэкенды и высокорисковые сервисы вроде БД; публичные функции остаются на периметре без лишних обходных путей. Безопасность концентрируется на точках входа, а чувствительные данные оказываются в приватной подсети.

Границы доверия

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

На примере ниже API-шлюз обращается к вычислительному инстансу (эфемерному или постоянному), который читает постоянное хранилище. Отдельно есть сервис аутентификации, авторизации и/или идентичности вызывающей стороны — типичная модель OAuth, IAM или каталога. Пунктиром отмечены границы доверия между вычислительными узлами, шлюзом и сервером auth/identity, даже если всё это одно приложение.

Разные уровни доверия

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

1. Пример без доверия между компонентами

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

И API-шлюз, и вычислительный инстанс обращаются к auth/identity: даже трафик «внутри» приложения между соседними узлами не считается доверенным. Инстанс берёт эфемерную идентичность для доступа к хранилищу, потому что сам инстанс не считается доверенным к конкретному ресурсу, даже если пользователь доверен инстансу.

Между auth/identity и эфемерным IAM и остальными компонентами тоже нет неявного доверия (на диаграмме не все детали): это ведёт к более строгим проверкам до аутентификации и большим накладным расходам на криптографию.

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

2. Пример с высоким доверием

Противоположный край: всё доверяет всему. «Опасный» пользовательский ввод передаётся напрямую в критичный бизнес-компонент; auth/identity не используется. Вероятность успешной атаки выше, контролей нет; корпоративные ресурсы IAM/OAuth могут простаивать. (Общие сервисы компании не используются по назначению.)

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

3. Частичное доверие

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

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

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

Эта логика отличается от Zero Trust; подробнее см. CISA Zero Trust Maturity Model v2 (PDF).

Инструменты безопасности

WAF (межсетевой экран веб-приложений)

WAF фильтрует или блокирует типовые вредоносные полезные нагрузки (например XSS и SQLi) либо пропускает только допустимые шаблоны запросов. Размещайте WAF на периметре — у балансировщика или API-шлюза — чтобы отсечь угрозы до кода приложения. У крупных провайдеров есть управляемые наборы правил:

• AWS Managed Rules
• GCP WAF Rules
• Azure Core Rule Sets

Базовые наборы универсальны; добавляйте правила под ваш стек и критичные маршруты, например:

• ограничение маршрутов (против скрейпинга);
• защита выбранных технологий и эндпоинтов;
• rate limiting для чувствительных API.

Журналирование и мониторинг

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

Журналирование

Рекомендации:

• логировать HTTP-запросы уровня 7 с заголовками, метаданными вызывающей стороны и ответами
  • тела запросов могут не логироваться из-за TLS-терминации и чувствительности данных;
• логировать внутренние действия с указанием субъекта и прав;
• прокидывать trace ID через весь жизненный цикл запроса;
• маскировать или удалять чувствительные данные (SSN, PHI, прочий PII не должен попадать в логи).

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

Мониторинг

Добавьте, в частности:

• алерты по аномалиям:
  • доля HTTP 4xx/5xx выше нормы;
  • память, диск, CPU вне нормы;
  • чтения/записи в БД вне нормы;
  • число вызовов serverless выше нормы;
• сбои health check;
• ошибки деплоя или циклы перезапуска контейнеров;
• пороги по расходам / биллингу.

Пороги «в процентах от нормы» задаются от базовой линии конкретной среды, с учётом риска и возможностей реагирования команды. У WAF часто есть свои метрики и детекция аномалий.

Защита от DDoS

Провайдеры предлагают продукты разной сложности: простые случаи закрываются WAF с rate limit и блокировкой маршрутов; для серьёзных угроз — специализированные сервисы, например:

• AWS Shield
• GCP Cloud Armor Managed Protection
• Azure DDoS Protection

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

Модель общей ответственности (Shared Responsibility)

Модель описывает, как между облачным провайдером (CSP) и разработчиком/заказчиком распределяются обязанности по разным слоям стека. Физическое железо и ЦОД — зона CSP; в зависимости от уровня управляемости сервиса заказчик может отвечать за всё от ОС и выше или только за прикладной код и администрирование.

Часто выделяют три уровня:

• Infrastructure as a Service (IaaS)
• Platform as a Service (PaaS)
• Software as a Service (SaaS)

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

Чем «выше» уровень сервиса, тем больше зон ответственности берёт на себя провайдер; у каждого уровня свои компромиссы.

IaaS

Инфраструктуру ведёт CSP, остальное — зона разработчика: аутентификация и авторизация, хранение и доступ к данным, сетевая настройка (порты, ACL и т.д.), прикладное ПО.

Модель даёт гибкость и контроль, но сложнее и обычно дороже PaaS/SaaS; ближе к классическому on-prem, что упрощает «подъём» некоторых приложений в облако без полной переработки архитектуры.

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

PaaS

Платформа между IaaS и SaaS. Разработчик контролирует, как правило:

• аутентификацию и авторизацию приложения;
• прикладной код;
• внешние по отношению к платформе хранилища.

Удобные хостинг и контейнеры помогают небольшим командам, но возможны ограничения конкретного предложения и несовместимость версий языка/фреймворка/контейнера. Масштабируемость обычно выше, чем у «ручного» IaaS, за счёт типовых образов ОС.

Объём ручной работы по безопасности меньше, чем в IaaS: аутентификация/авторизация приложения и внешние данные остаются на вас; CSP закрывает контейнеры, ОС, эфемерные ФС и часть сетевых контролов.

SaaS

Почти готовый продукт: пользователь настраивает детали под себя. Обычно под контролем заказчика:

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

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

Безопасность SaaS одновременно проще и сложнее: с вашей стороны — ограниченный набор функций (часть ACL, доверие к интеграциям, последствия кастомизаций), остальное — у провайдера. Исправления могут приходить не в вашем темпе или не на нужном уровне; зато не требуют ваших инженерных ресурсов.

При выборе SaaS запрашивайте отчёты об аттестации и соответствии стандартам вроде ISO 27001. Ссылки на программы комплаенса крупных CSP:

• GCP
• AWS
• Azure

Спектр «управляемости»

Модель общей ответственности можно описать как спектр от полностью управляемых сервисов (почти только код и админка — ближе к SaaS) до самоуправляемых систем с большим операционным overhead (ближе к IaaS).

У AWS наглядно показано, как разные продукты ложатся на этот спектр.

Точная классификация каждого SKU как IaaS/PaaS может различаться — смотрите документацию к конкретному сервису.

Стратегия обновлений для самоуправляемых сервисов

Самоуправляемые компоненты требуют ресурсов на обновления версий, образов (AMI, Compute Images) и обслуживание на уровне ОС. Автоматизируйте мелкие обновления и образы; закладывайте в циклы разработки время на «освежение» устаревших ресурсов.

Не оставляйте дыры в безопасности управляемых сервисов

Управляемый сервис закрывает часть задач (например, железо под вашим кодом), но команда разработки всё равно отвечает за многие аспекты. Убедитесь, что понятно разделение ответственности по выбранному продукту. Часто целиком или частично на заказчике:

• аутентификация и авторизация;
• логирование и мониторинг;
• безопасность кода (OWASP Top 10);
• обновление сторонних библиотек.

Смотрите документацию CSP; для serverless, например:

• AWS Lambda
• GCP Cloud Functions
• Azure Functions

Ссылки

• Secure Product Design Cheat Sheet
• CISA Cloud Security Technical Reference Architecture (PDF)