2026-05-29 17:44:55 -04:00
|
|
|
#!/usr/bin/env node
|
|
|
|
|
import "source-map-support/register";
|
|
|
|
|
import * as cdk from "aws-cdk-lib";
|
|
|
|
|
import { AccountBaselineStack } from "../lib/account-baseline-stack";
|
Add AWS Backup with offsite vault (audit C-7) (#3)
* Add AWS Backup with offsite vault (audit C-7)
The account had zero AWS Backup vaults/plans, so 22 of 23 data stores
had no immutable, cross-region recovery path (audit finding C-7). One
ransomware event or rogue delete would erase primary plus same-region
snapshots/PITR.
Phase 1 ("critical data first") protects the seven highest-risk stores
with no offsite leg today (2 RDS, 2 DynamoDB, 3 S3) via a daily plan in
a new us-east-1 vault, copied cross-region into a governance-locked
us-west-2 vault. Governance (not compliance) mode first so the plan can
be validated before committing to irreversible immutability.
The backup service role is backup-only (no restore policies) to stay
least-privilege; restores get a separate audited path later. Resources
are selected by explicit ARN to avoid drifting the stacks that own them.
Deploys via the shared cdk deploy --all alongside the C-1 CloudTrail
stack. See the README pre-deploy gates (S3 versioning, database-1
unencrypted copy smoke-test, DynamoDB PITR) before the first run.
* Grant AWS Backup service use of vault CMKs
The L2 BackupVault does not grant the backup service principal use of a
customer-managed key; the synthesized key policy only delegated to
account IAM. Cross-region copy of encrypted RDS/EBS recovery points uses
KMS grants on the destination key, so without an explicit grant those
copy jobs fail — and silently, since the account has no CloudTrail yet.
Add backup.amazonaws.com crypto + CreateGrant statements to both vault
keys, scoped by aws:SourceAccount (cross-review BLOCK 2; mirrors the
discipline used on the C-1 CloudTrail key). Same class of bug the C-1
cross-review caught on the CloudTrail CMK.
2026-05-29 18:06:17 -04:00
|
|
|
import { BackupOffsiteStack } from "../lib/backup-offsite-stack";
|
|
|
|
|
import { BackupStack } from "../lib/backup-stack";
|
2026-06-08 16:17:50 -04:00
|
|
|
import { RegionalBaselineStack } from "../lib/regional-baseline-stack";
|
|
|
|
|
|
|
|
|
|
const ACCOUNT = "328440206208";
|
2026-05-29 17:44:55 -04:00
|
|
|
|
|
|
|
|
const app = new cdk.App();
|
|
|
|
|
|
|
|
|
|
new AccountBaselineStack(app, "account-baseline", {
|
|
|
|
|
stackName: "seahaven-account-baseline",
|
2026-06-08 16:17:50 -04:00
|
|
|
env: { account: ACCOUNT, region: "us-east-1" },
|
2026-06-01 17:56:12 -04:00
|
|
|
monthlyBudgetUsd: 1200,
|
|
|
|
|
budgetAlertEmail: "adam@seahavenind.com",
|
2026-05-29 17:44:55 -04:00
|
|
|
});
|
Add AWS Backup with offsite vault (audit C-7) (#3)
* Add AWS Backup with offsite vault (audit C-7)
The account had zero AWS Backup vaults/plans, so 22 of 23 data stores
had no immutable, cross-region recovery path (audit finding C-7). One
ransomware event or rogue delete would erase primary plus same-region
snapshots/PITR.
Phase 1 ("critical data first") protects the seven highest-risk stores
with no offsite leg today (2 RDS, 2 DynamoDB, 3 S3) via a daily plan in
a new us-east-1 vault, copied cross-region into a governance-locked
us-west-2 vault. Governance (not compliance) mode first so the plan can
be validated before committing to irreversible immutability.
The backup service role is backup-only (no restore policies) to stay
least-privilege; restores get a separate audited path later. Resources
are selected by explicit ARN to avoid drifting the stacks that own them.
Deploys via the shared cdk deploy --all alongside the C-1 CloudTrail
stack. See the README pre-deploy gates (S3 versioning, database-1
unencrypted copy smoke-test, DynamoDB PITR) before the first run.
* Grant AWS Backup service use of vault CMKs
The L2 BackupVault does not grant the backup service principal use of a
customer-managed key; the synthesized key policy only delegated to
account IAM. Cross-region copy of encrypted RDS/EBS recovery points uses
KMS grants on the destination key, so without an explicit grant those
copy jobs fail — and silently, since the account has no CloudTrail yet.
Add backup.amazonaws.com crypto + CreateGrant statements to both vault
keys, scoped by aws:SourceAccount (cross-review BLOCK 2; mirrors the
discipline used on the C-1 CloudTrail key). Same class of bug the C-1
cross-review caught on the CloudTrail CMK.
2026-05-29 18:06:17 -04:00
|
|
|
|
2026-06-08 16:17:50 -04:00
|
|
|
// ── Secondary-region baselines (INFRA-16, INFRA-91) ──────────────────────────
|
|
|
|
|
// The us-east-1 baseline above is region-pinned by design. These stacks extend
|
|
|
|
|
// a minimal detective/logging footprint into the secondary regions, codifying
|
|
|
|
|
// state applied out-of-band this week so it lives in IaC.
|
|
|
|
|
|
|
|
|
|
// us-west-2: Bedrock invocation logging only (INFRA-91). Shares the region with
|
|
|
|
|
// the offsite backup vault but is an independent concern (separate stack).
|
|
|
|
|
new RegionalBaselineStack(app, "regional-baseline-us-west-2", {
|
|
|
|
|
stackName: "seahaven-regional-baseline-us-west-2",
|
|
|
|
|
env: { account: ACCOUNT, region: "us-west-2" },
|
|
|
|
|
bedrockLogging: true,
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
// us-east-2: Bedrock invocation logging (INFRA-91) + the still-missing AWS
|
|
|
|
|
// Config recorder and Security Hub (INFRA-16). GuardDuty + flow logs already
|
|
|
|
|
// live here (adopted as a follow-up, see lib/regional-baseline-stack.ts).
|
|
|
|
|
new RegionalBaselineStack(app, "regional-baseline-us-east-2", {
|
|
|
|
|
stackName: "seahaven-regional-baseline-us-east-2",
|
|
|
|
|
env: { account: ACCOUNT, region: "us-east-2" },
|
|
|
|
|
bedrockLogging: true,
|
|
|
|
|
configRecorder: true,
|
|
|
|
|
securityHub: true,
|
|
|
|
|
});
|
|
|
|
|
|
Add AWS Backup with offsite vault (audit C-7) (#3)
* Add AWS Backup with offsite vault (audit C-7)
The account had zero AWS Backup vaults/plans, so 22 of 23 data stores
had no immutable, cross-region recovery path (audit finding C-7). One
ransomware event or rogue delete would erase primary plus same-region
snapshots/PITR.
Phase 1 ("critical data first") protects the seven highest-risk stores
with no offsite leg today (2 RDS, 2 DynamoDB, 3 S3) via a daily plan in
a new us-east-1 vault, copied cross-region into a governance-locked
us-west-2 vault. Governance (not compliance) mode first so the plan can
be validated before committing to irreversible immutability.
The backup service role is backup-only (no restore policies) to stay
least-privilege; restores get a separate audited path later. Resources
are selected by explicit ARN to avoid drifting the stacks that own them.
Deploys via the shared cdk deploy --all alongside the C-1 CloudTrail
stack. See the README pre-deploy gates (S3 versioning, database-1
unencrypted copy smoke-test, DynamoDB PITR) before the first run.
* Grant AWS Backup service use of vault CMKs
The L2 BackupVault does not grant the backup service principal use of a
customer-managed key; the synthesized key policy only delegated to
account IAM. Cross-region copy of encrypted RDS/EBS recovery points uses
KMS grants on the destination key, so without an explicit grant those
copy jobs fail — and silently, since the account has no CloudTrail yet.
Add backup.amazonaws.com crypto + CreateGrant statements to both vault
keys, scoped by aws:SourceAccount (cross-review BLOCK 2; mirrors the
discipline used on the C-1 CloudTrail key). Same class of bug the C-1
cross-review caught on the CloudTrail CMK.
2026-05-29 18:06:17 -04:00
|
|
|
// AWS Backup (audit C-7). Offsite vault (us-west-2) must exist before the
|
|
|
|
|
// primary plan that copies to it, hence the explicit dependency.
|
|
|
|
|
const backupOffsite = new BackupOffsiteStack(app, "backup-offsite", {
|
|
|
|
|
stackName: "seahaven-backup-offsite",
|
|
|
|
|
env: { account: "328440206208", region: "us-west-2" },
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
const backupPrimary = new BackupStack(app, "backup", {
|
|
|
|
|
stackName: "seahaven-backup",
|
|
|
|
|
env: { account: "328440206208", region: "us-east-1" },
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
backupPrimary.addDependency(backupOffsite);
|