みち草

Azure中心にまとめる技術情報ブログ

Azure ADユーザーに多要素認証(MFA)を適用する方法

はじめに

今回は、Azure ADユーザーに多要素認証(MFA)を適用する方法を紹介します。

クラウドでは、ベンダーにより基盤側のセキュリティ対策はされているものの、
ユーザー権限を悪用されてしまっては意味がありません。

ユーザーのセキュリティを強化するMFAですが、費用や範囲の違いなどがあるため、目的に合わせて選びましょう。
比較だけ知りたい方は「まとめ」へどうぞ。

目次

セキュリティデフォルトを利用する

概要

1つ目は、セキュリティデフォルト設定を利用する方法です。
これは2019年10月頃にAzure ADに追加された設定値であり、MFAやレガシ認証のブロックが可能です。

セキュリティデフォルトについては以下を参照
Azure Active Directory のセキュリティ デフォルト | Microsoft Docs

この設定を用いることで、Azure AD内のすべてのユーザーに、無償でMFAを強制することができます。
Azure ADのメンバーやゲスト、ユーザー数に依らず無償で利用できますが、特定のユーザーのみ、 ということはできず必ず全ユーザーに適用されてしまいます。

お手軽に全体をセキュリティ強化したい、という場合に有効です。

設定方法

ポータルでAzure Active Directoryを開き、[プロパティ]の一番下にある[セキュリティの既定値の管理]をクリック、 [セキュリティ既定値の有効化]を[はい]にすることで、次回ログイン時にMFAの設定が求められます。
※2019年10月以降に作成されたAzure ADでは、最初から有効の可能性があります。

認証方法については指定できず、電話番号へのテキストメッセージか、Authenticatorなどの認証アプリしか利用できません。

MFA1
MFA1

Azure AD管理者のMFAを利用する

概要

2つ目は、Azure ADの管理者に対してMFAを有効にする方法です。

通常、個々のユーザーにMFAを適用するには後述のライセンスが必要になりますが、 対象ユーザーがAzure ADの「グローバル管理者」であれば、ライセンス不要でMFAを利用することができます。

グローバル管理者はAzure ADの最高権限であるため、全ユーザーにMFAはやりたくないが、 管理者だけでも...という場合に有効です。

現在では、後述のPremiumライセンスを用いた方法を推奨しているようです。

ユーザーごとの多要素認証 - Azure Active Directory | Microsoft Docs

設定方法

ポータルでAzure Active Directoryを開き、[ユーザー]を開きます。
右上の[...]をクリックし、表示されるメニューの[Multi-Factor Authentication]をクリックします。

MFA2
MFA2

MFAを適用したいグローバル管理者ユーザーにチェックを入れ、右の[有効]をクリックすればOKです。
次回ログイン時にMFAの設定を求められます。

MFA3
MFA3

認証方法は、上部の[サービス設定]をクリックした先で指定することができます。
[検証オプション]から、ユーザーに使用させたい認証方法にチェックを入れ、下部の[保存]をクリックします。

電話の着信を用いるオプションを利用するには、Premiumライセンスの購入が必要です。

MFA4
MFA4

Premiumライセンス(条件付きアクセス)を利用する

概要

3つ目は、Azure AD Premium条件付きアクセスを利用する方法です。

対象ユーザーアカウント毎にAzure AD Premiumライセンス(P1またはP2)を購入し、条件付きアクセスを設定します。

ライセンスが必要ですが、電話認証もできる、ユーザーでもグループでも指定できる、 特定のユーザーや認証時のIPアドレスを指定して該当する場合にMFAを適用するなど、最も自由な設定ができます。

加えて、Premiumライセンスに付随する他の機能も利用可能です。
例:Azure ADのサインインログ取得、禁止パスワードの設定、セルフパスワードリセット、動的グループなど

Premiumライセンスの詳細については以下を参照
料金 - Active Directory | Microsoft Azure

これまで紹介した方法で要件を満たせない場合や、MFA+αの機能を利用したい場合に有効です。

設定方法

ポータルでAzure Active Directoryを開き、[セキュリティ]-[条件付きアクセス]上部の[新しいポリシー]をクリックします。

MFA5
MFA5

