manage-firewall

プラグインの確認：node "${PLUGIN_ROOT}/scripts/check-version.js" を実行します。メッセージが出力された場合は、先にユーザーに表示してください。

Web アプリケーションファイアウォールを管理する

Power Pages の本番サイトのファイアウォールを構成します。ファイアウォールは本番サイトかつサポート対象のリージョンでのみ利用できます。スクリプトが利用条件を確認し、問題を報告します。ルールの変更後、エッジへの反映には最大 1 時間かかります。

初期リクエスト： $ARGUMENTS

注意点

• Web サイトレコード ID とポータル ID。 .powerpages-site/website.yml に保存されているのは Web サイトレコード ID であり、ポータル ID ではありません。すべてのスクリプトで --portalId を指定します。前提条件の確認中に website.js --websiteId を使って一度だけ解決してください。
• 名前で解決しないでください。 サイト名は重複する場合があるため、安全に使えるのは Web サイトレコード ID のみです。
• 非同期操作。 enable.js と disable.js は、ステータスが目標値に達するまで（またはタイムアウトするまで）ポーリングします。delete-rules.js は直ちに（202）返します。get-rules.js で確認してください。
• 同時操作のガード。 B003 は、別の有効化／無効化処理が進行中であることを示します。ステータスが確定するまでポーリングしてから、再試行してください。
• 誤検知されたマネージドルール： ルールのオーバーライドで無効にします（RuleGroupOverrides 内で EnabledState: "Disabled" を指定します。マネージドルールのフィールドでは PascalCase を使用します）。
• 優先順位が先のルールが適用されます。 ルールは優先順位順に評価されます。地域の許可後にデフォルトで拒否するパターンには、許可ルールの後に明示的なデフォルト拒否ルールが必要です。
• カスタムルールの優先順位の範囲：11～65000。 1～10 はプラットフォーム管理ルール用に予約されています。
• set-rules.js は追加／更新のみです。 作成または変更するルールのみを送信してください。サービスがそれらをマージするため、ペイロードに含まれない既存のルールは変更されません。
• ルールの削除には delete-rules.js を使用してください。 set-rules.js では削除できません。必ず delete-rules.js --names を使用してください。
• WAF の状態の意味 — 「有効」を示す状態は Created のみです。 ファイアウォールが有効で、実際にフィルタリング中の場合、get-status.js は value: "Created" を返します（直感に反しますが、API は "Enabled" を使用しません）。それ以外の値（Disabled、None、Enabling、Disabling、Failed）の場合、アクティブなポリシーは存在しません。まず 必ず get-status.js を呼び出し、value が Created の場合にのみ get-rules.js を呼び出してください。それ以外の場合、ルールのエンドポイントは 500 を返し、レポートのファイアウォールセクション全体がスキップされます。

ワークフロー

1. 前提条件 — プロジェクトを特定し、サインインを確認して、サイトを識別し、利用条件を確認します
2. ファイアウォールの状態を確認 — 状態とルールを記録します
3. アクションを選択 — 状況に応じた推奨または質問を提示します
4. 変更を適用 — 対応するスクリプトを実行して確認します
5. 結果と次のステップを要約 — 結果を提示し、使用状況を記録して、追加の対応を提案します

タスクの追跡

3 つのグループでタスクを作成します。各タスクは開始時に in_progress、完了時に completed にします。

グループ	作成するタイミング	タスク
1	開始時	前提条件を確認
2	前提条件の確認後	ファイアウォールの状態を確認 · アクションを選択（レビュー モードではスキップ）
3	ユーザーがアクションを確認した後	変更を適用（レビュー モードまたは変更アクションが選択されなかった場合はスキップ） · 結果と次のステップを要約（常に実施）

---

1. 前提条件

1.1 プロジェクトの場所を特定し、レビュー モードを検出する

Glob を使用して **/powerpages.config.json を検索します。$ARGUMENTS に --review <out-dir> が含まれている場合は、出力ディレクトリを記録します。この場合、ステップ 3～4 はスキップされ、ステップ 5 では JSON のみが出力されます。

1.2 サイト識別子を解決する

.powerpages-site/website.yml を読み取り、id フィールドを抽出します。これが <WEBSITE_ID> です。

存在しない場合、サイトはデプロイされていません。その旨をユーザーに伝え、/deploy-site を推奨します。停止してください。名前や URL で解決してはいけません。

portalId に解決します。

node "${PLUGIN_ROOT}/scripts/website.js" --websiteId "<WEBSITE_ID>"

Id（portalId）、Type、Name、WebsiteUrl を取得します。終了コードが 2 の場合は、サインインが必要です（pac auth create または az login）。null の場合は、この環境でサイトが見つかりません。どちらの場合も停止してください。

1.3 対象条件

