人間以外のアイデンティティは侵害のエンジンです：トークンとサービスアカウントが漏洩し続ける理由

/テクノロジー/ による

人間以外のID（APIキー、トークン、サービスアカウント、ワークロードIDなど）は、現代のクラウド環境に侵入する最も容易な手段の一つとなっています。これは、攻撃者が突如として天才になったからではなく、組織がますますマシン間の信頼関係に基づいて運営されるようになり、その信頼関係が過度に広範で、長期間にわたり、かつ適切に監視されていないことが原因です。

報告書で強調された新たな分析は、大規模な環境においてよくあるパターンを指摘しています。何千ものコンテナイメージとリポジトリが、本番システムへのアクセスを密かに許可する秘密を誤って公開してしまうのです。問題は、開発者がミスを犯すことがあるというだけではありません。デフォルトのツールとインセンティブによって、それが可能になってしまうのです。簡単秘密を発送し、難しいそうでないことを証明するためです。

これは「目に見えない侵害」の話です。多くの侵害は、エクスプロイトやマルウェアによる大規模な攻撃から始まるわけではありません。不正な認証が行われたトークン（つまり、すべてが正常に見えるトークン）から始まり、それが不正な主体によって使用されていたことに気付くまで、それは続きます。

「非人間的アイデンティティ」とは何か（簡単に言うと）

非人間 ID (NHI) とは、ソフトウェアが信頼できるアクターとして認証できるようにする資格情報です。

  • クラウドアクセスキーとセッショントークン
  • サービスアカウントとワークロードID
  • ビルドパイプラインで使用される CI/CD 認証情報
  • SaaSツール（GitHub、GitLab、Slack、監視プラットフォーム）のトークン
  • サードパーティ サービス (決済プロバイダー、メール プロバイダー、AI モデル API) の API キー

人間によるログインとの重要な違いは、NHI が通常次のような点です。

  • 継続的に実行する
  • コードまたは構成に埋め込まれている
  • MFAを使用しないことが多い

それが彼らを魅力的にしているのです。

攻撃者が有効なトークンを入手した場合、「侵入」する必要はありません。認証するだけです。

なぜ今悪化しているのか

NHI を「重要」から「主要なリスク」へと押し上げる 3 つの傾向:

1) ソフトウェアサプライチェーンはかつてないほど拡大している

最新のアプリは以下から構成されています。

  • コンテナ
  • オープンソースの依存関係
  • インフラストラクチャ・アズ・コード
  • 数十のSaaS統合

統合ごとに別の資格情報が追加されます。

2) 自動化はどこにでもある

組織が求めているのは:

  • より速い展開
  • セルフサービスインフラストラクチャ
  • 一時的な環境

自動化は良いことですが、それは権限を持つ ID によって実現されます。

3) 資格情報はそれを作成した人よりも長く存続する

人間は役割を変えて去っていく。

ただし、リポジトリまたはコンテナ内のトークンでは次のことが可能です。

  • 数か月または数年にわたって持続する
  • 新しいビルドにコピーされる
  • 誰もがその存在を覚えてからずっと有効であり続ける

つまり、攻撃対象領域は静かに拡大していくのです。

現実世界で秘密が漏洩する仕組み（必ずしも「誰かが鍵を盗んだ」だけではない）

開発者がコミットするステレオタイプAWS_SECRET_ACCESS_KEYGitHub へ。

今でもそういうことは起こります。しかし、漏洩の多くは目に見えないものです。

  • コンテナレイヤーに焼き付けられたトークン
  • ビルド中にイメージにコピーされた設定ファイル
  • 秘密を含むデバッグログ
  • チャットで共有され、後でコードに貼り付けられる「一時的な」キー
  • 誤って設定されたパイプラインによって印刷された CI 変数

コンテナ イメージが特に危険な理由は次のとおりです。

  • それらは鏡に映る
  • キャッシュされる
  • チーム間でコピーされる

リポジトリからキーを削除しても、キーが古いイメージ レイヤーに残ることがあります。

