企業がモバイルデバイスを活用するためのインフラストラクチャーとは？：新連載・これからのモバイル基盤（2/5 ページ）

[安納順一，ITmedia]

ユーザーIDのモビリティ

　企業ネットワークのセキュリティにおいて、利用者にとって最も身近な要素が「ユーザーID」だ。システムを利用する場合、その入り口で利用者は自分自身が「本人」であることをシステムに伝える必要がある。本人であることをシステムが確認するプロセスを「ユーザー認証」と呼ぶ。モビリティを考える上で最も重要なのは、「確実にユーザー認証が行える」こと。この「確実に」には以下の2つの意味が含まれる。

• どこからでも認証できる
• どこに対しても認証できる

　この2つが実現できて、はじめて「ユーザーIDのモビリティ」を実現できたと言える。

　例として、利用者が自宅から仕事を行うことを考えてみよう。自宅からメールサーバーなどの業務サービスにアクセスするには、はじめにユーザー認証が必要だ。マイクロソフトはユーザー認証を行うためのサービスとして 「Windows Server Active Directory ドメインサービス」（AD DS）を提供している。AD DSは通常社内ネットワーク内に構築され、そのままでは自宅からの認証要求を受け取ることができない。そこで、社外からの認証要求を社内に転送するための仕組みが必要になる。これを実現するのがWindows Server 2012 R2に実装されている「Web Application Proxy」（WAP）と「Active Directory Federation Service」（AD FS）だ。

APは社外からの認証要求を社内のAD FSに転送できる。認証前のユーザーが直接リソースにアクセスすることを抑止できるため安全性を向上できる

　WAPはWebアプリケーションへのリバースプロキシーとしての役割を持つほか、AD FSに対する認証プロキシーとしても動作する。インターネットから社内サービスへのアクセス要求を受け取ったWAPは、ユーザーに対して認証を要求する。ユーザーが入力したユーザーIDとパスワードは、HTTPSに乗せられて社内のAD FSに転送され、AD FSはさらにKerberosによる認証要求に変換してAD DSに転送する。ここでユーザー認証が正常に完了して、はじめてWAPはリバースプロキシーとして社内サービスをユーザーに公開することになる。結果的に、AD DSを外部に公開することなく、安全に社外からアクセスしてきたユーザーの認証要求を受け取ることができるようになる。

　これで全てが解決できたわけではない。リソースは社内だけでなくパブリッククラウド上にも存在するからだ。Office 365を例にとって考えてみよう。Office 365とはマイクロソフトが提供するSaaS（Software as a Service）だ。もちろんパブリッククラウド上に存在しているため、社内のActive Directoryドメインに参加させることはできない。認証の仕組みもAD DSとは異なるため、通常は社内リソースとクラウドの間では、認証は分断されてしまうことになる。

　このことは利用者のユーザーIDとパスワードが複数存在することになるとともに、管理の煩雑さも生じるため安全性上脅威となる面が増えてしまう。よって、パブリッククラウド上のリソースであってもガバナンスの効いた社内IDでユーザー認証を行えるのが理想だ。実は、Office 365には独自に認証基盤が存在している。これを「Azure Active Directory」（AAD）と呼ぶ。「Active Directory」という言葉が入っているが、オンプレミスのAD DSとは全く別物である。AADにはAD DSのようにActive Directoryドメインを構成したりグループポリシーを配布したりする機能は存在していない。持っているのはクラウドサービスに対する認証とアクセス制御機能だ。もちろん、AD DSと通信するような機能も無いため、Office 365の認証要求をAD DSから直接受け取るといったこともできない。そこで先出のAD FSが大きな役割を果たす。

　AD FSはAD DSで正しく認証したユーザーに対して、「SAMLトークン（セキュリティトークン）」と呼ばれるチケットを発行する機能を持っている。一方で、AADはSAMLトークンを受け取る機能を持っている。つまり、AD FSが発行したSAMLトークンをAADに渡すことができれば、結果的にAD DSの認証結果をAADに転送できることになる。このやり取りは標準プロトコル化されており、「WS-Federation」（ダブルエスフェデレーション）と呼ばれている。この仕組みを使用すると、異なるアイデンティティプロバイダー（IdP）に登録されているユーザー同士をマッピングできるため、AD DSで認証された「ユーザーA」はAADの「ユーザーA」と同一人物であることが確認でき、結果としてAD DSで認証されたユーザーがOffice 365を利用できる。