Zero Trust

Zero Trust — модель информационной безопасности, основанная на принципе отсутствия автоматического доверия к пользователю, устройству или сетевому сегменту только из-за того, что они находятся внутри корпоративной инфраструктуры.

Вместо подхода «внутренняя сеть доверенная, внешняя — опасная» Zero Trust предполагает постоянную проверку Identity, прав, состояния устройства и контекста каждого запроса на доступ.

Главная идея формулируется как «never trust, always verify» — не доверять автоматически и проверять доступ на основании актуальных данных.

Zero Trust — это не один продукт и не отдельный Firewall, а архитектурный подход к управлению доступом, при котором доверие минимизируется, а права предоставляются только после проверки конкретного запроса.

Что такое Zero Trust простыми словами

В традиционной сети пользователь, подключившийся к корпоративному VPN, часто получает широкий доступ к внутренним ресурсам.

Zero Trust меняет модель:

User requests access
↓
Verify identity
↓
Check device
↓
Check policy and risk
↓
Allow only required resource

Даже сотрудник компании должен подтвердить, кто он, с какого устройства работает и действительно ли ему нужен доступ к конкретному приложению.

Почему появилась концепция Zero Trust

Современная инфраструктура перестала ограничиваться одним офисом и локальной сетью.

Компании используют:

• Cloud;
• SaaS;
• Remote Work;
• Mobile Devices;
• Contractors;
• Microservices;
• Hybrid Infrastructure.

Поэтому граница между «внутри» и «снаружи» стала менее очевидной.

Проблема традиционного периметра

Классическая модель часто строилась так:

Internet
↓ Firewall
Trusted internal network
↓
Servers and users

Если злоумышленник преодолевал внешний периметр или получал VPN Credentials, он мог оказаться в относительно доверенной внутренней среде.

Zero Trust и сетевой периметр

Zero Trust не означает отказ от Firewall, VPN или сегментации.

Он означает, что само нахождение пользователя внутри сети не является достаточным основанием для доступа.

Основные принципы Zero Trust

Практическая архитектура обычно строится вокруг нескольких идей:

• явная проверка каждого доступа;
• Least Privilege;
• минимизация постоянного доверия;
• сегментация;
• контроль Identity и Device;
• постоянный Monitoring;
• предположение о возможной компрометации.

Verify Explicitly

Доступ должен предоставляться на основании проверяемых сигналов.

Например:

User = employee-125
Role = accountant
Device = managed
MFA = passed
Risk = low
→ allow finance application

Одного IP Address или факта подключения через корпоративную сеть недостаточно.

Least Privilege

Пользователь получает только те Permissions, которые нужны для текущей работы.

Например, бухгалтеру может быть разрешен доступ к 1С и финансовому документообороту, но не к административной панели Kubernetes.

Assume Breach

Zero Trust исходит из предположения, что отдельный User, Device или Network Segment может быть уже скомпрометирован.

Архитектура должна ограничить масштаб возможного ущерба.

Blast Radius

Blast Radius — масштаб систем и данных, которые могут быть затронуты после компрометации одного объекта.

Zero Trust стремится уменьшить его через сегментацию и минимальные права.

Identity как новая граница

В Zero Trust важнейшей точкой принятия решения становится Identity.

Система должна понимать:

• кто пользователь;
• какую Role он имеет;
• какое приложение запрашивает;
• с какого Device выполняется вход;
• каков текущий Risk.

Zero Trust и IAM

IAM является фундаментальным компонентом Zero Trust.

IAM управляет Identities, Roles и Policies, а Zero Trust использует эти данные для принятия решений о доступе.

Zero Trust и MFA

MFA усиливает Authentication и снижает вероятность входа по одному украденному Password.

В Zero Trust второй фактор особенно важен для:

• Remote Access;
• Administrators;
• Cloud Console;
• критичных приложений;
• подозрительных Logins.

Zero Trust и 2FA

