Infosys implements AWS Control Tower to enforce multi-account governance

Today, most enterprises adopt a multi-account strategy on AWS as their workloads scale and become more complex. Because the number of AWS accounts can grow quickly when you use a multi-account strategy, you need mechanisms to govern these accounts and standard guardrails to enforce controls across them. In this blog post, we are going to talk about how Infosys implemented AWS Control Tower to securely govern their multi-account AWS environment.

Infosys, a global leader in next-generation digital services and consulting, has a workforce of more than 240,000 employees across the globe who provide business consulting, information technology, and outsourcing services. Infosys adopted a multi-account strategy because there are multiple teams who run and manage their workloads on AWS independently. Infosys has a central IT team and an information security team that are responsible for setting the standards and governing these AWS accounts.

Infosys set up AWS Control Tower to meet these key objectives:

• Adopt cloud agility without compromising enterprise security and safety.
• Provide self-service ability for the creation of AWS accounts.
• Enforce security baseline controls as guardrails centrally across an organization created in AWS Organizations.
• Provide a centralized dashboard for monitoring the guardrail compliance status of their AWS accounts.
• Provide a shared services model for infrastructure and security.

Onboarding existing AWS accounts to AWS Control Tower

When Infosys adopted a multi-account strategy, the workloads were spread across AWS accounts that were part of a partner-managed organization created in AWS Organizations. There was no centralized governance structure to manage these accounts, so we created a new management account and onboarded the AWS accounts to AWS Control Tower.

If you want to onboard your accounts to AWS Control Tower, here are few things to consider:

• Review the service control policies (SCPs) used in the existing and new target organizations. Ensure that the access control guidelines meet the standards for your enterprise.
• In most cases, customers want to integrate their corporate Active Directory with AWS Single Sign-On (AWS SSO) so that users have seamless access to the AWS management console. At Infosys, the older organization had local AWS Identity and Access Management (IAM) access enabled for its users. The AWS Control Tower setup in the new management account had AWS SSO integrated with their corporate Active Directory. In the first few weeks, we continued to retain the local IAM users on the AWS accounts and started notifying the end users about using SSO to access AWS management console. We planned a graceful cutover to a federated approach for AWS management console access so that the local IAM access on the linked accounts would eventually be phased out.
• Turn off the AWS Config recorder in the accounts to be onboarded. AWS Control Tower will create an AWS Config recorder and delivery channel for governance. This change is required only in those AWS Regions where AWS Control Tower governance is being extended.
• Download all billing details, such as the cost usage report, for the AWS accounts to be migrated to AWS Organizations in the new management account.
• Review the Reserved Instances and savings plan that are applied in your old AWS Organizations’ management account and consider the service consumption in your linked accounts.
• If you have existing trail in AWS CloudTrail, you might want to turn it off to avoid duplicate charges.
• In the case of an existing AWS Organizations setup, if there are nested organizational units (OUs), flatten the OU structure before you onboard them to AWS Control Tower.

For more information, see Enroll an existing AWS account in the AWS Control Tower User Guide.

Account OU strategy

Infosys manages AWS accounts that fall into one of these categories: production, test/development, or innovation sandbox. Each business unit has multiple accounts that belong to these categories. Because these accounts have different security and operational needs, they are grouped into different OUs. Infosys has applied relevant SCPs at the OU level to ensure that the accounts in each unit have uniform policies.

Figure 1 shows the account structure:

Figure 1: AWS Organization account structure

Azure AD integration with AWS SSO

Infosys uses Azure AD for user authentication and wanted to extend the same user experience for accessing the AWS accounts. AWS Control Tower lets you integrate with Azure AD as your external identity provider. To make this work, we configured the AWS Single Sign-On enterprise app on the Azure AD side and enabled automated provisioning on the AWS SSO side. For more information about integrating Azure AD with Control Tower, see this Control Tower authentication and authorization lab.

The automated provisioning feature uses the System for Cross-domain Identity Management (SCIM) standard to populate the users and groups automatically, with appropriate attribute mappings, from Azure AD to AWS SSO. After the users and groups are in AWS SSO, we created standard permission sets in AWS SSO to assign required access permissions to the users and groups for accessing resources in the linked accounts.

Figure 2: SCIM endpoint configuration

Resource tagging

