ファイアウォールポリシーとACL

1）目標と原則

• 最小特権：必要なものだけを許可する（明示的な許可、暗黙的な拒否）。
• セグメンテーション：環境（prod/stage/dev）、テナント、重要な輪郭（PCI/KMS/DB）の分離。
• 排出制御：アウトバウンドトラフィックは、FQDN/IPリストとプライベートエンドポイントに限定されます。
• Identity-aware （L7）： IPだけでなく、認証されたエンティティ（SPIFFE/OIDC）によって決定が行われます。
• コードとしてのインフラストラクチャ：コードとしてのルール、レビュー/CI/CD、監査の変更。

2）分類： どこで何をフィルタリングするか

2.1レイヤーとステータス

L3/L4ステートレス：古典的なACL （CIDR、プロトコル、ポート）。
L3/L4ステートフル：セキュリティグループ/NSG、モニタ接続。
L7-aware： proxy/WAF/mesh RBAC（メソッド、パス、JWTクレーム、SNI）。
インラインvsアウトオブバンド：インラインファイアウォールルートトラフィック；帯域外-分析/アラート。

2.2輪郭

周囲：エッジ/WAF/アンチDDoS。
コア：トランジットハブ/меж -VPC/VNet。
ワークロード：VM/ENI/POD。
アプリレベル：Envoy/Istio/NGINXポリシー、サービスツーサービスmTLS。

3）クラウドモデル

AWS

セキュリティグループ（SG）： ステートフルENI/インスタンス/LB。
ネットワークACL （NACL）：サブネット上でステートレス、ルールの順序、双方向エントリ。
AWS ネットワークファイアウォール/GWLB： L7 検査/IDS。
推奨事項：「SG-基本制御、NACL-粗粒フェンシング/deny-list」。

Azure

NSG（ステートフル）、ASG（タグ別アプリケーショングループ）、Azure FW for L7/IDS、プライベートエンドポイント。
推奨事項：NSG on sabnet+NIC、 ASG経由のサービスタグ。

GCP

VPCファイアウォールルール（ステートフル）、階層FW（組織/フォルダ）、クラウドアーマー（L7）、プライベートサービス接続。
推薦：orgレベルのガードレール+プロジェクトは許可します。

4）規則の設計： パターン

4.1基本セット

バッチリポジトリ、アーティファクトレジスタ、サードパーティ製API（プライベート/固定出力を介して）。
東西最小：サービスは必要な依存関係とのみ通信します。
管理者アクセス：bastion/JIT経由でMFA、レコーディングセッション。

4.2タグとグループ

IPの代わりにラベル/タグを使用します：'env'、 'service'、 'tier'、 'tenant'、 'pci=true'。
タグが変更されたときのポリシーの更新-IPグリッドの手動編集はありません。

4.3ライフサイクル

Propose→Evaluate （staging）→Enforce （prod）、 dry-run/hitログを使用します。
老化：各規則のためのTTL/owner、未使用の自動点検。

5） Kubernetesおよびサービスメッシュ

5.1ネットワークポリシー（L3/L4）

最小限は「必要なものを除いてすべてを禁止する」ことです。

yaml apiVersion: networking. k8s. io/v1 kind: NetworkPolicy metadata: { name: deny-all, namespace: core }
spec:
podSelector: {}
policyTypes: ["Ingress","Egress"]
kind: NetworkPolicy metadata: { name: api-egress }
spec:
podSelector: { matchLabels: { app: api } }
egress:
- to:
- namespaceSelector: { matchLabels: { ns: db } }
ports: [{ protocol: TCP, port: 5432 }]
- to:
- ipBlock: { cidr: 10. 100. 0. 0/16 } # Private endpoints ports: [{ protocol: TCP, port: 443 }]

5.2 L7 RBACメッシュ（Istio/Envoy）

mTLS+JWT認証/クレーム/スコープ/パス。

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: api-rbac }
spec:
selector: { matchLabels: { app: api } }
rules:
- from:
- source:
principals: ["spiffe://svc. payments"]
to:
- operation: { methods: ["POST"], paths: ["/v1/payouts"] }
when:
- key: request. headers[x-tenant]
values: ["eu-1","eu-2"]

6）出口制御および私用周囲

PrivateLink/Private ServiceをPaaS/レジスタ/リポジトリ経由で接続します。
allowlist FQDNと固定IP（サードパーティ製allowlist用）を使用したNAT/proxy経由の残りの出力。
インターネットへのPod/VMの直接アクセスをブロックします。例外はegressゲートウェイを介してのみ発生します。

7） DNSおよびSNI対応ルール

分割地平線：内部ゾーンは外部から解決しません。
発信HTTPS （SNI許可）のためのFQDN/SNIサポートを備えたFW/Proxy。
特定のベンダーのドメインへのピン留めを修正。IPの変更を監視します。

8）ログ、監査、可視性

フローログ（VPC/VNet/NSG/NACL）を有効にし、SIEMに送信します。
ログの'trace_id'を介してアプリケーションと相関します。
メトリクス：ヒット/ミスルール、トップトーカー、ドロップレート、トラフィック非対称性、排出漏れ。
レポート："unused rules"、 "widest permissions'。

9）コード（IaC）および点検として管理

テンプレートによるTerraform/CloudFormation+モジュラーポリシー。
コードとしてのポリシー（OPA/ゲートキーパー/Conftest）： no '0。0.0.0/0'、requirement' description/owner/ttl'、prod/devを混合することの禁止。
CI： lint、 static analysis、 reachability analyzer、プランビュー、必須ピアレビュー。

