サービスアカウントの棚卸し手順｜所有者・権限・未使用IDの確認チェックリスト

まず結論：消す前に「誰の・何のための・どこまで使えるIDか」を確認する

サービスアカウントの棚卸しとは、アプリや自動処理が使うIDについて、用途・所有者・権限・認証情報・利用実態を照合し、継続・縮小・廃止を決める作業です。 担当者の退職やシステム移行後もIDだけが残ると、不要なアクセスが続く一方、慌てて削除すれば請求処理やバックアップが止まるおそれがあります。 最初に行うのは一括削除ではなく、対象IDと依存する処理を台帳に結び付けることです。 漏えいや不正利用が疑われる場合だけは平時の棚卸しと分け、証拠保全と封じ込めを優先します。

対象読者は、初めて棚卸しを担当する情シス、開発者、SRE、SaaS管理者です。本記事は2026年9月23日に確認した公式資料に基づく平時の運用ガイドであり、特定の侵害事案の報道ではありません。管理画面の名称・取得できるログ・停止方法は製品や契約で異なります。

サービスアカウントとは：人のアカウント・キーとの違い

サービスアカウントは、バッチ、API連携、CI/CDなどが使うIDです。より広い概念の非人間ID（Non-Human Identity）には、こうした自動処理用のIDが含まれます。ただし、各製品が同じ名前・同じ仕組みで管理しているわけではありません。

Microsoft EntraではサービスプリンシパルやマネージドIDのほか、自動処理に流用されたユーザーアカウントも確認対象になります。Google Cloudのサービスアカウントと、AWSのIAMロールや長期アクセスキーを使うIAMユーザーは、同一のオブジェクトではありません。台帳では製品名とID種別を分けて記録します。

分けて見る対象	確認する問い	台帳に残すもの
ID	どの主体として処理するか	製品、環境、一意のID、表示名
認証情報・信頼設定	何を使い、誰がそのIDを利用できるか	キーID、期限、保管先の参照、引受け・フェデレーション条件
権限	どのデータに何ができるか	対象リソース、操作、範囲、付与経路
利用先	止めると何が止まるか	ジョブ、アプリ、SaaS連携、実行周期、復旧手順
所有者	誰が必要性を承認するか	業務責任者、技術担当、代替連絡先

キーを交換しても、IDの権限が狭くなるとは限りません。IDの権限を減らしても、不要なキーが自動的に消えるとは限りません。この違いは認証と認可の比較で確認できます。

読者別に担当を分ける

担当	主に確認すること	単独で決めないこと
初心者・業務担当	自動処理の用途、実行予定、停止時の業務影響	分からないIDの削除やキーの共有
情シス・SaaS管理者	組織のID一覧、所有者、同意済みアプリ、退職・異動との関係	アプリを止めても支障がないという判断
開発者・SRE	実行環境、依存先、認証方式、変更後の検証と戻し方	自分のリポジトリに利用箇所がないことだけを根拠にした廃止
セキュリティ担当	高権限、ログ欠損、不審操作、例外の期限	業務承認なしの平時の一括停止

退職した開発者が「作成者」であっても、現在の業務責任者とは限りません。個人名が不明なら、まず利用システムの担当部門を仮の窓口とし、正式な所有者と回答期限を決めます。

まず確認すること：棚卸しチェックリスト

以下は作業票へ転記して使うチェックリストです。各項目を「確認済み／未確認／対象外」で記録し、証拠の参照先を添えてください。秘密鍵・トークンの実値は集めません。

• 対象範囲：本番・検証、別テナント・別プロジェクト・別アカウント、外部委託先を含めたか。
• IDの同一性：表示名だけでなく一意のIDを確認したか。同名・類似名を取り違えていないか。
• 所有者と用途：業務責任者と技術担当が、現在の処理に必要だと説明できるか。
• 利用先と周期：日次だけでなく月末、四半期、年次、災害復旧時だけ動く処理を確認したか。
• 認証情報：キー・証明書の識別子、期限、保管・更新責任者、複数の旧キーの残存を確認したか。
• そのIDを利用できる主体：キーを読める人、IDを引き受けられる主体、CI/CDや外部IdPの信頼条件を確認したか。
• 実効権限：直接付与だけでなく継承、グループ、リソース側の許可を含めたか。読み取りだけで足りる処理に変更・削除権限がないか。
• 利用証跡：最終利用の時刻・タイムゾーン・対象操作を確認したか。ログの取得範囲と保持期間も記録したか。
• 変更の安全性：検証環境、変更枠、監視、復旧担当、切り戻し条件を用意できるか。
• 判断の完了条件：継続・権限縮小・廃止候補・要調査のどれかを、承認者と次回確認日付きで残したか。

Microsoftのサービスアカウント管理ガイドも、所有者・用途・権限・依存先・レビュー周期を管理情報として挙げています。本チェックリストの担当分担と作業順序は、その原則を現場で使うための編集部による整理です。

