Forem: Matheus Almeida Costa

How to Ensure Security Tool Connectivity on EC2 Across AWS Accounts with Automated Security Group Compliance

Matheus Almeida Costa — Fri, 06 Mar 2026 02:20:12 +0000

Introduction

Cloud security operations often require ensuring consistent and compliant network access for security tools across hundreds of Amazon EC2 instances distributed across multiple AWS accounts and regions.

In large-scale environments managed through AWS Organizations, what seems like a simple requirement can quickly become operationally complex.

Many security tools depend on network connectivity to perform their functions. Without the correct inbound rules configured on EC2 Security Groups, these tools cannot reach the instances they are supposed to monitor and access.

Common examples include:

Privileged Access Management (PAM) such as BeyondTrust or CyberArk, which require network connectivity to EC2 instances to rotate credentials and manage privileged sessions.
Vulnerability management platforms such as Qualys or Tenable, which require network connectivity to perform authenticated vulnerability scans and deeper security assessments.
Configuration compliance and hardening tools which connect via SSH or RDP to EC2 instances to verify system configurations, validate security baselines, and assess compliance with standards such as CIS Benchmarks.

In large multi-account AWS environments, maintaining this connectivity manually becomes unmanageable.

The traditional manual approach quickly breaks down for several reasons:

Slow onboarding: Every new AWS EC2 on any AWS account required manual configuration of Security Group rules.
Operational fragility: If someone accidentally removed a rule, the security tool immediately lost access reducing visibility into the environment.
Lack of scalability: Managing scanner IP ranges across dozens of AWS accounts and multiple regions through the console simply doesn't scale.

As the environment grows, these issues compound, creating gaps in security monitoring and increasing operational overhead for security teams.

Objective

The goal was to guarantee network accessibility in a reliable and automated way for approved security tools to EC2 instances across all AWS regions and accounts.

The solution needed to meet the following requirements:

Automatic coverage for new resources: Newly launched EC2 instances should always receive the required connectivity without manual intervention.
Operational scalability: The mechanism must work seamlessly across multiple regions and accounts without requiring per-account configuration.
Auto remediation configuration: If a rule is accidentally removed, it should be automatically restored.
Centralized management : Security teams should be able to update security tools IP ranges in a single location and propagate those changes across all accounts.

Solution Architecture

To achieve this, I built an automated daily compliance mechanism that validates and enforces security group rules across the entire AWS Organizations.

Architecture Diagram

The following diagram illustrates the high-level architecture used to automate Security Group compliance across multiple AWS accounts and regions.

The automation runs from a dedicated security account, where AWS Lambda functions handle two main tasks: building an inventory of AWS accounts by assuming a role in the Organizations management account and performing remediation actions by assuming roles in member accounts.

In this example, the diagram shows two fictional member accounts (Account X and Account Y) containing EC2 instances and Security Groups. In real environments, this approach can scale to dozens or even hundreds of accounts.

The architecture also demonstrates a multi-region setup (us-east-1, us-east-2, and sa-east-1), where Security Groups reference regional Prefix Lists to allow connectivity from centralized security tools.

Core Components

The solution relies on a small set of AWS services working together to provide centralized control, automation, and scalability across all accounts in the organization.

AWS Lambda: Acts as the automation engine. The function assumes cross-account IAM roles to audit EC2 Security Groups and automatically remediate missing rules when necessary.
Amazon S3: Stores a daily-generated inventory of all AWS accounts. This inventory is used by the automation workflow to determine where audits and remediations should be executed.
AWS VPC Prefix Lists: Provides a centralized and scalable way to manage the IP ranges used by security tools. Instead of hardcoding IPs in Security Group rules, the rules reference a Prefix List. This allows security teams to update the IP ranges in a single place and AWS automatically propagates the changes to every Security Group referencing the list.
AWS Organizations: Provides the centralized account structure that allows the automation to discover and operate across all AWS accounts.
AWS Resource Access Manager (RAM): Enables the Prefix List to be shared with all accounts in the organization, allowing Security Groups in any account to reference the centralized list.
AWS CloudFormation StackSets: Used to deploy the required IAM roles across all AWS accounts in the organization. This ensures that newly created accounts automatically receive the permissions required for the automation to operate.

How It Works

1. AWS account inventory collection

A scheduled AWS Lambda function (triggered by Amazon EventBridge) runs in the management account and queries AWS Organizations to retrieve the list of active accounts. The function also enumerates enabled AWS regions and stores this inventory in an Amazon S3 bucket. Maintaining this inventory allows the automation to dynamically adapt as new accounts are added or removed from the organization.

2. Cross-Account Security Group Audit and Remediation

The main Lambda function consumes the account inventory stored in S3 and iterates through each AWS account and region. Using cross-account role assumption, the function inspects EC2 instances and their associated Security Groups to verify whether inbound access from the authorized Prefix List is allowed. If the required rule is missing, the Lambda automatically injects the appropriate inbound rule into the Security Group, ensuring the instance remains accessible to the approved security tools.

As a result, EC2 instances will have a Security Group rule similar to the following:

In this example, the rule allows all ports to simplify connectivity for security tools. However, depending on your environment and the requirements of each tool, you can restrict the rule to only the specific ports that are required.

Deployment Steps

The full implementation for this project is available in the GitHub repository.

Below is a high-level guide to deploy this solution in a multi-account AWS environment.

1. Create the Prefix List

Start by creating a Prefix List in each region where your workloads run. This list will contain the IP ranges used by your security tools and will be referenced by Security Group rules instead of hardcoding individual IP addresses.

With this approach, security teams can update IP ranges centrally through the Prefix List, without needing to modify Security Groups across multiple accounts or regions.

2. Share the Prefix List Across Accounts

Use AWS Resource Access Manager (RAM) to share the Prefix List with all accounts in your AWS Organization.

This allows Security Groups in other accounts to reference the centralized Prefix List. After sharing, Security Groups in all accounts can reference the Prefix List.

3. Deploy the Cross-Account IAM Role

The automation Lambda requires permissions to describe and modify Security Groups across multiple AWS accounts.

To enable this, use AWS CloudFormation StackSetsto deploy a receiver role in all accounts of the organization. This ensures that newly created AWS accounts automatically receive the required role.

The following custom IAM policy is attached to the role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowEC2",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeSecurityGroups",
                "ec2:AuthorizeSecurityGroupIngress"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowOrganizations",
            "Effect": "Allow",
            "Action": [
                "organizations:ListAccounts",
                "organizations:ListAccountsForParent"
            ],
            "Resource": "*"
        }
    ]
}

The role must also allow sts:AssumeRole from the central security account where the Lambda runs.

4. Deploy the Lambda functions

Deploy the two Lambda functions in the security account.

The first Lambda is responsible for building an inventory of AWS accounts by retrieving the list of accounts from AWS Organizations and storing this inventory in Amazon S3.

The second Lambda consumes this inventory, assumes the cross-account role in each account, audits EC2 Security Groups across regions, and automatically adds the missing inbound rule referencing the Prefix List when necessary.

5. Deploy the EventBridge Schedule

Create an Amazon EventBridge rule to trigger the Lambda functions on a schedule, for example once per day.

Extra: Security by Default with IaC

While the automation remediates missing rules, the best control is preventing the misconfiguration from happening in the first place.

To achieve this, a security-by-default approach can be implemented in the Infrastructure as Code layer using Terraform.

When new EC2 Security Groups are created, the rule allowing access from approved security tools is added by default. This ensures that new workloads are compliant from the moment they are deployed, reducing the need for remediation.

Example Terraform Configuration

Instead of hardcoding scanner IP addresses directly in Security Group rules, the configuration references AWS Managed Prefix Lists. This allows security teams to update scanner IP ranges centrally without modifying infrastructure code.

ingress {
  from_port       = 0
  to_port         = 65535
  protocol        = "-1"
  description     = "Allow security scanning tools"
  prefix_list_ids = local.security_pl
}

Because Managed Prefix Lists are regional resources in AWS, the Terraform configuration dynamically selects the correct Prefix List ID based on the region where the infrastructure is deployed.

security_pl = lookup({
  "us-east-1" = "pl-xxx"
  "us-east-2" = "pl-yyy"
  "sa-east-1" = "pl-zzz"
}, local.region)

This approach ensures that:

Security tools have immediate access to newly created instances.
IP changes are managed centrally through the Prefix List instead of individual Security Group rules.

Conclusion

Maintaining network access for security tools across multiple AWS accounts can quickly become an operational burden if handled manually.

By combining Managed Prefix Lists, cross-account automation, and Infrastructure as Code, we transformed this into a scalable and self-healing control.

Instead of relying on manual Security Group management, connectivity for security tooling becomes part of the platform itself automatically enforced and continuously verified.

AWS Security Services Overview

Matheus Almeida Costa — Sun, 01 Feb 2026 02:54:00 +0000

AWS Security Services

This post provides a complete overview of AWS security services, serving as a resumed reference guide for professionals who work with Cloud Security.

