normalian blog

Let's talk about Microsoft Azure, ASP.NET and Java!

Azure Virtual WAN の RouteTable をまっさらにする方法

最近ちょっと Azure Virtual WAN を使って遊んでたんですが、アレコレいじった後にリソースを削除しようとしたときに「Azure Virtual WAN 側の Route Table が Azure Firewall を参照しているので削除できず、Azure Firewall 側は参照されているので削除できない」という問題にぶつかりました。
Azure ポータル上で誤った設定かつ不要な Route Table を削除しようとしたのですが、Route Table を空にする処理はポータル上ではできないようなので PowerShell コマンドを利用しましたが、自分自身が忘れそうなので今回は自分用の備忘録です。

まず、Virutal WAN の書く Hub には Route Tables がありますが、こちらは以下のスクリーンショットを見て頂ければ分かる通り Default と None が存在します。

更に上記のスクリーンショット右側は見て頂ければ分かると思いますが、ポータル上に表示させる名前とコマンド上で扱う名前は別になっています(ポータル上だと Default だが、コマンドだと defaultRouteTable 等)。Viritual WAN の特定の Hub 上での Route Table を取得するコマンドは以下となります。

PS /home/daichi> Get-AzVHubRouteTable  -HubName "your subscription id" -ResourceGroupName "your rg name"                   

Name                   : defaultRouteTable
Id                     : /subscriptions/"your subscription id"/resourceGroups/"your rg name"/providers/Microsoft.Network/virtualHubs/"your hub name"/hubRouteTables/defaultRouteTable
ProvisioningState      : Succeeded
Labels                 : {default}
Routes                 : []
AssociatedConnections  : []
PropagatingConnections : []

Name                   : noneRouteTable
Id                     : /subscriptions/"your subscription id"/resourceGroups/"your rg name"/providers/Microsoft.Network/virtualHubs/"your hub name"/hubRouteTables/noneRoute
                         Table
ProvisioningState      : Succeeded
Labels                 : {none}
Routes                 : []
AssociatedConnections  : []
PropagatingConnections : []

上記は既に値がまっさらになった状態の Route Table ですが、ここの Routes プロパティに不要な情報が含まれている場合にポータル上で消す手段がありませんでした(誰か知ってたら教えてください)。加えて Routes プロパティは RouteTable という構造体なので空の作り方がイマイチ不明でした。そのため noneRouteTable を利用して以下の様に更新しました。

PS /home/daichi> $rt = Get-AzVHubRouteTable -HubName "your hub name" -ResourceGroupName "your rg name" -name noneRouteTable                            
PS /home/daichi> Update-AzVHubRouteTable -ResourceGroupName "your rg name" -name defaultRouteTable -Route $route.Routes -VirtualHubName "your hub name"

Name                   : defaultRouteTable
Id                     : /subscriptions/"your subscription id"/resourceGroups/"your rg name"/providers/Microsoft.Network/virtualHubs/"your hub name"/hubRouteTables/defaultRouteTable
ProvisioningState      : Succeeded
Labels                 : {default}
Routes                 : []
AssociatedConnections  : []
PropagatingConnections : []

誰得な記事となりましたが、どなたかの参考になれば幸いです。

Azure Bastion の shareable links 機能を使って Azure Portal にアクセス権のない人間でも VM 上での作業を可能にする

本記事のタイトルで伝えたいことが完了している気がしないこともないですが、つい先日にまたしても社畜心を捉えて離さないナイス機能が発表されました。そう、Azure Bastion の shareable links 機能です。
azure.microsoft.com
そもそも Azure Bastion をご存じない方の為にざっと解説すると、Azure Bastion は自身の仮想マシンへのアクセスを閉域的に行うことができるサービスであり、エンドポイントをインターネットに公開したり、踏み台の設定等を行うことが不要となります。
これ自体は非常に有用な機能なのですが、Azure Bastion の利用を踏まえたうえでも良く頂いた質問があります。それは「特定の仮想マシンの操作以外は何もさせたくないし、できれば Azure ポータルにもアクセスさせたくないけど、どういった権限を与えたらいい?」です。
石橋を叩いて壊す社畜黒帯な方々と相対したことのある皆様なら「にゃんこ大戦争のねこラーメン道」位の勢いで首を縦に振ってくれることでしょう(にゃんこ大戦争知らない人すいません)。上記の要望を実現する場合、RBAC を活用しても Built-in Role では制限が難しいケースもあり、要望達成がやや難しいという難がありました。

