AWS SSO (IAM Identification Middle) for Separation of Duties | by Teri Radichel | Cloud Safety | Jan, 2023

January 8, 2023

24

ACM.126 Making a permission set for DNS Directors in AWS SSO

It is a continuation of my collection on Automating Cybersecurity Metrics.

In my final put up I defined how one can have higher governance and management the dangers related to DNS configuration modifications by segregating your domains out to a separate account and solely giving sure customers entry to that account.

In fact you are able to do that with separate roles inside a single account as properly however utilizing a separate account could simplify permissions administration in a big (or perhaps a small) group the place IAM permissions can get complicated and complex in a rush. Maybe separating out sure vital permissions to a particular account will aid you merely entry. You may even restrict entry to that account by disabling person accounts and solely re-enabling them when required.

At this level within the collection we’re going to department out into utilizing a number of accounts for various functions. As described within the final put up we’re going to place all our domains in Route 53 in a single AWS account. That approach they are going to be straightforward to search out and handle. Then we’re going to permit a set of DNS directors to handle the domains in that account, and nobody else.

We’ll let our IAM directors grant customers and roles permission to handle domains within the account. The IAM directors shouldn’t be capable of change their very own permissions to grant themselves the flexibility to handle domains. Ideally IAM directors additionally can’t get the password assigned to new customers or get entry to new roles we create. I’ll deal with these subjects extra later if I’ve time.

We’ve been utilizing IAM however we’ll take a look at AWS SSO for a minute as a option to handle customers throughout a number of accounts and permit customers to entry a number of accounts. You’ll finally wish to automate creation of all permissions however for this put up, I’m going to manually add permissions for a site title administrator in a corporation to entry an AWS account set as much as handle domains, simply to exhibit the idea.

Delegating permission to handle DNS configurations utilizing AWS SSO (IIC)

AWS SSO is now known as IAM Identification Middle (which I’ll discuss with as IIC beneath). I’m used to calling it AWS SSO so I’d slip up beneath. I’m unsure why the title change. It’s simply complicated and IIC performance doesn’t exchange totally what you are able to do with AWS IAM as described all through this weblog collection. Possibly it would some day.

Nonetheless, I’ve been utilizing and attempting to get used to AWS SSO (I imply IIC) so let’s see the way it works and the way we would outline person permissions to handle domains (versus the automation permissions I’ve been creating with AWS IAM).

The primary two ideas in AWS SSO/IIC are acquainted to these utilizing AWS IAM:

Customers: Sometimes a person is related to an e-mail deal with and it’s a individual (not a compute useful resource or software). You should use one thing apart from an e-mail deal with.

Group: A gaggle of customers. You may assign entry to an account to a gaggle as an alternative of particular person customers.

That is the place it will get unnecessarily complicated to me.

Permission Set: A assortment of IAM insurance policies. (They need to have simply known as it a task or a task template.)

The identical permission set can be utilized in a number of AWS accounts, so in different phrases, you outline the set of permissions as soon as after which assign it to customers in numerous accounts.

As you’ll see, a permission set is actually a task. Below the hood it’s like a CloudFormation template for a task that will get deployed to chose accounts, after which the position is assigned to the customers you affiliate with the position in that account. What you find yourself with while you assign a permission set is a task within the account the place you assigned the permission set to a person. It’s a task.

Why they don’t simply name it a task template and roles, I don’t know. It could make the idea clearer as to what’s occurring while you create the assets I’m going to indicate you beneath.

I discovered permission units complicated at first, and I additionally discover the SSO UI a bit missing, however it works. Let’s take a look at including a brand new person and I’ll clarify what I might change if I might. Possibly AWS is engaged on it.

Create an AWS SSO / IIC permission set

Let’s add a permission set so we will assign DNS directors entry to the AWS account we’ve designated for our area title administration.

Create a permission set for DNS administration — mainly full entry to AWS Route 53. You may see within the following display shot that I’m going by the steps to create a brand new permission set and selecting the inbuilt coverage: AmazonRoute53FullAccess.

What occurs subsequent appears to be a bug. Once I seek for my new permission set it says not discovered by way of the search operate:

Nonetheless, if I am going to the second web page I discover my new permission set which I named Route53FullAccess. I can click on on it and see the small print together with which permissions are included on this permission set:

Assign the DNS directors within the domains account

OK now I wish to assign this permission set to my area title directors and solely permit these permissions within the account the place I handle domains.

To start with I created a gaggle and added the customers I wish to be DNS directors to the group:

Now I can affiliate that group to the permission set and the account through which I would like the permission set to use.

You may suppose you could possibly do that from the person within the console. However no, you can not.

Nor are you able to do it from the teams display.

Navigate to accounts and the place you need to affiliate the person or group and the permission set to that account.

