В прошлом году большинство компаний столкнулись с инцидентами в области облачной безопасности. Причина — не изощренные хакеры, а элементарные ошибки: неправильные настройки стали причиной почти каждого взлома. — csoonline.com
В прошлом году большинство компаний столкнулись с инцидентами в области облачной безопасности. Что примечательно — за этими событиями стояли не изощренные киберпреступники. Вместо этого, дверь открыли элементарные ошибки. Согласно отчету Cloud Security Alliance за 2024 год о рисках в облачных вычислениях, неправильные настройки стали причиной практически каждого взлома. Всего один неверный переключатель — и этого оказалось достаточно.
Представьте себе шкаф, оставленный нараспашку, с ключами на ручке. Не каждый вход требует дополнительных проверок — некоторые пропускаются полностью. Барьеры на входах часто пропускают свободно, словно развернутые коврики. Код порой хранит пароли на виду, обнаженные из-за недосмотра. Ничего подобного не происходит раз в сто лет. Именно так утекают состояния, рушатся репутации, данные попадают в дикую среду, а команды неделями пытаются наверстать упущенное.
Далеко от изысканного цифрового воровства, этот беспорядок живет в неосмотренных углах. Каждый пробел подпитывает проблему — нет надзора, только открытые двери.
Масштаб кризиса
Что бросается в глаза в первую очередь? Масштаб кажется нереальным. Согласно отчету IBM о расходах на утечки данных за 2025 год, утечки данных в мире теперь обходятся в среднем в 4,44 миллиона долларов. При этом в Соединенных Штатах каждое событие стоит 10,22 миллиона. Однако за этими шокирующими цифрами скрывается нечто более глубокое, что трудно уловить только статистикой.
Вспомните инцидент со Snowflake в 2024 году — десятки компаний оказались втянуты, затронуты полмиллиарда жизней. AT&T потеряла 109 миллионов клиентских файлов. Затем Ticketmaster, где почти 560 миллионов записей исчезли в руках хакеров. Даже Santander раскрыла данные 190 миллионов человек.
Но как им удалось прорваться? Достаточно было войти в систему. Реальные учетные данные дали им доступ к профилям, лишенным дополнительных мер защиты входа.
Примечательно, что старые проблемы по-прежнему наносят вред. Неисправный веб-фаервол открыл дверь для инцидента Capital One в 2019 году. Этот промах затронул более 100 миллионов клиентов, за которым последовал штраф в 80 миллионов долларов, а затем еще 190 миллионов, выплаченных позже. Почти два года Football Australia держала активные API-ключи видимыми в коде своего сайта — без всякой защиты. В результате 127 хранилищ данных стали доступны. Toyota девять, а может, и десять лет хранила клиентские файлы в общедоступной облачной конфигурации. За это время утекло около 260 000 учетных записей.
Более глубокий анализ рисует реальную картину:
- Большинство ошибок настройки облака — 8 из 10 — происходят из-за человеческого фактора, а не из-за сбоев в коде.
- Каждая третья облачная конфигурация остается пустой, без какого-либо надзора. Треть онлайн-хранилищ не получает никакого внимания от мониторинговых систем.
- Почти каждое двухсотое хранилище в облаке Amazon открыто, согласно отчету мониторинговой фирмы Datadog за 2024 год. Их выводы подчеркивают, насколько распространены слабые настройки в веб-ориентированных файловых системах.
- В 50% случаев устранение утечек занимает около девяноста четырех дней. То, что происходит после обнаружения, затягивается почти на три месяца.
Странно, как часто это случается. Кража учетных данных не должна приводить к ущербу так быстро — однако здесь у хакеров было более трех месяцев просто на ожидание. Инцидент со Snowflake опирался на старые данные, собранные много лет назад и не тронутые с 2020 года. Новые пароли не выпускались, дополнительные шаги входа не добавлялись, и никаких проверок странной активности не проводилось. Шаблон повторяется — беспорядочный и игнорируемый.
Почему это продолжает происходить
Странно, что нечто столь очевидное остается нерешенным — неправильные настройки сохраняются, несмотря на легкость их обнаружения. По итогам бесед с несколькими CISO и экспертами по облачным технологиям, каждый раз всплывают схожие причины. Одно тянет за собой другое, и появляются закономерности.
- Представьте, как пытаться уследить за всем — современные облачные среды забиты бесконечным количеством элементов, работающих одновременно. Жонглируйте этим: ресурсы распределены по бесчисленным учетным записям, разбросанным по регионам и платформам. Подумайте об AWS — с ее более чем 200 инструментами, каждый из которых загружен настраиваемыми параметрами. Затем есть Azure, где число предложений превышает шестьсот. Найти одного человека, который мог бы справиться со всем этим вручную — сохраняя точность — невозможно. Цифры просто не позволяют этого в такой ситуации.
- Люди сейчас работают быстро. Пока разработчики постоянно выпускают обновления, старые шаги безопасности — предназначенные для ежемесячных развертываний — мешают. То, что когда-то работало, теперь тормозит. Сотрудники команд обходят эти проблемы, обещая вернуться позже, чтобы разобраться. Правда в том, что этот будущий момент ускользает каждый раз.
- С глаз долой — из сердца вон — так часто и бывает. Скрытые технологии появляются в каждом отделе. Сотрудники настраивают онлайн-инструменты без чьего-либо разрешения, минуя проверки. Когда кодеры создают тестовые среды, они иногда оставляют их работать. Эти незамеченные места? Идеальные гнезда для ошибок. В конце концов, что-то дает сбой — и редко это первым ловит дружественный сотрудник.
- Владение также приносит проблемы. Когда облачные компании управляют оборудованием, пользователи по-прежнему должны самостоятельно обеспечивать безопасность настроек и данных. Звучит просто, пока не попробуешь. Вспомните инцидент со Snowflake. Люди предполагали, что Snowflake поймает опасности до их распространения. Что случилось у Snowflake? Клиенты должны были включить MFA. Но как-то каждая команда предполагала, что кто-то другой уже позаботился об этом. Поскольку никто не проверял завершение настройки, хакеры входили беспрепятственно.
Итак, сложность наносит сильный удар, когда к ней добавляется скорость. Слепые зоны растут там, где должна быть ясность. Нечеткие границы смешиваются с нехваткой квалифицированных кадров. Ошибки возвращаются — неудивительно.
Путь вперед
Хорошие новости? Эта ситуация не безнадежна. В то время как уязвимости нулевого дня оставляют вас в бездействии в ожидании обновлений, неправильные настройки — не таковы. Они находятся в ваших руках. Сила для решения проблемы принадлежит вам.
Быстрые победы:
- Включите многофакторную аутентификацию везде, где это возможно. Серьезно. После инцидента со Snowflake следователи выяснили — почти все взломы можно было остановить с помощью MFA. Относитесь к этому как к правилу без исключений. Проверьте каждый облачный сервис в течение следующего месяца. Везде, где отсутствует этот дополнительный шаг входа, внедрите его.
- Начните проверять каждый S3-бакет, затем переходите к Azure Blobs, а затем к хранилищам Google Cloud Storage. Убедитесь, что ни один из них не находится в открытом доступе без необходимости. Включите блокировку публичного доступа прямо на корневом уровне учетной записи — это обеспечит защиту. Включите уведомления, чтобы предупреждение прилетало вам на почту всякий раз, когда что-то проникает в публичное пространство, независимо от того, как оно туда попало.
- Начните с логов. Без четких записей обнаружение проблем превращается в угадывание. Когда что-то идет не так, ответы приходят из записей, сделанных ранее. Включите AWS CloudTrail для каждого входа. Включите также Azure Activity Log — никаких пробелов не допускается. GCP Cloud Audit Logs должны быть активированы точно так же. Каждая система должна регистрировать предпринятые действия. Не пропускайте ничего. Не упускайте ничего.
- Возможно, стоит также взглянуть на настройки вашей сети. Правила, разрешающие все через 0.0.0.0/0? Лучше их удалить. Доступ администратора должен осуществляться только с известных и ожидаемых вами IP-адресов.
Стратегический ход:
- Инструменты управления состоянием облачной безопасности (Cloud Security Posture Management, CSPM) помогают быстро выявлять проблемы. Постоянно отслеживая, они обнаруживают ошибки в настройке систем. Одно исследование 2025 года показало, что фирмы, использующие эти инструменты, сократили время экспозиции с недель до менее чем двух дней. Ошибки задерживаются гораздо меньше. Меньше возможностей для тех, кто пытается взломать систему.
- Начните относиться к инфраструктуре как к коду (Infrastructure as Code) как к настоящему коду — с реальными рисками. Прежде чем что-либо попадет в облако, проверьте каждый файл Terraform или конфигурацию CloudFormation, которые у вас есть. Ошибки, найденные на раннем этапе, избавляют от хаоса в работающих системах позже. Встраивайте проверки безопасности прямо в процесс создания, шаг за шагом. Таким образом, ошибочные конфигурации никогда не просочатся туда, где они работают.
- При правильном подходе принцип «ничего не доверять по умолчанию» работает в вашу пользу. Неправильно настроенный параметр может проскочить, но ущерб останется локализованным. Полагайтесь на минимальные разрешения вместо широких, разделяйте системы на слои, и каждая проверка будет проводиться заново, даже если запрос кажется знакомым. Подтверждайте каждую точку входа без исключений.
И последнее — вложите силы в свою команду. Каждый, кто работает с облачными системами, должен пройти реальное практическое обучение по безопасности. Побуждайте их к получению официальных сертификатов. Помогите специалистам по безопасности понять работу разработки, в то время как разработчики узнают о потребностях безопасности — баланс способствует лучшему диалогу.
У вас здесь много контроля. Воспользуйтесь им.
Вопрос культуры
Большинство проблем не исчезнут только из-за добавления инструментов. Правильное обеспечение облачной безопасности требует усилий со всех сторон — специалисты по безопасности не могут нести это в одиночку. Когда кодеры выбирают короткие пути, риски растут — эта истина должна быть усвоена с самого начала. Обучение системных администраторов должно соответствовать облачному миру, а не быть переработанными советами из старых систем. Поддержка со стороны высшего руководства проявляется лучше всего, когда меняются бюджеты и решения включают проверки рисков.
Не все должно двигаться быстро. Замедление может означать правильное выполнение работы, особенно когда речь идет о безопасности. Это не провал — так растут надежные системы. Умные группы находят способы вплести защиту в инструменты, чтобы прогресс продолжался.
Ставки реальны
В этой сфере переход в облако не просто меняет технологии — он переопределяет скорость роста компаний и то, что они могут пробовать. Правильное обеспечение безопасности открывает двери, которых большинство никогда не достигает. Однако, если допустить промах, риск поглотит все. Скорость без безопасности превращается в опасность.
Мало кто думал, что слабые шаги входа могут так быстро привести к краху. Промах Snowflake обнажил более 165 групп, затронув полмиллиарда жизней. Счета растут — вероятно, на сотни миллионов — пополняемые выкупами, штрафами, судебными тяжбами и разрушенным доверием. Слабые щиты открыли двери; отсутствие дополнительных проверок входа усугубило ситуацию.
Этот момент реален, а не отдаленная угроза. То, что происходит сегодня, сильно бьет, когда облачная безопасность отходит на второй план. Киберпреступники неуклонно смещают фокус на онлайн-инфраструктуру. Правила ужесточаются в разных регионах; ярок пример: недавний приказ CISA побуждает государственные органы твердо обеспечивать безопасность цифровых сред.
Реалистичный оптимизм
Большинство проблем облачной безопасности возникают из-за ошибок в настройке. Хорошая новость в том, что их проще решить, чем другие проблемы. Вместо того чтобы надеяться на лучшее, запускайте проверки с помощью программного обеспечения CSPM. Политики лучше соблюдаются, когда они вписаны непосредственно в код системы. Люди обращают внимание, если понимают, что поставлено на карту. Когда безопасность становится обычной темой для обсуждения, меньше ошибок проскальзывает. Риск снижается, как только привычки смещаются в сторону осторожности.
Инструменты существуют. Четкие методы доказаны. Случай за случаем показывает, что действительно меняет ситуацию. Прямо сейчас препятствие находится внутри — заставить всех действовать сообща. Сначала нужно признать факты. Затем последует финансирование. И только потом придет понимание: то, как вы настраиваете системы, определяет все в облачной безопасности.
Вот правда: неправильные настройки провоцируют каждый облачный взлом. Настройте все правильно, и безопасность последует. Ошибки, стоящие миллионы? Полностью предотвратимы.
Эта статья опубликована в рамках Сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Ashish Mishra