Azure PostgreSQL Immutable Backups and Cross-Tenant Recovery

In this blog post Azure PostgreSQL Immutable Backups and Cross-Tenant Recovery we will explain how regulated organisations can keep critical database backups recoverable, even if ransomware compromises administrators, subscriptions or everyday cloud accounts.

At a high level, the design combines two controls. Immutable backups prevent recovery points from being changed or deleted before their retention period expires. Cross-tenant encryption keeps the encryption key under a separate identity boundary, so the people managing the database do not automatically control every key protecting it.

This matters for healthcare providers, insurers and other regulated organisations because a backup job marked “successful” does not prove that data is safe. The real business test is whether clean information can be restored within an acceptable timeframe while maintaining patient privacy and a defensible audit trail.

What the technology does

Azure Database for PostgreSQL Flexible Server is Microsoft’s managed version of PostgreSQL, a widely used open-source database. Microsoft handles much of the underlying infrastructure, while your organisation remains responsible for access, retention, encryption choices and recovery planning.

Azure automatically creates native backups for point-in-time recovery. This means the database can be returned to an earlier moment following accidental deletion or corruption. Native backup retention can be configured from 7 to 35 days, with transaction-log backups supporting a recovery point that may be as recent as approximately five minutes.

That is useful for everyday operational recovery, but regulated workloads often need longer retention and stronger protection against malicious deletion. Azure Backup can place additional recovery points inside a Backup vault, which is a separately managed location for backup data.

When vault immutability is locked, destructive operations are blocked for the required retention period. Azure describes this as write once, read many protection, commonly shortened to WORM. Even an administrator cannot simply switch off the locked setting and remove the recovery points.

For a broader ransomware checklist, see our immutable Azure SQL and PostgreSQL backup checklist for CIOs. Here, we are extending that design into tenant separation, encryption ownership and healthcare recovery evidence.

Encryption and immutability solve different problems

These controls are sometimes treated as interchangeable, but they protect against different risks.

• Encryption protects confidentiality. It helps prevent someone from reading database or backup data without the required key.
• Immutability protects retention. It helps prevent someone from changing or deleting recovery points prematurely.
• Access separation protects administration. It reduces the chance that one compromised account can control production, backups and encryption keys.
• Restore testing protects availability. It proves that the organisation can turn protected data back into a working service.

A strong recovery design needs all four. Encryption alone does not stop an authorised administrator from deleting an ordinary backup, while an immutable but untested backup may still take too long to restore during a patient-care disruption.

How cross-tenant encryption works

A Microsoft Entra tenant is the identity boundary containing an organisation’s users, applications and cloud access rules. In a cross-tenant design, the PostgreSQL server can operate in one tenant while its customer-managed encryption key is held in Azure Key Vault or Managed HSM in another tenant.

Azure Key Vault is a protected service for storing encryption keys and other sensitive credentials. Managed HSM provides dedicated, hardware-backed key protection for organisations with stricter security or regulatory requirements.

Azure PostgreSQL data is encrypted at rest by default. Customer-managed keys provide additional control over key ownership, access and rotation, and current PostgreSQL Flexible Server capabilities allow the key to be held in a different tenant. However, customer-managed encryption must be selected when the server is created; an existing server cannot simply be switched from Microsoft-managed encryption later.

For an existing healthcare database, adopting this model may therefore require creating a new encrypted server, migrating the data, validating the application and completing a controlled cutover. That effort should be included in the business case rather than discovered halfway through the project.

A practical recovery architecture

For a regulated PostgreSQL workload, we would typically assess a layered design similar to this:

1. Production tenant. The PostgreSQL server, application and normal operational teams remain in the primary tenant.
2. Security tenant. The customer-managed encryption key and, where appropriate, the Resource Guard approval control are managed by a separate security team.
3. Native PostgreSQL backups. These support fast point-in-time recovery for recent mistakes, failed releases and corruption.
4. Immutable Backup vault. Longer-term recovery points are retained under a locked policy that administrators cannot shorten after an incident begins.
5. Separate vault encryption. The Backup vault can use its own customer-managed key, separate from the source database key, reducing dependence on one key.
6. Isolated recovery environment. Restore tests are performed away from production, with no automatic connection to live applications or user devices.

