Cloud Armor protects the applications from multiple types of threats, including distributed denial-of-service (DDoS) attacks and application attacks like cross-site scripting (XSS) and SQL injection (SQLi).
Cloud Armor provides protection only to applications running behind an external HTTP(S) and TCP/SSL Proxy load balancer.
Cloud Armor supports applications deployed on Google Cloud, in a hybrid deployment, or in a multi-cloud architecture.
Cloud Armor is implemented at the edge of Google’s network in Google’s points of presence (PoP).
Security policies protect applications running behind a load balancer from DDoS and other web-based attacks
Backend service can have only one security policy associated with it
Prioritized rules define configurable match conditions, actions (allow or deny) and order in a security policy
Cloud Armor provides Preview mode that helps evaluate and preview the rules before going live.
Identity-Aware Proxy IAP allows managing access to HTTP-based apps both on Google Cloud and outside of Google Cloud.
Identity-Aware Proxy IAP intercepts the web requests sent to the application, authenticates the user making the request using the Google Identity Service, and only lets the requests through if they come from an authorized user. In addition, it can modify the request headers to include information about the authenticated user.
Identity-Aware Proxy IAP helps establish a central authorization layer for applications accessed by HTTPS to use an application-level access control model instead of relying on network-level firewalls.
IAP uses Google identities and IAM and can leverage external identity providers as well like OAuth with Facebook, GitHub, Microsoft, SAML, etc.
Identity-Aware Proxy (IAP) can be configured to use JSON Web Tokens (JWT) as signed headers to make sure that a request to the app is authorized and doesn’t bypass IAP
Access Context Manager allows organization administrators to define fine-grained, attribute-based access control for projects and resources
helps prevent data exfiltration
helps reduce the size of the privileged network and move to a model where endpoints do not carry ambient authority based on the network.
helps define desired rules and policy but isn’t responsible for policy enforcement. The policy is configured and enforced across various points, such as VPC Service Controls.
FIPS 140-2 Validated
The NIST developed the Federal Information Processing Standard (FIPS) Publication 140-2 as a security standard that sets forth requirements for cryptographic modules, including hardware, software, and/or firmware, for U.S. federal agencies.
FIPS 140-2 Validated certification was established to aid in the protection of digitally stored unclassified, yet sensitive, information.
Google Cloud Platform uses a FIPS 140-2 validated encryption module called BoringCrypto in its production environment.
Data in transit to the customer and between data centers, and data at rest are encrypted using FIPS 140-2 validated encryption.
BoringCrypto module that achieved FIPS 140-2 validation is part of the BoringSSL library.
BoringSSL library as a whole is not FIPS 140-2 validated
In order to operate using only FIPS-validated implementations:
Google’s Local SSD storage product is automatically encrypted with NIST approved ciphers, but Google’s current implementation for this product doesn’t have a FIPS 140-2 validation certificate. If you require FIPS-validated encryption on Local SSD storage, you must provide your own encryption with a FIPS-validated cryptographic module.
Google automatically encrypts traffic between VMs that travels between Google data centers using NIST-approved encryption algorithms, but this implementation does not have a FIPS validation certificate. If you require this traffic to be encrypted with a FIPS-validated implementation, you must provide your own.
Clients connecting to Google infrastructure with TLS clients must be configured to require use of secure FIPS-compliant algorithms; if the TLS client and GCP’s TLS services agree on an encryption method that is incompatible with FIPS, a non-validated encryption implementation will be used.
Applications built and operated on GCP might include their own cryptographic implementations; in order for the data they process to be secured with a FIPS-validated cryptographic module, you must integrate such an implementation yourself.
All Google Cloud regions and zones currently support FIPS 140-2 validated encryption.