Passing the AWS Security Specialist Cert Part 1: Identity and Access Management & Data Protection

The AWS Security Specialist certification is a great choice for anyone working in AWS, whether you are a security engineer, developer, site reliability engineer, or admin. Any resource created in AWS quickly becomes a target. Knowing and practicing the many nuances of securing these resources will help keep you, your applications, your data, and your customers safe.

We’ve already covered whether or not this cert is worth it in the past. Hopefully, you made your way to this article because you’ve already decided that, for you, it is worth it, and you are ready to get a little deeper into the domains covered by the cert. 

If you review that article (or the official exam guide), you’ll recall the five domains of knowledge that this certification covers. For today we start at the end with domain four (Identity and Access Management) and domain five (Data Protection, which mostly covers AWS KMS). We start with these because they represent the most critical pieces of a fully secured AWS account, both in terms of the real world and in terms of the topics you will see most hammered on on your exam.

Overall, this is a wide certification in terms of what you need to know, but it does go deep into these two key areas. Later in a future article, we’ll cover, well, everything else basically. The three other domains cover many many other AWS services, but at much less depth.

Before jumping in, let’s take a big step back to look at the bigger picture. Log in to your AWS console, hit the Services button in the top left, and look at the list of all services. There’s a lot there, over 500 as of the time of this article’s publication. And your job presumably as someone reading an article like this is to help secure this wide and deep surface area for your organization.

But guess what? Fundamentally, IAM is one of the two biggies that you need to secure your entire account. It controls permissions for services, giving access to users, other services, and your code. The other we’ll cover today, KMS, will cover encrypting and protecting data, also across many services.

There’s a lot to cover in these two domains alone, so let’s get started with an overview of the most essential component of securing any workload on AWS, the one service to rule them all: Identity and Access Management, or IAM.

Related: Passing the AWS Security Speciality Cert Part 2: Logging & Monitoring.

Ready to Learn AWS Skills in 2023?

AWS is the undisputed leader in the cloud computing market. If you’ve been thinking about earning a certification or upskilling this year, learning AWS is as safe a bet as any. Find the online AWS training you need at CBT Nuggets. 

No matter if you are brand new to the cloud or a seasoned networking pro, our courses can get you up to speed on the latest AWS technologies and best practices. Our AWS cloud training maps to highly valued certifications — and covers skills that many organizations desperately need. 

Not a CBT Nuggets subscriber? Sign up for a 7-day free trial to get a feel of what it’s like to learn IT with us. Explore our AWS training and start learning skills that can help you level up your career today!

Identity and Access Management

The AWS Security Speciality cert is not intended for beginners, but for folks with at least a few years of AWS experience under their belts. However, it’s always worth a review of the basics before getting too deep.

Let’s start with breaking down IAM. “Identity” ties the closest to authentication (remember your AAA framework?), whether that’s logging in with a username and password or your code using an access key and secret to, say, write a file to an S3 bucket. These are users that you or another admin create in the IAM console. There are all kinds of best practices that you must learn involved with creating users, things like enabling MFA, enforcing a strong password policy, and granting users the least privilege they need to do their jobs.

Multi-factor authentication, or MFA, is Security 101 in the 21st century. MFA on login requires a second means of identifying yourself, usually a code generated by either a hardware device or an authenticator app like Authy or Duo. That proves you are you because you both know the password for the account and you have the means to generate a valid code for your account. This knowing and having combined is the “multi” in multi-factor authentication.

Strong password policies are obvious, an admin ticks a box that requires users to choose a password that has characteristics like a minimum length, it contains special characters, it must be changed every so many days, etc.

Granting least privilege is another essential security principle. If Bob the intern only needs read-only access to a few S3 buckets to do his job, but you assign the SystemAdministrator policy to his user, you’ve just given him keys to the kingdom, every S3 bucket, every database, every EC2 instance, and access to create any of his own resources (or delete yours!). Plus if his account were to be compromised, hackers will have a field day with your account.

So that’s IAM users. We mentioned another facet to IAM though: policies. Policies are grouping of permissions that you attach to users. There are many policies, called AWS-managed policies, that you get out of the box for common tasks, like AmazonEC2FullAccess. This, as it says on the tin, gives you full access to everything related to EC2 on the account. Creating and deleting EC2 instances, starting and stopping them, and many other auxiliary functions necessary to use EC2.

