Zum Inhalt springen
Sprache: DE
Menü

Lernnachweise

RODMENA LRS

Auf Anfrage erhältlich

Der Nachweisspeicher für das Lernen, der einmalige Ereignisse erfasst und exakt aufbewahrt.

Kontakt aufnehmen

RODMENA LRS ist ein Learning Record Store. Er empfängt Datensätze von Lernaktivitäten im xAPI-Format, speichert sie unverändert und gibt sie über die standardmäßige xAPI-Abfrageschnittstelle zurück. Er besteht alle Tests der ADL LRS Conformance Test Suite für xAPI 1.0.3 und xAPI 2.0. Die Datenbank selbst trennt die Datensätze von Kunden voneinander. Inhalte von Datensätzen werden im Ruhezustand verschlüsselt. Bezeichner für Lernende werden nur in schlüsselbasierter, pseudonymer Form gespeichert. Gespeicherte Datensätze können nicht geändert werden; personenbezogene Daten von Lernenden können jedoch auf Anfrage gelöscht werden, und die Löschungen werden in ein manipulationserkennbares Protokoll geschrieben.

Für wen es gedacht ist. Lernplattformen und Schulungsanbieter, die einen konformen Speicher für Datensätze zu Lernaktivitäten benötigen. Es handelt sich um einen Back-End-Dienst, auf dem Produkte aufbauen und den sie von ihren Servern aus aufrufen; Lernende und Browser kommunizieren nicht direkt mit ihm. REES ist sein erster Nutzer.

Status
Auf Anfrage erhältlich
Teil von
Angebote
Lizenz
Proprietär. Copyright RODMENA LIMITED, alle Rechte vorbehalten.
Konformität
1,365 xAPI-1.0.3-Konformitätstests, alle bestanden
1,435 xAPI-2.0-Konformitätstests, alle bestanden
Geprüft am 23. September 2026
Tags
xAPILernnachweiseKonformitätMandantenfähigDatenschutzPrüfpfad

Technische Spezifikation

Verfasst für technische Prüfer. Eine Zeile ohne Messwert wird weggelassen.

Standards

xAPI 1.0.3
ADL Experience API Specification, Version 1.0.3
xAPI 2.0
IEEE 9274.1.1-2023
Versionsauswahl
Pro Anfrage über den X-Experience-API-Version-Header. 1.0.x und 2.0.x werden akzeptiert, und eine fehlende oder unbekannte Version wird mit 400 abgewiesen.
Konformitäts-Testsuite
ADL LRS Conformance Test Suite, zuletzt ausgeführt am 23. September 2026
Konformitätsergebnis
xAPI 1.0.3: 1.365 von 1.365. xAPI 2.0: 1.435 von 1.435.
Über die Suite hinaus
Wenn die Suite angibt, dass sie eine Anforderung nicht testet, wird sie durch eine dedizierte Prüfung abgedeckt. Wir haben zudem sechs Suite-Tests gefunden, die keine Prüfungen durchführen, und diese separat abgedeckt.
Konstruktionsbedingt
OAuth 1.0 ist veraltet und wird nicht akzeptiert. Produkte, die auf dem Dienst aufbauen, rufen ihn von Server zu Server auf. Er nimmt keine ursprungsübergreifenden Aufrufe von einem Browser entgegen.

Schnittstelle

