ぴろログ

Output Driven

Azure AD の緊急アクセス用管理者アカウントの管理策を設定した

Azure AD の運用のなかで、条件付きアクセスの誤設定で管理者自身がロックアウトされてしまい、 Azure AD の管理ポータルにアクセスできなくなるケースがあるとのこと。 このようなケースに備えて、緊急アクセス用管理者アカウント( Emergency access account )の作成が推奨されています。

管理者として別のユーザーのアカウントへのサインインやアクティブ化ができなくなるので、Azure Active Directory (Azure AD) 組織から誤ってロックアウトされないようにすることが重要です。 複数の "緊急アクセス用アカウント" を組織に作成することにより、誤って管理アクセスが不可能になることによる影響を軽減できます。

緊急アクセス用管理者アカウントを管理する - Azure AD | Microsoft Docs

個人テナントで Emergency access account を作成し、推奨される運用にあわせて設定したことをメモしておきます。

※ Microsoft365 E5 を利用しており、同ライセンスにより利用可能な機能がいくつかあります。

推奨される運用

上記の公式ドキュメントにある推奨事項から以下を抜粋しました。

  • .onmicrosoft.com ドメインでアカウントを作成する
  • グローバル管理者ロールの割り当てを、緊急アクセス用アカウントに対して永続的に設定
  • MFA 設定や条件付きアクセスポリシーから除外
  • アカウントの資格情報を安全に保管する
  • サインインログを監視する
  • 定期的(90日ごと)にアカウントを検証する
    • アカウントチェックアクティビティが行われていることをセキュリティ監視スタッフが認識していること
    • グローバル管理者権限が付与されていること
    • パスワードの更新・ MFA 登録状況

設定

.onmicrosot.com ドメインでアカウントを作成

.onmicrosoft.com ドメインは、 Azure AD でテナントを作成時に設定する最初のドメインのことです。 <任意の文字列>.onmicrosoft.com で発行されます。

カスタムドメインを設定している場合は、ユーザ作成時にサフィックス.onmicrosoft.com に切り替える必要があります。

f:id:pirox07:20201018133132p:plain

カスタムドメインは削除されることもあるため、影響を受けないよう .onmicrosot.com ドメインでアカウントを作成しましょう、ということかと思います。

ユーザ作成時に設定したパスワードは初回サインイン時に変更を求められます。 Azure AD では最大で256文字までのパスワードが設定できる仕様となっています。

Emergency access account を守るために256 文字のパスワードを設定しようとすると「パスワードの複雑性を満たさない」という旨のエラーが表示されました。

f:id:pirox07:20201018232019p:plain

文字の種類の組み合わせを見直しても同じエラーが出るため、試しに適当な一文字を削除して255文字にしたところ変更が成功しました。(この挙動についてサポートに問い合わせ中です。)

グローバル管理者ロールを [ 永続的 ] に設定

Azure AD では2 通りのロールの割り当て方があります。

  • Eligible (対象): ロールを使用するために指定されたアクションが必要( MFA 、承認者による承認、等)
  • Active: 制約を設けずに、ロールによって提供される特権を常に行使できる

「 Eligible (対象)」Privileged Identity Management (PIM) の機能で、普段は一般ユーザと同じ権限でアカウントを使用し、必要なときに Just-in-Time で特権アクセスを付与することができます。利用するには特定のライセンスが必要です。

Privileged Identity Management を使用するには、次のライセンスのいずれかが必要です。
- Azure AD Premium P2
- Enterprise Mobility + Security (EMS) E5

PIM の使用を開始する - Azure Active Directory | Microsoft Docs

Emergency access account に対しては、ロールの割り当て時に [ Active ] - [ 永続的 ] を選択します。

f:id:pirox07:20201018133744p:plain

アカウントの資格情報を安全に保管する

緊急アクセス用アカウントの資格情報は安全に保管し、それらを使うことを許可されたユーザーのみに知らせる必要があります。 スマートカードを使用するお客様も、パスワードを使用するお客様もいます。 緊急アクセス用アカウントのパスワードは、通常、2 または 3 つの部分に分けて、異なる紙に書き記し、個別に安全な耐火性の場所に保管します。

