# Sicherheitskonzept (RLS - Row Level Security)

RLS ist auf Datenbankebene in Postgres implementiert und erzwingt Datenisolierung:

- **Unternehmen (`companies`)**: Authentifizierte Benutzer dürfen nur die Unternehmen lesen.
- **Endkunden (`end_customers`)**:
  - `USING (partner_id = (SELECT company_id FROM public.users WHERE id = auth.uid()))`
  - Partner sehen und modifizieren nur Endkunden, deren `partner_id` mit der `company_id` des angemeldeten Benutzers übereinstimmt.
- **Bestellungen (`orders`)**:
  - `USING (company_id = (SELECT company_id FROM public.users WHERE id = auth.uid()))`
  - Partner sehen und modifizieren nur Bestellungen, die ihrer Company zugewiesen sind (sie müssen einer Company zugeordnet sein).
  - Jede Bestellung wird bei der Erstellung automatisch der Company des Erstellers zugewiesen.
  - Admins haben uneingeschränkten Zugriff und können Bestellungen nachträglich anderen Companies zuweisen.
- **Lizenzen (`licenses`)**:
  - Partner sehen nur Lizenzen von Endkunden, die ihrer Company zugeordnet sind.

- **Systembenutzer (`users`) & Rollen-Schutz**:
  - Authentifizierte Nutzer dürfen nur ihr eigenes Profil lesen.
  - Admins dürfen alle Benutzer lesen. Zur Vermeidung von unendlichen RLS-Rekursionen auf der Tabelle `users` wird die Admin-Zuweisung über die Security-Definer-Funktion `public.is_admin(user_id)` geprüft, welche RLS auf Datenbank-Ebene umgeht.
  - Rollenschutz-Trigger (`check_user_role_escalation`): Jegliche Änderung der Spalte `role` oder Zuweisung der Rolle `'admin'` ist auf API-Ebene für normale Nutzer gesperrt. Updates/Inserts der Rolle werden ausschließlich von der `service_role` (Backend Admin-Client) akzeptiert, um Privilegien-Eskalation zu verhindern.