Compliance Guide for Data Orchestration for Dell

Introduction

This page summarizes the compliance-relevant capabilities of Data Orchestration (Golden Copy): how backup copies can be made immutable, how data movement is audited, and how administrative access is controlled.

Backup Best Practice Alignment

Golden Copy automates data sync from a PowerScale cluster to S3 compatible object storage, allowing customers to maintain a third copy of data off site in the cloud or on premises. This supports the 3-2-1 backup best practice: 3 copies of data, stored on 2 different storage technologies, with 1 copy kept off site.

Immutable Backup with Object Lock (Compliance Mode)

Golden Copy can be paired with Dell ECS Object Lock to create backup copies that cannot be deleted, even by the root user, for a defined retention period.

• Requirements: Dell ECS 3.6.2 or later, an S3 bucket with Object Lock enabled in Compliance mode, Golden Copy 1.1.6 or later with the Advanced license key, and Ransomware Defender 2.5.8 or later (for the zero trust integration described below).
• The S3 bucket is created with Object Lock enabled, and a default retention rule is applied in COMPLIANCE mode with a configurable retention period (for example, 180 days).
• Once written, locked objects cannot be deleted or modified until the retention period expires, protecting backup data even if the source environment is compromised.
• Object retention and expiry dates on individual objects can be verified directly against the bucket.

info

By default, Golden Copy's incremental sync mode deletes an object from S3 when the corresponding file is deleted from the source file system. With Object Lock in Compliance mode, deleted objects remain in the bucket as locked, undeletable versions until their retention period expires. This default delete-sync behavior can be disabled so that deleted files are retained as S3 objects instead of removed, which is recommended in most Object Lock deployments.

Configure the ECS Bucket with Object Lock

Download the ECS Perl tools and configure them with credentials for a user that has permission to modify the target bucket. An IAM user is required to modify Object Lock settings. Adapt the following examples to your environment, replacing x.x.x.x with the IP address of your ECS and gcbucket with the S3 bucket name to be used with Golden Copy.

1. Create the bucket with Object Lock enabled:

   ./s3curl.pl --id=ecsid --createBucket -- https://x.x.x.x:9021/gcbucket -H "x-amz-bucket-object-lock-enabled: true"

2. Set the Object Lock default retention on the bucket. This example uses a 180 day lock period:

   ./s3curl.pl --id=ecsid -- https://x.x.x.x:9021/gcbucket?object-lock -X PUT -d "<ObjectLockConfiguration><ObjectLockEnabled>Enabled</ObjectLockEnabled><Rule><DefaultRetention><Mode>COMPLIANCE</Mode><Days>180</Days></DefaultRetention></Rule></ObjectLockConfiguration>"

3. Verify the Object Lock configuration:

   ./s3curl.pl --id=ecsid -- https://x.x.x.x:9021/gcbucket?object-lock

   Example output:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?><ObjectLockConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><ObjectLockEnabled>Enabled</ObjectLockEnabled><Rule><DefaultRetention><Mode>COMPLIANCE</Mode><Days>180</Days></DefaultRetention></Rule></ObjectLockConfiguration>

4. Copy data to the bucket with Golden Copy, and decide whether to disable delete syncs. See Sync Deleted Files During Incremental Jobs.

5. To verify that an object is locked and check its expiry date, query the object's retention (replace <clustername> and the object path with your own values):

   ./s3curl.pl --id=ecsid -- https://x.x.x.x:9021/gcbucket/<clustername>/ifs/GCTest/folder7/bfile2.txt?retention

   Example output:

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?><Retention xmlns="http://s3.amazonaws.com/doc/2006-03-01/"><Mode>COMPLIANCE</Mode><RetainUntilDate>2022-01-25T16:29:39.407Z</RetainUntilDate></Retention>

Zero Trust Integration with Ransomware Defender

Golden Copy can integrate with Ransomware Defender through the Zero Trust API so that backup jobs (full or incremental) are automatically blocked if active threats are detected on the production data set, and resume automatically once the threat is addressed. This integration requires configuring the Golden Copy appliance with the Ransomware Defender (Eyeglass) IP address and an API token generated from the Eyeglass API menu. See Data Security's API Guide for token creation steps and licensing requirements, and the Integration Guide for the corresponding Data Orchestration-side configuration.

To enable the integration:

1. Log in to Golden Copy node 1 over SSH and open the configuration file:

   nano /opt/superna/eca/eca-env-common.conf

2. Add the following lines, replacing x.x.x.x with the IP address of the Eyeglass VM and yyyyyyyy with the API token created to authenticate:

   export EYEGLASS_LOCATION=x.x.x.x
   export EYEGLASS_API_TOKEN=yyyyyyyy

3. Save and exit the file (Ctrl+X).

Dell ECS support for Object Lock/Compliance mode specifically is also noted at the storage-target level; other supported S3 targets vary in their support for versioning, retention policies, and Object Lock, and target-specific support should be confirmed in References.

Immutable Storage for Azure Blob Storage