The goal is to give a clear understanding of what each service does, how it fits into an AWS security strategy, and when it makes sense to use it in real environments.

Each section is grouped by category, with a short scenario and a few practical notes:

Identity & Access Management
- AWS Identity and Access Management (IAM)
- AWS IAM Access Analyzer
- AWS IAM Identity Center
- AWS Organizations
- AWS Resource Access Manager (RAM)
- Amazon Cognito
- AWS Directory Service
Data Protection
- AWS Secrets Manager
- AWS Private Certificate Authority (Private CA)
- AWS Certificate Manager (ACM)
- Amazon Macie
- AWS Key Management Service (KMS)
- AWS CloudHSM
- AWS Payment Cryptography
Network and Application Protection
- AWS WAF
- AWS Shield
- AWS Network Firewall
- AWS Firewall Manager
- AWS Verified Access
- Amazon VPC Lattice
Threat Detection & Monitoring
- AWS CloudTrail
- Amazon GuardDuty
- AWS Security Hub
- Amazon Detective
- Amazon Inspector
- Amazon Security Lake
- AWS Security Incident Response
Application Security
- AWS Systems Manager
- AWS Signer
- AWS Security Agent
- Amazon Verified Permissions
Compliance & Governance
- AWS Config
- AWS Audit Manager
- AWS Artifact

Identity & Access Management

AWS Identity and Access Management (IAM)

Description
IAM defines who can do what in an AWS account. It handles authentication (users, roles, federated identities) and authorization (policies) across every AWS service.

Scenario
A security team designs IAM roles so developers can deploy Lambda functions only in non-production accounts. Each role uses scoped permissions, and developers assume the role with temporary credentials instead of relying on long-term access keys.

Best Practices

Apply least privilege. Only grant what's actually needed.
Replace IAM users with roles and short-lived credentials wherever possible.
Enforce MFA on every privileged identity.
Run IAM Access Analyzer regularly to find unused permissions and external access. Since 2024 it also surfaces unused-access findings, which is useful for cleaning up over-permissive roles.

Pricing
Free.

AWS IAM Access Analyzer

Description
IAM Access Analyzer uses automated reasoning (what AWS calls "provable security") to find resources shared outside your trust boundary, identify unused permissions, and validate IAM policies before they ship. It runs across S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, Secrets Manager, and others.

Scenario
A new feature ships with an S3 bucket policy that accidentally allows s3:GetObject from any account. Access Analyzer flags it within minutes as an external access finding, and the team rolls back the policy before any data leaves the account.

Best Practices

Enable both an external access analyzer and an unused access analyzer at the organization level.
Wire custom policy checks into CI/CD so policies that grant new access trigger an approval step before merge.
Treat findings like security tickets, not informational logs. Archive intentional ones and resolve the rest.

Pricing
External access analysis is free. Unused access analysis is per IAM role or user analyzed per month.

AWS IAM Identity Center

Description
IAM Identity Center (formerly AWS SSO) is the recommended way to manage human access across multiple AWS accounts. It connects to identity providers like Okta, Entra ID, or Google Workspace and centralizes permission sets per account.

Scenario
A company with 12 AWS accounts integrates Identity Center with Entra ID. Employees log in once with their corporate credentials and land on a portal that shows only the accounts and roles they're entitled to, mapped from their AD groups.

Best Practices

Assign access by group, not by individual user.
Map directory groups to AWS accounts and permission sets.
Enable MFA and reasonable session timeouts.

Pricing
Free.

AWS Organizations

Description
AWS Organizations lets you centrally manage multiple AWS accounts as a single entity. It's where you set up Organizational Units (OUs), Service Control Policies (SCPs), and the more recent Resource Control Policies (RCPs) to define guardrails across the whole environment.

Scenario
A platform team groups production accounts under a "Prod" OU and applies an SCP that blocks anyone (including admins) from disabling CloudTrail or operating outside approved regions. Even if a member account creates a role with AdministratorAccess, the SCP still wins.

Best Practices

Use OUs to reflect environments or business units, not just teams.
Combine SCPs (identity guardrails) with RCPs (resource-side guardrails) to build a data perimeter.
Enable trusted access for services like CloudTrail, Config, and GuardDuty so they can be managed organization-wide.

Pricing
Free.

AWS Resource Access Manager (RAM)

Description
RAM shares AWS resources like subnets, Transit Gateways, or Route 53 Resolver rules across accounts inside an Organization, without duplicating infrastructure.

Scenario
A central network account owns the Transit Gateway and shares it through RAM with workload accounts. Each team works in its own VPC but uses shared connectivity, keeping the network footprint consistent.

Best Practices

Share only what's needed, and only with the accounts that actually need it.
Audit shares regularly. Old ones tend to outlive the projects that created them.
Tag shared resources with an owner so accountability is clear.

Pricing
Free.

Amazon Cognito

Description
Cognito handles authentication and authorization for end-user applications. User pools manage sign-up and sign-in; identity pools issue temporary AWS credentials for federated users.

Scenario
A mobile app lets users sign in with Google or Apple ID. Cognito brokers the federation and hands back short-lived AWS credentials so the app can call backend APIs through API Gateway.

Best Practices

Enforce a strong password policy and enable MFA.
Use Cognito triggers (Lambda) when you need custom validation or extra checks at sign-up or sign-in.
Keep tokens out of insecure storage on the client side.

Pricing
Per monthly active user (MAU), with a free tier for the first 50,000 MAUs in most cases.

AWS Directory Service

Description
Directory Service provides managed Microsoft Active Directory in AWS, or connects AWS resources to an existing on-prem AD.

Scenario
A company migrates Windows workloads to EC2 and wants to keep the same group policies and authentication flow. AWS Managed Microsoft AD gives them a real AD domain in AWS, with a trust to the on-prem forest.

Best Practices

Pick Managed Microsoft AD when you need full AD features. AD Connector is enough if you only need to proxy authentication to on-prem.
Keep domain admin accounts separate from day-to-day accounts.
Send directory logs to CloudWatch for visibility into logins and policy changes.

Pricing
Per directory type and per hour.

Data Protection

AWS Secrets Manager

Description
Secrets Manager stores, rotates, and serves credentials, API keys, and other secrets, with native rotation support for RDS, Redshift, and DocumentDB.

Scenario
Instead of putting a database password in a Lambda environment variable, the function fetches it from Secrets Manager at runtime. A rotation Lambda swaps the password in RDS and updates the secret on a schedule, with no application changes required.

Best Practices

Turn on automatic rotation, especially for database credentials.
Scope IAM access down to the specific secret ARN. Wildcards on secretsmanager:GetSecretValue are a common mistake.
Encrypt secrets with a customer-managed KMS key when you want full control over who can decrypt them.

Pricing
Per secret per month, plus a small charge per 10,000 API calls.

AWS Private Certificate Authority (Private CA)

Description
AWS Private CA issues and manages private TLS certificates for internal services, IoT devices, and other workloads that don't need a publicly trusted CA.

Scenario
An internal platform issues short-lived certificates to microservices through Private CA, replacing long-lived self-signed certs scattered across containers.

Best Practices

Automate issuance and renewal. Manual cert management never scales.
Keep certificate lifetimes short to reduce blast radius if a key leaks.
Restrict who can issue certificates with IAM and CA-level permissions.

Pricing
Monthly fee per CA, plus a per-certificate fee that drops at higher volumes.

AWS Certificate Manager (ACM)

Description
ACM provisions, deploys, and renews public and private TLS certificates for AWS-integrated services like CloudFront, ALB, and API Gateway.

Scenario
A site behind CloudFront gets a free public ACM certificate validated via DNS. Renewal happens automatically, with no calendar reminders and no expired-cert pages.

Best Practices

Prefer DNS validation for fully automated renewal.
Use ACM for any AWS-integrated endpoint. Reach for Private CA only when you need certs outside that scope.
Pair with WAF in front of CloudFront or ALB for layered protection.

Pricing
Public certificates are free. Private certificates go through Private CA pricing.

Amazon Macie

Description
Macie uses ML and pattern matching to find sensitive data (PII, credentials, financial data) sitting in S3, and flags buckets that look risky.

Scenario
After Macie runs on a data lake, it surfaces a few buckets containing customer PII that nobody had classified. The findings feed into Security Hub and trigger remediation through Config.

Best Practices

Schedule recurring jobs on the buckets that actually matter. Running it on everything gets expensive fast.
Use managed data identifiers first, then add custom ones for company-specific patterns.
Send findings to Security Hub so they live alongside everything else.

Pricing
Per GB classified and per object monitored.

AWS Key Management Service (KMS)

Description
KMS creates and manages cryptographic keys used by AWS services and applications, with everything logged in CloudTrail.

Scenario
A finance team encrypts S3 and RDS with customer-managed keys (CMKs). Key policies restrict decryption to specific roles, and CloudTrail captures every Decrypt call for audit.

Best Practices

