Reliability
Part of Cloud security operations
Reviewing configuration changes that expose services
Trace a cloud access change to its affected service, assess reachability and record the correction and checks.
Review a cloud configuration change by identifying the affected service, tracing the access path and deciding whether the new access was intended. A broad rule is a warning signal, not proof that someone on the internet can use the application. Capture the change before correcting it so its owner can explain and verify the outcome.
Identify the change and affected resources
Record the change time, resource ID, account, actor or automation, previous and new settings, and related approval. Identify every workload using the changed resource. An AWS security group rule applies to resources associated with that group; one change may affect several servers.
Check the activity records that were actually available. AWS CloudTrail Event history provides the past 90 days of regional management events for an account. It excludes data events, records events in the AWS Region where the event happened, and is separate from any trails or event data stores that you create.
AWS Config can provide configuration history for a resource it recorded. Azure Activity Log records management operations; data-plane resource logs require separate configuration. An absent event in one view is therefore not proof that no activity occurred.
Cloud Logging Sources: Availability and Scope
- AWS CloudTrail Event History
- 90-day retention, regional events only, excludes data events
- AWS Config
- Configuration history for recorded resources, requires setup
- Azure Activity Log
- Records management operations; data-plane logs need separate enablement
Trace the access path
For a network change, inspect the permitted source, protocol and port, then the attached endpoint, address, routing, listener and application authentication. In an AWS security group, 0.0.0.0/0 and ::/0 allow traffic from any IPv4 and IPv6 address respectively for the rule’s specified traffic. Other parts of the path still determine whether a service is reachable.
A public web entry point may deliberately accept HTTPS from a broad audience. A management or database port needs its own access justification. Ask which users and systems need the path and whether a narrower source or private route would meet that need.
| Finding | Question | Possible decision |
|---|---|---|
| Intended public entry point | Are only required ports permitted, and is application access controlled? | Retain with an owner and recorded checks |
| Unexpected broad access | Which resources and users could be affected? | Investigate and prioritise containment |
| Broad rule without a current route | Is the permission needed, and could a route be added later? | Narrow unnecessary permission |
The rows are review prompts, not findings about an assessed environment.
Correct and verify
If the owner rejects the exposure, agree on the immediate change and likely service effect. Preserve the original configuration and activity details in the change or incident record. If activity looks suspicious, involve the incident owner before treating the matter as a routine mistake.
After correction, check the intended user action from a relevant network and assess the unwanted path through an authorised check. Record who performed each check and what it showed. A saved rule proves a setting changed; it does not establish that the application still works or that every access route is closed.
