SSL ტერმინალი და დაბალანსება

მოკლე რეზიუმე

SSL/TLS ტერმინალი აშორებს კრიპტო დატვირთვას პროგრამებიდან და ხსნის გზას L7 მარშრუტიზაციამდე, WAF, rate-limit, mTLS, კანარის გამოშვებამდე. საკვანძო გადაწყვეტილებები: სად უნდა დასრულდეს TLS (edge/ingress/ingress/mesh- ის შიგნით), როგორ გავაბალანსოთ (L4 vs L7), რომელი შიფრების პროფილები უნდა გამოვიყენოთ, თუ როგორ უნდა განაახლოთ სერთიფიკატები დასრულების გარეშე და როგორ უნდა შეინარჩუნოთ p95 ლატენტობა და შეცდომები SLLO- ში.

სად დავასრულოთ TLS

ზღვარზე (CDN/Anycast/WAF): მომხმარებლის მინიმალური ლატენტობა, გლობალური დაცვა, ქეში/ბოტი კონტროლი. შემდეგი არის re-encrypt უკანა პლანზე.
Ingress L7 (Nginx/Envoy/HAProxy/ALB): თხელი მარშრუტი URI/სათაურებზე, mTLS, JWT სავალდებულო.
TLS (passthrough L4) მეშვეობით: როდესაც თქვენ გჭირდებათ end-to-end mTLS pod/სერვისამდე (მაგალითად, მკაცრი შესაბამისობის ზონა).
Service Mesh (Envoy/Istio/Linkerd): ავტომატიზირებული mTLS კლასტერის, პოლიტიკის და ტელემეტრიის შიგნით.

პრაქტიკა: უფრო ხშირად - edge terminate - re-encrypt ingress; PII/გადახდებისთვის - mTLS მომსახურებამდე.

L4 vs L7 დაბალანსება

L4 (TCP/UDP): მინიმალური შეფერხება, მარტივი ჯანმრთელობის შემოწმება (პორტი/TSR), passthrough TLS. შესაფერისია GRPC- სთვის TLS- ზე, L7 Fich- ის ნაკლებობით.
L7 (HTTP/HTTPS/HTTP3): ჰოსტის/ტრეკების/სათაურების/ქუქი-ფაილების მარშრუტიზაცია, WAF, საბინაო-ლიმიტები, კანარის გამოშვებები, სტილის სესიები, რეტრაები/ტაიმაუტები.

TLS: ვერსიები, გასაღებები, შიფრები

ვერსიები: TLS 1. 3 ყველგან, TLS 1. 2 ჰგავს fallback. გამორთეთ 1. 0/1. 1.
გასაღებები/სერიები: ECDSA (P-256) - უფრო სწრაფად, ვიდრე RSA; შეგიძლიათ ორმაგი დასტის (ECDSA + RSA) ანტიკურისთვის.
ALPN: `h2` и `http/1. 1`; HTTP/3 - 'h3' (QUIC/UDP).
OCSP Stapling: ჩართვა; HSTS საჯარო დომენებზე.
გასაღებები: შენახვა KMS/HSM- ში; ავტომატური გაფართოება (ACME/ნდობის ხე).
0-RTT (TLS 1. 3): ჩართეთ წერტილოვანი (GET/idempotent), გაითვალისწინეთ replay რისკი.

ძირითადი შიფრის პროფილი (TLS 1. 2): `ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305`

TLS შესრულება

Resumption: session tickets/IDs - ამცირებს handshake ღირებულებას.
ECDSA + ChaCha20 ეხმარება მობილური/AES-NI- ს გარეშე.
OCSP Stapling + მოკლე ჯაჭვები ამცირებს p95.
HTTP/2/3: მულტიპლექსირება, ნაკლები ნაერთები p95 ქვემოთ.
Offload: pin CPU ბირთვი crypto- ს ქვეშ, ჩართეთ reuseport, tune socket ბუფერები.

უსაფრთხოება

mTLS: მოითხოვეთ client cert ოპერატორების ადმირალებისთვის/API; CRL/OCSP გაწვევისთვის.
SNI/ECH: SNI - სტანდარტი; ECH (Encr. ClientHello) მალავს დომენს (თუ მხარს უჭერს edge პროვაიდერს).
Strict Transport Security (HSTS): prod დომენები, თავიდანვე სიფრთხილით.
TLS ჰოპს შორის: re-encrypt მომსახურებამდე, თუნდაც DC- ს შიგნით (Zero-Trust).
Rate-limit/gree-voles: L7- ზე ისინი იცავს api- ს ბოტების/ბრუტფორებისგან.

