Firewall және трафикті сүзу

(Бөлім: Технологиялар және Инфрақұрылым)

Қысқаша түйіндеме

Faervol - бұл периметрдегі бір жәшік емес, L3-L4-ден L7-ге дейінгі сүзгілеудің қабатты моделі: бұлтты Security Groups/NACL, Kubernetes-тегі желілік саясат, egress-бақылау (сыртқа шығу), WAF және edge-тегі бот-менеджмент, және mTLS/сервис үшін ақиқат көзі - сервиске. iGaming үшін негізгі нәрсе - төлем ағындары мен ойын провайдерлерін қорғау, гео-саясат, DNS бақылау және бақылау (кім, қайда, қашан және неліктен).

1) Мақсаттар мен қағидаттар

Default deny: әдепкі тыйым салынған, ең аз қажеттіге рұқсат етеміз.
Defense-in-depth: периметрдегі, бұлттағы, кластердегі және қолданбадағы бірдей саясаттар.
Egress-first: шығу трафигі - кіріс трафигі сияқты тәуекел (PSP, ойын провайдерлері, пошта, талдау).
Сәйкестік> мекенжайы: мүмкін болған жерде, жалаңаш IP орнына сәйкестік бойынша авторизацияланады (mTLS/Spiffe).
Бақылау және аудит: шешімдердің логтары (allow/deny), трассировка, инциденттермен корреляция.

2) Сүзу қабаттарының картасы

1. Edge: CDN/WAF/DDoS/бот-қорғау, L7-ережелер, TLS-терминация.
2. Бұлт: VPC/кіші желілер/VM деңгейінде Security Groups/NACL/Firewall Rules.
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 резольверлер, тәуекел домендері/түрлері.

3) Периметр: WAF, DDoS және бот-менеджмент

WAF: API (JSON-схемалар, әдістер/контент-type) үшін негізгі белгілер + кастомдық ережелер.
Боттар: мінез-құлық скорингі, device fingerprint, аномалиялар кезінде динамикалық капча.
DDoS: L3/4 (волюм/синапс) және L7 (HTTP floods) - автоматты түрде edge-ге лақтыру.
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) Бұлт: Security Groups және NACL

Security Group (stateful) - порттар/хаттамалар/сегменттер бойынша сүзгілер.
NACL (stateless) - кіші желілердің өрескел торлы сүзгісі.

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

Практика: төлемдер үшін жеке SG және egress-allowlist PSP/ойын провайдерлерінің нақты диапазондарында ұстау. Жаңартулар - IaC және ревю арқылы.

5) Kubernetes: NetworkPolicy және сервис-теш

NetworkPolicy кластер ішіндегі L3/4 шектейді; әдепкі бойынша «бәрі бәрімен сөйлеседі» - жабыңыз.

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 емес, сәйкестігі бойынша аутентификация қызметтері).
• L7-сүзу (әдістер/хосттар/жолдар/тақырыптар), circuit-breaker, outlier-ejection.
• Сервистік тіркелгі/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-саясатты және көрінуді (flows, DNS, HTTP-метадеректер) береді.

7) Egress-бақылау және тағайындау каталогтары

Сыртқы қоңыраулар үшін Allowlist домендері/IP (PSP, пошта, KYC, ойын провайдерлері).
DNS-пиннинг/SNI саясаты: тек сенімді резольвер арқылы; шикі IP-egress-ке тыйым салу.
Төлем, ойын және жалпы контурлар үшін бөлек VPC/VNet egress.
PII емес трафик үшін TLS-инспекциясы бар прокси; төлем ағындары - MITM-сіз, тек тікелей mTLS/PII-safe.

8) TLS/mTLS және криптополитика

TLS 1. 2 +, заманауи шифрлар, OCSP stapling, HSTS.
mTLS ішінде - Spiffe ID байланыстыру/сервис-акаунттарды сертификаттау.
Сертификаттарды тұрақты ротациялау және сенім тізбектерін тексеру.
Фронттағы шабуыл көздерін кесу үшін L7-проксидегі CORS/CSP.

9) Rate-limit және L7-квоталар

IP/ASN/префикстер бойынша Edge-лимиттер; қосымшалық лимиттер - сәйкестігі бойынша (аккаунт/тенант/кілт).
Idempotency-keys POST төлем операциялары үшін, ретрайлер қосарланбауы үшін.
Leaky/Token bucket джиттермен; деградация кезінде - «сұр жауаптар «/капча/баяулау.

