DEV Community: 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 reference 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 organized by category with practical examples and common use cases that reflect real-world scenarios:

Identity & Access Management.
Data Protection.
Network Security.
Threat Detection & Monitoring.
Application Security.
Compliance & Governance.

Identity & Access Management

AWS Identity and Access Management (IAM)

Description
IAM defines who can do what in your AWS environment. It provides authentication (via users, roles, and federated identities) and authorization (via policies) for every AWS service.

Scenario
A security team designs IAM roles for developers to deploy Lambda functions only in non-production environments. Each role has a limited set of permissions (using wildcards carefully) and temporary credentials are used instead of long-term access keys.

Best Practices

Apply the principle of least privilege grant only what’s needed.
Replace IAM users with roles and temporary credeBest Practicesntials.
Enforce MFA for all privileged accounts.
Use IAM Access Analyzer to identify unused or overly broad permissions.

Pricing

Free.

AWS IAM Identity Center (AWS SSO)

Description
IAM Identity Center is a centralized access management for all your AWS accounts.
It connects with identity providers like Okta, Azure AD, or Google Workspace.

Scenario
In an enterprise setup, employees log in once using their corporate credentials and can access multiple AWS accounts through the AWS Console Portal, with fine-grained permissions mapped by group (Dev, SecOps, Finance, etc.).

Pricing

Free.

AWS Organizations

Description
AWS Organizations is a centralized way to manage user access across multiple AWS accounts and business applications. It integrates with identity providers (like Okta, Azure AD, or Google Workspace) for single sign-on (SSO).

Scenario
A company with 10 AWS accounts configures IAM Identity Center with Azure AD. Developers log in once with their corporate credentials and access the AWS accounts they’re assigned to, based on group membership.

Best Practices

Use group-based access instead of assigning permissions to individuals.
Map corporate directory groups to AWS accounts and permission sets.
Enable MFA and session timeouts.

Pricing

Free.

AWS Resource Access Manager (RAM)

Description
RAM allows you to securely share AWS resources (like subnets, Transit Gateways, or Route 53 zones) across accounts or within your AWS Organization.

Scenario
A central network account shares a Transit Gateway with multiple VPCs across other accounts, allowing secure and controlled inter-VPC communication.

Best Practices

Share only necessary resources with trusted accounts.
Review resource shares regularly for unused ones.
Use tagging to track ownership and accountability.

Pricing

Free.

Amazon Cognito

Description
Cognito handles authentication and authorization for web and mobile apps, supporting user pools (sign-up/sign-in) and identity pools (federation with social or enterprise IdPs).

Scenario
A startup builds a mobile app where users can sign in using Google or Apple ID. Cognito manages identity federation and issues temporary AWS credentials for accessing backend APIs securely.

Best Practices

Enable MFA and password policies.
Protect access tokens using HTTPS and secure client SDKs.
Use Cognito triggers (Lambda) to validate user data or enforce additional checks.

Pricing

Pay per monthly active user (MAU) and per authentication request.

AWS Directory Service

Description
Directory Service provides managed Microsoft Active Directory (AD) in AWS or integrates AWS resources with your existing on-premises AD.

Scenario
An enterprise migrates its Windows-based workloads to AWS. By deploying AWS Managed Microsoft AD, administrators can apply the same group policies and authentication rules as in their on-premises environment.

Best Practices

Use AWS Managed Microsoft AD when you need full AD capabilities.
Limit domain admin access and use dedicated admin accounts.
Monitor directory logins using CloudWatch or CloudTrail.

Pricing

Charged per directory type and instance hours.

Data Protection

AWS Secrets Manager

Description
AWS Secrets Manager is a managed service for storing, rotating, and retrieving database credentials, API keys, and other secrets securely.

Scenario
Instead of embedding credentials in a Lambda environment variable, the function retrieves the password from Secrets Manager at runtime. Automatic rotation ensures passwords stay up to date.

