以下ハンズオンのModule 02の部分です。
英語版。
日本語版はこちら。
全部で4 Module。
Module 01: https://qiita.com/smr1/items/1c2558fdb466795669cc
Module 02: https://qiita.com/smr1/items/975769ee5d0822562aef
Module 03: https://qiita.com/smr1/items/8de42c5504511b067890
Module 04: https://qiita.com/smr1/items/fdd57f3f2bc2acab9633
多要素認証
多要素認証は5種類の方法で設定できる。
正直、多要素認証は複数の方法で設定できるのが混乱を生んでいる気がする。
結局どのユーザーが多要素認証どうなってるのかわからなくなってしまい、とても面倒くさい。
①がSecurity Defaults
Security Defaultsを設定したら自動的に多要素認証が設定される。
Azure ADのセキュリティの既定値群（Security Defaults）は、一般的な攻撃から組織を保護するための事前構成済みのセキュリティ設定を提供します¹²。以下のセキュリティ対策が含まれています¹²：
Azure AD Multi-Factor Authenticationへの登録必須化¹²：すべてのユーザーは、14日以内にMicrosoft Authenticatorアプリまたはアプリをサポートする任意のOATH TOTPを使用して、登録する必要があります¹²。
管理者への多要素認証の実行要求¹²：管理者は、毎回多要素認証を実行する必要があります¹²。
ユーザーへの多要素認証の要求¹²：認証の追加のレイヤーが必要なアカウントは管理者アカウントだけであると考えがちですが、多くの場合、攻撃者はエンドユーザーをターゲットにします¹²。
レガシー認証のブロック¹²：旧式の認証方式であるレガシー認証（POP3/IMAP4など）が利用できなくなります¹²。
Azure portalなどへのアクセス時の多要素認証の要求¹²：Azure portalへのアクセスなどの特権が必要な作業を保護します¹²。
これらの機能は無料で利用することができ、Microsoft 365やDynamics 365に対して適用することが可能です¹²。具体的な手順については、Microsoft Entra ID での既定のセキュリティ レベルの提供に関するページを参照してください¹。¹²
Conditional Acces Policyと排他的（Security DefaultsがOnの場合、Conditional Access Policyは使えない）なので、注意が必要。
②が多要素認証設定ページ
このページのConfigureでMFA option page（Entra Admin CenterとURLが違うからこれは別のポータルなんだけど）を開く。
Usersでユーザーごとの多要素認証の設定。
Service Settingsで多要素認証の詳細な設定。
IP除外、多要素認証の方法とか。
③は条件付アクセス制御
条件にあったら多要素認証を要求。
④MFA registration policy
Identity protectionから。
正直②と何が違うのかわからない。
⑤Sign in risk policy
Sign in risk policyで簡易的な条件付アクセスポリシーみたいなものを設定できる。
Self Service Password Reset
Protection > Self Service Password Resetでグループごとに設定する。
グループに含まれているユーザーの場合、パスワード忘れた場合、からリセットできるようになる。
設定されていない場合、できない旨が表示される。管理者への連絡が必要。
VMにAzure ADユーザーでログイン
VM作成時にAADユーザーでログインを選択。自動的にシステム割り当てIDが有効化される。
これをOnにすると、ADログイン用の拡張機能が有効になるらしい。
ユーザーにRBACを割り振る。
で、結論からいうと、ログインできなかった。
Webで調べてみると、個人ブログでは手順がサイトによってばらばらだったり、Microsoftのサイトを見るとOSやWindows Updateによって、サポートされるかされないか色々条件があるみたい。
必要になった時にちゃんと調べることにして、スキップ。
Smart lockout
Password protectionで、ロックアウトとかが設定可能。
何回失敗したらロックされるか、ロック時間、パスワードのブラックリストとか。
勝手に正規化されて、あいまい検索でチェックされるらしい。
Conditional Access Policy
Users ... Who、誰に対して。
Target resources ... What、なんのリソースに対して。
Conditions ... When、どの条件の場合。
Grant ... Block or Grant、許可もしくはブロックする。
Session ... How、許可した場合も利用を制限するか。
Users
Include、Excludeが設定可能。
Target resources
Azure Portalとかが設定可能。
Conditions
User risk
Sign in risk
どのアクセス方法
Grant
許可する場合も多要素認証を必須にするとかを選べる
Session
例えばデフォルトでは1度ログインすれば90日ログインが有効だが、それを特定アプリだけ短くすることができる。
What If
例えば1人にログイン時に多要素認証を要求するPolicyを付けた場合、What IfツールでPolicyをテストできる。
Report-only
レポートだけにすると、条件を実際に有効する前に影響度合いを測ることができる。
Sign in risk, User risk
リスクレベルに応じて簡易的な条件付アクセスポリシーみたいな設定ができる。
Azure ADのSign in risk policyとUser risk policyは、Identity Protectionの一部で、リスクベースのアクセス制御を提供します¹²³⁴。
Sign in risk policy（サインインリスクポリシー）：各サインイン中に、Identity Protectionはすべてのリアルタイムサインイン検出を実行し、サインインセッションのリスクレベルを生成します²。これはサインインが侵害された可能性の高さを示します²。その後に、このリスクレベルに基づいて、ユーザーと組織を保護するためのポリシーが適用されます。
User risk policy（ユーザーリスクポリシー）：割り当てたユーザに対して高・中・低のリスクが特定された場合にアクセスをブロックするのか、アクセスを許可するのか（レポートのみ）、アクセスを許可するがパスワードの変更を要求するのかといったポリシーが設定可能です⁴。
これらのポリシーは、リスクを検出して偽陽性を減らすことができ、ユーザーと管理者が影響を受けることを防ぐことができます¹²³⁴。具体的な手順については、リスク ポリシーを構成して有効にするに関するページを参照してください⁶。¹²³⁴⁶
