Last updated on March 3rd, 2023 at 11:40am
A Cloud Management Horror Story
Here’s a typical story about cloud management today.
Let’s say you're running a cloud operations team and receive a request from Jim. He's trying to get a new AWS account for a brand new app that his team is building. This type of request often spawns many tickets.
In some instances, you might have to put a ticket in with your cloud reseller to provision the new account. Next, you’d go to your cloud security team to set up baseline services like AWS CloudTrail or AWS CloudWatch. Maybe your ticket goes to your identity team to make sure you're creating IAM users and roles and configuring and applying baseline policies. After that, your networking team needs to set up a VPC and security groups.
After three tickets handled by three separate teams, you're finally able to go back to Jim and say, "here you go." Then Jim comes back and states that he needs to be able to connect to his on-prem infrastructure. Now you must create two additional tickets and you need two more teams to set this up and, of course, Bob is the only person on the team that knows how to connect the VPC to your on-prem infrastructure, and he is out of the office and won’t be able to get this done until the following day.
Fast forward a week later. You’re checking your morning emails and see you’ve received a report of compliance issues in Jim's account that you provisioned last week. You see he's trying to use Amazon Kendra to make a search capability easy in his new app.
You call Jim and explain that Amazon Kendra is not a service approved to run in FedRAMP high workloads. You then walk him through how to tear down the infrastructure he and his team have spent the past two weeks creating.
The following week, you notice Jim’s account is at the top of your daily report of cloud accounts that have been flagged for overspending their budget. Jim spent $50,000 in the past two days. How? You call Jim up, explain the situation, and realize Jim left the cluster up over the weekend.
Obviously this is not a story with a happy ending.
What if we reimagined cloud management to reduce these roadblocks, while still building in the needed controls for your organization?
Last year, our CEO, Brian Price, answered this question during his breakout session at the AWS Public Sector Summit. Read on for his four recommendations you can use to help write a cloud management story with a happy ending.
Cloud Management With a Happier Ending
Realize One-Way Doors Are Few
First, let's first talk about one-way and two-way doors and cloud management and governance.
Whether you're new or experienced in managing cloud environments, you're likely to make mistakes and some mistakes can be debilitating. Individuals who make mistakes can also have a fear of making more, preventing them from making timely decisions. Our advice: don’t fall prey to analysis paralysis. Most decisions you confront in the cloud are two-way doors. Think of one-way-door decisions as almost impossible to reverse, like quitting your job. Two-way door decisions, like making a change to a pricing model, are easier to reverse.
When designing your cloud management strategy, you might encounter one-way door decisions from time to time, and these decisions can be difficult to unwind or change. For example, an important first step in a one-way door decision would be correctly setting up your centralized auditing and logging as part of your landing zone, maybe through a service like AWS Control Tower, so you have the full provenance of actions that happened inside of all the cloud accounts inside your organization. However, waiting until you have the full set of preventative controls that you need to be implemented in your compliance standards isn’t something you’d have to make sure you’ve got implemented. You can run checks first and see how far you stand from those baselines.
It’s important to be careful in finding the balances around one-way doors. Make sure your one-way doors are needed and are not preventing you from making progress in the cloud.
Consider Your Accreditation Boundary
This is a big one we see across almost every customer environment. It's especially important in the U.S. public sector.
While we’ve seen some agencies get authority to operate (ATO) for the entirety of their AWS environment so that any workload can fall underneath one giant accreditation boundary, this doesn't usually give organizations a lot of flexibility and granularity if something changes. On the other side, we’ve seen customers take a completely different approach where they've accredited every single app and system.
We’ve found the best approach for this is to meet in the middle. Think of this process as layers of cake:
- The bottom layer is essentially everything you're going to use in every single environment and account that you could possibly have.
- The next layer is a set of controls that are satisfied by shared services that you've deployed in your environment that everyone or every tenant can take advantage of.
- At the top of the cake, you have a small layer of actual controls that need to be satisfied because of their unique per-application workload.
This layered approach will reduce the workload that your individual tenants need to actually get into the cloud and be effective along the way. Making the ATO process more efficient can yield quick accreditations and help streamline workflows.
Remember: Least Privilege is Best Practice for a Good Reason
It’s easy to over-provision cloud access, forget who has access, and forget to revoke access. To prevent over-provisioning accounts, it’s important to get this set up at the beginning of your cloud journey and have account provisioning as automated as possible. As you begin to add more accounts and resources, this process becomes completely automated.
We recommend using a multi account strategy to help with this challenge. A multi-account strategy can limit the blast radius from both security and financial perspectives, so if an incident does occur, it doesn't impact every single application across every cloud environment. This is critical when it comes to least privilege access so you can quickly adjust permissions and specific roles across accounts, as well as the underlying IAM policies, that were overly permissive.
Know That Exemptions Will Be Needed
There is no “one size fits all” when it comes to the cloud and it’s impossible to plan for every single scenario and every workload, like Jim's new app, that needs to run in the cloud. It’s important to find a flexible process that can grant rights to certain individuals in certain roles on certain types of projects at certain times.
You need to walk through how you plan on providing exemptions. Are they based on security baselines or are they based on whether the service, like in Jim's example, is trying to use Amazon Kendra, which hasn't officially been approved? Sometimes it's based on where the application lives in the organization or maybe its type. Is it internal or external? It's important to think about not just the what, but the who. Who has the approval to actually provide that exemption?
We've all heard the cloud management horror stories. These four recommendations can help you achieve a happier ending in your journey to a well-managed cloud.
To get Jim's story in video format, check out the replay of our AWS Public Sector Summit presentation, and if you have questions about how you can implement these four points with Kion, we're here to help. To transform your organization with effective cloud management, and go farther, faster in the cloud, schedule a demo with us.