tm_back/docs/security/policies/access-control-policy.md

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 | ISMS Foundation §4

---

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.

---

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