Идентификаторы, не являющиеся человеческими данными, — источник утечек информации: почему токены и учетные записи сервисов постоянно оказываются под угрозой.

/Технологии/ К

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

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

Это история о «незаметном взломе». Многие компрометации начинаются не с эксплойта или громкого вредоносного ПО. Они начинаются с токена, который проходит проверку подлинности — поэтому всё выглядит нормально — пока вы не поймёте, что его использует не тот субъект.

Что такое «нечеловеческие идентичности» (проще говоря)?

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

  • Ключи доступа к облаку и токены сеанса
  • служебные учетные записи и идентификаторы рабочих нагрузок
  • Учетные данные CI/CD, используемые конвейерами сборки.
  • Токены для SaaS-инструментов (GitHub, GitLab, Slack, платформы мониторинга)
  • API-ключи для сторонних сервисов (платежные системы, почтовые сервисы, API для моделей ИИ)

Важное отличие от входа в систему человеком заключается в том, что системы NHI обычно:

  • работать непрерывно
  • встроены в код или конфигурацию
  • и часто не используют MFA

Это делает их привлекательными.

Если злоумышленник получит рабочий токен, ему не нужно будет «взламывать систему». Он просто пройдет аутентификацию.

Почему ситуация сейчас ухудшается

Три тенденции переводят немедицинские страховые полисы из разряда «важных» в разряд «доминирующих рисков»:

1) Цепочки поставок программного обеспечения стали масштабнее, чем когда-либо.

Современные приложения создаются из:

  • контейнеры
  • зависимости с открытым исходным кодом
  • инфраструктура как код
  • десятки интеграций SaaS

Каждая интеграция добавляет еще одни учетные данные.

2) Автоматизация повсюду

Организации хотят:

  • более быстрые развертывания
  • инфраструктура самообслуживания
  • эфемерные среды

Автоматизация — это хорошо, но она осуществляется с помощью учетных записей, обладающих привилегиями.

3) Учетные данные сохраняются дольше, чем люди, которые их создали.

Люди меняют роли и уходят.

Но токен в репозитории или контейнере может:

  • продолжаются месяцами или годами
  • копировать в новые сборки
  • и остаются актуальными ещё долго после того, как кто-либо вспомнит об их существовании.

Таким образом, поверхность атаки незаметно расширяется.

Как в реальной жизни утекают секреты (не всегда это происходит из-за того, что «кто-то спрятал ключ»).

Стереотипный образ — это разработчик, который вносит изменения в код.AWS_SECRET_ACCESS_KEYна GitHub.

Такое всё ещё случается. Но многие утечки менее очевидны:

  • токены, встроенные в слои контейнера
  • Файлы конфигурации копируются в образы во время сборки.
  • отладочные журналы, содержащие секреты
  • «Временные» ключи, которыми обмениваются в чате, а затем вставляют в код.
  • Переменные CI, выводимые неправильно настроенными конвейерами.

А образы контейнеров особенно опасны, потому что:

  • они зеркально отображаются
  • они кэшируются
  • Они копируются между командами.

Даже если вы удалите ключ из репозитория, он может остаться в старых слоях образа.

Почему утечки токенов опаснее многих эксплойтов

Эксплойты создают много шума. Они часто вызывают срабатывание оповещений.

Утекшие токены не содержат никаких утечек. Зачастую они выглядят как обычное использование:

  • успешная аутентификация
  • корректные вызовы API
  • легитимные конечные точки

Это меняет суть проблемы защитника.

Вместо обнаружения «злоумышленника» вам необходимо обнаружить:

  • неожиданныйглавныйиспользуя действительные учетные данные
  • из необычных мест
  • в необычное время
  • совершение необычных действий

Именно поэтому немедицинские идентификационные данные представляют собой пробел в системе выявления нарушений здоровья для многих организаций.

Проблема привилегий: токены зачастую слишком сильны.

Многие секреты создаются как бы для того, чтобы "заставить всё работать":

  • широкие облачные разрешения
  • Доступ к API на уровне администратора
  • долговечные ключи

А как только система заработает, люди не захотят к ней прикасаться.

