アカウントの棚卸しを進めていくと、「人と対応づけられないアカウント」が必ず出てきます。システム同士の連携やバッチ処理のために作られた、いわゆるサービスアカウントです。人が日常的にログインして使うものではないため、入退社をきっかけとした見直しの対象に乗らず、そのまま長期間残り続けやすいという特徴があります。なお、複数の担当者が1つのIDを使い回している状態は共有アカウントの廃止で扱う別の問題であり、本記事の対象とは分けて考えてください。アカウント管理全体の考え方はアカウント管理システムとは？の解説記事にまとめています。
サービスアカウントとは何か
サービスアカウントは、人がログインするためではなく、システムやプログラムが動作するために用意されたアカウントです。基幹システムと外部サービスをつなぐデータ連携、夜間に走るバッチ処理、サーバーやネットワークの監視ツール、バックアップ処理などが代表的な用途です。呼び方は環境によってさまざまで、サービス実行用のアカウント、連携用アカウント、機械的なアカウントなどと表現される場合もありますが、共通しているのは「利用者が人ではない」という点です。
Windows環境であれば、サービスの実行ユーザーやタスクスケジューラの実行ユーザーとして設定されているアカウントがこれに該当します。Active Directoryでのアカウント管理を行っている組織では、こうしたアカウントも人のアカウントと同じディレクトリ上に並んで存在しているため、見分けがつきにくくなりがちです。
なぜ管理から漏れるのか
サービスアカウントが管理から漏れる理由は、大きく3つに整理できます。
1つ目は、人事情報と紐づかないことです。入社・異動・退職を起点にしたアカウントの見直しは、人事側の情報とアカウント一覧を突き合わせる形で行われます。サービスアカウントには対応する従業員がいないため、この突き合わせの過程で必ず「該当なし」となり、判断が保留されたまま残ります。
2つ目は、用途が担当者の記憶にしか残っていないことです。作成した時点では明確な目的があっても、その内容が記録されていなければ、担当者の異動や退職とともに用途が分からなくなります。
3つ目は、止めたときの影響が読めないことです。用途が不明なアカウントは、削除や無効化によってどの業務が止まるか予測できません。結果として「触らないでおく」という判断になり、放置が固定化していきます。
放置されたサービスアカウントが抱えるリスク
用途不明のまま残ったサービスアカウントには、いくつかの共通した弱点があります。
まず、権限が広く設定されている傾向があります。連携処理が途中で権限不足により失敗することを避けるため、必要な範囲を精査せずに強い権限を与えてしまうケースは珍しくありません。権限設計そのものの考え方は権限管理の記事を参照してください。
次に、認証情報が長期間変更されない点です。設定ファイルやスクリプトに認証情報が埋め込まれている場合、変更には関係するシステムの修正が伴うため、後回しにされやすくなります。
さらに、対話的なログインが許可されたままになっている場合があります。本来はプログラムが使うためのアカウントであっても、設定上は人がそのIDでサーバーにログインできる状態が残っていることがあり、これはWindows Serverの特権アカウントを扱う際にも注意が必要な論点です。
そして、誰も日常的に見ていないため、想定外の利用が起きても気づきにくくなります。人のアカウントであれば本人が違和感に気づく可能性がありますが、サービスアカウントにはその機会がありません。
サービスアカウントの洗い出し方
まずは実態を把握することから始めます。次の手順を目安に進めるとよいでしょう。
- 人と紐づかないアカウントを一覧化する — 従業員名簿と突き合わせて対応する人がいないアカウントを抽出します
- 最終ログイン日時を確認する — 稼働中かどうかの判断材料になります。定期的に動いているのか、長期間まったく使われていないのかを分けます
- 用途と責任者を特定する — 何のために作られたアカウントで、現在は誰が管理責任を負うのかを明らかにします
- 依存しているシステムを聞き取る — 関係する部門や委託先に確認し、どの処理がそのアカウントに依存しているかを整理します
- 用途が判明しないものは段階的に扱う — すぐに削除せず、まず無効化して一定期間様子を見ることで、影響範囲を安全に確認できます
棚卸しの進め方や実施頻度といった全体の枠組みについては、アカウントの棚卸しの記事で詳しく解説しています。本記事の内容は、その棚卸しの中で扱いに困りやすい部分を補うものと考えてください。
管理のルールとして決めておくこと
一度洗い出しても、ルールがなければ同じ状態に戻ります。少なくとも次の項目は決めておくことをおすすめします。
- 作成時の記録 — 用途、依存するシステム、責任者を作成と同時に記録することを必須にします
- 権限の範囲 — 処理に必要な範囲に限定し、広い権限を既定にしないようにします
- 対話的ログインの扱い — 人がそのIDでログインする必要がないのであれば、明示的に禁止する設定にします
- 認証情報の保管場所と変更手順 — どこに保管し、変更するときに何を修正する必要があるかをあらかじめ整理しておきます
- 定期的な見直しの対象に含める — 人のアカウントの見直しとは別枠でも構わないので、確認するタイミングを決めます
サービスアカウントの棚卸しシート項目
サービスアカウントは「人がログインしない」ため、記録がなければ存在自体が忘れられます。洗い出したものは、最低限次の項目で残しておいてください。
- アカウント名 — システム側で実際に使われている名称
- 用途 — 何を動かすためのものか。ここが空欄のものは調査対象です
- 動いている場所 — どのサーバー・どのシステムで使われているか
- 業務上の責任者 — 情報システム担当ではなく、その処理が止まると困る部門の担当者を書きます
- 権限の範囲 — 管理者権限が必要な理由まで書けるか
- パスワード変更の可否と手順 — 変えると何が止まるか、変えるには誰の作業が必要か
- 最終確認日 — いつ棚卸しの対象にしたか
このうち実務上いちばん効くのが「パスワード変更の可否と手順」です。ここが埋まっていないと、漏洩が疑われる事態になっても変更に踏み切れず、対応が止まります。逆にここさえ整理されていれば、緊急時の判断が速くなります。
止められないアカウントとどう向き合うか
棚卸しをすると、「用途が分からないが、消すと何かが止まりそうで触れない」というアカウントが必ず出てきます。この状態を放置しないための現実的な進め方は次のとおりです。
- まず記録を取る — 消す判断の前に、そのアカウントがいつ使われているかを一定期間観察します。動きがなければ、止めたときの影響も限定的だと判断できます
- 止める前に権限を絞る — いきなり無効化せず、まず不要な権限を外します。これで止まるものがあれば、そこで用途が判明します
- 止める日を決めて周知する — 「この日に止めます、困る方は申し出てください」と社内に出すと、使っている部門から反応が返ってきます
- 戻せる形で止める — 削除ではなく無効化から始めれば、影響が出た場合に短時間で戻せます
記録の残し方はアクセスログの監査で見るべきポイントもあわせて参照してください。
人のアカウントと同じ枠で扱わないほうがよい理由
サービスアカウントに、人のアカウント向けのルールをそのまま当てはめようとすると、運用が回らなくなることがあります。たとえばパスワードの定期変更は、変更に合わせて関係するシステム側の設定も直す必要があるため、人のアカウントと同じ運用では対応しきれません。多要素認証も、人が操作する前提の仕組みであるため、プログラムが自動で動くアカウントには適用できない場合があります。
そのため、パスワードポリシーの設計を検討する際には、人が使うアカウントと、システムが使うアカウントを分けて考え、それぞれに現実的なルールを用意しておくことが実務的です。片方のルールに無理に寄せるより、対象を分けたほうが結果として管理の抜けが減ります。
まずは自社の状況を確認する
サービスアカウントの扱いは、アカウント管理全体のルールが整っているかどうかに左右されます。applippliの無料診断では、約3分の質問に回答するだけで、自社のID・アカウント管理の対応状況を確認できます。棚卸しや権限の見直しをどこから着手すべきか整理する材料としてご活用ください。