Hauptseite: Unterschied zwischen den Versionen

Aus Dokument
Zur Navigation springen Zur Suche springen
← Zum vorherigen Versionsunterschied

Thorsten (Diskussion | Beiträge)

3 Benutzergruppen
69 Bearbeitungen
VisuellWikitext
imported>Import
Version 34
Markierung: Manuelle Zurücksetzung
 
(99 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
''Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).''
Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).
----
== Grundaufbau eines Wissensmanagement-Systems ==
Die folgenden Bausteine beschreiben kein klassisches CMS für Blog-Artikel, sondern ein '''Wissensmanagement-System (Wiki-artig)''': Im Mittelpunkt steht nicht die einzelne Seite, sondern das Netz aus Wissensartikeln, ihren Verknüpfungen und ihrer Auffindbarkeit. Entsprechend rücken Taxonomie, Verlinkung und Suche stärker in den Vordergrund als bei einem reinen Content-Ausgabe-System.


= Sicherheitsanalyse-Bericht (MeinCMS) - 21.03.2026 =
== Hauptbausteine im Detail ==


Dieser Bericht dokumentiert die aktuelle Sicherheitslage von MeinCMS nach der ersten Entwicklungsphase. Er identifiziert bestehende Schutzmechanismen und potenzielle Schwachstellen, die noch nicht behoben wurden.
=== [[Data Engine]] ([[Wissensmodell]] &  [[Speicherung]]) ===
Das Herzstück des Systems. Es definiert, wie Wissensartikel und ihre Beziehungen abgelegt werden:
* Entwickler-Entscheidung: Monolithisches Datenmodell (feste Tabellen für articles, categories, tags) oder flexibles Schema (JSONB / EAV-Muster für benutzerdefinierte Wissens-Typen wie Glossareinträge, How-Tos, FAQs).
* Taxonomie als Kernbestandteil: Eigene Tabellen für Kategorien, Tags und Artikel-Artikel-Relationen (Verlinkungen), nicht nur für den Inhalt selbst.
* Mandantenfähigkeit / Multi-Tenancy (optional): Trennung von Daten per tenant_id-Spalte oder separaten Datenbankschemas.
* Datenbank: Relationale Datenbanken wie PostgreSQL bieten mit JSON-Unterstützung volle Flexibilität bei hoher Integrität – wichtig, da Wissensartikel oft variable Zusatzfelder benötigen.


=== Content & Routing Layer (Wissensartikel-Verwaltung & URLs) ===
Verantwortlich für das Laden und Rendern von Wissensartikeln für Nutzer:
* Slug-Mapping: Zuordnung von lesbaren Pfaden (/wiki/rust-cms-guide) zu Datenbank-Einträgen.
* Status & Versionierung: Artikel besitzen Zustände (draft, published, archived) sowie eine Revisions-Historie – bei einem Wissenssystem meist zentraler als bei einem Blog, da Artikel fortlaufend gepflegt statt einmalig veröffentlicht werden.
* Rendering:
** Server-Side Rendering (SSR): HTML wird direkt über eine Template-Engine (z. B. Askama, Tera) gerendert.
** Headless (API): Ausgabe von JSON für entkoppelte Frontends.


-----
=== Wissensverknüpfung & Taxonomie (Knowledge Graph) ===
Das eigentliche Unterscheidungsmerkmal eines Wissenssystems gegenüber einem reinen CMS – Wissen entsteht durch Verknüpfung, nicht nur durch einzelne Artikel:
* Wiki-Links & Backlinks: Erkennung von Verweisen zwischen Artikeln (z. B. <nowiki>[[Artikelname]]</nowiki>-Syntax) sowie automatische Rückverfolgung, welche Artikel auf einen bestimmten Artikel verlinken.
* Kategorien & Tags: Hierarchische und flache Klassifizierung von Wissensartikeln zur Navigation und Filterung.
* Verwandte Artikel: Automatische oder manuelle Vorschläge thematisch ähnlicher Artikel (z. B. über gemeinsame Tags oder Verlinkungsdichte).
* Glossar & Begriffsdefinitionen: Zentrale Verwaltung wiederkehrender Fachbegriffe, die aus Artikeltexten heraus verlinkt werden können.


