VM-SERIES ON GOOGLE CLOUD DEPLOYMENT GUIDELINES

Transcription

1 SERIES ON GOOGLE CLOUD DEPLOYMENT GUIDELINES Organizations are adopting Google Cloud Platform to take advantage of the same technologies that drive common Google services. Many business initiatives, such as big data, analytics and machine learning, deployed on GCP allow you to leverage contextual data collected from billions of search engine data points. The power behind GCP, combined with agility and a global footprint, help you quickly deploy enterprise-class applications and services. From a security perspective, moving your applications and data to GCP does not necessarily eliminate or minimize your security challenges, which is why it s so critical to understand the shared responsibility model. GCP is likely more secure than your data center, but in most cases, your GCP deployment is connected to your corporate network, making GCP resources accessible by users and possibly attackers. Wherever they are located in a public or private cloud, or in a physical data center your applications and data are targets, and protecting them on GCP should be no different from protecting them in your own data center. Deployed within a Google project, virtualized next-generation firewalls allow you to securely deploy enterprise applications and data to GCP. This document complements the technical documentation with examples of how the can be deployed on GCP. Palo Alto s on Google Cloud Deployment Guidelines White Paper 1

2 Table of Contents Security Is a Shared Responsibility 3 GCP Firewall or Next-Generation Firewall? 3 on GCP Licensing 3 Sizing and Performance Considerations 4 Securing Google Cloud Deployment Scenarios 5 Deploying Next-Generation Firewalls in Google Cloud 5 Typical Deployment in a Google Cloud VPC 5 Securing Outbound and East-West Traffic Flows 6 High Availability and Failover 6 Scale-Out Security for Google Cloud 6 Hybrid Cloud 7 Establishing a Connection to Google Cloud 7 Advanced Integration Features 9 Automate Deployments Using Bootstrapping 9 Monitoring via Google Stackdriver 9 Enabling Scale-Out Security Using VM Monitoring 9 Conclusion 10 References 10 Palo Alto s on Google Cloud Deployment Guidelines White Paper 2

3 Security Is a Shared Responsibility GCP was designed with security as a core component, using a variety of technologies and processes to secure information stored on Google servers. However, Google is clear about where their responsibilities end and customers begin. As shown in Figure 1, it is the customer s responsibility in all cases to protect their operating systems, packages and applications deployed. Security best practices dictate that you should take a prevention-based approach to protecting your applications and data in the public cloud: understand your threat exposure through application visibility, use policies to reduce the attack surface area, and then prevent threats and data exfiltration within the allowed traffic. That s where the on GCP can help it complements GCP firewalls by securely enabling your business-critical applications, preventing threats within allowed application flows and stopping data exfiltration. GCP Firewall or Next-Generation Firewall? As you deploy workloads on GCP, the question of how the complements GCP firewalls will arise. GCP firewall performs port-based filtering to control access to the GCP resources deployed. They are a required feature in that they must be enabled for the cloud deployment to be operational. They also: Follow a positive control security model, using port-based policies to allow traffic and deny all else. GCP firewall rules cannot be used to explicitly deny traffic on GCP. IT Managed Google Managed Content Access Policies Usage Deployment Web Application Security Identify Operations Access and authentication security Guest OS, data and content Audit logging Storage + encryption Hardened kernel + IPC Boot Hardware Google Cloud Enterprise Allow all outbound traffic by default. More granular policies can be defined to further reduce outbound traffic flows, but only by whitelisting IPs. Enable you to add or remove rules at any time, meaning there is no traditional policy commit process. As a reminder, years ago, application developers stopped adhering to specific port-protocol development methodology, allowing tech-savvy applications and users to bypass them with ease by hopping ports, using SSL, sneaking across TCP/80 or using non-standard ports. The addresses the security implications of the evolving application landscape by classifying traffic based on the application, not the port, allowing you to fully understand your threat exposure, reduce your threat footprint with application-based policies, and prevent threats and data exfiltration. The complements GCP firewalls by enabling an application-centric, prevention-based approach to securing GCP deployments. Complete visibility and control. The gives you complete visibility into the applications traversing your cloud deployment and the content within, malicious or otherwise. This knowledge helps you deploy a more consistent, stronger security policy for inbound and outbound traffic to prevent known and unknown attacks. Reduce the attack surface, limit data exfiltration. Using the application identity as a means of enforcing a positive security model reduces the attack surface by enabling only allowed applications and denying all else. Application usage can be aligned with business needs, extending to application functions as needed (e.g., allow SharePoint documents for all but limit SharePoint administration access to the IT group). In addition to controlling applications, policies can be enabled to block or generate alerts on file and data transfers, limiting data exfiltration. Prevent known and unknown threats. Applying application-specific threat prevention policies to allowed traffic can block known threats, including vulnerability exploits, malware, and malware-generated command-and-control traffic. Unknown and potentially malicious files are analyzed based on hundreds of behaviors. If a file is deemed malicious, a prevention mechanism is delivered in as few as five minutes. Following delivery, the information gained from file analysis is used to continually improve all other prevention capabilities. Used in conjunction with GCP firewall, Palo Alto s virtualized next-generation firewall enables you to protect your applications and data deployed in the public cloud using an application-centric, prevention-based approach. on GCP Licensing The on GCP supports several licensing options, including a pay-as-you-go, consumption-based model, a traditional bring-your-own-license model and the Enterprise License Agreement, or ELA. Consumption-based licensing: This licensing model allows you to purchase the, select subscriptions and Premium Support as a bundle directly through your Google Cloud Launcher console on a pay-as-you-go basis with per-second billing, subject to a minimum specified on the Launcher page. IaaS Google Cloud Storage Shared Security Model: Where Google ends and IT controls begin Figure 1: GCP Shared Security Model diagram Palo Alto s on Google Cloud Deployment Guidelines White Paper 3