対象条件を確認するには、Type フィールドとスクリプトの応答を確認してください。スクリプトは、対象外のサイト（本番環境ではない、サポートされていない地域、機能制限あり）に対して特定のエラーコードを返します。全一覧については、references/commands.md の「Common error catalogue」と「Regional availability」を参照してください。

サイトが対象外の場合は、制限の内容をわかりやすい言葉でユーザーに伝え、終了してください。

---

2. ファイアウォールの状態を確認する

2.1 状態を取得する（必ず最初に実行）

node "${PLUGIN_ROOT}/skills/manage-firewall/scripts/get-status.js" --portalId "<PORTAL_ID>"

応答の形式は { "status": "ok", "value": "<state>" } です。

• Created — WAF が有効で、フィルタリングしています。ルールを取得するには 2.2 に進んでください。
• それ以外の値（Disabled、None、Enabling、Disabling、Failed など）— WAF は有効ではありません。get-rules.js を呼び出してはいけません。読み取れるアクティブなポリシーが存在しないため、ルールのエンドポイントは 500 を返します。2.2 をスキップし、ルールのペイロードを空として扱ってください：{ "status": "ok", "body": { "CustomRules": [], "ManagedRules": [] } }。

状態の応答が "status": "unsupported" の場合は、ファイアウォールを利用できないことをユーザーに伝え、終了してください。

2.2 ルールを取得する（WAF が有効な場合のみ）

node "${PLUGIN_ROOT}/skills/manage-firewall/scripts/get-rules.js" --portalId "<PORTAL_ID>"

両方のスクリプトは、完全な応答を JSON として stdout に出力します。get-rules.js が "status": "unsupported" を返した場合は、ファイアウォールを利用できないことをユーザーに伝え、終了してください。

---

3. アクションを選択する

レビュー モードではスキップしてください。

ユーザーには平易な言葉だけを使ってください。WAF、OWASP、ModSec、ルールセット、地域ブロック、レート制限、ASN、SocketAddr、ルールの優先順位などの言葉は使わないでください。

AskUserQuestion の呼び出しはそれぞれ個別の呼び出しです。次に質問する前に、ユーザーの回答を待ってください。

デフォルトのアプローチ

🚦 ゲート（plan · manage-firewall:3.action-choice）： サイトの現在の状態に基づいてアクションを推奨し、ユーザーにその案を受け入れるか、別のアクションを選ぶか尋ねます。フェーズ 3 に入るたびに一度実行されます。フェーズ 4 で最初の変更を適用した後、ユーザーが追加の変更を希望する場合は、ここに戻ります。

トリガー： フェーズ 3 への移行（対話モードのみ。レビュー モードではスキップ）。 質問する理由： ファイアウォールの誤った変更は、サイトを訪れるすべてのユーザーに影響します。同意を得ずに自動で推奨すると、作成者が意図的に追加した有効なルールを無効にするおそれがあります。 キャンセル後の状態： 変更なし — フェーズ 4 はまだ実行されていません。

サイトの現在の状態（ファイアウォールの状態、既存のカスタムルール、マネージドルール、地域の対象条件）を分析し、最も関連性の高いアクションを 1 つだけ推奨してください。AskUserQuestion で推奨内容を提示してください。

• ファイアウォールがオフの場合 → 有効化を推奨します。
• ファイアウォールがオンで、カスタムルールがない場合 → 明確な不足（例：レート制限がない）があれば、ルールの追加を推奨します。そうでなければ、状態を要約し、ルールを追加するかユーザーに尋ねます。
• ファイアウォールがオンで、ルールが存在する場合 → 設定内容を要約し、何をしたいかユーザーに尋ねます。

サイトの状態から具体的な推奨が妥当でない場合は、無理に推奨せず、ユーザーが何をしたいか尋ねてください。

セキュリティを低下させるアクション（ファイアウォールの無効化、マネージドルールの削除、既存ルールの弱体化）を先回りして提示してはいけません。ユーザーがそれらを必要とする場合は、自分から尋ねます。

オプションのルール

AskUserQuestion でオプションを提示する場合：

• label は1～5語にしてください。すべてのオプションに description を含めてください。
• オプションが具体的な変更（ルールの作成、更新、削除）を表す場合に限り、preview を含めてください。適用される設定を示し、承認前にユーザーが確認できるようにします。ナビゲーションや情報提供の選択肢には preview を追加しないでください。
• 現在の状態で実行可能なオプションだけを表示してください。サイトで利用できない機能のオプションは省略してください（references/commands.md §「地域別の利用可否」を確認してください）。
• 「（推奨）」を付けるのは、状況に即した明確な理由がある場合に限ります。特に目立つ選択肢がない場合は、何も付けないでください。
• サイトにすでに存在する種類のルールの追加を提案する場合は、description でその旨に触れてください。件数と現在の設定内容の概要を含め、ユーザーが追加するか更新するかを判断できるようにします。
• パスベースのルールでは、判明している場合はプロジェクト構成にある実際のページパスを参照してください。プロジェクトのコンテキストがない場合に限り、一般的な表現を使用してください。