== 1. Übersicht der Schutzmechanismen (Ist-Zustand) ==
=== Authentication & Authorization (Sicherheit) ===
Trennt den öffentlichen Bereich vom Verwaltungsbereich:
* Authentifizierung: Identitätsprüfung von Benutzern (z. B. Session-Cookies oder JWT-Tokens).
* Rechteverwaltung (RBAC): Rollenbasierte Zugriffskontrolle (z. B. Admin, Editor, Author), um festzulegen, wer welche Endpunkte oder Inhalte bearbeiten darf.


* '''XSS-Schutz''': Verwendung von <code>Ganss.Xss.HtmlSanitizer</code> im <code>PageController</code> vor dem Speichern von Wiki-Inhalten.
=== Media Manager (Dateiverwaltung) ===
* '''CSRF-Schutz''': <code>[ValidateAntiForgeryToken]</code> ist auf den <code>HttpPost</code>-Methoden (<code>Create</code>, <code>Edit</code>) im <code>PageController</code> vorhanden.
Verwaltet Bilder, PDFs und sonstige Uploads:
* '''Authentifizierung''': ASP.NET Core Identity wird verwendet.
* Upload-Pipeline: Empfang von Dateien, Prüfung von MIME-Types und Dateigrößen.
* '''Autorisierung''': Rollenbasierte Zugriffskontrolle (<code>[Authorize(Roles = &quot;Admin&quot;)]</code>) für administrative Aufgaben (Erstellen, Bearbeiten, Historie).
* Verarbeitung: Automatische Skalierung oder Konvertierung von Bildern (z. B. Erzeugung von WebP-Thumbnails).
* '''SQL-Injection''': Verwendung von Entity Framework Core (LINQ), was standardmäßig gegen SQL-Injection schützt (keine Verwendung von <code>FromSqlRaw</code> mit unsicheren Parametern gefunden).
* Storage: Speicherung auf dem lokalen Dateisystem oder in einem Object-Storage (S3/MinIO).
* '''Eingabevalidierung''': Slugs werden mittels Regex im <code>PageController</code> validiert (<code>IstSlugGueltig</code>).


=== Admin Backend (Verwaltungsoberfläche) ===
Die Benutzeroberfläche für Redakteure:
* Rich-Text / Markdown Editor: Eingabeoberfläche für Inhalte.
* REST / gRPC / GraphQL API: Kommuniziert mit dem Backend, um Inhalte, Einstellungen, Benutzer und Medien zu verwalten.


-----
=== Caching & Performance Layer ===
Verhindert unnötige Datenbankabfragen bei hoher Last:
* HTTP-Caching: Passende Header (Cache-Control, ETag) für Nginx oder CDNs.
* In-Memory Caching: Zwischenspeichern von zusammengestellten Seiten oder Datenbank-Ergebnissen (z. B. über In-Memory-Stores oder Redis).


== 2. Identifizierte Schwachstellen &amp; Risiken (Offen) ==
=== Search & Discovery (Suche) ===
In einem Wissenssystem oft der wichtigste Einstiegspunkt überhaupt – Nutzer suchen gezielt nach Antworten statt zu stöbern:
* DB-native Suche: Volltextsuche über PostgreSQL tsvector/tsquery, ausreichend für kleinere bis mittlere Datenmengen.
* Externer Suchindex: Bei höheren Anforderungen an Relevanz und Performance Anbindung an Meilisearch, Typesense oder Elasticsearch.
* Facettierung & Filter: Eingrenzung nach Kategorie, Tag, Datum oder Autor.


=== 2.1 Password Policy &amp; Account Lockout ===
=== SEO & Metadata ===
Sorgt dafür, dass Inhalte von Suchmaschinen korrekt erfasst werden:
* Meta-Tags & Open Graph: Pro Inhalt konfigurierbare Title-, Description- und Social-Preview-Daten.
* Sitemap & Robots: Automatisch generierte sitemap.xml und robots.txt.
* Kanonische URLs & Redirects: Vermeidung von Duplicate Content, Verwaltung von 301-Weiterleitungen bei Slug-Änderungen.


