Hartmut/CapaKraken
1
0
Fork 0
Code Issues 10 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

CDP 35948470: Segregation of Duty Access (app) #12

New Issue
Closed
opened 2026-04-16 08:16:46 +02:00 by Hartmut · 2 comments
Hartmut commented 2026-04-16 08:16:46 +02:00
Owner
Copy Link
Copy Source

CDP Control ID: 35948470
Category: Least Privileged Access
Frequency: Biannually
Owner: h.noerenberg
Parent: #1

Requirement & Guidance

Least Privileged Access Requirement: When assigning responsibilities, apply the concept of segregation of duties so that no individual person has access to perform tasks that could create a security conflict of interest (for example: developer/reviewer; developer/tester).If the project follows an Agile/DevOps arrangement and there are not sufficient resources to fully apply segregation of duties, the following compensating controls must be in place:Automated application vulnerability code scans in repositoriesLeast privilege access (e.g. Developers should not be given privileged rights (e.g. Root access) which can allow them to delete change logs and their access should be strictly controlled and restricted with least privilege access)Audit Logging and Monitoring (Strong Logging and Auditing capabilities should be implemented and change control logs should not be edited by developers and should be thoroughly reviewed to identify any unauthorized changes)Guidance: Confirm that segregation of duties is ensured for all critical activities (e.g.: approval for deployment process; development team does not have deployment privilege). Confirm avoidance of conflict of interest (e.g.: developer and reviewer being the same person). Additional information can be found on CDP website Least Privileged AccessFor teams responsible for implementing Oracle ERP, if controls #2 and #3 are in place and the Oracle ERP checklist has been completed, please contact your CDP account manager for a deviation.

**CDP Control ID:** `35948470` **Category:** Least Privileged Access **Frequency:** Biannually **Owner:** h.noerenberg **Parent:** #1 ## Requirement & Guidance Least Privileged Access Requirement: When assigning responsibilities, apply the concept of segregation of duties so that no individual person has access to perform tasks that could create a security conflict of interest (for example: developer/reviewer; developer/tester).If the project follows an Agile/DevOps arrangement and there are not sufficient resources to fully apply segregation of duties, the following compensating controls must be in place:Automated application vulnerability code scans in repositoriesLeast privilege access (e.g. Developers should not be given privileged rights (e.g. Root access) which can allow them to delete change logs and their access should be strictly controlled and restricted with least privilege access)Audit Logging and Monitoring (Strong Logging and Auditing capabilities should be implemented and change control logs should not be edited by developers and should be thoroughly reviewed to identify any unauthorized changes)Guidance: Confirm that segregation of duties is ensured for all critical activities (e.g.: approval for deployment process; development team does not have deployment privilege). Confirm avoidance of conflict of interest (e.g.: developer and reviewer being the same person). Additional information can be found on CDP website Least Privileged AccessFor teams responsible for implementing Oracle ERP, if controls #2 and #3 are in place and the Oracle ERP checklist has been completed, please contact your CDP account manager for a deviation.
Hartmut added the cdpsecurity labels 2026-04-16 08:16:46 +02:00
Hartmut commented 2026-04-16 08:32:37 +02:00
Author
Owner
Copy Link
Copy Source

CapaKraken Action Plan — 35948470 Segregation of Duty

Scope: Kein einzelner Entwickler soll Dev + Review + Test + Prod-Deploy allein ausführen können. Bei kleinen Teams: kompensierende Controls.

Aktueller Stand:

  • Kleines Team (CapaKraken ist aktuell 1-Entwickler-Projekt)
  • CI/CD mit Gitea Actions (Unit/E2E/Lint/Typecheck)

Todos (Kompensierende Controls gem. Guidance):

  • Automated Vulnerability Scans als CI-Pflicht (SAST: Semgrep/CodeQL; DAST: OWASP ZAP baseline) — siehe #28
  • Automated Code Review (bisher nur Lint/Type; Regel: für main Branch ist Merge via Pull Request + CI-Pass zwingend)
  • Branch Protection auf main: Require PR + CI + keine Direct Pushes
  • Dokumentieren: docs/segregation-of-duty.md — warum SoD nicht voll möglich + welche Kompensationen
  • Evidence: Branch-Protection-Settings Screenshot + CI-Konfig

Dateien:

  • .github/workflows/*.yml, Gitea Branch Protection Settings
### CapaKraken Action Plan — 35948470 Segregation of Duty **Scope:** Kein einzelner Entwickler soll Dev + Review + Test + Prod-Deploy allein ausführen können. Bei kleinen Teams: kompensierende Controls. **Aktueller Stand:** - Kleines Team (CapaKraken ist aktuell 1-Entwickler-Projekt) - CI/CD mit Gitea Actions (Unit/E2E/Lint/Typecheck) **Todos (Kompensierende Controls gem. Guidance):** - [ ] Automated Vulnerability Scans als CI-Pflicht (SAST: Semgrep/CodeQL; DAST: OWASP ZAP baseline) — siehe #28 - [ ] Automated Code Review (bisher nur Lint/Type; Regel: für `main` Branch ist Merge via Pull Request + CI-Pass zwingend) - [ ] Branch Protection auf `main`: Require PR + CI + keine Direct Pushes - [ ] Dokumentieren: `docs/segregation-of-duty.md` — warum SoD nicht voll möglich + welche Kompensationen - [ ] Evidence: Branch-Protection-Settings Screenshot + CI-Konfig **Dateien:** - `.github/workflows/*.yml`, Gitea Branch Protection Settings
Hartmut commented 2026-04-16 10:02:26 +02:00
Author
Owner
Copy Link
Copy Source

CapaKraken Compliance-Status

EAPPS-Mapping: 3.2.2.3.11
Status: ✅ OK (laut docs/acn-security-compliance-status.md)

Zusammenfassung

5-stufiges RBAC (Owner/Admin/Manager/Resource/External) mit per-User PermissionKey[]-Overrides. Admin-Procedures sind über adminProcedure/requirePermission gatekeeped.

Nachweis

Entscheidung: Control ist nachweislich erfüllt → Ticket wird geschlossen.

## CapaKraken Compliance-Status **EAPPS-Mapping:** `3.2.2.3.11` **Status:** ✅ **OK** (laut `docs/acn-security-compliance-status.md`) ### Zusammenfassung 5-stufiges RBAC (Owner/Admin/Manager/Resource/External) mit per-User `PermissionKey[]`-Overrides. Admin-Procedures sind über `adminProcedure`/`requirePermission` gatekeeped. ### Nachweis - `SystemRoleConfig.defaultPermissions` + `User.permissionOverrides` — [`packages/db/prisma/schema.prisma`](../blob/main/packages/db/prisma/schema.prisma) (siehe `system_role_configs`) - tRPC `adminProcedure` Middleware — [`packages/api/src/router/`](../blob/main/packages/api/src/router) - UI-seitige Trennung: `/admin/*` nur für Admin-Rollen — [`apps/web/src/middleware.ts`](../blob/main/apps/web/src/middleware.ts) - Compliance-Doc: EAPPS 3.2.2.3.11 = **OK** --- **Entscheidung:** Control ist nachweislich erfüllt → Ticket wird geschlossen.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
cdp
CDP (Client Data Protection) compliance
 epic
Parent/umbrella ticket
 not-applicable
Control does not apply to CapaKraken scope
 security
Security / compliance work
No Label cdp security
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Hartmut
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Hartmut/CapaKraken#12
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?