Data access control

1) Why is it iGaming

Risk and regulation: PII/finance, cross-border, RG/AML requirements.

Speed ​ ​ and trust: safe self-service analytics and ML without manual "distributions."

Audit and responsibility: "who saw what and why," the provability of the principle of minimum rights.

2) Basic principles

1. Least Privilege - just what you need and for the right time.
2. Segregation of Duties (SoD) - developer ≠ approves access; analyst ≠ data owner.
3. Just-in-Time (JIT) - temporary, automatically revoked rights.
4. Defense in Depth - multi-level protection: network → service → table → column → row → cell.
5. Policy-as-Code - accesses and masks in code/repository, review via PR.
6. Provenance-aware - solutions rely on catalog, lineage, classification and contracts.

3) Data classification

Classes: Public/Internal/Confidential/Restricted (PII/Finance).
Tags in the diagrams and catalog: 'pii', 'financial', 'tokenized', 'masking', 'rle' (row-level), 'cle' (column-level), 'geo = EU/TR/...', 'tenant'.

• Restricted: tokens/masks everywhere; detokenization only in the "clean zone" upon request.
• Confidential: access with default masks; removing masks - through justification and JIT.
• Internal/Public: by domain roles, no PII.

4) Authorization models

RBAC (role-base.) : quick start, role catalogs ("Marketing-Analyst," "Risk-Ops").
ABAC (attribute-basis.) : country, brand, environment (prod/stage), project, processing purpose, time, risk level.

ReBAC (by relationship): "set owner," "domain steward," "reviewer."

Hybrid: RBAC as framework, ABAC refines boundaries.

5) Granularity of access

Network/ingress: mTLS, allow-list, private links.
Service/cluster: IAM roles, service account with a minimum of privileges.
Repositories: catalogs/diagrams/tables (GRANT), Row-Level Security (RLS), Column-Level Security (CLS).
Masking/tokenization: dynamic masks in SQL/BI; tokens instead of PII.
Fichestor/ML: access only to aggregates/allowed features; feature policy (allow/deny).
Files/objects: pre-signed links with TTL, encryption and download policy.

6) Patterns for key domains

KYC/AML: CLS (only tokens are visible), RLS by operator country; detokenization - DPO/Legal by JIT.
Payments: Restricted, FLE + tokens, Risk/Payments-Ops access via JIT; audited uploads.
Game events: Internal/Confidential, RLS by brand/region/tenant, CLS for user_id.
Responsible Gaming: RG command access to aggregates; individual cases - upon request.
BI/ML: "gold" showcases without PII; ML - list of allowed features, justification log for controversial ones.

7) Access procedures

7. 1 Request → approval of → provisions

Requisition form: purpose, scope, term, role, ABAC attributes, set owner.
Auto check: data class, SoD, training completed? conflict of interest?
RACI: Owner (R), Steward (C), DPO/Sec (A/C), IT/IAM (R).

7. 2 JIT и break-glass

JIT: 15 min/2 h/1 day with auto-recall; renewal - on a new application.
Break-glass: for incidents; individual roles/keys, enhanced audit, post-mortem required.

7. 3 Regular reviews

Quarterly access review: Domain owners confirm roles/attributes.
Auto-deactivation of "forgotten" accesses (no-use 30/60 days).

8) Technical mechanisms

Catalog & Contracts: a source of truth about owners, classes, masks.
Policy Engine: OPA/equivalent for ABAC/Row/Column policies.
Data Masking: dynamic masks in DWH/BI; safe mask format for phones/email.

Tokenization: vault/FPE; detokenization only in the "clean zone."

Secrets & PAM: secret manager, JIT sessions, recording screens for admin accesses.
Audit & SIEM: immutable logs (WORM), correlation of access events with sessions and uploads.
Geo/tenant isolators: physical/logical separation (schemes, directories, clusters, encryption keys).

9) Consent & DSAR

Accesses take into account the player's consent (marketing = off → hide marketing attributes).
DSAR buttons: find/unload/delete by token; log of the entire operation; Legal Hold counts.

10) Monitoring and SLO

Access SLO: p95 time of issuing JIT access (e.g. ≤ 30 min).
Zero-PII in logs: 100% events without PII.
Anomaly rate: alerts for SELECT spike or atypical JOIN to Restricted.
Review Coverage: ≥ 95% of roles are reviewed on time.
Mask Hit-Rate: The proportion of requests where the mask/token was triggered.
Detokenization MTTR: average time to process a valid application.

11) Templates

11. 1 Access Policy (snippet)

Principle: least privilege + SoD + JIT.
Roles: a catalog of roles with a description of tasks/showcases.
ABAC attributes: 'country', 'brand', 'env', 'purpose', 'retention'.
Masks/Tokens: Active on Confidential/Restricted by default.
Review: Quarterly; auto-recall of "forgotten" accesses.
Violations: blocking, investigation, training.

11. 2 Application form

Who: Full name/team/manager.
What: Set/Table/Showcase/Feature.

Why: Goal, Expected Result/Metrics

How long: term/schedule.
Data class: (autocomplete from catalog).
Signatures: Owner/Steward, DPO or Sec (if Restricted).

11. 3 Role catalog (example)

Marketing-Analyst: Internal/Confidential Marketing Marts; without detokenization; RLS by brand.
Risk-Ops: Restricted payments with masks; JIT for detokenization; export only through "white" templates.
RG-Team: RG units, access to cases on request.
DS/ML: fichestor (allow-list feature), sandbox without PII.

12) Implementation Roadmap

0-30 days (MVP)

1. Classification of data and labels in schemas.
2. Role catalog + basic ABAC attributes (country/brand/env).
3. Default masking/tokenization for Confidential/Restricted.
4. JIT process and audit log; break-glass regulations.
5. RLS/CLS for payments, KYC, gaming events; disallowing'SELECT 'for Restricted.

30-90 days

1. Policy-as-Code in CI (request linter, blocks in case of violations).
2. Integration with Consent/DSAR; access SLO reports.
3. Quarterly access review; auto-deactivation.
4. PAM for admin accesses; Recording sessions time box.

3-6 months

1. Geo/tenant isolation, individual encryption keys by jurisdiction.
2. Auto-recommendations of roles based on actual requests (usage-based).
3. Behavioral analytics of access (anti-analytics), SOAR playbooks.
4. Process certification and external audit.

13) Anti-patterns

"Superuser" for all - without SoD and JIT.
Sharing data through files/screenshots outside of controlled channels.
RLS/CLS only "on paper" - masks are turned off in BI.
No rights review and auto-recall; "eternal" access.
Catalog/contracts are not updated - access rules are out of date.
Detokenization in applications "for convenience" without audit.

14) RACI (example)

Policies/Architecture: CDO/CISO (A), DPO (C), SecOps (R), Data Platform (R).
Access issuance: IAM/IT (R), Owners (A/R), Stewards (C), Managers (I).
Audit/Review: Owners (R), DPO/Sec (A), Internal Audit (C).
Incidents: SecOps (R), Legal/PR (C), Domains (R).

15) Related Sections

Data Management, Data Tokenization, Data Security and Encryption, Data Origin and Path, Ethics/DSAR, Confidential ML, Federated Learning.

Total

Access control is a system of policies, attributes and automation that gives teams the right data in exactly the right amount and time, leaving complete traceability. In iGaming, this is the basis of trust in metrics, incident resilience and speed of decision making.