[MUSIC PLAYING]
EMIL KINER: Welcome to the "Google Cloud Security
Showcase," a special web series where
we'll focus on security use cases
that customers can solve with Google Cloud.
My name is Emil, and I'm a product manager
at Google Cloud.
Today, we'll be walking you through one
of the top questions we get from customers--
how do I protect my application from DDoS attacks and other web
attacks with Google Cloud Armor?
Google Cloud Armor is the web application firewall and DDoS
mitigation service able to provide protection
from L3, L4 volumetric and protocol-based DDoS attacks,
as well as L7 protection and filtering
for workloads deployed on GCP, on prem,
or with other infrastructure providers.
Cloud Armor is deeply integrated with the global load balancing
infrastructure and is able to inspect and filter
incoming requests after SSL termination has occurred.
As a web application firewall, Cloud Armor
contains preconfigured rules to help mitigate the risk
from the most common attacks and vulnerability exploit attempts.
Users have access to real-time telemetry in the form of log
[INAUDIBLE] Cloud Logging containing
Cloud Armor's decisions on a per request basis, a monitoring
dashboard that gives granular views of allowed,
denied, or preview traffic, as well as correlated WAF security
finding sent to the Cloud Security Command Center.
To get started, we're first going
to want to deploy the external HTTPS load balancer in front
of our application.
You can do so by navigating to Network Services, Load
Balancing in your Cloud console, and clicking Create Load
Balancer.
Click Start Configuration for HTTPS load bouncing.
Select From the Internet and click Continue.
We're going to name this load balancer examplelb.
Now, you will have to configure the back end, host rules,
and front-end configuration for the GCLB.
For back-end configuration, we'll
select an existing back-end service containing
my protected workload.
Next, host and path rules allow you
to specify advanced routing rules to proxy requests
to different back ends based on the requested URL or hostname.
For now, we'll choose simple routing.
After that, we will configure the front end,
choosing HTTP as the protocol and leaving all other settings
as default. If you wanted to select HTTPS as the protocol,
here is where you would upload your own SSL certificates
or use Google-managed certs.
Finally, we click the Create button
to create the load balancer.
With your application residing behind the HTTPS LB,
you will be automatically protected
from the L3, L4 volumetric and protocol-based DDoS attacks.
Now, we will configure a Cloud Armor security
policy to provide layer 7 protection for our application.
We do this by first navigating to Network Security, Cloud
Armor in the Cloud console.
We'll want to create a new security policy
by clicking Create Policy.
Next, we'll name the policy, configure the default action
of the policy to deny, and select the appropriate response
code.
After that, we will create rules within this policy
by expanding Add More Rules and clicking Add Rule.
The first rule we'll create is a rule
to block SQL injection attacks.
After selecting Advanced Mode, you
are able to write a rule using the Cloud Armor rules
language called CEL--
Common Expression Language.
With the evaluate preconfigured expression helper function,
we are able to invoke preconfigured expression
sets, including the preconfigured WAF rules,
as well as named IP lists.
This rule will now match on incoming traffic that contains
an SQL injection attack.
Next, we select the action to take
in the event of a request satisfying the match condition.
In this case, my desired action is deny
and I want to return a 403 HTTP response code.
Preview mode is a logging-only mode
that will generate a log when the rule matches,
but the associated action won't be taken.
In this case, I will not enable preview mode,
but it is a good idea to do so in production
to validate the rule's impact before enabling it
on your production traffic.
Finally, we specify a priority for the rule.
Rules are evaluated in priority order
from lowest to highest with the default
rule being evaluated last.
In this policy, I only want to accept user traffic
from Singapore, the United Kingdom, and Mexico.
Since the default action of the policy is deny,
I will create an allow rule that matches on those geographies.
We do so by checking if the origin region code matches
my desired geographies.
The or operator allows us to combine several region code
checks into one rule.
Now that we have created some rules in our policy,
it's time to attach it to one or more back-end services.
In order to do so, we click Next Step, and then
the Add Target button.
I select the target back-end service
that I wish to protect with a security policy.
Now, all traffic destined to this back-end service
will be evaluated against this Cloud Armor security policy
before being proxied to the back end.
Lastly, we click Create Policy to save and propagate
this policy across Google's global edge.
We have now successfully deployed
Cloud Armor and the HTTPS load balancer
in front of our demo application.
The application is now protected from
volumetric and protocol-based DDoS attacks,
while well-formed layer 7 traffic will
have to conform to the security policy
we have specified in order to reach my application.
We can now switch over to the network security policies
dashboard under Cloud Monitoring to see
real-time metrics of my application broken down
by policy, back-end service, as well as by action taken.
Thank you for tuning in.
Please visit cloud.google.com/security
for more content from Google Cloud experts.
[MUSIC PLAYING]