დაკვირვება და SLO

SLO (მაგალითები)

p95 TLS-handshake - 80-120 ms (გლობალურად), p95 TTFB - 200-300 ms.
შეცდომები TLS (handshake/peer-verify) - 0. 1%.
შეჯამების წილი 70% -ს შეადგენს განმეორებითი ვიზიტებისთვის.

მეტრიკი

`handshake_time`, `tls_version`, `alpn`, `cert_expiry_days`, `ocsp_staple_status`.
L7: `p50/p95/p99`, `5xx`, `429`, `upstream_rq_time`, `retry_budget`.
Capacity: აქტიური კონექტორები, CPS (Connections per second), RPS.

სტანდარტული კონფისკაციები

Nginx (L7 terminate + HTTP/2 + OCSP stapling)

nginx server {
listen 443 ssl http2 reuseport;
server_name api.example.com;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:...:ECDHE-RSA-CHACHA20-POLY1305';
ssl_ecdh_curve X25519:P-256;
ssl_certificate   /etc/ssl/cert.pem;    # полная цепочка ssl_certificate_key /etc/ssl/key.pem;
ssl_stapling on; ssl_stapling_verify on;
ssl_session_cache shared:SSL:50m; ssl_session_timeout 1d;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto https;
proxy_pass https://upstream_pool;
}
}

upstream upstream_pool {
zone backends 64k;
server 10.0.1.10:8443 max_fails=3 fail_timeout=10s;
server 10.0.1.11:8443 max_fails=3 fail_timeout=10s;
keepalive 256;
}

HAProxy (L7 terminate + stickiness + mTLS ზურგზე)

haproxy frontend fe_https bind:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1 mode http http-response set-header Strict-Transport-Security max-age=31536000 default_backend be_api

backend be_api mode http balance roundrobin cookie SRV insert indirect nocache option httpchk GET /healthz server s1 10.0.1.10:8443 check ssl verify required ca-file /etc/haproxy/ca.pem server s2 10.0.1.11:8443 check ssl verify required ca-file /etc/haproxy/ca.pem

Envoy (L7 terminate + mTLS კლიენტიდან + კანარი)

yaml static_resources:
listeners:
- name: https address: { socket_address: { address: 0.0.0.0, port_value: 443 } }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager stat_prefix: ingress route_config:
virtual_hosts:
- name: api domains: ["api.example.com"]
routes:
- match: { prefix: "/" }
route:
weighted_clusters:
clusters:
- name: api-stable weight: 95
- name: api-canary weight: 5 http_filters:
- name: envoy.filters.http.router transport_socket:
name: envoy.transport_sockets.tls typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext common_tls_context:
tls_certificates:
- certificate_chain: { filename: "/etc/tls/cert.pem" }
private_key:   { filename: "/etc/tls/key.pem" }
validation_context:       # mTLS (опционально)
trusted_ca: { filename: "/etc/tls/ca.pem" }
require_client_certificate: true

AWS ALB/NLB (კონცეფცია)

ALB (L7 terminate): HTTPS listener 443 (TLS 1. 2/1. 3), target group HTTPs:8443, health-check `/healthz`, stickiness (cookie).
NLB (L4 passthrough): TLS listener 443, TCP health checks, SNI- ს მეშვეობით pod.
CloudFront/Cloudflare: TLS edge + WAF + Bot მენეჯმენტი; origin — HTTPS only.

სერთიფიკატების განახლება დასრულების გარეშე

