「ブラウザのパスワード管理で良いのでは？」と言われたら～IDaaSが企業のガバナンスを支える理由

ある同僚が、企業の経営者からこのようなことを実際に言われたそうです。
「SSOが便利で安全？IDaaS（Identity as a Service）が必要？ブラウザにパスワードを保存すればいいんじゃないですか？」

わざわざ費用をかけてIDaaSを導入し、シングルサインオン（以下、SSO）を実現しなくても、ブラウザのパスワード管理機能を使えばよい。複雑で長いパスワードを考えたり覚えたりする必要もなく、入力の手間も減るのだから、便利で安全ではないかということです。そう言われた同僚は、その場でうまく切り返すことができなかったとこぼしていました。確かに、ブラウザのパスワード管理は便利です。しかし、企業にとってそれだけで本当に十分なのでしょうか。

今回の記事では、同僚に代わってこの経営者の疑問に答えてみたいと思います。ポイントは、パスワードを安全に管理することと、社員が業務システムを利用できる状態を企業として管理することは、別の話だという点です。

IDaaSが支えるガバナンス

ブラウザにパスワードを保存させれば便利で安全であるということを否定するつもりはありません。強いパスワードの生成・保管・自動入力や、パスワードの使い回しの抑止に役立つ、実用的な機能です。

しかし、企業が考えるべきことはパスワードの管理だけではありません。誰がどの業務システムを利用できるのかを企業として管理・統制する必要があります。つまり、このようなガバナンスを支える仕組みの一つがIDaaSです。ブラウザのパスワード管理が、利用者の認証情報を安全かつ便利に扱うための機能であるのに対し、IDaaSは認証の仕組みを集約するとともに、利用者と業務システムの関係を管理しやすくします。

IDaaSとブラウザのパスワード管理では、カバーする範囲や目的が異なっているということですね。その違いが分かりやすく表れるのが、社員の退職時です。

退職者のアクセスを直ちに止められますか？

ある社員が退職したとします。その社員が利用していたメール、ファイル共有、営業支援、経費精算などの各種業務システムや、生成AI、開発基盤などに関するアクセスをできないようにする必要があります。退職時にブラウザから保存済みのパスワードを削除したとしても、各業務システム側に作成されたアカウントや付与済みの権限がなくなるわけではありません。

IDaaSと連携していないシステムや、ライフサイクル管理の対象になっていないアカウントについては、管理者が個別にアカウントを無効化し、権限を削除する必要があります。そもそも退職者がどのサービスを利用していたか、すべて把握できているでしょうか。利用しているSaaSが増えるほど、こうした確認や作業は煩雑になります。担当者の記憶や手作業に頼っていれば、対応漏れが起きるおそれもあります。そこで、IDaaSを導入してガバナンスを利かせられるようにしましょう、ということになります。

ただし、IDaaSを導入しさえすればすべての業務システムのアカウントを自動的に管理できるわけではありません。IDaaSとの連携に対応していないSaaSや例外的なアカウントには別途の管理が必要となります。それでも、利用資格の付与・変更・停止を個別の手作業ではなく、標準化されたプロセスに近づけられることに価値があります。

業務システム利用を管理するための観点

IDaaSとブラウザのパスワード管理ではカバーする範囲が異なると述べましたが、ここでもう一度整理します。ブラウザのパスワード管理は、利用者がパスワードやパスキーを使って安全で便利にサインインするのに有効です。IDaaSはそれに加えて、企業が業務システムの利用を管理するのに有効です。

観点	ブラウザのパスワード管理		IDaaS
利用者の利便性	○	パスワードの保存・自動入力により、サインインの手間を減らせる	○	SSOにより、複数の業務システムへのサインインを簡素化できる
認証・MFA	△	パスワードやパスキーの利用を助けるが、企業共通のMFAや認証条件を適用する仕組みではない	○	MFAや認証条件を、利用者・業務システム・役割に応じて企業のルールとして適用しやすい その流れで、パスワードレスへの移行も比較的進めやすい
利用できる業務システムの管理	×	利用者が認証情報を持っていればサインインを補助するが、利用資格そのものは管理しない	○	誰にどの業務システムを利用させるかを管理しやすい 利用するSaaSが増加した場合も管理しやすい
役割・権限の管理	×	閲覧者、承認者、管理者などの役割は管理しない	△	役割・権限の付与や連携が可能 （連携するSaaSの仕様に依存する）
入社・異動・退職への対応	×	利用者の認証情報を扱う機能であり、利用資格の付与・変更・停止は担わない	△	人や所属・役割の変化に応じ、利用資格の付与・変更・停止が可能 （連携するSaaSの仕様に依存する）
アクセスの承認・棚卸し・説明・監査	×	誰がなぜ利用できるのか、今も利用が必要かを管理・説明する仕組みではない	△	アクセス申請、承認、定期的な棚卸し、監査対応を支援可能 （IDaaSの仕様やオプション機能に依存する）

