Cyber Hygiene for Indian SMEs: 10 Basic Practices That Prevent Most Attacks

Introduction: India’s Cloud Boom and Its Hidden Danger

India is one of the fastest-growing cloud markets in the world. By 2025, Indian enterprises were spending over $17 billion annually on public cloud services, with adoption accelerating across BFSI, healthcare, e-commerce, IT services, and government. AWS, Microsoft Azure, and Google Cloud have all made India a strategic priority, opening local regions and data centers to capture this explosive demand.

But beneath this growth story lies a troubling reality that rarely makes headlines until it is too late: the vast majority of Indian cloud deployments are misconfigured in ways that leave sensitive data — customer records, financial transactions, Aadhaar-linked information, health data, intellectual property — exposed to theft, ransomware, or regulatory penalty.

The numbers are sobering. IBM’s Cost of a Data Breach Report 2024 placed the average cost of a data breach in India at approximately ₹19.5 crore, up significantly from previous years. Gartner has estimated that through 2025, 99% of cloud security failures would be the customer’s fault — not the cloud provider’s. And the most common root cause? Misconfiguration.

Unlike sophisticated zero-day exploits, misconfigurations do not require advanced hacking skills to discover or exploit. Automated scanners run continuously across the internet, probing for open ports, public storage buckets, and exposed admin panels. A new misconfigured resource can be found and attacked within minutes of being deployed. The window of safety is essentially zero.

India’s cloud security challenge is compounded by several structural factors: a shortage of experienced cloud security professionals, enormous pressure to ship products quickly, fragmented DevOps practices, limited adoption of Infrastructure as Code (IaC), and — until recently — weak regulatory enforcement. The Digital Personal Data Protection (DPDP) Act 2023 and CERT-In’s incident reporting mandates are beginning to change the regulatory landscape, but the security debt accumulated over years of fast-growth cloud adoption will take time and discipline to address.

This guide examines the ten most dangerous and prevalent cloud misconfigurations affecting Indian enterprises today. For each, we cover what it is, why it happens, what the real-world consequences look like, and — most importantly — what to do about it.

Misconfiguration 1: Publicly Exposed Cloud Storage Buckets

What It Is

Cloud object storage — Amazon S3, Azure Blob Storage, Google Cloud Storage — is designed to be private by default. However, a single wrong configuration setting can make an entire bucket, or individual objects within it, accessible to anyone on the internet without authentication. This is not a theoretical risk. It is one of the most commonly exploited vulnerabilities in cloud environments globally, and Indian firms have been hit repeatedly.

Why It Happens in India

The root causes are consistent across organisations. Developers working under deadline pressure create storage buckets for testing or staging environments and set them to public for convenience, intending to restrict access later. “Later” never comes. In other cases, teams copy bucket configurations from tutorials or StackOverflow answers without understanding the access model. Some organisations use public buckets intentionally to host static websites or assets, then accidentally store sensitive files in the same bucket. In larger enterprises, shadow IT creates buckets outside of central IT governance entirely.

AWS in particular changed its default settings over the years, meaning that older buckets created before 2018 may have permissive ACLs that predate the Block Public Access controls introduced later. Many Indian firms that began their cloud journey early carry this legacy.

Real-World Consequences

The pattern is heartbreakingly predictable. Security researchers or malicious actors run bucket enumeration tools — many are freely available — that probe for predictable bucket names tied to company names, product names, or common patterns. They find a match, discover it is publicly accessible, and download everything.

In India, this has resulted in: insurance companies exposing policyholder names, mobile numbers, and policy details for millions of customers; healthcare providers leaking patient records including Aadhaar numbers used for KYC; HR service providers accidentally publishing employee salary data and PAN card scans; and logistics companies exposing customer shipment histories and addresses. In several documented cases, the data was sitting publicly accessible for six months or more before anyone noticed.

The consequences extend beyond the immediate breach. Under the DPDP Act 2023, organisations processing personal data of Indian residents are required to implement reasonable security safeguards. A publicly accessible bucket containing personal data is arguably a per se violation, and the Data Protection Board has the authority to impose penalties up to ₹250 crore for significant breaches.

What to Do

The most important control is enabling Block Public Access at the AWS account level — not just at the bucket level. This overrides any bucket-level or object-level ACL that might accidentally grant public access. In Azure, the equivalent is setting the storage account’s “Allow Blob Public Access” to disabled. In GCP, the uniform bucket-level access feature and the public access prevention policy serve the same purpose.

Beyond that, every organisation should implement continuous scanning of their cloud storage posture. AWS Macie uses machine learning to discover sensitive data — PII, financial records, credentials — stored in S3 and alerts when that data is in buckets that are publicly accessible or insufficiently protected. GCP’s Cloud DLP and Azure Purview offer similar capabilities.

Bucket policies should be reviewed as part of every deployment pipeline. Any Infrastructure as Code template that creates a storage bucket should fail automated checks if it includes any public access grants. Tools like Checkov, tfsec, and AWS CloudFormation Guard can enforce this at the CI/CD level before anything reaches production.

