ファイアウォールとトラフィックフィルタリング

（セクション： 技術とインフラ）

簡単な要約

ファイアウォールは境界上の1つのボックスではなく、L3-L4からL7までの階層化されたフィルタリングモデルです。クラウドセキュリティグループ/NACL、 Kubernetesのネットワークポリシー、エッジコントロール、WAFおよびボット管理、およびサービス・ツー・サービスのためのmTLS/source-truth。iGamingの鍵は、支払いフローとゲームプロバイダ、地理政治、DNS制御と観測性（誰が、どこで、いつ、なぜ）を保護することです。

1）目標と原則

デフォルトのdeny：デフォルトでは、必要最小限の値を許可します。
ディフェンスの詳細-境界、クラウド、クラスタ、およびアプリケーションに関する同じポリシー。
出力トラフィックは入力（PSP、ゲームプロバイダ、メール、分析）と同じリスクです。
Identity> address：可能であれば、bare IPの代わりにID （mTLS/Spiffe）で認証します。
オブザビリティと監査：意思決定ログ（許可/拒否）、トレース、インシデントとの相関。

2）ろ過層の地図

1.エッジ：CDN/WAF/DDoS/ボット保護、L7ルール、TLS終了。
2.クラウド：VPC/サブネット/VMレベルのセキュリティグループ/NACL/ファイアウォールルール。
3.クラスタ：Kubernetes NetworkPolicy、 mTLSおよびL7フィルタを備えたサービスメッシュ（Envoy/Istio）。
4.ホスト：iptables/nftables/ufw、エージェントeBPFフィルタ。
5.アプリケーション：rate-limit/idempotency/WAF in-app、 egressのドメインリスト。
6.DNS： split-horizon、 allowlist resolver、リスクドメイン/タイプのブロック。

3）周囲： WAF、 DDoSおよびボット管理

WAF：基本署名+APIのカスタムルール（JSONスキーム、メソッド/content-type）。
ボット：行動スコアリング、デバイス指紋、異常のための動的キャプチャ。
DDoS： L3/4 （volum/synapse）とL7 （HTTP洪水）-エッジ上の自動廃棄。
Geo/ASN：危険な領域（管理パネルなど）の領域/自律システムを制限します。

nginx
Разрешаем только JSON POST/GET на /api/
location /api/ {
limit_req zone=rl_api burst=50 nodelay;
if ($request_method!~ ^(GET    POST)$) { return 405; }
if ($http_content_type!~ "application/json") { return 415; }
proxy_pass http://api_upstream;
}
ModSecurity CRS + собственные правила modsecurity on;
modsecurity_rules_file /etc/nginx/modsec/crs.conf;

4）クラウド： セキュリティグループとNACL

セキュリティグループ（ステートフル）-ポート/プロトコル/セグメントによるフィルタ。
NACL（ステートレス）-サブネットのラフメッシュフィルタリング。

yaml security_group:
name: api-sg ingress:
- proto: tcp; port: 443; cidr: 0.0.0.0/0 # через CDN/WAF egress:
- proto: tcp; port: 443; cidr: 203.0.113.0/24  # PSP-X
- proto: tcp; port: 443; cidr: 198.51.100.0/24 # ProviderA
- proto: udp; port: 53; cidr: 10.10.0.10/32  # только наш DNS

練習：支払いのために特定のPSP/ゲームプロバイダの範囲のための別々のSGと脱出許可リストを維持します。更新-IaCとレビューを介して。

5） Kubernetes： NetworkPolicyとService Mesh

NetworkPolicyはクラスタ内のL3/4を制限します。デフォルトでは「everyone talks to everyone」-close。

yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: deny-all, namespace: prod }
spec:
podSelector: {}
policyTypes: [Ingress, Egress]
ingress: []
egress: []
---
Разрешаем API разговаривать с платежным сервисом и DNS apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: { name: api-allow-specific, namespace: prod }
spec:
podSelector: { matchLabels: { app: api } }
policyTypes: [Ingress, Egress]
egress:
- to:
- namespaceSelector: { matchLabels: { name: prod } }
podSelector: { matchLabels: { app: payments } }
ports: [{ protocol: TCP, port: 8080 }]
- to:
- ipBlock: { cidr: 10.10.0.10/32 }
ports: [{ protocol: UDP, port: 53 }]

• mTLSはどこにでもあります（IPではなくIDによるサービス認証）。
• L7フィルタリング（メソッド/ホスト/パス/ヘッダ）、サーキットブレーカ、アウトリアイジェクション。
• サービスアカウント/Spiffe IDによるアクセスポリシー。

yaml apiVersion: security.istio.io/v1 kind: AuthorizationPolicy metadata: { name: api-to-payments, namespace: prod }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://prod/ns/prod/sa/api-sa"]
to:
- operation:
methods: ["POST"]
paths: ["/deposit","/withdraw"]

6）ホストファイアウォール： iptables/nftables/eBPF

nft table inet filter {
sets {
psp { type ipv4_addr; elements = { 203.0.113.10, 203.0.113.11 } }
}
chains {
input { type filter hook input priority 0; policy drop;
ct state established,related accept iifname "lo" accept tcp dport {22,443} accept
}
output { type filter hook output priority 0; policy drop;
ct state established,related accept udp dport 53 ip daddr 10.10.0.10 accept  # только наш DNS tcp dport 443 ip daddr @psp accept    # egress к PSP
}
forward { type filter hook forward priority 0; policy drop; }
}
}

eBPFエージェント（Ciliumなど）は、薄いL3-L7ポリシーと可視性（フロー、DNS、 HTTPメタデータ）を提供します。

7）出力制御および宛先ディレクトリ

