2026/03/09 6:56

検知は保護ではない：WAF の検知モードが行うことと、できないこと --- 備考 - 「Detection Is Not Protection」は「検知は保護ではない」と直訳し、意味を明確にしました。 - 「What WAF Detection Mode Does (and Doesn’t)」は「WAF の検知モードが行うことと、できないこと」に訳し、専門性と読みやすさを両立しています。

RSS: https://news.ycombinator.com/rss

要約▶

Japanese Translation:

Azure Web Application Firewall（WAF）はデフォルトでDetectionモードで作成され、マッチしたルールは「Block」としてログに記録されますが、バックエンドにはまだ到達します。パイプラインチェック（ボディ解析失敗やサイズ制限違反）のみが真にブロックされ、OWASP Top 10 の保護を実現するにはPreventionモードが必要です。Prevention では異常スコア ≥ 5 を持つリクエストがアプリケーションへ到達する前にブロックされます。

Microsoft は Detection モードで数週間の調整期間を推奨しますが、Prevention への切替えを強制するタイマーやアラートは提供していないため、多くのチームが Detection を離れません。これにより誤った安全感が生まれます：ログでは「Block」操作が記録され、

action_s == "Block"

のみでフィルタリングした SIEM クエリが実際の脅威を過大評価し、コンプライアンスツールはモードを検証せずに「WAF 有効」と報告するため、PCI DSS チェックは満たされるものの保護は提供されません。

Azure は Application Gateway と Front Door で Prevention を強制するポリシー定義を提供していますが、採用例はほとんどありません。単純な Resource Graph クエリ（

mode != "Prevention"

）を実行すると、サブスクリプション全体の Detection モードに残っているすべての WAF ポリシーを棚卸しでき、内部サービスが脆弱であるギャップを明らかにします。

本文

WAFが有効になっているのに、ダッシュボードは緑色で、アプリケーションへのすべての攻撃がそのままバックエンドへ届く――なぜですか？

Azure 環境のどこかに、デフォルト設定として Detection（検知）モード にある WAF ポリシーが存在している可能性があります。
誰かが明示的にその呼び出しを行ったわけでもなく、受動的観測を必要とするアクティブなインシデントもないのに、単に「デフォルト」だからです。チューニングには時間が掛かり、会話を閉じるような強制は一切ありません。

実際にリクエストに起こること

Detection モードで動作する WAF エンジンは以下の処理を行います：

すべてのリクエストを完全管理ルールセットと照合し、異常スコア（デフォルトでは OWASP 異常スコアリング）を算出します。
Prevention（防止）モード – スコアが5以上になるとブロックし、WAF は 403 を返して接続を閉じます。リクエストはバックエンドに届きません。
Detection モード – 同じスコアでログを書き込み、マッチしたルールを記録しますが、その後リクエストは変更せずにアプリケーションへ転送されます。攻撃者は通過します。

検知モードでも、ボディ解析失敗やサイズ制限などの必須ルールでブロックされるケースはありますが、これは「配管行動」であり OWASP Top 10 の脅威をカバーするセキュリティ制御ではありません。

罠を設定しているデフォルト

Azure の新規 WAF ポリシーはすべて Detection モードで初期化されます。Microsoft は「検知から始め、実際のトラフィックを観測し、誤検出を除外してから防止へ移行する」ことを推奨しています。
しかし:

WAF が検知モードに留まった時点でトリガーされるタイマーやアラート、Azure Policy のゲートは存在しません。
チューニングループには正式な終了基準がなく、実際には終わりません。

このパターンは繰り返されます：検知モードでデプロイ → アラートをレビュー → 除外設定 → アラート量減少 → 次の優先事項へ。
ループは閉じられず、検知モードは「意図しない」結果として永続化します。

検知モードは攻撃が成功しているかどうかを示すシグナルを持たず、検知モードと防止モードの WAF は「ブロックされたトラフィックからユーザーへの影響ゼロ」という同一指標で見たときに区別できません。
静寂は何も証明しないのです。

