Azure AD のグループ管理について

Azure AD のグループ

Azure AD の中心的な機能といえばアカウントやグループの管理ですよね。
グループは大きく分けて2つあります。

  • セキュリティグループ
  • Microsoft 365 グループ

また、セキュリティグループ、Microsoft 365 グループそれぞれ動的グループというものが作れて条件に合ったユーザー/デバイスを動的にグループに所属させると言う機能も提供されています。

セキュリティグループ

セキュリティグループは以下のように分類されます。

  • セキュリティグループ(メールアドレスなし)
    • オンプレミスADと同期する場合、メールアドレスが設定されていないとこの形式になる
  • メールアドレスが有効なセキュリティグループ
    • クラウドで作成する場合はExchange Onlineの管理画面での操作が必要
    • クラウドで作成した場合、後からメールアドレスを有効にすることが出来ない(オンプレADは可能)

また、グループに割り当てられるものはユーザーとデバイスがあり、メンバーシップは以下のように分類されます。
割り当て済みは手動でユーザーもしくはデバイスを登録できます。 デバイスグループは Azure AD Join / Azure AD Registered デバイスを登録でき、主に Microsoft Intune の利用時に必要となります。

  • 割り当て済み
  • 動的ユーザー
  • 動的デバイス

他のMicrosoft 365 プロダクトで権限など管理する場合、メールアドレスが有効ではないセキュリティグループでは権限が当てられなかったりするので、ユーザーを割り当てる場合はメールアドレスを有効にするか Microsoft 365 グループを選択することをお勧めします。

Microsoft 365 グループ

メンバーに共有メールボックス、カレンダー、ファイル、SharePoint サイトなどへのアクセスを付与できます。
グループ メンバーにはユーザーのみ指定可能です。
Teamsのチームを作成する時にはこのグループが作成されます。
部署毎のチームを作成する場合は、動的グループとして Microsoft 365 グループとして作成して動的に所属部署のユーザーアカウントを入れることも可能です。

Microsoft 365 グループのメンバーシップの種類は以下が選択可能です。

  • 割り当て済み
  • 動的ユーザー

動的ユーザーグループ

条件を指定して動的にユーザーをグループメンバーとして登録できます。
ルールとして指定できるプロパティは以下です。

  • accountEnabled
  • objectId
  • displayName
  • city
  • companyName
  • country
  • department
  • facsimileTelephoneNumber
  • givenName
  • employeeId
  • jobTitle
  • mail
  • mailNickname
  • mobile
  • passwordPolicies
  • physicalDeliveryOfficeName
  • postalCode
  • perferredLanguage
  • sipProxyAddress
  • state
  • streetAddress
  • surname
  • telephoneNumber
  • usageLocation
  • userPrincipalName
  • userType
  • onPremisesSecurityIdentifier
  • otherMails
  • proxyAddresses
  • assignedPlans
  • extensionAttribute1 〜 15

動的デバイスグループ

条件を指定して動的にデバイスをグループメンバーとして登録できます。
ルールとして指定できるプロパティは以下です。

  • accountEnabled
  • objectId
  • displayName
  • isRooted
  • deviceOSType
  • deviceOSVersion
  • deviceCategory
  • deviceManufacturer
  • deviceModel
  • deviceOwnership
  • enrollmentProfileName
  • managementType
  • organizationalUnit
  • deviceId
  • devicePhysicallds
  • systemLabels

例えば、Windowsだけを指定したデバイスグループを作る場合は以下のように指定します。

項目 パラメータ
プロパティ deviceOSType
演算子 Equals
Windows

Windows 11 だけのグループを作りたければ、上記条件に加えて以下をand条件で指定することで作成できます。

項目 パラメータ
プロパティ deviceOSVersion
演算子 Starts With
10.0.22000

AndroidiPhoneといった指定も出来ますので、色々お試しください。

グループへの Azure AD ロールの割り当て

セキュリティ、Microsoft 365 それぞれのグループには Azure AD ロールの割り当てが可能です。
これは例えば情シス部門へ Microsoft Intune の管理権限を割り振りたいという場合に、個人個人のアカウントではなく部署グループにロール割り当てをすることで、部署異動時の管理工数の削減が可能です。
この機能はグループ作成時にのみ有効化できるため、作成時にあらかじめロール割り当てを使うか決めておく必要があります。

f:id:tsukatoh:20220304183829p:plain

グループへのライセンス割り当て

