現代環境における非人間アイデンティティのライフサイクル管理

はじめに：非人間アイデンティティのライフサイクルが注目されるべき理由

非人間のアイデンティティ（Non-human identities：NHIs）は、人間のアカウントが直接関与しなくても、システム、アプリケーション、または自動化プロセスが認証して他のリソースとやり取りできるようにする、あらゆる資格情報（credential）またはアイデンティティの構成要素を指します。NHIsには、アプリケーションやサービス専用のサービスアカウント（service accounts）、外部サービスへアクセスするための静的トークンであるAPIキー（API keys）、OAuthトークンやJWTトークンのような有効期間が短いトークン（short-lived tokens）、そしてCI/CDパイプライン、構成管理ツール、またはRPAワークフローで使用される自動化用の資格情報が含まれます。インフラが多様で自動化手順が複雑な組織では、NHIsが人間のユーザー数を10倍以上上回ることも珍しくありません。中規模の組織でもNHIsが数百件存在し、規模の大きい企業では数千件に達することがあります。NHIの種類やセキュリティ上の課題について詳しくは、こちらの記事をご覧ください。non-human identity security.

人のアイデンティティのライフサイクル管理は、すでに確立され成熟しています。HR 主導のワークフローにより、IT は RBAC ロールと定期的なアクセスレビューに基づいて、新規入社者（joiner）、異動者（mover）、退職者（leaver）の従業員についてプロビジョニング（付与）とデプロビジョニング（剥奪）を管理できます。一方で、NHI には定義された管理体制がありません。NHI は多くの場合、開発者や DevOps チームが場当たり的に作成し、利便性のために過剰または広範な権限を付与し、ドキュメント化された所有者がいないまま放置され、ほとんどローテーションされない静的な認証情報で構成されます。

正式な NHI のライフサイクル管理がない場合、組織は次の 3 つの課題に直面します：

• アイデンティティのスプロール（Identity sprawl）： インフラ全体にわたって NHI が制御されないまま増殖し、見つけられないものはレビューや保護ができないため、ガバナンスが極めて難しくなります。
• 孤立した認証情報（Orphaned credentials）： 正当な所有者や目的を失ったにもかかわらず、まだ稼働している NHI です。誰もそれらを積極的に使用していないため、攻撃者が悪用できる「見えないリスク」として残り続けます。
• セキュリティ上の死角（Security blind spots）： NHI は通常、SIEM や SOAR のようなセキュリティツールの監視範囲の外にとどまります。これらは、人のアカウントによる不審な活動を検出するよう調整（チューニング）されているためです。アイデンティティのガバナンスプラットフォームも人のアカウントに重点を置いており、一般的に NHI は含まれません。その結果、大きな攻撃対象領域（attack surface）が開いたままになります。

この記事では、NHIライフサイクルの5つの段階（発見と作成から、監視、リスク管理、そして安全な廃止まで）に焦点を当てます。

今日の IT エコシステムにおける非人間のアイデンティティ（NHI）の定義

非人間のアイデンティティ（Non-human identities：NHIs）とは、自律的に動作するマシン、アプリケーション、サービス、コンテナ、スクリプト、そして自動化プロセスに割り当てられるデジタルアイデンティティです。人の介入なしに、NHIs は認証を行い、特定の権限に対して許可（認可）を受け、リソースにアクセスし、IT システム内でプログラムによる操作を実行します。たとえば、AWS でホストされているアプリケーションは IAM ロールを使用してストレージのファイルにアクセスすることができますし、Kubernetes 上で動作するマイクロサービスはサービスアカウントを使用して他のサービスと通信する場合があります。

NHIs は API キー、共有シークレット、証明書、JWT または OAuth トークン、そしてワークロードアイデンティティなど、機械向けの仕組みで認証を行います。人間のアカウントと異なり、インタラクティブにログインすることはなく、従来の意味でのパスワードも使わず、保存された認証情報（資格情報）に依存することがよくあります。自動的に動作するため、NHIs は非常に速い速度で数百〜数千ものアクションを実行でき、そのため人間のアイデンティティと同じセキュリティ制御と基準でガバナンスされる必要があります。

NHI は、今日の複雑な IT インフラにおいて不可欠です。現代の組織はクラウドネイティブのデプロイメント アーキテクチャを採用する必要があり、マイクロサービスや DevOps の実践には、土台として機械対機械の通信が求められます。

