【Office365】多要素認証(MFA)の計画と展開

皆さん、お久しぶりです。Miyaです。

ここ最近は仕事に追われる日々(現在進行形)で記事が更新できていませんでしたが、久々の更新です!

さて、今回はOffice365の「多要素認証(MFA)の計画と展開」をテーマにしてみました。

最近になり、アクセス制限をしていないお客様からOffice365のアカウント乗っ取りのお知らせをいただくことがあり、緊急対策としてOffice365のMFAのご相談をいただくのですが、環境によっては中々ややこしい動きをするため、整理したく本ブログの記事に起こしてみました。

スポンサーリンク:

そもそもOffice 365 MFAとは?

Office 365 MFA(Mluti Factor Authentication)とは、Office365の標準機能の一つで、ユーザー本人が知っている情報(サインインパスワード)に加えてユーザー本人持っているモバイルデバイスを追加の認証要素として要求する本人認証の仕組みです。

MFA

従来の認証は、①のユーザー名とサインインパスワードの組み合わせで認証されていましたが、MFAはそれに加えて②のSMS/電話、スマホのAuthenticatorアプリでアカウントの所有者であるかどうかを確認することが目的です。

よくAzure AD MFAと誤解される方々がいらっしゃいますが、Azure AD MFAはAzure AD Premiumライセンスの機能で、細かな条件分岐でMFAの要求タイミングを制御可能なOffice 365 MFAの上位互換です。

Office365 MFAとは、Azure AD MFAの一部で、ユーザーID/パスワード+本人所有のモバイルデバイスを使った先進認証の一つである。

Office365 MFAの計画

Office365 MFAの実動作をを見てみましょう。下の例はスマホのAuthenticatorアプリを使った認証方式です。

MFA

MFAには上記の他に携帯電話の SMS/電話 を使った認証方式もありますが、この認証方式が一番手間がかからない方式でしょう。

…だとしても面倒くさいですよね?

無鉄砲にMFAを展開してもユーザにとっては手間になるだけなので、本当に必要なケースを除いてはMFAは極力避けるべきだと私は考えます。

例えば、Office365に対して何かしらでIPアドレス制限をしている構成の場合、仮にID/PWが漏れても社外NWからの接続は拒否するので、本機能はあまり必要ではないはずです。

逆に、何のアクセス制限もしていない環境はID / PW 漏洩時のリスクが極めて高いのでMFAを展開すべきですし、管理者アカウントとして構成されがちな***.onmicrosoft.comは最もMFAを展開すべきでしょう。

補足情報ですが、一部の管理権限を持ったアカウントは自動的にMFAが有効になるポリシーというよりかは時限爆弾がセットされているのでシステムアカウントとして利用している場合は計画的に対応しましょう。
Title:“Baseline policy: Require MFA for admins” について

Office365 MFAの設計

MFAの展開に向けて、サーバー側の設定をどう構成するかを決めていく必要があります。

Office365の管理者ポータル、[アクティブなユーザー] – [その他]メニューにある[Multi-Factor Authentication]でOffice365 MFAの設定ページへ飛べます。

ここではユーザー毎にMFAのON/OFFを構成したり、[サービス設定]からサーバー側の設定値を構成することが出来ます。
※”信頼済みip”はAzure AD MFAの機能のため、Azure AD Premiumを必要とします。

MFA

MFAの設定できる項目なんてものはかなり限定的で、それこそ考える項目なんて少ないように思えますが、ややこしい点もいくつかございますので、本記事で整理しておきたいと思います。よろしければご参考ください。

Office365 MFAの有効化

まずは、Office365 MFAを有効化した時にユーザー側はどう見えるのかを確認します。MFAの有効化は先ほど紹介したMFAの管理画面からユーザー単位で有効にすることが出来ます。

MFA

MFAが有効になったユーザーは、次回のブラウザログイン時にMFAの登録を要求するウィザードが実行されるようになります。

従来のようにユーザー名とサインインパスワードを入力すると、追加のセキュリティ情報の登録ウィザードが開始されます。

MFA

携帯電話(電話・SMS)、Authenticatorのいずれかの認証方式を選択してセットアップをしていきます。下図ではAuthenticatorアプリの[通知]を選択した場合のイメージです。

MFA

登録が完了すると、次回以降のサインインはセットアップした方式で認証します。

ここで肝心なのがセットアップウィザードが流れるのは初回の「ブラウザでのログイン時」という点であると私は思います。

MFAを有効後、例えばモバイルアプリからOffice 365へ接続すると、↓のように再認証を求められ、MFAのセットアップウィザードが開始されます。

MFA

PCのスタートアップとして登録されがちなSkype for Business 、Teams、OneDrive同期クライアントでセットアップウィザードが流れることを特段気にする必要はありませんが、モバイルの場合はAuthenticatorのQRコードスキャンが出来ず不便すぎるので、PC版から登録を促す周知をしておくと親切ですね。