2FA может быть частью Zero Trust Policy, но сама по себе не создает Zero Trust Architecture.

Нужны также Authorization, Device Security, сегментация и Monitoring.

Zero Trust и SSO

SSO централизует Authentication и позволяет применять единые Security Policies через Identity Provider.

Это облегчает реализацию Zero Trust, потому что компания получает центральную точку проверки Identity.

Conditional Access

Conditional Access позволяет учитывать контекст запроса.

Например:

Managed device + MFA + normal location → allow
Unknown device + high risk → deny

Решение становится динамическим, а не постоянным.

Контекст доступа

Zero Trust Policy может учитывать:

Device Trust

Identity пользователя — не единственный фактор.

Даже легитимный сотрудник может работать с зараженного или неуправляемого устройства.

Поэтому система может проверять Device Posture.

Device Posture

Device Posture — текущее состояние безопасности устройства.

Проверяться могут:

• наличие EDR;
• Disk Encryption;
• актуальность OS;
• корпоративное управление;
• наличие критичных Vulnerabilities;
• Risk Score.

Zero Trust и EDR

EDR предоставляет информацию о состоянии Endpoint.

Если на Notebook обнаружен Malware, его Risk может повыситься, а IAM временно ограничит доступ к критичным системам.

EDR detects compromise
↓
Device risk = high
↓
Access denied

Zero Trust и XDR

XDR объединяет Endpoint, Identity, Email, Cloud и Network Events.

Эти сигналы могут использоваться для более точной оценки риска доступа.

Zero Trust и SIEM

SIEM собирает события Authentication, Authorization и Network Access.

Security Team анализирует, насколько корректно работают Zero Trust Policies и не происходит ли их обход.

Zero Trust и SOC

SOC расследует события, которые могут влиять на доверие к User или Device.

Например, необычный Login, Malware Detection и попытка доступа к финансовому сервису могут быть объединены в один Incident.

Zero Trust и Network Segmentation

Сегментация ограничивает перемещение между ресурсами.

Если Workstation скомпрометирована, злоумышленник не должен автоматически видеть все Servers.

Microsegmentation

Microsegmentation делит инфраструктуру на небольшие Security Zones и применяет точные Policies между ними.

Web → API : allow 443
API → Database : allow 5432
User PC → Database : deny

Так ограничивается Lateral Movement.

Zero Trust и VLAN

VLAN может быть частью сегментации, но сама VLAN не является Zero Trust.

Необходимы Policies, определяющие, кто и к какому Resource может обращаться.

Zero Trust и Firewall

Firewall остается важным элементом контроля Network Traffic.

Но правило вида «вся внутренняя сеть может обращаться ко всем серверам» противоречит принципу минимального доступа.

Identity-aware Firewall

Современная Access Policy может учитывать не только Source IP, но и User, Device или Application Identity.

Это делает сетевой контроль более контекстным.

Zero Trust и VPN

VPN создает защищенный Network Tunnel, но часто предоставляет доступ к целому сегменту сети.

Zero Trust стремится предоставлять доступ не к сети вообще, а к конкретному Resource.

ZTNA

ZTNA, или Zero Trust Network Access, — подход к удаленному доступу, при котором пользователь получает доступ к конкретным Applications, а не ко всей внутренней сети.

User
↓ identity + device check
ZTNA gateway
↓
Allowed application only

ZTNA и VPN

Конкретные возможности зависят от используемой архитектуры, поэтому ZTNA не всегда является полной заменой VPN во всех сценариях.

Zero Trust и Reverse Proxy

Identity-aware Reverse Proxy может находиться перед внутренним Web Application и проверять User до передачи Request Backend.

Так старое приложение получает дополнительный слой Access Control без полной переделки Authentication.

Zero Trust и API Gateway

API Gateway может проверять Access Token, Scope и Client Identity перед вызовом Backend.

Это один из способов реализовать Policy Enforcement для API.

Policy Enforcement Point

