Zero Trust არქიტექტურა

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

Zero Trust (ZT) არის უსაფრთხოების მოდელი, რომელშიც ქსელის პერიმეტრი აღარ განიხილება სანდო ზონად. თითოეული მოთხოვნა (app, სერვისი, მომსახურება, მოწყობილობა და ქსელი) გადის აშკარა ავთენტიფიკაციას, ავტორიზაციას და დაშიფვრას კონტექსტური სიგნალების გათვალისწინებით (თვითმყოფადობა, მოწყობილობის მდგომარეობა, ადგილმდებარეობა, რისკი, ქცევა). მიზანია blast radius- ის შემცირება, ლათინური მოძრაობის რისკის შემცირება და შესაბამისობის გამარტივება.

Zero Trust- ის ძირითადი პრინციპები

1. აშკარა ნდობა არ არსებობს: ნდობა მემკვიდრეობით არ მიიღება ქსელიდან/VPN/ASN.
2. მინიმალური წვდომა აუცილებელია: პოლიტიკა „უზრუნველყოს მხოლოდ ის, რაც ახლა საჭიროა“.
3. უწყვეტი გადამოწმება: სესიები და ნიშნები რეგულარულად გადაჭარბებულია რისკის და კონტექსტის თვალსაზრისით.
4. კომპრომისის ვარაუდი: სეგმენტი, დაკვირვება, სწრაფი შინაარსი და გასაღებების როტაცია.
5. დაშიფვრა ყველგან: TLS 1. 2+/1. 3 და mTLS DNS- ის მიერ დაცული მონაცემთა პლანეტების შიგნით, საიდუმლოებები KMS/HSM- ში.

სამიზნე ლანდშაფტი და საკონტროლო დომენები

თვითმყოფადობა: ადამიანები (IDP: SSO, MFA, passkeys/FIDO2), მანქანები (SPIFFE/SVID, x509/mTLS).
მოწყობილობები: კორესპონდენცია პოლიტიკოსებისთვის (MDM/EDR, დისკი დაშიფრულია, პატჩი, jailbreak/root - აკრძალულია).
ქსელი: მიკრო გაცვლითი L3/L7, ZTNA/SDP კარიბჭეები, თვის მომსახურება (Envoy/Istio/Linkerd).
პროგრამები/API: mTLS, OIDC/JWT, მოთხოვნის ხელმოწერები (HMAC), საბაზო ლიმიტები, DLP/ნიღაბი.
მონაცემები: კლასიფიკაცია (Public/Confidential/Restricted), ტოკენიზაცია/დაშიფვრა ველების დონეზე.
დაკვირვება: ავტორიზაციის/ავტორიზაციის ცენტრალიზებული ლოგოები, ქცევითი ანალიტიკა, SLO/SLA.

რეფერენდუმი-არქიტექტურა (თვითმფრინავების კონტექსტში)

Control Plane: IDP/CIAM, PDP/PEP (OPA/Envoy), პოლიტიკის კატალოგები, PKI/CA, მოწყობილობების სერტიფიკაცია.
Data Plane: მარიონეტული წვდომა (ZTNA), mTLS და L7 პოლიტიკა, სერვისის კარიბჭეები/API GW.
მენეჯმენტის გეგმა: სერვისების კატალოგი, CMDB, CI/CD, საიდუმლო მენეჯმენტი (Vault/KMS), ცენტრალიზებული აუდიტი.

მოთხოვნის ნაკადი:

