What are Wasabi's recommended general user security Best Practices?

1. Introduction

This article covers recommended security best practices for users of the Wasabi cloud storage service. While it is not an exhaustive list of security measures that may be taken, it covers the fundamentals that will help ensure the Confidentiality, Integrity, and Availability of your cloud data. Topics covered include encryption, authentication, data replication, immutability, logging, and security policies. This article is not meant to be a substitute for generally available security practices, but rather a guide to help implement those practices to protect your Wasabi cloud data.

2. Encryption

2.1 Data in transit encryption

Ensure that your S3 clients are using HTTPS transport, i.e., the URL contains “https” as in the example of https://s3.us-east-2.wasabisys.com/. See Service URLs for Wasabi's Storage Regions for the list of URLs that are used to access the different Wasabi cloud regions.  

Reference How do I restrict bucket access with resource-based policies? for example bucket policies that limit access to be HTTPS only. 

2.2 Data at rest encryption

By default, Wasabi encrypts each storage object using a random Advanced Encryption Standard (AES) 256-bit key. The key is stored in the Wasabi meta-data secure layer of the Wasabi system (until the object is deleted) and is used again for decryption when the object is retrieved. More information can be found at How Does Wasabi protect against malicious encryption?.

Objects may be encrypted instead by using Server-Side Encryption with Customer-provided keys (SSE-C). More information can be found at How secure is my data?.  Note that Wasabi only stores a cryptographic hash of the SSE-C encryption key to ensure future decryption requests are using the proper key. We do not store the SSE-C keys themselves. Management of the keys is the responsibility of the customer in this case.

Client-Side Encryption: Customers may also encrypt objects at their own site before transmitting to Wasabi, with the customer managing the keys and encryption/decryption process.

3. Authentication

3.1 Access and Secret Keys 