Use customer-managed keys for sensitive data. AWS-managed keys are fine for low-risk workloads but offer less control.
Enable automatic annual rotation.
Be careful with key policies. Locking yourself out of a CMK is a real (and painful) failure mode.

Pricing
Per key per month, plus per API request.

AWS CloudHSM

Description
CloudHSM gives you dedicated, FIPS 140-2 Level 3-validated Hardware Security Modules. Unlike KMS, the keys live in an HSM that only you control.

Scenario
A payments company processing card transactions needs full custody of the keys used for cryptographic operations. CloudHSM provides isolated HSMs in the customer's VPC, satisfying PCI DSS key-management requirements.

Best Practices

Use CloudHSM when regulation or contracts require exclusive key control. Otherwise KMS is usually enough.
Run an HSM cluster across multiple AZs for redundancy.
Consider a KMS custom key store backed by CloudHSM if you need both ecosystems.

Pricing
Hourly per HSM instance.

AWS Payment Cryptography

Description
Payment Cryptography provides managed cryptographic operations specifically for payment processing, including PIN translation, key exchange, and similar operations that traditionally required on-prem HSMs.

Scenario
A fintech replaces a legacy on-prem HSM setup with Payment Cryptography to handle PIN generation and key exchange with acquiring banks, while staying inside PCI PIN scope.

Best Practices

Pair with strict IAM conditions (e.g. source VPC, source IP) to limit who can call cryptographic operations.
Rotate keys on a defined schedule and document it for audit.
Keep CloudTrail logs of all operations as part of the compliance evidence chain.

Pricing
Per active key and per cryptographic API call.

Network and Application Protection

AWS WAF

Description
AWS WAF is a layer-7 firewall that protects HTTP(S) endpoints from common exploits like SQL injection, XSS, and bad bots. It integrates with CloudFront, ALB, API Gateway, AppSync, and App Runner.

Scenario
An API behind API Gateway is the front door for a retail app. WAF blocks requests with obvious injection patterns and rate-limits abusive clients before they reach the backend.

Best Practices

Start with AWS Managed Rule Groups (Core, Known Bad Inputs, OWASP-style sets) and tune from there.
Add rate-based rules to slow down brute-force and credential stuffing.
Send logs to CloudWatch, S3, or Kinesis Firehose so you can actually investigate when something is blocked, or when it isn't.
Keep separate Web ACLs for staging and production.

Pricing
Per Web ACL, per rule, and per million requests inspected.

AWS Shield

Description
Shield protects against DDoS attacks. Shield Standard is automatic and free; Shield Advanced adds higher-tier mitigations, cost protection, and access to the AWS Shield Response Team.

Scenario
A public API behind CloudFront sees a sudden traffic spike. Shield Standard absorbs the volumetric portion automatically. With Shield Advanced, the customer also gets detailed attack diagnostics and 24/7 escalation if mitigation needs human input.

Best Practices

Enable Shield Advanced for critical public-facing workloads where downtime has real financial impact.
Always pair with WAF for application-layer attacks. Shield alone won't stop a slow HTTP flood.
Run game days that simulate traffic surges so the team isn't learning the runbook during a real incident.

Pricing
Standard: free. Advanced: monthly subscription per organization, plus data transfer.

AWS Network Firewall

Description
Network Firewall is a managed stateful firewall and IPS for VPC traffic. It supports Suricata-compatible rules, so existing rule sets often port over with minimal changes.

Scenario
A central inspection VPC sits behind a Transit Gateway. All east-west and egress traffic flows through Network Firewall, where the security team enforces domain allowlists and Suricata IDS rules.

Best Practices

Centralize the firewall in a shared inspection VPC rather than deploying per-VPC instances.
Log everything to S3 or CloudWatch. Without logs, troubleshooting a blocked flow is guesswork.
Use domain-based stateful rules for egress filtering. They're much easier to maintain than IP lists.

Pricing
Per firewall endpoint hour, plus per GB processed.

AWS Firewall Manager

Description
Firewall Manager centrally manages WAF, Shield Advanced, Network Firewall, and security group policies across all accounts in an Organization.

Scenario
A security team defines a baseline WAF rule set that every CloudFront distribution in the org must have. Firewall Manager applies it automatically to new distributions as they're created.

Best Practices

Pair with AWS Organizations for org-wide reach.
Use resource tags to scope policies. For example, only enforce certain rules on resources tagged env=prod.
Treat Firewall Manager policies like infrastructure-as-code: version them, review changes, and avoid clicking around in the console.

Pricing
Per policy per region per month.

AWS Verified Access

Description
AWS Verified Access provides VPN-less access to internal applications. Each request is evaluated against identity (via an IdP), device posture (via integrations with Jamf, CrowdStrike, Zscaler, and others), and policy context before access is granted, which makes it a practical building block for zero-trust architectures.

Scenario
A company replaces its corporate VPN with Verified Access. An engineer accessing an internal Grafana dashboard is authenticated through Entra ID, has their device posture checked by CrowdStrike, and gets a short-lived session, with the whole evaluation logged for audit.

Best Practices

Define access policies per application instead of one broad policy. Sensitive apps get stricter device and identity requirements.
Require both identity and device trust providers. Identity alone misses compromised endpoints.
Send evaluation logs to S3 or OpenSearch so failed access attempts are visible during incident reviews.

Pricing
Per application per hour, plus per GB of data processed.

Amazon VPC Lattice

Description
VPC Lattice is an application networking service that connects services across VPCs and accounts without the usual peering or routing complexity. It includes IAM-based auth policies that gate service-to-service traffic, which is what makes it relevant in a security post.

Scenario
A microservices platform running across three accounts uses VPC Lattice to expose internal services. Auth policies require requests to come from a specific IAM role and carry a particular tag, blocking traffic from any other workload even if they're on the same network.

Best Practices

Treat VPC Lattice auth policies as part of your security model, not just networking config.
Combine with Verified Access for the user-to-service hop. Lattice handles service-to-service.
Share service networks through RAM rather than rebuilding per account.

Pricing
Per service per hour, per request, and per GB processed.

Threat Detection & Monitoring

AWS CloudTrail

Description
CloudTrail records API calls and management events across an AWS account. It's the foundation for auditing, forensics, and most compliance work.

Scenario
Someone accidentally makes an S3 bucket public. CloudTrail captures the PutBucketPolicy call, including the user identity, source IP, and timestamp, which is exactly what the security team needs to investigate and reverse it.

Best Practices

Set up an organization trail so every account is covered, including new ones.
Send logs to a dedicated logging account with restricted access. Production teams shouldn't be able to delete their own audit trail.
Turn on CloudTrail Insights for anomaly detection on API call patterns.
Enable data events selectively. They're powerful but can get expensive on busy S3 buckets.

Pricing
One management trail per region is free. Additional trails and data events are billed per 100,000 events.

Amazon GuardDuty

Description
GuardDuty is a managed threat detection service. It analyzes CloudTrail, VPC Flow Logs, DNS logs, EKS audit logs, S3 data events, RDS login activity, and EBS volumes for malware, using a mix of ML and threat intelligence.

Scenario
GuardDuty raises a finding that an EC2 instance is talking to a known crypto-mining domain. An EventBridge rule triggers a Lambda that detaches the instance role, isolates the security group, and creates a snapshot for forensics.

Best Practices

Enable it organization-wide. Turning it on per-account is a recipe for blind spots.
Enable the protection plans that match your stack (EKS, S3, RDS, Malware Protection, Lambda) rather than leaving them off by default.
Suppress known-benign findings instead of ignoring the inbox.

Pricing
Based on volume of logs analyzed and resources protected. Each protection plan adds its own usage charge.

AWS Security Hub

Description
Security Hub aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Config, and dozens of partner products into a single place. It's split into Security Hub CSPM (the posture-management piece) and the broader Security Hub experience that consolidates detection findings.

Scenario
A compliance lead enables the AWS Foundational Security Best Practices and CIS standards in Security Hub CSPM. The dashboard immediately surfaces unencrypted S3 buckets, missing CloudTrail trails, and overly permissive security groups across every account.

Best Practices

Enable the standards that match the company's compliance scope. Don't enable all of them and drown in noise.
Use cross-account aggregation so one delegated administrator account holds the full picture.
Set up automated remediation for the highest-frequency findings (public S3, unencrypted volumes, etc.).

Pricing
Per finding ingested and per compliance check evaluated.

Amazon Detective

Description
Detective automatically pulls in CloudTrail, VPC Flow Logs, GuardDuty findings, and EKS audit logs, then builds a behavior graph you can pivot through during an investigation.

Scenario
A GuardDuty finding suggests a compromised IAM access key. Detective shows the affected role's activity over the past weeks, the resources it touched, and other identities behaving similarly, all without writing custom queries.

Best Practices

Enable Detective in the same accounts where GuardDuty is on. The two pair naturally.
Treat it as an investigation tool, not a real-time alerting system.
Default 12-month data retention is usually worth keeping for incident postmortems.

