[SEC-01] Role-based Access Control (RBAC)

{
  "cost": {
    "input_tokens": 16,
    "estimated_usd": 0.03482,
    "output_tokens": 1158
  },
  "model": "gemini-3-pro-preview",
  "status": "success",
  "transport": "gemini_api",
  "latency_ms": 23189,
  "response_text": "This document outlines the standard for **[SEC-01] Role-based Access Control (RBAC)**. It is intended to be used as a requirement specification for software architects, developers, and security administrators.\n\n---\n\n# [SEC-01] Role-based Access Control (RBAC) Standard\n\n## 1. Objective\nTo restrict system access to authorized users based on their role within the organization. This standard enforces the **Principle of Least Privilege (PoLP)**, ensuring users have only the amount of access necessary to perform their job functions and nothing more.\n\n## 2. Core Definitions\n*   **Subject (User):** A person or automated service identity requesting access.\n*   **Role:** A job function or title which defines authority level (e.g., `Administrator`, `Auditor`, `Editor`).\n*   **Permission:** A specific approval to perform an operation on a resource (e.g., `read:file`, `write:database`).\n*   **Resource:** The system object being accessed (e.g., Files, API Endpoints, Database Records).\n*   **Session:** A mapping between a user and an active set of roles.\n\n## 3. Fundamental Rules\nTo comply with [SEC-01], the system MUST adhere to the following rules:\n\n1.  **Role Assignment:** Users are never assigned permissions directly. Users are assigned **Roles**, and Roles are assigned **Permissions**.\n2.  **Role Authorization:** A subject can execute a transaction only if the subject has selected or been assigned a role that possesses the corresponding permission.\n3.  **Default Deny:** If a role is not explicitly granted permission to perform an action, access is denied by default.\n\n## 4. Implementation Requirements\n\n### 4.1. Role Hierarchy\nSystems SHOULD implement hierarchical role inheritance where applicable to reduce redundancy.\n*   *Example:* A `Senior Editor` role inherits all permissions of an `Editor` role, plus additional privileges (e.g., `publish:article`).\n\n### 4.2. Separation of Duties (SoD)\nStatic Separation of Duties (SSD) MUST be enforced for critical operations to prevent conflict of interest.\n*   *Requirement:* No single role should have permissions to execute mutually exclusive tasks (e.g., The role that *requests* a payment cannot be the same role that *approves* the payment).\n\n### 4.3. Identification and Authentication\nRBAC is an authorization mechanism. It MUST rely on a verified identity established via a separate Authentication process (e.g., [SEC-02] MFA or SSO) before roles are evaluated.\n\n### 4.4. API Security\nFor RESTful or GraphQL APIs:\n*   Roles MUST be included in the access token (e.g., JWT Claims) or resolved server-side via a session store.\n*   Every endpoint MUST check for the required permission/scope before processing the request.\n\n## 5. Access Matrix Example\nThe following matrix demonstrates a compliant RBAC structure for a generic Content Management System (CMS).\n\n| Permission / Action | Guest | Subscriber | Editor | Administrator |\n| :--- | :---: | :---: | :---: | :---: |\n| **View Public Content** | ✅ | ✅ | ✅ | ✅ |\n| **View Premium Content**| ❌ | ✅ | ✅ | ✅ |\n| **Create Draft** | ❌ | ❌ | ✅ | ✅ |\n| **Edit Own Draft** | ❌ | ❌ | ✅ | ✅ |\n| **Publish Content** | ❌ | ❌ | ✅ | ✅ |\n| **Delete Any Content** | ❌ | ❌ | ❌ | ✅ |\n| **Manage Users** | ❌ | ❌ | ❌ | ✅ |\n\n## 6. Lifecycle Management\n\n### 6.1. Provisioning\n*   Roles are assigned during the user onboarding process based on HR job codes or management requests.\n*   Temporary role elevation (e.g., \"Break Glass\" scenarios) must be time-bound and logged.\n\n### 6.2. Review (Recertification)\n*   User-to-Role assignments MUST be reviewed quarterly.\n*   Roles that are no longer required for a user's function must be revoked immediately.\n\n### 6.3. Deprovisioning\n*   Upon termination or role change, previous role associations must be removed immediately to prevent \"Privilege Creep.\"\n\n## 7. Audit and Compliance\nThe system MUST log the following RBAC events for audit purposes:\n1.  **Creation/Modification of Roles:** (e.g., Admin added `delete:user` permission to `Editor` role).\n2.  **Assignment of Roles:** (e.g., User A was assigned `Administrator` role).\n3.  **Access Decisions:** (e.g., User B failed to access Resource X - Missing Role).\n\n## 8. Anti-Patterns (What to Avoid)\n*   **Role Explosion:** Creating a new role for every single user. (Use Attribute-Based Access Control if granularity per specific user is needed).\n*   **Hardcoded IDs:** Checking `if (user.id == 1)` instead of `if (user.hasRole('Admin'))`.\n*   **Client-Side Validation Only:** Hiding UI buttons based on roles but failing to secure the backend API endpoint.\n\n---\n*End of [SEC-01] Specification*"
}