This course illustrates how to leverage Azure authentication and access features to simplify and streamline users' experience using SAP running on Azure Infrastructure. Azure Active Directory supports single sign-on to SAP applications, while role-based access control, a fundamental building block Azure Resource Manage, enables system administrators to allow access to and protect the resources hosting an SAP environment.
Learning Objectives
- Underlying concepts of authentication and access in an Infrastructure as a Service environment
- Learn the steps required to set up Azure Active Directory Authentication with SAP applications
- Learn how to apply role-based access control to an SAP environment
- Use resource locks to add an extra layer of security to your infrastructure
Intended Audience
This course is intended for anyone who wants to boost security for their SAP environments on Azure, through the use of authentication and access practices.
Prerequisites
There are no particular prerequisites required for this course other than a general understanding of user authentication and access.
While RBAC works from a user perspective, it is also possible to insulate resources from users with locks. Locks override users' permissions, so are especially valuable for protecting critical resources from accidental modification or deletion.
Resources can be locked either as Delete or Read-Only. Delete, meaning a resource can be modified but not deleted. Within Azure Resource Manager, this translates into a lock level of CanNotDelete. Read-Only, as you'd expect, means users who have role-based access to the resource can't modify or delete the resource.
A resource's lock attribute is inherited by child resources in its scope. Even child resources added later will inherit the parent's lock setting. The most restrictive lock setting within the inheritance structure takes precedence. A child resource with an explicitly set CanNotDelete lock will behave as Read-Only if that is the parent resource's lock.
Locks only apply to the resource and not to the functionality or data of the resource. In Azure speak, this translates into locks operating in the control plane, whereas resources operations happen within the data plane. Locks only affect a user's ability to modify a resource and not a resource's functionality. A Read-Only lock on an Azure SQL database server will stop users from deleting or modifying the instance but will not make the information contained within its databases read-only.
Locks implementation is a little ham-fisted, leading to it not working as you might expect in some scenarios. Https://management.azure.com API endpoint is the destination of control plane operations, whereas data plane calls are made to https://myaccount.blob.core.windows.net. Azure Resource Manager implements locks by preventing POST operations sent to the control plane API endpoint. Azure documentation has many examples of unintended lock behavior, but a read-only lock on a virtual machine is most pertinent to us. A read-only lock will prevent any user from starting or restarting a VM as each of these involves a POST request. Now, this may or may not be a bad thing, but if your intention was just to prevent modification, then it could be an inconvenience.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.