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.
NOTE: This article is not an exhaustive security framework or a substitute for general security practices, but rather is 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 always using HTTPS for s3 access, i.e., the URL contains “https”. Example: https://s3.us-east-2.wasabisys.com/. See Service URLs for Wasabi's Storage Regions for the list of URLs listed by Wasabi storage region.
Refer to the following Wasabi Academy Knowledge Base articles:
How do I restrict bucket access with resource-based policies?: provides example bucket policies that limit access to be HTTPS only.
How Does Wasabi protect against malicious encryption?: provides additional information regarding Wasabi data encryption.
2.2 Data at rest encryption
Default Encryption: every object is encrypted with a randomly generated Advanced Encryption Standard (AES) 256-bit key, which is stored in Wasabi’s secure metadata layer of the Wasabi until the object is deleted. This key is used again for decryption when the object is retrieved. More information can be found in the How secure is my data? Wasabi Academy Knowledge Base article.
Server-Side Encryption with Customer Keys (SSE-C): Provides customers the option to bring their own encryption keys. Only a cryptographic hash of your key is stored. Wasabi never stores your actual key; customers must manage their own keys. More information can be found in the Server-Side Encryption with Customer-provided keys (SSE-C) Wasabi Academy Knowledge Base article.
Client-Side Encryption: Customers may also encrypt objects at their own site before upload/transmitting to Wasabi; customers maintain full key ownership and lifecycle.
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 (root user or sub-user) may have up to two key pairs at a time, whether active or inactive.
Do not use root keys - always prefer to use scoped sub-user keys.
Compromise Response & Rotation (prescriptive steps):
Generate new keys via the Wasabi console.
Update S3 clients with the new keys.
Set the old keys to inactive.
Test access.
Delete old keys.
Rotate Guidance: Rotate keys at least as frequently as your organization rotates passwords.
More information can be found in the Access Keys section of the user guide.
3.2 Passwords and MFA
Password Policy:
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: a password policy is not set by default – a root user must specify a password policy and Wasabi recommends the following guidance:
Require strong passwords (i.e, 12 or more characters, uppercase, lowercase, number, and/or special character).
Set password expiration (i.e, 90 days).
Enforce lockout after failed login attempts.
Prevent reuse of previous passwords.
Allow sub-users to change their own passwords (toggle in Console).
Never share your password.
More information can be found the following sections of the user guide:
MFA Policy:
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. More information can be found in the following sections of the user guides:
Which virtual MFA applications have been tested with Wasabi?
Viewing the MFA Status of Wasabi Account Control Manager Users
Use MFA, with the following recommendations:
Required for root and sub-users.
Enable via Console: Settings > Security Settings > MFA Settings (root).
Sub-users: Users > Profile > Require MFA toggle.
WACM: My Profile > Multi-Factor Authentication > Turn On.
Required for sensitive actions like changing alert settings.
3.3 Multi-User Authentication (MUA)
Multi-User Authentication (MUA) can be used to prevent account deletion and/or bucket deletion by a rogue user. There is no limit to the number of activities that these contacts can oversee, and security contacts do not need to have access to the Wasabi console Features and benefits include:
Prevents unauthorized account/bucket deletion.
Assign up to three security contacts.
All contacts must unanimously approve deletions.
MFA required to manage security contacts.
Contacts do not need Console access, minimizing credential comprise and other risks.
If a deletion is denied, the root user is notified.
Contacts can oversee unlimited activities.
More information can be found in the MUA (Multi-User Authentication) user guide.
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. Features and benefits of the SSO function include:
Supports OpenID and SAML 2.0 (i.e, Azure AD, Okta).
Works across Wasabi Console, Wasabi Account Control Manager (WACM), and Custom Cloud Console (CCC).
Improves user productivity (one set of credentials).
Reduces weak password risk.
Allows centralized MFA enforcement via your Identity Provider.
More information can be found in the SSO (Single Sign On) user guide.
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. 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.
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 Identity Access Management ( 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.
Protects against ransomware, malware, or rogue deletion attempts.
Choose between Object Lock and Bucket-Level Retention.
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.
Overview:
Enabled only at bucket creation.
Requires bucket versioning.
Applies immutability per object.
Compatible with many backup tools (Veeam, Commvault, etc.).
More information can be be found in the Object Lock and Bucket Versioning user guides.
4.3 Compliance Mode (Recommended)
Compliance Mode applies to an entire bucket, and cab be enabled with or without Object Lock. Features include:
Prevents deletion or modification during retention period.
Lock workflow: type “agree” in Console → only Wasabi Support can unlock.
Once locked, retention can be increased but not decreased.
Also supported in Wasabi Cloud NAS.
More information can be be found in the following user guides:
Compliance Mode with an Object Locked bucket (see Object Lock)
Compliance Mode without Object Lock (see Compliance)
Note: After being locked, the retention time may be increased on the console; however, the retention time cannot be but not decreased. In addition, Compliance Mode cannot be disabled by the user.
4.4 Governance Mode (Use with caution)
Governance Mode applies to an entire bucket.
Allows deletion if IAM permissions are granted.
Use only if you have specific needs not met by Compliance Mode.
5. Logging
Logging of account and bucket access helps aid in troubleshooting, incident response, and early intervention when unauthorized access is suspected. Wasabi provides the root user(s) access to Bucket Logging, Compliance Logging, and Administrative Logging. More information can be found in the Console User Access to Audit Logs user guide.
5.1 Bucket Logging
Must be enabled separately for each bucket.
Sends logs to a dedicated s3 bucket in the customer’s account with a unique filename prefix
Follows any rules the root user configures using Object Lifecycle Management.
5.2 Administrative Logging
Administrative Logging tracks and exports console events, including:
Logins
MFA changes
Password resets
Key creation and deletion, provided the key was created within the console (vs. using SSE-C)
5.3 Compliance For Logging
Information on Setting Compliance Logging for a Bucket can be found in the user guide. The basic steps:
Apply Compliance Mode to a bucket.
An Example of retention of 90 days requires a Lifecycle expiration set at 91 days.
The Console path: Buckets > Target Log Bucket > Settings > Lifecycle > Create Rule.
CAUTION: Do not apply lifecycle rules to buckets managed by 3rd party backup software.
6. User Access Restrictions
In the case where sub-users are created on your account:
Use separate access and secret keys for each sub-user. Keys are initially created when the sub-user is created.
API versus Console Access
Consider giving sub-users API-only, not console, access. This will allow them to use an S3 client to access their bucket data, but not access the Wasabi console.
7. IAM and Bucket Policies
For cases where sub-users are defined on the account, Identity and Access Management (IAM) policies and bucket policies may be used to restrict who can access customer data.
More Information can be found in the How to Separate Access at a Bucket Level user guide.
7.1 IAM (Identity-Based Policies)
Permits root users to attach a policy to users or groups to allow specific actions (i.e, list buckets, change MFA/password).
An example IAM policy: permit users to change their own passwords and MFA settings.
7.2 Bucket Policies (Resource-Based)
Policies applied to s3 buckets in order to:
Enforce HTTPS-only access.
Restrict access by an IP address range or to the account.
7.3 Policy Management Guidance
Suggested guidance:
Prefer using one approach, but hybrid IAM + bucket policies may be valid in some cases (i.e, IAM to list buckets, bucket policies for HTTPS/IP enforcement)
8. Security Health Monitoring
8.1 Security Health Check
Access the the Security Health Check via the Security Center in the Console, which will then display the configuration status for the following functions:
User session activity IAM policy misconfigurations
8.2 IAM Credential Report
This exportable audit report shows:
Access key age and usage
MFA status for each user
User activity flags
8.3 Egress Monitor
This monitor:
Alerts on anomalous data egress patterns
Define thresholds for automatic alerts on large or unexpected transfers
Click here to learn more about Egress Monitor.
9. Contact Resources
Please contact compliance@wasabi.com with any questions and/or for Wasabi policy summaries.
Please contact support@wasabi.com with any technical questions about any of the above suggested best practices.