aiMOOC

Projekt Ersatzteilshop und Werkstattdaten – Berechtigungen im Ersatzteilshop umsetzen

QR-Code

Einleitung

Projekt Ersatzteilshop und Werkstattdaten – Berechtigungen im Ersatzteilshop umsetzen

Zielgruppe: Ausbildung – Fachinformatik, Anwendungsentwicklung und IT-Systemmanagement

Dauer: 7 kurze Lerneinheiten à 10–15 Minuten sowie eine Projektabgabe

Projektziel: Du entwickelst und überprüfst ein Berechtigungskonzept für einen fiktiven Ersatzteilshop mit Werkstattverwaltung.

Dein Auftrag: Ein Ersatzteilshop benötigt drei Benutzerrollen: Kunde, Mitarbeitende und Administration. Jede Rolle erhält nur die Rechte, die sie wirklich benötigt.

Du erstellst ein fortlaufendes Projektdossier mit Skizzen, Rollenmatrix, Implementierung, Simulationen, Testdaten und einer begründeten eigenen Abgabe.

Sicherheitsregel: Arbeite ausschließlich mit erfundenen Daten in lokalen oder ausdrücklich autorisierten Testumgebungen. Verwende keine echten Kundendaten, Passwörter oder Zugangsdaten. Untersuche keine fremden Netze oder Produktivsysteme und übertrage keine Daten ungefragt an externe Dienste.

Dein Ausbildungsfall

Die fiktive Nordwerk Lernwerkstatt verkauft Ersatzteile und verwaltet Werkstattaufträge.

Eine Kundin soll ihre eigene Bestellung ansehen können, aber niemals die Bestellung anderer Personen. Werkstattmitarbeitende sollen Ersatzteilbestände pflegen und nur ihnen zugewiesene Werkstattaufträge bearbeiten. Die Administration soll Rollen verwalten, ohne automatisch sämtliche Kundendaten lesen zu dürfen.

Leitfrage: Wie setzt Du diese Berechtigungen so um, dass sowohl die Benutzeroberfläche als auch die serverseitige Verarbeitung die Regeln einhalten?

Lernziele

Nach dem Kurs kannst Du Authentifizierung und Autorisierung unterscheiden, RBAC erläutern, eine Berechtigungsmatrix entwerfen, objektbezogene Zugriffsregeln umsetzen und mit reproduzierbaren Testfällen überprüfen.

Dein fortlaufendes Projektdossier

Lege lokal einen Ordner mit dem Namen Ersatzteilshop_Dossier an.

Abschnitt	Deine Abgabe
D1 – Anforderungen	Anwendungsfälle und Skizze
D2 – Rollen	Berechtigungsmatrix
D3 – Objekte	Regeln für eigene und fremde Daten
D4 – Umsetzung	Architektur und lokale Simulation
D5 – Prüfdaten	Fiktive Benutzer und Objekte
D6 – Tests	Soll-Ist-Protokoll
D7 – Entscheidung	Begründete Abgabe und Quellen

Arbeitsprinzip: Nach jeder Lerneinheit ergänzt Du Dein Dossier. Bewahre Änderungen und begründete Entscheidungen nachvollziehbar auf.

Lerneinheit 1: Anforderungen verstehen

Zeit: 10 Minuten | Ergebnis: D1

Schritt 1: Die drei Rollen

Rolle	Aufgabe	Schutzbedarf
Kunde	Ersatzteile suchen, eigene Bestellungen verwalten	Fremde Bestellungen bleiben verborgen
Mitarbeitende	Bestand pflegen, zugewiesene Werkstattaufträge bearbeiten	Keine Rollenverwaltung
Administration	Rollen und Berechtigungen verwalten	Kein pauschaler Zugriff auf Werkstatt- und Kundendaten

Merke: Authentifizierung prüft, wer Du bist. Autorisierung entscheidet, was Du tun darfst.

Schritt 2: Anwendungsfälle skizzieren