Microsoft 365 / Office 365 ライセンスなどはグループに対して割り当てすることが可能です。
こちらも部署毎にE3だったりE5だったりと別れている場合は、各部署グループにあらかじめライセンス割り当てをしておくことで部署異動時に動的にライセンスをユーザーへ割り当てることができます。

f:id:tsukatoh:20220304183657p:plain

まとめ

Microsoft Azure を使う場合でも、Microsoft 365 を使う場合でも Azure AD のアカウント管理は重要なファクターです。
グループをうまく設計することで、アカウントやデバイスの管理が数倍にも楽になります。
組織にあったグループの設計をして管理工数を減らせる運用を是非目指してみてください。

Azure AD 条件付きアクセスの活用について

Azure AD

前回Azure ADの機能やプランについて書きましたが、Azure ADってMicrosoft 365を使うから必要ってことじゃなく、認証基盤として優秀なので連携できるアプリケーションは連携して使った方がいいってことです。
Micorosft Azure 使うから管理者だけ管理しておけばいいや、ではなくちゃんと権限ロール管理をして管理者自体を管理したりアクセス制御したりIAMでAzureリソースへの権限管理したりと必要になってきますので是非管理手法を学んでいただけるとよりよいクラウドライフが送れると思うんですよね。
というわけで、今回は条件付きアクセスです。
Azureポータルへのアクセスなんかも制御できます。

Azure AD 条件付きアクセス

Azure AD Premium P1 / P2 で利用できる機能で、ユーザーが対象のアプリケーション認証時にアクセス許可/ブロックに対する条件をつけることが可能です。
例えば、以下のようなことができます。

  • 総務部のアカウント(かつ部長は除外)がExchange Online にアクセス
  • Windowsのみアクセス可能
  • 社内ネットワークからのみアクセス可能
  • 多要素認証を強制
  • Intune で管理されている準拠済みデバイス
  • Hybrid Azure AD Join を使用したデバイス
  • アプリの条件付きアクセス制御で重要データが入っている場合拒否

以前、Azure Virtual Desktop で利用する場合の条件付きアクセスも書いているので参考にしてみてください。

tsukatoh.hatenablog.com

条件付きアクセスポリシー

設定できる項目は色々あります。
2022/03/03 時点では以下項目が設定可能です。

  • ユーザー
    • ユーザー
    • ユーザーグループ
    • 権限ロール
  • クラウドアプリ
  • 条件
    • ユーザーのリスク
      • 高 / 中 / 低
    • サインインのリスク
      • 高 / 中 / 低 / リスクなし
    • バイスプラットフォーム
    • 場所
      • MFA 信頼済みIP / 設定済みの場所
    • クライアントアプリ
      • 先進認証クライアント / レガシ認証クライアント
    • バイスのフィルター
      • フィルター処理が書けます(動的グループと同様のフィルター)

上記の条件に対して以下の制御を行うことができます。

  • アクセスのブロック
  • アクセス権の付与
    • 多要素認証を要求する
    • Intune の準拠デバイス
    • Hybrid AAD Join デバイス
    • 承認されたクライアントアプリ
    • アプリの保護ポリシー必須
    • パスワードの変更を必須

アクセス権の付与については「すべて」もしくは「いずれか」で指定が可能です。

これを組み合わせていくことでアプリケーションへのアクセスをセキュアなものにしていきます。

実装例

前提条件として以下があるとします。

  • 社内ユーザーで管理者ロールは対象外
  • Office 365アプリケーション
  • Intune 管理デバイス
  • 場所はどこでも
  • 多要素認証は必須
  • バイス種別はWindowsiOSにしぼる
  • レガシ認証は除外したい

社内ユーザーに絞る理由としてはゲスト参加しているユーザーやコラボレーションした先の外部ユーザーはアクセスさせたくないとかな要件ですね。
Intune管理デバイスに絞る理由は社給のデバイスだったりBYODでも会社として管理・許可しているデバイスを使わせるという理由になります。
場所については最近流行りのゼロトラストですね、どこからでも許可したい場合に色々と縛りをつけることでセキュリティを担保するという考え方です。
正直今回条件付きアクセスの観点で書いていますが、ゼロトラストをやる場合はMicrosoft Defender for Endpoint の導入までやった方がいいです。
Intune のデバイス管理と連携してインシデント管理やデバイス管理が可能になります。

実際の設定画面は以下となります。