Pricing
Per GB of data ingested per month.

Amazon Inspector

Description
Inspector continuously scans EC2 instances, container images in ECR, and Lambda functions for known CVEs and unintended network exposure. Findings are scored using a contextual risk model.

Scenario
Inspector flags an outdated OpenSSL package on a running EC2 instance. The finding flows into Security Hub, opens a ticket in Jira, and gets patched in the next deployment cycle.

Best Practices

Enable it across the organization so new resources are covered automatically.
Pipe findings into the team's existing ticketing flow. Security tools that don't connect to engineering workflows tend to be ignored.
Use tags to exclude short-lived resources where scanning isn't useful.

Pricing
Per resource scanned per month.

Amazon Security Lake

Description
Security Lake centralizes security data from AWS and third-party sources into a customer-owned S3 data lake, normalized to the OCSF schema. Athena, OpenSearch, and most SIEMs can query it directly.

Scenario
A SOC pulls GuardDuty, CloudTrail, Route 53 logs, and EDR alerts into Security Lake, then runs cross-source Athena queries to correlate suspicious DNS lookups with API activity.

Best Practices

Define lifecycle policies up front. Security data accumulates fast.
Subscribe consumers (Athena, OpenSearch, SIEM) per data type rather than giving everyone access to everything.
Use OCSF normalization to your advantage when writing detections. Queries port between sources much more easily.

Pricing
Per GB ingested and per GB normalized. Underlying S3 storage is billed separately.

AWS Security Incident Response

Description
AWS Security Incident Response is a managed service that combines automation, tooling, and access to AWS Customer Incident Response Team (CIRT) experts to help triage and recover from security events.

Scenario
GuardDuty raises a high-severity finding outside business hours. The service triages it automatically, escalates only what matters, and gives the on-call engineer a direct line to AWS CIRT if expert help is needed.

Best Practices

Don't wait for an incident to set it up. Define runbooks, contacts, and access boundaries while things are calm.
Combine with Step Functions or Systems Manager Automation for repeatable response actions.
Run tabletop exercises at least once a year.

Pricing
Subscription-based. AWS service usage during a response is billed normally.

Application Security

AWS Systems Manager

Description
AWS Systems Manager is broad, but a few of its tools are core to workload security: Session Manager replaces SSH bastions with auditable, port-less access to instances; Patch Manager automates OS and application patching; Parameter Store holds configuration values and secrets, with SecureString parameters encrypted by KMS.

Scenario
A company removes inbound port 22 from every EC2 security group. Engineers connect through Session Manager instead, with every session logged to S3 and CloudWatch. Patch Manager runs weekly inside a maintenance window, and compliance data flows into Security Hub so unpatched fleets are visible at the org level.

Best Practices

Use Session Manager instead of SSH bastions. Stream session logs to S3 with object lock and to CloudWatch for real-time review.
Define custom patch baselines per OS, with auto-approval after a short test window for security and critical patches.
Store secrets in Parameter Store SecureString (with a customer-managed KMS key) for low-volume config secrets. Use Secrets Manager for credentials that need rotation.

Pricing
Session Manager and Parameter Store standard parameters are free. Advanced parameters, Patch Manager on hybrid nodes, and other features have their own usage charges.

AWS Signer

Description
AWS Signer provides managed code signing for Lambda, container images, and IoT firmware. Signed artifacts can be verified at deploy time or runtime.

Scenario
A CI/CD pipeline signs every Lambda deployment package with Signer. Lambda is configured to reject unsigned or tampered packages, so a malicious push to a build artifact bucket can't quietly become production code.

Best Practices

Make signing part of the pipeline, not a manual step.
Protect signing profiles with KMS and tight IAM.
Only sign artifacts that have actually passed tests and security checks.

Pricing
Per signing job.

AWS Security Agent

Description
AWS Security Agent, which went GA in April 2026, is an AI-driven security agent that performs continuous, context-aware penetration testing across cloud, multicloud, and on-prem environments. It's designed to behave like a human pentester rather than a static scanner.

Scenario
The agent runs continuously against a staging environment, finding a chain that combines an exposed metadata endpoint with a permissive IAM role into a privilege escalation path. It writes up the finding with reproduction steps, and the team fixes the chain before it reaches production.

Best Practices

Start in non-production to calibrate noise and false positives.
Connect findings to your existing vulnerability management workflow.
Treat it as a complement to Inspector and traditional SAST/DAST, not a replacement.

Pricing
Based on scope and scan frequency.

Amazon Verified Permissions

Description
Verified Permissions is a managed authorization service based on the Cedar policy language. It centralizes fine-grained permission decisions for application users, separate from IAM (which governs AWS resources).

Scenario
A banking app needs to decide whether a given user can view, edit, or close a specific account. Instead of scattering if user.role == "admin" checks throughout the codebase, the app calls Verified Permissions with the request context and gets a clean allow/deny back.

Best Practices

Keep policies in version control alongside code. Cedar is text and reviews well in pull requests.
Model policies on real business rules, not just technical roles.
Use Cognito or your IdP for authentication and Verified Permissions for the decisions that follow.

Pricing
Per authorization request.

Compliance & Governance

AWS Config

Description
Config records the configuration state of AWS resources over time and continuously evaluates them against rules. It's the backbone of most CSPM and compliance automation.

Scenario
A Config rule detects an S3 bucket that just had BlockPublicAccess disabled. An automatic remediation Lambda re-enables the setting and notifies the owning team via SNS.

Best Practices

Enable it in every account through Organizations and aggregate findings centrally.
Use Conformance Packs for frameworks like CIS, NIST, or PCI rather than building rules from scratch.
Be selective about which resource types you record. Recording everything in a busy account adds up quickly.

Pricing
Per configuration item recorded and per rule evaluation.

AWS Audit Manager

Description
Audit Manager automates evidence collection for compliance frameworks like SOC 2, ISO 27001, HIPAA, and PCI DSS. It maps AWS resource data to controls so audit prep is mostly continuous instead of a quarterly fire drill.

Scenario
A compliance officer creates an ISO 27001 assessment. Audit Manager pulls encryption settings, IAM data, and CloudTrail logs into structured evidence that's ready for the auditor, with no manual screenshots required.

Best Practices

Use prebuilt frameworks and customize them. Don't start from a blank page.
Assign control owners explicitly, otherwise everything ends up as "the security team's problem."
Review collected evidence in advance of audits, not the night before.

Pricing
Per active assessment per month.

AWS Artifact

Description
Artifact is the self-service portal for AWS's own compliance reports (SOC 1/2/3, ISO certifications, PCI attestations, and similar) plus customer-facing agreements like the BAA.

Scenario
A new enterprise customer asks for AWS's PCI DSS Attestation of Compliance during procurement. The security team pulls the latest report from Artifact instead of opening a support case.

Best Practices

Refresh reports each audit cycle so you're not handing out stale documents.
Restrict Artifact access to people who actually need it.

Pricing
Free.

This post covers all AWS security-related services as of April 2026.

How to create Root and Intermediate CA in AWS ACM Private CA to issue private certificates

Matheus Almeida Costa — Mon, 06 May 2024 02:20:22 +0000

The purpose of this post is to show how to create an external root CA and an intermediate CA using AWS Private CA to be able to issue private certificates in AWS.

To generate the certificates, you will need to use the openssl tool, if it is not installed, use the following command to install:

sudo apt install openssl
# or
sudo yum install openssl

Create a local environment for creating the certificate components:

mkdir ca
touch ca/root-openssl.cnf
touch ca/intermediate-openssl.cnf
touch ca/intermediate-request.csr
cd ca

Create external root certificate

First, we must create the custom openssl configuration file to generate the certificate with the appropriate information and the extensions.

The extensions will define the usefulness of the certificate, for more information about these extensions I recommend reading the official openssl documentation.

1. Fill the `root-openssl.cnf` file with the content:

[ req ]
distinguished_name              = req_distinguished_name
policy                          = policy_match
x509_extensions                 = v3_ca

[ policy_match ]
countryName                     = optional
stateOrProvinceName             = optional
organizationName                = optional
organizationalUnitName          = optional
commonName                      = supplied
emailAddress                    = optional

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = BR
countryName_min                 = 2
countryName_max                 = 2
stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = State
localityName                    = Locality Name (eg, city)
localityName_default            = City
0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Organization
organizationalUnitName          = Organizational Unit Name (eg, section)
organizationalUnitName_default  = Organizational Unit
commonName                      = Common Name (eg, your name or your server hostname)
commonName_max                  = 64
emailAddress                    = Email Address
emailAddress_max                = 64

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical,CA:true
keyUsage = critical,keyCertSign,digitalSignature,cRLSign

2. Generate password to encrypt private key

openssl rand -base64 32 > root-password-encrypted.txt

The command will generate 32 random characters to create a password that will be used to encrypt the private key.

3. Generate the encrypted private key

openssl genrsa -aes256 -out root-encrypted.key -passout file:root-password-encrypted.txt 4096