Video: UML-Anwendungsfalldiagramm für IT-Auszubildende – Stefan Macke

Erstelle ein einfaches Anwendungsfalldiagramm. Zeichne die drei Rollen und verbinde sie mit ihren erlaubten Funktionen.

Basisaufgabe: Ordne jeder Rolle zwei passende Funktionen zu.

Feedback: Eine gute Zuordnung beschreibt die betriebliche Aufgabe, nicht die technische Macht einer Rolle. Administration benötigt deshalb nicht automatisch sämtliche Leserechte.

Dossier D1: Skizze mit drei Akteuren und mindestens sechs Funktionen.

Lerneinheit 2: Berechtigungen modellieren

Zeit: 15 Minuten | Ergebnis: D2

Schritt 1: Rollenbasierte Zugriffskontrolle

Video: Role-Based Access Control Explained – Harness

Bei Role Based Access Control erhalten Benutzer Berechtigungen über ihre zugewiesenen Rollen.

Grundprinzip:

Benutzer
   |
   v
Rolle
   |
   v
Berechtigung
   |
   v
Aktion auf einer Ressource

Beispiel: K-17 besitzt die Rolle Kunde. Diese Rolle erlaubt das Lesen einer eigenen Bestellung. Ob eine bestimmte Bestellung tatsächlich zu K-17 gehört, muss zusätzlich geprüft werden.

Schritt 2: Deine Berechtigungsmatrix

Aktion	Kunde	Mitarbeitende	Administration
Artikel anzeigen	Ja	Ja	Nein
Bestellung anlegen	Ja	Nein	Nein
Eigene Bestellung lesen	Ja	Nein	Nein
Bestand ändern	Nein	Ja	Nein
Zugewiesenen Werkstattauftrag ändern	Nein	Ja	Nein
Rollen zuweisen	Nein	Nein	Ja

Wichtig: Die Rollen sind in diesem Lernmodell bewusst getrennt. Die Administration erhält keine zusätzlichen fachlichen Berechtigungen. Erweiterungen müssen später einzeln begründet und geprüft werden.

Anwendungsaufgabe: Übertrage die Matrix in Dein Dossier und begründe drei verweigerte Zugriffe.

Feedback: Die beste Lösung orientiert sich am Prinzip der geringsten Berechtigungen. Ein Recht ist nur dann angemessen, wenn es für die jeweilige Aufgabe benötigt wird.

Dossier D2: Vollständige Berechtigungsmatrix mit drei Begründungen.

Lerneinheit 3: Eigene und fremde Daten schützen

Zeit: 10 Minuten | Ergebnis: D3

Der Ersatzteilshop führt den fiktiven Artikel E-300 – Bremsbelagsatz.

Schritt 1: Objektbezogene Berechtigungen

Problem: Zwei Personen besitzen dieselbe Kundenrolle. Trotzdem dürfen sie nicht gegenseitig ihre Bestellungen lesen.

Bestellung	Eigentümerkennung
B-701	K-17
B-702	K-18

Entscheidungsregel:

Rolle erlaubt die Aktion?
          |
          v
Gehört die Bestellung
zur angemeldeten Person?
          |
     +----+----+
     |         |
    JA        NEIN
     |         |
 ERLAUBEN  VERWEIGERN

Bei Werkstattaufträgen gilt entsprechend: Bearbeiten darf nur das zugewiesene Werkstattpersonal.

Merke: Eine erlaubte Funktion bedeutet noch nicht, dass jedes Objekt dieser Art freigegeben ist. Hier wird RBAC um eine objektbezogene Regel ergänzt.

Schritt 2: Papier-Simulation

Simuliere die folgenden Entscheidungen ausschließlich auf Papier oder lokal.

Benutzer	Anfrage	Ergebnis
K-17	B-701 lesen	Erlaubt
K-17	B-702 lesen	Verweigert
K-18	B-702 lesen	Erlaubt
M-21	Rollen ändern	Verweigert

