Skip to main content

Azure Files architecture

Updated yesterday

The Druva Data Resiliency Cloud provides agentless, 100% Software-as-a-Service (SaaS) data protection for Azure Files Server Message Block (SMB) shares. This architecture eliminates the requirement for the customer to deploy or manage any dedicated backup infrastructure within their Azure subscription, thereby reducing operational overhead and overall Total Cost of Ownership (TCO).

Druva utilizes secure delegated access through Azure Role-Based Access Control (RBAC) for data operations. The capabilities for strengthening cyber resilience are founded upon always-encrypted, immutable (DataLock) backups stored in an air-gapped storage layer.

Solution Architecture

The architecture is founded on a secure, cloud-native model that separates the customer’s production environment from Druva’s processing and storage environment. Data movement is performed agentlessly using optimized Azure Files REST APIs, ensuring direct-to-cloud efficiency, reduced API cost, and security.

Components: Customer’s Azure Environment

These resources are created in your Microsoft Entra ID Tenant and Landing Zone Subscriptions to facilitate delegated access for data protection:

  • Authorization Components (Flow A): The initial Druva onboarding process creates a temporary Service Principal to establish a trusted identity, and then creates the Druva Backup Application and App Secret, which is used to initiate secure backup and recovery operations.

  • Delegated Access Role (Flow B): The Druva Backup Role is a custom Role-Based Access Control (RBAC) role created within each of your protected subscriptions. This role grants the least privilege permissions required for the Druva Backup App to discover, protect, and recover your selected data sources (i.e., Azure Files shares).

  • Protected Resources: Includes the Storage Accounts containing your Azure File shares.

  • Encryption Key Management: Druva creates a primary and secondary Key Vault in your subscription with an eKey that grants the Delegated Access Role secure access to read/write your encrypted backups. Druva never has access to your data without you first providing the eKey to initiate a data activity.

Components: Druva Data Resiliency Cloud

These services are fully hosted, managed, and financially owned by Druva, residing outside of your subscription:

  • Druva Enterprise Application: This is the core application identity used to initiate backup or recovery operations. Access to the customer's resources occurs over the Microsoft global network and utilizes the Azure Files service's public endpoint.

  • Druva Data Mover Service: An ephemeral, highly optimized cloud service instantiated on-demand within a region-matched Druva Azure subscription. This service reads data using the delegated Backup Role and Azure REST APIs, performs global deduplication and compression before storage, and incurs zero egress charges to the customer's account for this data transfer.

  • Druva Data Security Cloud (Storage): This secure, highly durable, and immutable storage layer is logically air-gapped from the customer's Azure tenant by locating entirely within the Druva cloud. Storage options are available in Azure or AWS, and can be provisioned in the same or an alternate region for enhanced disaster recovery. Data is protected with AES-256 encryption at rest.


Note:

All communications between Druva and your subscriptions occur over encrypted Transport Layer Security (TLS) 1.2+ connections. All backup data is written using server-side encryption (SSE) with encryption keys that are encrypted with your personal ekey. Druva has no access to your backup data unless you grant access via an initiated recovery operation.


Backup Workflow

The data protection cycle is executed in a secure, sequential manner, leveraging the established delegated roles and public endpoints:

A) Onboarding and Access Control: You onboard your tenant and one or more subscriptions into the Druva Data Resiliency Cloud. This onboarding process grants Druva least privilege access within your Entra ID tenant and within each subscription selected for protection.

B) Delegated Protection: Your Azure landing zone is secured by configuring each protected subscription with a custom RBAC role that permits discovery, backup, and recovery. A dedicated, Druva-created KeyVault ensures you control access to your protected data at all times.

C) Optimized Data Transfer: Druva uses ephemeral Data Mover(s) to access your storage account(s) over the Microsoft global network using TLS 1.2+ encryption. The Mover captures unique and changed data (via global deduplication) and transfers it securely, agentlessly using optimized Azure Files REST APIs. This operation incurs zero egress cost to your Azure account.

D) Storage Resilience: The optimized, immutable data is transferred to the Druva Data Security Cloud, which exists in both Azure and AWS in a broad selection of regions. This deployment flexibility allows you to implement robust cross-region and cross-cloud protection for your Azure workloads.

Restore Workflow

The restore workflow is executed in reverse sequence to the backup process, prioritizing the rapid retrieval of data to meet Recovery Time Objectives (RTOs).

  1. Recovery Initiation & Setup: An authorized administrator initiates the restore job and selects the target share. Druva intelligent automation validates the request and obtains the necessary recovery metadata and customer-controlled encryption key from the Azure Key Vault.

  2. Secure Data Retrieval: The system provisions the ephemeral Druva Data Mover(s), which retrieves the recovery point from the air-gapped Druva Data Security Cloud, preparing the data for the transfer back to your Azure environment.

  3. Zero-Egress Transfer: The recovered data is transferred from the Data Mover to the target File Share over the Microsoft global network using TLS 1.2+ encryption. This restoration transfer utilizes the public endpoint and incurs zero egress cost to the customer.

  4. Secure Read from Backup: The Data Mover must decrypt your secure backup data during recovery. Druva cannot access your encrypted data unless you specifically initiate a recovery event; the act of logging into the Druva console and providing your credentials provides Druva delegated access to your encrypted backups to complete the recovery.

Did this answer your question?