Access and secret keys are used by applications using the S3 protocol for Application Programming Interface (API) access to your data. The access keys can be thought of as API usernames, and the secret keys as API passwords.  Keep your access and secret keys in a safe place, such as in a password manager, encrypted file, etc.  In the event your keys are compromised, delete them on the Wasabi console (https://console.wasabisys.com/) and generate new ones. This will require updating the keys on your S3 clients after generating new access/secret key pairs.

Each user, such as the root user and each sub-user, may have two access/secret key pairs at any given time, whether active or inactive.

Consider not using any root user access/secret keys and instead use keys only for sub-users.

Rotate your root (if the root user is using keys) and sub-user access/secret key pair(s) at least as frequently as your security policy dictates changing passwords.

• Generate new key pair(s) on the Wasabi console.

• Update your S3 clients with the new access/secret keys.

• Set the old key pair(s) to Inactive.

• Test to make sure your S3 clients can access necessary bucket objects.

• After successful testing, delete the older key pair(s).  

More information can be found in the Access Keys section of the user guide.

3.2 Passwords and MFA

Multi-Factor Authentication (MFA) can be used to reduce the risk of a rogue user being able to access your account and data. Generally speaking, MFA includes factors such as a password (what you know) and other forms of authentication such as what you have (e.g. your phone), and who you are (such as biometrics). Wasabi supports MFA for access to your account. See Which virtual MFA applications have been tested with Wasabi? for more information.  

Use MFA on the Wasabi console.  

• For the customer root user, in the Wasabi console click on Settings on the left hand side, then Security Settings, then MFA Settings, and follow the on-screen instructions.

• To enable MFA for sub-users, in the Wasabi console click on Users on the left hand side, then click on a particular user’s profile, then turning on the “Require MFA” switch.  Repeat for each sub-user. MFA for sub-users can also be enabled when creating a new sub-user.

• To allow users to enable, manage, and use MFA, implement the IAM policy listed in How do I allow users to change passwords and enable MFA?. Sub-users may then in the Wasabi console click on Settings, then Security Settings, then MFA Settings, and follow the instructions.  

If using the Wasabi Account Control Manager (WACM), MFA is supported there as well. Login to WACM, click on your name in the top right corner, then My Profile.  Under Multi-Factor Authentication > One-time Password, click on Turn On, and follow the on-screen instructions.

Utilize a strong, unique password such as a random one generated by a password manager.  Do not share your password.

A password policy can and should be defined by the customer’s root user in the Wasabi console for the root user and all sub-users. Please note that a password policy is not set by default – a root user must specify a password policy.  For example, requiring a minimum password length, an uppercase letter, a lowercase letter, a number, and a non-alphanumeric character can be mandated.  The number of failed login attempts before a user gets locked out, the auto-expiration of passwords, and preventing password reuse can also be specified by the customer root user. See Defining User Password Settings for more details. For ease of administration, the “Allow users to change their own password” should be toggled to enabled if sub-users have console access.  

3.3 Multi-User Authentication

Multi-User Authentication (MUA) can be used to prevent account deletion and/or bucket deletion by a rogue user.  A customer root user can assign up to three security contacts who must unanimously approve of an attempted account and/or bucket deletion.  Multi-Factor Authentication (MFA) is required to create, modify, or delete any security contact.  If a security contact denies the account or bucket deletion, the root account user will receive a message notifying that an attempt was made to delete the account or bucket and a security contact denied the action.

Additionally, there is no limit to the number of activities that these contacts can oversee.  The security contacts do not need to have access to the Wasabi console, so there is no risk of the security contacts’ Wasabi console credentials being compromised.

3.4 Single Sign On (SSO)

SSO is important because it enhances the user experience and productivity by allowing users to access multiple applications and systems with a single set of credentials. Additionally, SSO improves security by reducing the risk of weak passwords and enabling centralized authentication and access control.  Using SSO gives you the ability to use your own Identity Provider (IdP) for MFA when logging in. SSO eliminates the need for creating multiple logins and passwords and activating MFA for each user.  Consider using SSO if your organization has implemented it for other applications.

The Wasabi console, Wasabi Account Control Manager (WACM), and Custom Cloud Console (CCC) support using SSO, allowing you to assign roles to users and attach access policies to those roles.  See Configuring SSO for the Wasabi Console or search for “SSO” in the Wasabi Academy for a list of related articles.  Both OpenID and SAML 2.0 are available, and multiple Identity Providers (such as Azure Active Directory, Okta, etc.) are supported.

4. Immutability

Immutability means that data cannot be modified or deleted. This is especially useful to protect your company from ransomware, malware, rogue users trying to delete data, etc.

4.1 Overview of Immutability Features

Utilize Wasabi’s immutability features, i.e., Object Lock with or without Governance Mode or Compliance Mode. The selection of which form of immutability to use will depend on your specific needs, such as if your backup application supports Object Lock integration.

Note:  For immutability some backup applications such as Veeam, CommVault, and others require the use of Object Lock without Bucket-Level Object Retention. See the “Third-Party Integrations” section in Wasabi Object Lock for more details.

Caution: Governance Mode allows the root user and users with the proper IAM permissions to disable the function and delete data. It is highly recommended NOT to use Governance Mode unless you have a specific need for it.  Use Compliance Mode instead of Governance Mode.

For Bucket-Level Object Retention, Compliance Mode or Governance Mode can only be set when enabling Object Lock at the time of bucket creation  See Wasabi Object Lock and Difference Between Compliance and Object Lock for details on each feature.

4.2 Object Lock

Object Lock applies to individual objects in a bucket.  

Wasabi Object Lock and Bucket Versioning (which is required for Object Lock) may be enabled only during bucket creation.  

Note: Make sure your backup application supports Object Lock integration.

4.3 Compliance

Compliance Mode and Governance Mode applies to an entire bucket. It is controlled entirely by the bucket settings. There are two ways of setting up Compliance Mode on the Wasabi console:

• With an Object Locked bucket (see Object Locking)

• Without Object Lock (see Compliance)

Compliance Mode can also be enabled on the Wasabi Cloud NAS application. 

Upon successful testing of the Compliance settings with your application(s), including Retention settings, lock the Compliance settings by clicking on the blue warning in the console and typing "agree".  Only Wasabi Support can unlock the settings afterwards, thus helping prevent malicious or accidental changing of the settings.  

Note that after being locked the Retention Time may be increased on the console, but not decreased, and Compliance cannot be disabled by the user.

5. Logging

Logging of account and bucket access helps aid in troubleshooting, incident response, and early intervention when unauthorized access is suspected.  

Enable bucket logging for each bucket and use a separate target bucket, with separate logging prefixes for each source bucket. See Does Wasabi support data access auditing? (Bucket Logging) for more details.

Utilize Compliance on the target bucket. See Section 5 for information about Compliance. Set a Retention Time that meets your requirements, and keep in mind that logs can continue to grow over time and use your Wasabi cloud storage.

Wasabi’s Lifecycle feature should also be used to delete older logs that have passed the Retention Time. For example, say that you have a Retention Time of 90 days.  You would want to set the Lifecycle Expiration Days to 91 days or greater. On the Wasabi console, click on Buckets, then the name of the target logging bucket, Settings (gear wheel), the Lifecycle tab, then Create New Rule. 

Note: Do not use the Lifecycle feature on buckets where other applications, such as backup applications, manage the life of objects in the bucket.  

Utilize Administrative Logs on the Wasabi console to log root and sub-user login attempts, password resets, etc. See How do I get Console User Access Audit Logs? and Downloading Administrative Logs for details.

6. User Access Restrictions