Finally, conduct a full audit of every existing storage bucket in your organisation. List all buckets, check their access configuration, and enumerate what data they contain. This exercise almost always surfaces surprises.

Misconfiguration 2: Over-Privileged IAM Roles and Service Accounts

What It Is

Identity and Access Management (IAM) is the backbone of cloud security. Every resource, user, application, and service that interacts with a cloud environment does so through an identity, and that identity carries permissions that define what it can and cannot do. The principle of least privilege — granting only the permissions necessary for a specific task — is a foundational security concept. In practice, it is honoured far more in theory than in reality.

Over-privileged IAM means granting an identity — a developer, an application, a Lambda function, a Kubernetes service account, a CI/CD pipeline — more permissions than it needs to do its job. The extreme end is attaching the AWS AdministratorAccess managed policy, or the Azure Owner role, or the GCP Project Owner role, to something that only needs to read from a single database table.

Why It Happens in India

The reasons are systemic and cultural. Developers working on new features need to access cloud resources during development and testing. Configuring precise least-privilege IAM policies is time-consuming and requires detailed knowledge of exactly which API calls a given workload will make. It is much faster to grant AdministratorAccess and move on. The intent is always to tighten this later, but in the pressure of product development cycles, it rarely happens.

In Indian IT services organisations, there is often a disconnect between the team that provisions cloud infrastructure and the team that writes application code. Infrastructure teams may not know what specific permissions an application actually needs, so they grant broad access to avoid blocking the development team. Startups, where one or two developers are doing everything, often have everyone operating with near-root access across all environments.

Compounding this is the misuse of long-lived access keys. IAM users with programmatic access keys — as opposed to role-based temporary credentials — are created, distributed across multiple developers and applications, and then never rotated or deleted when team members leave or project contexts change. These keys often end up hardcoded in applications (see Misconfiguration 7), stored in shared Slack channels, or accidentally committed to version control.

Real-World Consequences

Over-privilege is devastating in a breach scenario because it enables lateral movement. An attacker who compromises a single over-privileged identity — by phishing a developer, finding a hardcoded key, or exploiting an application vulnerability — can immediately pivot to the entire cloud environment. They can read from any database, download any S3 bucket, access secrets, spin up compute instances to mine cryptocurrency, exfiltrate data to external storage, and cover their tracks by deleting logs — all using legitimate cloud APIs that generate no obvious alerts.

In Indian fintech and e-commerce environments, this has led to breaches where attackers extracted months of transaction data, customer PII, and payment card information by leveraging a single compromised service account that had been granted broad read permissions across multiple databases.

The problem extends to third-party vendors. Indian enterprises routinely grant cloud access to software vendors, audit firms, and managed service providers. When these grants are made without appropriate scope restrictions, and without using cross-account roles with external IDs and permission boundaries, a compromise at the vendor’s end becomes a compromise of the customer’s cloud environment.

What to Do

Start with an IAM access review. AWS IAM Access Analyzer generates detailed findings for any principal whose permissions allow access to resources outside the account, or that are unused. AWS also provides IAM Access Advisor, which shows the last time any permission was used for any IAM user or role — this is invaluable for identifying and removing permissions that are granted but never exercised.

Migrate from IAM users with long-lived access keys to role-based authentication wherever possible. Applications running on EC2, Lambda, ECS, or EKS should authenticate via instance profiles and IAM roles that vend short-lived credentials automatically. This eliminates the entire class of risk associated with static credentials.

For developers, use AWS IAM Identity Center (formerly SSO) with time-limited console access and programmatic credentials that expire after a session, rather than permanent access keys. Enforce key rotation every 90 days as a minimum, and treat any access key older than 90 days as potentially compromised.

Implement Service Control Policies (SCPs) in AWS Organizations to set hard limits on what any identity in any account can do — for example, preventing anyone from disabling CloudTrail, or from creating access keys for the root account. These are guardrails that cannot be overridden even by account administrators, making them a powerful last line of defence.

Misconfiguration 3: Unrestricted Inbound Security Group Rules

What It Is

In cloud environments, security groups (AWS), network security groups (Azure), and VPC firewall rules (GCP) act as virtual firewalls controlling which network traffic is allowed to reach a resource. A rule that allows inbound traffic from 0.0.0.0/0 — the entire internet — on sensitive ports is one of the most dangerous and prevalent misconfigurations found in cloud environments.

The ports most commonly left exposed include port 22 (SSH), port 3389 (RDP for Windows remote access), port 5432 (PostgreSQL), port 3306 (MySQL), port 27017 (MongoDB), port 6379 (Redis), port 9200 (Elasticsearch), and port 8080/8443 (admin panels and development servers). Any of these open to the world is a standing invitation to attack.

Why It Happens in India

The genesis is almost always in development convenience. A developer needs to SSH into a cloud instance from home, or connect directly to a database for debugging, and the easiest solution is to open the port to 0.0.0.0/0 rather than figure out their current home IP address or set up a VPN. This takes two minutes. Configuring proper access controls takes much longer. The “temporary” open rule gets forgotten and lives in production for months or years.