Policy Enforcement Point — компонент, который непосредственно разрешает или запрещает Access Request.

Это может быть Gateway, Proxy, Firewall или Application.

Policy Decision Point

Policy Decision Point принимает решение на основании Identity, Attributes и Context.

Логически:

Request
↓
Policy decision
↓
Allow / Deny

Policy Engine

Policy Engine оценивает условия и формирует решение.

Например, Administrator Access разрешается только с Managed Device и после Phishing-resistant MFA.

Continuous Evaluation

Zero Trust не должен ограничиваться только проверкой в момент Login.

Risk может измениться во время уже активной Session.

Например, EDR обнаруживает Malware через 30 минут после входа пользователя.

Динамический отзыв доступа

При повышении Risk система может:

• потребовать Reauthentication;
• отозвать Session;
• заблокировать Access;
• ограничить Permissions;
• изолировать Device.

Zero Trust и Session

Долгоживущая Session может сохранять доступ после изменения Risk.

Поэтому Session Lifetime и Revocation являются важной частью архитектуры.

Zero Trust и OAuth

OAuth позволяет выдавать ограниченные Access Tokens с конкретными Scopes.

Это хорошо соответствует принципу Least Privilege.

Zero Trust и JWT

JWT может передавать Identity и Access Context между Services.

Но Resource Server должен проверять Signature, Issuer, Audience, Expiration и Permissions.

Сам факт наличия JWT не означает автоматического доверия.

Short-lived Credentials

Zero Trust предпочитает уменьшать использование постоянных Credentials.

Например, вместо постоянного Administrator Key можно выдавать временный Access Token.

Just-in-Time Access

JIT Access предоставляет повышенные права только тогда, когда они действительно нужны.

Admin request
↓ approval
Temporary role
↓ expires automatically

Так сокращается время существования Privileged Access.

Just Enough Access

Пользователь получает не полный Administrator Role, а только конкретные действия, необходимые для текущей задачи.

Это дополнительно уменьшает Blast Radius.

Zero Trust и PAM

PAM помогает контролировать Privileged Accounts и хорошо дополняет Zero Trust.

Он может обеспечивать MFA, JIT Access, Session Recording и временные Administrator Credentials.

Zero Trust для администраторов

Privileged Users требуют наиболее строгих Policies.

Например:

Admin account
+
managed workstation
+
security key
+
JIT approval
→ production access

Separate Admin Account

Администратор не должен использовать одну и ту же высокопривилегированную Identity для Email и обычного Web Browsing.

Разделение Accounts уменьшает вероятность компрометации Privileges.

Privileged Access Workstation

Для наиболее критичных операций могут использоваться специально защищенные административные устройства.

Так снижается риск выполнения Administrator Session на зараженном пользовательском Notebook.

Zero Trust и Cloud

Cloud Environment хорошо подходит для Identity-based Access Control.

Пользователь или Workload получает конкретную Role и доступ только к определенным Resources.

Cloud IAM и Zero Trust

Пример Policy:

Principal: analytics-service
Action: read
Resource: reports-storage
→ allow

При этом другой Storage Bucket остается недоступным.

Zero Trust и SaaS

SaaS Applications можно подключить к центральному IdP и применять Conditional Access.

Например, финансовый SaaS доступен только с корпоративного Device и после MFA.

Zero Trust и Microservices

Во внутренней Microservices Architecture нельзя считать Service доверенным только потому, что он находится в одном Cluster.

Service A должен подтвердить свою Workload Identity перед обращением к Service B.

Zero Trust и Service Mesh

Service Mesh может реализовывать mTLS и Service Identity между Workloads.

Service A
↓ mTLS + identity
Service B

Далее Authorization Policy определяет, какие вызовы разрешены.

Zero Trust и mTLS

mTLS позволяет взаимно аутентифицировать Client и Server с помощью Certificates.

Это полезно для Machine-to-Machine Zero Trust, но само наличие mTLS не заменяет Authorization.

Zero Trust и Kubernetes

