AWS and GCP Cloud Security: Misconfigurations That Take Down Startups
In short
Most cloud incidents at startups come from misconfiguration, not from the provider. The critical points: overly privileged IAM keys, public S3 or Cloud Storage buckets, secrets in code, root without MFA, CloudTrail turned off, and open security groups (0.0.0.0/0). The minimum baseline is least privilege, blocking public storage, centralized logs, MFA, and measuring your environment against the CIS Benchmarks with a CSPM.
Decripte is a cybersecurity company serving businesses from 1 to 100,000+ employees — from MVPs to scale-ups. A full platform and services, starting with the free Threat Management plan.
Key takeaways
- ›Under the AWS and GCP shared responsibility model, your account's configuration is the startup's responsibility, not the provider's.
- ›IAM least privilege, blocking public bucket access, and MFA on the root/Organization Admin user eliminate most of the attack surface.
- ›CloudTrail (AWS) and Cloud Audit Logs (GCP) must be on in all regions before an incident; afterward it is too late to investigate.
- ›A CSPM with a CIS Benchmarks baseline lets a lean team measure and fix deviations continuously, without manual auditing.
Why configuration is the weak point, not the infrastructure
AWS and GCP operate under the shared responsibility model: the provider protects the physical infrastructure, the hypervisor, and the managed services; the customer is responsible for who accesses what, how data is exposed, and how credentials are managed. For a startup, this means that nearly all compromise vectors sit within the team's own scope, not the provider's.
The pattern repeats in cloud incident reports: the problem is rarely a vulnerability in S3 or Compute Engine. The problem is a bucket left public, an access key committed to Git, a security group opening port 22 to the entire internet, or a root user without MFA. These are misconfigurations, and configuration is exactly where a small team, with no dedicated security specialist, most often slips under deadline pressure.
The good news is that these errors are known, finite, and measurable. The AWS Well-Architected Framework (Security pillar) and the Google Cloud Architecture Framework describe the expected practices, and the CIS Benchmarks for AWS and GCP translate them into verifiable controls. The goal of this article is to map the errors that appear most often and define a minimum baseline that fits the reality of a lean team.
IAM and least privilege: the error that amplifies all the others
Identity is the new perimeter. A credential with broad permissions turns a small leak into a total account compromise. The most frequent errors are: attaching broad managed policies like AdministratorAccess to users or application roles; using a single long-lived access key shared across services; and provisioning human users with static keys instead of federated identities with temporary credentials.
The principle of least privilege, described in NIST SP 800-53 (AC-6) and in both Well-Architected frameworks, requires granting only the permissions needed for the task, and nothing more. In practice: prefer assumed roles (AWS IAM Roles, GCP service accounts with Workload Identity) over long-lived keys; grant permissions per resource and per action, not by wildcard; and periodically review what each principal actually used. AWS exposes the IAM Access Analyzer and Access Advisor (last accessed) precisely for this; GCP offers the IAM Recommender, which suggests removing unused roles.
For workloads, eliminate static keys: on AWS use IAM Roles for Service Accounts (IRSA) on EKS or instance profiles; on GCP use Workload Identity Federation, which avoids downloading service account JSON keys. A service account key in a file is one of the most leaked credentials in public repositories, and it does not expire on its own.
Start with visibility
See for free what has already leaked and where your startup is exposed.
Decripte's free Threat Management plan maps vulnerabilities, monitors threats and shows leaked credentials — no credit card and no security team required.
Start free nowExposed storage: public S3 and Cloud Storage buckets
Data leaks from open buckets remain among the most common and most embarrassing incidents. On AWS, enable Block Public Access at the whole-account level, not just per bucket; this prevents a misconfigured ACL or policy from exposing data, even if someone makes a mistake later. Combine it with encryption at rest by default (SSE-KMS) and with policies that deny uploads without TLS.
On GCP, prefer uniform bucket-level access, which disables per-object ACLs and centralizes permissions through IAM, reducing the chance of a single object becoming public. Use Domain Restricted Sharing in the Organization Policy to prevent allUsers or allAuthenticatedUsers from being granted to any resource, closing the door to accidental exposure.
On both providers, the recurring error is treating exposure as a per-resource decision. Treat it as an organization decision: public access blocked by default, with explicit, documented, and monitored exceptions. The CIS Benchmark covers these items directly (the S3 and Cloud Storage sections), which makes it easy to verify compliance automatically.
Secrets, root MFA, and logging: the triad that defines the blast radius
Secrets in code or in versioned environment variables are a chronic source of compromise. Centralize secrets in AWS Secrets Manager or GCP Secret Manager, inject them at runtime, enable automatic rotation, and use secret detection in the pipeline (git hooks, PR scanning). Never commit keys; when one leaks, revoke and rotate it immediately, because bots scan GitHub within minutes. OWASP reinforces separating credentials from code as a basic control.
The AWS root account and the GCP Organization Admin user have unrestricted power. Enable MFA on these identities (ideally a hardware key), do not use them for day-to-day operations, remove access keys from root, and create separate administrative users via SSO/IAM Identity Center. This is the highest return-per-effort control: a protected root drastically limits the damage from any leaked credential.
Logging is not optional. On AWS, keep CloudTrail on in all regions, with an organization trail, log integrity validation, and delivery to a dedicated bucket with restricted access; also enable GuardDuty for detection. On GCP, ensure Cloud Audit Logs (Admin Activity is on by default; enable Data Access where it makes sense) and consider the Security Command Center. Without an audit trail enabled before the incident, the investigation is blind: you will not know what was accessed or by whom.
Security groups and networking: stop opening 0.0.0.0/0
Security groups (AWS) and firewall rules (GCP) opened to the entire internet are a classic. The most dangerous cases: SSH (22), RDP (3389), and database ports (5432, 3306, 27017) reachable from 0.0.0.0/0. The rule is simple: no administrative or database port should be exposed to the internet. Use bastion access, AWS Systems Manager Session Manager, or GCP IAP (Identity-Aware Proxy), which avoid opening SSH altogether.
Structure the network with segmentation: private subnets for databases and internal workloads, public ones only for what needs to receive external traffic, and everything behind a load balancer or WAF where applicable. Restrict rules by source (a specific CIDR, a source security group) instead of opening wide ranges. The CIS Benchmark explicitly checks for the absence of 0.0.0.0/0 rules on sensitive ports, so this is an easy item to measure and keep clean.
A minimum baseline with a lean team: CSPM and CIS without a dedicated security team
A startup does not need a SOC to get started; it needs a baseline applied consistently and an automatic way to detect when the environment drifts from it. That is where CSPM (Cloud Security Posture Management) comes in: the tool continuously evaluates your AWS/GCP account against a set of rules, usually aligned with the CIS Benchmarks, and flags deviations with priority and suggested remediation. This replaces manual auditing, which a small team cannot sustain.
There are native resources that already deliver part of this: AWS Security Hub (which aggregates the CIS AWS Foundations Benchmark, GuardDuty, and Inspector) and GCP Security Command Center. Enable at least the standard tier, connect the findings to a channel the team reads (Slack, email, tickets), and treat critical findings like production bugs: with an owner, a deadline, and a resolution. Infrastructure as code (Terraform) with review and static scanning (tfsec, Checkov) prevents deviations from getting in in the first place.
The central point is to make the posture measurable and continuous, not a one-off hardening project that ages within weeks. With IAM at least privilege, storage blocked, secrets centralized, root with MFA, logging on, and the network closed, you cover most of the real vectors with an investment proportional to the team's size.
Practical checklist
- 1
1. Protect root and enable MFA
Enable MFA on the AWS root account and the GCP Organization Admin, remove access keys from root, and create administrative access via SSO/IAM Identity Center with separate profiles.
- 2
2. Apply least privilege in IAM
Replace broad policies (AdministratorAccess) with specific permissions, migrate workloads to temporary roles (IRSA, Workload Identity), and use Access Analyzer and IAM Recommender to remove unused privileges.
- 3
3. Block public access to storage
Turn on whole-account Block Public Access on AWS and uniform bucket-level access plus Domain Restricted Sharing on GCP. Enable encryption at rest by default.
- 4
4. Centralize and rotate secrets
Move credentials to Secrets Manager (AWS) or Secret Manager (GCP), inject them at runtime, enable rotation, and add secret scanning to the pipeline. Revoke any key that has already leaked.
- 5
5. Turn on logging in all regions
Enable an organization CloudTrail with integrity validation and GuardDuty on AWS; ensure Cloud Audit Logs and evaluate the Security Command Center on GCP. Deliver logs to a restricted destination.
- 6
6. Close the network
Remove 0.0.0.0/0 rules for SSH, RDP, and databases. Use Session Manager or IAP for administrative access and segment databases into private subnets.
- 7
7. Measure against CIS with a CSPM
Enable Security Hub (CIS AWS Foundations) or Security Command Center, or a dedicated CSPM, and treat critical findings as bugs with an owner and a deadline. Use IaC with tfsec/Checkov to prevent deviations.
Frequently asked questions
Whose responsibility is cloud security: mine or AWS/GCP's?
It is shared. The provider protects the physical infrastructure and managed services; your startup is responsible for account configuration, access control (IAM), data exposure, and credential management. Most incidents happen precisely in that layer under your responsibility.
What is least privilege and why does it matter so much?
It means granting each user or service only the permissions needed for its task, and nothing more (NIST SP 800-53 AC-6). It matters because it limits the damage from a leaked credential: with least privilege, a compromised key accesses little; with broad privilege, it compromises the whole account.
How do I keep an S3 or Cloud Storage bucket from becoming public by accident?
On AWS, enable Block Public Access at the whole-account level. On GCP, use uniform bucket-level access and Domain Restricted Sharing in the Organization Policy to prevent grants to allUsers. Treat public exposure as a documented exception, never as an isolated per-resource decision.
Why do CloudTrail and Audit Logs need to be on before an incident?
Because they are the audit trail that records who did what. Without these logs enabled beforehand, there is no way to reconstruct what an attacker accessed or changed. Turned on afterward, they only capture future events, leaving the incident period without visibility.
What is a CSPM and does my startup need one?
A CSPM (Cloud Security Posture Management) is a tool that continuously evaluates your cloud account against security rules, usually aligned with the CIS Benchmarks, flagging deviations and remediations. For a lean team, it replaces manual auditing and keeps the posture under control automatically.
Can I use only the native AWS and GCP tools?
Yes, it is a good start. AWS Security Hub (with CIS Foundations, GuardDuty, Inspector) and GCP Security Command Center cover much of the baseline. The gain from a CSPM or partner comes from the unified multi-cloud view, prioritization, and continuous tracking of finding remediation.
How do I access instances without leaving the SSH port open to the internet?
Use AWS Systems Manager Session Manager or GCP's Identity-Aware Proxy (IAP). Both allow authenticated, audited administrative access without opening ports 22 or 3389 in security groups, eliminating one of the most exploited attack vectors against servers.
Where should a startup with a small team start?
With the highest-return triad: MFA on root, least privilege in IAM, and logging on in all regions. Next, block public storage, centralize secrets, and close the network. Then automate measurement with a CSPM or Security Hub so you do not regress.
Security for startups and fintechs
From the first round to enterprise: Decripte grows with you.
A full platform and services: threat management, 24x7 SOC, incident response, pentest and compliance (LGPD, ISO, BACEN). Start free and see what has already leaked from your business.