Это создает опасную асимметрию:

  • В учетной записи, созданной человеком, могут быть предусмотрены многофакторная аутентификация и мониторинг.
  • Идентификатор машины может иметь широкий доступ и не подвергаться тщательному контролю.

Когда происходит утечка информации о личности машины, радиус взрыва может быть больше.

Как выглядит эффективная стратегия национального медицинского страхования (конкретные примеры)

Это решаемо, но только если рассматривать немедицинские данные как первоклассные активы безопасности.

1) Предпочтение отдается сертификатам с кратковременным сроком действия.

По возможности:

  • использовать временные учетные данные сессии
  • часто меняйте токены
  • Избегайте ключей с пометкой «срок действия не ограничен».

Кратковременные токены снижают отдачу от утечек информации.

2) Замените статические ключи идентификаторами рабочих нагрузок там, где это возможно.

В современных облачных средах аутентификацию рабочих нагрузок часто можно осуществлять следующим образом:

  • идентификатор экземпляра
  • федерация OIDC
  • управляемая идентификация

Это снижает необходимость хранения статических ключей.

3) Строго разделяйте рабочие среды.

Распространенная ошибка — использование одного и того же лексемы во всех случаях:

  • дев
  • постановка
  • производство

Токены должны иметь область действия в рамках среды.

Если образ для разработчиков попадёт в сеть, это не должно разблокировать доступ к продакшену.

4) Инвентаризация и право собственности

Каждый значимый токен должен обладать следующими характеристиками:

  • владелец
  • цель
  • ожидаемая модель использования

Если у токена нет владельца, это технический долг, который может перерасти в инцидент.

5) Отслеживайте поведение медицинских работников так же, как вы отслеживаете поведение людей.

К числу хороших сигналов относятся:

  • Невозможные путешествия / необычные географические регионы
  • необычные последовательности вызовов API
  • всплески доступа к данным
  • предоставлены новые разрешения
  • созданы новые токены

Цель состоит не в идеальном обнаружении, а в раннем выявлении.

6) Рассматривайте CI/CD как фабрику по производству идентификационных данных с высоким риском.

Системы CI часто содержат следующие утверждения:

  • ключи развертывания
  • ключи для подписи
  • облачные учетные данные

Заблокируйте их:

  • наименьшие привилегии
  • разделились бегуны
  • Скрытая маскировка и предотвращение утечек данных из журналов.
  • строгие согласования этапов развертывания в производственной среде

Где команды обычно терпят неудачу (и как этого избежать)

«Иногда мы меняем ключи» — это не план.

Если вращение происходит вручную и причиняет боль, оно не произойдет под давлением.

Сделайте ротацию рутинной и автоматизированной.

Инструменты безопасности без надлежащего контроля превращаются в «театрализованное наблюдение».

Сканирование хранилищ на предмет секретов полезно, но этого недостаточно.

Вам также потребуется:

  • быстрая отмена
  • оповещения об использовании
  • и предотвращение в конвейерах сборки

Ловушка слоя контейнера

Если секреты когда-либо попадали в контекст сборки контейнера, предположите, что они могут находиться в:

  • старые изображения
  • кэшированные слои
  • артефакты CI

Решение заключается не только в «удалении ключа репозитория». А в следующем:

  • повернуть секрет
  • восстановить и повторно опубликовать изображения
  • По возможности очищайте кэш.

Что посмотреть дальше

Если вы хотите отслеживать, улучшаются ли показатели NHI в организациях, обратите внимание на следующие факторы:

  • внедрение кратковременной идентификации (OIDC/идентификатор рабочей нагрузки)
  • широкомасштабные программы ротации токенов
  • более строгий контроль границ CI/CD
  • В отчетах об инцидентах в качестве основной причины указывается «использование действительных учетных данных».

Также обратите внимание на инструментарий: лучшие инструменты будут переходить от «обнаружения скрытых строк» ​​к «уменьшению количества существующих статических секретов».

Экономика: почему злоумышленники любят охоту за токенами

Весы для охоты за жетонами.