В Kubernetes подход включает:

• RBAC;
• Service Accounts;
• Network Policies;
• Secrets Management;
• Admission Policies;
• Workload Identity;
• Runtime Monitoring.

Почему внутренний Cluster не считается доверенным

Если один Container скомпрометирован, атакующий может попытаться обратиться к соседним Services.

Network Policies и Service Authentication ограничивают такое перемещение.

Zero Trust и Database

Database не должна быть доступна каждому Server в сети.

Access Policy может разрешать соединение только определенному Application Service.

Zero Trust и Secrets

Приложения не должны использовать один общий Password для доступа ко всем системам.

Secrets следует ограничивать конкретными Workloads и по возможности заменять короткоживущими Credentials.

Zero Trust и DevOps

CI/CD Pipeline должен иметь собственную Machine Identity и минимальные Permissions.

Например, Pipeline может развертывать только конкретное Application, а не иметь полный Administrator Access ко всему Cloud Account.

Zero Trust и Git

Доступ к Source Code также строится по Least Privilege.

Developer получает только необходимые Repositories, а критичные Branches защищаются отдельными Policies.

Zero Trust и 1С

В инфраструктуре 1С принципы Zero Trust можно применять вокруг системы доступа.

Например, пользователю разрешается подключение к 1С через защищенный Gateway только после проверки корпоративной Identity, MFA и состояния Device.

При этом Database Server остается недоступным напрямую с пользовательских рабочих станций.

Пример Zero Trust для 1С

User
↓ MFA + device check
Remote access gateway
↓
1C session
↓
Application server
↓ restricted connection
Database

Так компрометация обычного Notebook не дает прямого доступа к Database.

Zero Trust и Remote Work

Удаленная работа является одним из основных сценариев Zero Trust.

Сотрудник может работать из дома, гостиницы или мобильной сети, поэтому IP Address корпоративного офиса перестает быть главным признаком доверия.

BYOD

Bring Your Own Device усложняет Zero Trust, потому что компания контролирует устройство меньше.

Для BYOD можно ограничивать набор доступных Applications или запрещать Download чувствительных данных.

Managed и Unmanaged Devices

Zero Trust и DLP

DLP может учитывать Identity и Device Context.

Например, документ разрешено просматривать с личного устройства, но запрещено скачивать на Local Disk.

Zero Trust и Data Classification

Не все данные требуют одинакового уровня защиты.

Public Marketing File и финансовая Database имеют разный Risk.

Zero Trust Policies должны учитывать Criticality Resource.

Data-centric Zero Trust

Цель доступа — не сама сеть, а данные и бизнес-функции.

Поэтому архитектура должна понимать, какие Resources наиболее чувствительны и кто действительно должен иметь к ним доступ.

Zero Trust и Encryption

Шифрование защищает данные, но не отвечает на вопрос, кому разрешено их получить.

Zero Trust сочетает Encryption с Identity и Authorization.

Zero Trust и TLS

TLS защищает Network Connection и часто является базовым компонентом Zero Trust.

Но защищенный TLS Channel не означает, что Client имеет право обращаться к Resource.

Zero Trust и хеширование

Хеширование может участвовать в проверке целостности и Credential Storage, но само по себе не относится к модели управления доверием.

Zero Trust и Phishing

Phishing остается угрозой даже в Zero Trust Environment.

Если Password украден, MFA и Device Context могут остановить попытку Login.

Для критичных Accounts особенно полезна Phishing-resistant Authentication.

Zero Trust и украденная Session

Если атакующий получает действующий Session Token, часть Authentication уже пройдена.

Поэтому нужны короткие Session, Continuous Risk Evaluation и возможность Revocation.

Zero Trust и Lateral Movement

Одна из основных целей подхода — ограничить перемещение атакующего после первоначальной компрометации.

Если User PC не имеет прямого доступа к Domain Controller или Database, захват устройства дает меньше возможностей.

Zero Trust и Ransomware

