Why the Old Security Model Does Not Work for Cloud
Traditional enterprise security was built around a perimeter. Everything inside the office network, or later the VPN, was trusted. Everything outside was not. Firewalls defined the boundary. Location determined trust.
Cloud infrastructure dismantled this model in three ways. First, there is no meaningful perimeter: storage is on the internet by design, accessible via API from anywhere by any credential that can authenticate. Second, the threat increasingly originates inside the perimeter, through compromised credentials, malicious insiders, and third-party integrations with excessive access. Third, services authenticate each other constantly: microservices, CI/CD pipelines, and data processing jobs all generate service-to-service access events that need to be controlled and logged.
Zero Trust does not 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. When we review cloud security configurations for Indian engineering teams, the perimeter assumption is almost always still embedded somewhere: a shared service account, a wildcard IAM policy, logging that was configured once and never verified. Zero Trust is the discipline of eliminating those assumptions one by one.
Zero Trust Applied to Cloud Object Storage
Zero Trust is not a product to purchase. It is a set of principles applied systematically to how infrastructure handles access. For cloud object storage specifically, it translates into five concrete practices.
Every access request passes through the same evaluation chain regardless of where it originates.
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 circulated in a messaging tool.
When a credential is compromised, the blast radius is limited to what that credential can access. A single shared key used across all services means a compromise gives an attacker full access to everything. Per-service credentials with scoped permissions mean a compromise of one service key affects only what that service was permitted to do. The architectural principle is straightforward: isolate identities so that failures are contained.
In practice this means creating one IAM service account per application or service, generating credentials specifically for that account, and storing credentials in a secrets manager rather than in environment variables or configuration files where they are visible to any process on the host.
Principle 2: Grant Minimum Necessary Access
Every credential should have exactly the access its holder needs, nothing more. 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. The policy should reflect exactly what the service does, not what it might conceivably need in the future.
The most common violations we encounter are service accounts created with administrator access because it was faster to set up that way, wildcard resource permissions in IAM policies that apply to all buckets in an account, read-only services given write permissions as a precaution, and shared credentials used across multiple services with genuinely different access requirements. None of these are intentionally insecure decisions: they are convenience decisions made under time pressure that accumulate into significant risk.
Principle 3: Validate Every Request
In a Zero Trust model, a request originating from inside the organisation's own infrastructure is not sufficient authorisation by itself. The request must carry valid credentials, those credentials must be authorised for the specific action on the specific resource, and the request should ideally originate from an expected source IP or VPC endpoint.
Bucket policies that restrict access to specific VPC endpoints or IP ranges add a second verification layer. Even if a credential is compromised and used from an unexpected location, the request can be blocked because the source does not match the expected access pattern. This is the practical meaning of "always verify": the credential alone is not enough, the context of the request matters too.
Principle 4: Log Everything, Retain for 180 Days
Zero Trust assumes breaches will happen. The audit log is how they are detected, investigated, and reported to regulators.
Every API call against cloud storage should generate an audit record: timestamp, credential used, action requested, resource accessed, source IP, and result. Logs should be stored separately from the primary data, because an attacker who compromises storage should not be able to delete the record of their intrusion. Logs should be retained for 180 days to meet CERT-In requirements and stored within Indian jurisdiction for DPDP Act compliance. Logs should be monitored for anomalous patterns: unusual access volumes, access from unexpected locations, and credential usage outside normal operational hours.
IBEE includes audit logging as standard with 180-day retention, stored within Indian jurisdiction, at no additional cost and with no configuration required.
Principle 5: Rotate Credentials Regularly
Credentials that never expire remain useful to an attacker indefinitely. Rotating access keys on a regular schedule, typically every 90 days, limits the exposure window if a key is compromised and not immediately detected.
Automated rotation using secrets management tooling such as HashiCorp Vault removes the human process dependency and eliminates the common failure mode of rotation being skipped because it requires manual coordination across multiple teams. Manual rotation schedules are consistently the first practice to slip when engineering teams are under delivery pressure.
The Zero Trust Audit for Your Current Cloud Storage Setup
Running through five questions against an existing cloud storage configuration will surface the most common gaps.
On identity: does every service have its own credential, or are credentials shared? Can every entity with access to storage be listed, with its specific permissions documented?
On least privilege: when were the IAM policies on storage buckets last reviewed? Are there any wildcard permissions or over-broad access grants that have not been revisited since initial setup?
On source validation: are bucket policies restricted to specific VPC endpoints or IP ranges, or do valid credentials allow access from anywhere on the internet?
On logging: is access logging enabled on every bucket? Where are logs stored, for how long, and are they in a separate account or location from the primary data they cover?
On credential rotation: when were service account credentials last rotated? Is the rotation schedule automated or dependent on a manual process that can be deferred?
Zero Trust Is a Journey, Not a Configuration
Most engineering teams implementing Zero Trust for the first time discover that the largest gaps are in places they assumed were already handled: credentials created years ago and never rotated, IAM policies written by a developer who left the company and never reviewed, logging enabled but never monitored, bucket policies that made sense at the time and no longer reflect actual access requirements.
The value of Zero Trust is not that it prevents all breaches. It is that it limits the damage when one occurs and 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 that cannot be satisfied retroactively.
IBEE's security architecture is built around these principles: per-account IAM, granular bucket policies, default-on AES-256 encryption, and audit logging within Indian jurisdiction as the baseline configuration for every account.
