Privilege segmentation

1) Why segmentation is needed

Privilege segmentation is key to reducing "blast radius" errors and insider abuse. It allows you to accurately limit who can perform what actions on what data and where, while maintaining speed of operations and compliance with regulatory requirements.

• fewer incidents due to "superfluous rights";
• accelerating investigations: access is transparent and explicable;
• compliance with SoD/compliance, provable audit;
• safe experiments and quick releases without risk to the production core.

2) Principles

Zero Trust: each action is contextually checked; no "trusted zones."

Least Privilege: minimum rights issued for a minimum period (ideally JIT).
Context over Role: rights depend not only on the role, but also on the attributes (tenant, region, environment, risk).
Segregation of Duties (SoD): separate initiation, approval, execution and audit.
Policy-as-Code: policies in code with versioning, tests and reviews.

3) Access maturity model

1. RBAC (roles) - start - fixed roles (Support, Risk, Payments, Trading, Ops, SRE, Compliance).
2. ABAC (attributes): add attributes: tenant, region, jurisdiction, product, channel, environment (prod/stage/dev), time, risk class of operation, KRI signals.
3. PBAC (policy-based): centralized policies "who/what/where/when/why" + conditions (for example, "in sales - only by JIT and with a ticket").

4) Segmentation domains (axis by axis)

4. 1 Tenant/Client

Access and operations are limited to a specific brand/operator/affiliate.
Cross-tenant activities are prohibited except for strictly defined non-PII aggregations.

4. 2 Region/Jurisdiction

Policies take into account local licensing and KYC/AML rules.
Player data operations are limited by the geography of storage and processing.

4. 3 Environment (dev/stage/prod)

Prod is isolated: individual credits, networks, Bastion/PAM, "read-only by default."

Access to prod only JIT, with a ticket and change windows.

4. 4 Data class

PII/finance/gaming telemetry/technologists - different levels of access and masking.
Export PII - only through approved encrypted workflows and TTL.

4. 5 Criticality of operations

P1/P2/P3 classes: publication of coefficients, manual offsets, conclusions, PSP routing change - require dual control.
Low-risk operations can be auto-lifted by politics.

5) Privilege levels (tiers)

Viewer: read-only aggregates and masked data.
Operator - Perform runbook procedures without changing configurations.
Contributor-Modifies configurations in non-critical domains.
Approver: approval of applications and high-risk operations (not combined with execution - SoD).
Admin (JIT): short-term promotion for rare tasks under dual control and session recording.

6) SoD and incompatible roles

• Initiate conclusions ≠ approve ≠ finalize.
• Create a bonus campaign ≠ activate in the sale ≠ change limits.
• Develop the feature ≠ apply the release ≠ roll out to the prod.
• Request a PII upload ≠ approve ≠ decrypt.

For each pair - a formalized policy of prohibition and exclusion with a revision date.

7) JIT access and PAM

Elevation on request: specify the target/ticket/term; after expiration - auto-recall.
Dual control: P1/P2 actions - two apps from different functions.
Session control: recording critical sessions, anomaly alerts, copy paste prohibition when working with PII.
Break-glass: emergency access with hard limits and mandatory post-audit.

8) Service accounts and API scopes

Minimal scopes; Task/microservice partitioning short-lived tokens/certificates.
Rotation of secrets, prohibition of shared secrets; "god-scope" prohibition.
Limits on rate/quotas, idempotency keys, webhook signature (HMAC).

9) Infrastructure level segmentation

Networks: segment isolation (per-domain/per-tenant), default egress inhibit, mTLS.
Kubernetes/Cloud: namespaces/projects per-environment and domain, Gatekeeper/OPA to prohibit dangerous patterns.
DB/Caches: access broker (DB proxy/IAM), read-only by default, DDL barring in out-of-window sales.
Repositories: different keys/buckets per-class data with TTL and WORM policies for auditing.

10) Policies as Code (PaC)

Policies in repositories (Rego/YAML), PR review, auto tests (unit/e2e), diff audit.
Dynamic context: time of day, location, KRI level, risk scoring of the operation.
Explainability of allow/deny decision and reference to policy in audit.

11) Logs and audit

Completeness: who/what/where/when/why, pre/post values, ticket ID.
Non-changeable: centralized collection, WORM/immutable, record signing.
Connectivity: a chain of admin consoles → APIs → databases → external providers.
Audit SLA: rate of response to control/regulator requests.

12) Dashboards and Metrics (KPI/KRI)

Access KPI: share of JIT vs permanent rights, average privilege duration,% covered by SoD, application processing time, recertification coverage.
KRI of abuse: bursts of sensitive operations, mass unloading, atypical locations/hours, "zayavka→deystviye→otkat" sequences.
Exec-dashboard: track status of high-risk roles, break-glass events, trends.

13) Policy examples (sketches)

Prod-операции: `allow if role in {Operator, Admin} AND env=prod AND jit=true AND ticket!=null AND sod_ok AND time in ChangeWindow`.
Экспорт PII: `allow if data_class=PII AND purpose in ApprovedPurposes AND ttl<=7d AND encryption=ON AND approvers>=2`.
PSP-роутинг: `allow if action=UpdateRouting AND dual_control AND risk_assessment_passed AND rollback_plan_attached`.

14) Implementation Roadmap (8-12 weeks)

Ned. 1-2: Operation/Role/Data Inventory, SoD Matrix, Data Classification and Segmentation Domains.
Ned. 3-4: RBAC basis, role catalog, JIT for production consoles, start of PaC (OPA/Gatekeeper).
Ned. 5-6: ABAC: tenant/region/environment/data class attributes; separation of namespaces/projects.
Ned. 7-8: PAM (JIT-elevation, session recording, break-glass), DDL prohibition and database broker, PII export policies.
Ned. 9-10: PBAC for high-risk operations (conclusions, bonuses, PSP), dual control, KRI alerts.
Ned. 11-12: Quarterly recertification, 100% high-risk coverage of PaC operations, reporting and training.

15) Artifacts

Role Catalog: roles, minimum privileges, owners.
SoD Matrix: incompatible roles/operations, exceptions, override process.
Policy Pack: a set of PaC policies with tests and examples deny/allow.
Access Request Form: goal, term, object (tenant/region/environment), risk assessment, apps.
Sensitive Ops Register: list of P1/P2 actions, windows, dual control criteria.
Audit Playbook: collecting and providing logs, SLA response, roles.

16) Antipatterns

Permanent admin rights and general accounts.

Cross-tenant accesses "for convenience."

No isolation prod/stage/dev.
Policies on paper without enforce in code/consoles.
PII export by manual arrangement without encryption and TTL.
Lack of recertifications and hung rights.

17) The bottom line

Privilege segmentation is not just "right roles." This is multidimensional isolation (tenant, region, environment, data, criticality) + dynamic context (ABAC/PBAC) + processes (SoD, JIT, recertification) + technical coercion (PaC, PAM, networks/DB). This loop dramatically reduces the risk of error and abuse, accelerates safe change, and makes the platform resilient to scale and regulatory requirements.