Read-only cloud discovery of the Scrivas AWS Organization (o-qfj0pvhhv7) to inform a proposal. - scripts/: boto3 org assessment, member-account assessment, fast discovery - findings/: self-contained HTML dashboards, written report, summary JSON, and the rendered Prowler benchmark report - docs/full_discovery_plan.md: phased full-discovery plan - index.html: landing page linking all reports - Pipfile/.python-version: reproducible pipenv env (Python 3.12.11) Large raw scans (OCSF JSON, CSV, compliance/) are git-ignored.
4.1 KiB
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→ trusts123311413059(Intruder.io — external vuln scanning)SecureframeRole-f983f1e89008→ trusts728997465891(Secureframe — SOC 2 / compliance automation)- One OIDC-federated EKS role (
AmazonEKS_EBS_CSI_DriverRole, cluster inus-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
- Enumerate the full resource footprint per account (compute/storage/network/cost) to size the proposal.
- Pull SCP contents attached to Root to understand existing guardrails.
- Pull CloudTrail configuration & organization trail status.
- Cost & Usage (Cost Explorer) for spend baseline and optimization signals.
5. How to reproduce
# 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.