外部通話（PSP、メール、KYC、ゲームプロバイダ）のためのAllowlist ドメイン/IP。
DNSピン留め/SNIポリシー：信頼できるリゾルバを使用してのみ解決します。未加工IP egressを禁止して下さい。
支払い、ゲーム、一般回路のVPC/VNegressを分離します。
非PIIトラフィックのTLS検査によるプロキシ；支払いフロー-MITMなし、直接mTLS/PII-safeのみ。

8） TLS/mTLSと暗号ポリシー

TLS 1。2+の現代暗号、OCSPのステープリング、HSTS。
mTLS内部-Spiffe ID/サービスアカウントの認証へのバインディング。
定期的な証明書の回転とトラストチェーンの検証。
L7プロキシ上のCORS/CSPは、前面の攻撃ソースをカットします。

9）レート制限とL7-quotas

IP/ASN/接頭辞によるエッジ制限；アプリケーションの制限-ID（アカウント/テナント/キー）による。
POST決済操作のIdempotency-keysを使用して、再トレイが重複を作成しないようにします。
ジッターが付いている漏出/トークンバケット；劣化中-「灰色の答え「/captcha/減速。

10） DNSセキュリティ

コーポレートリゾルバ（VPC resolver/laised CoreDNS）のみが許可されています。
Split-horizon：内部名は外部から解決しません。
有害なTLD/カテゴリーをブロックし、囲炉裏からDoH/DoTを禁止します。
異常によるロギング要求とアラート（新しいドメイン、頻繁なNXDOMAIN）。

11）ログ、observabilityおよびテスト

ファイアウォールログ（許可/拒否、ルール、バイト）、WAF監査、DNSログ→SIEM/SOAR。
例：'trace_id'→問題のクエリトレースへのクイックジャンプでメトリックをロックします。
Synthetics：適切な地域からPSP/ゲームプロバイダの可用性を定期的にチェックします。
ネットワークカオステスト：パケット損失、RTT、 DNSエラー-ルールの反応と自動修復をチェックします。

12）オートメーションおよびIaC

すべてのルールはコード（Terraform/Ansible/Helm/Kyverno/Gatekeeper）のようなものです。
セキュリティポリシー（OPA）によるプルリクエストレビュー。
バージョン管理とアノテーション-グラフのルール変更をマークします。
カナリアの変更点：ネットワークポリシーを徐々にロールアウトします（名前空間/ラベル、ピッチの5〜10％）。

13） iGamingの詳細

支払ルート（PSP）：個々の脱出グループ、厳格な許可リスト、コード/タイムアウト監視。
ゲームプロバイダ：CDNドメインのホワイトリスト、突然のリダイレクトに対する保護。
ジオルール：地域の制限、エッジ上の地域のブロックの遵守。
Backoffice/KYC：信頼できるネットワークからのみ/bastion+MFA経由でアクセスできます。
詐欺：L7の速度制限と異常なソースのAPIへの「重い」要求。

14）クイックルールの例

UFW（ホスト）

bash ufw default deny incoming ufw default deny outgoing ufw allow 22/tcp ufw allow 443/tcp ufw allow out to 10.10.0.10 port 53 proto udp ufw allow out to 203.0.113.0/24 port 443 proto tcp

Istio EnvoyFilter（非標準的な方法、アイデアの禁止）

yaml typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router до роутера — Lua/Match для блокировки методов not in [GET,POST,OPTIONS]

NGINXレート制限

nginx limit_req_zone $binary_remote_addr zone=rl_api:10m rate=10r/s;
server {
location /api/ { limit_req zone=rl_api burst=50 nodelay; proxy_pass http://api; }
}

15）実装チェックリスト

1.デフォルトでは、クラウド（SG/NACL）、クラスタ（NetworkPolicy）、ホストのレベルで拒否します。
2.信頼できるDNSを通じてのみ解決されたPSP/プロバイダへの排出許可リスト。
3.エッジ上のWAF/ボット 管理/DDoS、 REST/JSONおよびダウンロード用のL7ルール。
4.サービス間のmTLS、 ID認証（Spiffe/SA）。
5.エッジとアプリのレート制限/クォータ、支払いのためのidempotency-keys。
6.DNSポリシー：DoH/DoT禁止、分割地平線、ロギング。
7.ログとSIEM：一元管理されたコレクションにより、/deny/WAF/DNS,異常に対するアラートが許可されます。
8.IaCプロセス：ルールコード、PRレビュー、カナリアロール、注釈。
9.テスト/カオス：RTT/損失/DNS障害、フォールバックルートおよび自動スクリプトのチェック。
10.定期監査：未使用ルールの監査、PSP/CDNアドレスの回転。

16）アンチパターン

「すべてを開き、WAFを望む」-周囲は内部トラフィックを節約しません。
出力制御なし-チューブトンネルはleaks/C2のために外側にありません。
KubernetesのAllow-all NetworkPolicy-横方向の動きが保証されています。
ドメイン/DNS制御なしの動的CDN/PSP世界でのIPのみのフィルタリング。
内部にmTLSがない唯一のTLS終端点はサービス置換である。
IaC/監査なしでの販売における手動ルールの変更-非再現性と負債。
ファイアウォールは「どこにもない」ログを記録します。

［結果］

効率的なトラフィックフィルタリングは、プラットフォームのアーキテクチャファブリックです。エッジWAFとクラウドSGからクラスタ内のNetworkPolicyおよびmTLSまで、IaCを介したPSP/プロバイダおよび管理への厳しい排出制御を備えています。このようなシステムは、漏洩や攻撃のリスクを軽減し、SLO内で支払いやゲームを維持し、完全な監査と監視を通じて事件を迅速に調査するのに役立ちます。