For security engineers, CTOs, and compliance leads at Indian companies storing sensitive data in cloud infrastructure.
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 your 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 your audit trail.
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 (Advanced Encryption Standard with 256-bit keys). This protects against physical media theft or unauthorised physical access to storage hardware.
What to check: Is encryption at rest enabled by default, or does it require explicit configuration? 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 weren't explicitly encrypted.
On IBEE, AES-256 encryption at rest is enabled by default on all storage. There is no configuration step that could accidentally be missed.
2. Encryption in Transit — TLS 1.3
Data moving between your application and cloud storage — upload requests, download responses, API calls — should be encrypted using TLS 1.3. Older versions of TLS have known vulnerabilities. Connections that allow TLS 1.0 or 1.1 are a real attack surface, particularly for applications running in environments where network traffic can be intercepted.
What to check: Does the storage provider enforce TLS 1.3 minimum, or does it still accept connections on deprecated protocol versions?
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 — read, write, delete, list — that its function requires.
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 by how much the IAM policy permitted.
A complete IAM configuration for cloud storage 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
- Bucket policies that restrict access by IP range or VPC where applicable
4. Bucket Versioning
Versioning keeps 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 your data creates an irrecoverable situation. With versioning, even a delete operation can be reversed — the object is marked as deleted but previous versions are retained for a configurable period.
For regulated data — medical records, financial documents, legal archives — versioning is often a compliance requirement, not just a best practice.
5. Audit Logging — The Record That Proves What Happened
Audit logs record every API call against your storage — who accessed what object, from which IP, 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 maintained for 180 days
- Logs stored within Indian jurisdiction
- Logs 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're 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.
IBEE includes audit logging as standard, with 180-day retention within Indian jurisdiction by default. No additional configuration, 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 files is a credential that will eventually be discovered and exploited.
A complete key management practice covers:
- No long-lived root credentials used by applications
- Scoped service account keys with minimal permissions
- Regular rotation schedule — typically 90 days maximum
- Automated detection of credentials committed to version control
- Immediate revocation protocol for suspected compromised keys
The CERT-In Audit Checklist for Cloud Storage
For organisations subject to CERT-In's mandatory directions, the practical audit questions for cloud storage are:
Log retention — Are audit logs retained for 180 days? Where are they stored? Are they in Indian jurisdiction?
Incident reporting capability — Can you pull a complete access log for any storage bucket within six hours of a request? If the logs are in an external SIEM or log management system, is that system also within Indian jurisdiction?
Access control documentation — Can you produce documentation of who has access to what storage resources, with what permissions, and when those permissions were last reviewed?
Encryption documentation — Can you confirm encryption at rest and in transit, with the specific algorithms and protocol versions used?
Data localisation — For sensitive personal data covered by the DPDP Act, can you confirm the data is stored within India and governed under Indian law?
Common Security Misconfigurations in Cloud Storage
Public buckets — The single most common and damaging cloud storage misconfiguration. Bucket permissions set to public-read expose every object in the bucket to the internet without authentication. Several major Indian data breaches have been caused by accidentally public S3 buckets.
Overly permissive bucket policies — Policies that allow any authenticated user within the account to read or write, rather than scoping access to specific roles or services.
Logging disabled — The default configuration on many cloud platforms disables access logging. Teams that rely on default configurations may be running buckets with no audit trail.
No versioning on critical data — Regulatory data, financial records, and customer data stored without versioning has no recovery path if accidentally deleted or corrupted.
Credentials in environment variables on shared systems — Credentials visible to any process or user on a shared compute instance rather than being managed through a secrets manager or IAM role.
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 right configuration being applied correctly every time will eventually be missed.
IBEE's approach is to make the secure default the only default: encryption at rest on all storage, TLS in transit enforced, audit logging enabled by default with 180-day retention, all within Indian jurisdiction. The baseline is the starting point, not an option to be enabled.