Entra ID・Google Cloud・AWSで確認する場所

Microsoft Entra / Azure

• IDと認証：アプリ登録、エンタープライズアプリケーション、対象リソースのマネージドIDを確認します。アプリIDとオブジェクトIDを区別してください。
• 権限と利用実態：アプリの権限・同意、ディレクトリロール、Azure RBAC、サービスプリンシパル／マネージドIDのサインインログを照合します。

Google Cloud

• IDと認証：プロジェクトのサービスアカウント、ユーザー管理キー、紐付く実行リソースを確認します。
• 権限と利用実態：IAMポリシー、サービスアカウントを利用できる主体、Cloud Audit Logs、用途に応じた利用分析を確認します。

AWS

• IDと認証：IAMロール、信頼ポリシー、長期キーを使うIAMユーザー、紐付くワークロードを確認します。
• 権限と利用実態：IAMとリソース側のポリシー、Last Accessed情報、CloudTrailを照合し、必要に応じてIAM Access Analyzerを利用します。

SaaS・CI/CD

• IDと認証：Bot、連携アプリ、ワークフロー、登録された認証情報のメタデータを確認します。
• 権限と利用実態：スコープ、管理者同意、実行履歴、監査ログを照合し、参照できる保管先とデプロイ先を確認します。

読み取り権限で確認できる範囲から始めます。監査のためだけに秘密情報を表示・ダウンロードしたり、全権限のIDを新設したりしないでください。見えない対象は「存在しない」ではなく、確認権限と担当が不足している状態として記録します。

最終利用がない＝未使用、ではない

AWSのLast Accessed公式説明では、対象サービス・操作や集計期間に制約があり、記録の不在だけで権限を判断しないよう注意しています。また、表示される情報にはアクセスの試行も含まれ、業務処理の成功と同義ではありません。

実務では「認証した」「APIへアクセスした」「予定した業務が完了した」を分けて確認します。例えば、30日間のログに記録がなくても四半期決算の処理は使われる可能性があります。逆に毎日認証していても、失敗し続ける不要ジョブかもしれません。実行予定表・アプリ設定・処理結果を突き合わせ、判断できない場合は期限付きの「要調査」にします。ログ自体が欠ける場合は監査ログ欠損の切り分けへ進んでください。

初動対応：所有者不明のIDを見つけたら

やること：記録、依存確認、変更承認の順に進める

1. 現状を記録する：一意のID、権限、認証方式、最終利用、ログ参照先、確認時刻を残します。秘密の値はコピーしません。
2. 利用先をたどる：管理台帳、アプリ設定、ジョブの予定、担当部門を照合します。名前だけから用途を推測して確定しません。
3. 不正利用と平時の整理を分ける：不審なキー追加、権限拡大、説明できないデータ操作があれば、通常レビューを待たずセキュリティ担当へ連絡します。
4. 変更単位を決める：不要な権限だけ縮小するのか、特定キーを止めるのか、ID自体を廃止するのかを明確にし、業務責任者が承認します。
5. 小さく検証する：製品が提供する可逆的な制限を選び、ジョブの成功、認証エラー、データの到着を監視します。停止を試す目的で、無承認の本番変更はしません。
6. 廃止または例外を確定する：必要な業務周期を確認したうえで廃止を承認するか、継続理由・代替統制・期限を残します。ID削除後も、保管先の認証情報、CI設定、台帳に不要な参照がないか確認します。

Google Cloudの公式推奨は、不要なサービスアカウントをまず無効化し、影響を確認してから削除する考え方です。同名で作り直しても別のIDになるため、元のIAMバインディングがそのまま戻るとは限りません。この挙動を他製品へそのまま当てはめず、マネージドIDやサービスが管理するIDは、それぞれのライフサイクルに従って扱います。

やってはいけないこと

• 所有者不明、名前が古い、ログがない、という理由だけで本番IDを一括削除する。
• IDが動くか試すため、見つけた秘密鍵を自分の端末へ取り込む。
• 台帳・チャット・チケットへ秘密鍵、クライアントシークレット、トークンの実値を貼る。
• 権限不足のエラーを解消するため、根拠なく管理者権限へ戻す。
• 漏えいが疑われる古いキーを、切り戻し手段として再有効化する。
• 「所有者へ問い合わせ中」のまま期限と暫定責任者を決めず放置する。

優先度とエスカレーションの判断基準

以下は編集部が提案する運用上の目安であり、ベンダー指定の期限ではありません。社内のインシデント基準と業務影響に合わせて調整してください。

