In Transit დაშიფვრა

In Transit დაშიფვრა

1) კონტროლის განსაზღვრა და საზღვრები

in transit- ის დაშიფვრა არის მონაცემთა დაცვა ქსელის გადაცემის მთელ გზაზე (ბრაუზერი - სერვერი, სერვისი, აგენტი - ბროკერი, მონაცემთა ბაზა, დანართი, დანართის ცენტრი) ისე, რომ პასიური ჩარევა და არხზე აქტიური შეტევები არ გაამჟღავნებს შინაარსს და არ იძლევა საშუალებას შეცვალოს იგი გამოვლენის გარეშე.

რას ვფარავთ: საჯარო და კერძო API (HTTP/HTTPS, gRPC), ნაკადი და ბროკერები (Kafka, NATS, RabbitMQ), WebSocket, ქსელის ბაზები და ქეში, მომსახურების ტრაფიკი მტევრის შიგნით, VPPPPPPPPPPPPPPPPPPPPPPPPPP- ს შორის OD და ღრუბლები, DNS მოთხოვნები, მობილური/IoT კლიენტები.

რასაც სრულად არ ვფარავთ: საბოლოო წერტილებზე თავდასხმები (მასპინძელი/ბრაუზერის კომპრომისი), აპლიკაციების დაუცველობა, გაჟონვა ლოგებიდან/დამპებიდან. ეს წყდება ცალკეული მაკონტროლებლებით (A&A, უფლებების შემცირება, დაშიფვრა, უსაფრთხო ლოჯისტიკა).

2) მუქარისა და მიზნის მოდელი

რისკები: ტრეფიკის ჩარევა/შეცვლა (MITM), პროტოკოლის/შიფრაციის შემცირება, ყალბი სერთიფიკატები/CA, გასაღების გაჟონვა, SNI/მეტამონაცემებზე თავდასხმები, შერეული შინაარსი, ბალანსებზე TLS- ის არასწორი ტერმინირება, არასასურველი ურთიერთდახმარების ნაერთები.

1. კონფიდენციალურობა + მთლიანობა კრიპტოგრაფიული ავთენტიფიკაციით.

2. დაპირისპირება (მკაცრი პოლიტიკა და კონფისკაცია).

3. მხარეთა იდენტიფიკაცია (სერვერი, საჭიროების შემთხვევაში - ურთიერთგამომრიცხავი).

4. კონტროლირებადი სასიცოცხლო ციკლი/გასაღებები და აუდიტი.

5. შესრულების პროფილი უსაფრთხოების კომპრომისის გარეშე.

3) ძირითადი პრინციპები

TLS ყველგან ნაგულისხმევია. გარე და შიდა ტრაფიკი დაშიფრულია.
თანამედროვე ვერსიები. TLS 1. 3 როგორც სტანდარტი; TLS 1. 2 - მხოლოდ მკაცრი პოლიტიკოსებით. გამორთეთ 1. 0/1. 1.
AEAD შიფროზუიტები PFS- ით. AES-GCM ან ChaCha20-Poly1305; PFS მეშვეობით (EC) DHE.
მრუდი/კეი ექსჩეინჯი. X25519 (სასურველია) ან secp256r1 (P-256). RSA გასაღებები - 2048, უკეთესია, ვიდრე ECDSA (P-256).
mTLS არის იქ, სადაც ნდობა საკმარისი არ არის. ოფშორული არხები, admin-API, ბროკერები, ბაზები - ურთიერთგაგების გზით.
HSTS ვებ - ისთვის. იძულებითი HTTPS + preload საჯარო დომენებისთვის.
„დაშიფვრა და ისევ დაშიფვრა“ შეგნებულად. ჩვენ ვირჩევთ TLS ტერმინალს პერიმეტრზე + re- დაშიფვრა ზურგჩანთებამდე ან passthrough- ის გავლით - ჩვენ ვირჩევთ საფრთხეების მოდელის მიხედვით.
Crypto-agility. მოსახვევი/სუიტის/ვერსიის ნულოვანი სისწრაფით შეცვლის შესაძლებლობა.

4) ოქმების სტეკი და სკრიპტები