漏洩したトークンが多くのエクスプロイトよりも危険な理由

エクスプロイトは大きな問題です。多くの場合、アラートがトリガーされます。

漏洩したトークンは目立たず、通常の使用方法のように見えることがよくあります。

  • 認証成功
  • 正しいAPI呼び出し
  • 正当なエンドポイント

それによって、防御側の問題は変わります。

「攻撃者」を検出するのではなく、次のものを検出する必要があります。

  • 予想外の主要有効な資格情報を使用する
  • 珍しい場所から
  • 異常な時に
  • 異常な行動をする

このため、多くの組織では NHI が検出ギャップとなります。

特権問題：トークンはしばしば強力すぎる

多くの秘密は、「動作させるための近道」として作成されます。

  • 幅広いクラウド権限
  • 管理者レベルのAPIアクセス
  • 長寿命キー

そして、システムが一旦機能すると、人々はそれに触れたくなくなります。

これにより危険な非対称性が生まれます。

  • 人間のアカウントにはMFAと監視機能があるかもしれない
  • マシンのアイデンティティは広範囲にアクセスできるが、監視はほとんど行われない可能性がある

機械の身元が漏洩すると、爆発半径が大きくなる可能性があります。

優れたNHI戦略とはどのようなものか（具体的な実践）

これは解決可能ですが、NHI を第一級のセキュリティ資産として扱う場合に限られます。

1) 有効期限の短い資格情報を優先する

可能な場合:

  • 一時的なセッション資格情報を使用する
  • トークンを頻繁にローテーションする
  • 「無期限」の鍵を避ける

短命なトークンは漏洩による利益を減らします。

2) 可能な場合は静的キーをワークロードIDに置き換えます

最新のクラウド設定では、多くの場合、次の方法でワークロードを認証できます。

  • インスタンスID
  • OIDCフェデレーション
  • マネージドID

これにより、静的キーを保存する必要性が軽減されます。

3) 環境を厳密に分離する

よくある失敗は、次の場合に同じトークンを使用することです:

  • 開発
  • ステージング
  • 生産

トークンは環境スコープにする必要があります。

開発イメージが漏洩した場合、製品版のロックを解除することはできません。

4) 在庫と所有権

意味のあるトークンには次のものが必要です。

  • 所有者
  • 目的
  • 予想される使用パターン

トークンに所有者がいない場合は、インシデントになるのを待っている技術的負債になります。

5) 人間の行動を監視するようにNHIの行動を監視する

良いシグナルには次のようなものがあります:

  • 不可能な旅行 / 珍しい地理
  • 異常なAPI呼び出しシーケンス
  • データアクセスの急増
  • 新しい権限が付与されました
  • 新しいトークンが作成された

目標は完璧な検出ではなく、早期検出です。

6) CI/CD を高リスクのアイデンティティファクトリーとして扱う

CI システムでは、次のようなことが頻繁に行われます。

  • デプロイメントキー
  • 署名鍵
  • クラウド資格情報

彼らをロックダウンする：

  • 最小権限
  • 分離されたランナー
  • 秘密のマスキングとログ漏洩の防止
  • 本番環境への導入手順に対する厳格な承認

チームが失敗することが多い場所（そしてそれを避ける方法）

「時々鍵をローテーションする」というのは計画ではない

回転が手動で痛みを伴うものであれば、圧力がかかっても回転は起こりません。

ローテーションをルーチン化して自動化します。

強制力のないセキュリティツールは「監視劇場」になる

リポジトリをスキャンして秘密を探すのは便利ですが、それだけでは十分ではありません。

また、次のものも必要です:

  • 迅速な取り消し
  • 使用状況に関するアラート
  • ビルドパイプラインのセキュリティと予防

コンテナレイヤーの罠

シークレットがコンテナのビルド コンテキストに入った場合、次の場所に存在する可能性があると想定します。

  • 古い画像
  • キャッシュされたレイヤー
  • CIアーティファクト

