Deletion Security

Introduction

Nasuni provides the means to restore files, directories, or entire volumes of lost or deleted material. However, this ability depends on the security of the cloud storage platform. It is necessary to protect against unwanted deletion of the following items:

Cloud storage accounts.
Cloud storage containers or buckets.

Unwanted deletion can occur for a variety of reasons:

Accidental deletion by an administrator.
Deliberate deletion by a malicious individual.

For these reasons, you should take steps available on your cloud storage platform to guard against unwanted deletion. The safeguards available depend on the individual platform. The purpose of this document is to acquaint you with some available safeguards for certain platforms.

Note: Third-party vendors can change or end support for features with little notice. Check with third-party vendors to verify the support for security features.

Important: When you add cloud credentials in Nasuni for a cloud storage provider, a bucket or container is automatically created to verify that the credentials work. This bucket or container is immediately deleted. However, for this deletion to work, delete privileges must be enabled for the storage account. After the cloud credentials are added, the delete privileges can be disabled again.

Nasuni Safeguards

Nasuni offers a number of safeguards to prevent, or mitigate, unwanted deletion. You might choose to employ some or all of these safeguards.

Safe Delete

To help ensure that one administrator cannot delete a volume accidentally or by themselves, you can specify how many administrators must approve deleting a volume. This feature is called “Safe Delete”. Only if the specified number of administrators approves the deletion does the volume become scheduled for deletion. Safe Delete settings are managed on a per-volume basis.

If Safe Delete is enabled for a volume, after the “Delete Volume” button is clicked, the following processing can take place:

Any of the volume-delete-capable administrators, not including the initiator of the delete, can click “Approve Delete” to approve the deletion of the volume.
If the required number of volume-delete-capable administrators approves the deletion, the volume is scheduled for deletion.
If any of the volume-delete-capable administrators clicks “Cancel Delete”, the volume’s deletion is cancelled.
If any volume-delete-capable administrator who approved deletion clicks “Revoke Approval”, their approval of the deletion is revoked.

All actions related to Safe Delete are logged, including the following:

Enable Safe Delete.
Disable Safe Delete.
Change required number of approvals.
Request volume delete.
Approval received.
Final approval granted.
Approval revoked.
Delete request cancelled.

If enabled, for each of these actions, a notification is created, and an email alert is sent.

In addition, once per day, a report is generated of all pending deletions, pending deletion approvals, and volumes recently deleted through the automated Safe Delete cleanup process. This report includes the state of volume pending deletion, which administrator initiated the pending deletion, and which administrators have approved the pending deletion. You can receive this report if you are configured to receive email alerts.

Microsoft Azure

The Microsoft Azure cloud storage platform offers a number of safeguards to prevent, or mitigate, unwanted deletion. You might choose to employ some or all of these safeguards. For details, see Security recommendations for Blob storage.

With Azure, you apply soft delete policies at the storage account level, and so any new Nasuni volume that is backed by Azure automatically has soft delete enabled. (This is because a Nasuni volume is backed by an Azure storage container, which is within an Azure storage account.) Therefore, for every new Azure storage account that you create and intend to use for Nasuni volumes, follow the Azure procedure to enable soft delete.

Storage redundancy

You should carefully consider the best redundancy options for your data and your organization. Considerations might include legally mandated locations for data, as well as geographic proximity to other resources.

Toward this end, Microsoft offers locally redundant storage (LRS), zone-redundant storage (ZRS), geo-redundant storage (GRS), and geo-zone-redundant storage (preview) (GZRS). For details, see https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy.

Locking resources

You can lock a subscription, a resource group, or a resource to prevent other users in your organization from accidentally deleting or modifying critical resources. You can set the lock level to CanNotDelete or ReadOnly.

CanNotDelete: Authorized users can still read and modify a resource, but they cannot delete the resource.
In the portal, this lock is called Delete.
ReadOnly: Authorized users can read a resource, but they cannot modify or delete. Applying this lock is similar to restricting all authorized users to the permissions granted by the Reader role.
In the portal, this lock is called Read-only.

A resource inherits any lock from its parent.

