Roles in myDRE workspace
Identity & Access Governance: Workspaces Entitlement Matrix
This architecture manual governs identity classification, role boundaries, and privileged entitlement structures within the myDRE platform. Designed in absolute compliance with ISO/IEC 27001:2023 (A.08.02- Privileged Access Rights, A.08.03 - Access Restriction), NIS 2, and the GDPR (Article 25 - Least Privilege), this matrix enforces strict logical separation between collaborative research personas and administrative support domains.
1. Identity Governance Principles
Every myDRE workspace operates as an isolated, multi-tenant security boundary. To maintain the data confidentiality tiers defined in our Terms of Service, all user management workflows must strictly adhere to the following baseline rules:
- The Principle of Least Privilege: Users must be provisioned with only the minimum functional access vectors absolutely required to perform their research tasks.
- Dynamic Scoping: Roles are defined explicitly per workspace. A myDRE platform identity may hold high-level administrative credentials in one isolated workspace while being bound to standard or data-restricted parameters in another.
- The Accountable Anchor: Every active workspace must contain exactly one named Accountable who serves as the primary legal and financial proxy. While this role can be reassigned to another verified user, it can never be removed or left vacant.
2. Core Workspace Persona Profiles
Standard workspaces support seven distinct structural roles designed to separate data ingestion, analytical computing, and data extraction vectors:
Core Research Personnel
- Accountable: The legally bound owner of the research study or project. Holds absolute structural control and ultimate cost accountability over the workspace lifecycle.
- Privileged Member: Shares identical technical capabilities and system administration rights with the Accountable, serving as a co-investigator or technical lead.
- Advanced Member: An active researcher authorized to perform data uploads, execute inbound data requests, connect directly to Virtual Machines (VMs), and dynamically resize VM compute parameters to fit analytical demands.
- Standard Member: A baseline research scientist. Authorized to ingest data, submit data requests, and operate inside a designated VM. All features impacting data egress, external network access, membership rosters, or cloud billing lines are structurally blocked.
Specialized Data Custodians
- Data Contributor: A siloed ingestion persona. Authorized to upload data files and submit data requests, but strictly barred from initiating VM connections or viewing any pre-existing dataset pools hosted within the workspace.
- Data Egressor: A gateway auditing persona. Authorized to review and approve outbound data extraction requests, but completely isolated from data ingestion tools or active VM compute instances.
- Data Reader: An observational persona. Barred from uploading data or initializing VM connections; authorized exclusively to view files via the dashboard and submit data requests.
Compliance-Driven Quarantine
- Restricted Member: A non-functional isolation state. The user remains a member of the workspace roster but holds zero system rights. This state is automatically triggered by a failure to complete a mandatory, periodic Access Review Policy, the expiration of a data permit window, or by explicit lock commands issued by an Accountable.
3. European Health Data Space (EHDS) Workspaces
To prepare for emerging cross-border compliance standards under the European Health Data Space (EHDS), anDREa enforces specialized Approver, Controller, and Processor operational archetypes.
GDPR-to-EHDS Legal Alignment: Under the GDPR, anDREa operates strictly as a Processor. In an EHDS framework, the tenant organization maps to the EHDS Controller—holding accountability for the underlying scientific methodology and filters—but operates within a heavily locked-down workspace topology.
┌────────────────────────────────────────────────────────────────────────┐ │ EHDS DATA PERMIT TUNNELING │ ├────────────────────────────────────────┬───────────────────────────────┤ │ 🧪Phase 1: Pre-Issuance (Configuration)│ 🔒 Phase 2: Post-Issuance │ ├────────────────────────────────────────┼───────────────────────────────┤ │ Full inbound/outbound internet allowed.│ Ingress blocked. Outbound text│ │ EHDS Controllers configure VMs and │ locked to verified license │ │ build software stacks. │ engines. Rigid data isolation.│ └────────────────────────────────────────┴───────────────────────────────┘
- EHDS Approver: A specialized, non-technical persona. Authorized to review and approve data requests. Approvers are allocated per Azure Subscription and managed by Support Team.
- EHDS Controller: A standard research persona restricted from uploading data manually. Holds full rights to initialize data requests, modify VM instances, adjust budget alert boundaries, and install dependencies from the local software share. During Phase 1 (pre-issuance), full network capabilities are provided; just prior to data delivery, the system automatically restricts outbound paths to approved licensing servers and severs unmanaged ingress channels.
- EHDS Processor: A pure compute-bound persona. Restricted from uploading data or submitting formal data requests; authorized exclusively to log into pre-configured VMs and execute analytical workloads under a completely isolated network perimeter.
EHDS-like workspaces will be available in the future for non-EHDS research projects. The same Approver, Controller, and Processor archetypes will be applied to all workspaces that require strict data isolation and regulatory compliance. Unlike EHDS-compliant, these workspaces will not be bound to the EHDS legal framework and will not require formal data permits and will be managed by the organisation's Support Team.
4. Administrative & Infrastructure Support Roles
Administrative operations are isolated from research data pools and operate under clear Privileged Access Management (PAM) boundaries:
- Support Team: Comprising local Research Support personnel and future Health Data Access Body (HDA) operators. Responsible for initializing and destroying workspaces, managing tenant-wide settings, and configuring global policies via
admin.mydre.org. Tied to one or more Azure Subscriptions, the Support Team is authorized to perform all administrative tasks except for data ingestion, data extraction, or direct VM access. - Support Team + PAM: An elevated, auditable "Break-the-Glass" administrative role. Activated exclusively to resolve technical system faults on behalf of an Accountable. Every activation and subsequent command line is captured and permanently logged to the immutable workspace Activity Feed.
- Billing Reader: A non-technical auditing persona. Authorized to query workspace metadata, configuration parameters, and cloud consumption rates to compile internal compliance and financial reports without gaining access to underlying data layers.