Zero Trust сәулеті
Қысқаша түйіндеме
Zero Trust (ZT) - бұл желілік периметр енді сенімді аймақ болып есептелмейтін қауіпсіздік моделі. Әрбір сұрау салу (user → app, service → service, device → network) контекстік сигналдарды (сәйкестігі, құрылғының жай-күйі, орналасқан жері, тәуекелі, мінез-құлқы) ескере отырып, анық сәйкестендіруден, авторизациядан және шифрлаудан өтеді. Мақсаты - blast radius-ты барынша азайту, lateral movement тәуекелін азайту және комплаенсті жеңілдету.
Zero Trust базалық қағидаттары
1. Айқын сенім жоқ: сенім/VPN/ASN желісінен мұраға қалдырылмайды.
2. Қолжетімділік ең аз қажет: «тек қазір қажет нәрселерді ұсыну» саясаты.
3. Үздіксіз верификация: сессиялар мен токендер тәуекел мен контекст бойынша үнемі қайта бағаланады.
4. Компрометация болжамы: сегменттеу, бақылау, жылдам containment және кілттердің ротациясы.
5. Барлық жерде шифрлау: TLS 1. 2+/1. 3 және mTLS data-planes ішінде, 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), rate limits, DLP/бүркемелеу.
Деректер: жіктеу (Public/Confidential/Restricted), өріс деңгейінде токенизация/шифрлау.
Бақылау қабілеті: орталықтандырылған аутентификация/авторизация логтары, мінез-құлық талдауы, SLO/SLA.
Референс-сәулет (жазықтықтар бөлігінде)
Control Plane: IdP/CIAM, PDP/PEP (OPA/Envoy), саясат каталогтары, PKI/CA, құрылғыларды аттестаттау.
Data Plane: прокси-қолжетімділік (ZTNA), mTLS үшін sidecar-прокси (Envoy) және L7 саясаты, сервистік шлюздер/API GW.
Management Plane: сервистер каталогы, CMDB, CI/CD, құпия менеджмент (Vault/KMS), орталықтандырылған аудит.
1. Сәйкестендіру (SSO + phishing-resistant MFA) → 2) Құрылғыны бағалау (MDM posture) → 3) ZTNA-прокси қосымшаға mTLS орнатады → 4) PDP (саясат) атрибуттар негізінде шешім қабылдайды (ABAC/RBAC) → 5) үздіксіз тәуекелді қайта бағалау (уақыт, гео, аномалиялар).
Сәйкестендіру және авторизациялау
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 → кіру минимумы немесе блок.
Аттестаттау: device identity + signed attestations (MDM/Endpoint).
Желілік шектеулер: сыртқы туннельдер блогы, мәжбүрлі корпоративтік DNS, DNS/WebRTC ағымдарынан қорғау.
Желі және микросегментация
«Жазық» VLAN-дан бас тарту: оның орнына - сегменттер/VRF және L7-дегі саясат.
Service Mesh: sidecar-прокси mTLS, саясат бойынша авторизацияны (OPA/EnvoyFilter), телеметрияны қамтамасыз етеді.
ZTNA/SDP: желіге емес, нақты қосымшаға қол жеткізу; клиентке брокердің саясаты PDP болып табылады.
Remote Access: «қалың» VPN апп-проксиді ауыстыру; fallback-туннельдері бағыттар/порттар бойынша шектелген.
Саясат және шешімдер қозғалтқышы
PDP/PEP: Policy Decision Point (OPA/Styra, Cedar и пр.) + Policy Enforcement Point (Envoy/Istio/Gateway).
Саясат моделі: декларативтік ережелер (Rego/Cedar), статикалық және контекстік атрибуттар, тәуекелді бағалау.
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 '/' explain' логині.
Әдепкі шифрлау және сенім
TLS 1. 2+/1. 3 барлық жерде, қатаң шифр, HSTS, OCSP stapling.
mTLS ішінде: тек өзара сертификаттар бойынша қызмет; қысқа мерзімді кілттер (сағат/күн).
Құпиялар: KMS/HSM, dynamic secrets (Vault), қысқа TTL, қолданбаларға арналған least-privilege.
Бақылау, SLO және ден қою
Метрика (ең аз жиынтық):- Аутентификация мен авторизацияның табысы (%), PDP шешімін қабылдау уақыты p95, TLS-handshake.
- Саясатпен бұғатталған сұраулардың пайызы (ауытқулар/жалған).
- ZTNA брокерлері мен Mesh-контроллердің қолжетімділігі.
- Compliant құрылғылар мен трендтердің үлесі.
- "ZTNA қолжетімділігі ≥ 99. 95 %/ай; p95 authZ decision ≤ 50 мс».
- "mTLS сұраныстарының үлесі ≥ 99. 9%».
- "0 артық емес. Қол жеткізуден жалған бас тартудың 1 %/тәулік".
Алартинг: deny жарылыстары, қол алысу p95 деградациясы, халидті емес тізбектер, compliant құрылғылар үлесінің төмендеуі, география/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. Сервис-мешке кеңейту: S2S мTLS, L7 саясаты, телеметрия.
8. Автоматтандыру және SLO: алертинг, саясат тестілері (CI), "IdP қол жетімді болмаса не болады? ».
iGaming/финтех ерекшелігі
Домендердің қатаң сегментациясы: төлемдер/PII/антифрод/контент - жеке периметрлер мен саясат; тек қана ZTNA бойынша қатынау.
PSP/банктермен өзара іс-қимыл: ASN/диапазондар бойынша allow-list, PSP-эндпоинттерге mTLS, Time-to-Wallet мониторингі және authZ-де істен шығулар.
Контент жеткізушілер мен серіктестер: уақытша JIT-API қолжетімділігі, қысқа TTL токендері, интеграция аудиті.
Комплаенс: PCI DSS/GDPR - деректерді барынша азайту, DLP/псевдонимдеу, сезімтал кестелерге қол жеткізуді журналдау.
Жеткізу тізбектерінің қауіпсіздігі және CI/CD
Артефактілердің қолтаңбалары (SLSA/Provenance): контейнерлердің қолтаңбалары (cosign), K8s Admission саясаты.
SBOM және осалдықтар: SBOM (CycloneDX) генерациясы, пайплайндағы policy-gate.
CI құпиялары: OIDC-бұлтты KMS федерациясы; статикалық кілттерге тыйым салу.
Ротациялар: жиі, автоматты; оқиғалар кезінде мәжбүрлі revoke.
Типтік қателер мен қарсы үлгілер
«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-де тексеру (policy-tests).
Логи және телеметрия: OpenTelemetry → орталықтандырылған талдау, аномалиялар бөлшегі.
Конфигурация мысалдары (фрагменттер)
Envoy (сервистер арасындағы мьютуал-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: trueOPA/Rego: есептерге тек «finance» -тен, compliant-құрылғылардан, жұмыс уақытында қол жеткізу
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 және MFA FIDO2 қосу.
2. Non-compliant бұғаттауымен device posture (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. «game days» (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, орталықтандырылған саясат және өлшенетін сенімділік. Жол картасы мен чек парағын сақтай отырып, сіз шабуыл бетін азайтып, аудитті жеделдетіп, «әдепкі сенімсіз» тұрақты қауіпсіздікке қол жеткізесіз.