Transferfrage: Warum genügt es nicht, eine fremde Bestellnummer lediglich schwer erratbar zu machen?

Begründetes Feedback: Auch unbekannte oder zufällig erzeugte Kennungen ersetzen keine Berechtigungsprüfung. Die Anwendung muss die Zuordnung zu einer berechtigten Person kontrollieren.

Dossier D3: Zwei Zugriffsregeln und vier begründete Entscheidungen.

Lerneinheit 4: Berechtigungen technisch umsetzen

Zeit: 15 Minuten | Ergebnis: D4

Schritt 1: Client und Server unterscheiden

Die Benutzeroberfläche darf nicht die einzige Sicherheitskontrolle sein. Entscheidend ist die Prüfung im Backend bei jeder geschützten Anfrage.

Benutzeroberfläche
       |
       v
Server prüft Sitzung
       |
       v
Server prüft Rolle
       |
       v
Server prüft Objektbezug
       |
       v
Erlauben oder Verweigern

Sicherheitsprinzipien:

Autorisierung: Berechtigungen für jede geschützte Anfrage prüfen.
Minimalprinzip: Nur notwendige Rechte vergeben.
Zugriffskontrolle: Nicht ausdrücklich erlaubte Aktionen verweigern.
Protokollierung: Sicherheitsrelevante Ereignisse datensparsam dokumentieren.

Schritt 2: Lokale Python-Simulation

Die folgende vereinfachte Funktion darfst Du lokal mit fiktiven Daten ausführen. Sie modelliert eine Berechtigungsentscheidung, aber kein vollständiges Anmelde- oder Sicherheitssystem.

RECHTE = {
    "Kunde": {
        "artikel_lesen",
        "bestellung_anlegen",
        "bestellung_lesen"
    },
    "Mitarbeitende": {
        "artikel_lesen",
        "bestand_aendern",
        "auftrag_aendern"
    },
    "Administration": {
        "rollen_zuweisen"
    }
}

def erlaubt(sitzung, aktion, objekt=None):
    if not sitzung.get("geprueft", False):
        return False

    rolle = sitzung.get("rolle")
    nutzer = sitzung.get("nutzer")

    if aktion not in RECHTE.get(rolle, set()):
        return False

    if aktion == "bestellung_lesen":
        return (
            objekt is not None
            and objekt.get("kunde") == nutzer
        )

    if aktion == "auftrag_aendern":
        return (
            objekt is not None
            and objekt.get("zustaendig") == nutzer
        )

    return True

Testbeispiel:

kunde = {
    "geprueft": True,
    "rolle": "Kunde",
    "nutzer": "K-17"
}

eigene_bestellung = {"kunde": "K-17"}
fremde_bestellung = {"kunde": "K-18"}

assert erlaubt(
    kunde, "bestellung_lesen", eigene_bestellung
) is True

assert erlaubt(
    kunde, "bestellung_lesen", fremde_bestellung
) is False

Achtung: Das Feld „geprueft“ ist ausschließlich eine Testannahme. In einer echten Anwendung darf weder dieses Feld noch die Rolle ungeprüft aus Browserdaten übernommen werden. Die Identität muss verlässlich serverseitig festgestellt werden. Auch Objektgültigkeit und Eingaben müssen geprüft werden.

Schritt 3: Fehleranalyse

Anwendungsaufgabe: Entferne gedanklich die Prüfung des Eigentümers aus der Funktion. Beschreibe die fachliche Konsequenz und stelle die korrekte Regel anschließend wieder her.

Feedback: Ohne Eigentümerprüfung könnte K-17 jede Bestellung lesen, sofern sie über die Kundenrolle verfügt. Die Rollenprüfung allein ist daher nicht ausreichend.

Dossier D4: Architektur-Skizze, lokale Funktion und eine begründete Fehlerkorrektur.

Lerneinheit 5: Prüfdaten vorbereiten

Zeit: 10 Minuten | Ergebnis: D5

