--- > [!NOTE] 目次 ```table-of-contents title: minLevel: 0 maxLevel: 0 includeLinks: true ``` --- > [!NOTE] リスト掲載用文字列 - [2026年、非人間アイデンティティが最大のセキュリティ盲点となる理由](https://blackhatnews.tokyo/archives/57382)【TokyoBlackHatNews】(2026年02月02日) --- > [!NOTE] この記事の要約（箇条書き） - 2026年、非人間アイデンティティ（NHI）が最大のセキュリティ盲点となる。人間ユーザーは保護が進む一方、サービスアカウントやAIエージェントは野放し。 - マイクロサービス、CI/CD、AIエージェントの普及によりNHIが爆発的に増加し、人間：マシンの比率が1:100、時には1:500に達する企業もある。 - 従来のIAMシステムは人間向けに設計されており、NHIの急速な増加とライフサイクル管理に対応できていない。 - 3つの主要な盲点： - **あってはならない場所にあるシークレット**: APIキーやパスワードがソースコード、Jira、Slackなどに平文で漏洩している。 - **不合理な権限レベルのサービスアカウント**: 97%のNHIが過剰な権限を持ち、開発者の利便性から管理者権限が付与され放置されている。 - **ライフサイクルの責任者がまったくいない**: プロジェクト中止や開発者退職後もNHIが休眠アカウントとして有効なまま残存している。 - セキュリティリーダーへの実践的な前進策として以下を推奨： - **実態に即したインベントリ作成**: 環境内のすべてのNHIを自動で発見し、継続的に可視化する。 - **例外なく最小権限を徹底する**: NHIに必要最低限のアクセスのみを許可し、昇格にはセキュリティ承認を必須とする。 - **可能な限り静的な認証情報を排除する**: 長寿命のシークレットを短寿命トークンに置き換え、ジャストインタイムアクセスを実装し、認証情報の自動ローテーションを行う。 - 攻撃者は人間を狙うよりNHIの侵害が容易で静かであることを認識しており、2026年にはマシンアイデンティティが主要な侵害経路になると予測されている。 > [!NOTE] 要約おわり --- 投稿日 ## MFAで人は厳重に守ったのに、サービスアカウントとAIエージェントは野放しのまま——それこそが、マシンアイデンティティが今日最大のセキュリティギャップである理由です。 先月、Azure環境で定期的なアクセス監査を実施していたところ、svc-dataloader-poc というサービスアカウントを見つけました。793日間——2年もの間、手つかずで休眠していました。権限を確認した瞬間、背筋が凍りました。顧客データベースを含む3つの本番サブスクリプションに対するオーナーレベルのアクセス権が付与されていたのです。そのアカウントは、結局本番化しなかった概念実証（PoC）の移行のために作られたものでした。作成した請負業者は18か月前に退職。誰もその存在を知りませんでした。 これは一度きりの話ではありません。同じ監査で、似たようなアカウントを47個見つけました。47枚の扉が、開け放たれたままだったのです。 2026年、あらゆるセキュリティリーダーが直面する不都合な現実があります。過去10年、私たちは人間ユーザー向けにMFAの展開やゼロトラスト・アーキテクチャの完成度を高めることに注力してきましたが、その一方で、別のものが環境内で静かに増殖していました。サービスアカウント。APIキー。自動化用の認証情報。AIエージェント。こうした非人間アイデンティティは、今や多くの企業で実在の従業員数を、5年前なら荒唐無稽に思えた比率で上回っています。 [ManageEngineの「2026 Identity Security Outlook」](https://www.manageengine.com/privileged-access-management/identity-security-outlook-report.html) では、組織が機械：人間の比率を100:1と報告し、中には500:1に達した例もあるとされています。そして、その大半はガバナンス・プログラムの完全な外側に置かれています。 私たちのIAMシステムは、そもそもこの状況を想定して作られていません。アイデンティティは、人間に属し、上長がいて、アクセスレビューのメールに反応し、いずれ退職や引退をする——という前提です。マシンアイデンティティには上長がいません。認証（棚卸し）キャンペーンにも反応しません。辞めることもありません。 [OWASP Non-Human Identities Top 10](https://owasp.org/www-project-non-human-identities-top-10/) では、不適切なオフボーディングが最大のリスクに挙げられています。プロジェクトが中止になったとき、ベンダー連携が廃止されたとき、開発者が退職したとき——誰かがサービスアカウントの削除を覚えているでしょうか。複数組織でIAMプログラムを運用してきた私の経験では、答えはほぼ「いいえ」です。 ## 私が繰り返し見つける3つの盲点 クラウドセキュリティとアイデンティティ管理に長年携わっていると、どこを見ても同じパターンが現れます。特に、私が評価するほぼすべての環境で、次の3つの問題が見つかります。 1. **あってはならない場所にあるシークレット。** 今でもソースファイルにAPIキーがハードコードされているのを見つけます。今でも。2026年になっても。昨年、GitGuardianは公開GitHubリポジトリで1,300万件のシークレット露出を検出しました。Google APIキー、MongoDBの認証情報、AWSアクセスキー——誰でも収集できる平文のまま置かれていました。しかし、公開リポジトリは最大の問題ですらありません。私自身の評価では、本番データベースのパスワードがJiraチケット、Slackメッセージ、Confluenceの運用手順書、共有Googleドキュメントに書かれているのを見つけています。同僚は、2023年にTeamsチャットへ貼り付けられた決済ゲートウェイの管理者トークンを発見しました。まだ有効で、まだフルアクセスを許していました。シークレットがコラボレーションツールに流出した時点で、あなたは制御を失っています。コピーされ、転送され、インデックス化され、アーカイブされます。完全に消えることはありません。 2. **不合理な権限レベルのサービスアカウント。** これは防げるのに防がれていないので腹立たしい。開発者が新しいLambda関数のためにサービスアカウントを必要とします。締め切りに追われています。必要最小限の権限を正確に見極めるには時間がかかるため、AdministratorAccessを付けて先へ進みます。関数は動きます。誰も見直しません。そのアカウントは、S3バケット1つへの読み取り権限で足りた作業のために、AWS環境全体への神権限を持つことになります。これがチームごと、スプリントごと、年ごとに積み上がります。Entro Securityによる [「2025 State of Non-Human Identities report」](https://nhimg.org/2025-state-of-non-human-identities-and-secrets-in-cybersecurity) では、NHIの97%が過剰権限を持つとされています。97%です。さらに憂慮すべきことに、わずか0.01%のマシンアイデンティティがクラウドリソースの80%を制御しています。そのうちの1つでも侵害されれば、攻撃者はあなたの環境を掌握します。 3. **ライフサイクルの責任者がまったくいない。** 従業員が退職すると、HRがオフボーディングを開始します。アクセスは剥奪されます。プロセスがあります。では、サービスアカウントが不要になったらどうなるでしょうか。何も起きません。ただそこに残ります。私は、6か月、12か月、時には3年も触られていないのに、本番アクセスを保持したままのアカウントを日常的に見つけます。Vezaの調査では、休眠アカウントが前年比でほぼ倍増しました。孤児化したアイデンティティは40%増加。あるデータセットでは、元従業員（その数78,000人）が、HRシステム上は非アクティブとフラグ付けされているのに、誰もサービスアカウントを無効化しなかったため、依然として有効な認証情報を持っていました。これは机上の脆弱性ではありません。誰かに見つけられるのを待っている、生きた認証情報です。 ## セキュリティリーダーのための実践的な前進策 問題を認めることが第一歩です。解決には、マシンアイデンティティを、人間ユーザーにようやく適用できるようになったのと同じガバナンス規律で扱う必要があります。実際に機能しているものを踏まえると、私なら次に注力します。 - **実態に即したインベントリを作る。** 見えないものは守れません。まず最初に、環境内のあらゆる非人間アイデンティティを発見してください。クラウドプラットフォーム全体のすべてのサービスアカウント。アプリケーション内のすべてのAPIキー。Vault、設定ファイル、CI/CDパイプラインにあるすべてのシークレット。システムにアクセスできるすべてのサードパーティ連携。私が関わる多くの組織は、自分たちのフットプリントを大幅に過小評価しています。実数は通常、想定の3〜5倍です。これは手作業や年次監査では成り立ちません。アイデンティティは、人間が数えられる速度より速く作られます。発見を自動化し、継続的に行ってください。 - **例外なく最小権限を徹底する。** すべてのNHIは、その機能に必要な最小限のアクセスにスコープされるべきです。はい、手間はかかります。はい、開発者は反発します。それでもやるのです。新規デプロイから始め、初日から最小権限をデフォルトにしてください。既存アカウントについては、付与権限を実際の利用パターンと照合します。広範なアクセスを持ちながら、実際には1〜2個のリソースにしか触れていないアカウントが多数見つかるはずです。そこはクイックウィンです。NHIに昇格権限を付与する前に、必ずセキュリティ承認を要求してください。提案ではなくゲートにするのです。 - **可能な限り静的な認証情報を排除する。** 長寿命のシークレットは、NHI侵害の大半の根本原因です。目標は、それらを完全に排除することです。恒久的なAPIキーを、自動的に失効する短寿命トークンに置き換えてください。特定タスクのために権限を付与し、直後に剥奪するジャストインタイムアクセスを実装してください。定義したスケジュール（週次、日次、機微なシステムなら毎時）で認証情報のローテーションを自動化してください。調査では、非人間アイデンティティの71%が推奨期間内にローテーションされていません。認証情報が変更されないままの1日1日が、攻撃者が検知されずに使い続けられる1日になります。 セキュリティ業界では、2026年に向けて明確なコンセンサスが形成されつつあります。クラウド環境において、マシンアイデンティティが主要な侵害経路になるということです。Tenableもそう予測しています。Delineaもそう予測しています。One Identityもそう予測しています。攻撃者はすでに、サービスアカウントの侵害が、人間を狙うより簡単で静かであることを知っています。彼らはもう扉を破って入りません。私たちが鍵をかけ忘れた扉から、歩いて入ってくるのです。 この脅威に先んじる組織は、非人間アイデンティティを、経営層アカウントと同じ深刻さで扱う組織です。完全な可視化。厳格なガバナンス。例外なし。NHIを後回しにし続ける組織は、中止になったプロジェクトの忘れ去られたサービスアカウントが、いかにして全体を崩壊させたのかを取締役会に説明することになるでしょう。 私たちは何年も前に正面玄関には鍵をかけました。裏口を守ってからは、長い時間が経っています。 **この記事はFoundry Expert Contributor Networkの一環として公開されています。 [参加したいですか？](https://www.csoonline.com/expert-contributor-network/)** 翻訳元: [https://www.csoonline.com/article/4125156/why-non-human-identities-are-your-biggest-security-blind-spot-in-2026.html](https://www.csoonline.com/article/4125156/why-non-human-identities-are-your-biggest-security-blind-spot-in-2026.html) ### 関連 [](https://blackhatnews.tokyo/archives/2300 "エージェントAIリスクを抑えるには非人間のアイデンティティのセキュリティが必要") #### エージェントAIリスクを抑えるには非人間のアイデンティティのセキュリティが必要 出典: ArtemisDiana via Shutterstockサービスアカウントからウェブアプリ… darkreading.com [](https://blackhatnews.tokyo/archives/24011 "企業は非人間アイデンティティ（NHI）のセキュリティ確保に自信がない") #### 企業は非人間アイデンティティ（NHI）のセキュリティ確保に自信がない 読了時間：4分論評非人間アイデンティティ（NHI）は、今後1年で爆発的な成長と導入が見込まれており、… darkreading.com [](https://blackhatnews.tokyo/archives/20199 "ゼロトラストをAIエージェントに拡張する：「決して信頼せず、常に検証する」が自律化へ") #### ゼロトラストをAIエージェントに拡張する：「決して信頼せず、常に検証する」が自律化へ 執筆者：Ido Shlomo、CTO兼共同創業者、Token Security 組織がワークフローの… bleepingcomputer.com Published in