Windows 10のサポートは2025年10月14日(火)に終了します。Microsoftはサポート終了後も「拡張セキュリティアップデート」を提供することを約束していますが、無料で利用するには「Windowsバックアップ」の設定が必要です。新たに、欧州経済領域(EEA)のユーザーに限り、このWindowsバックアップを不要とする施策をMicrosoftが打ち出したことが分かりました。
MicrosoftがWindows 10の延長セキュリティ更新プログラムをヨーロッパ限定で条件緩和 - GIGAZINE
⇧「欧州」だけが優遇されるのが意味が分からない...
しつこいと思われようが、
Microsoftが開発するOS「Windows」は、1985年に誕生したWindows 1.0からスタートして2012年にWindows 8が登場するまでたくさんのバージョン改訂を行い、それに伴ってOSとしての機能も大きく変化させてきました。そんなWindowsシリーズの最新バージョンとなるのが「Windows 10」ですが、Microsoftのジェリー・ニクソン氏が「Windows 10はWindowsの最後のバージョンとなる」と発言して話題になっています。
Microsoftで開発部門に属するジェリー・ニクソン氏は、アメリカ・シカゴで開催されたMicrosoft Igniteというイベントの中で、Windows 10がデスクトップソフトウェアの「最後のバージョンになる」と発言しています。
さらに、Microsoftも「Windowsは新しいイノベーションとアップデートを継続して提供していく」と声明を出しており、今後は独立した新しいバージョンを提供していくのではなく、既にリリースされているWindowsを数ヶ月ごとあるいは1年ごとに「大幅アップデート」していくことになるとコメント。
⇧ 上記のような発言の責任は取ってもらう必要がありますな。
「有言実行」されないのであるならば、消費者を騙していたわけになるので「偽証罪」が成立すると思うのでね。
「Winodws 11」にアップデートできない端末（「Windows 10」を利用しているもの）を使用している消費者に、「Windows 11」対応の端末を購入する費用を全額補償して欲しいところですわ。
Azure Application Gatewayのバックエンドプールとのネットワーク制御についての情報が欲しい
公式のドキュメントによると、
アプリケーション ゲートウェイの動作
この記事では、アプリケーション ゲートウェイで受信要求をどのように受け付け、それらをどのようにバックエンドにルーティングするかについて説明します。
https://learn.microsoft.com/ja-jp/azure/application-gateway/how-application-gateway-works
⇧ 上記のような説明があるのだが、肝心の「バックエンドプール」側のネットワーク制御の話が不明瞭という...
「バックエンドプール」としては、
- Virtual Machine
- Virtual Machine Scale Set
- On-premises/external App Servers
- Azure App Service
の選択肢があるようなのだが、いずれにしろ、「ネットワーク」で外部からの通信を遮断しているはずなので、「Application Gateway」から流れてくる通信を許可する設定、所謂「ネットワーク制御」が必要になって来ると思うのだが、見事に説明が無いのよね...
ちなみに、
⇧ 上記サイト様でも、「バックエンドプール」側の「ネットワーク制御」の話は出てこない...
完全に推測になってしまうのだが、
⇧ 上図の構造に近いことが、「Application Gateway」との間でも実現できるってことなんですかね？
ただ、「バックエンドプール」で、
- On-premises/external App Servers
を利用している場合は、対象外となると思うが。
で、「Application Gateway」には「サブネット」が割り当てられるので「IPアドレス」の「範囲」も割り当てされますと。
なので、「バックエンドプール」側の「NSG（Network Security Group）」の「セキュリティ受信規則」の追加で「Application Gateway」の「サブネット」の「IPアドレス」の「範囲」を許可するようにすれば良いと。
「バックエンドプール」で、
- On-premises/external App Servers
を利用している場合は、
⇧ 上記のような感じで「private endpoint」を利用する感じになるんかね？
「Application Gateway」に対して「双方向」のアクセスを受け付ける構成になっているように見えるので、「オンプレミス環境」が「バックエンドプール」の役割も担っていると思われる。
何やら、
サンプルシナリオ
次の例では、ルート テーブルを作成し、それを Application Gateway サブネットに関連付けて、そのサブネットからの送信インターネット アクセスが確実に仮想アプライアンスから送信されるようにします。 大まかには、次の設計が図 1 に要約されています。
図 1: 仮想アプライアンスを経由した送信インターネット アクセス
⇧「ルート テーブル」を利用する方法も紹介されているのだが、「NAV-Subnet」内の「仮想マシン」に対する通信を制御してると思われる「NSG（Network Security Group）」に対して「Application Gateway」からの通信を許可する「セキュリティ受信規則」を追加していないように見えるので通信が弾かれる気がするのだが、「Microsoft Azure」が「ブラックボックス」過ぎてよく分からない...
Azure Application Gatewayの構築作業でやること多い件
公式のドキュメントによると、
Azure Application Gateway とは
Azure Application Gateway は、Web アプリケーションに対するトラフィックを管理できる Web トラフィック (OSI レイヤー 7) ロード バランサーです。 従来のロード バランサーはトランスポート レイヤー (OSI レイヤー 4 - TCP と UDP) で動作し、送信元 IP アドレスとポートに基づくトラフィックを送信先 IP アドレスとポートにルーティングします。
https://learn.microsoft.com/ja-jp/azure/application-gateway/overview
Application Gateway では、URI パスやホスト ヘッダーなど、HTTP 要求の追加属性に基づいてルーティングを決定できます。
https://learn.microsoft.com/ja-jp/azure/application-gateway/overview
この種類のルーティングは、アプリケーション レイヤー (OSI レイヤー 7) の負荷分散と呼ばれます。 Azure Application Gateway は URL ベースのルーティングなどを行うことができます。
https://learn.microsoft.com/ja-jp/azure/application-gateway/overview
⇧ 上記の説明によると「OSI参照モデル」で言うところの「第7層」に該当するようだ。
⇧ 上図にあるように、「主なプロトコル」で「HTTP」とあることから、「Azure Application Gateway」は「OSI参照モデル」で言うところの「第7層」を対象としているようだ。
で、「Terraform」による「Azure Application Gateway」の作成の手順を見た感じ、
⇧ 上記が標準的な構成なのかが分からないのだが、作業が盛り沢山な感はある。
で、残念ながら、「Terraform」による「Azure Application Gateway」の作成のサンプルだと、「TLS/SSL 証明書」の話、所謂「HTTPS」化の部分が触れられていない...
どうやら、
チュートリアル: Azure portal を使用して TLS 終端でアプリケーション ゲートウェイを構成する
Azure portal を使用して、バックエンド サーバーに仮想マシンを使用する TLS ターミネーションの証明書で、アプリケーション ゲートウェイを構成することができます。
https://learn.microsoft.com/ja-jp/azure/application-gateway/create-ssl-portal
⇧「自己署名証明書」は「TLS/SSL 証明書」のことだと思うのだが、作成する必要があるようなのだが、「チュートリアル」にするのではなく、「Azure Application Gateway」の構築のための正式な「手順」として確立して欲しいのだが...
で、「TLS/SSL 証明書」の「有効期限」とかが分からないのだが、
リスナーの TLS 証明書の管理
Application Gateway のリスナーの TLS/SSL 証明書は、ゲートウェイでクライアント TLS 接続を終了するために使用されます。 この機能は、クライアント/ブラウザーからの TLS/HTTPS 接続をサポートするために Web サーバーに証明書をアップロードすることに似ています。
https://learn.microsoft.com/ja-jp/azure/application-gateway/quick-create-terraform
⇧ 上記でも「TLS/SSL 証明書」の「有効期限」についての記載が見当たらない...
まぁ、毎度のことながら、「Microsoft Azure」のドキュメントは「ファインダビリティ（Findability）」の欠片も無いのだが、いつになったら整理されるんだろうか...
「AI」の性能が向上しても、改善される日は未だ遠いということなんですかね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