判断	例	次の対応
インシデント対応へ切替	キーの外部露出、不審な認証情報追加、説明不能な大量読取・権限変更	セキュリティ担当へ直ちに連絡。証拠保全と封じ込め、業務継続判断を並行する
高優先の調査	所有者不明で本番の変更権限がある、利用できる外部主体が説明できない	当日中を目安に責任者・調査期限・暫定措置を決める。無承認で一括停止しない
計画変更	利用先は明確だが過剰権限、共有ID、不要な長期キーがある	検証と変更枠を確保し、権限縮小・用途分離・認証方式の移行を進める
継続承認	用途・所有者・権限・利用証跡が整合し、例外も説明できる	承認理由、次回確認日、用途変更時の再レビュー条件を記録する

棚卸し完了は「一覧を出した」ことではなく、未確認項目に責任者と期限が付き、判断の根拠が残った状態です。 例外が必要ならセキュリティ例外申請の書き方を利用してください。

そのまま使える棚卸し記録テンプレート

権限を制限した社内の台帳やチケットで使います。保管先は承認済みの参照番号を記録し、秘密情報の実値や、それを取得できる署名付きURLを貼らないでください。

確認日・確認者：
製品 / テナント・プロジェクト・アカウント / 環境：
ID種別 / 一意のID / 表示名：
業務責任者 / 技術担当 / 代替連絡先：
用途 / 利用アプリ・ジョブ / 実行周期：
対象リソース / 操作権限 / 付与経路：
IDを利用できる主体・信頼条件：
認証方式 / キー等の識別子 / 期限 / 保管先の管理番号：
最終認証 / 最終操作 / 最終業務成功：
確認したログと対象期間 / 欠損・未確認範囲：
停止影響 / 検証方法 / 監視担当 / 切り戻し条件：
判断（継続・縮小・廃止候補・要調査）/ 根拠：
変更内容 / 承認者 / 実施日 / 検証結果：
残課題 / 担当 / 期限 / 次回レビュー日：

例えば「月次請求のIDで担当者が退職、直近30日間のログなし」なら、即廃止ではなく請求部門を窓口にして実行予定とログの保持範囲を調べます。用途を確認できたら所有者を再設定し、権限の必要性を承認します。用途が確認できない間も、高権限を放置せず、責任者が期限と暫定措置を決めます。これは架空の判断例であり、特定の被害事例ではありません。

よくある誤解と、次回の棚卸しを軽くする工夫

「人のSSOやMFAを整備すれば、自動処理も保護できる」

人の対話的ログインと自動処理の認証は別に確認します。退職者のログインを止めても、連携アプリや独立した認証情報の廃止を済ませたことにはなりません。退職者アカウント確認と、利用アプリの所有権引継ぎを組み合わせます。

「マネージドIDや短期トークンなら棚卸しは不要」

AzureのマネージドIDは、アプリが認証用の秘密情報を管理する負担を減らします。しかし、何にアクセスさせるかという権限設計と、利用リソースの管理は残ります。AWS IAMの推奨でも、ワークロードの一時認証情報と最小権限・不要権限の見直しは併せて扱われています。

CI/CDではGitHub ActionsのOIDCやWorkload Identity Federationへの移行を検討できます。長期キーの削減だけで終わらせず、どのワークフロー・環境を信頼するかも確認してください。具体的な点検はGitHub Actionsセキュリティチェックリストで扱っています。

「全IDを毎月同じ深さで確認しなければならない」

本記事では一律の周期を指定しません。高権限、本番、外部から利用可能、所有者変更があったIDを先に確認します。通常のレビュー周期に加えて、担当者の退職、システム廃止、権限拡大、認証情報の追加を再確認のきっかけにすると、台帳と実態のずれを見つけやすくなります。

関連用語・次に読むページ

• 全体の作業票：SaaS権限棚卸しチェックリスト
• 漏えい疑いの記録・報告：情報漏えい疑い初動テンプレート
• 考え方を学ぶ：認証と認可の基礎／認証と認可の違い
• 用語を復習：サービスアカウント／非人間ID／最小権限の原則
• 判断を練習：サービスアカウント・非人間ID・認証連携のクイズ
• 人の権限も見直す：SaaS権限棚卸しの進め方

公式情報・参考情報

以下の公式文書を2026年9月23日に確認しました。公開資料の更新日と本記事の確認日は別です。製品の仕様はリンク先の現行文書と、自組織の契約・設定で再確認してください。

• Microsoft Learn：Governing Microsoft Entra service accounts — 所有者、用途、権限、レビュー、廃止を含む管理の原則。
• Google Cloud：Best practices for using service accounts securely — 用途の分離、IDへのアクセス管理、無効化と削除の注意点。
• AWS IAM：Security best practices in IAM — 一時認証情報、最小権限、不要な認証情報の見直し。
• AWS IAM：View last accessed information for IAM — 最終アクセス情報の見方と対象範囲の制約。
• Microsoft Learn：Managed identities for Azure resources — マネージドIDの役割と利用条件。
• GitHub Docs：OpenID Connect — 長期シークレットを減らすCI/CDとクラウドの認証連携。