Account Infrastructure
You set up account infrastructure by separating workloads into isolated cloud accounts and mapping identity provider groups to specific roles. This structure keeps billing, network boundaries, and user permissions clean across your whole company. Most teams start with one shared account for every app and database. As the team grows, shared accounts create broad permissions that are hard to audit. One mistake in a shared role can expose production data to every user. Separating accounts early pre
Cross-Account Access Delegation + Cloud Infrastructure Entitlement Management (CIEM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up account infrastructure by separating workloads into isolated cloud accounts and mapping identity provider groups to specific roles. This structure keeps billing, network boundaries, and user permissions clean across your whole company. Most teams start with one shared account for every app and database. As the team grows, shared accounts create broad permissions that are hard to audit. One mistake in a shared role can expose production data to every user. Separating accounts early prevents these broad permission risks.
How to design your core account infrastructure
A strong setup starts with one central root account for billing and identity management. You link your identity provider to this central point first. Next, you create separate member accounts for production, staging, and local testing. Each member account holds its own networks, databases, and compute nodes. You never run production apps in the central billing account.
Admins then map team groups to roles inside each member account. A developer might get write roles in staging but read roles in production. Service accounts for apps also live inside the specific member account they serve. You apply global guardrails at the top level to block risky actions everywhere. For example, a top rule can stop anyone from making storage buckets public. This layout keeps blast radiuses small when a key leaks or fails.
Where native account boundaries fall short
Cloud account boundaries do a great job of isolating networks and cloud resources. They decide who can log in and which servers a user can see. Still, native roles stop working once a user opens a database or server session. If an engineer needs to fix a live bug, they assume a production role. That role grants full privileges for the whole time the keeps the session active.
Account rules cannot check individual queries or shell commands while they run in flight. A read role on a database still returns raw emails, phone numbers, and card numbers. An admin role lets a user drop a table without a second check. Also, cloud logs only show that a user assumed a role at a given time. They rarely show the exact SQL statements or terminal commands run inside the target.
Cross-Account Access Delegation + Cloud Infrastructure Entitlement Management (CIEM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Adding runtime controls to your setup
To close this gap, teams pair account boundaries with command and query checks. Instead of handing out long sessions, you review the exact action a user wants to run. High risk commands require a peer to click approve before they run. Data masking rules rewrite sensitive fields like national IDs and emails in query results. This approach keeps daily work fast while protecting production data at the command level.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How many cloud accounts should a small team start with?
Start with at least three separate accounts for management, staging, and production workloads. This base layout separates live customer data from daily test work right away.
Should we share database credentials across different accounts?
No, never share database keys or service roles across account boundaries. Each account should hold its own unique secrets and restrict them to local apps.
How do we handle emergency fixes in production accounts?
Avoid giving permanent write roles to engineers for production accounts. Instead, require peer approval for specific commands or grant short roles that expire fast.
Teams that document these role rules and review logs each month catch config drift early. Clear ownership for each role keeps live systems simple to run and easy to audit across the whole team.