IDの正しい生成プロセスとは
前回（連載第1回）は、認証基盤の見直しにおいての実際の課題はID管理であるケースが多いことをお伝えしました。今回はこのセキュリティルール・運用とシステムの“スキマ”に目を向けてみたいと思います。
ID管理にまつわる問題は、ID管理のルールが企業の定めるセキュリティルールに沿った内容になってさえいれば起きにくいと筆者は考えています。しかし、現実はそう単純にいきません。
ID発行の理想像としては、一元化された生成元からIDが作成され、その企業で利用している一連のシステムを利用するためのアカウントが連携して生成されるといった流れが望ましいです。とはいえ、様々な要因によってこの流れに沿わない実態が多く見られます。まずは、良くない事例とそれがもたらす結果について見てみましょう。
検討すべきは「パターン漏れがないか」という点
人事システムから得られる人事異動情報を元にIDを生成することがID生成の基本形だとすると、この基本に従わない例外的な措置を取るID生成のパターンを考えなければいけないのは、以下のような要望が出てきたときだと考えられます。
- 組織外の人にシステムを使わせたい
- クラウドサービスを部署で使用するためにIDを作りたい
- 共用IDなど、個人のものではないIDを作りたい
どれも業務上発生する可能性がある状況ですので、IT部門の管理者はこのような要望がユーザーから出てくることを考慮したうえで、統合ID管理の導入などのしかるべき対応を検討しておく必要があります。
上記で挙げたような場合に留意しておきたい統合ID管理の導入における検討ポイントは「IDの種類とメンテナンスのパターンを網羅できているか」「現状を踏まえてパターンに漏れがないことを確認できているか」の2点です。管理対象となるIDの拾い上げに失敗していると、管理されない謎のIDが残ってしまい、セキュリティホールとなりかねません。そのため、組織外の人に組織内のシステムを使わせたい場合や共用IDを作成する場合は、権限を与えて良い人にだけ必要な権限を与えるための権限範囲の設計や、IDを使わなくなった場合の取り扱いについてのルール制定を事前に行っておく必要があります。
こうしたパターン漏れの検討の次にすべきなのが、「生成・変更されたID情報のメンテナンスが、利用するシステム上で自動実行可能か」を確認することです。クラウドサービスを利用している企業にありがちなのが、メンテナンスが可能な権限を持つアカウントによって手動でテキスト化された利用者データをアップロードできたり、その上に蓄えられた機密情報をダウンロードできたりする“手動運用”が許されている状態。たとえば、ID管理システムからクラウドサービス向けの情報を出すのに手間がかかるため、現場部門で集めたログイン情報を元に利用を開始し、手動運用を混ぜる、といったようなことが起きると、システムのガバナンスが効かなくなってしまいます。
ごく最近の事例として、このような運用の余地を残してしまった結果、退職者が退職前に使っていた共用アカウントから、退職後にクラウドサービスを利用できる状態になっていたことで、営業情報が盗まれてしまうといった事件がありました。IDをしかるべきルールに沿って適切に管理できていれば、せめて認証の連携だけでもきちんと設定できていれば、退職者がログインできる余地はなかったのではないか？ と考えてしまいます。勿体ないですよね。
【画像クリックで拡大】
先ほどから「統合ID管理」と言っていますが、具体的には何が統合されていれば良いのでしょうか。IDの採番ルール、用途、パスワードの長さ、文字種別など、思いつくまま挙げていくといろいろと出てきますが、根本的な考え方として「IDライフサイクル」が統合されている必要があります。IDライフサイクルとは、「IDを作る」「必要に応じて設定を変更する」「使わなくなったら消す」「権限は一元化されたルールのもと割り当て、ルール外の権限が必要な場合は権限を持つ責任者が承認して割り当てる」といったID管理の一連の流れを指します。このIDライフサイクルを統合し、すべてのIDを適切に管理できる状態にすることが大切です。
