Wasabi security review using the AWS CIS Benchmark
Leveraging the CIS AWS Foundations Benchmark to fill the gap in Wasabi security assessment standards.
Published: Fri, September 26, 2025
A few months ago, I had to perform a security review of a Wasabi environment. Having done something similar in AWS, I knew that having a reference for best practices would help a lot. But I could not find anything back then, besides the sparse information in Wasabi's docs. So the idea of adapting the AWS CIS Benchmark (CIS AWS Foundations Benchmark) struck me, as there are similarities in the APIs and features offered by Wasabi for cloud storage and Identity and Access Management (IAM). The benchmark for AWS was at v4.0.0 during the time of my assessment, so my post follows this version exclusively, although it's at v6.0.0 as of today.
Here's some good information about CIS Benchmarks from AWS: What are CIS Benchmarks?
Wasabi
Wasabi is a cloud storage service that provides an AWS S3-compatible storage API. It offers a simple and cost-effective solution for storing data in the cloud.
The Wasabi Cloud Object Storage service and its IAM service have similarities with that of AWS, and we can pick certain controls from the CIS Benchmark and adapt it for Wasabi.
Summary of recommendations
As I mentioned, we can pick certain controls related to AWS S3, IAM and logging, and adapt them for Wasabi. The table below is a summary of such controls:
Summary of recommendations based on CIS AWS Foundations Benchmark v4.0.0:
Recommendation | CIS Benchmark Mapping | Set Correctly ( YES / NO ) | Remarks |
---|---|---|---|
1. Identity and Access Management | See: Authentication | ||
1.1 Ensure no 'root' user account access key exists | 1.4 | 3.1 Access and Secret Keys | |
1.2 Ensure MFA is enabled for the 'root' user account | 1.5 | 3.2 Passwords and MFA | |
1.3 Ensure hardware MFA is enabled for the 'root' user account | 1.6 | 3.2 Passwords and MFA Can be waived off according to our threat model. | |
1.4 Eliminate use of the 'root' user for administrative and daily tasks | 1.7 | ||
1.5 Ensure IAM password policy requires minimum length of 14 or greater | 1.8 | 3.2 Passwords and MFA | |
1.6 Ensure IAM password policy prevents password reuse | 1.9 | 3.2 Passwords and MFA | |
1.7 Ensure multi-factor authentication (MFA) is enabled for all IAM users that have a console password | 1.10 | 3.2 Passwords and MFA | |
1.8 Do not create access keys during initial setup for IAM users with a console password | 1.11 | 3.1 Access and Secret Keys | |
1.9 Ensure credentials unused for 45 days or more are disabled | 1.12 | ||
1.10 Ensure there is only one active access key for any single IAM user | 1.13 | 3.1 Access and Secret Keys | |
1.11 Ensure access keys are rotated every 90 days or less | 1.14 | 3.1 Access and Secret Keys | |
1.12 Ensure IAM users receive permissions only through groups | 1.15 | ||
1.13 Ensure IAM policies that allow full "*:*" administrative privileges are not attached | 1.16 | ||
1.14 Ensure IAM users are managed centrally via identity federation | 1.21 | ||
2. Storage | |||
2.1 S3 / Cloud Object Storage | |||
2.1.1 Ensure S3 Bucket Policy is set to deny HTTP requests | 2.1.1 | How do I restrict bucket access with resource-based policies? | |
2.1.2 Ensure MUA Delete is enabled on S3 buckets | 2.1.2 | Authentication > 3.3 Multi-User Authentication If enabled, multiple users need to sign-off before deleting the bucket. | |
2.1.3 Ensure that S3 is configured with 'Block Public Access' enabled | 2.1.4 | How can I check if my bucket is private? | |
2.1.4 Ensure that the bucket objects are encrypted at rest | - | Can enable encryption with customer-managed key as well. | |
3. Logging | |||
3.1 Ensure console user access audit logging is enabled | - | How do I get Console User Access Audit Logs? | |
3.2 Ensure that server access logging is enabled on the audit logging S3 bucket | 3.4 | Logging: Enabling/Disabling for a Bucket | |
3.3 Ensure that object-level logging for write events is enabled for S3 buckets | 3.8 | Logging: Enabling/Disabling for a Bucket | |
3.4 Ensure that object-level logging for read events is enabled for S3 buckets | 3.9 | Logging: Enabling/Disabling for a Bucket |
Last updated on