1. იდენტიფიკაცია (SSO + phishing-resistant MFA) - 2) მოწყობილობის შეფასება (MDM posture) (3) ZTNA მარიონეტული ადგენს mTLS- ს დანართისთვის (4) PDP (პოლიტიკა) იღებს გადაწყვეტილებას ატრიბუტების საფუძველზე (ABBBAAC C OOOAAAAC C C AAAD D D D CAAAAD D D AD AAAD D D D D D D რისკის გადაფასება (დრო, გეო, ანომალია).

თვითმყოფადობა და ავტორიზაცია

IDP/SSO: OIDC/SAML, MFA ნაგულისხმევი, სასურველია FIDO2 (passkeys).
RBAC/ABAC: როლები + კონტექსტის ატრიბუტები (მოწყობილობის სტატუსი, განყოფილება, რისკის პროფილი).
Just-In-Time (JIT) წვდომა: დროებითი პრივილეგიები ავტომატური მიმოხილვით; break glass მკაცრად რეგულირდება.
mTLS მანქანებისთვის: SPIFFE/SVID ან შიდა PKI მოკლე სერთიფიკატებით; ავტომატური როტაციის საკითხი.

მოწყობილობები და კონტექსტი

შესაბამისობის შემოწმება (posture): OS/EDR ვერსია, ჩართულია დისკი, firewall; non-compliant - წვდომა მინიმუმამდე ან ბლოკში.
სერთიფიკატი: მოწყობილობის იდენტურობა + უხეში ატესტაცია (MDM/Endpoint).
ქსელის შეზღუდვები: მესამე მხარის გვირაბების ბლოკი, იძულებითი კორპორატიული DNS, დაცვა DNS/WebRTC გაჟონვისგან.

ქსელი და მიკროსემენტაცია

„ბრტყელი“ VLAN- ის უარყოფა: ამის ნაცვლად - სეგმენტები/VRF და პოლიტიკა L7- ზე.
Service Mesh: sidecar მარიონეტული უზრუნველყოფს mTLS- ს, პოლიტიკის ავტორიზაციას (OPA/EnvoyFilter), ტელემეტრიას.
ZTNA/SDP: სპეციფიკური აპლიკაციის წვდომა და არა ქსელი; კლიენტი - ბროკერი - აპი, პოლიტიკა PDP- ში.
Remote Access: „სქელი“ VPN ჩანაცვლება app მარიონეტული; fallback გვირაბები შემოიფარგლება მარშრუტებით/პორტებით.

პოლიტიკა და გადაწყვეტილებების ძრავა

PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
პოლიტიკის მოდელი: დეკლარაციული წესები (Rego/Cedar), სტატიკური და კონტექსტური ატრიბუტები, რისკის შეფასება.

Rego- ს მაგალითი (გამარტივებული):

rego package access. http

default allow = false

allow {
input. user. role == "support"
input. request. path == "/admin/tickets"
input. device. compliant == true time. now_hh >= 8 time. now_hh <= 20
}

გადაწყვეტილებების კვალი: აუდიტის 'input '/' result '/' expain'.

დაშიფვრა და ნდობა

TLS 1. 2+/1. 3 ყველგან, მკაცრი შიფროსუიტები, HSTS, OCSP სტაპლინგი.
mTLS შიგნით: მომსახურება მომსახურებას მხოლოდ ურთიერთსერთიფიკატებისთვის; მოკლე გასაღებები (საათი/დღეები).
საიდუმლოებები: KMS/HSM, დინამიური საიდუმლოებები (Vault), მოკლე TTL, დაბალი პრიორიტეტი პროგრამებისთვის.

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

მეტრიკა (მინიმალური ნაკრები):

ავტორიზაციის და ავტორიზაციის წარმატება (%), PDP გადაწყვეტილების მიღების 95, p95 TLS-handshake.
პოლიტიკის მიერ დაბლოკილი მოთხოვნების პროცენტი (ანომალიები/ყალბი).
ZTNA ბროკერებისა და მესის კონტროლერის ხელმისაწვდომობა.
კომპლექსის მოწყობილობების წილი და ტენდენციები.

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

"ZTNA წვდომა 99. 95 %/თვე; p95 authZ decision ≤ 50 мс».
"მოთხოვნის წილი mTLS- ით არის 99. 9%».
"არა უმეტეს 0. 1% ყალბი წვდომა დღეში."

ალარინგი: დენის აურზაური, p95 ხელის დაჭერის დეგრადაცია, არასტაბილური ჯაჭვები, მცენარეთა მოწყობილობების წილის ვარდნა, გეოგრაფიის ანომალიები/ASN.

პერიმეტრიდან გადასვლა Zero Trust: საგზაო რუკა

1. ინვენტარიზაცია: პროგრამები, მონაცემთა ნაკადები, მომხმარებლები, მგრძნობელობა (PII/ბარათები/გადახდები).
2. პირადობა და MFA: SSO და phishing-resistant MFA ყველასთვის.
3. მოწყობილობების კონტექსტი: MDM/EDR, ძირითადი შესაბამისობის პოლიტიკოსები, non-compliant ბლოკი.
4. პრიორიტეტული მარშრუტების მიკროსპექტირება: გადახდები, სარეზერვო ოფისი, ადმინისტრაციული განყოფილება; MTLS შეყვანა.
5. ZTNA მომხმარებლის წვდომისთვის: აპლიკაციების გამოქვეყნება მარიონეტული გზით, ამოიღეთ „ფართო VPN“.
6. ABAC პოლიტიკოსები: ცენტრალიზებული PDP, დეკლარაციული წესები, აუდიტი.
7. გაფართოება mesh სერვისზე: S2S mTLS, L7 პოლიტიკა, ტელემეტრია.
8. ავტომატიზაცია და SLO: ალერტინგი, პოლიტიკოსის ტესტები (პოლიტიკური CI), თამაშის დღეები "რომ თუ IDP არ არის ხელმისაწვდომი? ».

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

დომენების მკაცრი სეგმენტი: გადახდა/PII/ანტიფროდიული/შინაარსი - ინდივიდუალური პერიმეტრები და პოლიტიკა; წვდომა მხოლოდ ZTNA- სთვის.
ურთიერთქმედება PSP/ბანკებთან: allow-list ASN/bands, mTLS PSP endpoints, Time-to-Wallet- ის მონიტორინგი და authZ- ზე უარის თქმა.
შინაარსის მომწოდებლები და პარტნიორები: დროებითი JIT წვდომა API- ზე, ნიშნები მოკლე TTL- ით, ინტეგრაციის აუდიტი.
შესაბამისობა: PCI DSS/GDPR - მონაცემთა შემცირება, DLP/ფსევდონიზაცია, მგრძნობიარე ცხრილებზე წვდომის ჟურნალირება.

მიწოდების ჯაჭვების უსაფრთხოება და CI/CD

არტეფაქტების ხელმოწერები (SLSA/Provenance): კონტეინერების ხელმოწერები (კოდირება), ადმისიის პოლიტიკა K8s- ში.
SBOM და დაუცველობა: SBOM (CycloneDX) წარმოება, პოლიცია-კარიბჭე.
საიდუმლოებები CI- ში: OIDC ფედერაცია ღრუბლოვანი KMS- სთვის; სტატიკური გასაღებების აკრძალვა.
როტაციები: ხშირი, ავტომატური; იძულებითი რეაგირება ინციდენტების დროს.

ტიპიური შეცდომები და საწინააღმდეგო ნიმუშები

„ZTNA = ახალი VPN“: ქსელის გამოქვეყნება პროგრამების ნაცვლად არ არის Zero Trust.
მოწყობილობების გადამოწმება არ არსებობს: MFA არის, მაგრამ ინფიცირებული/რუტინული მოწყობილობები ხელმისაწვდომია.
ერთი სუპერ მომხმარებელი: JIT- ის არარსებობა და ცალკეული როლები.
მომსახურების კოდის პოლიტიკა: ცენტრალიზებული აუდიტის/განახლების შეუძლებლობა.
mTLS ნაწილობრივი: ზოგიერთი მომსახურება mTLS- ის გარეშე - „გაჟღენთილი“ კონტური.
ნულოვანი UX: MFA- ს გადაჭარბებული მოთხოვნები, SSO- ს ნაკლებობა; შედეგი გუნდების წინააღმდეგობაა.

მინი ჰაიდი ტექნოლოგიის არჩევისთვის

მომხმარებლის დაშვება: ZTNA/SDP ბროკერი + IDP (OIDC, FIDO2 MFA).
შიდა სერვისის უსაფრთხოება: მესის მომსახურება (Istio/Linkerd) + OPA/Envoy authZ.
PKI: SPIFFE/SVID ან Vault PKI მოკლე TTL.
პოლიტიკოსები: OPA/Rego ან Cedar; შეინახეთ Git, შეამოწმეთ CI (პოლიცია-ტესტი).
ლოგოები და ტელემეტრია: OpenTelemetry - ცენტრალიზებული ანალიზი, ანომალიების დეტალი.

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

Envoy (Mutual-TLS მომსახურებებს შორის)

yaml static_resources:
listeners:
- name: listener_https 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 route_config: { name: local_route, virtual_hosts: [] }
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_2 }
tls_certificates:
- certificate_chain: { filename: /certs/tls. crt }
private_key: { filename: /certs/tls. key }
validation_context:
trusted_ca: { filename: /certs/ca. crt }
require_signed_certificate: true

