This Google Cloud Platform security best practice is part of the DevSecOps and CI/CD security domain.

Customers can create and manage alerting policies with Stackdriver Monitoring (using the console or the Stackdriver Monitoring API). Also export logs to SIEMs and detect any threats or anomalies.

Automated code analysis tools with specific components for monitoring for security issues shall be used.

Customer can integrate with GCP → Security Command Center, Google App Engine → Cloud Security Scanner and Google Kubernetes Engine → Container Registry Scanning.

Container Registry scans for vulnerabilities and identifies package vulnerabilities for your container images. This page describes how you can view the vulnerabilities using Google Cloud Platform Console, the gcloud command-line tool, and Container Analysis API.

Cloud Security Command Center integrates with Google Cloud Platform security tools like Cloud Security Scanner, the Cloud Data Loss Prevention (DLP) API, and third-party security solutions from Cloudflare, CrowdStrike, Dome9, Palo Alto Networks, Qualys, and RedLock.

This Google Cloud Platform security best practice is part of the DevSecOps and CI/CD security domain.

Customers can use Cloud Security Command Center, which is designed to enable users to monitor the inventory of their cloud assets, scan storage systems for sensitive data, detect common vulnerabilities, and review access rights to critical resources.

Customers can also use Stackdriver Monitoring to provide visibility into the performance, uptime, and overall health of applications in GCP

This Google Cloud Platform security best practice is part of the Governance Risk and Compliance security domain.

The training program shall include:

• Reviewing risks
• Reviewing actions each group shall take to treat risks
• Training and testing participants in their responsibilities
• Requires passing before being allowed to participate in the development and support of cloud products

Remediate and track progress toward remediation for areas of noncompliance to include:

• Developing a plan of action and milestones for the information system to document planned remedial actions to correct weaknesses or deficiencies noted during the assessment of the security controls, and to reduce or eliminate known vulnerabilities in the system
• Updating existing plan of action and milestones at each quarter, based on the findings from security controls assessments, security impact analyses, and continuous monitoring activities

Over the next few days will publish a series of articles that describe some of the best security practices for GCP. Those security practices are mapped to the ISO 27002:2013 controls and standards.

The security domains that we are going to cover:

• Governance Risk and Compliance
• DevSecOps and CI/CD
• Data Protection
• Vulnerability and Threat Management
• Logging and Monitoring
• Incident Response Management
• Network & Infrastructure Security
• Identity and Access Management
• Business Continuity & Disaster Recovery

You can find all the related articles by searching for “GCP best practice” in the Tag cloud below:

azure Azure Best Practice Azure Firewall Azure Lighthouse azure migration Azure Policy Azure Security Azure Security Center backup CIS cloud migration cloud security cybersecurity databasesecurity devops disaster recovery GCP GCP best practice GCP PCI GCP security Google Cloud Security Identity Management ISO 27001 iso 27002 managed draas Managed Security Services Microsoft 365 Business Premium microsoft 365 security Microsoft365Business nist nist 800-53 office 365 PCI DSS Security Compliance Security Controls sqlsecurity vdi virtual desktop wfd windows virtual desktop workfromhome wvd

The following security controls are part of the GCP CIS 1.0.0 specifications and they can audited by our managed GCP security services. Please note the standard has more security controls that unfortunately cannot be audited at this time, due to lack of APIs from the Google platform. Our GCP Security Services can audit and help you remediate most of the technical controls listed below:

