Unlock the Power of Cloud Governance : AWS IAM Case study
Section 1 : Understanding the Significance of Cloud Governance & Data security
Before diving in, it’s crucial to understand the significance of Cloud Governance in cloud computing. Many cybersecurity experts emphasize that without it, we face significant risks. However, implementing it effectively can also be challenging, especially for those specializing in cloud security.
TL;DR..
Cloud Governance is the backbone of a secure, compliant, and efficient cloud environment. It refers to the structured framework of policies, standards, and controls that govern how cloud services are utilized within an organization. The key aim of Cloud Governance is to ensure that cloud resources are used in a way that maintains high standards of security, compliance, and performance across cloud infrastructures.
One of the most critical aspects of Cloud Governance is Data Protection. Cloud service providers (CSPs) face a growing number of threats, ranging from cyberattacks to data breaches.
Cloud governance requires the adoption of frameworks, principles, and policies to ensure a secure cloud environment. One of the most widely used principles is the principle of least privilege, which restricts user access to only the data and systems necessary for their specific tasks, thereby minimizing the risk of unauthorized access.
Above diagram gives us the main building blocks of Cloud Governance in modern businesses, we can summarize it on :
- Cost efficiency By monitoring and controlling cloud infrastructure, businesses can identify inefficiencies and keeping there costs in check.
- Performance Here performance relates to overall productivity of businesses, by enhancing operational efficiency and also resolving bottlenecks.
- Compliance By adopting Governance frameworks, organizations adhere to policies and standards this ensures minimal risks of non-compliance and legal issues.
- Security in fact Governance models focus on identity and access management (IAM) and security monitoring, which reduce vulnerabilities and protect against cyber threats.
Before exploring this principle further, as it is a crucial element in our discussion, it is essential to first understand the nature of these threats and the motivations behind them.
Threats in Cloud environment
With expansion of cloud services and rapid adoption, the threat landscape has evolved, with a notable increase in cyberattacks targeting vulnerabilities in cloud environments. Attackers exploit these weaknesses to steal sensitive data, disrupt services, or even cause irreparable damage.
The threats in cloud environments can generally be categorized into two major types, external threats and internal threats.
External threats can be summarized in Cyberattacks, they are mainly sponsored by Advanced Persistent Threat (APT) groups often targeting sensitive industries and government institutions ,they aim to cause significant damage, often by stealing highly confidential data or disrupting critical services. . Their methods are sophisticated, involving the use of zero-day vulnerabilities, spear-phishing attacks, and other cutting-edge techniques.
Internal threats are various, but the one to whom it may concern the most is Privilege Misuse known as leading cause of data breaches in cloud environments. Whether intentional or accidental, privilege misuse can expose cloud systems to significant risk. It occurs mostly when internal users exploit or exceed their access permissions, leading to the unauthorized disclosure of sensitive data.
If you wonder, what are the motivations for a Privilege Misuse threat ? simply financial gains, but for more sophisticated threats like ones done by APTs they look for gathering sensitive data that can be used against organizations.
Technical measures taken by CSPs
The principle of least privilege is a fundamental security measure employed by cloud providers. It ensures that users are granted only the minimum access necessary to complete their tasks, reducing the risk of unauthorized access or data breaches.
By limiting permissions to the essentials, this approach minimizes potential vulnerabilities and strengthens the overall security framework of cloud environments.
This layered approach not only limits access to sensitive information but also allows for flexibility and precision in managing permissions. it adopts the Permission-based Access approach specifically :
- Restricts Permissions: So access is granted based on user roles, ensuring they only have access to the specific data and systems required for their responsibilities.
- Granular Access Control: This goes further by setting detailed rules and conditions for access, allowing for precise and conditional management of user permissions. we can give and example of giving access to resources in certain interval period for users, or giving access based on department tags in an organization.
The principle of least privilege limits risks by minimizing access, reducing the chances of data breaches, and restricting the impact of both internal and external threats, even in cases of compromised users accounts.
Legal Frameworks
U.S. government frameworks like NIST and FedRAMP are designed to ensure that cloud services used by federal agencies meet high security standards.
In the case of FedRAMP , this framework ensures that cloud service providers maintain a high level of data protection, significantly reducing the risk of data breaches. they emphasis on :
- Least privilege principle
- Zero-Trust Architecture
- Ongoing oversight through continuous monitoring
In fact FedRAMP classifies CSPs into high, moderate, and low impact levels based on the sensitivity of the data they handle. thus CSPs must undergo a rigorous risk assessment before gaining the FedRAMP authorizations.
As we can see, AWS is upon the major CSPs that aligns with FedRAMP regulations, making it a great option for federal agencies and governments entities.
Section 2 : Deep Overview of AWS implementation of the principle of least privilege
In this next section we will be deeping dive into IAM theories, and how it helps providing a framework to encounter threats in there realm.
How IAM works
Before understanding how IAM works, it’s necessary to understand the parties involved,
We have external access through Console, CLI, API/SDK, this access requires having secret access keys.
We can find also Principal which is a person or application that can make a request for an action or operation, or an AWS resource, by specifying certain policies.
Based on defined Policies , AWS determines whether to authorize a request (Allow/Deny).
Finally AWS Resources which corresponds to Compute, Storage, Network,..
Users, Groups, Roles, Policies
Users, Groups, Roles, Policies are the buidling blocks of IAM workflow.
Policies define the permissions for the identities or resources they are associated with.
The User gains the permissions applied to the group through defined policies.
So policies especially identity-based policies define and group certain users into a group that share the same responsibilities in certain AWS resources.
IAM Users
Users are one of the main resources in AWS, they represent in an organization a certain employee or even a certain application.
Basically each user has an account, they can access there account using a root user that has full permissions.Up
One of the best practices is to avoid using the root user account, and enable MFA.
- Up to 5000 individual user account can be created for a user.
- Users has no permissions by default.
IAM Authentification methods
There is two basic ways to authenticate to AWS IAM, either by credentials for users accessing through Console, or through Access keys for users accessing through CLI/API.
IAM Groups
Groups are collections of users. “Users can be members of up to 10 Groups”
The main reason to use groups is to apply permissions to users using policies.
The best practice is to gain a user a certain permissions applied to a group, nor directly.
IAM Roles
IAM roles are IAM identities that has specific permissions, these roles are assumed by users, applications, services.
Once assumed the identity “becomes” the role and gain the roles permissions.
IAM Policies
What are policies in AWS ?
policies are documents that define permissions and are written in JSON.
Policies are two types : identity-based and resource-based policies.
the key difference between these policies is identity-based policy can be applied to users, groups, roles, in the other hand resource-based policy are applied to resources such as S3 buckets or DynamoDB tables.
Let’s see the basic structure of each one of them..
- identity-based policy :
{ “Version”: “2012–10–17”,”Statement”: [{ “Effect”: “Allow”, “Action”: “*”, “Resource”: “*”}]}
- permission-based policy :
{ “Version”: “2012–10–17”, “Id”: “Policy23224”,”Statement”: [{ “Sid”:”Stmt1223443", “Effect”: “Allow”, “Principal”: {“AWS”: “arn:aws:iam:515677628892:user/John”}, “Action”: “S3:*”, “Resource”: “arn:aws:s3:::mycompany”}]}
Getting back to IAM Roles, basically as we discussed these roles has there own policy and each role can have two types of policies : Trust Policy and Permissions Policy. a trust policy is also an example of a resource-based policy in which we specify conditions on accessing certain AWS resources in our organization, a permissions policy is an identity-based policy.
Role-based Access Control (RBAC)
RBAC is an extension of groups, in fact through it a user can assume a well defined role and has it’s permissions.
Famous well defined roles :
- Administrator
- Billing
- Developer power user
- Network administrator
- System administrator
- Security auditor
- View-only user
As we said before users are assigned permissions through policies attached to groups.
Role — → Permission — → User
Attribute-based Access Control (ABAC)
AWS implement least privilege principle by adopting the ABAC method, in this case each user, identity, group should emphasise key tags to access data.
So basically, all permissions defined for role are granted to resources when the tag matches a certain values.
Permissions Boundaries and preventing Privilege Escalation
permissions boundaries comes to solve a major threat that exploits AWS resources to a Privilege Misuse threat, it sets the treshhold to identity-based policy and resource-based policy.
How the privilege escalation threat occurs :
- Basically Alice a user has permissions to use AWS IAM only, Alice uses this privilege to create a new User, and assign to them iam:AdministratorAccess , then Alice access AWS through this new user account, resulting into this threat.
Lets see now the scenario of privilege escalation as a diagram.
Evaluation Logic
Now after understanding the basics , that you can apply in your AWS cloud environnement, let’s see the flow of applications for the roles and policies to roles, users, groups..
AWS Organizations
TL;DR..
AWS Organizations is a service in AWS that allows you to centrally manage and govern multiple AWS accounts under one organization.
Basically an AWS Organization consist of multiple parts, we can mention :
- Organization is a group of AWS accounts that are managed within an organization
- Master Account that creates the organization. It has complete control over it, including the ability to create and invite new accounts to join the organization, it also sets it’s policies.
- Member Accounts are accounts that are part of the organization and managed by the master account.
- Organizational Units (OUs) so basically in an organization you can group accounts into OUs. these OUs helps organize accounts by business divisions, teams, or any other group that makes sense for the organization.
- Service Control Policies (SCPs) are policies that applied to organizational units or individual accounts within AWS Organization.
- Consolidated Billing provides the ability to combine billing across multiple accounts, simplifying the process and offering potential cost savings by pooling resources and sharing volume discounts in an organization.
Section 3: Case studies
In this section we will focus on some of the common cases we encounter in AWS role assignment and implementations of RBAC and ABAC to mitigate the risks of threats and align to the least privilige principle.
Use Case : Cross Account Access
In this case, a user in account B will assume a role in account A, and account A will allow account B to assume it.
Use Case : Cross Account Access (3rd Party)
In this case, a user in account B will assume a role in account A using a shared ARN.
Use Case : Delegation to AWS Services
In this case, we will see how a resource en AWS can assume a role, and the sharing of secure keys STS.
AWS Security Token Service (STS) are credentials that helps AWS resources get access to other resources securely.
Use Case : ABAC in AWS
AWS implement least privilege principle by adopting the ABAC method, in this case each user, identity, group should emphasise key tags to access data.
Conclusion
The integration of federal data protection standards into cloud service policies is crucial for advancing cloud security.
We can see the emphasize role of cloud governance in enhancing security through the integration of legal frameworks and technical measures.
CSPs can advance in the field of data protection by focusing on the implementation of the least privilege principle, including tools like ABAC, Zero-Trust Architecture, and condition keys, as we demonstrate there contribution to preventing data breaches.
I hope you did enjoy this masterclass, and you can now discuss about the topics explained here.