4 Bundle 1 contents: 300 firewall license, Threat Prevention (inclusive of IPS, AV, and malware prevention) subscription and Premium Support (spoken and written English only). Bundle 2 contents: 300 firewall license, Threat Prevention (inclusive of IPS, AV, and malware prevention), WildFire cloud-based threat analysis, URL Filtering and GlobalProtect network security for endpoints subscriptions, and Premium Support (spoken and written English only). Bring your own license: You can purchase any one of the models, along with the associated subscriptions and support, via normal Palo Alto s channels and then deploy via a license authorization code through the Google Cloud Launcher. ELA: For large-scale deployments on GCP or across multiple virtualization environments, the ELA allows you to forecast, and purchase upfront, the firewalls to be deployed over a one- or three-year period. The ELA gives you a single license authorization code used for the life of the term, providing predictable security spend and simplifying the licensing process by establishing a single start and end date for all licenses and subscriptions. Each ELA includes a firewall, subscriptions for Threat Prevention, URL Filtering, WildFire, and GlobalProtect Gateway, plus unlimited Panorama virtual machine licenses and support. Sizing and Performance Considerations Google Cloud allows you to select virtual machine instance sizes based on predefined machine types offered by Google or custom machine types. The main considerations in selecting a VM size include: Number of virtual CPUs: licensing supports options that use 2, 4, 8 or 16 vcpus. Memory: requires specific amounts of memory based on the license model. Check the on Google Cloud Platform datasheet for more details. Number of network interfaces: Google Cloud allows the following number of maximum interfaces: For n1-standard-x instance types supported by : one NIC per value of x, with a minimum of two NICs and a maximum of eight. The uses one dedicated network interface by default, the first one, eth0 for management. You can use the interface swap feature to move management to eth1 and make eth0 a data plane interface when deployed behind the Google Cloud HTTP(S) load balancer. Check documentation for the on Google Cloud Platform for more information. Disk storage: The uses a minimum 60GB disk for PAN-OS and logs. You can choose to use a larger local disk, add more disks for additional log storage or use a log collector offering, such as Panorama network security management or Palo Alto s Logging Service. The recommended options allow deleting/terminating the instance without the need to export local logs. Performance: The on Google Cloud Platform supports Data Plane Development Kit libraries, which provide fast packet processing to improve network performance. Larger licenses and larger Google Cloud VM sizes will give higher network performance. As a best practice, it is also recommended in public cloud environments to consider using a scale-out architecture, when possible, and then larger, higher-performing VMs. This avoids being subject to a single point of failure and allows for addition or removal of firewall capacity as needed. Follow GCP best practices for improving network performance. Select an instance size and license based on your deployment use cases, cost factors and performance requirements. For example, most inbound traffic (i.e., from the internet to your GCP deployment) use cases require at least three network interfaces on the firewall: a management interface for firewall administration, an untrust interface for the internet-facing side and a trust interface for the private network. The following table shows the recommended VM sizes for specific licenses based on the available vcpu, memory and network interfaces offered by Google Cloud. Refer to Google Cloud documentation for more information. 100, 200 BYOL: 300, 1000-HV BYOL: 500 BYOL: 700 CPU cores (min) Memory (min) 6.5GB 9GB 16GB 56GB Disk 60GB 60GB 60GB 60GB Google Cloud instance type (vcpus, RAM, NICs) n1-standard-2 (2, 7.5, 3) n1-standard-4 (4, 15, 4) n1-standard-8 (8, 30, 8) n1-standard-16 (16, 60, 8) Licensing BYOL or ELA Bundle 1, Bundle 2, BYOL or ELA BYOL or ELA BYOL or ELA Palo Alto s on Google Cloud Deployment Guidelines White Paper 4

