ファイアウォール（攻撃面）

概要 — 何をする画面か

セキュリティ ▸ ファイアウォール（/security/firewall）は、サーバー群が開けているすべてのポートを1枚の露出マップに描き出します。開放ポートをリスク別（crit / warn / ok / unknown）に色分けし、登録済みサービス（managed）なのか、意図しない開放（unmanaged）なのかを区別するため、「外部から何が見えていて、それはなぜか」をすぐに把握できます。

3つのソースを結合します。

infr_instance_firewall   (per-instance firewall rules = open ports/services)
        ×  infr_instance  (host meta — public IP · criticality · env · status)
        ×  infr_service   (registered logical services — instance_id · port)
        →  classified by FirewallLore →  exposure map

• これは読み取り専用のコンソールです。 ファイアウォール規則そのものの編集・収集は 資産 ▸ インスタンス ▸ [fw] の役割であり、この画面はその台帳を全体ビューに組み替えるだけです。
• すべてのソースが新しい infr_ テーブルであるため、legacy_glory（Suricata、Kitsune、…）には一切触れません — Eloquent で直接クエリするので SecurityRepository は不要です。
• 30秒ポーリング（ライブ）。リスク分類ロジックの正本は App\Support\FirewallLore、その解説文は resources/lang/{ko,en}/fwlore.php にあります。

役割の境界: この画面が見るのはポートの物理的な開放・露出（攻撃面）です。*論理的なサービス到達性（ヘルスチェック）*は サービス ▸ カタログ の領域です。同じポートでも、それぞれの画面で見る観点が異なります。

こんなときに使う

• サーバー群全体の攻撃面を棚卸しする — 「いま外部から見えているポートは何か」。
• 意図しない開放を見つける — 登録済みサービスではないのに開いている DB・キャッシュ・リモート管理ポート（未管理の露出）。
• 最悪の露出から順にトリアージする — 公開 IP を持つホストで開いている crit リスクのポート。
• あるポートをどのホストが開けているかを一目で見る（ポート別ビュー）。
• 1台のマシンが何をどれだけ露出しているかを確認する（ホスト別ビュー）。
• なぜそのポートが危険で、どう絞り込むかを学ぶ（ポートリスク解説モーダル）。

画面構成

ヘッダー（HERO）

タイトル／サブタイトル（Ports your fleet leaves open — attack-surface exposure map）、最終収集時刻、LIVE / PAUSED トグル（30秒ポーリングのオン・オフ）、全画面ボタン。

空の状態

ファイアウォール規則が1件もない場合はオンボーディングパネルが表示され、Go to Instances ボタンで /asset/instances に移動します。インスタンス ▸ [fw] から firewall-cmd の結果をインポートするか、リモートエミュレートで開放ポートを収集すると、マップが埋まります。

KPI バンド（5タイル）

公開 · crit は意図的な二重計上です。 公開 IP 上の crit ポートは、すでに Risky exposure に、（登録済みサービスでなければ）Unmanaged exposure にも計上されています — しかしその交差（public × crit）はサーバー群における最悪の露出であるため、見落としが起きないよう独立した KPI としてもう一度表に出しています。このタイルが 0 でなければ、まずここから直してください。

露出リスクバンド

4色の積み上げバー（crit・warn・ok・unknown）がリスクの内訳を示します。その下の凡例はクリックフィルターです — リスクレベルをクリックするとそのレベルだけが残ります（もう一度クリックで解除）。バンドの横の coverage（例: 7 / 12 hosts collected）は、ファイアウォール規則を持つホスト数とインスタンス総数の比です。

ツールバー・フィルター

• ビュー切替: ポート別／ホスト別。
• プロトコル: all / TCP / UDP。
• リスク: all / crit / warn / ok / unknown。
• 未管理のみ チェックボックス: 登録済みサービスではないポートだけ。
• 検索: ポート・サービス・ホスト（別名を含む）に一致。

ポート別ビュー

ポートカードのグリッドです。各カードにはポート／プロトコル・サービスラベル・リスクバッジ、このポートを開けているホストチップ（最大8個 + +N）、そしてフッターにホスト数・公開露出数・カテゴリが表示されます。カードをクリックするとポート詳細＋リスク解説モーダルが開きます。並び順はリスク → ホスト数 → ポート番号です。

ホスト別ビュー

ホストカードのグリッドです。各カードにはホスト名・別名・env・重要度、公開バッジ、そのマシンが開けているポートチップ（リスク色付き、登録済みサービスなら check-decagram マーカー）、そしてフッターにリスク別件数・ポート総数が表示されます。ポートチップをクリックすると同じ詳細モーダルが開きます。並び順は crit 件数 → warn 件数 → ポート数です。

ポート詳細＋リスク解説モーダル

ポート／プロトコル・サービス名・リスクバッジ・カテゴリに加えて、fwlore の3部構成の解説を表示します。

• これは何か（what） — このポートが何のサービスか。
• なぜ危険か（why） — 露出するとどのような攻撃につながりうるか。
• 推奨される対応（best） — 露出をどう絞り込むか。

その下にこのポートを開けているホストの一覧（env・重要度・ゾーン・公開／内部・管理済み／未管理のバッジ）と、Manage in Instances ▸ [fw] リンクがあります。

使い方