Indian cloud environments also suffer from a common pattern around MongoDB and Elasticsearch specifically. Both databases, when first installed, have no authentication enabled by default and bind to all network interfaces. When an EC2 instance running one of these databases has a security group rule allowing 0.0.0.0/0 on the relevant port, the database is effectively open to the entire internet with no authentication required at all. This combination has led to multiple large-scale Indian database exposures documented by security researchers.

Real-World Consequences

Automated scanning infrastructure run by researchers and attackers alike continuously sweeps the internet for open ports. Tools like Shodan, Censys, and masscan can scan the entire IPv4 address space in under an hour. A new EC2 instance with an open port 22 will typically appear in Shodan’s index within 24-48 hours. Attackers run automated scripts against open SSH ports attempting known username/password combinations and leaked credentials. Against databases with no authentication, they simply connect and download everything.

The consequences range from complete database theft to ransomware. MongoDB databases exposed to the internet have been targeted by automated scripts that delete all data and leave a ransom note demanding Bitcoin for restoration — a type of attack that hit thousands of databases globally including many in India. Redis instances exposed without authentication have been used as pivot points for remote code execution on the underlying host by injecting cron jobs or SSH keys into Redis’s persistence mechanism.

For Indian BFSI firms, open RDP ports are a favourite target for ransomware gangs. Brute-forcing RDP credentials is an automated commodity attack, and successful compromise of a Windows server in a financial institution’s cloud environment can lead to complete ransomware deployment across the organisation.

What to Do

The fundamental principle is that no management port — SSH, RDP, or any database port — should ever be accessible from the internet. The legitimate ways to access cloud instances for management purposes are: AWS Systems Manager Session Manager (which provides shell access to EC2 instances without opening any inbound ports at all), a dedicated bastion host in a separate subnet with access tightly controlled to known IP ranges, or a corporate VPN that routes all management traffic through controlled infrastructure.

Audit all security groups for rules containing 0.0.0.0/0 or ::/0 (IPv6) on any port other than 80 (HTTP) and 443 (HTTPS). AWS Config provides a managed rule called “restricted-ssh” and “restricted-common-ports” that flags these automatically. Azure Security Center and GCP Security Command Center have equivalent checks.

For databases specifically, they should never be in a public subnet. Database instances should be in private subnets with no route to the internet gateway, and security group rules should allow inbound traffic only from the specific application servers that need to connect, not from broad IP ranges.

Misconfiguration 4: MFA Not Enforced on Root and Admin Accounts

What It Is

Multi-Factor Authentication (MFA) requires a user to prove their identity using something they know (a password) and something they have (a time-based one-time code from an authenticator app, a hardware token, or a push notification). Without MFA, anyone who obtains a username and password — through phishing, credential stuffing, dark web purchase, or social engineering — can log in with no further barrier.

The cloud root account is the most powerful identity in any cloud environment. In AWS, the root account bypasses all IAM policies and can do anything, including deleting all data, disabling all security controls, and transferring the account to a different owner. Leaving the root account without MFA, or using weak credentials on it, is one of the most dangerous possible misconfigurations.

Why It Happens in India

MFA adoption in Indian enterprises lags significantly behind Western counterparts, partly due to a historical deficit in security culture and partly due to the friction that MFA introduces into developer workflows. Many Indian organisations view MFA as a burden that slows down teams rather than as a fundamental security control. There is also a common and mistaken belief that network perimeter controls — VPNs, IP whitelisting — are a substitute for MFA, when in reality they are complementary.

For cloud root accounts specifically, the problem is compounded by a lack of understanding of cloud account structure. Many Indian teams, particularly in smaller organisations and startups, are not fully aware that the root account is special and categorically more dangerous than an administrative IAM user. They treat it as just another login and may even use it for day-to-day operations, which is strongly against best practices.

Shared credentials are another Indian-specific pattern. In teams with high turnover or flat hierarchies, the root account credentials (and sometimes MFA device) are shared among multiple team members. This defeats the purpose of MFA entirely and makes it impossible to attribute actions to specific individuals.

Real-World Consequences

Root account compromise is catastrophic and near-instantaneous in its consequences. An attacker with root access can disable CloudTrail to cover their tracks, delete all IAM users and roles to lock out legitimate users, exfiltrate all data from all regions, run up enormous compute bills by launching GPU instances for cryptomining, and permanently destroy the organisation’s cloud environment. AWS has documented cases where compromised root accounts led to bills of hundreds of thousands of dollars within hours, as attackers launched expensive instances before the breach was detected.

Phishing attacks targeting cloud credentials are well-documented and increasingly sophisticated. Attackers create fake AWS login pages, send phishing emails to developers with links to these pages, and harvest credentials. Without MFA, a harvested username and password is all they need. With MFA, the harvested credentials are worthless unless the attacker can also intercept the OTP — significantly harder and requiring real-time interaction with the victim.

