Кибербезопасность в эпоху облаков: защита периметра и данных, когда граница стёрлась

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

Куда исчез периметр

Облачные технологии стёрли границу между «внутри» и «снаружи». Раньше охраняли сеть, теперь охраняют личность и информацию: злоумышленнику больше не нужно пробивать firewall — достаточно угнать пароль менеджера. Отсюда главный сдвиг последних лет — модель нулевого доверия (Zero Trust — принцип «никому не верь по умолчанию», даже своим сотрудникам и сервисам). Каждый запрос к системе заново подтверждает: кто это, с какого устройства, откуда и зачем.

Выглядит это буднично. Сотрудник заходит в CRM — и получает отказ, потому что вошёл с незнакомого ноутбука. Сервис запрашивает данные из соседнего сегмента — и должен предъявить токен, а не просто «находиться в той же сети». Многофакторная аутентификация (второй фактор помимо пароля — код, приложение или физический ключ) давно стала гигиеническим минимумом: по отраслевой статистике она отсекает львиную долю попыток угона учётных записей.

Данные в облаке: шифровать и не терять ключи

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

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

Открытые бакеты: утечка без единого хакера

Бакет — «папка» в облачном хранилище файлов. Печальная закономерность отрасли: те, кто ищет, как защитить данные в облаке от утечки, обычно делают это уже после инцидента. А начинается почти каждый случай одинаково — настройки доступа выставили «на быстро», папка стала публичной, содержимое ушло в открытый доступ. Автоматические сканеры находят подобные хранилища за считаные часы.

Типичные промахи, которые дорого обходятся:

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

Периметр по-новому: экраны, сегменты, фильтры

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

Рядом стоит защита от DDoS-атак в облаке (DDoS — когда сервер «заваливают» миллионами запросов, и он перестаёт отвечать живым посетителям): трафик фильтруется на мощностях провайдера, до инфраструктуры доходит уже чистый поток. Микросегментация сети в облаке — деление её на мелкие изолированные участки — не даёт взломанному контейнеру добраться до соседних систем: вместо одной большой квартиры получается множество комнат с отдельными замками. А CASB (посредник, который видит, какими сторонними облачными сервисами пользуются сотрудники) закрывает слепую зону «теневых ИТ» — когда отдел маркетинга сливает клиентскую базу в непонятный онлайн-сервис мимо ИТ-службы.

Базовый набор, без которого всё остальное бессмысленно

  1. Резервное копирование в облако по правилу 3-2-1: три копии, на двух разных типах носителей, одна — вне основной площадки. Копию делают неизменяемой даже для администратора — иначе шифровальщики зашифруют и её.
  2. Управление доступом (IAM — система, раздающая «ключи» людям и программам) с регулярной ревизией: сотрудник уволен — отозваны все доступы, включая старые API-токены.
  3. Своевременные обновления: половина взломов эксплуатирует уязвимости, для которых патчи вышли месяцами раньше.
  4. Централизованные журналы: кто, когда и что трогал в системе.
  5. План реагирования на инцидент, написанный до инцидента, а не во время него.

Люди, процессы и круглосуточное дежурство

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

Крупные команды держат SOC — центр мониторинга инцидентов, дежурная смена которого круглосуточно читает логи и ловит странности: вход из двух стран за пять минут, массовая выгрузка базы в три ночи. У кого своего дежурства нет — те подключают внешние службы мониторинга, отрасль давно это отладила. Полезно и репетировать: отработка сценария «база скомпрометирована» превращает панику в чек-лист, а в реальный день инцидента экономит те часы, которых всегда не хватает.

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

Оцените статью