New Normal に向かい、様々な分野でクラウドの活用が進んできていると思います。
その中から、今回はIDaaS（クラウドID）について、ネットワークにどの様な影響が出てくるかを考えてみたいと思います。
多くのエンタープライズでは、ユーザIDの管理はMicrosoftのActive Directory（AD）や、OpenLDAPなどのLDAPサーバを利用し、ネットワークの認証、特にWi-Fiの802.1X認証でRADIUSサーバとADを連携させていると思います。
このAD/LDAPを単純にクラウドインフラに持っていくだけであれば、今までとそこまで大きな違いは出ませんが、（通信経路の暗号化や遅延の問題はありますが）
Microsoft Azure Active Directory,
Google Cloud Identity,
Oktaなど多くのクラウドベンダーがIDaaSとしてID管理製品の提供を始めています。
特にOffice 365を使っていたり、オンプレADのクラウドへの移行先としてAzure ADを検討しているユーザが多い気がします。
まだ認識が少ないのですが、これらIDaaSを使った時、ネットワーク認証は今までと大きな変更が求められます。
最も大きな違いは、Azure ADがLDAPを直接サポートしていない点にあります。（
Azure AD FAQ）
その結果、ネットワーク認証で必須の802.1Xがそのままだと実現できなくなってしまいます。
LDAPの代わりにIDaaSがサポートしているのが、SAMLやOAuthなどのWeb系のプロトコルです。
この時、単純にネットワーク認証をCaptive Portal（Web認証）にすればいい様にも思われますが、そこでまた落とし穴があります。
特に、Wi-Fiの802.1X認証では、以下にある様にその仕組みの中で無線区間通信の暗号化が含まれています。逆にWeb認証では無線区間の暗号化が考慮されていません。
PSKと組み合わせることも可能ですが、それはそれでKey管理の課題があるため、Wi-Fi屋の私としては、どうにかして802.1Xを使いたくなります。
そこで便利なのが、
Onboard (端末のセルフプロビジョニング)という仕組みです。
Aruba ClearPassは、RADIUSサーバとしての機能だけでは無く、端末のOnboardをすることができます。
このOnboardは、簡単に解説すると、端末がWi-Fiにアクセス、ClearPassのOnboard用Webページリダイレクトさせ、そこでWeb認証をすることで、ユーザIDに応じた端末のプロビジョニングを実行し、クライアント証明書をインストールすることができます。
つまり、
OnboardのWeb認証でIDaaSと連携、クライアント証明書をインストールし、Onboard後は今まで通りの802.1X認証を利用することができます。
まだまだIDaaSはアプリケーションレイヤでの連携が中心でネットワークレイヤでの連携は少ないですが、
上記の通り、Onboardを使うことでネットワーク認証にも簡単に活用することができるので、
クラウド化、As a Serviceの活用促進に、是非ClearPassも活用してみて下さい。
こうなってくると、次はRADIUSサーバもクラウドに持って行きたくなるかもしれませんが、それはまた別の機会にお話します！
------------------------------
Keita Shimono,
Aruba Japan SE Manager & Technical Lead
------------------------------