OPA/Rego: ანგარიშებზე წვდომა მხოლოდ „ფინანსიდან“, კომპლექსური მოწყობილობებიდან, სამუშაო საათებში

rego package policy. reports

default allow = false

allow {
input. user. dept == "finance"
input. device. compliant == true input. resource == "reports/profit"
time. now_hh >= 8 time. now_hh <= 21
}

Zero Trust- ის განხორციელების შემოწმების სია

1. ჩართეთ SSO და FIDO2 MFA ყველა მომხმარებლისთვის და ადმირალისთვის.
2. შეიყვანეთ მოწყობილობის ფოსტა (MDM/EDR) არონ-ქარხნის ბლოკირებით.
3. მომხმარებლის წვდომის გადაცემა ZTNA- ზე (per-app), დატოვეთ VPN მხოლოდ ვიწრო S2S არხებისთვის.
4. შიგნით - mTLS ნაგულისხმევი + მოკლემეტრაჟიანი სერთიფიკატები.
5. პოლიტიკის ცენტრალიზაცია (PDP/OPA), შენახვა Git- ში, ტესტირება CI- ში.
6. მგრძნობიარე დომენების სეგმენტი (გადახდები/PII/სარეზერვო ოფისი) და შეზღუდეთ east west.
7. ტელემეტრიის, SLO და ალერტინგის კონფიგურაცია auth/authZ, mTLS წილი, posture სიგნალები.
8. გამართეთ „თამაშის დღეები“ (IDP უკმარისობა, გასაღების გაჟონვა, ბროკერის დაცემა) და დაფიქსირდა SOP/გამოტოვება.