For Azure Blob targets, immutability is configured directly on the Blob container using Azure's own time-based retention policies or legal hold, rather than Golden Copy configuration:

• Time-based retention policy: configured on the storage account container's access policy settings, specifying a retention period in days. Only one retention policy is allowed per container. A policy can be left unlocked during initial testing (so it can still be edited or removed while validating incremental schedules), but once locked, the policy cannot be undone and data cannot be deleted for the remainder of the retention period, even after the lock is applied.
• Legal hold: unlike a locked retention policy, a legal hold (applied with a descriptive tag) can be removed at any time, making it suited to hold requirements that may later be lifted.
• Because Azure retention is anchored to an object's creation date, incremental sync cannot update an object that already exists and is still within its retention/hold period. A copy error citing BlobImmutableDueToPolicy indicates the incremental job attempted to update a file whose corresponding object is currently locked — this is expected behavior for a modified file during the retention window, not a configuration fault. A legal-hold container returns an equivalent legalholdpolicy error if an object matching an existing (held) object name is uploaded again.

warning

Review Azure's retention and legal hold documentation and limitations in full before locking a retention policy — a locked policy cannot be reversed, and the underlying storage will continue to be retained (and billed) for the full lock duration.

Data Security Best Practices

• Authentication: Golden Copy authenticates to S3 targets using access and secret keys, which is the recommended best practice. For Amazon S3 specifically, AWS advises against using IAM roles for Golden Copy, since Golden Copy operates from an on-premises appliance and IAM roles are designed for use by AWS-hosted resources — access/secret key authentication should be used instead.
• In-flight encryption: configuring a folder definition's target endpoint over HTTPS ensures data in transit is TLS-encrypted. The endpoint can use a self-signed or CA-signed certificate; certificate signing itself is external to Golden Copy and requires no additional configuration on either signing path.
• At-rest encryption: provided by the target cloud or object storage provider, typically using provider-managed keys by default. Golden Copy does not support configuring customer-provided, object-level encryption keys — consult your target's own documentation on default at-rest encryption behavior.
• Retention and versioning: both are configured at the bucket level following the target provider's own administration steps; Golden Copy requires no additional configuration to take advantage of either once they are enabled on the target bucket. Use separate buckets to apply different retention levels to different data sets.

Auditability of Data Movement

Golden Copy provides monitoring and reporting that can serve as evidence of backup activity for audit or DR/backup-testing purposes:

• Job history (searchctl jobs history) retains a record of every archive, incremental, and inventory job that has run, including job type, duration, and success/failure outcome, and can be filtered by folder or job type.
• Detailed job reports can be exported per job (searchctl archivedfolders export --jobid <job-id>) to produce a file-by-file breakdown of successes and failures, which can be retained as evidence that a specific backup or restore operation completed as expected.
• Archive Data Audit jobs can be scheduled to periodically compare the file system to the target S3 bucket and reconcile any differences, providing an ongoing evidence trail that the target copy matches the source.
• Golden Copy is described as providing global monitoring of user activity with auditing and traceability of where data is moved, copied, when, and by whom, when used as part of a hybrid cloud data mobility workflow.

Role-Based Access Control

Golden Copy supports role-based administrative access so that day-to-day copy job monitoring can be separated from full appliance administration:

• The built-in ecaadmin user is the appliance administrator and is the only account permitted to run ecactl cluster operations (startup, shutdown, upgrades).
• Additional administrators can be granted access to searchctl commands only, without the ability to perform cluster-level operations, by adding them to the built-in ecactl group or a custom group.
• A read-only style Operator role can be created that is limited to monitoring commands only, for example searchctl archivedfolders list, searchctl jobs *, and searchctl archivedfolders stats *, without granting configuration change permissions.
• Both local OS accounts and Active Directory accounts can be used for administrator or operator login, and CLI command sets can be assigned per group using searchctl settings groups add --name <group> --cmd <commands>.
• Password policy and failed-login-attempt controls, and an admin-only login mode that blocks all non-administrator logins, are also available.

Enable Administrator RBAC

Additional administrators can run searchctl commands only after the built-in ecactl group is activated. Without this command, no users other than the built-in ecaadmin appliance administrator can run commands.

searchctl settings groups add --name ecactl --cmd '*'

Join the Appliance to Active Directory for OS Login

Active Directory OS login requires joining the appliance to Active Directory.

1. Log in to the appliance over SSH as ecaadmin.

2. Run sudo -s and enter the ecaadmin password.

3. Type yast.

4. Navigate to Windows Domain Membership.

5. Enter your AD domain and select the options appropriate for your environment.

6. Enter a domain administrator, or an account that is allowed to join computers to the domain.

7. After the domain is joined successfully, exit YaST by using Tab to select Quit.

8. Test SSH login with an AD user. The following examples use an AD domain called ad2.test with the user demo1. The double backslash is required to escape the backslash character.

   • Linux SSH client:

     ssh ad2.test\\demo1@x.x.x.x

     or

     ssh demo1@ad2.test@x.x.x.x

   • PuTTY on Windows: use demo1@ad2.test as the user name.