Ressourcen
Statements, State, Activity Profile, Agent Profile, Activities, Agents und About. Alle GET-Routen antworten auch auf HEAD.
Authentifizierung
HTTP Basic unter Verwendung von Zugangsdaten, die der Dienst ausstellt. Secrets umfassen 256 Bit und werden ausschließlich als schlüsselbasierter Verifizierer gespeichert. Unbekannte, deaktivierte und abgelaufene Zugangsdaten erhalten byte-identische 401-Antworten.
Alternative Anforderungssyntax
Unter 1.0.3 unterstützt und unter 2.0 abgelehnt, wie es diese Spezifikation verlangt.
Signierte Statements
JWS mit RS256, RS384 und RS512, verifiziert, wenn ein Zertifikat enthalten ist.
Anhänge
multipart/mixed, abgeglichen per SHA-2-Hash. 5 MiB pro Anhang und 1 MiB pro Statement-Body, beides konfigurierbar.
Paginierung
Signierte zustandslose Cursor, die über einen Neustart hinweg gültig bleiben. Alle Statements-Antworten enthalten den xAPI-Konsistenz-Header.
Idempotenz
Das erneute Senden einer identischen Statement-ID wird ohne Duplizierung akzeptiert. Ein abweichendes Statement mit derselben ID wird mit 409 abgelehnt.
Ratenbegrenzung
Pro Zugangsdaten, zuzüglich eines separaten Budgets pro Client-Adresse für fehlgeschlagene Authentifizierungen.

Isolation und Sicherheit

Mandantentrennung
PostgreSQL Row-Level Security, aktiviert und erzwungen für jede Tabelle, die Mandantendaten enthält. Die Datenbankrolle der Anwendung besitzt keine Objekte und kann sie nicht umgehen. Jede Transaktion bezieht ihren Mandanten ausschließlich aus den authentifizierten Zugangsdaten.
Isolation, durchgesetzt
Ein Katalogtest lässt den Build fehlschlagen, wenn eine Mandantentabelle oder eine zur Laufzeit erstellte Partition die Richtlinie nicht besitzt.
Verschlüsselung im Ruhezustand
AES-256-GCM für Statement-Inhalte, Dokumente, Anhänge, Aktivitätsdefinitionen und Identitäten der Zugangsdaten, mit einem je Datensatz per HKDF-SHA256 abgeleiteten Schlüssel.
Bindung des Chiffrats
Ein Geheimtext ist an die Identität seiner Zeile gebunden und lässt sich nicht entschlüsseln, wenn er in eine andere Zeile verschoben wird.
Schlüsselverwahrung
Drei Schlüssel, die außerhalb der Datenbank in Schlüsseldateien mit den Rechten 0600 oder in der Umgebung gehalten werden. Es gibt keinen Standardschlüssel, und der Dienst weigert sich zu starten, wenn sie fehlen.
Schlüsselrotation
Der Indexschlüssel wird durch einen offline durchführbaren, fortsetzbaren Rekey rotiert, und die Rotation des Zugangsdatenschlüssels stellt Zugangsdaten neu aus. Da Datensätze die ID des Schlüssels speichern, der sie geschrieben hat, erfordert eine Rotation keine Datenmigration.
Kennungen von Lernenden
Ausschließlich als HMAC-SHA256-Tokens unter einem Schlüssel pro Mandant vorgehalten, und eine lernende Person in zwei Mandanten ergibt zwei voneinander unabhängige Tokens. Keine Spalte enthält die Identität einer lernenden Person im Klartext.
Geltungsbereiche der Zugangsdaten
Die xAPI-Scope-Gruppe aus statements/write, statements/read, statements/read/mine, state, profile, all/read und all. Der engste Scope liest nur die Statements, die diese Zugangsdaten selbst geschrieben haben.
Unveränderlichkeit
Datenbank-Trigger halten Statements und Anhänge rein anfügbar, indem sie UPDATE, DELETE und TRUNCATE verweigern. Die einzig zulässigen Änderungen sind das Ungültigkeits-Flag und eine Löschung.
Datenbankverbindung
TLS mit vollständiger Zertifikats- und Hostnamenüberprüfung ist obligatorisch, und der Dienst verweigert den Start ohne diese.
Audit-Ereignisse je Anfrage
Ein strukturiertes Ereignis pro Anfrage mit Anfrage-ID, Schlüssel-ID der Zugangsdaten, Mandant, Methode, Ressource, Status, Datensatzanzahl, Dauer und Filternamen. Lernendenwerte in Filtern werden vor der Protokollierung tokenisiert.
Manipulationserkennung
Das Löschprotokoll ist per Hash verkettet, und ein einziger Befehl verifiziert die gesamte Kette vom ersten bis zum letzten Glied.

