退職者が出たとき、情報システム担当は決まった手順を踏みます。メールを停止し、共有ドライブの権限を外し、貸与端末を回収する。ここまでは、たいていの会社に手順書があります。
止まらないものがあります。その人が5年前に作った、基幹システムと会計ソフトをつなぐための連携用アカウントです。人事の退職フローには載っていません。誰の持ち物か記録もありません。そして止めると業務が止まるので、誰も触りません。
こうした「人ではないID」は Non-Human Identity（NHI）と呼ばれます。サービスアカウント、APIキー、外部サービスに許可したOAuthアプリ、自動デプロイ用のトークン、そして最近ではAIエージェントに渡した認証情報も含まれます。
なぜ棚卸しから漏れ続けるのか
人のIDには持ち主がいます。入社したら発行し、異動したら権限を変え、退職したら止める。誰の責任かが自明です。
NHIにはそれがありません。抜け落ちる理由は、だいたい次の3つに集約されます。
- 作った時点では「一時的」だったから。 検証のために発行したキーが、そのまま本番で使われ続ける
- 作った人がいなくなるから。 引き継ぎ資料に載っておらず、次の担当は存在自体を知らない
- 止めた時に何が壊れるか分からないから。 分からないので、疑わしくても触らない判断になる
そして数が効いてきます。NHIの数は人のIDを大きく上回り、調査によって20倍から100倍以上まで幅があるとされています。幅がこれだけ広いこと自体が、実態を誰も把握できていないことの表れです（Non-Human Identityのリスクとセキュリティ対策 — gihyo.jp）。
数十倍という比率は、感覚的にも合います。社員30人の会社でも、クラウド上のサービスアカウント、SaaS間の連携キー、CI/CDのトークン、監視ツールの読み取り権限を数えれば、あっという間に数百に届きます。
放置されたIDが実際に入口になっている
これは理屈上の話ではありません。国家の支援を受けた攻撃グループが、管理されないまま残っていた古いOAuthアプリケーションを悪用し、本番ではないテナントから本番環境への広範なアクセス権を得て、企業のメールから機密のやり取りや文書を持ち出した事例が報告されています。
構図として重要なのは、破られたのが最新の防御ではなく、誰も見ていなかった古い連携だという点です。多要素認証を全社に入れても、人が介在しないIDには効きません。
OWASPはこの領域について Non-Human Identities Top 10 として整理しています（OWASP Non-Human Identities Top 10 — 2025）。上位に並ぶ項目は、中小企業でもそのまま当てはまるものばかりです。
| 項目 | 中小企業での現れ方 |
|---|---|
| 不適切なオフボーディング（NHI1） | 使わなくなった連携用アカウントが有効なまま残る |
| シークレットの漏洩（NHI2） | APIキーが設定ファイルや共有ドライブに平文で置かれている |
| 第三者NHIの脆弱性（NHI3） | 導入したツールに広い権限を渡したまま、そのツールが侵害される |
| 過剰な権限（NHI5） | 読み取りだけで足りるのに管理者権限で発行されている |
| 長期間有効なシークレット（NHI7） | 5年前に発行したキーが無期限で生きている |
1番目が最上位に来ているのが、この分野の実態をよく表しています。高度な攻撃手法よりも、消し忘れのほうが件数として効いているということです。
発注した側が確認できること
自社に開発体制がない場合、この話は「専門的すぎて手が出ない」に見えます。しかし発注側の立場でも、確認できる場面は決まっています。
引き渡しのとき。 納品物の中に、そのシステムが使っている外部サービスとIDの一覧があるかを確認します。無ければ作ってもらいます。何と何がつながっていて、それぞれ何のためのIDなのか。この一覧が無いまま運用に入ると、数年後に「消していいか分からないID」の山ができます。検収時の確認範囲については発注したシステムを受け取るときにまとめています。
保守契約を結ぶとき。 契約の中に、認証情報の見直しが含まれているかを見ます。「脆弱性対応」とだけ書かれている契約は、たいてい公表された脆弱性への対応を指しており、IDの棚卸しは含まれていません。 保守契約で何を明記すべきかはシステムの保守・運用契約で発注者が見るべきことで整理しました。
担当者が代わるとき。 委託先の担当者交代は、こちらから見えにくい形で起きます。ビルド環境や自動デプロイに使われている認証情報の有効期間を確認する良い機会で、この観点は委託先のビルド環境、まだ長期トークンで動いていませんかで具体的に扱っています。
一斉に止めようとすると、必ず失敗する
棚卸しの結果を見ると、大量の不明なIDが出てきます。ここで「分からないものは全部止める」と決めると、翌朝に業務が止まります。しかも、何を止めたせいで止まったのかを特定するのに数日かかります。
順序としては次のようにするのが現実的です。
- 一覧を作る。 止めるかどうかはまだ判断しない。存在を全部書き出す
- 最終利用日を確認する。 クラウド側のログで、直近90日に使われていないものを抽出する
- 使われていないものから、まず権限を落とす。 削除ではなく縮小にすると、影響が出ても戻せる
- 数週間様子を見て、問題がなければ無効化する。 ここでも削除はしない
- 新規発行のルールを決める。 発行時に「持ち主」と「有効期限」を必ず記録する
5番が抜けると、棚卸しは一度きりの作業で終わり、1年後に同じ状態に戻ります。そもそも長期の鍵を配らずに済ませる方向もあり、その考え方はサービスアカウントの鍵、何個配りましたかで扱っています。AIエージェントに認証情報を渡す場面での注意点はAIエージェントに認証情報を渡す前にを参照してください。
最初に数えるのは1つでいい
全部を一度に把握しようとすると着手できません。まず1つだけ数えてください。自社のクラウド環境とSaaSに、外部サービスへ許可した連携がいくつあるかです。
管理画面の「接続済みアプリ」や「承認済みアクセス」の一覧を開けば、数分で数字が出ます。その中に、社名を聞いても何のツールか思い出せないものが混じっていたら、そこが出発点です。思い出せないということは、誰も見ていない期間がそれだけ続いたということだからです。
引き渡し資料に何を含めるべきか、既存システムの連携をどう洗い出すか——そうしたご相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
