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 Risposta

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.
con risposta 2 anni fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande