This is post 5 of 9 in a multi-part series (hosted here) discussing the advantages, pitfalls, deployment methodology, and management of a multi-cloud account architecture. For this series, we are focusing strictly on using AWS as the Cloud Service Provider (CSP) but the concepts discussed port well to any provider or even to on-premise operations.
Not a moment too soon
If you are just starting in the cloud, then there is no better time than now.
If you are already in the cloud with a single account, there there is no better time than now.
The sooner you establish a solid foundation around MAA the better. The deeper you get into the configuration of your security tools (logging, scanning, patch deployment, etc.) the harder it will be to reconfigure these solutions to properly accommodate your new MAA trajectory. Security tools, however, might be the least of your concerns. Let’s go over just a few of the popular reasons to make this architectural decision.
Federation
The moment you have a one-to-many, many-to-one, or many-to-many relationship regarding roles and responsibilities in your AWS account, you need to stop and address MAA. Fine-grained access control is really a key moment in design or implementation where multi-account should be established. Managing credentials like IAM Access Tokens, as well as access to individual resources in the different tiers of your applications, can get very complicated within a single account. Can it be done? Certainly.
Where the difficulty lies is when certain individuals within your account have competing roles and responsibilities. Or when developers also have, but do not require, access to modifying the allocated resources individual services. Just as permissions within an enterprise network, where a particular role/responsibility is granted via membership of a specific security group, the federation of authentication allows you to configured access in a very similar matter.
Configuring federation through the use of Single Sign-on (SS0) solutions not only enhances ease of use for accessing your resources, but it more easily provides for fine-grained access to multiple accounts. By establishing roles through the use of federation you reduce the ability for the accidental assignments of permissions to an individual, minimize the possibility of someone having permissions that allow them to elevate themselves to a level of higher permission, and delegate access to the appropriate resources on an as-needed basis.
The moment you deploy another pair of access keys with a specific set of permissions to an individual or a group of developers, for instance, take a moment to think if this is really the right decision, or if their access should be controlled and managed by the membership of a group that can provide the same level of access to one or many cloud accounts.
Logging & Records
We’ve beaten the security drum pretty hard up to this point so this shouldn’t be a surprise. If your organization has to keep records for any period of time, you must consider MAA. Depending on the industry you may be in or the service you provide you may be required to hold, maintain, and archive access logs, modification records, and customer information of all types for a specific period of time. It’s hard to imagine any more a service that isn’t regulated in this way by some external body.
Creating a separate account for all of your audit, logging, and customer record data is a critical decision point. Maybe you hold HIPPA, PCI, Personally Identifiable Information (PII), or some other form of critical record. This information should have its own account designated for it. Not necessarily an account per data type, but for sure an account dedicated to data storage and protection.
By separating out this type of data from the more generalized application and usage data, you inherently protect it at a much higher degree. It takes intentional and knowledgeable configuration in order to provide access to such data from the tiers of your application deployed within a separate account. While this could increase the chances of misconfiguration due to complexity, good architects can accomplish this very easily. The risk is setting a configuration that is too open when something works and not locking access down to specific resources.
Aside from accidental resource access, you protect critical information from people who 1) does not need to even see it, and 2) could inadvertently manipulate it impacting the integrity of the information. This type of data needs significantly higher levels of protection. By placing it in an account of its own allows you to better manage the disposition schedule of the information more properly and more granularly configure retention policies.
It’s just easier when you know that an account is designated for critical information.
Baselining
Lastly, but of equal importance, is deploying a well-documented and baselined configuration. The ability to leverage multiple accounts for the deployment of identical environments is paramount. If your organization needs to test something or research a new feature, having a solid foundation for MAA greatly increases the repeatability and serviceability of your application. Testing new features or versions of your application or service from within a single account can leave a trail of undocumented resources and configurations. If you (even infrequently) deploy test resources or additional servers for short periods of time, consider MAA.
Baselining can more easily be accomplished when you have an account for dedicated, unchanged, shared, or brokered services. Having a baseline for new or temporary accounts allows you to control and manage, the services that are available that have been vetted for use as well as, through federation (mentioned earlier), control who can use such services and in what capacity.
Honorable mention
When else might you consider MAA? When you have different cost centers and accounting needs. The moment different ‘colors’ or types of money funnel into the funding stream for your service or application, it is time to break out the resources with the funding source. This will save you and your finance department a lot of time, effort, and heartache.
Series parts are as follows:
- Series Introduction
- My experience with Multi-Account Architecture
- What does the end-state look like
- Reasons you might consider multi-account architecture
- When it is right to implement
- What the potential architecture might look like
- How do you get there
- How do you support and maintain the architecture
- Lessons learned
Top comments (0)