Zero Trust, IAM and security operations

The rest of this folder covers application vulnerabilities. This one covers the architecture and the operations around them — the vocabulary that appears in security-adjacent job ads and that a backend engineer is expected to hold an opinion on without being a security engineer.

Zero Trust, stated properly

The perimeter model assumed a trusted inside: get past the firewall and you can reach anything. It fails because attackers get inside, and because “inside” no longer means anything when services run across clouds and people work from cafés.

Zero Trust replaces location-based trust with per-request verification.

The three principles

1. Verify explicitly. Every request is authenticated and authorised on identity, device and context — not on source IP.
2. Least privilege. Scoped, time-bound access. Just-in-time elevation rather than standing admin.
3. Assume breach. Segment so a compromise is contained, and instrument so it is visible.

The practical version for a backend engineer: service-to-service calls authenticate. An internal API that trusts anything inside the VPC is the perimeter model wearing a cloud costume. mTLS or signed tokens between services, and authorisation checks in the service rather than at the gateway alone.

# Every hop carries and verifies identity - no implicit internal trust.
async def call_billing(user_ctx: UserContext) -> Invoice:
    token = await sts.issue(
        audience="billing",              # scoped to one service
        subject=service_identity(),      # who is calling
        act_as=user_ctx.subject,         # on whose behalf
        ttl=timedelta(minutes=5),        # short-lived
    )
    return await client.get("/invoice", headers={"Authorization": f"Bearer {token}"})

IAM concepts that get probed

Authentication is who; authorisation is what. Separate them in the answer and in the code.

• Roles over users. Grant to a role, assume the role. A human or a workload gets credentials by assuming, so revocation is one change and credentials are short-lived.
• Workload identity over static keys. A pod, a Lambda or a CI job gets a federated identity from its runtime; a long-lived access key in an environment variable is the credential that leaks.
• Least privilege is a process, not a state. Start denied, add on evidence of need, and review. Access reviews exist because grants accumulate.
• Separation of duties. The person who writes the deploy is not the only person who can approve it.

RBAC versus ABAC and the policy mechanics are in Authorization: RBAC, ABAC and where to enforce them; federation and SSO in SSO — Deep Topical Notes.

SOC, SIEM and what they consume

A SOC (security operations centre) is the team and process that watches for and responds to incidents. A SIEM is the tooling: aggregate logs from everywhere, correlate, alert. SOAR adds automated response playbooks.

What this means for you is that your application’s logs are an input to someone’s detection, which changes what belongs in them.

• Emit security-relevant events explicitly — authentication success and failure, authorisation denials, privilege changes, data exports, admin actions. A denial that is logged at debug is invisible.

# A SIEM correlates on fields. Prose in a message string is not
# correlatable, and a denial at debug level is not collected at all.
log.warning(
    "authz.denied",
    actor=ctx.subject,             # who
    actor_type="user",             # or "service"
    resource=f"invoice:{invoice_id}",
    action="read",
    outcome="denied",
    reason="tenant_mismatch",
    source_ip=ctx.ip,
    trace_id=ctx.trace_id,         # joins to the request trace
)

• Structure them with a stable schema, actor, resource, action and outcome. A SIEM correlates on fields, not on prose. See Structured logging in Python.
• Never log secrets or full PII. Logs go to a system many people read and are retained for a long time.
• Make logs tamper-evident. Append-only, shipped off the host promptly, so an attacker who gets the host cannot rewrite the record.
• Retention is a compliance input. SOC 2 and ISO 27001 both ask how long and how protected — see SOC 2, ISO 27001 and GRC for engineers.

Threat modelling, briefly

The lightweight version that fits in a design review: for each component, ask what an attacker would want, how they would reach it, and what limits the damage. STRIDE is the usual checklist — spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.

Doing it at design time is much cheaper than a pentest finding, and being able to say “we threat-modelled this and here is what we accepted” is a strong answer in any security-adjacent interview. GRC — governance, risk and compliance — is the organisational wrapper: policies, the risk register, and evidence that controls operate.

Where it breaks in production

• Zero Trust bought as a product. It is an architecture. A vendor’s gateway in front of a service that still trusts the VPC changes nothing.
• Standing admin access. The most common finding. Nobody needs permanent production write; make it request-and-expire.
• Alert fatigue. A SIEM tuned to alert on everything trains people to ignore it. Alert on symptoms with an owner, as in SLO, SLI, SLA, and Error Budgets.
• Service accounts with no owner. They accumulate, outlive their purpose and keep their permissions.
• Break-glass with no audit. Emergency access is necessary; unlogged emergency access is a backdoor.

Related

• SOC 2, ISO 27001 and GRC for engineers - the frameworks that audit all of this.
• Secrets management and rate limiting - secret handling and abuse limits.
• Authorization: RBAC, ABAC and where to enforce them
  • the authorisation model.
• Structured logging in Python
  • the log schema a SIEM needs.
• Data poisoning, backdoors and model extraction
  • the ML-specific threat surface.