Least Privilege и сегментация способны уменьшить количество систем, доступных зараженному Account.

Но Zero Trust не заменяет EDR, Backup и Incident Response.

Zero Trust и DDoS

Zero Trust не является специализированным средством Anti-DDoS.

Защита Availability требует отдельных Network и Application Controls.

Zero Trust и WAF

WAF защищает Web Application от определенных классов HTTP-атак, а Zero Trust регулирует, кто имеет доступ к Resource.

Обе меры дополняют друг друга.

Zero Trust и Vulnerability Management

Даже строго ограниченный Server необходимо обновлять.

Zero Trust уменьшает Exposure и Blast Radius, но не устраняет Vulnerabilities.

Zero Trust и Backup

Если данные уничтожены или зашифрованы, Access Policy не восстанавливает их.

Поэтому Backup остается обязательным независимым уровнем защиты.

Zero Trust и Observability

Для динамических Policies требуется качественная Telemetry.

Security и Operations Teams должны видеть Authentication Errors, Policy Denials и состояние компонентов Access Infrastructure.

Логирование решений доступа

Полезно фиксировать:

Zero Trust и Privacy

Контекстная проверка может собирать большой объем Telemetry о Users и Devices.

Организация должна ограничивать сбор необходимыми данными и контролировать доступ к ним.

Zero Trust не означает тотальную слежку

Цель подхода — оценивать Security Context, а не собирать максимум информации о сотруднике.

Telemetry должна соответствовать конкретным Access и Security Use Cases.

Zero Trust не является продуктом

Одна из распространенных ошибок — купить сервис с названием Zero Trust и считать проект завершенным.

Реальная архитектура затрагивает IAM, Endpoint Security, Network, Cloud, Applications и процессы.

Zero Trust не означает запрет всего

Цель состоит не в том, чтобы мешать сотрудникам работать.

Правильная Policy должна предоставлять необходимый доступ быстро, но только подходящему субъекту и в подходящем контексте.

Zero Trust и User Experience

Если сотрудник вводит Password и MFA перед каждым кликом, система становится непрактичной.

SSO, Device Trust, Session Management и Risk-based Policies позволяют снизить лишние Authentication Requests.

Risk-based Access

Низкорисковый запрос с корпоративного устройства может обрабатываться практически незаметно для пользователя.

Необычный Login из новой среды потребует дополнительного подтверждения.

Как внедрить Zero Trust

Шаг 1. Инвентаризировать ресурсы

Определите Applications, Data, Servers, Cloud Services и критичные бизнес-системы.

Шаг 2. Определить Identities

Учитывайте Users, Administrators, Service Accounts и Workloads.

Шаг 3. Централизовать Authentication

Используйте IAM, SSO и MFA для управляемого доступа.

Шаг 4. Сократить права

Уберите избыточные Roles и постоянные Administrator Permissions.

Шаг 5. Сегментировать инфраструктуру

Разрешайте только действительно необходимые Network Flows.

Шаг 6. Подключить Device Context

Учитывайте EDR, MDM и Security Posture.

Шаг 7. Настроить Monitoring

Identity и Access Events должны поступать в SIEM или XDR.

Шаг 8. Внедрять постепенно

Начинайте с критичных Resources и измеряйте влияние Policy на бизнес-процессы.

Почему Zero Trust лучше внедрять поэтапно

Попытка одновременно перепроектировать весь доступ может привести к массовым блокировкам и сложным ошибкам.

Практичнее выбрать критичное Application, описать его Access Model и затем расширять подход.

Приоритетные системы

Обычно разумно начинать с:

1. Administrator Access.
2. Cloud Console.
3. Corporate Email.
4. VPN и Remote Access.
5. Financial Systems.
6. Production Infrastructure.

Типичные ошибки Zero Trust