緊急アクセス用管理者アカウントを管理する - Azure AD | Microsoft Docs

自宅に耐火性の何かは無いですし、分散保管も厳しいので、とりあえず 1Password で管理します。 (企業で運用する場合は、複数名でパスワードの一部分ずつを管理する形でしょうか。。)

MFA 登録ポリシーから除外

Identity Protection の機能でテナントの全ユーザに MFA 登録を強制していますが、「対象外」のユーザ(またはグループ)を指定することができます。

Emergency access account はポリシーの対象外としました。

f:id:pirox07:20201018133927p:plain

条件付きアクセスポリシーからの除外

条件付きアクセスポリシーの設定時にも、ポリシーの対象外となるユーザまたはグループを設定することができます。

f:id:pirox07:20201018134002p:plain

SSPR の無効化

セルフサービスパスワードリセット( SSPR )は、パスワードを忘れてしまった場合にユーザ自身でリセットをかけることができる利便性の高いサービスです。

通常、SSPR を利用するには対象ユーザに特定の有償ライセンスを割り当てる必要がありますが、何らかの管理ロールが割り当てられたユーザはライセンス不要でセルフリセットが可能なようです。

管理ロールを割り当てられたユーザは、SSPR 時に以下のうち2つの方法での認証を求められます。

  • モバイルアプリの通知 ( Microsoft Authenticator )
  • モバイルアプリコード ( TOTP )
  • 電子メール ( 認証コード )
  • TEL / SMS ( 認証コード )

Microsoft では、あらゆる Azure 管理者ロールに強力な既定の 2 ゲート パスワードのリセット ポリシーを適用します。 このポリシーは、ユーザーに対して定義したものとは異なる場合があります。また、このポリシーを変更することはできません。 パスワードのリセット機能は、必ず Azure 管理者ロールが割り当てられていないユーザーとしてテストする必要があります。

セルフサービス パスワード リセット ポリシー - Azure Active Directory | Microsoft Docs

Emergency access account に対してはパスワード以外の認証方法を登録していないので、パスワードリセットをかけようとしても失敗しました。

f:id:pirox07:20201018134340p:plain

余談ですが、 SSPR の適用対象グループに Emergency access account を明示的に所属させると、 SSPR のポリシーが適用されるためかサインイン時に認証要素の登録を求められるようになりました。ついそのまま MFA の登録等をしてしまいそうになります。

意図せず制約をかけることを防止するため、Emergency access account は各種ポリシーの適用対象となるグループには所属させない運用にした方が良さそうです。

サインインログを監視する

公式ドキュメントの手順(サインイン ログと監査ログを監視する )に従って、 Azure Monitor 経由でサインインの検知・アラートを送信する設定をします。

のですが、先にサインインのログを流す設定が必要です。(気づかずに待ちぼうけでした。)

最初に、ログデータの容れ物となる Log Analytics のワークスペースを作成します。 こちらのドキュメント( Azure portal で Log Analytics ワークスペースを作成する - Azure Monitor | Microsoft Docs )に詳しい手順がありますので、作成手順の記載は割愛します。

次に、作成した Log Analytics ワークスペースにサインインのログを流すよう設定します。手順はこちら(Azure Active Directory のログを Azure Monitor ログにストリーミングする | Microsoft Docs)を参照ください。
※サインインのログ( SignInLogs )を 流すにはAzure AD P1 ( or P2 )のライセンスが必要になります。

監査ログのモニタリングも試してみたいので、SignInLogs に加えて AuditLogs も対象として選択しました。

f:id:pirox07:20201018135002p:plain

その後、 Log Analytics ワークスペースでアラートの設定を行います。 こちらの手順の通り設定し(緊急アクセス用管理者アカウントを管理する - Azure AD | Microsoft Docs)、 5 分間隔で Emergency access account のサインインログを確認し、該当ログがあれば所定のメールアドレスに通知させるようにします。

f:id:pirox07:20201018135129p:plain

しばらくして、アラートメールを受信しました。( タイトルはカスタマイズしたもの。)これで第三者による不正アクセスは検知できそうです。