Best Practices

Enable automatic secret rotation using Lambda.
Restrict IAM access to specific secrets.
Use encryption with KMS for all stored secrets.

Pricing

Per secret stored and per 10,000 API calls.

AWS Private Certificate Authority (CA)

Description
AWS Private Certificate Authority (CA) is a managed service for issuing and managing private SSL/TLS certificates for internal use cases.

Scenario
An enterprise uses Private CA to issue certificates for internal APIs, IoT devices, and internal dashboards eliminating reliance on public certificate providers.

Best Practices

Automate certificate renewal and deployment via ACM integration.
Enforce short certificate lifetimes to reduce exposure risk.
Restrict who can issue certificates with IAM policies.

Pricing

Monthly fee per CA + per certificate issued.

AWS Certificate Manager (ACM)

Description
AWS Certificate Manager (ACM) Simplifies the provisioning, deployment, and renewal of SSL/TLS certificates for AWS resources (ALB, CloudFront, API Gateway, etc.).

Scenario
A website hosted on CloudFront automatically uses ACM-issued certificates to enable HTTPS, with zero manual renewal effort.

Best Practices

Use DNS validation for automation.
Prefer ACM for public-facing endpoints.
Combine with AWS WAF for secure web delivery.

Pricing

Public certificates are free; private ones incur cost via Private CA.

Amazon Macie

Description
Amazon Macie uses machine learning to identify and protect sensitive data (like PII, financial data, or credentials) in Amazon S3.

Scenario
A company stores millions of files in S3. Macie scans the data and alerts the security team when PII is detected in unexpected locations, triggering remediation workflows.

Best Practices

Schedule automatic scans of critical buckets.
Use Macie findings to enforce Config remediation rules.
Integrate with Security Hub for centralized visibility.

Pricing

Per GB of data classified and objects monitored.

AWS Key Management Service (KMS)

Description
AWS KMS manages encryption keys for AWS services and custom applications, allowing encryption at rest and in transit with centralized control.

Scenario
A financial team encrypts S3 and RDS data using customer-managed CMKs, ensuring only specific IAM roles can use them for decryption. CloudTrail logs all KMS usage for auditability.

Best Practices

Use customer-managed CMKs for sensitive data.
Rotate keys automatically.
Enable key usage logging in CloudTrail.
Enforce access policies to prevent key misuse.

Pricing

Per key and per API request (encryption/decryption).

AWS CloudHSM

Description
AWS CloudHSM is a dedicated Hardware Security Module that gives you full control over your cryptographic keys and operations. It’s ideal for compliance-heavy industries.

Scenario
A payments company processes card transactions that must comply with PCI DSS. It uses CloudHSM to generate and store encryption keys in an isolated, FIPS 140-2 Level 3–compliant environment.

Best Practices:

Use CloudHSM when compliance requires exclusive control of keys.
Combine with KMS custom key store if you need hybrid integration.
Plan redundancy HSM clusters span multiple Availability Zones.

Pricing

Hourly cost per HSM instance.

AWS Payment Cryptography

Description
AWS Payment Cryptography provides on-demand cryptographic processing for payment systems, including key management and transaction signing.

Scenario
A fintech uses AWS Payment Cryptography to perform secure PIN generation and key exchange with banks, ensuring compliance with PCI PIN standards.

Best Practices

Use with CloudHSM for regulated workloads.
Restrict access using IAM conditions and audit logs.
Rotate cryptographic keys periodically.

Pricing

Per cryptographic operation and per key.

Network and Application Protection

AWS Web Application Firewall (WAF)

Description
AWS WAF protects web applications from common exploits like SQL injection, cross-site scripting (XSS), and malicious bots. It operates at layer 7 (HTTP/HTTPS) and integrates with CloudFront, API Gateway, and Application Load Balancer.

