As we've just seen, the platform already does a lot for us , but we still could end up leaving ourselves vulnerable to attack if we don't go about designing our cloud infrastructure carefully. To begin with, let's understand a few facilities provided by the platform for our benefit.

• Data encryption options: We have already discussed Google's default encryption; this encrypts pretty much everything and requires no user action. So, for instance, all persistent disks are encrypted with AES-256 keys that are automatically created, rotated, and themselves encrypted by Google.
• In addition to default encryption, there are a couple of other encryption options available to users. Both of these only make sense for those who really understand encryption, cryptography, and security. If you don't know how these work, it's best that you just stick with the default encryption.
  • Customer-managed encryption keys (CMEK) using Cloud KMS: This option involves a user taking control of the keys that are used, but still storing those keys securely on the GCP, using the key management service. The user is now responsible for managing the keys that are for creating, rotating and destroying them. The only GCP service that currently supports CMEK is BigQuery and is in beta stage for Cloud Storage. When might you use this option? Whenever you have sensitive data as well as the stipulation that that data be protected using your own key. Note that the keys are stored on the cloud, that is, they do leave your on-premise facility if you opt for CMEK.
  • Customer-supplied encryption keys (CSEK): Here, the user specifies which keys are to be used, but those keys do not ever leave the user's premises. To be precise, the keys are sent to Google as a part of API service calls, but Google only uses these keys in memory and never persists them on the cloud. CSEK is supported by two important GCP services: data in cloud storage buckets as well as by persistent disks on GCE VMs. There is an important caveat here though: if you lose your key after having encrypted some GCP data with it, you are entirely out of luck. There will be no way for Google to recover that data. CSEK makes sense when you have sensitive data that needs to be encrypted using your own keys, and what's more, you have a stipulation that those keys cannot leave your on-premise facilities.
    • Cloud security scanner: Cloud security scanner is a GCP, provided security scanner for common vulnerabilities. It has long been available for App Engine applications, but is now also available in alpha for Compute Engine VMs. This handy utility will automatically scan and detect the following four common vulnerabilities:
      • Cross-site scripting (XSS)
      • Flash injection
      • Mixed content (HTTP in HTTPS)
      • The use of outdated/insecure libraries

  • Like most security scanners, it automatically crawls an application, follows links, and tries out as many different types of user input and event handlers as possible.