normalian blog

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

Microsoft Azure の拡張機能やエージェントのバージョンに関する Tips

最近あった質問の中で、仮想マシンのエージェントや拡張等々のバージョンについて質問されたことがあったのですが、どれがどのバージョンかというのがかなり分かりにくかったのでブログにまとめたいと思います。ことの発端となったのは以下のスクリーンショットで「Azure Agent はどこ？」や「Azure Site Recovery Agent のバージョンはどこで確認するのか？」といった質問が来たからです。

特にオチ等はありませんが、言われてみればこの辺りはややこしいので Tips としてブログにまとめておいた方が良かろうと思ってこちらにまとめておきます。

Azure VM Agent のバージョンはどこ？

これについては仮想マシンの Extensions + applications メニューには存在しません。Azure Agent のバージョンは以下の様に Properties メニューから確認できます。以下の様に Windows と Linux ではバージョンが異なることがわかります。

Linux でも同様のことが可能ですが、Windows の場合なら以下の様にエクスプローラーから開いて Azure Agent の実態があるフォルダにアクセスることが可能です。C:\WindowsAzure\ 配下に Azure Agent の各バージョンが配置されているのが分かると思います。

Extensions + applications メニューのバージョンって何？

これが一番分かりにくいところかなと思っていますが、ここで表示されるバージョンは typeHandlerVersion と呼ばれる「スクリプトとして実行されるVM 拡張部分のみ
（Azure VM agent 等の実態のエージェントとは別）」のバージョンになります。
learn.microsoft.com
VM 拡張の実態は各種スクリプトを動作させるもの（Azure Monitor Agent の実態をインストールする等）になりますが、そちらのバージョンを表しています。例として Azure Site Recovery を取り上げますが、以下のコマンドを利用することで ASR の VM 拡張バージョン（!= ASR 等のエージェントのバージョン）の確認が可能です。

PS C:\Users\daisami> az vm get-instance-view --resource-group rg-name --name vmname --query "instanceView.extensions[] | [?type=='Microsoft.Azure.RecoveryServices.SiteRecovery.Windows']"
[
  {
    "name": "SiteRecovery-Windows",
    "statuses": [
      {
        "code": "ProvisioningState/succeeded",
        "displayStatus": "Provisioning succeeded",
        "level": "Info",
        "message": "Installation and configuration succeeded.",
        "time": null
      }
    ],
    "substatuses": [
      {
        "code": "ComponentStatus/{\"unique_id\":\"0d4f05d6-4960-4157-80ef-00ade88ffb01\",\"start_time_utc\":638125298878808978,\"end_time_utc\":6381252994438287
68,\"os_identifier\":\"Windows Server 2019 Datacenter\",\"os_version\":\"10.0.17763\",\"azure_guest_agent_version\":\"2.7.41491.1071\",\"python_version\":null,\
"kernel_version\":null,\"available_physical_memory\":4680007680}/succeeded",
        "displayStatus": "Provisioning succeeded",
        "level": "Info",
        "message": null,
        "time": null
      },
      {
        "code": "ComponentStatus/taskid:7849f91b-2ea6-4bd7-894a-f7a7b086fbc3/succeeded",
        "displayStatus": "Provisioning succeeded",
        "level": "Info",
        "message": null,
        "time": null
      }
    ],
    "type": "Microsoft.Azure.RecoveryServices.SiteRecovery.Windows",
    "typeHandlerVersion": "1.0.0.9202"
  }
]

Azure Site Recovery Agent のバージョンは？

上記で ASR 拡張のバージョンは分かりましたが、VM にインストールされる Agent のバージョンはどこで確認したら良いのでしょうか？ASR は実態のエージェントとして、以下の Mobility Agent と呼ばれるものをインストールします。
learn.microsoft.com

こちらのバージョンを確認する一番簡単な方法は Recovery Service Vault の Replication Item から以下の様に確認する方法です。

