認証基盤のクラウド移行が自然の流れ

　IDaaSが注目される背景には、業務アプリケーションのクラウド化が大きく進んだことが要因の一つとしてある。利用するアプリケーションがクラウドに展開されている中で、認証基盤だけがオンプレミスに設置されていては運用の面で煩雑になりやすい。通常のADサーバはオンプレミスに展開されるため、ハードウェアとしてのサーバ管理などが別途必要となる。可能であればクラウドに展開できた方が自然だろう。

　管理面からも、各種クラウドアプリケーションの管理コンソールへアクセスする際、サービスごとにIDとパスワードを個別に管理するのは運用上の負担が大きい。また、契約するSaaSテナントのログインページへのセキュアなアクセスを実現するために多要素認証（MFA）を活用する際にも、豊富なMFAに対応したIDaaSを利用するメリットは大きい。

　クラウドアプリケーションへのSSOによって利便性を向上させるためにも、管理負担が軽減できるIDaaSへのニーズが高まるのは当然だ。

ゼロトラストセキュリティの要となるIDaaS

　クラウドアプリケーション活用が進むことで重要な情報資産が社外にあるケースも増えていることから、ファイアウォールをはじめとした境界防御が限界を迎えつつある。そこで、企業ネットワークの内部・外部問わず、企業が持つ情報やデバイスなどへのアクセス全てを検証した上で、自社のポリシーに応じて許可する考え方、いわゆる何も信頼しないことを前提とした「ゼロトラスト」という考え方が広まりつつある。

　このゼロトラストの中核ソリューションとなるのが、アクセス制御の要となるIDaaSだ。IDaaSを中心にエンドポイント対策のソリューションなどと連携を深めることで、ゼロトラストと呼ばれるコンセプトに近づくことができる。今後のセキュリティを考える上でもIDaaSは重要なコンポーネントとなるはずだ。

IDaaS導入のメリット

　IDaaSを実際に導入することで、どんなメリットが得られるのだろうか。管理者や利用者目線双方からそのメリットを考えてみたい。

運用管理者のメリット

　パスワードを忘れた場合、通常であれば管理者側でユーザーの認証情報をリセットした上で本人に再設定してもらうという作業が必要だ。IDaaSを利用すれば、パスワードのリセットや回復処理などはユーザー自ら実施できるセルフサービス化が可能となり、管理者の負担を大きく軽減できる。

　また、入社退職に伴って発生するクラウドアプリケーションのアカウント作成や削除も、IDaaSを活用することで契約しているSaaSに対して自動的にアカウント作成および削除が可能になる。アカウントの生成から破棄までのライフサイクル管理が自動化されることで、管理者の工数が削減できる。

　セキュリティリスクの軽減という意味でも、管理者の負担軽減につながるはずだ。IDaaSによってSSOが可能になれば、メモ書きされたパスワードなどが不要になるなど情報漏えいリスクを低減でき、セキュリティ環境の維持工数を減らすことができる。IDaaSが持つ多要素認証を駆使すれば、ユーザー情報だけでなく、アクセスしてきた位置情報やデバイスそのものの情報なども認証条件に加えることで、たとえフィッシングサイトを経由してIDやパスワードが漏えいしたとしても、侵入されるリスクが軽減できる。

利用者のメリット

　IDaaSによってSSOが可能になれば、システムごとにパスワードを記憶せずに済むだけでなく、1つのポータル画面から各SaaSに容易にアクセスできるなど、ユーザビリティの向上にも寄与する。もしパスワードを忘れた場合でも、ユーザー自身でパスワードをリセットでき、回復処理もできるため、都度管理者とやりとりする必要がない。

　また、新たなメンバーが入社してきた場合、通常であればシステム部門に業務アプリケーションにアクセスするためのアカウント作成を申請する必要があるが、IDaaSであれば属性に応じて自動的にSaaSのアカウントが生成されるため、入社してすぐにSaaSを利用できる。契約しているSaaSによっては管理部門や申請方法が異なっていることもあるが、IDaaSにログインするだけで利用可能なSaaSが自動的に使える状態になるのは利用者にとってメリットが大きいはずだ。

IDaaSの基本機能

　ここで、グローバルでシェアを持つIDaaS「Okta」のソリューションをベースに、IDaaSが持つ基本的な機能を見ていこう。

SSO機能

　SAML（Security Assertion Markup Language）やWS-Federationをはじめ、アプリケーションに対してアクセス権限を付与する際に利用されるOAuth 2.0や、その拡張仕様の一つであるOpenID Connectなど標準的な認証プロトコルを駆使することで、さまざまなアプリケーションへのSSOを実現する。また各種APIにも対応しており、標準的な認証プロトコルに対応していないアプリケーションに対してもインテグレーションが可能で、オンプレミスにあるアプリケーションに対してもSSOが可能だ。なお、不正アクセスに対する防御策として、複数回にわたる認証失敗時にアクセス遮断を実行することで総当たり攻撃などのアカウントハックを防ぐロックアウト設定機能も備わっている。