* '''Schwachstelle''': In <code>Program.cs</code> ist die Passwort-Mindestlänge auf nur 6 Zeichen eingestellt (<code>options.Password.RequiredLength = 6</code>).
=== Plugin- & Extension-System ===
* '''Risiko''': Erhöhte Anfälligkeit für Brute-Force-Angriffe auf Admin-Accounts.
Erlaubt es, Funktionalität ohne Eingriff in den Core zu erweitern:
* '''Status''': Lockout-Mechanismen (<code>LockoutOnFailure</code>) sind im <code>Login.cshtml.cs</code> standardmäßig auf <code>false</code> gesetzt.
* Hooks & Events: Definierte Erweiterungspunkte (z. B. before_publish, after_upload), an denen Plugins andocken können.
* '''Empfehlung''': Passwortkomplexität erhöhen (mind. 10-12 Zeichen) und Account Lockout nach X Fehlversuchen aktivieren.
* Middleware-Ketten: Zusätzliche Verarbeitungsschritte in Request/Response-Pipeline einschiebbar.


=== 2.2 Fehlender CSRF-Schutz in Razor-Formularen ===
=== Background Jobs / Task Queue ===
Verlagert zeitintensive Arbeiten aus dem Request-Zyklus:
* Queue-Anbindung: Asynchrone Verarbeitung über Redis-basierte Queues oder tokio-Task-Runner.
* Typische Jobs: Bildkonvertierung, E-Mail-Versand, Sitemap-Neubau, Webhook-Zustellung.
* Retry & Fehlerbehandlung: Wiederholungslogik und Dead-Letter-Handling bei fehlgeschlagenen Jobs.


* '''Schwachstelle''': In <code>Neuformular.cshtml</code> wird das Tag-Helper <code>&lt;form asp-action=&quot;Create&quot; ...&gt;</code> verwendet, welches automatisch ein Anti-Forgery-Token einfügt. In <code>Edit.cshtml</code> wird jedoch ein direktes HTML-Tag <code>&lt;form action=&quot;~/Edit/@Model.Slug&quot; ...&gt;</code> verwendet.
=== Internationalisierung (i18n / l10n) ===
* '''Risiko''': Wenn der <code>@Html.AntiForgeryToken()</code>-Aufruf im manuellen Formular fehlen würde, wäre die Aktion angreifbar. In <code>Edit.cshtml</code> ist er vorhanden, aber die Inkonsistenz ist eine potenzielle Fehlerquelle für zukünftige Formulare.
Unterstützt mehrsprachige Inhalte und Oberflächen:
* '''Empfehlung''': Konsistente Verwendung von ASP.NET Core Tag-Helpern.
* Mehrsprachige Inhalte: Übersetzungsstatus pro Sprache und Content-Objekt.
* Locale-Routing: Sprachspezifische Pfade (/de/…, /en/…) oder Subdomains.
* UI-Übersetzung: Lokalisierte Texte im Admin Backend.


=== 2.3 Sensitive Daten in Konfigurationsdateien ===
=== Notifications & E-Mail ===
Kommuniziert Systemereignisse an Nutzer und Redakteure:
* Transaktionale Mails: Passwort-Reset, Einladungen, Kommentar-Benachrichtigungen.
* Workflow-Benachrichtigungen: Hinweise bei Freigabe-Anfragen oder Statuswechseln von Inhalten.


* '''Schwachstelle''': Der Connection String wird direkt aus der <code>appsettings.json</code> gelesen.
=== Audit-Log & Monitoring ===
* '''Risiko''': Wenn diese Dateien versehentlich ins Repository eingecheckt werden (was oft passiert, trotz <code>.gitignore</code>), sind die Datenbank-Zugangsdaten exponiert.
Schafft Nachvollziehbarkeit und Betriebssicherheit:
* '''Empfehlung''': Nutzung von ''Environment Variables'' oder ''User Secrets'' für die lokale Entwicklung und ''Azure Key Vault'' / ''HashiCorp Vault'' für Produktion.
* Audit-Log: Protokollierung, wer wann welche Änderung vorgenommen hat (Compliance, Nachvollziehbarkeit).
* Monitoring & Tracing: Metriken, Logs und Fehlerreporting für den laufenden Betrieb (z. B. über OpenTelemetry).


=== 2.4 Mass Assignment (Overposting) ===
=== Konfigurationsmanagement ===
Zentrale Steuerung systemweiter Einstellungen:
* Site-Settings: Globale Konfiguration wie Seitenname, Standardsprache, Zeitzone.
* Feature-Flags: Kontrolliertes Ein-/Ausschalten einzelner Funktionen ohne Redeploy.


