Multi-Person Process for Updating Domain Names

ACM.238 Protecting one of your most critical assets in the cloud

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: AWS Security | Cloud Governance | DNS

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post I explained why I used tags on some resources associated with the static website I’m deploying.

In this post I’m going to update the NS (Name Server) records on a domain in Route 53 to match the NS records in the Hosted Zone for a subdomain I deployed in this post.

The change I’m making in this post is one of the things I need to do to deploy a static website on AWS hosted in an S3 bucket. You can find all the posts I’ve written on that topic here:

Now as I’ve mentioned before I tend to host my domain names in a separate locked down AWS account.

In order to update the NS records in my domain account, I need a way to run a script against that account. As I mentioned, Domain Name security is very important for your organization, so one of the things I do is create an Service Control Policy that prevents any changes to that account unless I am actively making them.

You can lock down an entire account where the domains are hosted, or if you have multiple things in the account where your domains are hosted, you can lock down the Route 53 domains service.

Here are the AWS CLI actions related to route53domains:

You can see in these sample policies that there are two scopes for actions related to Route53. Some actions such as modifying a hosted domain as I showed you in a prior script fall under route53. The actions related to domains I would further lock down are related to route53domains.

This policy looks risky without MFA! route53domains is he riskier line. As I showed you in a prior post, the hosted zone doesn’t work until the route53domains record is updated to match. There are a few other reasons why you should not leave NS records hanging around on domain names that you aren’t using which I may get to later.

Here is the full list of IAM actions related to route53domains from the IAM documentation that you might want to block except under special circumstances.

Just-In-Time access for domain name changes

In order to make changes to my locked down domain names, I need to unlock that security prior to running any scripts to update the domain name. The process, if you choose to follow it, in a large organization might look something like this, if changes are very infrequent:

• The domains account exists in an OU that disallows all actions.
• When someone needs to make a change, the account is moved to an OU where they can make changes.
• Once the changes are complete, the account is moved back to the OU where changes are disallowed.

Alternatively, you could have a process for removing and reapplying an SCP when changes need to be made. An inadvertent change in that regard might be harder to identify at a glance. An account that is in the wrong OU will be much more obvious. I would not recommend modifying SCPs.

WARNING: If anyone can trigger these changes and move the account to a different OU by running a script or triggering an automated process, then your domains are not very secure. The goal is to have two completely separate people with different MFA devices involved in the process if possible — one to move the account and one to change the domains. That way access to a single set of credentials or session will not lead to instant compromise.

Check out these posts for more on the keys to the kingdom problem and session compromise.

These types of changes, when triggered manually, should be limited to people who understand the implications and have the appropriate permissions.

Alternatively, and better to help prevent errors or abuse, you could have a locked down automated process. The process could look something like this:

• Developer who wants to deploy a new static website kicks off the process by filling out a web form and submitting a request.
• Request goes to business or application owner queue who approves the new site by pushing a button.
• Request goes to DNS Admin who uses the request to submit a request to edit the domain for a certain period of time.
• Governance Admin receives and approves the request which automatically moves the account into the OU that allows the DNS Admin to make changes.
• After the DNS admin is done they close the ticket and the account is automatically put back in the locked OU.
• If the DNS Admin is not going to finish in the required amount of time, they can request more time.
• If time runs out the account automatically moves back to the locked down OU.

Hopefully I’ll have the time to automate and demonstrate the above later to show you what I’m thinking on this subject with some code. However, at the moment, it’s me myself and I, and I’m going to put the steps all into one script with different CLI profiles, but know that is not exactly how I would do it in a larger organization with more time. For my single user use case, I can use a separate user and credentials with a different Yubikey and a very short session when making DNS changes.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab