Aufbau einer React-Komponente
Meine Vorstellung davon, wie jede React-Komponente aussehen sollte
421
8 min.
Für ihre Arbeit benötigen Mitarbeitende oft geschäftliche E-Mail-Konten, ein CRM, Code-Repositories und Cloud-Speicher. Zugriffe werden häufig einzeln auf Anfrage vergeben. Mit der Zeit sammeln sich Berechtigungen an, die nicht mehr gebraucht werden. Ehemalige Projektbeteiligte können weiterhin aktive Konten haben.
Wird ein Konto kompromittiert oder werden wichtige Daten versehentlich geändert, können zu weitreichende Rechte den möglichen Schaden vergrößern. Zugriffe müssen deshalb während der gesamten Nutzung eines Systems verwaltet werden.
Beim Zugriff gibt es zwei verschiedene Fragen. Die Authentifizierung bestätigt, wer sich angemeldet hat. Die Autorisierung legt fest, welche Aktionen diese Person ausführen darf.
Eine Mitarbeiterin muss zum Beispiel Kundendaten möglicherweise ansehen können, während nur eine bestimmte Gruppe Finanzdaten ändern darf. Diese Grenzen sollten feststehen, bevor einzelne Systeme eingerichtet werden.
Wer Rechte einzeln an jede Person vergibt, verliert mit der Zeit leicht den Überblick darüber, wer Zugriff hat und warum. Ein Rollenmodell erleichtert die Verwaltung. Berechtigungen werden nach Aufgaben gebündelt und Mitarbeitenden werden die passenden Rollen zugewiesen.
Ein Redakteur kann beispielsweise Inhalte erstellen und bearbeiten. Eine Redaktionsleitung kann sie zusätzlich veröffentlichen. Bei RBAC werden Berechtigungen den Rollen zugeordnet und Nutzer erhalten ihren Zugriff über diese Rollen. NIST beschreibt RBAC als Zugriffsverwaltung über Rollen und die zugehörigen Berechtigungen.
Mein Grundsatz ist, Mitarbeitenden von Anfang an nur die Berechtigungen zu geben, die sie für ihre aktuelle Arbeit benötigen. Wird ein weitergehender Zugriff gebraucht, sollte der Antrag erklären, welche Aufgabe ihn erfordert, welche Daten oder Systeme betroffen sind und wie lange der Zugriff benötigt wird.
„Könnte vielleicht nützlich sein“ reicht als Begründung nicht aus. Erweiterte Rechte sollten von der zuständigen Person für das System oder der Projektleitung genehmigt und auf die benötigten Ressourcen begrenzt werden. Sobald die Aufgabe abgeschlossen ist, werden die zusätzlichen Rechte entzogen.
In einer Webanwendung muss jede geschützte Aktion auf dem Server geprüft werden. Eine Schaltfläche in der Oberfläche auszublenden, beschränkt den Zugriff nicht von selbst. Wenn eine Regel für eine neue Aktion noch fehlt, sollte der Zugriff standardmäßig verweigert werden. Diese Vorgehensweisen empfiehlt das OWASP Authorization Cheat Sheet.
Wenn ein Mitarbeiter ein Projekt abgeschlossen hat und nicht weiter daran mitarbeitet, sollte sein Zugriff auf die Projektsysteme sofort entzogen werden. Die nächste regelmäßige Zugriffsprüfung abzuwarten, ist nicht erforderlich. Das betrifft Repositories, Cloud-Umgebungen, Dokumente und weitere Projektressourcen.
Wechselt eine Person in ein anderes Team, sollten die bisherigen Berechtigungen im Zusammenhang mit den neuen Aufgaben überprüft werden. Verlässt jemand die Organisation, müssen das Konto und die Zugriffe auf Unternehmenssysteme sofort deaktiviert werden. Das entspricht dem Kontolebenszyklus, der in NIST SP 800-53, Kontrolle AC-2 beschrieben wird.
Für alltägliche Aufgaben benötigen Mitarbeitende keine Administratorrechte. Erweiterte Berechtigungen sollten nur für Tätigkeiten genutzt werden, die sie tatsächlich erfordern. Für Administrationskonten und den Fernzugriff sollte Mehr-Faktor-Authentifizierung aktiviert sein. CISA empfiehlt außerdem, normale und privilegierte Konten zu trennen und regelmäßig zu prüfen, ob die vergebenen Rechte noch benötigt werden. CISA-Empfehlungen für Organisationen.
Jede Person sollte ein eigenes Konto haben. Gemeinsame Logins erschweren die Zuordnung von Aktionen und die Aufklärung von Fehlern.
Manche Vorgänge benötigen eine zusätzliche Kontrolle. Es ist zum Beispiel riskant, wenn dasselbe Konto eine Zahlung vorbereiten und selbst freigeben kann.
Werden solche Schritte auf mehrere Mitarbeitende verteilt, sinkt das Risiko von Fehlern und Missbrauch. Für jeden wichtigen Ablauf sollte feststehen, wer eine Aktion ausführt und wer sie bestätigt.
Für jedes System sollte klar sein, wer Zugriffe genehmigt, Rollen zuweist und deren Aktualität überprüft. Ein guter Anfang ist eine Übersicht über Systeme, Rollen und die jeweils verantwortlichen Personen.
Prüfen Sie anschließend, wer Administratorrechte hat, ob Konten ehemaliger Projektbeteiligter noch aktiv sind und wie Zugriffe bei einem Aufgabenwechsel oder beim Ausscheiden aus der Organisation behandelt werden.
Zugriffsrechte sollten zur aktuellen Arbeit einer Person passen. Endet die Arbeit, sollten auch die dafür vergebenen Rechte entfallen.
Ähnliche Kategorien:
Meine Vorstellung davon, wie jede React-Komponente aussehen sollte
421
8 min.
Schritt-für-Schritt-Anleitung zum Schutz von VPS unter Ubuntu, zur Konfiguration von Benutzern, SSH-Schlüsseln und der UFW-Firewall. Außerdem Analyse der kritischen React2Shell-Sicherheitslücke in Next.js und Schutzmethoden
268
3 min.
Analyse kritischer Fehler im Webdesign. Warum Slider, Autoplay und schwerfällige Seiten die Konversionsrate sowie die Platzierungen bei Google verschlechtern
232
2 min.
Lösung des Problems mit der Funktion von Vite bei aktiviertem VPN, Konfiguration der Verbindung, um zu verhindern, dass lokaler Datenverkehr in den VPN-Tunnel umgeleitet wird
522
2 min.