Defining your ADDF architecture
An ADDF instance is only as secure as the AWS account environment it's deployed in. This AWS account environment must be designed to meet the security and operational needs of your specific use case. For example, the security and operations-related tasks and considerations for setting up an ADDF instance in a proof-of-concept (PoC) environment are different than those for setting up ADDF in a production environment.
Running ADDF in a PoC environment
If you intend to use ADDF in a PoC environment, we recommend that you create a dedicated AWS account for ADDF that doesn't contain any other workloads. This helps keep your account secure while you explore ADDF and its features. The following are the benefits of this approach:
In case of a severe ADDF misconfiguration, no other workloads would be adversely affected.
There is no risk of any other workload misconfiguration that could adversely affect the setup of ADDF.
Even for a PoC environment, we still recommend that you follow as many of the best practices listed in Running ADDF in a production environment as possible.
Running ADDF in a production environment
If you intend to use ADDF in an enterprise production environment, we highly recommend that you consider your organization's security best practices and implement ADDF accordingly. In addition to your organization's security best practices, we recommend that you implement the following:
Create a long-term, committed ADDF DevOps team – ADDF needs to be treated as a custom piece of software. It requires ongoing maintenance and care by a dedicated DevOps team. Before starting to run ADDF in a production environment, a DevOps team of sufficient size and capabilities should be defined with a full resource commitment, until the end-of-life of the ADDF deployment.
Use a multi-account architecture – Each ADDF instance should be deployed in its own dedicated AWS multi-account environment, without any other unrelated workloads. As defined in the AWS Account Management and Separation (AWS Well-Architected Framework), it is considered best practice to separate resources and workloads into multiple AWS accounts, based on your organization's requirements. This is because an AWS account acts as an isolation boundary. A properly designed AWS multi-account architecture provides workload categorization and reduces the scope of impact in the event of a security breach, as compared to a single-account architecture. Using a multi-account architecture also helps your accounts remain within their AWS service quotas. Distribute your ADDF modules across as many AWS accounts as needed to meet your organization's security and separation-of-duties requirements.
Deploy multiple ADDF instances – Set up as many separate ADDF instances as you need in order to properly develop, test, and deploy ADDF modules according to your organization's software development processes. When setting up multiple ADDF instances, you can use one of the following approaches:
Multiple ADDF instances in different AWS multi-account environments – You can use separate AWS accounts to isolate different ADDF instances. For example, if your organization has dedicated development, testing, and production stages, you can create separate ADDF instances and dedicated accounts for each stage. This provides many benefits, such as reducing the risk of any error propagating across stages, helping you implement an approval process, and restricting user access to only certain environments. The following image shows two ADDF instances deployed in separate, multi-account environments.
Multiple ADDF instances in the same AWS multi-account environment – You can create multiple ADDF instances that share the same AWS multi-account environment. This effectively creates isolated branches in the same AWS accounts. For example, if different developers are working in parallel, a developer can create a dedicated ADDF instance in the same AWS accounts. This helps developers work in isolated branches for development and testing purposes. If you use this approach, for each ADDF instance, your ADDF resources must have unique resource names. This is supported in ADDF pre-supplied modules by default. You can use this approach as long as you do not exceed the AWS service quotas. The following image shows two ADDF instances deployed in a shared, multi-account environment.
Multiple ADDF instances in the same AWS single-account environment – This architecture is very similar to the previous example. The difference is that the multiple ADDF instances are deployed in a single-account environment instead of a multi-account environment. This architecture can fit very simple ADDF use cases that have a very limited scope and multiple developers working on different branches at the same time.
Because SeedFarmer is the single tool that controls deployments for an ADDF instance, you can build any environment and account architecture that fits your organization's deployment strategy and CI/CD processes.
Customize the AWS Cloud Development Kit (AWS CDK) bootstrap process according to your organization's security requirements – By default, AWS CDK assigns the AdministratorAccess AWS managed policy during the bootstrapping process. This policy grants full administrative privileges. If this policy is too permissive for your organization's security requirements, you can customize which policies are applied. For more information, see Custom least-privilege policy for the AWS CDK deployment role.
Adhere to best practices when setting up access in IAM – Establish a structured AWS Identity and Access Management (IAM) access solution that allows your users to access the ADDF AWS accounts. The framework of ADDF is designed to adhere to the principle of least privilege. Your IAM access pattern should also follow the principle of least privilege, should be compliant with your organization's requirements and should adhere to the Security best practices in IAM (IAM documentation).
Set up networking according to your organization's best practices – ADDF includes an optional networking AWS CloudFormation stack that creates a basic public or private virtual private cloud (VPC). Depending on your organization's configuration, this VPC might expose resources directly to the internet. We recommend that you follow your organization's networking best practices and create a custom security-hardened network module.
Deploy security prevention, detection, and mitigation measures at the AWS account level – AWS offers various security services, such as Amazon GuardDuty, AWS Security Hub, Amazon Detective, and AWS Config. Enable those services in your ADDF AWS account and integrate your organization's security prevention, detection, mitigation, and incident-handling processes. We recommend that you follow Best Practices for Security, Identity, & Compliance
(AWS Architecture Center) and any service-specific recommendations contained in the documentation for that service. For more information, see AWS Security Documentation.
ADDF doesn't address any of these topics because the implementation and configuration details heavily depend on the requirements and processes that are specific to your organization. Instead, it's the core responsibility of your organization to address these topics. Commonly, the team that manages your AWS landing zone helps you plan and implement your ADDF environment.
