Bc Gov Sdn Zones

BC Gov Network Security Classification & Zone Model

Core BC Government network architecture knowledge. Platform-independent — applies before you write a single line of NetworkPolicy or Helm chart.

For Emerald-specific enforcement mechanics (AVI, pod labels), see bc-gov-emerald. For NetworkPolicy YAML patterns, see bc-gov-networkpolicy.

Information Security Classification Framework (ISCF)

The ISCF (IMIT 6.18) defines how sensitive government information is classified. Every workload's DataClass label and network zone placement must be derived from ISCF.

Classify by data the workload is responsible for storing, not data it can access. An application server that processes Protected B data in memory and forwards it to a database is Low (or Medium if it caches sensitive content); the database is High. — SDN Security Classification Model v1.0 §Guiding Principles

Rule: classify the data, then assign the zone. Never infer classification from where a workload currently lives. Workload examples by classification:

• Low: web frontends, application servers, UIs, APIs (no sensitive data at rest)
• Medium: databases, file servers, analytics services storing Protected A / lower Protected B
• High: databases, sensitive file stores, data warehouses storing Protected B (higher-risk) / Protected C

SDN Security Classification Model (Low / Medium / High)

From the OCIO SDN Security Classification Model v1.0 (June 2022) — the workload-centric model used by SDN tenants (including OpenShift Private Cloud namespaces). The SDN model coexists with IMIT 6.13's zone model; they map to each other but have distinct enforcement.

Default-deny applies to all SDN traffic. Every flow (ingress and egress) is denied until an explicit security policy permits it. Guardrails are global deny rules that security policies cannot override; security policies are allow rules within what guardrails permit.

Low

• Workloads responsible only for public information, or no information at rest
• Maps to: DMZ when traffic exits the SDN to a multi-zone network
• Internet ingress: denied by default; permitted only via Public VIP + Internet-Ingress:ALLOW tag
• Internet egress: denied directly; allowed via the SDN Forward Proxy (whitelist-based)
• A Low workload that is Internet Accessible without a WAF cannot reach any High workload
• A Low workload protected by a Web Application Firewall (configured + monitored) may reach High workloads
• Typical: web frontends, application servers, UIs, APIs

Medium

• Workloads responsible for Protected A / lower-risk Protected B information
• Maps to: Zone B when traffic exits the SDN to a multi-zone network
• Internet ingress: denied (no Public VIP)
• Internet egress: denied directly; allowed via the SDN Forward Proxy
• Medium → Extranet (3PG): denied (Extranet flows route via Low + 3PG controls)
• Typical: databases, file servers, analytics services, data stores

High

• Workloads responsible for higher-risk Protected B / Protected C information
• Maps to: Zone A when traffic exits the SDN to a multi-zone network
• Internet ingress: denied (no Public VIP, even with WAF)
• Internet egress: denied; SDN Forward Proxy requires MISO exemption (rare; intended for licence / update / call-home use cases only — not API integrations)
• High → Low / Zone DMZ / Zone C / Extranet: denied by guardrail
• High accepts ingress only from: Medium, High, Zone A, Zone B, and Low workloads that are Non-Internet-Accessible or Internet-Accessible with WAF
• Typical: sensitive databases, data warehouses, classified data stores

IMIT 6.13 Zone Model (current, v5 — Aug 2022)

IMIT 6.13 v5 is the current Network Security Zones Standard — not historic. It applies to all core government networks (Data Centre Classic, SPAN/BC) and coexists with the SDN model above. Zone names persist in firewall rules, IPAM tagging, and partner connectivity.

Mandatory boundary controls (IMIT 6.13 v5 §5)

• All traffic transiting a zone boundary MUST pass firewall rules + IPS + anomaly detection
• Internet-bound traffic from Low Security Zones (Zone C, Guest) MUST pass content filtering
• Datacentre-to-datacentre zone extensions MUST be encrypted (per IMIT 6.10) unless using dedicated private circuits
• Servers in DMZ MUST be in DMZ AD domain (trust relationship to IDIR), NOT in IDIR domain
• A server, router, or switch MUST exist in only one non-management zone (no straddling)
• Reverse proxies to a higher security zone MUST be avoided
• Host firewalls MUST be configured on servers operating outside OCIO datacentres

Zone Adjacency Rule — No Zone Hopping

Only adjacent zones may initiate or service communication requests. A workstation in Zone C cannot initiate a session directly to data in Zone A; traffic must traverse intermediate zone boundaries (where firewall + IPS + anomaly detection enforce policy).

Internet  ↔  DMZ  ↔  Zone B  ↔  Zone A
              ↕         ↕         ↕
            (SDN)     (SDN)     (SDN)
            Low   ↔  Medium  ↔  High

• The internet cannot initiate a session directly into Medium / High / Zone B / Zone A.

• Session initiation between adjacent zones may be asymmetric (e.g., Zone C → Internet permitted; Internet → Zone C denied).

• NetworkPolicy and SDN Security Policies cannot override guardrails. Adjacency is enforced at the SDN guardrail / firewall, not at the pod level. A NetworkPolicy allow rule from Internet to Medium is silently dropped at the guardrail.

SDN guardrail key denies (selected)

Internet Egress Constraints by SDN Classification

SDN Forward Proxy supported protocols

