«Сравнение облака и локальной инфраструктуры, это не просто выбор технологии, а выбор ответственности. Решение о том, кто контролирует каждый элемент системы, в конечном итоге формирует профиль рисков, где уязвимости превращаются в конкретные инциденты и компенсацию ущерба. Вопрос не в том, что «безопаснее» абстрактно, а в том, какие угрозы вы способны нейтрализовать своими силами и какие готовы делегировать, осознавая компромиссы».
Почему «безопаснее» — вопрос не бинарный
Обсуждение безопасности облака против локальной инфраструктуры часто скатывается в спор «стенка на стенку», где каждая сторона приводит удобные для себя аргументы. Облачные адепты говорят о физической безопасности дата-центров мирового уровня, регулярных пентестах и патчах, которые применяются централизованно. Сторонники локального хранения указывают на полный контроль над каждым битом данных и отсутствие зависимости от внешних провайдеров. Обе позиции верны, но рассматривают безопасность с разных углов. Говорить, что один подход «безопаснее» другого — всё равно что утверждать, что автомобиль безопаснее велосипеда. Это зависит от того, по какой дороге вы едете, кто за рулём и какие правила соблюдаете.
Безопасность, это не статичное состояние, а динамичный процесс управления рисками. Риски в облаке и локально — разные. В одном случае вы делегируете часть угроз профессиональной команде, но взамен принимаете на себя риски доверия, цепочек поставок и соблюдения регуляторных требований провайдером. В другом — оставляете все риски внутри организации, что требует наличия компетенций и ресурсов для их парирования.
Ответственность и контроль: разделение зон
Ключевая концепция, которую необходимо понять — модель разделения ответственности (Shared Responsibility Model). Это не юридическая отговорка провайдеров, а фундаментальный принцип архитектуры.
В облаке
- Провайдер отвечает за безопасность «облака» как такового: физическая защита дата-центров, безопасность гипервизора, сетевой инфраструктуры ниже определённого уровня, базовой платформы хранения.
- Клиент отвечает за безопасность «в облаке»: конфигурация виртуальных сетей и групп безопасности, управление доступом к ресурсам (IAM), шифрование данных на уровне приложения, безопасность операционных систем и ПО на виртуальных машинах, резервное копирование конфигураций и данных.
Провайдер обеспечивает безопасный фундамент, но вы строите на нём дом. Если вы не установили замки на дверь этого дома (например, оставили порт 3389 для RDP открытым для интернета), провайдер не виноват во взломе. Ваша зона ответственности огромна и требует не меньшей, а иногда и большей экспертизы, чем при локальном развёртывании.
В локальной инфраструктуре
Здесь вы — единственный ответственный за всё: от замка на двери серверной комнаты до последнего патча в базе данных. Это даёт иллюзию полного контроля, но также означает полную ответственность за все упущения. Недостаток ресурсов на регулярное обновление систем, устаревшие модели управления доступом или физический доступ к серверам со стороны неавторизованного персонала становятся исключительно вашей проблемой. Никто не разделит с вами эту нагрузку.
Специфические угрозы и уязвимости
Угрозы отличаются не только по природе, но и по масштабу потенциального воздействия.
Угрозы в облачной среде
- Ошибки конфигурации и «утечки ведёр»: Самая распространённая причина инцидентов. Неправильно настроенная политика доступа к хранилищу объектов (например, S3-совместимому), делающая данные публичными, или открытые административные порты.
- Компрометация учётных записей и ключей доступа: Учётные данные с чрезмерными привилегиями, хранящиеся в открытом виде в репозиториях кода, становятся лёгкой добычей.
- Риски цепочки поставок: Зависимость от сторонних образов виртуальных машин, контейнеров из публичных реестров, SaaS-сервисов, интегрированных в инфраструктуру.
- Атаки между арендаторами (tenant isolation attacks): Теоретическая, но существующая угроза выхода из-под контроля гипервизора или компрометации соседней виртуальной машины на одном физическом хосте.
Угрозы в локальной среде
- Физический доступ и инсайдеры: Несанкционированный доступ к серверным стойкам, установка устройств для перехвата, кража носителей информации.
- Устаревшее и непропатченное ПО: Из-за сложности процессов или боязни сломать рабочую систему обновления откладываются на месяцы и годы, оставляя известные уязвимости открытыми.
- Ограниченные возможности мониторинга и реагирования: Нехватка инструментов и экспертизы для обнаружения аномальной активности в сети, сложность масштабирования систем защиты.
- Зависимость от одного человека или небольшой команды: Уход ключевого специалиста может оставить систему без должного наблюдения и понимания её тонкостей.
Влияние российского регуляторного поля
В России выбор между облаком и локальным хранением данных часто определяется не только техническими соображениями, но и требованиями регуляторов, прежде всего Федерального закона № 152-ФЗ «О персональных данных» и актов ФСТЭК России.
Персональные данные и 152-ФЗ
Закон требует, чтобы оператор персональных данных обеспечивал их безопасность, в том числе при обработке с использованием средств автоматизации. Использование облачных провайдеров для обработки ПДн возможно, но оператор остаётся ответственным лицом перед законом. Это означает, что он должен:
- Убедиться, что провайдер (обработчик) соответствует требованиям закона и имеет необходимые организационно-распорядительные документы.
- Заключить с ним регламентированный договор, где прописаны цели, условия обработки и обязанности по защите данных.
- Обеспечить, что данные хранятся на территории России (требование о локализации). Многие российские облачные провайдеры изначально строят инфраструктуру с учётом этого требования.
регуляторная нагрузка не исчезает при переходе в облако, а трансформируется в задачу управления договорными отношениями и проверок соответствия.
Требования ФСТЭК и аттестация
Для государственных информационных систем (ГИС) и систем, обрабатывающих критически важную информацию, требования жёстче. ФСТЭК России устанавливает порядок и методы защиты информации. Вопрос использования облачных сервисов для таких систем долгое время был дискуссионным. Сейчас подход формализуется.
Ключевой момент — необходимость аттестации объекта информатизации (системы) на соответствие требованиям по безопасности. В облачной модели возникает сложность: объект информатизации не находится полностью под физическим контролем заказчика. Решение возможно при выполнении ряда условий:
- Использование облачной инфраструктуры, развёрнутой на территории России и принадлежащей юридическому лицу, подконтрольному российскому законодательству.
- Обеспечение прозрачности и возможности для заказчика проводить необходимые проверки, аудиты, включая контроль конфигураций и мер защиты.
- Чёткое документальное закрепление зон ответственности, которое не противоречит модели ФСТЭК.
На практике для систем высокого уровня защищённости чаще выбирается либо полностью локальное развёртывание, либо использование изолированных частных облачных сегментов («облако на территории заказчика»), которые по факту ближе к modern on-premise.
Экономика безопасности: где расходы скрыты
Затраты на безопасность часто неочевидны при сравнении прайс. Оплата ежемесячной подписки за облачные ресурсы выглядит прозрачной, но стоимость обеспечения их безопасности может быть высокой.
| Статья затрат | Облако (IaaS/PaaS) | On-premise |
|---|---|---|
| Экспертиза персонала | Требуются специалисты по облачной безопасности, знающие специфические сервисы и инструменты провайдера (например, IAM, CloudTrail-аналоги, защиту контейнеров). Дефицит таких кадров высок. | Требуются классические специалисты по сетевой безопасности, SOC, администрированию ОС и СУБД. Спрос также стабильно высок. |
| Инструменты мониторинга и защиты | Многие базовые функции (сетевой фаервол, WAF, DDoS-защита) предлагаются как встроенные или дополнительные сервисы провайдера, что снижает CAPEX. Однако для продвинутого мониторинга (UEBA, анализ поведения) часто нужны сторонние или кастомные решения, которые также нужно интегрировать и оплачивать. | Необходима закупка всего стека аппаратных и программных решений «с нуля» (NGFW, SIEM, EDR, шлюзы), что означает крупные первоначальные инвестиции (CAPEX) и плату за лицензии. |
| Операционные расходы (OPEX) | Постоянные затраты на облачные сервисы безопасности, квалифицированный персонал, аудит конфигураций. | Постоянные затраты на электроэнергию, охлаждение, обновление и ремонт «железа», лицензионные продления, зарплату персонала. |
| Расходы при инциденте | Могут быть связаны с экстренным масштабированием ресурсов для отражения атаки, услугами Incident Response от провайдера или сторонних фирм. Риск штрафов за потерю данных, если это нарушает соглашение об уровне услуг (SLA) или закон. | Прямые затраты на восстановление инфраструктуры (закупка нового оборудования), оплату работы внутренней или приглашённой IR-
команды. Юридические издержки и штрафы от регуляторов, если инцидент привёл к нарушению требований. |
облако не отменяет расходов на безопасность, а меняет их структуру с капитальных на операционные и требует другой, часто более узкой и дорогой, экспертизы.
Как делать выбор: практические шаги
Вместо поиска универсального ответа стоит следовать структурированному подходу.
- Определите, что именно вы защищаете. Классифицируйте данные: персональные данные, коммерческая тайна, критическая информация для бизнеса. Поймите регуляторные требования для каждого типа.
- Честно оцените свои внутренние компетенции. Есть ли в штате или есть возможность нанять команду, способную круглосуточно обеспечивать физическую безопасность, своевременное обновление и мониторинг локального парка? Или же экспертиза команды лежит в области разработки и эксплуатации приложений, и безопасность инфраструктуры логичнее делегировать?
- Проанализируйте угрозы. Составьте модель угроз для вашего сценария. Где вероятнее атака: через уязвимость в публичном API облачного сервиса или через фишинг против системного администратора с доступом в серверную?
- Рассмотрите гибридные и частные модели. «Облако» — не монолит. Это могут быть публичные сервисы, частное облако на арендованной инфраструктуре или полностью изолированный приватный кластер на вашем оборудовании (on-premise cloud). Последний вариант, по сути, переносит облачную операционную модель в вашу серверную, давая автоматизацию и единообразие, но оставляя физический контроль.
- Проверьте совместимость с регуляторами. Для работы с ПДн или в госсекторе заранее изучите позицию конкретного облачного провайдера относительно 152-ФЗ и требований ФСТЭК. Запросите типовые договоры и заключения соответствия. Для локального хранения подготовьтесь к затратам времени и ресурсов на проведение аттестации силами аккредитованной организации.
Итог: безопасность как результат процессов, а не местоположения
Данные не становятся безопасными от того, что лежат на сервере в подвале вашего офиса или в дата-центре провайдера класса Tier III. Они становятся безопасными, когда:
- Чётко определены, классифицированы и учтены.
- Доступ к ним контролируется на основе принципа наименьших привилегий, независимо от среды.
- Их целостность и конфиденциальность защищены криптографией там, где это необходимо.
- Все действия с ними логируются, а аномалии выявляются системами мониторинга.
- Процессы их обработки и защиты регулярно аудитируются и улучшаются.
Эти процессы можно выстроить как в собственном ЦОДе, так и в виртуальной приватной сети у облачного провайдера. Сложность в том, что в облаке часть инструментов и возможностей вам предоставляется «из коробки», но требование глубокого понимания их работы и правильной настройки только возрастает. На локальной стороне вам придётся создавать эти инструменты и процессы с нуля, что требует иного типа ресурсов.
Поэтому ответ на вопрос «где безопаснее хранить данные?» всегда будет контекстным. Он звучит так: «безопаснее там, где вы обладаете достаточными компетенциями, ресурсами и вниманием, чтобы реализовать и поддерживать полноценный цикл управления информационной безопасностью, соответствующий ценности ваших данных и уровню регуляторных требований». Всё остальное — детали реализации этого цикла.