RDS instances and S3 buckets confirmed unencrypted at rest
What does ZopNight detect here?
Coverage here is exactly 2 resource types: RDS instances and S3 buckets. Each fires only when discovery confirms encryption is off. EBS volumes are deliberately excluded to avoid double-flagging the same volume alongside the dedicated EBS rule, and both remediations require rebuilding the resource rather than flipping a setting.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-087 |
| Category | compliance |
| Severity | high |
| Metric | none — pure configuration read |
| Source | encryption_at_rest.go |
Two resource types, on purpose
The rule sounds generic but its scope is exact: RDS instances (reading the engine’s storage encryption state) and S3 buckets (reading the default-encryption probe). EBS volumes used to be in scope too, and every unencrypted volume then received two findings (this rule plus the dedicated EBS rule) reading the same underlying flag. The EBS branch was removed so each resource has one owner, which is worth knowing when you wonder why your unencrypted volume appears elsewhere in the directory.
Only a confirmed “no” fires
Discovery writes the encryption state as an explicit boolean. When the flag is absent, because the probe failed or was denied, the rule abstains rather than treating silence as exposure. So findings here are proven states, not inferences, and severity is high because the exposures are real: unencrypted RDS storage and snapshots readable if access controls slip, and required by PCI DSS, HIPAA, and SOC 2 alike.
RDS: the fix is a rebuild
RDS storage encryption cannot be enabled on a live instance. The path is snapshot → copy the snapshot with encryption and a KMS key → restore a new instance from the encrypted copy → repoint applications. On a large production database that is a scheduled migration with a cutover window, not a settings change. That is exactly why these findings age badly and why starting encrypted is so much cheaper than retrofitting.
S3: the gap is subtler than “unencrypted”
Since January 2023 every S3 bucket applies SSE-S3 by default, so on recent buckets the real findings are usually the absence of SSE-KMS with a customer-managed key (no audit trail, no revocation lever) or the absence of enforcement on writes. Upgrading default encryption does not touch existing objects; re-encrypting history takes an S3 Batch Operations copy. A bucket policy denying unencrypted PUTs is what stops regression.
Spot-check the RDS side
aws rds describe-db-instances \ --query 'DBInstances[?StorageEncrypted==`false`].[DBInstanceIdentifier,Engine]' --output tablePair it with aws s3api get-bucket-encryption --bucket <name> per bucket on the S3 side, and
enable default EBS encryption separately. That account-level switch prevents the sibling
rule’s findings, not this one’s.