GoogleCloudPlatform / GoogleCloudPlatform/pubsec-declarative-toolkit

Compliance: ITSG-22 Network Security Zones and ITSG-38 Network Security Zoning - Design Considerations for Placement of Services

Open
#78 2 comments 0 reactions 1 assignee Claimed by @fmichaelobrien View on GitHub
documentation enhancement Networking Solution
Dominant language
Shell
Stars
36
Forks
26
PR merge metrics
No merged PRs in 30d

Description

We have been focused on ITSG-33 security controls until 202208 - we need to verify our compliance with Network Zoning and ZIPs (Zone Interface Point)

ITSG-22 https://cyber.gc.ca/en/guidance/baseline-security-requirements-network-security-zones-version-20-itsp80022 and https://cyber.gc.ca/sites/default/files/cyber/publications/itsp80022-e.pdf

ITSG-38 Placement of Services with Zones - https://open.canada.ca/data/en/dataset/7ef76a62-bb53-4e9c-b2a4-03e5c53570a1 and
https://cyber.gc.ca/en/guidance/network-security-zoning-design-considerations-placement-services-within-zones-itsg-38
SSC 2020 https://wiki.gccollab.ca/images/9/9d/Network_Security_Zoning_Reference_Architecture.pdf

Flows, firewall demarcation, encryption in transit levels l3/l4 (default internal) + l7

Expand on https://cloud.google.com/architecture/landing-zones/decide-network-design#option-2 in https://cloud.google.com/architecture/landing-zones#what-is-a-google-cloud-landing-zone

Google Front End Service (reverse proxy) - https://cloud.google.com/docs/security/infrastructure/design#google_front_end_service

20220920
Network separation question:
We have a couple options to start -
1 - shared VPC (host) - with service subnets - this works best for PaaS workloads (with some sharing - where separation is at the k8s namespace and/or service level) - (aka transit gateway)
2 - workload (non-shared) VPC's peered to the shared perimeter (1 fortigate cluster per gc-cap - with flow separation)
3 - workload (non-shared) VPC's peered to their own perimeter (usually prod/stg/dev fortigate separation but we can expand) - I have only see 2 above though
For all 1-3 we can separate using explicit and implicit routing/firewall-rules separation
Usually 2-3 are for both free-form sandbox and specific prod workloads (one team does bucket downloads for example) - where the rest of the workloads are ok with sharing the paas in 1

see prototyping that needs to be moved to kcc
org a- gcp.obrien.services https://console.cloud.google.com/networking/peering/list?orgonly=true&project=ospe-obs-obsprd-obspubper&supportedpurview=project

Screen Shot 2022-10-07 at 10 44 55 AM

Existing peering to be updated as per
https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit/blob/dev/solutions/landing-zone/architecture.md#di-20-separate-vpc-per-cloud-profile-356-workloads

uncomment and KPT render each peer pair in
https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit/blob/main/solutions/landing-zone/environments/common/network/network-peering.yaml#L15

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.