実際のバイナリ等は C:\Program Files (x86)\Microsoft Azure Site Recovery\agent に配置されます。


ここで注意が必要な点として C:\WindowsAzure\Logs\Plugins 以下に以下の様な Extensions + applications メニューに表示されているものが並んでいる点です。こちらにはエージェントのバイナリ等は配置されておらず、VM 拡張を有効化する際に実行されるスクリプトの実行ログが格納されています（フォルダパスに Logs とあるので推察する方もいると思いますが）。
ログの一部を抜粋しますが、以下の様なコマンド実行内容が出力されており、VM 拡張を有効化する際の詳細処理が確認可能です。

[2023-03-26T08:17:21.750Z] Executing: C:\Packages\Plugins\Microsoft.Azure.RecoveryServices.SiteRecovery.Windows\1.0.0.9202\Scripts\enable.cmd  
[2023-03-26T08:17:24.512Z] Execution Complete.
######
Execution Output:
C:\Packages\Plugins\Microsoft.Azure.RecoveryServices.SiteRecovery.Windows\1.0.0.9202>start /B cmd /C AzureReplicationVmExtension.exe "enable" 
2023-03-26T08:17:25.2774571Z	[Information]:	----------------VM Extension run started----------------
2023-03-26T08:17:25.2774571Z	[Warning]:	Skip the logging due to absence of the log blob URI: .
2023-03-26T08:17:25.2774571Z	[Information]:	Operating system identifier: Windows Server 2019 Datacenter. Operating system version: 10.0.17763. Azure guest agent version: 2.7.41491.1075.
2023-03-26T08:17:25.2774571Z	[Warning]:	Skip the logging due to absence of the log blob URI: .
2023-03-26T08:17:25.2824569Z	[Information]:	Bcdr Handler Initialized SiteRecoveryExtensionProd.
2023-03-26T08:17:25.2824569Z	[Warning]:	Skip the logging due to absence of the log blob URI: .
2023-03-26T08:17:25.2824569Z	[Information]:	Initializing configuration helper.
2023-03-26T08:17:25.2824569Z	[Warning]:	Skip the logging due to absence of the log blob URI: .
2023-03-26T08:17:25.2874560Z	[Information]:	Configuration file count: 1 and files are C:\Packages\Plugins\Microsoft.Azure.RecoveryServices.SiteRecovery.Windows\1.0.0.9202\RuntimeSettings\0.settings
2023-03-26T08:17:25.2874560Z	[Warning]:	Skip the logging due to absence of the log blob URI: .
2023-03-26T08:17:25.2874560Z	[Information]:	GetEnvironmentVariables: 
2023-03-26T08:17:25.2874560Z	[Warning]:	Skip the logging due to absence of the log blob URI: .
2023-03-26T08:17:25.2874560Z	[Information]:	  COMPUTERNAME = Win2019Gen2VM01
2023-03-26T08:17:25.2874560Z	[Warning]:	Skip the logging due to absence of the log blob URI: .

Microsoft Sentinel で検証用 Incident を作ってみる

新年あけましておめでとうございます。最近はセキュリティ周りのキャッチアップに迫られてえっちらほっちらと Defender 関連やら Microsoft Sentinel をキャッチアップしとります。どちらも脅威の検出、調査・対策の検討等々で大活躍する強力なツールなのは間違いないのですが、学習・検証用に Incident 等を作成するのは意外と面倒だったりします。
そんな悩みに対して応えるため、実はサンプルの Incident を発生させる機能が提供されています。以下の記事は Microsoft Defender for Cloud の記事ですが、Microsoft Sentinel の Incident 作成としても利用可能です。
learn.microsoft.com

上記の記事で記載されている内容を端的に表現すると「 echo みたいな無害なコマンドを他とかぶらない名前（ asc_alerttest_662jfi039n ）に変えて実行すれば Incident 作るぜ」というものです。Linux と Windows でややファイル操作が異なるものの、大枠の操作は一緒です。今回はこちらの利用感を軽くまとめてみたいと思います。

