The AES-256 Marketing Problem
Open the pricing page of almost any cloud storage provider and you will find AES-256 encryption listed as a security feature. AWS lists it. GCP lists it. Azure lists it. IBEE lists it. Every credible cloud storage platform has offered AES-256 encryption at rest for years.
The problem is that AES-256 at rest has become a checkbox: something providers list to signal they take security seriously, and something buyers check off without asking what the complete security picture looks like. Encryption at rest is the floor of cloud storage security, not the standard. It prevents someone who physically removes a hard drive from reading the data. It does nothing against a compromised access credential, an over-permissive IAM policy, an attacker who has obtained valid API keys, or an insider threat with legitimate access.
A complete cloud security baseline for production workloads covers more than encryption at rest. It covers the full chain from data ingestion to access to audit to retention, and it covers the jurisdictional question of who can compel access to the audit trail. In our experience reviewing cloud configurations for Indian companies preparing for CERT-In audits, encryption at rest is nearly always in place. The gaps are almost always in IAM scope, audit log retention, and jurisdiction.
The Six Elements of a Complete Cloud Storage Security Baseline
1. Encryption at Rest: AES-256
Data stored on disk should be encrypted using AES-256. This protects against physical media theft or unauthorised physical access to storage hardware.
The question worth asking is not whether encryption at rest is available, but whether it is enabled by default. Default-on encryption is meaningfully more secure than opt-in encryption because it eliminates the category of breaches caused by misconfigured or newly created buckets that were not explicitly encrypted. A team that creates fifty buckets over two years and manually enables encryption on forty-nine of them has a problem.
On IBEE, AES-256 encryption at rest is enabled by default on all storage. There is no configuration step that can accidentally be missed.
2. Encryption in Transit: TLS 1.3
Data moving between an application and cloud storage, including upload requests, download responses, and API calls, should be encrypted using TLS 1.3. Older versions of TLS have known vulnerabilities. Connections that accept TLS 1.0 or 1.1 are a real attack surface, particularly for applications running in environments where network traffic can be intercepted.
The question to ask the provider is not whether TLS is supported but whether deprecated protocol versions are still accepted. A storage endpoint that allows TLS 1.0 connections for backward compatibility is a security gap regardless of whether TLS 1.3 is also available.
3. IAM Access Controls: Principle of Least Privilege
Identity and Access Management determines who can do what to which storage resources. A well-configured IAM setup ensures that an application only has access to the specific buckets it needs, with the specific permissions its function requires: read, write, delete, or list, but not all four unless all four are genuinely needed.
The failure mode here is almost always over-permissive IAM. A service account with full S3 access used for a single read-only reporting job, or a developer credential used in production that grants delete permissions when the application only ever reads: when that credential is compromised, the blast radius is determined entirely by how much the IAM policy permitted. A scoped read-only credential that is compromised is a contained incident. A full-access credential that is compromised is a catastrophe.
A complete IAM configuration covers per-application service accounts with scoped permissions, no wildcard resource permissions in production, separate credentials for read and write operations where practical, regular rotation of access keys on a schedule of no more than 90 days, and bucket policies that restrict access by IP range or VPC where the application's network boundaries are known.
4. Bucket Versioning
Versioning retains previous versions of objects when they are overwritten or deleted. This protects against accidental deletion, ransomware that encrypts or deletes files, and application bugs that overwrite data incorrectly.
Without versioning, a malicious actor with write access who deletes data creates an irrecoverable situation. With versioning enabled, a delete operation marks the object as deleted but retains previous versions for a configurable period, and the deletion can be reversed. For regulated data such as medical records, financial documents, and legal archives, versioning is often a compliance requirement rather than just a best practice.
5. Audit Logging: The Record That Proves What Happened
Audit logs record every API call against storage: who accessed which object, from which IP address, at what time, using which credential, and what the result was. This is the forensic record that makes a security incident investigation possible, and it is what CERT-In requires Indian organisations to maintain.
CERT-In's April 2022 mandatory directions require IT system logs to be maintained for 180 days, stored within Indian jurisdiction, and made available to CERT-In within six hours of a direction to provide them.
The jurisdictional requirement is the one that catches organisations using foreign-operated cloud platforms. Audit logs stored on AWS or GCP are accessible to Indian security teams, but they are also potentially accessible to US federal authorities under the CLOUD Act, and the storage is ultimately governed by US legal frameworks rather than Indian ones. For a company being asked by CERT-In to produce logs within six hours, the question of which legal framework governs access to those logs is not theoretical.
IBEE includes audit logging as standard, with 180-day retention within Indian jurisdiction by default. No additional configuration is required, and there is no extra cost.
6. Access Key Management and Rotation
Access keys, the API credentials used by applications to authenticate against cloud storage, are the most common entry point for cloud breaches. A key committed to a public GitHub repository, included in a Docker image, or left in a decommissioned server's configuration file is a credential that will eventually be discovered and exploited. This is not a hypothetical: automated scanners continuously index public repositories and cloud metadata endpoints for exposed credentials.
A complete key management practice covers: no long-lived root credentials used by applications, scoped service account keys with minimal permissions, a rotation schedule of 90 days maximum, automated detection of credentials accidentally committed to version control, and an immediate revocation protocol for any credential that is suspected to be compromised. The revocation step is the one that most teams do not have documented until they need it urgently.
The CERT-In Audit Checklist for Cloud Storage
The six questions a CERT-In audit will ask about your cloud storage configuration.
Common Security Misconfigurations in Cloud Storage
Public buckets are the single most common and most damaging cloud storage misconfiguration. Bucket permissions set to public-read expose every object in the bucket to the internet without authentication. Several significant Indian data breaches in recent years have been caused by accidentally public S3 buckets, typically created by a developer for testing and never locked down before production data found its way in.
Overly permissive bucket policies are nearly as common. Policies that allow any authenticated user within the account to read or write, rather than scoping access to specific roles or services, mean that compromising any credential in the account is sufficient to access all data.
Logging disabled by default is a configuration risk that many teams do not discover until after an incident. The default configuration on many cloud platforms disables access logging. Teams that rely on default configurations may be running storage buckets with no audit trail, which means both that incidents cannot be investigated and that CERT-In compliance obligations are being violated continuously.
No versioning on critical data leaves regulatory data, financial records, and customer data with no recovery path if accidentally deleted or corrupted. This is the misconfiguration that turns an accident into a catastrophe.
Credentials in environment variables on shared systems, where they are visible to any process or user on a shared compute instance rather than being managed through a secrets manager or IAM role, remain surprisingly common in production environments at Indian companies, particularly those that grew quickly and carried early-stage infrastructure decisions into production without revisiting them.
Security as Infrastructure, Not Configuration
The distinction between security that requires configuration and security that is built into the infrastructure matters in practice. Teams move fast. Developers create new buckets, deploy new services, and onboard new team members, and security controls that depend on the correct configuration being applied every time will eventually be missed.
IBEE's approach is to make the secure default the only default: AES-256 encryption at rest on all storage, TLS in transit enforced, audit logging enabled with 180-day retention, all within Indian jurisdiction. The baseline is the starting point, not an option to be enabled after the fact.