5 Securing Google Cloud Deployment Scenarios The can be deployed on GCP to address several different use cases, as shown in Figure 2. Hybrid: Secure traffic from on-premise environments into the Google Cloud environment. Segmentation: Secure traffic between application tiers deployed in different VPCs or between VPCs of different trust levels. This use case is commonly known as east-west flow. Gateway firewall: Secure traffic inbound and outbound, i.e., north-south, from a Google Cloud deployment. Remote access: Use as a GlobalProtect VPN gateway running in Google Cloud for security of mobile users. Deploying Next-Generation Firewalls in Google Cloud The can be deployed in virtual private cloud, or VPC, networks in GCP to protect the infrastructure- and platformas-a-service components of Google Cloud Platform. In addition to these deployment architectures, you can consider building architectures that use VPC network peering and shared VPCs. Typical Deployment in a Google Cloud VPC Google Cloud Platform offers VPC networking functionality that provides an RFC 1918 IP space for creating networks and subnets, and to connect VMs in those networks to each other and the internet. The VPC includes a stateful firewall and ACL rules to enforce basic network controls and define which packets can reach specific destinations. By default, the stateful GCP firewall will block all incoming connections and allow all outgoing connections. It does not inspect traffic for malware, attacks or connections to command-and-control traffic; it only controls traffic by port, protocol and IP address. Google Cloud VPC also includes a routing feature that tells the network how to forward packets to every subnet in that VPC network, as well as a default internet gateway route for outbound packets to the internet. You can manually add routes and forwarding rules to control packets based on the desired destination and next hop. The is deployed in the network path to protect north-south VPC traffic. To protect east-west traffic between VPCs that contain different application tiers or applications, you can route traffic through the using the single network interface per VPC. These fundamental features of the VPC let you deploy the firewall in the network path to secure traffic flowing inside the VPC. In GCP, VMs can have only one network interface per VPC. This allows you to create architectures to secure north-south and east-west traffic. Figure 3 shows a common deployment for protecting north-south and east-west flows for an internet-facing web service. is deployed with four network interfaces across VPCs for management, public/untrust facing the internet, web server and database. Users will connect to the public IP address of the management interface to configure and manage the firewall over SSH for CLI and HTTPS for the web interface. The firewall security policy can be configured to permit web traffic from the public interface (untrust zone) to the web interface (web zone). Additionally, a destination NAT policy sends all traffic from eth1 to the web server. Users who want to use the web server will connect to the public IP of the eth1 interface (public IP2 assigned in the Google Cloud console), at which point the firewall will inspect traffic and send it, via DNAT, to the web server. Threat Prevention on the protects the web server against vulnerabilities, such as the CVE remote code execution vulnerability found in some versions of the Apache Struts server. Project Hybrid Gateway Segmentation Mobile devices/ remote users Figure 2: on GCP deployment scenarios Management VPC /24 Public IP1 Public VPC /24 Public IP2 eth0 eth1 GP eth2 eth3 Web VPC /24 Webserver Database VPC /24 Database Apache WordPress SQL Server Figure 3: Common deployment for securing north-south and east-west traffic flows MySQL Palo Alto s on Google Cloud Deployment Guidelines White Paper 5