f:id:tsukatoh:20220302163935p:plain f:id:tsukatoh:20220302163952p:plain f:id:tsukatoh:20220302164008p:plain f:id:tsukatoh:20220302164024p:plain f:id:tsukatoh:20220302164110p:plain f:id:tsukatoh:20220302164127p:plain f:id:tsukatoh:20220302164142p:plain

認証について

条件付きアクセスを利用する場合、よく言われるのが「条件付きアクセスっていつかかるんですか?」です。
条件付きアクセスはユーザー認証時にかかるものです。
上記の例で言うと、Office 365 アプリに対象のユーザーがアクセス・認証した時に条件に合致したものをアプリへのアクセスを許可またはブロックするといった仕組みになります。
簡単に図で書くと以下のような流れになります。

f:id:tsukatoh:20220302170909p:plain

補足情報ですが、シャドーIT対策で会社のテナントにはアクセスさせるけど、個人所有テナントにはアクセスさせないとかいう場合はProxy製品で対応する形となります。

docs.microsoft.com

まとめ

条件付きアクセスを使ったクラウドアプリケーションへのアクセス制御の一例ですが、複数ポリシーを使ってルールを作っていく形となります。
一つで作ろうとしても無理が出てきますので、アプリケーション単位だったりユーザー単位だったりで工夫して作る必要があるので試行錯誤が必要かなと思います。

次回はIdentity Protectionかグループ管理辺りでもまとめたいと思います。

Azure Active Directory のプラン別機能について

Azure Active Directory (Azure AD)とは

クラウドベースの ID サービス (IDaaS) で、シングルサインオンや条件付きアクセス、多要素認証などの機能を提供しています。
ただ、Active Directoryという名前がついていてもドメインコントローラーの機能は提供されません。
ドメインコントローラーが必要なら Azure AD Domain Services の導入や、オンプレミスADとAzure ADの連携のためのAzure AD Connectの導入を検討ください。
また、Azure AD B2C や Azure AD B2B といった顧客ID・アクセス管理だったりコラボレーションを提供していますがここでは割愛します。

Azure AD の機能とプランによる違い

Azure AD のプランはFree、Office 365 アプリ、Premium P1、Premium P2の4つが提供されています。(2022/03/02現在) Office 365 アプリはO365などのサブスクリプションを購入したテナントに適用されるプランです。
Premiumは有償プランとなり、個別購入もしくはMicrosoft 365 E3以上に同梱される形で提供されます。
以下はプラン別の提供機能の違いになります。

機能 Free O365 P1 P2
ユーザー/グループ/デバイス管理
外部ユーザー連携
オンプレミスAD同期
カスタムドメイン
シングルサインオン
セルフパスワードリセット ×
多要素認証 ×
IP制限 × ×
エンタープライズアプリケーション
レポート
アプリケーションプロキシ × ×
不正アクセスアラート × × ×
条件付きアクセス × ×
リスクベースの条件付きアクセス × × ×
アプリの条件付きアクセス(MCAS統合) × ×
Identity Protection × × ×
Privileged Identity Management × × ×

公式サイト情報はコチラ
docs.microsoft.com

テナントについて

Microsoft社が提供するクラウドサービスにはテナントという考え方があり、テナント内は自社の領域となります。
例えて言うならオフィスビルだったりマンションといったものでしょうか。
認証時の画面はMicrosoft社が用意している共有のものを使用しますが、アカウントを入力した時点でテナントの判別がされます。
アカウントの@以降、ドメインでの判断となります。
これによりサインインするテナントへ割り振りされるのです。

機能について

よく使う機能を抜粋して紹介します。

ユーザー/グループ/デバイス管理

  • ユーザー管理 アカウントの管理、権限ロールの管理ができます
  • グループ管理 セキュリティグループ、Microsoft 365グループの管理ができます

    • セキュリティグループ:一般的なユーザー・デバイスを管理するためのグループでメールアドレスを有効化することも可能(Exchange Online側で作成する必要がありクラウド側のグループでは後から変更が不可)
    • Microsoft 365 グループ:Teamsのチームの管理などにも使われ、M365内のアクセス制御用途で使うことができる

オンプレミスAD同期

オンプレミスADのアカウント/セキュリティグループ/デバイスを Azure AD と同期する機能。
Azure AD Connect サーバーを使って同期する。
既存でADでアカウント管理している場合にはこちらを構成することで、オンプレADとのシングルサインオンが実現できる。
また、AD Joinしているデバイスを連携する Hybrid AD Join を構成することで、オンプレADに参加しているデバイスMicrosoft Intune で管理するために連携したりもできます。