チームは WAF アラートを無視するようになり、二次的な問題が生じます。すべてがログに残るもののブロックされず、アラートには運用上の意味がなくなるため、数か月後に防止モードへ切り替える際に「誤検出で実際にユーザー影響を与えているケース」を扱うチャンネルが機能しない状態になってしまいます。

誤解させるログ

Detection モードで WAF ルールにマッチしたリクエストのログは次のようになります:

action_s     : Block
policyMode_s : Detection
ruleName_s   : DefaultRuleSet-1.0-SQLI-942430

合理的なエンジニアは「Block」と読み、リクエストがブロックされたと結論付けます。しかし実際には action_s = "Block" は「防止モードであればこうなる」という仮想結果 を示すだけです。リクエストはバックエンドに到達しています。

Microsoft の公式ドキュメントでもこのログ構成をサンプルとして示しつつ、誤読を防ぐ十分な強調が欠けています。

結果:

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"
| where action_s == "Block"

というクエリは、実際には「アプリケーションへ到達したリクエスト」を返します。構文自体は正しいが解釈を誤っています。

修正方法

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"
| project TimeGenerated,
          RuleID   = ruleName_s,
          Action   = action_s,
          Mode     = policyMode_s,
          ClientIP = clientIp_s,
          URI      = requestUri_s
| where Action == "Block" and Mode == "Prevention"

必ず

policyMode_s

をプロジェクトし、明示的にフィルタリングしてください。
防止モードでの Block は何かが停止されたことを意味し、検知モードでの Block は「観測して通過した」だけです。ダッシュボードやアラートルールで同一イベントとしてカウントすべきではありません。

SIEM 連携規則、Sentinel 分析、セキュリティダッシュボードが

policyMode_s

をフィルタリングせずに構築されている場合、「ブロックされた攻撃」数は実際にはブロックされなかったケースを含む可能性があります。

なぜ誰も気づかないのか

セキュリティ姿勢ツール は「WAF が有効」かどうか（リソースにポリシーが紐付いているか）だけを報告します。モード、診断設定の有無（検知モードでは完全に可視化されません）、実際にトラフィック経路上で動作しているかは言及しません。
ほとんどのコンプライアンスレビューは存在確認に留まり、
```
policyMode_s
```
を尋ねることはありません。
PCI DSS 要件 6.4 はインターネット向けアプリケーションに対する WAF 保護を求めますが、評価では「WAF があるか？」のみをチェックし、ブロックしているかどうかは別問題で、通常尋ねられません。
Azure には「Application Gateway」「Front Door」に対し指定モードを要求する 2 つの組み込みポリシー定義があります。これらはほとんど環境で未使用です。

解決策

ログ設定に依存しないインベントリ を作成します:

Resources
| where type == "microsoft.network/frontdoorwebapplicationfirewallpolicies"
       or type == "microsoft.network/applicationgatewaywebapplicationfirewallpolicies"
| project name, resourceGroup, subscriptionId,
          mode = properties.policySettings.mode
| where mode != "Prevention"

これで「防止モードにない」WAF ポリシーを正確に把握できます。

スコープが分かったら:
1. チューニング期限 を設定（例：代表的トラフィックを持つ安定アプリなら 2〜4 週間）。
2. その期間中は毎日ログをレビュー。
3. 除外ルールはコード化（Bicep/Terraform）し、管理ルールセットバージョンアップ時にも継続できるようにします。
4. 防止モードへ切り替える際には正当なリクエストがブロックされることを想定し、実行手順書（何がブロックされたかを照会し、対象除外を作成するプロセスと承認者）を用意します。
その後 Azure Policy の組み込みポリシー を有効化。新規デプロイ時に防止モードでない場合は拒否させます。
コンプライアンスダッシュボードへ統合し、「WAF: 有効」＝「実際に保護が機能している」を意味するようにします。

名称の問題

Detection（検知） は「何かを捕捉した」という印象を与えます。
実際には「検出されたものはただ記録されるだけ」で、攻撃が通過したままです。
もしこのモードを **Logging（ログ）」と呼べば、エンジニアは本来の一時的診断状態として扱いやすくなります。「検知」という語が「脅威が識別され対処されている」という誤解を招き、保護があると思い込ませる原因となっています。

