Skip to main content
Migration Notice
We're migrating documentation from the old portal into this one. Some things may look a little different or out of place in the meantime — we know, and we're working to get it right. If something's unclear or doesn't look right, let us know.
Version: 2.15.0

Design Guide for AirGap for Dell

Introduction

This guide covers the architecture, deployment topology, and hardening decisions involved in planning an AirGap deployment. It is intended for architects and administrators designing how AirGap will be deployed — for step-by-step procedures, see the Installation Guide and Configuration Guide.

Deployment Modes

AirGap supports two deployment modes:

Virtual AirGap (outside-the-vault)

In this mode, the AirGap network is opened and closed by Ransomware Defender from outside the vault, using a static route added to the source cluster's replication IP pool. This is the default/basic deployment mode and does not require the Enterprise AirGap license.

Inside-the-Vault mode (Enterprise AirGap)

This mode requires the Enterprise AirGap license and deploys a dedicated Vault Agent VM inside the vault itself. Instead of managing the AirGap network from outside, this VM opens and closes the vault from within, by adding or removing the IP address from the replication interfaces. It provides the same automation as Virtual AirGap, plus:

  • Smart AirGap fail-safe: if the Vault Agent cannot reach the Ransomware Defender/Smart AirGap API to confirm it is safe to replicate, it fails safe and closes the vault rather than replicating.
  • Hardened operating mode: CLI commands to force-open the vault for maintenance are not supported in this mode — physical console access to the vault cluster or ESX host is required, which is a more secure (if less convenient) operating posture.
  • A 2-hour heartbeat maintenance-window request mechanism (disabled by default) that can be enabled to allow a timed maintenance-access window.
note

A static route must still be configured for inside-the-vault mode, even though it is not used for replication. Confirm this requirement with Support for your target release.

Network Topology

Layer 2 vs. Layer 3 vault network

The network between the source and vault clusters can be designed as either a flat Layer 2 VLAN or a routed Layer 3 network:

  • Layer 2: Simpler for multiple source clusters to share a single vault network/VLAN (a "fan-in" topology).
  • Layer 3: Allows a firewall to be placed between the source cluster(s) and the vault cluster, adding traffic firewall rules between them — recommended when additional network-layer security controls are required.

Fan-in (multiple source clusters to one vault)

The Enterprise AirGap license supports a fan-in topology where multiple protected source clusters replicate into a single vault cluster, over either a shared Layer 2 VLAN or a routed Layer 3 network.

Solution summary

At a high level, an AirGap deployment consists of the source (production) cluster, a dedicated AirGap replication network/switch (or firewall), and the vault cluster — with Eyeglass/Ransomware Defender orchestrating replication, alarms, and (optionally) an Enterprise Vault Agent running inside the vault.

Best Practice: Use a Bastion Host

Complete all initial configuration of the vault cluster through a bastion host — a VM connected only to the private vault management network — rather than connecting the vault cluster directly to the corporate network during commissioning. The vault cluster should never be exposed directly to the production network.

Cyber Recovery RunBook

As much pre-configuration, labeling, port/VLAN planning, cabling, and logic configuration as possible should be completed at initial deployment time, to speed up execution of the recovery scenarios described in Use Cases. Document these deployment-specific steps in a Cyber Recovery RunBook — this documentation provides the high-level steps, but your RunBook should turn them into environment-specific, detailed steps your team can execute directly during a recovery event.

Avoiding DR Path Overlap

When designing AirGap SyncIQ policies, do not use a source path that is already used by a DR replication policy on the same production cluster.

  • Example: if a DR policy replicates /ifs/data/zone1, an AirGap policy should use a path above (/ifs/data) or below (/ifs/data/zone1/somepath) that DR path — never the same path.
  • Reason: during a full reverse-replication recovery from the vault (see Use Cases), an overlapping DR mirror policy would cause two clusters to attempt to write into the same production path simultaneously, blocking the vault recovery policy from completing successfully.
  • Solution: plan non-overlapping AirGap and DR policy paths from the start, even if this means creating additional AirGap policies to cover all required data. This is simpler and faster than resolving an overlap manually during an actual recovery.