CONTROL	DESCRIPTION
1.1 Ensure that corporate login credentials are used instead of Gmail accounts	Use corporate login credentials instead of Gmail accounts.
1.3 Ensure that there are only GCP-managed service account keys for each service account	User managed service account should not have user managed keys.
1.4 Ensure that ServiceAccount has no Admin privileges.	A service account is a special Google account that belongs to your application or a VM, instead of to an individual end user. Your application uses the service account to call the Google API of a service, so that the users aren’t directly involved.
1.5 Ensure that IAM users are not assigned Service Account User role at project level	It is recommended to assign `Service Account User (iam.serviceAccountUser)` role to a user for a specific service account rather than assigning the role to a user at project level.
1.6 Ensure user-managed/external keys for service accounts are rotated every 90 days or less	Service Account keys consist of a key ID (Private_key_Id) and Private key, which are used to sign programmatic requests that you make to Google cloud services accessible to that particular Service account.
1.8 Ensure Encryption keys are rotated within a period of 365 days	Google Cloud Key Management Service stores cryptographic keys in a hierarchical structure designed for useful and elegant access control management. Access to resources.The format for the rotation schedule depends on the client library that is used.
2.1 Ensure that Cloud Audit Logging is configured properly across all services and all users from a project	It is recommended that Cloud Audit Logging is configured to track all Admin activities and read, write access to user data.
2.2 Ensure that sinks are configured for all Log entries	It is recommended to create sink which will export copies of all the log entries.
2.3 Ensure that object versioning is enabled on log-buckets	It is recommended to enable object versioning on log-buckets.
2.4 Ensure log metric filter and alerts exists for Project Ownership assignments/changes	In order to prevent unnecessarily project ownership assignments to users/service-accounts and further misuses of project and resources, all `roles/Owner` assignments should be monitored.
2.5 Ensure log metric filter and alerts exists for Audit Configuration Changes	Google Cloud Platform services write audit log entries to Admin Activity and Data Access logs to helps answer the questions of “who did what, where, and when?” within Google Cloud Platform projects.
2.6 Ensure log metric filter and alerts exists for Custom Role changes	It is recommended that a metric filter and alarm be established for changes IAM Role creation, deletion and updating activities.
2.7 Ensure log metric filter and alerts exists for VPC Network Firewall rule changes	It is recommended that a metric filter and alarm be established for VPC Network Firewall rule changes.
2.8 Ensure log metric filter and alerts exists for VPC network route changes	It is recommended that a metric filter and alarm be established for VPC network route changes.
2.9 Ensure log metric filter and alerts exists for VPC network changes	It is recommended that a metric filter and alarm be established for VPC network changes.
2.10 Ensure log metric filter and alerts exists for Cloud Storage IAM permission changes	It is recommended that a metric filter and alarm be established for Cloud Storage Bucket IAM changes.
2.11 Ensure log metric filter and alerts exists for SQL instance configuration changes	It is recommended that a metric filter and alarm be established for SQL Instance configuration changes.
3.1 Ensure the default network does not exist in a project	To prevent use of `default` network, a project should not have a `default` network.
3.3 Ensure that DNSSEC is enabled for Cloud DNS	DNSSEC in Cloud DNS enables domain owners to take easy steps to protect their domains against DNS hijacking and man-in-the-middle and other attacks.
3.4 Ensure that RSASHA1 is not used for key-signing key in Cloud DNS DNSSEC	DNSSEC algorithm numbers in this registry may be used in CERT RRs. Zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms.
3.5 Ensure that RSASHA1 is not used for zone-signing key in Cloud DNS DNSSEC	DNSSEC algorithm numbers in this registry may be used in CERT RRs. Zone signing (DNSSEC) and transaction security mechanisms (SIG(0) and TSIG) make use of particular subsets of these algorithms.
3.9 Ensure VPC Flow logs is enabled for every subnet in VPC Network	Flow Logs is a feature that enables you to capture information about the IP traffic going to and from network interfaces in your VPC Subnets. After you’ve created a flow log, you can view and retrieve its data in Stackdriver Logging.
4.1 Ensure that instances are not configured to use the default service account with full access to all Cloud APIs	To support principle of least privileges and prevent potential privilege escalation it is recommended that instances are not assigned to default service account `Compute Engine default service account` with Scope `Allow full access to all Cloud APIs`.
4.2 Ensure “Block Project-wide SSH keys” enabled for VM instances	It is recommended to user Instance specific SSH key(s) instead of using common/shared project-wide SSH key(s) to access Instances.
4.3 Ensure oslogin is enabled for a Project	Enabling OS login binds SSH certificates to IAM users and facilitates effective SSH certificate management.
4.4 Ensure ‘Enable connecting to serial ports’ is not enabled for VM Instance	If you enable the interactive serial console on an instance, clients can attempt to connect to that instance from any IP address.
4.5 Ensure that IP forwarding is not enabled on Instances	Forwarding of data packets should be disabled to prevent data loss or information disclosure.
5.1 Ensure that Cloud Storage bucket is not anonymously or publicly accessible	It is recommended that IAM policy on Cloud Storage bucket does not allows anonymous and/or public access.
5.3 Ensure that logging is enabled for Cloud storage buckets	It is recommended that storage Access Logs and Storage logs are enabled for every Storage Bucket.
6.1 Ensure that Cloud SQL database instance requires all incoming connections to use SSL	It is recommended to enforce all incoming connections to SQL database instance to use SSL.
6.2 Ensure that Cloud SQL database Instances are not open to the world	Database Server should accept connections only from trusted Network(s)/IP(s) and restrict access from the world.
6.4 Ensure that MySQL Database Instance does not allows root login from any Host	It is recommended that root access to a MySql Database Instance should be allowed only through specific white-listed trusted IPs.
7.1 Ensure Stackdriver Logging is set to Enabled on Kubernetes Engine Clusters	Stackdriver Logging lets you have Kubernetes Engine automatically collect, process, and store your container and system logs in a dedicated, persistent datastore.
7.2 Ensure Stackdriver Monitoring is set to Enabled on Kubernetes Engine Clusters	Stackdriver Monitoring to monitor signals and build operations in your Kubernetes Engine clusters.
7.3 Ensure Legacy Authorization is set to Disabled on Kubernetes Engine Clusters	In Kubernetes, authorizers interact by granting a permission if any authorizer grants the permission. The legacy authorizer in Kubernetes Engine grants broad, statically defined permissions.
7.4 Ensure Master authorized networks is set to Enabled on Kubernetes Engine Clusters	Authorized networks are a way of specifying a restricted range of IP addresses that are permitted to access your container cluster’s Kubernetes master endpoint.
7.5 Ensure Kubernetes Clusters are configured with Labels	A cluster label is a key-value pair that helps you organize your Google Cloud Platform resources, such as clusters. You can attach a label to each resource, then filter the resources based on their labels.
7.6 Ensure Kubernetes web UI / Dashboard is disabled	Dashboard is a web-based Kubernetes user interface. You can use Dashboard to deploy containerized applications to a Kubernetes cluster, troubleshoot your containerized application, and manage the cluster itself along with its attendant resources.
7.7 Ensure `Automatic node repair` is enabled for Kubernetes Clusters	Kubernetes Engine’s node auto-repair feature helps you keep the nodes in your cluster in a healthy, running state. When enabled, Kubernetes Engine makes periodic checks on the health state of each node in your cluster.
7.8 Ensure Automatic node upgrades is enabled on Kubernetes Engine Clusters nodes	Node auto-upgrades help you keep the nodes in your cluster or node pool up to date with the latest stable version of Kubernetes.
7.10 Ensure Basic Authentication is disabled on Kubernetes Engine Clusters	Basic authentication allows a user to authenticate to the cluster with a username and password and it is stored in plain text without any encryption. Disabling Basic authentication will prevent attacks like brute force.
7.11 Ensure Network policy is enabled on Kubernetes Engine Clusters	A network policy is a specification of how groups of pods are allowed to communicate with each other and other network endpoints.
7.13 Ensure Kubernetes Cluster is created with Alias IP ranges enabled	Google Cloud Platform Alias IP Ranges lets you assign ranges of internal IP addresses as aliases to a virtual machine’s network interfaces.
7.14 Ensure PodSecurityPolicy controller is enabled on the Kubernetes Engine Clusters	A Pod Security Policy is a cluster-level resource that controls security sensitive aspects of the pod specification.
7.15 Ensure Kubernetes Cluster is created with Private cluster enabled	A private cluster is a cluster that makes your master inaccessible from the public internet. In a private cluster, nodes do not have public IP addresses, so your workloads run in an environment that is isolated from the internet.
7.16 Ensure Private Google Access is set on Kubernetes Engine Cluster Subnets	Private Google Access enables your cluster hosts, which have only private IP addresses, to communicate with Google APIs and services using an internal IP address rather than an external IP address.
7.18 Ensure Kubernetes Clusters created with limited service account Access scopes for Project access	Access scopes are the legacy method of specifying permissions for your instance. Before the existence of IAM roles, access scopes were the only mechanism for granting permissions to service accounts.
1.7 Ensure that Separation of duties is enforced while assigning service account related roles to users	It is recommended that the principle of ‘Separation of Duties’ is enforced while assigning service account related roles to users.
1.9 Ensure that Separation of duties is enforced while assigning KMS related roles to users	It is recommended that the principle of ‘Separation of Duties’ is enforced while assigning KMS related roles to users.
3.6 Ensure that SSH access is restricted from the internet	GCP `Firewall Rules` are specific to a `VPC Network`. Each rule either `allows` or `denies` traffic when its conditions are met. Generic `(0.0.0.0/0)` incoming traffic from internet to VPC or VM instance using `SSH` on `Port 22` can be avoided.
3.7 Ensure that RDP access is restricted from the internet	GCP `Firewall Rules` are specific to a `VPC Network`. Each rule either `allows` or `denies` traffic when its conditions are met. Generic `(0.0.0.0/0)` incoming traffic from internet to VPC or VM instance using `RDP` on `Port 3389` can be avoided.
3.8 Ensure Private Google Access is enabled for all subnetwork in VPC Network	Private Google Access enables virtual machine instances on a subnet to reach Google APIs and services using an internal IP address rather than an external IP address.
4.6 Ensure VM disks for critical VMs are encrypted with Customer-Supplied Encryption Keys (CSEK)	If you supply your own encryption keys, Google uses your key to protect the Google-generated keys used to encrypt and decrypt your data. By default, Google Compute Engine encrypts all data at rest.
7.9 Ensure Container-Optimized OS (cos) is used for Kubernetes Engine Clusters Node image	Container-Optimized OS is an operating system image for your Compute Engine VMs that is optimized for running Docker containers.
7.17 Ensure default Service account is not used for Project access in Kubernetes Clusters	A service account is an identity that an instance or an application can use to run API requests on your behalf. This identity is used to identify applications running on your virtual machine instances to other Google Cloud Platform services.