Scenario
An online retail application exposes an API through API Gateway. AWS WAF inspects incoming traffic and blocks requests containing suspicious patterns (like “UNION SELECT” or script injections), preventing data leaks and service disruptions.

Best Practices

Use AWS Managed Rule Groups to defend against OWASP Top 10 vulnerabilities.
Create rate-based rules to throttle suspicious traffic and prevent brute-force attacks.
Regularly review logs in CloudWatch or Kinesis Firehose for visibility.
Deploy different WAF Web ACLs for staging and production environments.

Pricing

Charged per Web ACL, rule, and number of requests inspected.

AWS Shield

Description
AWS Shield provides managed protection against Distributed Denial of Service (DDoS) attacks. It offers two tiers Shield Standard (automatic and free) and Shield Advanced (enhanced detection and mitigation with 24/7 support).

Scenario
A fintech company hosts its public-facing APIs behind CloudFront. During a DDoS attempt, AWS Shield Advanced automatically detects abnormal spikes in traffic and engages AWS’s DDoS Response Team (DRT) to mitigate the attack while maintaining availability.

Best Practices

Use Shield Advanced for mission-critical workloads (e.g., e-commerce, financial APIs).
Combine with WAF for application-layer defense.
Regularly test DDoS resilience with simulated events.
Monitor metrics in CloudWatch DDoSDashboard.

Pricing

Shield Standard: Free (included by default).
Shield Advanced: Monthly subscription + data transfer usage.

AWS Network Firewall

Description
AWS Network Firewall a managed, scalable firewall that inspects traffic at the VPC level and blocks or allows traffic based on stateful and stateless rules.

Scenario
A large organization builds a central inspection VPC where Network Firewall analyzes all traffic between business units using AWS Transit Gateway. Security teams manage policies globally.

Best Practices

Centralize firewalls in shared network accounts.
Log all traffic to CloudWatch Logs or S3.
Use domain-based and Suricata-compatible rule groups.

Pricing

Per firewall endpoint-hour and GB processed.

AWS Firewall Manager

Description
AWS Firewall Manager is a centralized management for WAF, Shield, and Network Firewall policies across multiple AWS accounts.

Scenario
A security team applies a standard WAF rule set to every CloudFront distribution in the organization using Firewall Manager policies, ensuring consistency across environments.

Best Practices

Integrate with AWS Organizations for unified control.
Tag resources consistently for policy targeting.
Use for compliance enforcement (e.g., mandatory WAF).

Pricing

Per policy per region.

Threat Detection & Monitoring

AWS CloudTrail

Description
AWS CloudTrail records every API call and management event in your AWS environment, providing visibility into who did what and when. It’s fundamental for auditing, incident response, and compliance.

Scenario
A developer accidentally grants public access to an S3 bucket. CloudTrail logs the API call, capturing the user identity, source IP, and timestamp. The security team uses these logs to investigate and roll back the change.

Best Practices

Enable CloudTrail across all accounts using AWS Organizations.
Store logs in S3 with encryption and set lifecycle policies for retention.
Integrate with CloudWatch Logs or Security Lake for monitoring.
Use CloudTrail Insights to detect unusual activity patterns automatically.

Pricing

One management trail per region is free.
Additional trails and data events (e.g., S3 object access, Lambda invocations) incur cost per 100,000 events.

Amazon GuardDuty

Description
Amazon GuardDuty provides continuous, intelligent threat detection for your AWS environment. It analyzes CloudTrail logs, VPC Flow Logs, and DNS logs to identify suspicious activity using machine learning and threat intelligence feeds.

Scenario
Your security team receives a GuardDuty finding showing an EC2 instance communicating with a known crypto-mining domain. An EventBridge rule triggers a Lambda function that isolates the instance by removing its IAM role and updating the security group.

Best Practices

Enable GuardDuty at the organization level for centralized visibility.
Automate incident response workflows using EventBridge and Lambda.
Regularly review findings in Security Hub and suppress known safe activities.

Pricing

