Transcript for "Clientless remote access for third-party contractors and employee BYOD":
Alrighty. Hey, everybody. We'll wait just a second as folks are trickling in to officially get started. But, just to orient, of course, throughout this presentation about clientless remote access, feel free to be asking any questions in the chat that we will monitor for. There's a few documents in in the side tab about third party access, VPN replacement, and even a deeper technical implementation guide that's talking through a lot of the same stuff from today. And per usual with the webinar, everybody that signed up, regardless if they showed up or not, will receive a link to the recording afterwards. We wanna send it along to a colleague or something like that. But today is all about clientless remote access. I'm Michael Keane from our SaaSy team here at Cloudflare. I'm joined by a couple of my peers. Ivana, wanna introduce yourself real quick? Yes. Thank you, Michael. I am Ivana from the chat advisory solutions engineering team, and, basically, I'm working with customers who are under active cyberattacks, helping them mitigate them and onboard faster. Awesome. And Chris? Hi. I'm Chris Lopez. I'm a technical marketing engineer for Cloudflare Zero Trust, our SaaS platform. Awesome. And what I love about today's presentation, the way we've structured it is we promise we're gonna spend about half of it in the actual product with Chris demoing. He has a bunch of plan for us. But we are gonna just set up the stage, Yvonne and I, first just so we're gonna contextualize all the awesome stuff that Chris is gonna show in that demo. So, again, today is about clientless remote access, which is a a sub use case that we find a lot of our customers starting with that might be on a path to broader remote access modernization over time. It's all about access through the browser to let the layer seven resources whether those are web apps, cell phone set apps, or even infrastructure resources, something like clientless RDP, perhaps remote desktop protocol through the browser as well. So this is all about security and simplicity for unmanaged devices, And we find that in two primary use cases, one with third parties like contractors, partners, suppliers, or the second one is just employees on their own devices. On the personal machine's market often refers to that as BYOD or bring your own device. Couple of things that we've seen come up, actual examples, were customers that had lots and lots of contractors that only needed to access one thing. So definitely not the whole network. We had one organization where there was tens of thousands of contractors that just needed an internal timesheet app, and that was it. So this concept of just give them access to what they need and nothing more. Maybe it's employees wanting to access their email and collaboration apps from their personal device, but, you know, maybe not production server access with the ability to change anything. Another category is when I'm giving access to these contractors or or employees on their personal devices, maybe not take an all or nothing approach. Give them access to something like Salesforce or documentation, but don't let them copy paste or don't let them upload download. So kind of instead of full on access or block, it's kind of access but with conditions. And then this also supports gig economy, temporary work. Think of project based work where you hire a bunch of contract developers for just three or four months to get through a project, and that's it. You know, we can't wait until week two or three to get those folks productive We need that. They want access. So primary things we're solving for, both in the security side and the IT side. We mentioned we don't wanna give contractors or employees on their personal devices more access than that what they truly need because we don't want the risk of data loss, in our organization. And VPNs are a traditional tool sometimes used to still accomplish remote access. And Ivana, in just a second, is gonna talk through some of what she's seeing about why that's such a problem, in modern times. But a lot to to say on the IT operation side as well about speedy onboarding and off boarding. That, you know, VPNs are known for being, slow and clunky, so they're definitely not the best tool for that. All of the IT issues with with access problems that come up from that. Maybe you don't have time or budget or staffing to ship everybody laptops. If you have some contractors joining for a few months, do we really have the time or budget to send everybody a corporate managed device, whether laptop or mobile device? Do we have the time or does it make sense to issue all of our contractors corporate identities or integrate with some third party, identity provider and do some custom work there? Or there's just their simple reality that some other organizations might say, no. I I'm not allowed to install anything. We can't install software. That's a requirement. Or if they do allow it, maybe they still have kind of extensive audit processes to really vet the software. So is that really worth it? But back to the security side of, you know, Ivana, and as a member of our threat advisory team, can you talk a little bit about these more legacy approaches to remote access? Yes. Thank you, Michael. To reflect shortly on on your part, BYOD used to mean, right, bring your own device, but that can become quickly bring your own disaster until we do add the zero trust access, into the mix. So for now for a while now, we see that remote, access remote workforce is constantly under the attack. And this tech stack, that was in charge of securing the remote access, uses either not secured access technologies like RDP or technologies like VPNs, which are proved to be not granular enough, over permissive, hard to maintain and manage, and are exposed and vulnerable to zero day attacks. And the information that we have seen is pretty concerning. So in 2023, as an example, we saw that 5,000 organizations experienced breaches of remote services such as VPN, TeamViewer, IDP. And they made into the headlines, some of which you can see here. And another information that, I wanted to share is in 2024 then, we saw that, estimation that around eight out of every 10, ransomware attacks originated through remote access tools, with VPNs being the most common initial entry point. And we know that data breaches not only undermine the confidence in your company, but also the lead to costly GDPR fines. And the question isn't only how do we secure the network. The question is how do we secure access everywhere without trusting anywhere? If we can move on to that. Yes. Thank you. So with that, we surveyed around 200 decision makers that were responsible for securing access in their organizations. And out of those 200, 74% were focused on reducing reliance on hardware by replacing their VPNs with zero trust network access. So what we have seen is, for their security teams, VPNs were too risky. They allowed lateral movement, always had new vulnerabilities. They are constantly under attack. For IT and networking teams, they were too efficient inefficient to manage and too slow for end users. We have remote work, hybrid teams, and now we have return to auto office talks. But the truth is that still 47% of full time employees are hybrid or remote users. So modern organizations still need modern remote access, modern remote access, and they need it everywhere. If we add into that the expanding circles of trust, we see that 27% of users are accessing internal resources, and those are contractors, partners, suppliers, so third parties. And they all need access and they need it fast. But how do you grant that without opening the gates to risk? And not to forget also the devices. We have laptops we don't manage, phones that we don't own, so bring your own device is no longer Latane optional. It be it is becoming a default as, Michael was mentioning as well. And we saw that an amazing 50% of employees access internal resources from an unmanaged device. So the world has changed. The way we work has changed. So how do we secure access that also has to change? So overall, from this survey, there is an agreement that traditional approaches don't quite take captive, and most organizations are actively looking for alternatives. So let's take a look at our customer, delivery hero. So imagine the scenario. You're running an online food delivery company, and in a couple of years, you triple in size from 10,000 to 40,000 employees. Thanks to the rapid growth, to mergers, acquisitions, you get lots of new contractors. Now imagine trying to securely onboard every one of them, from developers, dispatchers, across multiple regions, and all of that without slowing down the business. And that is exactly what this Germany based, food delivery company faced. The old VPN model was way too slow, it was painful to manage, so they turned to Cloudflare. They started simple with no device agents, no heavy installs, just fast, identity based, clientless access to internal web apps. And within minutes, those apps were protected. And with every step, they tightened those policies. They added multi factor authentications, posture checks, risk scores, and over time, they scaled calls for zero trust across 40,000 users, covering self hosted SaaS apps. And the result of all of that was that the users had a seamless access, they were fast faster onboarded, and they had better security. And the real benefit of this all is that their IT teams got to focus less on this firefighting, but more on building. Because the speed of innovation is everything when your competitors are just a tap away from, from you on someone's phone. So that is the power of starting zero trust simply, but also scaling it smartly with Cloudflare. And now let's take a closer look, after you, Chris. Yeah. I'll set up Chris right before we hop in on just what it so what are they actually doing when they're monetizing that remote access? You know, like any big problem, most of our customers like the Delivery Hero are splitting it up into smaller chunks and figuring out what's that long term journey, how are they adopting more use cases over time. And so many of our customers have started with third party access in particular or unmanaged BYOD access, to start with that population of risky users or risky apps to get started, and they gain some momentum over time. So on the on the security side, what they're actually doing with a ZTNA product or a SASE platform or a zero trust platform? So many synonyms to achieve that zero trust mindset that, the market's always talking about, where the core idea is individual users to the individual resources they actually need. So with clientless access, the main thing you're usually giving up is the ability to do device posture. But in there's some maybe some work around so to get creative. But the the main thing that we find is that strong identity authentication with with stronger MFA, maybe five zero two compliant MFA, that's pretty good for for a lot of folks, especially if it's just to, you know, less sensitive apps, one or two apps that a contractor might need. So it's it's all about setting up those policies, those identity centric policies with plenty of authentication methods, whether that's and if they threw, through LinkedIn or a one time PIN or maybe they're okay doing face ID, fingerprint, Windows Hello, whatever it is. Getting strong identity centric authentication to those resources and then being able to apply data controls even through a browser. So things like we mentioned of access Salesforce, but don't copy and paste anything. Or access the Wiki, but don't take all of it with you. No big old uploads, downloads. So applying all of that through these individual resources and then speeding up the onboarding because we're not shipping laptops. We're not doing custom identity workarounds. And then also just the fact that some companies cannot install software. It's as simple as that. We're doing all this straight to the browser. So no software to download, and we're aggregating that across lots of resources. So not just simple websites or SaaS apps, but extending that to self hosted apps or even infrastructure through the browser. Something like remote desktop that, Chris will show in just a second. But everything I just said, there's actually just to be totally honest, there's plenty of tools on the market that do all of those things. So we're gonna restrict the user to resource access, develop identity centric policies, choose our authentication or MFA methods for that, use those data protection policies or those data protection methods all through the browser. That's great. That's kind of the table stakes, way to solve this use case. What we find at Cloudflare is by accomplishing clientless access through a connectivity cloud approach, which is our unified platform of all of the programmable cloud native services that we have on that platform across different markets, like application services and SASE and our full developer platform is when they do it through the connectivity cloud, folks like Delivery Hero or Indeed or or others that have deployed our platform, they find it faster to get started and initially deploy and easier to maintain over time because of our heavy investment in automation. So an organization like Delivery Hero that's growing very quickly or any others that are experiencing rapid growth, they love to automate it so that when they add new users and new apps over time, it's gonna be a lot easier to keep up. Because of the expanse of our network and the way it's designed, they find that the access experience is not just low latency and it's not just about a city count or or, you know, how many places in the world we show up. It's also about consistency where if those contractors are global, we want everybody to have a great experience, not just in the most heavily populated areas. So whether it's easier deployments, better user experience, and, more consistent user experience, Or it's, hey. I'm getting through this contractor use case right now, but I I see a path to solving other SaaS use cases with web filtering or, you know, tackling shadow IT or tackling more data protection with GenAI apps. Maybe it's just expanding their own remote access modernization to their entire organization beyond just unmanaged devices. Whatever it might be in a proof of concept with Cloudflare, folks usually feel those architecture differences, for themselves for for how, composable these services really are, which means you can adopt them in any order, and they see that long term road map. Last thing I'll say is that we just we make it really easy to get started. And a lot of folks start with clientless access on the broader journey where they connect an app, set some policies, and just test it out in the browser. With something like a web app, that's kind of overly simplified, but then expand that to more resources like maybe infrastructure, apply data controls before they start to expand out that modernization to their entire organization. So, with that, Chris, can you make real some of the stuff that we've been showing? I'll pass it over to you. Absolutely. I just need to share the screen real fast. Alright. So I'm gonna begin just with a little slide over here. It'll be really quick. I wanna reinforce this, what I feel is the central premise of Cloudflare here, which is you're going to build a private network using our our edge, and you're gonna see all the ways you're gonna be able to connect and and basically send your traffic and on ramp it to Cloudflare. Now we're gonna be focusing on what you can accomplish more or less just with Cloudflare d. We're not gonna be focusing on device agents in this one, but I did wanna point out all of the dynamic deployment options that Cloudflare has, and you'll actually be able to see that with the clientless options as well. So just as a quick refresher, for, I guess, people who might not be familiar, you know, that familiar with Cloudflare, first First thing we're gonna do is we're gonna begin with authentication. So you're gonna be onboarding your sources of truth to Cloudflare. You can see that we have, like, you know, Google as a login. We have Azure AD as a login. We do support most, major providers, and we also have room for OpenID Connect and SAML and this is gonna be pulling in device posture information, in addition to identity information that you get from the IDP. So that's gonna be like where are you coming in from, did you use multi factor authentication, what groups are you a part of, and Cloudflare is going to be able to ingest that and use it to create rules surrounding application access. Once you've done that, I mean, it is important to understand, like, what your users' devices look like. And, typically, one thing that we the way that we get a lot of telemetry would be the device client. But, again, this is gonna be a very clientless one, so I'm gonna showcase how we're gonna be able to pull in more telemetry on the back end. So we're gonna move on from that, and we're gonna talk about how you connect your applications to Cloudflare itself. So in that diagram that you saw, I was kinda hovering over, an instance of APM and Azure that's running that's running Cloudflare d. And that is, well, that is our app connector. Right? It's gonna be reverse proxying whatever service that you, you know, that you designate, through Cloudflare d back to the user, and it's gonna be doing so through a DNS CNAME record that routes to the tunnel record. So over here, I have a tunnel called corporate app server. You can see that I have a it's we support most major, OSes. So depending on, you know, Windows, Mac, whatever Linux distro that you're using, you're gonna get a pre baked command that you throw into your command line and at which point Cloudflare is going to set up and instantiate and connect the Cloudflare d or, you know, connect the tunnel back to your private network that you created on Cloudflare as I mentioned at the beginning. Once you do that, you can begin proxying, either public host names, the DNS CNAME record that I mentioned, or private networks. You know, basically, you'd have to, you know, be able to access through a device client, or through a special clientless browser, that we have. So over here in public hostnames, I wanna point out that we have and this is like a docker compose file. We have eight, applications that are all onboarded here and the, you know, they all correspond to each of these public host names. The thing is, if somebody accesses one of these host names, they're not gonna be able to move laterally to another service that's also potentially on that subnet because Cloudflare is not proxying the subnet here in this instance. It's only proxying the service running on port eighty eighty on the local host. And this is, you know, for web based services. But if you wanted to add a host name, you would also be able to target, you know, TCP. You'd be able to target SSH, RDPs. We'll see in a little bit, you know, more than just, more than just web based applications. So once you've done that, you create a connectivity, but, unfortunately, you do you know, that that connectivity is only one half of the battle. It's also about securing it. So what we end up doing is we create an application definition inside of Cloudflare access that targets the domain and the subdomain that you just created inside of tunnel, and we're going to use that, basically as a target to which create, you know, which we create all these rules behind. So we're going into the application definition of the company Wiki, which I'm gonna access here in just a moment. And if we go over here to policies, you can see that I've layered two policies here, one for all employees, the other for isolating all contractors. Now if we go to all employees and I go down here, you can see that this corresponds to, a rule group called all full time employees. If we were to look at what a rule group is, that's really just a, well, it's it's just an a an object that we've used to define, like, a certain set of users, and potentially, what was it, also security measures that need to be on top of that. So if we were to look at this, we're saying, okay. Well, all full time employees, it's gonna be the Okta group employees and using lock in method, Okta. Behind this, we also have the ability, or we have another policy that's, that's overlaid behind that, which is going to be targeting contractors. So isolate all contractors. If we go in here, you can see this matches to only a lot of firms that you get contractors from, so KPMG, Wipro, Berlin Rosen, Accenture, and I've also added at Cloudflare.com over here. And the point of this is that if somebody matches to this and they are not, you know, explicitly part of your organization, if they're a contractor, like Michael was pointing out, you'd be able to provide them access to the Wiki, but you'd also be able to isolate that access in such a way that, you know, you could you'd be able to apply data protection controls on top of it. So I won't go through all the details of browser isolation because, time is short, but I will demonstrate, what happens if you log in and you don't match the appropriate policy. So I'm gonna go to wiki.scottflash.co.k. And I'm gonna sign in as a Scott Flash employee. Alright. Then we're gonna be pulling in, just two factor from Google Authenticator. And you can see here that I have access. I have full access to the Wiki. I can navigate around it, you know, exactly as I choose, and I also don't have my clients enabled. So anybody anywhere will be able to potentially access this because the tunnel record and all the security behind it is tied to this domain name. Now if I were to match with this, you know, let's, let's back out just a little bit and let's go to, you know, that same place, wiki.skyflash.co, but in a different browser that needs to sign into it. And this time, I'm actually gonna sign in, as myself, and I'm gonna get a code. So the point is I'm gonna showcase that we're we're matching to a different policy. And as a result, I'm gonna be, receiving an isolated version of this application. Alright. So the first thing we're gonna notice once this loads is I'm gonna pull up an isolation toolbar. This toolbar is going to be, basically just a log of, like, how quickly the remote browser is is communicating with my native browser. One second. And you'll be able to see, like, message channel, draw channel, performance. You'd be able to see the round trip time, and, essentially, contractors would be able to get, isolated access to this application. One moment. Where are we gonna go to? Okay. There we go. So here, we're gonna be receiving, an isolated version of this, and you'll be able to see not only is the keyboard blocked, but things like copy paste and printing are blocked. And that is because of the, data protection controls that we have overlaid on top of the service. Alright. And if we are actually to jump into that, I'd be able to showcase, like, what those policies exactly are. So let's go over here to virus users and isolate Internet. There we go. So you can see here I have a policy. Now this is a policy that would typically execute, you know, via a, you know, via gateway policy that would typically be executed via a client. But here, because it's happening via an isolated browser, which is attached to our, your instance of, you know, the private network being created for Cloudflare, the gateway goals are still going to apply without the presence of a policy. So if we go down here and say, okay. Well, if you have access to internet.skyflash.co or wiki.skyflash.co, we're gonna isolate that, and we're not going to allow you to copy. We're not gonna allow you to paste keyboard printing, downloads and uploads, you know, as much or as little as you would like to be able to restrict. In addition, those same gateway policies are also gonna be able to apply, to other, like SaaS applications and things like that that you've uploaded. So this is the same, I'm sorry. This is a different application, an instance of Salesforce that I'm accessing through an isolated browser as well. And, ostensibly, this would be something that I'm providing to, you know, to a contractor or somebody like that. And once again, I'm gonna say, okay. Well, let's say this contractor wants to you know, tries to edit something that they're not supposed to be able to edit. You can see that it says we've hit a snag, that this you know, there's some errors that have been occurring on this page. In addition, if I go over here to a file that I would like to download, I'm gonna try and download it, and you're gonna see that it has failed, due to a network error. So let's go ahead and look at why exactly that happens. So over here, I'm gonna pull up, firewall policies that are related to what we just looked at. You can see that I have a policy called restrict Salesforce edits to trusted devices. So, you know, I have a a expression based policy here that says, hey. If you're trying to update a record and you're not a member of the executive or sales group, we're gonna block that, which is exactly what you saw there. In addition, we have another policy, that would be prevent download of sensitive customer data. And once again, if you're not a member of executives or sales, you wouldn't be able to download, like, a record of customer data like you just saw. And the point of mentioning all this is to say these are policies that would typically be executed via a device client, but we were able to execute them clientlessly in a remote browser that you're using to provide secure access to your contractors. So the security posture that you've developed doesn't need to be compromised just because you're being clientless. And, actually, just to kind of move off of that and then go into, like, some non web applications that we're gonna be able to do, I'm gonna go over here to Skyflash the app launcher, and I'm gonna showcase how this can work for RDP. So over here, I have, this is just my app launcher. Based on the nature of my login, it's gonna tell me what applications I have access to. And over here, you can see I have access to something called the corporate domain controller. We're gonna go ahead and click on this. And, you know, we see we have a login page. I'm gonna sign in as Alice again. And now I'm gonna have browser based RDP. This is a, just Windows device that's sitting in in our cloud, And it's going to be able to provide, you know, just, again, like, your native RDP access, to a device based on the context of the login. Doesn't necessarily require a client unless you need that as part of device posture. And, what was he gonna say? It also this would also work for browser based SSH, if you need to provide people access to a developer environment, and you'd also be able to provide that for browser based VNC, for other distributions that are not necessarily that don't necessarily rely on RVP. Alright. And we're now I did wanna touch on, device posture real fast because there are elements of device posture that don't, you know, that aren't that are lost. Right? Because, they you have to pull them through the device client. And in order to, in order to showcase all this, I'm gonna go ahead and switch over to a separate account here and we're gonna go up to applications. Now over here, I have something called a call center application. Now this is just a private IP application that I've configured, inside of a WAN environment. But I've used these policies, to be able to define logic, that would be, you know, accessible to that would be accessible to, people who do not necessarily have a client. So over here, you can see I've just basically broken it up into shifts. We have telemarketer managers, AM shift telemarketers, and PM shift telemarketers. And in order to get that last bit of device posture, you can see that I've actually created an external evaluation URL. Now this one is pretty basic. Right? This is just, designating, like, what time is it. If it's between 6AM and 3PM, then first shift users are allowed. This will return true, thus meaning that first shift users are allowed to access the call center application. If it is not, then this will return false, and they'll be denied access. And this isn't to shave showcase the power of using a worker as a timekeeper, but, really, it's more about talking about using a worker, to be able to put in logic that may not necessarily be there or you may not necessarily be able to, analyze in a traditional way. Because if we go into settings, you know, work client, you know, we do have a lot of things that will perform a device level scan for. But if we're in a clientless environment, you'll need to bait you know, you you have the ability to bake that back into the access policy, in any way you see fit. So if you need to look for certain certificates, like, if you need to you know, whatever the business logic happens to be for the incoming device, you'd be able to to, recreate that logic with a worker or create some, you know, a new logic or a specific one that is, you know, that is more or less specific to your, you know, to your environment, just your organizational needs. And we'd be able to, you know, still have your security posture intact despite the lack of a client. And that is something that, a lot of SaaS vendors would struggle with because a lot of a lot of them are going to end up requiring the client to perform some of the last miles of device posture, you know, verification. Alright. And, I guess, do we have any questions? Okay. So Philip is asking, is this supported by all browsers or only the, Chromium based browser? So browser isolation, does work on all of the, major browsers. So you'd find it with Safari, you'd find with Firefox, you'd find it with Chrome. We simply spit up a a headless Chromium browser at our edge and then use that to complete the request and then send the SKIA draw and message, you know, commands back to you to natively draw, on your on your device what the remote browser sees. Okay. Another question from Philip. What would the behavior oh, okay. Be with a no non supported browser with a user agent set to a supported browser. Would you be able to elaborate on that? And I guess, feel free to hop off mic if if that would if that would help. Oh, no worries. Yeah. No worries. We can probably double check on that one too, Philip. I think it's that the access portion would would still be functional, you know, like, basically any any resource if if it's, you know, something like the Internet score. But probably it's not the isolation aspect for those data controls that we talked about. But, yeah. That's a good question. I I know we are at time. So, I mean, thanks, Chris, for fitting as much in as you did in that fifteen minutes of showing about the web apps and SaaS and RDP and infrastructure, how to set up policies, implement those data controls, and everything that we talked about. And for folks watching, again, just a reminder that whether it's the general white paper on, like, you know, modernizing remote access or the implementation guide that has the click here, click here instructions of some of the stuff that Chris walks through and find those docs, in the in a sidebar. And everyone should get a recording to this if you found it useful and wanna watch anything back. But, other than that, we'll see you in the next security builders workshop. So thanks again for tuning in, everyone. Thank you.