IDaaSでクラウドの認証を統合管理する

2019年5月26日 16:16

業務ツールのクラウド化が進み、社内で利用するクラウドサービスの数がどんどん増えてきている昨今。
私も以前の会社では、入退社の度に10個以上ものクラウドサービスのアカウントを発行・停止するといったオペレーションをしていました。その頃にIDaaSの存在を知って導入していれば、もっと楽に管理できただろうなという後悔の念があるので、今回はIDaaSについて紹介したいと思います。

IDaaSとは

IDaaSとは"Identity as a Service"の略称です。
「ID管理・認証基盤を提供するクラウドサービス」といった物をイメージしてもらえば大丈夫です。
IDaaSの主な構成要素は以下の3つ。
1. IdP（Identity Provider）
2. SSO（Single Sign-On）
3. SAML

順に簡単に説明していきます。

1. IdP（Identity Provider）
IdPはその名の通り、IDのプロバイダです。
各種クラウドサービスでは、サービスごとにID・PWを発行してアカウント認証を行っています。SAMLという規格に従ってクラウドサービスをIdPに連携させることで、クラウドサービスの認証をIdPに委任することができます。

2. SSO（Single Sign-On）
SSOについては聞いたことがある人も多いのではないでしょうか。
指定した認証基盤で認証が通っていれば、各サービスへの認証をパスすることができる仕組みです。今回の例であれば、「IdPで認証が通ってれば、クラウドサービスにアクセスする際にID・PW入力しなくてもいいよ」といった感じですね。
利用者がIDaaSにログインすると、利用できるクラウドサービスのアイコンが並んでいて、それをクリックすると追加の認証情報の入力なしで各クラウドサービスにアクセスできるといった形です。

例）OneLoginのポータル画面

3. SAML
IDaaSとクラウドサービス間のIdP・SSO連携は、SAMLという規格に沿って実装されます。（厳密にはIdPもSSOもSAML以外の実装方法はありますが、今回は現状で最もメジャーなSAMLについてのみ説明します）
なお、SAMLについても技術的な説明はサイボウズ社のエンジニアブログのこちらのエントリが詳しいので、興味がある方は参考にしてみてください。
――SAML認証ができるまで

全体図
IDaaSの構成要素であるIdP・SSO・SAMLを図にまとめると、以下のようになります。

利用者はIDaaSのID・PWさえ覚えていれば、各クラウドサービスにアクセスでき、管理者はIDaaSのIDとアクセス管理さえしっかりと行っておけば、クラウドサービス毎にセキュリティポリシーを設計する必要も無くなります

IDaaS製品の強み

Azure AD、G SuiteなどもIDaaSとしての機能は兼ね備えていますので、これらを認証基盤として利用することも可能です。しかし、IDaaSに特化した製品には、機能面で大きな強みがあります。
「Azure ADで全部実装できる」というスキルがある方はそれでもいいでしょうが、初心者が扱うにはなかなか大変だと思います。そこで、OneLoginやOktaといったIDaaSに特化した製品を導入するメリットについて述べていきます。

1.豊富なSAMLコネクタ
各種クラウドサービスとSAMLで連携するには、SAMLのコネクタを作成する必要があります。クラウドサービスによって仕様や挙動が異なるので、個別にSAMLコネクタを開発するのは結構大変な作業です。汎用的なSAMLカスタムコネクタを作成する機能を持っているIDaaSも多いですが、やはりハマることが多い印象です。
メジャーなIDaaS製品であれば、グローバルな各種クラウドサービスへのコネクタはあらかじめ用意されており、随時開発・リリースされています。ドキュメントやサポートもあるので、SAMLの専門知識が無くても簡単に連携設定が可能です。

2.ユーザー同期・プロビジョニング
IDaaSを導入して最も工数削減を実感したのが、ユーザー同期とプロビジョニング機能です。
IDaaSでは、Azure ADやActive Directoryなどのディレクトリサービスをユーザーディレクトリのマスタとして使用できます（オンプレのADの場合はAD Connectorをドメインコントローラにインストールする必要があります）。
そしてIDaaSに登録されたユーザー情報を、SAML連携している各クラウドサービスのユーザー情報に反映させることが可能です（これをプロビジョニングと呼びます）。

なお、外部のディレクトリサービスを使用せず、IDaaS自体をユーザーマスタとして単独で使用することも可能です（その場合はIDaaSのユーザーを直接編集することになります）。

ADと連携している場合は、AD上にユーザーが作成されると、自動的にIDaaS上にもユーザーが作成されます。FirstName、LastName、Emailといったプロパティも同期されます。
IDaaS上で作成されたユーザーに各クラウドサービスを割り当てると、更にIDaaSのユーザー情報を元に、各クラウドサービスのアカウントが自動的に作成されます（ライセンスの割当やカスタムプロパティの設定も、物によっては自動化可能）。

同様に、ADのアカウントを停止した場合は、IDaaSのアカウントも停止され、プロビジョニングしていた各クラウドサービスのアカウントも停止されます。つまり、各クラウドサービス毎にユーザーを作成・更新・停止する必要が無くなるため、アカウント管理の工数が大幅に削減されます。

例えば社内で20個のクラウドサービスを利用しており、入退社の度にアカウント作成・削除をそれぞれで行っていた場合、入社の度に一人あたり20回のアカウント作成オペレーションが必要だったのが、「ADのアカウント作成→IDaaSでのプロビジョニング承認」の1つのオペレーションで完結することになります。
退職処理の場合も同様に、ADアカウントを無効にすればIDaaSのアカウントも無効になり、各クラウドサービスのアカウントも停止されます。特に退職処理は速やかに対応しないと不正アクセスのリスクもあるので、セキュリティ面でも非常に安心感があります。
毎月何十人も入退社が発生するほどの規模の会社であれば、圧倒的な工数削減効果があります。

