Setting Permission Boundaries is considered one of the critical components of cloud security. It involves defining the maximum permissions that users or groups can have within a cloud environment. This helps prevent unauthorized access and reduces the risk of data breaches. Permissions boundaries are set at different levels, such as for individual users, groups, or roles.
In today’s blog let us dive deeper and understand the process of setting AWS permissions in a large cloud environment and building strong security foundations.
What is a Security Boundary?
Security Boundary refers to the perimeter or barrier that separates a trusted network or system from an untrusted environment. The term “perimeter” is often used interchangeably with “boundary.”.
In the context of cloud computing, the security boundary can be both physical and logical. Physical boundaries include network firewalls and physical access controls, while logical boundaries encompass security policies, access controls, and encryption mechanisms.
The security boundary in a cloud environment defines the maximum permissible permissions for users or resources. It’s a logical separation that can be set at the network level or IAM level.
- Network boundaries: These define the network segments or zones within a cloud environment.
- IAM boundaries: These restrict the permissions granted to users or groups within the cloud environment.
Permissions boundary in a nutshell
Credit: Kushagra Sharma
Differentiating security boundaries and security baselines
It has been observed that people often confuse security boundaries with security baselines. When we asked Kushagra (in our Scale To Zero podcast) to shed some light on the topic and educate us on the minute differences, Kushagra made it easy and consumable for all of us! Below are the key differences.
- Scope: Boundaries focus on the maximum limits, while baselines establish the minimum requirements.
- Relationship: Baselines are generally broader in scope, encompassing various security controls, while boundaries are often more specific to particular aspects of the environment (e.g., network, IAM).
- Intersection: Security boundaries can be considered a subset of security baselines, as they contribute to establishing the overall security posture.
Setting up the basics - Challenges with IAM management
All of us must have heard security leaders speaking out loud at least once in a meeting, “When it comes to the security of large cloud environments, the game often boils down to identities.”. The old-aged debate between IAM and cloud security never ends! When it comes to large cloud environments and IAM, here are a few challenges with IAM management;
- Myriad compliance requirements: The complexities of adhering to numerous compliance standards and regulations.
- Evaluating effective permissions gets complicated for cloud developers: Developers are not security practitioners and thus are not aware of implementing required and best security practices.
- Difficulty keeping up with new cloud services: Major cloud providers like AWS, Azure, or GCP continuously update their systems.
- Security teams end up operationalizing. They often are bogged down in day-to-day tasks, limiting their ability to focus on strategic initiatives.
- You often hear “security creates friction”: Security measures can sometimes hinder business agility and innovation if other business units are not collaborating effectively.
Is a one-size-fits-all permissions boundary possible?
Building a one-size-fits-all permissions boundary that addresses AWS account-level exceptions, Allowing only “vetted” AWS services deployments, regulatory requirements, a growing number of AWS accounts, etc can be cumbersome.
Booking.com came with a unique approach for permissions boundary added Kushagra. He shares 4 real-time steps of their “Flavoured approach to permissions boundary” method. The steps are as follows;
- One dynamic boundary includes global defaults that are defined by security teams.
- Allow exceptions to the boundary on per account level.
- Enable developers to contribute to the boundary moving towards a self-service IAM model.
- For environments falling under the regulatory scope, it is recommended to have a “new flavor” of the boundaries.
To implement the permission boundaries using Terraform, you can also define a hash map to specify expectations for Regions, IAM Actions, and allow AMI owner IDs for deploying vendor tooling.
Basically, a layered approach to security baselines, combining a global baseline with environment-specific permission boundaries. This allows for flexibility and scalability while maintaining consistency across different accounts. A standardized template or boilerplate can be used to dynamically generate permission boundaries based on specific context, ensuring a consistent and efficient approach. This approach helps avoid the complexity and maintenance challenges associated with having multiple siloed baselines
Leveraging Threat Intelligence for building a strong security foundation
Organizations should understand that defining and maintaining security baselines is not a set-and-forget practice. Especially in the cloud environments and large organizations, where new services and features are constantly being produced. Below are the key points to cater to the importance of leveraging threat intelligence to inform and refine the baselines:
- Integrating threat intelligence: Threat detection and response teams provide valuable insights into real-world threats and vulnerabilities.
- Baseline refinement: By analyzing threat intelligence, security teams can identify and address potential risks, leading to continuous improvement of the baseline.
- Constant monitoring: Security teams need to stay updated on new AWS services, existing service features, and IAM namespace changes.
- Multiple Sources: Threat intelligence can come from various sources, including public announcements, blogs, podcasts, and internal security teams.
The above key points highlight the critical role of threat intelligence in ensuring that security baselines remain effective and relevant in a dynamic cloud environment.
Effective strategies for defining strong permissions boundaries
When it comes to defining permissions, the very first thing that comes to mind is Identities. However, in the case of testing a new service, a developer might have to undergo all the security checks, which can be a cumbersome process. That’s where the flavored permissions boundary - which we have explained earlier in the blog, comes in.
Organizations should also consider designing Service Control Policies (SCPs) that can be applied to all IAM entities within a specific AWS account or organizational unit (OU). They are designed for non-negotiable controls. To move things a little faster, we also recommend automating the process of creating and modifying permission boundaries using IaC. This streamlines the workflow and reduces the risk of human error.
The benefits of following such an approach are;
- Enhanced Security: By using both permission boundaries and SCPs, organizations can establish a robust security posture while maintaining flexibility.
- Improved Efficiency: The use of automation and dynamic permission boundaries can streamline workflows and reduce the time required for security approvals.
- Empowered Developers: Developers can experiment and innovate without compromising security, leading to increased productivity and agility.
Defining permission boundaries when migrating from legacy systems to the cloud
Migrating from legacy systems to cloud environments keeping security in mind remains a challenge for almost every organization. Experts recommend starting with defining relaxed permission boundaries during migration and gradually tightening them as your environment stabilizes. There are a few other areas that organizations should prioritize, let us take a look at them;
- Leverage Flavored Permission Boundaries: Use different types of permission boundaries to cater to various environments, including legacy systems, regulatory requirements, and specific use cases.
- Refactor and Optimize: Re-evaluate the existing environment to identify opportunities for optimization and leverage cloud-native features.
- Centralized Deployment: Ensure a centralized mechanism for deploying and managing permissions across multiple accounts to facilitate efficient migration and ongoing management.
Along with the above-mentioned methods, stick to the basics and remember to conduct risk assessments, data classification, continuous monitoring, and training. Here’s what your overall strategy for migrating from legacy systems to the cloud should look like;
- Assess the Legacy Environment: Understand the current security posture, data sensitivity, and compliance requirements.
- Define Permission Boundaries: Create appropriate permission boundaries based on the identified needs and risks.
- Migrate Gradually: Implement a phased approach to migration, starting with less sensitive data and gradually increasing the scope.
- Refine and Optimize: Continuously review and refine permission boundaries as the migration progresses and the environment evolves.
- Implement Monitoring and Auditing: Establish robust monitoring and auditing processes to detect and respond to security threats.
- Provide Training and Awareness: Educate employees about security best practices and the importance of following established policies.
What if a specific cloud provider feature does not align with your defined security baselines?
For the sake of clarity and understanding, let us assume that AWS rolls out a new feature that does not align with your security baselines. It is not recommended to follow an approach where you deny a specific set of services and allow the rest. Why? Because this approach allows every other service without undergoing your security review cycle.
What experts recommend is to follow a “Safelisting” approach to manage your production environment’s security. To make it more simple, create a whitelist of all the approved cloud services and features. And only allow those that are explicitly on this list to be used within the organization’s cloud environment.
What are the benefits of safelisting?
- Controlled Environment: By limiting the services used, organizations can better manage the risks associated with their cloud infrastructure, especially referring to the production cloud environment.
- Proactive Security: It allows for proactive threat handling as only approved services are deployed, reducing the potential for unauthorized or risky activities.
- Baseline Alignment: Safelisting can help ensure that the organization’s security baseline is aligned with the services in use.
Guidelines for implementation and maintenance
- Create the List: The first step is to carefully identify and compile a list of cloud services or features that are deemed necessary and secure for the organization’s operations.
- Regular Review: The list should be regularly reviewed and updated to account for new services, changes in existing services, and evolving security threats.
- Threat Handling: For each approved service, organizations should implement appropriate security controls and threat-handling mechanisms.
- Continuous Testing: Regular testing of security controls is crucial to ensure their effectiveness, provided that you don’t miss to identify any vulnerabilities.
While safelisting provides a structured approach, it can sometimes limit flexibility. Thus, organizations need to balance security with operational needs. As new cloud services and features are constantly introduced, the safelisting process needs to be agile to accommodate them without compromising security.
Where the “safelisting” approach can be proved as a valuable strategy that provides numerous benefits. It is essential to strike a balance between security and operational needs and to continuously review and update the safelisting process to adapt to the evolving cloud landscape.
Conclusion
Setting up effective security boundaries is crucial for safeguarding cloud environments, especially in large organizations with complex infrastructures. By understanding the nuances of permission boundaries, leveraging threat intelligence, and implementing best practices, organizations can establish a robust security posture that protects sensitive data and mitigates risks.
Similar Resources
People Also Read
- AWS IAM Permission Boundary and Why You Shouldn’t Ignore It
- Comprehensive Guide to Threat Modeling
- A Guide About Priorities For Chief Information Security Officer (CISO)
- Top 18 Challenges of Cloud Security in 2026
- What SMBs Owners need to know about Cloud Security?
- Cybersecurity For Every User
- The Different Types of Protection your Application Needs If Hosted in AWS
- Top 15 Cloud Misconfigurations in 2026 - How to Fix Them?
