seahaven-account-baseline/bin/app.ts

109 lines
4.9 KiB
TypeScript
Raw Normal View History

#!/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";
[INFRA-91/89/16/88/73] Reconcile out-of-band baseline changes + add missing detective controls (#18) * Codify primary vault lock + add backups (INFRA-89, INFRA-88) INFRA-89: codify the GOVERNANCE Vault Lock applied out-of-band on the seahaven-primary vault (MinRetention 1d, MaxRetention 2555d, no changeableFor = admin-removable) so it lives in IaC. Values match the live lock exactly, so the deploy is a no-op adoption. Add a scoped vault access policy that denies manual recovery-point deletion and lock/policy tampering to all principals except the AWS Backup service role and the break-glass SSO AdministratorAccess role, so automatic lifecycle expiry still works but humans cannot prune recovery points by hand. Cross-review (GPT-4.1) BLOCK: NotPrincipal does not support wildcard ARN matching, so the SSO exemption is expressed as Effect DENY with Principal * and a StringNotLike condition on aws:PrincipalArn, which does support wildcards. This avoids an unrecoverable vault lockout. INFRA-88: add 6 S3 buckets (kb-docs, payroll-emails [PII], amazon-po, extracted-amazon-po, proposal-system uploads + generated) to the phase2-offsite-everything selection. Versioning verified enabled on all 6 against the live account (S3 backup requires versioning). Refs: INFRA-89, INFRA-88 * Promote account trail to organization trail (INFRA-73) INFRA-73: set isOrganizationTrail on seahaven-org-trail and pass orgId (o-9kufuzz6b4) so the L2 Trail attaches the AWSLogs/<org-id>/* bucket PutObject statement for member-account delivery. CloudTrail org trusted-access is already enabled on the management account. Broaden the KMS key policy with an org-scoped GenerateDataKey/DescribeKey statement for member-account trail delivery, guarded by aws:PrincipalOrgID. The existing single-account statements are preserved so management-account delivery is unaffected. Cross-review (GPT-4.1) BLOCK: the member KMS SourceArn and encryption context must be wildcarded across accounts (org-trail shadow trails present the member account id), not pinned to the management account, or member delivery silently fails. Fixed before checkpoint. CHECKPOINT: delicate org-trail KMS/bucket-policy change — code + diff captured for review, NOT deployed. Refs: INFRA-73 * Add secondary-region baseline stacks (INFRA-91, INFRA-16) INFRA-91: codify the Bedrock model-invocation logging applied out-of-band in us-west-2 and us-east-2 (per-region delivery role seahaven-bedrock-invocation-logging-<region> + log group /aws/bedrock/model-invocations 90d, CloudWatch-only). The account-level logging config itself has no CFN resource type and is applied via CLI (already live), same as us-east-1. INFRA-16: add the still-missing us-east-2 detective controls — AWS Config recorder role + delivery bucket (recorder/channel via CLI to avoid the CFN stabilization deadlock seen in us-east-1) and Security Hub with FSBP + CIS v3.0. GuardDuty + flow logs already live in us-east-2 and are left for a follow-up adoption to keep this change non-destructive. The us-east-1 baseline stays region-pinned; these are separate RegionalBaselineStack instances composed opt-in per region. CHECKPOINT: new multi-region stacks. The live Bedrock role + log group already exist (CLI-created), so a plain deploy would collide — these need cdk import / changeset adoption, not cdk deploy. Code + diff captured for review, NOT deployed. Refs: INFRA-91, INFRA-16 * Drop vault access policy from this deploy; tracked in INFRA-94 (kept governance lock codify + selection)
2026-06-08 17:03:18 -04:00
import { RegionalBaselineStack } from "../lib/regional-baseline-stack";
import { DynamoDbCmkStack } from "../lib/dynamodb-cmk-stack";
Merge external-dev member baseline; rename to seahaven-org-baseline (#43) * Parameterize baseline constructs for multi-account reuse DetectiveControls, FlowLogs, and GovernanceToggles were forked into seahaven-external-dev-baseline with only physical-name and VPC-sourcing differences. Prefix/name props let one implementation serve both accounts; synthesized templates are unchanged (verified: empty cdk diff against all deployed stacks). * Absorb external-dev member baseline stack Moves seahaven-external-dev-baseline's stack in as MemberBaselineStack, construct ids and physical names byte-identical to the deployed stack (logical IDs are path-derived; empty cdk diff verified via change set against 396287094661). Retires the forked repo so member-account baselines share one drift surface and one dependency pin. * Rename package to seahaven-org-baseline Prepares the repo rename: the app now spans the management account and org member accounts, so 'account-baseline' undersells the scope. README documents the two-account deploy topology and logical-ID constraints. * Commit extdev flow-log VPC ids in code, not -c context Security review SH-ORG-004 (confirmed high): with the ids sourced from ephemeral cdk context, any context-less deploy silently removes every flow log in the isolated account. A committed list makes the attachment set reviewable and immune to a forgotten -c flag. Empty list matches the deployed stack (zero diff). * Split CD into per-account deploy jobs The app now spans two AWS accounts; cdk deploy --all under one role fails on the other account's stacks (security review IAC-01). Each job passes explicit stack selectors and its own account's OIDC role via the new cd-cdk stacks input.
2026-07-14 13:53:07 -04:00
import { MemberBaselineStack } from "../lib/member-baseline-stack";
[INFRA-91/89/16/88/73] Reconcile out-of-band baseline changes + add missing detective controls (#18) * Codify primary vault lock + add backups (INFRA-89, INFRA-88) INFRA-89: codify the GOVERNANCE Vault Lock applied out-of-band on the seahaven-primary vault (MinRetention 1d, MaxRetention 2555d, no changeableFor = admin-removable) so it lives in IaC. Values match the live lock exactly, so the deploy is a no-op adoption. Add a scoped vault access policy that denies manual recovery-point deletion and lock/policy tampering to all principals except the AWS Backup service role and the break-glass SSO AdministratorAccess role, so automatic lifecycle expiry still works but humans cannot prune recovery points by hand. Cross-review (GPT-4.1) BLOCK: NotPrincipal does not support wildcard ARN matching, so the SSO exemption is expressed as Effect DENY with Principal * and a StringNotLike condition on aws:PrincipalArn, which does support wildcards. This avoids an unrecoverable vault lockout. INFRA-88: add 6 S3 buckets (kb-docs, payroll-emails [PII], amazon-po, extracted-amazon-po, proposal-system uploads + generated) to the phase2-offsite-everything selection. Versioning verified enabled on all 6 against the live account (S3 backup requires versioning). Refs: INFRA-89, INFRA-88 * Promote account trail to organization trail (INFRA-73) INFRA-73: set isOrganizationTrail on seahaven-org-trail and pass orgId (o-9kufuzz6b4) so the L2 Trail attaches the AWSLogs/<org-id>/* bucket PutObject statement for member-account delivery. CloudTrail org trusted-access is already enabled on the management account. Broaden the KMS key policy with an org-scoped GenerateDataKey/DescribeKey statement for member-account trail delivery, guarded by aws:PrincipalOrgID. The existing single-account statements are preserved so management-account delivery is unaffected. Cross-review (GPT-4.1) BLOCK: the member KMS SourceArn and encryption context must be wildcarded across accounts (org-trail shadow trails present the member account id), not pinned to the management account, or member delivery silently fails. Fixed before checkpoint. CHECKPOINT: delicate org-trail KMS/bucket-policy change — code + diff captured for review, NOT deployed. Refs: INFRA-73 * Add secondary-region baseline stacks (INFRA-91, INFRA-16) INFRA-91: codify the Bedrock model-invocation logging applied out-of-band in us-west-2 and us-east-2 (per-region delivery role seahaven-bedrock-invocation-logging-<region> + log group /aws/bedrock/model-invocations 90d, CloudWatch-only). The account-level logging config itself has no CFN resource type and is applied via CLI (already live), same as us-east-1. INFRA-16: add the still-missing us-east-2 detective controls — AWS Config recorder role + delivery bucket (recorder/channel via CLI to avoid the CFN stabilization deadlock seen in us-east-1) and Security Hub with FSBP + CIS v3.0. GuardDuty + flow logs already live in us-east-2 and are left for a follow-up adoption to keep this change non-destructive. The us-east-1 baseline stays region-pinned; these are separate RegionalBaselineStack instances composed opt-in per region. CHECKPOINT: new multi-region stacks. The live Bedrock role + log group already exist (CLI-created), so a plain deploy would collide — these need cdk import / changeset adoption, not cdk deploy. Code + diff captured for review, NOT deployed. Refs: INFRA-91, INFRA-16 * Drop vault access policy from this deploy; tracked in INFRA-94 (kept governance lock codify + selection)
2026-06-08 17:03:18 -04:00
const ACCOUNT = "328440206208";
Merge external-dev member baseline; rename to seahaven-org-baseline (#43) * Parameterize baseline constructs for multi-account reuse DetectiveControls, FlowLogs, and GovernanceToggles were forked into seahaven-external-dev-baseline with only physical-name and VPC-sourcing differences. Prefix/name props let one implementation serve both accounts; synthesized templates are unchanged (verified: empty cdk diff against all deployed stacks). * Absorb external-dev member baseline stack Moves seahaven-external-dev-baseline's stack in as MemberBaselineStack, construct ids and physical names byte-identical to the deployed stack (logical IDs are path-derived; empty cdk diff verified via change set against 396287094661). Retires the forked repo so member-account baselines share one drift surface and one dependency pin. * Rename package to seahaven-org-baseline Prepares the repo rename: the app now spans the management account and org member accounts, so 'account-baseline' undersells the scope. README documents the two-account deploy topology and logical-ID constraints. * Commit extdev flow-log VPC ids in code, not -c context Security review SH-ORG-004 (confirmed high): with the ids sourced from ephemeral cdk context, any context-less deploy silently removes every flow log in the isolated account. A committed list makes the attachment set reviewable and immune to a forgotten -c flag. Empty list matches the deployed stack (zero diff). * Split CD into per-account deploy jobs The app now spans two AWS accounts; cdk deploy --all under one role fails on the other account's stacks (security review IAC-01). Each job passes explicit stack selectors and its own account's OIDC role via the new cd-cdk stacks input.
2026-07-14 13:53:07 -04:00
const EXTERNAL_DEV_ACCOUNT = "396287094661";
// All 5 VPCs in 328440206208 / us-east-1 (4 custom + default), audit Agent 7.
// Index-derived logical IDs — append only, never reorder.
const PROD_VPC_IDS = [
"vpc-061d66990b6a4d1fb",
"vpc-0542a9e934b417d23",
"vpc-062d200c68bd4ca0e",
"vpc-0d3d4b67bd0cf8a68",
"vpc-02c10a89d66f6f9b8",
];
const app = new cdk.App();
new AccountBaselineStack(app, "account-baseline", {
stackName: "seahaven-account-baseline",
[INFRA-91/89/16/88/73] Reconcile out-of-band baseline changes + add missing detective controls (#18) * Codify primary vault lock + add backups (INFRA-89, INFRA-88) INFRA-89: codify the GOVERNANCE Vault Lock applied out-of-band on the seahaven-primary vault (MinRetention 1d, MaxRetention 2555d, no changeableFor = admin-removable) so it lives in IaC. Values match the live lock exactly, so the deploy is a no-op adoption. Add a scoped vault access policy that denies manual recovery-point deletion and lock/policy tampering to all principals except the AWS Backup service role and the break-glass SSO AdministratorAccess role, so automatic lifecycle expiry still works but humans cannot prune recovery points by hand. Cross-review (GPT-4.1) BLOCK: NotPrincipal does not support wildcard ARN matching, so the SSO exemption is expressed as Effect DENY with Principal * and a StringNotLike condition on aws:PrincipalArn, which does support wildcards. This avoids an unrecoverable vault lockout. INFRA-88: add 6 S3 buckets (kb-docs, payroll-emails [PII], amazon-po, extracted-amazon-po, proposal-system uploads + generated) to the phase2-offsite-everything selection. Versioning verified enabled on all 6 against the live account (S3 backup requires versioning). Refs: INFRA-89, INFRA-88 * Promote account trail to organization trail (INFRA-73) INFRA-73: set isOrganizationTrail on seahaven-org-trail and pass orgId (o-9kufuzz6b4) so the L2 Trail attaches the AWSLogs/<org-id>/* bucket PutObject statement for member-account delivery. CloudTrail org trusted-access is already enabled on the management account. Broaden the KMS key policy with an org-scoped GenerateDataKey/DescribeKey statement for member-account trail delivery, guarded by aws:PrincipalOrgID. The existing single-account statements are preserved so management-account delivery is unaffected. Cross-review (GPT-4.1) BLOCK: the member KMS SourceArn and encryption context must be wildcarded across accounts (org-trail shadow trails present the member account id), not pinned to the management account, or member delivery silently fails. Fixed before checkpoint. CHECKPOINT: delicate org-trail KMS/bucket-policy change — code + diff captured for review, NOT deployed. Refs: INFRA-73 * Add secondary-region baseline stacks (INFRA-91, INFRA-16) INFRA-91: codify the Bedrock model-invocation logging applied out-of-band in us-west-2 and us-east-2 (per-region delivery role seahaven-bedrock-invocation-logging-<region> + log group /aws/bedrock/model-invocations 90d, CloudWatch-only). The account-level logging config itself has no CFN resource type and is applied via CLI (already live), same as us-east-1. INFRA-16: add the still-missing us-east-2 detective controls — AWS Config recorder role + delivery bucket (recorder/channel via CLI to avoid the CFN stabilization deadlock seen in us-east-1) and Security Hub with FSBP + CIS v3.0. GuardDuty + flow logs already live in us-east-2 and are left for a follow-up adoption to keep this change non-destructive. The us-east-1 baseline stays region-pinned; these are separate RegionalBaselineStack instances composed opt-in per region. CHECKPOINT: new multi-region stacks. The live Bedrock role + log group already exist (CLI-created), so a plain deploy would collide — these need cdk import / changeset adoption, not cdk deploy. Code + diff captured for review, NOT deployed. Refs: INFRA-91, INFRA-16 * Drop vault access policy from this deploy; tracked in INFRA-94 (kept governance lock codify + selection)
2026-06-08 17:03:18 -04:00
env: { account: ACCOUNT, region: "us-east-1" },
Account detective layer + budget (audit Day 1) (#5) * Add account detective layer + budget (audit Day 1: H-2/H-3/H-4/M-5/M-10) Adds to the seahaven-account-baseline stack: - AWS Config recorder (all + global resources) + delivery channel + role + hardened delivery bucket (H-2, CIS 3.3/3.5). Recorder role IAM cross-reviewed. - GuardDuty detector, us-east-1 (H-3) - Security Hub with AWS FSBP v1.0.0 + CIS v3.0.0 standards, depends on Config (H-4) - IAM Access Analyzer, account scope (M-5) - Monthly cost budget $1,200 with 80/100% actual + 100% forecast alerts to adam@seahavenind.com (M-10) Scope us-east-1 only (all workloads here); multi-region is a follow-up. The CLI-applied governance toggles (M-6/M-3/M-7/L-8/M-11) are documented separately in the README runbook. * Document Day 1 detective layer + CLI governance toggles in README * Move Config recorder+channel to CLI (L1 stabilization deadlock) The L1 AWS::Config::ConfigurationRecorder hangs the stack: it never reaches CREATE_COMPLETE until recording is active (needs a delivery channel), and the delivery channel cannot be created until the recorder completes — a deadlock that hung the deploy ~27 min before manual cancel (2026-06-01). Keep the cross-reviewed recorder role + delivery bucket in IaC; create the recorder, delivery channel, and start recording via CLI (documented in README). Security Hub no longer takes a CFN dependency on the recorder; CIS/FSBP controls evaluate once Config is recording. Verified live: recording=true, SUCCESS.
2026-06-01 17:56:12 -04:00
monthlyBudgetUsd: 1200,
budgetAlertEmail: "adam@seahavenind.com",
Merge external-dev member baseline; rename to seahaven-org-baseline (#43) * Parameterize baseline constructs for multi-account reuse DetectiveControls, FlowLogs, and GovernanceToggles were forked into seahaven-external-dev-baseline with only physical-name and VPC-sourcing differences. Prefix/name props let one implementation serve both accounts; synthesized templates are unchanged (verified: empty cdk diff against all deployed stacks). * Absorb external-dev member baseline stack Moves seahaven-external-dev-baseline's stack in as MemberBaselineStack, construct ids and physical names byte-identical to the deployed stack (logical IDs are path-derived; empty cdk diff verified via change set against 396287094661). Retires the forked repo so member-account baselines share one drift surface and one dependency pin. * Rename package to seahaven-org-baseline Prepares the repo rename: the app now spans the management account and org member accounts, so 'account-baseline' undersells the scope. README documents the two-account deploy topology and logical-ID constraints. * Commit extdev flow-log VPC ids in code, not -c context Security review SH-ORG-004 (confirmed high): with the ids sourced from ephemeral cdk context, any context-less deploy silently removes every flow log in the isolated account. A committed list makes the attachment set reviewable and immune to a forgotten -c flag. Empty list matches the deployed stack (zero diff). * Split CD into per-account deploy jobs The app now spans two AWS accounts; cdk deploy --all under one role fails on the other account's stacks (security review IAC-01). Each job passes explicit stack selectors and its own account's OIDC role via the new cd-cdk stacks input.
2026-07-14 13:53:07 -04:00
flowLogVpcIds: PROD_VPC_IDS,
});
// ── Member-account baseline: seahaven-external-dev ───────────────────────────
// Absorbed from the retired seahaven-external-dev-baseline repo. Stack name and
// every construct id preserved byte-identically (logical IDs are path-derived —
// renaming anything here replaces live resources). Deploys to the isolated
// external-dev member account via its own OIDC deploy role, NOT the mgmt role.
//
// Flow-log VPC ids are COMMITTED here, not passed via -c context. The old
// repo's `-c flowLogVpcIds=...` pattern was a confirmed security-review trap
// (SH-ORG-004): once flow logs were attached via context, any context-less
// deploy (including CI) would silently REMOVE them all. Append ids via PR;
// never reorder (index-derived logical IDs). Empty = hardened bucket only,
// matching the currently deployed stack.
const EXTDEV_FLOW_LOG_VPC_IDS: string[] = [];
new MemberBaselineStack(app, "external-dev-baseline", {
stackName: "seahaven-external-dev-baseline",
env: { account: EXTERNAL_DEV_ACCOUNT, region: "us-east-1" },
namePrefix: "seahaven-extdev",
monthlyBudgetUsd: 200,
// NOTE: seahaven.com (not seahavenind.com) is deliberate-as-deployed; flagged
// in the 2026-07-14 security review (SH-ORG-007) for mailbox verification.
budgetAlertEmail: "adam@seahaven.com",
flowLogVpcIds: EXTDEV_FLOW_LOG_VPC_IDS,
// Keeps the tag value the stack was deployed with (zero-diff merge). Update
// to the current repo name in a deliberate follow-up change if desired.
managedByTag: "seahaven-external-dev-baseline",
});
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
// ── Shared DynamoDB CMK (INFRA-95 / M-3) ─────────────────────────────────────
// Dedicated, standalone stack so the customer-managed key for sensitive
// finance/PII DynamoDB tables is an independent shared dependency for the owning
// app repos (payments-dashboard, procurement-ingest, exec-aide). Its ARN is
// published to SSM (/seahaven/dynamodb/cmk-arn) for those stacks to consume.
new DynamoDbCmkStack(app, "dynamodb-cmk", {
stackName: "seahaven-dynamodb-cmk",
env: { account: ACCOUNT, region: "us-east-1" },
});
[INFRA-91/89/16/88/73] Reconcile out-of-band baseline changes + add missing detective controls (#18) * Codify primary vault lock + add backups (INFRA-89, INFRA-88) INFRA-89: codify the GOVERNANCE Vault Lock applied out-of-band on the seahaven-primary vault (MinRetention 1d, MaxRetention 2555d, no changeableFor = admin-removable) so it lives in IaC. Values match the live lock exactly, so the deploy is a no-op adoption. Add a scoped vault access policy that denies manual recovery-point deletion and lock/policy tampering to all principals except the AWS Backup service role and the break-glass SSO AdministratorAccess role, so automatic lifecycle expiry still works but humans cannot prune recovery points by hand. Cross-review (GPT-4.1) BLOCK: NotPrincipal does not support wildcard ARN matching, so the SSO exemption is expressed as Effect DENY with Principal * and a StringNotLike condition on aws:PrincipalArn, which does support wildcards. This avoids an unrecoverable vault lockout. INFRA-88: add 6 S3 buckets (kb-docs, payroll-emails [PII], amazon-po, extracted-amazon-po, proposal-system uploads + generated) to the phase2-offsite-everything selection. Versioning verified enabled on all 6 against the live account (S3 backup requires versioning). Refs: INFRA-89, INFRA-88 * Promote account trail to organization trail (INFRA-73) INFRA-73: set isOrganizationTrail on seahaven-org-trail and pass orgId (o-9kufuzz6b4) so the L2 Trail attaches the AWSLogs/<org-id>/* bucket PutObject statement for member-account delivery. CloudTrail org trusted-access is already enabled on the management account. Broaden the KMS key policy with an org-scoped GenerateDataKey/DescribeKey statement for member-account trail delivery, guarded by aws:PrincipalOrgID. The existing single-account statements are preserved so management-account delivery is unaffected. Cross-review (GPT-4.1) BLOCK: the member KMS SourceArn and encryption context must be wildcarded across accounts (org-trail shadow trails present the member account id), not pinned to the management account, or member delivery silently fails. Fixed before checkpoint. CHECKPOINT: delicate org-trail KMS/bucket-policy change — code + diff captured for review, NOT deployed. Refs: INFRA-73 * Add secondary-region baseline stacks (INFRA-91, INFRA-16) INFRA-91: codify the Bedrock model-invocation logging applied out-of-band in us-west-2 and us-east-2 (per-region delivery role seahaven-bedrock-invocation-logging-<region> + log group /aws/bedrock/model-invocations 90d, CloudWatch-only). The account-level logging config itself has no CFN resource type and is applied via CLI (already live), same as us-east-1. INFRA-16: add the still-missing us-east-2 detective controls — AWS Config recorder role + delivery bucket (recorder/channel via CLI to avoid the CFN stabilization deadlock seen in us-east-1) and Security Hub with FSBP + CIS v3.0. GuardDuty + flow logs already live in us-east-2 and are left for a follow-up adoption to keep this change non-destructive. The us-east-1 baseline stays region-pinned; these are separate RegionalBaselineStack instances composed opt-in per region. CHECKPOINT: new multi-region stacks. The live Bedrock role + log group already exist (CLI-created), so a plain deploy would collide — these need cdk import / changeset adoption, not cdk deploy. Code + diff captured for review, NOT deployed. Refs: INFRA-91, INFRA-16 * Drop vault access policy from this deploy; tracked in INFRA-94 (kept governance lock codify + selection)
2026-06-08 17:03:18 -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);