事前準備

当たり前の話ですが、以下は必須です。

Microsoft Sentinel 向けの Incident を作成してみる

これに関しては記事に記載がある通りですが、さっそく用意した CentOS の仮想マシンに SSH でつないで以下のコマンドを実施してみましょう。echo を記事で指定した通りのファイル名で実行していますが、オプション無を 1 回、オプション有を 6 回実行しています。

[xxxxxxxxx@centosvm01 ~]$ cp /bin/echo ./asc_alerttest_662jfi039n
[xxxxxxxxx@centosvm01 ~]$ ./asc_alerttest_662jfi039n 

[xxxxxxxxx@centosvm01 ~]$ ./asc_alerttest_662jfi039n testing eicar pipe
testing eicar pipe
[xxxxxxxxx@centosvm01 ~]$ for i in `seq 1 5`;do  ./asc_alerttest_662jfi039n testing eicar pipe; done
testing eicar pipe
testing eicar pipe
testing eicar pipe
testing eicar pipe
testing eicar pipe
[xxxxxxxxx@centosvm01 ~]$

コマンド実行後、通知設定をしていれば 5 分もしないうちに以下のメールが届きます（これ自体は Defender 側の機能ですが、Microsoft Sentinel 側で Incident が作成されたタイミングを認識するのにちょうどいいので）。

次に Microsoft Sentinel を開きます。何個の Incident があるかを確認してみましょう。開いてみると新規の Incident が 7 個作成されています。「実はオプション要らないのでは？」という疑問が頭をよぎることはさておき、severity が high の incident がコマンド実行回数分だけ作成されていることが分かります（ closed になっている incident は私の環境で別途発生したものです）。

更に以下のコマンドを実行したところ新規に Incident が作成されたので、どうやら引数と関係なく Incident は作成されるようです。

Last login: Tue Jan 10 14:16:43 2023 from vm000001.internal.cloudapp.net
[xxxxxxxxxx@centosvm01 ~]$ ./asc_alerttest_662jfi039n "Do I need to put something here?"

Microsoft Sentinel で Incident を深堀してみる

以下の様に Incident メニューから個別に一つ選んで View Full Details を押して詳細を見てみましょう。

ボタン押下後は以下の画面に遷移します。Incident の状態を New から Active/Closed にしたり、Incident の担当を割り当てたりは当然可能ですが、せっかくなので以下の Investigation のボタンを押してみましょう。

以下でご覧の通り、Incident に関連するエンティティ一覧が表示されます。タイトルには「テストアラートだから脅威じゃないよ」と英語で記載されています。

実際の脅威で有れば、ここから SOC チームのメンバーが「ユーザは誰か？」「どんな引数で実行したのか？」「いつ実行したのか？」等を確認しつつ、どの様な脅威なのかを分析し、運用チーム等とどの様な対応をするかを検討していきます。今回の Incident は実際の脅威ではないので、特に対応不要として Incident を Closed に変更して対応を終了します。


今回の機能は意外と知られていないので、Microsoft Defender for Cloud はもちろん Microsoft Sentinel を学習する際にも有用な機能だと思います。

アメリカでソリューションアーキテクトとしての 5 年を 2022 年で振り返って

つい最近、技術的にも人間的にも敬意を払ってる友人と焼肉を食べてきた際に「１年の振り返りはやった方が良いよ～」とアドバイスをもらったので、アメリカで Solution Architect として５年ほど住んでみたことの振り返りと反省を書いてみようかなと思っています。私についてのざっとの内容は以下とかを見ると分かりやすいかもしれません。
normalian.hatenablog.com
念のためざっと自己紹介すると、私自身は大手系 SIer として日系企業に勤めた後、外資企業にソリューションアーキテクトとして転職して３年弱位でアメリカに渡米し、今のところ何とか無事に５年ほど無事に過ごすことができました。外資系企業に転職後、役割の差は大小あれど一貫してソリューションアーキテクトとして働いております。英語経験についてよく聞かれるのであらかじめ記載すると、自身の経歴としては日本国外に在住経験は全くなかったどころか、初めてパスポートを作ったのが大学院卒業後というレベルです。

