Mazyar
06e663b691
- Introduced a comprehensive suite of security documents to support ISO/IEC 27001 certification, including the ISMS Foundation, Risk Assessment Matrix, Gap Analysis Report, Statement of Applicability, and ISO27001 Roadmap. - Updated the README to include links to the new security documentation, enhancing the project's compliance framework and providing clear guidance on security policies and procedures. This addition strengthens the overall security posture of the Tender Management System and aligns with industry standards for information security management.
175 lines
6.4 KiB
Markdown
175 lines
6.4 KiB
Markdown
# Access Control Policy
|
||
|
||
| Field | Value |
|
||
|-------|-------|
|
||
| **Document ID** | POL-002 |
|
||
| **Version** | 1.0 |
|
||
| **Status** | Draft — Pending approval |
|
||
| **Owner** | Information Security Officer (ISO) |
|
||
| **Effective Date** | _Pending approval_ |
|
||
| **Review Cycle** | Annual |
|
||
| **ISO 27001 Reference** | A.5.15–A.5.18 — Access control |
|
||
|
||
Related: [Information Security Policy](./information-security-policy.md) | [ISMS Foundation §4](../ISMS_FOUNDATION.md#4-information-asset-inventory)
|
||
|
||
---
|
||
|
||
## 1. Purpose
|
||
|
||
This policy defines requirements for granting, reviewing, modifying, and revoking access to Tender Management System resources, ensuring that only authorized individuals and services can access information based on business need.
|
||
|
||
---
|
||
|
||
## 2. Scope
|
||
|
||
Applies to access for:
|
||
|
||
- **Admin users** — internal operators of the admin panel (`/admin/v1`)
|
||
- **Customer users** — company representatives using the mobile/public API (`/api/v1`)
|
||
- **Service accounts** — worker, scraper, CI/CD, and integration credentials
|
||
- **Infrastructure access** — MongoDB, Redis, MinIO, deployment environments
|
||
|
||
---
|
||
|
||
## 3. Access Control Principles
|
||
|
||
1. **Least privilege** — minimum access required for the role
|
||
2. **Need-to-know** — access limited to data required for the task
|
||
3. **Separation of duties** — no single person holds unrestricted production access without oversight
|
||
4. **Default deny** — access is denied unless explicitly granted
|
||
5. **Accountability** — all access is attributable to an individual or service identity
|
||
|
||
---
|
||
|
||
## 4. User Access Management
|
||
|
||
### 4.1 Account Provisioning
|
||
|
||
| Step | Requirement |
|
||
|------|-------------|
|
||
| Request | Access request submitted by manager with role justification |
|
||
| Approval | ISO or Engineering Lead approves based on role matrix |
|
||
| Creation | Account created with default-deny; only required permissions assigned |
|
||
| Notification | User receives credentials via secure channel (never email plaintext passwords) |
|
||
| Recording | Access grant logged in access register |
|
||
|
||
### 4.2 Role Matrix — Application Users
|
||
|
||
| Role | System | Permissions |
|
||
|------|--------|-------------|
|
||
| **Admin** | Admin panel API | Full CRUD on users, companies, tenders, CMS, notifications |
|
||
| **Customer Admin** | Public API | Manage company profile, customers within company, view matched tenders |
|
||
| **Customer Analyst** | Public API | View tenders, submit feedback; no user management |
|
||
| **Service: Web API** | MongoDB, Redis, MinIO | Read/write per domain; no direct admin DB access |
|
||
| **Service: Worker** | MongoDB, MinIO, AI API | Read/write tenders; invoke translation jobs |
|
||
| **Service: Scraper** | MongoDB, TED source | Write tenders/notices only |
|
||
|
||
Technical enforcement: JWT role claims and middleware in `pkg/authorization`; company-scoped access for customer roles.
|
||
|
||
### 4.3 Role Matrix — Infrastructure
|
||
|
||
| Role | MongoDB | Redis | MinIO | Production Deploy |
|
||
|------|---------|-------|-------|-------------------|
|
||
| Developer | Staging read/write | Staging | Staging | No |
|
||
| DevOps | Prod read (break-glass write) | Prod | Prod | Yes (with approval) |
|
||
| ISO | Audit read-only | No | No | No |
|
||
|
||
Production database write access requires break-glass procedure (§7).
|
||
|
||
### 4.4 Account Modification
|
||
|
||
- Role changes require re-approval by manager and ISO
|
||
- Privilege elevation is temporary where possible (time-limited tokens)
|
||
|
||
### 4.5 Account Deprovisioning
|
||
|
||
Access must be revoked **within 24 hours** of:
|
||
|
||
- Employment or contract termination
|
||
- Role change removing need for access
|
||
- Extended leave (>30 days) for privileged accounts
|
||
|
||
Checklist: disable admin user account, revoke JWT/refresh tokens (Redis blacklist), remove SSH/infra access, rotate shared secrets if exposed.
|
||
|
||
---
|
||
|
||
## 5. Authentication Requirements
|
||
|
||
### 5.1 Human Users
|
||
|
||
| Requirement | Admin Users | Customer Users |
|
||
|-------------|-------------|----------------|
|
||
| Unique account | Mandatory | Mandatory |
|
||
| Password complexity | Min 12 chars; mixed case, number, symbol | Min 8 chars; mixed case, number |
|
||
| Password storage | bcrypt hash (never plaintext) | bcrypt hash (never plaintext) |
|
||
| MFA | Required (target: Q3 2026) | Recommended |
|
||
| Session/token TTL | Access token ≤ 15 min; refresh rotation | Access token ≤ 1 h; refresh rotation |
|
||
| Failed login lockout | 5 attempts / 15 min lockout | 5 attempts / 15 min lockout |
|
||
| hCaptcha | On registration and password reset | On registration and password reset |
|
||
|
||
### 5.2 Service Accounts
|
||
|
||
- Unique credentials per service and environment
|
||
- Stored in secret manager (not `.env` in production)
|
||
- Rotated at least annually or on personnel change
|
||
- No shared passwords between services
|
||
|
||
### 5.3 API Authentication
|
||
|
||
- All protected endpoints require valid JWT in `Authorization: Bearer` header
|
||
- Public endpoints limited to explicitly whitelisted routes (health, public tender list, contact form with hCaptcha)
|
||
|
||
---
|
||
|
||
## 6. Access Reviews
|
||
|
||
| Review Type | Frequency | Reviewer | Scope |
|
||
|-------------|-----------|----------|-------|
|
||
| Admin user accounts | Quarterly | ISO + Engineering Lead | All active admin users |
|
||
| Customer admin accounts | Semi-annual | Product Owner | Accounts inactive >90 days |
|
||
| Infrastructure access | Quarterly | DevOps Lead | SSH, DB, MinIO, CI/CD |
|
||
| Service account credentials | Semi-annual | DevOps Lead | All non-human identities |
|
||
|
||
Findings are documented and remediated within 30 days.
|
||
|
||
---
|
||
|
||
## 7. Break-Glass Access
|
||
|
||
Emergency production access when normal procedures cannot meet operational need:
|
||
|
||
1. Request logged in incident/ticket system with justification
|
||
2. Approved by DevOps Lead or ISO (second approver if requester is DevOps Lead)
|
||
3. Time-limited (maximum 4 hours)
|
||
4. All actions logged and reviewed within 48 hours post-event
|
||
5. Credentials rotated if break-glass credentials were used
|
||
|
||
---
|
||
|
||
## 8. Remote Access
|
||
|
||
- Production infrastructure accessible only via VPN or bastion host
|
||
- No direct public exposure of MongoDB, Redis, or MinIO ports
|
||
- Admin panel and API served over HTTPS only in production
|
||
|
||
---
|
||
|
||
## 9. Violations
|
||
|
||
Unauthorized access attempts, credential sharing, or bypassing access controls must be reported immediately per the [Incident Response Plan](./incident-response-plan.md).
|
||
|
||
---
|
||
|
||
## 10. Document Control
|
||
|
||
| Version | Date | Author | Changes |
|
||
|---------|------|--------|---------|
|
||
| 1.0 | 2026-06-11 | Engineering | Initial policy |
|
||
|
||
**Approval**
|
||
|
||
| Role | Name | Signature | Date |
|
||
|------|------|-----------|------|
|
||
| ISO | _Pending_ | | |
|
||
| Executive Sponsor | _Pending_ | | |
|