MFAを有効にしたユーザーは次回のブラウザログイン時にMFAセットアップウィザードが表示される。IE、Edgeなどのブラウザ以外にも、モバイルやその他ブラウザ経由で認証するクライアントでセットアップすることも可能。

Office365 MFAのステータスについて

さて、MFAの実動作が確認できた次STEPとして、Office356 MFAのステータスについて整理してみましょう。MFAのステータスには「無効」「有効」「強制」の3つがあります。

MFA

無効 / 有効については言葉のままですが、「強制」というワードはあまりイメージが湧かないかと思います。MSの公式ドキュメントには以下のように紹介されていましたが、相変わらず理解出来ません…。

  • すべて すべてのユーザーが表示されます。これは既定の状態です。
  • 有効 ユーザーは、MFA に登録されていますが、登録プロセスが完了していません。ユーザーが次回サインインしたときに、プロセスを完了するように要求するメッセージが表示されます。
  • 強制 ユーザーは、登録を完了している場合と、完了していない場合があります。登録プロセスを完了している場合、MFA を使用しています。完了していない場合は、ユーザーが次回サインインしたときに、プロセスを完了するように要求するメッセージが表示されます。

引用 – Office 365 ユーザー用の多要素認証を設定する

有効と強制で何が違うのかというと、強制はMFAが実施できないレガシー認証のクライアント向けにアプリケーションパスワードを要求する状態を意味します。(間違ってたらご指摘ください…

ADAL認証、レガシー認証についてはMSのJapan SharePoint Team Blogの↓記事に分かり易くまとめられています。
Title:Office 製品の Office 365 モダン認証フローと認証キャッシュについて

アプリケーションパスワード”というNew単語が出てきたので、次セクションで紹介します。

アプリケーション パスワードとは?

アプリケーションパスワードとは、認証にブラウザを利用しないレガシー認証のクライアント向けに用意されたサインインパスワードとは全く別物の専用パスワードです。

Office 365に接続するクライアントはOutlook、Skype for Business…など様々ですが、大きく以下の二つの認証画面に分類出来ます。

MFA右のOutlook 2016のように、ブラウザ(IE)を認証のコンポーネントとするADAL対応クライアントは、サーバー側のWebAPIを経由して様々な認証ライブラリにアクセス出来る=MFAに対応しているのですが、左のOutlook2010のようにレガシー認証はユーザーID / サインインパスワードでしか認証が出来ないため、MFAに対応していません。

レガシー認証はOutlook 2010、ActiveSyncなどなど…まだまだ一般利用している組織は多いでしょう。そこで登場するのが”アプリケーションパスワード“です。

MFAステータスが強制になると、レガシー認証はサインインパスワードで認証出来なくなります。代わりにユーザー名 / アプリケーションパスワードの組み合わせでサインインする動きへ切り替わります。つまり、MFAでログインした後に取得したパスワードだからあなたは本人ですよね?というやり方です。

MFA

ちなみに、先ほどのセクションでMFAセットアップウィザードを登録したユーザーのステータスを確認すると、「強制になっていることが確認できます。

MFA

つまり、MFAの初回セットアップ完了後、自動的に「強制」にステータスへ変わり、アプリケーションパスワードに切り替わる仕組となります。ややこしい…。

アプリケーションパスワードとは、レガシー認証のための専用パスワードである。MFAステータスが「強制」に切り替わると従来のパスワードの代わりにアプリケーションパスワードが要求される。

アプリケーションパスワードの取得

アプリケーションパスワードはOffice365が自動で生成する16桁の乱数英字です。初回セットアップウィザードの中で最初のアプリケーションパスワードが生成されます。

このアプリケーションパスワードは、一度のみしか表示されない非常に恥ずかしがり屋のパスワードなので、生成時にレガシー認証のクライアントに入力する必要があります。

しかし、ここで問題があります。レガシー認証がサインイン情報の再入力を要求するタイミングにラグタイムがある点です。

基本的に認証に成功した各クライアントはしばらくは認証をBypassしてOffice 365へ接続できるようキャッシュを持ちます。

キャッシュが切れたタイミングで、端末に保存されたサインインパスワードで再認証を試そうとするのですが、この時に「強制」に 切り替わっていればOffice365はアプリケーションパスワードを要求するため、結果、不一致による認証ダイアログ↓が表示されます。

MFA

ユーザーはアプリケーションパスワードを生成したタイミングではなく、↑の状態になったときにアプリケーションパスワードを入力する必要があるため、メモ帳などに保管するか、都度ポータルから生成する必要があります。
Title:Office 365 のアプリ パスワードを作成する

ただでさえ16桁の長いパスワードなのに、アプリケーション毎で操作が異なるのはユーザーにとって非常に煩雑ですので、なるべくレガシー認証は撲滅するべきでしょう。

Office365 MFA 各種設定内容の検討

Office365 MFAの管理画面の[サービス設定]では、少ないですがいくつかの設定項目があります。展開前にこれらの設定値を確認しておきましょう。

■アプリケーション パスワード

アプリケーションパスワードの生成を許可するか否かを設定する画面になります。組織の中にレガシー認証が存在する場合は、[許可]で構成しないといけませんが、逆にレガシー認証が無いのであれば許可しないようにしておくのがベストです。

MFA■検証オプション

検証オプションとは、MFAの認証方式を意味します。ユーザーにどの検証オプションが選択出来るかをここで定義します。チェックを外すことでユーザーの検証オプションメニューから非表示されます。

MFA携帯電話のオプションはAuthenticatorアプリが使えないときの代替手段となるので、特別な理由がない限りは残しておくほうが良いでしょう。

■multi-factor authentication を記憶する

MFAを1 – 60日間の範囲でBypass出来るCookieを生成する機能です。

MFA本機能をONにすることで、ブラウザ認証画面で以下のようなチェックボックスが表示されます。チェックを付けて認証することで最大60日間はMFAをBypassすることが出来ます。

MFA

この機能の仕組みですが、CookieにMFAを実施したかどうかの情報を含めてブラウザに保存しています。よって、ブラウザ・端末が変われば勿論ですがMFAを要求する動きとなります。

ちなみに、キャッシュの話についてもう少し深い話をしておくと、その他のクライアントアプリもそれぞれの仕様に準じて認証キャッシュを端末に保持します。

代表的な例を挙げると、ADAL対応のOffice2016はOAuth2.0と呼ばれるプロトコルを利用しており、既定で最大90日間有効なアクセストークン+リフレッシュトークンを資格情報マネージャーに保持します。

MFA

このトークンの中にMFAが完了しているという情報も含まれているため、MFAも90日間はスキップされる動きとなります。
Title:Azure MFA を求められるタイミングについて

また、アプリケーションパスワードを使うアプリは従来のパスワードキャッシュの動作に準じて資格情報を半永久的に保持します。

MFAは、「認証の度にでてくるんでしょ?」と思われがちですが、キャッシュを使ってスキップするよう構成されているので、求められるタイミングは意外と少ないんです。

ちなみに、Cookie限定ですが、多要素認証のユーザー設定画面からサーバー側のCookieを破棄することが可能です。

MFA

ユーザーにとっては手間のかかるステップなので、こういったキャッシュをうまく使ってなるべくクレームが上がらないように展開したいですね。

Office365 MFAの展開

MFAの各機能と動作の整理が出来たところで、管理者画面からMFAを有効化していきます。[一括更新]メニューからCSVをインポートして設定出来るので、難なく操作できるかと思います。

その他にもPowerShellから有効化することが可能です。PowerShellからConnect-MsolServiceで接続して以下コマンドを実行します。

MFAの有効化は極めて簡単なので実際の展開にはあまり困らないかと思いますが、モバイル紛失時などに困らないよう代替番号の登録をマニュアルに組み込んだり、紛失した時のフローは考えておきましょう。

[応用]Office365 MFA のBypass

Office365 MFAはAzure AD MFAの一部機能ですが、特定IPアドレスからのアクセスはMFAをBypassするなどの条件分岐でルールを作成することが出来ません。

しかし、AD FSでフェデレーションを構成している環境であれば発行変換規則からMFAのBypassルールを構成することが可能です。

下記リンクは英語になりますが、AD FSの発行変換規則でクレームルールを構成することで、特定条件に満たしたクライアントはMFAをBypassする構成を紹介したBlogです。
Title:Office 365 customers who have ADFS installed can do simple filtered MFA using ADFS claim rules

①社内NW(WAP経由じゃない)からの認証はMFAをBypassする

not exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”])
=> issue(Type = “http://schemas.microsoft.com/claims/authnmethodsreferences”, Value = “http://schemas.microsoft.com/claims/multipleauthn”);

②ActiveSyncはMFAをBypassする

Exists([Type ==”http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application“, Value =~”^(Microsoft.Exchange.(Autodiscover|ActiveSync))$”]) => Issue(Type =”http://schemas.microsoft.com/claims/authnmethodsreferences“,Value =”http://schemas.microsoft.com/claims/multipleauthn“);

②はActiveSyncのアプリケーションパスワードをBypassするクレームルールになります。さすがに16ケタのアプリケーションパスワードをモバイルで入力させるのは…という場合に使えそうですね。

おわりに

いかがでしたでしょうか?Office365 MFAは標準機能でありながら簡単に本人認証が出来る便利な機能ではありますが、単純に展開するには少し複雑な動きかと思います。

もし、お使いのOffice 365をアクセス制限せずに利用しているのであれば、本記事を参考にMFAの展開を検討してみてはいかがでしょうか。

それでは、良いOffice365ライフをっ♪

スポンサーリンク