テレワーク普及で注目必至　“クラウド型ID管理”の強力ベンダー、Oktaがいよいよ日本に本格進出か　その強みと課題を先取りしよう：幅広い連携機能がポイント（3/3 ページ）

» 2020年06月11日 07時00分 公開
[谷川耕一，ITmedia]
前のページへ 1|2|3 　　　　　　

Oktaが目指す「ID管理のプラットフォーム」は、日本でどう生きるのか

　「競合はいない」――そんな強気の発言を繰り出すOktaとのやりとりで目立ったのは「ID管理のプラットフォームを目指す」という姿勢だ。この姿勢は、Okta Identity Cloudの方向性を具体的にどこへ導くのか。Celioの浅井氏は「Okta Identity Cloudは、プラットフォーム化のためにSaaSだけでなく、ワークフローやアナリティクス、CASB、さらには『Jamf』や『MobileIron』などのデバイス管理サービスとも連携の幅を広げています」と話す。

　ユーザーにとって、ID管理プラットフォームの連携先が広がるメリットは大きい。例えば、セキュリティ要件を満たすため、アプリケーションへのアクセスにIPアドレス制限をかけたとしよう。ネットワーク環境の変更でユーザーのIPアドレスが変わった際、Ciscoなどのネットワークセキュリティ製品では把握できてもIDaaS側では把握できず、ユーザーから見れば「認証情報は変わっていないのに、いきなりアクセスを拒否される」という事態につながりかねない。ネットワークセキュリティ製品とOktaを連携させて「Ciscoのこのルーターからのアクセスは信頼できる」としておけば、IPアドレスの変更を気にせずに安全なSSO環境が維持できるというわけだ。

　同様に、CASB（Cloud Access Security Broker）とOkta Identity Cloudを連携させれば、CASB側で不正なクラウドサービスを検知した場合にOkta Identity Cloud経由で当該サービスの利用を止められる。また、JamfとOktaを連携させれば、モバイルデバイスのアクセス管理もできる。「SaaS以外との連携が充実してきたことが、Okta Identity Cloudのプラットフォーム化の現れです」と浅井氏は指摘する。

日本での進出を阻む壁？　代理店が明かす「日本のSaaSに潜む課題」とは

　多くの強みを持つOkta Identity Cloudだが、日本市場での展開に当たっては、1つ見逃せない課題がある。それは日本の多くのSaaSが、SSO向けの認証規格であるSAML（Security Assertion Markup Language）に対応していないことだ。SAML非対応のSaaSでSSOを実現する場合、連携の仕組みを個別に構築しなければならない。

　SAMLはグローバルで利用されるSaaSのほとんどが採用していて、その認証フローはサービスプロバイダー（SP）をSSOの起点とする「SP-initiated」と、ユーザー（Identity Provider）を起点とする「IdP-initiated」の2種類に分かれる。複数のSaaS間で認証情報を連携させる場合、SaaSが後者のIdP-initiated方式でSAMLに対応していることが重要になる。SP-initiatedのみに対応しているSaaSと他のSaaSを連携させる場合、ユーザーはSSOのためだけに前者にログインしなければならなくなるためだ。

　「日本のSaaSの場合、仮にSAMLに対応していても、SP-initiatedだけでIdP-initiatedに対応していないものも多いのです」と浅井氏は指摘する。

　「日本のSaaSには、ぜひIdP-initiated SAMLに対応してほしいです。そうしないと、毎回誰かがID連携の仕組みを作り込むことになり、それはかなりの無駄です」（浅井氏）

　COVID-19終息後もテレワーク環境は継続され、日本でもSaaSの利用はさらに増えるだろう。そうなれば、IDaaSの採用も増加するはずだ。認証規格への対応度合いも含めた日本市場の変化がどれだけのスピードで実現するかが、Oktaを含めたIDaaSの市場の今後を左右するかもしれない。

前のページへ 1|2|3 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