GH GambleHub

Segregation of duties and access levels

1) Goals and principles

Objectives:
  • exclude single control over critical operations (money/PII/compliance),
  • reduce the risk of fraud/error,
  • ensure verifiability for regulators and internal audits.

Principles: Zero Trust· Least Privilege· Need-to-Know· SoD (4-eyes)· Traceability· Revocability (quick recall).


2) Data classification and access levels

ClassExamplesBasic access requirements
Publicsite contentwithout authorization
Internalnon-PII operational metricsSSO, role read-only
ConfidentialDWH reports (aggregates)SSO + MFA, approved groups
Restricted (PII/Finance)KYC/AML, transactions, RG signalsABAC + JIT, field log, WORM log
Highly Restrictedsecrets, admin consoles, payment perimeterPAM, recorded sessions, isolated networks
💡 The class is fixed in the/RoPA data directory and bound to the encryption, retention, and export policies.

3) Rights model: RBAC + ABAC

RBAC: roles by domain (Support, VIP, Payments, AML, KYC, FRM, BI, DevOps, DPO, Legal).
ABAC: contextual attributes (environment, geography, data class, device/MDM, time, KYC level, access target 'purpose', device risk).

An example of an ABAC condition: a BI analyst can read 'events _' only without PII, only from the corporate network/MDM, on weekdays 08: 00-21: 00, with active privacy training.


4) SoD - matrix of incompatible functions

FunctionIt is authorizedIncompatible (requires/4-eyes separation)
Paymentsconfirm conclusionschange anti-fraud rules or VIP limits
Anti-Fraud (FRM)edit rules, set holdApprove your own cacheouts/chargeback solutions
Compliance/AMLEDD/STR/SAR, KYC readfull export of DWH/raw logs
Support/VIPprofile display (masked)access to ICC documents/raw transactions
Data/BIaggregates/anonymizationviewing PII without 'purpose'
DevOps/SREinfrastructure administrationreading business tables with PII
Developersstage/dev, logs (mask.) prod-PII
DPO/Privacyaudit, PII logschange of production rights
💡 Any transaction affecting money/PII/sanctions is subject to two-circuit approval (initiator ≠ approver).

5) Access levels and types

Read-only/Masked Read: default for BI/Support.
Scoped Write: changes within the service/procedure (e.g. entering case notes).
Privileged Admin: only through PAM (password safe, session proxy, session recording, secret rotation).
API/Service Accounts: minimal ospreys, individual keys per integration, mTLS.


6) JIT и break-glass

JIT (Just-in-Time): temporary elevation (15-120 min) for a specific ticket, automatic recall, mandatory 'purpose'.
Break-glass: emergency access with MFA + second confirmation, session recording, Security + DPO post-review, automatic creation of an incident in case of violations.


7) Processes (SOP)

7. 1 Request/Modify Access (IDM/ITSM)

1. Requisition with 'purpose', date and data owner.
2. Self check SoD/data class/jurisdiction.
3. Domain owner approval + Security (for Restricted +).
4. Issuance of JIT/permanent access (minimum scope).
5. Entry in the register of rights (revision date, SLA revocation).

7. 2 Re-certification of rights

Quarterly owners confirm group/user rights.
Automatic unused rights (> 30/60 days).

7. 3 Data export

Only through approved display cases/pipelines; Default masking white lists of destinations/formats; signature/hash; download log.


8) Vendor/partner control

Individual B2B tenants, minimal API scopes, allow-list IP, time windows.
DPA/SLA: access logs, retention periods, geography, incidents, sub-processors.
Offboarding: key recall, confirmation of deletion, closing act.


9) Integration with security and compliance

Audit trails: `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `PAYMENT_APPROVE`, `BREAK_GLASS`.
SIEM/SOAR: alerts for abnormal volumes/access without 'purpose '/going out of window/geo.
GDPR/AML/PCI: Need-to-Know, DSAR compatibility, payment perimeter segregation, WORM for journals.


10) Example policies (fragments)

10. 1 VIP Manager Policy

Masked profile view, export ban, JIT to single KYC view via ticket.

10. 2 Policy for Marketing Analyst

Only units without PII; access with consent (CMP flag), from the MDM device, during working hours.

10. 3 Pseudo-YAML ABAC

yaml policy: read_transactions_masked subject: role:bi_analyst resource: dataset:tx_
condition:
data_class: in [Confidential]
network: in [corp_vpn, office_mdm]
time: 08:00-21:00 workdays purpose: required effect: allow masking: on logging: audit_access + fields_scope

11) RACI

ActivityCompliance/LegalDPOSecuritySRE/ITData/BIProduct/EngDomain Owner
SoD Policies/Access LevelsA/RCCCCCC
RBAC/ABAC designCCA/RRRRC
JIT/PAM/break-glassIIA/RRICI
RecertificationCCARRRR
Export/MaskCARRRCC

12) Metrics and KRIs/KPIs

Coverage ABAC: ≥ 95% of critical sets under attribute rules.
JIT-rate: ≥ 80% of elevations are JIT.
Offboarding TTR: revocation of access ≤ 15 minutes from the moment of dismissal/deactivation.
Abnormal accesses without 'purpose': = 0 (KRI).
Quarterly recertification: 100% roles/groups confirmed.
Export compliance: 100% of exports are signed/logged.


13) Checklists

13. 1 Before granting access

  • 'purpose' defined, date, data owner
  • SoD/Jurisdictions/Data Class validation passed
  • Minimum scope + masking enabled
  • MFA/MDM/network conditions met
  • Journals and revision date set up

13. 2 Quarterly audit

  • Check groups/roles against organizational structure
  • Revoke Unused Rights
  • Check break-glass and major exports
  • Confirm training (privacy/security)

14) Typical scenarios and measures

A) Engineer needs temporary access to prod-DB

JIT 30-60 min, recorded session via PAM, post-review, CAPA for violations.

B) New affiliate asks players to unload

Aggregates only/anonymization; if PII - contract, legal basis, whitelist of fields, journal/signature, limited term of reference.

C) VIP manager wants to see KYC documents

Prohibition of direct access; request via AML/KYC, single issue via JIT, full log of fields.


15) Implementation Roadmap

Weeks 1-2: System/Data Inventory, Classification, Baseline RBAC Matrix, Primary SoD Table.
Weeks 3-4: ABAC (environment/geo/class/MDM) implementation, JIT and break-glass, PAM launch, export logs.
Month 2: CMC/payment perimeter segmentation, individual keys/KMS, SOAR alerts for SoD/ABAC violations.
Month 3 +: quarterly re-certification, attribute extension (device risk/time), masking automation, regular tabletop exercises.


TL; DR

Reliable access model = data classification → RBAC + ABAC → SoD with 4-eyes → JIT/PAM and hard audit → regular re-certification and export control. This reduces the likelihood of abuse and speeds up the passage of audits/regulatory checks.

Contact

Get in Touch

Reach out with any questions or support needs.We are always ready to help!

Start Integration

Email is required. Telegram or WhatsApp — optional.

Your Name optional
Email optional
Subject optional
Message optional
Telegram optional
@
If you include Telegram — we will reply there as well, in addition to Email.
WhatsApp optional
Format: +country code and number (e.g., +380XXXXXXXXX).

By clicking this button, you agree to data processing.