Resources To Deploy for an AWS Organization Using a Common Deployment Container

ACM.386 Taking a moment to regroup and think through code migration and re-deployment

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

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: AWS Security | AWS Organizations

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

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

In the last post I finally got my container running my scripts with MFA after some fits and starts trying to do it cross-organization and cross-region.

Sometimes you just need to stop and think a bit.

The following is a list of things I think I need to create or recreate related to the Governance OU and Environment. I skipped over some of this before and jumped over to my Sandbox environment. Now I’m going to revisit all of this and see if I can get it done.

Importing vs. deleting or renaming and redeploying

Now I want to redeploy my governance environment with that container. I need to move my code over from the prior post into the container and run it from there. I don’t think I am going to bother importing existing resources as I did with my organization in this post. If anything has a conflicting name I’ll simply delete or rename it. If you can’t do that, you can leverage the import mechanism I used here.

What do I need to deploy or redeploy?

Here are the things I am going to redeploy with the new naming convention and leveraging the new directory structure. I’ll need to pull over the code I wrote about and created in prior posts. I also need to test this out to make sure it works as I’m envisioning it so there may be changes down the line. It’s based off this earlier post for the most part:

Governance OU

• Any Organizational settings I’m missing from my prior code plus new settings mentioned below.
• An environment script that creates any new accounts in the environment with the account related resources for that environment, run by the OrgAdminRole.
• Governance OU
• Root Service Control Policies: Allowed Regions, DenyAll, Suspended, RestrictUsersToOwnCredentials
• IAM, Governance, and Billing Accounts.
• SSM Parameters (org and env) in each account and every other account created below. All the accounts in this list are part of the “governance” environment. The org name is pulled from the org parameter in the root account.
• A rootadminrole in every account with full admin access that requires MFA and can only be assumed by the rootadmin in the management account.
• OrgAdmin — an account that can assume any role in the “governance” environment to deploy resources that require multiple roles, like a new environment structure. The OrgAdmin can assume any admin role in the OrgAdmin OU.
• IAMAdmin, GovernanceAdmin, BillingAdmin (admins of the three new accounts) with respective groups and a role in each account that can be leveraged by our container. All Admin roles across the organization will require MFA to assume and can be assumed by the OrgAdmin.
• IAM, Governance, and Billing Cross-Account management roles for things the administrators cannot do outside the management account. I have been looking for a clearcut list of what those things are and so far cannot find it.
• OrgAdmin Service Control Policies: An SCP that limits which accounts and roles can perform which actions. This policy gets updated as new accounts and permissions are added below. For example, once I create the KMS account, I restrict creation of all new KMS keys to this account.
• DenyAll OU for accounts in which no actions are allowed.
• Suspended OU for accounts that are closed but have not yet dropped off the list.

Critical Resources OU

As described in the diagram in the post above I want to manage critical resources in particular accounts with Specific Administrators.

• A Shared Resources OU for KMS, Networking, Repository, Domain and Repository accounts
• A KMS Account, administrator, group, role and policies — any new KMS keys I create will go in this account. I’ve done this before but need to revisit and make sure it works the way we want and proper logging gets enabled.
• A Environment KMS Key shared to any account in that environment for use as needed. More granular keys can be leveraged as needed. The environment admin account has access to use the key to view anything encrypted with it in an environment.
• A NetworkAdmin account, administrator, group, role, and policies for deploying network resources. Ultimately networking jobs can run from this account and if there are any shared network resources like Shared VPCs would exist in this account.
• DeployAdmin Account including admin, group, role, and policies — this is the account for deployment jobs that move code between environments like GitHub to CodeCommit or Sandbox to Production.
• Production Repository Account**, admin, group, role, and policies. This account maintains the ECR repository, CodeCommit repository, AMIs, containers, and packages used in production environments. Repositories for the governance environment.
• Sandbox Repository Account**, admin, group, and policies. Same as production repository account but for development and QA. Repositories for the governance environment.

** Note that in a larger environment I’d likely also have QA and Staging repositories but we’ll start with this.

Security OU

• A Security Monitoring Account that can manage security across the organization including any AWS Organizations security related services that span the organization. Delegate any of the AWS Organizations Security services to the Security account.
• Organization Logs and Monitoring Services deployed by or leveraged by security monitoring account. There are certain services that can be leveraged across the organization like CloudTrail and GuardDuty. I need to get these all set up in this account. Where possible the security team will set up these logs and manage them in the Security Monitoring Account. This will be a one stop shop place to view all logs across the organization. I want to check out Security Data Lake but also need to review the cost.
• A separate KMS key for logs in each environment. The Security Admin needs to be able to decrypt any logs throughout the organization. Each Environment Admin needs to be able to decrypt logs in their own environment.
• OrgAdmin SCP: Logging SCP that enforces what logs must be configured for different services when deployed. Also, prevent anyone from deleting or modifying the CloudTrail log configuration once it is in place.
• A Seller account for the AWS Marketplace with related user, group, roles. At some point I will revisit setting up a container on the AWS Marketplace.
• IdP: Redeploy the IdP I set up for interaction with Okta. Create Okta logins for certain users and roles above to login to everything from one place. I still need to review Okta further. As noted previously I do not like that Okta lacks some network features I would like such as AWS PrivateLink integration. Perhaps those features would have helped in recent credential compromise attacks I wrote about in earlier posts, but I need to review all that further.

After that is all setup I want to work on the following:

• Use the common environment script to deploy my Sandbox environment. What is common out of the above resources? The way accounts get created with the admin user and SSM parameters. The repository account access. An environment KMS key for use in all the accounts in the environment. (Again, separate keys can be created for resources as needed, but this base key can be used in some cases to reduce costs for non-critical assets and to make sure the environment administrator can view all those assets, such as logs.)
• Redeploy and all the Sandbox resources with the new code structure.
• Complete my web deployment with an environment KMS key shared from the KMS account (which is part of what led me to another reboot.)
• Okta APIs and automation: I want to review the Okta APIs at some point and see if I can automate things on the Okta side. At first glance I did not like my options but perhaps things have improved.
• Better container security and AMI deployments.
• A production web environment.
• A production project environment.

Phew! I better get to work. I may revise this as things change. I have a lot of this code written already but need to move it to the new directory structure and get it working in my container.

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