Cloud Security: Identity and Access Management (IAM)

Identity and Access Management (IAM) is a framework of policies, processes, and technologies that ensures the right people (identities) have the right access to the right cloud resources at the right time, for the right reasons. It is the digital version of the office building key card system.

At its heart, IAM answers three questions: Who are you? What are you allowed to do? And are you actually doing what you are allowed to do? To answer these, IAM relies on three core concepts: authentication, authorisation, and accounting (often called AAA).

Authentication is the process of verifying that you are who you claim to be. It is the 'who are you?' question. You prove your identity using something you know (a password), something you have (a phone with an authenticator app), or something you are (your fingerprint). When you log into a cloud provider like AWS, Azure, or Google Cloud, you authenticate first. The cloud checks your username and password. If they match what is stored, you are authenticated. This is the same as showing your photo ID to the security guard.

Authorisation happens after authentication. It answers the 'what are you allowed to do?' question. Once the cloud knows who you are, it checks a set of rules — called policies — to determine what actions you can perform. For example, you might be authenticated as an employee, but your policy says you can only read files in a specific storage bucket, not delete them. You cannot delete the bucket because the policy does not allow it. Authorisation is the lock on the server room door checking your badge.

Accounting (or auditing) is the third piece. It is the process of keeping a record of who did what, when, and where. Every action you take — every file you upload, every virtual machine you start — gets logged. This is critical for security investigations and for meeting compliance requirements. If something goes wrong, you can look at the logs to see exactly which identity performed the action.

IAM introduces two fundamental types of identities: users and groups. A user is a single, unique identity for one person or application. A group is a collection of users. Instead of assigning permissions to every user individually (which is a nightmare to manage), you assign permissions to a group, and then add users to that group. If someone joins the sales team, you add them to the 'sales' group. They automatically inherit the permissions needed for sales. If someone leaves the sales team, you remove them from the group. This is called the principle of least privilege: giving a user only the minimum permissions they need to do their job.

Another critical identity concept in cloud IAM is the service account (sometimes called a 'service principal' or 'system-assigned managed identity'). A service account is an identity created for an application or a service (like a script, a virtual machine, or a serverless function) rather than for a human. For example, an automated backup script needs permission to read a database and write to a storage bucket. You do not give the script a human username and password — that would be insecure. Instead, you create a service account, attach the necessary permissions to it, and configure the script to authenticate using that service account.

Permissions are granted through policies. A policy is a document that explicitly states what actions are allowed or denied on which resources. In cloud IAM, policies are often written in a structured language like JSON. A typical policy might say: "Allow user 'Alice' to 'read' objects in 'bucket-123'." Or: "Deny everyone from 'deleting' the 'database-server'." Policies can be attached to users, groups, or directly to resources.

One of the most important things to understand for CV0-004 is the difference between 'allow' and 'deny' in policies. Most cloud IAM systems use an explicit deny model. This means that if something is explicitly denied by a policy, it overrides any other allow. In other words, even if you have a policy that says 'allow everything', if there is another policy that says 'deny delete on this database', then the delete action is denied. This is a safety mechanism. Also, by default, all actions are implicitly denied. That means if you do not explicitly allow something, it is denied. You must explicitly add an allow statement to grant access.

Finally, IAM replaces older, less secure ways of managing access. In traditional on-premises data centres, you might have had a single shared admin password that everyone used. That was terrible for security because you could not trace who did what. IAM gives every identity its own credentials and its own audit trail. It also enables centralised access management across multiple cloud services. Instead of setting up a separate login for each database, each server, and each application, you define all access in one central IAM system. This is called single sign-on (SSO), but SSO is just one feature of a broader IAM strategy.

Imagine you work as a junior cloud administrator for 'GreenLeaf Organics', a company that sells organic food online. Your boss hands you a new task: you have just received a request from the marketing department. They need a new cloud storage bucket to store promotional video files. Your real-world job is to create a secure, IAM-managed solution that only the marketing team can access.

Here is the step-by-step of what you actually do:

First, you log into the cloud provider's console using your own IAM user account. Your account has administrative permissions, which were granted by a senior admin through a custom policy that says 'allow all actions'. You know this is a very powerful account, so you only use it when necessary.

Second, you open the IAM dashboard and create a new group called 'marketing-team'. You attach a policy to this group that allows read and write access to a specific storage service. You do not attach a policy that allows deleting the storage itself, because you want to prevent accidental deletion.

Third, you create a new storage bucket called 'greenleaf-marketing-videos' and configure it with a bucket policy. This bucket policy specifically allows access only to the 'marketing-team' group. It also denies access to any IP address outside of the company's office network. This is a combination of identity-based policy (the group policy) and resource-based policy (the bucket policy).

Fourth, you add the marketing employees to the 'marketing-team' group. You do this by finding their existing IAM user names in the directory and clicking 'add to group'. You do not need to touch their passwords or their existing permissions. They just inherit the new storage permissions.

Fifth, you test the setup. You log out of your admin account, log in as a test marketing user, and attempt to upload a video file to the bucket. It works. Then you try to delete the bucket itself. The delete fails because the bucket policy denies it, and the group policy never granted it. Finally, you log in as a user from the finance team and try to access the bucket. The access is denied.

You also set up logging. You enable 'cloud logging' on the bucket to track every read and write action. This way, if a video file goes missing, you can check the logs to see exactly who accessed it and when.

The key actions you perform as an IT professional include:

In a real enterprise, you would also be responsible for integrating IAM with an on-premises directory service (like Microsoft Entra ID) using federation, but for a beginner, the core skill is creating users, groups, and policies.