Zero Trust controls for your SaaS applications

Hello, good morning, good afternoon, depending on where you're at in the world. Greetings from Austin, Texas. My name is Kenny Johnson and I'm the product manager for Cloudflare Access. I'm excited to join you all today on Cloudflare TV to talk about Zero Trust controls for your SaaS applications. Really what we're going to go ahead and cover today is going over how you actually would be able to set up and put Cloudflare Access, which is our Zero Trust access management tool in front of your cloud applications or SaaS applications. I've got a brief presentation that I'll walk through just to kind of set the scene, show where this Zero Trust SaaS solution sits in the broader access management suite at Cloudflare, kind of how we think about it. And then I want to spend the bulk of the time actually going through a concrete demo and showing you guys what Zero Trust controls for a SaaS application, in this case Slack, actually looks like and how it works. Awesome. So without further ado, I'll go ahead and kick off. So really kind of what prompted this or how we think about security at Cloudflare is that the kind of old model that I have here on the left of the corporate-based perimeter or the office-based perimeter is something that really has cracked under pressure because of two reasons. One is because for COVID and for other reasons, much of the workforce has gone remote or has distributed across the globe. So creating perimeters around office-based IP addresses or data center-based IP addresses and back calling using VPNs really is not working. There's too much surface area for people to sneak through that maybe shouldn't. There's not enough granularity to be able to say that one user should be able to access one particular resource, but not 10 other resources on the same corporate network. So that's kind of the first reason. The second piece is as businesses have moved to SaaS applications away from their own hosted applications, these are things that live outside a company's wall. So it's really difficult to draw a perimeter around this. Certain SaaS apps have crude network controls that allow you to do IP -based allow listing, but that kind of has the same problems as self-hosted apps where by creating a VPN, all you're effectively doing is poking a hole into a firewall. If a bad actor is able to spoof that IP address or get onto your VPN, it gives them broad access if they have a user credential to that particular SaaS application. So really the way that we view the world and a lot of vendors are moving and a lot of customers are moving is moving to, excuse the buzzword, but moving to a SASE approach or a secure access service side approach where the actual network security or application security is delivered at an edge network. So you're able to actually check and verify whether or not a user should have access to a particular resource directly or close to that user and then direct traffic to that particular application. And this can be true for Internet-bound apps, apps that you self-host and control. And really for today's focus, SaaS apps. And double-clicking on this a bit further, really the way that we approach this is we have a Zero Trust network access solution that allows you to combine various sets of signal, excuse me, that allows you to combine various sets of signal to determine whether or not a user should have access. Traditionally, this might've been just does the user's username and password check out and are they coming from the right IP address? That just doesn't cut it anymore. So what we're able to do now is we can sync up and take signal from multiple identity providers. So this could be Azure AD or Okta, or if you have contractors using GitHub or Google Auth or something like that, we can combine all those different identity providers into one place. We can take signal from the device itself. So looking at things like, does the device have a corporately managed serial number? Is the device up-to-date in terms of its operating system? Does it have disk encryption turned on? Various sets of device context to determine is the user trying to access from their corporately managed machine or from a personal machine, either by accident or maliciously to try to exploit data, as well as additional contextual factors. So things like what country is this connection coming from? What IP address is it coming from? You can actually cross-reference that against bad IPs or known IPs, things like that. I'm able to combine all of these into policies that are checked on every single request to. In the past, this was specifically for self-hosted applications, and this was kind of traditionally how Access was built, but now what we're able to do is we can do that for SaaS applications as well, using what's called an identity proxy. And the way that the identity proxy works is we leverage the existing SSO or single sign -on infrastructure that most enterprise SaaS apps support, and Cloudflare is actually able to act as the single sign-on or SSO provider to that particular SaaS app. And then we're able to call out to various identity providers to validate the identity component and then provide additional context before saying yes or no to the particular SaaS application. And then where this stacks really nicely with other Cloudflare products, and this is a spot where, in a lot of customer conversations, things like these types of problems come up in the sense of, I've got a number of different SaaS applications, my visibility is really limited in terms of what's going on in those SaaS applications. The logging can be very disparate across certain SaaS applications. An app like Salesforce has really robust logging versus something kind of a newer style enterprise app might not have granular audit logs to show specific actions taken by users. That's kind of a key problem we're able to help solve in terms of consolidating all of those network requests via our secure web gateway to be able to see which requests or all of the requests made on top of all of your SaaS apps in a single plan. The other piece, and this is a bit of another buzzword, but we can act as kind of a CASB or a cloud access security broker to where within access, you are able to require that a user is running the secure web gateway in order to access a particular SaaS app. And then you can start doing filtering based on that user's identity in that SaaS application. So if there's a granular permission that a particular SaaS app is missing, you can actually enact that permission via our secure web gateway and ensure that that's always running by blocking that in front of access. So that's another kind of classic problem we see is businesses trying to create a consolidated place to really broker and manage access to specific spots within their SaaS applications. I know I touched on a lot. This is gonna kind of come together in the demo and I'll show you how all these pieces work together. But those are kind of the two of the main pieces that we see in terms of visibility and control that customers are able to get by putting access in front of their SaaS applications in the running gateway. And then kind of the final piece here that we call out on this slide is browser isolation, which is a pretty exciting technology that we announced last year that allows a user to be triggered into an isolated browser session. And we have a fairly novel way of triggering browser isolation so that there's no major performance penalties because it's all delivered at Cloudflare's edge and it's all done using native HTML commands. So what that allows you to do is if there's specific pages in a SaaS app or if you have contractors accessing a SaaS app, you're able to effectively turn it into a thin client or turn it into almost a VDI session where the user is only able to view certain records. They can't copy and paste, they can't download files, they can't print the screen, those types of things via browser isolation. This is all made possible by gating your SaaS app with access and requiring that the gateway is running in order to access that particular SaaS application. So before I jump into the demo, I think the final thing that I wanna call out is that all of the products that I'm about to demo today and all of the security features all run at Cloudflare's edge, which is the network that we had to build in order to become a great CDN provider. We've got hundreds of co-locations or I think it's over 200 co -locations across the world, which means we're under a hundred milliseconds within 99% of the Internet connected population in the world. All of these security products resolve at every single one of those columns, which means that these security checks don't have to backhaul all the way across the world, more similar to a VPN or a traditional security provider. They occur as close to the user as possible with very minimal latency in terms of the security trade-off that you're getting. So I always like to call that out because that's a bit of a superpower that we have at Cloudflare from building our CDN and networking business. Excellent. So what I'm gonna go ahead and do is I'll jump into the Cloudflare dashboard now and go through a little bit of how I would go ahead and set up an access for SaaS application, how that kind of works together, how I would create zero trust policies, and then we'll actually see that in action. Excellent. So I'm in the Cloudflare dashboard. I'm at dash .teams.Cloudflare.com. You can actually get to this from your core Cloudflare dashboard as well. I always like to call that out because there are separate views, separate dashes if you wanna go ahead and try out Teams. So I'll go ahead and log in quickly to my core dash just to show you how to get to the Teams dash. When I land on the core dash page, I just go ahead and click on Teams and then that'll jump me out to my Cloudflare for Teams dashboard. If you don't have a Cloudflare account at all and you wanna try this stuff out, we actually make this available up to 50 users for free for users that wanna give this a try. If you go to the Cloudflare for Teams homepage, you should see that free trial signup. Excellent. So now that I'm in the Teams dashboard, what I'm gonna go ahead and do is I'll talk you through how the Slack access for SaaS integration is put together as well as how I've gone about putting together my various policies. So within access, I've set up a number of applications. This one is Slack. And what I'm able to do within my Slack access application is using, and if you've ever set up SSO or a SAML integration, this stuff should start to look familiar. All I need to do in order to set up Slack for access for SaaS is to grab my Slack entity ID and assertion consumer service URL, which is what I get from the Slack side of their SSO configuration. So if I actually jump into Slack and I'll go ahead and actually, hold on, I will, let's go ahead and complete this view and then we can sign in through Slack and I'll show you the setup over there. It's a bit of a chicken and egg to be able to get into Slack. I gotta go through access. So I'll touch on how all that stuff's tied together and then we can jump over to Slack. So I grabbed these values from Slack. One other piece that's a bit of a newer feature that we've recently launched is the ability to do SAML attribute mapping. And what this allows you to do is when access certifies or signs off or a user passes the policy for access to the particular SaaS application, we're doing that via a SAML response and SAML supports what are called attributes. Basically, these are additional pieces of information about a particular user. That could be something like their first name, their username, their phone number, really anything. And a number of identity providers support passing this from their directory service down into Cloudflare. So just how this is kind of stitched together, I can take the attribute coming from my identity provider, which I'll show you quickly what that looks like in my identity provider setup. I jump into, I've got an Okta account here that I've set up and configured, and I'm passing a number of Okta SAML attributes. So things like the department the user's in, the last name, their phone number. What I'm then able to do within my Slack setup is I can do something like, I want to pass the department coming from Okta and put that into something like, a lot of SaaS tools kind of vary in terms of how they set these up. This particular syntax here is, I got this from AWS, but Slack likely looks fairly similar. So I would do something like that. And now what this will do is this actually allows me to, when a user logs in via Slack, it will push that department attribute down, which allows you to do things like create permissions off of that attribute if it's supported in the SaaS tool, as well as keep that up to date in the SaaS tool as well. I know Zendesk has support for that. I'm not sure about Slack, but what you're basically able to do is if you're mapping these attributes, if their department changes in Okta or in Azure AD or something like that, it can be, the update can be pushed into your SaaS application. So that's a newer feature, and it's really helpful for SaaS tools that either require specific attributes or where you wanna keep their user attributes in sync and up to date. So once I've set up and configured the application itself, what I'm then able to do is configure policies on exactly who and when, basically when users are able to access that particular application. So I've created a number of policies here. What I'll do is I'll touch on the require gateway plus internal only emails policy. We can talk a little bit more about the additional pieces that I'm able to require. So in this case, what I'm doing is I'm saying that I want to include everybody whose email ends in Cloudflare. So a fairly kind of common, straightforward rule we see. I'm just limiting this to my own internal employees. And then I want to require that Cloudflare gateway is running. So I'm actually running this right now, what Cloudflare gateway does is it's powered by our on-device client called Warp that basically proxies all of my traffic to Cloudflare's edge as a first hop out to the Internet. And then it's pushed out publicly from that point. What that allows me to do is create gateway policies. And this is really important because what I'm basically saying is I wanna gate any access to Slack behind users coming to Slack via my gateway instance. This is really powerful. You'll see in a moment as I go to build gateway policies for Slack or for my broader SaaS apps. Some of the other policies that I can configure, I always like to kind of just go down this dropdown quickly and touch on a few of these. So I can do things like location -based restrictions. So I can restrict high risk countries or I can restrict to specific countries based on where I know my employees are located. I'm able to do things like checking for a certificate on a machine. I can validate API traffic. I'm able to do this based on major IDP groups. So if you use Azure AD groups or Okta groups or Google groups, or even if you have a different SAML provider or YDC provider, you can pass those groups in as well. And then finally, we're able to do a number of device posture checks. So these are things like, is there a specific file on the machine? Does it have endpoint protection software running like Canium or CrowdStrike? Does the device's serial number match a corporately managed list? Does it have a firewall running? These are all types of checks that I'm able to do for both my self-hosted applications, but now even your SaaS applications. Excellent. So then once I've set up that particular SaaS application, what this then allows me to do is in my SaaS application, I set up Cloudflare as the identity provider. And then what this is going to allow me to do is I'm at just my Slack instance here. I've set it up so that I can only log in via SSO. So this is an important point. Most of these tools have this ability. So I can't even use my username and password for Slack to get in, which means that only access, that I have to pass an access policy to be able to get in. And if you remember back, we created that required gateway rule that basically said gateway must be running and I'm proxying my traffic to Cloudflare right now. I get presented with this Cloudflare access view. If you don't have multiple identity providers, this can be configured to take you straight to your identity provider, but multiple identity providers can be really helpful if you want to, especially with Slack and similar tools where you might have contractors collaborating or third-party users collaborating. This can be really powerful because you can give them the ability to sign in via a one-time pin in their email address or even plug in something generic like GitHub or LinkedIn. So in this case, I'm just going to go ahead and log in through Google. This will validate my Cloudflare email address and then take me directly into Slack. So effectively what this did was I logged in via Slack SSO. This took me to Cloudflare access, then out to Google or Okta, whichever identity provider that I selected. That passed a SAML response to Cloudflare. Cloudflare took that SAML response to make sure that the identity matched and then applied any additional pieces like the attribute statements or any additional pieces required to make sure that I will pass the policy and have the necessary SAML information to then pass one final SAML response to Slack. And then Slack basically is able to validate and say, yes, this is a user I recognize. I'm good to allow access into Slack. And then now what's great is I'm in Slack running Cloudflare Secure Web Gateway. So users are able to actually configure policies around specific pages that I'm allowed to see and not see. And then I'll quickly touch on how the actual authentication setup works within Slack. It's fairly straightforward. All I need to do is go ahead and set up a SAML authentication option. And then within settings, all I need to provide is the SAML endpoint, the identity or entity ID endpoint, and then a public certificate. And then I can force the user to only authenticate via SSO and then I'm done. That's been set up. And now Cloudflare access is sitting in front of my Slack instance and forcing device posture and other tools. And just as an example of what I can start to do with Cloudflare Gateway is things like, say I don't want all my users that have admin access that are managing users, I don't want them to see how much I'm paying for Slack, something like that. What I could then do is within Cloudflare Gateway, which allows me to do both DNS and HTTP level policies, I'm able to create specific filtering rules that say based on a particular, let me grab a good one here. Yeah, this is a good one here. Based on a specific host name and a specific URL path, and even something like a specific user email group or set of user emails, I want to actually either block or allow requests being made to that particular end point. Similarly, on top of block, I'm also able to do things like isolate the session. So I can actually trigger an isolated browser session to then where the user is not able to copy and paste or print the screen, things like that. That can be really, really useful if you have contractors accessing your SaaS applications. The other major benefit of Cloudflare Gateway running on the particular SaaS application is that I then get very rich gateway logs. And I get very rich both DNS level and HTTP logs to be able to see specific information being taken in that particular application. So these gateway, these logs, are tracking my activity to where I'm able to actually see specific application traffic or specific actions being taken in a particular application down to both the DNS and HTTP levels. So I can see where that came from, the specific hosts being made, as well as kind of whether or not that was allowed or blocked. Similarly, from an access management standpoint, I'm also able to see whether or not a user was allowed or denied access into a particular SaaS application. So in this case, we can see my authentication to Slack that just occurred here a few minutes ago. So instead of having to go to each individual SaaS application and go look at the audit logs for who logged in, when did they log in, I have this all in a centralized place directly within Cloudflare. The other benefit here is that both these access logs and gateway logs are available via a product called Cloudflare Log Push that integrates with major security event and incident management tools like Splunk and Datadog. So you can actually use this as additional signal in your SIEM tools to create robust reports and alerts based on specific user actions. So all of this data can be pushed into kind of major popular reporting platforms to be able to look for patterns, look for issues, look for unauthorized access, things like that. Cool, so that was kind of the end to end of getting Slack set up directly within Access for SaaS. But this definitely is not the only SaaS tool out there in the world. There's a number of different SaaS applications. And what we're actually working through at Cloudflare, and this is a project I'm working on directly, we're working to create specific guides for popular SaaS applications because every SaaS app's SSO setup can be slightly different, can be slightly unique. So if you actually go to developers.com and go to our Cloudflare 1 tutorials, you'll see other major SaaS apps supported in here. So these are things like AWS and Zendesk. Zendesk is actually a great example where I'm able to configure those attributes statements to map a first name to a first and last name so that they dynamically update from the identity provider down into the SaaS tool from Cloudflare Access. So I definitely encourage you to go ahead and check out the Cloudflare 1 tutorials for particular popular SaaS apps. We also have a section in the Cloudflare community. Let me go ahead and get that link pulled up. I'll go ahead and pull that up. So if you go to, oh, I just had it. Let's see if we can get to that guy. Here we go, sorry about that. So there's a community post that I put out that basically says, which guide should we build next? So I'm fully aware that we have not built a comprehensive guide of major SaaS tools that folks would wanna go ahead and set up with Access for SaaS. So if there are additional Access for SaaS platforms that you would want to go ahead and have us document, feel free to post them into this community post. I watch this pretty regularly. So I'd be happy to put together a guide if there's a significant interest for additional SaaS tools. Excellent. So with the remaining few minutes, I think what I'll do is I'll just talk a little bit about kind of where we're headed with not only Access for SaaS, but Access more generally and a few other new pieces that we've put into the tool. So in terms of Access for SaaS, the kind of major improvements that are coming down the line, hopefully in the next few months are, it's really around kind of the ease of use and setup of the SaaS application. So really the next thing that we wanna put into Access for SaaS is the ability to put together or use a metadata file to set up. Basically what a metadata file is, is it allows you to download a file and upload into SaaS apps that support metadata file upload. And that just makes it a turnkey setup, makes it really, really straightforward to get up and going. So we're hoping to get that put out and set up hopefully in the next few months. That should make things quite a bit easier for getting these tools set up. In terms of other new things that we've shipped recently within Access that I wanna point out, there's really kind of two major ones. The first one is called purpose justification. And what purpose justification allows you to do is if there are specific sensitive applications that you need to collect a business reason, oftentimes this is because of HIPAA or GDPR or other major regulatory requirements. If you have those types of requirements in your business, you can actually use what we call purpose justification to serve a message screen to an end user asking them to please provide their business reason for accessing that particular resource. That then gives you a log every time that that user accesses that particular resource for compliance or review reasons. This can be used for things like accessing a medical record or accessing a release sensitive system, or internally we're talking about using this to actually justify why an engineer might access a production system because those are reasonably sensitive. So that's a fairly new feature that we've just put out. The other piece that's new and pretty cool, it's similar to the vein of the SaaS apps that we've talked about is the concept of browser rendered apps. This is actually allowing you to almost kind of SaaSify some of your non-web-based tools. So if you have SSH within your business, I'm guessing most of you do if you have developers, if you have people using SSH, we've actually created the ability to have a browser rendered terminal that uses all of the same Zero Trust controls that I just went through today. So this is great if you have partner contract developers that want to give access to certain SSH resources, even internal users, if you don't want to have them go through downloading a certificate and things like that, they can have just a URL endpoint that they hit and then they're able to log in to a rendered browser that really works seamlessly since we delivered at the edge. Similarly, if you use VNC to do any desktop rendering or anything like that, you can do that as well. And we're not done. We're not done there. We want to add more protocols, more non-web-based tools using our browser rendering tools. So we're very excited about that as well. Excellent. So that is everything that I had for you all today. Again, it's really straightforward to get up and running if you want to give Cloudflare for Teams a try. I'm going to go ahead and actually pull that page up. So if you go to Cloudflare.com slash Teams, there's actually an option to go ahead and get started and sign up. And again, we allow a free trial up to the first 50 users for both our secure web gateway and Cloudflare access. So I really encourage you to go ahead and give this stuff a try. Getting a SaaS app set up is really straightforward. It's really, it really only takes a few minutes. And then what you're able to do is start enforcing additional controls on top of what you have with your traditional identity provider to really ensure both security as well as visibility across your SaaS apps. Just like you've done if you haven't used access or you could do with your self-hosted applications where you control the infrastructure. Thank you all so much for coming. Enjoy the rest of your morning, afternoon, evening, wherever you're at in the world. And thank you so much. Thank you.