• API のやり取り： モダンなアプリケーションは API に大きく依存しています。アプリケーションは API を使って、データベース、決済ゲートウェイ、ストレージ サービス、監視ツール、そしてサードパーティの SaaS プラットフォームと通信します。これらのやり取りのそれぞれは NHI によって実現され、認証が必要です。
• DevOps および CI/CD パイプライン： 継続的インテグレーション（CI）と継続的デプロイ（CD）のパイプラインは、ソフトウェアのビルド、テスト、デプロイを自動化します。これらのパイプラインでは NHI エージェントを使って、ソースコード リポジトリ、アーティファクト レジストリ、コンテナ プラットフォーム、デプロイ用のクラウド環境、通知ツールに対して認証します。各やり取りでは、別個の NHI による認証が必要で、これらのアイデンティティはしばしば昇格された権限を持ちます。
• クラウド ワークロード： クラウドネイティブ環境では、仮想マシン、コンテナ、サーバーレス関数、そして Kubernetes の Pod などのワークロードを動的に作成・破棄します。これらのワークロードには、ストレージへのアクセス、データベースへの問い合わせ、メッセージング サービスへのアクセスを行うための NHI が割り当てられます。作成・変更・廃止されるこれらすべての NHI には、適切な可視性を伴うライフサイクル管理が必要です。
• スケジュールされたタスクと自動化： クラウドや DevOps を超えて、従来型の IT 環境でも、バッチ処理ジョブ、スケジュールされたスクリプト、データ同期タスク、バックアップ サービス、監視エージェントに NHI が利用されます。これらの自動化タスクは昇格された特権を持つサービス アカウントで実行されることが多く、ローテーションや監視、また適切な制限が行われないことも少なくありません。

組織が管理する一般的な非人間（ノンヒューマン）IDの種類

サービスアカウントおよびアプリケーションのID： これらのIDは、アプリケーション、サービス、プロセスが認証を行い、リソースに安全にアクセスするために、特定の用途として作成された専用の非対話型アカウントです。たとえば、給与アプリケーションがサービスアカウントを使ってSQLデータベースに接続し、従業員データにアクセスすることで、人事異動があっても業務の継続性を確保できます。これらは通常、固定の認証情報（クレデンシャル）やキーで、めったに変更されません。その結果、時間の経過とともに過剰な権限が蓄積されやすく、複数のアプリケーションや環境にまたがって共有されることも多いです。

APIキー、トークン、証明書： これらのIDは、機械同士（マシン・ツー・マシン）のやり取りで使用されます。ユーザー名とパスワードでログインする代わりに、アプリケーションやサービスはこれらのIDを使って自分自身を安全に識別します。APIキーは、呼び出し元のアプリケーションを識別し認可するために、サービス（AWS、Entra ID、Stripe など）から発行される静的な秘密文字列であることがよくあります。OAuth または JSON Web Tokens（JWT）は、認証イベントの後に発行される有効期限の短いトークンで、追加の検証なしにそれらを保持する者にアクセスを許可します。PKI ベースの証明書は、相互TLS認証、コード署名、サービスメッシュの通信に使用されます。これらの証明書には有効期限がありますが、管理されていない証明書はサービス停止の主要な原因の1つです。

クラウドのワークロードおよびコンテナのID： NHIs は、仮想マシン、コンテナ、サーバレス関数、そして Kubernetes のポッドに対して動的に割り当てられます。これらのワークロードは互いに通信し、さらにクラウドの外部では他のクラウド基盤やオンプレミスのインフラとも連携します。管理されたIDによってハードコードされたシークレットの必要性は減りますが、これらのワークロードが使用する IAM ロールに紐づく権限が誤って設定されていると、攻撃者にとって格好の標的になります。

DevOps、CI/CD、および自動化のID： DevOps 環境は、自動化のIDに大きく依存しています。Jenkins、GitHub Actions、GitLab CI、CircleCI などの CI/CD パイプラインツールでは、コードのチェックアウト、アーティファクトのプッシュ、クラウド環境へのデプロイ、インフラの更新のために認証情報が必要です。Terraform や Ansible のような Infrastructure-as-Code（IaC）ツールでは、広範な権限を持つクラウドプロバイダーの認証情報が必要になります。これらの自動化IDが侵害された場合、攻撃者は本番環境をすぐに制御できるようになります。