To create or delete management locks, you must have access to Microsoft.Authorization/* or Microsoft.Authorization/locks/* actions. Of the built-in roles, only the Owner role and the User Access Administrator role are granted those actions.

For more information, see https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources.

Preventing container delete access

You can use a shared access signature (SAS) to ensure that other users do not have the ability to delete items.

The purpose of the shared access signature is to allow users besides yourself to access resources in your storage account, but only with the permissions that you specify. For example, you can allow other users to read and write, but not delete.

Only the account owner can create the shared access signature (SAS).

Using this practice, no one but the account owner can delete one of your containers.

For more information, see https://social.msdn.microsoft.com/Forums/azure/en-US/ced7bbb4-54b1-484e-989e-538da16c1fbe/prevent-container-delete-access

Attaching to a VM

Azure prevents the deletion of a disk that is attached to a VM. It also prevents deletion of containers and storage accounts that have a page blob that is attached to a VM.

In addition, leased blobs cannot be deleted without breaking the lease first. Leased blobs that are not attached to a VM prevent deletion of the blob, but do not prevent deletion of the container or storage account.

You can use these features to protect disks, containers, storage accounts, and blobs from unwanted deletion.

For more information, see https://docs.microsoft.com/bs-latn-ba/azure/virtual-machines/troubleshooting/storage-resource-deletion-errors.

“Soft Delete” for blobs and containers

When enabled, soft delete enables you to recover your data when blobs or containers are deleted. This protection extends to blob data that is erased as the result of an overwrite.

Tip: Nasuni recommends a 30-day retention period if soft delete is enabled. Due to increased storage costs, we recommend contacting your Microsoft representative to determine these expenses beforehand.

When data is deleted, it transitions to a soft deleted state instead of being permanently erased.

When soft delete is on and you overwrite data, a soft deleted snapshot is generated to save the state of the overwritten data.

You can configure the amount of time soft deleted data is recoverable before it is permanently expired.

Soft delete is off by default. Nasuni recommends enabling soft delete with a retention period of 30 days.

Soft delete does not save your data in cases of container or account deletes.

For more information, see https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-soft-delete and https://docs.microsoft.com/en-us/azure/storage/blobs/soft-delete-container-overview

Amazon Simple Storage Service (Amazon S3)

The Amazon S3 cloud storage platform offers a number of safeguards to prevent, or mitigate, unwanted deletion. You might choose to employ some or all of these safeguards.

When you create a new Nasuni volume backed by Amazon S3, a new Amazon S3 bucket is created. That bucket has no policies on it by default, so you must follow these procedures in order to protect it. Therefore, for every new Nasuni volume you create that is backed by S3, you must follow this procedure to protect it.

Protecting against accidental deletion using versioning

You can use bucket versioning and lifecycle policies to add extra protection against accidental deletion. Nasuni recommends the following settings for any S3 bucket used for a Nasuni volume:

From the Bucket name list, click the name of the bucket that you want to enable versioning for.
Click the Properties tab.
In the Bucket Versioning area, click Edit. The Edit Bucket Versioning page appears.
Select Enable, and then click Save changes.
We additionally recommend creating a lifecycle rule to expire previous object versions after a specified time. This ensures that you continue to realize cost savings from deleted files, and on any volumes with a snapshot retention policy.
Click the Management tab, and then, in the Lifecycle rules area, click Create lifecycle rule. The Create lifecycle rule page appears.
In the Lifecycle rule name text box, type a name for your rule, to help identify your rule later.
Select “Apply to all objects in the bucket”.
Then select “I acknowledge that this rule will apply to all objects in the bucket.”.
The option “Limit the scope of this rule using one or more filters” is not supported by Nasuni.
In the Lifecycle rule actions area, enable “Permanently delete noncurrent versions of objects”.
The “Permanently delete noncurrent versions of objects” area appears.
Enter the “Days after objects become noncurrent”. Nasuni recommends 30 days. Selecting a longer duration involves a tradeoff between limiting potential cost savings, but receiving the extra protection for that duration.
In the Lifecycle rule actions area, enable “Delete expired object delete markers or incomplete multipart uploads”.
The “Delete expired object delete markers or incomplete multipart uploads” area appears.
Make sure that both “Delete expired object delete markers” and “Delete incomplete multipart uploads” are unchecked. Nasuni does not support these options.
Verify the settings for your rule. Click Create rule.

If the rule does not contain any errors, it is created, listed on the Lifecycle page, and enabled.

Using IAM to prevent accidental deletion of Amazon S3 buckets

Nasuni stores all data in Amazon S3 buckets, including all versions, in UniFS format. Each individual Nasuni volume corresponds to an individual Amazon S3 bucket. It is important to prevent someone with API or AWS Management console access from accidentally deleting a bucket used by Nasuni.

The following steps provide a procedure that uses Identity and Access Management (IAM) to protect your Nasuni data in Amazon S3 from accidental deletions. The steps create two groups, one that allows access to the S3 buckets that back Nasuni volumes, and one that disallows access to those S3 buckets. In general, all IAM users should belong to the “disallow” group, while only the IAM credentials used for the Edge Appliance should belong to the “allow” group.

Note: There are other possibilities to achieve the same result, such as a strict policy to implement IaC (Infrastructure as Code) while all interactive console administrative users have read permissions only.

Important: You must have created an Amazon Simple Storage Service account. See http://aws.amazon.com/s3/.

Note: Confirm with Nasuni Sales or Support that your Nasuni account is configured for supplying your own Amazon Simple Storage Service credentials.

Defining “Nasuni-S3-Volume-Credentials”

In the NMC or Edge Appliance UI, you must enter storage credentials to use for Nasuni volumes backed by Amazon S3. Best practices dictate that these storage credentials have minimal privileges: only the permissions that they need to accomplish their actions. The “Nasuni-S3-Volume-Credentials” group defined on the next pages represents that minimal set of permissions. You create a Group in IAM with such a minimal policy, and then you create an IAM User in that Group. From that IAM User you get an Access Key and a Secret Key to use in your Nasuni NMC or Edge Appliance.

To define Nasuni-S3-Volume-Credentials, follow these steps:

2. Click IAM. The Identity and Access Management (IAM) page appears.

Click Groups. The Groups pane appears.

Create a group for Nasuni S3 access only. This group should only be used for Nasuni S3 volume credentials.
Click Create new Group. The Create New Group Wizard appears.

Enter a Group Name (such as “Nasuni S3 volume credentials”), then click Next Step. The Attach Policy pane appears.

Select AmazonS3fullAccess, then click Next Step.
Review the features, then click Create Group.
The new group is created and appears in the list of groups.
Click the new group, and review the group permissions.
From the Identity and Access Management (IAM) menu, click Users, then click Add User. The Add user page appears.

Create one or more users for Nasuni S3 volume credentials only, with no interactive logon credentials.
Enter a User name (such as “Nasuni S3 volume credentials user”), then select only Programmatic access. Nasuni Edge Appliances only communicate using the S3 API, using Access Key ID and Secret Access Key for all create, put, get, list, and delete actions. AWS Management Console access is not required.
Click Next: Permissions. The Set permissions pane appears.

Assign the user to the Nasuni S3 volume credentials group.
Click Next: Tags. The Add tags pane appears.
Click Next: Review. The Review pane appears.
Click Create user. The new user is created and appears in the list of users.
Click the new user in the list, then click the Security credentials tab.

Verify that the Console password is Disabled.

Defining other users

It is also useful to create a group that every other user of this AWS account should be a member of, in order to ensure that no casual user of this account has the ability to delete the S3 buckets that back Nasuni volumes. It is actually preferable to not have any other users in this account at all, but we are presenting this procedure in case you do want to have other users.

Any other IAM user of this account should have a policy that prevents the accidental deletion of the S3 buckets that back Nasuni volumes. The following procedure shows how to create such a group and policy. However, it is your responsibility to ensure that every other IAM user in this account is a member of this group.

To define all other users (both interactive and programmatic), follow the following steps:

Go to the Identity and Access Management (IAM) page. Click Policies. Click Create policy. Click the JSON tab.

A screenshot of a cell phone Description automatically generated

Create a permissions policy preventing Delete Actions for Nasuni buckets.

Note: All Nasuni buckets start with “nasunifiler*”.

Create a permissions policy such as the following:

{

"Version": "2012-10-17",

"Statement": [

{

"Sid": "VisualEditor0",

· "Effect": "Deny",

"Action": [

"s3:DeleteBucketWebsite",

"s3:DeleteObjectVersion",

"s3:DeleteObject",

"s3:DeleteBucket"

"Resource": "arn:aws:s3:::nasunifiler*"

}

]

}

Click Review policy.
Enter a Name for this policy (such as “Prevent Deletions”), then click Create policy.
The new policy appears in the list of permissions policies.
Attach the new policy to any Groups that have administrative access to the AWS console by following these steps:
1. Select the new policy from the list of Policies.
2. From the Policy actions drop-down list, select Attach, then select the Groups and click Attach policy.
3. The policy is attached to the groups.
Attach the new policy to any Users that have administrative access to the AWS console by following these steps:
1. Select the new policy from the list of Policies.
2. From the Policy actions drop-down list, select Attach, then select the Users and click Attach policy.
3. The policy is attached to the users.
Specifically test the effectiveness of the policy with the IAM Policy Simulator by following these steps:
1. From the Identity and Access Management (IAM) menu, click Dashboard, then click Policy Simulator on the right side. The IAM Policy Simulator appears.
2. Create a simulation, by selecting items such as the following:
  1. Group: such as Admin.
  2. For that group, a Policy: such as the new policy.
  3. From the Select service drop-down list: Amazon S3.
  4. From the Select actions drop-down list: such as DeleteBucket.
3. Click Run Simulation, then examine results.
For example, the Admin group with a Nasuni bucket deletion prevention policy assigned has the permission denied when trying to simulate DeleteBucket for a bucket resource that starts with “nasunifiler*”.

Google Cloud Storage

The Google Cloud Storage cloud storage platform offers a number of safeguards to prevent, or mitigate, unwanted deletion. You might choose to employ some or all of these safeguards. For details, see Deleting Data.

Retention policy

A retention policy specifying a retention period can be placed on a bucket. Then an object in the bucket cannot be deleted until it reaches the specified age.

Object hold

An object hold can be placed on individual objects to prevent anyone from deleting the object until the hold is deliberately removed.

Object versioning

Object versioning can be enabled on a bucket in order to retain older versions of objects. When the live version of an object is deleted, it becomes noncurrent. If you accidentally delete a live object version, you can restore the noncurrent version of it back to the live version.

Caution: Object Versioning does not protect your data if you delete the entire bucket.

Object Versioning increases storage costs, but you can partially mitigate this by configuring Object Lifecycle Management to delete older object versions.