This allows OS login but blocks application CLI commands until the AD user is added to a role.

Add an AD User as an Appliance Administrator

The appliance must already be joined to Active Directory. Log in as ecaadmin and add the AD user to the built-in ecactl group, which provides access to all searchctl commands. In this example, AD02 is the domain name in upper case and xxxx is the AD user name. The double backslash is required as an escape character.

sudo /usr/sbin/usermod -a -G ecactl AD02\\xxxx

Log out, then test the user's access by logging in over SSH and running CLI commands.

Add a Local OS Appliance Administrator

1. SSH to the appliance as ecaadmin.

2. Create the user. You are prompted for the ecaadmin password. The new user is added to the built-in ecactl group:

   searchctl settings users add --name NAME

3. Set the password for the new user. You are prompted for the ecaadmin password, then for the new user's password:

   sudo passwd NAME

4. To remove a user, run the following command. You are prompted to confirm:

   searchctl settings users remove --name NAME

To view the members of the group, run cat /etc/group. Log in over SSH to test CLI commands.

Create an Operator Role for Monitoring Copy Jobs and Stats

The Operator role can monitor copy jobs and folder statistics but cannot change configuration.

1. SSH to the appliance as ecaadmin.

2. Create the group. Do not use spaces or special characters in the name. When prompted for a password, enter the ecaadmin password:

   sudo /usr/sbin/groupadd operator

3. Assign the operator CLI commands to the group:

   searchctl settings groups add --name operator --cmd 'searchctl archivedfolders list' 'searchctl jobs *' 'searchctl archivedfolders stats *'

4. Add an AD user to the group. The double backslash is required to escape the backslash character:

   sudo /usr/sbin/usermod -a -G operator AD02\\demo1

5. Optionally, remove a user from a group:

   sudo gpasswd -d AD02\\demo1 ecactl

6. Test the CLI commands as the new user.

Assign CLI Commands to a Role

Custom roles are based on a local OS group that can contain local users or AD users. The ecactl group is reserved for appliance administration. To add or remove CLI commands for a group:

searchctl settings groups add --name <group name> --cmd COMMANDS [COMMANDS ...]
searchctl settings groups remove --name <group name> --cmd COMMANDS [COMMANDS ...]

Examples:

• Give administrator access to all commands and subcommands:

  searchctl settings groups add --name ecactl --cmd '*'

• Give access to only searchctl archivedfolders list:

  searchctl settings groups add --name DemoGr1 --cmd 'searchctl archivedfolders list'

• Add multiple commands at once, separated by a space:

  searchctl settings groups add --name DemoGr1 --cmd 'searchctl archivedfolders *' 'searchctl jobs *'

Create a Custom Role

This example creates a role named role1 for an AD user AD02\demo1 in the domain AD02. It requires the appliance to be joined to Active Directory. The role provides monitoring and configuration commands to add, delete, or modify folder configurations and to start archive copy jobs.

1. Log in as ecaadmin over SSH.

2. Create the group:

   sudo /usr/sbin/groupadd role1

3. Add a user to the group:

   sudo /usr/sbin/usermod -a -G role1 AD02\\demo1

4. Add the CLI commands to the group:

   searchctl settings groups add --name role1 --cmd 'searchctl archivedfolders *' 'searchctl jobs *' 'searchctl archivedfolders stats *'

Grant Web UI Access

• Local OS administrator: After creating the local administrator as described above, add the user to the Web UI:

  searchctl settings admins add --name <OS user name> --local

  Then set the Web UI password. Log in to node 1 over SSH as ecaadmin and run the following command, entering the password after the user name. The new password is active immediately on all nodes.

  ecactl cluster exec "htpasswd -b /opt/superna/eca/conf/nginx/.htpasswd <user name> password"

• Active Directory user: AD users can access only the Web UI; no CLI access is granted. Login is proxied through to the PowerScale authentication provider, so the user must have access to at least one SMB share on the PowerScale cluster to test the password, and TCP port 445 must be open from node 1 to the PowerScale cluster. Use the user@domain syntax:

  searchctl settings admins add --name <AD user name>

Browse to https://x.x.x.x and log in with user@domain and the password. The user must be added as an administrator first.

Admin-Only Login Mode

Admin-only mode blocks all users who are not on the admin list from logging in, so end users do not need UI access. This includes the local ecaadmin account unless it is on the list. To view the admin list, run searchctl settings admins list.

1. Log in to node 1 of the Golden Copy cluster as ecaadmin over SSH.

2. Edit the configuration file:

   nano /opt/superna/eca/eca-env-common.conf

3. Add the following line and save the file (Ctrl+X):

   export SEARCHMW_ADMIN_MODE_ONLY=true

4. Restart the cluster for the change to take effect. Wait for the shutdown to complete before starting it again:

   ecactl cluster down
   ecactl cluster up

Only users on the admin list can then log in to run commands.

See Also

• References – CLI commands, folder definition parameters, and S3 target feature support notes.
• Disclaimers – Licensing dependencies and known product/version limitations.