AIエージェントと自律システムのアイデンティティ： 組織がAI駆動の自動化をこれまでより速いペースで導入するにつれて、新しいクラスの NHI が登場しています。これらのAIエージェントおよび自律システムのアイデンティティは、エンタープライズシステムとやり取りするAIコパイロット、運用タスクを実行するインテリジェントボット、データパイプラインにアクセスする機械学習モデル、そしてフォームに入力しデータを変換するロボティック・プロセス・オートメーション（RPA）ボットを表します。組織はこれらのAIエージェントを導入する際に注意し、監査証跡（audit trail）付きでアクセス範囲を制御・監視するアイデンティティのライフサイクル管理システムを定義する必要があります。

人間のアイデンティティ vs. 非人間のアイデンティティ：ライフサイクル比較

人間のアイデンティティも非人間のアイデンティティもガバナンスが必要ですが、それらのライフサイクルは構造、所有権、リスクプロファイル、運用上の振る舞いにおいて根本的に異なります。従来の IAM プロセスは主に人間のユーザーを対象に設計されており、それをそのまま NHI に適用すると、多くの場合十分な制御を提供できません。

従来の IAM ワークフローは、人の雇用ライフサイクルを前提に設計されています。明確なアカウント所有者がいて、HR のステータスがイベントを引き起こすことを想定しています。NHI はこれらのパターンに従わないため、目的に合わせて作り込まれたライフサイクル管理が必要です。なぜなら、HR 記録がなく、管理者がいないこと、対話型ログインイベントがなく、自然に発生するオフボーディング（退職・停止）のタイムラインが存在しないためです。

非人間のアイデンティティのライフサイクルには実際に何が含まれるのか

NHI には、人間のユーザーと同様の構造化されたライフサイクル管理が必要ですが、管理は自動化、機械対機械の通信、そして高速なスケーラビリティといったシナリオに適応しなければなりません。以下は、NHI ライフサイクルの5つの重要な段階です：

ライフサイクルの考え方で NHI を統治（ガバナンス）することで、セキュリティ上の死角が生じないことを確実にできます。各段階はセキュリティコントロールとして機能します。発見（ディスカバリー）がないとシャドーアイデンティティが生まれ、プロビジョニングが弱いと特権の肥大化（privilege creep）につながり、監視がないと侵害が検知されないまま残り、資格情報のローテーションがないと漏えいした1つのキーが継続的なアクセスを許してしまい、退役（ディコミッショニング）がないと孤立した資格情報が残って、検知されない持続的なバックドアが作られます。

段階 1：非人間のアイデンティティの発見とインベントリ

発見（Discovery）は、非人間のアイデンティティを管理するうえで重要な最初のステップです。なぜならセキュリティにおける最初のルールは「見えないものは守れない」だからです。ガバナンス、ポリシー、またはセキュリティコントロールを適用する前に、組織は環境内のあらゆる NHI について、包括的で正確かつ継続的に更新されるインベントリを確立しなければなりません。

ディスカバリーに必要なこと

継続的なスキャン： NHIは静的なものではありません。開発者は必要に応じてサービスアカウントをプロビジョニングし、CI/CD パイプラインは短命のトークンを生成し、クラウドネイティブのワークロードは新しいアイデンティティを動的に作成します。ある時点で行う監査では、ほぼすぐに古くなってしまうスナップショットが記録されるだけです。効果的なディスカバリーには、スケジュールまたはイベントベースで実行される、継続的かつ自動化されたスキャンが必要であり、新しく作成されたアイデンティティが現れた時点で検出できるようにする必要があります。

複数環境へのカバレッジ： 現代の組織は、ハイブリッドおよびマルチクラウド環境で運用されています。ディスカバリーでは、オンプレミスのディレクトリ（Active Directory など）、AWS/Azure/GCP のクラウド IAM システム、SaaS プラットフォーム、コンテナオーケストレーションシステム、secrets vault（シークレット保管庫）を継続的にスキャンする必要があります。ディスカバリーが 1つまたは2つの環境に限定されていると、NHI の攻撃対象領域の大部分が見えないままになります。

