Tighten SSH access across your AWS environment by removing or restricting any security group rule that exposes port 22 (SSH) to the entire internet (0.0.0.0/0 or ::/0). The plan walks through discovering risky security groups, mapping them to the resources they protect, guiding you to define and apply approved SSH sources, and finally validating that only explicitly authorized locations can initiate SSH connections.
By the end, all in-scope security groups will either have SSH fully removed or restricted to a clearly documented set of trusted CIDR ranges and/or source security groups, with exceptions deliberately approved and recorded.
Start by reviewing in-scope AWS accounts and regions, then enumerate all security groups within them. For each security group, the plan examines inbound rules for TCP port 22—both single-port rules and port ranges that include 22.
Any rule that allows SSH from 0.0.0.0/0 or ::/0 is identified, including cases where port 22 is part of a broader range or where combined CIDRs effectively expose SSH to the internet. For every matching security group and rule, the plan captures key attributes such as IDs, names, descriptions, VPCs, accounts, regions, protocols, ports, CIDRs, and referenced source security groups. These findings are consolidated into a clean, structured list for subsequent steps.
Next, the plan links each identified security group to the resources it protects. It gathers all attached network interfaces (ENIs) and records their basic details, then determines which resources they belong to—such as EC2 instances, load balancers, NAT gateways, or other managed services.
For EC2 instances, relevant metadata is captured, including instance IDs, names, state, type, Availability Zone, and key tags (like environment or owner). For other resources, the plan records their type, identifiers, and any helpful naming or tagging. Security groups that are not attached to any resource are flagged separately. The result is a structured mapping of each risky security group to its associated ENIs and resources, ready for user decisions.
With visibility into which resources are affected, the plan guides you through defining what “approved SSH access” means for your environment. You review the security groups and resources currently exposed and then specify:
If broader temporary access is necessary, the plan captures the justification, scope, and review or expiry dates. All of this is documented in a structured format to guide configuration changes.
The plan then helps you make concrete decisions for each affected resource (or logical group of resources). Using the mapping from security groups to resources and their tags, you decide:
These decisions are translated into target outcomes for each security group rule: which SSH rules should be removed, which should be replaced with more restrictive rules, and which may remain as approved exceptions. The results are captured in a structured form that can be directly used by the configuration phase.
Using the collected decisions and approved source definitions, the plan updates security groups in line with your policies.
For security groups where SSH is to be fully removed, it identifies all inbound rules that permit TCP 22 (whether explicitly or as part of a range, and from any source) and removes them so that no SSH access remains.
For groups where SSH must be retained but restricted, the plan identifies and deletes rules that allow port 22 from 0.0.0.0/0, ::/0, or other non-approved sources. It then creates or adjusts rules so that SSH is allowed only from the specific IPv4 CIDRs, IPv6 CIDRs, and/or source security groups you designated.
If a single security group is shared by multiple resources with differing SSH needs, the plan ensures rules reflect the strictest common requirement and flags any cases where future re-segmentation might be beneficial. After changes, each modified security group is rechecked to confirm that:
Any security groups that cannot be changed as planned are documented along with the reasons, and a concise before-and-after summary of SSH-related rules is produced for all modified groups.
Finally, the plan re-runs an environment-wide check to verify the outcome. It re-enumerates all in-scope security groups and inspects inbound rules for any occurrence of port 22, including ranges.
The validation step confirms that:
The process concludes with a validation report summarizing the scan results, highlighting any remaining issues or exceptions, and clearly stating that SSH is no longer open to the internet for all in-scope security groups.