Auditing Infrastructure Changes made via AWS Console


Our environment manages most of the infrastructure component changes via code. Additionally, certain administrators have access to make infrastructure changes to applicable resources directly via console (although direct changes are not encouraged or frequently made). Our auditors are indicating that as administrators have access to make direct infrastructure changes via console, they cannot rely on the population of infrastructure changes made via code (obtained from Git), and also want us to evidence that no direct infrastructure changes were made by administrators directly from the console. I wanted to understand the following:

  1. How can we obtain population of direct infrastructure changes made from the console? We are thinking of obtaining the cloudtrail logs, but is there any other efficient way to obtain this population?

  2. Also, does it make sense to restrict administrator access to prevent from making any direct infrastructure changes? What is the industry standard in terms of restricting administrator access?

  3. Are there any other ways to evidence that no direct infrastructure changes were made outside of code changes?

1 réponse

Hello! I'll do my best to answer each of your questions below:

  1. 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.
  2. 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.
  3. 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.
répondu il y a 2 ans

Vous n'êtes pas connecté. Se connecter pour publier une réponse.

Une bonne réponse répond clairement à la question, contient des commentaires constructifs et encourage le développement professionnel de la personne qui pose la question.

Instructions pour répondre aux questions