In this lesson, we look at how to configure Amazon GuardDuty to work across multiple AWS accounts as well as the different permissions required and used when working with Amazon GuardDuty.
By the end of this lesson, you will have a greater understanding of Amazon GuardDuty, including:
- The terminology for using a multi-account strategy with Amazon GuardDuty
- How to connect multiple AWS accounts to centralize findings
- How to ensure you have the correct permissions in place to work with Amazon GuardDuty successfully
- Individuals working as security consultants or specialists, security analysts, security auditors, Cloud architects, or Cloud operational support analysts
- Anyone looking to learn more about AWS Security and threat detection within AWS
- Have a basic understanding of the fundamentals of AWS
- An awareness of different security measures and mechanisms offered by different AWS services, such as IAM resources, specifically IAM Policies and IAM roles
- Understand AWS Organizations at a fundamental level and have a basic understanding of Amazon GuardDuty
- If you’d like more information on some of these features, check out the following courses titled:
Hello and welcome to this lecture, where I’ll explain the different permissions that are required and used when using Amazon GuardDuty, both from a user perspective and through the service itself.
Let’s talk about the user permissions when using Amazon GuardDuty first. When you first try to access the GuardDuty dashboard from the homepage of the AWS Management Console, it’s possible that you’ll receive an error saying you’re unauthorized or that your access is denied. In this case, it’s most likely related to lack of permissions.
So if you see something like this error, that says your account doesn’t have the necessary permissions, you would need to speak to your administrator to ask them to revise your permissions for GuardDuty. You would need the relevant permissions to access the GuardDuty service.
The administrator would most likely assign permissions through an IAM policy that looks like this: allowing all actions on all resources in Amazon GuardDuty.
With this policy, you can even enable the service. However, after enabling the service, you will get a warning that you don’t have the necessary service role permissions to enable Malware Protection.
That’s because malware protection uses a specific service-linked role and requires additional IAM permissions to create it. So although the user will have full access to GuardDuty actions, the user will still need these additional permissions relating to IAM and service-linked roles. Without this role, the malware protection feature will remain disabled.
Fortunately, to provide all the necessary permissions to enable GuardDuty, including permissions to create the malware protection service-linked-role, AWS created a managed policy called the Amazon GuardDuty Full Access policy. This enables full access to GuardDuty actions and includes the added permissions to create the service-linked role.
You can see that here in this policy: Not only do you have full access to GuardDuty, you also have the ability to create a service-linked role, get a role, and access certain AWS Organizations features, such as the ability to list delegated administrators.
However, one thing to keep in mind is this Amazon GuardDuty Full Access policy doesn't allow you to upload a Trusted IP or Threat List as this again, requires different IAM permissions. If you do try to add a list with the Full Access policy you will receive the following error.
To allow a user to be able to manage your Trusted IP and Threat lists you will need to add the following permissions to the user group or role. Do remember to replace the AWS account number with your own account.
AWS also offers another managed policy for you to use as well, called the Amazon GuardDuty Read Only Access Policy. As expected this policy provides the user to have read-only permissions to Amazon GuardDuty allowing them to review findings.
It’s also worth mentioning that GuardDuty uses a service-linked role during the enablement of the service. This role uses the AmazonGuardDutyServiceRolePolicy, which contains the following permissions. It can retrieve information about your EC2 instances, networking components such as VPCs and security groups, S3 buckets and objects, Lambda functions and tags, EKS clusters and tags, AWS organizations to describe associated accounts, and it can use IAM to create the service-linked role permissions for Malware protection after it’s been enabled.
The service-linked roles have an associated trust relationship which allows Amazon GuardDuty to adopt this role. When this service is enabled in a region, the GuardDuty Service Role permissions are granted to Amazon GuardDuty automatically. By default, Malware protection is also enabled, so the service-linked role for Malware Protection is also automatically created for you, as long as you have the necessary IAM permissions.
The malware protection service role looks like this. It enables GuardDuty to get information about EC2 instances, EBS volumes and snapshots, and ECS and EKS clusters. It also enables GuardDuty to take EBS snapshots and evaluate them for potential threats. It can create a CloudWatch log group for malware detection to log scan events, and more.
As with other AWS services, you can be very specific with what actions a user, group, or role can perform with Amazon GuardDuty by creating custom IAM policies.
That brings us to the end of this video - I’ll see you in the next one.
Alana Layton is an experienced technical trainer, technical content developer, and cloud engineer living out of Seattle, Washington. Her career has included teaching about AWS all over the world, creating AWS content that is fun, and working in consulting. She currently holds six AWS certifications. Outside of Cloud Academy, you can find her testing her knowledge in bar trivia, reading, or training for a marathon.