本日（2019年3月16日) MS の海外エンジニアであるSue Bohn @Sue Bohn さんが、下記 Blog をポストしており、興味深かったので紹介したいと思います。
Azure AD Mailbag: Discovering and blocking legacy authentication
Blog URL:https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-AD-Mailbag-Discovering-and-blocking-legacy-authentication/ba-p/369725
簡潔に言ってしまうと、レガシー認証を使っていないのなら、セキュリティ対策のために、条件付きアクセスでブロックしましょう！っていう内容なのですが、そもそもレガシー認証って何？モダン認証って何？という方もいる(私も弊社 join 前はそうでした)と思いますので、Sue さんが何を言っているのかについて、個人的解釈も交えて記したいと思います。
Q1 「レガシー認証って何？なにがいけないの？」
一般的には、レガシー認証とは、「ユーザー名」と「パスワード」を使ったごくごく基本的な認証方法です。また、最近ではよく利用されている、「多要素認証」を強制することがプロトコル的に不可能です。
一方、モダン認証は、多要素認証を要求することができ、ブラウザーを使って、ポップアップ表示で、設定することができます。
例えば、「ユーザー名」と「パスワード」で認証したとに、メールで送られてきた「セキュリティー コード」を入力したり、登録済みの携帯電話に、通知が送られてきたり、携帯電話に電話がかかってきて、「自分だけが」認証することができるようにすることができます。
その他に異なる点としては、レガシー認証はネイティブアプリやクライアント サービスが、資格情報を格納して、 その資格情報をIMAP サーバーなどの認証サーバーが検証を行います。ネイティブアプリやクライアント サービスは安全な通信として資格情報を取り扱うために信頼されています。
モダン認証においては、資格情報は信頼された認証機関、例えば Azure AD や AD FS サーバーにリダイレクトされ、認証が完了した後に「ユーザーに代わって」、アプリケーションやサービスにトークンが発行されます。
例えば、レガシー認証の代表的なプロトコルとして、「POP3」「IMAP4」や「SMTP」があります。
対して、モダン認証において使わるプロトコルとしては、「MAPI」や「EWS」があります。
#####私的見解
文面だけだとイメージしづらいかと思いますので、具体的にレガシー認証とモダン認証の画面イメージを下記に貼ります。
こちらがレガシー認証で利用している Thunderbird の設定画面です。
シンプルに、「メールアドレス」と「パスワード」で認証しますよね、逆にいうと、「メールアドレス」と「パスワード」さえ合っていれば、
このメールクライアントは使えるわけです。(Thunderbird もモダン認証対応しているはずです、あくまでこれは一例です)
そしてこちらは、モダン認証の画面イメージです。
１枚目は Office 365 にサインインする時のサインイン画面です。
画面上部に注目してください、 URL でブラウザー形式でアクセスしていますよね？
また、こちらは AD FS の認証画面ですが、こちらもブラウザー アクセスしていますよね。
さて続きですが、レガシー認証の何がいけないのでしょうか？
現代において、「ユーザー名」と「パスワード」だけのシンプルな認証方法は、セキュリティーを担保する認証方法としては充分ではありません。
シンプルなパスワードだと、簡単に悪意のある第三者にセキュリティーを突破されますし、逆に難しすぎるパスワードだと、利用する我々が困ってしまいます。
上記対策として、最もシンプルで簡単なソリューションが、「MFA」といわれる、多要素認証なのです。
悪意ある第三者が、「ユーザー名」と「パスワード」を特定しても、多要素認証を設定「さえ」していれば、コンピューターの中にあるデータやリソースにアクセスすることができないのです。
電子メールを受信するために使用される、「POP3」、「IMAP」、「EWS」のようなプロトコルは、「ユーザー名」と「パスワード」の組み合わせが正しければ、認証が通ってしまうので、ブルート フォースアタックや、パスワードのスプレー攻撃を受けやすいのです。悪意のある第三者はユーザーの電子メールアドレスにアタックをしかけてきます。
#なるほど、では、我々はどうすればいいのか？
レガシー認証をブロックすること、もしくは特定のユーザーや場所からだけ、アクセスを許可するような対策を勧めます。
昨年、 Azure AD のサインイン ログにおいて、何点か改良が加えられました。
サインイン ログの「クライアント アプリ」のプルダウンメニューから、サインインするために、どのプロトコルが使われたかを選択することができます。
Azure AD のサインイン ログを選択すると、上部に、絞り込みを行うためのプルダウンメニューがありますが、その中の「クライアント アプリ」をクリックすると、どのプロトコルでアクセスした、ログを確認するかを絞り込むことができるようになっています。
まず最初にやるべきことは、どのクライアント、どのプロトコルを使って、あなたのシステムにアクセスしにきているかを、このサインイン ログを見て分析することです。
サインイン ログは Excel ファイルにダウンロードすることができるので、 SIEM を持っているのであれば、データをインポートして、多次元分析をすることも可能です。
誰が、何をつかっているのかを把握することで、モダン認証をサポートしているクライアントにバージョン アップさせることもできますし、「IMAP4」などのプロトコルの利用をやめることで、セキュリティを高めることができます。
#####私的見解
上記内容は、まさに IT サービス運用管理者の仕事の 1 つですよね、当然システムが大規模になればなるほど、誰がどのバージョンのクライアント アプリを使っているのか把握することは困難なはずです。
Azure AD は認証基盤ですから、必ず、 Azure AD で認証をしてからアプリケーションを利用する仕組みを作れば、「サインイン ログ」を解析しさえすれば、職場環境のクライアント アプリの状況を把握できるようになるわけです。
且つ、 SIEM を持っていれば、CSV ファイルをそこに放り込んでしまえば、分析は簡単にできるわけですよね。
さて、次が最後の項目です。
#よし分かった、コントールしたいと思うけど、じゃあ、具体的にどうしたらいいの？
去年までは、下記 2 つのレガシー認証のブロック方法が Azure AD にはありました。
・AD FS を使うようなフェデレーション環境では、クレーム ルールを設定することで、特定のプロトコルやアクセスを規制することができます。
・レガシー認証のプロトコルに対して、「app password」をユーザーに強制するように、ユーザー単位で多要素認証を設定することができます
ただここで残念なお知らせがあります。このやり方は、柔軟性がない、ということです。設定を全ユーザーにするか、もしくは、しないか、という方法しかない、ということです。また、ユーザーごとに多要素認証適用する方法には適していないといえます。
これらの対策として、「条件付きアクセス」がありますが、大幅に柔軟性が向上しています。
去年、条件付きアクセスにおいて、レガシー認証をピンポイントでブロックする機能が、追加されました。
例えば、 IMAP プロトコルを使って、 MS Exchange Online のメールボックスから、メールを取り出すようなアプリケーションを使っているのであれば、「条件付きアクセス」でブロックすることができるようになるわけです。
具体的な設定箇所は下記になります。
もう 1 つのアプローチ方法としては、サーバー側、もしくはクライアント側で、レガシー認証をブロックするということです。
もし、 Azure AD の条件付きアクセスと組み合わせて使うのであれば、このアプローチ方法も有効だと思います。
例えば、 MS Exchange Online において、ユーザー側で POP3 もしくは IMAP のプロトコルを使う事自体を、無効にすることです。
ここで起きる問題としては、レガシー認証をそのまま使い続けたいので、これらのプロトコルをブロックしたくない、となった場合です。
救済措置として、 MS Exchange Online は新しい機能がリリースされました。特定のユーザーの特定の組織に対してのみ、プロトコル単位でレガシー認証をブロックできるようになりました。
プロトコルの通信は、 Azure AD や AD FS における資格情報の認証が行われる前に、拒否される通信となるので、まず先に Azure AD や AD FS での認証を強制する、「事前認証」の環境を作ることができます。
条件付きアクセスで設定したポリシーは、ユーザーもしくは悪意のある第三者が認証された「後」に評価されるので、上記の事前認証を強制することは有効な対策ということができます。
#####最後に(私的見解)
いくらクラウド サービスを使っていても、すべてのシステムをクラウドに移行できるわけではないと思いますので、結果、レガシー認証のシステムも残ることになると思います。
レガシー認証のアプリケーションも、 Azure AD と統合することで、条件付きアクセスが使えるようになり、レガシー認証をブロックすることで、セキュリティー対策ができる、という話でした。
条件付きアクセスは、かなり柔軟性の高い機能で、且つ、逐次機能が強化されています。
今回のようにレガシー認証対策だけでなく、多くの機能が備わっていますので、活用することをお勧めします。