Konzepte und Datenmodell
Grundbegriffe von swark – Daten und Content, Configuration Items, Scomp-IDs, Datenmodell mit Beziehungen, C4-Zuordnung sowie Zonen, Stages, Kritikalität, Schutzziele und Datenklassifikation.
Daten und Content
swark trennt zwei Arten von Information:
| Daten | Content | |
|---|---|---|
| Inhalt | Objekte mit festen Feldern und Beziehungen (Host, Software, Regulierungskapitel, Finding usw.) | Fliesstext, Bilder als HTML, Diagramm-Quelltext |
| Speicherort | MariaDB-Datenbank | Dateien im Content-Pfad (SWARK_CONTENT_PATH), optional Tabelle content |
| Pflege | Admin-Oberflächen (/admin/<panel>), Excel-Import, Markdown-Import für Regulierungen |
Dateien anlegen oder ändern (Markdown, HTML, Blade, PlantUML) |
| Darstellung | Tabellen und generierte Diagramme im Frontend | An festen Stellen (Slots, Hooks) in die Frontend-Seiten eingeblendet |
Die Seiten des Frontends kombinieren beides: Eine Seite wie «IT-Architektur» zeigt Tabellen aus der Datenbank; vor oder nach jedem Kapitel kann zusätzlich Text aus dem Content-Pfad erscheinen (siehe Kapitel Content).
Configuration Items
Fast jedes fachliche Objekt in swark ist ein Configuration Item (CI). Technisch erbt das Modell von IsKnownConfigurationItem. Zu jedem solchen Datensatz legt swark automatisch einen Eintrag in der zentralen Tabelle configuration_item an:
| Feld | Bedeutung |
|---|---|
ref_type, ref_id |
Typ (zum Beispiel host, software) und ID des Datensatzes in seiner Fachtabelle |
uuid |
Global eindeutige ID, beim Anlegen erzeugt |
name, fullname |
Anzeigename, in der Regel aus dem Feld name übernommen |
scomp_id |
Sprechender, je Typ eindeutiger Schlüssel (siehe unten) |
lifecycle_id, last_seen_at |
Für Lebenszyklus und Discovery vorgesehen, in 0.2.1 nicht befüllt |
created_at, updated_at |
Zeitstempel |
Im Admin-Bereich ist dieser Eintrag in jedem Formular als eingeklappter Abschnitt «Meta» sichtbar (nur lesend).
Scomp-ID
Die Scomp-ID ist der sprechende Schlüssel eines Configuration Items. Sie ist pro Typ eindeutig (Unique-Index auf ref_type + scomp_id); derselbe Wert darf bei verschiedenen Typen vorkommen, zum Beispiel prod als Stage und als Logische Zone.
Entstehung
- Excel-Import: Die Scomp-ID steht in einer eigenen Spalte und wird unverändert übernommen. Über sie werden Objekte beim erneuten Import wiedergefunden und aktualisiert (Upsert).
- Anlegen im Admin-Bereich: Die Scomp-ID wird aus dem Namen abgeleitet: Kleinschreibung, Leerzeichen entfallen, Wortgrenzen werden zu Unterstrichen. Beispiel: Organisation «Red Hat» erhält
red_hat. Ist der Wert beim gleichen Typ schon vergeben, hängt swark einen zufälligen Teil mit Doppelpunkt an. - Zusammengesetzte Scomp-IDs: Einige Typen bilden die Scomp-ID aus mehreren Feldern, getrennt durch Doppelpunkt:
| Typ | Bestandteile |
|---|---|
| Release | Software-ID und Version |
| Technologie-Version | Technologie-ID und Versionsname |
| Regel (Rule) | Policy-ID und Name |
| Schutzziel-Stufe | Schutzziel-ID und Name |
| Resource | Resource-Type-ID und Name |
| Application Instance | Executor-Typ, Executor-ID, Release-ID |
Im Admin-Bereich ist die Scomp-ID schreibgeschützt. Ein erneuter Excel-Import mit geänderter Scomp-ID ändert das bestehende Objekt nicht, sondern legt ein zusätzliches an. Eine Umbenennung ist in 0.2.1 daher nur direkt in der Datenbank (Tabelle configuration_item) möglich.
Referenzen im Import
Beim Excel-Import verweisen Zeilen über Scomp-IDs aufeinander, zum Beispiel ein Host auf sein Betriebssystem debian:12 oder ein Ziel auf eine Frage strategy_question:2029:techstack. Die genaue Syntax beschreibt das Kapitel Datenimport.
Datenmodell
Das Schema wird durch die Migration create_swark_tables angelegt (dazu kommen die Laravel-Standardtabellen für Benutzer, Sessions, Cache und Jobs). Die folgende Übersicht gruppiert die Tabellen nach Fachbereich. Verknüpfungstabellen sind kursiv beschrieben.
Zentrale Meta-Tabellen
| Tabelle | Zweck | Status 0.2.1 |
|---|---|---|
configuration_item |
Register aller CIs mit UUID und Scomp-ID | genutzt |
relationship, relationship_type |
Gerichtete Beziehung zwischen zwei beliebigen CIs (Quelle, Ziel, Typ, Port, Protokoll-Stack, Beschreibung) | genutzt (Zonen-Zugriffe, Verbindungen, Ressourcennutzung, C4-Beziehungen) |
relationship_type_constraint |
Erlaubte Quell- und Zieltypen je Beziehungstyp | angelegt, nicht genutzt |
content |
In die Datenbank importierte Inhalte (Markdown, HTML) | befüllbar, im Frontend kaum wirksam (siehe Kapitel Content) |
naming_type, configuration_item_naming |
Zusätzliche Namen je CI (zum Beispiel Kubernetes-UID, IPv4) | angelegt, nur vom nicht lauffähigen Kubernetes-Import vorgesehen |
meta_schema, meta_type, meta_property, meta, configuration_item_meta |
Frei definierbare Zusatzfelder für CIs | angelegt, nicht genutzt |
configuration_item_history |
Änderungsprotokoll | angelegt, nicht genutzt |
lifecycle_schema, lifecycle_status, lifecycle, lifecycle_transition, lifecycle_assigned |
Lebenszyklus-Modelle (geplant, beschafft, online, ausser Betrieb) | angelegt, nicht genutzt |
Governance und Strategie
| Tabelle | Zweck |
|---|---|
strategy |
Strategie (zum Beispiel «Strategie bis 2029») |
question |
Strategische Frage; question_in_strategy ordnet sie Strategien zu |
objective |
Strategisches Ziel mit Beschreibung und Begründung, gehört zu genau einer Strategie |
question_in_objective |
Welche Fragen ein Ziel beantwortet |
objective_for_regulation_chapter, question_for_regulation_chapter |
Bezug von Zielen und Fragen zu Regulierungskapiteln |
metric |
Messgrösse mit Typ, Genauigkeit und Zielrichtung |
kpi |
Zielwert und Schwellwerte für eine Metrik |
kpi_assigned |
KPI an Ziel oder Massnahme gehängt (polymorph measurable) |
measurement_period |
Messperiode mit Beginn und Ende |
measurement |
Gemessener Wert eines KPI in einer Periode |
criticality |
Kritikalitätsstufen mit Reihenfolge (position) |
technology, technology_version |
Technologien (Protokolle, Sprachen, Formate) und deren Versionen |
Compliance
| Tabelle | Zweck |
|---|---|
regulation |
Regulierung (NIS2, DORA, VAIT usw.) |
regulation_chapter |
Kapitel mit Nummer (external_id), Überschrift, amtlichem Text, Zusammenfassung, Ist- und Sollzustand, Relevanz |
regulation_control |
Control (Prüfpunkt) einer Regulierung, optional einem Kapitel zugeordnet |
data_classification |
Datenklassifikationen mit Reihenfolge |
protection_goal, protection_goal_level |
Schutzziele (Vertraulichkeit, Integrität …) und ihre Stufen |
policy_for_regulation_chapter |
Bezug Richtlinie zu Regulierungskapitel (in 0.2.1 nicht befüllt) |
Auditing
| Tabelle | Zweck |
|---|---|
policy |
Richtlinie |
rule |
Regel innerhalb einer Richtlinie |
scope_template |
Vorlage, die festlegt, welche Objekte eine Regel betrifft |
rule_scope, rule_scope_item |
Konkreter Geltungsbereich einer Regel und die gefundenen Objekte |
finding |
Feststellung mit Typ, Status, Auswirkung, Wahrscheinlichkeit, Schadensausmass, Behandlungsstrategie, Kritikalität |
finding_assigned |
Finding an Control oder Ziel gehängt (polymorph examinable) |
action |
Massnahme mit Status, Beginn, Ende |
action_assigned |
Massnahme an Finding, Control oder Ziel gehängt (polymorph actionable) |
Business
| Tabelle | Zweck |
|---|---|
organization |
Organisation mit Rollen-Flags (intern, Hersteller, Kunde, Managed Service Provider) und Bedeutung (normal, high, very_high) |
associated_with_organization |
Zuordnung von CIs zu Organisationen mit Rolle (owner, manager, customer) |
actor |
Person, Rolle oder Benutzergruppe |
actor_in_logical_zone |
Welche Akteure auf welche Zone zugreifen |
IT-Architektur und Software
| Tabelle | Zweck |
|---|---|
logical_zone |
Logische Zone (zum Beispiel PUBLIC, DMZ, CORE) mit Datenklassifikation |
stage |
Umgebung (DEV, TEST, PROD …) |
logical_layer |
Schicht einer Software-Architektur (Frontend, API …) |
protocol_stack |
Protokoll-Stack über OSI-Schichten 3 bis 7 mit Standard-Port |
resource_type |
Art einer bereitgestellten Ressource (Datenbankschema, Queue …), optional mit Technologie |
artifact_type, architecture_type |
Artefakt-Arten (Container-Image, Helm-Chart …) und Prozessorarchitekturen |
software |
Software-Katalog mit Verwendungsart, Flags (Virtualisierer, Betriebssystem, Runtime, Bibliothek, Bundle), Hersteller, Kritikalität, Zone |
release |
Version einer Software; Flags is_latest und is_any (Platzhalter-Release *) |
component, service, service_interface |
Komponenten einer Software, deren Dienste und Schnittstellen |
component_with_technology, component_in_layer |
Technologien und Schichten einer Komponente |
source_provider, source |
Herkunft einer Software (zum Beispiel Helm-Chart auf Artifact Hub) für helm:update |
release_train, release_in_release_train |
Gebündelte Releases eines Systems |
release_in_bundle, artifact_in_release |
Bundles und Artefakte eines Releases (angelegt, nicht genutzt) |
system |
System im Sinne von C4 (Software System) mit Zone, Stage und zwei Kritikalitäten |
system_element |
Woraus ein System besteht (Software, Resource Types) |
system_parameter |
Kennwerte eines Systems je Metrik (zum Beispiel RTO, RPO) |
system_in_protection_goal |
Schutzbedarf eines Systems je Schutzziel |
Infrastruktur, Betrieb und Cloud
| Tabelle | Zweck |
|---|---|
baremetal |
Physische Maschine |
host |
Logischer Host mit Betriebssystem-Release, optional Virtualisierer, läuft auf Baremetal oder auf einem Eltern-Host |
runtime |
Laufzeitumgebung auf einem Host (zum Beispiel Kubernetes-Node, Tomcat) mit Release |
cluster |
Cluster mit Modus (failover, replica, lb), Stage, optional Ziel-Release |
cluster_member |
Mitglieder eines Clusters (Host, Runtime, Application Instance, Subscription, Deployment), optional mit Namespace |
namespace |
Namespace in einem Cluster |
application_instance |
Laufende Instanz einer Software-Release auf einem Executor (Host, Runtime oder Cluster), mit Stage, Zone und System |
resource |
Bereitgestellte Ressource (zum Beispiel Datenbankschema) eines Providers (Cluster, Application Instance, Subscription) |
deployment, deployment_element |
Deployment eines Release Trains in einer Stage |
service_in_cluster, service_path |
Dienste in Clustern und Dienstpfade (angelegt, nicht genutzt) |
region, availability_zone |
Regionen und Verfügbarkeitszonen eines Providers |
managed_offer, managed_account, managed_subscription |
Angebote, Konten und Abonnements bei Managed Service Providern |
managed_baremetal |
Baremetal, das bei einem Provider gemietet ist |
Netzwerk
| Tabelle | Zweck |
|---|---|
vlan |
VLAN mit Nummer |
ip_network, ip_address |
Netze (IPv4/IPv6, Maske, Gateway) und Adressen |
ip_address_assigned, ip_network_assigned |
Zuordnung von Adressen und Netzen zu NIC, Cluster oder Application Instance |
nic |
Netzwerkkarte an Baremetal oder Host |
dns_zone, dns_record |
DNS-Zonen (verschachtelbar) und Einträge |
dns_record_upstream |
Ziele hinter einem DNS-Eintrag (angelegt, nicht genutzt) |
Wichtige Beziehungen im Überblick
Strategy 1─n Objective n─m Question
Objective ─ Finding (finding_assigned) ─ Action (action_assigned) ─ KPI (kpi_assigned) ─ Metric
Regulation 1─n Chapter 1─n Control ─ Finding / Action
Policy 1─n Rule 1─n Scope (Template) ─n ScopedItem → z. B. Logical Zone
Software 1─n Release
Baremetal 1─n Host (OS = Release, Virtualisierer = Release)
Host 1─n Host (virtualisiert, parent_host_id)
Host 1─n Runtime (Release)
Application Instance → Release, Executor (Host | Runtime | Cluster), Stage, Zone, System
Cluster n─m Host | Runtime | Application Instance (cluster_member, optional Namespace)
System n─m Software | Resource Type (system_element)
Logical Zone → Data Classification; Logical Zone n─m Actor
Logical Zone → Logical Zone (relationship: allow_access / deny_access)
Application Instance → Cluster | Application Instance | Resource (relationship: connects_to, mit Protokoll-Stack und Port)
Application Instance → Resource (relationship: uses)
Zuordnung zum C4-Modell
Die offizielle swark-Dokumentation ordnet die Typen dem C4-Modell so zu:
| swark-Typ | C4-Element |
|---|---|
| Actor, Organization | Person |
| Region, Availability Zone | Group |
| System | Software System |
| Software, Cluster | Container |
| Component | Component |
| Stage, Logical Zone | Deployment Environment |
| Cluster | Deployment Group |
| Host, Runtime | Deployment Node |
| Baremetal | Infrastructure Node |
| Application Instance | Software System Instance bzw. Container Instance |
| Layer, Artifact Type, Managed Offer, Resource, Resource Type | keine Entsprechung |
C4-Beziehungen (Rel) werden in der Tabelle relationship gespeichert. Im Admin-Bereich zeigen Akteure, Systeme, Software und Resource Types ihre eingehenden und ausgehenden Beziehungen in eigenen Registern. Das Frontend erzeugt in 0.2.1 genau ein C4-Diagramm: das Zonenmodell auf der Seite IT-Architektur (Zonen als Boundary, Akteure als Person, Zugriff als Rel).
Logische Zonen
Eine logische Zone fasst Systeme und Anwendungen nach Schutzbedarf und Erreichbarkeit zusammen, zum Beispiel PUBLIC, B2X, CORE, INFRA. Eine Zone hat:
- eine Datenklassifikation (welche Daten höchstens darin liegen dürfen),
- Akteure, die auf die Zone zugreifen,
- Zugriffsregeln auf andere Zonen: «Allow access to» und «Deny access to». Ohne ausdrückliche Regel gilt eine Verbindung als verweigert. Die Seite IT-Architektur zeigt daraus eine Zugriffsmatrix.
Software, Systeme, Application Instances und Managed Subscriptions können einer Zone zugeordnet werden. Eine Application Instance kann eine andere Zone haben als ihre Software (zum Beispiel eine Testinstanz).
Stages
Stages sind die horizontale Sicht auf den Lebenszyklus einer Anwendung: DEV, TEST, QA, UAT, PROD. Systeme, Cluster, Namespaces, Application Instances und Deployments tragen eine Stage. Im Gegensatz dazu sind Layer die vertikale Sicht innerhalb einer Software (Frontend, Service, DAO).
Kritikalität
Die Tabelle criticality enthält frei benennbare Stufen mit einer Position (zum Beispiel Niedrig = 1 bis Sehr hoch = 4). Verwendet wird sie für:
- Business-Kritikalität und Infrastruktur-Kritikalität bei Systemen und Software,
- die Priorität eines Findings.
Das Frontend zeigt Kritikalität als farbige Skala zwischen kleinster und grösster Position.
Schutzziele
Schutzziele (protection_goal) wie Vertraulichkeit, Integrität, Verfügbarkeit, Authentizität haben jeweils geordnete Stufen (protection_goal_level, zum Beispiel Normal, Hoch, Sehr hoch). Ein System erhält je Schutzziel eine Stufe und eine Begründung (Register «Protection goals» beim System im Admin-Bereich). Im Frontend werden Schutzziele in 0.2.1 nicht angezeigt.
Datenklassifikation
Datenklassifikationen (zum Beispiel Öffentlich, Intern, Vertraulich, Geheim) mit Beschreibung und Reihenfolge. Sie werden logischen Zonen zugeordnet und auf der Seite IT-Architektur als eigene Tabelle und als Spalte im Zonenmodell gezeigt.
Metriken als Systemparameter
Metriken können nicht nur als KPI gemessen, sondern auch als Kennwert eines Systems verwendet werden (Flag is_system_parameter), etwa RTO, RPO oder maximal tolerierbare Ausfallzeit. Die Werte werden im Admin-Bereich beim System im Register «System parameters» gepflegt.