マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

ハイセキュアな Azure運用のためのAzure Active Directoryテナントの作り方

  • 原則論としては 1 組織 = 1 テナントで、
    その配下ですべてのクラウド・サービスを利用
  • ただし、Azureの運用用のテナントを分けたい場合もある
  • 業務システム運用に関わるリソースなど
    OA用アカウントと明確に分離しておきたい。
  • と言う事で、
    デプロイ・ガイド(チェックリスト)に、
    幾つかアレンジを加えたモノが本項となっている。
    • 管理を想定したアカウント構成
      (OA用アカウントとの切り離し)
    • オンプレAD とのアカウント同期の削除
    • アプリケーション管理の削除
    • , etc.

詳細

サブスクリプション

基本的にEAから切り出す。

  • 初期状態
    • O365 AAD の EAポータルからサブスクリプションを作成する。
      • https://ea.azure.com
      • EA契約管理者からアサインされたEA契約アカウント管理者が実施。
    • ディレクトリ・サブスクリプションには、課金と環境管理の紐付けがある。

検証では、ダミー・テナントを使用。

  • EA契約アカウント管理者のアカウントでログイン
  • Azure Active Directory管理用のサブスクリプションを作成
    (コード入力、質問回答などを行って、作成する。)
  • サブスクリプションが出来たら名称の変更を行う。

ホーム / B2B

いずれの方式を利用する場合でも、
複数の作業者でアカウントを共有することは避ける。

ホーム・アカウント

個別作成(Azure Active Directoryにアカウントを別途作って利用する)

  • 一方、退職や人事異動を確実に反映させる必要があり、面倒
  • OA 作業からアカウントや端末を切り離せるため、マルウェア攻撃を受け難い。
  • 故に、特権アカウントは、B2Bアカウントではなくホーム・アカウントを使用すると良い。

B2Bアカウント

B2B 招待(O365 テナントから B2B 招待したアカウントを利用する)

  • 1 ユーザ = 1 ID となり、作業者から見て使い勝手がよい
  • 多くの場合、人事システムやオンプレ AD と連携しており、退職時に自動失効する
  • 故に、各種、作業者アカウントは、コチラを使用すると良い。

静的 / 動的

どちらの場合でも、以下のようにするのが基本

  • セキュリティ管理者(あるいは権限管理システム)に対して、
    静的に Privilege Role Administrator ロールを割り当てる。
  • その上で、静的または動的(推奨)に、
    必要に応じて Global Administrator などの作業特権を与える。

静的権限

  • ユーザ単位(またはグループ単位)に権限を付与する
  • 高権限をむやみに与えないようにする(最大でも 5 人程度)

動的権限

Azure AD PIM(特権 ID 管理)を利用して、ユーザに対して動的に権限を付与・はく奪する。

手順

初期構築用アカウント

初期構築時と、構築後の構成変更とを分けて考える。

2つのアカウントを併用するので...。

以下の手順で、初期構築用アカウントに加え複数アカウントを使い回すので...。

InPrivate?ブラウザで作業するなど。

加えて、キャッシュが残らないようにできる。

異なるブラウザを使用する(EdgeとChrome)。

そもそも別物なので。

WWWブラウザのセッション等を別にする。

ユーザ・プロファイルも別になる。

Step 0. O365 用 AAD テナント

  • 通常は、既存の O365 用 AAD テナントを利用
  • 検証用なら
  • 以下の 4つのアカウントを作成
    ea_ea@o365aadEA エンタープライズ管理者の個人アカウント
    ea_aa@o365aadEA アカウント管理者の個人アカウントAzure サブスクリプション払い出し
    xxxx@o365aad一般ユーザ1の個人アカウント
    yyyy@o365aad一般ユーザ2の個人アカウント

Step 1. Azure 用 AAD テナントの作成

  • P2ライセンスの試用版の有効化
  • テナント(ディレクトリ)の属性を変更
    名称や詳細の記述を変更する。

Step 2. 管理者アカウントの作成と保護

アカウントの作成

  • 以下の 4つのアカウントを作成
    • 緊急事態用アカウント(Breakglass Account)
      Azure AD 用、Azure 用の 2 つが必要
    • Azure AD 管理用アカウント
      日常的な Azure AD の管理用に利用するアカウントだが、以下 2 つの検討が必要
