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 маалымат пландары ичинде, DNS корголгон, KMS/HSM сырлар.

Максаттуу пейзаж жана контролдоо домендери

Id: адамдар (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/masking.
Маалыматтар: классификация (Public/Confidential/Restricted), tokenization/талаа денгээлде шифрлөө.
Байкоо: борборлоштурулган аутентификация/авторизация логдору, жүрүм-турум аналитикасы, SLO/SLA.

Референс-архитектура (тегиздиктер боюнча)

Control Plane: IdP/CIAM, PDP/PEP (OPA/Envoy), саясат каталогдору, PKI/CA, түзмөктөрдү тастыктоо.
Data Plane: Proxy-Access (ZTNA), mTLS үчүн sidecar-Proxy (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-proxy 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 (жөнөкөй):

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 ичинде: өз ара күбөлүктөр боюнча гана кызмат; кыска ачкычтар (саат/күн).
Secrets: KMS/HSM, dynamic secrets (Vault), кыска TTL, тиркемелер үчүн least-privilege.

Байкоо, SLO жана жооп

Метрика (минималдуу топтому):

Ийгилик аутентификация жана авторизация (%), p95 PDP чечим кабыл алуу убактысы, p95 TLS-handshake.
Саясат тарабынан бөгөттөлгөн суроо-талаптардын пайызы (аномалиялар/жалган).
Жеткиликтүү ZTNA брокерлер жана Mesh-контроллер.
compliant түзмөктөр жана тенденциялар үлүшү.

SLO (мисалдар):

"ZTNA жеткиликтүүлүгү ≥ 99. 95 %/ай; p95 authZ decision ≤ 50 мс».
"mTLS менен суроо үлүшү ≥ 99. 9%».
"0 ашык эмес. 1 %/күнүнө кирүүдөн жалган баш тартуу".

Алартинг: Дени жарылуулары, кол алышуу p95 деградациясы, нөлдүк чынжырлар, compliant түзмөктөрдүн үлүшүнүн төмөндөшү, географиялык аномалиялар/ASN.

Периметрден Нөлгө өтүү: жол картасы

1. Инвентаризация: тиркемелер, маалыматтардын агымы, керектөөчүлөр, сезгичтик (PII/карта/төлөмдөр).
2. Идентификация жана MFA: SSO жана phishing-resistant MFA бардыгы үчүн.
3. түзмөктөрдүн контекст: MDM/EDR, негизги шайкештик саясаты, non-compliant бирдиги.
4. Артыкчылыктуу жолдордун микросегментациясы: төлөмдөр, бэк-кеңсе, админка; mTLS киргизүү.
5. ZTNA колдонуучу жетүү үчүн: прокси аркылуу колдонмолорду жарыялоо, "кенен VPN" алып салуу.
6. ABAC саясаты: борборлоштурулган PDP, декларативдик эрежелер, аудит.
7. Service-мешке кеңейтүү: S2S mTLS, L7 саясаты, телеметрия.
8. Автоматташтыруу жана SLO: Алертинг, саясат тесттер (саясий CI), оюн күндөрү "IdP жок болсо эмне болот? ».

iGaming/Fintech үчүн өзгөчөлүктөрү

Катуу домендерди сегментациялоо: төлөмдөр/PII/антифрод/мазмун - өзүнчө периметрлер жана саясат; ZTNA аркылуу гана жеткиликтүү.
PSP/банктар менен өз ара аракеттенүү: ASN/диапазондору боюнча allow-list, PSP-endpoints үчүн mTLS, authZ боюнча Time-to-Wallet мониторинг жана баш тартуу.
Мазмун жөнөтүүчүлөр жана өнөктөштөр: Убактылуу JIT APIге жетүү, кыска TTL токендери, интеграция аудити.
Комплаенс: PCI DSS/GDPR - маалыматтарды минималдаштыруу, DLP/псевдонимдештирүү, сезгич таблицаларга кирүү мүмкүнчүлүгүн каттоо.

Коопсуздук жеткирүү чынжыр жана CI/CD

Артефакттардын кол тамгалары (SLSA/Provenance): контейнерлердин кол тамгалары (cosign), K8s Admission саясаты.
SBOM жана алсыздыгы: SBOM генерациясы (CycloneDX), policy-gate pipeline.
CI сырлары: OIDC булут KMS үчүн Киргизия; статикалык ачкычтарга тыюу салуу.
Rotation: тез-тез, автоматтык; окуяларга аргасыз revoke.

Типтүү каталар жана анти-үлгүлөрү

"ZTNA = жаңы VPN": колдонмолордун ордуна тармакты жарыялоо - Zero Trust эмес.
Эч кандай түзмөктөрдү текшерүү: MFA бар, бирок жуккан/Ruted түзмөктөр мүмкүнчүлүк алышат.
Бирдиктүү супер-колдонуучу: 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: true

OPA/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. Киргизүү device posture (MDM/EDR) non-compliant кулпу менен.
3. ZTNA (per-app) үчүн колдонуучунун жетүү которуу, тар S2S каналдар үчүн гана VPN калтыруу.
4. Ичинде - mTLS демейки + кыска мөөнөттүү күбөлүктөр.
5. саясат борборлоштуруу (PDP/OPA), Git сактоо, CI сыноо.
6. Сезгич домендерди сегменттөө (төлөмдөр/PII/бэк-кеңсе) жана чыгыш-батышты чектөө.
7. auth/authZ, mTLS үлүшү, posture сигналдары боюнча телеметрия, SLO жана алертинг орнотуу.
8. "Оюн күндөрдү" өткөрүү (IdP баш тартуу, ачкычтарды агып чыгуу, брокердин кулашы) жана SOP/артка кайтарууларды оңдоо.

FAQ

Zero Trust толугу менен VPN алмаштырат?
Колдонуучу жетүү үчүн - ооба, ZTNA пайдасына. S2S-магистралдары үчүн VPN/IPsec калышы мүмкүн, бирок mTLS жана катуу саясатчылар менен.

ZT UX начарлатышы мүмкүнбү?
ойлонбой болсо. SSO + FIDO2, адаптивдүү MFA жана per-app UX жетүү менен адатта жакшырат.

Сервис-мешти киргизүү зарылбы?
Дайыма эле эмес. Бирок ири микросервис чөйрө үчүн, сетка түп-тамырынан mTLS/саясат/телеметрия жөнөкөйлөтөт.

Жыйынтык

Zero Trust - бул продукт эмес, архитектуралык тартип: жаңы периметри, түзмөктөрдүн контексти, тиркемелик жеткиликтүүлүк (ZTNA), микросегментация жана бардык жерде mTLS, борборлоштурулган саясат жана өлчөнүүчү ишенимдүүлүк. Жол картасын жана чек баракчасын ээрчип, сиз кол салуу бетин азайтып, аудитти тездетип, "демейки ишеним" жок туруктуу коопсуздукту аласыз.