More than 3 years have passed since last update.

ID インフラストラクチャをセキュリティ保護する 5 つのステップを読み解く

Posted at 2020-03-01

はじめに

今から書く内容は、Microsoft の公開情報である「ID インフラストラクチャをセキュリティ保護する 5 つのステップ」の内容をかみ砕いて書いています。

-参考情報
ID インフラストラクチャをセキュリティ保護する 5 つのステップ
URL:https://docs.microsoft.com/ja-jp/azure/security/fundamentals/steps-secure-identity

以下の設定を施したからといって、セキュリティ保護が万全になるわけではありません。
逆に以下の設定を必ずしもすべて設定しないといけない、というわけでもありません。

この記事を書いた意図としては、ID を正しく保護するための方法が複数用意されているので、ご利用の環境に合わせて選択していただくための一助にして欲しいからです。

下記 Microsoft 公開情報にベストプラクティスとして書かれている記事がありますので、そちらも参考にしてみてください。

-参考情報
Azure の ID 管理とアクセス制御セキュリティのベストプラクティス
URL:https://docs.microsoft.com/ja-jp/azure/security/fundamentals/identity-management-best-practices

推奨アクションについて

設定を検討して欲しい項目は以下のとおりです。

項目	機能名	ライセンス	備考
資格情報を強化する 1.	セキュリティデフォルト	Azure AD Free	特定の管理者のみ、多要素認証の要求方法が限定的
資格情報を強化する 2.	条件付きアクセス	Azure AD Premium P1 以上	Azure AD 上で ID 管理をするならほぼ必須な機能
資格情報を強化する 3.	パスワード保護	Azure AD Premium P1 以上	クラウドユーザーのグローバル禁止パスワード機能のみ Free で使える
資格情報を強化する 4.	スマートロックアウト	Azure AD Free	ロックアウトの規定値をカスタマイズする場合は Azure AD Premium P1 以上必要
攻撃の対象となる領域を減らす 1.	条件付きアクセスでレガシー認証をブロック	Azure AD Premium P1 以上	AD FS を利用している場合は AD FS 側の設定も必要
攻撃の対象となる領域を減らす 2.	ユーザーの同意操作を制限する (Admin Consent)	Azure AD Free
攻撃の対象となる領域を減らす 3.	Azure AD Privileged Identity Management	Azure AD Premium P2
脅威への対応を自動化する	Azure AD Identity Protection	Azure AD Premium P2 推奨	リスクポリシーを設定するためには Azure AD Premium P2 ライセンスが必要
クラウドインテリジェンスを利用します	Azure AD サインインログ、監査ログ、Azure AD Identity Protection のイベントログ	ライセンスにより監視できる期間が異なる
エンドユーザーセルフサービスを有効にします	セルフサービスパスワードリセット	Azure AD Premium P1 以上推奨	クラウドユーザー限定で Office 365 ライセンスでリセット可能だが機能が限定的

資格情報を強化する 1. 「セキュリティデフォルト」

セキュリティデフォルトは Azure AD Premium がなくても特定の管理者ユーザーに対して多要素認証を要求できる機能になります。
ただし、多要素認証の要求方法が Microsoft Authnticator アプリにより通知に限定されるため、スマートフォーンを持っていない場合多要素認証の要求に応えられないため、認証が完了することができません。

電話番号を利用した、通知、もしくは電話による認証を希望する場合は後述する条件付きアクセスを利用してください。

-関連する公開情報
セキュリティデフォルトとは
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/fundamentals/concept-fundamentals-security-defaults

設定箇所は、「Azure ポータル」→「Azure Active Directory」→「プロパティ」→「セキュリティの期待値の管理のリンクをクリック」すると表示される下記「セキュリティの規定値の有効化」を「はい」に変更し「保存」をクリックします。

上記設定をした後に、管理者ユーザーでサインインすると、下記画面ショットのように Microsoft Authenticator で応答する旨の画面に遷移し、応答した後にアプリケーションにサインインできます。

セキュリティデフォルトで多要素認証が要求させる管理者ロールは下記のとおりです。

全体管理者
SharePoint 管理者
Exchange 管理者
条件付きアクセス管理者
セキュリティ管理者
ヘルプデスク管理者またはパスワード管理者
課金管理者
ユーザー管理者
認証管理者

また、この機能は条件付きアクセスと組み合わせて利用することはできません。
この機能を有効にすると条件付きアクセスで多要素認証の設定ができなくなりますし、逆に条件付きアクセスで設定済みの場合は、セキュリティデフォルトの機能は有効化できません。

