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