権限過剰なサービスアカウントの隠れたコスト

あなたの最も強力なユーザーは人ではありません

チームがアクセス権を整理するとき、通常はプロジェクトが終了した契約者、役割が変わった従業員、必要以上の権限を持つ管理者など、人から始めます。これは良い出発点ですが、全体の大部分を見落としています。サービスアカウントやアプリ統合は、個人よりも広範な機密データへのアクセス権を持つことが多く、通常は最後に見直されるものです。不衛生な環境では、強力なサービスアカウントが最も簡単な侵入経路になることがあります。

なぜアクセスレビューは人から始まり人で終わるのか

人は常に侵害における最も身近な関係者でした。攻撃者が侵入する方法は、フィッシング、盗まれたパスワード、ソーシャルエンジニアリングによることが多いです。また、内部者が退職時にファイルをコピーしたり、攻撃者が侵害されたアカウントを使ってデータを引き出したりするなど、データが流出する一般的な経路でもあります。 Verizon's 2026 Data Breach Investigations Report によると、人間の要素は62％の侵害に関与していることがわかりました。したがって、アクセスレビュー、オフボーディングチェックリスト、最小権限プロジェクトはユーザーアカウントを中心に構築されているのは理にかなっています。

サービスアカウントはほとんどそのプロセスに当てはまりません。何かを動かすために作成され、多くの場合、問題が起きないように広範な権限が与えられ、その後は誰も管理しません。設定した人が離職するとアカウントは残り、何が失敗するかわからないためチームは変更をためらいます。したがって、アクセスを見直す際、サービスアカウントはせいぜい二次的な対象です。

サービスアカウントが魅力的なターゲットである理由

機械のIDは人間のIDを82対1で上回っており、CyberArk's 2025 Identity Security Landscapeによると、そのほぼ半数が機密または特権アクセスを持っています。これらは24時間稼働し、通常MFAを使用できず、同じパスワードを何年も使い続けることが多いです。

Active Directoryでは、攻撃者を直接狙った技術があります。ドメインユーザーは誰でも、サービスプリンシパル名（SPN）を持つアカウントのKerberosサービスチケットを要求でき、そのチケットの一部はサービスアカウントのパスワードから派生したキーで暗号化されています。攻撃者はアカウントに再度触れることなく、チケットをオフラインで取得して解読できます。この技術はKerberoasting（MITRE ATT&CK T1558.003）と呼ばれます。これは、多くの環境で見られる、古いパスワードが一度も変更されず、RC4のような古い暗号化がまだ有効なサービスアカウントに対して最も効果的です。

サービスアカウントは、実際には常に非人間的とは限りません。管理者は手動作業を行うためにそれらでサインインし、チーム内で1セットの資格情報を共有したり、複数のアプリケーションで1つのアカウントを再利用したりします。OWASP Non-Human Identities Top 10は両方の問題を指摘しています：過剰権限の非人間的ID（NHI5）と非人間的IDの人間による使用（NHI10）。人がサービスアカウントを通じて作業すると、誰が何をしたかが追跡できなくなります。

実際の侵害での様子

Uber, 2022. 攻撃者が契約者を騙してMFAリクエストを承認させ、内部ネットワークに侵入しました。ネットワーク共有上で、UberのPrivileged Access Managementツール用にハードコードされた管理者資格情報を含むPowerShellスクリプトを見つけました。これによりAWS、Google Cloud、Google Drive、Slackなどへの扉が開かれました。

Cloudflare, 2023. Oktaの侵害後、Cloudflareは数千の資格情報をローテーションしましたが、チームが未使用と考えていたサービストークン1つとサービスアカウントの資格情報3つを見逃しました。そのうちの1つはJiraへの管理者アクセス権を持つSmartsheetのサービスアカウントでした。攻撃者はこれらを使ってCloudflareのConfluence、Jira、Bitbucketシステムに侵入しました。

Salesloft Drift, 2025. 攻撃者はDriftチャットボット統合からOAuthトークンを盗み、700以上の組織のSalesforce環境からデータをエクスポートするために使用しました。