Schritt 1: Datenbeziehungen verstehen

In einem Entity-Relationship-Modell kannst Du Beziehungen zwischen Benutzer, Bestellung und Werkstattauftrag darstellen.

Modellidee: Eine Bestellung ist genau einer Kundenkennung zugeordnet. Ein Werkstattauftrag besitzt für diesen Ausbildungsfall genau eine zuständige Mitarbeiterkennung.

Schritt 2: Fiktive Testdaten

Kennung	Rolle	Bezug
K-17	Kunde	B-701
K-18	Kunde	B-702
M-21	Mitarbeitende	W-81
M-22	Mitarbeitende	W-82
A-01	Administration	Rollenverwaltung

Objekt	Art	Zuordnung
E-300	Ersatzteil	Bremsbelagsatz
B-701	Bestellung	Kunde K-17
B-702	Bestellung	Kunde K-18
W-81	Werkstattauftrag	Mitarbeitende M-21
W-82	Werkstattauftrag	Mitarbeitende M-22

Alle Kennungen und Zuordnungen sind ausdrücklich erfunden.

Basisaufgabe: Zeichne die Beziehungen und erkläre, welche Felder für die Objektprüfung erforderlich sind.

Feedback: Entscheidend ist der zuverlässige Vergleich zwischen der angemeldeten Identität und der im Datenmodell hinterlegten Zuordnung. Eine bloße Anzeige der Kennung ist kein Sicherheitsnachweis.

Dossier D5: Datenmodell und vollständig fiktive Prüfdaten.

Lerneinheit 6: Berechtigungen testen

Zeit: 15 Minuten | Ergebnis: D6

Softwaretests überprüfen, ob die Regeln tatsächlich umgesetzt wurden. Besonders wichtig sind erlaubte und verweigerte Aktionen sowie unterschiedliche Datenobjekte.

Schritt 1: Prüfprotokoll

Arbeitsauftrag: Führe die folgende Tabelle als lokale Simulation oder mit Deiner eigenen ausdrücklich freigegebenen Testanwendung durch. Trage für jeden Fall das tatsächliche Ergebnis in die Ist-Spalte ein.

Test	Benutzer	Aktion / Objekt	Soll	Ist
T01	K-17	Artikel E-300 lesen	Erlaubt	…
T02	K-17	Bestellung B-701 lesen	Erlaubt	…
T03	K-17	Bestellung B-702 lesen	Verweigert	…
T04	K-17	Bestand E-300 ändern	Verweigert	…
T05	M-21	Bestand E-300 ändern	Erlaubt	…
T06	M-21	Auftrag W-81 ändern	Erlaubt	…
T07	M-21	Auftrag W-82 ändern	Verweigert	…
T08	A-01	Rolle zuweisen	Erlaubt	…
T09	A-01	Bestellung B-701 lesen	Verweigert	…
T10	Unbekannt	Artikel E-300 lesen	Verweigert	…

Hinweis: „Unbekannt“ bezeichnet hier eine nicht authentifizierte Testidentität. Der Artikel ist in diesem Lernmodell nicht öffentlich freigegeben.

Schritt 2: Prüfergebnisse bewerten

Vergleiche Soll und Ist.

Beobachtung	Begründetes Feedback
Alle Ergebnisse stimmen überein	Die untersuchten Testfälle erfüllen die definierten Regeln; vollständige Sicherheit ist damit nicht bewiesen.
Fremde Bestellung wird angezeigt	Objektbezogene Prüfung fehlt oder ist fehlerhaft. Zugriff verweigern und den Test wiederholen.
Mitarbeitende können Rollen ändern	Eine unzulässige Rechteerweiterung liegt vor. Rollenverwaltung ausschließlich für die Administration freigeben.
Berechtigte Aktion wird verweigert	Die Rollenmatrix oder ihre Umsetzung widerspricht möglicherweise der vorgesehenen Fachfunktion.

