> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xloud.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# XDR Security

> Secure XDR deployments with replication encryption, RBAC access control, site token management, and audit logging.

## Overview

XDR security spans three domains: encryption of data in transit across the replication
link, access control over who can initiate potentially destructive failover operations,
and credential isolation between sites using token-based authentication.

<Note>
  **Prerequisites**

  * Administrator credentials with the `dr-admin` role
  * TLS certificates provisioned for site-to-site communication
  * Identity and access management configured in XDeploy
</Note>

***

## Replication Encryption

All replication traffic between primary and DR sites is encrypted in transit.

<AccordionGroup>
  <Accordion title="TLS configuration" icon="lock">
    Configure encryption in **Disaster Recovery → Sites → Replication Links → \[Link] → Security**:

    | Setting                | Recommended Value                                          |
    | ---------------------- | ---------------------------------------------------------- |
    | **Protocol**           | TLS 1.3 minimum (TLS 1.2 allowed for legacy compatibility) |
    | **Certificate source** | Managed by XDeploy (auto-renewed 30 days before expiry)    |
    | **Authentication**     | Mutual TLS — both sites authenticate each other            |
    | **Cipher suites**      | XDeploy defaults (AES-256-GCM, ChaCha20-Poly1305)          |

    Verify the current TLS configuration from **Disaster Recovery → Sites → Replication Links → \[Link] → Security**.
  </Accordion>

  <Accordion title="Certificate management" icon="shield-check">
    XDeploy manages site certificates automatically. Certificates are:

    * Issued per-site at registration time
    * Automatically renewed 30 days before expiry
    * Rotated without interrupting active replication

    To manually trigger certificate renewal, navigate to **Disaster Recovery → Sites → \[Site] → Certificates** and click **Renew Certificate**.

    Monitor certificate expiry in XIMP by creating an alert rule:

    | Setting       | Value                          |
    | ------------- | ------------------------------ |
    | **Condition** | `xdr_cert_days_to_expiry < 30` |
    | **Severity**  | Warning                        |
    | **Channel**   | ops-alerts                     |
  </Accordion>

  <Accordion title="Encryption at rest" icon="hard-drive">
    Replicated data at rest on the DR site is encrypted using the same storage
    encryption policy as the primary site. Configure encryption at rest in XSDS
    at the pool or volume level — XDR inherits the encryption status of the
    source volumes.

    See [XSDS Admin — Security](/services/sds/admin-guide/security) for storage
    encryption configuration.
  </Accordion>
</AccordionGroup>

***

## RBAC Access Control

XDR operations are governed by Xloud identity roles. Failover and failback are
potentially disruptive operations — restrict them to trained personnel.

| Role          | Permissions                                                                                           |
| ------------- | ----------------------------------------------------------------------------------------------------- |
| `dr-viewer`   | View plan status, replication lag, test reports, and site health                                      |
| `dr-operator` | Create and manage protection plans; run DR tests; initiate failover and failback                      |
| `dr-admin`    | Full access including site registration, replication link configuration, and compliance report export |

### Assigning DR Roles

<Tabs>
  <Tab title="Dashboard" icon="gauge">
    Navigate to **Identity → Projects → \[Project] → Members** and assign the
    appropriate DR role to each user. DR roles apply at the project level —
    a user must have a DR role in both the primary and DR site projects to
    operate across sites.
  </Tab>

  <Tab title="CLI" icon="terminal">
    ```bash title="Assign dr-operator role to a user" theme={null}
    xloud role add \
      --user operator@example.com \
      --role dr-operator \
      --project prod-project
    ```

    ```bash title="List users with DR roles" theme={null}
    xloud role list \
      --role dr-operator \
      --project prod-project
    ```
  </Tab>
</Tabs>

<Warning>
  Grant `dr-operator` access only to personnel trained in XDR failover procedures.
  An untrained operator initiating an unnecessary failover can cause extended
  service disruption and require a full failback cycle to restore normal operations.
</Warning>

***

## Site Token Management

XDR agents authenticate between sites using site-specific tokens, not user credentials.
This isolates site-to-site authentication from user identity management.

### Token Lifecycle

| Event                | Action Required                                               |
| -------------------- | ------------------------------------------------------------- |
| Initial deployment   | Token generated by XDeploy during site registration           |
| Scheduled rotation   | Rotate via the Dashboard on schedule (recommended: quarterly) |
| Suspected compromise | Rotate immediately; review access logs                        |
| Token expiry         | 90-day expiry by default; configurable at registration        |

Manage tokens from **Disaster Recovery → Sites → \[Site] → Token Management**:

* **View token status**: Displays token expiry date and current validity for all registered sites
* **Rotate token**: Click **Rotate Token** to generate a new authentication token
* **Update peer**: After rotation, navigate to the peer site configuration and enter the new token

<Note>
  Token rotation does not interrupt active replication. The old token remains valid
  for 15 minutes after rotation to allow the update to propagate before the old
  token is invalidated.
</Note>

***

## Audit Logging

XDR records all administrative actions and failover events in an immutable audit log.

| Event Category                     | Logged Information                                                        |
| ---------------------------------- | ------------------------------------------------------------------------- |
| Site registration / deregistration | Admin user, timestamp, site details                                       |
| Plan creation / modification       | Admin user, timestamp, changed fields                                     |
| Failover initiated                 | Operator user, timestamp, trigger type (manual/automatic), recovery point |
| Failback initiated                 | Operator user, timestamp                                                  |
| DR test started / completed        | Operator user, timestamp, outcome                                         |
| Token rotation                     | Admin user, timestamp, affected site                                      |

Navigate to **Disaster Recovery → Reports → Audit Log** to view and export the audit trail:

* Filter by event type (failover, failback, test, site registration, token rotation)
* Set date range for the reporting period
* Export as PDF or CSV for compliance submissions

***

## Network Security

| Requirement                | Implementation                                                                   |
| -------------------------- | -------------------------------------------------------------------------------- |
| Dedicated replication VLAN | Separate replication traffic from production networks                            |
| Firewall rules             | Open only required ports (TCP 7000–7002) between site CIDRs                      |
| No internet exposure       | Replication endpoints should not be reachable from the public internet           |
| VPN / MPLS                 | Use a dedicated circuit rather than the public internet for the replication link |

Run a connectivity audit from **Disaster Recovery → Sites → \[Site] → Test Connectivity**
to verify that only the required replication ports are accessible between sites.

***

## Next Steps

<CardGroup cols={2}>
  <Card title="Replication Configuration" href="/services/disaster-recovery/admin-guide/replication-config" color="#197560">
    Configure replication link encryption and bandwidth settings
  </Card>

  <Card title="Compliance" href="/services/disaster-recovery/admin-guide/compliance" color="#197560">
    Export audit logs for compliance reporting
  </Card>

  <Card title="XSDS Admin — Security" href="/services/sds/admin-guide/security" color="#197560">
    Configure storage encryption that XDR inherits
  </Card>

  <Card title="Identity & Access Admin Guide" href="/services/identity/admin-guide" color="#197560">
    Manage Xloud RBAC roles and identity federation
  </Card>
</CardGroup>