多位置环境中云原生应用访问控制的零信任体系架构模型-28页_1mb

NIST SP 800-207A.ipd: Zero Trust Architecture Model for Access Control in Cloud-Native Applications

Introduction & Background

• Document Focus: Provides guidance for realizing a Zero Trust Architecture (ZTA) model for granular access control in multi-location cloud-native application environments.
• Cloud-Native Characteristics:
  • Composed of microservices.
  • Services communicate across networks.
  • Often uses a Service Mesh for infrastructure.
• Enterprise Environment: Highly distributed geographically (on-premises, multiple clouds), hybrid IT.
• ZT Principles: Emphasizes zero-trust tenets from NIST SP 800-207, moving away from network perimeters and implicit trust.

Core Recommendations & Architecture

• Key Shift: Replace implicit trust based on network location/affiliation/ownership. Security controls move from network segments to identities (users, services, devices).
• Required Infrastructure (Reference Architecture Plan):
  • Service Mesh: Provides security within microservices, includes edge/ingress/egress gateways, sidecars, and proxies.
  • Enterprise Infrastructure Layer: Includes a Global Control Plane (for uniform policy, leveraging PKI) and Management Plane.
• Identity Based Segmentation (IDsG): Required for ZT enforcement. Focuses on:
  • IDSEG-REC-1 (Encrypted Connection): Service-to-service communication must be encrypted.
  • IDSEG-REC-2 (Service Authentication): Short-lived service identities (mTLS) via SPIFFE/SVID.
  • IDSEG-REC-3 (Service-to-Service Authorization): Granular policies enforced based on identities.
  • IDSEG-REC-4 (End-user Authentication): Robust, MFA-based user authentication using short-lived tokens (OAuth 2.0, JWT).
  • IDSEG-REC-5 (End-user-to-Resource Authorization): Authorization checks for user actions.

Policy Framework & Tiers

• Combined Approach: Requires network-tier and identity-tier policies.
• Network-Tier Policies: Static, rely on location/IP, firewall rules. Provide basic perimeter control but require constant updates in dynamic environments.
• Identity-Tier Policies (Required for ZT): Dynamic, context-based, based on identities (users, services). Offer:
  • Granular, non-disruptive control (e.g., specific HTTP verbs/path restrictions).
  • Agility: Easier to modify than network rules.
  • 'Write Once, Enforce Everywhere': Environment-agnostic.
  • Context: Directly express intent (e.g., "service A can call service B on /foo with GET").
  • Automation: Support "Policy as Code" (PaC) and testing.
• Advantages of Identity-Tier Policies: Goes beyond least privilege with context, enforces security irrespective of infrastructure changes or location.

Multi-Tier Implementation & Considerations

• Implementation: Leverages Service Mesh components (control plane, data plane proxies, SPIFFE). Requires a Global Control Plane/Management Plane infrastructure for consistent enterprise-wide policies.
• Deployment Scenarios: Demonstrates policy application in hybrid-cloud environments and three-tier applications with service meshes.
• Use of Service Mesh: Serves as the 'cloud-native security kernel'.
• Gateways: Essential for enforcing policy at network edges (ingress/egress/transit/edge).

Conclusion

Summarizes the document's objectives: To provide guidance for achieving a ZTA posture in cloud-native environments by:

1. Using both network-tier and identity-tier policies.
2. Leveraging cloud-native platform components.
3. Emphasizing the critical role of identity-tier policies underpins the necessity for the multi-tier model.