GH GambleHub

Role delegation and accesses

(Section: Operations and Management)

1) Why role-based delegation

The goal is to give each participant (employee, partner, service) exactly as many rights as necessary and exactly as much time as necessary, with full traceability of actions. This reduces the risks of leaks and abuse, speeds up onboarding and the passage of audits.

2) Access model: levels and domains

Access domains: people (console/panels), services (machine tokens), data (tables/objects), infrastructure (cloud/K8s), counterparties (external integrations), regions/tenants.
Trust levels: public → internal → protected (PII/finance) → especially critical (keys/payments).

Operation zones: prod/staging/sandbox; rule "from "below" to "above" - only through approved pipelines."

3) Authorization models

RBAC: roles are linked to tasks (Content Editor, Payout Operator). Simple start, easy to check.
ABAC: policies by attributes of the subject/resource/context (region, tenant, shift, device, risk scoring).
ReBAC (relationship-based): rights follow from relationships (project owner, team member).
Hybrid: RBAC for base matrix, ABAC for context constraints, ReBAC for ownership.

💡 Practice: keep a graph of rights (who → what → why) to identify escalation paths and "super nodes" of risk.

4) Minimum required access (Least Privilege)

Start - minimum roles-by-default (read-only, without PII).
Promotion - only through an application with justification, term and owner.
Time limit (TTL): rights "melt" automatically; extension - consciously.
Contextual guard rails: region/tenant, opening hours, device, geo.

5) Segregation of Duties (SoD)

The SoD matrix excludes dangerous combinations:
  • "Sets limits" ≠ "approves limits."
  • "Prepares the payment" ≠ "signs the payment."
  • "Writes code" ≠ "releases in prod."
  • "Admin DB" ≠ "reads PII in analytics."
  • Implement SoD in policies and in the processes themselves (two-signature, M-of-N).

6) JML processes (Joiner/Mover/Leaver)

Joiner: auto-assignment of basic roles by position/team/region, checklist of access for 24 hours.
Mover: review of roles when changing team/project; automatic removal of "old" rights.
Leaver: revocation of sessions, keys, tokens; reissue of secrets, transfer of possession of artifacts.

7) Temporary Privileges: JIT/PAM

Just-In-Time (JIT): raising rights on an application for 15-240 minutes with MFA and ticket justification.
PAM (Privileged Access Management): proxy/shell login, recording sessions, command log.
Break-glass: emergency access with instant alert, short TTL and mandatory post-mortem.

8) Service identities and keys

Service Accounts: separate for each service and environment, no shared secrets.
Workload Identity: binding tokens to the pod/vir/function; short-term credits.
Secrets: KMS/Vault, rotation, two-loop encryption, prohibition of getting into logs.
Signature/payout keys: threshold/MPC, hardware HSMs, diversity across trust domains.

9) SSO/MFA/SCIM and account lifecycle

SSO: IdP (SAML/OIDC), single sign-on, centralized password/device policies.
MFA: mandatory for admins/finance/PII; preferably FIDO2.
SCIM: automatic creation/deletion/modification of accounts and groups.
Device Posture: conditional access by device status (disk encryption, EDR, current patches).

10) Policies-as-code and verification

OPA/Authorization service: policies in the form of code (Rego/JSON), review via PR, tests.

Drift control: regular comparisons "declared vs actually."

Pre-flight checks: "will the policy allow this operation?" - test cases before release.

11) Data access

Classification: public/internal/limited/PII/finance.
"Minimum" pressure: aggregates/masks instead of "raw" data; PII requests - through approved jabs only.
Tokenization/DE-ID - replace identifiers, audit requests.
Layers: food → replicas → showcases → aggregates; direct access to the production database - only JIT/PAM.

12) Cloud, K8s, networks

Cloud IAM: roles per-account/project; "Admin" prohibition by default; Restricting actions on tags/folders.
Kubernetes: RBAC on neimspaces, PSP/similar policies without "privileged," allowlist image, secrets via CSI, service accounts per-pod.
Network: Zero-Trust (mTLS, identity-aware), access to jump-host - JIT only, recording SSH sessions.

13) External Partners and Integrations

Isolated tenants/keys, minimum scopes of OAuth2, short TTL tokens.
Webhooks: signature (HMAC/EdDSA), 'nonce + timestamp', narrow reception window.

Rotation of keys on a schedule, recall upon compromise, status endpoints for "health."

14) Audit, recertification, reporting

Immunity: WORM logs, policy release signatures, Merkle slices.
Recertification: quarterly check of critical roles, monthly - admin rights.
Quarantine rights: "unused 60 days" → auto-removal.
Evidence pack: uploads of the role matrix, SoD triggers, JIT requests, recording PAM sessions.

15) Metrics and SLO

TTG (Time-to-Grant): median time for granting access to a standard application (target ≤ 4h).
The share of JIT access among the "privileged" (target ≥ 80%).
SoD-violations: 0 in prod, elimination time ≤ 24 hours.
Orphan rights:% of users with excess rights (target → 0. 0x%).
Rotation of secrets: average age of the secret (target ≤ 30 days for sensitive).
Audit coverage: 100% privileged actions with artifacts (records, receipts).

16) Dashboards

Access Health: active roles, orphan rights, JIT vs permanent.
PAM & Sessions: number of privileged sessions, duration, MFA success.
SoD & Incidents: lock statistics, causes, MTTR.
Secrets & Keys: age, upcoming rotation, red keys.
JML: SLA of onboarding/offboarding, overdue applications.
Audit Evidence: quarterly recertification status, completeness 100%.

17) Incident playbooks

Token/key compromise: immediate recall, global usage search, dependency rotation, retro audit in N days.
Violation of SoD: block of operation, temporary disconnection of the role, post-mortem and policy change.
Unauthorized access to PII: isolation, DPO notification, leak inventory, legal procedures.
Escalation abuse: freezing the JIT for the subject/team, analyzing applications/justifications, adjusting TTL limits.

18) Operational practices

Four eyes on issuing/changing critical rights.
Role catalog with description of tasks, risks and allowed operations.
Test environments with anonymized data and other roles.
Policy dry-run: simulation of the effects of changes before application.

GameDays by access: "loss of IdP," "PAM failure," "secret leak."

19) Implementation checklist

  • Create a role taxonomy and SoD matrix for key processes.
  • Enable SSO + MFA for all, SCIM streams for JML.
  • Deploy PAM/JIT, configure break-glass with alerts and short TTL.
  • Enter policies-as-code (OPA), revisions via PR, and autotests.
  • Separate service accounts and workload-identity; prohibition of shared secrets.
  • Vault/KMS, regular rotation of secrets and keys, prohibition of secrets in the code/logs.
  • Separate environments and regions, consolidate cross-regional access rules.
  • Run dashboards and SLOs, monthly recertification reports.
  • Perform a SoD scan of the rights graph and eliminate escalation paths.
  • Regular exercises and post-mortems with action items.

20) FAQ

RBAC or ABAC?
RBAC - basic readability layer, ABAC - context and dynamics. Use a hybrid.

Is PAM needed if there is a JIT?
Yes: PAM gives session recording and managed privileged access channels.

How to reduce the "sticking" of rights?
TTL for roles, auto-remove unused, monthly recertification and SoD alerts.

What to do with external contractors?
Dedicated tenants/groups, limited scopes, short TTLs, mandatory reports, and recertification.

Summary: Role delegation and accesses are not a "tick box set," but a rights lifecycle: minimum required roles, SoD, JIT/PAM, policy-as-code, observability, and regular recertification. Such an outline gives quick work to teams and predictable security for business and audit.

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.