Aufsicht und Eingriff getrennt: neuer Haken "Audit-Betrieb"
Die DSGVO-Rolle trug audit:* komplett, also auch audit:admin. Ein DSGVO-Beauftragter konnte damit seal-backlog, rehash und cleanup - seine eigene Beweisgrundlage ersetzen. Wer das Protokoll beaufsichtigt, darf es nicht umschreiben koennen. Dieselbe Klasse wie R184-02: falsche Domaene, zu breit gebuendelt. Der naheliegende Fix waere falsch gewesen. audit:admin einfach aus der DSGVO-Rolle zu streichen haette es heimatlos gemacht: Die Admin-Rolle ist ausdruecklich ohne audit/gdpr gebaut, einzige verbleibende Quelle waere der Entwicklerzugriff - der alles gibt. Prod versiegeln haette dann Vollzugriff vorausgesetzt. Deshalb eine eigene versteckte Rolle "Audit-Betrieb" (audit:read + audit:admin), zugewiesen ueber eine Checkbox wie DSGVO/Entwickler. DSGVO behaelt audit:read + audit:export + gdpr:*. Fuer kein bestehendes Konto weitet sich etwas aus; es wird enger, und wer eingreifen koennen soll, bekommt es ausdruecklich. Keine zusaetzliche Rechte-Huerde davor, weil das am Henne-Ei-Problem scheitert: Nach der Aufteilung haelt zunaechst niemand audit:admin, koennte ihn also auch niemand vergeben. Stattdessen wird die Vergabe laut - CRITICAL im Protokoll und PERMISSION_CHANGED/CRITICAL im Alarmkanal, samt Kennzeichen, ob sich jemand den Haken selbst gesetzt hat. Nebenbei geschlossen: setUserGdprAccess() legte die DSGVO-Rolle im Notfallpfad mit audit:* komplett an - eine zweite Liste, die dasselbe bedeuten sollte und die Buendelung stillschweigend zurueckgebracht haette. ACHTUNG beim Deploy: Bestehende DSGVO-Konten verlieren audit:admin. Wer Prod versiegeln will, muss sich vorher "Audit-Betrieb" ankreuzen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 5
@@ -93,9 +93,34 @@ async function main() {
|
||||
// Developer: alles
|
||||
const developerPermIds = allPermissions.map((p) => p.id);
|
||||
|
||||
// DSGVO: audit + gdpr komplett
|
||||
// DSGVO: Datenschutz-Verwaltung plus LESENDEN Zugriff aufs Audit-Protokoll.
|
||||
//
|
||||
// Bewusst OHNE `audit:admin`. Diese Rolle beaufsichtigt das Protokoll - sie
|
||||
// darf es nicht umschreiben koennen. Mit `audit:admin` haette ein
|
||||
// DSGVO-Beauftragter `seal-backlog`, `rehash` und `cleanup`, also die Mittel,
|
||||
// seine eigene Beweisgrundlage zu ersetzen. Wer prueft und wer eingreift,
|
||||
// sind zwei Rollen (Pentest R186, im Anschluss an R184-02: falsche Domaene,
|
||||
// zu breit gebuendelt).
|
||||
const gdprPermIds = allPermissions
|
||||
.filter((p) => p.resource === 'audit' || p.resource === 'gdpr')
|
||||
.filter(
|
||||
(p) =>
|
||||
p.resource === 'gdpr' ||
|
||||
(p.resource === 'audit' && (p.action === 'read' || p.action === 'export')),
|
||||
)
|
||||
.map((p) => p.id);
|
||||
|
||||
// Audit-Betrieb: die eingreifenden Rechte am Protokoll - versiegeln,
|
||||
// neu berechnen, aufraeumen, Aufbewahrung aendern. Plus `audit:read`, denn
|
||||
// siegeln zu duerfen ohne das Ergebnis sehen zu koennen waere unbrauchbar.
|
||||
//
|
||||
// Eigene versteckte Rolle statt einem Anhaengsel an Admin: So weitet sich
|
||||
// durch die Umstellung fuer KEIN bestehendes Konto etwas aus. Wer eingreifen
|
||||
// koennen soll, bekommt es ausdruecklich - und diese Zuweisung ist selbst
|
||||
// ein sichtbarer Vorgang.
|
||||
const auditBetriebPermIds = allPermissions
|
||||
.filter(
|
||||
(p) => p.resource === 'audit' && (p.action === 'read' || p.action === 'admin'),
|
||||
)
|
||||
.map((p) => p.id);
|
||||
|
||||
// Gegenbuch: NUR audit:read.
|
||||
@@ -152,7 +177,8 @@ async function main() {
|
||||
const rolesSpec: Array<{ name: string; description: string; permIds: number[] }> = [
|
||||
{ name: 'Admin', description: 'Voller Zugriff auf alle Funktionen', permIds: adminPermIds },
|
||||
{ name: 'Developer', description: 'Voller Zugriff inkl. Entwickler-Tools', permIds: developerPermIds },
|
||||
{ name: 'DSGVO', description: 'DSGVO-Zugriff: Audit-Logs und Datenschutz-Verwaltung', permIds: gdprPermIds },
|
||||
{ name: 'DSGVO', description: 'DSGVO-Zugriff: Audit-Logs lesen und Datenschutz-Verwaltung', permIds: gdprPermIds },
|
||||
{ name: 'Audit-Betrieb', description: 'Darf das Audit-Protokoll versiegeln, aufräumen und die Aufbewahrung ändern', permIds: auditBetriebPermIds },
|
||||
{ name: 'Mitarbeiter', description: 'Kann Kunden und Verträge verwalten', permIds: employeePermIds },
|
||||
{ name: 'Mitarbeiter (Nur-Lesen)', description: 'Kann nur lesen, keine Änderungen', permIds: readOnlyPermIds },
|
||||
{ name: 'Gegenbuch', description: 'Darf das Audit-Protokoll nur lesen und prüfen – sonst nichts', permIds: gegenbuchPermIds },
|
||||
|
||||
@@ -3,6 +3,7 @@ import bcrypt from 'bcryptjs';
|
||||
import prisma from '../lib/prisma.js';
|
||||
import * as userService from '../services/user.service.js';
|
||||
import { logChange } from '../services/audit.service.js';
|
||||
import { AUDIT_OPS_ROLLE } from '../services/user.service.js';
|
||||
import { ApiResponse, AuthRequest } from '../types/index.js';
|
||||
import { emit as emitSecurityEvent, contextFromRequest } from '../services/securityMonitor.service.js';
|
||||
import { pickUserCreate, pickUserUpdate, isValidEmail, sanitizePhoneField } from '../utils/sanitize.js';
|
||||
@@ -162,9 +163,26 @@ export async function updateUser(req: AuthRequest, res: Response): Promise<void>
|
||||
...beforeUser,
|
||||
hasGdprAccess: beforeUser.roles.some((ur) => ur.role.name === 'DSGVO'),
|
||||
hasDeveloperAccess: beforeUser.roles.some((ur) => ur.role.name === 'Developer'),
|
||||
hasAuditOpsAccess: beforeUser.roles.some((ur) => ur.role.name === AUDIT_OPS_ROLLE),
|
||||
}
|
||||
: null;
|
||||
|
||||
// Der Audit-Betrieb-Haken vergibt die EINGREIFENDEN Rechte am Protokoll
|
||||
// (versiegeln, neu berechnen, aufraeumen, Aufbewahrung). Ihn zu setzen ist
|
||||
// kein gewoehnliches Benutzer-Update: Er entscheidet, wer die
|
||||
// Beweisgrundlage ersetzen darf.
|
||||
//
|
||||
// Eine eigene Rechte-Huerde davorzusetzen scheitert am Henne-Ei-Problem -
|
||||
// nach der Aufteilung haelt zunaechst niemand `audit:admin`, und dann
|
||||
// koennte ihn auch niemand vergeben. Stattdessen wird die Vergabe LAUT:
|
||||
// CRITICAL im Protokoll und zusaetzlich in den Alarmkanal, so wie beim
|
||||
// Dienstkonto-Kennzeichen (R184-01).
|
||||
const setztAuditBetrieb =
|
||||
data.hasAuditOpsAccess !== undefined &&
|
||||
before !== null &&
|
||||
data.hasAuditOpsAccess !== (before as any).hasAuditOpsAccess;
|
||||
const aktiviertAuditBetrieb = data.hasAuditOpsAccess === true;
|
||||
|
||||
// Das Dienstkonto-Kennzeichen SENKT die Alarmstufe der Anmeldungen dieses
|
||||
// Kontos (Pentest R184). Damit ist es selbst ein Hebel zur Waesche: Wer sein
|
||||
// Konto so markiert, laesst die eigenen auffaelligen Anmeldungen als
|
||||
@@ -236,6 +254,7 @@ export async function updateUser(req: AuthRequest, res: Response): Promise<void>
|
||||
const fieldLabels: Record<string, string> = {
|
||||
email: 'E-Mail', firstName: 'Vorname', lastName: 'Nachname', isActive: 'Aktiv',
|
||||
hasGdprAccess: 'DSGVO-Zugriff', hasDeveloperAccess: 'Entwicklerzugriff',
|
||||
hasAuditOpsAccess: 'Audit-Betrieb (versiegeln, aufräumen, Aufbewahrung)',
|
||||
isServiceAccount: 'Dienstkonto (Anmeldungen als Routine)',
|
||||
};
|
||||
for (const [key, newVal] of Object.entries(data)) {
|
||||
@@ -265,7 +284,7 @@ export async function updateUser(req: AuthRequest, res: Response): Promise<void>
|
||||
: `Benutzer ${user.firstName} ${user.lastName} aktualisiert`,
|
||||
// Die Aenderung dieses Kennzeichens wird wie ihre Wirkung eingestuft:
|
||||
// Sie beeinflusst, wie kuenftige Anmeldungen bewertet werden.
|
||||
sensitivity: setztDienstkonto ? 'CRITICAL' : undefined,
|
||||
sensitivity: setztDienstkonto || setztAuditBetrieb ? 'CRITICAL' : undefined,
|
||||
details: Object.keys(changes).length > 0 ? changes : undefined,
|
||||
});
|
||||
|
||||
@@ -291,6 +310,28 @@ export async function updateUser(req: AuthRequest, res: Response): Promise<void>
|
||||
details: { betroffenesKonto: user.email, aktiviert: aktiviertDienstkonto },
|
||||
});
|
||||
}
|
||||
|
||||
if (setztAuditBetrieb) {
|
||||
const ctx = contextFromRequest(req);
|
||||
emitSecurityEvent({
|
||||
type: 'PERMISSION_CHANGED',
|
||||
severity: 'CRITICAL',
|
||||
message: aktiviertAuditBetrieb
|
||||
? `Konto ${user.email} darf ab jetzt am Audit-Protokoll EINGREIFEN: versiegeln, ` +
|
||||
'neu berechnen, aufräumen, Aufbewahrung ändern. Damit kann es die Grundlage ' +
|
||||
'ersetzen, gegen die Manipulation nachgewiesen wird.'
|
||||
: `Konto ${user.email} darf nicht mehr am Audit-Protokoll eingreifen.`,
|
||||
ipAddress: ctx.ipAddress,
|
||||
userId: req.user?.userId,
|
||||
userEmail: req.user?.email,
|
||||
endpoint: ctx.endpoint,
|
||||
details: {
|
||||
betroffenesKonto: user.email,
|
||||
aktiviert: aktiviertAuditBetrieb,
|
||||
selbstvergabe: user.id === req.user?.userId,
|
||||
},
|
||||
});
|
||||
}
|
||||
} else {
|
||||
await logChange({
|
||||
req, action: 'UPDATE', resourceType: 'User',
|
||||
|
||||
@@ -65,9 +65,10 @@ export async function getAllUsers(filters: UserFilters) {
|
||||
]);
|
||||
|
||||
// Get hidden role IDs
|
||||
const [developerRole, gdprRole] = await Promise.all([
|
||||
const [developerRole, gdprRole, auditOpsRole] = await Promise.all([
|
||||
prisma.role.findFirst({ where: { name: 'Developer' } }),
|
||||
prisma.role.findFirst({ where: { name: 'DSGVO' } }),
|
||||
prisma.role.findFirst({ where: { name: AUDIT_OPS_ROLLE } }),
|
||||
]);
|
||||
|
||||
return {
|
||||
@@ -78,11 +79,15 @@ export async function getAllUsers(filters: UserFilters) {
|
||||
const hasGdprAccess = gdprRole
|
||||
? u.roles.some((ur) => ur.roleId === gdprRole.id)
|
||||
: false;
|
||||
const hasAuditOpsAccess = auditOpsRole
|
||||
? u.roles.some((ur) => ur.roleId === auditOpsRole.id)
|
||||
: false;
|
||||
return {
|
||||
...u,
|
||||
roles: u.roles.map((r) => r.role),
|
||||
hasDeveloperAccess,
|
||||
hasGdprAccess,
|
||||
hasAuditOpsAccess,
|
||||
};
|
||||
}),
|
||||
pagination: buildPaginationResponse(page, limit, total),
|
||||
@@ -146,6 +151,7 @@ export async function createUser(data: {
|
||||
customerId?: number;
|
||||
hasDeveloperAccess?: boolean;
|
||||
hasGdprAccess?: boolean;
|
||||
hasAuditOpsAccess?: boolean;
|
||||
whatsappNumber?: string;
|
||||
telegramUsername?: string;
|
||||
signalNumber?: string;
|
||||
@@ -190,6 +196,10 @@ export async function createUser(data: {
|
||||
await setUserGdprAccess(user.id, true);
|
||||
}
|
||||
|
||||
if (data.hasAuditOpsAccess) {
|
||||
await setUserAuditOpsAccess(user.id, true);
|
||||
}
|
||||
|
||||
return user;
|
||||
}
|
||||
|
||||
@@ -206,12 +216,13 @@ export async function updateUser(
|
||||
customerId?: number;
|
||||
hasDeveloperAccess?: boolean;
|
||||
hasGdprAccess?: boolean;
|
||||
hasAuditOpsAccess?: boolean;
|
||||
whatsappNumber?: string;
|
||||
telegramUsername?: string;
|
||||
signalNumber?: string;
|
||||
}
|
||||
) {
|
||||
const { roleIds, password, hasDeveloperAccess, hasGdprAccess, ...userData } = data;
|
||||
const { roleIds, password, hasDeveloperAccess, hasGdprAccess, hasAuditOpsAccess, ...userData } = data;
|
||||
|
||||
// Check if this would remove the last admin
|
||||
const isBeingDeactivated = userData.isActive === false;
|
||||
@@ -348,6 +359,10 @@ export async function updateUser(
|
||||
await setUserGdprAccess(id, hasGdprAccess);
|
||||
}
|
||||
|
||||
if (hasAuditOpsAccess !== undefined) {
|
||||
await setUserAuditOpsAccess(id, hasAuditOpsAccess);
|
||||
}
|
||||
|
||||
return getUserById(id);
|
||||
}
|
||||
|
||||
@@ -407,6 +422,16 @@ async function setUserDeveloperAccess(userId: number, enabled: boolean) {
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Name der versteckten Rolle fuer eingreifende Audit-Rechte.
|
||||
*
|
||||
* Getrennt von `DSGVO`, weil Aufsicht und Eingriff nicht dieselbe Rolle sein
|
||||
* duerfen: Wer das Protokoll beaufsichtigt, darf seine Beweisgrundlage nicht
|
||||
* ersetzen koennen (Pentest R186). Die Rolle wird von `sync-roles.ts` beim
|
||||
* Containerstart angelegt.
|
||||
*/
|
||||
export const AUDIT_OPS_ROLLE = 'Audit-Betrieb';
|
||||
|
||||
// Helper to set GDPR access for a user
|
||||
async function setUserGdprAccess(userId: number, enabled: boolean) {
|
||||
// Get or create DSGVO role
|
||||
@@ -415,17 +440,24 @@ async function setUserGdprAccess(userId: number, enabled: boolean) {
|
||||
});
|
||||
|
||||
if (!gdprRole) {
|
||||
// Create DSGVO role with all audit:* and gdpr:* permissions
|
||||
// Rechte-Satz identisch zu sync-roles.ts: gdpr komplett, vom Audit-
|
||||
// Protokoll nur LESEN und EXPORTIEREN. Ohne `audit:admin` - sonst
|
||||
// brächte dieser Notfallpfad genau die Bündelung zurück, die wir gerade
|
||||
// aufgelöst haben (zwei Listen, die dasselbe bedeuten sollen, laufen
|
||||
// auseinander).
|
||||
const gdprPermissions = await prisma.permission.findMany({
|
||||
where: {
|
||||
OR: [{ resource: 'audit' }, { resource: 'gdpr' }],
|
||||
OR: [
|
||||
{ resource: 'gdpr' },
|
||||
{ resource: 'audit', action: { in: ['read', 'export'] } },
|
||||
],
|
||||
},
|
||||
});
|
||||
|
||||
gdprRole = await prisma.role.create({
|
||||
data: {
|
||||
name: 'DSGVO',
|
||||
description: 'DSGVO-Zugriff: Audit-Logs und Datenschutz-Verwaltung',
|
||||
description: 'DSGVO-Zugriff: Audit-Logs lesen und Datenschutz-Verwaltung',
|
||||
permissions: {
|
||||
create: gdprPermissions.map((p) => ({ permissionId: p.id })),
|
||||
},
|
||||
@@ -457,6 +489,50 @@ async function setUserGdprAccess(userId: number, enabled: boolean) {
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Eingreifende Audit-Rechte setzen: versiegeln, neu berechnen, aufraeumen,
|
||||
* Aufbewahrung aendern. Bewusst getrennt vom DSGVO-Haken (siehe
|
||||
* `AUDIT_OPS_ROLLE`).
|
||||
*/
|
||||
async function setUserAuditOpsAccess(userId: number, enabled: boolean) {
|
||||
let rolle = await prisma.role.findFirst({ where: { name: AUDIT_OPS_ROLLE } });
|
||||
|
||||
if (!rolle) {
|
||||
// Rechte-Satz identisch zu sync-roles.ts.
|
||||
const rechte = await prisma.permission.findMany({
|
||||
where: { resource: 'audit', action: { in: ['read', 'admin'] } },
|
||||
});
|
||||
rolle = await prisma.role.create({
|
||||
data: {
|
||||
name: AUDIT_OPS_ROLLE,
|
||||
description: 'Darf das Audit-Protokoll versiegeln, aufräumen und die Aufbewahrung ändern',
|
||||
permissions: { create: rechte.map((p) => ({ permissionId: p.id })) },
|
||||
},
|
||||
});
|
||||
}
|
||||
|
||||
const hatRolle = await prisma.userRole.findFirst({
|
||||
where: { userId, roleId: rolle.id },
|
||||
});
|
||||
|
||||
if (enabled && !hatRolle) {
|
||||
await prisma.userRole.create({ data: { userId, roleId: rolle.id } });
|
||||
// Token invalidieren bei Rechteaenderung
|
||||
await prisma.user.update({
|
||||
where: { id: userId },
|
||||
data: { tokenInvalidatedAt: new Date() },
|
||||
});
|
||||
} else if (!enabled && hatRolle) {
|
||||
await prisma.userRole.delete({
|
||||
where: { userId_roleId: { userId, roleId: rolle.id } },
|
||||
});
|
||||
await prisma.user.update({
|
||||
where: { id: userId },
|
||||
data: { tokenInvalidatedAt: new Date() },
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
export async function deleteUser(id: number) {
|
||||
// Check if user is an admin
|
||||
const user = await prisma.user.findUnique({
|
||||
|
||||
@@ -654,6 +654,10 @@ const USER_UPDATABLE_FIELDS = [
|
||||
// stehen, damit pick() sie nicht aus dem Request entfernt.
|
||||
'hasGdprAccess',
|
||||
'hasDeveloperAccess',
|
||||
// Eingreifende Audit-Rechte (versiegeln/aufraeumen/Aufbewahrung), bewusst
|
||||
// getrennt von hasGdprAccess: Aufsicht und Eingriff sind zwei Rollen
|
||||
// (Pentest R186). Mappt auf die versteckte Rolle 'Audit-Betrieb'.
|
||||
'hasAuditOpsAccess',
|
||||
// Nicht: id, customerId, tokenInvalidatedAt, passwordResetToken, passwordResetExpiresAt
|
||||
// Nicht: password – wird über dedizierten Endpoint POST /users/:id/password
|
||||
// gesetzt (Pentest Runde 12 (2026-05-18) – MITTEL: generisches User-Update
|
||||
|
||||
@@ -97,6 +97,43 @@ isolierte Instanz (keine Multi-Tenancy im Code), Provisioning + Abrechnung
|
||||
|
||||
## ✅ Erledigt
|
||||
|
||||
- [x] **⚖️ Aufsicht und Eingriff getrennt: neuer Haken „Audit-Betrieb"** (2026-08-26)
|
||||
- Die DSGVO-Rolle trug `audit:*` **komplett**, also auch `audit:admin`. Ein
|
||||
DSGVO-Beauftragter konnte damit `seal-backlog`, `rehash` und `cleanup` –
|
||||
seine eigene Beweisgrundlage ersetzen. Wer das Protokoll beaufsichtigt,
|
||||
darf es nicht umschreiben können. Dieselbe Klasse wie R184-02: falsche
|
||||
Domäne, zu breit gebündelt.
|
||||
- **Der naheliegende Fix wäre falsch gewesen.** `audit:admin` einfach aus
|
||||
der DSGVO-Rolle zu streichen hätte es heimatlos gemacht: Die Admin-Rolle
|
||||
ist ausdrücklich **ohne** `audit`/`gdpr` gebaut, einzige verbleibende
|
||||
Quelle wäre der Entwicklerzugriff – der *alles* gibt. Prod versiegeln
|
||||
hätte dann Vollzugriff vorausgesetzt.
|
||||
- Deshalb eine eigene versteckte Rolle **`Audit-Betrieb`**
|
||||
(`audit:read` + `audit:admin`), zugewiesen über eine Checkbox wie
|
||||
DSGVO/Entwickler. DSGVO behält `audit:read` + `audit:export` + `gdpr:*`.
|
||||
**Für kein bestehendes Konto weitet sich etwas aus** – im Gegenteil, es
|
||||
wird enger, und wer eingreifen können soll, bekommt es ausdrücklich.
|
||||
- **Keine zusätzliche Rechte-Hürde davor**, weil das am Henne-Ei-Problem
|
||||
scheitert: Nach der Aufteilung hält zunächst niemand `audit:admin`, könnte
|
||||
ihn also auch niemand vergeben. Stattdessen wird die Vergabe **laut** –
|
||||
CRITICAL im Protokoll **und** `PERMISSION_CHANGED`/CRITICAL im Alarmkanal,
|
||||
inklusive Kennzeichen, ob sich jemand den Haken selbst gesetzt hat.
|
||||
- Nebenbei geschlossen: `setUserGdprAccess()` legte die DSGVO-Rolle im
|
||||
Notfallpfad mit `audit:*` komplett an – eine zweite Liste, die dasselbe
|
||||
bedeuten sollte und die Bündelung stillschweigend zurückgebracht hätte.
|
||||
- **⚠️ Beim Deploy:** Bestehende DSGVO-Konten verlieren `audit:admin`. Wer
|
||||
Prod versiegeln will, muss sich vorher „Audit-Betrieb" ankreuzen.
|
||||
- **Gemeldet, nicht geändert:** Jeder mit `users:update` (also Admin) kann
|
||||
sich DSGVO oder Entwicklerzugriff selbst vergeben – Entwickler heißt
|
||||
*alle* Rechte. Das ist vorbestehend und gehört ins Rollenmodell-Thema des
|
||||
Pentesters.
|
||||
- Dateien: `backend/prisma/sync-roles.ts`,
|
||||
`backend/src/services/user.service.ts`,
|
||||
`backend/src/controllers/user.controller.ts`,
|
||||
`backend/src/utils/sanitize.ts`,
|
||||
`frontend/src/pages/users/UserList.tsx`,
|
||||
`frontend/src/services/api.ts`, `tools/audit-notary/README.md`
|
||||
|
||||
- [x] **🏷️ Siegel über null Blättern meldet nicht mehr „intakt"** (2026-08-26)
|
||||
- Ein Bestandssiegel, das zum Zeitpunkt des Siegelns keinen Altbestand
|
||||
vorfand, ist rechnerisch tadellos und schützt **nichts**. Gemeldet wurde
|
||||
|
||||
@@ -121,7 +121,7 @@ export default function UserList() {
|
||||
<td className="py-3 px-4">{user.email}</td>
|
||||
<td className="py-3 px-4">
|
||||
<div className="flex gap-1 flex-wrap">
|
||||
{user.roles?.filter((role: any) => !['Developer', 'Kunde', 'DSGVO'].includes(role.name)).map((role: any) => (
|
||||
{user.roles?.filter((role: any) => !['Developer', 'Kunde', 'DSGVO', 'Audit-Betrieb'].includes(role.name)).map((role: any) => (
|
||||
<Badge key={role.id || role.name} variant="info">
|
||||
{role.name}
|
||||
</Badge>
|
||||
@@ -246,6 +246,7 @@ function UserModal({
|
||||
roleIds: [] as number[],
|
||||
isActive: true,
|
||||
hasDeveloperAccess: false,
|
||||
hasAuditOpsAccess: false,
|
||||
hasGdprAccess: false,
|
||||
isServiceAccount: false,
|
||||
whatsappNumber: '',
|
||||
@@ -264,9 +265,10 @@ function UserModal({
|
||||
currentPassword: '',
|
||||
firstName: user.firstName,
|
||||
lastName: user.lastName,
|
||||
roleIds: user.roles?.filter((r: any) => !['Developer', 'Kunde', 'DSGVO'].includes(r.name)).map((r: any) => r.id) || [],
|
||||
roleIds: user.roles?.filter((r: any) => !['Developer', 'Kunde', 'DSGVO', 'Audit-Betrieb'].includes(r.name)).map((r: any) => r.id) || [],
|
||||
isActive: (user as any).isActive ?? true,
|
||||
hasDeveloperAccess: (user as any).hasDeveloperAccess ?? false,
|
||||
hasAuditOpsAccess: (user as any).hasAuditOpsAccess ?? false,
|
||||
hasGdprAccess: (user as any).hasGdprAccess ?? false,
|
||||
isServiceAccount: (user as any).isServiceAccount ?? false,
|
||||
whatsappNumber: (user as any).whatsappNumber || '',
|
||||
@@ -283,6 +285,7 @@ function UserModal({
|
||||
roleIds: [],
|
||||
isActive: true,
|
||||
hasDeveloperAccess: false,
|
||||
hasAuditOpsAccess: false,
|
||||
hasGdprAccess: false,
|
||||
isServiceAccount: false,
|
||||
whatsappNumber: '',
|
||||
@@ -326,6 +329,7 @@ function UserModal({
|
||||
roleIds: formData.roleIds,
|
||||
isActive: formData.isActive,
|
||||
hasDeveloperAccess: formData.hasDeveloperAccess,
|
||||
hasAuditOpsAccess: formData.hasAuditOpsAccess,
|
||||
hasGdprAccess: formData.hasGdprAccess,
|
||||
isServiceAccount: formData.isServiceAccount,
|
||||
// Das Kennzeichen senkt die Alarmstufe der Anmeldungen dieses Kontos.
|
||||
@@ -369,6 +373,7 @@ function UserModal({
|
||||
lastName: formData.lastName,
|
||||
roleIds: formData.roleIds,
|
||||
hasDeveloperAccess: formData.hasDeveloperAccess,
|
||||
hasAuditOpsAccess: formData.hasAuditOpsAccess,
|
||||
hasGdprAccess: formData.hasGdprAccess,
|
||||
isServiceAccount: formData.isServiceAccount,
|
||||
// Das Kennzeichen senkt die Alarmstufe der Anmeldungen dieses Kontos.
|
||||
@@ -489,7 +494,7 @@ function UserModal({
|
||||
<div>
|
||||
<label className="block text-sm font-medium text-gray-700 mb-2">Rollen</label>
|
||||
<div className="space-y-2">
|
||||
{roles.filter((role) => !['Developer', 'Kunde', 'DSGVO'].includes(role.name)).map((role) => (
|
||||
{roles.filter((role) => !['Developer', 'Kunde', 'DSGVO', 'Audit-Betrieb'].includes(role.name)).map((role) => (
|
||||
<label key={role.id} className="flex items-center gap-2">
|
||||
<input
|
||||
type="checkbox"
|
||||
@@ -533,7 +538,28 @@ function UserModal({
|
||||
<Shield className="w-4 h-4 text-blue-600" />
|
||||
DSGVO-Zugriff
|
||||
</span>
|
||||
<span className="text-sm text-gray-500">(Audit-Logs, Datenschutz)</span>
|
||||
<span className="text-sm text-gray-500">(Audit-Protokoll lesen, Datenschutz)</span>
|
||||
</label>
|
||||
<label className="flex items-start gap-2">
|
||||
<input
|
||||
type="checkbox"
|
||||
checked={formData.hasAuditOpsAccess}
|
||||
onChange={(e) => setFormData({ ...formData, hasAuditOpsAccess: e.target.checked })}
|
||||
className="mt-1 rounded border-amber-300 text-amber-600 focus:ring-amber-500"
|
||||
/>
|
||||
<span>
|
||||
<span className="flex items-center gap-1">
|
||||
<Shield className="w-4 h-4 text-amber-600" />
|
||||
Audit-Betrieb
|
||||
<span className="text-sm text-gray-500">(versiegeln, aufräumen, Aufbewahrung)</span>
|
||||
</span>
|
||||
<span className="block text-sm text-gray-500 mt-0.5">
|
||||
Erlaubt Eingriffe am Audit-Protokoll: Bestandssiegel setzen oder
|
||||
ersetzen, aufräumen, Aufbewahrungsfristen ändern. Bewusst getrennt
|
||||
vom DSGVO-Zugriff – wer das Protokoll beaufsichtigt, soll seine
|
||||
eigene Beweisgrundlage nicht ersetzen können.
|
||||
</span>
|
||||
</span>
|
||||
</label>
|
||||
<label className="flex items-center gap-2">
|
||||
<input
|
||||
|
||||
@@ -1548,11 +1548,12 @@ export const userApi = {
|
||||
const res = await api.get<ApiResponse<User>>(`/users/${id}`);
|
||||
return res.data;
|
||||
},
|
||||
create: async (data: { email: string; password: string; firstName: string; lastName: string; roleIds: number[]; customerId?: number; hasDeveloperAccess?: boolean; hasGdprAccess?: boolean; isServiceAccount?: boolean; confirm?: string; whatsappNumber?: string; telegramUsername?: string; signalNumber?: string }) => {
|
||||
create: async (data: { email: string; password: string; firstName: string; lastName: string; roleIds: number[]; customerId?: number; hasDeveloperAccess?: boolean; hasGdprAccess?: boolean;
|
||||
hasAuditOpsAccess?: boolean; isServiceAccount?: boolean; confirm?: string; whatsappNumber?: string; telegramUsername?: string; signalNumber?: string }) => {
|
||||
const res = await api.post<ApiResponse<User>>('/users', data);
|
||||
return res.data;
|
||||
},
|
||||
update: async (id: number, data: Partial<User> & { password?: string; roleIds?: number[]; isServiceAccount?: boolean; confirm?: string }) => {
|
||||
update: async (id: number, data: Partial<User> & { password?: string; roleIds?: number[]; isServiceAccount?: boolean; hasGdprAccess?: boolean; hasDeveloperAccess?: boolean; hasAuditOpsAccess?: boolean; confirm?: string }) => {
|
||||
const res = await api.put<ApiResponse<User>>(`/users/${id}`, data);
|
||||
return res.data;
|
||||
},
|
||||
|
||||
@@ -195,12 +195,12 @@ Im CRM, als Administrator:
|
||||
4. E-Mail und Passwort in die `.env` des Gegenbuchs eintragen
|
||||
(`PROD_CRM_EMAIL` / `PROD_CRM_PASSWORD`).
|
||||
|
||||
> **Nicht den DSGVO-Haken benutzen.** Der sieht naheliegend aus („Audit-Logs,
|
||||
> Datenschutz"), vergibt aber `audit:` **komplett** – einschließlich
|
||||
> `audit:admin` mit `seal-backlog`, `rehash` und `cleanup`. Ein Einbruch auf
|
||||
> dieser Maschine hätte damit nicht nur den Wächter, sondern gleich die Mittel,
|
||||
> das Bewachte umzuschreiben. Das Passwort steht hier im Klartext in der
|
||||
> `.env`; es muss so wenig wert sein wie möglich.
|
||||
> **Weder den DSGVO- noch den Audit-Betrieb-Haken setzen.** Der DSGVO-Haken
|
||||
> gibt zusätzlich Leserechte auf personenbezogene Daten und den Export; der
|
||||
> Haken „Audit-Betrieb" gibt `audit:admin` mit `seal-backlog`, `rehash` und
|
||||
> `cleanup`. Ein Einbruch auf dieser Maschine hätte damit nicht nur den
|
||||
> Wächter, sondern gleich die Mittel, das Bewachte umzuschreiben. Das Passwort
|
||||
> steht hier im Klartext in der `.env`; es muss so wenig wert sein wie möglich.
|
||||
|
||||
Mit `audit:read` allein kann dieses Konto **nur Prüfwerte lesen** – keine
|
||||
Kundendaten, keine Verträge, nichts ändern und nichts versiegeln. Selbst wenn
|
||||
|
||||
Reference in New Issue
Block a user