修正方法は「リポジトリキーを削除する」だけではありません。

  • 秘密を回転させる
  • 画像を再構築して再公開する
  • 可能な場合はキャッシュを無効にする

次に見るもの

組織が NHI を改善しているかどうかを追跡したい場合は、次の点に注目してください。

  • 短命アイデンティティ（OIDC/ワークロードアイデンティティ）の採用
  • 広範囲にわたるトークンローテーションプログラム
  • より強力なCI/CD境界制御
  • 「有効な資格情報の使用」が主な原因であると認めるインシデントレポート

また、ツール側にも注意してください。最適なツールは、「公開された文字列を検出する」ことから「存在する静的シークレットの数を減らす」ことに移行します。

経済学：攻撃者がトークンハンティングを好む理由

トークン狩猟スケール。

有効な認証情報を 1 つ盗んだ攻撃者は、多くの場合、次のことを行うことができます。

  • 複数のシステムにアクセス（クラウド + ソース管理 + CI）
  • 多くの組織で同じ技術を再利用する
  • 自ら運営したくない場合は、マーケットプレイスでアクセスを販売する

防御側にとって、これは脅威が単なる「私たちを狙うハッカー」ではないことを意味します。それは「再利用可能な認証情報から利益を得る機械経済」なのです。

だからこそ、ここでは対応よりも予防​​が重要です。鍵が静的な形で存在しなかった場合は、後から入手することはできません。

具体的な検出アイデア（何を警告するか）

NHI の検出を構築する場合は、マジックキーワードではなく動作の変化に焦点を当てます。

高信号の例:

  • サービスアカウントは、新しい国/ASNこれまで一度も使用したことがありませんでした。
  • 通常は 1 つの API のみを呼び出すトークンが、突然リソースを列挙したり、大量のダウンロードを行ったりします。
  • 通常のリリース期間外でアクションを実行する CI ID。
  • サーバー ワークロードのみを対象としている場合に、対話型ユーザー エンドポイントから使用されるシークレット。

基本的な異常アラートでも、「静かな認証情報の盗難」パターンを早期に検出できます。

コンクリート強化のアイデア（少ない労力で大きな効果）

これらは、大規模な再設計を行わなくてもほとんどのチームが実行できる実用的な変更です。

  • トークンのスコープを縮小する: 1 つの広い範囲のトークンを、範囲が狭い複数のトークンに分割します。
  • スケジュールに従ってローテーションする: 何も「問題」がないときでも回転するため、回転が筋肉の記憶になります。
  • ゲート生産: 本番環境のデプロイ ID には明示的な承認が必要です。
  • ビルドでプレーンテキストの秘密をブロックする: 明らかな秘密のパターンが現れた場合、CI はビルドを失敗させる必要があります。

漏れがまだ発生している場合でも、各移動により爆発半径が縮小されます。

多くの苦痛を防ぐシンプルな社内ポリシー

より良い行動を強制するポリシーを 1 つ望むなら、それは次のとおりです。

  • 開発者のラップトップまたはコンテナ ビルド コンテキストには、本番環境で使用できるシークレットはありません。

このルールは次のような変化をもたらします。

  • サービスのワークロードID
  • 開発用のステージング資格情報
  • 実稼働展開手順の明示的な承認

最初は面倒ですが、最も簡単な漏れ経路を遮断します。

結論

人間以外のアイデンティティは現代の自動化のバックボーンであり、人間向けに構築された保護を回避することが多いため、侵害の主な原因にもなります。

実用的なしきい値が必要な場合は、「長期間有効なトークンはどこに保存され、誰が所有し、どのくらい迅速に失効/ローテーションできるか」に答えることができれば、希望的観測から実際の防御プログラムに移行したことになります。

現実的な解決策は、魔法のスキャナ1つではありません。静的な秘密情報を最小限に抑え、権限を縮小し、ローテーションルーチンを作成し、ユーザーアカウントを監視するのと同じようにマシンのIDを監視するプログラムです。

出典

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...
日本語