For security engineers, DevOps leads, and CTOs building or auditing cloud infrastructure access controls.
Why the Old Security Model Doesn't Work for Cloud
Traditional enterprise security was built around a perimeter. You trusted everything inside the office network — or later, the VPN — and you distrusted everything outside. Firewalls defined the boundary. If you were inside, you were trusted. If you were outside, you weren't.
Cloud infrastructure destroyed this model in three ways. First, there is no meaningful perimeter — your storage is on the internet by design, accessible via API from anywhere, by any credential that can authenticate. Second, the threat is increasingly inside the perimeter — compromised credentials, malicious insiders, third-party integrations with excessive access. Third, services authenticate each other constantly — microservices, CI/CD pipelines, data processing jobs — and each of those service-to-service interactions is an access event that needs to be controlled and logged.
Zero Trust doesn't replace perimeter security so much as it acknowledges that the perimeter no longer exists. The operating principle becomes: never trust, always verify. Every request for access — from a person, a service, or an application — is evaluated on its own merits, with the minimum access granted that is sufficient for the task, and every access event logged.
Zero Trust Applied to Cloud Object Storage
Zero Trust isn't a product you buy. It's a set of principles you apply systematically to how your infrastructure handles access. For cloud object storage specifically, it translates into a set of concrete practices.
Principle 1: Every Identity Has Its Own Credential
The starting point for Zero Trust is identity. Every application, service, and user that needs to access storage gets its own dedicated credential — not a shared key, not a root credential, not a team credential passed around in Slack.
Why this matters: when a credential is compromised, the blast radius is limited to what that credential can access. If you have one shared key that all your services use, a compromise means full access to everything. If you have per-service credentials with scoped permissions, a compromise of one service's key affects only what that service was permitted to do.
In practice: create one IAM service account per application or service. Generate credentials specifically for that account. Store credentials in a secrets manager, not in environment variables or configuration files.
Principle 2: Grant Minimum Necessary Access
Every credential should have exactly the access its holder needs — no more, no less. This is the Principle of Least Privilege, and it is the single most impactful practice for reducing the damage potential of a compromised credential.
A data processing job that reads from one bucket and writes to another needs read access on the source bucket and write access on the destination bucket. It does not need list access on all buckets, delete permissions, or access to any other bucket in the account.
Common violations: service accounts with administrator access "because it was easier to set up that way", wildcard resource permissions (*) in IAM policies that apply to all buckets, read-only services given write permissions "just in case", and shared credentials used across multiple services with different access requirements.
Principle 3: Validate Every Request
In a Zero Trust model, the fact that a request comes from inside your own infrastructure is not sufficient authorisation. The request must carry valid credentials, those credentials must be authorised for the specific action being requested on the specific resource being accessed, and the request should ideally come from an expected source IP or VPC.
Bucket policies that restrict access to specific VPC endpoints or IP ranges add an additional verification layer — even if a credential is compromised and used from an unexpected location, the request can be blocked because the source doesn't match the expected access pattern.
Principle 4: Log Everything, Retain for 180 Days
Zero Trust assumes breaches will happen. The audit log is how you detect them, investigate them, and prove to regulators what occurred.
Every API call against cloud storage should generate an audit record: timestamp, credential used, action requested, resource accessed, source IP, and result (success or denial). These logs should be:
- Stored separately from the primary data (an attacker who compromises your storage account shouldn't be able to delete the logs of their intrusion)
- Retained for 180 days to meet CERT-In requirements
- Stored within Indian jurisdiction for DPDP Act and CERT-In compliance
- Monitored for anomalous patterns — unusual access volumes, access from unexpected locations, credential usage outside normal hours
IBEE includes audit logging as standard with 180-day retention, stored within Indian jurisdiction. No additional configuration or cost.
Principle 5: Rotate Credentials Regularly
Credentials that never expire are credentials that stay useful for attackers indefinitely. Rotating access keys on a regular schedule — typically 90 days — limits the window of exposure if a key is compromised and not immediately detected.
Automated rotation using secrets managers (HashiCorp Vault, AWS Secrets Manager, or cloud-native equivalents) removes the human process dependency and eliminates the common failure mode of rotation being skipped because it requires manual intervention.
The Zero Trust Audit for Your Current Cloud Storage Setup
Run through these questions against your current cloud storage configuration:
Identity — Does every service have its own credential, or are credentials shared? Can you list every entity that has access to your storage, with what permissions?
Least privilege — When did you last review IAM policies on your storage buckets? Are there any wildcard permissions or over-broad access grants that haven't been revisited since the initial setup?
Source validation — Are your bucket policies restricted to specific VPC endpoints or IP ranges, or do valid credentials allow access from anywhere on the internet?
Logging — Is access logging enabled on every bucket? Where are logs stored, and for how long? Are logs in a separate account or location from the primary data?
Credential rotation — When were your service account credentials last rotated? Do you have a rotation schedule, and is it automated or manual?
Anomaly detection — Do you have alerting configured for unusual access patterns — bulk downloads, access from unexpected IPs, credential usage outside business hours?
Zero Trust Is a Journey, Not a Configuration
Most engineering teams implementing Zero Trust for the first time discover that the biggest gaps are in places they thought were already handled: credentials that were created years ago and never rotated, IAM policies written by a developer who has since left the company and never reviewed, logging that was enabled but never monitored, bucket policies that made sense at the time and no longer reflect actual access requirements.
The value of Zero Trust isn't that it prevents all breaches. It's that it limits the damage when one occurs, and it creates the audit record that makes investigation and response possible. For Indian businesses operating under CERT-In mandatory directions and the DPDP Act, that audit record is also a compliance obligation.
IBEE's security architecture is built around these principles — per-account IAM, granular bucket policies, default-on encryption, and audit logging within Indian jurisdiction as the baseline.