The command will generate a 4096-bit encrypted RSA private key using the AES256 encryption algorithm.

4. Generate the root CA certificate

openssl req -new -x509 -days 7300 -config root-openssl.cnf -key root-encrypted.key -passin file:root-password-encrypted.txt -out root-certificate.pem

The command will generate the self-signed root certificate based on the decrypted private key with an expiration time of 20 years (7300 days).

When executing the command, you will be asked to fill in the certificate information such as CN, OU, etc.

We can use the command below to view the certificate content in plain text:

openssl x509 -in root-certificate.pem -text -noout

The output of this command will look like:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            70:5a:46:4a:85:a6:20:51:4b:21:47:dc:1e:4a:d5:98:a9:c6:4b:d2
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = BR, ST = Minas Gerais, L = Belo Horizonte, O = Me, OU = Me, CN = Root CA
        Validity
            Not Before: May  5 19:05:30 2024 GMT
            Not After : Apr 30 19:05:30 2044 GMT
        Subject: C = BR, ST = Minas Gerais, L = Belo Horizonte, O = Me, OU = Me, CN = Root CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:c4:04:99:9e:f9:aa:13:02:b5:8e:19:49:44:77:
                    8c:4d:89:c6:0b:86:6b:6e:51:d7:0b:38:e2:69:aa:
                    f2:2c:ff:21:fd:b1:8b:f2:65:d9:0c:69:a2:f6:b0:
                    53:7c:92:9a:6d:ed:8a:3d:ce:6a:9d:2f:92:c4:17:
                    df:83:ef:a1:37:4d:c0:22:bd:85:55:7a:bd:81:a7:
                    02:31:50:08:49:ec:40:00:46:3c:16:ed:54:d8:9e:
                    db:9b:03:d8:75:e9:0d:54:81:da:de:98:87:aa:6c:
                    87:b8:fe:98:5f:d8:8d:22:a1:86:3d:03:ad:32:3d:
                    61:8e:bb:32:75:78:2a:e8:a7:4a:27:93:2b:09:de:
                    0a:f5:e2:4f:ae:d1:88:0e:11:42:82:da:31:ab:4c:
                    45:db:a6:60:c8:54:a0:6b:79:79:77:73:ad:e4:79:
                    7e:66:58:eb:a9:eb:9a:28:89:bf:85:76:93:42:53:
                    8c:f9:8b:d3:a5:88:aa:db:d9:ab:b6:82:76:f9:fd:
                    76:06:17:41:16:de:83:94:60:5c:d7:96:cd:87:76:
                    20:22:52:e1:6b:dc:f6:d1:b5:76:b3:01:03:7c:a0:
                    36:d4:d1:5b:e8:14:1a:60:e2:26:71:89:fc:aa:c8:
                    d9:25:66:0e:72:7b:5a:5d:02:86:11:05:44:0f:d2:
                    09:8e:51:34:0d:85:58:e2:e6:9e:ad:4e:04:1f:c0:
                    8b:0a:44:9a:b0:73:a2:0c:fc:1c:61:51:04:70:47:
                    7f:d2:d3:bd:b1:ce:8f:26:63:9c:63:8a:73:6a:e4:
                    7b:29:19:b6:1f:e1:3e:18:a0:a3:c9:75:46:06:f0:
                    06:85:e0:4d:87:03:84:b1:11:ba:c0:50:f9:ac:dd:
                    29:ff:c2:94:c5:59:02:61:37:c1:f2:0c:79:5d:ef:
                    96:7d:a8:ab:e3:c8:94:05:a1:e0:19:4a:3b:ad:37:
                    db:02:51:39:fa:0d:96:c3:88:d7:98:9c:6d:5e:62:
                    11:4f:44:58:26:1b:3c:5c:56:58:b4:f2:65:08:f4:
                    02:b8:11:44:76:01:62:b7:76:e7:fd:de:f4:3f:c9:
                    02:1f:e1:95:71:03:12:26:d0:78:23:0c:53:35:1d:
                    fd:9b:45:37:8e:46:96:f5:66:d4:a4:b5:36:79:d6:
                    50:0c:f1:e3:89:b4:79:32:09:5e:11:72:5c:65:34:
                    6c:9c:a3:45:8a:a7:04:6f:c7:88:d8:ac:93:ec:e9:
                    57:62:a3:9a:de:43:d9:72:63:40:c1:7b:dc:ba:cf:
                    2f:35:db:70:68:ed:1c:c6:78:89:8b:f4:29:da:e4:
                    79:4a:27:38:71:d8:61:4a:f9:dd:5f:8f:33:45:f4:
                    40:20:bd
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                61:51:2D:F8:F0:95:C5:FF:FE:96:A8:2C:E0:85:ED:58:E5:7F:0A:84
            X509v3 Authority Key Identifier:
                keyid:61:51:2D:F8:F0:95:C5:FF:FE:96:A8:2C:E0:85:ED:58:E5:7F:0A:84
X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
         41:91:9e:85:54:bd:44:49:86:94:4c:d4:fb:8b:9e:c3:32:4f:
         6d:a3:8f:ea:e4:0f:b0:a2:97:24:56:64:3a:e6:99:15:2f:31:
         96:6c:ed:6f:cf:0a:8d:f8:1c:38:db:41:86:64:22:52:19:fd:
         3b:ff:22:92:37:f8:05:6e:0a:7c:f2:4b:ba:4c:5f:bf:5b:18:
         8f:f5:38:0c:22:49:15:de:17:99:e1:c5:69:3a:0f:d9:18:4d:
         c0:c5:6e:ff:32:35:df:e1:7e:c1:e7:0f:7f:b6:ed:a6:e2:0d:
         2f:cd:29:65:14:94:3d:90:79:e5:a7:3e:93:a6:d4:92:2a:b6:
         62:9f:41:20:ed:23:80:28:3d:80:cd:d4:47:bd:06:d3:6e:35:
         c9:28:6e:21:87:c7:72:39:c4:1c:66:fa:21:c2:73:f6:dd:ba:
         16:99:84:11:fb:91:f0:40:17:38:5a:24:c1:d2:2d:8d:be:76:
         34:05:95:f0:f3:bf:b2:5b:26:05:d1:28:5f:b8:e2:cb:db:d7:
         79:29:fe:8e:c5:4e:ac:97:55:f0:fd:37:42:f3:f0:23:27:f9:
         24:b4:92:f0:d0:23:63:10:52:82:55:61:fe:7a:c4:5f:5b:a8:
         7c:88:16:e2:8e:f1:72:bf:56:8b:23:c4:93:5b:3b:4b:d5:e9:
         e1:f4:bb:26:d4:2c:32:7c:f7:6a:a9:f3:42:21:a3:f4:5b:d3:
         f1:59:74:67:13:59:e6:81:3c:88:a2:2a:3a:25:b3:df:b2:b9:
         fd:b3:95:36:f4:18:bf:a1:51:b6:1d:c8:03:cc:a2:e6:2b:99:
         bb:36:68:48:88:96:31:f0:db:7f:f0:48:57:da:bc:dd:f4:f6:
         53:1b:57:7a:5f:16:ab:1b:f5:ff:a0:96:30:5f:8d:57:b5:b0:
         7c:f2:a2:40:27:6d:e6:20:5f:13:79:3c:5b:ac:5d:78:40:59:
         24:e2:91:5f:ac:e1:f2:c0:b7:87:b7:d0:66:78:06:6e:1b:77:
         b3:64:2d:62:14:e1:ec:cf:c3:2a:cb:38:08:87:04:11:ca:03:
         e6:a8:e1:4e:c4:13:ad:9b:ed:15:80:58:44:81:50:17:cf:ae:
         84:32:0c:b3:fc:89:93:db:9c:a1:56:7c:a0:5a:f9:37:7e:a0:
         81:dd:48:b4:a4:40:25:95:17:f3:00:0f:72:4d:9f:ca:9e:e0:
         c0:a1:d4:58:67:21:11:29:4c:97:0d:c6:38:db:c5:f8:80:98:
         1b:77:12:7c:7e:0c:bc:cc:11:d7:79:7e:45:d5:69:ae:5c:6d:
         a6:8a:a9:6c:c2:22:90:0d:74:a4:c5:af:56:72:cd:46:38:40:
         32:a9:05:29:5b:28:b9:fd

Create Intermediate Certificate in AWS Private CA

Now that we have our external root CA, the idea is to use it to sign the intermediate (subordinate) CA that we will create in AWS Private CA, this intermediate CA will be responsible for issuing the certificates for end use.

Note 1: Creating a CA on AWS has a cost of 400 dollars per month, but for the first CA the cost is minimal in the first month.

Note 2: The CA's private key is only stored in AWS, which is a security advantage as there is no risk of it being leaked and having to be revoked, on the other hand there is no way to export it .

To generate an intermediate CA, you must first generate your certificate signing request (CSR) so that it can be signed by the root CA.

