{"id":81810,"date":"2026-09-11T18:25:36","date_gmt":"2026-09-11T12:55:36","guid":{"rendered":"https:\/\/www.tothenew.com\/blog\/?p=81810"},"modified":"2026-09-15T16:20:23","modified_gmt":"2026-09-15T10:50:23","slug":"aws-security-misconfigurations-small-drift-severe-blast-radius","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/aws-security-misconfigurations-small-drift-severe-blast-radius\/","title":{"rendered":"AWS Security Misconfigurations: Small Drift, Severe Blast Radius"},"content":{"rendered":"

Security incidents in AWS rarely stem from zero-day exploits against the hypervisor. In practice, they trace back to routine configuration drift: an IAM policy wildcard added at 2 AM to fix a broken deployment, a database spun up in a public subnet for staging, or a security group rule left open to 0.0.0.0\/0<\/em>.<\/p>\n

AWS operates on a shared responsibility model. AWS secures the physical infrastructure, virtualization layer, and managed services. You own identity management, network boundaries, data protection, and operational hygiene.<\/p>\n

That distinction is important. AWS can provide highly secure building blocks, but an incorrectly configured building block can still create a significant security gap.<\/p>\n

The good news is that most of these issues are preventable.<\/p>\n

    \n
  1. \n
      \n
    1. Excessive IAM Privileges & Wildcard Policies<\/strong>
      \nIAM is often the first place where convenience wins over security.
      \nThe path of least resistance during development is attaching managed policies such as AdministratorAccess or writing policies containing:
      \n
      \n{
      \n\"Effect\": \"Allow\",
      \n\"Action\": \"*\",
      \n\"Resource\": \"*\"
      \n}
      \n<\/code>
      \nThis effectively breaks the Principle of Least Privilege (PoLP).The problem becomes much more serious when an application has excessive permissions. For example, an SSRF vulnerability could potentially allow an attacker to access temporary credentials from an instance metadata service. If those credentials have broad permissions, a relatively small application vulnerability can become a much larger AWS compromise.
      \nAntipattern: Excessive blast radius<\/strong>
      \n
      \n{
      \n\"Effect\": \"Allow\",
      \n\"Action\": \"s3:*\",
      \n\"Resource\": \"*\"
      \n}
      \n<\/code>Hardened approach<\/strong>
      \n
      \n{
      \n\"Effect\": \"Allow\",
      \n\"Action\": [
      \n\"s3:GetObject\",
      \n\"s3:PutObject\"
      \n],
      \n\"Resource\": \"arn:aws:s3:::app-production-assets-2026\/*\"
      \n}
      \n<\/code>
      \nThe second policy gives the workload only the permissions it actually needs.Practical controls<\/strong><\/p>\n
        \n
      • \n
          \n
        • Use targeted resource ARNs.<\/strong>
          \nInstead of allowing access to every S3 bucket, restrict permissions to the specific bucket, prefix, queue, table, or secret required by the application.<\/li>\n
        • Use condition keys.<\/strong>
          \nConditions such as aws:PrincipalOrgID, aws:RequestedRegion, source VPC endpoints, or encryption requirements can add another layer of control.<\/li>\n
        • Use Permission Boundaries.<\/strong>
          \nPermission boundaries establish the maximum permissions an IAM principal can receive, even if someone attempts to attach a broader policy.<\/li>\n
        • Use SCPs for organization-level guardrails.<\/strong>
          \nService Control Policies can prevent member accounts from performing certain actions, regardless of permissions granted within the account.<\/li>\n
        • Prefer IAM roles over long-lived access keys.<\/strong>
          \nFor EC2, ECS, Lambda, and other AWS workloads, use IAM roles and temporary credentials wherever possible.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

          The objective isn’t to eliminate administrative access completely. It is to control where administrative access exists and reduce the blast radius when credentials or workloads are compromised.<\/li>\n

        • Unrestricted Management Ports in Security Groups<\/strong>
          \nSecurity Groups are another common source of accidental exposure.Opening SSH or RDP directly to the internet makes infrastructure continuously reachable by external scanners and attackers.
          \nAntipattern<\/strong>
          \n
          \nType: SSH
          \nProtocol: TCP
          \nPort: 22
          \nSource: 0.0.0.0\/0
          \n<\/code>
          \nSimilarly:
          \n
          \nType: RDP
          \nProtocol: TCP
          \nPort: 3389
          \nSource: 0.0.0.0\/0
          \n<\/code>
          \nThis doesn’t automatically mean the server is compromised. However, it unnecessarily increases the attack surface and exposes authentication endpoints to brute-force attempts and credential attacks.Better approach: eliminate direct management ingress<\/strong>
          \nFor supported workloads, use AWS Systems Manager Session Manager instead of exposing SSH or RDP.
          \nConceptually:
          \n
          \nAdministrator
          \n|
          \n\u2193
          \nSSM Session Manager
          \n|
          \n\u2193
          \nEncrypted HTTPS \/ TCP 443
          \n|
          \n\u2193
          \nEC2 Instance
          \n<\/code>
          \nThe instance doesn’t need an inbound SSH rule for Session Manager access.
          \nFor instances in private or isolated subnets, VPC Interface Endpoints can provide private connectivity to the Systems Manager control plane, including endpoints such as:
          \n
          \nssm
          \nssmmessages
          \nec2messages
          \n<\/code>
          \nIf SSH\/RDP is genuinely required<\/strong>
          \nDon’t automatically open it to the world. Restrict the source to a trusted network, VPN, bastion host, or specific administrative IP range:
          \nSSH \/ TCP \/ 22
          \nSource: 10.0.36.246\/32
          \nA useful rule is:<\/p>\n

          If an administrative port doesn’t need to be publicly reachable, don’t make it publicly reachable.<\/p><\/blockquote>\n<\/li>\n

        • Publicly Exposed Data Stores<\/strong>
          \nData stores deserve particular attention because they often contain the information an attacker is ultimately trying to access.The most common mistake is treating “publicly accessible” as equivalent to “compromised.”It isn’t.A public database may still have strong authentication and restrictive security groups. However, making it publicly reachable increases the attack surface and creates additional opportunities for misconfiguration.Amazon S3<\/strong>
          \nS3 exposure can occur through:<\/p>\n
            \n
          • Bucket policies<\/li>\n
          • IAM policies<\/li>\n
          • Access Control Lists<\/li>\n
          • Account-level settings<\/li>\n
          • Bucket-level settings<\/li>\n
          • Cross-account permissions<\/li>\n<\/ul>\n

            For buckets that should remain private, enable and regularly validate S3 Block Public Access at the appropriate account and bucket levels.<\/p>\n

            But don’t stop at the S3 console’s public-access indicator.<\/p>\n

            Think about the complete access path:
            \n
            \nUser \/ Workload
            \n|
            \n\u2193
            \nIAM Policy
            \n|
            \n\u2193
            \nBucket Policy
            \n|
            \n\u2193
            \nS3 Object
            \n<\/code>
            \nA secure bucket requires the entire authorization chain to be intentional.<\/p>\n

            Also consider whether sensitive data is encrypted using an appropriate mechanism such as SSE-KMS, and whether access logging and monitoring are configured according to the workload’s requirements.<\/p>\n

            Amazon RDS<\/strong>
            \nMaking an RDS database publicly accessible does not automatically mean the database has been compromised.<\/p>\n

            It does, however, increase exposure.<\/p>\n

            A typical production architecture should look more like:
            \n
            \nInternet
            \n|
            \n\u2193
            \nLoad Balancer
            \n|
            \n\u2193
            \nApplication
            \n|
            \n\u2193
            \nPrivate RDS
            \n<\/code>
            \nThe database Security Group should allow database traffic only from the application layer that requires it.
            \nFor example:
            \n
            \nApplication SG
            \n|
            \n\u2193
            \nTCP 5432
            \n|
            \n\u2193
            \nRDS PostgreSQL
            \n<\/code>
            \nrather than:
            \n
            \n0.0.0.0\/0
            \n|
            \n\u2193
            \nTCP 5432
            \n|
            \n\u2193
            \nRDS
            \n<\/code>
            \nNetwork placement, Security Groups, authentication, encryption, and database configuration should all work together.<\/p>\n

            Amazon OpenSearch<\/strong>
            \nOpenSearch domains also require careful network and access design.<\/p>\n

            An unnecessarily internet-accessible domain increases the potential attack surface, particularly when combined with weak access policies or authentication controls.<\/p>\n

            Where appropriate, place OpenSearch within a VPC and restrict access through Security Groups and identity-based controls.
            \nThe general principle is simple:<\/p>\n

            If a data store does not need to be publicly reachable, don’t expose it.<\/p><\/blockquote>\n<\/li>\n

          • Configuration Drift: The Silent Security Problem<\/strong>
            \nOne of the biggest challenges in cloud security is that an environment can start secure and become insecure later.Consider this sequence:
            \n
            \nDay 1
            \nSecure configuration
            \n\u2193
            \nDay 30
            \nTemporary firewall rule
            \n\u2193
            \nDay 60
            \nNew IAM permission
            \n\u2193
            \nDay 90
            \nUnused access remains
            \n\u2193
            \nDay 180
            \nSecurity exposure
            \n<\/code>
            \nThis is configuration drift.The dangerous part is that nothing necessarily “breaks.” Applications may continue working normally while security boundaries slowly deteriorate.How to control drift<\/strong>Use automated controls rather than relying exclusively on manual reviews.Useful AWS capabilities include:<\/p>\n
              \n
            • AWS Config for tracking configuration changes and compliance<\/li>\n
            • AWS Security Hub for centralized security findings<\/li>\n
            • Amazon GuardDuty for threat detection<\/li>\n
            • AWS CloudTrail for API activity and audit trails<\/li>\n
            • AWS IAM Access Analyzer for identifying unintended access<\/li>\n
            • Automated remediation through EventBridge\/Lambda where appropriate<\/li>\n<\/ul>\n

              For example, AWS Config can detect when a Security Group changes from:
              \n
              \nTCP 22 \u2192 10.0.0.0\/8
              \n<\/code>
              \nto:
              \n
              \nTCP 22 \u2192 0.0.0.0\/0
              \n<\/code>
              \nCloudTrail can then help answer the next question:<\/p>\n

              Who or what made the change?<\/p><\/blockquote>\n

              That distinction is important. Configuration monitoring tells you what changed; audit logs can help determine who made the change and when.<\/li>\n

            • Don’t Confuse “Working” With “Secure”
              \n<\/strong><\/strong>A common operational mistake is prioritizing availability over security without revisiting the temporary decision.For example:”The deployment was failing, so we temporarily gave the role s3:*.”
              \nOr:”The developer needed database access, so we temporarily made RDS public.”
              \nOr:”We opened port 22 for troubleshooting and will close it later.”
              \nThe problem isn’t necessarily the emergency action.The problem is when the temporary exception becomes permanent infrastructure.<\/p>\n

              Every temporary security exception should have:<\/p>\n

                \n
              1. An owner<\/li>\n
              2. A documented reason<\/li>\n
              3. A defined expiration\/review date<\/li>\n
              4. Monitoring<\/li>\n
              5. A plan to remove it<\/li>\n<\/ol>\n

                This turns emergency access from an uncontrolled risk into a managed exception.<\/li>\n<\/ol>\n

                Conclusion<\/strong>
                \nAWS security is not only about protecting against sophisticated attacks; it is equally about preventing everyday configuration mistakes from becoming security incidents. Excessive IAM permissions, unrestricted management ports, publicly accessible data stores, and configuration drift can significantly increase an organization’s attack surface and impact the potential blast radius of a compromise.<\/p>\n

                A secure AWS environment requires a defense-in-depth approach: apply least-privilege access, restrict network exposure, keep sensitive workloads private, encrypt and protect data, and continuously monitor the environment for unexpected changes.<\/p>\n

                Ultimately, security should be treated as an ongoing operational practice rather than a one-time configuration task. Regular reviews, automated monitoring, and timely remediation help ensure that AWS environments remain aligned with their intended security posture as infrastructure and applications evolve.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"

                Security incidents in AWS rarely stem from zero-day exploits against the hypervisor. In practice, they trace back to routine configuration drift: an IAM policy wildcard added at 2 AM to fix a broken deployment, a database spun up in a public subnet for staging, or a security group rule left open to 0.0.0.0\/0. AWS operates […]<\/p>\n","protected":false},"author":2252,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"footnotes":""},"categories":[5877],"tags":[248,7041],"class_list":["post-81810","post","type-post","status-publish","format-standard","hentry","category-msp","tag-aws","tag-security"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t