4. 1 HTTP/2, HTTP/3 (QUIC), gRPC, WebSocket

ALPN: h2 HTTP/2, h3 HTTP/3; აკრძალვა h2c (TLS- ის გარეშე).
HTTP/3/QUIC: ამცირებს ლატენტობას, ჩაშენებული 0-RTT და ნაერთების მიგრაციას; 0-RTT შერჩევით დაშვება (რეპლიკის რისკი).
GRPC: h2/h3; აუცილებელია TLS, სურვილისამებრ mTLS + per-RPC ავტორიზაცია.
WebSocket: მხოლოდ ws ://; მარიონეტულ/ბალანსებში - სწორი განახლება და დომენის TLS პინინგი.

4. 2 სერვისის ტრაფიკი და მომსახურება

Sidecar მოდელი (Istio/Linkerd და ა.შ.). ავტომატური mTLS, ნებართვის პოლიტიკოსები, სერთიფიკატების როტაცია.
SPIFFE/SPIRE. სერვისების დეცენტრალიზებული იდენტურობა (SPIFFE ID), SVID სერთიფიკატები, მოკლე TTL.
TLS პარამეტრები ცენტრალიზებულია. სერვისების კოდში კონფიგურაციის შეუსაბამობის შემცირება.

4. 3 ბროკერები/ნაკადი/ხაზები

Kafka/NATS/RabbitMQ: TLS კლიენტისთვის - ბროკერი და ბროკერი - ბროკერი; თუ ეს შესაძლებელია - mTLS.
SASL TLS- ზე: თუ mTLS შეუძლებელია, ავთენტიფიკაცია ტოქსინებით/ლოგინებით, მაგრამ არხის დაშიფვრა.
ACL და თემების ავტორიზაცია. დაშიფვრა და წვდომის კონტროლი.

4. 4 მონაცემთა ბაზა და ქეში

PostgreSQL/MySQL/SQL Server: ჩართეთ TLS, CN/SAN შესაბამისობა, pin CA/ფესვი.
Redis/Memcached: გამოიყენეთ stunnel/TLS რედიტები; აკრძალვა plain ტრაფიკის გაყიდვაში.

4. 5 ქსელი/გვირაბები

მონაცემთა ცენტრს/ღრუბლებს შორის: IPsec (IKEv2) ან WireGuard (პრიმიტიული თანამედროვე ნაკრები).
Admin წვდომა: SSH თანამედროვე KEH/შიფრებით; პაროლების აკრძალვა, მხოლოდ გასაღებები/SSO.

4. 6 DNS და დამხმარე ოქმები

DNS over HTTPS (DoH )/DNS TLS (DoT) კლიენტებისთვის და კლასტერის შიგნით, სადაც შესაძლებელია.
შერეული შინაარსის გამორთვა. არაფერი http ://გვერდებზე https ://.

5) სერთიფიკატები, PKI და კლავიშების მართვა

PKI მოდელი: გარე დომენებისთვის - საზოგადოებრივი CA; შიდა ტრაფიკისთვის - საკუთარი CA ან SPIRE-CA.
ავტომატიზაცია: ACME/Cert მენეჯერი Kubernetes- ისთვის, მოკლე TTL, ავტომატური როტაცია.
OCSP stapling и CRL. ფრონტზე შეტევის ჩართვა; რეგულარულად განაახლეთ ჯაჭვები.
Pinning - სიფრთხილით. მობილური/დესკტოპის კლიენტებში - pin CA/SPKI სასწრაფო დახმარების მექანიზმით.
გასაღებების შენახვა: პირადი გასაღებები HSM/KMS/საიდუმლო საცავებში; მინიმალური ექსპოზიცია; ლოგიკის აკრძალვა.

6) კონფიგურაცია: პრაქტიკული პროფილები

• ვერსიები: TLS 1. 3 (აუცილებელია), TLS 1. 2 (fallback).