最後に

プロダクション環境で WAF が Detection モード のまま 1 か月以上経過している場合、アプリケーションは実質的に保護されていません。
攻撃の詳細ログは残りますが、何も遮断しない状態です。これを今日修正する価値があります。

現在 WAF ポリシーのモードはどう設定されていますか？
確認には約 30 秒で完了します。答えに驚くこともあるでしょう。

同じ日のほかのニュース

一覧に戻る →

2026/03/09 5:30

エージェント・セーフハウス – macOS ネイティブサンドボックスによるローカルエージェントの保護 --- **ポイント解説** - **Agent Safehouse** は、macOS 上で動作するローカルエージェント（バックグラウンドプロセスやサービス）を安全に隔離し、外部からの不正アクセスや権限昇格を防ぐための仕組みです。 - 「macOS‑native sandboxing」は、Apple が提供するサンドボックス機能（`sandbox-exec`, `com.apple.security.*` など）を利用しており、追加のソフトウェアやカーネル拡張は不要です。 **主な特徴** 1. **最小権限で実行** – 必要最低限のファイル・ネットワークアクセスのみ許可し、それ以外は自動的にブロック。 2. **監査ログ** – アクセス試行や失敗がすべて記録され、後からトラブルシューティングやセキュリティ調査に利用可能。 3. **設定の柔軟性** – プロファイルベースでポリシーを定義でき、企業規模に合わせた細かな制御が可能。 **実装例（サンドボックスプロファイル）** ```xml <key>com.apple.security.app-sandbox</key> <true/> <key>com.apple.security.files.user-selected.read-write</key> <true/> ``` このように、エージェント・セーフハウスは macOS の標準機能だけで安全性を大幅に向上させるソリューションです。

## Japanese Translation: > Safehouse は、ローカル AI エージェントがアクセスできるファイルを厳密に制御する軽量な macOS ネイティブサンドボックスです。デフォルトでは「deny‑first」ポリシーに従い、指定されたワークスペース外への読み書き試行はカーネルエラー（“Operation not permitted”）を引き起こし、SSH キーや `.aws` などの機密項目やその他個人リポジトリを保護します。ツールは `curl` を使って `~/.local/bin` にインストールされる単一の Bash スクリプト（`safehouse.sh`）でセットアップされます。 > > エージェントは `safehouse claude --dangerously-skip-permissions` のようなコマンドで呼び出され、現在の作業ディレクトリ（通常は git リポジトリルート）への読み書きアクセスを自動的に許可し、インストール済みツールチェーンへの読み取りアクセスのみを許可して残りのホームディレクトリは拒否します。 > > 上級ユーザーは `safe() { safehouse --add-dirs-ro=~/mywork "$@"; }` のようなシェル関数を `.zshrc` や `.bashrc` に追加し、すべてのエージェント呼び出しがデフォルトで Safehouse 内で実行されるようにできます。セッションごとにサンドボックスをバイパスするには、コマンドに文字列 `command` を接頭辞として付けます（例：`command claude`）。 > > このゼロコンフィグ方式により、開発者やチームはローカルファイルとの AI 連携を安全に行い、個人プロジェクト、クラウド認証情報、企業リポジトリでの偶発的なデータ漏洩を減らすことができます。

2026/03/09 6:40

**ブラックスカイ・AppView**