10) DNS қауіпсіздігі

Тек корпоративтік резольверлерге рұқсат етіледі (VPC resolver/көтерілген CoreDNS).
Split-horizon: ішкі аттары сыртынан қосылмайды.
Зиянды TLD/санаттар блогы, сыртқы табандардан DoH/DoT тыйым салу.
Сұрауларды логикалау және аномалиялар бойынша алертинг (жаңа домендер, жиі NXDOMAIN).

11) Логтар, бақылау және тестілеу

Фаерволдар логтары (allow/deny, ережелер, байттар), WAF-аудит, DNS-логтар → SIEM/SOAR.
Exemplars: 'trace _ id' → түйткілді сұрау жолына жылдам секіру.
Синтетика: PSP/ойын провайдерлерінің қажетті өңірлерден қолжетімділігін тұрақты тексеру.
Желінің хаос-тесттері: packet loss, RTT, DNS-қателері - ережелер мен авто-ремедиацияның реакциясын тексереміз.

12) Автоматтандыру және IaC

Барлық ережелер - код ретінде (Terraform/Ansible/Helm/Kyverno/Gatekeeper).
Қауіпсіздік саясатымен (OPA) Pull-request-ревю.
Нұсқалау және аннотациялар: ережелердің кез келген ауысуы кестелерде белгіленеді.
Канареялық өзгерістер: желілік саясаттарды біртіндеп жаю (namespace/label, 5-10%).

13) iGaming ерекшелігі

Төлем бағыттары (PSP): жекелеген egress-топтар, қатаң allowlist, кодтар/таймауттар мониторингі.
Ойын провайдерлері: CDN домендерін whitelisting, кенеттен қайта басқарушылардан қорғау.
Гео-ережелер: жергілікті шектеулерге сәйкестігі, edge.
Backoffice/KYC: тек сенімді желілерден/bastion + MFA арқылы қатынау.
Фрод: L7-ге velocity-лимиттер және аномальды көздердің 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 rate-limit

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) және хосттар деңгейіндегі Default deny.
2. Egress-allowlist PSP/провайдерлерге тек сенімді DNS арқылы ғана қосылады.
3. WAF/бот-менеджмент/DDoS на edge, L7-REST/JSON және жүктеу ережелері.
4. mTLS сервистер арасында, сәйкестік бойынша авторизациялау (Spiffe/SA).
5. Rate-limit/quotas edge және қосымшада, idempotency-keys төлемдер үшін.
6. DNS саясаты: DoH/DoT тыйым салу, split-horizon, логин.
7. Логи және SIEM: allow/deny/WAF/DNS орталықтандырылған жинағы, аномалиялар бойынша алерталар.
8. IaC-процестер: ережелер коды, PR-ревю, канареялық домалақтау, аннотациялар.
9. Тесттер/хаос: RTT/loss/DNS ақаулары, fallback маршруттарын және авто сценарийлерін тексеру.
10. Тұрақты тексерулер: пайдаланылмайтын ережелердің аудиті, PSP/CDN мекенжайларын ротациялау.

16) Қарсы үлгілер

«Бәрін ашып, WAF-қа үміт арту» - периметр ішкі трафикті сақтап қалмайды.
Egress-бақылаудың болмауы - сыртқа шығуға арналған шам туннелі/С2.
Kubernetes-те Allow-all NetworkPolicy - бүйірден орын ауыстыруға кепілдік берілген.
Тек IP бойынша сүзу әлемдегі динамикалық CDN/PSP домен/DNS бақылауынсыз.
Ішінде mTLS жоқ жалғыз TLS-терминация нүктесі - сервистерді ауыстыру.
IaC/аудитсiз өнiмдегi ережелердi қолмен түзету - өндiрiлмеушiлiк және борыштар.
Фаерволдың «ешқайда» - бақылаусыз бұл жай ғана «қара жәшік».

Қорытынды

Трафикті тиімді сүзу - edge-WAF және бұлтты SG-ден кластер ішіндегі NetworkPolicy және mTLS-ке дейін, PSP/провайдерлерге қатаң egress-бақылау және IaC арқылы басқару арқылы платформаның архитектуралық матасы. Мұндай жүйе ағып кету және шабуыл жасау қаупін төмендетеді, SLO аясында төлемдер мен ойындарды ұстайды және толық аудит пен бақылаудың арқасында инциденттерді тез арада тексеруге көмектеседі.