Azure AD のグループ管理について
Azure AD のグループ
Azure AD の中心的な機能といえばアカウントやグループの管理ですよね。
グループは大きく分けて2つあります。
- セキュリティグループ
- Microsoft 365 グループ
また、セキュリティグループ、Microsoft 365 グループそれぞれ動的グループというものが作れて条件に合ったユーザー/デバイスを動的にグループに所属させると言う機能も提供されています。
セキュリティグループ
セキュリティグループは以下のように分類されます。
- セキュリティグループ(メールアドレスなし)
- オンプレミス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
- 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 |
AndroidやiPhoneといった指定も出来ますので、色々お試しください。
グループへの Azure AD ロールの割り当て
セキュリティ、Microsoft 365 それぞれのグループには Azure AD ロールの割り当てが可能です。
これは例えば情シス部門へ Microsoft Intune の管理権限を割り振りたいという場合に、個人個人のアカウントではなく部署グループにロール割り当てをすることで、部署異動時の管理工数の削減が可能です。
この機能はグループ作成時にのみ有効化できるため、作成時にあらかじめロール割り当てを使うか決めておく必要があります。
グループへのライセンス割り当て
Microsoft 365 / Office 365 ライセンスなどはグループに対して割り当てすることが可能です。
こちらも部署毎にE3だったりE5だったりと別れている場合は、各部署グループにあらかじめライセンス割り当てをしておくことで部署異動時に動的にライセンスをユーザーへ割り当てることができます。
まとめ
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 で利用する場合の条件付きアクセスも書いているので参考にしてみてください。
条件付きアクセスポリシー
設定できる項目は色々あります。
2022/03/03 時点では以下項目が設定可能です。
上記の条件に対して以下の制御を行うことができます。
- アクセスのブロック
- アクセス権の付与
アクセス権の付与については「すべて」もしくは「いずれか」で指定が可能です。
これを組み合わせていくことでアプリケーションへのアクセスをセキュアなものにしていきます。
実装例
前提条件として以下があるとします。
- 社内ユーザーで管理者ロールは対象外
- Office 365アプリケーション
- Intune 管理デバイス
- 場所はどこでも
- 多要素認証は必須
- デバイス種別はWindowsとiOSにしぼる
- レガシ認証は除外したい
社内ユーザーに絞る理由としてはゲスト参加しているユーザーやコラボレーションした先の外部ユーザーはアクセスさせたくないとかな要件ですね。
Intune管理デバイスに絞る理由は社給のデバイスだったりBYODでも会社として管理・許可しているデバイスを使わせるという理由になります。
場所については最近流行りのゼロトラストですね、どこからでも許可したい場合に色々と縛りをつけることでセキュリティを担保するという考え方です。
正直今回条件付きアクセスの観点で書いていますが、ゼロトラストをやる場合はMicrosoft Defender for Endpoint の導入までやった方がいいです。
Intune のデバイス管理と連携してインシデント管理やデバイス管理が可能になります。
実際の設定画面は以下となります。
認証について
条件付きアクセスを利用する場合、よく言われるのが「条件付きアクセスっていつかかるんですか?」です。
条件付きアクセスはユーザー認証時にかかるものです。
上記の例で言うと、Office 365 アプリに対象のユーザーがアクセス・認証した時に条件に合致したものをアプリへのアクセスを許可またはブロックするといった仕組みになります。
簡単に図で書くと以下のような流れになります。
補足情報ですが、シャドーIT対策で会社のテナントにはアクセスさせるけど、個人所有テナントにはアクセスさせないとかいう場合はProxy製品で対応する形となります。
まとめ
条件付きアクセスを使ったクラウドアプリケーションへのアクセス制御の一例ですが、複数ポリシーを使ってルールを作っていく形となります。
一つで作ろうとしても無理が出てきますので、アプリケーション単位だったりユーザー単位だったりで工夫して作る必要があるので試行錯誤が必要かなと思います。
次回は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グループの管理ができます
オンプレミス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 なども対象とすることが可能です。
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による一定時間内の権限付与を可能にします。
まとめ
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 にデータを保存する必要がない、プールされたデスクトップまたはアプリ
FSLogix が Azure AD Join VM をサポートしていないのが原因で、マルチセッション環境では移動プロファイルを持てない(現状ローカルプロファイルのみ利用可能)なためですね。
ただ、2021/12/2 にプレビューで発表されていますが、対応中でそのうちGAすると思いますのでこの制限も外れると思います。
それほど難しくなく構成できるので、Intune 管理まで含めてやってみたいと思います。
AVD ホストプール構築
前提として Azure AD にすでにアカウント・グループがあること、Azure テナントに仮想ネットワークを作成済みであることとします。
Azure Portal から Azure Virtual Desktop を開き、ホストプールを作成します。
※ここではプール型にしています
次に仮想マシンを紐づけます。
「参加するドメイン」の部分を以下のようにします。
参加するディレクトリを選択する:Azure Active Directory
Intune に VM を登録する:はい
この後の手順は従来と同様です。
ホストプールのデプロイが完了したら割り当てするのを忘れずに。
Intune 側の表示
VMのデプロイが完了すると自動的に Azure AD のデバイスへ登録され、Intuneでも確認ができるようになります。
※画面はWindows 11 Enterprise Multi-session
Multi-session だとプライマリユーザーはなしになります。
コンプライアンスポリシーにしてもデバイス構成プロファイルにしても AVD 用で物理デバイスと分けておかないと非準拠になったりポリシーが当たらなかったりするので注意が必要です。
AVD への接続
Windows Client から接続する場合はAzure ADアカウントで登録されているデバイスからは特にそのままでも問題ありません。
それ以外のデバイスから接続する場合(macやLinuxなど)、ホストプールのRDPプロパティへ以下を追加する必要があります。
targetisaadjoined:i:1
これで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 ライセンスを利用する際のセキュリティ考察をしていきたいと思います。
※前回記事ついては以下参照ください。
今回の構成については以下も含めて検討していき、ゼロトラストセキュリティを目指します。
- 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) の強制
条件付きアクセスの設定等については以下記事を参照ください。
WVDホストからの通信
前回の書いた3つと追加で Microsoft Cloud App Security (MCAS) を追加できます。
- Network Security Group (NSG)
- Azure Firewall
- 3rd Party Security Appliance
- 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 で利用する場合は以下のような対応が必要になります。
Device制御 (MDM / MAM)
Microsoft Intune でデバイスを管理して企業のポリシーにあった構成を組みます。
前述の条件付きアクセスへ Intune で管理されており、かつポリシーにそった構成であることを条件とすることができます。
上記により許可されていない端末やデバイス構成をとっているデバイスについては企業データへのアクセスを禁止することができます。
また、インストールするアプリケーションの制御や企業データの個人領域へのコピー&ペーストの禁止等の制御も可能です。
※この辺りの細かい記事はIntune関連の記事を参照ください。
ただ2021年6月5日現在、Windows 10 Enterprise マルチセッションには対応していないので WVD でどうしてもIntune管理下に置きたい場合はマルチセッション以外のイメージをお使いください。
ログ関連
Microsoft 365 関連ログ及びAzure AD ログはAzure Sentinelへ接続します。
Azure Sentinel (SIEM) を使うことでAIによるセキュリティ分析が可能になります。
Power BI と連携することで可視化することも可能です。
最終的な構成
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に関するライセンスについては以下参照ください。
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つあると思います。
NSGとAzure Firewallを組み合わせて構成する形で検討していきます。
[Network Security Group (NSG)]
NSGを使うのは基本で、サブネットへ構成するようにします。
VM自体に構成しない理由としてはWVD Session Host は運用上増減する可能性があることと、VM毎に設定すると運用コストが高くなるため。
サブネットに構成することで、そのサブネット内は同一ルールで制御されます。
[Azure Firewall]
現在GAしているStandardではなくPreview公開されているPremiumを利用します。
理由としては以下機能が追加されたため。
- Web カテゴリ フィルタリング
- URLフィルタリング
- IDPS (ネットワーク侵入検出と防止システム)
- TLS インスペクション
詳細は以下を参照。
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上でアクティビティログの分析が可能になります。
全体最適を考えるとOffice 365 ログ及びAzure ADログはAzure Sentinelへ接続します。
また、SharePoint サイトの監視にはApplication Insightsが利用できます。
WVD自体のログもAzure Monitor ログと統合することでアクティビティログの分析が可能です。
最終的な構成
色々と組み合わせることで最小ライセンスであってもセキュリティを担保して利用することは可能です。
ただ、ライセンス範囲で足りない部分をAzureのサービスで補っているので従量課金は発生します。
予算と比較して利用するしないの判断をしていくことで、よりスリムな構成にもできると思います。
ぜひお試しください。
Azure Firewall で侵入検知!IDPS (プレビュー)を試してみる
概要
前回記事でAzure Firewall PremiumのWebフィルタリング機能について触れましたが、今回はIDPSを試してみようと思います。
ちなみに前回記事はこちら。
Azure Firewallの公式ドキュメントは以下にあります。
構築
前回記事と同様に従来のファイアウォール作成から作成していきます。
Firewall tierの部分をPremiumと指定するだけでプレビュー機能が利用できます。
リソースが作成された後の画面上に「TLS検査(プレビュー)」と「IDPS(プレビュー)」が表示されています。(赤枠部分)
今回使うのはIDPS側になります。
構築のチュートリアルはこちらを参照ください。
IDPS を使ってみる
IDPSの設定は「IDPS (プレビュー)」から作成できます。
(該当の画面にいくには Firewall Manager → 対象のPremium ファイアウォールポリシー でいけます)
設定画面からアラートのみかアラートを出力してブロックするかを選択します。
運用上ブロックしたい場合は「アラートを出して拒否」を設定します。
設定すると概要ページのIDPSモードが変わります。
【アラートの場合】
【アラートを出して拒否の場合】
また、フィルターを適用しない対象も設定できます。
IDPS設定画面の「バイパス一覧」から名前や宛先などの設定してフィルターの適用対象外とします。
フィルター挙動について
Azure Firewall Premiumで利用できるIDPSはシグネチャベースのIDPSで、ルールセットには以下のものが提供されます。
上記ルールセットはフルマネージドで提供されます。
継続的にポリシーは更新されますが、Application Gateway のWAFのようにシグネチャの個別有効/無効化は現在提供されていません。
まとめ
前回ご紹介したWeb フィルタリング機能と同様IDPSも企業でよく利用される機能と思います。
Webフィルタリング、IDPS、URLフィルタリング、TLSインスペクションといった機能が1つのサービスで提供されるので、かなり便利と思います。
ぜひお試しください。