In AWS Private CA we select the subordinate type and fill in the certificate information, just as we did to generate the root CA, we normally fill in the same information for both with the exception of the Common Name (CN) field.

In addition, we must select the type of private key algorithm (RSA or ECDSA) and optionally the certificate revocation configuration via CRL or OCSP.

Once this is done, it will generate a new arn for this AWS resource and will be in Pending Certificate status, because the request to generate the certificate (CSR) has been created but has not yet been signed by a root CA to issue the certificate for this intermediate CA.

To sign the CSR with our external root, we must select the resource and go to the "Install CA certificate" option.

We then select whether this intermediate CA will be signed by a CA that already exists in the AWS PCA or whether it will be signed by an external CA, in our case it will be an external CA.

AWS will make a certificate signing request (CSR) available.

1. Copy the CSR content provided by AWS to the `intermediate-request.csr` file

2. Fill the `intermediate-openssl.cnf` file with the following content:

[ intermediate_ca_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, issuer:always
basicConstraints = critical,CA:true,pathlen:0
keyUsage = critical,keyCertSign,digitalSignature,cRLSign

3. Generate the intermediate CA certificate

openssl x509 -req -days 3650 -extfile intermediate-openssl.cnf -extensions intermediate_ca_ext -in intermediate-request.csr -CA root-certificate.pem -CAkey root-encrypted.key -passin file:root-password-encrypted.txt -CAcreateserial -out intermediate-certificate.pem

To issue the certificate, we are based on the signature request (CSR) information made available by AWS intermediate-request.csr signed by the root CA root-certificate.pem and its encrypted private key root-encrypted.key along with the password to decrypt it root-password-encrypted.txt.

We also pass the extension settings for this intermediate certificate based on the intermediate_ca_ext profile in the intermediate-openssl.cnf file, in addition to the number of days that the certificate will be valid, in this case 10 years (3650 days).

Also set the random serial number creation using the -CAcreateserial argument and thus generate the intermediate CA certificate intermediate-certificate.pem.

With the certificate generated, simply import the respective fields directly into AWS Private CA:

Certificate body: Certificate of the intermediate CA intermediate-certificate.pem.
Certificate chain: Root CA certificate root-certificate.pem.

With the certificates imported, select the "Install CA" option.

This way we will have a certification authority (CA) chain to issue private certificates on AWS via ACM.

How to restrict default access to KMS via key policy with Terraform

Matheus Almeida Costa — Sun, 31 Mar 2024 23:49:59 +0000

The objective of this post is to implement KMS key access security for AWS Identity and Access Management (IAM) identities by changing the default policy when provisioning the resource with Terraform.

This is a practical example, so I first recommend recommend read this post to better understand the objective of restricted key policy.

Note: This post demonstrates the AWS account ID 123456789012 with existing role named TERRAFORM, ADMIN and ANALYST. These values must be replaced for your environment.

The default KMS key policy contains the following statement:

{
    "Sid": "Enable IAM User Permissions",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
    },
    "Action": "kms:*",
    "Resource": "*"
}

By default KMS policy allow caller's account to use IAM policy to control key access.

The Effect and Principal elements do not refer to the AWS root user account. Instead, it allows any principal in AWS account 123456789012 to have root access to the KMS key as long as you have attached the required permissions to the IAM entity.

The created terraform blueprint will come with the following custom policy by default:

{
    "Sid": "Enable root access and prevent permission delegation",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
    },
    "Action": "kms:*",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:PrincipalType": "Account"
        }
    }
},
{
    "Sid": "Allow access for key administrators",
    "Effect": "Allow",
    "Principal": {
        "AWS": [
            "arn:aws:iam::123456789012:role/TERRAFORM",
            "arn:aws:iam::123456789012:role/ADMIN"
        ]
    },
    "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:TagResource",
        "kms:UntagResource",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
    ],
    "Resource": "*"
},
{
    "Sid": "Enable read access to all identities",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
    },
    "Action": [
        "kms:List*",
        "kms:Get*",
        "kms:Describe*"
    ],
    "Resource": "*"
}

The key policy allows the following permissions:

First statement: The AWS root user account has full access to the key.
Second statement: The principals role ADMIN and TERRAFORM has access to perform management operations on the key.
Third statement All account principals are able to read the key.

Terraform restrict KMS blueprint

1. `versions.tf`

Define Terraform versions and providers.

terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0.0"
    }
  }
}

2. `main.tf`

Use the AWS provider in a region and create the KMS resource with your configuration parameters including your policy.

provider "aws" {
  region = "us-east-1"
}

resource "aws_kms_key" "this" {
  description = "Restricted kms key policy example"
  policy = data.aws_iam_policy_document.restricted_key_policy.json
}

3. `variables.tf`

Defines the variable that will be responsible for the value of the new desired policy to be attached to the KMS policy.

variable key_policy {
  description = "key policy"
  type = list(object({
    sid           = optional(string)
    effect        = string
    actions       = list(string)
    resources     = list(string)
    principals  = optional(list(object({
      type        = string
      identifiers = list(string)
    })))
    conditions = optional(list(object({
      test = optional(string),
      variable = string,
      values = list(string)
    })))
  }))
  default = []
}

4. `policy.json`

Create a rule with the new default policy based on the current account id and merge it with the custom policy passed by variable.

data "aws_caller_identity" "current" {}

locals {
  aws_account_id = data.aws_caller_identity.current.account_id
  # Default key policy to restrict AWS access
  default_key_policy = [
    {
      sid    = "Enable root access and prevent permission delegation"
      effect = "Allow"
      principals = [
        {
          type        = "AWS"
          identifiers = [local.aws_account_id]
        },
      ]
      actions   = ["kms:*"]
      resources = ["*"]
      conditions = [
        {
          test     = "StringEquals"
          variable = "aws:PrincipalType"
          values   = ["Account"]
        },
      ]
    },
    {
      sid    = "Allow access for key administrators"
      effect = "Allow"
      principals = [
        {
          type = "AWS"
          identifiers = [
            "arn:aws:iam::${local.aws_account_id}:role/TERRAFORM",
            "arn:aws:iam::${local.aws_account_id}:role/ADMIN"
          ]
        },
      ]
      actions   = [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:TagResource",
        "kms:UntagResource",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
    ],
      resources = ["*"]
    },
    {
      sid    = "Enable read access to all identities"
      effect = "Allow"
      principals = [
        {
          type        = "AWS"
          identifiers = [local.aws_account_id]
        },
      ]
      actions = [
        "kms:List*",
        "kms:Describe*",
        "kms:Get*",
      ]
      resources = ["*"]
    }
  ]
}

# Merge the default key policy with the new key policy
data "aws_iam_policy_document" "restricted_key_policy" {
  dynamic "statement" {
    for_each = concat(local.default_key_policy, var.key_policy)
    content {
      sid       = statement.value.sid
      effect    = statement.value.effect
      actions   = statement.value.actions
      resources = statement.value.resources

      dynamic "principals" {
        for_each = try(statement.value.principals, null) == null ? [] : statement.value.principals
        content {
          type        = principals.value.type
          identifiers = principals.value.identifiers
        }
      }

      dynamic "condition" {
        for_each = try(statement.value.conditions, null) == null ? [] : statement.value.conditions
        content {
          test     = condition.value.test
          variable = condition.value.variable
          values   = condition.value.values
        }
      }
    }
  }
}

5. `outputs.tf`

Defines the output of the kms arn value after its creation.

output arn {
  value       = aws_kms_key.this.arn
  description = "ARN KMS key"
}

6. `terraform.tfvars`

Enter a custom policy for the purpose of creating the KMS, in this case I will create one just to allow the use of actions for a specific role.

key_policy = [
    {
      sid       = "Allow use of the key"
      effect    = "Allow"
      principals = [
        {
          type        = "AWS"
          identifiers = ["arn:aws:iam::123456789012:role/ANALYST"]
        },
      ]
      actions   = [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
        ]
      resources = ["*"]
    }
]

After apply, as a result you will always have a restricted KMS with the possibility of customizing it by changing the value of the key_policy variable, making it not only a secure blueprint but also scalable.

Check out the full code on GitHub!.

How to restrict default access to KMS via key policy

Matheus Almeida Costa — Sun, 31 Mar 2024 23:49:31 +0000

About AWS Key Management Service

AWS Key Management Service (AWS KMS) is a managed service that makes it easy for you to create and control the cryptographic keys that are used to protect your data.

The KMS key policy allows IAM identities in the account to access the KMS key with IAM permissions.

The objective of this article is to implement secure of KMS key from access by AWS Identity and Access Management (IAM) identities.

Note: This article demonstrates the AWS account ID 123456789012 with existing role named TERRAFORM, ADMIN and ANALYST. These values must be replaced for your environment.

The default KMS Authorization behaviour

The default KMS key policy contains the following statement:

{
    "Sid": "Enable IAM User Permissions",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
    },
    "Action": "kms:*",
    "Resource": "*"
}