○：カバーしている、△：一部をカバーしている、×：カバーしていない

ここで重要なのは、ブラウザのパスワード管理が不十分だということではありません。利用者が認証情報を安全かつ便利に扱うための対策として、引き続き有効な手段です。ただし、企業としては社員がサインインできることに加え、誰が、どの業務システムを、どの立場で、いつまで利用できるのかを管理しなければなりません。IDaaSの価値は、サインインを便利にすることだけでなく、業務システム利用に企業としてのガバナンスを利かせられる点にあります。

IDaaSがもたらす三つの価値

IDaaSが企業にもたらす価値は、大きく三つに整理できます。

1. 利用資格の付与・変更・停止を管理しやすくする

従業員が入社すれば、業務に必要なシステムを利用できるようにする必要があります。部署異動や役割変更があれば、これまで不要だったシステムを使えるようにしたり、反対に不要になった権限を外したりしなければなりません。退職時には、業務システムへのアクセスを確実に停止する必要があります。

ブラウザのパスワード管理は、利用者が持つ認証情報を保存・入力する仕組みです。そのため、ブラウザから保存済みパスワードを削除しても、SaaS側に作成されたアカウントや付与済みの権限がなくなるわけではありません。

IDaaSでは、人、所属、グループ、役割と、利用する業務システムとの関係を管理しやすくなります。人事上の変化をきっかけとして、利用資格を付与・変更・停止するプロセスを整えれば、アカウント管理を個別SaaSごとの作業から、より標準化された運用へ近づけられます。例えば、異動した社員に新しい部署で必要なシステムの利用資格を付与し、以前の部署で不要になった利用資格を外す、退職時には対象となるアカウントを無効化する必要があります。こうした処理を、担当者が都度判断して手作業で進めるのではなく、あらかじめ定めたルールに沿って実行しやすくなります。

もちろん、IDaaSを導入するだけで、すべてのアカウント管理が自動化されるわけではありません。連携していないSaaS、共有アカウント、例外的な運用は別途管理が必要です。それでも、誰が何を利用できるかを把握し、変更を反映するための管理基盤を設けることは、アカウント管理の抜け漏れを減らすうえで有効です。

2. 全社共通の認証ルールを適用しやすくする

業務システムによって扱う情報の重要度は異なります。例えば、一般的な社内ポータルと、顧客情報を扱うシステム、設定変更ができる管理画面では、求める認証の強さが同じでよいとは限りません。

ブラウザのパスワード管理は、強いパスワードやパスキーを利用しやすくします。しかし、「このシステムでは多要素認証を必須にする」「管理者にはより強い認証方法を求める」「特定の条件では追加認証を求める」といったルールを、企業として業務システム横断で適用することとは別の話です。

IDaaSを認証の入口として利用すれば、利用者、グループ、対象アプリケーションなどに応じて、認証や多要素認証のポリシーを設けやすくなります。IDaaSでは、アプリケーションへのアクセスを許可・拒否するルールや、認証時に求める要素を含むポリシーを設定できるものがあります。

重要なのは、すべての利用者に同じ負担を課すことではありません。業務上の重要度や利用者の役割に応じて、必要な場面に必要な認証を求めることです。IDaaSは、そのような認証ルールを、各SaaSの設定画面に分散させず、全社的な方針として運用するための土台になります。また、認証の入口を集約することは、パスワードレス認証への移行を検討する際にも役立ちます。対応する認証方式やアプリケーションの条件を確認しながら、認証の仕組みを段階的に見直しやすくなります。

3. 説明・監査・調査の起点を作る

業務システムの利用にガバナンスを利かせるとは、アクセスを制限することではありません。必要な人が必要なシステムを利用できる状態を維持しながら、次のような問いに企業として答えられる状態を作ることです。

• この社員は、なぜこの業務システムを利用できるのか
• 管理者権限は、誰に付与されているのか
• 異動後も、以前の部署向けの利用資格が残っていないか
• 退職者のアクセスは、いつ、どのように停止したのか
• 不審なサインインが疑われる場合、どの認証イベントを確認すべきか

IDaaSは、アプリケーションの割り当てや認証の入口を集約することで、こうした確認・説明の起点を作りやすくします。また、IDaaSを認証の入口として利用することで、認証の成功・失敗や認証方法など調査に役立つ情報を横断的に確認しやすくなり、インシデント発生時にも役立ちます。

ただし、IDaaSのログだけで、すべての監査や調査が完結するわけではありません。例えば、「業務システム内のどのデータを閲覧・変更したか」といった操作の詳細は、原則として各SaaSの監査ログも確認する必要があります。また、IDaaSさえ導入すれば良いというものでもありません。そこにはもちろん、IDaaSならではの考慮事項も存在します。そのあたりについては次の記事も参考にしていただければ幸いです。