属性のマッピング： ディスカバリーは単にアイデンティティを列挙するだけではありません。セキュリティとガバナンスの制御を適用するために、各アイデンティティの全体的な文脈（コンテキスト）を把握する必要があります。これには、すべての NHI について、アイデンティティを所有するチームまたは個人は誰か、どのような業務機能を担っているのか、それに依存するシステムやサービスは何か、そして資格情報（credentials）が最後にいつローテーションされたか、といった主要な属性のマッピングが含まれます。

よくあるディスカバリーの課題

1. HR システムや主要の ID プロバイダーに集約される人間のアイデンティティとは異なり、NHI はたいてい 1 か所に存在しません。NHI は、クラウド プラットフォームの IAM コンソール、サーバー上のローカル サービス アカウント設定、保管庫（vault）に保存されたシークレット、設定ファイルやコード リポジトリに埋め込まれた API キーなどに存在します。このようなアイデンティティの分散（スパrawl）により、専用の NHI 管理ツールがなければ正確な棚卸し（インベントリ）を把握するのが難しくなります。
2. HR システムから集中ディレクトリ（directory）へ同期される人間のアイデンティティとは異なり、NHI には通常、権威ある（authoritative）起点となるシステムがありません。同じ機能を複数のアイデンティティが担うことがあり、アプリケーションが退役した後も孤立したアイデンティティがアクティブなまま残り、さらに環境をまたいで重複する資格情報（credentials）が存在します。セキュリティ チームは、複数のソースからデータを集約し相関付けて、統一されたインベントリ基盤を構築する必要があります。
3. NHI の発見（discovery）で特に難しい状況の 1 つが、シャドー アイデンティティ（shadow identities）です。開発者や DevOps エンジニアは、正式なプロビジョニング（provisioning）手順の外で、応急対応のための修正、テスト、迅速なデプロイのためにアイデンティティを作成することがよくあります。これらのアイデンティティは適切なドキュメントやスコープが欠けているため、リスクが高く、発見もしにくくなります。

ステージ 2：安全なプロビジョニングとアクセス権の割り当て

最初の防衛線はプロビジョニング（provisioning）フェーズです。NHI がどのように作成されるかは、ライフサイクル全体にわたるリスク プロファイルを決定します。もしあるアイデンティティが、文書化されていないまま、かつ明確な所有者もない状態で過剰な権限を持っている場合、それは検知されないまま何年も続き得るリスクになります。

プロビジョニングのベストプラクティス

作成ワークフローを標準化する： すべての NHI は、事前に定義された反復可能なプロセスを通じて作成する必要があり、アクセス権はロールベースのアクセス制御（RBAC）または属性ベースのアクセス制御（ABAC）のモデルに合わせる必要があります。つまり、サービスアカウント、API キー、CI/CD パイプラインのトークンなどの一般的なアイデンティティ種別について、承認済みテンプレートを用意し、ガバナンス・ポリシーの範囲外で NHI が環境に投入されないようにします。

最初から最小権限を徹底する： NHI のプロビジョニングにおける最大のリスクの一つは、開発段階で広いアクセス権を付与してしまい、それが本番環境では永続化してしまうことです。 最小権限 はアイデンティティ作成時に適用する必要があります。必要なシステムと API の要件を正確に定義し、付与すべき権限を慎重に評価し、クラウドの IAM ポリシーでワイルドカード権限を避け、最小限のアクセスから開始してください。

所有者（オーナー）を割り当てる： すべての NHI は、明確な所有者を確立するために、個人・ロール・チームのいずれかに紐付ける必要があります。所有者情報は、Change Management Database (CMDB) および IAM プラットフォームで定期的に更新し、必要な変更がある場合は必ず所有者に相談のうえ承認を得るようにします。所有者が組織を離れる場合は、所有権を直ちに再割り当てしなければなりません。

有効期限を設定する： 多くの NHI は、期限付きのプロジェクト、移行、テスト環境、ベンダー連携、短期の自動化タスクのために作成されますが、必要性がなくなった後に無効化されることはほとんどありません。各 NHI に有効期限（Time to Live：TTL）を割り当ててください。期限が切れたら、所有者は必要性を見直し、承認されない場合は、その NHI をシステムから自動的に削除する必要があります。

避けるべきプロビジョニングの落とし穴

