Public SSH and private service access in a VPC
A public web application runs in a VPC in us-south with three subnets: public load balancer, application VMs, and database. The application VMs read from COS and call Key Protect over public endpoints. A security scan found SSH (22) open to 0.0.0.0/0 on the application security group, a subnet ACL that allows all ingress and egress, and no VPC flow logs. Developers say they need SSH from home for troubleshooting. An on-premises monitoring system needs to reach the database on port 5432, and the security team wants private service access without traversing the internet. The VPC has no Transit Gateway or Direct Link yet. The load balancer must remain public. The team has one maintenance window before the next external audit and wants fixes that reduce exposure immediately without blocking developers for weeks.
1. What do you change in the maintenance window, and what do you explicitly defer?
Read the worked answer
In the window, I would close SSH to 0.0.0.0/0 first. That is the highest-risk finding because it exposes management access to the internet. Replace it with a controlled path: a bastion host or client-to-site VPN in a dedicated management subnet, restricted to known developer source ranges and requiring MFA, or a session-management approach if available. Security groups should allow 22 only from that management path, not from the application subnet broadly. Keep the public load balancer on 443 only.
I would also enable VPC flow logs to a central, security-readable destination and tighten the subnet ACL from allow-all to the minimum required. ACLs are stateless, so both directions must be considered; a careless ACL change can break return traffic. I would not attempt the full private-service redesign in the same window. Moving COS and Key Protect to virtual private endpoints requires DNS, endpoint gateways, security-group egress rules, and application testing.
The deferred items are Transit Gateway or Direct Link for on-premises database monitoring, full private service access, and long-term bastion architecture. The immediate goal is to remove internet-exposed SSH, gain flow visibility, and avoid an audit finding that the team knowingly left open. Developers get a working path, not an open door.
2. Design the private connectivity for COS, Key Protect, and the on-premises monitoring system.
Read the worked answer
For COS and Key Protect, use virtual private endpoints so application traffic resolves to private endpoints inside the VPC rather than public service endpoints. Create the endpoint gateways, update private DNS, and restrict application security-group egress to the endpoint addresses and required ports. Remove public egress where it is no longer needed. Validate that the application's service authorization and IAM policies still allow the bucket and key operations; private connectivity does not replace authorization.
For the on-premises monitoring system, use Direct Link with Transit Gateway for a private, predictable path, or a site-to-site VPN if Direct Link cannot be provisioned in time. Connect the on-premises network to the VPC through the transit layer, then restrict database access to the monitoring system's specific source addresses on 5432. Use both security groups and ACLs: security groups are stateful and can allow only the monitoring source, while ACLs provide a stateless subnet-level guard. Do not expose the database subnet to the internet as a shortcut.
Keep the public load balancer protected by a web application firewall and DDoS service. Separate management, application, and data paths so that a compromised application VM cannot reach the database management port or the bastion.
3. What logging and detection would you add, and how would you prove the exposure is reduced?
Read the worked answer
Enable VPC flow logs for the VPC and send them to a security-controlled bucket or logging destination with retention longer than the incident-response window. Flow logs show accepted and rejected traffic, so the team can see attempted SSH from the internet, database-port scans, and unexpected egress to public service endpoints. Add Activity Tracker coverage for IAM, COS, and Key Protect changes, and alert on security-group or ACL modifications because those can silently reopen exposure.
Detection should include SSH attempts from non-management sources, repeated rejects on 22 and 5432, new public IP egress from application subnets, and load-balancer errors that suggest scanning. For proof, run an external scan after the change and show that 22 is closed from the internet while the bastion path works. Show the security-group and ACL rules with timestamps, a flow-log sample of a denied SSH attempt, and a successful application read from COS through the private endpoint.
Finally, record the residual risk: the load balancer is still public by design, and developers still have a management path. The claim should be specific - internet-exposed SSH is removed and private service access is in place - not a general claim that the VPC is secure.