* '''Schwachstelle''': Im <code>PageController.Create</code> und <code>Edit</code> werden Parameter wie <code>string slug</code> und <code>string markdownInhalt</code> einzeln entgegengenommen. Das ist sicher, solange keine komplexen Objekte direkt an Models gebunden werden.
=== Deployment & Infrastructure ===
* '''Risiko''': Zukünftige Erweiterungen, die direkt <code>WikiArtikel</code> oder <code>WikiArtikelVersion</code> als Parameter binden, könnten dazu führen, dass Angreifer Felder wie <code>Id</code> oder <code>Zeitpunkt</code> manipulieren.
Betrifft Betrieb und Wartbarkeit des Systems:
* '''Empfehlung''': Einsatz von spezifischen '''ViewModels''' (DTOs) anstelle von direkter Bindung an Datenbank-Models.
* Migrations-Tooling: Versionierte Datenbank-Migrationen (z. B. via sqlx oder refinery).
* CI/CD: Automatisierte Tests und Deployments.
* Backup-Strategie: Regelmäßige Sicherung von Datenbank und Medien-Storage.
==Siehe auch==
* [[Grundbegriffe Informatik]]
* [[Weiter]]
* [[Wissenssysteme & Tools im Überblick]]
* [[Drupal]]


=== 2.5 Clickjacking ===
==Hinweis==
 
Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).
* '''Schwachstelle''': Es fehlen explizite Security-Header wie <code>X-Frame-Options</code> oder eine <code>Content-Security-Policy</code> (CSP).
* '''Risiko''': Die Anwendung könnte in einem Iframe auf einer bösartigen Seite eingebettet werden, um Benutzer zu Aktionen zu verleiten.
* '''Empfehlung''': Middleware hinzufügen, die <code>X-Frame-Options: DENY</code> oder <code>SAMEORIGIN</code> setzt.
 
=== 2.6 Informations-Leakage durch Fehlerseiten ===
 
* '''Schwachstelle''': Die <code>Error.cshtml</code> zeigt im Development-Modus detaillierte Fehler an.
* '''Risiko''': Wenn die Umgebung fälschlicherweise auf “Development” in Produktion steht, werden Stack-Traces und interne Pfade preisgegeben.
* '''Status''': Die Standard-Abfrage <code>if (app.Environment.IsDevelopment())</code> in <code>Program.cs</code> ist vorhanden, was das Risiko mindert, aber die Fehlermeldung in <code>Error.cshtml</code> selbst ist sehr generisch.
 
 
-----
 
== 3. Administrative Tools (UserAdmin) ==
 
* '''Sicherheit''': Das Tool <code>UserAdmin</code> liest Passwörter per <code>Console.ReadLine()</code> im Klartext ein.
* '''Risiko''': Passwörter sind während der Eingabe auf dem Bildschirm sichtbar (Schulterblick-Gefahr).
* '''Empfehlung''': Verwendung einer Methode zur maskierten Eingabe (Sterne statt Klartext).
 
 
-----
 
== 4. Fazit ==
 
MeinCMS verfügt bereits über eine solide Basis an Sicherheitsmechanismen (Sanitization, CSRF-Tokens, Identity). Die kritischsten Punkte für die nächste Iteration sind die '''Verschärfung der Password Policy''', die '''Absicherung der Konfigurationsdaten''' und die Einführung von '''Security-Headern''' (CSP, HSTS-Tuning).
 
----
''Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).''
 
[[Category:Technik]]
[[Category:Hilfe]]

Aktuelle Version vom 18. August 2026, 14:57 Uhr

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Grundaufbau eines Wissensmanagement-Systems

Die folgenden Bausteine beschreiben kein klassisches CMS für Blog-Artikel, sondern ein Wissensmanagement-System (Wiki-artig): Im Mittelpunkt steht nicht die einzelne Seite, sondern das Netz aus Wissensartikeln, ihren Verknüpfungen und ihrer Auffindbarkeit. Entsprechend rücken Taxonomie, Verlinkung und Suche stärker in den Vordergrund als bei einem reinen Content-Ausgabe-System.

Hauptbausteine im Detail

Data Engine (Wissensmodell & Speicherung)