ルールタイプの追加質問

ユーザーが「ルールを追加」を選んだ場合は、続けてルールの種類を尋ねてください。同じオプションルールを適用します。回答を set-rules.js のパラメーターに変換し、優先順位の番号付けやルール名の詳細にユーザーを関与させないでください。ルールの形式については references/rule-reference.md を参照してください。

ルールの削除

現在のカスタムルールを一覧表示し、それぞれについて、ルールの動作（平易な言葉での説明）、対象となるトラフィック、ブロックするか許可するか、ほかのルールとの優先順位を示してください。ルールの削除によって拒否／許可のパターンが崩れる場合は、実行前に警告してください。

計画・検証・実行

🚦 ゲート（同意 · manage-firewall:3.execute-consent）： 破壊的なWAF変更（有効化／無効化、ルールの追加／更新／削除）を実行する前の最終同意です。提案するJSONペイロードと、提示された検証上の問題を再掲します。変更ごとに実行されます。有効化、無効化、ルールの追加、ルールの更新、ルールの削除は、それぞれ個別の同意が必要です。

トリガー： フェーズ3のアクションが選択され、計画と検証結果が提示されたとき。 確認する理由： ファイアウォールの変更は環境レベルで行われ、すべてのサイト訪問者に影響します。自動適用すると、正当なトラフィックを締め出したり、保護を弱めたりするおそれがあります。 キャンセル時： 何も起こりません。API呼び出しはまだ実行されておらず、計画と検証結果は破棄されます。

すべてのルール変更について：

1. 計画 — 追加または更新するルールだけを含むJSONペイロードを作成します。
2. 検証 — 既存のルールセットに照らして計画を確認し、次の点を提示します。
   • 既存ルールとの優先順位の競合
   • 条件の重複（同じ matchVariable／operator で、matchValue が重複するもの）。first-match-wins によってどのルールが優先されるかを説明します。
   • 許可ルールとブロックルールの矛盾。優先順位への影響を指摘して説明します。
   • 冗長性。重複ルールの追加ではなく、既存ルールの更新を提案します。
3. 実行 — AskUserQuestion を介してユーザーの承認を得た後にのみ適用します。

削除の場合は、続行する前にルール名と現在の動作を提示してください。

レビュー モードでは、このステップをすべて省略します。

4. 変更を適用する

レビュー モードではスキップします。

アクション	スクリプト
有効化	enable.js --portalId <id>
無効化	disable.js --portalId <id>
ルールの追加／更新	set-rules.js --portalId <id> --data-inline '<json>'
ルールの削除	delete-rules.js --portalId <id> --names <comma-separated>

有効化／無効化は run_in_background: true で実行します（ポーリング機能が組み込まれた非同期操作）。

適用する前に、実行するアクションに関連する説明のみを示します。

• 有効化： 管理対象ルールセットは直ちに適用されます。確認が済むまで、一部の正当なリクエストがブロックされることがあります。
• 無効化： 再度有効化するまで、サイトは保護されません。
• ルールの追加／更新： 反映には最大1時間かかります。ルールで Allow を使用する場合、ブロックルールが適用される状況でも例外が作成されることを説明します。
• ルールの削除： 該当するトラフィックはブロック（または許可）されなくなります。ルールが拒否パターン内の Allow 例外だった場合、今後はトラフィックがブロックされることを警告します。
• 管理対象ルールの無効化： その攻撃カテゴリは検査されなくなります。カテゴリ名を示します。

完了後、ステータスとルールの呼び出しを再実行し、新しい状態を確認します。

---

5. 要約と次のステップ

5.1 レビューモード

§ 2 と同じステータス確認後のルール取得制御を適用します。get-rules.js を呼び出してよいのは、ステータスの value が Created の場合のみです。それ以外の値では WAF ポリシーは存在せず、ルールエンドポイントは 500 を返します。オーケストレーターはスクリプトを呼び出す代わりに、空のルールペイロードを直接書き込む必要があります。

手順 A — 必ずステータスを取得します：

node "${PLUGIN_ROOT}/skills/manage-firewall/scripts/get-status.js" --portalId "<PORTAL_ID>" > "<REVIEW_DIR>/firewall-status.json"

手順 B — 取得した value に応じて分岐します：

• value が Created の場合は、ルールを取得します：

  node "${PLUGIN_ROOT}/skills/manage-firewall/scripts/get-rules.js" --portalId "<PORTAL_ID>" > "<REVIEW_DIR>/firewall-rules.json"
  