FAQ

Zero Trust შეცვლის VPN მთლიანად?
მომხმარებლის წვდომისთვის - დიახ, ZTNA- ს სასარგებლოდ. S2S მაგისტრალებისთვის VPN/IPsec შეიძლება დარჩეს, მაგრამ mTLS- ით თავზე და მკაცრი პოლიტიკოსებით.

შეუძლია თუ არა ZT- ს გაუარესდეს UX?
თუ დაუფიქრებლად. SSO + FIDO2- ით, ადაპტირებული MFA და per-app UX დაშვება ჩვეულებრივ უმჯობესდება.

აუცილებელია მომსახურების მესის დანერგვა?
ყოველთვის არა. მაგრამ დიდი მიკრო სერვისის გარემოსთვის, mesh რადიკალურად ამარტივებს mTLS/პოლიტიკას/ტელემეტრიას.

შედეგი

Zero Trust არ არის პროდუქტი, არამედ არქიტექტურული დისციპლინა: იდენტურობა, როგორც ახალი პერიმეტრი, მოწყობილობების კონტექსტი, თანდართული წვდომა (ZTNA), მიკრო გაცვლითი და mTLS ყველგან, ცენტრალიზებული პოლიტიკოსები და გაზომილი საიმედოობა. საგზაო რუქისა და შემოწმების ჩამონათვალის შემდეგ, თქვენ შეამცირებთ თავდასხმის ზედაპირს, დააჩქარებთ აუდიტს და მიიღებთ სტაბილურ უსაფრთხოებას „ნაგულისხმევი ნდობის“ გარეშე.