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개 답변

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.
답변함 2년 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인

관련 콘텐츠