High Change Rate vs. Low Change Rate Data

Data sets change at different rates, and this should inform both SyncIQ scheduling and vault retention planning:

  • Longer SyncIQ retention (using Target Snapshots with a retention period, in days) supports recovery from a wider window of history, at the cost of more vault storage.
  • Data change rate determines how many days of retention are practical/affordable — higher change rate data consumes more space per day of retention.
  • Consider dedicated AirGap policies (with independent schedules) for data sets with meaningfully different change rates, rather than a single policy/schedule for all data.

Vault Location: On-Site vs. Remote

The vault PowerScale can be located on-site next to the source cluster, or off-site/remote (SyncIQ supports either). This is a trade-off:

  • On-site (recommended): fastest recovery time; requires dedicated AirGap networking (no IP routing to the vault from anywhere but the source cluster) implemented via firewall rules.
  • Remote: supported, but trades rapid recovery speed for physical separation.

Superna's general recommendation is on-site, since Disaster Recovery already protects against site failure — the vault's job is to protect against an on-site threat, not a site outage.

Security Hardening

Eyeglass VM hardening

  • Apply Eyeglass appliance hardening and password-management best practices, including fail-to-ban auto-blocking of failed login attempts.
  • Configure two-factor SSH authentication on Eyeglass, the ECA, and the Vault Agent VM.
  • Firewall SSH/HTTPS access to the Eyeglass VM so it is only reachable from a management-network jump box with 2FA.
  • Restrict ECA firewall ports to only the traffic required between Eyeglass and the ECA, and allow SSH to the ECA only from a jump box.
  • Enable full user UI access and configuration auditing.

Vault cluster hardening

At minimum, the vault cluster should be hardened as follows (a full hardening pass is available as part of Superna's AirGap Design and Implementation service):

  • Use only local accounts on the vault cluster — no Active Directory provider — to reduce attack surface.
  • Enable configuration auditing on the vault cluster to track all configuration changes.
  • Disable all non-essential services (SMB, NFS) and delete the default SMB share and NFS export.
  • Disable all built-in user accounts except root, and set a random root password of 20+ characters (upper/lower case, numbers, and at least one special character), owned and managed only by senior security management.
  • Create a minimum-privilege Eyeglass service account on the vault cluster, scoped only for alarm collection.

Role-based management (RBAC)

AirGap supports discrete, separable administrative roles so day-to-day monitoring and vault control are never held by the same personnel:

RoleAssigned ToPurpose
Ransomware Defender RoleInfosec teamDay-to-day configuration/management of real-time monitoring
Easy Auditor RoleInfosec teamDay-to-day configuration of auditing
AirGap RoleCSO / senior managementAccess to the AirGap GUI and vault control
Ransomware Defender Read-Only RoleNAS teamRead-only visibility, no changes
Easy Auditor Read-Only RoleNAS teamRead-only visibility, no changes

Recommendation: assign the AirGap Role to CSO or senior security management personnel who are separate from the personnel holding the Ransomware Defender Role.

Enterprise Hardware Sizing Considerations

For full sizing detail, see the Vault Cluster Requirements and Additional Requirements for Enterprise AirGap sections of Prerequisites. At a design level, plan for:

  • A dedicated Vault Agent VM host (dual-socket server, 512 GB RAM, 1G/10G Ethernet, 2–4 TB local flash), sized to allow for future VMs (for example, a hardened admin desktop for recovery/upgrade operations).
  • A dedicated AirGap Ethernet switch (minimum 4x10G ports) — or a firewall for enhanced traffic control and logging — rather than reusing production front-end switches with a VLAN.
  • High-availability production node connections where possible (at least 2 nodes/interfaces on both source and vault clusters); a single-node/interface connection is a supported fallback with reduced availability.

See Also

  • Concept – What AirGap is and the core concepts behind it.
  • Prerequisites – Full platform compatibility and system requirements.
  • Configuration Guide – Step-by-step configuration procedures.