Zero Trust architecture: resource access without trusting the network

Zero Trust is an architecture in which a position inside the corporate network does not create trust. Every request is evaluated using identity, device posture, context, policy and current risk. Access is granted to a named resource with minimum permissions and a limited lifetime.

It is not one product or a replacement VPN. It changes the decision model from broad network admission to verification at each meaningful interaction.

Why the perimeter is insufficient

Resources now span offices, cloud, IaaS, SaaS and partner environments. People work remotely, services communicate through APIs and devices have different owners and control levels.

NIST SP 800-207 describes Zero Trust as a move from a static network perimeter towards users, devices, services and resources. Authentication and authorisation occur before a session is created, without implicit trust based on location or ownership.

Seven practical principles

1. Protect resources, not subnets. Express policy in terms of applications, data and operations.
2. Identify people and services. Give every integration its own identity and owner.
3. Grant least privilege. Limit access by resource, action, environment and time.
4. Use device posture. A valid password does not make a compromised laptop safe.
5. Evaluate session context. Time, location, network, action and behaviour affect risk.
6. Treat the network as untrusted. Encrypt and authenticate internal communication.
7. Measure and revise. Policies without decision telemetry become stale.

Logical architecture

Component	Responsibility
Policy Engine	Decides using rules and risk signals
Policy Administrator	Creates, changes or terminates the session
Policy Enforcement Point	Allows or blocks the request near the resource

Signals may come from identity directories, MFA, device management, CMDB, SOC telemetry, resource classification, vulnerability data and behaviour history.

Enforcement belongs close to the resource: a reverse proxy, API gateway, service mesh, administrative-access gateway or a platform-native control.

Start with inventory

Record critical applications and owners, data classification, human and machine identities, device control, external dependencies, access paths, privileged actions and required evidence.

Do not attempt the entire company at once. Choose one critical workflow with a clear owner, such as cloud administration or contract-system access.

Write an access model

A policy should answer:

1. Who is requesting access?
2. From which device or workload?
3. Which resource?
4. Which operation?
5. In what context?
6. What is the current subject and device posture?
7. What assurance level is required?
8. How long does the decision last?

A service policy can combine workload identity, environment, permitted operations, mTLS, rate limits and credential lifetime. Our API integration architecture guide covers the contract side of that design.

Device posture without stopping work

A binary “compliant or blocked” policy may stop operations when posture telemetry fails. Define several modes:

• trusted mode with the full permitted operation set;
• restricted mode such as read-only access;
• recovery mode limited to update and support services;
• full block for confirmed high risk.

Every denial needs a safe remediation path. Unexplained controls encourage unsafe workarounds.

Segmentation and workload identity

Network segments reduce blast radius, but IP rules are difficult to maintain in dynamic infrastructure. Cloud and container environments need workload identity and service-level policy.

Separate production from test, user from administrative traffic, applications from databases, control planes from workloads, and backup from the primary administrative domain. A backup reachable through the same identities is not independent protection; see backup and fault tolerance.

Telemetry

Record subject and resource IDs, operation, decision, matched rules, device posture, authentication level, session ID, decision lifetime and a safe denial reason. Track denials, step-up authentication, temporary privilege, stale entitlement, unknown devices and critical resources without enforcement.

Do not place tokens, passwords or sensitive document content in normal logs. Infrastructure observability explains how to connect metrics, logs and traces.

Staged adoption plan

1. Select one workflow, owner and success measure.
2. Remove shared accounts, add risk-based MFA and service identities.
3. place an enforcement point in observation mode.
4. Add minimum device-posture signals and test missing telemetry.
5. Narrow access from networks to applications and operations.
6. Continuously review rights, exceptions and active sessions.

Introduce restrictions in small waves with a rollback. Confirm that an employee departure or identity compromise can terminate existing sessions quickly.

Common mistakes

• Buying a “Zero Trust product” without resource ownership.
• Applying MFA only at VPN entry while leaving broad internal access.
• Reusing one service account across integrations.
• Having no restricted or recovery mode.
• Permanent exceptions without an owner and expiry.
• Trusting a device merely because an agent is installed.
• Logging decisions without linking them to business operations.
• Attempting a company-wide cutover.

Pilot checklist

• One critical workflow and accountable owner.
• Known users, services, devices and resources.
• No shared identities.
• Operation-level policies.
• Risk-based MFA and device posture.
• Restricted mode and recovery path.
• Investigable decision logs.
• Access revocation terminates sessions.
• User-task impact is measured.
• Exceptions have owners and expiry dates.

Conclusion

Zero Trust is useful as a discipline of precise access, not a slogan. Move one workflow from network location to identity and resource, add device posture and telemetry, and expand only after measuring the outcome.

The primary reference is NIST SP 800-207, supplemented for cloud-native systems by NIST SP 800-207A. Applicability to a specific Russian information system and its requirements must be assessed separately.

Next step: Logic Telecom can help map critical access flows, identify enforcement points and plan a pilot that does not interrupt existing operations.