あくまで Azure AD Free ライセンスのみ持っているテナント用の機能だと思ってください。

資格情報を強化する 2. 「条件付きアクセス」

Azure AD を触ったことがある人は知らない人はいないというほど有名な機能です。
多要素認証の要求だけではなく、デバイス、場所、アプリケーション、ユーザー単位などに対して、多要素認証の要求、アクセスブロック、追加の要件を要求させるなど、非常に柔軟な機能を持ち合わせているサービスです。

-関連する公開情報 (ドキュメントが多いので Index ページを紹介)
Azure AD 条件付きアクセスのドキュメント
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/conditional-access/index

Azure Active Directory 条件付きアクセスによるアクセス制御の概要
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/conditional-access/controls

例えば、Azure AD 上の特定のアプリケーションにアクセスする際に、多要素認証を要求させたい場合には、下記画面ショットのように「アクセス制御の項目」で「多要素認証を要求する」のチェックボックスを有効にすることで、実現可能です。

資格情報を強化する 3. 「パスワード保護」

パスワード保護の機能は、ユーザーが簡単に推測できるようなパスワードを設定させないように、Microsoft が非公開として予め設定されている「グローバル禁止パスワード」と管理者がテナント単位に個別に禁止パスワードを設定できる「カスタム禁止パスワード」を組み合わせることで、悪意のあるアクターからのアカウントの侵害を防ぐための対策の 1 つとして用意されている機能です。

Azure AD Free ライセンスでは、クラウドユーザー限定でかつ「グローバル禁止パスワード」のみしか利用できないので、オンプレミス AD から ID を同期している環境および「カスタム禁止パスワード」を利用する場合には、Azure AD Premium P1 以上が必要になります。

-関連する公開情報
組織内の不適切なパスワードを排除する
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/concept-password-ban-bad

カスタム禁止パスワードの設定は「Azure ポータル」→「Azure AD パスワード保護」で表示される以下画面ショットの「カスタムの禁止パスワードの一覧」の項目で行います。

グローバル禁止パスワードに引っかかると以下の画面が表示されて入力したパスワードの設定ができません。

カスタム禁止パスワードに引っかかると、下記画面ショットのように組織で禁止されているパスワードを入力していることが指摘されます。

資格情報を強化する 4. 「スマートロックアウト」

スマートロックアウトはブルートフォース対策として、悪意のあるアクターがパスワードをリスト型アタックを利用して侵入を試みる行為を自動的にロックアウトさせることで、攻撃を遮断させる機能になります。

この機能の良いところは、管理者側が何も設定しなくても内部的に機能してくれる点があります。
細かい動作は公開情報を見て欲しいのですが、デフォルトの設定では、ユーザーもしくは悪意のあるアクターがパスワード入力を 10 回失敗した段階で、 1 分間ロックアウトされます。

スマートロックアウトはデータセンター側に「既知の場所」と「未知の場所」のロックアウトカウンターが用意されていて、それぞれのカウンターが 10 に達した時点でロックアウトされます。

従って、通常悪意のあるアクターは「未知の場所」からアタックを仕掛けてくるので、「未知の場所」のカウンターが 10 に達しても、「既知の場所」のカウンターが 10 に達していなければ、正しいユーザーは正しくパスワードを入力すれば問題なくアプリケーションにアクセスできます。
上述のロックアウトされる閾値「10」を変更したい場合、もしくはロックアウトの時間「60秒」を変更したい場合には、Azure AD Premium P1 以上のライセンスが必要になります。

-関連する公開情報
Azure Active Directory のスマートロックアウト
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/howto-password-smart-lockout

スマートロックアウトの設定は、「Azure ポータル」→「Azure AD パスワード保護」で表示される、下記画面ショットの「カスタムのスマートロックアウト」の項目で設定します。

スマートロックアウトでロックアウトされると下記画面ショットのように正しいパスワードを入力しても一時的にサインインできなくなります。

攻撃の対象となる領域を減らす 1. 「条件付きアクセスでレガシー認証をブロック」

レガシー認証を利用しているアプリケーションは、POP 3 クライアント、IMAP4 クライアント、SMTP クライアントなどのプロトコルを利用して認証をするため、上述で触れている多要素認証を強制することがプロトコルとしてできません。

このあたりの話については、私の過去の記事にて言及しているので参考にしてみてください。

-参考情報
[日本語訳][個人的解釈]Azure AD Mailbag: Discovering and blocking legacy authentication
URL:https://qiita.com/Shinya-Yamaguchi/items/fc1add86a8985e8cbe8f