This is a partial list of default security controls that we check as part of our managed security service for GCP (Google Cloud Platform):

Open DNS	Determines if TCP or UDP port 53 for DNS is open to the public
Open SSH	Determines if TCP port 22 for FTP is open to the public
Open CIFS	Determines if UDP port 445 for CIFS is open to the public
Open FTP	Determines if TCP port 20 or 21 for FTP is open to the public
Open Hadoop HDFS NameNode Metadata Service	Determines if TCP port 8020 for HDFS NameNode metadata service is open to the public.
Open Hadoop HDFS NameNode WebUI	Determines if TCP port 50070 and 50470 for Hadoop/HDFS NameNode WebUI service is open to the public
Open Kibana	Determines if TCP port 5601 for Kibana is open to the public
Open MySQL	Determines if TCP port 4333 or 3306 for MySQL is open to the public
Open NetBIOS	Determines if UDP port 137 or 138 for NetBIOS is open to the public
Open Oracle	Determines if TCP port 1521 for Oracle is open to the public
Open PostgreSQL	Determines if TCP port 5432 for PostgreSQL is open to the public
Open RDP	Determines if TCP port 3389 for RDP is open to the public
Open RPC	Determines if TCP port 135 for RPC is open to the public
Open SMBoTCP	Determines if TCP port 445 for Windows SMB over TCP is open to the public
Open SMTP	Determines if TCP port 25 for SMTP is open to the public
Open SQLServer	Determines if TCP port 1433 or UDP port 1434 for SQL Server is open to the public
Open Telnet	Determines if TCP port 23 for Telnet is open to the public
Open VNC Client	Determines if TCP port 5500  for VNC Client is open to the public
Open VNC Server	Determines if TCP port 5900 for VNC Server is open to the public
Open Oracle Auto Data Warehouse	Determines if TCP port 1522 for Oracle Auto Data Warehouse is open to the public
Multiple Subnets	Ensures that VPCs have multiple networks to provide a layered architecture
Default VPC In Use	Determines whether the default VPC is being used for launching VM instances
VM Max Instances	Ensures the total number of VM instances does not exceed a set threshold
Instances Multi AZ	Ensures managed instances are regional for availability purposes.
Key Rotation	Ensures cryptographic keys are set to rotate on a regular schedule
DB Restorable	Ensures SQL instances can be restored to a recent point
DB Automated Backups	Ensures automated backups are enabled for SQL instances
DB Multiple AZ	Ensures that SQL instances have a failover replica to be cross-AZ for high availability
DB Publicly Accessible	Ensures that SQL instances have a failover replica to be cross-AZ for high availability.
Bucket Versioning	Ensures object versioning is enabled on storage buckets
Bucket Logging	Ensures object logging is enabled on storage buckets
CLB HTTPS Only	Ensures CLBs are configured to only accept connections on HTTPS ports
Excessive Firewall Rules	Determines if there are an excessive number of firewall rules in the account
Open All Ports	Determines if all ports are open to the public
CLB No Instances	Detects CLBs that have no backend instances attached
Flow Logs Enabled	Ensures VPC flow logs are enabled for traffic logging
Autoscale Enabled	Ensures instance groups have autoscale enabled for high availability
Service Limits	Determines if the number of resources is close to the per-account limit.
Private Endpoint	Ensures the private endpoint setting is enabled for kubernetes clusters
Monitoring Enabled	Ensures all Kubernetes clusters have monitoring enabled
Private Access Enabled	Ensures Private Google Access is enabled for all Subnets
Instance Level SSH Only	Ensures that instances are not configured to allow project-wide SSH keys
VM Instances Least Privilege	Ensures that instances are not configured to use the default service account with full access to all cloud APIs
IP Forwarding Disabled	Ensures that IP forwarding is disabled on all instances
Connect Serial Ports Disabled	Ensures connecting to serial ports is not enabled for VM instances
CSEK Encryption Enabled	Ensures Customer Supplied Encryption Key Encryption is enabled on disks
Storage Bucket All Users Policy	Ensures Storage bucket policies do not allow global write delete or read permissions
Security Policy Enabled	Ensures all backend services have an attached security policy
CLB CDN Enabled	Ensures that Cloud CDN is enabled on all load balancers
DNS Security Enabled	Ensures that DNS Security is enabled on all managed zones
DNS Security Signing Algorithm	Ensures that DNS Security is not using the RSASHA1 algorithm for key or zone signing
OS Login Enabled	Ensures OS login is enabled for the project
Database SSL Enabled	Ensures SQL databases have SSL enabled
Service Account Key Rotation	Ensures that service account keys are rotated within 90 days of creation.
Service Account Managed Keys	Ensures that service account keys are being managed by Google.
Cluster Least Privilege	Ensures Kubernetes clusters are created with limited service account access scopes
Project Ownership Logging	Ensures that logging and log alerts exist for project ownership assignments and changes
Storage Permissions Logging	Ensures that logging and log alerts exist for storage permission changes
SQL Configuration Logging	Ensures that logging and log alerts exist for SQL configuration changes
Audit Configuration Logging	Ensures that logging and log alerts exist for audit configuration changes.
Custom Role Logging	Ensures that logging and log alerts exist for custom role creation and changes
VPC Firewall Rule Logging	Ensures that logging and log alerts exist for firewall rule changes
VPC Network Route Logging	Ensures that logging and log alerts exist for VPC network route changes
VPC Network Logging	Ensures that logging and log alerts exist for VPC network changes
Alias IP Ranges Enabled	Ensures all Kubernetes clusters have alias IP ranges enabled
Legacy Authorization Disabled	Ensure legacy authorization is set to disabled on Kubernetes clusters
Master Authorized Network	Ensures master authorized networks is set to enabled on Kubernetes clusters
Cluster Labels Added	Ensures all Kubernetes clusters have labels added
Web Dashboard Disabled	Ensures all Kubernetes clusters have the web dashboard disabled.
Default Service Account	Ensures all Kubernetes cluster nodes are not using the default service account.
COS Image Enabled	Ensures all Kubernetes cluster nodes have Container-Optimized OS enabled
Automatic Node Repair Enabled	Ensures all Kubernetes cluster nodes have automatic repair enabled
Automatic Node Upgrades Enabled	Ensures all Kubernetes cluster nodes have automatic upgrades enabled
Network Policy Enabled	Ensures all Kubernetes clusters have network policy enabled
Pod Security Policy Enabled	Ensures pod security policy is enabled for all Kubernetes clusters
Any Host Root Access	Ensures SQL instances root user cannot be accessed from any host
Service Account Admin	Ensures that user managed service accounts do not have any admin owner or write privileges.
Service Account User	Ensures that no users have the Service Account User role.
Service Account Separation	Ensures that no users have both the Service Account User and Service Account Admin role.
KMS User Separation	Ensures that no users have the KMS admin role and any one of the CryptoKey roles.
Audit Logging Enabled	Ensures that default audit logging is enabled on the project.
Log Sinks Enabled	Ensures a log sink is enabled to export all logs
Private Cluster Enabled	Ensures private cluster is enabled for all Kubernetes clusters
Logging Enabled	Ensures all Kubernetes clusters have logging enabled
Corporate Emails Only	Ensures that no users are using their Gmail accounts for access to GCP.
Basic Authentication Disabled	Ensure basic authentication is set to disabled on Kubernetes clusters.

