はじめに
本記事では、企業や組織において業務で利用されている Active Directory Federation Service（以降、ADFS）を移行しなければならない背景のおさらいと、将来テクノロジーがさらに発展していく想定での提言をしていきます。
ADFS 移行のきっかけは、大きく分けて下記の 6 つがあります。
・データセンターの契約満了
・事業継続性
・キャッシュフローの問題
・サイバーセキュリティの脅威
・IT 予算、リソースの不足
・急増するアプリケーション需要への対応
この中でも、「急増するアプリケーション需要への対応」について取り上げます。
急増するアプリケーション需要への対応の背景
アプリケーション需要が急増した背景は、アプリケーションのオンライン化が進み、SaaS と呼ばれるクラウドアプリケーションの利用が多くなってきたことが挙げられます。そして、オンライン会議や電子化されたデータを扱う業務のため、毎日 2 つ 3 つのツールを従業員の方が使うことが当たり前になりました。さらに、昨今の状況から、自宅や遠隔地からリモートワークを行う必要性があります。この時、モバイルデバイスから社外ネットワークを通じてアプリケーション利用するシーンが確実に増えています。このような背景から、従来の利用シーンと比較して想定を超えるニーズが出てくるようになってきました。
利便性の確保
急増するアプリケーション需要への対応として、利便性が求めらるようになるのは言うまでもありません。従業員の方は、アプリケーションごとにバラバラの ID を使うことを望んでおらず、１つの ID でアプリケーションを使いたいと思うはずです。多くの企業において、Identity as a Service（以降、IDaaS）とよばれるクラウドサービスの導入によって、クラウド環境の ID の一元化が進んできました。IDaaS の例の 1 つに Azure Active Directory（以降、Azure AD） があります。Azure AD は Office 365 に組み込まれているため、既にご利用いただいているお客様が多くいらっしゃいます。すでに利用中の IDaaS が存在していれば、投資を抑えながら、アプリケーション認証基盤としての展開が可能です。
よくある課題と目指すべきゴール
ADFS からの移行を検討する段階で、よくある課題があります。プロジェクトを進める時に立ちはだかる 2 つの壁について紹介します。
1 つ目の壁: アプリケーションの認証をイントラネット内で完結させることが必要となっているため、Azure AD のようなクラウドサービス上で認証を行うことがポリシー上で許可されない
2 つ目の壁: アプリケーションへのアクセスを社給デバイスのみに制限したい。ADFS の証明書認証を使って実現しているため、容易に移行できない
上記は社内と社外にネットワーク境界を設けた防御設計に沿った、非常に強固な考え方です。しかし、最近では、様々な場所から多様なデバイスを利用できることが、従業員の生産性向上に寄与しています。そのため、既存の ADFS を含むオンプレミスのインフラ基盤では、技術・運用の両面で対応が難しくなってきました。
例えば、下記のようなニーズが挙げられます。
・社給デバイスではない個人所有の端末（BYOD）を使いたい。
・証明書が入った端末のみに制限するだけでなく、より動的な適用型アクセス制御を行いたい。
・クラウドのエンドポイント セキュリティ ソリューションと連携して、ID や端末が保護されている状態を条件にアプリケーションへのアクセスを許可したい。
このような新しいニーズに対しては、クラウドで予め実装されたソリューションを持っている Azure AD で素早く対応することが出来ます。
強調しておきたいのは、ADFS を使ったアクセス制御の考え方と本質は同じであるということです。安全なネットワーク、デバイスからアクセスされるべきというセキュリティの考え方に基づいて、実装をアップデートしていくことが ADFS 移行の目指すべきゴールであると言えるでしょう。
まとめ
アプリケーションの観点から、ADFS からの移行が必要な理由を紹介しました。IDaaS によるアプリケーション認証の統合を推進していただけそうでしょうか。
これからアプリケーション認証を ADFS から移行しようとしている方の参考になれば幸いです。
次回の記事では、ADFS からアプリケーション認証移行を設計する前に知っておきたい事について掲載する予定です。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。