Each organization can create policies at its discretion and needs. But there are some policy recommendations that should be...
Conditional Access App Control in Azure ADLukas Beran
Azure AD, along with Microsoft Cloud App Security, will take your access to cloud resources to a whole new level. With conditional access in Azure AD, you can determine the conditions under which a user gets access rights (not only) to cloud services and applications.
But once you grant access, you can no longer work with it and somehow restrict that access. But what if you want to allow access to a cloud service or application but at the same time want to restrict some operations or interfere with an active session? This is not a standard conditional access, because the conditional access does not “see” into active sessions.
What is Microsoft Cloud App Security
But let’s first explain what is Microsoft Cloud App Security (MCAS). Microsoft Cloud App Security is a CASD (Cloud App Security Discovery) / CASB (Cloud App Security Broker) solution. So it is a service that can do both detection of used applications and services (CASD) and active intervention in communication with cloud applications and services (CASB). It is therefore a service that can collect, store and analyze various logs from cloud services and onprem devices. But it can also actively interfere with communication because it can act as a reverse proxy.
Within the discovery section, MCAS is able to identify more than 16,000 cloud applications or services for which detailed risk analyzes are available.
Access Control with Cloud App Security Broker
Because Microsoft Cloud App Security can act as a reverse proxy, it can interfere with active sessions and control communications. This makes it possible to block different types of actions or operations within cloud services. Even external ones.
Conditional Access App Control uses the just mentioned reverse proxy in MCAS and conditional access integration in Azure AD. Conditional access in Azure AD can define for some users or applications that access is only possible through the reverse proxy in MCAS. From the end user’s point of view, the user is automatically redirected to the MCAS reverse proxy after logging in and only accesses the cloud application itself through that proxy.
As you can see from the screenshots below, this is how access through MCAS reverse proxy looks like. First, after logging in, the user is informed that access is monitored. The user is then redirected to the cloud application itself. However, the URL still shows that access is through the reverse MCAS proxy – the address ends with the cas.ms domain, so for example, the Office 365 web Outlook does not have the standard outlook.office.com address, but currently uses outlook.office.com.cas.ms. Besides that it’s normal Outlook, only traffic is routed through MCAS reverse proxy.
This reverse proxy allows us to monitor and control access in real time. For example, we can prevent sensitive data from being downloaded to untrusted computers, protect files while downloading, prevent file uploads, monitor individual actions in an active session, and more.
Supported apps and clients
Session control works in all modern web browsers on all platforms – only TLS 1.2 support is required. The advantage is that no additional software installation is needed – the reverse proxy is purely cloud-based and runs as a SaaS application within Microsoft Cloud App Security. Traffic to this proxy is redirected due to conditional access in Azure AD. This makes the deployment trivial without the need for additional installations or configurations.
Within cloud services and applications, any application using SAML or Open ID Connect can be integrated with a reverse proxy in MCAS. Many applications are preconfigured, but you can integrate any custom application.