February 5, 2024

Cloud Governance Guardrails: Identity Access Management (IAM) and Resource Configuration Management

Whatever your growing cloud project is, at a certain point one thing will become crystal-clear: as your cloud grows, so does the complexity and risk. This is why, when a project really starts to take flight, it’s important to reassess the way your team works and how you manage it.


With a growing workload, the temptation may be to accelerate development by adding more developers to your team – however there’s a limit to what this can achieve. New team members can take time to settle-in and learn the ropes; the larger your team, the more active management is needed.


So a larger team doesn’t necessarily speed things up, and it often does the opposite; without everyone working harmoniously, a larger team will increase your costs and add new layers of risk and complexity.



Achieving the balance between speed and safety


The best strategy is one that seeks to minimize the size of your development team while ensuring they have the freedom to work as quickly as they are capable. And this must be without sacrificing security, stability, or compliance of your cloud.


Cloud Governance Guardrails are essential for this. By taking a little time to set up and configure these correctly, you can save a lot of headaches (and time) further down the road.


In addition to organization policies and guardrails for network access, there are two closely linked areas that require protection by a robust framework of tools and policies: user access and resource management.


These two areas are fundamental to maintaining your cloud as it grows. With properly configured measures in place, you can give your team the freedom to work fast, knowing they can rely on Cloud Governance Guardrails to keep everything the way it should be.



Identity and access management: how to do it right


The role of identity and access management (IAM) in maintaining a secure cloud environment is often underestimated. It might not seem like a big deal when your team is smaller, but it’s indispensable as you grow.


Using multiple accounts is perhaps one of the simplest and most powerful guardrails you can put in place. It ensures that access to resources is only given to the specific groups that need them, without needing to set up a million different access assignments. This partitioning works well alongside AWS Organization service control policies, which can give more fine-grained control by enforcing a ‘deny’ for specific accounts or groups (Organizational Units).


As always, you should pay careful attention to IAM cloud governance best practices as well as ‘standard’ measures, like ensuring inactive accounts are removed and using strong, unique passwords.


With all measures, you should seek to adopt and enforce a ‘least privilege’ principle, so credentials can only give access to limited resources as defined by absolute necessity.  



How to use AWS IAM and AWS Identity Center effectively


You have a lot of ways to install guardrails and other checks and balances with AWS Identity and Access Management (IAM) and AWS Identity Center. These can help cover all the angles with fine-grained controls and policies.


Building on the strength of using multiple accounts to group resources (and access) in a rational way, these can give peace of mind as your cloud becomes more complex and visibility decreases.


We recommend using the following identity access guardrails:

1. Permission boundaries - Properly configured permission boundaries help to prevent accidental access privileges, and can prevent privilege escalation by only granting access when both the identity-based policy and permission boundaries agree.

2. Temporary access credentials - To limit the liability that can come from needing temporary access to a resource, you can grant temporary access privileges in AWS IAM. This limits the potential for misuse and allows you to grant access without needing to create an AWS identity. Using the AWS Security Token Service (STS), these are generated dynamically, last a short (defined) time, and can’t be reused. Handy when you need them.

3. Permission sets - These can greatly simplify access management by allowing you to create templates for different user types, based on their role or other criteria.   


4. Access control lists - Access control lists (ACLs) define which AWS accounts can access objects and buckets. This is ideal for controlling access on a per-object basis.


5. Service control policies - You can define service control policies (SCPs) in AWS Organizations, and these enable you to set maximum access privileges for member accounts in your organization. It’s worth doing this incrementally, and using CloudTrail to check service usage before implementing these to avoid accidental lock-out.


Resource configuration management with AWS Config

As well as guardrails based on IAM users and roles, you also need to create a set of policies that enforce good resource management. Thankfully, AWS Config has a lot of tools that can help you manage the scalability and security of your cloud.

As well as keeping tabs on configuration changes (which might lead to vulnerabilities or other problems), AWS Config helps to identify and evaluate issues, and provides a simple route for resolving problems too.

AWS Config gives you a clear dashboard (accessed via AWS Management Console) showing an instant snapshot of resources, rules, conformance packs, and compliance states. You can also see the details of how resources are linked, and their past configurations.

Altogether, it’s a pretty powerful way to gain visibility over something that’s highly complex and in constant motion.



5 most important features of AWS Config for resource configuration management:


1. Configuration history for resources and software - If compliance is an issue (and even if it isn’t), then you need to have an auditing capability for resource management, so you can demonstrate compliance.

2. Tracking of resources/relationships - AWS Config maps out the relationships between resources, so you have a detailed understanding of how they’re linked.

3. Configurable rules - AWS Config offers both ‘Managed Rules’ and 'Custom Rules’. Managed rules are highly customizable, but in case you want to write one from scratch, you can.

4. Conformance packs – These help to monitor compliance by creating a collection of rules that can be applied as a single package. These can be implemented for an account, a region, or an AWS organization.

5. Aggregation across accounts and regions – AWS Config aggregators can centralize visibility over single and multiple accounts, across multiple regions.


Customizing and extending AWS Config to GitHub (and more)

In addition to the above, you can also use advanced querying to discover the configuration states of your AWS resources on demand, and generate configuration snapshots for a defined point in time.

In fact, there are a lot of features that AWS Config offers, but the greatest benefit comes from it being wrapped up in a single, easy to use tool for the centralized management of resources. This makes a complex task much easier and less stressful.

To top it off, AWS Config is also quite customizable and extensible, with the ability to monitor the configuration states of third-party resources like GitHub. You can also integrate it with a wide variety of services from AWS and specialized AWS Config Partners.

With the right guardrails in place for IAM and resource configuration, as well as organization policies and guardrails for network access, you can protect the integrity of your cloud with a minimum of burden. This is essential for giving your developers a ‘free rein’ to use their creativity and expertise, without too many restrictions or barriers.


Need advice?

‍Experience goes a long way. Especially when it comes to knowing shortcuts and avoiding common pitfalls. 

If you want help, advice, or pointers for setting up the best policies and guardrails for your cloud, we’re here for you.

Lets’s fly together! Contact us
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.