Сравнивать публичные облака по показателю «безопасность» как спортивные соревнования — бесполезно. Безопасность — не результат, а процесс, который зависит в первую очередь от тебя, а не от провайдера. Вопрос не в том, кто предоставляет «самый безопасный замок», а в том, какой набор инструментов и какие модели ответственности лучше соответствуют твоему конкретному сценарию, где и как провайдер может закрыть твои слабости и какой объём рутинной работы он с тебя снимет.
Модель ответственности: основа, которую часто не читают
В публичных облаках ты никогда не арендуешь просто сервер. Ты арендуешь уровень абстракции над физической инфраструктурой. От выбора этого уровня зависит, где проходит граница твоей ответственности и ответственности провайдера.
Все провайдеры следуют общей логике модели shared responsibility, но её конкретная реализация меняется в зависимости от сервиса.
IaaS: виртуальная машина
При аренде виртуальной машины провайдер отвечает за физическую безопасность дата-центров, сетевую инфраструктуру и гипервизор. Всё, что находится «внутри» виртуальной машины — операционная система, приложения, данные, настройки брандмауэра операционной системы и управление доступом — твоя зона.
- Пример риска: Незакрытая уязвимость в веб-сервере на твоей виртуальной машине — твоя проблема, а не AWS.
- Общая черта для всех: В IaaS провайдер предоставляет тебе максимальную гибкость и максимальную операционную нагрузку по безопасности.
PaaS и управляемые сервисы
При использовании, например, управляемой базы данных (RDS, Cloud SQL) или контейнерного сервиса (Elastic Kubernetes Service, Azure Kubernetes Service) провайдер берёт на себя часть операционной ответственности.
- Что делает провайдер: Патчинг операционной системы базового инстанса, обновление СУБД в определённых конфигурациях, изоляция сетевого трафика между твоими сервисами внутри своей платформы.
- Что остаётся тебе: Настройка правил доступа к сервису (IAM, брандмауэры уровня сервиса), шифрование данных (управление ключами), безопасность твоего прикладного кода, который работает с этой базой.
Чем выше уровень абстракции (переход к SaaS), тем больше рутинной безопасности ложится на провайдера, но тем сильнее ты зависишь от его конкретных политик и инструментов.
Три столпа: Identity, Data, Infrastructure
Безопасность облака, это не одна стена, а три взаимосвязанных контура. Слабость в одном сводит на нет усилия в других.
1. Identity and Access Management (IAM)
Система IAM, это шлюз ко всем твоим ресурсам. Настройка политик доступа по принципу наименьших привилегий (least privilege) — основа.
| Аспект | AWS IAM | Azure Active Directory + RBAC | Google Cloud IAM |
|---|---|---|---|
| Основная модель | Роли, политики на основе JSON. Сильно привязана к сервисам AWS. | Интеграция с корпоративным Active Directory. Ролевое управление доступом к ресурсам Azure (Azure RBAC). | Роли и политики. Понятие «организация» и иерархия ресурсов — ключевая особенность. |
| Особенность | Подробные политики, позволяющие описывать доступ с очень высокой гранулярностью (например, к определённому тегу или в определённое время). | Единая идентификация для Azure, Microsoft 365 и гибридных сред. Условный доступ (Conditional Access) для MFA и контроля сессий. | Иерархическое наследование политик от уровня организации к папкам и проектам. Удобно для централизованного управления в больших структурах. |
| Что проверять | Кто имеет доступ к корневой учётной записи? Используются ли роли для сервисов вместо долгосрочных ключей? Включён ли CloudTrail для аудита? | Настроен ли Conditional Access для критичных административных ролей? Проведена ли интеграция с локальным AD (если есть)? | Понимаешь ли ты наследование политик в Resource Hierarchy? Используются ли организационные политики (Organization Policies) для наложения ограничений? |
2. Защита данных
Данные — конечная цель атаки. Защита делится на два состояния: data at rest (хранимые) и data in transit (передаваемые).
Шифрование хранимых данных: Все провайдеры предлагают прозрачное серверное шифрование (SSE) для основных сервисов хранения (S3, Blob Storage, Cloud Storage) по умолчанию. Ключи могут управляться платформой (по умолчанию) или тобой (Customer-Managed Keys, CMK).
- Ключевое различие: Гибридные сценарии и интеграция с внешними аппаратными модулями безопасности. Azure, благодаря глубокой интеграции с экосистемой Microsoft, часто предлагает более плавные сценарии для организаций с существующей инфраструктурой PKI и Active Directory.
- Общая проблема: Шифрование есть, но конфигурация доступа к бакету или контейнеру (публичный доступ) может его обнулить. Безопасность данных упирается в правильные настройки IAM и сетевых политик.
Шифрование передаваемых данных: Обеспечивается TLS. Важно следить за устаревшими протоколами и шифрами. Все облака предоставляют инструменты для принудительного использования TLS 1.2+.
3. Защита инфраструктуры (сеть и вычисления)
Сетевой уровень изолирует твои ресурсы от интернета и друг от друга.
- Виртуальные частные облака (VPC/VNet): Ты определяешь диапазоны IP-адресов, создаешь подсети, таблицы маршрутизации. Это твоя изолированная сеть в облаке.
- Группы безопасности и брандмауэры: Stateful-фильтрация на уровне виртуальной машины или подсети. Основное правило: запретить всё, разрешить минимально необходимое.
- Защита от DDoS: Базовый уровень защиты предоставляется всем провайдерами автоматически на границе их сети. Расширенные сервисы (AWS Shield Advanced, Azure DDoS Protection) предлагают детальную аналитику и защиту для специфичных протоколов.
На уровне вычислений ключевую роль играет управление уязвимостями. Для виртуальных машин это твоя ответственность: сканирование образов, своевременный патчинг. Управляемые сервисы (PaaS) снимают эту нагрузку — провайдер сам обновляет базовую операционную систему.
Аудит и мониторинг: видеть, чтобы управлять
Без логов ты слеп. Возможность ответить на вопросы «Кто, что, когда и откуда сделал?» критична для расследования инцидентов и соблюдения регуляторных требований.
- AWS CloudTrail: Логирует все вызовы API, связанные с управлением аккаунтом и ресурсами. Хранилище для логов — S3.
- Azure Monitor + Activity Log: Activity Log фиксирует события на уровне подписки. Diagnostic Settings позволяют направлять логи в Log Analytics Workspace для глубокого анализа.
- Google Cloud Audit Logs: Административные аудит-логи, логи доступа к данным и системные логи. Интегрируются с Cloud Logging.
Логов много, их нужно где-то хранить, анализировать и настраивать на них оповещения. Все провайдеры предлагают свои SIEM-подобные решения (Amazon GuardDuty, Microsoft Defender for Cloud, Google Cloud Security Command Center), которые анализируют эти логи и сетевые потоки, выявляя подозрительную активность.
Что важнее провайдера: твоя зрелость процессов
Технические возможности провайдеров сопоставимы. Итоговый уровень безопасности определяется тем, как ты эти возможности используешь.
- Конфигурация по умолчанию: Облачные сервисы редко поставляются в максимально безопасной конфигурации. S3-бакет по умолчанию приватный, но публичный доступ можно открыть в два клика. Запрещающая политика брандмауэра, это твоя ручная настройка.
- Управление секретами: Хранение паролей, ключей API или строк подключения в коде или в метаданных инстанса — типичная и фатальная ошибка. Используй специализированные сервисы: AWS Secrets Manager, Azure Key Vault, Google Secret Manager.
- Инфраструктура как код (IaC): Развёртывание через Terraform, CloudFormation или аналоги гарантирует воспроизводимость и позволяет проводить статический анализ конфигураций на предмет уязвимостей до их применения в продуктивной среде.
- Регулярные проверки и пентесты: Все провайдеры требуют предварительного согласования на проведение тестов на проникновение в твоих ресурсах. Это стандартная практика. Регулярное сканирование уязвимостей в контейнерах и зависимостях приложений — must have.
Заключение: не «кто», а «как»
Спросить «какое облако безопаснее» — всё равно что спросить «какой автомобиль безопаснее». Ответ зависит от того, кто за рулём, как он водит, и обслуживается ли машина.
AWS, Microsoft Azure и Google Cloud вкладывают миллиарды в безопасность своей физической и логической инфраструктуры. Их модели сервисов и инструменты различаются, отражая их корпоративную ДНК: AWS с фокусом на гибкость и глубину для технических специалистов, Azure с синергией для гибридных и корпоративных сред, Google Cloud с акцентом на глобальную сеть и data-centric безопасность.
Выбор облака для проекта должен основываться на факторах, выходящих за рамки абстрактной «безопасности»: соответствие модели сервисов архитектурным требованиям, стоимость инструментов мониторинга и защиты, интеграция с существующими системами управления идентификацией, наличие экспертизы команды.
Самая большая уязвимость находится не между строчками в сравнительной таблице провайдеров, а в конфигурации ресурсов, оставленных с настройками по умолчанию, и в ключах доступа, хранящихся в открытом виде. Безопасность облака, это ответственность, которую нельзя делегировать полностью, её можно только правильно распределить.