What to Do

Enable MFA on the root account immediately and without exception. AWS recommends using a hardware MFA device (such as a YubiKey) for the root account rather than a virtual authenticator app, because hardware tokens are resistant to phishing and cannot be extracted from a compromised mobile device. Store the hardware token in a physically secure location with documented access procedures.

After enabling root account MFA, the root account should essentially never be used. Create a strong administrative IAM user or use IAM Identity Center for all routine administrative tasks. Use Service Control Policies to prevent the root account from taking certain destructive actions even if it is compromised.

For all human users accessing the AWS console or other cloud management consoles, enforce MFA through IAM policies that include a condition requiring MFA authentication before any sensitive action can be taken. In AWS Organizations, SCPs can enforce this organisation-wide. For IAM Identity Center, MFA can be mandated as part of the authentication policy configuration.

For developers accessing cloud resources programmatically, require MFA before generating temporary credentials via AWS STS assume-role calls for sensitive operations. This ensures that even programmatic access to production environments requires an MFA factor.

Misconfiguration 5: Unencrypted Data at Rest and in Transit

What It Is

Encryption at rest means that data stored in databases, file systems, object storage, backup systems, and log archives is encrypted on disk such that physical access to the storage medium does not yield readable data. Encryption in transit means that data moving between services — application servers to databases, APIs to clients, microservices to each other — is encrypted in the network so that interception of network traffic does not yield readable data.

Both are foundational security controls, and both are frequently absent or incompletely implemented in Indian cloud environments.

Why It Happens in India

Cloud providers have made encryption progressively easier and cheaper over the years, but enabling it still requires deliberate configuration. Many teams, particularly those migrating on-premises workloads to the cloud under time pressure, replicate their existing setup without adding cloud-native encryption controls. On-premises data centers often lacked encryption at rest because physical security was assumed to be sufficient; this assumption is entirely invalid in cloud environments where the physical infrastructure is shared and managed by the cloud provider.

The performance concern — that encryption adds latency or CPU overhead — is a persistent myth that has been decisively disproven for modern cloud workloads. AES-256 hardware acceleration is standard in all modern cloud instance types, and the performance overhead of encryption at rest is negligible for virtually all workloads. Nevertheless, teams sometimes disable encryption on latency-sensitive databases based on this misapprehension.

For encryption in transit, the failure mode is typically internal services communicating over HTTP rather than HTTPS, justified on the grounds that the traffic is “inside the VPC” and therefore safe. This ignores the reality of lateral movement: if an attacker compromises any service inside the VPC, they can sniff unencrypted internal traffic and harvest credentials, tokens, and data in transit.

Real-World Consequences

Unencrypted data is a multiplier for every other security failure. When a storage bucket is publicly exposed, unencrypted data can be read immediately. When a database server is compromised, unencrypted data requires no decryption before exfiltration. When a cloud provider employee or contractor has unauthorised access to underlying storage, unencrypted data is immediately readable.

For Indian firms specifically, the regulatory consequences of unencrypted personal data are becoming concrete. SEBI’s cloud adoption framework for regulated entities in the financial sector explicitly requires encryption of sensitive data at rest and in transit. RBI’s guidelines for payment system operators set similar requirements. IRDA has issued guidance for insurance companies. Under the DPDP Act, failure to implement reasonable security safeguards — a category that clearly includes encryption for sensitive personal data — can result in penalties up to ₹250 crore.

Beyond regulation, ransomware operators targeting Indian enterprises have exploited unencrypted databases specifically to enable double extortion: they encrypt the victim’s data and also exfiltrate it, threatening to publish it unless an additional ransom is paid. Unencrypted data at rest makes this exfiltration trivially easy.

What to Do

Enable encryption at rest by default across all storage services using cloud provider-managed KMS keys as a minimum, with Customer Managed Keys (CMKs) for the most sensitive data. In AWS, this means enabling default encryption on EBS volumes, RDS instances, S3 buckets, DynamoDB tables, and Redshift clusters. In Azure, this means Azure Disk Encryption and Transparent Data Encryption for databases. In GCP, Customer Managed Encryption Keys for Cloud Storage and Cloud SQL.

For CMKs, implement key rotation (AWS KMS supports automatic annual rotation), access controls restricting key usage to specific IAM roles, and CloudTrail logging of all key usage events. Key deletion should require a waiting period to prevent accidental or malicious loss of data.

For encryption in transit, enforce TLS 1.2 as a minimum (TLS 1.3 where supported) for all service-to-service communication, including internal VPC traffic. Use AWS Certificate Manager or equivalent to manage TLS certificates automatically with automatic renewal. Reject or redirect all plaintext HTTP connections. For database connections, enforce SSL/TLS at the database level — both RDS PostgreSQL and MySQL support this — so that connections without TLS are refused.

Conduct a full inventory of all data stores and verify encryption status for each. AWS Config managed rules such as “rds-storage-encrypted”, “s3-bucket-server-side-encryption-enabled”, and “encrypted-volumes” provide continuous compliance monitoring.

