Access policies and segmentation

1) Purpose and principles

The goal: to minimize the risk of leaks/fraud and regulatory consequences through strict "who, what and why has access" controls, with provability for audit.
Principles: Least Privilege (minimum rights), Need-to-Know, Zero Trust, Segregation of Duties (SoD), Just-in-Time (JIT), traceability and one-click recall.

2) Data classification and protection levels

3) Access model: RBAC + ABAC

RBAC (roles): basic "role → resolution" matrix.
ABAC (attributes): context rules (player/operator jurisdiction, environment segment, set sensitivity, shift/time, device, KYC verification level, service task/purpose).

• The marketing analyst can read the'events _' tables only for countries where there is consent to analytics, only on weekdays 08: 00-21: 00, only from the corporate network/MDM device, without PII fields (masking is enabled).

4) SoD - separation of duties (anti-fraud and compliance)

5) JIT, break-glass и PAM

JIT (Just-in-Time): elevated rights are issued for a limited interval (15-120 minutes) for a specific task and are automatically revoked.
Break-glass: emergency access through a separate procedure (MFA + second confirmation + mandatory indication purpose), full recording of the session and post-factual review.
PAM: for admin accounts - password stores, behavioral analytics, key/secret rotation, session proxy with recording.

6) Segmentation: medium, network and logical

6. 1 Environments: 'prod' ≠ 'stage' ≠ 'dev'. Prod data is not copied to stage/dev; uses synthetic or aliased sets.

• Edge/WAF/CDN → App Zone → Data Zone (DWH/DB) → Secrets/KMS.
• The payment perimeter (PSP/cards) is isolated from the common prod; CCM/sanctions - a separate segment.
• 6. 3 Logical segmentation: namespaces (K8s), tenant-IDs, DB/data directory schemas, individual encryption keys per tenant/region.
• 6. 4 Geo-segmentation: storage/processing according to location (EC/UK/...); routing guidas and keys around the region.

7) Vendor and partner access

Mechanics: individual B2B tenants/accounts, minimum API scope, mTLS, allow-list IP, window time.
Contracts: DPA/SLA (logs, retention periods, geography, incidents, sub-processors).
Offboarding: key recall, confirmation of deletion, closing act.
Monitoring: alerts for abnormal volumes, ban on mass exports.

8) Processes (SOP)

8. 1 Request/change access

1. Application to IDM/ITSM with purpose and term.
2. SoD/jurisdiction/data class auto-verification.
3. Domain owner approval + Security/Compliance (if Restricted +).
4. Issuance of JIT/permanent access (minimum set).
5. Logging: who/when/what is issued; revision date.

8. 2 Recertification

Quarterly: owners confirm rights of groups; automatic unused rights (> 30/60 days).

8. 3 Data export

Only through approved pipelines/showcases, according to white lists of formats (CSV/Parquet/JSON), default masking, signature/hash, download log.

9) Device policy and context

MDM/EMM - Access Restricted/Highly Restricted only from managed devices.
Context signals: geo, risk rate of devices, time of day, MFA status, IP reputation - as ABAC attributes.
Browser extensions/screen capture: control and log, prohibition for sensitive consoles.

10) Policy examples (snippets)

10. 1 YAML (pseudo) - ABAC for marketing analyst

yaml policy: read_analytics_no_pii subject: role:marketing_analyst resource: dataset:events_
condition:
consent: analytics == true data_class: not in [Restricted, HighlyRestricted]
network: in [corp_vpn, office_mdm]
time: between 08:00-21:00 workdays effect: allow masking: default logging: audit_access + fields_scope

10. 2 SQL masking (idea)

sql
SELECT user_id_hash,
CASE WHEN has_priv('pii_read') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

11) Monitoring, logs and alerts

Audit trails: `READ_PII`, `EXPORT_DATA`, `ROLE_UPDATE`, `BREAK_GLASS`, `PAYMENT_APPROVE`.
KRIs: accesses without 'purpose' = 0; attempts to Highly Restricted outside the window; share of failed SoD checks; abnormal discharges.
KPI:% of requests with JIT ≥ 80%; average access time ≤ 4 hours; 100% re-certification coverage.
SOAR playbooks: auto-recall for threats, investigation tickets.

12) Compliance (short map)

GDPR/UK GDPR: minimization, need-to-know, DSAR compatibility, PII audit.
AML/KYC: access to CCM/sanctions - only for trained roles, decision log.
PCI DSS (if applicable): payment zone segregation, ban on PAN/CSC storage, separate keys/hosting.
ISO/ISMS: formalized access policies, annual audits and tests.

13) PACI

14) Maturity metrics

ABAC rule coverage of critical datasets ≥ 95%.
JIT sessions/all elevations ≥ 90%.
The offboarding revocation time ≤ 15 minutes.
0 role ≠ function (SoD) incidents.
100% of access logs are available and verified (signature/hash).

15) Checklists

15. 1 Before granting access

• Purpose, date and data owner defined
• SoD/Jurisdictions Verified
• Minimum scope/masking enabled
• MFA/MDM/network conditions met
• Logging and revision date configured

15. 2 Quarterly Review

• Reconcile groups and roles with organizational structure
• Auto "hanging" rights
• Check for abnormal exports and break-glass
• Training and Test Alerts

16) Typical scenarios and measures

A) New role "VIP Manager"

Access to VIP profiles (masked), export ban, JIT for one-time KYC viewing via ticket.

B) BI audit vendor

read-only to storefronts without PII, temporary VPN + allow-list, prohibit saving locally, download log.

C) DevOps emergency access to prod-DB

break-glass ≤ 30 min, recording session, post-review with DPO/Compliance, CAPA for violations.

17) Implementation Roadmap

Weeks 1-2: data/system inventory, data classes, basic RBAC matrix, SoD.
Weeks 3-4: implement ABAC (first attributes: environment, geo, data class), IDM streams, JIT/break-glass, PAM.
Month 2: payment and KYC perimeter segmentation, separate keys/KMS, export journals, SOAR alerts.
Month 3 +: quarterly re-certifications, attribute extension (device/risk), masking automation, regular drills.

TL; DR

Robust access model = data classification → RBAC + ABAC → SoD + JIT/PAM → hard segmentation → logs and alerts. This reduces the likelihood of leaks and abuse, speeds up auditing, and keeps the platform within the boundaries of GDPR/AML/PCI and internal standards.