ディレクトリ管理機能

　これまで利用してきたADとの連携はもちろん、IDaaSで各アプリケーションに対するIDやパスワードを統合的に管理できる機能。Microsoft 365をはじめとした各種SaaSにアクセスするための情報をIDaaSにセキュアに格納して管理できるだけでなく、ユーザー属性の追加も可能となるため、例えば営業グループに属している人には「Salesforce」へのアクセス権を、エンジニアであれば情報共有ツールの「Slack」へのアクセス権を付与するといったことが可能になる。このグループ設定によって、新たに入社したメンバーが所属するグループによって、IDaaSのポータルにアクセスするだけで利用可能なアプリケーションを表示でき、アプリケーションごとの設定が不要になるわけだ。

　IDaaSのユーザー属性をうまく活用することで、グループ会社ごとに管理されているADの情報を統合することが可能になり、複数企業での認証情報を統合的に管理できる。認証基盤の統合を行う際にも、AD側のマイグレーションを実施せずとも柔軟な課管理が可能だ。

多要素認証機能

　SSOが可能なIDaaSだけに、認証基盤そのものがシングルポイントになってしまうため、IDaaSへの認証はこれまで以上にセキュアな環境づくりが必要だ。そこでIDaaSでは、通常のIDとパスワードに加えて、SMSやメールと連携した認証をはじめ、ワンタイムパスワードや物理的なトークン、生体認証といったさまざまな手段で認証が可能な多要素認証に対応している。また、アクセスする場所やデバイスの種類、アクセス可能なネットワークなど、状況も加味したコンテキストベースの認証にも対応しており、これらを状況に応じて動的に選択させることでセキュアな環境を整備することができるようになる。

ライフサイクル管理機能

　業務に利用するアプリケーションのID管理は、入社から退職までのライフサイクルで管理できることが望ましい。そこでIDaaSには、アカウントのライフサイクル管理が可能な機能が備わっている。最初にIDaaSで新たなアカウントがアサインされると、IDaaSを経由してアクセスする各種アプリケーションに対して同期を行って自動的にアカウント作成が可能になる。部署移動や役職などが変更になれば、IDaaSで管理されている属性情報を変更することで、各アプリケーションに対するアクセス権限も更新されるため、アプリケーションごとにアカウント情報やアクセス権限などの調整は不要だ。もちろん、退職する際には日付などを指定することで任意の日付でアカウントを停止することが可能となるため、退職後に情報漏えいリスクとして懸念される亡霊IDを残したままにしておくこともない。

　なおOktaの場合、ID管理上必要なワークフローの設定がGUIベースで簡単に実施でき、複雑に操作せずともドラッグ＆ドロップ操作でID管理タスクの自動化が可能になる。具体的には、新たに入社した人に対してアサインされたメールに対してアクセス方法を通知するメールを送付し、具体的なメール文言をGUI上で設定するといったことが可能となり、わざわざ個別にIDaaSへのアクセス方法をメールでメンバーに送るなどの手間もかからない。

オンプレミス上のWebアプリ連携機能

　IDaaSはオンプレミスにあるアプリケーションに対するSSOが可能だが、オンプレミスにあるWebアプリに対してVPNを経由することなくアクセスできる環境も提供している。Oktaでは、オンプレミスにあるWebアプリにアクセスするためにDMZ上に仮想アプライアンスを設置することで、SaaSへのアクセス同様にOktaのポータル画面からアクセスするだけで社内のWebアプリにログインできる。標準的にサポートされているアプリは限定されるものの、社内のシステム側で要求されるBasic認証やForm認証、SMAL認証など、各種認証方法に対して仮想アプライアンスである「Access Gateway」が連携し、シンプルなSSO環境が実現できる。

IDaaS選びの勘所

　IDaaS導入のメリットや基本的な機能について紹介してきたが、IDaaSを選択する際にはどんなポイントに注意するべきなのだろうか。ここで、IDaaS選びのポイントについて見ていきたい。

業務停止を避けるために重要な可用性は十分か

　IDaaSがダウンしてしまうとSaaSへのアクセスができずに業務停止に追い込まれてしまうため、可用性については重要なポイントだ。一般的なSaaSの場合、しっかり運用実績が公開されているケースが多いため、そこでの実績値を十分に吟味したうえで可用性を判断したい。ただし、SaaSが提供する一部の機能だけが落ちた場合は運用実績に反映されていないケースもあるため、十分注意が必要だろう。