カスタムドメイン

通常 Azure AD テナントを作成した場合、*.onmicrosoft.com というドメインが割り当てられます。
上記とは別に購入したドメインを割り当てることも可能です。

多要素認証

Multi-Factor Authentication が利用できます。

  • 電話
  • SMS
  • Microsoft Authenticator アプリ

追加として Windows Hello for Business なども対象とすることが可能です。

docs.microsoft.com

IP制限

クラウドサービスなので場所を問わずという考え方がゼロトラストですが、アクセス元IPを制限して利用させることも可能です。
この機能はP1以上が必要となります。

エンタープライズアプリケーション

Azure AD 上でクラウドサービス等をアクセス管理することができます。
SAML連携することでシングルサインオンの実装も可能です。

アプリケーションプロキシ

オンプレミスのWebアプリケーションを外部に公開するための機能です。

条件付きアクセス

ユーザー、デバイス、場所などを条件にMFAを強制したり、Intune管理されているデバイスのみアクセス可能にしたりと言った制限がかけられます。
リスクベースの条件付きアクセスを使うことでサインインリスクやユーザーリスクを条件に入れたり、アプリの条件付きアクセスを使うことで Microsoft Defender for Cloud Apps (旧称 Microsoft Cloud App Security [MCAS]) を通じてDLP/AIPを連携させてセッション制御することも可能です。

Identity Protection

サインインリスクやユーザーリスクを検知する機能で以下のようなリスクを特定できます。

  • 匿名 IP アドレスの使用
  • 特殊な移動
  • マルウェアにリンクした IP アドレス
  • 通常とは異なるサインイン プロパティ
  • 漏洩した資格情報
  • パスワード スプレー

Privileged Identity Management

Azure AD の特権ロール管理機能です。
常時特権ロールを割り当てないことにより不要な設定変更やリスクを回避できます。
割り当て可能なユーザー(グループで指定可能)を指定しておき、特権ロールを使用する際に承認を必要とすることでJust-In-Timeによる一定時間内の権限付与を可能にします。

docs.microsoft.com

まとめ

Azure AD は機能レベルによって購入するプランが変わりますので、必要な機能を検討してどのプランを導入するか決定していただければと思います。
セキュリティ観点ではP2まであった方がいいとは思いますが、最低限条件付きアクセス(Premium P1範囲)の導入を検討してみてはいかがでしょうか。

次回は条件付きアクセスをもう少し深く書こうかと思っています。

Azure Virtual Desktop を Azure AD Join 環境で使い、Intuneで管理する

概要

Azure Virtual Desktop (AVD) のVMが Azure AD Join に対応したり Windows 11 MultiSession が公開されたりと昨年色々アップデートがあったのでまとめました。
従来のAVDでは Hybrid AD Join もしくは Azure AD Domain Services へ Join されたVMのみサポートされていましたが、2021/9/22の発表でAzure AD Join がGAされました。
ただ、現状(2021/1/5 現在)は利用用途として以下の制限があります。

  • ローカル ユーザー プロファイルを使用する個人用デスクトップ
  • ジャンプ ボックスとして使用されるプールされたデスクトップ ※ユーザーは VM にデータを保存することはできません
  • ユーザーが VM にデータを保存する必要がない、プールされたデスクトップまたはアプリ

docs.microsoft.com

FSLogix が Azure AD Join VM をサポートしていないのが原因で、マルチセッション環境では移動プロファイルを持てない(現状ローカルプロファイルのみ利用可能)なためですね。
ただ、2021/12/2 にプレビューで発表されていますが、対応中でそのうちGAすると思いますのでこの制限も外れると思います。

azure.microsoft.com

それほど難しくなく構成できるので、Intune 管理まで含めてやってみたいと思います。

AVD ホストプール構築

前提として Azure AD にすでにアカウント・グループがあること、Azure テナントに仮想ネットワークを作成済みであることとします。

Azure Portal から Azure Virtual Desktop を開き、ホストプールを作成します。
※ここではプール型にしています

f:id:tsukatoh:20220105145501p:plain

次に仮想マシンを紐づけます。
「参加するドメイン」の部分を以下のようにします。
参加するディレクトリを選択する:Azure Active Directory Intune に VM を登録する:はい

