ACM.125: Technique for safeguarding domains and DNS configurations in your AWS Group
This can be a continuation of my collection on Automating Cybersecurity Metrics.
I wrote the significance of securing your domains in my final submit and why it issues. If somebody can take over your area title or DNS configuration they’ll doubtlessly take over your whole cloud account, relying on which cloud companies you employ and the way they confirm you’re the proprietor of the area used to arrange cloud companies utilizing that area.
To forestall unauthorized adjustments or takeover of your area title you’ll wish to take into account who has entry to handle and make adjustments to your domains or DNS settings. Right here is one doable method to restrict entry to domains and DNS adjustments for domains hosted and managed by Route 53 on AWS in a corporation.
- Create a brand new AWS account for area title administration on AWS.
You may attempt to lock down your IAM controls in a specific account to solely enable sure individuals to entry DNS configurations. Alternatively, you possibly can put your domains in a single account.
If you wish to automate account creation, I wrote about how you are able to do that within the following weblog submit:
That code is presently not a part of the GitHub repo related to this collection however it might be sooner or later if I’ve time.
Arrange one particular account devoted for area title administration. Individuals who have entry to handle domains in that account can not create compute assets, S3 assets or every other assets that would leverage the domains. The only objective of the account is for area title administration and actions in that account are restricted to that objective.
Every AWS account you create comes with some overhead with regard to safety and logging. To scale back some price and complexity related to a number of accounts, you possibly can utterly disable areas and companies besides these you actively want. Monitor adjustments carefully in case somebody tries to activate issues you might have disabled.
Route 53 is primarily a world service with the exceptions famous on this documentation:
For my functions, a separate account works. If you’re making an attempt to make use of different AWS Route 53 capabilities than these I exploit on this weblog collection, you’ll need to see if this method works for you.
2. Leverage segregation of duties for various DNS actions.
Permit one group to outline the DNS configuration. Give a separate group permission to assign that configuration to an utility. In different phrases, DNS admins arrange NS information; Builders use them to configure functions.
For my functions, on this weblog collection, I’m going to grant one automation function entry to create the NS information for the domains within the DNS account. I’ll give one other automation function permission to assign these DNS information to a static web site in an S3 bucket.
I’m additionally going to arrange an AWS SSO consumer as a DNS admin in a separate “domains” account who can log into the AWS console for the DNS account and handle domains and DNS configurations. Ideally we wish every thing automated however there could also be some present domains to switch over through the AWS CLI or another one-off perform that doesn’t make a whole lot of sense to automate.
How group dimension impacts function assignments
For those who work for a big firm like Capital One, resembling I did, you may need separate groups that every get a single one in every of function. You will have a crew devoted to DNS who makes use of the DNS administrator function and solely has entry to the domains account.
In a smaller group, you may need a single DevOps crew that’s allowed to imagine a number of roles resulting from restricted assets and a separate developer crew that performs utility growth capabilities. The DevOps groups could handle the domains, community, and encryption keys, for instance. On this latter situation, executives would possibly wish to register domains in a single account and even utilizing a separate service and use Route 53 to handle hosted zones for that area title.
To create separation of duties for a really small crew, create completely different credentials for a single individual. Use separate MFA units and credentials for various actions. It’s as if there are two completely different customers despite the fact that the identical individual occurs to be utilizing two units of credentials. The upper degree, riskier credentials, shouldn’t must be used as typically so there’s much less threat that an attacker will get entry to them. You must have extra logging and alerts for dangerous actions.
Caveat with function assumptions
For those who’re utilizing AWS SSO, now AWS IAM Identification Heart, watch out for granting one individual broad permissions by means of assumption of various roles. If a consumer can simply login and swap to any account or function, so can an attacker.
AWS IAM will not be that significantly better however you do need to know the account alias or quantity and function if utilizing the AWS console to change to a special account.
The best way strategy to emulate forcing MFA when switching accounts or roles can be to make use of completely different units of credentials and/or MFA units to drive re-authentication for sure actions as I’ve been doing all through this weblog collection.
3. Transfer domains to the central account
Having all of your domains situated in a single, central account ought to make them simpler to search out and handle.
Listed here are the directions to switch the area to a different AWS utilizing the AWS CLI. Have you learnt who has entry to do that in your group?
The fundamental syntax is fairly easy, although there are some extra choices within the documentation above.
aws route53domains transfer-domain-to-another-aws-account
--domain-name <worth>
--account-id <worth>
The above command will return a password that’s required for the following step. It’s easy to run the command within the AWS cloudshell if somebody has entry to the AWS console.
To finalize the switch, the account that’s accepting the area switch should run the AcceptDomainTransferFromAnotherAwsAccount command. Right here’s how to do this from the AWS CLI:
aws route53domains accept-domain-transfer-from-another-aws-account
--domain-name <worth>
--password <worth>
The password that was returned by the TransferDomainToAnotherAwsAccount request.
In my case, I transferred one in every of my domains between two AWS accounts in several organizations.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Be sure you prohibit entry to this Route 53 performance on AWS! These instructions are easy to run, as you possibly can see. Two strains of code can transfer your area title to a different AWS account. Entry to your area could imply disabling and enabling companies, manipulating e-mail accounts, and taking up cloud accounts as defined within the final submit.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
I simply learn a weblog submit about an “assault” that permits somebody to switch an AWS useful resource between accounts in several organizations. This isn’t an assault. It’s a function. I truly simply wanted that function to maneuver my area as I simply demonstrated above. It’s as much as the client to know what permissions individuals have of their cloud accounts and restrict actions appropriately.
4. Create or transfer NS information for the area within the acceptable account
Be aware that transferring the area doesn’t switch the NS file for the area. Although I simply transferred the area from one AWS account to a different, the performance of my web page and e-mail was unaffected. The area received transferred, not the hosted zones.
Warning: It might be that somebody takes management of your area and also you don’t even notice it as a result of every thing continues to work.
You should use this to your benefit on the subject of governance for domains. You may register the domains in a single account and use the NS information in a very separate account the place you host your functions and web sites.
We’ll look extra at NS information in upcoming posts.
Comply with for updates.
Teri Radichel
For those who favored this story please clap and comply with:
******************************************************************
Medium: Teri Radichel or E-mail Checklist: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests companies through LinkedIn: Teri Radichel or IANS Analysis
******************************************************************
© 2nd Sight Lab 2022
All of the posts on this collection:
____________________________________________
Writer:
Cybersecurity for Executives within the Age of Cloud on Amazon
Want Cloud Safety Coaching? 2nd Sight Lab Cloud Safety Coaching
Is your cloud safe? Rent 2nd Sight Lab for a penetration check or safety evaluation.
Have a Cybersecurity or Cloud Safety Query? Ask Teri Radichel by scheduling a name with IANS Analysis.
Cybersecurity & Cloud Safety Sources by Teri Radichel: Cybersecurity and Cloud safety courses, articles, white papers, shows, and podcasts
