← Security+: security and production decisions
04 / 7 · 30 MIN

Architecture, privileges, and recovery

Design access and resilience with shared dependencies in mind.

Concept and mechanism

Zero trust does not grant implicit trust merely because a request comes from the internal network. Decisions should consider identity, device, and resource authorization. A cloud migration does not automatically fix permissive access design. Under shared responsibility, identify the specific service and customer tasks, including data and permissions. If a frontend only needs an API, do not grant it database administration. Limiting privileges and paths reduces capabilities available when a component is compromised and clarifies what needs review at handover.

Guided application

RTO and RPO answer different questions: time to recover and the data point that must be recoverable. Fast restoration of old data can meet one and fail the other. Rehearsals should include consistency, functional outcome, and dependencies such as cryptographic keys. Encrypted backups can be unusable if the only key was lost with the server. Separate sites also do not remove a shared administrative control capable of deleting every copy. Assess management independence and backup protection, and demonstrate recovery when original infrastructure is unavailable.

IN PRACTICE

Restoring in 45 minutes can satisfy a 60-minute RTO. If the recovered point is 24 hours old and RPO is 15 minutes, data protection remains insufficient.

Common pitfalls

Trusting only LAN location; assigning all responsibility to the provider; measuring only startup; storing the only key with the lost server.

Related topics: Identities, patches, logs, and assets · Incidents and controlled response

Take this idea with you

Recoverability needs data, keys, access, and functional validation within objectives.

Create account

Reference: Contingency planning guide · SY0-701 V7