f:id:pirox07:20201018235350p:plain

Azure Monitor は取り込まれるデータ量に対する従量課金となるようで、東日本リージョンで利用する場合、毎月 5GB までは無料でそれ以降は ¥374.08/GB とのこと。無料枠に収まってほしいところですが、やってみないとわからないでしばらく様子見です。。(1ヶ月後に結果を追記しようと思います。)アラートにかかるコストは月額推定 $1.5 と表示されたので、お守り代として許容できる範囲です。

アカウントの定期的な検証

以下の運用を90日ごとに実施しようと思います。

  • アカウントチェック アクティビティが行われていることをセキュリティ監視スタッフ(今回は自分)が認識していることを確認
  • 緊急アクセス用アカウントのアカウント資格情報 (特にパスワード) を更新し、緊急アクセス用アカウントでサインインし管理タスクを実行できることを検証
  • ユーザの個人デバイスや個人情報に Microsoft Azure Multi-Factor Authentication またはセルフサービス パスワード リセット (SSPR) を登録していないことを確認

定期的な監査のトリガとして、 PIM のアクセスレビューを利用してみます。

f:id:pirox07:20201018135636p:plain

検証として頻度を「1回」に設定し、どんなフローになるのかを確認しました。

レビュー担当者がアクセスレビューの依頼通知を受信したら、「レビューを開始する」をクリックします。

f:id:pirox07:20201018135720p:plain

グローバル管理者( Global Administrator )の権限が割り当てられたユーザの一覧が表示されます。[ 監査の詳細 ] の [ 表示 ] をクリックすると、当該ユーザの [ 監査ログ ] 画面にジャンプします。

f:id:pirox07:20201018135841p:plain

[ 監査ログ] では、当該ユーザに加えられた変更や、当該ユーザが加えた変更が確認できます。通常のパスワード変更処理の記録も確認できました。

f:id:pirox07:20201018135924p:plain

ただし Azure AD の機能で参照可能なログは過去 1 ヶ月分という制約があり、 四半期分の確認ができません。 ログを長期間残すために、Azure ストレージにアーカイブすることにしました。

こちらの手順(ストレージ アカウントの作成 - Azure Storage | Microsoft Docs)を実施し、 Azure ストレージアカウントを作成します。

次に(チュートリアル - ディレクトリのログをストレージ アカウントにアーカイブする | Microsoft Docs)、 AuditLogsSigninLogs をそれぞれ180日間保存するよう設定します。

f:id:pirox07:20201018140324p:plain

アーカイブしたログを参照するために、作成済みの Log Analytics ワークスペースのデータソースにストレージアカウントを追加します。

f:id:pirox07:20201019090856p:plain

以下のクエリでセキュリティ情報の登録( MFA 登録)とパスワードの変更操作を抽出してみます。

AuditLogs
| where TimeGenerated > ago(90d)
| where TargetResources contains "<Emergency access account の Object Id>"
| where OperationName == "User registered security info" or OperationName == "Change password (self-service)"

パスワードの変更操作や、 Microsoft Authenticator の登録操作(検証のために設定)の履歴を確認できました。この後 Microsoft Authenticator の登録をリセットしました。

f:id:pirox07:20201019090051p:plain

最後のパスワード変更後にサインインできていることを Azure AD の [ 監視 ] - [ サインインログ ]で確認できたので、アクセスレビューを[ 承認 ]して監査を完了しました。

f:id:pirox07:20201018140419p:plain

まとめ

Microsoft が推奨する運用をいくつか設定してみました。Emergency access account の不正利用の検知や監査が主な運用となります。 パスワードをかなり長い文字数で設定しているものの、 MFA の設定をしないというのはなんとも落ち着かないです。。

検知の仕組みは整備しましたが、万が一 第三者によるアクセスを確認できても対応する前に自テナントを完全に掌握されてしまいそうです。。 アラート通知では Webhook も使えるようなので、 Slack に通知を流す & ボタンをクリックすると Emergency access account をアカウント停止、なフローも整備したいです。

また、 Emergency access account を作らずにこういう選択肢もありだなぁと思います。

blog.haniyama.com

参考資料