Azure VM の DSC Extention によるスクリプト実行でハマった話

はじめに

今回は、Azure の ARM テンプレートで DSC を使おうとしたらだいぶハマった箇所があったので備忘です。
検索しても全然情報を見つけられず、エラー内容から原因を推測することもできませんでした。。。

目次

テンプレートと DSC について

本題に入る前に、JSON テンプレートと DSC についてものすごーーく軽く紹介

ARM テンプレート

ARM テンプレートとは、デプロイしたい Azure のリソース、その設定値などを JSON 形式で書いておく設計図みたいなもの。

それをデプロイするとテンプレート通りのリソースをデプロイしてくれる。
同じ環境を繰り返し作りたいときに便利です。

ARM テンプレートの参考 Docs はこちら。

docs.microsoft.com

DSC

DSC とは PowerShell Desired State Configuration のことを指しており、一言でいえば構成管理ツールです。

ps1 ファイルに"こうあってほしい状態(設定)"を記述しておき、それを実行することで書かれている通りの状態に構成してくれます。
例えば OS の言語を変更したり、追加されたディスクにドライブレターを設定したり、などなど構成の自動化ができるものです。

DSC の参考 Docs はこちら。

docs.microsoft.com

ハマったことと解決法

やりたかったこと

今回は前述の ARM テンプレートと DSC を組み合わせて、 テンプレートのデプロイ時に Azure VM に DSC Extention をインストールし、 DSC 用 PowerShell スクリプトを実行して OS 設定を自動化させるつもりでした。

簡単なイメージは以下です
リソースグループ内に sysprep 済みのイメージと、DSC のスクリプトとモジュールを配置するためのストレージを用意しておいて、ARM テンプレートで VM デプロイ、 DSC 拡張機能でスクリプト & モジュールを持ってきて OS 設定、という流れです。
※スクリプト & モジュールは .zip 化して Blob に配置

DSC1

テンプレートの DSC Extention 部分はこんな感じ。
.zip ファイルを取ってきて展開して、setupWIndows.ps1 内の setupWIndows 関数をキックします。
そうすると DSC で機能のインストールやら OS の設定やらがいい感じに動いてくれる、はずでした。

DSC2

ハマったこと

ARM テンプレートでのリソースデプロイが進んでいき、VM のデプロイあたりでエラーが発生します。 エラーは以下の内容です。

DSC3

DSC4

Azure ポータル側とスクリプト側で貼りましたが、出ているエラーとしては、「"C:\Packages～\setupWindows.ps1" なんてコマンドはないから実行できないよ」という内容です。
RDP して確認すると示されたパスに setupWindows.ps1 が置かれておらず、要はスクリプト ファイルがないから実行できないということでした。

しかし、スクリプトは間違いなく zip に含めているので、なぜこのエラーが出るのか全く分からず、いろいろ試してみても結果は同じで困っていました。

解決方法

原因としては、スクリプトの中身ではなく "スクリプトとモジュールの zip 圧縮の仕方" でした。

まず、Blob に配置していたファイル群のフォルダ構造は以下のとおりです。

DSC5

これを圧縮するとき、最上位のフォルダ "setupWindows" を右クリックから zip 化していたのですが、これが原因でした。
この方法で zip 化し配置すると、前述のエラーが発生します。

解決方法は、"setupWindows 配下の 4 アイテムを選択して zip 化する" です。
つまりは、こういうことです。

DSC6

配置したいスクリプトとモジュールをフォルダでまとめて zip 化するのではなく、 スクリプトとモジュール個々を選択し、それを zip 化、完成した zip を "setupWindows.zip" にリネームしたものを Blob に配置します。

これで前述のエラーは発生しなくなります。

以上が解決方法です。

終わりに

これにハマっていた時は本当にわからず、他に同じようなところで詰まっている方の参考になるかと思い、備忘も兼ねて記事にしました。
(自分の探し方が悪いのでなければ)いくら調べてもこの zip 化の仕方は見つけられなかったですし、エラー内容からこれには辿りつけない。。。

ということで、前回からだいぶ空いてしまいましたが DSC でハマった話でした。 最近はなかなか書く時間を取れていないのですが、少しずつ投稿できればと思います。

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

はじめに

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

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

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

目次

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

概要

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

セキュリティデフォルトについては以下を参照

docs.microsoft.com

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

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

設定方法

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

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

MFA1

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

概要

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

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

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

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

docs.microsoft.com

設定方法

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

MFA2

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

MFA3

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

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

MFA4

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

概要

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

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

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

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

Premiumライセンスの詳細については以下を参照

azure.microsoft.com

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

設定方法

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

MFA5

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

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

MFA6

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

MFA7

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

MFA8

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

MFA9

これで設定は完了です。

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

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月に一般公開されたサービスです。

azure.microsoft.com

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

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

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

参考は以下です。

docs.microsoft.com

docs.microsoft.com

構成イメージ

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

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ディスクのスナップショットを作成します。

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

Shared Image Gallery準備

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

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

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

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

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

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

招待&権限割り当て

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

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

docs.microsoft.com

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

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

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

スクリプト準備

特殊化イメージの利用はプレビューであり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を指定してください。[プロパティ]からコピーできます。

VMデプロイ

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

スクリプト実行結果

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

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

おわりに

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

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

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

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

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

Azure BastionにNSGを設定する

はじめに

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

www.michikusayan.com

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

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

目次

BastionへのNSG設定

Azure BastionとNSG

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

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

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

docs.microsoft.com

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

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

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

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

受信ルール

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

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

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

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

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

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

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

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

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

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

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

受信ルール

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

おわりに

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

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

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

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

はじめに

今回はAzure ADの話です。

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

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

目次

MFAの強制

起きたこと

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

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

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

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

原因

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

docs.microsoft.com

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

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

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

解除方法

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

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

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

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

これで解除完了です。

おわりに

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

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

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

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

はじめに

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

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

目次

BGInfoインストール

BGInfo概要

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

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

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

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

インストール用コマンド

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

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

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

インストールおよび確認

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

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

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

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

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

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

おわりに

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

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

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

www.michikusayan.com

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

はじめに

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

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

www.michikusayan.com

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

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

2022/10 追記 : 本記事のポリシーよりももっと柔軟に制御するポリシーを作りました。そっちは以下の記事を参照ください。

www.michikusayan.com

目次

Azureポリシー

概要

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

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

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

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

markgossa.com

ポリシーの内容

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

{
  "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ルールを禁止するポリシーとして機能します。

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

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

docs.microsoft.com

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

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

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

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

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

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

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

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

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

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

www.michikusayan.com

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

テスト

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

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

すると。。。

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

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

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

ポリシー準拠状況の確認

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

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

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

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

料金

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

azure.microsoft.com

気になること

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

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

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

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

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

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

このオプションを使ってデプロイすることは防げなさそうなので、自動で修復するようにポリシー側を整備しておくしかないのかなと思います。

おわりに

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

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

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

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

はじめに

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

目次

許可すべきURL

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

docs.microsoft.com

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

ちょっと心配なこと

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

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

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

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

おわりに

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

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