GCP Security Auditing Services FAQ

Q: What are the costs related with the GCP security audit services provided by you?

A: You can see our transparent pricing on this page.

Q: We have very strict security rules that prohibit us from giving access to our GCP environment to any external entity. What are your particular access requirements in order to perform the security audit?

A: We don’t need ANY access to your environment. All we need is an export of your current cloud inventory assets as provided by CAI. This export consists of 6 files that can be shared securely with us. The information contained in those files will be stored securely on your GCP infrastructure, so no actual transfer of the data is required.

Q: Would you provide specific details or a script that we can run to collect this data?

A: Absolutely! We will share with you a very simple script that runs some basic gcloud export commands, which can be run from the GCP console by someone with Organization Admin rights. If your scope is only to look at certain projects and not at all the organization assets, we can customize this script.

Q: We would like to see all the IAM permissions required to run this script and exports, so can you share those details?

A: Of course!

Suggested Role	IAM Permissions Used	IAM Member	Target Resource	Remarks
roles/serviceusage.serviceUsageAdmin	serviceusage.services.enable	User or SA who enables the Cloud Asset API	Project to run Cloud Asset API	Our script will check for this permission and then enable the API
roles/storage.admin	storage.buckets.create	The same user as above	Project to host GCS bucket	Our script will create this bucket in the same project as above
roles/cloudasset.viewer	cloudasset.assets.exportResourcecloudasset.assets.exportIamPolicy	The same user as above	Organization	Our script will check for this permission and perform the exports
roles/serviceusage.serviceUsageConsumer	serviceusage.services.use	The same user as above	Project to run Cloud Asset API	Our script will check for this permission
roles/storage.objectViewer	storage.objects.get storage.objects.list	[email protected]	GCS bucket created by the script	Our script will check for this permission

