デジタル・トランスフォーメーシ…
企業におけるクラウドサービス利用が広がる中、煩雑なID管理やIDガバナンスの課題がクローズアップされています。クラウド活用におけるID管理の課題と解決策、また、SSO(シングルサインオン)の実現に必要な認証・認可情報の管理方法を解説します。
「2025年の崖」克服にむけて注目されるレガシーシステムのモダナイゼーションにおいて、Microsoft 365やG Suiteをはじめとしたグループウェアだけでなく、さまざまな機能がSaaSとして提供されています。
企業でのクラウドサービス利用は増加の一途を辿っており、2018年の調査で「何らかのクラウドサービスを利用している」と回答した企業は58%に上ります(※1)。この数字は年々増えており、複数サービスを利用する企業も増えてきました。
(※1)出典:総務省「令和元年版情報通信白書」https://www.soumu.go.jp/johotsusintokei/whitepaper/r01.html
目的や業務に応じて最適なクラウドサービスの使い分けが可能になった一方、ID/パスワードの管理には新たな課題が生じました。オンプレミス環境のID管理製品やシングルサインオン(SSO)基盤で一元的に管理されていたID/パスワードが、クラウド化されたことで管理対象外になってしまい、個別に更新を行う必要が出てきたのです。
(関連記事)SSO(シングルサインオン)とは?仕組みや認証方式、メリット・デメリットを徹底解説
クラウドサービス導入にまつわるID管理の課題は多岐に渡ります。新規ユーザの登録や退職者のID削除、人事異動や組織改編による権限変更といったシステム管理業務の増加やそれに伴う人件費増、人手作業によるスピードのばらつき、ミスも懸念されます。また、利用者の目線では、クラウドサービスごとに異なるID/パスワードでのログインが必要になるなど、利便性の低下が課題となります。
セキュリティ対策の課題もあります。セキュリティレベルがバラバラなサービスごとに、ガバナンス強化策を講じるには相応の時間がかかります。また、強化したガバナンスを安定的に維持するコストも無視できず、これを怠れば退職者IDの削除漏れによる不正アクセスなどのリスクが増大します。実際に2019年7月には、退職者IDが未削除であったために、不動産会社で利用していた外部情報提供サービスを退職者に不正利用される事件が起こりました。
クラウドサービスごとに異なるID/パスワードの管理が必要となることでサービス利用者の利便性が低下する課題に対しては、社内のActive Directory(AD)やLDAP Serverを源泉データとした各種クラウドサービスへの認証連携に対応するSSOの仕組みが必要です。
また、セキュリティの観点では、クラウドサービスの利用増加に伴い、企業のセキュリティ境界がネットワークからIDに変化している状況で、従来のID/パスワードだけでは情報保護の限界を迎えているという課題があります。現にハッキング関連の違反のうち、盗まれたパスワードや脆弱なパスワードに起因する割合が81%にのぼるという調査結果(※2)もあります。ID/パスワードだけでの情報保護の限界を踏まえ、PCI DSS(データセキュリティスタンダード)や経済産業省のクラウドセキュリティガイドラインでは、単体のパスワードの強度だけに依存しない対策として、多要素認証の導入が推奨されています。
(※2)出典:Verizon/2017 Data Breach Investigations Report
IIJでは、ID管理の課題を解決するために「IIJ IDサービス」を提供しています。同サービスではMicrosoft 365をはじめとした様々なクラウドサービスに対し、ADを起点としたシームレスなID同期や統合Windows認証、多要素認証を含む適切な認証条件でのSSOを実現しており、これまでに約3,000社以上にご利用いただいています。
さて、ユーザがSSOでクラウドサービスにログインするためには、前提として「サービス側でユーザIDが登録済みであること」が求められます。そのため、各クラウドサービスにあらかじめユーザ登録する「ユーザプロビジョニング」という作業が必要です。さらに、ユーザの属性情報に基づく適切な権限やロールなどの認可情報を設定する必要もあります。システム管理者が行うこれらの作業には大きく3通りの方法がありますが、それぞれの方法には個別の課題があるため、利用するユーザ数やクラウドサービスの数を見極めた上で費用対効果を検討し、適切な方法を選択しなければなりません。
1.は各サービスにログインして一つ一つ設定項目を入力するため、最も細かく認可情報を設定可能です。しかし、100名以上のユーザ規模では管理者の負担が大きくなります。また、異動や退職に伴うユーザIDの無効化・削除に対する負担も考慮が必要です。
2.はSAML(※3)2.0を用いた連携接続(SAMLアサーション)と同時に、SAML IDP(※4)側のユーザIDを元にSAML SP(※5)となるサービス上に自動登録/更新する SAML SP側の仕様です。本機能を提供するSAML SPとなるサービスへのID登録/変更が便利な反面、意図せずにユーザIDが増えてしまう可能性や、ユーザ登録はできるものの削除ができない点がデメリットとして挙げられます。また、SAMLアサーション内のデータに含まれる最低限の認可情報しか設定できないサービスがほとんどです。
(※3)SAML:Security Assertion Markup Languageの略称であり、標準化団体OASISによって策定されたシングルサインオンやID連携を行うためのXMLをベースにした標準規格
(※4)IDP:Identity Providerの略称であり、認証情報を提供する側のシステム。一般的にID管理製品やSSO基盤
(※5)SP:Service Providerの略称であり、認証情報を利用する側のシステム。一般的にユーザが利用するクラウドサービス
3.にはクラウドサービス側で提供されているAD等からの同期モジュールを利用する方法があります。これは導入やサポートの観点でとても便利ですが、あらゆるサービスが同期モジュールを提供しているわけではありません。
また、別の方法として、クラウドサービス側が用意しているプロビジョニングAPIを利用する方法があります。これはユーザ登録および削除が可能で、大変便利な仕組みです。主要なクラウドサービスではSCIM(※6)という仕様に準拠したAPIを用意しており、仕様の標準化も進んでいます。しかしながら、各サービス固有のユーザ情報や認可情報設定への対応は、SCIM自身に独自拡張を行っていたりすることで、各サービスの独自仕様に対する開発が不可欠なため、あまり普及が進んでいない状況です。
(※6)SCIM:Systems for Cross-domain Identity Managementの略称であり、SPMLの弱点であった相互運用性を向上させ、複数ドメイン間でユーザID情報のやり取りを自動化するための標準規格
ID管理製品単体であらゆるサービスのプロビジョニングAPIに対応することは、事実上困難です。この状況を改善するために、Web API Gatewayソリューションを活用することも考えられます。各サービスのプロビジョニングAPIの管理や実行が容易に可能になる方法です。具体的には、ID管理のリクエストがWeb API Gatewayソリューションを介してそれぞれのサービスに対して送信される形となります。そのため、管理者はそれぞれのサービスのプロビジョニングAPIを知る必要はありません。ただし、Web API Gatewayソリューションは高額になることが多いため、しっかりと投資対効果を判断する必要があります。
IIJでは、管理者が手作業で行っていたユーザ登録及び認可情報設定作業をロボティック・プロセス・オートメーション(RPA)で代替して管理者業務を一か所に集約、「IIJ IDサービス」とも連携し、認証と認可の情報を一元管理する「認証・認可情報共通管理ソリューション」を提供しています。
本ソリューションにより、従来製品では対応が難しいとされていた社内独自システムに対しても、RPAで認可情報連携することで、企業が利用するすべてのシステムを一元管理できます。また、リバースプロキシ方式の統合的なSSOやSaaSへのユーザプロビジョニングへも対応し、システム運用部門の業務効率を向上させると共に、ID管理業務の作業漏れを防いでガバナンスの強化を実現します。
クラウドサービスの積極的な利用に向けて、運用コストやガバナンスなどID管理に課題をお持ちの方は、IIJにお気軽にご相談ください。