1 Risposta
- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
0
Hello! I'll do my best to answer each of your questions below:
- Accessing CloudTrail logs is a great way to do this, and by filtering certain attributes you can find this info relatively quickly. CloudTrail logs include a "readOnly" attribute as well as a "userIdentity" attribute. The "readOnly" attribute determines whether changes (creates, updates, deletes, etc) were attempted on AWS resources, and the "userIdentity" includes info like the IAM Principal and username of the requester. By filtering logs with these attributes, you can see all actions where readOnly is false (meaning that some change was made to your account, infrastructure, or resources) for a particular user. You can see the details of these attributes in the CloudTrail records contents documentation.
- It's a best practice to restrict all AWS access to least privilege permissions. Administrators often require broader permissions so that they can make critical changes to your AWS environment, but it's ultimately up to your organization to determine what permissions your administrators need. With that said, AWS provides managed permissions sets for certain job functions to help you get started in scoping your permissions. I'd recommend exploring these to see if any are a better fit for your administrators, and then you can add custom policies to further restrict/allow actions based on your organization's specific needs.
- CloudTrail logs may be the only sure way to demonstrate that there have been no infrastructure changes. If you're managing your workload with infrastructure as code, you could potentially use CloudFormation's drift detection feature to support that the infrastructure hasn't changed. Depending on the scope of the audit, this may not be sufficient. I would still recommend the CloudTrail logs for this.
con risposta un anno fa
Contenuto pertinente
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata un anno fa