プロビジョニングについてもSAMLコネクタと同様に、IDaaSに特化した製品の方が、あらかじめテンプレートが用意されていたりプロビジョニング対応しているクラウドサービスの数も多いです。

3.セキュリティポリシーの統一
SAML連携を行うことによって、各クラウドサービスは認証をすべてIDaaS（IdP）に委任します。これは非常に強力で、各クラウドサービスへの直ログインをすべて遮断することとほぼイコールになります（厳密には各クラウドサービスの特権管理者のみ、SAML設定を変更する為の直ログインが許されます）。
そのため、クラウドサービス毎にアクセス制限を実装する必要がなく、多要素認証の仕組みが無いクラウドサービスでもIDaaS側で多要素認証を強制するといったことが可能です。

4.多要素認証
クラウドサービスは、ID・PWさえ知っていれば外部の第三者による不正ログインが可能という大きなリスクがあります。そのため、「アカウント情報以外に、本人しか持ちえない情報」を組み合わせた認証（＝多要素認証）が必要となってきます。利用できる要素は製品によって異なりますが、以下のような物が一般的です。
・ワンタイムパスワード（専用アプリ）
・物理トークン
・電話番号（SMS）
・生体情報

5.リスクベース認証
多要素認証は不正ログインを防ぐ為にはマストですが、オフィスから普段通りアクセスしているだけでも毎回多要素認証を求められるのは面倒です。オフィスのIPアドレスをホワイトリストに登録しておき、社外からのアクセス時のみ多要素認証を求めるというポリシーも設定可能ですが、ロケーションやネットワークに依存しない働き方が求められ、従来の境界型ネットワークの構成から変わりつつある現代では、あまり機能しないかもしれません。
その際に有力になってくるのがリスクベース認証です。
リスクベース認証とは、「普段の行動とは明らかに異なるログイン」や、「セキュリティポリシーを満たさないデバイスからのログイン」の場合のみ多要素認証を求めます。具体的には以下のようなケースです。
・物理的に明らかに離れた場所からの連続ログイン
・特定のセキュリティ設定が施されていないデバイスからのログイン
・Torなど匿名化プロキシ経由でのログイン

リスクベース認証はIDaaS自体に実装されている場合もありますし、サードパーティ製品と組み合わせて使用することも可能です。
詳細は各製品の情報を確認してください。

6.その他の拡張機能
IDaaS製品によってはRADIUSやLDAPなどの機能もあり、クラウドに限らず外部・内部システムのSAML以外の認証も集中管理することが可能です。
OneLoginではWindows/Macのデスクトップログインまで管理することができるので、ADすら不要になってくるかもしれません。

IDaaS製品の選定

IDaaSは国産製品よりも、グローバルでシェアが高い製品を選定した方が絶対に良いです。SAML対応しているアプリケーション数や導入事例も多いですし、信頼性（稼働率）も高いでしょう。
グローバルなIDaaS製品としては、今はOneLoginとOktaが2トップでしょうか。Ping Identityもよく名前を目にします。
IDaaS製品を選定するにあたり、気にしておいた方が良い点をいくつか紹介します。

1.SAML対応アプリケーションの数
IDaaS製品を導入しても連携対象のクラウドサービスが未対応だと元も子もないので、SAML対応しているアプリケーションを事前に確認しておくことが大切です。
OneLoginやOktaは数千以上のSAMLコネクタを提供していますが、国産のIDaaS製品だと数十しか対応していなかったり、SAMLではなくフォーム認証にしか対応していないクラウドサービスを「対応アプリ数」にカウントしていたりするので注意が必要です。（フォーム認証はパスワードマネージャと大差無く、クラウドサービスへの直ログインを防げる訳ではないので、利便性は向上してもセキュリティ面では何の効果もありません）

2.信頼性（稼働率）
構成を見て把握された方も多いかと思いますが、IDaaSは各クラウドサービスへのログインのSPOFになります。とは言っても、ログイン時にピンポイントでダウンしていなければ大丈夫なので、そこまでシビアではないですが。
メジャーな製品はStatusページでサービス稼働状況と合わせて過去の障害も公開していますし、その辺りも確認しながら選定するのがいいでしょう。（OneLoginは過去にセキュリティインシデントも起こしているので、気になる方はその辺りの経緯も確認した方がいいかもしれません）

3.管理画面
アカウント管理のオペレーションがすべてIDaaSに集約されるので、管理画面の使い勝手も重要です。私はOneLoginを使うことが多かったのですが、OneLoginは管理画面の使い勝手とログがイマイチで、その点は不満に思っています。Oktaは逆に評判良いですね。

4.機能・コスト
最終的にはこれが一番大きな判断軸になるかと思います。
各製品、エディションやオプションによって利用できる機能が変わってきます。プロビジョニングやリスクベース認証まで全部実装しようとすると、それなりのコストになっていたりするので、必要な機能とコストのバランスを見ながら選定するのがいいでしょう。
いずれの製品も評価利用が可能だと思いますので、一通り使ってみてから判断するのをオススメします。

実際に使ってみないとピンと来ないIDaaSですが、その便利さには目を見張るものがあります。
クラウドサービスが増えてきてからIDaaSを導入すると、各システムのSAML連携の調整が面倒なので、小さい規模であっても早い段階から導入しておき、今後利用するクラウドサービスもSAML連携ができることを全体に選定していくと、管理面でもセキュリティ面でもやりやすくなるのではないかと思います。

この記事が気に入ったらサポートをしてみませんか？