Transferaufgabe: Ergänze mindestens zwei eigene Negativtests, beispielsweise für ein fehlendes Objekt oder eine inzwischen entzogene Rolle.

Feedback: Ein guter Negativtest prüft eine konkret begründete Schutzregel. Er enthält Eingabedaten, erwartetes Ergebnis und eine nachvollziehbare Bewertung.

Dossier D6: Zehn ausgefüllte Testfälle, zusätzliche Negativtests und eine kurze Auswertung.

Lerneinheit 7: Sicherheitsentscheidung und Projektabgabe

Zeit: 10 Minuten | Ergebnis: D7

Schritt 1: Ergebnis beurteilen

Beantworte diese drei Fragen:

IT-Sicherheit: Wo wird die Autorisierung verbindlich geprüft und warum?
Datenschutz: Welche fremden Daten bleiben geschützt?
Softwarequalität: Welche Testergebnisse belegen Deine Entscheidung und welche Risiken bleiben offen?

Schritt 2: Begründete eigene Abgabe

Reiche Dein vollständiges Projektdossier ein. Begründe mindestens eine eigene Verbesserung gegenüber der Ausgangsmatrix.

Beispiele für mögliche Erweiterungen sind der geregelte Entzug einer Mitarbeiterrolle, die zeitlich begrenzte Vertretung oder die getrennte Freigabe besonders sensibler Werkstattdaten.

Wichtig: Eine Erweiterung ist erst dann überzeugend, wenn ihre Vorteile, Risiken und passende Tests dokumentiert sind.

Gestufte Lernhilfen

Nutze die Hilfen der Reihe nach und versuche zuerst eine eigene Lösung.

Stufe	Hilfe
Hilfe 1 – Denkimpuls	Wer führt welche Aktion auf welchem Objekt aus?
Hilfe 2 – Struktur	Prüfe Identität, Rolle, erlaubte Aktion und konkrete Objektzuordnung.
Hilfe 3 – Beispiel	K-17 liest B-701: erlaubt. K-17 liest B-702: verweigert, weil die Eigentümerkennung abweicht.

Basis-, Anwendungs- und Transfertraining

Niveau	Arbeitsauftrag	Begründetes Feedback
Basis	Erkläre Kunde, Mitarbeitende und Administration anhand je einer erlaubten und verweigerten Aktion.	Richtig ist die Lösung, wenn alle Rechte auf einen betrieblichen Bedarf zurückgeführt werden können.
Anwendung	Übertrage die Rollenmatrix auf eine lokale Testsimulation und dokumentiere vier Soll-Ist-Vergleiche.	Aussagekräftige Tests überprüfen auch unzulässige Aktionen, weil nur erfolgreiche Anfragen keine wirksame Zugriffskontrolle belegen.
Transfer	Entwirf eine Vertretungsregel für eine abwesende Werkstattkraft. Lege Freigabe, Umfang, Entzug und Tests fest.	Eine überzeugende Lösung begrenzt zusätzliche Rechte auf einen begründeten Zweck und verhindert unbegrenzte Dauerberechtigungen.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was wird bei der Autorisierung geprüft? (Ob eine angeforderte Aktion erlaubt ist) (!Ob ein Ersatzteil mechanisch passt) (!Ob ein Passwort besonders lang ist) (!Ob eine Datenbank groß genug ist)

Wie werden bei RBAC Berechtigungen hauptsächlich vergeben? (Über zugewiesene Rollen) (!Über zufällige Benutzerkennungen) (!Über die Bildschirmauflösung) (!Über die Länge einer Bestellung)

Welche Bestellung darf K-17 gemäß dem Lernmodell lesen? (Die eigene Bestellung B-701) (!Die fremde Bestellung B-702) (!Jede Bestellung im Ersatzteilshop) (!Alle Bestellungen der Werkstatt)

Was muss passieren, wenn K-17 die Bestellung B-702 lesen möchte? (Der Zugriff wird verweigert) (!Die Bestellung wird gelöscht) (!Die Kundenrolle wird automatisch erweitert) (!Die Administration wird ersetzt)