Q: I don’t need or understand what the security standards(CIS, NIST, etc) are, so why should I care about them?

A: Many small and medium businesses don’t need to be compliant with any of the mentioned standards, but the compliance will enable your GCP environment to be very secure and protected. The enablement and continuous monitoring of those security controls will give you confidence that your data is secure in the Cloud! As a best practice, we recommend to anyone having any workloads running in a public cloud like GCP, to use the CIS security standard as a baseline for securing their environment.

Q: I am interested in the initial assessment of those security controls, but I am not interested in the ongoing maintenance of the compliance: can you offer me only this service?

A: Short answer: Yes, but…without ongoing maintenance of your security compliance, your GCP environment will be very fast exposed to a lot of security risks. Cloud environments are very dynamic with resources and services/features being added, removed and modified quite often, so without keeping pace with all those changes, your initial security controls that we audited will become obsolete very fast. Of course the choice is yours.

Q: Could you perform a security assessment and remediation of any security flaws for the applications that we have running in GCP?

A: Not at this time, but we are always adding new services to our portfolio!

Q: Our environment is a hybrid environment with resources located on-premise and in GCP, would you be able to audit and propose a remediation plan for all the resources?

A: Short answer: No, we cannot. Long answer: enabling non-GCP resources for security auditing using GCP services, requires the installation of local agents on those resources and the use of a third party software that requires a substantial investment.

