SASE - Secure remote access to your critical infrastructure

In this video, learn how Cloudflare's SASE platform can provide highly secure access to your critical infrastructure by leveraging a modern ZTNA service to implement Zero Trust principles Applications, databases and their servers are running in a variety of locations from on-premises data centers to cloud hyperscalers, making the need to secure administrative access more important than ever.

Chapters

• 
  Introduction to SASE and Securing Access to Critical Infrastructure 0s
• 
  Connecting and Securing Private Servers with Cloudflare Tunnels 50s
• 
  Using Internal DNS to Securely Resolve Private Network Resources 02m12s
• 
  Connecting User Devices Securely with Cloudflare's Device Agent 03m01s
• 
  Enforcing Access Control with Identity, Network and Device Based Security Policies 03m48s
• 
  Auditing and Logging Access to Critical Infrastructure 05m03s

Transcript

Secure Access Service Edge or SASE solutions incorporate Zero Trust Network Access or ZTNA

to provide access to applications such as an internal wiki or a HR system.

But what about critical high risk services such as a database administration tool or

service requiring access via SSH or RDP?

In these cases, it's important to be able to ensure tight security from the device all the

way to the application and allow authorized users who are using strong authentication on

trusted devices. Let's say we need to secure access to a database admin app such as

pgAdmin, a common web interface for Postgres databases,

and also access to SSH on the same server.

Imagine we have an example environment, and in it we've already created connectivity

from the server to Cloudflare, using a software agent that maintains a

secure tunnel from the private network where the Pgadmin server is running back to the

Cloudflare network. No private server IP addresses are going to be exposed to the

Internet. We're essentially connecting this server to our new corporate network managed

by Cloudflare. Once connected, there are two methods by which we can access

our private server. Method one is to create a public hostname which resolves to Cloudflare,

which in turn proxies and routes the traffic for that specific hostname to that

application at the end of our tunnel.

And this method allows anyone, anywhere, on any device to easily access the

application. But that's not enough.

In this scenario we want to implement even tighter security.

So method two is to configure the tunnel to proxy access only to the server IP with no

public DNS record, and only for trusted users with managed devices that are connected to

the Cloudflare network.

So none of this server has any public exposure.

Now, to provide access to only database admins,

there are a few things we need to do.

We need to use an internal hostname that resolves to our server.

We need to connect to the user device to the Cloudflare managed network.

And we need to identify who the user is and if their device has a good security posture.

So let's first look at how we do the internal DNS resolution.

Because nobody likes using IP addresses to access services with the exception of

So we really should always be using hostnames.

With Cloudflare, it's as simple as connecting a private DNS service to the network,

and then building a policy that says any request from a user or a network,

anywhere on the Cloudflare network, for an internal domain,

should be answered by that specific DNS service.

In this example, we're going to connect it to Cloudflare using exactly the same tunnel

software that we're using for the database server.

So at this point we have our database admin tool that's connected to Cloudflare and we

have an ability to resolve the IP address of that private network using an internal

hostname. Next, we need to securely connect the user device to Cloudflare so that all

traffic destined for our database server is over secure channels.

We do this using a similar piece of software we used on the server,

but one that's designed for user devices.

It supports macOS, windows, Linux, iOS and Android and connects the

device to Cloudflare using a secure tunnel.

But the agent can actually provide information about the security posture of the

device, and we'll talk about that later when we look at the policy itself.

So once the user device is connected to Cloudflare,

requests for private applications are resolved using the internal DNS service,

and traffic is routed from the device through Cloudflare through secure tunnels down to the

private IP the application is running on.

Now we have secured connectivity all the way from the device to the server.

The last thing we need to do is actually write a policy which enforces access only to

users that you authorize, and that the device they're on meets a

certain level of security.

We use information from our device agent, and also leverage your existing identity and

device services to help build that policy.

Cloudflare is typically integrated with one or more identity providers.

Usually, your company has a central directory for employees,

but you can also add more.

For example, you might manage contractors in a different directory.

Cloudflare can also integrate with XDR platforms such as CrowdStrike and

SentinelOne, and these give us information we can use in the policy regards to the security

posture of the device, such as if the device is free of malware.

For our own agent, we can provide information about the device,

such as is the hard disk encrypted or if the local firewall is enabled.

So now we have all the information about the user,

their device, and how they're connected to Cloudflare.

A policy can be created which only allows users who have authenticated using a strong

factor, such as MFA using a hard token, that they also exist in a group such as IT

administrators, and they're using a secure device free of malware.

This policy sits in front of access to both the database admin tool and the SSH service.

Finally, because you might want to record of all access to the database administration

tool, you can optionally inject a page after authentication asking for justification for

access to the app and that gets audited and logged in Cloudflare.

So in summary, you've seen an example of how Cloudflare can protect access to some of your

critical infrastructure using our SASE platform.

We can help lock down access to servers only from highly authenticated users on tightly

managed devices that must be connected to your new corporate network or managed by

Cloudflare. Well, thanks for watching.

This video is part of a series which explains how to build your new corporate network using

Cloudflare SASE platform.

You can watch the other videos in this series to learn more.

Hi, I'm Simon from Cloudflare.

Congrats on finding this video!

We also cover a wide variety of topics including application security,

corporate networking, and all the developer content the Internet

can hold. Follow us online and thanks for watching!