Welche Aktion darf M-21 gemäß der Berechtigungsmatrix ausführen? (Den zugewiesenen Auftrag W-81 ändern) (!Die fremde Bestellung B-702 lesen) (!Jede Benutzerrolle verändern) (!Den fremden Auftrag W-82 ändern)

Welche Hauptaufgabe hat die Administration im Lernmodell? (Benutzerrollen zuweisen) (!Alle Kundenbestellungen lesen) (!Sämtliche Werkstattaufträge bearbeiten) (!Alle Ersatzteile bestellen)

Wo muss eine Webanwendung Berechtigungen verbindlich kontrollieren? (Auf dem Server) (!Nur in der Menüanzeige) (!Nur durch ausgeblendete Schaltflächen) (!Nur im Browserdesign)

Was bedeutet die Standardverweigerung? (Nicht ausdrücklich erlaubte Zugriffe werden abgelehnt) (!Unbekannte Zugriffe werden automatisch freigegeben) (!Administratoren dürfen immer alles) (!Kunden dürfen fremde Daten bearbeiten)

Was gehört zu einem überprüfbaren Testfall? (Eingabe und erwartetes Ergebnis) (!Nur ein zufälliger Benutzername) (!Nur ein farbiges Bildschirmfoto) (!Nur eine allgemeine Erfolgsmeldung)

Wie sollte ein sicherheitsrelevantes Protokoll gestaltet sein? (Nachvollziehbar und datensparsam) (!Mit sämtlichen Klartextpasswörtern) (!Ohne Kennzeichnung des Prüfergebnisses) (!Mit allen verfügbaren Kundendaten)

Memory

Verbinde jeweils zwei zusammengehörende Begriffe.

Kundenrolle	Eigene Bestellung lesen
Werkstattrolle	Zugewiesenen Auftrag bearbeiten
Verwaltungsrolle	Benutzerrollen zuweisen
Authentifizierung	Identität überprüfen
Autorisierung	Zugriffsrecht überprüfen
Standardverweigerung	Nicht freigegebene Aktion ablehnen
Objektprüfung	Konkrete Datenzuordnung kontrollieren

Drag and Drop

Ordne die Prüfungsschritte den passenden Gegenständen zu.

Ordne die richtigen Begriffe zu.	Thema
Anmeldung prüfen	Identität
Rolle ermitteln	Zuständigkeit
Berechtigung prüfen	Aktion
Eigentümer kontrollieren	Bestellung
Entscheidung dokumentieren	Prüfergebnis

Kreuzworträtsel

Rollenmodell	Wie heißt ein Konzept zur Verwaltung von Berechtigungen über Rollen?
Autorisierung	Wie heißt die Prüfung einer Zugriffsberechtigung?
Server	Wo wird die Berechtigungsentscheidung bei einer Webanwendung verbindlich kontrolliert?
Testfall	Wie heißt die dokumentierte Prüfung einer konkreten Softwareanforderung?
Protokoll	Wie heißt eine nachvollziehbare Aufzeichnung von Prüfergebnissen?
Objektbezug	Was muss zusätzlich zur Rolle geprüft werden, damit nur die eigene Bestellung gelesen wird?

LearningApps

Lückentext

Beim

werden Berechtigungen über Benutzerrollen vergeben.

Die

überprüft die Identität einer Person.

Die

entscheidet über die Zulässigkeit einer Aktion.

Eine Bestellung darf nur von ihrem berechtigten

gelesen werden.

Nicht ausdrücklich erlaubte Zugriffe werden standardmäßig

.

Die verbindliche Berechtigungsprüfung erfolgt auf dem

.

Die Rolle Mitarbeitende darf den

bearbeiten.

Ein Werkstattauftrag ist einer bestimmten Person

.

Die Administration verwaltet die

.

Ein Testfall besitzt ein überprüfbares

.

Die Projektdokumentation enthält nachvollziehbare