いずれの場合も、最も被害をもたらしたアクセスは、誰も監視していない範囲を持つ非人間のアイデンティティを通じて行われました。

サービスアカウントに潜む4つのアクセス問題

サービスアカウントは人と同じアクセスの問題を抱えています。ただし、誰も見ていないため見つけにくいのです。

• オープンアクセス。 サービスアカウントが依存するフォルダーや共有は、アプリケーションが権限エラーに遭遇しないように広く開放されており、そのまま維持されています。会社の全員に開かれたデータは、侵害されたすべてのアカウントにも開かれています。
• 古くて休止中のアクセス。 アプリケーションは廃止されましたが、アカウントはまだ有効で権利を保持しています。1年間誰も使用していないアカウントは、その資格情報を持つ誰にでもまだ機能します。
• 孤立したアクセス。 アカウントを作成した人が退職したか、アカウントが使われていたシステムがなくなりました。誰もアカウントの目的を知らないため、削除されません。
• 特権および過剰なアクセス。 サービスアカウントはしばしば管理者グループに追加されたり、「動作させるため」にフルコントロール権限が与えられます。管理者権限がなくても、ほとんどは業務に必要な以上のアクセス権を持っています。

これらはそれぞれアカウントの影響範囲を広げます。合わせて、1つのパスワードが多くの機密データへのアクセス権となります。

エージェンティックAIが賭け金を上げる

AIエージェントやコパイロットも非人間のアイデンティティです。これらはサービスアカウントやOAuth権限を通じて与えられた権限で動作します。エージェントがすべてのファイル共有を読み取れるアカウントで動作している場合、すべてを読み取り、潜在的に公開する可能性があります。組織がより多くのAIツールをデータに接続するにつれて、非人間のアイデンティティの数は増え続け、その権限を誤るコストも増加します。

サービスアカウントをアクセスハイジーンに取り込む方法

• インベントリを作成します。 Active Directoryでは、SPNを持つアカウントが良い出発点です。次にEntra IDアプリ登録、SaaS統合、APIトークンを追加します。
• すべてのアカウントに所有者を割り当てる その機能を説明し、変更を承認できる人を。
• 実際のアクセスをマッピングします。 グループメンバーシップと継承の破損を通じて、各アカウントがアクセスできるものを確認します。機密データに焦点を当てます。両方向から作業します：どのアカウントが機密共有にアクセスできるか、特定のアカウントがアクセスできるものは何か。
• 実際の使用状況に基づいて適切なサイズに調整します。 アカウントがアクセスできるものと使用したものを比較します。未使用のアクセスを削除することが、問題を引き起こすリスクが最も低いです。
• SaaS統合を実際の場所で確認してください。 OAuthの許可は通常、各プラットフォームの管理コンソールまたはあなたのidentity providerで管理されます。
• 認証情報を強化しましょう。 古いパスワードを変更し、スクリプトやファイル共有からハードコードされた認証情報を削除し、可能な場合はRC4を無効にしてください。
• 人間の使用を監視してください、 例えば、インタラクティブなサインインやワークステーションからのログオンなどです。
• サービスアカウントを定期的な権限レビューに追加し、人と同じスケジュールで行います。

もう人だけを考えないでください

機密データにアクセスできるすべてのアイデンティティは、人であれそうでなかれ、攻撃対象範囲の一部であり、サービスアカウントはその中でも最も広い部分であることが多いです。次回アクセスレビューを行う際には、サービスアカウントについても同じ手順を実施してください。

Active Directoryおよびファイルサーバーのサービスアカウントについて、Netwrix Access Analyzerはインベントリ、マッピング、レビューのステップをカバーします。サービスアカウントを特定し、最後にアクティブだった日時を表示し、Kerberoastingに脆弱なものをフラグ付けします。ファイルサーバー、SharePoint、Active Directory全体の実効アクセスを計算します。アクセスはどちらの方向からも確認可能です。フォルダーから開始してどのアカウントがアクセスできるかを確認するか、人間またはサービスのいずれかのアカウントから開始してアクセス可能なすべてを確認できます。そこからAccess Information Centerにより、リソース所有者は定期的な権限レビューを実施し、保持、削除、変更を決定できます。