# Scrivas — AWS Organizations Discovery & Account Assessment **Prepared by:** Dasnuve · **Date:** 2026-08-19 **Access used:** `dasnuve-scrivas-louis-impersonation` profile → `arn:aws:iam::716468089330:user/louis` (member of `Admin`, `devops`) **Method:** Read-only boto3 enumeration. Scripts in `scripts/`, raw output in `findings/*.json`. --- ## 1. Organization at a glance | Property | Value | |---|---| | Organization ID | `o-qfj0pvhhv7` | | Feature set | `ALL` | | Management account | `716468089330` — *Scrivas Admin* (`ScrivasAdmin@scrivas.com`) | | Member accounts | `547868853286` — *Lazka* (`lgarrido@gmail.com`) | | Organizational Units | **None** (flat — all accounts under Root) | | Policy types enabled | `SERVICE_CONTROL_POLICY` | Two-account, no-OU structure. All security tooling and all workloads currently live in the **management account**. --- ## 2. Assessment findings — the three targets ### 2a. Trusted access services (6 enabled) `cloudtrail` · `securityhub` · `guardduty` (+ `malware-protection.guardduty`) · `inspector2` · `notifications` Org-wide security services have trusted access enabled — the client has started centralizing security. ### 2b. Delegated administrators — **NONE** ⚠️ *(headline gap)* `list_delegated_administrators` returns empty. GuardDuty, Security Hub, and Inspector have org trusted-access enabled but **no member account is delegated to administer them**, so they are operated directly from the management account. AWS best practice is to delegate these to a dedicated security/audit account and keep the management account free of workloads and day-to-day operations. ### 2c. Trust policies - **Organization resource policy:** none set. - **IAM role trust relationships (management account, 44 roles):** almost all AWS service / service-linked roles. Two third-party **cross-account** trusts, both correctly gated with an `ExternalId`: - `IntruderReadOnlyRole` → trusts `123311413059` (**Intruder.io** — external vuln scanning) - `SecureframeRole-f983f1e89008` → trusts `728997465891` (**Secureframe** — SOC 2 / compliance automation) - One OIDC-federated EKS role (`AmazonEKS_EBS_CSI_DriverRole`, cluster in `us-east-2`). - **Lazka member account (6 roles):** only default service-linked roles + `OrganizationAccountAccessRole` (trusts the management account). **No GuardDuty/SecurityHub/Inspector roles present** → org-enabled security services are *not* deployed into the member account. --- ## 3. Governance signals for the proposal | # | Observation | Why it matters | |---|---|---| | 1 | **No delegated administrators** despite trusted access enabled | Security ops run from the mgmt account; violates AWS multi-account best practice | | 2 | **Workloads in the management account** — EKS (`scrivas-staging`, gpu/infra/apps node groups), EC2, RDS, VPC flow logs | Blast-radius & separation-of-duties risk; mgmt account should be minimal | | 3 | **Flat org, no OUs** | No policy boundaries (SCP targeting), hard to scale governance | | 4 | **Member account not monitored** — Lazka lacks security service-linked roles | Coverage gap; trusted access enabled but not delivered to members | | 5 | Third-party access via Intruder + Secureframe; Macie/Config/Access Analyzer present | Client is pursuing compliance — receptive to a landing-zone / governance engagement | --- ## 4. Recommended next discovery steps 1. Enumerate the full resource footprint per account (compute/storage/network/cost) to size the proposal. 2. Pull SCP contents attached to Root to understand existing guardrails. 3. Pull CloudTrail configuration & organization trail status. 4. Cost & Usage (Cost Explorer) for spend baseline and optimization signals. --- ## 5. How to reproduce ```bash # Org-level assessment (management account) python3 scripts/org_assessment.py --profile dasnuve-scrivas-louis-impersonation # Member-account extension (assumes OrganizationAccountAccessRole) python3 scripts/assess_member_account.py --account 547868853286 --name Lazka ``` Outputs: `findings/org_assessment_report.json`, `findings/member_lazka_547868853286.json`.