Azure Security– Gaining the Azure Data Engineer Associate Certification
Security is the most important aspect of IT. Networks, compute machines, data storage, and so on are important, but a data breach is almost, if not worse, than losing all your data. Knowing about the security products, features, and services that exist on Azure is an absolute must. Although your job as an Azure data engineer might not make you responsible for implementing a security model, it is very important that you can see when something is not secure and know how to approach fixing it.
Azure Active Directory
There are numerous approaches when it comes to signing up for an Azure subscription. When you sign up for an Azure subscription, you must provide the name of your organization. That name becomes what is called an Azure Active Directory tenant. The tenant is assigned a Tenant ID, which is a unique GUID, and a directory endpoint in the format of *. onmicrosoft.com, where * is the tenant name. When you code applications to authenticate against the Azure Active Directory for your subscription, then that is the URL you use—for example, csharpguitar.onmicrosoft.com. Figure 1.24 illustrates how the Azure Active Directory blade renders in the Azure portal.
FIGURE 1.24 Azure Active Directory portal
Azure Active Directory offers many features, and we’ll discuss them in the following subsections.
Remember that this chapter is an introduction and the information about many of these products have been summaries. There are many exercises in the following chapters where you will get hands‐on exposure and gain more insight into the products.
Users and Groups
The most common types of accounts are the user account and the service principal. The first, as you might expect, is linked to a human being. A user account has properties like first name, last name, email address, telephone number, and most importantly, a user ID and password. The user ID and password represent the credentials and are used to confirm the user’s identity. This is known as authentication. A service principal is also used for authentication reasons; however, this account type is not linked to a human but to a resource. A resource can be a server, a workstation, an application, or perhaps a mobile device. The point is a service principal is not linked to a person. A common reason for using a service principal is when you want to grant access to a database. Instead of using an account linked to a person, you use an account linked to the resource that needs access to the database. Then all requests from that resource to the database are rightly authenticated.
User accounts and service principals can be added to a group. It takes less administration to grant a group access to a resource versus individual accounts. The process is to create a group, then add accounts to the group. You then grant that group access to the resource and certain permissions, like read, write, and delete. If you need to add or remove someone’s access to that resource, then you remove them from the group, instead of changing the properties in an individual account. If you need to remove the delete permission from everyone, then you make the change on the group, instead of on each account. When an account is used to authenticate against a resource, the permissions assigned to the group is what gets used to verify authorization. Since the identity has already been authenticated, which means they are who they say they are, the account is granted certain permissions that define what they are allowed to do, known as authorization.
Security is the most important aspect of IT. Networks, compute machines, data storage, and so on are important, but a data breach is almost, if not worse, than losing all your data. Knowing about the security products, features, and services that exist on Azure is an absolute must. Although your job as an Azure data…
