Active Directoryもクラウド型のID基盤も導入しておらず、各PCにそれぞれのローカルアカウントを作って運用しているという状態は、中小企業では標準的な構成です。この記事は、その状態から何をどの順で整えるか、そしてどの時点で仕組みの導入を検討すべきかを扱います。
結論を先に書くと、最初にやるのは仕組みの導入ではなく、所在の確定と手順の固定です。順序を逆にすると、運用ルールが曖昧なままツールだけが入り、効果が出ないという結果になります。
この構成で実際に起きていること
ローカルアカウント運用そのものが即座に危険というわけではありません。問題は、この構成が特定の状態を生みやすいことです。
- アカウントの総数が誰にも分からない — 端末ごとに作られるため、社内に何個のアカウントが存在するかを答えられる人がいません
- 退職しても消えない — 端末が次の人に引き継がれる時、前任者のアカウントを消さずに新しいアカウントを追加します。使われないアカウントが端末に積もります
- 全員が管理者権限を持っている — 端末の初期設定時に作ったアカウントがそのまま使われるため、既定で管理者になっています
- パスワードのルールが端末ごとに違う — 一括で適用する手段がないため、実質は各利用者の裁量です
- ファイルサーバーの共有に全員が届く — アカウントで制御できないため、共有フォルダを誰でも読み書きできる設定にして運用を成り立たせています
3つ目と5つ目が組み合わさると、1台が侵害された時点で社内の共有データ全体に届く状態になります。ここが、この構成で最も影響の大きい点です。
台帳で回せる範囲と、回せなくなる境目
仕組みがなくても、Excelなどの台帳で管理することは可能です。ただし成立する条件があります。
台帳で回せるのは、担当者が社内の端末と人を頭の中で全部把握できる規模までです。誰がどの端末を使っているか、退職者が出た時にどの端末を触ればよいかが即座に分かるなら、台帳は機能します。
回せなくなる境目は、台数や人数そのものではなく次の兆候で判断できます。
- 台帳と実機が合わなくなった — 台帳にないアカウントが端末に存在した、あるいは台帳にあるのに端末にない。一度ずれると、ずれは戻りません
- 担当者以外が端末を設定するようになった — 拠点が増えた、現場で急いで設定した。台帳の更新が担当者を経由しなくなります
- 退職者対応が数日以上かかる — 該当端末を探して1台ずつ触る作業になり、当日中に終わらない
- 社外から接続する必要が出た — リモート接続や持ち出しが始まると、端末単位の管理では認証の強度を担保できません
4つ目が出た時点では、台帳運用の是非ではなく認証の強度が別の問題として発生しているため、仕組みの検討が必要になります。
段階1：所在を確定させる
最初の作業は、社内に存在するアカウントを全部数えることです。仕組みがない環境では、端末を1台ずつ確認する作業になります。次を記録します。
- 端末ごとに存在するアカウント名の一覧
- それぞれが管理者権限を持っているか
- 現在使われているか、使われていないか
- 使われていないものは、いつ誰が使っていたか
この作業の目的は台帳を作ることではなく、不要なアカウントを消すことです。数えた結果、退職者のアカウントや検証用に作って放置されたアカウントが見つかります。これらの削除は、費用をかけずにできる最も効果の大きい処置です。棚卸しを継続的に回す手順はアカウントの定期棚卸しで扱っています。
段階2：手順を固定する
次に、人の出入りに伴う作業を手順として決めます。仕組みがない環境では、手順が唯一の担保になります。
- 入社時 — 誰がアカウントを作るか、管理者権限を渡すかどうかを既定で決めておく。既定を「渡さない」にしておくと、例外だけを判断すればよくなります
- 退職時 — どの端末を触るかが即座に分かる状態にし、当日中に処理する。人事部門から担当者に通知が届く流れを作ります
- 端末の引き継ぎ時 — 前任者のアカウントを削除してから引き渡す。ここを決めておかないとアカウントが積もります
並行して、各PCのローカル管理者パスワードが全台同一になっていないかを確認してください。この構成では、キッティング時の値がそのまま全台に残っている場合が多くあります。ローカル管理者パスワードの管理で、この状態が1台の侵害を全台に広げる仕組みを解説しています。
段階3：仕組みへ移す判断
段階1と2を回してから仕組みを検討します。この順序にする理由は、仕組みを入れても運用手順は自動的には決まらないためです。手順が決まっていれば、それを実行できる仕組みを選べます。
導入形態ごとの性格と費用の考え方はアカウント管理システムとは？導入形態4種の比較、社内サーバーとクラウドのどちらに寄せるかの方式選定はローカルアカウント・AD・Entra IDの選び方で扱っています。
なお、Active Directoryを入れれば認証が強くなるわけではありません。ADはアカウントを一元管理する仕組みであり、ログイン時に何を要求するかは別の設定です。導入しても、IDとパスワードだけで入れる状態は変わりません。
認証の強度は別軸で考える
ここまでは「誰のアカウントがどこにあるか」の整理でした。これとは別に、そのアカウントでログインする時に何を要求するかという軸があります。2つは独立しています。
ADがない環境でも、OSのログインに認証要素を追加することは可能です。むしろ、一元管理の仕組みを導入するより先にこちらを手当てしたほうが、投資に対する効果が出る場合があります。パスワードが漏れても入られない状態を作るのは、認証側の対策だからです。
方式の選び方と導入の進め方はWindows/Windows Server OSログインの二要素認証で解説しています。台帳運用のままでも適用できる方式があるため、段階1と2を進めながら並行して検討して構いません。
自社の現在地を確認する
この記事の段階1から3のうち、自社がどこにいるかを判断するには、まず不要なアカウントと権限の状態を把握する必要があります。仕組みの検討はその後です。
自社のID・パスワード管理の状況は、無料の診断で確認できます。所要は約3分で、入力が必要な項目はありません。