Аутентификация и authority boundary

• Tenant и roles определяются доверенной server-side конфигурацией.
• Конфликтующее tenant_id assertion отклоняется, а не меняет scope.
• Opaque subject/reference не доказывает entitlement сам по себе.
• Production требует approved identity lifecycle, rotation, revocation, access review и audit.

A22.1 фиксирует target contract, но не включает Production identity runtime. Действующий API по-прежнему использует digest-only Local bearer и server-derived tenant/principal/organization/roles; production startup остаётся заблокированным.

CertaRail не становится IdP, password authority или universal token issuer. Customer-managed enterprise IdP/authorization server подтверждает tenant humans и partner clients; отдельный workforce authority — CertaRail operators; environment-scoped SPIFFE CA/STS — workloads; isolated emergency realm — только break-glass.

• Каждый issuer регистрируется exact HTTPS value и привязывается к одному tenant/environment boundary; request-time discovery и dynamic client registration запрещены.
• Каждый route plane принимает access token только от своего registered authority и только с exact CertaRail audience; ID token, assertion либо token другого plane не являются API credential.
• CertaRail verifier после cryptographic validation заново разрешает current membership, entitlement version и resource policy. Upstream groups/roles не становятся CertaRail authority напрямую.
• Metadata/JWKS rotation допускает reviewed current/next overlap, pinning разрешённых algorithms и bounded cache; неизвестный kid или stale metadata fail closed.
• Vendor выбирается на activation по этому conformance profile. Имя продукта не подменяет FAPI/OIDC, operational ownership, residency, HA, recovery и exit evidence.

• Shared, generic, orphaned и non-expiring human accounts запрещены; email, display name и mutable group label не являются identity key.
• Phishing-resistant MFA обязателен для Production humans; SMS/voice/manual OTP не являются единственным доступным privileged method.
• Browser получает только Secure, HttpOnly, host-only BFF session cookie; access/refresh tokens не попадают в JavaScript, URL, localStorage, analytics или support evidence.

• One workload/client identity cannot be shared across services, tenants or canonical environments.
• Human bearer, browser cookie and static client_secret are prohibited for service execution.
• Ownership, contact, environment, audiences, scopes, key/certificate expiry and last use are mandatory inventory fields.

• Prohibited at launch: implicit, hybrid, password, authorization_code_without_pkce, shared_client_secret, unrestricted_token_exchange, device_authorization_at_launch.
• Authorization response validates state, nonce and issuer; redirect URI uses exact match. Tokens are never accepted from query or fragment.
• Sender constraint is a selected deployment profile, never an opportunistic fallback: mTLS for confidential/service clients; a separately approved DPoP profile may be used only where mTLS is impractical and its nonce/replay storage is proven.

• Validate exact issuer, audience, authorized party/client, signature algorithm and key ID, expiry, not-before, issued-at, sender constraint, token ID, entitlement version and environment. Unknown issuer/key/scope or stale authorization fails closed.
• Asymmetric keys are HSM/KMS backed, have named owners and rotate on an approved schedule with tested current/next overlap; private material never enters source, image, environment dump, URL, log or evidence payload.
• Human disable, service disable, key compromise and privileged-grant withdrawal reach the PDP immediately and every resource server within five minutes; privileged operations always consult live entitlement state.

Scope является client/token ceiling, а не окончательным разрешением. Wildcard scope отсутствует; server authorizes только пересечение registration, token, current role и resource policy.

RBAC задаёт стабильные job functions; ABAC/PDP сужает их по tenant, organization, environment, resource owner, mandate, amount, provider connection, data class и maker-checker history.

• Decision = intersection of registered client scope, token scope, current role grant and resource policy; any missing or unknown input is DENY.
• Maker and approver permissions are not combined in one business role. A principal cannot approve a command, role grant, replay or activation it prepared.
• Service identities receive direct exact scopes and resource bindings; importing human roles into a workload token is prohibited.

Privileged capability is absent by default and issued just in time for one ticket and operation family. Every operation requires a fresh phishing-resistant step-up and a different checker; role possession alone is insufficient.

• Self-approval, standing global admin, hidden impersonation, shared break-glass account and elevation without expiry are prohibited.
• The immutable receipt binds tenant/environment, subject, actor, maker, checker, scopes, resource, reason, ticket, before/after digest, issued/expiry time and outcome.
• Expiry removes authority automatically. Cleanup/revocation evidence is part of completion, not a separate optional task.

• Review population is generated from authoritative memberships, client registrations, JIT eligibility, keys/certificates and last-use data; spreadsheets without a signed snapshot digest are not authoritative.
• Every decision is CERTIFY, REVOKE or TIME_BOUND_EXCEPTION with owner and due date. Missing reviewer or overdue exception fails the affected privileged activation closed.
• Review completion means removals propagated to sessions/tokens/PDP and were observed, not merely that a ticket was closed.

