Vittorio Bertocci氏インタビュー
開発者にとってのAzure Active Directoryの役割と今後の展開
米マイクロソフトのVittorio Bertocci氏に、Azure Active Directoryの概要と、今後の流れの中でIT管理者や開発者にとってのクラウド上のアイデンティティ基盤の役割についてインタビューした。
2014年1月14～15日に世界的に見ても最大規模のアイデンティティに関するイベントである「Japan Identity & Cloud Summit 2014」が東京で開催された。今回のメインテーマは「アイデンティティから考える。クラウド・ビッグデータ・モバイルの興隆」であり、2日間でエンタープライズ、コンシューマー、アカデミック、ガバメントなどさまざまな方面から1000名を超える来場があった。
イベント2日目のエンタープライズ向けトラックの中で、サービスとしてのアイデンティティ（IDaaS：Identity as a ServiceやIdMaaS：Identity Management as a Service）の領域で実際にサービスを提供しているMicrosoft Azure（旧称：Windows Azure） Active Directoryについて、米マイクロソフト・コーポレーションのプリンシパル・プログラム・マネージャーであるVittorio Bertocci氏から、企業のIT管理者や開発者にとってクラウド上のアイデンティティ基盤を利用するメリットは何なのか、マイクロソフトが目指している方向性は何なのか、について講演があった。
イベント期間中にVittorio Bertocci氏にAzure Active Directoryの概要、および今後の流れの中でIT管理者や開発者にとってのクラウド上のアイデンティティ基盤の役割についてインタビューを行うことができたので、本稿でその内容を紹介する。
■
―― まず自己紹介をお願いします。
Vittorio（以下：V） はい、私はAzureグループの中のActive Directoryチームでプログラムマネージャーをしています。主な担当はデベロッパーエクスペリエンスで、開発者がマイクロソフトのアイデンティティプラットフォームを使いやすくすることがミッションです。具体的には開発者を支援するライブラリの開発をしており、Windows Phone、Windows、Windowsサーバー、Azureなどのマイクロソフトの製品／プラットフォームだけでなく、iPad、Android、Javaアプリケーション、Node.jsなどの非マイクロソフトプラットフォームからでも開発者がセキュリティやアイデンティティ関連の機能を簡単に実装できるようにすることを目指しています。
Active Directoryの再創造とは？
―― 2012年にマイクロソフトは「Active DirectoryをIDaaSプラットフォームとして再創造する」と宣言しました。その再創造のキーポイントは何だったのでしょうか？
Active Directoryの再創造
2012年5月23日にAzureチームのBlogで、マイクロソフトがどのようにActive Directoryをサービスとして再創造していこうとしているのかが紹介された。詳しくは下記のリンク先を参照されたい。
V まず、マイクロソフトがActive Directoryを再創造することになったきっかけについてお話しします。これまでActive Directory（Windows Server Active Directory）は企業の中心としてイントラネット（ドメイン）を管理するために使われてきており、エンタープライズ企業の95％以上に導入されるなど、非常に大きな成功を収めてきました。しかし「Office 365をはじめとする、クラウド上で提供される非常に大きなスケールのサービスへの対応」という面ではスケーラビリティや負荷という面で従来とは違う考え方が必要になってきていました。
そこでマイクロソフトは、従来のWindows Server Active Directoryを拡張する、というアプローチでアイデンティティ基盤についてもクラウドへ足を踏み入れる選択をしました。オンプレミスは従来どおり1つのディレクトリで管理を行い、オンプレミスのアイデンティティがクラウド上にも反映される、というハイブリッドな形態を取り、さらにクラウド上のアイデンティティ基盤は地域間レプリケーションやマルチテナント対応で複数の企業からの同時利用に耐えられるようにして、SaaSアプリケーションなどへ対応できるようにしました。
しかしマイクロソフトのアイデンティティに関するゴールは一貫しており、たとえ企業の資産の置き場所やサービスの提供形態が変化しても、企業の資産を最良の方法で管理できるように支援をすることです。
―― Azure Active Directoryが提供される前にもクラウド上のアイデンティティ基盤としてLive IDや.NET Passportを提供していたと思いますが、それらのサービスとAzure Active Directoryでは何が違うのでしょうか？
V Live IDは現在、「マイクロソフトアカウント」と呼ばれており、現在でもコンシューマー向けにサービスを提供しています。マイクロソフトアカウントはWindowsへのサインインやoutlook.comやSkypeなど個人を対象としたサービスを利用する上で有用な機能を提供しています。
一方でAzure Active Directoryは企業・組織での利用されることを想定しており、例えば人事システムや、企業で利用するアプリケーションと連携して統一ポリシーを適用するなど、企業がビジネスを行う上で有用な機能を備えています。
開発者にとってのActive Directoryとは？
―― なるほど、あくまで企業や組織が管理をするための基盤である、というところは、従来のWindows Server Active DirectoryとAzure Active Directoryに共通した考え方、ということですね。
ただ、これまでのWindows Server Active Directoryは「IT Pro向けのインフラ基盤」という意味合いが濃かったように感じますが、Azure Active Directoryは「開発者向けのプラットフォーム」という色が濃いように見受けられます。意識的に位置付けを変えているのでしょうか？
V 振り返ると、「Windows Server Active Directoryは、これまでで最も成功した開発者向けのプラットフォームだった」と言えると思います。開発者がアプリケーションを開発する際、ドメインの中で実行されてさえいれば、Windows Server Active Directoryはネットワークと同様に低レイヤーのスタックで動作し、透過的に認証を実行できました。また、アプリケーションからアイデンティティ情報を利用したければ、LDAPクエリを実行することで必要な情報を取得することもできました。このように、これまでも多くのビジネスアプリケーションがWindows Server Active Directoryをアイデンティティ基盤として開発されてきました。つまり、これまでもWindows Server Active Directoryは開発者向けのプラットフォームとして、（見えないところで）機能してきた、ということです。
しかし、クラウドシナリオにおいては複数の企業がSaaS型アプリケーションを使うので、これまでのようにアプリケーションや利用者が同一ドメイン内に入ることは不可能です。つまり、これまでアイデンティティ基盤はインフラレイヤーで動作していましたが、クラウドの出現により、上位のレイヤーでアイデンティティ基盤を動作させる必要が出てきたのです。
しかし、基本的な考え方は従来とあまり変わっていません。例えば、SAMLやOpenID Connect、ws-federationなどのHTTPベースの仕組みであっても、従来のドメインにおいて、よりネットワークに近いレイヤーで透過的に動いていたKerberosであっても、アプリケーションに組み込んだ認証モジュールはほぼ似たような動きをしています。ただ、SAMLやOpenID Connect、ws-federationはアプリケーションに近いレイヤーで動作しているため、開発者はこれまでに比べると少々コードを書く必要があります。そのためマイクロソフトは開発者が簡単に実装できるようにライブラリを提供しています。
なお、どうしても従来どおりのアプリケーション開発をしたい場合は、IaaSであるAzure VM上にWindows Server Active Directoryを配置してVPNで企業内ネットワークと接続する、ということも可能です。しかし、Azure上のリソースをより多く消費してしまいコスト面で高価になってしまうため、今後、多くの企業は新しいシナリオでアプリケーション開発をする、という選択をしていくと考えています。
―― 開発者によって認証プロトコルの内部的な動きは見える方がよいのでしょうか？ それともこれまでのように隠ぺいして簡易に使えた方がよいのでしょうか？
V 全ての開発者がプロトコルの詳細まで意識する必要はないと考えています。アメリカの開発者はアプリケーションの前段でミドルウェアとしてライブラリがプロトコルを吸収してくれることを好むように感じています。大切なのは動作プラットフォームに制限がないことだと考えており、より多くのプラットフォームをサポートするライブラリを提供していこうと考えています。
もちろんプロトコルの詳細な動きまで見えた方がよいという開発者もいますが、SAML、OpenID Connect、ws-federationなどのモダンなプロトコルはシンプルなプロトコルなのでライブラリを使わなくても実装することは十分に可能だと思います。
Azure Active Directoryを使うメリットとは？
―― なるほど。では今後、SaaSアプリケーション開発者が、VPNを使って従来どおりのWindows Server Active Directoryを使う代わりにAzure Active Directoryを使うことで得られるメリットは何でしょうか？
V これは私がAzure Active Directoryの持つ機能の中で一番好きな機能なのですが、最大のメリットはAzure Active Directoryがアプリケーションへのプロビジョニングを標準化したことにあると考えています。
これまでSaaSベンダーにとって一番の問題点は複数の企業にアプリケーションを提供する際に、使われ方や構造の異なる各企業のディレクトリと接続することでした。たとえ95％以上の企業でWindows Server Active Directoryが導入されていたとしても、標準的な使い方が定義されていたわけではありませんし、企業ごとに使っている機能や使い方は異なりました。
しかし、Azure Active Directoryはそれ自身がクラウド上に展開されているため、使い方は統一されており、同じ機能、同じエンドポイントで複数の企業のディレクトリと自動的に接続をすることができるのです。同時にSaaSアプリケーションからも統一された方法でAzure Active Directoryを使うことができるため、会社ごとにカスタマイズされた方法でプロビジョニングを構成する必要がなくなるのです。つまりアプリケーションからは統一されたAPIでアイデンティティ情報を取得できますし、会社ごとに企業ファイアウォールを超えて人事データファイルをアップロードする必要もありません。
また、他のメリットですが、Azure Active Directoryはオープンなプロトコルをベースに実装されているので、どのようなプラットフォームからでも利用できます。基本的にすべでのインターフェースはHTTPベースで実装されていますし、ライブラリやSDKも多くのプラットフォーム向けに提供しているため、例えばPythonで開発したアプリケーションからライブラリを使ってAzure Active Directoryを利用する、ということも可能です。
―― 非マイクロソフト製品や.NET以外の言語用のライブラリを提供しているのは、そのような思想に基づいたものだった、ということですね。
では、一方でIT管理者・IT Proにとってのメリットにはどのようなものがあるのでしょうか？
V ひと言でいうと、管理者に力を与えることができる、ということです。最近の流れとしてユーザーはクラウド上のSaaSアプリケーションをより簡単に利用できるようになりましたし、複数の企業のユーザーが複数のアプリケーションを使って情報を共有できるようになりました。そのような環境の中、「オンプレミスのディレクトリを拡張する」というアプローチをベースとしたAzure Active Directoryを使うことで、IT管理者は従来と同様なレベルで、クラウドについてもガバナンスを利かせることができるようになります。Azure Active Directoryは「オンプレミス」「クラウド」「アプリケーション」が接続された中央ハブとして動作するため、データやアクセスの流れがどのようになっているのか、何が起きているのかを可視化できるため、IT管理者はより優れた洞察を得ることができます。
また、オンプレミスでは実装するのが非常に難しかった優れた機能をAzure Active Directoryは持っています。例えば多要素認証などがそれに該当しますし、他にも多くの優れた機能を持っています。
マイクロソフトが意識するオンプレミスとクラウドのハイブリッドシナリオとは？
―― 最近マイクロソフトはオンプレミスとクラウドのハイブリッドシナリオを強く意識しているように思われますが、具体的にどのようなシーンを想定しているのでしょうか？
V 複数の方式があると考えています。繰り返しになりますが、Azure Active Directoryは既存のWindows Server Active Directoryを拡張するものです。そのため、企業のIT資産の半分をオンプレミス、半分をクラウドに配置する、というシーンも想定できますし、全ての資産をクラウド上へ移行して企業内から利用する、というシーンも想定できます。
基本的にすぐに全てのアプリケーションをクラウド上に移行するのは難しい場合が多いと思われるため、例えばWeb技術を利用しているアプリケーションを選んでクラウドへ移行し、レガシーなアプリケーションは従来どおりオンプレミスに配置する、という形が一番考えやすいのではないかと思います。
一方で、サーバー統合のようなケースも想定しておく必要があります。これは仮想化テクノロジーを利用して従来のアプリケーションを何も変えずにクラウドへ移行する、というシナリオです。このような場合は先にもお話ししたようにIaaS上にドメインコントローラを配置することも可能です。
さらに小規模な企業においては全てのリソースをクラウド上に展開してしまう、ということも考えられると思います。Azure Active Directoryは5万オブジェクトまでは無料で利用できますので、メールやドキュメント共有などをクラウド上で利用する分には十分に活用できると思います。
このように各企業の置かれている状況や利用シーンによってさまざまな方法でWindows Server Active DirectoryおよびAzure Active Directoryを利用することが可能だと考えています。
セキュリティから見たAzure Active Directory
―― 別の視点ですが、セキュリティの観点から見たAzure Active Directoryの役割は何だと考えていますか？
V なかなか難しい質問です。組織の種類や使い方によっても異なります。例えば企業や組織から外部のサービスを使うためのアイデンティティ基盤なのか、企業リソースやサービスに対して顧客がアクセスするためのアイデンティティ基盤なのかによっても大きく異なると思います。
Azure Active Directoryが提供している機能として、利用者自身によるパスワードリセットや、デバイス管理のためのデバイス・レジストレーション・サービス、多要素認証などはもちろんセキュリティ上、重要な機能だと言えますが、もう少し大きな視点で見てみると、最も重要なことはAzure Active Directoryは包括的なハブとして各種サービスや資産と接続されている、ということだと思います。全てのサービスや資産が接続されているということは、統一されたポリシーを適用するのに最適な場所である、と言い換えることができると考えているためです。
例えばサービスがおのおので認証機能を持っている場合を想像してみてください。現状はこのような構成のサービスが多いと思いますが、この場合、それぞれのサービスに対してセキュリティポリシーを適用・管理する必要がありました。これを、中央にある一カ所で適用・管理していきたい、というのは自然な流れです。これはWindows Server Active Directoryが2000年に登場する前の状況に似ています。当時はWindows for WorkgroupやNovell NetWareを使って企業内の情報資産を個別に管理していましたが、全てのアプリケーションをローカルネットワーク上で実行されていましたし、数も少なかったので管理者は各アプリケーションやユーザーがどこで何をしているのかを把握できており、それほど大きな問題にはなりませんでした。しかし規模が大きくなるにつれて、一カ所で集中管理をしていきたいという要望が大きくなり、Windows Server Active Directoryが登場した際、その役割を果たしたのは自然な流れでした。
以降、クラウド化の流れも手伝い、さまざまな場所にアプリケーションなどの資産が配置され、フェデレーションプロトコルの発達により連携して便利に利用することは容易になりましたが、結局は企業の望む形で資産を一元的に管理できる場所が求められてきているのだと思います。
―― 企業のIT管理者の中にはセキュリティシステムをクラウドなどの外部へ出したがらない人も多いのですが、どう考えますか？
V さまざまなケースがありますし、今日の常識が明日通用するかどうかは誰にも分からないことなので、今後それらの考え方は変わっていくと思いますが、事実、自宅や外出先からのリモートアクセスなどインターネットを経由したシステムへのアクセスを考慮しないことは不可能になってきています。その際にインターネットからアクセスされる可能性があるシステムを自前で運用することを考えるとスケーラビリティやセキュリティ面での考慮が相当に必要となります。その点、すでにプロバイダー自身が提供するSaaSアプリケーションからのアクセスを含め、大量のアクセスをセキュアに運用している基盤を使った方がより安全である、ということが言えると思います。また、別の視点ですが電力消費の観点においても自社で設備を持つのに比べるとコストメリットが出てきます。
今後のアイデンティティ基盤に関するトレンドは？
―― 時代は変わっても大きな意味ではアイデンティティ基盤に求めることは変わらない、ということなのかも知れませんね。今後、アイデンティティ基盤に関するトレンドはどのようになっていくと考えていますか？
V マイクロソフトとしての回答をするのは難しいので、あくまで個人的な考えとしてですが、最も大きなトレンドの1つは「プログラマブルWeb」、つまり全てがAPIベースで稼働する世界です。さまざまなアプリケーションやシステムがAPIを公開し、それらの境界をまたいで大きなシステムが構成されていて、システム同士が利用者の代わりにAPIを利用して情報や機能のやりとりをしていく、という形です。これはFacebookやTwitterなどのようにコンシューマー市場ではすでに主流となっている考え方ですが、今後はエンタープライズ市場でも重要になっていくと考えられます。
もう1つは非常に将来性がある領域として考えているのが「機械学習」です。ビッグデータは一般に、データをふかんする1つの新しい方法として注目されており、多くの領域でイノベーションを起こしていますが、アイデンティティはその中で重要な位置を占めると考えています。いわゆるドミノ現象のような話ですが、全てのデータとひも付けられている中央ハブとしてアイデンティティ基盤が振る舞うことになるので、データ収集を行うためのキーポイントになることは自然なことだと思います。例えば、アイデンティティにひも付いたデータからは、「人々がどうやってモノを使っているのか」「人々がどうやってビジネスを遂行しているのか」などが見えてくるので、複数の組織が重複した機能を持っていないか、などの分析ができるようになり、ビジネスの最適化などに寄与できると思います。このようにふかん的にモニタリングし、レポーティングやサジェストを実現していくための最初のステップは、より多くのデータを得ることであり、そのためにはクラウドへ出ていくことだと考えています。より大きな効果を得るためにはマイクロソフトのプラットフォームの中だけに閉じるのではなく、クロスプラットフォーム、クロスボーダーであるべきだからです。
関連するキーワードとして、もちろん「IoT（Internet of Things）」も重要です。センサーデバイスがネットワークに接続され、個人はどこへでもデバイスを持ち歩きますが、ユーザーのアクセスやサービスのデリバリには必ずアイデンティティが利用されます。こうなると全てのデバイスがアイデンティティの要素に組み入れられることになるので、アイデンティティ基盤に関する考え方に非常に大きな影響を及ぼすと思われます。
開発者に向けたアドバイスは？
―― 最後に日本の開発者に向けたアドバイスはありますか？ 例えば今後、新しい技術の登場やトレンドの変化に強いアプリケーションを開発するにはどうすればよいか、などあれば教えてください。
V とても面白く、かつ難しい質問ですね。これまで、典型的に新しいプロトコルは突然登場するのではなく、特定のニーズやシナリオに対する解として出てきます。例えばOpenID Connectを例に取ると、OpenID Connectは「サインイン」と「アプリケーションが他のリソースへアクセスするためのトークンの取得」という2つの要素を一元化するものです。しかし過去にもこのシナリオは実現可能なものでした。サインインはws-federationでも同じことは可能でしたし、バックエンドアクセスのためのトークン取得はws-trustでも実現できていました。ただ、柔軟でもシンプルでもなかった、というのが一番の問題であり、OpenID Connectの登場のきっかけになりました。
現在、.NETのコンポーネントはws-federationやws-trustをサポートしていますが、OpenID Connectについてもサポートをしようとしています。ただその時に開発者から見てアイデンティティの使われ方を変えない、ということを主眼に置いてライブラリを提供していこうと考えています。例えば、現在アイデンティティを扱うのに「IClaimsIdentity」というインターフェースを使っていましたが、開発者は裏側のプロトコルがws-federationなのかOpenID Connectなのかを意識する必要はありません。
また、現在開発している「OWIN（Open Web Interface for .NET）」という次世代のアイデンティティライブラリについては、これまでのASP.NET／IISをベースのものから、セルフホストできるようにしてプラットフォーム制約を取り除いています。開発者は既存のアプリケーションを改変する場合は、モジュールをASP.NET／IISベースのものからOWINに変更し、利用プロトコルをOpenID Connectにするだけでモダンなアイデンティティ基盤に対応できるようになります。われわれはこの新しいライブラリを設計するにあたり、極力、ソースコードへの改変が少なく済むようにしているため、現在、.NETのライブラリでws-federationを使ったアプリケーションを開発しているような場合は、簡単にOpenID Connectに対応させることができます。
―― インターフェースの抽象化により利用する要素技術が変わってもビジネスロジックやビルディングブロックには影響を及ぼさないように設計をする、という意味でアイデンティティ・メタシステムの概念とよく似ていますね。
V アイデンティティ・メタシステムはフロントのミドルウェアでプロトコルの違いなどを吸収してアプリケーション自体は何も変えなくて済むようにする、という考え方でしたので、その意味では非常に似た概念だと思います。
いずれにしてもアプリケーションのロジック部分と認証や認可などアイデンティティに関連する部分を切り分けておき、かつ各種ライブラリなどをうまく活用することで変化に強いシステムを開発していくことが可能と言えると思います。
―― ありがとうございました。