-関連する公開情報
方法:条件付きアクセスを使用して Azure AD へのレガシ認証をブロックする
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/conditional-access/block-legacy-authentication

設定箇所は、「Azure ポータル」→「条件付きアクセス」より、条件の項目内の「クライアントアプリ」にて、「他のクライアント」を有効にします。これで、レガシー認証を利用してアクセスしてきたクライアントに対して制御ができるようになります。

同一の条件付きアクセスポリシー内で下記画面ショットのように「アクセスのブロック」を指定することで、レガシー認証を利用したアクセスをブロックできるようになります。

この設定をすると本当にレガシー認証を利用したクライアントはブロックされるので、レガシー認証を利用し続けている社員がいる場合には、事前に先進認証でもアクセスできる環境を用意しておくなどの対処をきちんと行う必要があります。

現行の機能では下記画面ショットのように条件付きアクセスの「レポート専用」機能があります。
この機能は当該のポリシーを有効化はしない代わりに、設定したポリシーに該当したアクセスが発生した際にはサインインログに記録されます。
つまり、移行前の動作確認として活用できます。

攻撃の対象となる領域を減らす 2. ユーザーの同意操作を制限する (Admin Consent)

既定では、Azure AD 上のユーザーが Microsoft ID プラットフォームを利用したアプリケーション上のデータにアクセスすることが許可されています。

ユーザーが勝手にアプリケーション上のデータにアクセスさせなくする、もしくはユーザーが勝手に Azure AD 上にアプリケーションを登録できないように、管理者の承認を得ることで初めてアクセスできるような仕組みを用意することができます。

以下はほんの一例ですが、「Admin Consent」という管理者の承認を得ることを前提とした設定ができます。

-関連する公開情報
すべてのアプリケーションに対して今後のユーザーの同意操作をすべて無効にする必要がある
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/methods-for-removing-user-access#i-want-to-disable-all-future-user-consent-operations-to-any-application

Azure AD アプリケーションの同意エクスペリエンスについて
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/develop/application-consent-experience

設定箇所は、「Azure ポータル」→「エンタープライズアプリケーション」→「ユーザー設定」→「ユーザーは、アプリが自身の代わりに会社のデータにアクセスすることを許可できます」を「いいえ」に変更します。

こうすることで、例えば「Graph Explorer」にアクセスした場合に、下記画面ショットのように「管理者の承認が必要」と表示されて文字通り「管理者の承認」を得られるまでアクセスができなくなります。

管理者側は、Graph Explorer の「アクセス許可」の項目内、「xxx に管理者の同意を与えます」をクリックします。

クリック後に、管理者の資格情報で認証を行うことで、下記画面ショットが表示されるので、「承諾」をクリックします。

上記はあくまで一例ですが、管理者の同意ワークフローを利用することで、ユーザー側から管理者の同意を「要求」する仕組みも利用することができます。(プレビュー機能です)

-参考情報
管理者の同意ワークフローの構成 (プレビュー)
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/configure-admin-consent-workflow

攻撃の対象となる領域を減らす 3. 「Azure AD Privileged Identity Management 」

PIM は Azure AD 管理者ロールや RBAC を永久的にユーザーに付与するのではなく、例えばコラボレーションしている別組織のユーザーに対して、一時的に作業に必要なロールを割り当てて利用したいとなった場合に、申請、承認の上、初めてロールが付与できるという機能になります。

ある管理者ロールを割り当てたユーザーが退職してしまったが、アカウントを無効化しないまま運用してしまい、悪意のあるアクターにそのアカウントを侵害され、管理者ロールを利用して不正に操作されるというケースが考えられます。

この場合は、Just-In-Time の機能を利用することで、指定した期間の間だけ指定したロールを利用させることで、期限が切れのあとは、割り当てたロールが自動的に利用できなくなる仕組みを構成することが可能となります。

-関連する公開情報
Azure AD Privileged Identity Management とは
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/privileged-identity-management/pim-configure

Azure AD Privileged Identity Management (PIM) をデプロイする
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/privileged-identity-management/pim-deployment-plan

脅威への対応を自動化する「Azure AD Identity Protection 」

Azure AD Identity Protection は様々な理由でセキュリティ侵害の可能性を検知した際に、「リスク」として評価を行い、低、中、高、という「リスクレベル」に応じて対象のユーザーアクセスをブロックさせたり、多要素認証を要求させることでそのユーザーが悪意のあるアクターでないことを証明させたりする機能を有しています。

この機能自体は Azure AD Free ライセンスでも動作はしていますが、後述する「ユーザーリスクポリシー」ならびに「サインインリスクポリシー」というリスク検出時の対策を自動化するためには Azure AD Premium P2 ライセンスが必要になります。

