What is zero trust security?
Zero trust security is a security model in which no user, device or system is trusted simply because it sits inside the corporate network. Each request to reach a resource is authenticated and authorized against policy, access is granted per session, and it is re-checked as conditions change. NIST SP 800-207 is the standard reference for the model.
Domain-joined backup servers on a trusted network
Plenty of backup environments still follow the older perimeter model. The backup server is a domain member, its console answers anyone on the internal network, and every domain administrator is in effect a backup administrator as well. An attacker who gains one internal admin account can then walk to the console and the repository as freely as the staff who built them.
Zero trust breaks that chain by treating the backup server, the console and the storage as separate resources, each with its own access decision, so a single stolen account reaches one of them instead of all three.
Virtualization adds a second route. When the backup server runs as a virtual machine managed from the same vCenter as production, a vCenter administrator can delete it together with its local repository, whatever permissions the backup software itself enforces.
Per-request checks, least privilege and assumed breach
The model is organized around resources rather than network zones, and it reduces to a few working principles.
- No trusted network. A request from inside the data center gets the same scrutiny as one from outside.
- Each request verified. Identity, device and context are evaluated every time, typically with multi-factor authentication.
- Least privilege. An identity receives only the access its job needs, for only as long as it needs it.
- Assumed breach. Systems are built on the expectation that some account or device is already in hostile hands.
- Continuous monitoring. Access is logged and re-evaluated, so a change in behavior can end a session.
Perimeter and zero trust layouts for backup components
| Component | Perimeter-style setup | Zero trust setup |
|---|---|---|
| Backup server | Domain-joined, managed with domain admin accounts | Separate identities with their own multi-factor authentication |
| Backup console | Reachable from anywhere on the internal network | Reachable only from designated management hosts |
| Repository access keys | One key with full rights over all buckets | Keys limited to specific buckets and actions |
| Storage administration | Same accounts as backup and virtualization | Distinct accounts, so no single login controls every layer |
Every row trims the administrative blast radius of one account.
A phished session passes every check
Zero trust shrinks what a stolen password unlocks and still admits an attacker who holds a valid, fully authorized session. If the backup administrator has been phished, one-time code included, every request the attacker sends comes from the right account and satisfies the policy engine. Any access-based control has this ceiling: it decides who may act, and credential theft exists to become that person.
The model also costs a small team effort. Separate identities for backup, storage and virtualization mean more accounts, more authentication prompts and more keys to rotate, all carried by the same handful of people. Service providers apply the logic tenant by tenant, giving each customer its own keys and buckets so that a compromise at one customer stays there. Beneath all of it, the protection that survives a hijacked session is retention the storage itself enforces, independent of any login.
ARTESCA and zero trust security
For the repository row of that table, ARTESCA uses an AWS IAM-compatible policy model in which a backup application's key can be scoped to named buckets and actions and fenced with explicit Deny rules, and its S3 endpoint is served over HTTPS.
The backup server, its console and the hypervisor sit outside ARTESCA, so their identities, MFA and network reach depend on the backup software and the virtualization platform. Storage-level policy narrows what a hijacked backup session can do to stored data without making that session any harder to obtain.
Related terms
- Administrative blast radius: what one admin identity is able to touch and destroy.
- Credential theft: stealing sign-in secrets to act under a real identity.
- Logical air gap: separating backup copies through access controls and immutability.
- Multi-tenancy: keeping several tenants isolated on shared infrastructure.
- Insider threat: harm from people who were given access on purpose.