要件に合わせてポリシーを設定します。
以下では、特定のユーザーに対して、Azureポータルへログインする際はアクセス場所に依らずMFAを要求するポリシーを作成しています。

ポリシーに名前をつけ、[ユーザーとグループ]欄にて対象のユーザーを指定します。
グループを指定することや、対象外のユーザーを指定することもできます。

MFA6
MFA6

[クラウドアプリまたは操作]にて、Azureポータルへのログインを示す[Microsoft Azure Management]を選択します。

MFA7
MFA7

[条件]にて、場所を[すべての場所]に指定します。
[条件]の設定を利用することで、オフィス以外の場所(グローバルIP)からのログイン時はMFAを要求することや、WindowsまたはMacOSの場合にMFAを要求する、などが可能です。

MFA8
MFA8

最後に、[アクセス許可]にて[多要素認証を要求する]にチェックを入れます。
[ポリシーの有効化]をオンにしてポリシー作成するのを忘れないようにしましょう。

MFA9
MFA9

これで設定は完了です。

認証方法を指定する場合は、「Azure AD管理者のMFAを利用する」と同様に[検証オプション]のチェックボックスを変更します。

MFA10
MFA10

まとめ

3つの方法を紹介しましたが、まとめると以下のようになります。
お手軽なセキュリティデフォルト、重要ユーザーだけでも守る管理者のMFA、フル機能のPremiumライセンス、というところでしょうか。

PremiumについてはO365系の一部ライセンスで利用することも可能と思いますが、自身が詳細を把握できていないため、Azure観点からP1/またはP2として記載しています。

セキュリティデフォルト Azure AD管理者のMFA 条件付きアクセス
対象ユーザー Azure AD全体 個別ユーザー指定
※Azure ADグローバル管理者のみ
ユーザー、グループなど任意に指定
認証方法 ・電話へのテキストメッセージ
・認証アプリの通知
・電話へのテキストメッセージ
・認証アプリの通知
・認証アプリの確認コード
・電話認証
・電話へのテキストメッセージ
・認証アプリの通知
・認証アプリの確認コード
追加ライセンス(費用) 不要 不要 ユーザー毎にAzure AD PremiumライセンスP1またはP2が必要
アクセス場所(IP)による制御 不可 不可 可能
その他 レガシ認証のブロックも可能 費用なく管理者にMFAを適用可能 Premiumライセンスに付随する他の機能も利用可能
・Azure ADのサインインログ
・禁止パスワードの設定
・セルフパスワードリセット
・動的グループ など

終わりに

今回はAzure ADユーザーにMFAを適用する方法を紹介しましたが、無償でMFAができるからセキュリティデフォルトがいい!など特定のどれかを推したいということではありません。

「MFA」のみの費用面で見ればセキュリティデフォルトや管理者用MFAがよく見え、Premiumライセンスは高く感じてしまうと思いますが、 Premiumライセンスにはその他にもいくつか機能がありますし、条件付きアクセスもMFA以外にAzureポータルへログインできる場所の制御などに使用することができます。

それぞれの違いを理解し適したものを選んでもらえればと思うので、本記事が検討材料として足しになれば幸いです。

Shared Image Galleryで異なるAzure ADテナントのイメージからVMをデプロイする

はじめに

今回はAzureのShared Image Galleryを利用して、あるAzure ADテナントで作成・登録したイメージ(スナップショット)を使って、別のAzure ADテナントにVMをデプロイしてみたので、方法を紹介します。

目次

Shared Image Gallery概要

Shared Image Galleryは、2019年5月に一般公開されたサービスです。
https://azure.microsoft.com/ja-jp/updates/shared-image-gallery-generally-available/

共通の設定を導入したイメージを作成および登録することで、別サブスクリプションや、別のAzure ADテナント内のユーザーがそのイメージを利用してVMをデプロイできます。
加えて、イメージ更新時のバージョン管理までできちゃいます。

一般化された(sysprep済み)イメージ、特殊化された(sysprepなし)イメージのどちらにも対応していますが、投稿時点(2019年12月)では、特殊化されたイメージはプレビュー機能です。

今回はプレビューである、特殊化されたイメージ(OSディスクのスナップショット)を別テナントでデプロイします。
プレビューの制限として、特殊化されたイメージのデプロイはPowerShellかCLIのみ可能(ポータル不可)のため、PowerShellスクリプトでデプロイします。

