Cloud security reviews become easier to act on when they start with three questions: who can change this resource, who can reach it, and what evidence would show misuse? A configuration can be technically valid while granting access the business never intended.
The short version
- Review effective permissions and network exposure together.
- Check data access separately from encryption settings.
- Validate logging with representative events and an assigned responder.
01 / Infrastructure security
Begin with a small, business-focused inventory
Choose one important service and trace its accounts, identities, storage, network rules, and deployment process. Include the environments that can influence production, such as build systems and shared administrative services. Record a resource owner and the business information involved.
The examples here use AWS documentation. Other platforms expose similar review questions through different services and policy models. Check the documentation for your provider before applying a setting, and test changes against legitimate service behavior.
02 / Infrastructure security
Permissions that outlive their purpose
AWS recommends temporary credentials for human and workload access, least-privilege permissions, MFA, and regular review of unused identities and credentials. Its guidance also recommends checking public and cross-account resource access. [1]
For your assessment, select a workload identity and ask what it actually needs to do. Compare that purpose with its effective permissions, including any roles it can assume. Examine emergency accounts and old automation alongside current staff access.
Illustrative question: Does a reporting job that reads one dataset also have permission to modify unrelated storage? Document the business reason for each broader capability or give its removal an owner. A permission review should account for trust relationships as well as the policy attached directly to an identity.
03 / Infrastructure security
Storage exposure that encryption does not resolve
AWS S3 Block Public Access provides controls that can reject public access allowed through other settings. AWS documents how the applicable settings combine across supported resource and account boundaries. Review the effective result, rather than a single screenshot from one bucket. [2]
Our suggested review separates confidentiality at rest from permission to read. Encryption and access policy answer different questions. Identify which datasets are intended to be public, which identities can retrieve private objects, and who can change those decisions.
For a public website asset bucket, public retrieval may be intentional. For customer exports, test the expected restriction with synthetic objects and an unauthenticated request. Record exceptions explicitly so a future team does not mistake a convenience setting for an approved design.
04 / Infrastructure security
Network rules without a current business reason
AWS security groups control allowed inbound and outbound traffic. Rules from multiple groups associated with a resource are aggregated. Reviewing only one group can therefore miss an access path permitted by another. [3]
Trace reachability to administrative interfaces, databases, and internal APIs. Review both the permitted source and the actual route to the service. Ask whether an externally reachable management port is necessary, which identity controls protect it, and how temporary access is removed.
Use a controlled change process for network restrictions. Begin with the intended service-to-service connections and validate them after the change. An assessment should identify unnecessary exposure without assuming that removing every route is compatible with the application’s purpose.
05 / Infrastructure security
Audit records that leave important questions unanswered
CloudTrail management events cover control-plane operations such as configuration changes. AWS notes that trails and event data stores log management events by default and do not include data events by default. An audit configuration should therefore be checked against the exact activity you need to investigate. [4]
Our recommended exercise is to perform an approved configuration change and a representative data-access event, then locate the expected evidence. Check the identity, time, resource, action, retention, and access to the logs. Decide who receives an alert and what they should do with it.
A log being enabled is an intermediate result. The useful outcome is that your team can answer a concrete incident question with the records available.
06 / Infrastructure security
Turn findings into a repeatable infrastructure review
For each issue, record the resource, intended behavior, observed exposure, affected information, and proposed change. Name an owner and include a validation step. Review exceptions when the service changes, rather than allowing them to become permanent by default.
- Which identities can grant themselves or others more access?
- Which resources are reachable from an untrusted network?
- Can sensitive data be retrieved through an unintended identity or public path?
- Can the team investigate both configuration changes and relevant data access?
- Can a fix be verified without disrupting required operations?
Start with the service where a configuration mistake would have the clearest business consequence. Use what you learn to create a review pattern for the next environment.
Turn insight into action
Discuss the workflow, information, and controls you want to assess. We’ll help define a clear testing scope and practical next steps.
Plan an infrastructure auditResearch & sources
Read the original guidance
Primary guidance checked on 6 November 2026. Examples and suggested review activities are Redteam Cybersec’s editorial synthesis. They do not describe a client engagement or establish the security of a particular system.
- AWS — Security best practices in IAMTemporary credentials, least privilege, MFA, and access reviews.
- AWS — Blocking public access to your Amazon S3 storagePublic-access controls and their effective combination.
- AWS — Security group rulesInbound and outbound rules and aggregation across security groups.
- AWS — Logging management eventsManagement-event coverage and the distinction from data events.