A22.2 фиксирует target Production contract. Текущий Compose остаётся loopback-only Local runtime: Nginx слушает HTTP, PostgreSQL/Kafka/Redis используют local-only development credentials and/or plaintext transports, а production KMS, Vault, private endpoints и emergency control plane не подключены.

TLS 1.3 является default minimum для всех Production planes. TLS 1.2 допускается только как отдельное time-bound compatibility exception для одного named interface; downgrade fallback отсутствует.

• Запрещены SSL_2_0, SSL_3_0, TLS_1_0, TLS_1_1, NULL/RC4/CBC/static-RSA suites, compression, insecure renegotiation и silent downgrade.
• TLS 1.2 exception разрешает только TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 и имеет owner, expiry, migration date и negative downgrade evidence.
• 0-RTT выключен по умолчанию и запрещён для create/approve/confirm/replay/rotate/revoke/delete/export и любых команд с side effect.
• Certificate inventory, automated renewal, expiry alerting, revocation and old/new validation являются частью acceptance evidence.

Public reachability заканчивается на approved HTTPS/mTLS gateways. Data, secret, cryptographic, administration и observability control planes не имеют public address; каждый flow задаётся source identity, destination identity, port и purpose.

• Ingress default: DENY; egress default: DENY. Unknown identity, destination, port, DNS answer or purpose is denied.
• Private connectivity does not authorize a principal: mTLS/workload identity, OAuth audience, current PDP policy and application tenant binding remain mandatory.
• IDENTITY_AWARE_EGRESS_PROXY_OR_CONTROLLED_NAT; EXACT_SCHEME_HOST_PORT_AND_PROVIDER_PROFILE_ALLOWLIST; redirects are denied and DNS/IP rebinding defences are required.
• Management and emergency planes are isolated from public ingress; peering, transitive routing and cross-environment trust are denied by default.

CORS отключён по умолчанию. Browser-enabled routes use an exact server-owned HTTPS origin allowlist per surface and environment; partner/internal service APIs do not emit CORS headers.

• Parse and canonicalize the Origin header, compare it to an exact environment-scoped allowlist and emit the matched canonical origin only.
• Emit Vary: Origin whenever a response can vary by Origin; preflight cache policy must vary by origin, method and requested headers.
• Reject malformed, multiple, opaque/null, HTTP or unregistered origins before handler execution.
• Allow-Credentials is emitted only for an approved cookie-based BFF/hosted profile and never with a wildcard origin.
• CORS does not replace session authentication, authorization, CSRF token plus Fetch Metadata validation, CSP frame-ancestors or postMessage origin checks.

Каждый canonical environment получает отдельную key hierarchy. Private keys and KEKs are non-exportable; workloads invoke only a purpose-bound cryptographic operation over a private endpoint.

• Envelope AAD binds tenant_id + environment + purpose + object_type + object_id + schema_version + key_version. Plaintext data keys are never persisted.
• Key-policy administrator, crypto user, custodian and auditor are distinct; no principal may create policy, use a key and approve destructive lifecycle changes alone.
• Disable/delete is maker-checker, impact-tested and delayed. Legal hold, backup/recovery and decrypt dependencies block destruction.
• KMS logs record metadata and result only; plaintext, private key, data key, bearer and restricted payload are prohibited.

A bank-approved secret manager is the Production source of truth. Workloads authenticate with environment-scoped identity, receive the narrowest dynamic lease and never receive a reusable root credential.

• Forbidden locations: SOURCE_CONTROL, IMAGE_LAYER, BROWSER_STORAGE, URL, CI_LOG, APPLICATION_LOG, EVIDENCE_PAYLOAD, ANALYTICS, TICKET_OR_CHAT, UNENCRYPTED_ENV_FILE.
• One namespace or mount per canonical environment
• Separate application, platform, integration and emergency policy domains
• Tenant-specific path and policy where a secret grants tenant authority
• No wildcard read/list capability across tenants or environments
• Long-lived static secret is an approved exception with owner, expiry and migration plan; dynamic database/cloud credentials are the default.

Rotation is an observable state machine, not an overwrite. Current/next material is prepared and verified before cutover; old material is negatively tested before the operation is complete.

• Suspected compromise starts containment/rotation within 15 minutes; the affected credential is revoked sooner where technically possible.
• Known or suspected disclosure, unauthorized use or unexplained authentication
• Owner, custodian, consumer identity, tenant or environment boundary change
• Algorithm, provider, trust anchor or policy change
• Failed integrity check, inventory mismatch, expired attestation or overdue scheduled rotation
• Break-glass use affecting the credential or its trust path