Misconfiguration 6: Disabled or Insufficient Cloud Audit Logging

What It Is

Cloud providers offer comprehensive audit logging — AWS CloudTrail, Azure Monitor Activity Log, and GCP Cloud Audit Logs — that record every API call made against the cloud environment, including who made it, from where, at what time, and what it did. These logs are the foundation of security monitoring, incident response, forensic investigation, and regulatory compliance. Without them, organisations are flying blind: breaches can go undetected for months, and post-breach investigation is nearly impossible.

Insufficient logging goes beyond simply having logging disabled. It includes logging that covers only some regions, log retention periods that are too short for meaningful investigation, logs that are stored in the same account that could be compromised in a breach, and logs that are not actually monitored or alerted on in real time.

Why It Happens in India

Logging is often treated as an afterthought. Teams focus on building and shipping features; the operational and security infrastructure that logging represents is deprioritised until something goes wrong. There is also a widespread misunderstanding of what cloud audit logging covers: many teams believe that their application logs are sufficient, without realising that cloud audit logs capture infrastructure-level activity — IAM changes, security group modifications, data access to storage — that application logs do not.

Cost is cited as a reason to minimise logging, particularly for organisations storing logs in managed logging services. However, the cost of CloudTrail management events logging for a typical AWS account is trivially small compared to the cost of a breach investigation conducted without log data.

The CERT-In directive of 2022 requires all organisations to retain logs for 180 days with the most recent 90 days being immediately accessible, and to report incidents within 6 hours. Many Indian organisations discovered only after this directive that they did not have the logging infrastructure to demonstrate compliance or to investigate incidents within the required timeframe.

Real-World Consequences

The absence of logs transforms a manageable security incident into an existential threat. Without CloudTrail data, an organisation that discovers a breach cannot determine: when the breach occurred, what entry point the attacker used, which resources were accessed, what data was exfiltrated, what changes the attacker made to the environment, or whether the attacker left behind persistent access mechanisms (backdoors, additional IAM users, Lambda functions).

This lack of forensic evidence has multiple severe consequences. It makes it impossible to scope the breach accurately, leading organisations to assume the worst-case and notify far more customers than necessary — or, alternatively, to underscope the breach and fail to notify affected individuals as required. It makes regulatory responses almost impossible, since regulators will ask for evidence of what happened and what was affected. It makes it impossible to confirm that the attacker has been fully evicted, leaving organisations uncertain about their own environment.

Indian cybersecurity incident response professionals working breach investigations in environments without CloudTrail frequently report that they cannot determine the root cause of breaches, cannot establish a timeline, and cannot confirm cleanup — leaving their clients in a state of perpetual uncertainty.

What to Do

Enable CloudTrail for all regions and all accounts in your AWS organization, including management events (which capture IAM changes, security group modifications, and other control plane activity) and data events for S3 and Lambda where sensitive data is involved. Configure CloudTrail to deliver logs to an S3 bucket in a dedicated, separate logging account that is not accessible from workload accounts — this ensures logs survive even if a workload account is compromised by an attacker attempting to cover their tracks.

Enable CloudTrail log file integrity validation, which creates SHA-256 hashes of each log file and chains them, making it detectable if any log file is modified or deleted after creation.

Set log retention to a minimum of 12 months, with the most recent 90 days queryable via CloudWatch Logs or AWS Athena for rapid investigation. For regulated industries — BFSI, healthcare — retain logs for 3-7 years as required by sector-specific regulations.

Most importantly, logs must be monitored. Raw log data sitting in an S3 bucket does nothing until someone looks at it. Configure CloudWatch Alarms or Amazon EventBridge rules to alert in real time on high-risk events: root account login, IAM policy changes, CloudTrail being disabled, console login without MFA, large-volume S3 data access, and security group rule changes. Feed logs into a SIEM — whether AWS Security Lake, Splunk, Microsoft Sentinel, or an open-source alternative — for correlation and automated threat detection.

Misconfiguration 7: Hardcoded Secrets and API Keys in Source Code

What It Is

Hardcoded secrets refers to the practice of embedding sensitive credentials — database passwords, API keys, cloud access keys, OAuth tokens, private certificates — directly in application source code rather than retrieving them at runtime from a secrets management system. This is one of the most dangerous and widespread security anti-patterns in software development globally, and it is acutely prevalent in the Indian technology sector.

Why It Happens in India

The immediate cause is always developer convenience. Retrieving a secret from AWS Secrets Manager or HashiCorp Vault at application startup requires writing additional code and managing IAM permissions. Hardcoding a database password takes thirty seconds. In the high-pressure, fast-moving environment of Indian product development — where shipping the MVP is paramount and security is seen as something to address after product-market fit — the shortcut wins every time.

The problem is amplified by the culture around version control. India has an enormous developer community, many of whom learned to code through open-source projects and public repositories. The boundary between personal projects (where publishing everything to GitHub is normal) and professional work (where proprietary code and credentials must be private) is not always clear. Developers may accidentally push to public repositories, or create public repositories for what they intend as private projects.

