以前以下のような記事を書きました。
Maesterによって推奨値等になっていない設定を変更していく過程を書いて行こうかと思います。
現段階での結果は以下のような感じです。
※個人契約のM365テナントです。
Secure Scoreは現在以下となっています。
上から順にみていきます
まずはこちらですね。
EIDSCA.AF03: Authentication Method – FIDO2 security key – Enforce attestation.
こちらは以前パスキーの登録を試したときに、「構成証明の適用」を「いいえ」にしていたのでFailになっていますね。
Entra管理センターからだとこちらの設定ですね。
設定を変更して、再テストしてみました。
今回はちゃんとPassedになりました。パスキーを利用したい場合は現時点(2024/8)では、構成証明の適用を「いいえ」にしないと登録できないので、必要に応じてテストを除外する等をしましょう
参考URL：https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-enable-passkey-fido2#passkey-optional-settings
EIDSCA.AG01: Authentication Method – General Settings – Manage migration.
これは個人テナントなので完全に放置していたやつなので、サクッと設定変更します。
移行の管理から、「移行が完了済み」を選択して保存します。
EIDSCA.AG02: Authentication Method – General Settings – Report suspicious activity – State.
ユーザーが疑わしいアクティビティを報告できるように設定をしておきます。
EIDSCA.AP01: Default Authorization Settings – Enabled Self service password reset for administrators.
まぁそうだよね。という感じではあるのですが、一人テナントなのでなかなかこれを対応するのは難しいなと。
攻撃者は管理者権限を狙ってくるので、管理者権限を持ったアカウントのSSPRはしないように設定しましょう。
ということですね。（別な管理者が、管理者のパスワードリセット対応をする等が望ましい）
設定箇所としてはこちら
SSPRのlearnにも書いてあります。
https://learn.microsoft.com/ja-jp/entra/identity/authentication/tutorial-enable-sspr#prerequisites
管理者以外のユーザーが所属するグループ (SSPR-Test-Group など)。 このチュートリアルでは、このグループに対して SSPR を有効にします。
EIDSCA.AP04: Default Authorization Settings – Guest invite restrictions.
ゲストを招待できる権限を絞りましょう。
デフォルトでは、誰でもゲストを招待できるようになっています。
Teamsゲスト招待等にも制限が入るため、情シス等の担当者負荷が高くなる可能性があります。
運用やセキュリティ規定にあわせて対応するのがいいかと思います。
推奨としては、「特定の管理者ロールに割り当てられているユーザーのみがゲスト ユーザーを招待できる」ですね
EIDSCA.AP05: Default Authorization Settings – Sign-up for email based subscription.
こちらはよく話題になる、Power BI FreeやPowerApp Free等をユーザーが自身でサインアップできるようにするかというやつですね。
推奨値はできないようにしておく。なので、設定を変更します。
が、これPowerShellからでないと変更できないので、以下のコマンドで変更します。
mac版のPowerShellからでも動作します。
参考URL：
https://learn.microsoft.com/ja-jp/entra/identity/users/directory-self-service-signup
https://jpbap-sqlbi.github.io/blog/powerbi/pbi_self-service-signup/
Import-Module Microsoft.Graph.Identity.SignIns
connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"
$param = @{
allowedToSignUpEmailBasedSubscriptions=$false
allowEmailVerifiedUsersToJoinOrganization=$false
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $param以下のコマンドで設定が変更されたかを確認します。Falseとなっていれば変更されています。
Get-MgPolicyAuthorizationPolicy | Select-Object AllowedToSignUpEmailBasedSubscriptions, AllowEmailVerifiedUsersToJoinOrganization
AllowedToSignUpEmailBasedSubscriptions AllowEmailVerifiedUsersToJoinOrganization
-------------------------------------- -----------------------------------------
False FalseEIDSCA.AP06: Default Authorization Settings – User can join the tenant by email validation.
ユーザーが電子メール検証によってテナントに参加できるかどうかを設定します。
検証済みドメインでないとこのフローでは参加できませんが、例えばGWS側でメールアドレスだけを発行している場合などは勝手に登録されてほしくないので、こちらの設定を無効にします。
設定方法は、EIDSCA.AP05と同様です。
EIDSCA.AP07: Default Authorization Settings – Guest user access.
デフォルト設定の場合、Entra上にあるユーザー情報やグループ情報をゲストアカウントでもオブジェクトIDで検索することで表示することができてしまいます。
セキュリティ上あまりよろしくないので、ゲストユーザーは自分のアカウントのみしか表示ができないよう設定変更を行います。
参考URL：https://learn.microsoft.com/en-us/entra/identity/users/users-restrict-guest-permissions
EIDSCA.AP08: Default Authorization Settings – User consent policy assigned for applications.
制御したほうがいいよなーと思いつつ制御していない組織が多いような気がする項目ですね。
GWSのOAuth設定も同じですが、悩ましいと思う気持ちにも同意です。
GWSの場合は、こちらのURLを参照してください。https://support.google.com/a/answer/7281227?hl=ja
が、ユーザー認可情報を渡すので制御しておくべき。というのもありますので制限可能なら制限しておくべきですね。
設定箇所は以下の設定で、完全に制御したい場合には、「ユーザーの同意を許可しない」を選択し保存します。
CISA SCuBA 2.7に則る場合には、こちらの設定をしておく形になります。
発行元が確認済みのものはOKとする場合は、「確認済みの発行元からのアプリに対して選択されたアクセス許可を与えることへのユーザーの同意を許可する (推奨)」を選択します。
Maesterのテストでは、ManagePermissionGrantsForSelf.microsoft-user-default-low」でないとFail扱いになってしまうので、厳しい設定とする場合にはテスト項目の修正を実施しておくとよいですね。
EIDSCA.AP09: Default Authorization Settings – Risk-based step-up consent.
不正な同意要求を行うアプリへ接続しようとした際に、管理者への承認を求めるように設定します。
こちらの対応をする場合には、PowerShellからの変更が必要になります。
※ イマイチよくわからないので誰か教えてください（笑
管理者の同意要求ワークフローを有効にしておくと、同意プロンプトから直接管理者に対して要求を送信することが可能になるので設定しておきます。
EIDSCA.AP10: Default Authorization Settings – Default User Role Permissions – Allowed to create Apps.
サードパーティのアプリケーションの登録は管理者のみに許可しておくべき。というものです。
デフォルトだとこちらの設定が、「はい」になっているので、「いいえ」にして管理者だけがアプリ登録ができるようにしておきましょう。
こちらを「いいえ」に設定したとしても、以下のロールにPIMで昇格をすればアプリ登録は可能です。
- 全体管理者
- アプリケーション管理者
- アプリケーション開発者
- クラウドアプリケーション管理者
EIDSCA.AT01: Authentication Method – Temporary Access Pass – State.
テナント内で一時アクセス パスが有効になっているかの確認です。
有効化していたつもりになっていました（笑）今後の検証にも利用するので有効化しておきます。
EIDSCA.CR01: Consent Framework – Admin Consent Request – Policy to enable or disable admin consent request feature.
管理者への同意ワークフローを構成しておきましょう。というものですね。
参考URL：https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-admin-consent-workflow
EIDSCA.PR01: Default Settings – Password Rule Settings – Password Protection – Mode.
オンプレのWindows Server ADパスワード保護が有効であり、強制モードに設定されているかの確認です。
オンプレは利用しておらず、Entra Connectで接続等もないのですが、設定しておいても問題ないと思いますので設定しておきます。
EIDSCA.PR02: Default Settings – Password Rule Settings – Password Protection – Enable password protection on Windows Server Active Directory.
上記と同様ですね。
EIDSCA.PR03: Default Settings – Password Rule Settings – Enforce custom list.
パスワード設定で、カスタム禁止パスワードリストを設定しましょう。ということですね。
デフォルトで確か、P@ssword等は利用不可設定が仕様として入っているので、それ以外の会社名とか自社で使われやすいパスワード文字列等を設定しておきましょう。
MS.AAD.1.1: Legacy authentication SHALL be blocked.
レガシー認証をブロックしましょう。ということですね。
条件付きアクセスでレガシー認証をブロックするポリシーを作成しましょう。
今は、テンプレートに「レガシ認証をブロックする」というのがあるので、そちらを選択して作成すればOKです。
自身がロックアウトしないように、除外されたユーザーに自動的に、現在のユーザーが設定されるので確認が終わったら除外設定も見直しましょう。
MS.AAD.2.1: Users detected as high risk SHALL be blocked.
高リスクと判定されたユーザーはブロックするように設定しましょう。ということですね。
Identity Protectionが必要になるため、こちらはEntra ID P2ライセンスが必要となります。
参考URL：https://learn.microsoft.com/ja-jp/entra/id-protection/overview-identity-protection
条件付きアクセスで以下の設定を入れ、アクセスをブロックするポリシーを作成します。
MS.AAD.2.3: Sign-ins detected as high risk SHALL be blocked.
高リスクと判定されたサインインをブロックするようにしましょう。というものです。
こちらもIdentity Protectionの機能なので、Entra ID P2ライセンスが必要になります。
条件付きアクセスで以下の設定を入れ、アクセスをブロックするポリシーを作成します。
CISAはブロックを推奨していますが、Microsoftは多要素認証の要求をすることを推奨しています。
自組織にあわせて設定をし、テストのカスタマイズをするのがいいと思います。
参考URL：https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-risk-policies#microsofts-recommendation
MS.AAD.3.1: Phishing-resistant MFA SHALL be enforced for all users.
フィッシング耐性のある MFA はすべてのユーザーに対して強制しましょう。
とはいっても、共有アカウント等だと対応しきれない場合もあるかと思いますので、除外グループに共有アカウント等TOTP許可アカウントをまとめるといいかもしれません。FIDO2やパスキーの登録が全ユーザー完了していないとログインできず詰むので、慎重に設定しましょう。また必ずbreakglassアカウントを除外しておきましょう。
breakglassアカウントこそちゃんと制御したいんですがここはジレンマですよね・・・
条件付きアクセスで以下のような設定を入れます。
- ユーザー → すべてのユーザー(必要に応じて除外設定を追加）
- ターゲットリソース → すべてのクラウドアプリ
- アクセス制御 → アクセス権の付与 → 認証強度が必要
MS.AAD.3.3: If phishing-resistant MFA has not been enforced and Microsoft Authenticator is enabled, it SHALL be configured to show login context information.
フィッシング耐性MFAが強制されていないため、Microsoft Authenticatorの設定を以下のように変更しておくべき。というものです。
| Microsoft Authenticator OTP の使用を許可する | いいえ |
| プッシュ通知に番号の一致が必要 | 有効 |
| プッシュ通知とパスワードレス通知にアプリケーション名を表示する | 有効 |
MS.AAD.3.5: The authentication methods SMS, Voice Call, and Email One-Time Passcode (OTP) SHALL be disabled.
認証方法のSMS、音声通話、電子メールのワンタイム パスコードは無効にするべき。というものですね。
これSSPRをやるにでは、電子メールのOTPは有効にしておかないと行けなかった気がするのですが、今はもうそんなことはないんですかね？
モバイルアプリ通知があればいけるのかな。
参考URL：https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sspr-howitworks#authentication-methods
以下の設定画面で、SMS、音声通話、メールOTPの無効化します。
MS.AAD.3.6: Phishing-resistant MFA SHALL be required for highly privileged roles.
PIM等で高い権限へ昇格できるユーザーは、フィッシング耐性のあるMFAを要求するようにしましょう。ということですね。
これはその通りなので、PIMを利用できるユーザー用の条件付きアクセスで設定しておくといいかと思います。
こちらもFIDO2の設定が必要なので、登録が完了していから条件付きアクセスを有効化するといった手順が必要ですね。
グループPIMを利用してうまく動的に制御できないかな。とか思っています。
MS.AAD.3.7: Managed devices SHOULD be required for authentication.
管理対象デバイス(デバイスが準拠としてマークされていること)からのアクセスに制限しましょう。ということです。
がこれは、Mac端末がある場合等にはなかなか厳しいので別な手段でデバイストラスト的なことをしている場合には、テストポリシーを変更するか、このテストは除外するといった対応が必要ですね
MS.AAD.3.8: Managed Devices SHOULD be required to register MFA.
こちらはMFAを登録できるデバイスは、管理対象デバイス(デバイスが準拠としてマークされていること)からのみに制限するべき。というものです。
これもMac端末等がある場合にはなかなか厳しいと思いますので、運用によってテストポリシーを除外等を検討されるといいかなと思います。
内容的にはそうだよなとはとても思いますが。
MS.AAD.5.1: Only administrators SHALL be allowed to register applications.
アプリケーションの登録は管理者のみに許可するようにしましょう。
デフォルト設定では、「ユーザーはアプリケーションを登録できる」が有効になっています。
PIM昇格で、権限をもったユーザーのみがアプリケーション登録ができるようにこの設定を無効化しておきます。
MS.AAD.5.2: Only administrators SHALL be allowed to consent to applications.
アプリケーションのユーザー同意ができるのは管理者のみに制限しましょう。
EIDSCA.AP08と同じですね
MS.AAD.5.3: An admin consent workflow SHALL be configured for applications.
アプリケーションのユーザー同意の際に管理者への同意ワークフローを構成しましょう。
この設定をすると以下のようなリンクが表示され管理者へリクエストが送信されます。
EIDSCA.AP09と同じですね。
MS.AAD.5.4: Group owners SHALL NOT be allowed to consent to applications.
グループ所有者がアプリケーションに同意できないようにしましょう。
こちらですが、設定箇所が見当たらなかったので誰か教えてください。
MS.AAD.7.4: Permanent active role assignments SHALL NOT be allowed for highly privileged roles.
高い権限を持つロールを、永続的なアクティブロールに割り当てないようにしましょう。
こちらの「アクティブな割り当て」に割り当てるのではなく、「資格のある割り当て」側に設定をし、利用したいときに必要ロールに昇格しましょう。
MS.AAD.7.6: Activation of the Global Administrator role SHALL require approval.
グローバル管理者ロールへの昇格は承認制にするようにしましょう。
ここは組織規模によって運用できるできないがあるとは思いますが、グローバル管理者への昇格には別なユーザーの承認が必要なように設定しておきましょう。
以下の設定にチェックを入れておくということですね
MS.AAD.7.7: Eligible and Active highly privileged role assignments SHALL trigger an alert.
高い権限ロールの割り当てがあった場合にはアラートを送信するように設定しましょう。
ここの「その他の受信者」に担当部署のML等を入れておくといいかと思います。
MS.AAD.7.8: User activation of the Global Administrator role SHALL trigger an alert.
グローバル管理者ロールがアクティブ化された場合には、アラートを送信するようにしましょう。
MS.AAD7.7と同様にグローバル管理者ロールに、通知設定を入れておくようにします。
MS.AAD.7.9: User activation of other highly privileged roles SHOULD trigger an alert.
高い権限を持つロールがアクティブ化された際に、アラートを送信するようにしましょう。
このテストでは、以下のロールに対して通知設定が入っているかが確認されます。
- ユーザー管理者
- Exchange管理者
- SharePoint管理者
- アプリケーション管理者
- 特権ロール管理者
- クラウドアプリケーション管理者
- ハイブリッドID管理者
MS.AAD.8.3: Guest invites SHOULD only be allowed to specific external domains that have been authorized by the agency for legitimate business purposes.
ゲストの招待は、承認された外部ドメイン対してのみ許可するようにしましょう。
B2Bコレボレーションの設定で、
「外部のユーザーとグループ」で「アクセスのブロック」に
「アプリケーション」タブで「アクセスのブロック」設定にします。
MT.1001: At least one Conditional Access policy is configured with device compliance.
条件付きアクセスで、コンプライアンス・ポリシーを要求する設定を入れましょう。
準拠済みデバイスの使用を強制する条件付きアクセスポリシーを1つ以上用意してください。となっています。
が、こちらも組織ポリシーやMac端末等々がある場合には厳しい場合もあると思いますので、テストから除外する等を検討するのが良いかと。
MT.1008: At least one Conditional Access policy is configured to require MFA for Azure management.
Azure管理センターへのアクセスに、MFAを要求する条件付きアクセスポリシーを入れましょう。
アプリの選択で、Azure管理センターが選択可能な場合には多要素認証を要求するようにポリシーを作成しましょう
MT.1009: At least one Conditional Access policy is configured to block other legacy authentication.
レガシー認証をブロックするようにしましょう。
MS.AAD.1.1と同じですね
MT.1010: At least one Conditional Access policy is configured to block legacy authentication for Exchange ActiveSync.
Exchange ActiveSyncの従来の認証をブロックするようにしましょう。
MS.AAD.1.1と同じですね
MT.1011: At least one Conditional Access policy is configured to secure security info registration only from a trusted location.
セキュリティ情報の登録を保護する条件付きアクセスポリシーを入れましょう。
参考URL：https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-policy-registration
条件付きアクセスでターゲットリソースで以下のように選択し、必要な条件を付与していきます。
例えばですが、オフィスの固定IPからのみセキュリティ情報の登録が可能にする。とかの設定をします。
MT.1012: At least one Conditional Access policy is configured to require MFA for risky sign-ins.
リスクのあるサインインに対して、MFAを要求するように構成しましょう。
MS.AAD.2.3と同じですね。
MT.1013: At least one Conditional Access policy is configured to require new password when user risk is high
ユーザーリスクが高の場合に、パスワード変更を要求するようにしましょう。
MS.AAD.2.1と同じですね。
MT.1014: At least one Conditional Access policy is configured to require compliant or Entra hybrid joined devices for admins.
高い権限を持ったロール利用時は、社給デバイスからであることを要求するようにしましょう。
Intune以外のMDMを利用して他のデバイスを管理している場合には少しむずかしいですが、
他の手法で対応している場合でも、その条件を満たしていないと高い権限が利用できない。や昇格できない等の設定をしておくとよいかと思います。
MT.1015: At least one Conditional Access policy is configured to block access for unknown or unsupported device platforms.
不明、またはサポートされていないデバイスプラットフォームからのアクセスをブロックしましょう。
WindowsとMacしか配布していない場合であれば、Linuxからのアクセスは存在しないはずなのでブロックしてしまいましょう。
MT.1016: At least one Conditional Access policy is configured to require MFA for guest access.
ゲストアカウントに対して、MFAを必ず要求するようにしましょう。
条件付きアクセスで、ユーザーとして「ゲストまたは外部ユーザー」を選択し、多要素認証を必ず要求するように設定します。
MT.1017: At least one Conditional Access policy is configured to enforce non persistent browser session for non-corporate devices.
社給デバイス以外は、非永続的なブラウザーセッションを強制するように構成しましょう。
社外デバイスと判定が出来る場合には、セッション時間を短くしておきましょう。
ポリシー次第ですが、最低でも1日1回にしたいですね。
MT.1018: At least one Conditional Access policy is configured to enforce sign-in frequency for non-corporate devices.
社給デバイス以外は、サインイン頻度を強制するようにしましょう。
MT.1017とほぼ同じです。
MT.1019: At least one Conditional Access policy is configured to enable application enforced restrictions.
社給デバイス以外からは、SharePoint、OneDrive、Exchangeコンテンツへのアクセスをブロックするか制限しましょう。
参考URL：https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-conditional-access-session#application-enforced-restrictions
MT.1024: Entra Recommendation – .
Entraの設定推奨事項を確認しましょう。
参考URL：https://learn.microsoft.com/en-us/entra/identity/monitoring-health/overview-recommendations
MT.1028: No user with mailbox and permanent role assignment on Control Plane.
高い権限を持つユーザーのメールアドレスを管理者アカウントとしないようにする
参考URL：https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-planning#ensure-separate-user-accounts-and-mail-forwarding-for-global-administrator-accounts
強い権限を持ったユーザーのメールボックスへフィッシングメール等が送られてくると強い権限を奪取されてしまうため、メールボックスを持ったユーザーをグローバル管理者に割り当てたり、PIM等で昇格できるようにせず
グローバル管理者専用の個別アカウントを作成するようにしましょう。
またそのメールは、担当者へ転送し、管理者宛への連絡に来づけるようにしておきましょう。
MT.1029: Stale accounts are not assigned to privileged roles.
30日以上サインインしていないアカウントの特権ロールは剥奪するようにしましょう。
毎月棚卸しをして、30日以上サインインしていないアカウントがある場合には無効化するか、削除の確認をするフローにしてしまうのがいいかと思います。
MT.1030: Eligible role assignments on Control Plane are in use by administrators.
過去30日間特権ロールを利用していないユーザーがいるので確認しましょう。
たまにしか利用しないユーザーというのもいるので、運用をどうするべきか検討が必要ですが、
余計な権限は剥奪してしまうのがいいと思います。利用したい際には再申請してもらえればいいので。
またはグループPIMを利用するといいのかもしれません。
MT.1031: Privileged role on Control Plane are managed by PIM only.
特権ロールはPIMによってのみ管理されていること。
ユーザーに直接特権ロールを付与せず、PIMを利用して昇格できるようにしておきましょう。
PIMの利用には、Entra ID P2ライセンスかEntra Suiteライセンスが必要です。
PIM以外での昇格があった場合に検知できるようにしておきましょう。
参考URL：https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-configure-security-alerts#roles-are-being-assigned-outside-of-privileged-identity-management
PIM→Azureリソース→Azureサブスクリプションを選択→警告→設定をクリック
「ロールが Privileged Identity Management の外で割り当てられています」を有効にします。
MT.1032: Limited number of Global Admins are assigned.
グローバル管理者の数を最低限にしておきましょう。
参考URL：https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-configure-security-alerts#there-are-too-many-global-administrators
Maesterでは、Break Glassアカウントと識別されたアカウントの場合にはこのチェックから除外されるようです。
Break Glassアカウント以外にはグローバル管理者ロールを付与しないように設定しておきましょう。
まとめ
一人テナントなので、設定できないものも(PIMで承認する人がいないので設定できないとか）ありますが、ちょこちょこ設定を変更していったところセキュアスコアが71%まで上昇しました。
設定を変えたばかりのもあるため、すべては反映されていないと思いますがいいですね
修正設定をしたことによって新たな検知項目が増えたりしましたが、都度都度内容を確認して対応し、セキュアにしていきたいですね。
GitHub Actionsを利用した自動実行等で定期的に監査をするようにしましょう。
カスタムテストも記述できるので、設定変更によっておかしくなった箇所等を検知できるようにしておくといいと思います。
Break Glassアカウントが実は削除されてしまっていた等に気づくために、アカウントの存在確認テストなども入れておくのが良いのかなと思っています。
また、Entra をどのように設定していくとセキュアになるのかといったベースラインとして把握しておくことも大事かなと思いますし、他のIdPを利用している場合でも、これは真似できるとか確かにこれはやったほうがいいよなとかの気付きにもなるので、とりあえずテストをしてみるのもお勧めです。
参考URL
Maester
https://maester.dev/
AzureAD Attack Defense
https://github.com/Cloud-Architekt/AzureAD-Attack-Defense
SCuBA Project
https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project