Based on the volume of data analyzed (per GB of logs).

AWS Security Hub

Description
AWS Security Hub aggregates and prioritizes findings from multiple AWS security services (like GuardDuty, Inspector, and Macie) and third-party tools. It gives you a unified view of your security posture across all AWS accounts.

Scenario
A compliance officer enables AWS Foundational Security Best Practices in Security Hub. The tool automatically checks for common misconfigurations such as unencrypted S3 buckets or unused IAM access keys and produces consolidated compliance scores.

Best Practices

Enable Security Standards (e.g., CIS AWS Benchmark, PCI DSS).
Integrate with AWS Organizations for centralized management.
Use custom insights to filter high-priority findings for your environment.

Pricing

Per compliance check and per finding ingested.

Amazon Detective

Description
Amazon Detective simplifies the process of investigating and understanding the root cause of security issues by automatically collecting and correlating data from GuardDuty, CloudTrail, and VPC Flow Logs.

Scenario
A GuardDuty alert shows potential credential compromise. The security team uses Detective to trace which IAM user performed the unauthorized API calls and what resources were affected, visualizing relationships over time.

Best Practices

Enable Detective in accounts where GuardDuty is active.
Use it for incident post-analysis, not real-time response.
Retain data for the default 12 months for full investigation context.

Pricing

Per GB of data processed monthly.

Amazon Inspector

Description
Amazon Inspector provides continuous vulnerability scanning for EC2 instances, container images in ECR, and Lambda functions. It identifies software vulnerabilities (CVEs) and insecure configurations automatically.

Scenario
Inspector detects an outdated OpenSSL library on EC2 instances. The findings are sent to Security Hub, which triggers an SNS notification to the DevOps team for remediation.

Best Practices

Enable automatic scanning for new workloads.
Integrate Inspector findings with ticketing systems (like Jira).
Use tags to include/exclude workloads from scanning.

Pricing

Based on resource type and number of assessments per month.

AWS Security Lake

Description
AWS Security Lake centralizes security data from AWS services and third-party sources into a data lake built on S3. It normalizes data into the Open Cybersecurity Schema Framework (OCSF) for analytics and SIEM integration.

Scenario
An enterprise collects logs from GuardDuty, CloudTrail, and EDR tools into Security Lake, then queries them with Amazon Athena for security analytics and incident correlation.

Best Practices

Use lifecycle policies to control storage costs.
Integrate with Athena or OpenSearch for detection and dashboards.
Segment access by team or data type (SOC, Compliance, Forensics).

Pricing

Per GB of data ingested and stored.

AWS Security Incident Response

Description
AWS Security Incident Response a set of AWS services, playbooks, and automations that help organizations prepare for, detect, and recover from security incidents.

Scenario
A company sets up an incident response workflow: GuardDuty detects a threat → EventBridge triggers Lambda → instance is quarantined → forensics team uses CloudTrail logs for investigation → snapshots are preserved for evidence.

Best Practices

Build automated runbooks using Step Functions or Systems Manager.
Predefine response actions for different incident categories.
Regularly test your response plan through simulations.

Pricing

Depends on the AWS services used (no direct cost for the framework).

Application Security

AWS Signer

Description
AWS Signer digitally signs code artifacts to ensure integrity and trust before deployment. It’s often used for Lambda functions, container images, and IoT applications.

Scenario
A DevOps team signs Lambda function packages with Signer before deployment. At runtime, the function’s integrity is verified automatically, ensuring no tampering occurred during delivery.

Best Practices

Integrate Signer into your CI/CD pipeline.
Rotate and protect signing keys with KMS.
Sign only verified and tested artifacts.

Pricing:

Per signing job.

AWS Security Agent

Description:
AWS Security Agent continuously scans workloads and applications for vulnerabilities and misconfigurations throughout the development lifecycle.

Scenario:
During CI/CD, the Security Agent detects that an ECS task definition exposes unnecessary ports. The pipeline blocks the deployment until the issue is fixed.