Злоумышленник, укравший одни рабочие учетные данные, часто может:

  • доступ к нескольким системам (облако + система контроля версий + CI)
  • повторно использовать одну и ту же методику во многих организациях
  • и продавать доступ на торговых площадках, если они не хотят управлять ими самостоятельно.

Для специалистов по защите это означает, что угроза заключается не просто в том, что «хакер нацелен на нас». Это «машинная экономика, которая извлекает выгоду из любых повторно используемых учетных данных».

Поэтому в данном случае профилактика важнее реагирования. Если ключ никогда не существовал в статическом виде, его нельзя будет использовать позже.

Идеи для обнаружения бетона (на что следует обращать внимание)

Если вы разрабатываете системы обнаружения нежелательных явлений, сосредоточьтесь на изменениях в поведении, а не на волшебных ключевых словах.

Примеры с высоким уровнем сигнала:

  • Служебный аккаунт, используемый изновая страна/ASNЕго никогда раньше не использовали.
  • Токен, который обычно вызывает только один API, внезапно начинает перечислять ресурсы или загружать большие объемы данных.
  • Идентификатор CI, выполняющий действия вне обычного окна выпуска.
  • Секреты, используемые из интерактивных пользовательских конечных точек, когда они предназначались только для серверных нагрузок.

Даже самые простые оповещения об аномалиях могут выявить схему «скрытой кражи учетных данных» на ранней стадии.

Идеи для затвердевания бетона (малые усилия, большой рычаг)

Это практические изменения, которые большинство команд могут внести без масштабной переработки дизайна:

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

Каждое перемещение уменьшает радиус поражения взрывной волной, даже если утечка всё ещё происходит.

Простая внутренняя политика, которая предотвращает множество проблем.

Если вам нужна политика, которая заставит людей вести себя лучше, то это вот она:

  • В ноутбуках разработчиков и в контексте сборки контейнеров нет никаких секретов, пригодных для использования в производственных условиях.

Это правило приводит к таким изменениям, как:

  • идентификация рабочей нагрузки для служб
  • учетные данные для тестирования в процессе разработки
  • и явные разрешения на этапы развертывания в производственной среде.

Поначалу это раздражает, но зато перекрывает самые лёгкие пути утечки.

Итог

Идентификаторы, не являющиеся людьми, составляют основу современной автоматизации, а также являются одним из основных факторов, способствующих утечкам данных, поскольку они часто обходят защиту, созданную нами для людей.

Если вам нужен практический критерий: как только вы сможете ответить на вопросы «где хранятся наши долгосрочные токены, кому они принадлежат и как быстро мы можем их аннулировать/обменять», вы перейдете от мечтаний к реальной программе защиты.

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

Источники