Das Herzstück des Systems. Es definiert, wie Wissensartikel und ihre Beziehungen abgelegt werden:

  • Entwickler-Entscheidung: Monolithisches Datenmodell (feste Tabellen für articles, categories, tags) oder flexibles Schema (JSONB / EAV-Muster für benutzerdefinierte Wissens-Typen wie Glossareinträge, How-Tos, FAQs).
  • Taxonomie als Kernbestandteil: Eigene Tabellen für Kategorien, Tags und Artikel-Artikel-Relationen (Verlinkungen), nicht nur für den Inhalt selbst.
  • Mandantenfähigkeit / Multi-Tenancy (optional): Trennung von Daten per tenant_id-Spalte oder separaten Datenbankschemas.
  • Datenbank: Relationale Datenbanken wie PostgreSQL bieten mit JSON-Unterstützung volle Flexibilität bei hoher Integrität – wichtig, da Wissensartikel oft variable Zusatzfelder benötigen.

Content & Routing Layer (Wissensartikel-Verwaltung & URLs)

Verantwortlich für das Laden und Rendern von Wissensartikeln für Nutzer:

  • Slug-Mapping: Zuordnung von lesbaren Pfaden (/wiki/rust-cms-guide) zu Datenbank-Einträgen.
  • Status & Versionierung: Artikel besitzen Zustände (draft, published, archived) sowie eine Revisions-Historie – bei einem Wissenssystem meist zentraler als bei einem Blog, da Artikel fortlaufend gepflegt statt einmalig veröffentlicht werden.
  • Rendering:
    • Server-Side Rendering (SSR): HTML wird direkt über eine Template-Engine (z. B. Askama, Tera) gerendert.
    • Headless (API): Ausgabe von JSON für entkoppelte Frontends.

Wissensverknüpfung & Taxonomie (Knowledge Graph)

Das eigentliche Unterscheidungsmerkmal eines Wissenssystems gegenüber einem reinen CMS – Wissen entsteht durch Verknüpfung, nicht nur durch einzelne Artikel:

  • Wiki-Links & Backlinks: Erkennung von Verweisen zwischen Artikeln (z. B. [[Artikelname]]-Syntax) sowie automatische Rückverfolgung, welche Artikel auf einen bestimmten Artikel verlinken.
  • Kategorien & Tags: Hierarchische und flache Klassifizierung von Wissensartikeln zur Navigation und Filterung.
  • Verwandte Artikel: Automatische oder manuelle Vorschläge thematisch ähnlicher Artikel (z. B. über gemeinsame Tags oder Verlinkungsdichte).
  • Glossar & Begriffsdefinitionen: Zentrale Verwaltung wiederkehrender Fachbegriffe, die aus Artikeltexten heraus verlinkt werden können.

Authentication & Authorization (Sicherheit)

Trennt den öffentlichen Bereich vom Verwaltungsbereich:

  • Authentifizierung: Identitätsprüfung von Benutzern (z. B. Session-Cookies oder JWT-Tokens).
  • Rechteverwaltung (RBAC): Rollenbasierte Zugriffskontrolle (z. B. Admin, Editor, Author), um festzulegen, wer welche Endpunkte oder Inhalte bearbeiten darf.

Media Manager (Dateiverwaltung)

Verwaltet Bilder, PDFs und sonstige Uploads:

  • Upload-Pipeline: Empfang von Dateien, Prüfung von MIME-Types und Dateigrößen.
  • Verarbeitung: Automatische Skalierung oder Konvertierung von Bildern (z. B. Erzeugung von WebP-Thumbnails).
  • Storage: Speicherung auf dem lokalen Dateisystem oder in einem Object-Storage (S3/MinIO).

Admin Backend (Verwaltungsoberfläche)

Die Benutzeroberfläche für Redakteure:

  • Rich-Text / Markdown Editor: Eingabeoberfläche für Inhalte.
  • REST / gRPC / GraphQL API: Kommuniziert mit dem Backend, um Inhalte, Einstellungen, Benutzer und Medien zu verwalten.

Caching & Performance Layer

Verhindert unnötige Datenbankabfragen bei hoher Last:

  • HTTP-Caching: Passende Header (Cache-Control, ETag) für Nginx oder CDNs.
  • In-Memory Caching: Zwischenspeichern von zusammengestellten Seiten oder Datenbank-Ergebnissen (z. B. über In-Memory-Stores oder Redis).