6 Figure 3 depicts application tiers deployed across VPCs for detailed inspection between them. It is also common to deploy an entire application stack in a VPC and use the for east-west inspection between different applications across these VPCs. This type of inter-vpc inspection allows you to connect different systems at different trust levels while ensuring security needs are met. Securing Outbound and East-West Traffic Flows The can be deployed to protect traffic outbound from a GCP VPC to the internet or an on-premise environment for hybrid architectures, as well as to secure east-west traffic between VPCs in GCP. The first step is to use the GCP routing and forwarding rules to ensure that is placed in the line of traffic for specified destinations. This ensures any VM or instance that is hijacked or compromised cannot bypass inspection by the firewall, even if the internal host routes are modified to change the default gateway. To protect these traffic flows, a security policy should be set up to allow east-west traffic between the web and database VPCs for MySQL traffic, which allows the WordPress server to securely connect to the database. This protects the service against SQL injection attacks. Finally, a security policy should be set up in the to allow the Ubuntu -based servers in web and database VPCs to connect to *.ubuntu.com or *.canonical.com for apt-get App-ID only. This ensures only approved, whitelisted traffic flows out and data cannot be exfiltrated by a command-and-control server. To ensure all outbound traffic from the web and database networks does not bypass the firewall, you must configure GCP routing rules that forward all traffic destined for /0 to the local interface of the firewall: eth2 s IP address in the web VPC, and eth3 s IP address in the database VPC. This type of inter-tier inspection makes it easier to meet compliance requirements for protecting payment card information and personally identifiable information. To configure outbound and east-west security in GCP, let s use the example deployment shown in Figure 3. Configure the following GCP routing rules in your project: GCP Route Rule Source Subnet or VPC Destination Priority Next Hop East-west Web /24 1 Database / Private IP of in web subnet East-west Database /24 Outbound Web /24 Internet Outbound Database /24 To protect against failures, you can use the GCP route metric feature. This feature allows you to set multiple routes to the same destination and next hop (the two different firewall instances) with different priorities. We will use the terms primary and secondary for these firewalls to distinguish this failover from traditional high availability that uses the terms active and passive. Normally, traffic will flow through the lower-metric, higher priority firewall called primary here based on the routing/forwarding rules configured in the VPC network. When GCP detects failure of the primary firewall, it shifts all traffic to the secondary firewall. This failover typically takes about 30 seconds. During this period, all existing sessions through the primary firewall will terminate, and applications establishing new sessions will do so on the secondary firewall. Web / Private IP of in database subnet /0 Internet /0 300 Private IP of in web subnet 300 Private IP of in database subnet High Availability and Failover Public cloud environments, such as GCP, are built on the premise of having no single point of failure, using the idea of service reliability rather than session reliability. When a failure occurs, the application or service itself must be available, and the application components must be able to deal with an individual traffic session failure by reestablishing the session. IP1 VMeth2 Web VPC Primary Secondary Database VPC Figure 4: Failover between primary and secondary firewalls using GCP VPC routes Scale-Out Security for Google Cloud Public clouds are commonly used for large-scale, internet-facing applications. These architectures use the cloud provider s native load balancing, which provides several advantages over traditional load balancing, such as lower costs, higher geographic availability across GCP availability zones and integration with auto-scaling of back-end instances. GCP provides three load balancing options: external HTTP(S), external TCP/UDP and internal TCP/UDP. This allows you to create common architecture IP2 eth2 2 1 Priority: 200 to Primary Destination /0 Next Hop IP1 of eth2 Priority: 200 to Primary Destination /0 Next Hop IP1 of eth2 Palo Alto s on Google Cloud Deployment Guidelines White Paper 6