## Japanese Translation: Blacksky の AppView は Bluesky Social PBC の AT Protocol 参考実装をフォークしたもので、**外部からの貢献やプルリクエストは受け付けません**。すべての変更は `packages/bsky`、`services/bsky` の3つのディレクトリと1つのマイグレーションファイルに限定され、参考コードの大部分を保持しています。リポジトリは組み込みの TypeScript フィーホーズコンシューマーを Rust ベースのインデクサ **rsky‑wintermute** に置き換えており、並列キューを通じて約10 k+ レコード/秒を取り込むことができます。Wintermute はブートストラップツール（`queue_backfill`、`direct_index`、`label_sync` など）を提供し、ライブインデクシングとバックフィルを分離します。主なパフォーマンス最適化は次の通りです： - PostgreSQL の LATERAL JOIN 再書き込み（`getTimeline` / `getListFeed` 用） - Redis キャッシュレイヤー（アクタープロファイル TTL 60 s、レコード TTL 5 m、相互作用カウント TTL 30 s、投稿メタデータ TTL 5 m） - 通知設定のサーバー側強制実装された修正： - JWT 検証における古い署名鍵の処理 - JSON のサニタイゼーションで null バイト／制御文字を除去 - アクターメモリキャッシュ内の protobuf タイムスタンプバグへの対策 Blacksky は **コミュニティ投稿サポート** をカスタムレキシコン namespace（`community.blacksky.feed.*`）と専用 `community_post` テーブル、データプレーン/API 層でのメンバーシップゲーティングを通じて追加しています。これは混在した投稿スレッド（`getPostThreadV2`）とも統合されます。全体アーキテクチャフロー： Bluesky Relay → rsky‑wintermute（フィーホーズコンシューマ/バックファラー/ラベルインデクサ） → PostgreSQL 17 → bsky‑dataplane（gRPC） → オプションの Redis キャッシュ → bsky‑appview（HTTP） → リバースプロキシ、Palomar が OpenSearch 検索機能を提供バックフィル性能：ライブインデクシングは約1 k イベント/秒。42 M ユーザーと 18.5 B レコードのフルバックフィルは10 k レコード/秒で 2–4 週間、部分的なバックフィルは数時間〜数日で完了ブートストラップ課題への対策： - PostgreSQL COPY による JSON 腐敗 - null バイト処理 - タイムスタンプ精度の強制 - 通知テーブルの肥大化緩和 - 投稿埋め込みテーブルの人口化 - ラベル否定順序 - Fjall キュー毒性解決 - TLS プロバイダ初期化 - アカウント移行後の署名鍵回転 **フルネットワーク AppView のリソース要件：** ≥ 16 CPU コア（推奨 48+）、≥ 64 GB RAM（256 GB 推奨）、10 TB NVMe ストレージ（28 TB RAID 推奨）、同一マシンまたは低遅延での PostgreSQL、継続的ネットワーク 100 Mbps（1 Gbps+）以上の取り込み帯域リポジトリは MIT/Apache 2.0 のデュアルライセンスです。アップストリーム同期手順は `git remote add upstream https://github.com/bluesky-social/atproto.git` で提供されています。

2026/03/09 4:58

「エージェント時代にリテラトープログラミングを見直すべきです。」

## Japanese Translation: > 本稿は、コードと説明文を組み合わせたリテラトープログラミングが、AI エージェント（例：Claude や Kimi）が Org‑Mode ファイルを単一の真実源として扱う場合に実用化できることを主張しています。 > > Org の構文を解析することで、これらのエージェントはランブックを生成し、埋め込みコードブロックを実行し、Jupyter ノートブックのように結果を保存し、プローズとコードを同期して自動的に更新できるため、ナラティブと実行可能なスクリプトを分離する手作業「タンギング」ステップが排除されます。 > > 著者は、Org Mode を設定管理に個人的に使用した例でこれを示しています：エディタ内で直接コマンドを書き込み、それらを実行し、メモを自動的に取得します。 > > コードとプローズの2つの並列文書を維持することは採用への一般的な障壁ですが、AI 主導のワークフローは `AGENTS.md` ファイルに記載された指示（実行前のタンギング、常にステップを説明するプローズ、両側を同期させる）に従うことでそのオーバーヘッドを排除します。 > > このアプローチはワークフローを合理化し、コードベースを複数の読みやすいフォーマットへエクスポートしやすくし、「コードを書く」から「コードを読む」へのシフトを促進します。また、大規模プロジェクトにおける Org‑Mode の Emacs 統合の限界を浮き彫りにし、リテラトープログラミングの普及を広げるために Markdown などの類似フォーマットを推奨することも示唆しています。