Document Title
Non-human identities are a breach engine: why tokens and service accounts keep getting exposed
Leaked API keys and service-account tokens are a quiet but growing breach driver in cloud environments. Here’s how they leak, why they’re dangerous, and how to harden and detect abuse.
Title Attribute
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
Amaranth-Dragon exploiting a WinRAR flaw shows how fast espionage actors weaponize public bugs
Google teases Pixel 10A: what we know ahead of the February 18 reveal
Page Content
Non-human identities are a breach engine: why tokens and service accounts keep getting exposed
Nature
Climate
/
Technology
/ By
Admin
Non-human identities—API keys, tokens, service accounts, workload identities—are now one of the easiest ways into modern cloud environments. Not because attackers suddenly became geniuses, but because organizations increasingly run on machine-to-machine trust, and that trust is often overbroad, long-lived, and poorly monitored.
A new analysis highlighted in reporting points to a familiar pattern at huge scale: thousands of container images and repositories accidentally exposing secrets that quietly grant access to production systems. The problem isn’t just that developers sometimes make mistakes. The problem is that the default tooling and incentives make it
easy
to ship secrets and
hard
to prove you didn’t.
This is an “invisible breach” story. Many compromises won’t start with an exploit or a loud malware event. They’ll start with a token that authenticates cleanly—so everything looks normal—until you realize the wrong principal has been using it.
What “non-human identities” are (in plain terms)
A non-human identity (NHI) is any credential that lets software authenticate as a trusted actor:
cloud access keys and session tokens
service accounts and workload identities
CI/CD credentials used by build pipelines
tokens for SaaS tools (GitHub, GitLab, Slack, monitoring platforms)
API keys for third-party services (payment providers, email providers, AI model APIs)
The important difference from human logins is that NHIs typically:
run continuously
are embedded in code or config
and often don’t use MFA
That makes them attractive.
If an attacker obtains a working token, they don’t have to “break in.” They authenticate.
Why this is getting worse now
Three trends are pushing NHIs from “important” to “dominant risk”:
1) Software supply chains are bigger than ever
Modern apps are assembled from:
containers
open-source dependencies
infrastructure-as-code
dozens of SaaS integrations
Every integration adds another credential.
2) Automation is everywhere
Organizations want:
faster deploys
self-service infrastructure
ephemeral environments
Automation is good—but it is powered by identities that have privileges.
3) Credentials last longer than the people who created them
Humans change roles and leave.
But a token in a repo or a container can:
persist for months or years
be copied into new builds
and remain valid long after anyone remembers it exists
So the attack surface grows silently.
How secrets leak in real life (it’s not always “someone committed a key”)
The stereotype is a developer committing
AWS_SECRET_ACCESS_KEY
to GitHub.
That still happens. But a lot of leakage is less obvious:
tokens baked into container layers
config files copied into images during build
debug logs containing secrets
“temporary” keys shared in chat and later pasted into code
CI variables printed by misconfigured pipelines
And container images are particularly dangerous because:
they get mirrored
they get cached
they get copied between teams
Even if you delete the key from the repo, the key can remain in old image layers.
Why leaked tokens are more dangerous than many exploits
Exploits are noisy. They often trigger alerts.
Leaked tokens are quiet. They often look like normal usage:
successful authentication
correct API calls
legitimate endpoints
That changes the defender’s problem.
Instead of detecting “an attacker,” you have to detect:
an unexpected
principal
using valid credentials
from unusual locations
at unusual times
doing unusual actions
This is why NHIs are a detection gap for many organizations.
The privilege problem: tokens are often too powerful
A lot of secrets are created as “get it working” shortcuts:
broad cloud permissions
admin-level API access
long-lived keys
And once the system works, people don’t want to touch it.
This creates a dangerous asymmetry:
a human account might have MFA and monitoring
the machine identity might have broad access and little scrutiny
When the machine identity leaks, the blast radius can be bigger.
What a good NHI strategy looks like (concrete practices)
This is solvable, but only if you treat NHIs as first-class security assets.
1) Prefer short-lived credentials
Where possible:
use temporary session credentials
rotate tokens frequently
avoid “never expires” keys
Short-lived tokens reduce the payoff of leaks.
2) Replace static keys with workload identity where you can
In modern cloud setups, you can often authenticate workloads via:
instance identity
OIDC federation
managed identity
This reduces the need to store static keys.
3) Separate environments strictly
A common failure is using the same token across:
dev
staging
production
Tokens should be environment-scoped.
If a dev image leaks, it shouldn’t unlock prod.
4) Inventory and ownership
Every meaningful token should have:
an owner
a purpose
an expected usage pattern
If a token has no owner, it is technical debt waiting to become an incident.
5) Monitor NHI behavior like you monitor human behavior
Good signals include:
impossible travel / unusual geographies
unusual API call sequences
spikes in data access
new permissions granted
new tokens created
The goal is not perfect detection; it’s early detection.
6) Treat CI/CD as a high-risk identity factory
CI systems frequently hold:
deployment keys
signing keys
cloud credentials
Lock them down:
least privilege
separated runners
secret masking and prevention of log leaks
strict approvals for production deploy steps
Where teams usually fail (and how to avoid it)
“We rotate keys sometimes” isn’t a plan
If rotation is manual and painful, it won’t happen under pressure.
Make rotation routine and automated.
Security tools without enforcement become “monitoring theater”
Scanning repositories for secrets is useful, but it’s not enough.
You also need:
rapid revocation
alerts on usage
and prevention in build pipelines
The container layer trap
If secrets ever entered a container build context, assume they may exist in:
old images
cached layers
CI artifacts
The fix is not only “delete the repo key.” It’s:
rotate the secret
rebuild and republish images
invalidate caches where possible
What to watch next
If you want to track whether organizations are improving on NHIs, look for:
adoption of short-lived identity (OIDC/workload identity)
widespread token rotation programs
stronger CI/CD boundary controls
incident reports that acknowledge “valid credentials used” as a primary cause
Also watch the tooling side: the best tools will shift from “detect exposed strings” to “reduce the number of static secrets that exist at all.”
The economics: why attackers love token hunting
Token hunting scales.
An attacker who steals one working credential can often:
access multiple systems (cloud + source control + CI)
reuse the same technique across many organizations
and sell access in marketplaces if they don’t want to operate it themselves
For defenders, this means the threat isn’t just “a hacker targeting us.” It’s “a machine economy that profits from any reusable credential.”
That’s why prevention is more valuable here than response. If the key never existed in static form, it can’t be harvested later.
Concrete detection ideas (what to alert on)
If you’re building detections for NHIs, focus on behavior changes rather than magic keywords.
High-signal examples:
A service account used from a
new country/ASN
it never used before.
A token that normally only calls one API suddenly enumerates resources or downloads large volumes.
A CI identity performing actions outside the normal release window.
Secrets used from interactive user endpoints when they were intended only for server workloads.
Even basic anomaly alerts can catch the “quiet credential theft” pattern early.
Concrete hardening ideas (low effort, high leverage)
These are practical changes most teams can make without a massive redesign:
Reduce token scope
: split one broad token into several narrowly scoped tokens.
Rotate on schedule
: rotate even when nothing is “wrong,” so rotation becomes muscle memory.
Gate production
: require explicit approval for production deploy identities.
Block plaintext secrets in builds
: CI should fail builds when obvious secret patterns appear.
Each move shrinks blast radius even if a leak still occurs.
A simple internal policy that prevents a lot of pain
If you want one policy that forces better behavior, it’s this:
No production-capable secrets in developer laptops or in container build contexts.
That rule drives changes like:
workload identity for services
staging credentials for development
and explicit approvals for production deployment steps
It’s annoying at first, but it cuts off the easiest leak paths.
Bottom line
Non-human identities are the backbone of modern automation—and also a major breach driver because they often bypass the protections we’ve built for humans.
If you want a practical threshold: once you can answer “where do our long-lived tokens live, who owns them, and how quickly can we revoke/rotate them,” you’ve moved from wishful thinking to a real defense program.
The practical fix is not one magic scanner. It’s a program: minimize static secrets, shrink privileges, make rotation routine, and monitor machine identities like you monitor user accounts.
Sources
https://www.bleepingcomputer.com/news/security/the-double-edged-sword-of-non-human-identities/
←
Previous Post
Next Post
→
oEmbed (JSON)
oEmbed (XML)
JSON
View all posts by Admin
Amaranth-Dragon exploiting a WinRAR flaw shows how fast espionage actors weaponize public bugs
Google teases Pixel 10A: what we know ahead of the February 18 reveal
Leaked API keys and service-account tokens are a quiet but growing breach driver in cloud environments. Here’s how they leak, why they’re dangerous, and how to harden and detect abuse.
Document Title
Page not found - Florin.blog
Image Alt
Florin.blog
Title Attribute
Florin.blog » Feed
RSD
Skip to content
Placeholder Attribute
Search...
Page Content
Page not found - Florin.blog
Skip to content
Home
Blog
Garden Decor
Indoor
Main Menu
This page doesn't seem to exist.
It looks like the link pointing here was faulty. Maybe try searching?
Search for:
Search
Quick Links
Outdoors
About
Contact
Explore
Bestsellers
Hot deals
Best of The Year
Featured
Gift Cards
Help
Privacy Policy
Disclaimer
: As an Amazon Associate, we earn from qualifying purchases — at no extra cost to you.
Florin.blog
Florin.blog » Feed
RSD
Search...
Русский