7 patterns, such as the load balancer sandwich and three-tier applications. This architecture can be used for internet-facing applications as well as for traffic between VPCs or from on-premise networks into GCP for hybrid cloud architectures. A load balancer sandwich architecture using GCP load balancing provides a highly available and secure architecture for protecting applications against advanced attacks. Users connect to the external GCP HTTP(S) or TCP/UDP load balancer, which uses its load balancing algorithm to send the traffic to one of the firewalls deployed behind it. The firewall inspects this traffic based on your security policies and sends it, via a destination NAT, to the GCP internal load balancing service. The firewall will perform a source NAT on this traffic to ensure returning session traffic comes back to the same instance. The internal load balancer will then balance its load balancing pool, which is typically the front-end or web tier of the application. GCP load balancing allows both the front-end and tiers to be deployed in separate GCP availability zones for higher geographic reliability. Health checks ensure the load balancing service uses only healthy back-end instances, for both the and applications, to send traffic to the next tier. Project Web VPC /24 Scale-out security /24 Web/front-end application tier Private VPC Application DNS name External HTTP(s) or TCP/UDP load balancing Internal load balancing The choice between HTTP(S) or TCP/UDP for external load balancing depends on your applications requirements refer to GCP documentation for more details. A basic overview is provided here in relation to security aspects. HTTP(S) is the preferred choice for internet-facing web applications as it includes support for hosting multiple HTTP path-based applications and an option for SSL offload. The HTTP(S) load balancer will, however, perform a proxy function by inserting its IP address as the source IP and placing the original user s source IP in the X-Forwarded-For header of the HTTP message. In contrast, the external TCP/UDP load balancer from GCP will only provide a normal, network-based load balancing service it does not perform an HTTP proxy function and will preserve the user s original source IP. This enables the firewall to see the true source IP, which provides full visibility of traffic to the, for a variety of purposes, including geolocation, country-based security policies, and blocking attackers as well as command-and-control traffic, by comparing against known malicious or high-risk IPs via external dynamic lists. Note: GCP s HTTP(S) load balancing only sends packets to the primary network interface of its load balance pool eth0 which, in the case of the, is a management interface. To support a scaled-out deployment, you can deploy the with a swapped interface whereby the primary interface, eth0, becomes a data plane interface (E1/1), and the second interface, the eth1 console, becomes the management interface. This allows the to be deployed behind the external HTTP(S) load balancer and still have a dedicated management interface to meet best practices. This setup can also be bootstrapped for automated deployments via templates. Additional network interfaces attached to the will become data plane interfaces (E1/2 and so on). Hybrid Cloud A hybrid cloud combines your existing data center resources, over which you have complete control, with ready-made IT infrastructure resources (e.g., compute, networking, storage, applications and services) found in IaaS public cloud offerings, such as GCP. The private cloud component is one or more of your data centers over which you have complete control, while the public cloud component is IaaS-based and allows you to spin up fully configured computing environments as needed. Establishing a Connection to Google Cloud: IPsec VPN or Dedicated Cloud Interconnect? To connect your private data center and GCP, you can use one or more IPsec VPNs across the internet, or you can use the dedicated Google Cloud Interconnect service. This service provides a mechanism for you to establish dedicated network connections from your on-premise, private clouds or data centers to Google Cloud. This provides dedicated connectivity with the performance and service-level agreement, or SLA, granted by your service provider. The dedicated connection terminates on hardware you manage that is based in an Interconnect location. From that point, one or more 802.1q VLANs complete the connection into your VPCs. Google Cloud also supports additional peering options, with alternative costs and connection speeds, between your data center network and GCP using direct peering and carrier peering services. You can find more information about Google Cloud Interconnect and peering options here. Figure 5: Scale-out security for inbound traffic to a Google Cloud VPC network Palo Alto s on Google Cloud Deployment Guidelines White Paper 7