• TLS 1. 3: `TLS_AES_128_GCM_SHA256`, `TLS_AES_256_GCM_SHA384`, `TLS_CHACHA20_POLY1305_SHA256`.
• TLS 1. 2: 'ECDHE-ECDSA-AES128-GCM-SHA256', 'ECDHE-RSA-AESA 128-GCM-SHA256' (+ ვარიანტები AEEEEESSSES256/CCCCCCCCCCCCCCCCCCCCCCCAAAAAEAAAAAA
• მრუდი: X25519, secp256r1.
• სერთიფიკატები: ECDSA სასურველია, RSA-fallback.
• უსაფრთხო სათაურები: 'Strict-Transport-Security', 'X-Content-Type-Options', 'X-Frame-Options' (საქმის მიხედვით), 'Referrer-Policy'.
• Cookies: 'Secure', 'Only', 'SameSite' (დიზაინის მიხედვით Lax/Strict).

• კლიენტის სერტიფიკატი სავალდებულოა.
• მოკლე TTL კლიენტის SVID (საათი/დღეები), ავტომატური როტაცია.
• პოლიტიკოსები: ვის შეუძლია დაუკავშირდეს ვის (intent-based/მუშაობა მესის ავტორიზაციის გზით).

7) პროდუქტიულობა და საიმედოობა

აპარატურის აჩქარება: AES-NI/ARMv8 Crypto, უპირატესობა ChaCha20-Poly1305 CPU- ზე AES-NI- ს გარეშე.
Session resumption: TLS 1. 3 tickets; იფიქრეთ ცხოვრების ხანგრძლივობაზე (ბალანსი პერფსა და უსაფრთხოებას შორის).
0-RTT: მხოლოდ იდემპოტენტური მოთხოვნებისთვის; დაიცავით თავი აბრეშუმისგან (სერვერის ანტი-replay მექანიზმები).
ბალანსერები/მარიონეტები: მკაფიოდ შეარჩიეთ termination vs passthrough; termination- ით - დაშიფვრა ზურგჩანთისთვის.
Observability: ALPN ხელჩანთების/შეცდომების/მოლაპარაკებების მეტრიკა, TLS 1 პროცენტი. 3, სერთიფიკატების გასვლა, OCSP სტატუსი.

8) ტესტირება და გადამოწმება

TLS პროფილის სკანი. მხარდაჭერილი ვერსიების/სუიტის/მრუდების და HSTS/OCSP- ის რეგულარული შემოწმება.
უარყოფითი ტესტები: downgrade აკრძალვა, სუსტი სუიტის გადახრა, SNI- ს გარეშე ნაერთების უკმარისობა/ჯაჭვის მოწმობის გარეშე.
არხის პენტესტი: MITM სიმულაციები, მობილური კლიენტებში pinning შემოწმება, 0-RTT მიმღების მცდელობები.
ქაოსის ტესტები: სერტიფიკატის გადინება/მიმოხილვა, OCSP/CA მიუწვდომლობა.

9) ხშირი შეცდომები და როგორ მოვერიდოთ მათ

ჩართულია TLS, მაგრამ მასპინძლობის გარეშე. ჩვენ ყოველთვის ვამოწმებთ CN/SAN- ს, კრძალავს 'InsecureSkipVerify'.
შერეული შინაარსი. დაბლოკეთ http რესურსები https გვერდებზე, გამოიყენეთ CSP.
სუსტი/მოძველებული ვერსიები და სუპერ. გამორთეთ TLS 1. 0/1. 1, CBC/RC4/3DES.
R- დაშიფვრის არარსებობა შიგნით. ბალანსიდან განაცხადამდე შეღავათიანი ტრაფიკი რისკია.
გრძელი სერთიფიკატები. გააკეთეთ მოკლე TTL და მანქანის განახლება.
არასწორი SNI/ALPN მარიონეტებისთვის. სწორი SNI/ALPN გადაცემა TLS-pass-tru/ტერმინალში.

10) მინი რეცეპტები (კონფიგურაციის ფრაგმენტები)

ssl_protocols      TLSv1. 3 TLSv1. 2;
ssl_ciphers       TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve     X25519:P-256;
ssl_stapling      on;
ssl_stapling_verify   on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

transport_socket:
name: envoy. transport_sockets. tls typed_config:
"@type": type. googleapis. com/envoy. extensions. transport_sockets. tls. v3. DownstreamTlsContext common_tls_context:
tls_params:
tls_minimum_protocol_version: TLSv1_3 validation_context:
trusted_ca: { filename: /etc/tls/ca. crt }
tls_certificates:
certificate_chain: { filename: /etc/tls/tls. crt }
private_key:   { filename: /etc/tls/tls. key }
require_client_certificate: true

