Октябрь каждый год дает нам официальный повод вернуться к основам безопасности. Но основы не должны быть сезонной темой, потому что именно проблемы с ними приводят к взломам каждый месяц.

Все это применимо независимо от того, используете ли вы ИИ. Это самый быстрый способ организовать защиту, потому что злоумышленники уже используют его. Если ваша организация медленнее внедряет ИИ, этот список все равно остается актуальным. Мы обнаружили, что 50% инструментов ИИ работают скрытно (это так называемый теневой ИИ). Рабочие нагрузки ИИ идентифицируются во время выполнения, работают в облаке и защищаются так же, как и все остальное.

Данные доказывают: базовые пробелы по-прежнему вызывают взломы

Прежде чем углубляться в вопрос «что делать», давайте начнем с обоснования того, почему нам нужно это делать.

Verizon’s 2026 Data Breach Investigations Report (DBIR) был составлен на основе более чем 22 000 подтвержденных взломов. Вторжение в систему и социальная инженерия в совокупности составляют 78% взломов. Кроме того, эксплуатация уязвимостей обошла компрометацию учетных данных в качестве основного вектора первоначального доступа, появившись в 31% взломов — это рост на 55% по сравнению с прошлым годом.

Кроме того, человеческий фактор по-прежнему фигурирует в 62% взломов, а участие третьих сторон и цепочек поставок подскочило на 60% по сравнению с прошлым годом, составив 48% от всех взломов. Виной тому отсутствие MFA, неротируемые или скомпрометированные учетные данные и отсутствие реализации принципа наименьших привилегий.

Идентичность — это общая нить. Google Cloud's Threat Horizons Report H1 2026 обнаружил скомпрометированные идентификационные данные в 83% вторжений в облачные и SaaS-среды во второй половине 2025 года. В отчете Sysdig 2026 Cloud-Native Security and Usage Report говорится, что 97,2% управляемых идентификаторов в рамках CSP принадлежат машинам. Отчет за 2024 год показал, что использовалось только два процента предоставленных разрешений, что оставляет 98% предоставленного доступа открытым для злоумышленника.

Проигнорируйте основы, и это будет стоить вам дорого

Отчет IBM 2026 Cost of a Data Breach Report оценивает средний мировой ущерб чуть менее чем в 5 миллионов долларов, что на 12% больше по сравнению с прошлым годом. Средний показатель по США составляет внушительные 11,5 миллионов долларов. Если вам интересно, почему эта цифра может быть такой высокой, то в некоторых случаях, например при DDoS-атаке или редкой разрушительной атаке программы-вымогателя, сюда включается время простоя. Согласно ITIC’s 2024 Hourly Cost of Downtime Survey, для крупных предприятий один час простоя стоит более 100 000 долларов, а в таких отраслях, как финансы, здравоохранение, СМИ и коммуникации, эта цифра значительно превышает 5 миллионов долларов в час. Это означает, что критический сбой в обслуживании, длящийся в течение среднего рабочего дня, может стоить бизнесу десятки миллионов долларов во время восстановления.

Все необходимые основы безопасности в одном месте

Если вы еще не поняли, закономерность во всех этих отчетах одна и та же: основы не выполняются последовательно (если выполняются вообще), и именно эти пробелы — причина, по которой злоумышленники продолжают проникать внутрь. То, что следует ниже, не является новым или уникальным, и в этом вся суть. Вот полный список:

Управление идентификацией и доступом

Внедрите MFA для каждой учетной записи пользователя с повышенными привилегиями, особенно для облачного администратора и root-пользователя. Не должно быть никаких исключений для «только этого одного администратора».
Предоставляйте сервисным учетным записям краткосрочные учетные данные и идентификаторы рабочих нагрузок вместо долгосрочных ключей.
Применяйте концепцию наименьших привилегий к каждой человеческой и нечеловеческой идентификации. Чрезмерные разрешения для сервисных учетных записей и CI/CD-конвейеров так же опасны, если не опаснее, чем чрезмерные разрешения для учетных записей людей, поскольку они все чаще становятся целями злоумышленников.
Проводите аудит и отзывайте доступ по запланированному графику, а не по прихоти. Временный доступ, необходимый для миграции, расследования инцидента или маркетингового проекта, должен истекать автоматически, а не висеть в течение шести месяцев. (Серьезно рассмотрите возможность полной автоматизации процесса проверки доступа.)
Ротируйте учетные данные и ключи API по фиксированному графику, а также немедленно после любых кадровых изменений или прекращения использования сторонних сервисов. (Вы также можете автоматизировать это!)
Отслеживайте аномальное поведение идентификаторов во время выполнения, а не только во время первоначального входа в систему. Валидные учетные данные, выполняющие действия, которые они никогда раньше не совершали, из места, откуда они никогда раньше не входили, или в странное время суток, — это все еще сигнал.

Управление уязвимостями и исправлениями