8 Many GCP customers prefer the entire connection to be IPsec encrypted all the way into the VPC, even when using Interconnect, for an extra layer of security for network traffic. In this scenario, the hybrid cloud solution looks no different from the perspective of the firewall than it would if the internet were used instead of Interconnect. In either case, the solution is the same, including routing, redundancy, managed scale, etc. For maximum security and flexibility in a hybrid cloud architecture, IPsec tunnels terminating on the firewall are recommended, including when using Interconnect. You can choose to use IKEv1 or IKEv2 for key exchange during IPsec tunnel setup. When setting up an IPsec VPN from your on-premise data center to Google Cloud, you have two options: IPsec VPN to in Google Cloud This is a typical site-to-site IPsec VPN between a hardware IPsec appliance in your data center, such as a Palo Alto s PA-5260, and the running in GCP. Refer to PAN-OS documentation for setup steps to configure the VPN. For high availability, you can set up a pair of IPsec tunnels from your private data center to two instances running in Google Cloud. As previously explained in the High Availability and Failover section, you should configure GCP routing and forwarding rules in the VPC to have redundant VPC routes through the two instances. Google Cloud Platform Project Private Data Center Web VPC /24 Apache PA-5260 Webserver IPsec VPN WordPress Database VPC /24 SQL Server Database MySQL Figure 6: Hybrid cloud IPsec VPN to in Google Cloud IPsec VPN to Google Cloud VPN Gateway This is a typical site-to-site IPsec VPN between a hardware IPsec appliance in your data center, such as a Palo Alto s PA-3020, and the Google Cloud VPN Gateway. You can create multiple VPN tunnels from two or more devices in your on-premise data center to a single VPN Gateway for redundancy or to connect to separate data centers. The VPN Gateway service also offers an SLA of 99.9 percent service availability. Google Cloud VPN Gateway supports Encapsulating Security Payload, or ESP, in tunnel mode for authentication, but it does not support Authentication Header or ESP in transport mode. For detailed configuration steps, refer to the Google Cloud VPN/Palo Alto s NGFW interoperation guide here. Google Cloud Platform Private Data Center PA-5260 Project Web VPC /24 Webserver Apache IPsec VPN VPN Gateway Database VPC WordPress SQL Server /24 Database MySQL Figure 7: Hybrid cloud IPsec VPN to Google Cloud VPN Gateway Palo Alto s on Google Cloud Deployment Guidelines White Paper 8

9 Deploy your firewalls behind the VPN Gateway, and use GCP routing and forwarding rules to ensure the firewalls inspect traffic entering and leaving the VPN tunnel. This way, malware and advanced threats are restricted at the perimeter before they can move laterally, in either direction, between your public cloud environment and private data center. As previously explained in the High Availability and Failover section, you should configure GCP routing and forwarding rules in the VPC to have redundant VPC routes through the two instances. Advanced Integration Features Deploying a next-generation firewall in the GCP environment is only the first step. Public cloud deployments require a large degree of automation using template-based deployments, API-based orchestration, monitoring services and serverless computing services, like Google Cloud Functions. The on Google Cloud includes several automation features that enable its advanced security to seamlessly operate in this environment. Automate Deployments Using Bootstrapping Bootstrapping enables automated deployments of fully configured firewalls using GCP templates or other API-based automation tools. Use a Google Cloud storage bucket to store the bootstrap configuration contents, and then at deployment time, provide the bucket name and IAM permissions to read it to the instance. The firewall will boot up and perform setup automatically, including: Configuration and security policies. Attaching the instance to a Panorama device group. /config /license /software Bootstrap /content files Licensing the using an auth code for BYOL or the ELA, if you are not using a consumption-based option. Dynamic security content updates for Threat Prevention, WildFire and URL Filtering. Software updates. Bootstrap configurations are placed in folders inside the storage bucket, where the will use IAM permissions provided by the service account of the instance to securely, privately read the storage bucket s contents. This allows the firewall to be initially configured via the bootstrap files, and then managed centrally by Panorama after bootstrapping. You can also include licenses, software updates and dynamic security content updates. Depending on how quickly a newly deployed firewall must be put into service, you can decide to deliver the software and content updates via Panorama after deployment instead of via bootstrap. Monitoring via Google Stackdriver GCP as a virtualized infrastructure platform can monitor basic VM metrics, such as CPU, network and disk usage, from the outside, but it cannot monitor the internal metrics of PAN-OS. includes an option to publish key metrics to the Google Stackdriver service. This allows you to monitor the firewall via GCP tools and use the related GCP services for diagnostics, alerting and follow-on actions, such as starting Google Cloud Functions when a certain PAN-OS metric crosses a threshold during the monitored interval. For example, the can push session utilization information to Stackdriver, allowing you to monitor firewall performance directly in the GCP console. Any automation or orchestration system that does elastic scaling to launch or terminate the for on-demand security should collect data over a sufficient period of time before taking a start or terminate decision. This is intended to avoid see-saw behavior by having sufficient available firewalls at any given time. 2. Alarm Stackdriver The following is a list of the PAN-OS metrics published by to Stackdriver: Session utilization % Total active sessions GlobalProtect tunnel utilization % GlobalProtect active tunnels Data plane CPU utilization % Data plane packet buffer utilization % SSL proxy utilization % = Cloud Storage Storage bucket name IAM permissions Figure 8: Automatically configure firewalls at deployment via bootstrap 3. Alerts + action 1. Publish metrics Enabling Scale-Out Security Using VM Monitoring Security policies have traditionally been written using IP addresses, subnets or firewall zones, the latter of which map to trust, DMZ, private and other zones. Figure 9: Monitoring internal metrics of via Stackdriver Palo Alto s on Google Cloud Deployment Guidelines White Paper 9