By default KMS policy allow caller's account to use IAM policy to control key access.

Implement secure KMS policy

Example of restricted key policy:

{
    "Sid": "Enable root access and prevent permission delegation",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
    },
    "Action": "kms:*",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:PrincipalType": "Account"
        }
    }
},
{
    "Sid": "Allow access for key administrators",
    "Effect": "Allow",
    "Principal": {
        "AWS": [
            "arn:aws:iam::123456789012:role/TERRAFORM",
            "arn:aws:iam::123456789012:role/ADMIN"
        ]
    },
    "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:TagResource",
        "kms:UntagResource",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
    ],
    "Resource": "*"
},
{
    "Sid": "Enable read access to all identities",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
    },
    "Action": [
        "kms:List*",
        "kms:Get*",
        "kms:Describe*"
    ],
    "Resource": "*"
}

The key policy allows the following permissions:

First statement: The AWS root user account has full access to the key.
Second statement: The principals role ADMIN and TERRAFORM has access to perform management operations on the key.
Third statement All account principals are able to read the key.

This way we can ensure that the root user account manages the key and prevents IAM entities from accessing the KMS key.

You can also allow IAM users or roles to use the key for cryptographic operations and with other AWS services by appending other statements like this:

{
    "Sid": "Allow analyst role use the key",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/ANALYST"
    },
    "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
    ],
    "Resource": "*"
},
{
    "Sid": "Allow sms service use the key",
    "Effect": "Allow",
    "Principal": {
        "Service": "sns.amazonaws.com"
    },
    "Action": [
        "kms:GenerateDataKey*",
        "kms:Decrypt"
    ],
    "Resource": "*"
}

So if the KMS is configured in this way, its access will be restricted and only those identities directly specified in the key policy will have access.

Check out the completed code example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable root access and prevent permission delegation",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:root"
            },
            "Action": "kms:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalType": "Account"
                }
            }
        },
        {
            "Sid": "Allow access for key administrators",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::123456789012:role/TERRAFORM",
                    "arn:aws:iam::123456789012:role/ADMIN"
                ]
            },
            "Action": [
                "kms:Create*",
                "kms:Describe*",
                "kms:Enable*",
                "kms:List*",
                "kms:Put*",
                "kms:Update*",
                "kms:Revoke*",
                "kms:Disable*",
                "kms:Get*",
                "kms:Delete*",
                "kms:TagResource",
                "kms:UntagResource",
                "kms:ScheduleKeyDeletion",
                "kms:CancelKeyDeletion"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Enable read access to all identities",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:root"
            },
            "Action": [
                "kms:List*",
                "kms:Get*",
                "kms:Describe*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/ANALYST"
            },
            "Action": [
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:Encrypt",
                "kms:DescribeKey",
                "kms:Decrypt"
            ],
            "Resource": "*"
        }
    ]
}

How to track Cognito Identity Pool IAM roles API calls via Athena

Matheus Almeida Costa — Wed, 21 Feb 2024 02:17:32 +0000

About Cloudtrail

AWS CloudTrail is a service that records AWS API calls and events for AWS accounts. This service can save logs as JSON text files in compressed gzip format (*.json.gzip) in S3 Bucket.

About Athena

AWS Athena is an interactive analytics service for large-scale data analysis, offering users the ability to perform SQL queries on data stored in S3 Bucket quickly, flexibly, and cost-effectively.

How these services work together

Through AWS CloudTrail we can monitor and audit all activities carried out in your AWS account via Athena

The purpose of the article is to demonstrate a way to perform Athena SQL query to:

Check if the Cognito Identity Pool is being used
Check which API calls to AWS are being made from temporary cognito IAM roles credentials

Steps

Create a trail.
Create a Athena database and configure location query result.
Run a Athena query to create table.
Run a Athena query to obtain the trail logs.

Athena Queries

To track Cognito roles API calls, we will use the table creation query from the official AWS documentation with an update.

To be able to query the Cognito-role event you must change the CloudTrail table schema so that the webIdFederationData column has the following definition:

webIdFederationData: STRUCT<
                federatedProvider: STRING,
                attributes: map<string,string>>

Example Athena query to create table:

CREATE EXTERNAL TABLE cloudtrail_logs_pp(
    eventVersion STRING,
    userIdentity STRUCT<
        type: STRING,
        principalId: STRING,
        arn: STRING,
        accountId: STRING,
        invokedBy: STRING,
        accessKeyId: STRING,
        userName: STRING,
        sessionContext: STRUCT<
            attributes: STRUCT<
                mfaAuthenticated: STRING,
                creationDate: STRING>,
            sessionIssuer: STRUCT<
                type: STRING,
                principalId: STRING,
                arn: STRING,
                accountId: STRING,
                userName: STRING>,
            ec2RoleDelivery:string,
            webIdFederationData:map<string,string>
        >
    >,
    eventTime STRING,
    eventSource STRING,
    eventName STRING,
    awsRegion STRING,
    sourceIpAddress STRING,
    userAgent STRING,
    errorCode STRING,
    errorMessage STRING,
    requestparameters STRING,
    responseelements STRING,
    additionaleventdata STRING,
    requestId STRING,
    eventId STRING,
    readOnly STRING,
    resources ARRAY<STRUCT<
        arn: STRING,
        accountId: STRING,
        type: STRING>>,
    eventType STRING,
    apiVersion STRING,
    recipientAccountId STRING,
    serviceEventDetails STRING,
    sharedEventID STRING,
    vpcendpointid STRING,
    eventCategory STRING,
    tlsDetails struct<
        tlsVersion:string,
        cipherSuite:string,
        clientProvidedHostHeader:string>
  )
PARTITIONED BY (
   `timestamp` string)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION
  's3://bucket-trail/AWSLogs/account-id/CloudTrail/aws-region'
TBLPROPERTIES (
  'projection.enabled'='true', 
  'projection.timestamp.format'='yyyy/MM/dd', 
  'projection.timestamp.interval'='1', 
  'projection.timestamp.interval.unit'='DAYS', 
  'projection.timestamp.range'='2020/01/01,NOW', 
  'projection.timestamp.type'='date', 
  'storage.location.template'='s3://bucket-trail/AWSLogs/account-id/CloudTrail/aws-region/${timestamp}')

Values that should be overridden for your environment:

LOCATION
- bucket-trail: Name of the S3 bucket where the trail log is saved.
- 012345678912: AWS Account ID.
- us-east-1: AWS region.
projection.timestamp.range
- '2024/02/01,NOW': Datetime range to track the trail logs.
storage.location.template
- bucket-trail: Name of the S3 bucket where the trail log is saved.
- 012345678912: AWS Account ID.
- us-east-1: AWS region.

Run a Athena query to obtain the trail logs

SELECT
 useridentity.arn,
 eventname,
 sourceipaddress,
 eventtime
FROM cloudtrail_logs
WHERE userIdentity.sessionContext.sessionIssuer.arn = 'arn:aws:iam::123456789012:role/ROLE-UNAUTHENTICATED'
LIMIT 100

Values that should be overridden for your environment:

WHERE userIdentity.sessionContext.sessionIssuer.arn = 'arn:aws:iam::123456789012:role/ROLE-UNAUTHENTICATED'
- 'arn:aws:iam::123456789012:role/ROLE-UNAUTHENTICATED': Cognito Identity Pool role arn.

How to track Cloudtrail API calls from all Organizations AWS accounts using Athena

Matheus Almeida Costa — Wed, 21 Feb 2024 02:17:21 +0000

About Cloudtrail

AWS CloudTrail is a service that records AWS API calls and events for AWS accounts. This service can save logs as JSON text files in compressed gzip format (*.json.gzip) in S3 Bucket.

About Athena

AWS Athena is an interactive analytics service for large-scale data analysis, offering users the ability to perform SQL queries on data stored in S3 Bucket quickly, flexibly, and cost-effectively.

About Organizations

AWS Organizations is a service that allows companies to manage multiple AWS accounts in a single hierarchical structure. It consolidates billing for these accounts, also helps automate account and resource management, as well as the enforcement of security and compliance policies across all accounts.

How these services work together

By integrating AWS Organizations with AWS CloudTrail, we can monitor and audit all activities performed in your AWS accounts via Athena.

The purpose of the article is to demonstrate a way to perform SQL query in athena to search for information from all AWS accounts and regions of an Organizations, instead of performing queries by region and specific AWS account.

Note: queries will have lower performance due to the larger amount of data, but depending on the occasion this may be useful.

Steps

Create a Organization trail.
Create a Athena database and configure location query result.
Run a Athena query to create table.
Run a Athena query to obtain the trail logs.

3 - Run a Athena query to create table

Values that should be overridden for your environment:

LOCATION
- bucket-trail: Name of the S3 bucket where the trail log is saved.
- o-123456789: Organization ID.
storage.location.template
- bucket-trail: Name of the S3 bucket where the trail log is saved.
- o-123456789: Organization ID.
projection.timestamp.range
- '2024/02/01,NOW': Datetime range to track the trail logs.
projection.accountid.values
- '012345678912,219876543210': AWS accounts IDs to track the trail logs.
projection.region.values
- 'us-east-1,sa-east-1': AWS regions to track the trail logs.