• それ以外（Disabled、None、Enabling、Disabling、Failed、その他すべて）の場合は、get-rules.js を呼び出さないでください。空のルールペイロードを直接書き込みます：

  { "status": "ok", "body": { "CustomRules": [], "ManagedRules": [] } }
  

生の出力を取得した後、両方のファイルを読み取り、状態と各ルールを平易な言葉で説明する <REVIEW_DIR>/firewall-annotations.json を書き込みます（変換スクリプトには説明がハードコードされなくなりました。説明はあなたが記述します）：

{
  "state": {
    "description": "Plain-language explanation of what \"<value>\" means — is the firewall actively filtering requests, or not?",
    "fix": "Optional — include only if the state genuinely needs action."
  },
  "rules": {
    "<RuleName>": { "description": "What this rule does, in plain language.", "fix": "Optional fix if the rule has a genuine issue." }
  }
}

Power Pages WAF の状態の意味（状態の説明を書く際に使用し、意味を独自に解釈しないでください）：

• Created — WAF は有効です。ファイアウォールが稼働し、リクエストをフィルタリングしています。
• Disabled — WAF は有効ではなく、ファイアウォールポリシーもありません。サイトは保護されていません。
• None — ファイアウォールポリシーが一度もプロビジョニングされていません。ユーザーにとっての意味は Disabled と同じです。
• Enabling / Disabling — 操作が進行中です。完了を待ちます。
• Failed — 直近の有効化／無効化操作に失敗しました。

次に、変換を実行します：

node "${PLUGIN_ROOT}/skills/manage-firewall/scripts/transform-firewall.js" \
  --statusFile "<REVIEW_DIR>/firewall-status.json" \
  --rulesFile  "<REVIEW_DIR>/firewall-rules.json" \
  --annotations "<REVIEW_DIR>/firewall-annotations.json"

変換処理の標準出力を <REVIEW_DIR>/manage-firewall.json に書き込み、終了します。変換処理は { status, findings } を出力します。プレゼンテーションはオーケストレーションを行うスキルが担当します。

5.2 要約を提示する

平易な言葉で要約します：ファイアウォールのオン／オフ、ルール数、変更内容、重要な不足点。

5.3 スキルの使用を記録する

参照先：${PLUGIN_ROOT}/references/skill-tracking-reference.md

--skillName "ManageFirewall" を使用します。

5.4 フォローアップを提案する

サイトの操作後の確認済み状態に基づいて自然なフォローアップ操作がある場合は、提案します。セキュリティを低下させる操作は提案しないでください。意味のあるフォローアップがない場合は、質問するためだけに質問せず、スキルを終了します。

---

制約

• 平易な言葉 — ユーザーに専門用語を使ってはなりません。日常的な言葉を使い、求められた場合にのみ専門用語を説明してください。
• 適格性 — 対象外のサイト（本番環境ではない、またはサポート対象外の地域）では、必ず処理を早期終了してください。スクリプトが対象外かどうかを検出します。エラーの一覧については、references/commands.md を参照してください。
• バックグラウンド操作 — 有効化と無効化は、必ず run_in_background を使って実行してください。
• 変更点のみを送信 — set-rules.js のペイロードには、新規または変更対象のルールのみを含めてください。
• ルールの命名 — PascalCase を使い、使用できるのは英字と数字のみです（例：BlockCountries、AllowOfficeIP）。
• 会社名の禁止 — ルールの例では、一般的な名称を使ってください。
• 状況を踏まえたやり取り — 質問、選択肢、追加の質問、開示内容はすべて、サイトの現在の状態を踏まえたものにしてください。
  • 該当しない選択肢を提示してはなりません（例：ルールが存在しない場合に「ルールを削除する」を提示する）。
  • 新しいルールの追加を提案する際は、同じ種類の既存ルールに言及してください。
  • プロジェクトで判明している場合は、説明の中でサイトの実際のページパスを示してください。
  • 計画を提示する前に、新しいルールと既存のルールとの競合、重複、矛盾、冗長性を確認してください。
  • 実施する操作に関係する開示のみを表示してください。
  • 保護を弱めることを先回りして提案してはなりません。
• プレビューは変更内容の確認専用 — ユーザーの承認が必要な具体的な変更を表す選択肢にのみ、preview を含めてください。ナビゲーションや情報提供の選択肢には追加しないでください。

参考資料

• references/commands.md — スクリプトのフラグ、応答形式、エラーの一覧、地域ごとの提供状況。スクリプトがゼロ以外の終了コードを返した場合は、「Common error catalogue」の節を参照してください。適格性の確認時には、「Regional availability」の節を参照してください。
• references/rule-reference.md — カスタムルール、照合条件、管理対象ルールの上書き、照合変数、演算子、優先度帯のフィールド単位のスキーマ。ルールの計画を作成する際に参照してください。