You can create custom policies as needed, selecting individual permissions to attach to the policy. You can also get even more fine-grained, selecting individual permissions on individual resources. For example, Bob the intern only needs read-only access on the buckets containing logs, so you would create a policy that does just that, without giving him any permissions to read any other buckets, like those containing customer data or payroll info.

Policies are written as JSON and are tricky to write from scratch. Luckily the console has a nice GUI that lets you build a policy through a wizard that generates the JSON for you. It’s helpful to go to any of the AWS-managed policies and read through the JSON, trying to follow the flow and how permissions are granted or denied to individual actions on services.

The next key part of IAM is roles. A role is an identity with policies attached to it. Roles can be used by users, generally in the form of a user assuming a specific role after logging in. Assuming a role gives you access to all the permissions that role has. The role isn’t unique to you; anyone with access can assume the role

This can be confusing and atypical of many other SaaS services where everyone has their own user. A typical use case might be logging in with SSO through an identity provider like G Suite or Active Directory. As a part of the SSO flow, the IdP tells AWS “Hey, Bob should get this role.” Once Bob is in the AWS console, he’s accessing it as that role, not as a Bob user. In this scenario, there aren’t even any individual user accounts in AWS, which for an admin makes it way easier to manage.

There are many many other uses for roles, such as a mobile app needing access to resources without hard coding access keys in the app, giving one service access to another (like an EC2 instance accessing S3 buckets), or granting cross-account access. The latter is helpful in an environment with multiple AWS accounts where you grant access via SSO to let an admin login to the parent account, then from there, they can assume a role in a child account where they need to work. Again, no individual users to manage across multiple accounts.

Roles get complicated as you can see. They are an essential part however of using IAM to secure your accounts. Since IAM is such a large part of the AWS Security Specialist cert, you will want to put extra effort into understanding it, both from the AWS docs and from the CBT Nuggets training.

Data Protection

The other test domain we’re going to cover today is Data Protection, which by and large focuses on AWS Key Management Service. KMS is all about protecting your data through encryption and decrypting it upon appropriately authenticated access. KMS by itself isn’t helpful, like a lock without a door, but for the dozens of other AWS services that integrate with it, it is essential.

KMS uses strong encryption keys to encrypt your data. For the services that use this encrypted data, the encryption and decryption functions are mostly transparent. If you are authenticated with a user that has access to the key that certain data is encrypted with, when you access that data KMS automatically works behind the scenes to decrypt it. 

Two important security best practices are at play here to protect your data: you must have explicit access to the keys and data is encrypted at rest.

For the first, IAM again comes into the picture. When you create a KMS key, the key needs a policy defining who can use the key to encrypt and decrypt data and who can administer the key. These policies all refer to either IAM users or roles to grant the permissions, so it’s essential to understand IAM first and have your account set up properly before delving into KMS.

If you want to use encryption but aren’t as concerned about the granular user permissions, there are AWS-managed keys for services. These have wide-open permissions, so anyone can decrypt data using them, with the added bonus of automatic transparent key rotation handled by AWS.

For the second best practice, KMS encrypts data at rest. This is literally the data stored on hard drives at the AWS data centers. Technically KMS also encrypts data in transit, or while it’s moving across a network. We’ll focus, however, on the at-rest aspect, as encryption in transit is a more familiar concept to most, akin to HTTPS encryption of web traffic across the wire.

For data at rest, a common example is for S3 buckets.  There’s an option for every bucket called default encryption. Once enabled, you choose either an AWS-managed key or your own KMS key, and any files created in that bucket are encrypted at rest in the bucket. When those files are requested, the appropriate decryption happens transparently (assuming you are allowed via the key policy). The importance of encryption at rest is that, even if someone had root access on the server where your data is at AWS or got hold of the actual hard drive, your data is safe.

That’s the gist of KMS, but like IAM there’s a huge amount of complexity and granularity, especially when it comes to configuring individual services. Also like IAM, combining a deep dive into the AWS docs with the CBT Nuggets training will be a winning combo to help you pass the cert.

That’s probably enough for today, in the next two parts we’ll take a look at the three remaining domains for the AWS Security Specialist certification. Stay tuned!