Skip to main content
This page records the security posture and known risks, and sets out how SG-Infra improves on TalentIdPipeline-Infra-CDK and what is still outstanding. SG-Infra is the target pattern, so this page is also the case for migrating onto it.

​
How SG-Infra Improves on the Legacy Pattern

  • Data separated from compute. The data is on a retained, encrypted volume in its own stack, so the instance can be rebuilt without losing data.
  • Backups with retention. The backup bucket is versioned with about a week of history, rather than a single overwritten file.
  • Stronger TLS. The certificate authority is generated on the instance rather than committed to the repository, certificate validation is enabled, and old TLS versions are disabled.
  • Encryption at rest. Both the root volume and the data volume are encrypted.
  • Team standard tooling. TypeScript CDK and a GitHub sourced pipeline, rather than Python CDK and CodeCommit.
  • Newer database. MongoDB 8.2, run in a container for a more reproducible setup.

​
Security Posture

  • Network: MongoDB is reachable only on 27017 from the Lambda security group, and the instance is in a private subnet with no public address. The container listens on all interfaces, but the security group and private placement contain it.
  • Transport: TLS is required, the CA is generated on the instance (not in source control), validation is enabled and weak TLS versions are disabled.
  • Credentials: the admin password is stored in Secrets Manager and reused across redeploys. The secret also holds the connection string and CA certificate for consumers.
  • IAM: the instance role is scoped to the specific setup and backup buckets for S3, which is good. However it still grants broad access to Secrets Manager and to SSM Parameter Store (all actions, all resources), which is wider than needed and worth tightening.

​
Remaining Risks

  • Single point of failure. One instance and a single node replica set, with no automatic failover. The improvement over the legacy instance is faster recovery (the data volume is retained), not high availability.
  • Dependency on the legacy repo. SG-Infra reads the VPC from TalentIdPipeline-Infra-CDK, so it is not yet self-contained.
  • No deployment approval. A merge to the prod branch deploys automatically, with no manual approval step.
  • Manual, untested restore. Recovery from backup is manual and not regularly exercised. See Backups and Disaster Recovery.
  • Broad IAM on secrets and parameters. As above, the Secrets Manager and SSM permissions on the instance role are wider than necessary.

​
Direction of Travel

SG-Infra is the target infrastructure pattern for new and migrated systems. New systems should adopt it rather than extending the legacy repo, and existing systems should move onto it over time, though no migration timeline has been agreed. The clearest outstanding step is to give SG-Infra its own VPC and remove the dependency on TalentIdPipeline-Infra-CDK, which would make it fully self-contained. Beyond that, the priorities are the ones any production database deserves: tighten the IAM permissions, consider high availability rather than a single node, add a deployment approval step, and write and test a restore runbook.

​
Key Files

Last modified on June 30, 2026