Устраняйте уязвимости на основе возможности эксплуатации и подверженности риску, а не только по оценке CVSS. Уязвимость средней степени тяжести на рабочей нагрузке, выходящей в интернет, будет использована раньше, чем критическая, спрятанная на три уровня вглубь.
Сократите разрыв в исправлении уязвимостей. Только 26% критических уязвимостей из каталога KEV CISA были полностью устранены в прошлом году. Отслеживайте время до устранения как KPI, а не как сноску.
Сканируйте образы и зависимости до того, как они попадут в продакшн, и постоянно сканируйте работающие рабочие нагрузки, потому что чистый образ сегодня может иметь новую CVE завтра.
Поддерживайте точный инвентарь программного обеспечения (SBOM), чтобы знать, что на самом деле работает, когда появляется новая CVE. Вы не можете исправить то, что не видите.

Конфигурация облака и Kubernetes

Проводите непрерывные проверки конфигурации для каждой учетной записи на всем вашем предприятии. Конфигурация может меняться между статическими сканированиями, поэтому сканируйте постоянно.
Блокируйте хранилища по умолчанию и открывайте их только в случае необходимости. Публичные бакеты и открытые блобы — это распространенные, предотвратимые пути воздействия в облачном провайдере.
Ограничьте сетевое воздействие. Закройте неиспользуемые порты, ужесточите группы безопасности и не позволяйте разрешающим правилам брандмауэра стать стандартом по умолчанию, потому что кто-то спешил. Добавьте сетевые политики в Kubernetes, поскольку трафик подов открыт между пространствами имен по умолчанию.
Ограничьте RBAC в Kubernetes принципом наименьших привилегий. Используйте роли с областью действия пространства имен (namespace-scoped Roles) вместо ролей для всего кластера, где это возможно. Относитесь к каждой привязке cluster-admin как к исключению, у которого должен быть владелец, потому что cluster-admin, раздаваемый без ограничений, — это проблема латерального перемещения, которая рано или поздно случится.
Отключите или жестко ограничьте повышение привилегий подов, монтирование hostPath и привилегированные контейнеры, если для этого нет законных оснований. Если они есть, отслеживайте их поведение на предмет аномального использования.

Обнаружение и реагирование во время выполнения

Разверните датчики времени выполнения на каждой рабочей нагрузке, потому что статическое сканирование на этапе сборки пропускает то, что происходит после развертывания.
Обнаруживайте отклонения в тот момент, когда они происходят. Контейнер, который начинает запускать бинарный файл, отсутствовавший в исходном образе, — это тревожный сигнал.
Сопоставление обнаружений с MITRE ATT&CK помогает вашей команде понять, какую технику они видят и на что реагируют, а не просто констатировать: «что-то сработало, что произошло?»
Настраивайте оповещения на основе фактических базовых показателей поведения вашей среды. Усталость от оповещений снизит скорость сортировки, а ложные срабатывания тратят время, которого у вас нет.
Имейте протестированные действия по локализации, готовые к применению при срабатывании высокоточных оповещений. Обнаружение без плана реагирования просто документирует взлом по мере его совершения, и вы будете наблюдать, как он происходит.

Логирование, мониторинг и видимость

Централизуйте логи на уровнях облака, контейнеров и идентификации. Фрагментированные логи означают фрагментированные расследования, а это означает низкую скорость.
Включите аудит логирования везде и убедитесь, что он действительно фиксирует то, что вы ожидаете.
Храните логи достаточно долго для проведения расследования. Среднее время обнаружения и локализации составляет 247 days; 30-дневное окно хранения данных покрывает только 12% от этого времени.
Сопоставляйте сигналы на разных уровнях. Аномалия IAM плюс аномалия среды выполнения для одной и той же рабочей нагрузки — это совсем другое дело, чем любая из них по отдельности.

Управление цепочкой поставок и CI/CD

Сканируйте сторонние зависимости и базовые образы контейнеров непрерывно, а не только при импорте.
Относитесь к учетным данным CI/CD и правам доступа в конвейере с таким же вниманием, как и к продакшен-доступу. Скомпрометированные конвейеры ведут к компрометации продакшена.
Проверяйте и отслеживайте доступ вендоров и партнеров. Сторонние компании теперь играют роль в 48% утечек данных.
Подписывайте и проверяйте артефакты в конвейере, чтобы в среду выполнения не попадало ничего непроверенного.

Управление и контроль (Governance)

Назначьте четких ответственных за каждый базовый пункт из этого списка. Останавливаться на утверждении «безопасность — это ответственность каждого» — значит допускать упущения.
Запишите, что одобрено (привет, ИИ-инструменты). Установите политику в отношении одобренных инструментов, данных, которые можно в них передавать, и порядка утверждения новых. Из организаций, столкнувшихся с инцидентами, связанными с ИИ, 68% не имели политики управления ИИ.
Применяйте созданные вами политики на практике. Запрет без контроля использования — это лишь рекомендация.
При предоставлении исключений назначайте ответственного и срок действия.
Опирайтесь на устоявшиеся фреймворки. Например, используйте NIST AI RMF для оценки рисков ИИ, а OWASP Top 10 для приложений с LLM — в качестве дополнительного чек-листа угроз.
Регулярно пересматривайте эти основы, а не только каждый октябрь.

Управление людьми и процессами

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

Ваш главный вывод

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

Месяц осведомленности о кибербезопасности — хорошее напоминание. Главное, чтобы оно не было единственным.