• 過剰な権限： 納期のプレッシャーのもと、チームは「とりあえず動くようにするために」過剰な権限を付与してしまうことがよくあります。過剰な権限は、動き出してしまうと見直されることはほとんどなく、隠れた特権昇格の経路を生みます。これは、横方向の移動（lateral movement）の機会になったり、重大なコンプライアンス違反につながったりする可能性があります。
• 既存の NHI から権限をコピーする： 新しいアイデンティティを作成するとき、承認された方法だと考えて、既存のものから権限をコピーするほうが簡単です。ですが、これにより、正式に承認されたことのない古い、あるいは過剰な権限を引き継いでしまうといった問題が生じます。
• ドキュメントやオーナーシップなしで NHI を作成する： ドキュメントなしで NHI を作成し、インベントリが更新されない場合、セキュリティチームはそれらをスコープに含められず、リスク評価は古くなり、インシデント対応やデコミッション（decommissioning）の計画もありません。

ステージ 3：継続的なモニタリングと行動の監督

NHI がプロビジョニングされたら、セキュリティ対応はそこで終わりません。対応は、定期的な静的なアクセスレビューだけでなく、権限がどのように使用されているか、また役割や権限が時間とともにどのように変化していくかを継続的に監視する方向へ移行します。継続的な監視により、NHI が行っていることが本来行うべきことと一致しているかを確認できます。もし逸脱が検出された場合は、調査と是正によって、逸脱がインシデントにつながる前に止めることが可能です。

監視するもの

利用パターン：NHI がどれくらいの頻度で、またどのような文脈の中で動作しているかを理解し監視することは、関連するリスクを把握するための基盤となります。NHI は毎日稼働しているのか、それとも週末や月末の数日間だけ稼働しているのか、という点を確認してください。1 時間あたり 100 件のリクエストを処理しているのに、突然 10,000 件へ急増したのはなぜでしょうか？通常の稼働時間帯から外れて利用頻度や呼び出し（コール）量が急増する場合は、侵害または誤用の可能性があります。NHI が長期間アクティブでない場合は、退役されたサービスであるにもかかわらず、資格情報（クレデンシャル）が一度も無効化されていない可能性があります。

アクセス範囲：NHI がアクセスする内容（リソース、API、データストア、サービスなど）を監視することは、可視性を確保し、実際の実行時の挙動が意図されたアクセス設計と一致していることを確認するうえで重要です。NHI が正常に動作しているとしても、過剰なアクセスは潜在的なリスクになり得ます。アクセス範囲の可視性には、定期的なアクセスレビュー、ロールの割り当て、そしてアクセスの重要度に基づくリスクスコアリングを含める必要があります。

不審な変更：あらゆるアクセス変更、特に予期していないものや許可されていないものは、セキュリティチームにとって赤信号であるべきです。これには、新しいロールの割り当て、ポリシーの適用、グループメンバーシップの変更、または変更管理のワークフローに含まれていなかったシークレットへのアクセス権の付与などが含まれます。NHI は自らリクエストを開始できないため、予期しないアクセス変更は、悪意ある活動、インサイダーによる濫用、または自動化の設定ミスの可能性として捉え、速やかに調査しなければなりません。

権限ドリフト: 時間の経過とともに、NHI はさまざまなタスクや一時的なプロジェクトに対する権限を蓄積し、当初意図されていたよりも多くのアクセス権を取得しがちです。よくある原因には、プロジェクトの拡大、一度追加されたまま削除されなかったトラブルシューティング用の一時アクセス、複雑なグループのネストによるロール継承の変更などがあります。権限ドリフトは、現在の権限をベースラインとなる権限テンプレートと比較して、厳密に監視する必要があります。

ログ記録とコンプライアンス

NHI の活動ログは任意ではありません。これは コンプライアンス要件、監査の準備、そしてインシデント対応において、人間の活動ログと同じくらい重要です。PCI DSS、HIPAA、SOC 2、GDPR といったフレームワークでは、人間のアカウントであっても非人間のアイデンティティであっても、システムアクセスについて追跡可能性（traceability）、説明責任（accountability）、および監査ログ（audit trails）が求められます。