ここで今回紹介する Azure Bastion の shareable links 機能を使うことさえできれば上記の要望が実現可能です。Azure Bastion が生成するリンクだけを共有し、リンクから当該 VM にアクセスが可能となります。この際、リンクを利用するユーザは仮想マシンの捜査権限どころか Azure Portal にログインする権限すら必要ありません。そんな素敵な Azure Bastion の shareable links 機能ですが、現時点での注意点としては以下だと思っています。

  • Azure Bastion の shareable links は現時点でプレビュー - 2022年11月時点
  • Standard SKU でないと利用できない
  • 同じサブスクリプション&同じリージョンの場合は VNET Peering が可能
  • 別リージョン、別サブスクリプションの VNET Peering だとダメ

プレビュー機能なこと自体は元記事を見ればご理解頂けると思いますが、VNET Peering 越しがダメなのはちょっと苦しい条件です。なぜなら一般的な社畜エンプラアーキテクチャでは Hub-Spoke 構成にすることが多く、Hub VNET 側に Azure Bastion を配置し、Hub/Spoke の仮想マシンにアクセスすることが多いからです。この点については Azure Bastion の追加配置を含む検討が必要になるところでしょう。
同じサブスクリプション&同じリージョンの場合のみ VNET Peering は OK のようです。誤読しておりました(汗

どうやって利用するの?

これ自体は非常に簡単です。Azure Bastion を Standard SKU で作成するか、Azure Bastion 既存の Basic SKU を Standard SKU に変更して以下の様に Shareable Link メニューにチェックして設定を保存してください。設定反映には10分程度の時間がかかりますが、以下のスクリーンショットで表示されている左のメニューの Shareable Links は設定有効前は表示されませんが、設定完了後も自動では追加反映されなかったので、10分程度たったら F5 等でブラウザを更新して設定完了を確認下さい。

Shareable Links は SKU を Standard に変更しないと有効化することができません。また、一度 Standard SKU に変更した Azure Bastion は Basic SKU に戻せない点もご注意ください。

Shareable Links を有効化後、左メニューから Shareable Links を選択して以下の様にリンクを作成したい仮想マシンを選択してください。この際、最初に注記で示した通り「当該 Azure Bastion の同一サブスクリプション&同一仮想ネットワーク」の仮想マシンしか選択できない点に注意ください。

仮想マシンの選択後は以下の様にクリップボードにコピー可能な URL が生成されます。

具体例があった方がわかりやすいと思うので、私が作成した Shareable Link を記載すると https://bst-"何かのUUID".bastion.azure.com/api/shareable-url/"何かのUUID" な感じです。使いまわしが可能な点に加え、特定のユーザや権限を示唆するものが何もないという点に注意が必要です。

Windows マシンに接続してみる

まずは Windows 側の Shareable Link をブラウザに入力してみましょう。以下の様が画面がブラウザ上に表示されます。

こちらに対し、ユーザ名とパスワードを入力すれば通常通りログイン可能です。ブラウザ経由となりますが、GUI 操作も可能で元気な Windows 操作が可能です。

Linux マシンに接続してみる

次は Linux マシンへの接続を試してみましょう。「SSH Private Key とかどうするのかなー?」とちょっと心配だったのですが、ブラウザから認証方式を選ぶことが可能なので、こちらから選択&Private Key のアップロードが可能です。

Windows 側と同様に必要な情報を入力すればログイン可能です。


以上で Azure Bastion の shareable links の簡単な解説は終了です。我らエンプラ業を営む生き物が関わる生き物は国境を跨いでも開発者側に制限を加えるのが大好きです(特に公共・金融系が顕著なのも各国変わらず)。銀河英雄伝説でヤン提督が「何にしても、わが同盟政府には、両手をしばっておいて戦いを強いる癖がおありだから、困ったものですよ」と言っていたのが脳裏をよぎりますが、準拠する必要のあるコンプライアンス等を加味しつつ、こうした技を使って是非快適な社畜ライフをエンジョイ下さい。

podcast 配信に誘われて英語の勉強やらアメリカ生活やらについて感想を話した件

Microsoft MVP 時代に仲良くして頂いた竹原さんに英語についてアレコレ聞きたいと相談されたので、誘われて podcast に出てみました。アメリカでの生活とか英語でどう苦労したとか語ってるんで良かったらどうぞ。
anchor.fm
出だしから 「Foreign language side effect って何だっけ?」位の英語力ですが、何とかアメリカで生活しております。過去に英語についてポストもしたことあるので、良かったらこっちもどうぞ。
normalian.hatenablog.com

また、私が言及してる発音矯正してくれた学校はここになります。
www.thejingles-summit.co.jp

Microsoft Defender for Cloud にオレオレコンプライアンスを登録する

このブログを読むような方々はコンプライアンスと聞くと身構えたりテンションが下がるフレンズだと思います(けものフレンズはもう5年前か…)。できれば関わりたくないですが、社畜業を営む我々にとって避けて通れないのもまた事実。可能であれば何とか楽に「コンプラ対応ばっちりっすわ~」と流したいものでしょう。Microsoft は以下の様なコンプライアンスオファリングと呼ばれるサイトがあり、膨大な情報が提供されているのでこれで大丈夫!
learn.microsoft.com
と言いたいところですが、実際のところ「そんな大量の情報読めない」「コンプライアンスのどの項目が Azure のどの機能に対応しているか分からん」というのが実態でしょう。その場合にお勧めしている機能が Microsoft Defender for Cloud の Regulatory compliance です。画面を眺めた方がわかりやすいので、まずは以下のスクリーンショットを参照下さい。

対応しているコンプライアンス一覧に関しては上記リンクを参照して頂ければと思いますが、この例では PCI-DSS での項目が表示されています。仮想マシンや仮想ネットワーク等の IaaS 機能だけでなく、Azure PaaS 機能に加えて AWSGCP にもアカウントリンクして情報の一元管理が可能です。
特に PCI-DSS については、Microsoft Defender for Cloud で分類されている項目がそのまま PCI-DSS 自体の項目に対応しているので、自身のサービスが PCI-DSS に順守する場合に何を確認したら良いか一元的に Azure 上で管理できるということがわかります。
learn.microsoft.com
learn.microsoft.com
後に詳細に解説しますが、上記二つ目のリンクで参照する通り Regulatory compliance の中身は Azure Policy であり、いくつかのコンプライアンスMicrosoft 側より提供されています。今回はこちらに対してオレオレのコンプライアンスを登録する方法を紹介します。

しかし、念のためご注意頂きたいのが、仮に Microsoft Defender for Cloud の項目にすべて順守したからと言ってもコンプライアンス準拠は保証されない点です。これまた PCI-DSS を例に挙げると Qualified Security Assessor (QSA) と呼ばれる人間のみ審査可能であり、外部ベンダーが行うことはできません。そうはいっても通常は「どうやってコンプライアンス対応したらいいか分からない」からスタートせざるを得ない状況が多い中、非常に有用度が高いサービスだともいえる認識です。

オレオレコンプライアンスを登録する

ガバナンスやコンプライアンスという言葉が大好きな自分で手を動かさない方々にとって、ルールを敷いたら現場で順守が当たり前、仮に何かあったら現場での実施ルールが足りなかった等の揚げ足取りの地獄がまっており、実際に作業する方々(特に現場のリーダー層等)にとっては辟易することが多いと思います。Microsoft Defender for Cloud の Regulatory compliance に対し、オレオレコンプライアンスを登録することができるとしたらどうでしょう。どのようなルールが実施されているかは一覧化され、順守状況の可視化もされて一目瞭然となり、ガバナンス運用の手間は大きく減らせることでしょう(その手のガバナンスチームとのコミュニケーションも難関という点は一旦不問でお願いいたします)。
上記で記載した通り Regulatory compliance の中身は Azure Policy であり、特に Initiative と呼ばれる個別 Policy の集合体となります。さっそく自分向けの Initiative を作って試してみましょう。まずは Azure ポータルを開き、Azure Policy の画面から以下の様に Initiative の作成を実施します。

まず最初にルール名と割り当て領域を策定しますが、それ以上に大事なのが Category に Regulatory Compliance を選択することです。これにより後で Microsoft Defender for Cloud の管理画面に登録することが可能になります。

Initiative の作成時、以下の様に Control タブから各 Policy 向けのグルーピングができます(なぜか Policy 選択後なので先にしてほしい…)。こちらで作成する Control がそのまま Regulatory compliance 画面で表示されるグルーピング名になるので注意してください。

次に Policies タブで利用する Azure Policy を選択します。この画面でどの Control に属するかも選択可能です。参考のため、ここではあえてどの Control にも含めない Policy を一つ追加しました。

Initiative の作成後は Assignment を行う必要があります。今回は割愛しますが、監査対象である subscription に作成した Initiative を割り当ててください

当然これだけでは Regulatory compliance 画面に表示されません。ここからは Microsoft Defender for Cloud の画面に戻り Environment setting メニューを選び、監査対象の Subscription の「…」をクリックして表示される Edit settings を選択します。

こちらで遷移した先の画面からさらに Security Policy メニューを選択することで Your custom initiatives 画面が表示されるので、ここから自身で作成した Initiative を追加します。

これでもう終わったと思ってしまうせっかちさんも多いと思いますが、Regulatory Compliance の監視周期は即時自実行ではありません。以下の記事を参照して頂ければと思いますが、Azure Policy や Initiative 自体は 15 分後には利用可能になりますが、Regulatory Compliance については24時間ごとの実行となります。つまりその間は Microsoft Defender for Cloud の画面に反映されません。
learn.microsoft.com

それが待てないせっかちさんの貴方に朗報です。Azure cli 等を利用することで即時実行が可能です。Get policy compliance data - Azure Policy | Microsoft Learn を参考に以下のコマンドを実行して即時反映が可能です(といっても私の場合、コマンド自体の実行完了には15分程度かかりました)。

az login
az account set -s "your subscription id"
az policy state trigger-scan

コマンド実行後は Microsoft Defender for Cloud の Regulatory Compliance の画面からオレオレコンプライアンスが無事に参照可能です。

上記で分かる通り、Initiative 作成時の Control 毎にグルーピングされ、特に Control を割り当てなかったものは Additional Recommendations というカテゴリになります。

以上でオレオレコンプライスを Microsoft Defender for Cloud で表示する方法を紹介しました。他のコンプライアンス含めてマルチクラウドマルチプラットフォームが一元管理可能できるので有用度は高いのではないでしょうか。

Update Management Center (Preview) を試す

今回は現時点(2022年11月)では Preview が取れていませんが、今後は重要度が増すであろう Update Management Center について紹介したいと思います。事前に以下のページ位は斜め読みをすると理解が早いのではと思います。
learn.microsoft.com

Update Management Center は OS のセキュリティパッチの適用をコントロールすることができるクラウドサービスですが、個人的に Update Management Center が非常にイケていると思っているところは主に二点です。

  • Windows だけでなく Linux 側も含め一括で制御可能
  • Azure Arc と連携することで Azure や on-premise のみならず AWSGCP 等の Azure 外部のプラットフォームについても制御可能

上記で何が嬉しくなるかというと SIer 各位の頭痛の種である Excel 表でのサーバ情報のマスター管理からの解放 という点が挙げられると思います。運用手順等で管理をしていたとしても人間が手作業で行う以上はミスや抜け漏れが発生するものです。Update Management Center を活用することでサービス全体の各マシンの状況が一括で確認できるようになります。

管理画面のトップページとしては以下となります。管理対象マシンが何台あるか、どのマシンにどのパッチが当たっていないか、パッチ適用の実施状況、Windows/Linux で適用されていないパッチの一覧等が表示されます。

Azure Automation の Update Management との違いは?

Azure 歴の長い方は「Azure Automation の Update Management があるじゃないか」とお気づきの方もいらっしゃると思いますが、Azure Automation とは以下の明示的な差が存在します。

  • Azure Automation の Update Management は別途 Azure Automation をリソースとして作成する必要があるが、Update Management Center は組み込み機能
  • Supported regions for linked Log Analytics workspace | Microsoft Learn Log Analytics workspace を Linked workspace として作成する必要があり、Azure Automation リソースの作成場所に制限があった(日本なら Japan East に作って東西の VM リソースを繋げば良いという話はありますが

イメージとして「Update Management Center」は 「Azure Automation の Update Management」の後継という捉え方をすれば祖語はない認識です。今までは Azure Automation のリソース管理や Log Analytics エージェントのインストール(Azure Automation で仮想マシン等を操作するために必要)等の追加の対応が必要でしたが、Update Management Center は特別な処理をせずに利用可能となります。

Update Management Center を使う場合のデメリットは?

逆に Update Management Center を利用する場合のデメリットをあえて考えてみたいと思います。ざっと以下のサポートマリックスを確認しました。

Windows 側はほぼ差がない認識ですが、例えば Cent OS, RHEL, Oracle Linux の場合に Update Management Center 側は v6 に対応していない(Azure Automation 側は対応)点、Ubuntu では v14 に対応していない点が挙げられます。
また、現時点ではプレビューだということもありますが、現時点ではサポートされているリージョンに日本が含まれていません(もっとも近い場所は東南アジア)。

外部ベンダーが提供するサービスをサポート有&追加構築無しの利用を夢見る女子高生な方々にとって、サポート無かつ日本リージョンでスケーリングされない(日本から利用できないというわけでなく Update Management Center の内部リソースは現時点では日本に展開されないの意)現状での利用は門限破りの朝帰り位の覚悟を要するのではという感覚です。

Update Management Center 自体を有効化するには

上記の通り Azure にとっては組み込みサービスなので、利用の開始自体に特に必要な処理はありません。。。。と言いたいところですが、現時点ではプレビューなこともあり以下の記事に従ってリソースプロバイダの有効化を行ってください。
learn.microsoft.com

az login
az account set --subscription "your subscription id"
az feature register --namespace Microsoft.Compute --name InGuestAutoAssessmentVMPreview
az feature show --namespace Microsoft.Compute --name InGuestAutoAssessmentVMPreview

上記のリソースプロバイダ登録に10分程度かかると思いますが、以下の様に az feature show で Status が registered になるまで随時確認してください。

Update Management Center を実際に利用する

トップ画面から Machines のタブをクリックすると以下の様に管理対象のマシンが表示されます。こちらの一覧に追加するのに特別な手順は不要です。Azure の仮想マシンなら自動的にこの一覧に加えられ、Azure 外部のマシンは Azure Arc を有効化することで一覧に加えられます。

画面で確認できる通り、Update Status の箇所で「更新パッチを全て適用済/X個のパッチが未適用/アセスメントが未実施」の三種類となります。アセスメントが実施されていない登録直後のマシンに対しては No updates data で表示されるので、最初に実施するのはアセスメントとなります。

アセスメントは以下の様にマシンを選択して Check for updates を実施することでアセスメントを手動で実行可能です。

当然以下の様に定期的なアセスメントを実施する設定も可能です。24時間ごとにパッチ適用の状況をチェックします。Enable periodic assessment using policy | Microsoft Learn の様に Azure Policy との併用も可能です。

アセスメント実施後は未適用のパッチ数が表示されるので、再度対象マシンを選んで One-Time update を選択しましょう。

次に適用パッチを選びます。こちらについては Windows/Linux を一括で選択できるようになった点が Azure Automation との大きな差と言えるかもしれません。適用対象パッチを細かく選択できる点は Azure Automation 側と同様です。

最後に、以下の様に再起動の条件を設定することで更新パッチの適用が行われます。

パッチ適用を実施後、画面左の history タブを選択することで以下の様にプロセスの状況を確認できます。

パッチ適用中の場合は InProgress となりますが、それ以外にも成功・失敗が確認できます。また、操作内容がアセスメント・パッチ適用なのか、手動操作か定期実行操作か等が確認できます。

今回は簡単な概要紹介をさせて頂きましたが、今後は Azure 外部も含めたマシンの更新管理で重宝される機能だと思われるので、是非お試しください。

Azure Blob Storage に SFTP でアクセスする - 閉域網版

前回の記事で Azure Storage に対して SFTP でアクセスするところまで行いました。Azure Storage 個別にユーザを作成し、パスワード or SSH Key Pair での認証が可能、Azure Storage 個別で認可制御を行えることが分かりました。
normalian.hatenablog.com
しかし、上記の記事では石橋を叩いて壊す社畜黒帯の方々にとって大事な観点が欠けています。そう、閉域網でアクセスするネットワーク制御です。こちらに関しては社畜というだけでなく、様々なコンプライアンスに対応するためにも非常に重要な観点です。特に金融系のコンプライアンスである FICS や PCI-DSS 等に準拠をする場合、Express Route や VPN で on-premise 側とつないでの閉域網通信は必須要件と言えるでしょう。
Microsoft Azure の場合 What is a private endpoint? - Azure Private Link | Microsoft Learn と呼ばれる機能を利用し、Microsoft Azure の仮想ネットワークに対してのみエンドポイントを公開することで閉域網からアクセスすることが可能になります。

今回の構成例としては以下になります。xxxxxxxxxwestus2.blob.core.windows.net 側が公開 FQDN となり、xxxxxxxxxwestus2.privatelink.blob.core.windows.net が Private DNS が関連付けされている VNET でのみ名前解決が可能な FQDN となります。

Private Endpoint を設定してインターネットアクセスを禁止する

まずは Private Endpoint から設定しましょう。以下の様にストレージアカウントの Network メニューから Private Endpoint 作成のメニューを選択し、当該 VNET に対してPrivate Endpoint 作成を完了します。

Private Endpoint の作成が完了すると、以下の様に VNET 側に NIC が登録されます(例でのプライベートアドレスは 192.168.0.7 です)。

次にインターネット側からのアクセスを制限します。ストレージアカウントの Private Endpoint の有効化を行うことで閉域アクセスは可能となりましたが、このままの設定では公開 FQDN からのアクセスは未だに可能となっています。こちらを禁止するためには以下の様にストレージアカウントの Network メニューの Firewalls and virtual networks のメニューから禁止できます。加えて Network Routing は Microsoft Network routing となっていることを確認ください。

インターネット経由でのアクセス

社畜御用達ツール WinSCP で前回行ったアクセスを再度実施してみましょう。以下の様なエラーが表示され、アクセスがブロックされるはずです。

Private Endpoint 経由でのアクセス

次に Private Endpoint 経由でのアクセスを行います。Host name には Private DNS で指定した FQDN でアクセス可能です。以下の様に Private DNS 側に登録された FQDN を使えばアクセス可能です。


感のいい方なら「NIC に登録された Private IP でもアクセスできるのでは?」と気づいたかもしれません。ご認識の通り当該 Private IP を指定することで SFTP 接続は可能でしたが、Private Endpoint に割り当てられた Private IP は以下の様に Dynamic となります。

Dynamic で割り当てられた IP の場合、何らかの要因で IP アドレスの再割り当てがされた場合に IP アドレスが変更されることを意味しています。古からの Azurer なら「原則 xxx.xxx.xxx.4 から割り当てられるからそこを駆使すればいいじゃん」と思うかもしれませんが、明にサポートされていないやり方はお勧め致しません。

実はこのブログを書いた後に Azure の更新を眺めていたら以下の情報を見つけてしまいました。どうやら Private Endpoint だろうが IP 固定ができる様です。
azure.microsoft.com

詳細は az network private-endpoint ip-config | Microsoft Learn のブログを参照頂くとして、以下のコマンドを行うことで無事に IP アドレスが固定できました。以下の Private IP アドレスは予め Private Endpoint 作成時に割り当てられた IP アドレスです。

az network private-endpoint ip-config add --endpoint-name "daisamiclientwestus2-storage" -g "daisami-client-rg" -n myipconfig --group-id blob --member-name blob --private-ip-address "192.168.0.7"

Azure Blob Storage に SFTP でアクセスする

「最近何か面白い発表でもないかな~」と思っていたら、Azure Storage にまつわる以下のアナウンスを見つけました。
azure.microsoft.com
一体、何度「SFTP でアクセスしたい」という質問を受けたことでしょう。結構前に Preview 発表をしていたのは記憶にあるのですが、SFTP を愛してやまない社畜力の高い方々は Generally Available (GA) になるまで石橋を叩いて壊すレベルで慎重を期すと思い、スルー控えていましたが重い腰を上げる時が来たようです。

概要や詳細については以下の記事を参照していくことになります。こちらの参照は必須となるので、本記事を通読して概要を把握した後はご参照ください。
learn.microsoft.com
上記の記事をざっと眺めましたが、認証プロキシ被害者の会を開催できそうな社畜力の高い方々が興味を示しそうなポイントは以下でしょうか(偏見有り)。

  • Azure Storage は general-purpose v2 か premium block blob storage 出ないとだめ
  • ポートは 22 番から変更できないので、オンプレからのアクセス時は outgoing ポート 22 番を許可しないとだめ
  • 固定 IP でのアクセス先を指定できないので FQDN で指定する必要あり(これは SFTP というより Azure Storage 自体の制限
  • Azure AD の認証・認可は対応してない(2022年10月時点)ので、RBAC での ACL には対応していない。上記記事の caution に具体例が書いてあるので参照下さい
  • Azure Storage 上に SFTP アクセス専用の local user が最大1000人まで作れる
  • 上記 local user の認証にはパスワードか SSH Key pairs が利用可能
  • local user 毎にアクセス制御は個別に設定可能

個人的な印象としては Azure AD の認証と連動していないので「うちは Microsoft 365 を導入してるから、そのユーザを活用できるんだよね?」というシナリオには向いてないなという印象です。現時点ではユーザ管理を Azure Storage 個別で行う必要があるので、直接そういった運用ができる組織が使う方が良いのではないでしょうか。

ではさっそく設定して使ってみましょう。

SFTP support for Azure Blob Storage を試す

general-purpose v2 または premium block blob storage の Azure Storage アカウント自体を作るステップは割愛します。もし general-purpose v1 や classic タイプの Azure Storage アカウントを利用している方は事前に upgrade してください。
以下の様に Azure Storage アカウントには SFTP のメニューがあるので、こちらを指定してまずは SFTP を有効化します。この処理実施時に Local users も有効化されます。

この時点ではユーザーは一切登録されていないので、当該 Azure Storage アカウントにアクセスするためのユーザを手動で作成します。以下の様に自分でユーザ名を指定(azureuser は私が自分で入力した例です)し、パスワードまたは SSH Key Pair を指定して認証方式を決定します。この際、既に Azure VM 向けにアクセス用の SSH Key Pair 等有れば検証用には便利でしょう。

次にどのストレージコンテナにどの権限でアクセスするかを設定します。ストレージコンテナ毎にアクセス制御を個別に指定できるので、手動で運用する場合は煩雑になりがちだと思いますが制御そのものは実施可能です。

ここで重要なのが Home (landing) directory です。Azure Storage アカウントのルートディレクトリへの SFTP アクセス許可は出来なさそう(誰か発見したら教えて下さい)なので、ここを空欄にしたままアクセス制御をしようとすると以下のエラーが発生しました。Home (landing) directory は必ず設定する様にしてください。

上記でお察し頂けたかもしれませんが、社畜力に満ち溢れる身として、今回は WinSFTP を SFTP クライアントとして利用しています。こちらで指定するユーザ名にはちょっと癖があるのでご注意ください。以下の様に "Azure Storage アカウント名"."作成した local user 名"をユーザ名として指定します。

コンテナも指定する場合は "Azure Storage アカウント名"."コンテナ名"."作成した local user 名"となるので、この辺りで混乱する方も居るかもしれません。
私が作成したユーザは特にパスワードを指定せずに作成したのでパスワードは入力不要ですが、以下の様に WinSCP 上で SSH Key Pair の指定を忘れずしてください。

設定完了後、以下の様に通常の SFTP サーバの様に WinSCP 上からは作業可能です。

サポートされている SFTP クライアントは以下に一覧があるので、必要な場合は参照下さい。
SFTP support for Azure Blob Storage | Microsoft Learn