Q: Could tell me more about the actual security checks that you will perform for my environment?

A: We are focusing our GCP security analysis on the following security domains:

• Resource Management
  • GCP org hierarchy
  • Environments & resource isolation
  • Resource provisioning
  • Organization policies

• Identity, Authentication & Authorization
  • User & group management
  • Administrative roles
  • Authentication
  • Assigning IAM roles

• Network Security
  • VPC architecture
  • Firewall rules
  • Network logging
  • VPC service controls
  • Identity Aware Proxy

• VM Security
  • VM identities
  • Remote access

• Data security
  • Encryption key management
  • Cloud Storage security
  • BigQuery security
  • Cloud SQL security

• Security operations
  • Logging
  • Monitoring
  • Policy scanning

• Kubernetes security
  • GKE cluster provisioning
  • Secure cluster default configurations
  • Cluster IAM/RBAC
  • Container image building
  • Container lifecycle management
  • Container runtime security
  • Workload hardening and isolation
• There are in total over 60 security controls that are being audited and reported upon.

Q: What is NOT included in your Security Posture review?

A: The following tasks are not included:

• Design and implementation of security software, hardware, or appliances
• Auditing of policies, objectives, controls and solutions solely related to applications, workloads, or hardware not deployed on Google Cloud Platform
• Creation of Security Operating Processes and Procedures
• Security assessments of commercial or custom application software
• Configuration or modification of your environment
• Testing and troubleshooting in your environment.
• Building any custom scripts or applications
• Review your application architecture or design.
• Review against any compliance frameworks (HIPPA, PCI etc.)