ACME (Let's Encrypt/კერძო CA) ავტომატური განახლებითა და ცხელი გადატვირთვით (Nginx 'reload', Envoy SDS).
ორმაგი სერთიფიკატი (ECDSA + RSA) მიგრაციის დროს.
ჯაჭვების კონტროლი: შუალედური CA- ს შემოწმება; OCSP შეტევა როტაციის შემდეგ.
ალერტები: 'cert _ expiry _ days <21' და 'ocsp _ status! = კარგი'.

ჯანმრთელობის შემოწმებები და მარშრუტიზაცია

L4: TCP connect, TLS handshake.
L7: HTTP 200/JSON მარკერი ვერსია, GRPC Health.
პოლიტიკოსები: failover, weighted, latency, consistent-hash (cookie/IP) სტიკისთვის.
Retrai/Taimauts: ბალანსი მოთხოვნის სტაბილურობასა და დუბლიკატებს შორის (imempotence!).

Kubernetes ნიმუშები

Ingress Controller (Nginx/Envoy/HAProxy): ingress ტერმინი, 'ExternalDNS' DNS ჩანაწერებისთვის, 'cert მენეჯერი' ACME- სთვის.
Gateway API: დეკლარირებული TLSRoute/HTTPRoute კანაფებით.
Service Mesh: ავტომატური mTLS pod pod, პოლიტიკა 'PeerAuthentical '/' DestinationRule'.

უსაფრთხოების სია

• TLS 1. 3 ჩართულია; 1. 0/1. 1 გამორთულია.
• თანამედროვე შიფრები; ECDSA სერჟები, სადაც მხარდაჭერა იძლევა.
• OCSP stapling, სავსე ჯაჭვები, HSTS.
• mTLS ადმირალებისთვის/ინტერკონექტებისთვის; კლიენტის სერჟების რეკონსტრუქცია.
• დაბალ-ლიმიტი/ბოტი ფილტრები ზღვარზე; დაცვა slowloris/oversized headers.
• Re-encrypt backends (Zero-Trust).
• საიდუმლოებები/გასაღებები KMS/HSM- ში; როტაცია და გაცემის აუდიტი.

დაკვირვება და ალერტები

Метрики: TLS handshakes/sec, failure rate, session resumption rate, OCSP, p95/99, open conns, CPS, RPS.
Logs: SNI/ALPN/TLS ვერსია, cipher, კლიენტის სერთიფიკატი (mTLS), upstream კოდები, latence breakdown.
ალერტები: ზრდა '5xx/525', შემცირება, 'cert _ expiry _ days', 'ocsp _ failed', ჭარბი p95, ვარდნა '429'.

ტიპიური შეცდომები

ტერმინალი ზღვარზე და plain HTTP შიგნით თავდაცვის გარეშე.
ზედმეტად გრძელი CA ჯაჭვები არის p95 handshake ზრდა.
OCSP სტაპლინგის არარსებობა კლიენტებზე/ბრაუზერებზე დაბლოკვის დროს.
Sticky სესიები, failover- ის გამოკლებით, დეგრადირებულ კვანძზე არის „ჩამოსხმა“.
0-RTT შედის ცვალებადი მოთხოვნებისა და ხელახალი მიწოდების რისკის შესახებ.
Hot-reload სერფების არარსებობა არის მეორე ფრაგმენტები როტაციის დროს.

სპეციფიკა iGaming/fintech

მწვერვალები (ტურნირები/მატჩები): TLS სესიების დათბობა (pre-connect), მოკლე ჯაჭვები, მაღალი წილი resumption, HTTP/2/3 ფრონტებისთვის.
გადახდის კარიბჭეები/PSP: mTLS, მკაცრი ciphers/ვერსიები, pinned CA, ინდივიდუალური დომენები/ALB მკაცრი წესებით.
ანტიფროგრამის/ბოტის ფილტრები: L7-rate-limit IP/ASN/Device-fingerprint, კანარის ტალღების (გამოწვევა/ქუდი) ცალკე დომენში.
მარეგულირებელი: HSTS, TLS პარამეტრების აუდიტის ჟურნალები, ვერსიების შესახებ მოხსენებები, ინციდენტებზე კლიენტის სერტების გაწვევა.

მინი ფლეიბუკები

კანარის გამოშვება L7- ბალანსის საშუალებით

1. დაამატეთ 'app-canary' მტევანი 5% წონით; 2) მიჰყევით p95/შეცდომებს; 3) 5→25→50→100%; 4) მანქანის გადამუშავება დეგრადაციის დროს.

სერტიფიკატის გადაუდებელი როტაცია

1. ატვირთეთ ახალი cert/key; 2) 'reload' კონექტორების დაცემის გარეშე (SDS/ცხელი ჩანაცვლება); 3) OCSP შემოწმება; 4) დაშბორდი p95 handshake.

HTTP/3 ჩართვა

1. გახსენით UDP/443; 2) დაამატეთ ALPN 'h3'; 3) ცალკეული მეტრიკა QUIC loss/RTT; 4) A/B მომხმარებელთა წილის მიხედვით.

შედეგი

ეფექტური SSL ტერმინი არის თანამედროვე TLS პროფილი, დასრულების სწორი ადგილი, ჭკვიანი L7 მარშრუტი, დაკვირვება და მკაცრი უსაფრთხოება (mTLS, HSTS, re-encrypt). დააფიქსირეთ ყველაფერი IaC- ში, ავტომატიზაცია მოახდინეთ როტაციებზე, გაზომეთ r95/შეცდომები და გამოიყენეთ კანარი - ასე რომ, ფრონტი გადარჩება მწვერვალებში და პროგნოზირებადი იქნება სწრაფი და უსაფრთხო.