-: Cloud access security broker.
What is a cloud access security broker, also known as a CASB?
Well, this is an enterprise management software
designed to mediate access to cloud services
by users across all types of devices.
Essentially, it's going to be a middle man
that helps you with your authentication
and ensure that people are using the services
they're supposed to use.
Now, there are many different vendors
who sell this type of product.
They include people like Symantec,
which uses the Blue Coat Proxy,
which I've personally used in a lot of my organizations.
There's Skyhigh Networks which is made by McAfee,
there's Forcepoint, there's Microsoft's Cloud App Security,
which is their version.
And Cisco has their version called Cloudlock.
All of these are different cloud access security brokers.
And the key term here is security.
By being a broker,
they're going to make sure that your device
is connecting to the right device using the right security.
Now, what are some benefits
of using these cloud access security brokers?
Well, they can enable a single sign-on authentication
and enforce access controls and authorizations
across your entire enterprise network,
all the way from your enterprise network
up to the cloud provider.
They also can help you scan for malware and rogue devices
and be able to find any of these devices
that might be on your network.
They also can help monitor and audit
user and resource activity
to know exactly what your users are doing
on your network at any time.
And finally, they can help you mitigate data exfiltration
by performing functions
like a data loss prevention system would.
Now, when you talk about a cloud access service broker,
I want you to remember they provide visibility
into how your clients and other network nodes
are using your cloud services.
When you start moving everything out to the cloud,
you have to think about how are my users using those things?
How much time are they spending?
Are they using it the right way?
Are they taking data and putting it where it shouldn't be?
And to do that, we have three different things.
We can set it up as either a forward proxy, a reverse proxy,
or using API access.
Now, when we talk about a forward proxy
in terms of a cloud access security broker,
we're essentially going to set up a security appliance or host
that's positioned at the client network edge,
and then it's going to forward the user traffic
to the cloud network
if the contents of that traffic comply with policy.
For example, in my home network,
I have my kids set up to use a forward proxy.
Now, this means that I went to their browser
and I configured it
so they had to go and connect to my proxy server
before they went out to the Internet.
This way, I can see what they're doing,
how much time they were spending on sites,
and if I needed to block certain things.
Now, as my kids got older, my son got smarter,
and he realized what a proxy server was.
And so, he wanted to prevent the use of the forward proxy.
So, what did he do?
Well, he evaded the proxy
and connected directly to the sites he wanted to.
And the way he did that was by bypassing the proxy.
And so, this is something you have to be concerned with
when you're dealing with a forward proxy.
Now, if I wanted to prevent that,
I might go to the second method, which is a reverse proxy.
Now, a reverse proxy is an appliance
that's positioned at the cloud network edge
and directs the traffic to the cloud services
if the contents of that traffic comply with the policy.
So, instead of having to go through the proxy
to leave the network,
you can leave the network,
but you can't get into the cloud network
until you hit the proxy.
That's the idea of the reverse proxy.
Now, the big problem with this is it only works
if the cloud application
you're trying to connect to supports proxies.
If they don't have proxy support,
you can't do a reverse proxy.
And so this brings us to our third method
which is an application programming interface or API.
This is a method that uses the broker's connections
between the cloud service and the cloud consumer
to make changes.
Now, essentially, when we're using
the application programming interface,
we're sending data
between the cloud service and the cloud consumer.
And what we're doing here
is we're being able to send information about those users.
So, if I had a user account that's now been disabled
or authorization has been revoked from the local network
because they were doing bad things,
I can send that using the cloud broker over the API
to the cloud service and say, "Hey, don't let Jason in.
We just fired that guy and his account has been disabled."
And so, they can now know not to give him access.
Now, the problem with this, the big warning here
is that it's dependent on the API
supporting the functions your policies demand.
So, as you start thinking about your policies,
and you start saying
well, I want people to be denied
or allowed access to everything,
that's probably going to be supported.
But if you start having very detailed requirements,
those things may not be supported,
depending on the service that you're using.
And if they don't support those policies,
the API doesn't have them
and you're not going to be able to use this method.