Seek for and click on in your account after which select Assign customers or teams.

Select your DNS admin group and the permission set simply created and submit the modifications.

That is cumbersome as a result of after I’m administering one person or — for safety finest observe usually — a gaggle, I would like to have the ability to choose all of the accounts that person or group can entry at one time and which permission set (position) to use. As an alternative I’ve to navigate into every account and set the permission on an account by account foundation.

This appears to defeat the aim of a service that will be a good way to centralize and make administration of person and group permissions throughout a corporation simpler. Maybe it has to do with the way in which AWS IAM works beneath the hood. If you’re utilizing AWS IAM, you need to log into every account and click on on the person or group, after which add the permissions. Maybe that is simulating that previous expertise of getting you login and click on on every account so as to add permissions because of some underlying architectural restriction however I hope they are going to repair this sometime.

Right here’s the place it will get problematic from a safety auditor’s viewpoint.

Let’s say you wish to evaluation all of the permissions of a specific person. Let’s say you named your person DNS Admin and also you assigned that individual entry to the domains AWS account and full route 53 entry by way of the permission set we created as we did above.

You later wish to see all of the permission that the DNS Admin person has. The logical factor can be to navigate to that person within the console and click on on it. Nonetheless, while you click on on the person all you’ll be able to see are the group memberships however no holistic view of the person’s permissions or accounts to which the person has entry.

Properly it should be beneath teams, you suppose? No. Identical factor. Click on on teams and a specific group. You see no such info.

As a way to evaluation permissions you need to individually evaluation every account. If you happen to click on on every account you’ll be able to see who has permissions by way of the assigned person or group title plus permission set.

I attempt to think about doing this at Capital One the place we had 70 accounts…(different organizations have many extra with the evolution of automated account creation). That’s not likely going to work for a safety skilled.

Creating the permissions was straightforward. Reviewing the permissions as an entire is one thing that didn’t appear to be thought-about when designing the UI. I preserve hoping AWS will repair this. #awswishlist. You’ll be higher off utilizing another report or software for this goal.

Overview what received created within the domains AWS account

Now let’s evaluation what received created in our domains account to grant entry to our SSO (I imply IIC) area directors. Navigate to the SSO dashboard utilizing no matter account has IAM entry to the domains account. You received’t be capable to see this entry with the area admins person or group as a result of we didn’t grant IAM entry to that group.

Discover that we’re navigating to IAM, not SSO (er. IIC) on this case. SSO/IIC is simply facilitating the creation of a task within the account the place you wish to grant permissions. Your permission set is actually a template for a task. You create the position within the accounts you choose and affiliate the customers or teams who can use that position in that account.

Why AWS didn’t merely name permissions units one thing like roles I don’t know. It looks like that will have been much less complicated. Actually, they might even present the underlying CloudFormation template used to deploy the position and can help you add your individual CloudFormation templates as an alternative of “permission units”.

Additionally discover that AWS SSO/IIC is utilizing SAML — for higher or for worse.

AWS SSO/IIC is ok for granting customers the flexibility to login and consider issues within the AWS console. It’s handy for customers who login and get a dashboard of all of the accounts to which they’ve entry. This one facet of AWS SSO makes me use it for customers who login to AWS.

Nonetheless, I don’t use it for automation. I’ll clarify why within the subsequent put up.

We could wish to grant DNS admins the flexibility to login and manually view or handle points of DNS within the AWS console. That will be the aim of granting a person SSO entry to the domains account as I’ve completed on this weblog put up.

Dangers to contemplate— who can grant permissions?

Now you may need solely given the DNS directors permission to handle domains, however contemplate the next:

Who has entry so as to add a person to the DNS administrator group?
Who has permission to create a brand new permission set like we did right here?
Who has administrative entry to the domains account and IAM who might create permissions immediately within the domains account?
Who has permission to reset person passwords and modify MFA gadgets comparable to these assigned to the area directors?

Any of the above permissions might primarily be used to grant somebody new entry to the area title switch performance I wrote about within the final put up. That’s the reason I like to recommend that you’ve a separate group assigned particularly to managing IAM and SSO and you concentrate on how one can create segregation of duties to stop somebody from granting themselves entry to one thing whey shouldn’t be capable of entry.

Now that we have now an AWS SSO person for DNS administration, we’ll take a look at how that person can execute instructions with the AWS CLI within the subsequent put up (and why I don’t use that strategy).

Observe for updates.

Teri Radichel

If you happen to favored this story please clap and comply with:

******************************************************************

Medium: Teri Radichel or E-mail Record: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests companies by way of LinkedIn: Teri Radichel or IANS Analysis

******************************************************************

All of the posts on this collection:

____________________________________________

Creator:

Cybersecurity for Executives within the Age of Cloud on Amazon