1. 01

   PREPARED

   Persist the transition, actor, approvals, material metadata fingerprint, consumer acknowledgements and outcome before advancing.

2. 02

   DISTRIBUTED

   Persist the transition, actor, approvals, material metadata fingerprint, consumer acknowledgements and outcome before advancing.

3. 03

   DUAL_READ_VERIFY

   Persist the transition, actor, approvals, material metadata fingerprint, consumer acknowledgements and outcome before advancing.

4. 04

   PRIMARY

   Persist the transition, actor, approvals, material metadata fingerprint, consumer acknowledgements and outcome before advancing.

5. 05

   RETIRED

   Persist the transition, actor, approvals, material metadata fingerprint, consumer acknowledgements and outcome before advancing.

6. 06

   REVOKED

   Old material is unusable, negative use is observed, dependants are reconciled and evidence is closed.

Ownership means accountability for policy and lifecycle; custody means control of private material. CertaRail does not become custodian of tenant asset private keys and does not receive KMS/Vault root or export authority.

Revocation is complete only when the authoritative disable decision has propagated and a denied use is observed. Ticket closure alone is not evidence of revocation.

• Compromise revocation bypasses planned overlap: block first, then distribute replacement and reconcile ambiguous operations.
• Short lifetime limits residual risk but does not replace disable, PDP policy update, session termination, provider-side revoke or key-ID rejection.
• Every revocation links replacement material by metadata reference only; no secret or recoverable private key appears in evidence.

Break-glass reuses the A22.1 BREAK_GLASS_SESSION contract: two distinct hardware-bound custodians activate one incident-scoped 15-minute session over an isolated private emergency path.

• Incident declaration, reason, impact and alternative-path failure
• Both custodian identities, hardware-auth events and issued/expiry time
• Complete approved command/session record and accessed resource metadata
• Automatic expiry, affected-credential rotation and next-business-day independent review

DEMO, LOCAL, HOSTED_SANDBOX, PROVIDER_SANDBOX and PRODUCTION share source artifacts, not trust or secret material. Production is isolated across account/project, network, PKI, KMS, Vault, identity clients, data planes, telemetry and recovery.

• Cross-environment trust: DENY_BY_DEFAULT; artifact promotion: IMMUTABLE_DIGEST_AND_PROVENANCE.
• Prohibited: each environment re-binds identity, endpoints, keys, secrets and policies from its own approved control plane.
• Only explicitly approved one-way metadata/aggregate export; no credential, restricted payload or control-plane trust is inherited.
• No shared IdP client, audience, PKI trust domain, KMS alias/root, Vault namespace, database, topic, cache prefix, log sink or backup set crosses into Production.

A22.3 публикует testable control contract и точные repository evidence locators. Он не превращает Local/sandbox tests, generated JSON или checklist в Production acceptance, restore drill либо independent review.

OWASP_API_SECURITY_TOP_10_2023_PLUS_CERTARAIL_ABUSE_CASES. Scope: Every public, partner, internal, administration, webhook, worker, export and recovery API in all canonical environments.

• Assets: Tenant identity, organization binding, scopes, roles and approval state; Authoritative policy, decision, idempotency, ledger, movement and provider state; Credentials, signing/encryption key references and revocation state; Audit, evidence, outbox/inbox, webhook and recovery artifacts; Availability, per-tenant fairness and production activation authority.
• Trust boundaries: Browser or partner client to approved edge/BFF/API gateway; Gateway to control-plane API and authorization decision point; Application runtime to PostgreSQL, cache, Kafka, Temporal and object storage; Webhook/provider ingress and controlled outbound delivery/adapter egress; Human administration to private JIT management and break-glass planes; Production to backup, DR, restore and independent-review environments.
• Adversaries: Unauthenticated internet client; Authenticated user or workload exceeding its tenant/resource authority; Compromised tenant administrator, support principal or service credential; Malicious or compromised provider/webhook endpoint; Insider with partial database, log, KMS, Vault or deployment access; Automated abuse causing cost, queue, parser, connection or storage exhaustion.
• Every reachable operation must inherit at least one risk row, control owner and positive/negative test before activation.

Tests follow the public seam: identity validation, route/function policy, object/relationship predicate and response filtering. A mocked permit decision without the protected handler/resource assertion is insufficient.

• Generate the matrix from canonical operation security plus A22.1 scope/RBAC/resource policies; fail if a reachable protected operation has no positive and negative case.
• Assert the downstream/domain spy count is zero on deny and compare durable state/effects before and after each negative case.
• Use missing, malformed, expired, revoked, wrong-issuer/audience, wrong principal type, missing scope, wrong tenant/object and protected-property variants.
• Authorization evidence records exact candidate digest, IdP/PDP/policy versions, test fixture IDs, result and audit-event digest without credentials.