1. LIVE がオンなら、画面は30秒ごとに更新されます。調査中に値が動くのが気になる場合は PAUSED に切り替えてください。
2. まず 公開 · crit の KPI を確認します — 0 でなければ、リスク凡例の crit をクリックしてポート別ビューを絞り込み、公開チップ（地球アイコン）が付いたホストから先に対処します。
3. 未管理のみ を使って「意図しない開放」を切り出します。登録済みサービスではない DB（3306/5432/27017）、キャッシュ（6379/11211）、Docker（2375）、リモート管理（23/3389/VNC）がここに現れたら、直ちに絞り込んでください。
4. ポートカードをクリックして解説モーダルの why／best を読み、Manage in Instances ▸ [fw] をたどって規則を締めるか、サービスとして登録します。
5. 実際にポートを閉じたり規則を編集したりする作業はここではなく、対象ホストのファイアウォールと インスタンス ▸ [fw] で行います。この画面はマップであり監査ツールです。

リスク分類ルール（FirewallLore）

ポート文字列は単一値（8080）の場合も範囲（6081-6100）の場合もあります。範囲は開始ポートでウェルノウンマップと突き合わせます。

• VNC 帯（5900–5910） は個別エントリではなく範囲として扱われ、remote_admin · crit です。
• unknown である広いポート範囲（例 6081-6100）は、範囲が広いほど攻撃面が広がるため、最低でも warn に引き上げられます。
• 未マッピングのポートでも、サービスラベルが与えられていれば表示用に示されますが、リスクは unknown のままです。ラベルがない場合、フロントエンドは Unknown service と表示します。

管理済み判定

登録済みサービスのマップは infr_service.instance_id : port をキーにしています。そのポートに登録済みサービスがインスタンス上に存在すれば、その規則は管理済みです（check-decagram マーカー、managed_name）。範囲ポートは**開始ポート（low）**で一致します。登録済みサービスがなければ規則は未管理となり、リスクが ok でなければ Unmanaged exposure の KPI に計上されます。

データソース

infr_instance_firewall の規則の形（UNIQUE instance_id, zone, proto, port）:

{
  "zone": "public",
  "ports": [
    { "port": "22",         "proto": "tcp", "service": "ssh" },
    { "port": "443",        "proto": "tcp", "service": "https" },
    { "port": "3306",       "proto": "tcp", "service": "mysql" },
    { "port": "6081-6100",  "proto": "tcp", "service": "" }
  ]
}

[fw] のインポーターは firewall-cmd --list-all の生テキストも解析します（ゾーンヘッダー → services: のマッピング → ports: は直接）:

public (active)
  services: http https ssh
  ports: 8080/tcp 6081-6100/tcp 3306/tcp

構築されたダッシュボードはサーバー側で30秒キャッシュされます（infr:sec:firewall:dashboard）。規則が1件もない場合は空のペイロード（empty=true）を返し、オンボーディング状態を描画します。

アクセス権限

• 閲覧: /security/* プレフィックス全体が infr.level:2 ミドルウェアで包まれています → staff（5）以上のみです（内部的には user_level >= 2）。demo（1）はセキュリティデータから完全に遮断されます。
• この画面に書き込みはありません（純粋な読み取り）。ファイアウォール規則の編集・インポートは 資産 ▸ インスタンス ▸ [fw] で行い、レベル 2 以上＋監査ログでゲートされます。
• レベル体系: demo=1 · staff=5 · admin=10（一部の領域ではさらに infr.level:N のゲートが加わります）。RBAC レベル を参照してください。

トラブルシューティングと FAQ

空の画面（「ファイアウォールのデータがまだありません」）しか出ません。 infr_instance_firewall に規則が1件もないという意味です。資産 ▸ インスタンス ▸ [fw] に firewall-cmd --list-all の結果を貼り付けてインポートするか、リモートエミュレート で開放ポートを収集してください。

ポートが Unknown service と表示されます。 そのポートが FirewallLore のカタログにない（リスク unknown）ということです。正当なサービスであれば サービス ▸ カタログ に登録するか、[fw] 規則の service／note にラベルを追加してください。不要であれば閉じてください。

登録済みサービスなのに unmanaged と表示されます。 管理済み判定には、同じインスタンス上のそのポートに infr_service が存在することが必要です。サービスが別のホストや別のポートにある場合は一致しません。範囲ポートは開始ポートでのみ一致します。

Risky exposure は 0 ではないのに Public · crit が 0 です。 crit ポートを開けているホストがすべて内部専用（ip_public なし）であることを意味します — 露出半径が小さいため相対的には安全です。それでも、内部脅威やラテラルムーブメントを考慮して絞り込んでおいてください。

値がリアルタイムではありません。 LIVE が PAUSED になっているか、タブがバックグラウンドにある可能性があります。ダッシュボードはサーバー側で30秒キャッシュされるため、[fw] で規則を変更してから最大30秒間は古い値が表示されることがあります。

ここでポートを閉じられますか。 いいえ。この画面は読み取り専用のマップです。実際の遮断は対象ホストのファイアウォールで行い、規則台帳の更新は インスタンス ▸ [fw] で行います。

関連項目

• 資産 ▸ インスタンス ▸ [fw] — ファイアウォール規則の台帳 · このマップの書き込み側（収集・編集・インポート）
• リモートエミュレート · tlx.php プローブによる開放ポートの収集
• サービス ▸ カタログ · 登録済みサービス（管理済み判定）・論理的な到達性
• 資産 ▸ インスタンス · インスタンスのメタ情報（公開 IP・重要度）
• セキュリティ ▸ 概要 · セキュリティコンソールの入口（防御ファネル）
• 管理 ▸ 運用ポリシー · 「監視対象ポート」のピッカーで FirewallLore のポートカタログを再利用