10 These are fairly static and don t deal with the dynamic nature of public clouds. PAN-OS running on Palo Alto s next-generation firewalls, physical or virtual, can natively monitor instances running in VMware, AWS and Google Cloud. This allows a security administrator to construct abstract policies that can dynamically keep up with the changes in the cloud infrastructure. For example, a policy can state that when a webserver connects to database, it should only allow MySQL traffic. The automatically determines what webserver and database map to, based on the cloud environment. The firewall can fetch the VM s metadata and IP address information as IP tag mappings, using the VM Monitoring feature. This section will use firewall to refer to both physical and virtual Palo Alto s firewalls since VM Monitoring is supported in both product lines. Hardware firewalls use Service Account credentials, and use Google Compute Engine IAM permissions to make GCP API calls for retrieving instance metadata. To use this feature, set up a VM Information Source (Device tab > Setup in the firewall s web console) that monitors the specific GCP zone containing your instances at a periodic interval you specify. The monitored VM metadata can include predefined properties, such as VM/hostname in GCP, project ID, VPC/network name, subnet, GCP zone, as well as user-defined properties, such as GCP tags and labels (name, value pairs). These tags or labels can designate VMs, based on their functions or roles, as web servers, database, production or test environments, etc. The tag-ip mappings the firewall retrieves can then be organized into Dynamic Address Groups. For example, us-west1-a, webserver and production could form a DAG for production web servers running in the US West 1A zone of GCP. When instances are deployed or destroyed, either automatically or via templates, security policies will automatically apply since the firewall will automatically learn or unlearn their IP addresses via VM Monitoring. Hardware firewalls using this feature typically secure hybrid cloud deployments whereby the firewall monitors the traffic going in/out of the on-premise environment into Google Cloud VPCs. This gives you greater control since the security policy can now be defined using App-ID and User-ID technology in addition to the tag/label assigned to GCP instances. Using a policy based on tags and labels lets the firewall have granular policies allowing traffic to and from only those instances, not the entire VPC. As new tagged instances come up, their traffic is allowed by the firewall if the security policy for it exists and blocked if they are not tagged correctly. Take the use case for protecting outbound traffic as an example. If all your Linux instances are tagged as Ubuntu and the VM Monitoring feature is enabled with a DAG for your Linux-tagged instances, then the can enforce the following policy: Linux-tagged instances can connect to *.ubuntu.com or *.canonical.com for apt-get updates As new Linux instances are spun up or down, typically based on templates, API or auto-scaling, their security policies are already being enforced by the without a need to change, add or delete policies. VM Monitoring allows you to create security policies that automatically stay up to date with deployments and elastic scaling of your application infrastructure. This reduces the need to create incident tickets with the security team to deploy or destroy changes to application stacks and makes it possible for DevOps teams to easily integrate security into operational flows. Conclusion Security best practices for protecting applications and data in your data center entail limiting your threat exposure through application visibility and control, then preventing threats and data exfiltration within the allowed application flows. The, combined with Google Cloud firewall, protects your enterprise workloads in the public cloud in the same manner, resulting in a strong, consistent security posture. It is important to remember that this is not a decision between one or the other; rather, it is best to utilize both approaches for a comprehensive security posture. References on Google Cloud Resource page: GitHub repository for example templates: Google Cloud VPC ing: Google Cloud Load Balancing: Tannery Way Santa Clara, CA Main: Sales: Support: Palo Alto s, Inc. Palo Alto s is a registered trademark of Palo Alto s. A list of our trademarks can be found at paloaltonetworks.com/company/trademarks.html. All other marks mentioned herein may be trademarks of their respective companies. how-to-secure-yourbusiness-in a-multi-cloud-world-wp