Example Athena query to create table:

CREATE EXTERNAL TABLE cloudtrail_logs_all_accounts(
  eventVersion STRING,
  userIdentity STRUCT<
    type: STRING,
    principalId: STRING,
    arn: STRING,
    accountId: STRING,
    invokedBy: STRING,
    accessKeyId: STRING,
    userName: STRING,
    sessionContext: STRUCT<
      attributes: STRUCT<
        mfaAuthenticated: STRING,
        creationDate: STRING>,
      sessionIssuer: STRUCT<
        type: STRING,
        principalId: STRING,
        arn: STRING,
        accountId: STRING,
        userName: STRING>,
      ec2RoleDelivery:string,
      webIdFederationData: STRUCT<
        federatedProvider: STRING,
        attributes: map<string,string>>
    >
  >,
  eventTime STRING,
  eventSource STRING,
  eventName STRING,
  awsRegion STRING,
  sourceIpAddress STRING,
  userAgent STRING,
  errorCode STRING,
  errorMessage STRING,
  requestparameters STRING,
  responseelements STRING,
  additionaleventdata STRING,
  requestId STRING,
  eventId STRING,
  readOnly STRING,
  resources ARRAY<STRUCT<
    arn: STRING,
    accountId: STRING,
    type: STRING>>,
  eventType STRING,
  apiVersion STRING,
  recipientAccountId STRING,
  serviceEventDetails STRING,
  sharedEventID STRING,
  vpcendpointid STRING,
  tlsDetails struct<
    tlsVersion:string,
    cipherSuite:string,
    clientProvidedHostHeader:string>
)
PARTITIONED BY ( 
  `timestamp` string, 
  `region` string, 
  `accountid` string)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION
  's3://bucket-trail/AWSLogs/o-123456789'
TBLPROPERTIES (
  'storage.location.template'='s3://bucket-trail/AWSLogs/o-123456789/${accountid}/CloudTrail/${region}/${timestamp}', 
  'projection.enabled'='true', 
  'projection.timestamp.type'='date', 
  'projection.timestamp.format'='yyyy/MM/dd', 
  'projection.timestamp.interval'='1', 
  'projection.timestamp.interval.unit'='DAYS', 
  'projection.timestamp.range'='2024/02/01,NOW', 
  'projection.accountid.type'='enum', 
  'projection.accountid.values'='012345678912,219876543210', 
  'projection.region.type'='enum', 
  'projection.region.values'='us-east-1,sa-east-1'
)

Run a Athena query to obtain the trail logs

Values that should be overridden for your environment:

FROM cloudtrail_logs
- cloudtrail_logs: Name of the table created above.
WHERE userIdentity.sessionContext.sessionIssuer.arn = 'arn:aws:iam::012345678912:role/ROLE-NAME'
- 'arn:aws:iam::012345678912:role/ROLE-NAME': Identity arn to track your trail log, be it role or user.

Example Athena query to track identity trail logs:

SELECT *
FROM cloudtrail_logs
WHERE userIdentity.sessionContext.sessionIssuer.arn = 'arn:aws:iam::012345678912:role/ROLE-NAME'

IAM Policy example required to execute the above queries after configuring the log trail and the Athena database:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AthenaRunQuery",
            "Effect": "Allow",
            "Action": [
                "athena:StartQueryExecution",
                "athena:GetQueryExecution",
                "athena:GetQueryResults",
                "athena:StopQueryExecution"
            ],
            "Resource": [
                "arn:aws:athena:us-east-1:012345678912:workgroup/*",
                "arn:aws:athena:us-east-1:012345678912:queryExecution/*"
            ]
        },
        {
            "Sid": "S3BucketLoggingAccess",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads",
                "s3:ListMultipartUploadParts",
                "s3:AbortMultipartUpload",
                "s3:PutObject*"
            ],
            "Resource": [
                "arn:aws:s3:::bucket-query-result",
                "arn:aws:s3:::bucket-query-result/*"
            ]
        },
        {
            "Sid": "S3BucketQueryAccess",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::bucket-trail",
                "arn:aws:s3:::bucket-trail/*"
            ]
        },
        {
            "Sid": "GlueWrite",
            "Effect": "Allow",
            "Action": [
                "glue:CreateTable",
                "glue:DeleteTable",
                "glue:BatchCreatePartition"
            ],
            "Resource": "arn:aws:glue:us-east-1:012345678912:*"
        },
        {
            "Sid": "GlueRead",
            "Action": [
                "glue:GetTable*",
                "glue:List*",
                "glue:GetPartition*",
                "glue:GetDatabase"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:glue:us-east-1:012345678912:*"
        }
    ]
}

Automated way to restrict all inbound and outbound rules from AWS default security groups

Matheus Almeida Costa — Fri, 09 Feb 2024 21:07:35 +0000

For each VPC created in AWS, a default security group is always automatically created, in this security group there is an inbound rule that allows access to all protocols and ports of the security group itself as source and it also has an outbound rule that allows access to all protocols and ports to the internet as source.

Following good security practices, it is not recommended to use default security groups associated with AWS resources, but rather to create custom security groups with least privileges for these resources.

The objective of this post is to present a script to delete all inbound and outbound rules from the default security groups of all VPCs and regions in an AWS account.

This makes the use of default security groups useless and will reduce AWS compliance security alerts for default security group that does not restrict all traffic.

It is important to remove the association of AWS resources with the default security group if used, to find out if it is being used by an AWS resource you can consult the network interfaces according to this post.

To run the code above you need to install python 3 with dependency boto3 and configure your AWS credentials:

Note 1: Default security groups always have the name "default" and it is not possible to create a security group with that same name, so there is no chance of deleting rules from other security groups.

Note 2: In regions used in your AWS account, it may make sense to manually evaluate the update of the default security group via network interfaces, so in this case it is recommended to exclude the elements (regions) from the regions variable array.

Note 3: This will not prevent more non-restricted default security groups from being created, to accomplish this you can add configuration parameters to your infrastructure as code, as this terraform resource.

Forem: Matheus Almeida Costa

How to Ensure Security Tool Connectivity on EC2 Across AWS Accounts with Automated Security Group Compliance

Introduction

Objective

Solution Architecture

Architecture Diagram

Core Components

How It Works

1. AWS account inventory collection

2. Cross-Account Security Group Audit and Remediation

Deployment Steps

1. Create the Prefix List

2. Share the Prefix List Across Accounts

3. Deploy the Cross-Account IAM Role

4. Deploy the Lambda functions

5. Deploy the EventBridge Schedule

Extra: Security by Default with IaC

Example Terraform Configuration

Conclusion

AWS Security Services Overview

AWS Security Services

Identity & Access Management

AWS Identity and Access Management (IAM)

AWS IAM Access Analyzer

AWS IAM Identity Center

AWS Organizations

AWS Resource Access Manager (RAM)

Amazon Cognito

AWS Directory Service

Data Protection

AWS Secrets Manager

AWS Private Certificate Authority (Private CA)

AWS Certificate Manager (ACM)

Amazon Macie

AWS Key Management Service (KMS)

AWS CloudHSM

AWS Payment Cryptography

Network and Application Protection

AWS WAF

AWS Shield

AWS Network Firewall

AWS Firewall Manager

AWS Verified Access

Amazon VPC Lattice

Threat Detection & Monitoring

AWS CloudTrail

Amazon GuardDuty

AWS Security Hub

Amazon Detective

Amazon Inspector

Amazon Security Lake

AWS Security Incident Response

Application Security

AWS Systems Manager

AWS Signer

AWS Security Agent

Amazon Verified Permissions

Compliance & Governance

AWS Config

AWS Audit Manager

AWS Artifact

How to create Root and Intermediate CA in AWS ACM Private CA to issue private certificates

Create external root certificate

1. Fill the root-openssl.cnf file with the content:

2. Generate password to encrypt private key

3. Generate the encrypted private key

4. Generate the root CA certificate

Create Intermediate Certificate in AWS Private CA

1. Copy the CSR content provided by AWS to the intermediate-request.csr file

2. Fill the intermediate-openssl.cnf file with the following content:

3. Generate the intermediate CA certificate

How to restrict default access to KMS via key policy with Terraform

Terraform restrict KMS blueprint

1. versions.tf

2. main.tf

3. variables.tf

4. policy.json

5. outputs.tf

6. terraform.tfvars

How to restrict default access to KMS via key policy

1. Fill the `root-openssl.cnf` file with the content:

1. Copy the CSR content provided by AWS to the `intermediate-request.csr` file

2. Fill the `intermediate-openssl.cnf` file with the following content:

1. `versions.tf`

2. `main.tf`

3. `variables.tf`

4. `policy.json`

5. `outputs.tf`

6. `terraform.tfvars`