参考は以下です。

Azure Shared Image Gallery | Microsoft Docs

Azure のテナント間でギャラリー イメージを共有する | Microsoft Docs

構成イメージ

イメージは以下です。
以降では、ギャラリー側をテナント1(サブスクリプション1)、デプロイ側をテナント2(サブスクリプション2)として表記します。

ギャラリー1

  1. サブスクリプション1で、OSディスクのスナップショットを作成します
  2. サブスクリプション1で、イメージ(スナップショット)をShared Image Galleryに登録します。
    ※正確にはShared Image Gallery内にイメージ定義を作成、イメージバージョンとして登録ですが、図中では省略します。
  3. テナント2のユーザーをテナント1に招待します。
  4. 招待したユーザーに対して、ギャラリーの読み取り権限を付与します。
  5. スクリプトを用いて、サブスクリプション1のイメージを基に、サブスクリプション2にVMをデプロイします。

sysprep無しのイメージなので、VMがテナントを移動したような動きになります。早速やっていきます。

環境構築

VMイメージ(スナップショット)作成

MSドキュメント内の言葉を借りて「特殊化されたイメージ」記載していますが、つまりはOSディスクのスナップショットを指しています。

VMを停止して、OSディスクのスナップショットを作成します。

ギャラリー2

データディスクを利用している場合は、併せてスナップショットを取得しておきます。

Shared Image Gallery準備

取得したスナップショットを登録するため、Shared Image Gallery(共有イメージギャラリー)を作成します。

ギャラリー3

ギャラリーを作成したら、そこに「イメージ定義」を追加します。

ギャラリー4

項目やタブがたくさんありますが、単に使うだけなら[基本]タブだけ埋めればOKです。
今回は特殊化されたイメージのため[特殊化]を指定します。

ギャラリー5

最後に、「バージョンの追加」を行います。

ギャラリー6

ここで、[OSディスクのスナップショット]として最初に作成したスナップショットを選択します。
データディスクがある場合には、LUNと併せて[データディスクのスナップショット]に指定します。

ギャラリー7

10分ほど待ちイメージバージョンが作成されたら、Shared Image Galleryの準備は完了です。

ギャラリー8

招待&権限割り当て

イメージを使わせたい別テナントのユーザーに対して、作成したギャラリーの読み取り権限(閲覧者ロール)を付与します。

別テナントのユーザーに権限を付与するには、以下を参考に対象ユーザーを招待しておきます。

クイック スタート:Azure portal でゲスト ユーザーを追加する - Azure AD | Microsoft Docs

招待後、ギャラリーの[アクセス制御]-[追加]-[ロールの割り当ての追加]を開きます。

ギャラリー9

[役割]は[閲覧者]を指定し、[選択]に外部テナントのユーザー名を入力します。

ギャラリー10

表示されたユーザーをクリックし保存します。
[ロールの割り当て]タブを見たときに、閲覧者として追加されていれば準備はOKです。

ギャラリー11

スクリプト準備

特殊化イメージの利用はプレビューでありPowerShellまたはCLIでのデプロイのみのため、以下のPowerShellスクリプトを用意しました。

$Subscription = "サブスクリプションID"
$ResourceGroup = "リソースグループ名"
$Location = "リージョン名"
$VNetName = "VNet名"
$VmName = "VM名"
$NicName = $VmName + "-NIC"
$GIpName = $VmName + "-IP"
$Image = "イメージバージョンのリソースID"

#サブスクリプションにログイン
Connect-AzAccount
Select-AzSubscription -Subscription $Subscription

# パブリックIP作成
$GIp = New-AzPublicIpAddress -ResourceGroupName $ResourceGroup -AllocationMethod Dynamic -Location $Location -Name $GIpName

# VNet取得
$VNet = Get-AzVirtualNetwork -ResourceGroupName $ResourceGroup -Name $VNetName