-関連する公開情報
Azure Active Directory Identity Protection とは
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/identity-protection/overview-identity-protection

Identity Protection ポリシー
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/identity-protection/concept-identity-protection-policies

方法:リスクポリシーを構成して有効にする
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies

設定箇所は、「Azure ポータル」→「Azure Active Directory」→「セキュリティ」→「Identity Protection」になります。
以下は一例ですが、「ユーザーリスクポリシー」で定義したポリシーに引っかかってアカウントブロックされた場合には、以下画面ショットのようにブロックされた画面に遷移します。

また、「サインインリスクポリシー」に引っかかってアクセスがブロックされた場合には、以下画面ショットに遷移します。

ブロックだけではなく、多要素認証を要求させる設定もありますので、いずれかを選択します。
この「ユーザーリスクポリシー」と「サインインリスクポリシー」はそれぞれ 1 つずつしか定義できません。
つまり、リスクレベルごとに、「ユーザーリスクポリシー」を設定するようなことはできません。

Microsoft では、「ユーザーリスクポリシー」を「高」、「サインインリスクポリシー」を「中以上」に設定することを推奨しています。

-参考情報
許容されるリスクレベルの選択
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies#choosing-acceptable-risk-levels

クラウドインテリジェンスを利用します「Azure AD サインインログ、監査ログ、Azure AD Identity Protection のイベントログ」

Azure AD サインインログ、監査ログは Azure AD を監視する上では欠かせない機能になります。
サインインログは主に認証時のログ、監査ログは、ユーザー、アプリ、グループ、ロール、ポリシーの追加や削除など、Azure AD 内のあらゆるリソースに加えられた変更が発生した際に記録されます。

また、Azure AD Identity Protection は「危険なユーザー」と「危険なサインイン」という項目でログを記録しているので、リスク発生時の履歴を追うことができます。

さらに、Azure Sentinel というクラウドネイティブの SIEM と組み合わせることで、リスクの可視化とトリアージの簡易化が実現できます。

-参考情報
Azure Sentinel に Azure AD と Identity Protection のログを取り込んで可視化してみる
URL:https://qiita.com/Shinya-Yamaguchi/items/7b4e30065857be797c82

-関連する公開情報
Azure セキュリティのログと監査
URL:https://docs.microsoft.com/ja-jp/azure/security/fundamentals/log-audit

Azure Active Directory ポータルの監査アクティビティレポート
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/concept-audit-logs

また、サインインログと監査ログは、以下のとおり、Azure AD テナントに保持しているライセンスにより保存期間が異なります。

-参考情報
Azure AD にデータが保存される期間

URL:https://docs.microsoft.com/ja-jp/azure/active-directory/reports-monitoring/reference-reports-data-retention#how-long-does-azure-ad-store-the-dataa

エンドユーザーセルフサービスを有効にします「セルフサービスパスワードリセット」

セルフサービスパスワードリセットは、文字通り、ユーザーが自分自身でパスワードをリセットできる機能になります。
ID を保護するというよりかは、運用を簡易化し、運用コストを下げるという意味で大きな効力を発揮します。

この機能を有効化していない場合は、パスワードを忘れてしまった場合、パスワードをリセットし、新しいパスワードを設定するオペレーションをヘルプデスクや IT 管理部門の管理者が行う必要があります。

１回のパスワードリセットのオペレーションコストはそれほど高くないかもしれませんが、当然社員が多ければ多いほどこの作業が発生する可能性が上がってしまいます。

「セルフサービスパスワードリセット」を有効化すればユーザーが自分でパスワードをリセットできますので、管理部門が作業する必要がなくなります。
また、ユーザー側から見ると、パスワードを忘れてリセットしたいとなったときに、管理部門に依頼をする必要がなくなります。
この機能を有効化していないと、今すぐアプリケーションにアクセスする必要があるのに、パスワードがリセットされるまで、アクセスできない、という時間的なロスが発生してしまいます。

このように、管理部門、ユーザーサイド双方にとってメリットのある機能になります。

-関連する公開情報
チュートリアル:Azure Active Directory のセルフサービスパスワードリセットを使用して、ユーザーが自分のアカウントのロック解除またはパスワードのリセットを実行できるようにする
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/tutorial-enable-sspr

設定は、「Azure ポータル」→「Azure Active Directory」→「パスワードリセット」で表示される項目で行います。
一例として、「認証方法」の項目にて下記画面ショットのようにリセットするために必要な数、方法を設定します。