ID役割主な日常作業個人/共用ホーム/B2BAAD 権限Azure 権限
bg_admin_aad@prodaad緊急事態用
アカウント
Azure AD 用ナシ共用ホームGlobal Administrator(静的)昇格権限
bg_admin_azure@prodaadAzure 用ナシTenant Root Group/owner(静的)
XXXX_prv_admin@prodaad個人アカウント特権ロール管理用AAD, Azure の
権限払い出し
個人ホーム or B2BPrivilege Role Administrator (静的)なし(暗黙的に User Access Admin を持つ)
YYYY_aad_admin@prodaadAzure AD 管理者用AAD の設定・操作・監査・(Global Reader(静的))
・Global Administrator(PIM
ナシ

※ 上記の表の通り、Azure 権限を除いて、アカウントを作成する。

  • 作成後の設定

パスワード・ポリシーの変更

  • パスワード保護機能(必要に応じて)
    • [Azure Active Directory] > [セキュリティ] > [認証方法] > [パスワード保護]を開く
    • 必要に応じてロックアウト、禁止パスワードの登録などを行う
  • パスワード有効期限の無効化
    • 既定は 90 日で失効
    • 緊急事態用アカウントでは必須
    • PowerShellで設定
      Install-Module -Name AzureAD
      Connect-AzureAD
      Get-AzureADUser -Filter "startswith(userPrincipalName,'緊急事態用アカウントのプレフィックス')" | Set- AzureADUser -PasswordPolicies DisablePasswordExpiration

管理者アカウントの保護

  • セキュリティ・グループの作成と割当
  • 緊急事態用アカウント用グループを作成し、各アカウントに割当
  • 個人アカウント用グループを作成し、各アカウントに割当
    権限をPIMでJIT割当するYYYY_aad_admin@prodaadのような
    アカウントは変更される可能性が高いので、対象外にする等。
  • 必要に応じて、B2Bを使用している場合など、動的メンバーシップ・ルールを使用する。
  • 対象
    • 対象:個人アカウント用グループ
    • 対象外:緊急事態用アカウント用グループ
  • アクセス制御で、多要素認証(MFA)などを追加する。
    その他、ネームド・ロケーション、セキュア・ワークステーション等がある。
  • レポート専用で作成して、問題なく動作しているか確認してからオンする。
  • 対象
    • 対象:個人アカウント用グループ
    • 対象外:緊急事態用アカウント用グループ
  • ユーザ・リスク、サインイン・リスク、MFA登録ポリシーなどを追加する。

Step 3. Azure サブスクリプションの準備

サブスクリプションを作成する。

Step 1のテナントで、サブスクリプションを作成する。

  • 作成に使用するアカウントは、
    EAアカウント管理者の個人アカウント(ea_aa@o365aad)
  • 2つのテナントに1つのサブスクリプションとなる。

サブスクリプションの環境管理を付け替える。

  • EA契約アカウント管理者(ea_aa@o365aad)は、招待を承認する。
  • 招待を承認する。
  • ディレクトリの切替が可能になる。
  • ディレクトリの変更を実行する。

変更する。...が「Microsoft Azure Pass」だと出来ないとのこと。

Azure権限付与(ルート管理グループ)

  • 初期構築アカウントでログインし、
    「Azureリソースのアクセス管理」が「はい」に
    なっていることを確認し、以下の作業を行う。
  • 自身がユーザ・アクセス管理者(User Access Administrator)権限を
    持っているので、自身に更に所有者(Owner)権限を追加する。
    • 管理グループ(Tenant Root Group)のアクセス制御(IAM)画面から、
      Azure AD 用の緊急事態用アカウント(bg_admin_aad@prodaad)に以下の権限を割当てる。
      • 所有者(Owner)
      • ユーザ・アクセス管理者(User Access Administrator)

Step 4. ログ・監視・アラートの設定

長期ログ保存のための設定

サブスクリプションに対し各種のログを長期保存
するため、ストレージの作成と診断ログの設定を行う。

  • 以下 3 つのリソースを作成
  • リソース・グループ
  • Log Analyticsワーク・スペース
    イベント・ログの収集と表示
  • ストレージ・アカウント
    • より長期のログ保管のストレージ
    • プライベート・エンドポイントを指定(パブリック・エンドポイントを塞ぐ)
  • 診断設定を有効化する。
    • Azure AD > サインイン > データ設定のエクスポート > 診断設定
    • サブスクリプション > アクティビティ・ログ > 診断設定

緊急事態用アカウント利用時に警告メールを送付する。

  • 緊急事態用アカウントの2つのオブジェクトIDを調査する(xxxx, yyyy)。
  • 緊急事態アカウントのサインイン(重大度 0)
  • Custom Log Search から以下の検索クエリを指定
    SigninLogs
    | project UserId
    | where UserId == "xxxx" or UserId == "yyyy"
  • アラート・ロジック:「結果の数が 0 より大きい場合」(既定値)
  • セキュリティ・チームのML宛にメール送信するアクション・グループを作成・設定
  • アラート・ルールの詳細でタイトル、本文、重大度 0 など設定。
  • 緊急事態アカウントの設定変更(重大度 1)
  • Custom Log Search から以下の検索クエリを指定
    AuditLogs
    | where TargetResources[0].id == "xxxx" or TargetResources[0].id == "yyyy"
  • アラートロジック:「結果の数が 0 より大きい場合」(既定値)
  • 先ほど作成したアクション・グループを設定
  • アラート・ルールの詳細でタイトル、本文、重大度 1 など設定。

Step 5. テストとクリーンアップ

緊急事態アカウントの動作確認

  • 封緘パスワードの用意
    Add-type -AssemblyName System.Web
    $len = 30
    do { $pwd = [System.Web.Security.Membership]::GeneratePassword($len,0) } until 
    ( $pwd -match '^[0-9a-zA-Z]+$' ); $pwd
  • 緊急事態アカウントでサインイン
    初回アクセス時にPWD変更が求められるので、封緘パスワードに変更。
  • 緊急事態アカウントの動作確認
    ログイン、権限確認、監査ログの参照などを行う。
  • 緊急事態アカウントのパスワードの封緘
    アカウント情報を封緘(リアルに封筒などに入れる)

全体セキュリティ管理者アカウントの動作確認

  • 特権ロール管理用の個人アカウント(XXXX_prv_admin@prodaad)でログイン
  • PIMでAzure AD 管理者用の個人アカウント(YYYY_aad_admin@prodaad)に、ロールを割当てる。
  • Azure AD 管理者用の個人アカウント(YYYY_aad_admin@prodaad)でログインして構成作業を行う。

初期構築用アカウントの削除

参考

Microsoft Docs

nakama

Azure 管理用 Azure AD テナントの作成方法中にも同様のトピックが含まれる。


Tags: :インフラストラクチャ, :クラウド, :Azure, :Active Directory, :認証基盤, :クレームベース認証


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2021-06-21 (月) 14:43:29 (39d)