# 指定サブネットのNIC作成
$Nic = New-AzNetworkInterface -Name $NicName -ResourceGroupName $ResourceGroup -Location $Location `
  -SubnetId $VNet.Subnets[0].Id -PublicIpAddressId $GIP.Id

# ギャラリーイメージを基にVMデプロイ用Config作成
$VmConfig = New-AzVMConfig -VMName $VmName -VMSize Standard_A1_v2 | `
  Set-AzVMSourceImage -Id $Image | `
  Add-AzVMNetworkInterface -Id $Nic.Id

# VMデプロイ
New-AzVM -ResourceGroupName $ResourceGroup -Location $Location -VM $VmConfig -DisableBginfoExtension

スクリプトは以下のことを行います。

  1. 指定サブスクリプションにログイン
  2. パブリックIP作成
  3. 指定VNetの先頭サブネットに接続するネットワークインターフェース作成
  4. 別テナントのギャラリーイメージを基に、VMデプロイ用のConfig作成(サイズはA1v2)
  5. Configを基にVMデプロイ

上部の変数に任意の値を指定すればOKですが、$Imageはサブスクリプション1側で取得する値、それ以外はサブスクリプション2側の値になります。

また、$Imageには「イメージバージョンの」リソースIDを指定してください。[プロパティ]からコピーできます。

ギャラリー12

VMデプロイ

準備ができたらスクリプトを実行し、ギャラリーの読み取り権限を付与したユーザーでログインすれば、テナント1のイメージを利用したVMがデプロイされます。

スクリプト実行結果

ギャラリー13

デプロイされたVMは、ソースが「共有イメージ」になります。

ギャラリー14

以上で、Shared Image Galleryを用いて、異なるAzure ADテナントのイメージからVMをデプロイすることができました。

おわりに

一般リリースされれば特殊化イメージでもポータルでデプロイ可能になるとは思いますが、VMをテナント間移動させる方法の1つとして試したため、せっかくならと記事にしました。

Azureでテナントを超えるってなかなか面倒なのですが、そもそも共有する用のサービスなのでやりやすかったです。

ギャラリーを使えば別サブスクリプションへのカスタムイメージの持ち込みも可能であるため、日本語化&社内で定められた設定実施済みのテンプレートを様々なサブスクリプションで利用することなんかもでき、いろいろ使い道のあるサービスではないかと思います。

ユーザーにあまり権限をつけたくない、という方でも安心な読み取り権限だけOKなのもよいです。

気が向いたら一般化イメージでも試してみたいと思います。

Azure BastionにNSGを設定する

はじめに

以前、別記事でBastionについて記載しましたが、その際はサブネット上のBastion自体にNSGを設定していませんでした。

踏み台サーバがPaaS化!Azure Bastionを試す! - みち草

最近になって試してみたところ、BastionのNSGはシステム用のルールを許可する必要があるため、自分のグローバルIPアドレスを許可するだけでは足りませんでした。

本記事では、BastionにNSGを設定する際の必須ルールを紹介します。

目次

BastionへのNSG設定

Azure BastionとNSG

Bastionは仮想ネットワーク内に専用サブネット(AzureBastionSubnet)を作成してデプロイするため、そのサブネットにNSGを適用することでBastionへアクセス可能なIPアドレスを制御でき、より安全な接続が可能です。

ただし、マネージドなPaaSサービスであるため、動作させるために必ず許可しなければならない通信があります。

それについて、以下の公式ドキュメントに記載があります。
(セッション監視については「セッションの監視と管理」ページに記載あり)

Azure Bastion で VM と NSG を使用する | Microsoft Docs

これを満たさないNSGをAzureBastionSubnetに割り当てようとすると、画像のように「Bastionに必要なルールが足らん」とエラーが出てしまいます。

BastionNSG1

ではどんなルールが必要なのか、次にまとめます。

Bastion用NSGの必須ルールと適用

NSGをデフォルトの状態で使う場合は送信が全許可されていますが、その場合でも次の受信2つ、送信2つで合計4つのルールが絶対に必要です。

受信ルール

(1) Bastion制御用の通信許可ルール
 "GatewayManager"タグからの、ポート"443"通信を許可します。

(2) セッション監視機能用の通信許可ルール
 "GatewayManager"タグからの、ポート"4443"通信を許可します。

これらは同じ発信元からの許可ルールなので、以下のように1ルールにまとめてもOKです。

BastionNSG2

送信ルール(デフォルトNSGでも必要!)

(1) Bastion機能用の通信許可ルール
 "AzureCloud"タグへの、ポート"443"通信を許可します。
 ※記事作成時点ではリージョン付タグ(AzureCloud.xxx)は非サポート

BastionNSG3

(2) 仮想ネットワークへの通信許可ルール
 "VirtualNetwork"への、ポート"3389/22"通信を許可します。

BastionNSG4

これら4つ(まとめると3ルール)を許可することで、ようやくAzureBastionSubnetにNSGを割り当てることが可能です。

BastionNSG5

BastionNSG6

これでAzure BastionにNSGを設定することができました。
あとは自宅のIPでも会社のIPでも、好きなものを許可しましょう。

ちなみに、利用者のグローバルIPに対しては443の通信を許可してくださいね。

接続先VM用NSGにて必要なルール

おまけとして、VM側のNSGで場合により必要なルールは以下です。
デフォルトのNSGであれば追加不要ですが、必要最低限のみ許可などポリシーが厳しい場合には必要になるでしょう。

受信ルール

(1) AzureBastionSubnetからの受信ルール
 "AzureBastionSubnetのIPアドレスレンジ"からの、ポート"3389/22"通信を許可します。

BastionNSG7

おわりに

今回は、Azure Bastionにて、許可が必須なNSGルールを紹介しました。

サービスの使用に必要な通信でも、明示的な許可が必要なものと不要なもの(内部で許可される)がありなかなかややこしいです。
それについてもそのうちまとめたいと思います。

その点Bastionは適さないNSG割り当てを拒否してくれるので、まだ親切ですね。

新規Azure ADを作成したらMFAを強制された

はじめに

今回はAzure ADの話です。

先日、Azure ADを新規で作成する機会がありましたが、その際にMFA(多要素認証)を強制されました。

備忘も兼ねて原因と解除方法を紹介します。

目次

MFAの強制

起きたこと

先日、検証環境を用意するため、クレジットカードを用いてサブスクリプションを作成しました。

MFA1

その後、新規にAzure ADを作成し、既定のディレクトリから新規Azure ADへディレクトリ変更を行いました。

MFA2

新規Azure ADには社用組織アカウントを招待しており、それでログインしサブスクリプションを使おうとしたところ、MFAの設定画面が表示されました。
社用アカウントは元々MFA必須のため、このときはそれが原因かと思い特に気にしていませんでした。

MFA3

その後、検証用に新規に作成した組織アカウントすべてでも同様にMFA設定を求められ、さすがに何かしらの力が働いている...と思い調べたところ今回の設定に至りました。

MFA4

原因

原因はこれ、Azure ADのセキュリティデフォルトでした。

Azure Active Directory security defaults | Microsoft Docs

以下は上記サイトの抜粋です。

Microsoft では、誰もがセキュリティ既定値を利用できるようにしています。 目標は、すべての組織が追加の費用なしで基本レベルのセキュリティを確実に有効にできるようにすることです。 セキュリティ既定値は、Azure portal で有効にします。
---中略---
テナント内のすべてのユーザーは、Azure Multi-Factor Authentication サービスのフォームを使用して多要素認証 (MFA) に登録する必要があります。

ということで、近頃のAzure ADはセキュリティ強化のための設定が既定で有効化されており、それによりMFAがテナント内の全ユーザーに強制されます。

解除方法

今回のような単なる検証用途では都度対応するのが面倒である、そんな方のための解除方法を記します。

Azureポータルにて、[Azure Active Directory]の[プロパティ]を開きます。
一番下にある青文字の[セキュリティ既定値の管理]をクリックします。
セキュリティ既定値の設定が面が開くので[いいえ]を選びます。

MFA5

理由を問われるため任意に指定し[保存]をクリックします。

MFA6

通知が表示されれば変更完了です。

MFA7

これで解除完了です。

おわりに

様々な脅威にあふれる昨今、追加の料金なく、すべてのユーザーに対してMFAを設定しセキュリティを強化できるのは結構すごいことではないでしょうか。

今回は検証環境のため無効としましたが、実環境の場合には、有効としたままの利用も考慮する価値がある設定だと感じます。

ただ、私はこの設定の存在を知らずにいきなりMFAを求められ驚いたので、まずは同じような方に要否関係なく知ってもらえればいいなと思います。

Azure VM(ARM)にBGInfo拡張機能をインストールする

はじめに

今回は、Azure VMにBGInfo拡張機能をインストールする方法を紹介します。

クラシック(ASM)VMではデプロイ時の他の拡張機能と同様に選択してインストール可能でしたが、 ARMでは拡張機能画面に表示されないため、インストール方法を紹介します。

目次

BGInfoインストール

BGInfo概要

BGInfoとは、デスクトップにホスト名やメモリサイズ、IPアドレスなどを表示させることが可能なツールです。

これをインストールすることで、多数のマシンにログインしている場合や多重RDP接続をしている場合に、 常に背景にシステム情報が表示されるため、どのマシンを操作しているかわかりやすくなります。

Azure VMでもクラシックの頃から利用でき、デプロイ時にチェックを入れるだけでインストールすることが可能でした。

ARMでは、以下の「拡張機能」画面にBGInfoが表示されませんが、後述するPowerShellコマンドを利用することでインストールが可能です。

BGInfo1

インストール用コマンド

ARM VMにBGInfoをインストールするには、以下のコマンドを実行します。

Set-AzVMBgInfoExtension -ResourceGroupName "<リソースグループ名>" -VMName "<VM名>" -Name "BGInfoExtension"

Nameパラメータは、ポータルの「拡張機能」画面で表示される名前なので、任意の名前でOKです。 リソースグループ、VMを正しく指定しましょう。

インストールおよび確認

Windows Server2016のVMにインストールしてみます。 VMが起動状態でなければ、拡張機能をインストールできないため起動しておきます。

BGInfo2

PowerShellでサブスクリプションにログインし、先ほどのコマンドを実行します。

BGInfo3

30秒ほど待ち、以下の結果となればインストール完了です。

BGInfo4

VMの拡張機能画面では、状態が"Provisioning succeeded"となればOKです。 コマンド中に指定した名前で表示されています。

BGInfo5

仮想マシンにログインすると、デスクトップの右上にシステム情報が表示されています。

BGInfo6

これで、ARM VMへのBGInfo拡張機能のインストールは完了です。

おわりに

ARMでGUIに表示されなくなった理由はわかりませんが、PowerShellでインストール可能なので、必要な方は試してみてください。

個人的にはPaaSの踏み台、Bastionでログインすれば多重RDPにならないので不要か?とは思いつつ、 あったらあったで安心なのかなぁとも思うので微妙なところ。。。

Bastionについては別記事で記載しているため、良ければ見てみてください。

踏み台サーバがPaaS化!Azure Bastionを試す! - みち草

AzureポリシーでNSGの設定値を制限する

はじめに

今回は、Azureポリシーを用いてリソースの設定値を制限する方法の紹介です。

以前、AutomationにPowerShellスクリプトを登録して特定のNSGルールを検出し、SendGridでメール通知する、という記事を投稿しました。

Azure AutomationとSendGridで発信元AnyのNSGルールを検出してメール通知してみた - みち草

これだと結局メールを確認する必要があり面倒で、NSGの作成/変更を検出して何とかしたいなぁと調べたところ、 Azureポリシーで特定の設定値を禁止できそうだったため試してみました。

「ソースIPアドレスがAnyのNSGルールは作成不可」というルールを設定します。

目次

Azureポリシー

概要

Azureポリシーは、リソースに対して名前や設定値のルールを与えることができるサービスです。 例として、[ストレージアカウントのSKUはLRSのみとする]、[東日本リージョンのみデプロイ可能]、[タグとして○○を必須とする]などが指定可能であり、それに違反するリソースをデプロイできないよう制御できます。

ポリシーは適用先としてサブスクリプションかリソースグループを選ぶことが可能なため、全体としての制御や、特定のリソースグループ内のみの制御など用途に合わせて利用します。

組み込みで用意されているルールもありますが、今回は該当するものがないため、JSONを記述して作成しています。

以下のサイトを参考にしました。

Technical Deep Dive: Azure Policy - Deny inbound RDP from the internet

ポリシーの内容

今回使用するポリシーはこれです。

{
  "mode": "All",
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Network/networkSecurityGroups/securityRules"
          },
          {
            "field": "Microsoft.Network/networkSecurityGroups/securityRules/access",
            "equals": "Allow"
          },
          {
            "field": "Microsoft.Network/networkSecurityGroups/securityRules/direction",
            "equals": "Inbound"
          },
          {
            "field": "Microsoft.Network/networkSecurityGroups/securityRules/sourceAddressPrefix",
             "in": [
                  "*",
                  "Internet"
              ]
          }
        ]
      },
      "then": {
        "effect": "deny"
      }
    },
  "parameters": {
  }
}

policyRuleブロック内に、JSONで条件を記述します。 allOfがand、anyOfがorとしてブロック構造で条件分岐を記述するので、なかなか書きづらいです。

条件と処理部分を日本語で書くと、「"リソースの種類がNSGのルール" かつ "アクセスを許可するルール" かつ "受信ルール" かつ "ソースアドレスが *(Any) または Internetタグ"ならば、拒否する」です。

これで不特定なIPアドレスからの接続を許可するNSGルールを禁止するポリシーとして機能します。

パラメータとして指定したポート番号を使用するルールは拒否、など も可能ですが、ここでは利用していません。

公式ドキュメントにサンプルが紹介されています。

ポリシーのサンプルのインデックス - Azure Policy | Microsoft Docs

ポリシーの定義、割り当て

実際にポリシーを作成し適用します。まずは、適用するポリシー(ルール)を定義します。

ポリシー1

[定義の場所]ではサブスクリプションを指定します。 その他は任意に指定します。

ポリシー2

ポリシー定義に先ほどのJSONを貼り付け、保存します。

ポリシー3

[種類]を"カスタム"に変更すると自作ポリシーのみ表示されるため、先ほど作成したポリシーの名前をクリックします。

ポリシー4

[割り当て]をクリックします。

ポリシー5

[スコープ]や[除外]の欄を用いることで、サブスクリプションの中の特定のリソースグループまたはリソースにのみ ポリシーを適用することや、一部のリソースグループやリソースを適用対象外とすることが可能です。

今回はサブスクリプション全体に適用するのでこのままです。 パラメータがあるポリシーを定義した場合は、パラメータタブにて指定することができます。

ポリシー6

修復タブでは、ポリシー用のマネージドIDの作成を指定できます。 ポリシーの作成の仕方によっては、ルールに合致した際に自動設定や自動修正が可能であり、それ用のIDです。 これはそのうち試してみたいですが、今回はそのままにして割り当てを実行。

ポリシー7

サービスIDについては以前にちょこっと書いたのでそれ参照。

AzureサービスにIDを与える!マネージドID - みち草

これでポリシーの定義と割り当ては完了です。

テスト

早速、適用したポリシーの動作をテストします。

送信元がAnyのNSGルールを追加してみます。

ポリシー8

すると。。。

ルールの作成時にエラーが表示され、「ポリシーにより許可されませんでした」とあります。

Azureポリシーを用いて、ルールに合致した設定値を拒否することができました。

ポリシー9

もちろん、ソースIPアドレスを指定したルールであれば作成可能です。

ポリシー準拠状況の確認

概要からポリシー名をクリックすると、そのポリシーの適用範囲に存在するリソースについて、 ポリシーの準拠状況や、準拠していないリソース、拒否されたイベント発生数などを確認することができます。

※割り当て後、状況取得にはある程度時間がかかります。

ポリシー10

以下は別のポリシーのキャプチャですが、時間が経つとポリシーの準拠していないリソースがどのくらいあるのか表示してくれます。

ポリシー11

イベントを発生させたユーザーもわかるので、誰が設定を行おうとしたか、ばっちりわかります。

ポリシー12

料金

Azureポリシーの利用料金は発生しないため、好きなだけ使えます。

価格 - Azure Policy | Microsoft Azure

気になること

ルールに合致した設定を拒否できるAzureポリシーですが、ちょっと気になる箇所があります。

それは、ユーザーが自分で設定した際は拒否してくれるのですが、システム的に設定される場合は拒否されない、という点です。

例として試したのは、VM作成時の以下の設定です。

ポリシー13

このチェック用いると、VMデプロイ時のインターフェースに割り当てられるNSGに対して自動でルールを追加してくれます。 ただし、ソースIPアドレスががAnyなのです。

今回のポリシーを適用していても、拒否されずにデプロイされてしまいます。

まぁ、以前は警告なくAny許可でしたが、最近は「すべてのIPアドレスからアクセス可能になります」と注意を明記してくれるだけマシになりました。 システム的に防ぎたいところですがダメそうです。。。

おわりに

今回は、Azureポリシーでリソースの設定値を制限する、ということを紹介しました。

組み込みのポリシーで済むようであればそれだけで、費用なく設定が可能です。 もし求めるものがない場合は作成するしかありませんが、記事中で紹介したサンプルページもあるため、それを参考にするのが良いかと思います。

環境全てをポリシーで制御しようと思うとひたすらJSON記述になり大変ですが、これは絶対使わせない!という設定を制御するにはよいかと思います。

プロキシやファイアウォールでAzureポータルのURLを許可する

はじめに

いつの間にか、Azureポータルを使うためにプロキシやFWで許可が必要なFQDNが公式に出ていたため、その紹介です。

目次

許可すべきURL

Azureポータルを利用するために許可が必要なFQDNはこれらです。

以下に対して、80/443ポートでの通信が必要です。

*.aadcdn.microsoftonline-p.com
*.aka.ms
*.applicationinsights.io
*.azure.com
*.azure.net
*.azureafd.net
*.azure-api.net
*.azuredatalakestore.net
*.azureedge.net
*.loganalytics.io
*.microsoft.com
*.microsoftonline.com
*.microsoftonline-p.com
*.msauth.net
*.msftauth.net
*.trafficmanager.net
*.visualstudio.com
*.windows.net
*.windows-int.net

上記は一般用であり、Governmentリージョン、中国リージョンではそれぞれ許可が必要なFQDNが異なるようです。詳細は以下のサイトを参照ください。

Azure portal の URL をセーフリストに追加する | Microsoft Docs

これで、アクセスを制限している環境でもAzureポータルが使えそうですね。

ちょっと心配なこと

数年前、AzureのIaaS環境を構築した際、「社内からインターネットへ出る際はプロキシで制限をかけている。Azureを使用するために許可が必要なURL、FQDNを教えてほしい。」と言われたことがあります。 その頃は上記の公式情報がなくサポートに聞いて、それをお客さんに設定してもらい構築作業に臨みました。

すると、ポータル自体は表示されており問題ないように見えるのですが、当時は選択制だった[ストレージの暗号化を有効にする]をクリックすると、 実は別のURLに飛ぶようで、そこが許可されておらずエラーが出て有効化できない、という問題で手間取ったことがあります。

という具合に、ポータル内の操作によって別のURLが必要なことが多々あるようで、同じようなことにならないといいなーという心配があります。

足りないものがあれば今後更新されていくとは思いますし、そもそも公式なので信じるしかないですが...(-"-)

おわりに

昔引っかかったことを思い出しましたが、その頃から考えると、公式にまとめて頂けるのは大変ありがたいです。

新しいサービスが出た際にはFQDNも追加される可能性があるため、利用の際は適度にチェックした方がよさそうです。

Azureポータルを前のメニューに戻す

はじめに

これまで結構キッチリ書いてましたが、今回は軽めの投稿です。

先日、Azureポータルの表示方法やアイコンが変わったので、以前の表示方法への戻し方紹介です。

目次

新しいポータル

以前は左端のメニューが常時表示されていましたが、左上の3本線をクリックすることで表示されるように変更されました。 ハンバーガーメニューと言うらしいです。

ポータルの表示変更1

ポータルの表示変更2

メニューにマウスカーソルを乗せておくと、最近使用したリソースなどが表示されます。

ポータルの表示変更3

以前の表示に戻す

以前のような常時表示に戻すには、左上の歯車マークをクリックし、ポータルの設定を開きます。

「Chose your default mode for the portal monu」を[ポップアップ]から[ドッキング]に変更します。

ポータルの表示変更4

これで、以前のように左端のメニューが表示されます。 [>>]をクリックすれば広がります。

ポータルの表示変更5

ポータルの表示変更6

おわりに

今回は小ネタ的にポータルの表示変更について記載しました。

戻すと言っても常時最小化されてしまうため完全に同じとはいきませんが、その辺りの変更は受け入れていくしかありませんね。

かく言う自分も手順書を作成しており焦りましたが、キャプチャ取得の直前に変更されたので助かりました...。

キッチリ書くことに拘り過ぎると続かなくなってしまいそうなので、今後はこのようなちょっとしたことも投稿したいなと思います。続けるの大事。