Country isolation
Keep workloads, networks, identities, data, encryption boundaries, and telemetry scoped to the correct country while retaining shared organizational governance.
← Selected work
Cloud Security · Google Cloud · DevSecOps
AfyaBridge Cloud Security
A multi-country cloud-security reference implementation for a fictional community-health organization operating across Kenya, Ghana, and South Africa — with country isolation, least privilege, keyless delivery, supply-chain integrity, posture governance, and evidence boundaries built into the system model.
Independent portfolio project. AfyaBridge Cloud Security uses a fictional organization and synthetic data to exercise cloud and application security controls. It does not represent the infrastructure, systems, credentials, or data of a healthcare organization.
The problem
Country boundaries, offline sync, and protected data change the security model.
The scenario assumes community-health teams operating across multiple countries, handling sensitive identity and health data, working through web and offline-capable field workflows, and depending on cloud infrastructure that must stay governable as the platform grows.
Least privilege
Minimize standing access for people and workloads, reject public principals, and make deployment privilege explicit and reviewable.
Protected health data
Define classification, residency, encryption, retention, secrets, backup, recovery, and deletion boundaries before deployment.
Secure delivery
Build toward keyless GitHub-to-GCP deployment with separate plan and apply identities instead of long-lived service-account keys.
Offline trust boundaries
Treat offline synchronization as a security boundary with actor and device binding, replay protection, idempotency, and conflict handling.
Evidence
Distinguish architecture that is designed from controls that are implemented and controls that have actually been validated.
Architecture
Govern centrally. Isolate deliberately.
The architecture separates organization-wide security and shared services from country-owned workloads. The goal is to keep the platform operable as one environment without making cross-country access the default.
Control maturity
Designed is not the same as validated.
The project avoids turning diagrams, Terraform, or a green workflow into claims that exceed the evidence. Each milestone records the boundary it has actually crossed.
Threat model + cloud architecture
Designed
Documented and reviewed architecture baseline
Application security baseline
Validated
Implemented with automated tests and successful CI evidence
Terraform / GCP infrastructure
Static validation
Implemented and recursively validated without live deployment
Shift-left security pipeline · v0.8
Completed
Fail-closed security gates enforced in repository CI
Software supply chain · v0.9
Validated
Trusted-main signing, attestations, provenance, SBOMs, and revocation checks exercised successfully
Posture & governance · v0.10
In review
Repository desired-state, drift decisions, finding lifecycle, and reporting exercised; live posture pending
Live Google Cloud enforcement
Pending
Deployment and runtime validation intentionally not yet claimed
Shift-left security · v0.8 · Completed
Security moves into the pull request.
Security checks run before deployment, feed a fail-closed security verdict, validate time-bounded exception records, and publish machine-readable and human-readable evidence for the reviewed change.
Software supply chain · v0.9 · Completed
The build has an identity and an evidence trail.
The supply-chain milestone hardens the path from protected source to build artifact: immutable workflow and provider inputs, SBOMs, separated build/sign identities, keyless signing, attestations, provenance verification, revocation policy, and negative compromise tests.
Signing authority is not available to pull requests
The privileged signing/provenance job is restricted to protected
refs/heads/main, while pull requests exercise the
unprivileged build and validation path.
Keyless signing and provenance
The trusted-main run signed the exact build with Sigstore/Cosign and verified GitHub provenance and SBOM attestations against source ref, source commit, and the fixed workflow identity.
Trust can be revoked
Artifact, source, and workflow identities are checked against an explicit revocation policy, with negative tests proving weakened trust boundaries fail rather than silently pass.
Cloud posture & governance · v0.10 · In review
Desired state becomes executable governance.
v0.10 turns the control matrix into machine-readable posture rules, tested drift decisions, a governed finding lifecycle, remediation SLAs, exception/risk-acceptance boundaries, and run-bound reporting.
11 / 11 repository rules currently pass
The repository report evaluates reviewed desired-state controls and fails closed when posture catalogue, ownership, implementation references, or governance invariants are weakened.
Findings keep their lifecycle evidence
Severity-derived SLAs, active and historical exceptions, remediation attempts, independent verification, and evidence-backed closure are represented as governed state rather than ad-hoc notes.
Repository posture is not live-cloud posture
All 11 executable rules still require live validation. Operational trend history remains intentionally empty until live evidence sources exist instead of being populated with synthetic operational claims.
Engineering decisions
The controls are consequences of trust boundaries.
The project is organized around security decisions and their evidence rather than a checklist of Google Cloud products.
No long-lived GCP keys in GitHub
The deployment path uses GitHub OIDC and Workload Identity Federation, with immutable repository claims and dedicated trust configuration instead of stored service-account credentials.
Terraform plan and apply are separate identities
Planning should not silently grant deployment capability. The IaC design separates plan and apply service accounts and keeps the impersonation path explicit.
Country boundaries are infrastructure boundaries
Shared governance does not require shared runtime trust. Country networks, keys, workload services, databases, storage, and observability routing are deliberately scoped.
Offline synchronization is security-sensitive
The application baseline binds actors and devices, handles replay and duplicate submissions, validates timestamps, and treats conflicts as an explicit state instead of blind eventual consistency.
Public edge does not mean public origin
The public path is designed around regional HTTPS load balancing, Cloud Armor, managed certificates, and restricted Cloud Run ingress so the application origin is not the intended direct entry point.
Detection is part of infrastructure
Logging, monitoring, security-detection metrics, and alert-policy contracts are implemented alongside workloads rather than treated as post-deployment documentation.
Repository evidence cannot impersonate live posture
Posture reports keep repository desired-state evidence separate from live Google Cloud state, findings, and trend history so a green CI run cannot become a fabricated operational claim.
Implementation evidence
What exists today.
The repository now carries validated application controls, statically validated Terraform, completed shift-left and supply-chain milestones, and v0.10 repository posture/governance controls. Live Google Cloud deployment and effective-state validation remain pending.
Threat model & control baseline
Assets, actors, trust boundaries, data flows, threat register, control matrix, assumptions, and scope for the multi-country scenario.
Landing zone, IAM, network & data architecture
Country hierarchy, Shared VPC patterns, identity domains, encryption, secrets, residency, backup, and recovery decisions.
Application security baseline
Deny-by-default authorization, country scope, audit events, database constraints, optimistic concurrency, offline sync controls, and automated security tests.
Terraform foundation
Bootstrap, remote state, project factory, folder hierarchy, org policies, IAM, budgets, network, workload, observability, and edge stacks.
Keyless deployment contracts
GitHub OIDC federation plus separate Terraform plan/apply identities and approval-gated deployment workflow contracts.
Observability & protected edge
Centralized logging, monitoring, detection metrics, alert policies, load balancing, Cloud Armor, DNS, certificate, and HTTPS controls.
Shift-left security pipeline
Secret, dependency, license, code, IaC, container, API, policy, and exception checks feed a fail-closed security verdict and evidence bundle.
Software supply-chain security
Immutable inputs, SBOMs, keyless Cosign signing, GitHub attestations, provenance verification, revocation policy, and negative compromise tests.
Posture & governance
Machine-readable posture, drift decisions, finding lifecycle, remediation SLA and exceptions, JSON/Markdown reports, and run-bound metrics with explicit live-state boundaries.
Current boundary
Repository evidence stops where live-cloud evidence should begin.
v0.8 and v0.9 are completed at their repository evidence boundaries, and v0.10 has executable desired-state checks, governance, and reporting in CI. The v0.7 infrastructure has still not been applied and validated in a live Google Cloud organization. Effective IAM, live network enforcement, managed-service behavior, Cloud Armor, logging delivery, live posture collection, real drift, runtime attack simulation, rollback, and recovery remain separate validation work.
Next milestones
- Close v0.10 posture/governance review
- Deploy and live-validate the v0.7 Google Cloud stacks
- Activate live posture and drift evidence sources
- Exercise a real finding, remediation, and closure lifecycle
- Shift-right runtime security validation
- Incident response and recovery exercises
Explore the work
The repository is the evidence trail.
The case study summarizes the engineering story. The repository holds the roadmap, architecture documents, Terraform, application baseline, security workflows, supply-chain controls, posture governance, evidence bundles, diagrams, runbooks, tests, and validation records.