Create tenant A and tenant B with distinct organizations, principals, resources, idempotency keys, cache entries, topic identities, jobs, audit records and backup samples.

• PostgreSQL runtime role owns tables: false; BYPASSRLS: false; FORCE RLS required: true.
• SET LOCAL certarail.tenant_id inside every transaction; missing or malformed context fails closed.
• Repeat the matrix for list, detail, create, mutate, delete/revoke, batch, search, export, retry/replay and recovery paths; success on one route cannot stand in for another.
• A 404 existence-hiding response must still prove zero tenant-B read/effect in service/database/audit evidence.

Limits are versioned policy with owner, measured source, metric, overload outcome and test. Edge, application and dependency budgets must compose; a high outer limit cannot silently bypass a lower inner guarantee.

• Run boundary and limit-plus-one tests, then slowloris/concurrency/storm and sustained soak tests against the exact candidate.
• Measure per-tenant fairness, memory/CPU/goroutines, connection pools, statement/lock time, queue age/bytes, retry amplification and provider cost units.
• Production limits require capacity evidence and rollback/override ownership; Local defaults are implementation facts, not Production sizing.

Schema certarail.security-audit-event.v1; production sink EXTERNAL_APPEND_ONLY_WORM_OR_EQUIVALENT; legally material command on audit failure: FAIL_CLOSED.

• Authentication success/failure and credential lifecycle
• Authorization permit/deny including policy/reason and protected operation
• Privileged request, approval, execution, expiry and break-glass review
• Tenant/security configuration and production activation changes
• Secret/key create, use metadata, rotate, revoke, disable and recovery
• Evidence/export access, deletion request, legal hold and retention action
• Rate/quota/backpressure decisions and security-control degradation
• Backup, restore, failover, incident and independent-review evidence changes

Each scenario has an inject/detect/contain/recover sequence, executable assertions and immutable evidence. Tabletop validates decisions and ownership; a technical exercise validates the actual control path. Activation requires both where applicable.

• Record commander, observers, start/end, candidate digest, canary IDs, decision log, control timings, gaps, follow-up owners and retest links.
• No scenario authorizes real money/asset movement, provider/regulator effects, destructive Production testing or unapproved secret exposure.
• A detection-only exercise does not close containment/recovery assertions; a tabletop does not replace the named technical drill.

Backup is accepted only after an observed restore into an isolated production-like environment, verification of declared invariants and measured comparison to an approved BIA/service SLO.

• External egress, Kafka/webhook/provider publication and production credentials are prohibited in the restore environment.
• Sample tenant A and tenant B independently; validate that recovered exports, keys/policies, audit and evidence remain tenant-bound.
• Do not invent RPO/RTO in this contract: approved BIA/SLO owns objectives, while each exercise records actual measured values and variance.
• Destroy the isolated exercise environment only through the approved evidence-preserving cleanup process.

Status: NOT_PERFORMED; reviewer: NOT_SELECTED. Reviewer and final approver must not be the control author, production administrator, key custodian or finding owner; conflicts are disclosed.

• Authors may approve: false.
• Production testing default: PROHIBITED_UNLESS_EXPLICITLY_APPROVED_IN_RULES_OF_ENGAGEMENT; destructive: PROHIBITED; real effects: PROHIBITED.
• Finding severity combines technical exploitability with CertaRail tenant, regulatory, financial/evidence and availability impact; the report preserves reproducible safe evidence.

Repository checks below are exact locators, not stored pass claims. Run outputs must record command, timestamp, toolchain, immutable source digest, environment and result; production evidence stays separate.

• PRODUCTION_LIKE_AUTHORIZATION_AND_TENANT_MATRIX · OPEN · Immutable-candidate execution with production IdP/PDP, non-owner RLS role, cache, Kafka, workers, exports and support access.
• MEASURED_RESOURCE_ABUSE_AND_CAPACITY · OPEN · Signed load profile, limits, fairness/SLO results, cost budgets, edge and dependency saturation evidence.
• EXTERNAL_AUDIT_SINK_AND_INCIDENT_DRILLS · OPEN · WORM-equivalent/SIEM manifests, secret canaries, gap alerts and completed technical incident exercises.
• OBSERVED_RESTORE_AND_FAILOVER · OPEN · Isolated production-like restore/failover evidence meeting approved BIA/SLO objectives and invariants.
• INDEPENDENT_REVIEW_AND_RETEST · OPEN · Independent signed scope, findings, remediation/retest and residual-risk recommendation bound to candidate digests.