f:id:tsukatoh:20220105145647p:plain f:id:tsukatoh:20220105145703p:plain

この後の手順は従来と同様です。
ホストプールのデプロイが完了したら割り当てするのを忘れずに。

f:id:tsukatoh:20220105150052p:plain

Intune 側の表示

VMのデプロイが完了すると自動的に Azure AD のデバイスへ登録され、Intuneでも確認ができるようになります。
※画面はWindows 11 Enterprise Multi-session

f:id:tsukatoh:20220105150159p:plain

Multi-session だとプライマリユーザーはなしになります。

f:id:tsukatoh:20220105152613p:plain

コンプライアンスポリシーにしてもデバイス構成プロファイルにしても AVD 用で物理デバイスと分けておかないと非準拠になったりポリシーが当たらなかったりするので注意が必要です。

AVD への接続

Windows Client から接続する場合はAzure ADアカウントで登録されているデバイスからは特にそのままでも問題ありません。
それ以外のデバイスから接続する場合(macLinuxなど)、ホストプールのRDPプロパティへ以下を追加する必要があります。

targetisaadjoined:i:1

f:id:tsukatoh:20220105153030p:plain

これでmacからの接続も確認できました。
FSLogixのAAD Join対応がGAされればプロダクション環境でも使えますね。

Microsoft 365 E5 で実現する WVD セキュリティ考察

概要

前回「Office 365 E3」および「Windows 10 Enterprise E3」のライセンスの組み合わせにおいての、WVD上でMicrosoft 365 Apps for enterprise (旧称 Office 365 ProPlus) を利用する際のセキュリティ考察について書きました。
今回は Microsoft 365 (M365) ライセンスの最上位である、Microsoft 365 E5 ライセンスを利用する際のセキュリティ考察をしていきたいと思います。

※前回記事ついては以下参照ください。

tsukatoh.hatenablog.com

今回の構成については以下も含めて検討していき、ゼロトラストセキュリティを目指します。

  • Endpoint Detection and Response (EDR)
  • Cloud Access Security Broker (CASB)
  • Mobile Device Management (MDM)
  • Mobile Application Management (MAM)
  • Secure Web Gateway (SWG)

アカウント認証

M365 E5 には Azure AD Premium P2 のライセンスが包含されています。
前回の構成ではできなかった、条件付きアクセスが利用できます。
ゼロトラストセキュリティ前提で構成する場合は、場所(IPアドレス)の指定は外すか事業所が存在してる国のみに絞るといった事を検討する必要があると思います。
もちろん許可されたデバイスかどうかの判定は必須と思います。
条件付きアクセスで検討する項目は以下。

・許可されたデバイスかどうか
 →MDMで認可としているデバイスを対象にする。
 →もしくはプレビュー機能 (Filters for devices) ですがデバイスのフィルターも可能です。
 ( モデルやOSといった条件でフィルターが可能)
・許可されたアプリケーションか
 →SSO対象にしているクラウドアプリ等を対象にできます

・許可されたロケーションか
 →アクセス許可するIPアドレスレンジ
・多要素認証 (MFA) の強制

条件付きアクセスの設定等については以下記事を参照ください。

tsukatoh.hatenablog.com

WVDホストからの通信

前回の書いた3つと追加で Microsoft Cloud App Security (MCAS) を追加できます。

上3つについては前回記載しましたので、今回は M365 の CASB サービスである MCASを検討していきます。

[Microsoft Cloud App Security (MCAS)]
MCAS を導入する理由としては以下のようなものがあります。

  • シャドウITの検出・制御
  • 機密情報の保護
  • 攻撃の脅威や異常に対する保護
  • コンプライアンス

以下のようなことが対応可能になるため、是非とも導入したいですね。
・Office365 へのアクセスは許可するが、個人テナントにはアクセスさせない。
・Azure Information Protection (AIP) や Data Loss Prevention (DLP) と組み合わせた機密情報保護。
・ユーザーアクティビティによる制御や Microsoft Defender for Endpoint との連携による振る舞い検知。 ・ダッシュボードによるデータ流出の監視やアクセス制御。

Web コンテンツ フィルタリングについては Microsoft Defender for Endpoint の1機能として現在プレビュー公開されています。
こちらを使うことでWVDだけではなくIntuneに登録されているデバイスと同等の構成を組むことができます。

WVD ホストのウイルス対策