渡米１～２年目

この辺りは純粋に英語でかなり苦労しました。RareJob で何度も英会話のトレーニングをして、渡米前は講師の方とはそれなりにスムーズに話せるようにはなりましたが、渡米した後に non native と話すことに慣れていない現地勢と話したときに全く伝わらずに非常に苦労しました（汗。結果としては RareJob の講師の方々は日本人のダメ発音に慣れすぎてるせいで、発音の矯正を何もせずに伝わらないというのを痛感した初年度でした。自分の能力を１００としたら１０も出せればいい方だなというのが渡米当初の実感でした。
本社がシアトルの会社に勤めている状況でロサンゼルスに赴任したこともあり、現地の同僚がほぼ居ない状態で就業したので現地のことを聞ける相手が全くいない状態だったので現地の生活に慣れるのにも非常に苦労しました。T-Mobile のとある支店の店員には英語がダメすぎて追い返されたり、SSN（ソーシャルセキュリティーナンバー）申請時にスタッフに英語ができなすぎるのを小声で笑われた等は、英語ができない勢の場合はアメリカでは（少なくともロサンゼルスでは）通常運転です。これは単なる個人的な体感ですが、英語で意思疎通ができないレベルの人間に対して在米現地民は相当に対応が雑です（これに比して、いわゆる GAFAM 村の方々は英語が苦手な移民の対応に慣れている人が多いので優しい人が多いです）。
純粋に英語が厳しい＆現地に慣れるのに苦戦するという意味で最初の半年くらいは仕事らしい仕事になりませんでしたが、他のメンバーが答えられないような内容を真摯に答え続けることで徐々に技術的な腕をかってくれる方々も増えました。あれやこれやと、自分の役職の枠を超えて現地のでどぶさらいみたいな仕事でも拾いながらこなした結果、お客さん側（相手は日本人皆無な native speaker 多めでした）の SVP/VP レベルの方々の信頼も得、仕事は比較的順調で世界規模にサービス展開する案件の CI/CD 回しながらの Windows Container やら Microservices のかなり deep なところをやれたので面白かったです。
※やっぱ最低限の意思の疎通ができる言語力と相手から信頼される程度の能力（技術だけに限らず）が無いと死ぬというのは痛感しました

実はこの辺のロサンゼルス時代はコロナ渦でなかったにもかかわらずほぼリモート勤務だったので、お客さんとは非常に親密になった人は何人かいましたが、non Japanese な同僚とは英語的なコミュニケーションがつらすぎることもあって中々親密な関係を持てなかったというのが率直な反省でした。逆にロサンゼルス時代の日本人同僚の方々とは今も親密な関係を持たせて頂いていることもあり、なんだかんだで米国側に移住した場合、同郷の人間しか同郷からの移住の苦労は分かりっこないので、下手に肩肘張らずに日本人の先住移民の方々に素直に相談したほうが良いと身に染みたのもこの辺です。何だかんだで手探りでの試行錯誤の期間でした。

渡米３年～５年目

この辺からはある程度は英語のコミュニケーションに慣れてきたので、同僚とくだらない雑談ができる頻度がかなり増えてきました。とはいっても、私自身の腰が引けていて中々に深入りしたコミュニケーションがとれないなと思う状況は未だに残ってるなぁとは思います（汗。くだらない雑談をする同僚とは家族の話題なり、お互いの出身国の愚痴なり、人種問題の雑談なり、かなり深入りして会話できることを実感できるようになったなぁとは思っています。
仕事ではインド・ドイツ・北アイルランド・オランダ等々に出張し、現地での Hands-On 系のイベントを主催・実施したので、この辺りからは色んな人を巻き込んで親密なコミュニケーションをとりながら仕事をできるようになったのを実感しました。自分の中でも「日本国外でも普通に仕事ができるようになったなぁ」という感覚で、ここにたどり着くまでにはアレやコレやと涙なしには語れないアレコレはありますが、何とか日本語圏外でも仕事ができるようになったかなと思ってます。

