
膨大なネットコンテンツの収集・保存を行っているインターネットアーカイブが、これまでに保存したウェブページの数が1兆件に到達したことを明らかにしました。
インターネットアーカイブは、学者・歴史家・研究者らにインターネット上のコンテンツへの永続的なアクセスを提供することを目的として、1996年から活動している非営利団体です。ニュース速報のようなものから小規模な個人サイトまで、収集コンテンツの対象は幅広く、保存されたウェブページは「Wayback Machine」機能で誰でも閲覧することが可能です。
⇧ 今が、2025年なので、1996年から29年が経っていることになるのだが、年毎の「保存したウェブページ」の数の推移を統計してグラフ化して欲しいですな。
Azure CLIにおけるWAF ポリシーの関連付けの解除が分かり辛過ぎる話
「Microsoft」の公開している「Azure CLI」のドキュメントを読んでいて、
⇧ とありますと。
とりあえず、
| 名前 | 説明 | 型 | 状態 |
|---|---|---|---|
az network application-gateway waf-policy |
Application Gateway Web アプリケーション ファイアウォール (WAF) ポリシーを管理します。 | Core | GA |
⇧「WAF(Web Application Firewall)ポリシー」に関連する「情報」の操作を集約していると思うじゃろ?
然に非ず...
公式のドキュメントで「Azure Web アプリケーション ファイアウォール (WAF) ポリシーの概要」のページの内容を確認してみる。
Azure Web アプリケーション ファイアウォール (WAF) ポリシーの概要
Web アプリケーション ファイアウォール ポリシーには、すべての WAF 設定と構成が含まれています。 これには、除外、カスタム ルール、マネージド ルールなどがあります。 これらのポリシーは、アプリケーション ゲートウェイ (グローバル)、リスナー (サイトごと)、またはパスベースのルール (URI ごと) に関連付けられ、有効になります。
https://learn.microsoft.com/ja-jp/azure/web-application-firewall/ag/policy-overview
作成できるポリシーの数に制限はありません。 ポリシーを作成した場合は、アプリケーション ゲートウェイに関連付けて有効にする必要があります。 アプリケーション ゲートウェイ、リスナー、およびパスベースのルールの任意の組み合わせと関連付けることができます。
https://learn.microsoft.com/ja-jp/azure/web-application-firewall/ag/policy-overview
⇧ 上記にあるように、「関連付け」には、
- アプリケーション ゲートウェイ
- リスナー
- パスベース ルール
の3つが用意されているらしい。
英語版のドキュメントも確認してみる。
There's no limit on the number of policies you can create. When you create a policy, it must be associated to an application gateway to take effect. It can be associated with any combination of application gateways, listeners, and path-based rules.
https://learn.microsoft.com/en-us/azure/web-application-firewall/ag/policy-overview
⇧ とありますと。
ドキュメント的には、
| No | 機能 | 関連付け(associated) |
|---|---|---|
| 1 | Global WAF policy | application gateways |
| 2 | Per-site WAF policy | listeners |
| 3 | Per-URI policy | path-based rules |
⇧ 上記のような関係らしい。
で、「関連付け(associated)」については、
⇧ 上記のような質問が上がっている。
で、
⇧ 上記サイト様によりますと、
- アプリケーション ゲートウェイ
- 「関連付け」の解除はできない。別のWAFポリシーと置き換えは可能。
- リスナー
- 「関連付け」の解除できる。
- パスベース ルール
- 「関連付け」の解除できる。
ということらしい。
で、公式のドキュメントには、「Azure CLI」による「関連付け」の解除で利用するコマンドについての言及が無いという...
「ChatGPT」氏に質問してみたところ、以下の回答が返ってきた。
■「WAF(Web Application Firewall)ポリシー」の「関連付け」の解除
■■アプリケーション ゲートウェイ(application gateways)の場合
■■解除はできない。別の「WAF(Web Application Firewall)ポリシー」と置き換えしかできない。
az network application-gateway waf-policy update \ --gateway-name <Application-Gateway-Name> \ --resource-group <Resource-Group-Name> \ --policy-name <WAF-Policy-Name>
■「WAF(Web Application Firewall)ポリシー」の「関連付け」の解除
■■リスナー(isteners)の場合
■■解除できる。
az network application-gateway http-listener update \ --gateway-name <Application-Gateway-Name> \ --resource-group <Resource-Group-Name> \ --name <Listener-Name> \ --waf-policy ""
■「WAF(Web Application Firewall)ポリシー」の「関連付け」の解除
■■パスベース ルール(path-based rules)の場合
■■解除できる。
az network application-gateway url-path-map rule update \ --gateway-name <Application-Gateway-Name> \ --resource-group <Resource-Group-Name> \ --name <Rule-Name> \ --default-backend-addresses <Backend-Address> \ --waf-policy ""
⇧ といった感じらしい。
動作確認してみないと、「AI」の回答が
- 幻覚(ハルシネーション)
- 正解
のどちらなのかが判断が付かないのだが、そもそも、「Microsoft」のドキュメントが酷過ぎるのよな...
結局、動作確認を繰り返さないと分からないって、全くもって「ユーザーフレンドリー」とはかけ離れた「サービス」ですな...
ちなみに、
⇧ サンプルも中途半端な感じでして、後進もされていなさそうなのよね...
ドキュメントが酷い分、サンプルが充実しているかというと、然に非ず。
最低限の「CRUD(Create, Read, Update, and Delete)」は、サンプルで公開していて欲しかったのだが、サンプルは「Create」ばっかりなのよね...
「ユーザー」のことを全く考慮してくれていないという...
誠に遺憾である...
あと、「Azure CLI」は「Azure Portal」に付属している「Azure Cloud Shell」以外で実施する場合は、最初に「az login」などで「認証・認可」を実施する必要があると思うのだが、不親切なことに、サンプルの「GitHub」の「README.md」には記載が無いのよね...
一体全体、誰のためのサンプルなのか...
内輪でしか利用しないというならば、文句は無いのだが、一般に公開されている状態なので、情報を端折らないで欲しいのよな...
2025年10月8日(水)追記:↓ ここから
職場の方に連携してもらい、
⇧ 上記の「プロパティ」を削除して、「update」するのが正しそう。
⇧ とりあえず、「プロパティ」の一覧を確認できるドキュメントを用意して欲しいのだが...
そもそも、「WAF(Web Application Firewall)ポリシー」の「関連付け」で、「プロパティ名」が「firewallPolicy」なのも納得いかないんだが...
「webFirewallPolicy」にすべきでしょうに...
まだ、動作確認できていないので、期待した通りの動作をしてくれるのか分からないのですが...
2025年10月8日(水)追記:↑ ここまで
2025年10月9日(木)追記:↓ ここから
2025年10月8日(水)に追記した方式で動作しました。
「AI」の回答は「幻覚(ハルシネーション)」だったということです...
ストレスが半端ないんだが...
とりあえず、
オープンソースで開発されている「curl」コマンド(以下cURL)のバグ報奨金プログラムに、AIを用いて作成されたいい加減なバグレポートが殺到した結果、開発者であるDaniel Stenberg氏が「もう限界に達した」「事実上、DDoSを受けているようなものだ」と訴えています。
AIによる無効なバグレポートが、Curlのバグ報奨金プログラムに殺到。「事実上、DDoS攻撃を受けているようなものだ」と開発者が訴え - Publickey
そして今後はバグレポートの作成者に対して、レポート作成にAIを用いたかどうかを回答するよう義務付けることを明らかにしました。
AIによる無効なバグレポートが、Curlのバグ報奨金プログラムに殺到。「事実上、DDoS攻撃を受けているようなものだ」と開発者が訴え - Publickey
⇧ 上記のような状況は発狂しても不思議でないですな...
2025年10月9日(木)追記:↑ ここまで
毎度モヤモヤ感が半端ない…
今回はこのへんで。