.

Für die Ausbildung verwenden wir ausschließlich

Benutzerdaten.

Offene Aufgaben

Leicht

Benutzerrolle: Zeichne drei Rollenkarten und notiere zu jeder Rolle zwei erlaubte sowie eine verweigerte Aktion.
Anwendungsfalldiagramm: Entwirf eine Skizze des Ersatzteilshops mit den wichtigsten Anwendungsfällen.
Berechtigung: Gestalte eine farbige Berechtigungsmatrix und erläutere Deine Farblegende.
Authentifizierung: Erstelle ein kurzes Erklärvideo oder eine Bildfolge zum Unterschied zwischen Anmeldung und Berechtigungsprüfung.

Standard

Role Based Access Control: Entwickle ein eigenes Rollenkonzept für die fiktive Lernwerkstatt und begründe die Vergabe der Rechte.
Softwareentwicklung: Implementiere eine lokale Berechtigungsentscheidung mit fiktiven Benutzerrollen und Ressourcen.
Softwaretest: Erstelle mindestens acht Prüffälle mit erwarteten und tatsächlichen Ergebnissen und dokumentiere Abweichungen.
Projektdokumentation: Führe ein simuliertes Anforderungsgespräch mit einer zweiten lernenden Person und überarbeite anschließend Dein Projektdossier.

Schwer

IT-Sicherheit: Entwirf einen geregelten Rollenwechsel für eine Person, die vorübergehend andere Werkstattaufgaben übernimmt.
Datenschutz: Analysiere, welche Informationen in der Werkstattverwaltung besonders schutzbedürftig wären, und entwirf ein minimiertes Datenmodell.
Qualitätssicherung: Entwickle zusätzliche Tests für fehlende Datenobjekte, Rollenentzug, parallele Änderungen und fehlerhafte Sitzungsannahmen.
Softwarearchitektur: Vergleiche ein einfaches Rollenmodell mit zusätzlichen objektbezogenen Bedingungen. Dokumentiere Vorteile, Grenzen, Risiken und eine begründete Architekturentscheidung.

Lernkontrolle

Bearbeite die folgenden Aufgaben schriftlich oder als kurze Präsentation. Begründe Deine Antworten anhand des Ausbildungsfalls.

Zugriffskontrolle: Ein Kunde kann die Bestellnummer eines anderen Kunden sehen. Erkläre, warum dies nicht automatisch zum Lesen der Bestellung berechtigen darf, und schlage eine Kontrolle vor.
Rollenmodell: Ein Mitarbeiter wechselt in die Administration. Entwickle ein Verfahren, mit dem alte Rechte überprüft und unnötige Berechtigungen entzogen werden.
Softwarearchitektur: Eine Anwendung blendet für Kunden die Schaltfläche „Bestand ändern“ aus. Begründe, weshalb dies allein keine ausreichende Schutzmaßnahme ist.
Teststrategie: Entwirf einen zusätzlichen Test, der eine bisher unerkannte Berechtigungslücke aufdecken könnte. Begründe Eingaben und erwartetes Ergebnis.
Datenschutz: Begründe, weshalb ein Administrationskonto nicht automatisch Zugriff auf die gesamte Kunden- und Werkstatthistorie benötigt.
Projektbewertung: Vergleiche zwei eigene Lösungsvarianten und entscheide Dich anhand von Sicherheitswirkung, Verständlichkeit und Wartbarkeit für eine Variante.

Lernnachweis

Für Deinen Lernnachweis reichst Du das vollständig bearbeitete Projektdossier D1 bis D7 ein.

Es enthält:

Eine eigene Anforderungsskizze mit allen drei Benutzerrollen.
Eine begründete Berechtigungsmatrix.
Ein Datenmodell mit ausschließlich fiktiven Daten.
Eine nachvollziehbare Implementierung oder lokale Simulation der Berechtigungsentscheidung.
Ein Prüfprotokoll mit positiven und negativen Testfällen.
Eine Analyse mindestens eines Fehlerszenarios einschließlich Korrektur.
Eine eigene begründete Weiterentwicklung des Rollenmodells.
Eine Quellen- und Medienübersicht mit geprüften Lizenzen.