今後について

私の役職である「Solution Architect という役職に就いた後、次のステップでどういったキャリアを形成するのか？」というのは他の Solution Architect 各位の話を聞いても中々に悩んでいる方が多いかなというのが率直な印象です。渡米前は「日本国外のことは分からないし、渡米して２～３年くらいは働いてみてから次のステップを明確にしよう」という気持ちはありましたが、既にその２～３年は突破してしまいました（汗。とはいっても、渡米して GAFAM 系の本社側だからこそ見える組織構成や会社としてのオペレーションが色々と見えてきたなぁというのも実感です。
技術に関しては「Azure 全般に対して幅広かつ踏み込んだ知識を持っている」という感じで、総じて高い評価を貰っているかなと信じています（リップサービスが上手い人たちが多いので確信はないですが）。ただ、現在は Azure プラットフォーム自体を取り巻く領域が体系化・成熟してきた実感もあり「Azure 全般が得意」というような強みでなく「Azure の〇〇の専門家」や「Azure と××を組み合わせる専門家」等の今よりも踏み込んだ領域での専門性は作らないといけないなとは思っている状態です。
現業のタスクも学びが色々と多く励みになっていますが、2023年では中長期的なキャリアに対して具体的な一歩と言える結果を出したいなと思っています。

（おまけ）他国の IT 事情について

各国の案件を支援して実感することは『自分の国は特殊だから～』と自称する方の案件で各国の特殊性を感じないという点です。この辺り、日本人の他国と話さない方ほど「日本は特殊なので～」と言って思考停止するケースをよく見ましたが、日本以外でも自国以外の人間のやり取りをする頻度が低い人ほど自国を特殊だと思い込んでいる人が多いなという印象です。Twitter 等だと「日本は海外と比べて遅れて～」等の発言を聞きますが、各国でも塩漬け案件は山の様にあるので、私個人の感覚として、他の国の印象はこんな感じです。

  • アメリカという文脈でシリコンバレーが意図されることが多いが、アメリカ国内でもシリコンバレーや GAFAM は特殊扱いされてる（2022年の年末に 70% のフライトをキャンセルした某アメリカ航空会社は「90年台の IT を未だに使い続けている」とか言われてるんで
  • 日本とかドイツみたいに2000年辺りに IT 投資をできる余力があったところは既存資産があるのでマイグレーション案件が多め
  • オーストラリア・ニュージーランド外の APAC 各国とかは今 IT 投資を進めてることが多いので、移行案件よりも新規案件が多め
  • ヨーロッパも保守的な国はすごく多く「契約にないけどこれ何とかしろ」と突っ込んできたのは日本とヨーロッパ某国

上記は単なる私の肌感なので統計値を取ったら当然話は変わると思いますが、シリコンバレー＆GAFAM を除き、現場の業務システム系では欧米圏と日本に大きな差はないなぁというのが率直な感想です。

散文的な文章となってしまいましたが、皆様も良いお年を過ごして頂ければ幸いです。意見・コメント等有れば頂ければ嬉しいです。

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 にオレオレコンプライアンスを登録する

Windows Azure Azure

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

対応しているコンプライアンス一覧に関しては上記リンクを参照して頂ければと思いますが、この例では PCI-DSS での項目が表示されています。仮想マシンや仮想ネットワーク等の IaaS 機能だけでなく、Azure PaaS 機能に加えて AWS や GCP にもアカウントリンクして情報の一元管理が可能です。
特に 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 で表示する方法を紹介しました。他のコンプライアンス含めてマルチクラウド・マルチプラットフォームが一元管理可能できるので有用度は高いのではないでしょうか。