Code review practices in many Indian organisations also fail to catch credentials. If security is not part of the review checklist — and in many organisations it is not — a hardcoded AWS access key will sail through review and be merged, deployed, and eventually become part of a breach statistic.

Real-World Consequences

The moment a credential is committed to a public Git repository, it must be considered compromised. Automated bots — run by both security researchers and malicious actors — continuously monitor GitHub, GitLab, Bitbucket, and other public repositories for patterns that look like API keys, access tokens, and database passwords. Tools like truffleHog, GitLeaks, and proprietary commercial scanners can find secrets in repository commit history even after they have been deleted from the current codebase, because git history is immutable by default.

Findings from GitGuardian and similar services have repeatedly identified Indian IT companies and startups as among the leading sources of leaked secrets on public platforms. AWS access keys found in public repositories are exploited within minutes of exposure by automated scripts that immediately assume the identity and begin enumerating permissions, accessing S3 buckets, querying databases, and launching compute instances.

Even in private repositories, hardcoded secrets pose risks. Former employees who retain access to repositories after departure, contractors with broader access than necessary, or a repository that is accidentally made public for a moment — any of these scenarios turns hardcoded credentials into a breach.

What to Do

The solution has two components: prevention and detection. For prevention, the architecture of applications must be changed to retrieve secrets at runtime from a managed secrets store. AWS Secrets Manager and AWS Parameter Store (for less sensitive configuration), Azure Key Vault, and GCP Secret Manager all provide secure, audited secret storage with IAM-controlled access. Applications authenticate to these services via their IAM role — no static credentials needed — and retrieve secrets at startup or on demand.

At the development tooling level, pre-commit hooks using tools like git-secrets, detect-secrets, or GitLeaks should prevent commits containing credential patterns from being accepted by the local git client. This provides a first line of defence at the moment a developer tries to commit a secret.

At the CI/CD pipeline level, automated secret scanning should be a mandatory gate before any code can be deployed to production. GitGuardian, Snyk, GitHub Advanced Security, and Semgrep all offer this capability. Any commit or pull request containing a detected secret should fail the pipeline and require remediation before proceeding.

For detection and remediation of existing secrets: conduct a full historical scan of all repositories, both public and private, using gitleaks or truffleHog. For every secret found, rotate it immediately — assume it is already compromised — and migrate the application to retrieve it from a secrets manager. Document the remediation for the incident record.

Misconfiguration 8: Publicly Exposed Kubernetes Dashboards and Misconfigured Clusters

What It Is

Kubernetes has become the dominant platform for container orchestration in Indian cloud environments, deployed on managed services like Amazon EKS, Azure AKS, and Google GKE. It is a powerful and complex system, and its security model requires careful configuration across multiple layers: API server access, RBAC policies, network policies, pod security standards, image provenance, and secrets management. Misconfigurations at any of these layers can expose the entire cluster and all workloads running on it.

The most visible and dangerous variant is the Kubernetes dashboard — a web-based UI for managing clusters — exposed to the public internet without authentication. But the attack surface extends well beyond the dashboard to include: the Kubernetes API server itself accessible from the internet, overly permissive RBAC policies granting too much access to service accounts, workloads running as root, pods with host network or host path access, and container images with known vulnerabilities.

Why It Happens in India

Kubernetes complexity is the primary driver. The Kubernetes security model is genuinely difficult to configure correctly, requiring deep understanding of concepts that are absent from traditional infrastructure management. Many Indian teams adopt Kubernetes because it is the industry standard, but without adequate training in its security model. The official Kubernetes dashboard documentation historically showed setup commands that resulted in deployments accessible without authentication, and many teams followed these literally.

The managed Kubernetes services from AWS, Azure, and GCP provide secure defaults in some areas but require explicit configuration in others. EKS clusters, for example, have an API server endpoint that is public by default — while authentication via OIDC and IAM is required, the endpoint being internet-accessible means it is exposed to vulnerability exploitation if a critical flaw is discovered in the Kubernetes API server itself. Restricting the API server to private VPC access requires deliberate configuration that many teams skip.

Real-World Consequences

Exposed Kubernetes dashboards have been one of the leading causes of large-scale cryptomining campaigns targeting Indian cloud environments. Attackers who gain access to a Kubernetes cluster can deploy pods on any or all worker nodes — pods running cryptocurrency mining software that consumes all available compute resources. The victim discovers the breach through a dramatically elevated cloud bill. By then, the attacker’s workloads have been running for days or weeks.

More sophisticated attackers use Kubernetes cluster access for data theft. Container workloads frequently have access to secrets, databases, and other sensitive resources. An attacker who can deploy arbitrary pods to a cluster can run pods with the same service account permissions as legitimate workloads, access all secrets mounted in the cluster, and exfiltrate data through egress traffic that looks like normal application traffic.

In Indian e-commerce environments, compromised Kubernetes clusters have led to the injection of malicious code into container images, leading to supply-chain attacks where the compromise propagates to every service running the tainted image.