[Interface]
PrivateKey = <priv>
Address  = 10. 10. 0. 1/24
[Peer]
PublicKey = <pub>
AllowedIPs = 10. 10. 0. 0/24
Endpoint  = gw. example. com:51820
PersistentKeepalive = 25

11) პოლიტიკა და შესაბამისობა

მინიმალური მოთხოვნები: TLS 1. 3 ყველგან, სადაც შესაძლებელია; TLS 1. 2 - შეზღუდული რაოდენობით სუიტებით.
მარეგულირებელი: PCI DSS/ფინანსური სექტორი - სუსტი ვერსიების/სუიტის აკრძალვა; სავალდებულო როტაცია და აუდიტი.
Zero Trust მიდგომა: იდენტურობა თითოეული სამუშაო დატვირთვისთვის, უწყვეტი შემოწმება და პოლიტიკა მომსახურების დონეზე.

12) ოპერაცია და SLO

SLO: წარმატებული ხელჩანთების 99% -ზე მეტი, TLS 1-ზე ტრაფიკის 95%. შერეული შინაარსის 3, 0%.
ალერტა: სერთიფიკატების გადინება (<14 დღე), ხელჩანთების უკმარისობის ზრდა, TLS 1-ის წილის ვარდნა. 3, OCSP შეცდომები.
პროცედურები: SA/ფესვის გადაუდებელი ჩანაცვლება, კომპრომეტირებული გასაღების გაწვევა, 0-RTT გამორთვა.

13) ჩეკის ფურცლები

• გამორთულია TLS 1. 0/1. 1 და სუსტი ლუქსი, შედის AEAD და PFS.
• ALPN მორგებულია (h2/h3); აკრძალვა h2c.
• HSTS ჩართულია (საჯარო დომენებისთვის), mixed შინაარსი არ არის.
• ავტომობილების სერთიფიკატები განახლებულია, OCSP stapling მუშაობს.
• შიდა არხები დაცულია mTLS (ან WireGuard/IPsec ეკვივალენტი).
• შემოწმებულია მასპინძელთა/კლიენტთა ჯაჭვების/SDK.

• TLS/ALPN/შეცდომების და გაფართოების ვერსიების მონიტორინგი.
• crypto-agility გეგმა (თარგმნა ახალი suites/crooks).
• არხის პერიოდული პენტესტები და ჩამორთმევის შურისძიება.

14) FAQ

გ: საკმარისია TLS მხოლოდ პერიმეტრზე?
ო: არა. შიდა ტრაფიკი ასევე უნდა იყოს დაშიფრული (mTLS/გვირაბები/mesh), განსაკუთრებით ღრუბლებში და მრავალმხრივ.

გ: გჭირდებათ 0-RTT?
O: ჩართეთ წერტილოვანი იდემპოტენტური მოთხოვნებისთვის, წინააღმდეგ შემთხვევაში - გამორთეთ ფრჩხილის რისკის გამო.

გ: რა უნდა აირჩიოთ მონაცემთა ცენტრს შორის? IPsec ან WireGuard?
ო: WireGuard უფრო მარტივი და სწრაფია, IPsec არის სექსუალური და ფართოდ მხარდაჭერილი. ორივე დასაშვებია სწორი კონფიგურაციით.

გ: როგორ დავიცვათ ვებჰუკები „გზაზე“?
O: HTTPS თანამედროვე პროფილით + გამგზავნის სერტიფიკატის შემოწმება (თუ mTLS) + დატვირთვის ხელმოწერა და დროის სტამპის შემოწმება (იხ. „ვებ ჰუკების მიწოდების გარანტიები“, „მოთხოვნა ხელმოწერა და გადამოწმება“).

• „დაშიფვრა At Rest“
• „ავთენტიფიკაცია და ავტორიზაცია“
• „მოთხოვნის ხელმოწერა და გადამოწმება“
• „S2S ავთენტიფიკაცია“
• „კლავიშების მართვა და როტაცია“