10）到達性のテストおよび混乱

異なるサブネット/AZ/リージョンからの合成サンプル：TCP/443、データベース/ブローカーの特定のポート。
一時的にDRパスをチェックすることを拒否します：無効化→依存性はretries/circuit/fallbackをトリガーします。
MTU/MSS：周囲（特にIPsec/NAT-T）に断片化がないことを確認します。

11）性能および信頼性

一元化されたボトルネックを避ける：スケールインラインFW （GWLB/スケールセット）。
ハブ間の分配のためのECMP/AS-path/BGP。
TLS検査プロファイル：ポイント（高価）を含み、キープリントを個別に保存し、コンプライアンスに準拠します。

12） configsの例（参照、短縮）

12.1 AWS SG： API→Postgres+S3 PrivateLink

hcl resource "aws_security_group" "api" {
name    = "sg-api"
description = "Ingress from ALB, egress to DB and PrivateLink"
vpc_id   = var. vpc_id

ingress { from_port=8080 to_port=8080 protocol="tcp" security_groups=[aws_security_group. alb. id] }
egress { from_port=5432 to_port=5432 protocol="tcp" security_groups=[aws_security_group. db. id] }
egress { from_port=443 to_port=443 protocol="tcp" prefix_list_ids=[aws_vpc_endpoint. s3. prefix_list_id] }
tags = { owner="team-api", env=var. env, ttl="2026-01-01" }
}

12.2 Azure NSG： deny-by-default+allow bastion

bash az network nsg rule create -g rg -n allow-bastion --nsg-name nsg-app \
--priority 100 --direction Inbound --access Allow --protocol Tcp \
--source-address-prefixes 10. 0. 0. 10 --source-port-ranges "" \
--destination-port-ranges 22 --destination-address-prefixes 10. 1. 0. 0/16

12.3 GCP階層ファイアウォール：org-guardrail

yaml direction: INGRESS priority: 1000 action: deny enableLogging: true match:
layer4Configs: [{ ipProtocol: "all" }]
srcIpRanges: ["0. 0. 0. 0/0"]
targetResources: ["organizations/123456"]

12.4特使RBAC （L7許可）

yaml
- name: envoy. filters. http. rbac typed_config:
rules:
action: ALLOW policies:
payments-post:
permissions: [{ url_path: { path: "/v1/payouts", ignore_case: true } }]
principals: [{ authenticated: { principal_name: { exact: "spiffe://svc. payments" } } }]

13） Antipatterns

`0.0.0.0/0 'in ingress/egress 「temporally」→は永遠に残ります。
コードとリビジョンなしの「Snowflakes」（コンソールで手動編集）。
prod/stage/devのための共通SG/NSG；クリティカルおよびクリティカルでないサブネットを混在させます。
出力制御とプライベートエンドポイントの欠如→キー/シークレットの漏洩。
DNS/SNIを無視する：サプライヤーのIPを許可しました-明日、それが変更され、全範囲が開かれました。
フローログがなく、ランブック→フェーズが不可能です。

14） iGaming/Finance （PCI/Regulatory）の詳細)

別のVRF/segmentのPCI CDE、インターネット無し；PSP/logsへのアクセス-mTLSおよびHMACとのプライベート接続/プロキシを介して。
データレジデンシー：PII/支払いイベント-国/地域内；地域間-集計/匿名のみ。
KMS/Vault/HSM：個々のサブネット/SG、短い証明書を持つmTLSクライアントのみ。
WORM監査：変更のないストレージ（オブジェクトロック）でのFW/フローログ、保持≥規制の最小化。
パートナー（PSP/KYC）： FQDN allowlist、静的なegress IP、プロバイダによるSLA監視。

15） Prod Readinessチェックリスト

• 統一されたセグメンテーションモデル（ハブアンドスポーク、VRF）、交差のないCIDR。
• Deny-by-defaultエグゼクティブ；PaaS/ストレージへのプライベートエンドポイント。
• ワークロード、NACL/route-filters-サブネット/ハブ上のSG/NSGステートフル。
• K8s： NetworkPolicy "deny-all'、 mesh mTLS+L7 RBAC。
• IPの代わりにタグ/グループ；各ルールの所有者/TTL/説明。
• IaC+Policy-as-Code；到達可能性シミュレーションを備えたCI；必須のピアレビュー。
• フローログが有効になっています。ダッシュボードのトップトーカー、ドロップレート；「漏出漏れ」を警告します。
• 管理者アクセスのためのバスティオン/JIT；MFA；ロギングセッション。
• Runbook'と：ルールの追加/削除方法、インシデントでの作業方法;「死んだ」規則の定期的な改訂。
• PCI/ファイナンスの場合：CDE分離、WORM監査、FQDN-allow for PSP/KYC、 static egress IP。

16） TL；DR（ドクター）

レイヤーによるビルド保護：ワークロードのSG/NSGステートフル、サブネットのNACL/ルートフィルタ、メッシュ/プロキシのL7 RBAC、周囲のWAF/エッジ。デフォルトでは、deny-by-defaultでは、制御点またはプライベートエンドポイントを介してのみ出力されます。ルールをコードとして記述し、ポリシーと到達可能性シミュレータでチェックし、フローログを収集します。iGaming/Financeでは、PCIセグメンテーション、WORM監査、および厳格なFQDN-allowをPSP/KYCに追加します。