What to Do

Never expose the Kubernetes API server or the Kubernetes dashboard to the public internet. Configure EKS cluster API server endpoints to be private (accessible only within the VPC). If public access is required for specific use cases, restrict it to known CIDR ranges. For the Kubernetes dashboard, either do not deploy it at all in production environments (use kubectl proxy or port-forwarding for local access instead) or deploy it with proper OIDC-based authentication and behind an authenticated reverse proxy.

Implement RBAC with least privilege for all service accounts. Review every ClusterRoleBinding and RoleBinding to ensure that broad permissions like cluster-admin are not granted to workload service accounts. Use specific, narrowly scoped roles for each application.

Implement Kubernetes Network Policies to restrict pod-to-pod communication. By default, Kubernetes allows all pods to communicate with all other pods in the cluster. Network policies define which pods can talk to which other pods, on which ports, dramatically reducing the blast radius of a compromised workload.

Enable pod security standards to prevent pods from running as root, from accessing the host network or filesystem, and from using privileged containers. Use image scanning in the CI/CD pipeline (AWS ECR image scanning, Trivy, Snyk) to prevent deployment of container images with known critical vulnerabilities.

Misconfiguration 9: Misconfigured Cross-Account and Third-Party Trust Relationships

What It Is

Modern cloud architectures routinely involve multiple AWS accounts (or Azure subscriptions, or GCP projects) that need to interact with each other, plus third-party SaaS vendors, managed service providers, and software tools that require access to cloud resources to function. All of these relationships are mediated by trust policies and cross-account IAM roles. Misconfiguring these trust relationships — making them too permissive, failing to verify the identity of the trusted party, or granting access that is not time-limited — creates supply-chain risk that is difficult to detect and devastating when exploited.

Why It Happens in India

Indian enterprises heavily outsource cloud management and application development to third-party IT service providers. A large enterprise may have its core IT managed by one vendor, its security monitoring by another, and its application development by several others, all of whom need some level of access to the enterprise’s cloud environment. Managing these access relationships carefully — with appropriate scope, auditing, and time limits — requires a level of cloud governance maturity that many organisations have not yet achieved.

The specific misconfiguration pattern that leads to the highest risk is cross-account IAM roles without the external ID condition. When an AWS account grants a third party the ability to assume a role, the role’s trust policy should include an external ID — a shared secret known only to the account owner and the specific third-party — as a condition. Without the external ID, any AWS account trusted in the policy can assume the role, and a confused deputy attack is possible where an attacker tricks the third party into making API calls on their behalf.

Real-World Consequences

The supply-chain dimension of this misconfiguration is what makes it particularly dangerous. A breach at a managed service provider, IT outsourcing vendor, or SaaS tool that has cross-account access to a customer’s cloud environment is automatically a breach of the customer’s environment. The attacker does not need to compromise the customer directly — they compromise the vendor, enumerate the vendor’s cross-account roles, and then pivot into every customer environment that has granted that vendor access.

This attack vector was central to several high-profile global breaches and has increasingly been seen in Indian enterprise environments as well. The challenge is that organisations often have little visibility into what access they have granted to third parties, because these grants were made years ago for projects that may have concluded, by team members who have since left, without any formal offboarding process that would revoke the access.

What to Do

Conduct a complete audit of all cross-account IAM roles and trust policies. For every role that trusts an external AWS account, verify: is this relationship still needed? Is the scope of permissions still appropriate? Is the external ID condition in place? Is there a process for revoking this access when the vendor relationship ends?

Implement the external ID condition on all cross-account roles used by third parties. AWS IAM documentation on the confused deputy problem provides detailed guidance on how to structure these trust policies correctly.

Create a vendor access management process: document every third party that has cloud access, what that access covers, the business justification, and the expected duration. Build an offboarding checklist that includes revoking all cloud access when a vendor relationship terminates. Review all third-party access on a quarterly basis.

For high-privilege vendor access — such as access granted to a cloud managed service provider managing your entire AWS environment — consider additional controls including AWS Organizations SCPs limiting what the vendor’s roles can do even within their granted scope, CloudTrail monitoring of all API calls made with vendor-owned identities, and regular access reviews conducted jointly with the vendor.

Misconfiguration 10: No Cloud Security Posture Management (CSPM)

What It Is

The first nine misconfigurations on this list are all discoverable and fixable — but only if someone is looking for them. Cloud Security Posture Management (CSPM) is the practice of continuously and automatically assessing a cloud environment’s configuration against security best practices and compliance frameworks, identifying deviations, and alerting on or automatically remediating them.

The absence of a CSPM capability — the tenth and arguably most important misconfiguration — means that the organisation has no systematic way to know whether any of the previous nine misconfigurations exist in their environment right now. Manual audits conducted quarterly or annually will never keep pace with the velocity of change in modern cloud environments, where hundreds of infrastructure changes may be made every week.

Why It Happens in India

