Access Flows — Apono's Engine

In previous articles, we saw how the Inventory catalogs resources, how Scopes segment what each flow can reach, and how permissions work under the hood. Now we arrive at the piece that connects everything: the Access Flow.

The Access Flow is where you define who can request access, to what, with what approval, for how long, and with what permissions. It's Apono's engine — without it, the inventory is just a read-only catalog and Scopes are filters without purpose.

Anatomy of an Access Flow

Every Access Flow is composed of five fundamental elements:

Each of these elements is a security decision. Let's detail each one.

1. Who Requests (Requesters)

Defines which users or groups can request access through this flow. Configuration is done by pointing to Identity Provider (IdP) groups — such as Entra ID, Okta, or Google Workspace.

Best practices:

• Use IdP groups, not individual users. If an engineer leaves the team, simply removing them from the IdP group automatically revokes access to all associated flows.
• Granularize by role. Instead of a generic "Engineering" group, use groups like "Backend", "Data", "SRE". This allows creating different flows with appropriate permissions for each function.
• Avoid the "Everyone" group. A flow available to the entire organization is almost always excessive. Even in development environments, restrict by team.

When configuring requesters, Apono allows choosing between Apono's own groups or Identity Provider (IdP) groups. Whenever possible, prefer IdP groups — they already reflect the organizational structure, are managed by the identity team, and update automatically when someone joins or leaves a team. Apono's internal groups can be useful for specific cases, but creating a parallel group structure generates duplication and divergence risk.

2. What They Can Access (Scope + Permissions)

Here come the two elements that define the access surface:

• Scope — which resources are available for this flow (defined in the previous article)
• Permissions — what level of access will be granted on those resources

Permissions vary by resource type. Some examples:

Resource	Common Permissions	When to Use
EC2	SSM Session (shell)	Troubleshooting, debugging
RDS	SELECT only	Data queries, investigation
RDS	Full Access (CRUD)	Migrations, one-off fixes
S3	ReadOnly	Log download, analysis
S3	ReadWrite	File upload, corrections
IAM	ViewOnly	Auditing, investigation

The Scope + Permissions combination is what determines the actual blast radius of the flow. A broad Scope with restricted permissions (e.g., all dev RDS, SELECT only) can be acceptable. A narrow Scope with broad permissions (e.g., one specific RDS, Full Access) can also work. The danger is a broad Scope with broad permissions.

3. How It's Approved (Approval Policy)

The approval policy defines what happens when someone requests access through this flow. Apono offers different models:

Auto-approval

Access is granted automatically, without human intervention. The requester clicks, waits a few seconds, and has access.

When to use:

• Development and sandbox environments
• Low-risk resources with restricted permissions
• Scenarios where speed matters more than individual control

When to avoid:

• Any production resource
• Resources with sensitive data, regardless of environment

Manager or owner approval

One or more people need to approve the request before access is granted. The approver receives a notification (email, Slack, or Teams) with the request details.

When to use:

• Staging and production environments
• Resources with internal or low-criticality data in production

Best practices for approvers:

• When there's a single approver, it's usually the team's direct manager — the person who knows the work context and can assess whether the request makes sense.
• Define more than one approver to avoid bottlenecks when the manager is unavailable (vacation, leave, different time zone). A backup prevents the team from being blocked waiting for approval.
• Choose approvers with technical context about the resources — a product manager approving access to a database is a fragile control
• For critical resources, consider including someone from the security or compliance/GRC team as an additional approver

Multiple approvers for critical resources

For high-criticality resources, the strategy is to configure multiple approvers on the same flow — for example, the team manager, the DBA, and someone from compliance. Apono notifies everyone, and any of them can approve or deny.

When to use:

• Access to PII data in production
• Changes to IAM Roles or security policies
• Regulated environments (PCI-DSS, HIPAA, SOC 2)
• Any scenario where the GRC team requires formal traceability

The idea is that the more critical the resource, the more people should have visibility into the request. Even if only one approver is needed to grant access, the fact that multiple people are notified increases the chance of someone questioning an improper request.

Note: currently, when a flow has multiple approvers, they all receive the approval notification at the same time. In practice, this creates unnecessary broadcast — especially when the first approver resolves the request in seconds and the others receive a notification that's no longer useful. Ideally, there would be an escalation logic: notify the primary approver first and, if they don't respond within a configurable timeframe, escalate to the others. This would reduce noise and prevent notification fatigue that, over time, causes approvers to ignore alerts.