• 追跡可能性: すべての自動化されたアクションは、所有権を確立できるように、特定のアイデンティティに紐づけられる必要があります。
• 監査証拠: 組織は、誰が機密性の高いシステムにアクセスしたのか、アクセスがいつ発生したのか、どのようなアクションが実行されたのか、そしてそのアクセスが承認されていたのかどうかを説明できなければなりません。
• インシデント調査： セキュリティ侵害のフォレンジック調査では、アイデンティティログが、認証情報（credentials）が侵害されたかどうかの判断、横方向の移動（lateral movement）の追跡、データの持ち出し（data exfiltration）範囲の特定、そして攻撃イベントを再構成するための明確なタイムラインの作成に役立ちます。

ステージ 4：認証情報（credentials）のリスク管理

長期間有効なシークレットは、非ヒューマン（NHI）アイデンティティのセキュリティにおける最も危険な要素の一つであり、システム全体に及ぶリスクを意味します。ポリシーによってパスワード変更が強制され、さらに MFA により追加の防御層が加わる人の認証情報（human credentials）とは異なり、NHI の認証情報は数か月、あるいは数年にわたって静的に維持されることがよくあります。これらの認証情報が漏えいすると、権限が明示的に取り消されるか、アイデンティティが削除されるまで、攻撃者が積極的に悪用できる状態のまま残ります。

なぜローテーションが重要なのか

未検知の露出： 認証情報（credentials）は、ログ、開発者環境、または高度な手法によって、何のアラームも作動せずに漏えいする可能性があります。シークレットが誤って Git にコミットされたり、設定ミスのあるクラウドストレージのバケット経由で公開されたり、メモリやログから抽出されたりすると、攻撃者は持続的なアクセスを得てしまい、組織はすでに侵害が発生していることに気づけません。

ローテーションは被害の範囲を制限します: ローテーションは、起こり得る侵害に対する時間的な上限の役割を果たします。認証情報を頻繁に変更することで、静かなアクセスを行っていた攻撃者は自動的に権限を取り消されます。たとえば、キーを 24 時間ごとにローテーションしていれば、盗まれたキーは翌日には使えなくなります。15 分間だけ有効な短命トークンなら、露出時間は 15 分にしか制限されません。原則はシンプルです。秘密が長く生き残るほど、何らかの未検知の攻撃経路を通じて暴露されている可能性が高くなります。

コンプライアンスとガバナンス: 現代のセキュリティおよびコンプライアンスのフレームワークでは、認証情報管理の統制が明確に求められており、認証情報のローテーションは「あると良い」ものではなく、必須の統制として位置づけられています。監査では、サービスアカウントの認証情報がどれくらいの頻度でローテーションされているか、ローテーションが自動化されているかどうか、そして秘密情報（シークレット）が露出した場合に何が起きるのかを示す証拠が必要です。

ローテーションのベストプラクティス

ローテーションの方針を定義します: 手動での認証情報ローテーションは、そもそも設計上、信頼性が高くありません。チームが忘れてしまったり、責任の所在が明確でなかったりする可能性があるためです。正式なローテーション方針では、ローテーションが必要な認証情報、認証情報タイプごとの最大有効期間、ローテーションの所有者（責任者）が誰であるか、そして使用すべきツールを定義する必要があります。方針に基づくローテーションにより、さまざまな環境での一貫性が確保され、明確な監査ログ（監査の追跡記録）が作成されます。

ローテーションのスケジュールを設定します: すべての認証情報が同じリスクを持つわけではないため、ローテーション頻度はそれに応じて設定する必要があります。高い権限を持つサービスアカウントは毎日または毎週ローテーションし、広範な権限を持つクラウド API キーは毎週または毎月ローテーションします。そしてユーザーのアクセス トークンは短命にしてください（有効期限は日ではなく分）。目的は、ローテーションを定期的な緊急時対応の統制ではなく、バックグラウンドのプロセスとして運用することです。

露出（exposure）に直ちに対応： ローテーション（Rotation）は時間ベースだけであってはいけません。継続的なモニタリングに基づくイベント駆動で行う必要があります。組織には、侵害（compromise）が疑われる、または確認された時点で即座に発動する、資格情報（credential）のインシデント対応のための明確なプロセスが必要です。露出が検知された場合、自動化されたプロセスにより、侵害された資格情報を無効化（revoke）し、新しいシークレット（secret）を生成し、すべての従属サービスを更新し、ログを記録したうえで関係者に通知するべきです。

ステージ5：非人間（non-human）アイデンティティの廃止（decommissioning）とオフボーディング