Q: Can you tell me a bit more about the 170 slide presentation that is included in the service?

A: The GCP Security Best Practices presentation walks you through all the sections of the Cloud Audit Security report in way more detail that we can accomplish otherwise. It will give you general guidance about how to design your GCP environment from security perspective. Hundreds of man-hours have been spent in creating this presentation, based on Google’s professional services guidance given to their partners like NovaQuantum.

The first economic benefit for infrastructure is you can have Windows 10 experience at multi-session cost. It matters to you because with today’s VDI solutions you’ll have to either go with Windows Server RDS which compromises on user experience or Windows 10 single-session which compromises on cost; but with WVD, you can get both.

Let’s take a look at a customer migration scenario here.

If you are using Windows 10 single-session on-prem today for better user experience (against Windows Server RDS deployment), WVD is the best solution for you going forward because not only it provides local like Windows 10 experience for your end users but also saves you big bucks via multi-session deployment.

Lets see why.

For a single session deployment on the left hand side, you’ll need 1 small VM per user, which usually ends up with low utilization. In comparison, for a multi-session deployment in the middle pane, you can have a larger shared VM to support multiple users so that you have higher utilization. in addition to that, since you’ll have fewer VMs, you can also expect lower operational costs. As a result, you can expect your multi-session cost to be around 1/6 of your single-session cost as seen on the right hand side. This is the key differentiation of WVD as you will find no other solution in the marketplace that supports Windows 10 multi-session.

Users are always isolated, whether using single or multi-session

WVD customers benefit from all the investment Microsoft has put into Azure Security. And customers can configure familiar Azure Security services, as they build out their deployment, or they can use our managed Security Services!

There are 3 security advantages which belong to the WVD service alone:

 – The attack surface is reduced, because it uses reverse connect technology.  Essentially that means it does not open inbound ports to VMs, so there are fewer places for bad actors to attack

 – The ability to define role-based access means the customer can parse out administration tasks, and also protect their most sensitive user groups and work loads

 – Finally, all the user sessions isolated, even in a multi-session environment!