Infosys uses standard tags for AWS resources and it helps them organize their resources better. One of the unique requirements was to add the AWS OU ID for each EC2 instance automatically so that they can use software licenses (such as endpoint agents) running on those instances that are meant for a particular business unit (mapped to OU). We deployed an automation solution that continuously watches for the creation of EC2 instances and adds OU-related tags to them. We used AWS Systems Manager Automation to deploy required software on the EC2 instances.

In addition to standard tags, Infosys has mandatory tags based on workloads and business unit structure such as:

• Business unit
• Owner

These resource tags help them track costs, manage resource access control, and drive automation.

Centralized logging and monitoring

AWS Control Tower lets you consolidate logs from all linked accounts into a centralized log archive account. Anyone who wants to audit the logs can do so from this account. The Infosys security team depends on their SIEM dashboard to keep a tab on key events, so we enabled centralized logging. All AWS CloudTrail and AWS Config files are stored in a central Amazon Simple Storage Service (Amazon S3) bucket of the log archive account. We configured the log ingestion into the Infosys SIEM platform from the S3 bucket in the log archive account.

A security account serves as the designated administrator account for Amazon GuardDuty and AWS Security Hub. The security and compliance team audits and, in case of an incident, performs emergency security operations on this single account. We put automation in place to watch for new account creation events. The automation ensures that Amazon GuardDuty and AWS Security Hub are enabled and pushing the updates to the designated administrator account. The Infosys information security group has exclusive access to this security account so that they can closely monitor dashboards for any security events across all accounts in their organization created in AWS Organizations.

Hybrid DNS strategy

Infosys uses a third-party DNS provider for local DNS resolution requests. To integrate with on-premises DNS, as a best practice, you should configure Amazon Route 53 Resolver endpoints in a shared networking account. We created a Resolver inbound endpoint and configured the on-premises DNS resolver to forward the DNS queries to Route 53 through this inbound endpoint.

For more information about using Route 53 Resolver endpoints for hybrid architecture, see the Using Route 53 Private Hosted Zones for Cross-account Multi-region Architectures blog post.

Enforcing custom baseline security controls

AWS Control Tower provides three types of guardrails: mandatory, strongly recommended, and elective. In addition to built-in guardrails, Infosys has enforced their enterprise security policies in the form of custom controls. Most of the custom controls are deployed in the form of AWS Organizations SCPs and AWS CloudFormation stack sets. We used AWS Control Tower lifecycle events to trigger these automations. The stack sets were used to deploy managed and custom AWS Config rules across all accounts.

We deployed stack sets for these custom controls:

• To enforce Infosys password policy.
• To check if any IAM role has a managed or inline policy with administration or power user access permissions.

Infosys uses AWS Security Hub to run continuous checks for the CIS AWS Foundations Benchmark standard and the AWS Foundational Security Best Practices standard on all their accounts. The designated admin account for AWS Security Hub consolidates the findings and insights from all accounts in their organization. The Infosys information security group exclusively manages this designated admin account to keep track of the security posture of all accounts in their organization.

We also deployed automation to mitigate issues flagged by these custom controls. Here are some indicative remediation actions we automated:

• To disable IAM users who are inactive for certain number of days.
• To check for subnets that have the auto-assign public IP address feature enabled and disable it.
• To ensure versioning is enabled on S3 buckets.
• To ensure S3 logging is configured and the right S3 location is used as log destination.

For network baselines, there is automation in place to create VPC attachments for AWS Transit Gateway.

Integrating with SD-WAN using AWS Transit Gateway Connect

Infosys uses SD-WAN to connect their branch offices and they wanted to extend the same connectivity to their AWS environment. As part of the landing zone setup, we configured AWS Transit Gateway, which helps easily connect multiple VPCs and the Infosys on-premises environment. We used a transit gateway Connect attachment to natively connect the on-premises network to AWS Transit Gateway using GRE tunnels. These tunnels can provide more bandwidth without the need to manage IPsec tunnels.

Figure 3 shows how we extended SD-WAN connectivity to AWS using the Connect attachment:

Figure 3: Extending SD WAN connectivity

Conclusion

With AWS Control Tower in place, Infosys can now govern their AWS accounts and enforce security controls. They have also reduced the manual effort involved in the creation of new AWS accounts because this is now a self-service capability. With designated accounts for audit and security services and built-in dashboards, it has helped Infosys IT and information security group gain visibility of their AWS environment.

About the authors