CSPM tools — AWS Security Hub, Microsoft Defender for Cloud, GCP Security Command Center, and commercial products like Prisma Cloud, Wiz, Orca Security, and Lacework — represent an additional technology investment, require dedicated security engineering to implement and operate, and produce findings that require human judgment and remediation effort. Many Indian organisations, particularly mid-sized enterprises and growing startups, have not yet built the security engineering function that would own and operate a CSPM program.

There is also a tendency in Indian cloud adopters to conflate compliance with security. Passing an ISO 27001 audit or achieving SOC 2 certification is often seen as proof that the cloud environment is secure. In reality, these certifications assess the existence of processes and controls at a point in time — they do not provide continuous assurance that those controls are correctly implemented and maintained in the cloud environment. A CSPM tool provides the continuous dimension that point-in-time certification cannot.

The alert fatigue problem is real and worth acknowledging. Naive deployment of CSPM tools on a mature cloud environment produces hundreds or thousands of findings across multiple severity levels. Organisations that deploy CSPM without a plan for triaging and remediating findings quickly conclude that the tool is generating noise and deprioritise its output. This creates a false sense of security that is worse than not having the tool at all.

Real-World Consequences

The absence of CSPM means that misconfigurations introduced by any developer at any time — a public S3 bucket created for a one-off data transfer, an open security group rule added to debug a connectivity issue, an IAM role with overly broad permissions granted to meet a deadline — persist in the environment indefinitely, accumulating security debt that grows with every new deployment.

The time-to-detect for misconfigurations in environments without CSPM is measured in months. Analysis of breach disclosures consistently shows that the gap between a misconfiguration being introduced and its exploitation is often weeks to months — but the gap between exploitation and discovery by the victim is often longer still. In environments with CSPM and active monitoring, misconfigurations are caught within hours of introduction, dramatically reducing the window of exposure.

What to Do

Start with the native CSPM capabilities available within your cloud provider, which are low-cost or free to enable. AWS Security Hub aggregates findings from AWS Config, Amazon GuardDuty, Amazon Inspector, and third-party integrations into a single dashboard with compliance scoring against CIS Benchmarks and AWS Foundational Security Best Practices. Enable Security Hub across all regions and all accounts in your AWS Organization. Azure Defender for Cloud and GCP Security Command Center offer equivalent capabilities.

Configure AWS Config to continuously record all resource configuration changes and evaluate them against managed Config rules covering the most important misconfiguration categories. Set up Amazon EventBridge rules to trigger alerts — and, where safe to do so, automated Lambda-based remediation — when critical findings are generated.

For organisations with more complex multi-cloud environments or higher security maturity requirements, commercial CSPM tools like Wiz, Prisma Cloud, or Orca provide broader coverage, deeper context, and better workflow integrations for remediation tracking. The key differentiator of these tools is attack path analysis — they don’t just identify individual misconfigurations in isolation, but surface the combinations of misconfigurations that together create a path from the internet to your most sensitive data.

Critically, implement CSPM findings as part of your security engineering workflow. Assign ownership of finding categories to specific team members. Set SLAs for remediation by severity — critical findings remediated within 24 hours, high within 7 days, medium within 30 days. Track remediation progress in your existing engineering ticketing system. Make CSPM health a metric reviewed in engineering leadership meetings. This operational discipline is what transforms CSPM from a checkbox into a genuine security improvement.

Finally, shift security left by integrating IaC security scanning into the CI/CD pipeline. Tools like Checkov, tfsec, Terrascan, and Snyk IaC scan Terraform, CloudFormation, and Helm templates for security misconfigurations before they are deployed. This prevents misconfigurations from reaching the environment in the first place, rather than detecting them after the fact — the most cost-effective possible approach to cloud security.

Conclusion: Building Cloud Security Maturity in India

The ten misconfigurations examined in this guide are not exotic or obscure vulnerabilities. They are foundational failures — the cloud security equivalent of leaving the front door unlocked. Every single one is detectable with existing tooling, and every single one is fixable with existing technology and processes. They persist not because they are technically difficult to address, but because security has not been institutionalised as a core engineering discipline in most Indian cloud-using organisations.

The regulatory environment is changing this calculation. The DPDP Act 2023, CERT-In directives, SEBI’s cloud security framework, and RBI’s cybersecurity guidelines for regulated entities all create enforceable obligations around exactly the controls described in this guide — encryption, access controls, logging, incident response. Organisations that have treated security as optional now face the prospect of significant financial penalties and mandatory breach disclosure.

The good news is that the path forward is clear. It begins with understanding your current state — a CSPM-driven inventory of existing misconfigurations across your cloud estate. It continues with prioritised remediation, starting with the critical findings that represent the greatest risk. It matures into a DevSecOps practice where security is embedded into every stage of the development and deployment lifecycle, making it structurally difficult to introduce misconfigurations in the first place.

India has the engineering talent and the cloud adoption momentum to build world-class cloud security practices. The organisations that invest in this now — not as a compliance exercise but as a genuine discipline — will be the ones that are not in the next breach headline.