Best Practices

Embed scans into your development pipeline.
Combine with Inspector for runtime checks.
Use findings to educate teams on secure configuration.

Pricing

Based on scan frequency and resource usage.

Amazon Verified Permissions

Description
Amazon Verified Permissions A fine-grained authorization service that lets applications make real-time access decisions based on centrally managed policies.

Scenario
A banking application uses Verified Permissions to determine whether a user can view or modify specific accounts. Authorization policies are stored centrally, ensuring consistent enforcement across microservices.

Best Practices

Keep authorization policies centralized and version-controlled.
Design policies that reflect real business logic, not only technical access.
Combine with Cognito or IAM for authentication.

Pricing

Charged based on authorization request volume.

Compliance & Governance

AWS Config

Description
AWS Config records the configuration state of AWS resources and continuously evaluates them against compliance rules and baselines.

Scenario
Config detects that an S3 bucket becomes public. A Lambda remediation function is triggered automatically to restore compliance by blocking public access.

Best Practices

Use Config Conformance Packs for CIS or NIST compliance.
Enable across all accounts via AWS Organizations.
Integrate Config findings with Security Hub for unified reporting.

Pricing

Per configuration item recorded and per compliance evaluation.

AWS Audit Manager

Description
Audit Manager automates the collection of compliance evidence, mapping AWS resource data to controls for frameworks such as SOC 2, ISO 27001, or PCI DSS.

Scenario
A compliance officer creates an assessment based on ISO 27001. Audit Manager automatically collects encryption settings, IAM configurations, and logging evidence to prepare audit-ready reports.

Best Practices

Use prebuilt control frameworks.
Assign ownership of each control to specific stakeholders.
Review reports regularly before formal audits.

Pricing

Per active assessment per month.

AWS Artifact

Description
AWS Artifact provides on-demand access to compliance reports and agreements such as SOC, ISO, and PCI certifications for AWS services.

Scenario
A security team downloads AWS’s PCI DSS attestation report from Artifact to include in their compliance documentation when onboarding a new client.

Best Practices

Keep reports updated for each audit cycle.
Store downloaded reports securely and limit access.

Pricing

Free.

AWS Security Hub CSPM (Cloud Security Posture Management)

Description
AWS Security Hub CSPM A feature within Security Hub that continuously checks your AWS environment against best practices and compliance standards to identify misconfigurations and security gaps.

Scenario
Security Hub CSPM detects that RDS instances aren’t encrypted and that CloudTrail logging is disabled in a few accounts. Findings are sent to Slack via EventBridge for immediate action.

Best Practices

Enable across all AWS accounts for unified visibility.
Align CSPM rules with your company’s compliance framework.
Use findings for automated remediation workflows.

Pricing

Included within Security Hub pricing.

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.

DEV Community: 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 Identity Center (AWS SSO)

AWS Organizations

AWS Resource Access Manager (RAM)

Amazon Cognito

AWS Directory Service

Data Protection

AWS Secrets Manager

AWS Private Certificate Authority (CA)

AWS Certificate Manager (ACM)

Amazon Macie

AWS Key Management Service (KMS)

AWS CloudHSM

AWS Payment Cryptography

Network and Application Protection

AWS Web Application Firewall (WAF)

AWS Shield

AWS Network Firewall

AWS Firewall Manager

Threat Detection & Monitoring

AWS CloudTrail

Amazon GuardDuty

AWS Security Hub

Amazon Detective

Amazon Inspector

AWS Security Lake

AWS Security Incident Response

Application Security

AWS Signer

AWS Security Agent

Amazon Verified Permissions

Compliance & Governance

AWS Config

AWS Audit Manager

AWS Artifact

AWS Security Hub CSPM (Cloud Security Posture Management)

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

About AWS Key Management Service

The default KMS Authorization behaviour

Implement secure KMS 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`