The Forward Proxy is whitelist-based (tenant-controlled list of accessible endpoints) and supports these client protocols (per SDN Security Classification Model §Egress Traffic):

• HTTP (TCP 80) / HTTPS (TCP 443)
• SSH / SFTP (TCP 22)
• FTPS (TCP 21)
• LDAP-S (TCP 636)

Other protocols are not supported via the proxy. To reach the Internet from any SDN workload:

1. Add the destination FQDN to the tenant Forward Proxy whitelist
2. Configure the application to use the Forward Proxy endpoint
3. Write a NetworkPolicy Egress rule allowing traffic to the proxy host (not the final destination)
4. Do not write a CIDR NetworkPolicy pointing at the public Internet — it will be silently dropped at the guardrail

Internet ingress constraints (perimeter denies)

The SDN perimeter denies inbound Internet traffic to common management/data ports regardless of any tenant policy:

• SSH (22), RDP (3389), Telnet (23), SMB (445), NetBIOS (139)
• LDAP (389), LDAP-S (636)
• Oracle (1521), SQL Server (1433/1434), MySQL (3306), PostgreSQL (5432/5433)
• ICMP

With geo-fencing enabled, traffic from non-US/non-Canadian source IPs is restricted to HTTP/HTTPS only.

Public VIPs

• Public VIPs are the only path for Internet ingress to SDN workloads
• Public VIPs may attach only to Low workloads carrying the Internet-Ingress:ALLOW tag
• Public VIPs MUST NOT attach to Medium / High / DMZ / Zone B / Zone A / Zone C workloads
• Workloads receiving a Public VIP MUST be in the DMZ AD domain, not IDIR

SDN Implementation Patterns — Multi-Segment vs Single-Segment

The SDN can be implemented two ways, with different implications when traffic crosses the SDN perimeter to legacy multi-zone networks (Data Centre Classic):

Multi-Segment (per-tenant Low / Medium / High network segments)

• Each tenant has separate network segments per classification, tagged in IPAM
• External multi-zone networks (Data Centre Classic) can read the SDN classification
• Mapping recognised at the boundary: Low ↔ DMZ, Medium ↔ Zone B, High ↔ Zone A
• Higher level of trust possible across the boundary

Single-Segment (single network segment + tag-based classification)

• All workloads share one segment; classification enforced via tags / labels in the DFW

• Tags are lost at the SDN perimeter

• External networks treat all SDN traffic as the segment's lowest classification — in practice, DMZ / Low

• A Medium workload may be permitted by SDN guardrails to reach a Zone A workload, but the Zone A boundary firewall will deny it (source appears as DMZ)

• Best suited to containerised workloads (e.g., OpenShift); confines guardrail scope to intra-SDN flows

External Partner Connectivity — Third Party Gateway (3PG) / ExtraNet

Any connection to an external government partner (other ministries, Crown corporations, health authorities, municipalities, federal partners) must traverse the ExtraNet zone via a Third Party Gateway (3PG). This is the connectivity model mandated by IMIT 5.08 Network-to-Network Connectivity Security Standard (a.k.a. the 3PG Standard).

IMIT 5.08 — Mandatory N2N Controls

When one end of a connection is the SPAN network, the 3PG service MUST be used (IMIT 5.08 §5). The 3PG architecture provides:

Process

1. Submit a formal SSBC connection request referencing the target organisation and IP range
2. Await 3PG CIDR allocation from SSBC (the actual destination CIDRs are not directly routable)
3. Write an Egress NetworkPolicy targeting the 3PG CIDR (not the partner's final destination IP)
4. The 3PG performs NAT/routing to the partner's network

Do not attempt to route external-partner traffic through the SSBC Forward Proxy or the regular internet egress path — neither path reaches the ExtraNet segment.

SPAN / BC Gov Network

Connections within the BC Gov SPAN network (e.g., to on-premises data centres, shared services, or other ministries on the corporate LAN) are also subject to zone-to-zone adjacency rules. Confirm the target system's zone before designing your NetworkPolicy.

Worked Example — Classifying a New Workload

Q: My API stores Protected-B (higher-risk) criminal justice data. What zone, what DataClass label, and can I call a public REST API for address validation?

1. Data class = Protected B (higher-risk) → SDN High → DataClass: High → IMIT 6.13 Zone A
2. Internet egress for High = denied at guardrail; SDN Forward Proxy requires MISO exemption
3. Options:

   • Recommended: split the workload — the data store stays High; create a Medium proxy service (or a Low + WAF service) that calls the public address-validation API via the Forward Proxy and serves the result to the High workload internally

   • Reclassify the requesting component if it is not itself responsible for High data

   • Apply for MISO exemption (lengthy; only justified for update / licence / call-home traffic)

Quick Reference — Which Standard Governs?

Full URLs are in this skill's frontmatter sources: block.

BC_GOV_SDN_ZONES_KNOWLEDGE

• 2026-06-05: [multi-app-engagement] Zone C is the Trusted Client Zone for IDIR workstations — never assign DataClass: High to Zone C; High maps to Zone A (Restricted High Security) and Low maps to DMZ, not Zone A
• 2026-06-05: [multi-app-engagement] AI models frequently confuse Zone A/B/C ordinal numbering with ascending sensitivity — always use the full name (Zone A = Restricted High Security, Zone B = High Security, Zone C = Trusted Client / workstations)