1. Datacenter security
    1. Cloud providers secure the physical data center
    2. Hardware taken out of service is destroyed
    3. Data centers access is limited
    4. Providers performs background checks on employees
    5. Employees access is limited to areas needed to perform their job
  2. Hierarchy
    1. Organizations can have one or more folders
    2. Folders can contain other folders and projects
    3. IAM restricts access to project resources
    4. Enables separation by service, but not by VPC
    5. Primary method of full isolation between environments
    6. Project-wide IAM roles grants access to all VPCs
    7. Projects can be further divide into VPCs
    8. Use projects, VPC and Firewalls to isolate resources
    9. Apply the principle of least privilege
  3. Intrusion protection
    1. Web Application Firewall
      1. Works with Global HTTPS(S) Load Balancer
      2. Provides built-in defence against infrastructure DDoS attacks
      3. Uses security policies made up of rules that allow or prohibit traffic
      4. Implemented in POP at edge of the network
      5. Paired with load balancers to block malicious traffic
      6. Supports HTTP, HTTPS, and HTTP/2
      7. Security policies deny list and allow list rules
      8. Can be specified for backend services
      9. Deny or allow list for IP/CIDR range IPv4/IPv6
      10. Designate the order of the rules
      11. Preview the effect of rules without going live
      12. Logs policy name, matched rule priority, associated action and related information
    2. Features
      1. DDoS, SQL Injection, Cross Site Scripting
      2. IP whitelist/blacklist controls
      3. Geo-based Access Control
      4. Allow and deny rules
    3. Implementation
      1. Create policy with rule
      2. Supply IP ranges to apply rule
      3. On rule/IP match, allow or deny traffic
      4. Overlap rules with different priorities
      5. Apply policies to target, e.g. load balancer
  4. Access control
    1. Linux
      1. OS Login role
        1. Only able to connect to instances
        2. Per instance or project wide access
        3. Enable OS Login in metadata
        4. OS Login and Service Account user roles required to connect
        5. External GCP users require OS Login External User role
      2. Compute Instance Admin role
        1. Connect via SDK
        2. No need to create and store own SSH keys
      3. Own SSH public/private keys
        1. Independent of IAM and SDK
        2. User is responsible for key management
        3. Manually generated public/private keys
        4. Public key added to project or per-instance meta data
        5. Allows access from outside of cloud
        6. Connects with 3rd party tools outside of cloud
    2. Windows
      1. RDP (tcp:3389)
      2. Username/password handled by instance
      3. Independent of IAM
      4. Compute instance admin role to reset password
  5. Secure Connection
    1. Protect internet-facing Compute instances
      1. Firewalls
      2. HTTPS/SSL
      3. Port forwarding over SSH
      4. SOCKS proxy over SSH
    2. Connect to instances without external IPs
      1. Bastion host and SSH forwarding
      2. Cloud IAP for TCP forwarding
      3. VPN
      4. NAT gateway
      5. Interactive serial console access
      6. HTTPS and SSL proxy load balancers
  6. IAM Policy
    1. Network Admin: Create, edit, delete network resources, except firewall rules, SSL certs
    2. Security Admin: Create, edit, delete network firewall rules, SSL certs, but not network resource
    3. Network User: Use network resources. Cannot create or delete
    4. Network Viewer: Readonly access to networking resources
    5. Compute Instance Admin: Create, modify and delete GCE resources
    6. Export policy YAML or JSON, edit and apply
  7. IAP
    1. Overview
      1. Establishes a central authorization layer for applications accessed by HTTPS
      2. Uses an application-level access control model
      3. Controls HTTPS access to applications and virtual machines
      4. Central anthorization layer for application-level access control
      5. Enforces access control policies for applications and resources
      6. Allows employees to work from untrusted networks without the use of a VPN
    2. Operation
      1. User hits IAP proxy
      2. IAP-enabled app or backend service authenticated
      3. Credentials validated
      4. Authorization check to verify user access
    3. Context-Aware Access
      1. Access web applications and infrastructure resources from virtually any device, anywhere
      2. VPN-less user access
      3. Integrated with Identity and WAF
      4. Supports cloud or on-premises
    4. Signed Headers
      1. Uses JSON Web Token (JWT) to make sure that a request to the app is authorized
      2. Provides secondary security in case someone bypasses IAP
    5. TCP Forwarding
      1. Controls who can access administrative services such as SSH and RDP over the public Internet
      2. Prevents these services from being openly exposed to the Internet
      3. Must pass authentication and authorization checks before they get to their target resource
    6. Best Practices
      1. CDNs may cache content and serve cached pages to unauthenticated users
      2. To properly secure applications, use signed headers
      3. Make sure all requests to are routed via a Load balancer
      4. Configure a firewall rule to allow health checking
      5. Configure source traffic to be routed through Google Frontend
  8. VPC
    1. Overview
      1. Virtual version of a physical network
      2. Global software defined network
      3. Provides connectivity between resources
      4. Core resource for all network functions
      5. Segmented into subnets
      6. Works with firewall rules and routes
      7. Subnets are regional resources, span multiple zones
      8. Projects have one or more VPCs
      9. Connect with on-premises through Interconnect or VPN
      10. VPC include one or more Regions
      11. Regions can have one or more subnets
      12. VPC separates resources (e.g. instances)
      13. Can have multiple VPCs per project
      14. Resources in same VPC accessible via private IP (RFC 1918)
      15. Use VPNs or network peering for secure access between different networks
      16. Global access to the same private network
      17. Project users have access to all VPCs
      18. IAM roles control across by GCP service, not VPC
    2. Routing
      1. Routes define paths for in/out bound packets
      2. Firewall rules control traffic in and out of the VPC
      3. Firewall rules apply to both ingress and egress traffic
      4. Private Google Access is an option for internal communication only
      5. Connect with on-premises through Interconnect or VPN
    3. Roles
      1. Administration is secured via IAM
      2. VPC Networking baked into Compute Engine IAM Role
      3. Compute Admin is granted full access to instance and network admin roles
      4. Compute Network Admin has full network admin role
    4. Limitations
      1. A network must have at least one subnet
      2. VPC networks support IPv4 unicast traffic
      3. No IPv6 traffic support within the network
      4. IPv6 address support for global load balancers
  9. Address
    1. Disable external IP
    2. Place resource on Internal network
    3. Use IAP, NAT or bastion host
  10. Firewall
    1. Overview
      1. Separate access by network traffic and location
      2. Manages Ingress and Egress traffic
      3. Allow or deny traffic to and from VMs based on configuration
      4. Defined at the network level, but enforced at the instance level
      5. Firewall rules are always enforced
      6. Firewall rules are stateful
      7. By default, all ports are closed
      8. Firewall rules control access to ports
      9. GRE traffic is always blocked
      10. Protocols other than TCP, UDP, ICMP and IPIP is blocked
      11. Egress traffic on TCP port 25 (SMTP) is blocked
      12. DHCP, DNS, Instance metadata (169.254.169.254) and NTP is always allowed
      13. Implied 'deny all' ingress and 'allow all' egress
    2. Limit access by
      1. Port
      2. IP address/range
      3. Between subnets
      4. Tags
      5. Service accounts
    3. Components
      1. Direction: Ingress/egress
      2. Source: traffic location source rule is applied to
      3. Target: all instances, tagged instances, or service accounts
      4. Protocol/port: specified for TCP, UDP, ICMP, SSH
      5. Action: Allow/deny
      6. Priority is higher for lowest number
      7. Deny rule is applied over allow rule when priorities match
      8. Enforcement status can be Enabled or Disabled
    4. Network Tags
      1. Tags can be used to determine which rules apply to particular machines
      2. Used to apply firewall rules and routes to specific instances
      3. Apply to VPC network with instance primary interface
      4. Can be used in different networks for different purposes
      5. Does not need to be unique
    5. Logging
      1. Logs every firewall connection attempt
      2. Useful for auditing, verifying and analysing effect of rules
      3. Applied per firewall rule, across entire VPC
      4. Creates connection record when rule allows/denies traffic
      5. Larger machine types log more firewall connections per interval
      6. TCP/UDP protocols only
      7. Default "deny all" ingress and "allow all" egress rules are NOT logged
      8. Can be exported to BigQuery or PubSub for analysis
    6. Load balancer/health check interactions
      1. Firewall controls access at an instance level, not LB
      2. Must allow LB traffic to connect to backend instances
      3. Must allow health check traffic to backend instances
      4. Network load balancer = 209.85.152.0/22,209.85.204.0/22 and 35.191.0.0/16
      5. HTTP(S)/SSL Proxy/TCP Proxy/Internal LB = 130.211.0.0/2 and 35.191.0.0/16
  11. Shared VPC
    1. Adopt the principle of least priviledge for network administration, auditing and access control
    2. Organizational Administrator: Full control
    3. Shared VPC Admin: Administers shared VPC for the organization
    4. Service Project Admins: Maintains ownership and control over service project resources
    5. Network Admins: Full control over all network resources except firewall rules and SSL certificates
    6. Security Admins: Manage firewall rules and SSL certificates
    7. Roles
      1. Grant service project service accounts the host project Network User Role
      2. Grant service project service account the Host Service Agent User role in the host project
      3. Grant service project Google API service account the Network User role in the host project
  12. DNSSEC
    1. Authenticates responses to domain name lookups
    2. Protects domains from spoofing and cache poisoning attacks
    3. Provides strong authentication (but not encryption) of domain lookups
    4. Both registrar and registry must support DNSSEC for the TLD in use
    5. To enable DNSSEC, add DS record to TLD at registrar
    6. Enable DNSSEC on the domain
  13. DDoS
    1. Overview
      1. Attempts to render services unavailable to its end users
      2. Attackers use a large number of compromised hosts to orchestrate large-scale attacks against targets
    2. Protecting shared infrastructure
      1. Mechanism in place to protect shared infrastructure
      2. Ensures no single service can overwhelm the infrasttucture
      3. Provides isolation among customers using the shared infrastructure
      4. DDoS defense involves
        1. Deploying detection systems
        2. Implementing barriers
        3. Absorbing attacks by scaling to prevent attackes from disabling access to services
      5. Shared responsibility model
        1. Google provided mechanism
        2. Best practices to implement
    3. Reduce the attack surface
      1. Isolate and secure network using subnets, firewall rules, tags and IAM
      2. Use firewall rules and/or protocol forwarding
      3. Anti-spoofing protection provided for the private nerwork by default
      4. Automatic isolation between virtual networks
    4. Isolate internal traffic from the external world
      1. Deploy instances without public IPs unless necessary
      2. Set up a NAT gateway or SSH bastion to limit the number of instances exposed to the Internet
      3. Deploy internal load balancing that access internal deployed services to avoid exposure
    5. Enable Proxy-Based Load Balancing
      1. HTTP(S) or SSL proxy load balancing allows Google infrastructure to absorb layer 4 and below attacks
      2. SYN floods, IP fragment floods, port exhaustion, etc
      3. Disperse attacks, across the globe with HTTP(S) load balancing to instances in multiple regions
    6. Scale to absorb the attack
      1. Protection by Google Frontend infrastructure, GLB
      2. Scales to absorb cetain types of attacks, e.g. SYN floods
      3. Anycast-based load balancing with HTTP(S) and SSL proxy load balancers
    7. Protection with CDN Offloading
      1. Google Cloud CDN acts as a proxy
    8. 3rd Party DDoS Protection Solutions
      1. 3rd party solutions can protect against DDoS attacks
    9. App Engine Deployment
      1. Fully multi-tenant system
      2. Safeguards in place
      3. Sits behind the Google frontend
      4. Specify a set of IPs/IP networks
    10. Google Cloud Storage
      1. Use signed URL to access GCS
    11. API Rate limiting
      1. Define number of allowed requests to Compute Engine API
      2. API rate limits apply on a per project basis
      3. Projects are limited to an API rate limit of 20 requests/second
    12. Resource Quotas
      1. Quotas help prevent unforseen spikes in usage
  14. Storage
    1. Securely interact with cloud storage
    2. Access Control methods: IAM, ACL, Signed URL
    3. Use IAM for Bucket level permissions
    4. Use ACL and Signed URL for Object level permission
    5. Signed URL does not require Google Cloud account
    6. Signed URL enables users to securely access their data
    7. Expires after a set period of time
  15. Best Practices
    1. Networking
      1. Use Internal IP and Private Google Access
      2. Start with single VPC network for resources with a common requirement
      3. Create a VPC for each team and connect to a shared service VPC
      4. Isolate sensitive data in own VPC
    2. Optimise cost, performance and security
      1. VPC network peering
      2. External vs internal routing
      3. VPN vs Interconnect
    3. Secure and protect applications
      1. Load Balancer
      2. Cloud Armor
      3. IAP
      4. Security Command Center
    4. VPC Flow Logs
      1. Network monitoring
      2. Forensics
      3. Realtime security analysis
      4. Expense optimisation