performing-service-account-audit

サービスアカウント監査の実施

概要

企業インフラ全体のサービスアカウントを監査し、孤立したアカウント、過剰な権限を持つアカウント、コンプライアンスに準拠していないアカウントを特定します。このスキルでは、Active Directory、クラウドプラットフォーム、データベース、アプリケーションにおけるサービスアカウントの検出、権限レベルの評価、所有者が不明なアカウントの特定、ライフサイクルポリシーの適用について説明します。

使用するタイミング

• サービスアカウント監査を実施するセキュリティ評価を行う場合
• 関連するセキュリティイベントのインシデント対応手順に従う場合
• 定期的なセキュリティテストや監査活動を実施する場合
• 実地テストを通じてセキュリティ制御を検証する場合

前提条件

• アイデンティティおよびアクセス管理の概念とツールに関する知識
• 安全に実施するためのテスト環境またはラボ環境へのアクセス
• 必要な依存関係をインストールした Python 3.8+
• テスト活動に必要な適切な認可

目標

• AD、クラウド、データベース、アプリケーション全体のサービスアカウントをすべて検出する
• 有効な所有者または関連するアプリケーションがない孤立アカウントを特定する
• 権限レベルを評価し、過剰な権限を持つサービスアカウントにフラグを立てる
• パスワードがローテーションされていないアカウントや、脆弱な認証を確認する
• 安全な修復のためにサービスアカウントの依存関係をマッピングする
• SOX、PCI DSS、HIPAA の監査用コンプライアンスレポートを生成する

主な概念

サービスアカウントの種類

1. AD サービスアカウント：Windows サービス、スケジュールされたタスク、IIS アプリケーションプール
2. マネージドサービスアカウント（gMSA）：AD によって管理される自動パスワードローテーション
3. クラウド IAM サービスアカウント：AWS IAM ロール／ユーザー、Azure サービスプリンシパル、GCP サービスアカウント
4. データベースサービスアカウント：アプリケーション接続アカウント、レプリケーションアカウント
5. アプリケーションサービスアカウント：API キー、ボットアカウント、連携アカウント

監査の観点

• 所有者：このアカウントの責任者は誰ですか？
• 目的：このアカウントを使用するアプリケーション／サービスは何ですか？
• 権限：このアカウントにはどのような権限がありますか？
• 認証：このアカウントはどのように認証しますか（パスワード、キー、証明書）？
• ローテーション：認証情報が最後に変更されたのはいつですか？
• アクティビティ：このアカウントが最後に使用されたのはいつですか？

ワークフロー

ステップ 1：検出 - Active Directory

1. AD にクエリを実行し、すべてのサービスアカウントを取得します（説明、OU、命名規則でフィルター）
2. ServicePrincipalName が設定されているアカウントを特定します
3. 特権グループ（Domain Admins、Enterprise Admins）に属するアカウントを一覧表示します
4. gMSA と従来型サービスアカウントのどちらかを確認します
5. PasswordNeverExpires フラグが設定されたアカウントを特定します

ステップ 2：検出 - クラウドプラットフォーム

• AWS：アクセスキーを持つ IAM ユーザーを一覧表示し、最終使用日を確認し、未使用のロールを特定します
• Azure：サービスプリンシパル、アプリ登録、マネージド ID を列挙します
• GCP：サービスアカウントを一覧表示し、キーの使用期間を確認し、未使用の権限を特定します

ステップ 3：評価

• 管理者権限または特権グループのメンバーシップを持つアカウントにフラグを立てます
• パスワードの経過期間をローテーションポリシー（最大 90 日）と照合します
• 90 日以上ログインアクティビティがないアカウントを特定します
• アカウントの所有者を CMDB／資産インベントリと照合して確認します
• 共有認証情報（複数のアカウントで同じパスワードハッシュが使われていること）を確認します

ステップ 4：リスク分類

• 重大：ドメイン／クラウドの管理者権限があり、パスワードがローテーションされていない
• 高：機密データへのアクセス権があり、所有者が特定されていない
• 中：標準的なサービス権限があり、パスワードが 90 日を超えて変更されていない
• 低：読み取り専用アクセスで、管理された認証情報を使用している（gMSA、マネージド ID）

ステップ 5：修復

• アプリケーションチームによる確認後、孤立アカウントを無効化します
• 可能な場合は、従来型サービスアカウントを gMSA に移行します
• ポリシーのしきい値を超えている認証情報をローテーションします
• 権限を必要最小限に減らします
• 所有者を割り当て、依存関係を文書化します

セキュリティ管理策

管理策	NIST 800-53	説明
アカウント管理	AC-2	サービスアカウントのライフサイクル
アカウントレビュー	AC-2(3)	アカウントの定期的なレビュー
最小権限	AC-6	サービスアカウントに必要な最小限の権限
認証器の管理	IA-5	サービス認証情報のローテーション
監査レビュー	AU-6	サービスアカウントのアクティビティのレビュー

よくある落とし穴

• アプリケーションの依存関係を事前に確認せずにサービスアカウントを無効にする
• Active Directory 外のサービスアカウントを検出しない
• クラウドのサービスプリンシパルやマネージド ID を見落とす
• サービスアカウントに対話型ログオン権があるか確認しない
• 修正作業の前に依存関係を文書化しない

検証

• すべてのプラットフォームでサービスアカウントのインベントリを作成済み
• 各アカウントに所有者を割り当て済み
• 特権サービスアカウントを根拠とともに文書化済み
• パスワードローテーションの準拠状況を確認済み
• 孤立アカウントに修正対応のフラグを設定済み
• gMSA への移行候補を特定済み
• コンプライアンスレポートを生成済み