Windows Defenderを利用するのは変わりませんが、脅威検知・保護の観点で Microsoft Defender for Endpointを構成します。
ウイルス検知だけではなく、攻撃に対する監視・検知・自動対応や振る舞い検知といったことが可能になります。

Windows 10 Enterprise Multi-Session で利用する場合は以下のような対応が必要になります。

docs.microsoft.com

Device制御 (MDM / MAM)

Microsoft Intune でデバイスを管理して企業のポリシーにあった構成を組みます。
前述の条件付きアクセスへ Intune で管理されており、かつポリシーにそった構成であることを条件とすることができます。
上記により許可されていない端末やデバイス構成をとっているデバイスについては企業データへのアクセスを禁止することができます。
また、インストールするアプリケーションの制御や企業データの個人領域へのコピー&ペーストの禁止等の制御も可能です。
※この辺りの細かい記事はIntune関連の記事を参照ください。

ただ2021年6月5日現在、Windows 10 Enterprise マルチセッションには対応していないので WVD でどうしてもIntune管理下に置きたい場合はマルチセッション以外のイメージをお使いください。

docs.microsoft.com

ログ関連

Microsoft 365 関連ログ及びAzure AD ログはAzure Sentinelへ接続します。
Azure Sentinel (SIEM) を使うことでAIによるセキュリティ分析が可能になります。
Power BI と連携することで可視化することも可能です。

docs.microsoft.com

最終的な構成

f:id:tsukatoh:20210605210744p:plain

Microsoft 365 E5 では Windows 10 ライセンスや Intune、MCASなど様々なライセンスが含まれるため個別に購入することもなくゼロトラストセキュリティを実現することが可能です。
また、Azure のセキュリティサービスやSIEMを組み合わせることで分析・監視の強化も行えます。
WVD、クラウド、デバイスのトータルセキュリティとしてこのような構成を考えてみました。
一部プレビュー機能が含まれますが、Microsoft 社製品だけでトータルセキュリティが構成できると思います。
サービス間の親和性も高いのでご検討のヒントになれば幸いです。

Azure リソースのみで実現する WVD セキュリティ考察

概要

まず WVD (Windows Virtual Desktop) を利用する上ではMicrosoft 365 関連のライセンスが必要となり、保有ライセンス毎にセキュリティの実装方法やプロダクトが変わってくると思います。
本記事では「Office 365 E3」および「Windows 10 Enterprise E3」といったWVD上でMicrosoft 365 Apps for enterprise (旧称 Office 365 ProPlus) を利用する最小ライセンス構成で考えていきます。

※WVDに関するライセンスについては以下参照ください。

docs.microsoft.com

Microsoft 365 E5 を保有しているとMicrosoft Cloud App Security (MCAS)やMicrosoft Defender for Endpointを利用したりと色々と幅が広くなりますがそれはまた別の機会に。

アカウント認証

まずOffice 365 E3 ライセンスですと、Azure AD Office 365 アプリ プランになるので、条件付きアクセスなどは使えません。
最低限の認証時セキュリティとして利用するユーザーには多要素認証(Multi-Factor Authentication)を有効化します。
本プランでMFAはユーザーごとに有効化するか全てのユーザーに対して有効/無効化するかのどちらかを選択する形となります。

より高度な管理をしたい場合はAzure AD Premium P1を購入して条件付きアクセスを利用することをお勧めします。(別記事で紹介しています)

WVDホストからの通信

選択肢としては大きく3つあると思います。

  • Network Security Group (NSG)
  • Azure Firewall
  • 3rd Party Security Appliance

NSGとAzure Firewallを組み合わせて構成する形で検討していきます。

[Network Security Group (NSG)]
NSGを使うのは基本で、サブネットへ構成するようにします。
VM自体に構成しない理由としてはWVD Session Host は運用上増減する可能性があることと、VM毎に設定すると運用コストが高くなるため。
サブネットに構成することで、そのサブネット内は同一ルールで制御されます。

[Azure Firewall]
現在GAしているStandardではなくPreview公開されているPremiumを利用します。
理由としては以下機能が追加されたため。

  • Web カテゴリ フィルタリング
  • URLフィルタリング
  • IDPS (ネットワーク侵入検出と防止システム)
  • TLS インスペクション

詳細は以下を参照。

docs.microsoft.com

WVDホストからの通信という観点では、Web カテゴリ フィルタリング / URLフィルタリング を構成してWeb コンテンツフィルターを構成します。
上記により、カテゴリ+ユーザーに閲覧させたくない特定のサイトをブロックといった構成が組めます。
Web カテゴリ フィルタリングについては別記事で紹介しています。

