Sweden
Loading...
India
Loading...
RBAC (Role-Based Access Control) for esysflow Project
Table of Contents
- Overview
- System Roles and Responsibilities
- Permission Matrix
- Resource Access Control
- Implementation Guide
- User Workflows
- Access Management Procedures
1. Overview
What is RBAC?
RBAC is a security model that controls system access based on user roles. Instead of giving each user individual permissions, we assign them to roles, and each role has a defined set of permissions.
Why RBAC for esysflow?
esysflow is a complex software development platform with multiple user types: - Engineers: Need to write and review code - Managers: Need oversight and decision authority - QA/Testers: Need testing permissions - DevOps: Need deployment permissions - Admins: Need system management access - Stakeholders: Need read-only dashboards
RBAC ensures: - ✓ Each user gets access they NEED (not everything) - ✓ Automatic consistency across the platform - ✓ Easy to audit who can access what - ✓ Secure by default - ✓ Scales to hundreds of users
RBAC Hierarchy for esysflow
┌─────────────────────────────────────────────────────┐
│ System Admin (Root - Access to everything) │
├─────────────────────────────────────────────────────┤
│ User Management | Security | Infrastructure │
│ | & Audit | & Backup │
├─────────────────────────────────────────────────────┤
│ Engineering Team Structure │
├────────────┬────────────┬─────────┬────────────────┤
│ Tech Lead │ Developers │ QA Team │ DevOps / Ops │
│ (Manager) │ │ │ │
│ │ │ │ │
│ ├─Senior │ ├─Mid Dev │ ├─QA │ ├─DevOps Eng │
│ ├─Mid Dev │ ├─Jr Dev │ └─Automation│ └─Sys Admin │
│ └─Jr Dev │ └─Interns │ │
├─────────────────────────────────────────────────────┤
│ Business / Management Layer │
├────────────┬────────────┬─────────┬────────────────┤
│ Product Mgr│ Manager │ Analyst │ Executive │
└────────────┴────────────┴─────────┴────────────────┘
2. System Roles and Responsibilities
Level 1: System Administrator
Description: Complete system access and control
Typical Responsibilities: - User account management (create/delete/modify) - Role and permission management - System configuration - Server/infrastructure management - Database administration - Security policy enforcement - Audit log management - Backup and recovery - System monitoring and alerts
Who Should Have This: 1-2 trusted senior IT staff members only
Key Permissions:
USER MANAGEMENT:
✓ CREATE_USER
✓ DELETE_USER
✓ MODIFY_USER_PROFILE
✓ RESET_PASSWORD
✓ SUSPEND_USER_ACCOUNT
✓ MANAGE_ROLES
✓ ASSIGN_ROLES_TO_USERS
SYSTEM ADMINISTRATION:
✓ MANAGE_SYSTEM_CONFIGURATION
✓ MANAGE_SECURITY_POLICIES
✓ CONFIGURE_BACKUP_SYSTEMS
✓ MANAGE_SERVER_INFRASTRUCTURE
✓ MANAGE_API_KEYS
✓ MANAGE_INTEGRATIONS
✓ CONFIGURE_NOTIFICATIONS
AUDIT & COMPLIANCE:
✓ VIEW_AUDIT_LOG (complete)
✓ VIEW_USER_ACTIVITY_LOG
✓ GENERATE_COMPLIANCE_REPORTS
✓ EXPORT_LOGS
✓ MANAGE_RETENTION_POLICIES
SECURITY:
✓ MANAGE_SECURITY_CERTIFICATES
✓ MANAGE_ENCRYPTION_KEYS
✓ MANAGE_FIREWALL_RULES
✓ MANAGE_IP_WHITELIST
✓ MANAGE_VPN_ACCESS
What They CANNOT Do:
✗ Cannot be audited by themselves (must use audit system)
✗ Cannot override security policies (they enforce them)
Level 2: Engineering Manager / Tech Lead
Description: Team leadership and technical oversight
Team Responsibility: Manages 5-15 engineers
Typical Responsibilities: - Code review and quality approval - Technical architecture decisions - Team work assignment and planning - Release approvals - Performance reviews for team - Setting coding standards - Risk assessment for changes - Mentoring junior developers
Key Permissions:
CODE MANAGEMENT:
✓ READ_CODE_REPOSITORY
✓ APPROVE_PULL_REQUESTS
✓ REJECT_PULL_REQUESTS
✓ MERGE_TO_MAIN_BRANCH
✓ CREATE_RELEASE_CANDIDATE
✓ APPROVE_RELEASE_TO_PRODUCTION
✓ MANAGE_BRANCH_POLICIES
TEAM MANAGEMENT:
✓ CREATE_TASKS_FOR_TEAM
✓ ASSIGN_TASKS_TO_TEAM_MEMBERS
✓ REASSIGN_TASKS
✓ CLOSE_TASKS
✓ CREATE_PROJECT_MILESTONES
✓ SET_PROJECT_DEADLINES
✓ MANAGE_TEAM_MEMBERS_ACCESS (limited)
✓ VIEW_TEAM_PERFORMANCE_METRICS
DOCUMENTATION:
✓ CREATE_TECHNICAL_DOCUMENTATION
✓ MODIFY_TECHNICAL_DOCUMENTATION
✓ DELETE_DOCUMENTATION (own team's only)
✓ CREATE_ARCHITECTURE_DIAGRAMS
TESTING & DEPLOYMENT:
✓ DEPLOY_TO_STAGING
✓ RUN_INTEGRATION_TESTS
✓ APPROVE_DEPLOYMENT_STAGING
VISIBILITY:
✓ VIEW_AUDIT_LOG (team actions only)
✓ VIEW_CODE_QUALITY_REPORTS
✓ VIEW_BUILD_LOGS
✓ VIEW_TEST_RESULTS
What They CANNOT Do:
✗ Cannot deploy to production (DevOps does that)
✗ Cannot manage other teams
✗ Cannot create new roles
✗ Cannot delete repositories
✗ Cannot access admin settings
Real-World Example:
Sarah is Tech Lead for the Backend Team (8 engineers)
Monday Morning:
1. Receives 4 pull requests from team members
2. Reviews each PR (reads code, checks for bugs)
3. Approves 3 PRs, asks for changes on 1
4. Merges the 3 approved PRs to main branch
5. Runs integration tests - all pass ✓
Wednesday:
1. Approves feature for staging deployment
2. DevOps engineer deploys to staging
3. Reviews test results from QA team
4. All tests pass ✓
Friday:
1. Approves release to production
2. DevOps engineer deploys to production
3. Monitors system for issues
4. Everything stable ✓
Level 3: Senior Developer
Description: Advanced software engineer with code review authority
Typical Responsibilities: - Write high-quality production code - Review junior developers' code - Mentor team members - Debug complex issues - Write integration tests - Create technical documentation - Suggest architectural improvements - Lead features/modules
Key Permissions:
CODE MANAGEMENT:
✓ READ_CODE_REPOSITORY
✓ WRITE_CODE_TO_BRANCHES
✓ CREATE_FEATURE_BRANCHES
✓ DELETE_PERSONAL_BRANCHES
✓ SUBMIT_PULL_REQUESTS
✓ REVIEW_PULL_REQUESTS (can comment, approve)
✓ RUN_LOCAL_BUILDS
✓ RUN_UNIT_TESTS
TESTING:
✓ RUN_TEST_SUITES
✓ RUN_INTEGRATION_TESTS
✓ VIEW_TEST_RESULTS
✓ CREATE_TEST_CASES
✓ MODIFY_TEST_CASES
DEBUGGING:
✓ ACCESS_STAGING_ENVIRONMENT
✓ DEBUG_IN_STAGING
✓ VIEW_STAGING_LOGS
✓ VIEW_ERROR_REPORTS
DOCUMENTATION:
✓ CREATE_API_DOCUMENTATION
✓ CREATE_TECHNICAL_DOCUMENTATION
✓ MODIFY_TECHNICAL_DOCUMENTATION
✓ CREATE_CODE_EXAMPLES
VISIBILITY:
✓ VIEW_BUILD_LOGS
✓ VIEW_PROJECT_STATUS
✓ VIEW_TEAM_TASKS
What They CANNOT Do:
✗ Cannot merge code to main (Tech Lead does that)
✗ Cannot deploy to staging or production
✗ Cannot delete repositories
✗ Cannot access admin settings
✗ Cannot create/modify roles
✗ Cannot view production database
Real-World Example:
John is a Senior Developer on the Backend Team
Tuesday:
1. Writes code for payment processing feature
2. Commits to feature/payment-processing branch
3. Runs local unit tests - all pass ✓
4. Creates pull request for review
Wednesday:
1. Receives review from another senior dev
2. Updates code based on feedback
3. Other senior dev approves ✓
Thursday:
1. Tech Lead merges PR to main
2. Automated tests run and pass ✓
Friday:
1. New code deploys to production ✓
2. John monitors for issues
3. System stable ✓
Level 4: Mid-Level Developer
Description: Software engineer with 2-5 years experience
Typical Responsibilities: - Write production code under guidance - Fix bugs assigned to them - Write unit tests - Participate in code reviews - Learn from senior developers - Document their code - Ask questions when uncertain
Key Permissions:
CODE MANAGEMENT:
✓ READ_CODE_REPOSITORY
✓ WRITE_CODE_TO_BRANCHES
✓ CREATE_FEATURE_BRANCHES
✓ DELETE_PERSONAL_BRANCHES
✓ SUBMIT_PULL_REQUESTS
✓ RUN_LOCAL_BUILDS
✓ RUN_UNIT_TESTS
TESTING:
✓ RUN_TEST_SUITES
✓ VIEW_TEST_RESULTS
✓ CREATE_TEST_CASES
✓ MODIFY_OWN_TEST_CASES
DEBUGGING:
✓ ACCESS_STAGING_ENVIRONMENT
✓ DEBUG_IN_STAGING
✓ VIEW_STAGING_LOGS
✓ VIEW_ERROR_REPORTS
VISIBILITY:
✓ VIEW_BUILD_LOGS
✓ VIEW_PROJECT_STATUS
✓ VIEW_ASSIGNED_TASKS
What They CANNOT Do:
✗ Cannot approve pull requests
✗ Cannot merge code
✗ Cannot delete code
✗ Cannot deploy to staging
✗ Cannot deploy to production
✗ Cannot modify test cases by others
✗ Cannot access production environment
Level 5: Junior Developer / Intern
Description: Entry-level software engineer or intern
Typical Responsibilities: - Write simple features - Fix simple bugs - Write unit tests - Learn coding standards - Get reviewed heavily by seniors - Ask for help when needed - Document their learning
Key Permissions:
CODE MANAGEMENT:
✓ READ_CODE_REPOSITORY
✓ WRITE_CODE_TO_OWN_BRANCHES
✓ CREATE_FEATURE_BRANCHES
✓ DELETE_PERSONAL_BRANCHES
✓ SUBMIT_PULL_REQUESTS
✓ RUN_LOCAL_BUILDS
✓ RUN_UNIT_TESTS
TESTING:
✓ RUN_TEST_SUITES
✓ VIEW_TEST_RESULTS
✓ CREATE_SIMPLE_TEST_CASES
VISIBILITY:
✓ VIEW_BUILD_LOGS
✓ VIEW_ASSIGNED_TASKS
✓ VIEW_DOCUMENTATION
What They CANNOT Do:
✗ Cannot delete any code
✗ Cannot modify branches
✗ Cannot approve pull requests
✗ Cannot merge code
✗ Cannot deploy anywhere
✗ Cannot modify code by others
✗ Cannot access production/staging
✗ Cannot run integration tests
Real-World Example:
Alex is a Junior Developer
Monday:
1. Gets assigned: "Add logout button to navigation"
2. Creates branch: feature/logout-button
3. Writes code for button
4. Writes unit tests for button
5. Runs tests locally - all pass ✓
6. Commits code and creates PR
7. Asks for review: "Senior devs, please review"
Tuesday:
1. Gets feedback from senior dev
2. Updates code based on feedback
3. Commits updated code
Wednesday:
1. Senior dev approves ✓
2. Tech Lead merges to main
3. Code automatically tests ✓
Friday:
1. New button deployed to production ✓
Level 6: QA Engineer / Test Engineer
Description: Quality assurance and testing specialist
Typical Responsibilities: - Write test plans - Execute manual tests - Create automated test scripts - Find and report bugs - Test on multiple browsers/devices - Verify fixes work - Create test documentation - Ensure code quality
Key Permissions:
TESTING:
✓ READ_CODE_REPOSITORY (understand what to test)
✓ RUN_TEST_SUITES
✓ RUN_INTEGRATION_TESTS
✓ RUN_PERFORMANCE_TESTS
✓ VIEW_TEST_RESULTS
✓ CREATE_TEST_CASES
✓ CREATE_TEST_PLANS
✓ MODIFY_TEST_CASES
✓ EXECUTE_MANUAL_TESTS
ENVIRONMENT ACCESS:
✓ ACCESS_STAGING_ENVIRONMENT
✓ ACCESS_DEVELOPMENT_ENVIRONMENT
✓ VIEW_STAGING_LOGS
✓ VIEW_ERROR_REPORTS
BUG MANAGEMENT:
✓ CREATE_BUG_REPORT
✓ UPDATE_BUG_REPORT (own)
✓ ASSIGN_BUG_TO_DEVELOPER
✓ CLOSE_BUG_AFTER_VERIFICATION
✓ VIEW_BUG_HISTORY
DOCUMENTATION:
✓ CREATE_TEST_DOCUMENTATION
✓ VIEW_TECHNICAL_DOCUMENTATION
✓ MODIFY_TEST_DOCUMENTATION
VISIBILITY:
✓ VIEW_BUILD_LOGS
✓ VIEW_PROJECT_STATUS
✓ VIEW_TEST_COVERAGE_REPORTS
What They CANNOT Do:
✗ Cannot write production code
✗ Cannot approve/merge code
✗ Cannot deploy anywhere
✗ Cannot modify code by developers
✗ Cannot access production database
✗ Cannot delete test cases
Level 7: DevOps / System Operations Engineer
Description: Infrastructure, deployment, and system operations
Typical Responsibilities: - Deploy code to staging/production - Manage servers and infrastructure - Monitor system health - Handle backups and recovery - Manage CI/CD pipelines - Scale systems as needed - Respond to production incidents - Create deployment procedures
Key Permissions:
DEPLOYMENT:
✓ VIEW_BUILD_LOGS
✓ APPROVE_DEPLOYMENT_TO_STAGING
✓ DEPLOY_TO_STAGING
✓ DEPLOY_TO_PRODUCTION (with approval)
✓ PERFORM_ROLLBACK
✓ MANAGE_DEPLOYMENT_PIPELINES
INFRASTRUCTURE:
✓ MANAGE_SERVERS
✓ MANAGE_DATABASES
✓ MANAGE_STORAGE
✓ CONFIGURE_NETWORKS
✓ MANAGE_LOAD_BALANCERS
✓ MANAGE_CACHING_SYSTEMS
MONITORING:
✓ VIEW_SERVER_LOGS
✓ VIEW_ERROR_LOGS
✓ VIEW_SYSTEM_METRICS
✓ VIEW_PERFORMANCE_DATA
✓ CREATE_ALERTS
✓ MODIFY_ALERTS
BACKUP & RECOVERY:
✓ CREATE_BACKUPS
✓ RESTORE_FROM_BACKUPS
✓ MANAGE_BACKUP_POLICIES
✓ TEST_DISASTER_RECOVERY
VISIBILITY:
✓ VIEW_AUDIT_LOG (deployment related)
✓ VIEW_APPLICATION_LOGS
✓ VIEW_SYSTEM_HEALTH_STATUS
What They CANNOT Do:
✗ Cannot modify code
✗ Cannot approve code changes
✗ Cannot create roles/users
✗ Cannot access customer data
✗ Cannot modify security policies
Level 8: Product Manager
Description: Business and product decision maker
Typical Responsibilities: - Decide what features to build - Prioritize work based on business value - Communicate with stakeholders - Define requirements - View progress and metrics - Make release decisions
Key Permissions:
PROJECT MANAGEMENT:
✓ CREATE_PROJECTS
✓ MODIFY_PROJECT_DETAILS
✓ VIEW_PROJECT_STATUS
✓ CREATE_MILESTONES
✓ SET_RELEASE_DATES
✓ PRIORITIZE_FEATURES
✓ UPDATE_ROADMAP
TASK MANAGEMENT:
✓ CREATE_TASKS
✓ MODIFY_TASK_DESCRIPTION
✓ ASSIGN_TASKS_TO_TEAMS
✓ SET_TASK_PRIORITY
✓ VIEW_ALL_TASKS
✓ TRACK_TASK_STATUS
REQUIREMENTS:
✓ CREATE_REQUIREMENTS
✓ MODIFY_REQUIREMENTS
✓ VIEW_REQUIREMENTS_TRACEABILITY
✓ APPROVE_REQUIREMENTS
REPORTING:
✓ VIEW_PROJECT_METRICS
✓ VIEW_BURN_DOWN_CHARTS
✓ VIEW_VELOCITY_REPORTS
✓ GENERATE_STATUS_REPORTS
✓ VIEW_ROADMAP
VISIBILITY:
✓ VIEW_TEAM_ASSIGNMENTS
✓ VIEW_PROJECT_BACKLOG
✓ VIEW_RELEASE_PLANS
What They CANNOT Do:
✗ Cannot write code
✗ Cannot modify code
✗ Cannot deploy
✗ Cannot modify technical documentation
✗ Cannot access system admin features
Level 9: Executive / Stakeholder
Description: High-level visibility and decision authority
Typical Responsibilities: - View project status and KPIs - Make strategic decisions - See financial impacts - Approve major releases - Attend status meetings
Key Permissions:
VISIBILITY:
✓ VIEW_PROJECT_SUMMARIES
✓ VIEW_KEY_METRICS
✓ VIEW_EXECUTIVE_DASHBOARD
✓ VIEW_ROADMAP
✓ VIEW_RELEASE_SCHEDULE
✓ VIEW_BUDGET_INFORMATION
✓ VIEW_RISK_ASSESSMENTS
REPORTING:
✓ VIEW_STATUS_REPORTS
✓ VIEW_KPI_DASHBOARDS
✓ VIEW_FINANCIAL_SUMMARIES
✓ GENERATE_EXECUTIVE_REPORTS
DECISIONS:
✓ APPROVE_MAJOR_FEATURES
✓ APPROVE_LARGE_EXPENDITURES
✓ APPROVE_ORGANIZATIONAL_CHANGES
What They CANNOT Do:
✗ Cannot write code
✗ Cannot modify requirements
✗ Cannot assign work
✗ Cannot deploy
✗ Cannot access detailed technical information
✗ Cannot modify system settings
3. Permission Matrix Quick Reference
Code Repository Access
┌─────────────────────────────────────────────────────────────────┐
│ CODE REPOSITORY PERMISSIONS MATRIX │
├──────────────────────┬──────┬──────┬──────┬──────┬──────┬────────┤
│ Permission │Admin │TLead │Sr. │Mid │Jr. │QA │
├──────────────────────┼──────┼──────┼──────┼──────┼──────┼────────┤
│ READ_CODE │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │
│ WRITE_CODE │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │ ✗ │
│ APPROVE_CODE │ ✓ │ ✓ │ ✓ │ ✗ │ ✗ │ ✗ │
│ MERGE_TO_MAIN │ ✓ │ ✓ │ ✗ │ ✗ │ ✗ │ ✗ │
│ DELETE_CODE │ ✓ │ ✗ │ ✗ │ ✗ │ ✗ │ ✗ │
│ MANAGE_BRANCHES │ ✓ │ ✓ │ ✗ │ ✗ │ ✗ │ ✗ │
│ DELETE_REPOSITORY │ ✓ │ ✗ │ ✗ │ ✗ │ ✗ │ ✗ │
└──────────────────────┴──────┴──────┴──────┴──────┴──────┴────────┘
Testing and Deployment Access
┌──────────────────────────────────────────────────────────────┐
│ TESTING & DEPLOYMENT PERMISSIONS MATRIX │
├──────────────────────┬──────┬──────┬──────┬──────┬──────┬────┤
│ Permission │Admin │TLead │Sr. │QA │DevOps│Jr. │
├──────────────────────┼──────┼──────┼──────┼──────┼──────┼────┤
│ RUN_UNIT_TESTS │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │
│ RUN_INTEGRATION_TEST │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │ ✗ │
│ RUN_PERFORMANCE_TEST │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │ ✗ │
│ DEPLOY_TO_STAGING │ ✓ │ ✓ │ ✗ │ ✗ │ ✓ │ ✗ │
│ DEPLOY_TO_PRODUCTION │ ✓ │ ✗ │ ✗ │ ✗ │ ✓ │ ✗ │
│ APPROVE_DEPLOYMENT │ ✓ │ ✓ │ ✗ │ ✗ │ ✓ │ ✗ │
│ PERFORM_ROLLBACK │ ✓ │ ✗ │ ✗ │ ✗ │ ✓ │ ✗ │
└──────────────────────┴──────┴──────┴──────┴──────┴──────┴────┘
Management and Administration
┌────────────────────────────────────────────────┐
│ MANAGEMENT & ADMIN PERMISSIONS MATRIX │
├──────────────────────┬──────┬──────┬──────────┤
│ Permission │Admin │Mgr │Exec │
├──────────────────────┼──────┼──────┼──────────┤
│ CREATE_USER │ ✓ │ ✗ │ ✗ │
│ DELETE_USER │ ✓ │ ✗ │ ✗ │
│ MANAGE_ROLES │ ✓ │ ✗ │ ✗ │
│ ASSIGN_ROLES │ ✓ │ ✓* │ ✗ │
│ VIEW_AUDIT_LOG │ ✓ │ ✓** │ ✗ │
│ SYSTEM_CONFIGURATION │ ✓ │ ✗ │ ✗ │
│ APPROVE_MAJOR_RELEASE│ ✓ │ ✓ │ ✓ │
│ APPROVE_LARGE_SPEND │ ✓ │ ✓** │ ✓ │
└──────────────────────┴──────┴──────┴──────────┘
* Manager can assign to team members only
** Manager can view own team's activities only
4. Resource Access Control
Code Repositories
Resource: Source code in Git repositories
Access Control:
Public Repositories:
├─ Read: Everyone (all authenticated users)
├─ Write: Developers only
├─ Approve: Senior devs and above
└─ Delete: Admins only
Private Repositories:
├─ Read: Team members + managers
├─ Write: Team members
├─ Approve: Senior devs / Tech leads
└─ Delete: Admins only
Sensitive Repositories (security, keys, etc.):
├─ Read: Authorized personnel only
├─ Write: Restricted to specific people
├─ Approve: Security team + admin
└─ Delete: Admin only with audit trail
Databases
Resource: Production and staging databases
Access Control:
Production Database:
├─ Read: Only DevOps (with logged queries)
├─ Write: DevOps only (for maintenance)
├─ Delete: Never (archive instead)
└─ Access: Restricted IP, VPN, MFA required
Staging Database:
├─ Read: DevOps, QA (with approval)
├─ Write: DevOps, limited QA
├─ Delete: DevOps only
└─ Access: Team network only
Development Database:
├─ Read: All developers
├─ Write: All developers
└─ Delete: All developers
Servers and Infrastructure
Resource: Production and staging servers
Access Control:
Production Servers:
├─ Read: DevOps only (with logging)
├─ Configure: DevOps with approval
├─ Deploy: DevOps with approval
├─ Access: SSH key + MFA required
└─ Monitoring: All ops staff
Staging Servers:
├─ Read: DevOps, QA
├─ Configure: DevOps
├─ Deploy: DevOps, Tech Lead
└─ Access: VPN + SSH key
Development Servers:
├─ Read: All developers
├─ Configure: Senior devs
├─ Deploy: All developers
└─ Access: Network login
Project Management
Resource: Tasks, issues, milestones
Access Control:
All Tasks:
├─ Read: All team members
├─ Create: Tech lead, Product manager
├─ Modify: Owner, Tech lead, Manager
├─ Assign: Tech lead, Manager
└─ Close: Owner, Tech lead
Sensitive Tasks (security, financials):
├─ Read: Authorized personnel only
├─ Create: Manager + security team
├─ Modify: Restricted access
└─ Assign: Manager approval needed
Documentation
Resource: Technical docs, API docs, wikis
Access Control:
Technical Documentation:
├─ Read: All team members
├─ Create: Any developer
├─ Modify: Author, Senior devs, Tech lead
└─ Delete: Tech lead, Admin
API Documentation:
├─ Read: All developers, QA
├─ Create: Senior devs, Tech lead
├─ Modify: Author, Tech lead
└─ Delete: Admin only
Sensitive Documentation (security, architecture):
├─ Read: Senior devs, Tech lead, Managers
├─ Create: Tech lead, Architects
├─ Modify: Tech lead, Architects
└─ Delete: Admin only
5. Implementation Guide
Step 1: Set Up Roles in Your System
In esysflow or your identity management system:
1. System Administrator
- ID: sys_admin
- Level: 1 (highest)
- Parent: None
2. Engineering Manager / Tech Lead
- ID: tech_lead
- Level: 2
- Parent: sys_admin
3. Senior Developer
- ID: senior_dev
- Level: 3
- Parent: tech_lead
4. Mid-Level Developer
- ID: mid_dev
- Level: 4
- Parent: senior_dev
5. Junior Developer
- ID: jr_dev
- Level: 5
- Parent: mid_dev
6. QA Engineer
- ID: qa_eng
- Level: 3
- Parent: tech_lead
7. DevOps Engineer
- ID: devops_eng
- Level: 2
- Parent: sys_admin
8. Product Manager
- ID: product_mgr
- Level: 2
- Parent: None
9. Executive / Stakeholder
- ID: executive
- Level: 2
- Parent: None
Step 2: Assign Permissions to Roles
Example: Senior Developer Role
role:
id: senior_dev
name: Senior Developer
description: Advanced developer with code review authority
permissions:
code_management:
- READ_CODE_REPOSITORY
- WRITE_CODE_TO_BRANCHES
- CREATE_FEATURE_BRANCHES
- DELETE_PERSONAL_BRANCHES
- SUBMIT_PULL_REQUESTS
- REVIEW_PULL_REQUESTS
testing:
- RUN_UNIT_TESTS
- RUN_INTEGRATION_TESTS
- VIEW_TEST_RESULTS
- CREATE_TEST_CASES
environment:
- ACCESS_STAGING_ENVIRONMENT
- DEBUG_IN_STAGING
- VIEW_STAGING_LOGS
documentation:
- CREATE_API_DOCUMENTATION
- MODIFY_API_DOCUMENTATION
visibility:
- VIEW_BUILD_LOGS
- VIEW_PROJECT_STATUS
Step 3: Assign Users to Roles
Example User Assignments:
Users:
├─ john@company.com
│ └─ Role: Tech Lead (senior_dev + management permissions)
│
├─ priya@company.com
│ └─ Role: Senior Developer (sr_dev)
│
├─ alex@company.com
│ └─ Role: Mid-level Developer (mid_dev)
│
├─ emma@company.com
│ └─ Role: Junior Developer (jr_dev)
│
├─ sam@company.com
│ └─ Role: QA Engineer (qa_eng)
│
├─ marcus@company.com
│ └─ Role: DevOps Engineer (devops_eng)
│
├─ rachel@company.com
│ └─ Role: Product Manager (product_mgr)
│
└─ david@company.com
└─ Role: System Administrator (sys_admin)
Step 4: Configure Access for Each Environment
Development Environment:
Access:
├─ Developers: Full access (read/write/delete)
├─ QA: Read/test access
├─ Product: Read-only
└─ Managers: Read-only
SSH Access: All developers
VPN: Required
Auth: Username/password or SSH key
Staging Environment:
Access:
├─ Developers: Limited (read only usually)
├─ QA: Full testing access
├─ DevOps: Full access
├─ Managers: Read-only
└─ Product: Read-only
SSH Access: DevOps only
VPN: Required
Auth: SSH key + MFA
Logging: All access logged
Production Environment:
Access:
├─ Developers: NO direct access
├─ QA: NO access
├─ DevOps: Full access (with approval)
├─ Managers: NO access
├─ Product: NO access
└─ Executive: Monitoring dashboard only
SSH Access: DevOps only
VPN: Required
Auth: SSH key + MFA + 2FA
Logging: All access logged, reviewed monthly
Approval: Change approvals required
Audit Trail: Complete and immutable
6. User Workflows
Workflow 1: New Feature Development
Timeline: 2-3 weeks Team: Senior Dev, 2 Mid-level Devs, Tech Lead, QA, DevOps
WEEK 1: PLANNING
─────────────────
Product Manager:
1. Creates feature requirement
2. Gets tech lead approval on approach
3. Assigns to tech lead for scheduling
Tech Lead:
1. Reviews requirements
2. Creates tasks for team
3. Assigns developers (1 senior, 2 mid-level)
4. Sets deadlines
WEEK 2: DEVELOPMENT
────────────────────
Senior Developer:
1. Creates architecture
2. Writes core logic
3. Writes integration tests
4. Reviews junior devs' code
Mid-level Devs (2 people):
1. Create feature branches
2. Write features following architecture
3. Write unit tests
4. Submit pull requests
5. Address code review feedback
All Developers:
1. Run local unit tests: ✓ Pass
2. Commit to feature branches
3. Submit PRs for review
Tech Lead:
1. Reviews all pull requests
2. Approves/requests changes
3. Merges approved PRs to main branch
4. Verifies automated tests pass
QA:
1. Starts testing in development
2. Finds minor bugs
3. Reports to developers
4. Developers fix bugs
WEEK 3: TESTING & RELEASE
──────────────────────────
QA:
1. Comprehensive testing in staging
2. Tests on Chrome, Firefox, Safari
3. Tests on desktop and mobile
4. Tests all edge cases
5. Reports all bugs found
Developers:
1. Fix bugs reported by QA
2. Update code in main branch
Tech Lead:
1. Reviews final code quality
2. Confirms all tests pass
3. Approves feature for release
DevOps:
1. Creates deployment package
2. Deploys to staging for QA
3. QA verifies feature in staging ✓
Tech Lead:
1. Approves release to production
DevOps:
1. Creates backup
2. Deploys to production
3. Monitors system health
4. Verifies feature live ✓
Product Manager:
1. Communicates feature to customers
2. Updates website/marketing
RESULT: Feature successfully released ✓
Workflow 2: Bug Fix (Critical Production Bug)
Timeline: 4 hours (emergency) Team: Tech Lead, Senior Dev, QA, DevOps
HOUR 0: ALERT
──────────────
Alert System:
1. Monitoring detects error spike
2. Alerts DevOps immediately
DevOps:
1. Investigates issue
2. Isolates to payment module
3. Creates emergency ticket
4. Notifies tech lead
Tech Lead:
1. Receives urgent notification
2. Calls emergency meeting
3. Assigns senior dev immediately
Product Manager:
1. Gets notified
2. Prepares customer communication
HOUR 1: DIAGNOSIS
──────────────────
Senior Developer:
1. Reviews error logs
2. Identifies root cause: payment API timeout
3. Creates hotfix branch: hotfix/payment-timeout
4. Writes fix
5. Writes test case that catches this bug
6. Tests locally: ✓ Passes
Tech Lead:
1. Reviews code immediately
2. Approves quickly ✓
HOUR 2: TESTING
────────────────
QA:
1. Tests fix in staging
2. Verifies payment now works
3. Confirms no side effects
4. Signs off ✓
DevOps:
1. Creates backup of production
2. Reviews deployment plan
HOUR 3: DEPLOYMENT
────────────────────
Tech Lead:
1. Approves emergency deployment
DevOps:
1. Deploys hotfix to production
2. Monitors closely
3. Confirms fix working ✓
4. Rolls back if issues (automatic)
Tech Lead:
1. Verifies payment working
2. Closes emergency ticket
Product Manager:
1. Sends customer update: "Issue resolved"
HOUR 4: FOLLOW-UP
──────────────────
Tech Lead:
1. Schedules post-mortem
2. Plans permanent fix
Senior Dev:
1. Creates backlog item for better monitoring
2. Plans additional tests
DevOps:
1. Creates alert for future issues
2. Updates incident log
RESULT: Production issue fixed in 4 hours ✓
Workflow 3: Security Vulnerability Found
Timeline: 2-4 hours (urgent)
Alert Source:
- Automated security scan
- Penetration tester
- Bug bounty report
- Code review finding
STEP 1: CLASSIFICATION (15 min)
─────────────────────────────────
Security Team:
1. Receives vulnerability report
2. Assesses severity (Critical, High, Medium, Low)
3. Creates urgent ticket if Critical/High
4. Notifies tech lead immediately
Tech Lead:
1. Reviews vulnerability details
2. Confirms impact
3. Prioritizes above all other work
STEP 2: FIX DEVELOPMENT (30-60 min)
────────────────────────────────────
Senior Developer:
1. Gets detailed vulnerability description
2. Locates affected code
3. Develops fix
4. Writes test that catches vulnerability
5. Tests fix locally
Code Review:
1. Tech lead + security team review
2. Approve quickly if fix is solid
STEP 3: TESTING (15-30 min)
──────────────────────────────
QA + Security Team:
1. Test that fix works
2. Confirm vulnerability is gone
3. Verify no side effects
DevOps:
1. Prepares emergency deployment
STEP 4: DEPLOYMENT (15-30 min)
────────────────────────────────
Tech Lead:
1. Approves emergency deployment
DevOps:
1. Creates backup
2. Deploys fix to production immediately
3. Monitors closely
4. Verifies fix working
Security Team:
1. Re-runs security scan
2. Confirms vulnerability fixed ✓
STEP 5: COMMUNICATION (ongoing)
─────────────────────────────────
Security Team:
1. Documents vulnerability
2. Updates security log
3. Prepares incident report
Executives:
1. Get notified if breach occurred
2. Customer communication prepared
Product Manager:
1. Updates status if needed
RESULT: Security vulnerability patched ✓
Audit Trail: Complete documentation of fix
7. Access Management Procedures
Adding a New User
Process: HR → System Admin → Role Assignment
STEP 1: HR SUBMITS REQUEST
──────────────────────────
HR Department:
1. New employee starts date: 2025-12-16
2. Position: Mid-level Developer
3. Team: Backend Team
4. Manager: Sarah (Tech Lead)
5. Submits to System Admin via form
STEP 2: SYSTEM ADMIN CREATES ACCOUNT
──────────────────────────────────────
System Admin:
1. Creates user account in system
- Username: priya.singh@company.com
- Email: priya.singh@company.com
- Full Name: Priya Singh
- Department: Engineering
- Manager: Sarah
2. Assigns default password (expires on first login)
3. Sets role: Mid-level Developer (mid_dev)
- Automatically grants permissions:
✓ READ_CODE_REPOSITORY
✓ WRITE_CODE_TO_BRANCHES
✓ CREATE_FEATURE_BRANCHES
✓ RUN_UNIT_TESTS
etc.
4. Adds to team in project management
- Backend Team Project
- Access level: Developer
5. Logs action in audit trail:
"User 'priya.singh@company.com' created by system_admin
Role assigned: mid_dev
Date: 2025-12-16"
STEP 3: USER CONFIRMS ACCESS
──────────────────────────────
New Employee (Priya):
1. Receives email with temporary password
2. Logs in to esysflow
3. Changes password to permanent one
4. Enables MFA (if required)
5. Tests access:
- Can access code repository? ✓
- Can see assigned tasks? ✓
- Can access development environment? ✓
Manager (Sarah):
1. Confirms Priya has correct access
2. Provides team overview
3. Assigns first task
STEP 4: ONBOARDING COMPLETE
────────────────────────────
Tech Lead (Sarah):
1. Verifies permissions are correct
2. Adds Priya to team meetings
3. Assigns mentor (senior dev)
System Admin:
1. Logs onboarding completion
2. Updates access records
3. Sends security training email
RESULT: New user successfully onboarded with correct access ✓
Changing User Role
Process: Manager → Tech Lead → System Admin
Scenario: Priya promoted from Mid-level to Senior Developer
STEP 1: APPROVAL
────────────────
Tech Lead (Sarah):
1. Decides Priya is ready for promotion
2. Sends promotion approval form
3. HR approves promotion
4. Sets effective date: 2025-12-31
STEP 2: SYSTEM ADMIN UPDATES
──────────────────────────────
System Admin:
1. Updates user role:
FROM: mid_dev (Mid-level Developer)
TO: senior_dev (Senior Developer)
2. Automatically grants new permissions:
+ REVIEW_PULL_REQUESTS
+ APPROVE_CODE_QUALITY
+ MENTOR_JUNIOR_DEVS
+ RUN_INTEGRATION_TESTS
+ ACCESS_STAGING_ENVIRONMENT
3. Logs role change in audit trail:
"User 'priya.singh@company.com' promoted
Old Role: mid_dev
New Role: senior_dev
Changed by: system_admin
Date: 2025-12-31
Reason: Promotion to Senior Developer"
STEP 3: VERIFICATION
─────────────────────
Priya:
1. Logs in and confirms new permissions
2. Can now review pull requests ✓
3. Can access staging environment ✓
Tech Lead (Sarah):
1. Confirms Priya can perform new role duties
2. Adjusts assignments as needed
STEP 4: CELEBRATION
────────────────────
Team:
1. Acknowledges Priya's promotion
2. Mentions in team meeting
System Admin:
1. Logs completion in HR system
RESULT: User successfully promoted with correct new permissions ✓
Removing User Access (Termination)
Process: HR → Manager → System Admin → DevOps
Scenario: Developer John is leaving company
STEP 1: HR NOTIFIES (T-2 weeks)
─────────────────────────────────
HR:
1. Informs tech lead of departure date: 2025-12-31
2. Schedules exit interview
3. Notifies system admin
Tech Lead (Sarah):
1. Plans knowledge transfer
2. Reassigns tasks
3. Collects work files
4. Schedules final code review
STEP 2: SYSTEM ADMIN PREPARES (T-1 day)
────────────────────────────────────────
System Admin:
1. Creates backup of John's files:
- Commits in repository
- Email archive
- Project files
2. Notifies all services:
- Git repository host (GitHub/GitLab)
- Project management tool (Jira)
- Collaboration tool (Slack)
- Email system
- VPN system
- All applications
3. Prepares deprovisioning checklist
STEP 3: TERMINATION DATE (T+0)
──────────────────────────────
System Admin (IMMEDIATE):
1. Disables all accounts:
- esysflow account: DISABLED ✓
- Email: DISABLED ✓
- GitHub access: REMOVED ✓
- VPN access: REVOKED ✓
- Physical badge: DEACTIVATED ✓
2. Revokes all permissions:
- Removes from all roles
- Removes from all teams
- Revokes API keys
- Removes SSH keys
- Clears session tokens
3. Logs all deprovisioning:
"User 'john.smith@company.com' deprovisioned
Termination date: 2025-12-31
All access removed: [lists all]
Performed by: system_admin
Time: 16:00"
DevOps (Marcus):
1. Removes John's SSH keys from servers
2. Revokes access tokens
3. Backs up any relevant logs
4. Confirms removal:
- John cannot SSH into production ✓
- John cannot access staging ✓
- John cannot deploy anything ✓
STEP 4: VERIFICATION (T+1 day)
───────────────────────────────
System Admin:
1. Verifies John's account completely disabled
2. Tests each system:
- Can he log in? NO ✓
- Can he access code? NO ✓
- Can he access projects? NO ✓
- Can he send email? NO ✓
3. Confirms all data archived:
- Email backed up ✓
- Files backed up ✓
- Code committed ✓
- Audit trail complete ✓
Tech Lead (Sarah):
1. Confirms all knowledge transferred
2. Reassigned work complete
3. Confirms John's access removed
STEP 5: FINAL CLEANUP (T+30 days)
──────────────────────────────────
System Admin:
1. After 30 days, permanently remove account
(keeping archive)
2. Final audit:
- No stray access remaining
- Complete audit trail maintained
- All data properly archived
HR:
1. Confirms employee records updated
2. Archives employment records
RESULT: User access completely removed while maintaining audit trail ✓
Emergency Access (Crisis Response)
Process for critical production incidents
Scenario: Production database corruption at 2 AM
STEP 1: EMERGENCY ALERT
────────────────────────
Monitoring System:
1. Detects issue at 02:15 AM
2. Alerts on-call DevOps engineer
3. Pages entire on-call team
STEP 2: CRISIS TEAM ACTIVATED
──────────────────────────────
On-call Team:
1. Senior DevOps: On-call manager
2. Database Admin: On-call specialist
3. Tech Lead: Senior engineer on-call
STEP 3: EMERGENCY ACCESS GRANTED
──────────────────────────────────
On-call Manager:
1. Identifies who needs access
2. Calls System Admin (or uses emergency protocol)
System Admin (or automated emergency system):
1. Grants temporary elevated access
2. Database Admin gets:
- FULL_PRODUCTION_DATABASE_ACCESS (temporary)
- PRODUCTION_SERVER_ROOT_ACCESS (temporary)
3. Tech Lead gets:
- PRODUCTION_ACCESS_FOR_DEBUGGING (temporary)
4. Logs emergency access:
"EMERGENCY ACCESS GRANTED
User: Database Admin
Resources: Production database
Reason: Database corruption - 02:15 AM incident
Duration: 1 hour
Approved by: On-call Manager
Timestamp: 02:16 AM"
STEP 4: CRISIS RESPONSE
────────────────────────
Database Admin:
1. Investigates corruption
2. Identifies root cause
3. Restores from backup
4. Verifies data integrity
Tech Lead:
1. Monitors recovery
2. Confirms system stability
3. Validates application working
STEP 5: POST-INCIDENT
──────────────────────
When emergency resolved (03:30 AM):
1. Emergency access AUTOMATICALLY EXPIRES
2. System logs all actions taken
3. Complete audit trail created
STEP 6: INVESTIGATION
──────────────────────
Next business day:
1. System Admin reviews emergency access logs
2. Tech Lead explains incident details
3. Root cause analysis conducted
4. Prevention plan created
5. Documentation updated
6. Emergency access procedures reviewed
RESULT: Critical incident resolved with documented emergency access ✓
8. Security Best Practices
Password Policy
Requirements:
- Minimum 12 characters
- Must include: UPPERCASE, lowercase, numbers, special chars
- No dictionary words
- No consecutive characters (aaa, 123)
- Cannot reuse last 5 passwords
- Must change every 90 days
- Expires after 90 days of inactivity
- Account locks after 5 failed attempts (30-min lockout)
Multi-Factor Authentication (MFA)
Required for:
✓ System Administrators: REQUIRED
✓ Tech Leads: REQUIRED
✓ Senior Developers: REQUIRED (especially for production)
✓ DevOps Engineers: REQUIRED
✓ All production access: REQUIRED
✓ All admin access: REQUIRED
Supported Methods:
- Authenticator app (Google Authenticator, Authy)
- SMS text message (as backup only)
- Hardware security keys (FIDO2)
- Biometric (fingerprint, face ID)
Audit Logging
Log all:
✓ User login/logout
✓ Permission changes
✓ Role assignments
✓ Access to sensitive data
✓ Code deployments
✓ Database modifications
✓ Configuration changes
✓ Access denials
✓ Emergency access grants/revokes
✓ Failed access attempts
Keep for:
- 7 years for compliance
- Immutable (cannot be deleted or modified)
- Encrypted at rest
- Stored in multiple locations
Access Review Schedule
Frequency:
- Weekly: Monitor failed login attempts
- Monthly: Review emergency access grants
- Quarterly: User-level access reviews (managers sign off)
- Semi-annual: Role-based access audits
- Annual: Comprehensive access audit + compliance review
Process:
1. Generate access report
2. Distribute to managers/owners
3. They verify access is current and appropriate
4. Flag any unnecessary access
5. Remove unnecessary access
6. Document findings
Summary
RBAC in esysflow ensures:
✓ Security: Only authorized people can access sensitive systems ✓ Efficiency: Easy to onboard/offboard users ✓ Accountability: Complete audit trail of who did what ✓ Compliance: Meets regulatory requirements ✓ Scalability: Works from 5 to 5000 users ✓ Consistency: Same rules apply to everyone
Key Takeaways:
- Principle of Least Privilege: Give users only what they need
- Segregation of Duties: One person can't do both sides of a transaction
- Audit Everything: Log all important actions
- Review Regularly: Quarterly access reviews catch problems
- Emergency Procedures: Have processes for critical incidents
- Documentation: Keep everything documented for compliance
Next Steps:
- Implement roles in your system
- Assign permissions to each role
- Train team on their access levels
- Establish audit procedures
- Review quarterly and adjust as needed