HARISH JAYAKUMAR: Hello, everybody.
Welcome to our session, and today we're
going to be talking about how to enhance your security posture
and run PCI compliant application with Anthos.
I'm Harish Jayakumar.
I lead the Application Modernization team
here at Google Cloud.
And today, with me, I have Ann.
ANN WALLACE: Hi, I'm Ann Wallace, Security Solution
Manager with Google Cloud.
HARISH JAYAKUMAR: Thank you, Ann.
Let's jump in.
So when we talk about running regulated workloads,
it can get quite complex, especially
because there are multiple stakeholders that
are involved in it.
On one side you have the makers, that's
the developers, the product owners, and the enterprise
architects.
And on the other side, you have the checkers,
which are the security teams, risk and compliance team,
and the legal teams as well.
So because of these complexities,
regulated workloads are the slowest ones
to move to the Cloud, or even to modernize.
So in this talk, we're going to be exploring
how to modernize these workloads, at the same time,
meet the compliance requirements that either need
to be on Google Cloud, or if you want to run them
on prem using Anthos.
Now, running a regulated workload, especially for PCI
in this case, what we're talking about with this one,
is challenging.
Because audits can be quite daunting.
Why?
One, compliance frameworks were not
built for cloud native architectures.
Two, it actually takes a village to pass an audit
and demonstrate the compliance associated with it.
Then three, you want to also avoid misconfigurations.
And if there are any, you have to fix that And then finally,
evidencing a shared responsibility, especially
today when we talk with customers, most of them
either have hybrid model or they're on multiple clouds,
so understanding that shared responsibility
becomes very, very important.
Which brings you to the slide where we are.
How does this fit into the shared responsibility model?
So when we're looking at simply, for example,
running Anthos on Google Cloud, or if you're
running Anthos on prem, you can see the difference over there.
Simply running on Anthos Cloud, you see a lot of it
is actually handed to you by Google itself.
And the customer only needs to focus
on the application, some configuration associated
with that, and some base images.
Whereas the picture completely changes when
you move to Anthos on prem.
It is much more controlled, the customer
has to take care of [? updating ?]
the node hardware, the networking, the storage,
and the physical hosting.
So we need to be able to see, for example, if something
happens, something goes wrong, who's responsible for it.
Let's take an example, for example, when
an identity management is done.
Whereas on the Google Cloud, you can actually
leverage the Google Cloud, and [? then repeat ?] some form
on the other with Cloud IAM, and then we
can handle that for you.
So customers are starting to adopt
Anthos to build the next generation digital platforms,
modernizing the security for cloud native deployments is
a great use case where they're actually using it.
And the key objectives for those modernizations,
are one, increasing the developer productivity
through the use of containers and micro services,
while adopting hybrid and multicloud
as deployment platforms.
Many of these customers process sensitive data
that include PII, PCI, and PHI.
Further, they must also meet the regulatory compliance.
But as application teams adopt new technology stacks
and development processes, using the existing paradigms
and processes is no longer optimal or even sufficient.
So in order to deliver the developer agility,
the security stack also needs to evolve
to align with the new development and [? product ?]
processes.
It must also address new threats that apply to modern production
environments.
Now, let's pivot quickly to the compliance requirements.
So we've taken some of the compliance frameworks,
such as NIST 800-53, which maps to [INAUDIBLE],, PCI DSS,
ISO 27001, and have identified some common technical
requirements.
They actually fall into these five categories--
segmentation and isolation, identity access management,
data security, supply chain, application security.
Now, we don't have time to dive into all these
in this 25 minutes talk, but we will
talk about how Anthos can help with several
of these requirements right out of the box.
As you can see, the same five requirements,
we have put them down into five pillars.
And out of the box, Anthos offers
a lot of security capabilities.
Each control aligns with the common compliance requirements
that we talked about in the previous slide,
whether it's going to be segmentation networking, IAM
data security and encryption, secure supply chain,
and application security.
So as you can see, most of these features
to help you achieve your security posture.
But as I mentioned before, it's the shared responsibility
model, and you need to know how to blend the controls together
appropriately and understand what you are responsible for.
For that, what we we're going to be introducing
is Anthos Blueprints.
And to talk in detail about that,
I'd like to call back Ann.
Ann?
ANN WALLACE: Cool, thanks Harish.
So before we dive into the Anthos Blueprints,
first, let's talk about our security blueprint.
So we've designed security blueprint
to help some of this complexity that Harish
described, to simplify it.
So the first security blueprint we
have is called a security posture.
So this is a collection of resources and code
that deliver granular and specific security
postures to a workload, such as maybe a customer facing
application or back end process.
For example, securing data, or securing API endpoints.
The next one that we offer is called a landing zone.
So this is a pre-configured environment
with a standard set of secure cloud Infrastructure, policy,
and guidelines.
So this can be something that's otherwise very complicated
to set up and might take months of investigation,
implementation by trial and error
to get right the first time.
So an example, this PCI for Anthos.
Regardless of the type of security blueprint,
they're all designed to be easy to use and deploy.
And we also employ all of Google Cloud Security
best practices in the blueprints.
So you can say they're secure by default.
So one of the first security landing zones that we released
was PCI on GKE, and coming soon as PIC on Anthos.
So these help customers get started with compliance
on Anthos quicker.
So it also allows you to quickly and easily deploy
workloads on Anthos that align to PCI DSS in a repeatable,
supported, and secure way.
So let's look at everything that's
included in the blueprint.
So the PCI on Anthos Blueprint contains
many opinionated reference architecture diagrams
depicting the infrastructure and application deployment.
While they're intended to be used with deployable assets,
they also show you how to create diagrams
of your containerized cardholder data environments,
and the boundaries between PCI and non-PCI workloads, which
is a requirement in PCI audits.
The Blueprint also contains different deployable assets.
And then we also include PCI DSS 3.2.1 mappings
to the solutions, and a compliance white paper.
So with our Anthos on GCP Blueprint,
we provide you with Terraform templates
to set up your infrastructure.
These include org policies, projects, VPCs,
and GKE clusters.
And as Harish described about the shift in the shared
responsibility model, on prem we only
provide you with reference architectures
for squares one and two.
But with both of the blueprints, we
provide you with service mesh profiles, GKE configurations,
ACM policies, and then a demo app
to test out the environment configuration and setup.
So let's pivot to segmentation.
There are two types of segmentation.
So the first one is macro segmentation.
So these are things that you do outside the cluster.
So you segment the users, networks,
and applications using different Google Cloud features
and tools.
This really helps you set aside the scope of the audit.
And then we have micro segmentation.
So these are things that you do inside the cluster.
So let's double click on that a little bit.
So with GKE micro segmentation, we offer many ways to do this.
So we have network policies.
This helps with layer 3 and 4 network level segmentation.
Then we have GKE namespaces for virtual clusters
to segment teams, or maybe app versus prod,
or app dev versus prod.
Then we have GKE private clusters,
so you have clusters of private IP space.
And then Anthos service mesh.
Then the net net here is there are many ways
to do micro segmentation in a cluster.
So for the PCI on Anthos on prem blueprint,
the first layer of segmentation is addressed
through separate clusters.
So we create two clusters, two user clusters,
one for in-scope, or for your cardholder data cluster,
and then one for the out-of-scope workloads.
And then building upon the segmentation,
we have segmented out of the pods within a cluster,
but you further need to demonstrate separation
of maybe dev and test versus prod environments
to your auditor, or you need to segment application profiles.
So this is where you would use different namespaces.
And then oftentimes, you're presented with a requirement
to protect the routing information and the private IP
spaces.
This is where you mark a cluster as private.
And such a cluster and the master
become inaccessible from the public internet.
And then the nodes in the private cluster
do not have public IP addresses.
So the admin and user clusters are
private for the on prem blueprint and the GCP
blueprint.
So looking at some of the reference architectures that
are provided as part of this blueprint,
you can see here that again, the in-scope and out-of-scope
cluster separation.
And then we have Anthos Service Mesh,
so it's a single mesh for multi clusters.
And then our demo app is called Online Boutique.
So this is an e-commerce micro services demo application.
So this allows you to test out the controls
and the architecture.
The PCI DSS audit burden is minimized
by moving the micro services from that demo application that
don't touch payment card data into the out-of-scope cluster.
This reference architecture details this layout.
This also helps you with your own architectures
and documentation.
And then looking more specifically at
PCI requirements.
So PCI requirement four talks about encrypting
data in flight, specifically of cardholder data
across open and public networks.
For our on prem blueprint, the in-scope and out-of-scope
clusters are in separate networks,
which helps with strong isolation for PCI boundaries.
This also means that the cross cluster communication must
go through a Istio gateway.
All cross customer communication uses mutual TLS authentication
and encryption.
Citadel is also included for managing
the internal certificates.
So a lot of the blueprint is for day zero,
but we also want to talk about day one and day
two sort of scenarios.
So this is where policy as code or shifting left happen.
So setting up initially is great, everything's PCI
compliant.
But as you're deploying new containers or new code
into your environment, how do you make sure
these meet PCI requirements?
So to help with this, we have binary authorization,
Anthos Config Management, and Anthos Policy Controller.
So let's look at these in a little bit more detail.
So for a requirements such as establish a process
to identify security vulnerabilities,
you can use Container Registry Vulnerability Scanning.
So this checks the images that you
push into the registry for known security vulnerabilities.
It is constantly refreshing its vulnerability database
by ingesting corresponding vendor security feeds,
so that you can be notified of new vulnerabilities that
maybe previously affected scan containers.
You can also tie this in with Pub/Sub to get notifications,
so you can integrate this in with your CICD process,
or file bugs for newly discovered vulnerabilities.
And another requirement is to ensure all systems
and software are protected from known vulnerabilities.
This is where binary authorization can help.
So it ensures that only properly signed
containers are deployed into production
or other environments.
You can use binary authorization to create deployment policies
based on container image metadata.
So these policies can be based on attestation,
such as a vulnerability scan, or other types of signatures,
such as maybe being built by a particular pipeline,
or having gone through a specific QA process.
Again, this ensures that only trusted images are deployed
into your environments.
So let's put all this together.
So when code is checked into GitHub or your source code
repository, it triggers a a build in Cloud Build.
Cloud Build then generates a new container image.
It will create a build record that contains information
on the image, including the location, the source code
from which the image was built.
And then that triggers a vulnerability scan.
So the vulnerability scan is done, the results
of that scan are stored as part of the metadata
for that container.
And as mentioned on the previous slide,
you can configure binary authorization
to require attestation based on the vulnerability scan results.
So this prevents images with known vulnerabilities
beyond a certain level, so maybe say high, from being deployed.
You can also have other requirements,
like only allowing images from trusted sources.
So if someone tries to deploy one
of these unauthorized images, binary authorization
will stop it, and all of this is logged in Cloud Audit Log.
So now Anthos Config Management, or ACM.
So with ACM, you can create common configurations
across all your infrastructure, including custom policies,
and apply it to both on prem and across clouds.
Anthos Config Management evaluates the changes
and rolls them out to all the Kubernetes clusters,
so that your desired state is always reflected.
And so based on Open Policy Agent's Gateway,
ACM Policy Controller provides first class integration
between OPA and Kubernetes via a custom controller.
So this turns Rego policies into Kubernetes objects,
allowing them to be customized and deployed
using your standard workflows.
When policy controller is configured,
incoming objects can be denied admission into your cluster,
or audited to see if they violate governance policies.
So we offer quite a few sample policies
that you can use with ACM.
They include policies like required services
to disable unauthorized access, or label enforcement.
But more specifically, with our Anthos PCI Blueprint,
we include policies to help enforce TLS.
And again, this helps enforce PCI requirement four,
which talks about encrypting data in transit,
specifically of cardholder data across open and public
networks.
So as you can see from this slide,
looking at some other common controls,
we can see how services like binary authorization
or Policy Controller and Anthos Config Management can help.
And then lastly, we tie all of this together
by mapping the various components
and policies in the blueprint to PCI DSS 3.2.1.
And we also include a PCI white paper.
So the white paper provides an independent third party
assessment of the blueprint performed by PCI auditors.
This not only gives you, our customers, more confidence
in our solution.
It is also something that you can provide your QSA
as part of your audit, which hopefully will help speed up
your assessment.
So to learn more about this, or our other Blueprint, schedule
a session with your Google team.
Or check out the links here.
So there's one for Google Cloud and PCI,
and one for our security blueprints.
Thank you.