Datenschutz

Löschung
Eine pseudonymisierende Schwärzung. Die lernende Person wird an jeder Position, an der ein Statement sie benennen kann, durch ein zufälliges Pseudonym ersetzt, Freitextantworten und Anhänge werden entfernt, und ihre State- sowie Agent-Profile-Dokumente werden gelöscht. Ein physisches Löschen kommt nicht zum Einsatz.
Löschung, protokolliert
Löschungen werden in das Hash-verkettete Protokoll geschrieben. Da der Befehl eine Löschung verweigert, die auf nichts zutrifft, kann eine falsch geschriebene lernende Person nicht als abgeschlossene Löschung durchgehen.
Backups
Eine Löschung ist abgeschlossen, sobald die vor ihr erstellten Backups abgelaufen sind. Nach einer Wiederherstellung wird das Löschprotokoll erneut angewendet.
Aufbewahrung
Nach Kalendermonat, pro Instanz. Der Monat wird abgetrennt, als eine Datei pro Mandant exportiert und anschließend entfernt. Das Entfernen wird verweigert, wenn die exportierte Zeilenanzahl nicht übereinstimmt.
Aufbewahrung, je Kunde
Ein Kunde, der eine eigene Aufbewahrungsfrist benötigt, benötigt eine eigene Instanz.
Export beim Ausstieg
Über die standardmäßige xAPI-Schnittstelle kann ein Kunde alle seine Datensätze und deren Anhänge als xAPI-JSON durchblättern und vollständig abrufen.
Datenresidenz
Eine Instanz läuft in der Region, die ein Vertrag erfordert. Der Dienst benötigt nur eine PostgreSQL-Datenbank.

Betrieb und Verifizierung

Bereitstellungsmodell
Eine gemeinsam genutzte, mandantenfähige Instanz oder eine dedizierte Instanz pro Kunde.
Prüfungen müssen nachweislich fehlschlagen können
Die Testumgebung wertet bei keiner der 47 Verhaltensprüfungen ein Ergebnis als bestanden, bis nachgewiesen wurde, dass diese Prüfung bei einem absichtlich fehlerhaften Build FEHLSCHLÄGT. Wir führen die Konformitätssuite ebenfalls für fehlerhafte Builds aus.

Was es leistet

  • Konformitätsgeprüft

    Besteht alle 1.365 Tests der ADL LRS Conformance Test Suite für xAPI 1.0.3 und alle 1.435 für xAPI 2.0.

  • Aufzeichnungen bleiben unverändert

    Ein einmal gespeichertes Statement kann nicht bearbeitet oder überschrieben, sondern nur ungültig gemacht werden, wie es der Standard vorsieht.

  • Konstruktionsbedingt isoliert

    Die Datensätze der Kunden werden durch von der Datenbank erzwungene Regeln getrennt – zusätzlich zum Anwendungscode.

  • Verschlüsselt und pseudonymisiert

    Die Inhalte der Aufzeichnungen werden im Ruhezustand verschlüsselt, und Lernendenkennungen werden nur als schlüsselbasierte Token indiziert.

  • Löschung mit Prüfpfad

    Auf Anfrage werden personenbezogene Daten eines Lernenden aus dessen Datensätzen entfernt, und die Löschung wird in einem manipulationserkennbaren Protokoll mit Hash-Verkettung erfasst.

  • Zugangsdaten mit begrenztem Geltungsbereich

    Anmeldedaten sind auf die erforderlichen Vorgänge beschränkt – bis hin zum ausschließlichen Lesen der Datensätze, die sie selbst geschrieben haben.

Für Dokumentation, ein Pilotprojekt oder eine Integration kontaktieren Sie uns.