How the Approver Structure Works

Apono allows configuring approval in layers with flexible logic. Each flow can have multiple approver groups, and each group can contain one or more people (or an entire IdP group). The approval logic works at two levels:

Within each approver group:

• Any one (OR) — one person from the group approving is enough for the group to be considered approved. Useful for groups where any member has equivalent authority (e.g., any SRE on the team).
• All of them (AND) — all people in the group need to approve. Useful when each member brings a different perspective that needs to be considered (e.g., the DBA and the application owner).

Between approver groups:

The same logic applies between groups. If the flow has Approver 1 (manager) and Approver 2 (security):

• Any one (OR) — only one group needs to approve
• All of them (AND) — both groups need to approve

Practical example:

Flow: Production RDS PII Access

Approver 1: Data Team (any one)
  - Maria (DBA)
  - João (DBA)

Approver 2: Security (any one)
  - Ana (Security Engineer)
  - Carlos (Security Lead)

Logic between groups: All of them (AND)

In this example, any DBA can approve for group 1, and any security person can approve for group 2 — but both groups need to approve for access to be granted. This combines agility (doesn't depend on a specific person) with rigor (two different areas validate).

4. For How Long (Duration)

Duration defines how long the access remains active after approval. When the time expires, Apono automatically revokes the permissions — without depending on manual action.

Although Apono is a Just-in-Time Access tool, you need to be pragmatic about duration. In an ideal world, every access would be as short as possible. In practice, if the manager needs to approve the same access 5 times a day for the same person on the same resources, the control becomes bureaucracy — and the approver starts approving automatically, which defeats the tool's purpose.

The rule is simple: duration should be proportional to the resource's risk. Resources used daily in low-risk environments should have longer durations to avoid friction. Critical production resources should have short durations, even if that generates more requests — because in those cases, each request deserves to be evaluated.

Scenario	Suggested Duration	Justification
Dev / Sandbox (daily use)	1-7 days	The engineer uses the same resources all week. Weekly durations with extension capability avoid repetitive requests with no security gain
Staging (frequent use)	4-8 hours	Intermediate environment — less sensitive than production, but access doesn't need to be permanent
Production troubleshooting	2-6 hours	Critical environment, one-off access. Short duration is justified by the risk
PII data query	30 min - 1 hour	Sensitive data requires minimum window, regardless of environment
Deploy or migration	2-4 hours	Planned operation with defined start and end
Break-glass (incident)	30 min - 1 hour	Emergency — the minimum to contain and diagnose

Excessive friction is the enemy of security. When the process is too heavy for routine tasks, people find shortcuts — they ask colleagues for credentials, keep sessions open, or push for permanent access. A flow with generous duration in dev and auto-approval is more secure than a restrictive flow that nobody wants to use.

For critical production resources and sensitive data, short durations are non-negotiable. In those cases, the cost of friction is worth it: each request generates an audit record, and the approver has a real responsibility to evaluate whether that access makes sense.

The engineer can also manually terminate access before the time expires if they finish the task early. This is a best practice that the security team can encourage — and it reinforces the least privilege culture without relying solely on automatic timers.

The values above are suggestions, not absolute rules. The ideal duration depends heavily on where the company is in its journey. Organizations with mature security teams and dedicated approvers can work with shorter windows. But smaller companies or those in the Apono adoption phase may need much longer durations — up to 1 month in some cases — simply because there aren't enough people to evaluate requests frequently. If nobody approves, people are blocked and can't work — and that's worse than access with a longer duration.

The right balance is found over time. Start with more generous durations, monitor usage, and adjust as the approval process maturity increases.

5. Where to Request (Portal / Slack / Teams)

The Access Flow is accessible through all channels configured in Apono:

• Web Portal — the Apono dashboard, complete interface with all details
• Slack — via ChatOps, request and approval directly in chat
• Microsoft Teams — same experience as Slack for organizations that use Teams

Regardless of the channel, the flow is the same. The difference is where the requester interacts — what matters is reducing friction so the developer uses Apono instead of looking for shortcuts.

Structuring Flows in Practice

The flow structure should reflect the organization's reality. There's no single model, but there are patterns that work well.

Pattern 1: One Flow per Team + Environment + Resource Combination

The most granular and secure model. Each flow has a clear purpose:

Flow	Requesters	Scope	Approval	Duration	Permissions
Backend → EC2 Dev	Backend	ec2-dev	Auto	8h	SSM Session
Backend → EC2 Prod	Backend	ec2-prod	Manager + SRE	2h	SSM Session
Data → RDS Dev	Data	rds-dev	Auto	4h	Full Access
Data → RDS Prod (PII)	Data	rds-prod-pii	Manager + DBA + Compliance	1h	SELECT
SRE → EC2 Prod	SRE	ec2-prod	Manager	4h	SSM Session
Data → S3 Prod (sensitive)	Data	s3-prod-sensitive	Manager + Security	1h	ReadOnly

Advantage: Total control over each combination. Each flow is individually auditable.

Disadvantage: Number of flows grows with the combination of teams × environments × resources. In large organizations, it can reach dozens of flows.

Pattern 2: Flows Grouped by Use Case

Groups flows by business scenario instead of individual resource:

Flow	Requesters	Included Scopes	Approval	Duration
Dev Troubleshooting	Backend + Data	ec2-dev, rds-dev, s3-dev	Auto	4h
Prod Troubleshooting	Backend + SRE	ec2-prod, rds-prod-internal	Manager + SRE	2h
Data Analysis	Data	rds-prod-pii, s3-prod-sensitive	Manager + Compliance	1h
Audit	Security + Compliance	All scopes ReadOnly	Auto	2h

Advantage: Fewer flows to manage. Reflects how teams actually work.

Disadvantage: Less granularity. A "Prod Troubleshooting" flow may include resources that aren't always needed for the specific task.

Which Pattern to Choose?

In practice, most organizations use a combination of both:

• Pattern 1 for critical resources (production, PII, IAM) — granular control where it matters
• Pattern 2 for low-risk environments (dev, sandbox) — simplicity where risk is lower

The important thing is that the structure is reviewed periodically. Teams change, resources are created and decommissioned, and the organization may need new flows or adjustments to existing ones.

Break-Glass: Emergency Access

Not all access follows the standard flow. In critical incidents — like a production outage at 3 AM — waiting for an approval chain isn't viable. For these scenarios, Apono allows configuring break-glass flows.

A break-glass flow has specific characteristics:

• Auto-approval or minimal approval — access is granted immediately or with a single approver
• Short duration — 30 minutes to 1 hour, the minimum to contain the incident
• Restricted scope — only the resources needed for diagnosis and mitigation
• Broad notification — the security team, managers, and compliance are immediately notified that a break-glass access was used
• Enhanced auditing — every action during the access is recorded for post-incident review

Break-glass is not a shortcut to avoid the approval process. It's a formal, audited, and monitored flow. The difference is that verification happens after the access, not before. Any break-glass use should trigger a documented post-incident review.

Request Justification

An important Access Flow feature is the ability to require the requester to provide a justification when requesting access. This justification is recorded in the audit trail and helps the approver make a more informed decision.

Best practices:

• Require justification on all production flows. Even if the approver doesn't read them all, the record exists for auditing.
• Link to tickets or incidents. Encourage requesters to include the ticket number (Jira, ServiceNow, PagerDuty) in the justification. This creates traceability between access and business reason.
• In auto-approval dev flows, justification can be optional to reduce friction.

Common Mistakes

1. One flow for everything

Creating a single generic Access Flow that serves all teams and all resources. In practice, this is equivalent to having no segmentation — and all security depends exclusively on the approver.

2. Same approver for everything

Using the same manager as approver for all flows. Besides creating a bottleneck (if they're unavailable, nobody gets approved), the approver suffers from approval fatigue — approving everything without evaluating because the volume is too high.

3. Not using Scopes

Creating flows pointing directly to the integration without a Scope. We already detailed this problem in the Scopes article — without a Scope, the requester sees all resources and the blast radius of an approval is the entire integration.

4. Ignoring break-glass

Not having an emergency flow means that during incidents, people look for shortcuts — like using shared credentials, requesting permanent access from an administrator, or bypassing Apono entirely. A formal break-glass flow is more secure than improvisation.

5. Not reviewing flows periodically

Flows created months ago may be outdated: teams changed, resources were decommissioned, approvers left the company. A quarterly flow review is the minimum recommended — and the GRC or compliance team should be involved in this review.

Lifecycle of a Request

To wrap up, let's follow the complete lifecycle of an access request through an Access Flow:

Every step in this lifecycle generates an audit record in Apono — who requested, when, why, who approved, how long it lasted, and when it was revoked. This audit trail is fundamental for compliance and security investigations.