[3rd Party Security Appliance]
個人的には別途アプライアンス費用がかかるためお勧めしないですが、企業毎にセキュリティポリシーがあると思いますので特定ベンダーの製品で構成しないとならない等があればこちらをご利用ください。

Outboundからの通信

NSGやAzure Firewallで遮断されるのはもちろんですが、侵入検知・不正アクセス検知という観点から Azure Firewall Premium を構成します。
IDPSの構成についても別記事で紹介しているので参考にしてみてください。

WVD ホストのウイルス対策

Windows Defenderを利用します。

接続元Device制御

こちらは本記事のライセンス構成ではできないため、別途MDM等の導入をご検討ください。
Intuneを含めたEMS構成については別途ご紹介する予定です。

ログ関連

Azure AD ログはAzure Monitor ログと統合することで、Azure Monitor上でアクティビティログの分析が可能になります。

docs.microsoft.com

全体最適を考えるとOffice 365 ログ及びAzure ADログはAzure Sentinelへ接続します。

docs.microsoft.com

また、SharePoint サイトの監視にはApplication Insightsが利用できます。

docs.microsoft.com

WVD自体のログもAzure Monitor ログと統合することでアクティビティログの分析が可能です。

docs.microsoft.com

最終的な構成

f:id:tsukatoh:20210505223243p:plain

色々と組み合わせることで最小ライセンスであってもセキュリティを担保して利用することは可能です。
ただ、ライセンス範囲で足りない部分をAzureのサービスで補っているので従量課金は発生します。
予算と比較して利用するしないの判断をしていくことで、よりスリムな構成にもできると思います。
ぜひお試しください。

Azure Firewall で侵入検知!IDPS (プレビュー)を試してみる

概要

前回記事でAzure Firewall PremiumのWebフィルタリング機能について触れましたが、今回はIDPSを試してみようと思います。

ちなみに前回記事はこちら

Azure Firewallの公式ドキュメントは以下にあります。

docs.microsoft.com

構築

前回記事と同様に従来のファイアウォール作成から作成していきます。
Firewall tierの部分をPremiumと指定するだけでプレビュー機能が利用できます。

f:id:tsukatoh:20210402132358p:plain

リソースが作成された後の画面上に「TLS検査(プレビュー)」と「IDPS(プレビュー)」が表示されています。(赤枠部分)
今回使うのはIDPS側になります。

f:id:tsukatoh:20210402153747p:plain

構築のチュートリアルはこちらを参照ください。

docs.microsoft.com

IDPS を使ってみる

IDPSの設定は「IDPS (プレビュー)」から作成できます。
(該当の画面にいくには Firewall Manager → 対象のPremium ファイアウォールポリシー でいけます)

f:id:tsukatoh:20210502164352p:plain

設定画面からアラートのみかアラートを出力してブロックするかを選択します。
運用上ブロックしたい場合は「アラートを出して拒否」を設定します。

f:id:tsukatoh:20210502164455p:plain

設定すると概要ページのIDPSモードが変わります。

【アラートの場合】 f:id:tsukatoh:20210502164716p:plain

【アラートを出して拒否の場合】
f:id:tsukatoh:20210502164703p:plain

また、フィルターを適用しない対象も設定できます。
IDPS設定画面の「バイパス一覧」から名前や宛先などの設定してフィルターの適用対象外とします。
f:id:tsukatoh:20210502170737p:plain

フィルター挙動について

Azure Firewall Premiumで利用できるIDPSはシグネチャベースのIDPSで、ルールセットには以下のものが提供されます。

  • マルウェア、コマンド&コントロール、エクスプロイトキット、悪意のあるアクティビティ
  • 50以上のカテゴリ、35,000を超えるルール
  • 毎日 20 〜 40 以上の新しいルールをリリース
  • 低い誤検知率

上記ルールセットはフルマネージドで提供されます。
継続的にポリシーは更新されますが、Application Gateway のWAFのようにシグネチャの個別有効/無効化は現在提供されていません。

まとめ

前回ご紹介したWeb フィルタリング機能と同様IDPSも企業でよく利用される機能と思います。
Webフィルタリング、IDPS、URLフィルタリング、TLSインスペクションといった機能が1つのサービスで提供されるので、かなり便利と思います。 ぜひお試しください。

azure.microsoft.com