cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Controlling the Uncontrollable, Component 5:  Securing Access to Company Resources
By
Brad Anderson
Published Sep 08 2018 08:29 AM 1,191 Views
Brad Anderson
Iron Contributor
‎Sep 08 2018 08:29 AM

Controlling the Uncontrollable, Component 5:  Securing Access to Company Resources

‎Sep 08 2018 08:29 AM
First published on CloudBlogs on Mar 25, 2016


In this series , I’ve talked a lot about the new and emerging differences between the traditional way of managing things vs. modern, simpler ways.  This post’s examination of how to protect company resources really illustrates that difference between past and present.  See more in the video below. If you think back just a few years, all the resources your organization needed were probably in your own datacenter on-prem.  In this setup, your infrastructure had a hard edge – the firewall and VPN – and this worked great because most of your users (and corporate data) were inside that firewall and, even if they were outside, they had to virtually come back through the firewall to access any sensitive data.

Today… that just won’t work

This perimeter-centric view of protecting your organization has become outdated for one really simple, pervasive reason:  Your users need to use (and are already using) cloud-based resources, and, if you address this with the “old way” of managing things, you are going to be exposed to a lot of attacks. These cloud-based resources aren’t random apps that don’t belong on business devices – your workforce is probably already productively using a lot of them, e.g. Office 365, your CRM may already be hosted in the cloud, as is a lot of expense data, and LOB apps. From an architecture perspective , the “old way” is just ineffective :  With so many mobile users in your organization, it’s kind of crazy to make all the communication and traffic with these SaaS apps come on-prem and then immediately bounce back to the cloud for the SaaS app.  The bandwidth necessary for this, to say nothing of the cost of the network devices needed to achieve and maintain this configuration, just doesn’t make sense.  Even if you do pour this much money into it, it’ll still be debatable whether or not these costs will make you safer – but the sluggishness of the network may make it seem like there’s some amazing security apparatus in place. This more modern, cloud-first architecture provides the environment that allows these mobile devices to thrive by talking directly to the service; the devices and the apps are built that way – and anything else adds unnecessary complexity. So, if what you’re after is security, I think it’s worthwhile to consider what “security” really means for you in this new world where the traditional idea of a “perimeter” has evaporated.  For many organizations, security means using the same protocols as any other website and having a central “access log” for auditing.  While common, at Microsoft we looked at this approach and agreed that there MUST be a better way.  There was.  That’s why we built what’s called Conditional Access .

Here’s how Conditional Access Works

Conditional Access operates at both the device level (through Intune) and at the identity level (through Azure AD).  This setup doesn’t tell the whole story, however.  To really see the power of this solution, and to better understand why Conditional Access is a far better way of controlling corporate access (compared to the common process of bouncing everyone through costly on-prem resources), consider this scenario:
  • A new employee needs to use his iPad to check his e-mail (via his Office 365 account).
  • His organization uses Conditional Access to protect Exchange Online.
  • To get to his e-mail, the first step is simple: He adds his Office 365 account to the mail app on his iPad.
  • Doing this registers his device against his O365 mailbox – and this immediately checks to see if the device is registered and marked as safe in Azure AD and Intune (this is a unique workflow to Office 365 and EMS).
  • At this point in time the device isn’t registered yet, so Exchange Online momentarily blocks the device but not the mailbox and sends him a single e-mail which explains how to get that device trusted.
  • Now the worker simply follows a series of prompts that enroll his device with Intune and which check compliance against the Conditional Access policies assigned to his identity.
  • Based on his identity, he’s also prompted for Multi-Factor Authentication because his organization’s Conditional Access rules require this for corporate mail.
  • Now that his device complies with the policy requirements, Intune tells Azure AD that everything is in order.
  • This user can now get back to his e-mail and, by the time he gets to the app, e-mails are popping up.
What makes this so groundbreaking is that it’s all implemented inside the Microsoft Cloud; there is literally nothing to deploy on-prem.  All that overwrought, expensive, redundant back-to-on-prem routing is gone .  Additionally, because the Microsoft cloud is so open, we automatically integrate with 2,500+ SaaS applications so that you not only get the Conditional Access capability for the apps in the Microsoft Cloud, but you also get these capabilities with any connected app (which includes your on-prem web apps).  This is totally unique for a single product suite. I can’t emphasize enough how much cross-product and cross-company integration it has taken to enable this.  Working across Microsoft, we’ve brought together logs for fast troubleshooting, and we have end-to-end SLAs that are tracked every minute of the day.

But, Wait, What About Exchange On-prem?

With all the functionality of Conditional Access in mind, the next logical question is, “What does this means for on-prem deployments of Exchange?”  If this question is relevant to you (and there will be a lot of you), you can get all the same functionality bulleted above by installing a simple server in your datacenter. For those of you planning to use SaaS apps besides something like the near-ubiquitous O365, there is also a ready-made solution that follows the path bulleted above:  When your user ID is used to connect to Exchange, the identity-based Conditional Access rules were applied and you’re then prompted for MFA.  These same rules can be applied to any SaaS app that is managed by Azure AD . Other mobility vendors make some pretty grandiose claims about protecting Office 365 to this extent, but, in every case, they use proxies, VPN’s, and firewalls to get things off the ground.  The idea of taking previously on-prem workloads to a SaaS app but still routing your users through your proxy/firewall makes absolutely no sense.  Consider this scenario:  One of your employees purchases a new device and one of the first things they do is add their corporate e-mail – but that device does not have a VPN configured on it and it just starts talking to the SaaS app right away.  This makes the traditional proxy/firewall useless. Microsoft is unique in being able secure and protect your SaaS apps. You probably don’t have a DeLorean on hand (but even if you do), so don’t go back in time to find a security solution. This functionality gets even more impressive when you consider the Identity Protection feature announced by the Azure AD that we covered in the previous post . To learn more about how to use and make a real impact with Conditional Access, here’s a deep dive with Simon and Dilip.

Additional Resources:


0 Likes
Like
Version history
Last update:
‎Sep 08 2018 08:29 AM
Updated by: