openveritas-site

OID-Architektur & Registry-Struktur

Die Grundlage von openVeritas ist eine strikt hierarchische Adressierung aller Komponenten mittels Object Identifiers (OIDs) nach dem Standard ITU-T X.660 (ASN.1). Dies garantiert globale Eindeutigkeit und maschinenlesbare Compliance.

Die OID-Kaskade

Jede Prüfregel, jeder Standard und jeder Befund folgt einer festen Hierarchie. Dies ermöglicht es, Umgebungen (Stages) physisch zu trennen und gleichzeitig technologische Ähnlichkeiten (Families) effizient zu verwalten.

Das Schema

1.3.6.1.4.1.65535.[STAGE].[PROJECT].[LAYER].[PLATFORM].[VERSION].[STATUS].[ID]

Segment Bezeichnung Beschreibung
1.3.6.1.4.1 Enterprise Root IANA Private Enterprise Number (PEN) Pfad
65535 openVeritas Root Eindeutige Kennung des Projekts
STAGE Environment 0: DEV, 1: TEST, 2: PROD
PROJECT Domain 17: External Standards, 19: Integrity Framework
LAYER Technologie 1: Hardware, 4: OS, 7: Application
PLATFORM OS-Familie 1: RHEL-Family, 2: SUSE-Family, 3: Debian-Family
VERSION OS-Version Major Version des OS (z.B. 9, 10, 15)
STATUS Reifegrad 0: INIT, 1: BUILD, 2: CERTIFIED
ID Modul-ID Eindeutige Kennung der Regel (z.B. 101: Kernel)

Dual-Root Konzept: Theorie vs. Praxis

Um regulatorische Flexibilität zu gewährleisten, trennt openVeritas zwischen der Definition eines Standards und seiner technischen Umsetzung.

Arc 17: External Standards (The Dictionary)

Hier liegen die Abbildungen externer Regelwerke. Eine OID in diesem Zweig enthält keine Logik, sondern nur die textliche Anforderung und Metadaten.

Arc 19: Integrity Framework (The Toolset)

Hier liegen die technischen Prüfmodule. Jedes Modul unter Arc 19 referenziert eine oder mehrere OIDs aus Arc 17.

Plattform-Awareness (Dynamic Pathing)

Der openveritas-inspector ist “plattformbewusst”. Beim Start identifiziert er das System und konstruiert dynamisch den Pfad zur benötigten Registry-Gasse.

  1. Erkennung: Auslesen der /etc/os-release.
  2. Mapping: Zuordnung der Distribution zur OID-Familie (z.B. Rocky Linux ➔ RHEL-Family ➔ Arc .1).
  3. Laden: Der Inspector zieht ausschließlich Atome aus dem Pfad, der seiner Plattform und Version entspricht.

Beispiel: Der Weg eines Kernel-Checks

Wenn ein System auf Compliance mit BSI SYS.1.3 geprüft wird, geschieht folgendes:

  1. Anfrage: Inspector sucht nach Modulen für die aktuelle Plattform (z.B. SLES 15 PROD).
  2. Pfad: Er steuert die OID 1.3.6.1.4.1.65535.2.19.4.2.15.2.2.101 an.
  3. Integrität: Das dort gefundene YAML-Atom wird per GPG verifiziert.
  4. Ausführung: Der technische Check (z.B. sysctl kernel.randomize_va_space) wird ausgeführt.
  5. Mapping: Das Ergebnis wird mit der Referenz-OID ...17.1.SYS.1.3 verknüpft und als fälschungssicherer Report exportiert.

Zusammenfassung der Vorteile