廃止（Decommissioning）は、非人間アイデンティティのライフサイクルにおいて最も見過ごされがちな段階であることがよくあります。組織はプロビジョニングやモニタリングに注力しますが、NHI の退役（retirement）は一般的に非公式なキャンペーンの中で行われるか、そもそも行われない場合が多くなっています。その結果、放置された（orphaned）NHI が大量に「ゴーストアカウント」としてシステム内に残り、見えにくい攻撃面を作り出してしまいます。

廃止（decommissioning）の対象となる NHI の特定

効果的な廃止（decommissioning）は可視性（visibility）から始まります。組織は、もはや存在しているべきではない NHI を先回りして検知する必要があります。

未使用のアイデンティティ： 多くの NHIs は、短期プロジェクト、期間限定の統合、テスト環境、または移行イニシアチブのために作成されます。これらのプロジェクトが終了すると、当該 NHIs は有効な認証情報（credentials）とともにシステム内に残り続けます。NHI がもはや使用されていないかどうかを判断する方針を設けるべきです。たとえば、定められた期間（30、60、または 90 日）内に認証イベントが一度も発生しないこと、などの基準を用います。

孤立したアイデンティティ： NHIs は、その所有者または責任チームが組織を離れたり、別のプロジェクトに再配置されたり、NHI が作成されたアプリケーションが NHI のクリーンアップなしで退役（引退）されたりすると、孤立状態になります。所有権がないと、アクセス権を見直したり、認証情報（credentials）をローテーションしたり、異常な活動を監視したりする担当者がいません。孤立したアイデンティティは、システム内では正当に見える一方で監督がないため、特に危険です。

重複したアイデンティティ： 分散型の DevOps 環境では、複数のチームが同じタスクに対して別々のアイデンティティを作成することがあります。その結果、冗長なサービスアカウント、API キーの重複、または同様のアクセス権を持つ複数の認証情報（credentials）が生じる可能性があります。重複したアイデンティティは、監査証跡（audit trails）の維持が難しくなり、あるアイデンティティのアクセスを無効化してもアクセスリスクがなくならないため、複雑性とリスクを高めます。

安全なデコミッション手順

注意深い検証なしに NHI を削除すること自体がリスクです。運用環境（production）でアプリケーションや依存するサービスが壊れる（停止・影響を受ける）可能性があります。デコミッション手順は、体系的な方法で実施する必要があります。

1. 識別とプロファイル作成： 自動化された発見（ディスカバリー）ツールを使用して、非アクティブ状態であること、または有効な保有者（オーナー）がいないこと、関連するアプリケーションやサービスが退役していること、あるいは NHI が重複したアイデンティティとして確認されたことを基準に、アイデンティティをフラグ付けします。識別された NHIs は、アプリケーションのオーナー、セキュリティ、DevOps チームにレビューのために送付する必要があります。
2. 依存関係の検証： NHI を無効化または削除する前に、バックグラウンドジョブ、スケジュールされた自動化タスク、サードパーティ連携、災害復旧プロセス、レガシーシステムを実際にサポートしていないことを確認します。依存関係の確認には、認証ログの見直し、CI/CD 設定の確認、Infrastructure as Code（infrastructure-as-code）テンプレートのスキャン、アプリケーションのオーナーへの相談が必要です。
3. 削除の前に無効化： 決して即時に削除しないでください。ベストプラクティスは段階的に削除することです。まず認証機能を無効化し、失敗やシステムエラーが発生しないか監視します。定義された猶予期間（7〜30日）を設け、その後影響がなければ恒久的に削除します。これにより、チームは影響の有無を検証でき、必要に応じて迅速にロールバックすることが可能になります。
4. 監査目的で削除を記録： すべての退役（decommissioning）のフェーズが完了したら、ハード削除を実行し、監査証跡のためにこの操作が SIEM プラットフォームのログに記録されていることを確認します。高い識別子（unique identifier）を含むアイデンティティ名、関連するシステムと権限、削除理由、レビューおよび承認のワークフロー詳細、削除日付など、必要な情報を文書化してください。

NHI ライフサイクル管理でよくある落とし穴

Netwrix が NHI のライフサイクル管理をどのように支援するか