IDaaSの導入を検討すべきなのは？

ここまでIDaaSが業務システム利用のガバナンスを支える仕組みであることを説明してきました。では、すべての企業がただちにIDaaSを導入すべきなのでしょうか。答えは、必ずしもそうではありません。

利用する業務システムが少なく、利用者や組織の変化も限られている企業であれば、まずは各システムのアカウント、管理者、権限、入社・異動・退職時の手順を整理することが先決です。ブラウザのパスワード管理、各SaaSでの多要素認証、アカウント台帳、明確な運用手順といった基本的な対策でも、一定の安全性と管理性を確保できる場合があります。

一方で、次のような状況にある企業では、IDaaSを検討する意義が大きくなります。

• 利用するSaaSやクラウドサービスが増え、誰が何を利用しているか把握しにくくなっている
• 入社、異動、兼務、休職、退職、組織変更が多く、アカウントや権限の変更が頻繁に発生する
• 従業員だけでなく、派遣社員、業務委託先、グループ会社、取引先など、多様な利用者が業務システムを利用している
• SaaSごとにアカウントを作成・変更・削除しており、情シスや各部門の担当者に手作業が集中している
• 多要素認証や管理者向けの認証ルールが、利用するSaaSごとにばらばらである
• 退職者や異動者の不要な利用資格が残っていないか、不安がある
• 親会社や取引先から、「誰が、なぜその業務システムを利用できるのか」を説明するよう求められる
• 顧客情報、従業員情報、財務情報、ソースコードなど、特に重要な情報を扱うシステムが増えている

これらに共通するのは、パスワードの数が増えたことではありません。業務システムを利用できる人と、その利用範囲を、企業として把握し続けることが難しくなっている点です。

利用するサービスが少なければ、各サービスの管理画面を確認しながらアカウントを管理できるかもしれません。しかし、利用するサービスが増え、組織や人の役割も変化し続けると、個別の管理画面や担当者の記憶に依存した運用には限界が生じます。IDaaSは、その限界を超えるための「便利なログイン機能」ではありません。人、所属・役割、業務システム、利用資格の関係を整理し、付与・変更・停止を企業の運用として回しやすくします。

導入判断でまず確認したい三つの問い

IDaaSの検討を始める際には、次の三つを問いかけるとよいでしょう。

• 1.誰が、どの業務システムを利用しているかを、企業として把握できているか
• 2.入社・異動・退職が発生したとき、必要な利用資格の付与・変更・停止を、漏れなく行えているか
• 3.「なぜこの人がこのシステムを利用できるのか」と問われたとき、説明できるか

これらの問いに自信を持って答えられない場合、課題は単なるパスワード管理ではなく、業務システム利用のガバナンスにある可能性があります。IDaaSを検討する基準は、社員が何個のパスワードを覚えているかではありません。企業が、誰に、どの業務システムを、どの立場で、いつまで利用させるのかを管理できているかです。この観点で現状を見直すことが、IDaaSへの投資が必要かどうかを判断する第一歩になります。

さいごに

ブラウザのパスワード管理は、強いパスワードの生成・保存・自動入力を通じて、利用者が安全かつ便利にサインインすることを助ける有効な手段です。パスワードの使い回しを減らし、サービスごとに異なる認証情報を使いやすくする点でも、重要な役割を果たします。しかし、業務システムを利用する企業に必要なのは、社員が便利にサインインできることだけではありません。以下のような問いに継続的に答えられる状態を作ることが、業務システム利用におけるガバナンスです。

• 誰が、どの業務システムを利用できるのか
• どの立場・権限で利用できるのか
• 入社、異動、退職の際に、利用資格を適切に付与・変更・停止できるのか
• 「なぜこの人がこのシステムを利用できるのか」を企業として説明できるのか

ブラウザのパスワード管理は個人の安全なサインインを支えるのに対し、IDaaSは企業の業務システム利用に関するガバナンスを支えます。両者は競合するものではなく、目的と役割が異なります。冒頭の「ブラウザにパスワードを保存すれば十分ではないか」という問いは、利用者の認証情報管理という観点ではもっともです。一方で、業務システムの利用を個人の記憶や各SaaSでの手作業に依存させず、企業のルールとして管理したいなら、考えるべき対象はパスワードの管理だけではありません。

まずは、自社で「誰が、どの業務システムを、どの立場で、いつまで利用できるか」を把握し、説明できるかを確認してみてはいかがでしょうか。その問いが、IDaaSを検討する出発点になります。そしてもしIDaaSの導入を検討することになりましたら、ぜひラックにお声がけください。

ラックでは、IDaaS分野をリードするサービスの一つであるOktaの導入支援サービスを複数提供しています。自社の課題や運用方針に合わせて、適切なプランをご検討いただけます。