多要素認証、選択肢が豊富で設定が柔軟か

　IDaaSの場合、IDaaSへのログインページがインターネットに公開されてしまっており、万が一フィッシングでIDやパスワードが漏えいしてしまうと、IDaaSを経由して情報が搾取されてしまうリスクがある。そこで見ておきたいのが、多要素認証の仕組みだ。ユーザーの属性やデバイスの種類、アクセスする環境、周辺システムとの連携状況など、IDやパスワード以外のコンテキスト情報も含め、柔軟に選択できるものが望ましい。例えばモバイルアプリによる多要素認証をデフォルトとして設定した場合でも、必ずしも全従業員にスマートデバイスを貸与しているとは限らない。一部のユーザーはUSB型の物理トークンを用いた認証を設定したり、拠点のグローバルIPからのアクセスであれば一律多要素認証を不要にしたりするなど、柔軟に対応できる環境が整備できるかどうかは重要だ。

周辺製品との連携が可能か

　IDaaSはSaaSや社内の業務システムなどに対するSSOを実現できるが、最近注目されているゼロトラストセキュリティの視点で考えると、周辺システムから得られる情報を基にアクセスコントロールすることが必要になるため、他システムとの連携についても検討しておく必要がある。例えばモバイル環境であればデバイス管理ツールとしてのMDM、PCであればエンドポイント対策として振る舞いから検知、対処可能なEDRなどから得られる情報をセンサーとして活用することになる。また、VPNやCASB、仮想デスクトップのVDI、セキュリティログを統合管理するSIEMといった仕組みを利用する際にも当然認証が必要となる。これらも含めて統合的に連携できるかどうかを見極めたい。

　なお、すでに周辺システムを導入済みのケースが多いため、IDaaSの仕様に周辺システムを合わせるのでなく、IDaaS側から周辺システムに歩み寄れる、つまりは幅広く連携できるかどうかがIDaaS選びにおいて重要なポイントだろう。

ユーザビリティが優れているか

　IDaaSを活用したID管理では、各アプリケーションに対してSSOを行うことになり、全てのユーザーが、IDaaSが提供するポータル画面からログインすることになる。だからこそ、この部分の使い勝手が現場の生産性に大きく影響を及ぼすことになる。全てのアプリケーションに対して共通のログイン手順でアクセスできるかどうかは確認したい。また、モバイル端末に対するサポートが貧弱であれば、出先で業務アプリを利用できないことにもなりかねないため注意が必要だ。

　万が一アカウント入力に失敗した場合、事前に設定された閾値を超えてしまうとアカウントがロックされてしまう場合もある。そんな場合でも、きちんとアカウントロック解除に向けたフローが整備されているかどうかも見ておきたい。

クラウドサービスの追加が容易か

　現在契約している以外にも新たにSaaSを契約して業務に生かすケースも出てくるだろう。その際にはIDaaS側で新たなアプリケーションを追加し、SSOできるように設定する必要がある。この設定が容易かどうかは運用管理面で大きく影響するだけでなく、連携できないサービスが出てきてしまうと個別管理が必要となり、統合的なID管理が実現できなくなってしまう。その意味でも、IDaaSが新たなアプリケーションを利用する際の足かせにならない仕組みを選択したい。

SaaS／Webアプリケーション連携の手順が明確化されているか

　IDaaSでSSOを実現するためには、当然ながら利用しているSaaSとの連携が必要になり、IDaaSおよびSaaS双方に設定を行う必要がある。この設定手順がマニュアル化されていない場合、SaaS側の仕様を個別に調査し、最適な設定を実装していなかければならないため、できればIDaaS側だけでなく、連携可能なSaaSに関する設定手順までマニュアル化されていると便利だ。できれば、接続先のSaaSの特徴も含めて、詳細に解説しているマニュアルが用意されているものが望ましい。

事業環境の変化に追従できるか

　アプリケーションにおけるSSOの基盤として、そして統合的なID管理の基盤として利用されるIDaaSだけに、多要素認証をはじめとした多彩な認証方法や豊富なテンプレートを活用したSaaS連携など、IDaaSには柔軟性が必要不可欠だ。それは、M＆Aなどによって異なるドメインを統合的に管理せざるを得ない場面においても、高い柔軟性が問われることになる。

　事業会社同士の基盤統合やM＆Aによる企業合併などの場合、双方の企業が異なるID管理を行っているのが当然で、ドメインもそれぞれ異なるもので運用しているだろう。IDaaS側では複数ドメインにおけるアカウントの統合管理およびSSOが実現できる柔軟性を持ったサービスを選択したい。