1. Считать Zero Trust отдельным продуктом.
2. Оставлять широкие постоянные Permissions.
3. Доверять всем устройствам внутри офиса.
4. Не контролировать Service Accounts.
5. Внедрить MFA, но забыть Authorization.
6. Не сегментировать Network.
7. Не учитывать Device Risk.
8. Не иметь Session Revocation.
9. Создать слишком строгие Policies без учета бизнес-процессов.
10. Не анализировать Security Events.

Как измерять эффективность Zero Trust

Полезны метрики:

• доля Applications за SSO;
• доля Users с MFA;
• количество постоянных Privileged Accounts;
• количество Unmanaged Devices с доступом;
• число разрешенных Network Flows;
• время Deprovisioning;
• количество Policy Violations;
• покрытие Identity Monitoring.

Zero Trust Maturity

Zero Trust обычно является развитием инфраструктуры, а не разовым проектом.

Компания постепенно переходит от статических сетевых правил к контекстным решениям на основе Identity, Device и Risk.

Практический пример

Сотрудник финансового отдела работает удаленно и хочет открыть корпоративную бухгалтерскую систему.

При традиционной архитектуре ему достаточно подключиться к VPN, после чего Notebook оказывается внутри корпоративной сети.

При Zero Trust запрос выглядит иначе.

User requests finance app
↓
Identity verified
↓
MFA passed
↓
Device managed and EDR healthy
↓
Role = Finance
↓
Application access allowed

Пользователь получает доступ только к финансовому приложению, но не к Database Server, Domain Controller и другим внутренним ресурсам.

Через час EDR обнаруживает подозрительный Process на его Notebook.

Device Risk меняется на High.

Identity Platform отзывает активную Session к финансовой системе, а EDR изолирует устройство.

SOC получает Incident и начинает расследование.

Даже если Endpoint был скомпрометирован, сегментация и ограниченные Permissions уменьшают возможность дальнейшего Lateral Movement.

Zero Trust для бизнеса

Для бизнеса Zero Trust помогает адаптировать Security к инфраструктуре, где пользователи, Applications и Data находятся одновременно в офисе, Cloud и SaaS.

Вместо широкого доверия к корпоративной сети компания управляет доступом к конкретным бизнес-ресурсам.

Это особенно актуально при удаленной работе, использовании подрядчиков, Cloud Services и большом количестве SaaS Applications.

Преимущества Zero Trust

• уменьшает избыточное доверие;
• ограничивает Lateral Movement;
• поддерживает Least Privilege;
• хорошо подходит для Remote Work;
• учитывает состояние Device;
• повышает контроль Cloud и SaaS Access;
• уменьшает Blast Radius при компрометации.

Ограничения Zero Trust

• требует инвентаризации инфраструктуры;
• нуждается в качественном IAM;
• может быть сложен для Legacy Applications;
• требует интеграции разных Security Systems;
• слишком строгие Policies могут мешать работе;
• не заменяет EDR, Backup, WAF и Patch Management;
• не устраняет все риски компрометации Sessions и Endpoints.

Когда Zero Trust особенно полезен

Подход особенно актуален для организаций с Hybrid Cloud, удаленными сотрудниками, большим количеством SaaS, подрядчиками и критичной внутренней инфраструктурой.

Он также полезен там, где необходимо ограничить последствия компрометации одного Account или Device.

Связанные термины

Краткий итог

Zero Trust — архитектурная модель информационной безопасности, в которой пользователь, устройство или сервис не получают доверие автоматически только потому, что находятся внутри корпоративной сети.

Каждый Access Request оценивается по Identity, Permissions, состоянию Device, Risk и другим контекстным сигналам. Доступ предоставляется только к необходимым ресурсам и в минимально достаточном объеме.

Zero Trust не является отдельным продуктом и не заменяет Firewall, EDR, MFA, Backup или другие средства защиты. Он объединяет IAM, Least Privilege, сегментацию, Device Security, Monitoring и динамическое управление доступом в единую архитектурную модель, цель которой — уменьшить вероятность успешной атаки и ограничить ее последствия.