Azure Backup supports customer-managed encryption for Backup vault data. The source and backup keys can be different, but the keys must remain enabled, accessible and properly protected or backup and restore operations can fail. Key Vault soft delete and purge protection should therefore be treated as recovery controls, not optional settings.

Prevent one administrator from controlling everything

The biggest design mistake is allowing the same cloud administrator to manage production, delete backups, change retention and disable the encryption key. If that identity is compromised, an attacker inherits the same reach.

Azure Backup Multi-User Authorisation addresses this with Resource Guard. In plain English, sensitive backup changes require approval through a separately controlled Azure resource. Microsoft recommends placing Resource Guard in another subscription or tenant for stronger isolation.

This is particularly valuable for healthcare organisations with small IT teams. Separation does not need to mean hiring a second operations department. It can mean assigning tightly controlled approval rights to a security officer, risk leader or trusted external specialist.

What a healthcare recovery test should prove

Consider a 180-person healthcare provider whose appointment, billing and clinical workflow platform depends on PostgreSQL. The organisation has daily backups, but nobody has restored the complete service since it was deployed.

During a ransomware incident, the IT team discovers that the database administrator’s account can also reduce backup retention. The backups are encrypted, but the attacker has already used the compromised account to remove the most useful recovery points.

Moving to locked immutability and separate approvals changes the outcome. The attacker may disrupt production, but cannot erase the retained recovery points. A rehearsed procedure tells the team which clean point to select, who approves the restore and how the recovered database is checked before reconnecting users.

Each test should record:

• The recovery point objective, meaning the maximum acceptable amount of recent data that could be lost.
• The recovery time objective, meaning how quickly the service must be operating again.
• The time taken to restore and validate the database.
• Whether applications, identities, network rules and encryption access also worked.
• Who approved the restore and what evidence was retained.
• Any manual steps that could delay recovery outside business hours.

Do not confuse cross-tenant encryption with cross-tenant restore

Holding an encryption key in another tenant does not automatically mean a PostgreSQL backup can be restored into any tenant. Encryption architecture and restore portability are separate decisions.

Azure Backup has introduced cross-tenant restore as a preview capability, with workload, region, mapping and permission requirements. Preview services should not become the only recovery path for a regulated production workload without a documented risk decision and successful testing.

If tenant failure or loss of organisational control is part of your threat model, test an alternative export or migration path as well. PostgreSQL tools such as pg_dump and pg_restore may support portability requirements, but they create their own security, storage and operational responsibilities.

Build evidence for compliance rather than relying on screenshots

The Essential Eight, the Australian Government’s cybersecurity framework that many organisations use as a security baseline, includes regular backups. For healthcare information, Australian Privacy Principle 11 also requires covered organisations to take active measures to secure the personal information they hold.

Neither requirement is satisfied by showing that a backup schedule exists. Decision-makers should expect evidence of retained recovery points, access separation, protected keys, alerts, restore-test results and remediation of failed tests.

A concise recovery standard might look like this:

Recent operational recovery: 35 days
Regulatory retention: Based on legal and clinical requirements
Immutable vault: Enabled and locked
Backup administration: Separate from security approval
Database and backup keys: Separately managed
Restore tests: Quarterly and after major platform changes
Recovery evidence: Retained for audit and risk review

The exact settings should come from business impact, privacy and legal requirements rather than a generic cloud template.

Recoverability is the outcome that matters

Immutable backups reduce the risk of ransomware destroying your recovery points. Cross-tenant encryption reduces the risk of one identity boundary controlling both the data and its key. Resource Guard reduces the power of a single administrator, while restore testing proves the complete design works.

CloudProInc brings more than 20 years of enterprise IT experience to this type of planning. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we combine practical Azure, Microsoft Defender and Wiz cloud security knowledge rather than treating backup, identity and compliance as separate projects.

If you are not sure whether your PostgreSQL backups would survive a compromised administrator—or whether your healthcare systems could be restored within the timeframe the business expects—we are happy to take a practical look at the current design, with no strings attached.