When you move to the cloud, you're not just renting servers; you're entering a security partnership. Microsoft Azure operates on a shared responsibility model, which is a simple but critical concept. It outlines what Microsoft is responsible for securing and what you are responsible for securing. Think of it like renting an apartment. The landlord is responsible for the building's security—the main entrance locks, the fire alarms, the structural integrity. But you are responsible for locking your own apartment door and deciding who you give a key to.

Microsoft handles the security of the cloud. You are always responsible for the security of what you put in the cloud. This includes your data, the virtual machines you configure, and, most importantly, who has access to it all. Following best practices like the principle of least privilege—giving users only the access they absolutely need—is your job, not Microsoft's.

The cornerstone of Azure security is identity. Before you can secure a resource, you need to know who is trying to access it. This is where Azure Active Directory (Azure AD) comes in. It's Azure's cloud-based identity and access management service. It's the bouncer at the door of your cloud environment, checking IDs and making sure only authorized people and services get in.

Every interaction with Azure resources is checked against Azure AD. It doesn't just manage users for Azure itself; it can also be the identity provider for thousands of other SaaS applications like Salesforce, Dropbox, and of course, Microsoft 365. This centralization is powerful. Manage a user in one place, and their access is updated everywhere.

If you've worked in IT, you're familiar with on-premises Active Directory Domain Services (AD DS). It’s been the standard for managing users, computers, and policies on corporate networks for decades. While Azure AD shares the "Active Directory" name, it was built for a different world—the world of the internet, cloud services, and mobile devices.

The key takeaway is that they solve different problems. On-premises AD is for controlling your internal network. Azure AD is for managing identity across the web. Many organizations use both in a hybrid setup, synchronizing their on-premises identities to Azure AD to provide a seamless single sign-on experience for users accessing both local and cloud resources.

To work with Azure AD, you need to understand its core structure. At the highest level, you have a tenant. A tenant is a dedicated and trusted instance of Azure AD that's automatically created when your organization signs up for a Microsoft cloud service subscription like Azure, Microsoft 365, or Intune. It represents your entire organization.

Within the directory, you'll find three main types of identities:

Groups are collections of users. Instead of assigning permissions to hundreds of individual users, you can assign them to a group. It simplifies administration immensely. If a user's role changes, you just move them to a different group, and their permissions are updated automatically.

A service principal is an identity for an application or service. When a script or application needs to access Azure resources, it can't log in with a username and password like a person. Instead, it authenticates using a service principal, which has its own set of permissions scoped only to what it needs to do. This is a critical security practice for automation.

Understanding these foundational elements—the shared responsibility model and the structure of Azure AD—is the first step toward building a secure and well-managed cloud environment.