Skip to content

Network Security

Statement

ClaimGuard runs on a single internet-exposed VM in GCP. Network security posture is enforced via:

  • GCP VPC firewall rules scoped to the production VM (claim-guard-app-1, europe-west1-b).
  • Identity-Aware Proxy (IAP) as the only path to administrative SSH — no public SSH, no jump host, no shared bastion.
  • Cloud Audit Logs record every firewall rule mutation in the immutable audit log bucket (see Audit logging).

Implementation

Administrative access (SSH)

SSH is not exposed to the public internet. The only allow-rule for TCP/22 is allow-ssh-iap, scoped to Google's IAP source range:

$ gcloud compute firewall-rules describe allow-ssh-iap --project=train-cvit2
direction: INGRESS
allowed:
  - IPProtocol: tcp
    ports: ['22']
sourceRanges:
  - 35.235.240.0/20      # GCP IAP only
targetTags:
  - allow-ssh-iap

To reach the VM, an operator must:

  1. Hold a GCP IAM role granting roles/iap.tunnelResourceAccessor on the VM.
  2. Use gcloud compute ssh ... --tunnel-through-iap (no inbound port from the public internet is involved).

The legacy world-open SSH rules (allow-ssh, default-allow-ssh) were deleted on 2026-04-28 (plan step A0.2, journal entry of the same name).

RDP

There is no RDP service on the VM, and there has not been since at least the start of the hardening engagement. The legacy default-allow-rdp rule that exposed TCP/3389 to 0.0.0.0/0 was deleted on 2026-04-27 (A0.1). A second rule, allow-comfui, also opened TCP/3389 alongside TCP/8188 and was deleted in the same week.

Application traffic

Application traffic currently reaches the VM directly on its public IP (34.76.180.225, static, named claim-guard-vm-ip) on the API and frontend dev ports. There is no managed load balancer or TLS termination in front yet. This is the single largest gap in this control area and is the reason the status below is partial.

The plan to close this gap is:

  1. A1.3 — front the VM with a global external Application Load Balancer plus a Google-managed SSL certificate. DNS for app.<domain> points at the LB.
  2. A1.2 — remove the world-open dev/internal firewall rules (the LB then becomes the only ingress path):
  3. allow-vite-dev (TCP/5173)
  4. allow-tcp-9996-9997 (TCP/9996, 9997, 3001)
  5. claim-guard-tools (TCP/9999, 9998, 8737, 5678)
  6. allow-8998, allow-8999, allow-fastapi, allow-api-8001, allow-forensic-8002, allow-n8n, rabbit-amqp, rabbit-mgmt, rabbit-prom, wma-backend-server, verifai-gateway-allow-8080, allow-8542.

A1.3 must precede A1.2 because the rule that exposes the production API port (3001) is bundled into allow-tcp-9996-9997. Closing it before the LB takes traffic would be a production outage.

Internal service traffic

The Node.js backend talks to the on-VM Python tool services (master_tool, c2pa, dtect_image, provenance, layover) over 127.0.0.1 only. None of those calls leave the VM, so the firewall rules exposing those ports to 0.0.0.0/0 are surplus and slated for removal in A1.2.

Egress

Egress is the GCP default default-allow-egress (allow all). Tightening egress is a roadmap item (post-LB, see below).

Status

partial — verified 2026-04-29.

What's done:

  • World-open SSH and RDP eliminated; SSH gated behind IAP.
  • All firewall mutations are audit-logged with 400-day retention.
  • VM uses a known, static external IP (no risk of IP recycling exposing stale DNS).

What's still pending:

  • The application API and dev tooling ports remain world-reachable until A1.3 (HTTPS LB) lands and A1.2 (firewall closure) follows. Tracked in docs/security/HARDENING-LOG.md.

Roadmap

  • A1.3 — HTTPS LB + Google-managed cert (target: Q2 2026, blocked on hostname decision).
  • A1.2 — close all dev/internal firewall rules listed above (gated on A1.3).
  • Egress restrictions — post-LB, define an egress allow-list (Secret Manager, Cloud Logging, GCS endpoints, third-party APIs the app calls).
  • Cloud Armor / WAF — explicit non-goal until the LB is in place; will be re-evaluated for SOC 2 Type II.