Search & Discovery (Suche)

In einem Wissenssystem oft der wichtigste Einstiegspunkt überhaupt – Nutzer suchen gezielt nach Antworten statt zu stöbern:

  • DB-native Suche: Volltextsuche über PostgreSQL tsvector/tsquery, ausreichend für kleinere bis mittlere Datenmengen.
  • Externer Suchindex: Bei höheren Anforderungen an Relevanz und Performance Anbindung an Meilisearch, Typesense oder Elasticsearch.
  • Facettierung & Filter: Eingrenzung nach Kategorie, Tag, Datum oder Autor.

SEO & Metadata

Sorgt dafür, dass Inhalte von Suchmaschinen korrekt erfasst werden:

  • Meta-Tags & Open Graph: Pro Inhalt konfigurierbare Title-, Description- und Social-Preview-Daten.
  • Sitemap & Robots: Automatisch generierte sitemap.xml und robots.txt.
  • Kanonische URLs & Redirects: Vermeidung von Duplicate Content, Verwaltung von 301-Weiterleitungen bei Slug-Änderungen.

Plugin- & Extension-System

Erlaubt es, Funktionalität ohne Eingriff in den Core zu erweitern:

  • Hooks & Events: Definierte Erweiterungspunkte (z. B. before_publish, after_upload), an denen Plugins andocken können.
  • Middleware-Ketten: Zusätzliche Verarbeitungsschritte in Request/Response-Pipeline einschiebbar.

Background Jobs / Task Queue

Verlagert zeitintensive Arbeiten aus dem Request-Zyklus:

  • Queue-Anbindung: Asynchrone Verarbeitung über Redis-basierte Queues oder tokio-Task-Runner.
  • Typische Jobs: Bildkonvertierung, E-Mail-Versand, Sitemap-Neubau, Webhook-Zustellung.
  • Retry & Fehlerbehandlung: Wiederholungslogik und Dead-Letter-Handling bei fehlgeschlagenen Jobs.

Internationalisierung (i18n / l10n)

Unterstützt mehrsprachige Inhalte und Oberflächen:

  • Mehrsprachige Inhalte: Übersetzungsstatus pro Sprache und Content-Objekt.
  • Locale-Routing: Sprachspezifische Pfade (/de/…, /en/…) oder Subdomains.
  • UI-Übersetzung: Lokalisierte Texte im Admin Backend.

Notifications & E-Mail

Kommuniziert Systemereignisse an Nutzer und Redakteure:

  • Transaktionale Mails: Passwort-Reset, Einladungen, Kommentar-Benachrichtigungen.
  • Workflow-Benachrichtigungen: Hinweise bei Freigabe-Anfragen oder Statuswechseln von Inhalten.

Audit-Log & Monitoring

Schafft Nachvollziehbarkeit und Betriebssicherheit:

  • Audit-Log: Protokollierung, wer wann welche Änderung vorgenommen hat (Compliance, Nachvollziehbarkeit).
  • Monitoring & Tracing: Metriken, Logs und Fehlerreporting für den laufenden Betrieb (z. B. über OpenTelemetry).

Konfigurationsmanagement

Zentrale Steuerung systemweiter Einstellungen:

  • Site-Settings: Globale Konfiguration wie Seitenname, Standardsprache, Zeitzone.
  • Feature-Flags: Kontrolliertes Ein-/Ausschalten einzelner Funktionen ohne Redeploy.

Deployment & Infrastructure

Betrifft Betrieb und Wartbarkeit des Systems:

  • Migrations-Tooling: Versionierte Datenbank-Migrationen (z. B. via sqlx oder refinery).
  • CI/CD: Automatisierte Tests und Deployments.
  • Backup-Strategie: Regelmäßige Sicherung von Datenbank und Medien-Storage.

Siehe auch

Hinweis

Hinweis: Diese Inhalte wurden mit Unterstützung von Künstlicher Intelligenz erstellt und redaktionell überprüft (Transparenzhinweis gemäß Art. 50 EU AI Act).

Abgerufen von „https://mediawiki.wissen-ahrensburg.de/index.php?title=Hauptseite&oldid=609“