Bewertungskriterien

Kriterium	Erwartung	Punkte
Fachliche Richtigkeit	Rollen, Aktionen und Objektprüfungen sind korrekt getrennt.	0–2
Sicherheitsprinzipien	Rechte sind begrenzt und serverseitige Prüfungen vorgesehen.	0–2
Testqualität	Positive und negative Testfälle sind überprüfbar dokumentiert.	0–2
Eigenständigkeit	Entscheidungen und Verbesserungen werden nachvollziehbar begründet.	0–2
Dokumentation	Dossier, Testdaten, Quellen und Medienrechte sind vollständig.	0–2

Maximal: 10 Punkte

Orientierung: 9–10 Punkte zeigen eine sehr überzeugende Umsetzung, 7–8 eine weitgehend vollständige Umsetzung, 5–6 eine teilweise überzeugende Umsetzung. Unter 5 Punkten müssen zentrale Bestandteile überarbeitet werden.

Abschlussreflexion: Erkläre, welche Berechtigungsregel Dir besonders wichtig erscheint, welche Tests sie absichern und wo die Grenzen Deiner Simulation liegen.

Fachquellen und Medienrechte

Geprüfte Fachquellen

NIST: Definition von Role-Based Access Control – Grundlage für die Zuordnung von Berechtigungen zu Rollen.
OWASP: Authorization Cheat Sheet – geringste Berechtigungen, Standardverweigerung, serverseitige Kontrolle und Testen.
BSI: ORP.4 – Identitäts- und Berechtigungsmanagement – Regelung der Vergabe, Änderung und des Entzugs von Berechtigungen.
OWASP: Authorization Regression Testing Cheat Sheet – strukturierte Prüfung von Akteuren, Ressourcen und Aktionen.

Bildnachweise

Die folgenden Medien wurden anhand ihrer Wikimedia-Commons-Dateiseiten ausgewählt. Prüfe bei einer eigenen Weiterverwendung die jeweils angegebenen Lizenzbedingungen, insbesondere Namensnennung, Lizenzlink und eventuelle Bearbeitungsangaben.

Datei auf Wikimedia Commons	Urheber und Lizenz
Auto workshop01.jpg	Leotard – gemeinfrei
UML Use Case diagram.svg	Slashme – CC BY-SA 4.0
Role-based access control.svg	Babbage – CC0 1.0
Brake pad.jpg	A7N8X – CC BY-SA 3.0
Client-server model.svg	Lubaochuan – CC BY-SA 4.0
Flowchart de.svg	Erik Streb – CC BY-SA 3.0
Flowchart Decision.svg	DevinCook – CC BY-SA 4.0
Entity Relationship Diagram Examples.png	Chad250 – CC BY-SA 4.0
Testing Pyramid.svg	Abbe98 – CC BY-SA 4.0

Lizenzinformationen: CC BY-SA 4.0, CC BY-SA 3.0 und CC0 1.0.

Videonachweise

UML-Anwendungsfalldiagramm für IT-Auszubildende – Stefan Macke.
Role-Based Access Control Explained – Harness.

Medienrechtlicher Hinweis: Die YouTube-Videos sind als externe Lernmedien verlinkt beziehungsweise eingebettet. Eine frei nachnutzbare Lizenz für ihre Inhalte wird damit nicht behauptet. Die Übernahme von Videodateien oder Ausschnitten erfordert eine gesonderte Rechteprüfung.

Datenschutzhinweis: Beim Aufrufen externer Videos oder Lernplattformen können technische Nutzungsdaten an den jeweiligen Anbieter übertragen werden. Alle Aufgaben lassen sich ohne externe Testdienste bearbeiten. Verwende dort keine Projekt-, Zugangs- oder Kundendaten.