What I Learned Building IAM and RBAC on Azure

As part of my Azure learning journey, I recently worked on a hands-on lab focused on Identity and Access Management (IAM) and Role-Based Access Control (RBAC) in Microsoft Azure.

Before this lab, IAM and RBAC sounded like concepts mainly used by cybersecurity and cloud professionals. After working with them practically, I understood that they are really about one simple question:

Who should be allowed to do what, and where?

IAM and RBAC in Plain English

Identity and Access Management (IAM) is the process of controlling who can access a company's systems, applications, data, and cloud resources.

Think of an office building. Not everyone who enters the building should have access to every room. An employee may have access to their department, while the finance team may have access to financial records. The security team may have access to security systems.

Cloud environments work in a similar way.

Role-Based Access Control (RBAC) takes this a step further by assigning permissions based on a person's job or role.

For example:

• A developer may need permission to deploy and manage applications.
• An accountant may only need access to financial information.
• An auditor may need to view resources but should not be able to modify them.
• A junior employee may only need limited access to specific resources.

The important principle is least privilege: give users only the access they need to perform their responsibilities.

What Can Go Wrong Without Proper IAM and RBAC?

During the lab, I realized that access control is not just an administrative task. Poor access management can create serious security and operational problems.

1. A careless or disgruntled employee could delete production resources

Imagine an employee has full administrative access to a company's Azure environment when their job only requires access to a specific application.

If they accidentally delete a production database, virtual machine, or other critical resource, the company could experience downtime or data loss.

RBAC can reduce this risk by ensuring that employees receive only the permissions required for their roles.

2. A leaked password could provide far more access than necessary

Suppose an employee's Azure credentials are stolen through phishing or another attack.

If that account has excessive privileges, the attacker could potentially access or modify resources far beyond what the employee actually needs.

With properly configured RBAC, a compromised account can be restricted to a smaller set of permissions, reducing the potential impact.

3. An auditor could accidentally make changes

An auditor may need to inspect resources, configurations, and activity logs without changing anything.

Giving the auditor an administrative role creates unnecessary risk.

A read-only role allows the auditor to perform their job while preventing accidental configuration changes.

My Azure IAM and RBAC Lab

In my lab, I worked with Azure access control and role assignments to understand how permissions can be assigned to identities and resources.

The practical experience helped me understand that RBAC is not simply about giving someone access. It is about giving the correct level of access to the correct identity at the correct scope.

Lab 1 – Azure IAM/RBAC configuration

Lab 2 – Role assignment / access verification

One of the most important things I learned is that permissions can be managed at different scopes, such as a subscription, resource group, or individual resource. This makes it possible to provide access without automatically giving someone control over the entire environment.

Why IAM and RBAC Matter to a Company Like Flutterwave

IAM and RBAC become especially important for companies that handle financial transactions, payment information, and customer data.

A company such as Flutterwave operates in an environment where cloud infrastructure and business systems can contain highly sensitive information and critical services.

Consider what could happen if a privileged employee account were compromised.

If that account had unnecessary administrative permissions, an attacker who obtained the credentials could potentially use those privileges to access or modify resources beyond what was required for the employee's job.

This is why security teams use principles such as:

• Least privilege
• Role separation
• Multi-factor authentication
• Regular access reviews
• Privileged access management
• Monitoring and auditing of user activity

IAM and RBAC do not eliminate every security threat, but they help reduce the blast radius when something goes wrong.

Key Lessons From the Lab

My biggest takeaways were:

1. Access should be based on job responsibilities.
2. Users should receive the minimum permissions they need.
3. Administrative access should be carefully controlled.
4. Read-only access is useful for users who need visibility but should not make changes.
5. Regularly reviewing permissions is just as important as assigning them.
6. Good IAM and RBAC can limit the damage caused by compromised accounts.

Conclusion

Building IAM and RBAC in Azure helped me move from understanding these concepts theoretically to seeing how they work in a real cloud environment.

The biggest lesson for me is simple:

Don't give everyone a master key when they only need access to one room.

Good identity and access management helps organizations protect their infrastructure, reduce accidental changes, limit the impact of compromised accounts, and maintain better control over their cloud environment.

For companies handling payments and customer information, access control is not just a technical configuration. It is an important part of protecting the business and the people who trust it.