Netwrix Identity Manager は、自動化されたライフサイクル プロセスによって、人間のアカウントと非人間のアイデンティティを1つのプラットフォームで管理する包括的なアイデンティティ ガバナンスおよび管理（IGA）フレームワークを提供します。Netwrix Identity Manager は、すべてのアイデンティティ タイプを含む集中型のアイデンティティ リポジトリを構築し、統一されたインベントリを作成して、アイデンティティのライフサイクル管理の土台として機能させます。

検出と棚卸し： NHIs を含むすべての ID タイプが、可視性を提供し、ID のスプロールを抑える中央集約型の identity manager リポジトリに同期されます。コネクタは、異なるディレクトリ（Active Directory、Microsoft Entra ID）およびビジネスアプリケーションから、ID とエンタイトルメント（権限）データを取り込み、NHIs を人間の ID と並んでガバナンスの範囲に含めます。

管理されたプロビジョニング: すべてのアイデンティティに対して標準化されたプロビジョニングワークフローが定義されており、過剰な権限によるアドホックなプロビジョニングを削減します。アイデンティティ作成が要求されるとポリシーベースのワークフローが起動し、最小権限の原則を適用してアイデンティティの役割に必要なアクセスのみをプロビジョニングします。ロールベースのアクセス制御により、アイデンティティはその機能に適した権限のみを取得します。

継続的なモニタリングとレビュー： Netwrix Identity Manager は、管理対象となるすべてのアイデンティティについて、権限（entitlements）、変更イベント、およびコンプライアンス状態を追跡します。内蔵されたアクセス認証キャンペーン機能に加え、リスク分析によって、NHIs が過剰な権限を蓄積し始めたタイミングを検知し、アクセスパターンやリソース使用状況も監視します。さらに、人間および非人間のアイデンティティの両方に対して、休眠状態のアイデンティティや孤立したアイデンティティ、権限の肥大化（privilege creep）、および職務分掌（segregation of duties）の違反を検出するのに役立ちます。

アクセスの是正（リメディエーション）とクリーンアップ： Netwrix Identity Manager により、組織は各アイデンティティの権限をポリシー ルールと照らし合わせて分析できます。アクセスをもはや必要としない、またはポリシーで許可されている範囲を超える権限を持つ NHIs は、是正（remediation）対象としてフラグを立てられます。ルールを定義して、一定期間（例：90日）ログインしていない未使用アカウント、所有者が不在の孤立した NHIs、またはアクセス認証の結果として明らかになった過剰な権限を特定することができます。

ライフサイクルの完了： Netwrix Identity Manager は、joiner-mover-leaver（JML）プロセスに対応できる包括的なワークフローによって、プロビジョニング、更新、デプロビジョニングの各フェーズを自動化します。アプリケーションやサービスが退役した場合、プロジェクトが終了した場合、または人間の所有者が離任／次のプロジェクトへ異動した場合でも、Netwrix Identity Manager は関連する NHIs の権限が取り消され（revoked） 、最終的に削除（deleted）されることを保証します。

結論：アイデンティティの拡散からライフサイクル制御へ

現代の IT インフラでは、非人間（non-human）のアイデンティティが支配的なアイデンティティ種別になっており、今後もなくなることはありません。指数関数的に増え続けています。あらゆる新しい自動化メカニズム、クラウドのワークロード、そして AI エージェントが、絶えず拡大する NHI のフットプリントに拍車をかけています。モノリシックなアプリケーション設計からマイクロサービスへの移行により、他のサービスと通信する各サブサービスごとに複数のアイデンティティが必要になります。仮想マシン、サーバーレス関数、コンテナ、マネージド サービスといったクラウド ワークロードはいずれも、より多くの NHIs を必要とします。DevOps パイプラインは、サービス プリンシパル、デプロイ トークン、Git 統合、API 資格情報、ビルド エージェントに大きく依存しています。NHIs は現在、人間のアイデンティティを 10 対 1 の比率で上回っており、その比率はさらに上昇し続けています。

NHI ライフサイクル管理は、増え続けるリスクである NHIs を、管理された資産クラスへと変換し、組織が NHIs がもたらす規模と影響に見合う、より効果的な統制でそれらを管理できるようにします。各段階（発見（discovery）、プロビジョニング、監視、ローテーション、廃止（decommissioning））に取り組むことで、組織はアイデンティティのスプロール（identity sprawl）を抑え、最小権限を徹底し、従来の IAM では NHIs に対して対応しきれないセキュリティのギャップを埋めることができます。