Externer Abruf nach einem Fehlversuch
Ein späterer regulärer Abruf bestätigt zunächst einen noch nicht übertragenen Fehlversuch. Nach erfolgreicher Bestätigung kann derselbe Lauf einmal einen neuen Transfer versuchen. Die alte Fehlermeldung bleibt historisch erhalten. Eine fehlende Bestätigung verhindert diesen neuen Versuch; sie wird nicht als Erfolg gewertet.
Der externe Rechner muss zum geplanten Zeitpunkt eingeschaltet, wach, online und zugriffsbereit sein; sein Zielverzeichnis muss verfügbar sein. Ein erfolgreicher manueller Abruf beweist nicht, dass der nächste geplante Lauf gelingt. Eine bestätigte externe Kopie ist außerdem kein Wiederherstellungsnachweis.
Komponentenbestand und aktuelle Nachweise
Ein kürzlich erstellter Komponentenbericht ist nicht automatisch ein Nachweis für den aktuell eingesetzten Plattformstand. Fehlt die belastbare Zuordnung, bleibt die technische Bewertung unvollständig. Frühere Berichte bleiben unverändert erhalten.
Inventarisierte Komponenten und tatsächlich durchgeführte Schwachstellenprüfungen sind unterschiedliche Nachweise. Eine erfolgreiche Teilprüfung bedeutet keine vollständige Sicherheitsprüfung aller eingesetzten Bibliotheken. Fehlende oder veraltete Quellen müssen weiterhin geprüft werden.
Personen, Zugänge und Vereinsrollen
Personen und Zugänge zeigt Kontostatus, E-Mail-Bestätigung, technische Plattformrollen und Vereinsmitgliedschaften getrennt. Suche und Kontostatus lassen sich kombinieren. Pro Seite sind 10, 25, 50 oder 100 Konten wählbar; die Gesamtzahl bezieht sich auf die aktuelle Filterung.
Details zeigt Mitgliedschaften und fachliche Rollen je Verein oder Organisation. Mehrere Vereinszugehörigkeiten werden nicht zu einer globalen Rolle zusammengefasst. Abgelaufene, vorgemerkte und noch nicht bestätigte Rollen sind gesondert gekennzeichnet. Fehlt ein eindeutiger Organisationsbezug, bleibt dies sichtbar; aus einer Mitgliedschaft wird keine Rolle abgeleitet.
Noch kein Loginzeitpunkt erfasst bedeutet, dass kein entsprechender Zeitstempel vorhanden ist. Daraus lässt sich nicht sicher schließen, dass es niemals eine Anmeldung gab. Historische Werte werden nicht nachträglich geschätzt. Die Ansicht ändert weder Rollen noch Kontostatus.
- Personen und Zugänge in der Plattformadministration öffnen.
- Suche, Kontostatus und Seitengröße wählen und anwenden.
- Details oder Mitgliedschaften und Rollen öffnen.
- Plattformrollen und die einzelnen Organisationszuordnungen getrennt prüfen.
- Zur Liste zurückkehren; Suche, Filter und Seite bleiben erhalten.
News und Infos überblicken
Die News-Liste zeigt Datum, Kategorie, Überschrift und Zusammenfassung. Mehr lesen öffnet den vollständigen Inhalt. Suche, Kategorie und Zeitraum lassen sich weiterhin gemeinsam verwenden; eine Neu-Markierung bleibt vom Aufklappen unabhängig.
Laufzeiten von Sicherheitsprüfungen
Im Prüfverlauf steht der fachliche Prüfstatus im Vordergrund. Neue Prüfungen zeigen nach abgeschlossener Zeitmessung ihre Gesamtdauer. Die aufklappbaren Laufzeitdetails trennen tatsächlich ausgeführte Arbeitsschritte, einschließlich des Speicherns und Bestätigens der Ergebnisse.
Bei historischen Prüfungen sind Timingdetails nicht verfügbar. Konnte eine neue Laufzeitmessung nicht abgeschlossen werden, wird dies gesondert angezeigt. Fehlende Messwerte sind nicht null Sekunden und ändern weder das Prüfergebnis noch die Benachrichtigungen. Die Dauer nachgelagerter Benachrichtigungen gehört nicht zur Scanlaufzeit.
Aufgabe und Zugang
Die Plattformadministration unterstützt den technischen und übergreifenden Betrieb von OC//HSC. Plattformvorgänge erscheinen als eigener berechtigungsabhängiger Bereich im zentralen Postfach; die fachliche Bearbeitung bleibt von Vereins- und Veranstaltungsaufgaben getrennt.
Nur ausdrücklich berechtigte Plattformadministratoren sehen den Einstieg im Kontrollbereich. Die öffentliche Anleitung gewährt keinen Zugriff auf geschützte Funktionen.
Übergreifende Bereiche
Die geschützte Administration bündelt übergreifende Personen- und Zugangsvorgänge, Plattformhinweise, Rechtstexte, Zustellübersichten und betriebliche Statusinformationen.
Fachliche Aufgaben eines Vereins oder einer Veranstaltung werden weiterhin im jeweiligen Kontext bearbeitet und nicht pauschal in den Plattformbetrieb verschoben.
Anträge auf Vereinsanbindung
Ein Antrag aus dem Kontrollbereich erscheint als Plattformvorgang und als Rollenfreigabe. Der Vorgang nennt Benutzer, Personen-ID, Verband, Verein und gewünschte Rolle. Der Mitgliedsnachweis selbst befindet sich ausschließlich in der gesendeten E-Mail und wird nicht im Postfach oder Dokumentenbestand gespeichert.
Bei einer Freigabe werden die vorbereitete Mitgliedschaft und Rolle aktiviert. Bei einer Ablehnung werden beide inaktiv beziehungsweise abgelehnt und der Vorgang geschlossen. Eine optionale Antwort kann über den bestehenden Vorgang erfolgen.
- Vorgang und zugehörige Rollenfreigabe prüfen.
- Nachweis in der Plattform-E-Mail fachlich prüfen.
- Freigeben oder mit nachvollziehbarer Begründung ablehnen.
- Vorgang und Ergebnisstatus kontrollieren.
Interne Testorganisationen
Für kontrollierte technische Abnahmen können Plattformadministratoren unter Organisationen eine verborgene DVG-Testhierarchie vorbereiten. Der geführte Ablauf beschränkt die Auswahl auf den kanonischen DVG und bereits angelegte interne Testebenen.
Vor dem Anlegen zeigt OC//HSC Typ, Elternorganisation, technische Kennung und die deaktivierten Kommunikations- und Zahlungswege zur Kontrolle. Interne Testorganisationen erscheinen weder in regulären Organisationssuchen noch auf öffentlichen Seiten.
- Gewünschte Testebene und zulässige Elternorganisation auswählen.
- Name, Kurzname, technische Kennung, Referenz und Zweck angeben.
- Kontrollansicht prüfen.
- Interne Organisation anlegen und die Hierarchie in der Organisationsliste kontrollieren.
Cybersecurity und CRA-Nachweise
Der geschützte Bereich Cybersecurity & CRA zeigt Plattformadministratoren erfasste technische Komponenten, bekannte Schwachstellen, Prüfverläufe, geschützte SBOM-Dokumente und offene Sicherheitsmaßnahmen.
Schwachstellen werden kompakt je Komponenteninstanz, Version, Umgebung und Quelle zusammengefasst. Einzelne Advisory-IDs bleiben in den aufklappbaren Details vollständig such- und filterbar. Ein aktuelles Risiko benötigt einen belastbaren Bezug zur installierten Version oder Paketquelle; unsichere Zuordnungen erscheinen getrennt als Prüfung erforderlich.
Technische Betriebsnachweise und organisatorische Prüfungen werden getrennt angezeigt. Automatische Überwachung beschreibt den aktuellen Zustand eines Jobs oder Systems; die organisatorische Wiedervorlage ist eine davon unabhängige menschliche Prüfung. Bei Sicherungen, Wiederherstellung, Zertifikaten, Monitoring, Sicherheitsmeldungen, Malwareprüfung und Rollback bleiben nur aktuell belegte offene Punkte als Handlungsbedarf sichtbar. Eine unklare Debian-Versionszuordnung bleibt Prüfung erforderlich. Die Übersicht trifft keine automatische Aussage zur rechtlichen CRA-Konformität.
Historische Meldungen bleiben im Prüfverlauf auditierbar, gelten aber nicht automatisch als aktueller technischer Fehler. CRA-Readiness gleicht ihre frühere Ursache mit dem aktuellen Betriebsnachweis ab und zählt gleiche aktuelle Ursachen nur einmal.
Offene Punkte stehen getrennt unter „Technisch offen“ und „Organisatorisch offen“. Technische Hinweise nennen den konkreten Befund und vorhandene Anzahlen. Ein technischer Fehler öffnet keine bereits abgeschlossene organisatorische Entscheidung; diese lässt sich bei Bedarf bewusst über „Entscheidung bearbeiten“ öffnen.
Der Restore-Nachweis zeigt nur nach einer echten, vollständig bereinigten Wiederherstellungsprüfung den Status Nachgewiesen. Ein vorbereiteter Dienst oder Timer allein reicht nicht aus. Bei Fehlern bleiben Ursache, Cleanupstatus und ein späterer Recovery-Lauf nachvollziehbar, ohne Nutzdaten anzuzeigen.
Übersicht, Kontrollverzeichnis und einzelne Kontrolle sind getrennte Ansichten. Technische Bewertung, automatische Überwachung, Aktualität und organisatorischer Handlungsbedarf bleiben dabei eigenständig. Messwerte und Quellen stehen in den technischen Details. Der Entscheidungseditor öffnet nur ausdrücklich, auch bei einer fälligen Wiedervorlage.
Die Kennzahlen öffnen die passende Kontrollauswahl und können sich überschneiden. Suche, Bereich, technischer und organisatorischer Status, Handlungsbedarf, Nachweisart und Verantwortung lassen sich kombinieren. Sortierung, Seitengröße und Filter bleiben in der URL erhalten. Das Verzeichnis zeigt 10, 25, 50 oder 100 Kontrollen pro Seite.
Bei einer nicht anwendbaren organisatorischen Bewertung ist der fachliche Grund sichtbar und wird auch in den Readiness-Berichten ausgegeben. Optionale leere Angaben wie Vertretung, Eskalationsrolle oder Notiz erzeugen für sich allein keine offene Maßnahme. Der aktuelle Readiness-Stand kann als PDF, JSON oder CSV heruntergeladen werden; alle Formate verwenden unabhängig von der sichtbaren Filterung den vollständigen aktuellen Zustand und sind keine rechtliche Konformitätsbescheinigung.
Die Sicherheitsübersicht priorisiert kritische und hohe Risiken sowie offene Maßnahmen. Sie nennt den Zeitpunkt der letzten erfolgreichen Prüfung. Risiken zählen aktuelle Ursachen je Komponente, nicht jede einzelne Advisory-ID. Befunde mit bekanntem Fix sind nicht automatisch sofort installierbare Updates; die konkrete Handlung steht in den Schwachstellendetails. Die Fehlerzahl bezieht sich auf den ausdrücklich angezeigten rollierenden Zeitraum.
- In der Übersicht eine Kennzahl auswählen oder das Kontrollverzeichnis öffnen.
- Filter und Sortierung wählen, anwenden und die Trefferzahl prüfen.
- Eine Kontrolle öffnen und technische Nachweise, organisatorische Angaben und Entscheidungshistorie getrennt prüfen.
- Nur für eine beabsichtigte organisatorische Änderung „Entscheidung bearbeiten“ öffnen, stark bestätigen und speichern.
- Bei einem Konflikt den Entwurf prüfen. Erst nach bewusstem Verwerfen den aktuellen Stand neu laden. Bei unklarer Speicherantwort bleibt der Entwurf erhalten; eine unveränderte Wiederholung erzeugt keine zweite Entscheidung.
- Bei Bedarf den vollständigen aktuellen Bericht als PDF, JSON oder CSV herunterladen. Die Listenfilter begrenzen den Bericht nicht.
- Nach dem Speichern den aktuellen organisatorischen Stand und den neuen Historieneintrag prüfen.
Nachweis- und Entscheidungsverlauf
Die Historie einer Kontrolle kennzeichnet technische Nachweisaktualisierungen getrennt von organisatorischen Entscheidungen. Für neue Einträge lassen sich der vorherige und der neue Stand öffnen. Frühere Einträge enthalten nur die damals tatsächlich gespeicherten Angaben; fehlende historische Details werden nicht ergänzt.
Eine automatische Nachweisaktualisierung überschreibt keine organisatorische Entscheidung. Eine organisatorische Bearbeitung verändert keine technischen Prüfergebnisse. Ein verspätetes älteres Prüfergebnis ersetzt keinen neueren Nachweis. Bei einem organisatorischen Bearbeitungskonflikt bleibt Ihr Entwurf erhalten; laden Sie den aktuellen Stand erst nach bewusster Prüfung neu.
Kontrollen suchen
Die CRA-Suche findet Kontrollen anhand der angezeigten Bezeichnungen, Beschreibungen und Kontrollbereiche in der gewählten Sprache, zum Beispiel Datensicherung. Bisherige Bezeichnungen und technische Referenzen bleiben ebenfalls suchbar. Die Suche lässt sich mit den übrigen Kontrollfiltern kombinieren und verändert keine Nachweise oder Entscheidungen.
Automatische Prozesse
Unter Automatische Sicherheitsprozesse bündelt OC//HSC vorhandene Laufzeit-, Zeitplan-, Audit- und Nachweissignale. Angezeigt werden nur Prozesse, für die ein tatsächliches Signal vorliegt.
Statusfarben beschreiben den zuletzt erkannten Betriebszustand. Ein geplanter Prozess ohne bisherigen Lauf erscheint als „Geplant, noch nicht ausgeführt“ und bleibt damit klar von einem Prozess ohne Zeitplan getrennt. Ein älterer Fehler bleibt in der Historie sichtbar, hält einen später erfolgreich wiederhergestellten Prozess aber nicht dauerhaft im Fehlerstatus.
- Zeitraum, Status oder Prozess filtern.
- Letzten und nächsten Lauf sowie Auslöser und Intervall prüfen.
- Details für Laufzeiten, Fehler, Recovery, Quellen und Artefakte öffnen.
- Bei gelbem oder rotem Status den zugehörigen Nachweis und die Betriebsprotokolle prüfen.
Backup
Öffne in der geschützten Sicherheitsverwaltung die Betriebsprozesse und vergleiche beim Backup den letzten erfolgreichen Serverlauf mit dem letzten bestätigten externen Satz. Die Ansicht zeigt Nachweise; sie startet weder eine Sicherung noch eine Wiederherstellung.
Der externe Abruf ist für 22:30 Uhr Berliner Zeit vorgesehen. Fehlt nur die Bestätigung eines neuen Satzes, ist sie bis vor 23:30 Uhr ausstehend. Ein gemeldeter Abruffehler gilt sofort; auch ein über 36 Stunden alter letzter externer Erfolg ist unabhängig von der Nachlauffrist nicht aktuell.
Eine Bestätigung kann sich auf einen früheren Fehlversuch beziehen. Sie bedeutet dann nicht, dass eine neue Kopie vorliegt. Vergleiche Satz, letzten Versuch und letzten Erfolg. Erst eine Bestätigung desselben vollständigen Satzes mit passenden Prüfsummen belegt die externe Kopie; sie ersetzt keinen Wiederherstellungstest.
Restore
Ein Restore-Test gilt erst nach erfolgreicher Wiederherstellung, Prüfung und vollständiger Bereinigung als erfolgreich. Ein vorbereiteter Timer oder Dienst ist nur ein Zeitplansignal.
Fehler und spätere Wiederherstellungen bleiben in der Laufhistorie getrennt nachvollziehbar.
Rollback
Rollback-Nachweise zeigen, ob der vorgesehene Rückkehrpfad geprüft wurde und mit welchem Ergebnis. Die Ansicht löst keinen Rollback aus und verändert keine Releases.
Ein manueller oder ereignisgesteuerter Ablauf wird entsprechend gekennzeichnet.
Security Scan
Sicherheitsprüfungen erscheinen mit letztem Lauf, Ergebnis, Dauer und verfügbarem Zeitplan. Die Historie zeigt höchstens die letzten 50 Läufe und berechnet Durchschnittswerte aus höchstens 20 aktuellen Läufen. Auf Smartphones erscheinen die Läufe als lesbare Karten.
Der technische Laufstatus und die Abdeckung der vorgesehenen Quellen werden getrennt erklärt. Eine eingeschränkte Abdeckung nennt die verständliche Ursache; technische Codes bleiben aufklappbaren Details vorbehalten.
Eine manuelle vollständige Prüfung erhebt unmittelbar vor der Auswertung einen neuen Produktionsbestand und wird weiterhin nur über den geschützten bestehenden Ablauf gestartet. Scheitert diese Erhebung, entsteht kein neues SBOM aus älteren Bestandsdaten.
Nach Abschluss einer angezeigten manuellen Prüfung werden die zugehörigen Status- und Ergebnisanzeigen gemeinsam aktualisiert. Eine laufende Prüfung bleibt vom letzten erfolgreich abgeschlossenen Prüfstand unterscheidbar.
SBOM
Die SBOM-Erzeugung wird anhand tatsächlicher Scan- und Artefaktdaten erkannt. Erzeugte geschützte Artefakte bleiben ausschließlich im berechtigten Plattformbereich sichtbar.
Die Ablaufansicht ordnet die SBOM zwischen Inventarisierung und Schwachstellenbewertung ein, ohne eine zweite Bewertung zu erzeugen.
Operational Evidence
Operational Evidence fasst datensparsame Produktionssignale zu Backup, Wiederherstellung, Monitoring, Zertifikaten, Malwareprüfung und Benachrichtigungen zusammen. Quellen werden sichtbar, sensible Inhalte jedoch nicht offengelegt. Bei der Malwareprüfung werden Engine, Scannerdienst, Signaturaktualisierung, Signaturfrische, Socketschutz und Anwendungszugriff getrennt ausgewiesen.
Technische Nachweise bleiben klar von organisatorischen Bestätigungen und rechtlichen Bewertungen getrennt.
Datenlebenszyklus und Aufbewahrung
Die geschützte Lifecycle-Sicht ordnet Datenklassen nach Zweck, technischer Aufbewahrungslogik, Schutz und noch offener fachlicher oder juristischer Entscheidung. Bestandszahlen werden nur aggregiert angezeigt; Personen- und Zugangsdaten erscheinen dort nicht.
Der Abschnitt Retention & Audit zeigt für Mail- und Authentifizierungsprotokolle die versionierte Policy, den nächsten Bereinigungstermin, den letzten Lauf und den aktuellen Dry-Run-Bestand. Diagnose-, Zustell-, Sicherheits- und Rollennachweise besitzen getrennte Fristen.
Der bestehende Bereinigungsjob läuft täglich um 03:15 Uhr UTC. Die Ansicht stellt seine Zeitpunkte in Europe/Berlin dar und berücksichtigt damit Sommer- und Winterzeit.
Aktive Sitzungen und Sicherheitsmethoden bleiben unberührt. Die technischen Fristen sind interne Governance-Entscheidungen und keine pauschale gesetzliche Aufbewahrungsfrist.
- Datenklasse und Lifecycle-Status prüfen.
- Unter Retention & Audit Policy-Version, letzten Lauf und Überfälligkeit kontrollieren.
- Dry-Run-Bestand und zweckgebundene Frist vergleichen.
- Bei Bedarf den aktuellen aggregierten Bericht als PDF, JSON oder CSV herunterladen.
Datenintegrität
Die geschützte Datenintegritätsprüfung vergleicht zentrale fachliche Regeln und referentielle Zusammenhänge über Personen, Mitgliedschaften, Organisationen, Tiere, Veranstaltungen, Ergebnisse, Dokumente und weitere Plattformbereiche hinweg. Fachliche Einordnung und Sollzustand stehen in der Übersicht im Vordergrund; technische IDs bleiben aufklappbar verfügbar.
Auf Tablet und Smartphone werden Findings als strukturierte Abschnitte dargestellt. Ein technisch erfolgreicher Prüflauf kann Findings enthalten. Bewusst tolerierte historische Fallbacks werden als Hinweise von Fehlern und manuellen Prüffällen getrennt; die Ansicht verändert oder repariert keine Daten.
- Zusammenfassung und Zeitpunkt des aktuellen Prüflaufs kontrollieren.
- Bei Bedarf nach Domäne, Schweregrad oder Kategorie filtern.
- Sollzustand, kanonische Quelle und technische IDs eines Findings prüfen.
- Vor jeder fachlichen Korrektur Ursache, Schreibpfad und Aufbewahrungsregeln klären.
Benachrichtigungen
Die Benachrichtigungsübersicht zeigt je erkanntem Prozess Klasse, Eskalationsstufe, Empfänger, Mailregel, letzte Meldung und letzte Recovery.
Routineerfolge erzeugen keine E-Mail. Kritische oder handlungsbedürftige neue Ereignisse können sofort an die verantwortliche Person gesendet werden; normale relevante Änderungen und Recoveries werden höchstens einmal täglich zusammengefasst. Ohne zugewiesene Person fällt der Vorgang an die Plattformadministration.
Verantwortlichkeiten
Solange keine individuelle Person zugeordnet ist, liegt die Verantwortung standardmäßig bei der Plattformadministration. Das gilt für technische und organisatorische Aufgaben sowie für die Eskalation.
Eine bewusst ausgewählte Person hat Vorrang und wird nicht durch den Standard ersetzt. Eine Vertretung wird nur angezeigt, wenn sie ausdrücklich gepflegt wurde.
Wiedervorlage
Technisch automatisch überwachte Kontrollen benötigen keine manuelle Wiedervorlage. Organisatorische Regeln werden bei wesentlichen Änderungen erneut geprüft; kombinierte Kontrollen sind standardmäßig jährlich organisatorisch zu prüfen.
Ein konkretes Datum entsteht erst durch eine entsprechende Entscheidung. Der Prüfmodus selbst erzeugt keine künstliche Erledigungsfrist.
Erledigen bis
Eine Erledigungsfrist kann für offene, in Bearbeitung befindliche oder nicht umgesetzte Aufgaben gepflegt werden. Nach Abschluss oder bei Nichtanwendbarkeit wird keine Frist angezeigt.
Die Plattform setzt keine pauschalen Fristen. Die Kennzahl für überfällige Aufgaben führt zum gefilterten Verzeichnis; Zuständigkeit, Datum und überfällige Tage stehen in den Kontrolldetails.
Eskalation
Ohne individuelle Festlegung ist die Plattformadministration die Eskalationsrolle. Dringlichkeit und Wiederholung richten sich nach der sichtbaren Benachrichtigungsklasse.
Die Diagnosevorschau zeigt die vorgesehenen Wege und Empfänger, ohne eine Nachricht zu versenden oder einen Vorgang zu verändern.
Der Bereich Plattform-Mail-Bereitschaft zeigt, ob SMTP, Absender, Antwortadresse, Zugangsdaten und Prüfstatus vorhanden sind. Webdomain und Maildomain dürfen voneinander abweichen; entscheidend sind gültige Mailadressen und die Unterstützung durch das verwendete SMTP-Konto. Zugangsdaten selbst werden nicht angezeigt.
Ohne erfolgreich versandte Testmail werden keine Sicherheits-E-Mails freigegeben. Dashboard, Postfach, Audit und Recovery funktionieren weiterhin; die Ansicht weist klar auf die deaktivierte Zustellung hin.
Recovery
Nach einem Fehler zeigt die Historie einen späteren erfolgreichen Lauf als Recovery. Der aktuelle Status folgt dem jüngsten belastbaren Signal, während der ursprüngliche Fehler für die Nachvollziehbarkeit erhalten bleibt.
Bleibt ein Recovery aus, müssen Plattformadministratoren den betroffenen Prozess und seine Nachweisquellen prüfen.
Recovery wird im Dashboard und Audit auch dann nachvollziehbar, wenn keine Plattform-Mail konfiguriert ist. Eine E-Mail-Zusammenfassung erfolgt nur über einen tatsächlich verfügbaren Mailweg.
Schwachstellen nach Verantwortung bearbeiten
Die Schwachstellenansicht zählt aktuelle Ursachen statt jede einzelne Advisory mehrfach. Sie zeigt, ob eine Ursache eine Anwendungsabhängigkeit, Plattform-Laufzeit, ein Distributionspaket oder gemeinsam betriebene Infrastruktur betrifft. Anwendungsabhängigkeiten werden zusätzlich als Laufzeit, Build, Entwicklung/Test oder optional eingeordnet.
Aktuell bezeichnet ausschließlich den heute installierten Zustand. Prüfung erforderlich kennzeichnet eine noch nicht belastbar entschiedene Zuordnung zur aktuellen Version und ist kein bestätigtes Risiko. Historie enthält frühere Versionen und Nachweise ohne aktuellen Handlungsbedarf.
Bei transitiven Paketen zeigen die Details die Abhängigkeitskette. Client-, Server-, Job- und Build-Exposition sowie der belegte Produktionsbundle-Status erklären die technische Reichweite, ohne den Schweregrad eines Befunds zu verändern.
Paketquelle, installierte Version, verfügbarer Kandidat und der zur Paketquelle passende Hersteller- oder Distributionsnachweis bestimmen den nächsten Schritt. Für ein offiziell betriebenes ClamAV-Paket zeigt die Komponentenansicht zusätzlich den Releasekanal, den aktuellen Patchstand und den Supportzeitraum aus dem offiziellen Nachweis. Ein offiziell als nicht betroffen oder bereits behoben ausgewiesener aktueller Stand bleibt als aktueller Nachweis sichtbar, erzeugt aber keine offene Ursache. Weist die offizielle Quelle ausdrücklich keinen Schweregrad aus, zeigt OC//HSC dies als „Keine“ und erfindet weder CVSS-Wert noch Update-Aktion.
Ein sofort verfügbares Plattform- oder Betriebssystemupdate wird von einem ausstehenden Distributionsfix, einer dokumentierten Schwachstelle ohne verfügbare Behebung und einer notwendigen Kompatibilitäts- oder Backportprüfung getrennt.
Die Filter Verantwortung, Nächste Aktion, Abhängigkeitsklasse und Abhängigkeitsart grenzen die Arbeitsliste ein. PDF, JSON und CSV verwenden dieselbe zentrale Einordnung und trennen aktuelle Version, aktuellen Prüfbedarf und historische Nachweise.
- Schwachstellen öffnen und die Zusammenfassung der aktuellen Ursachen prüfen.
- Nach Verantwortung oder nächster Aktion filtern.
- Die Paketquelle und den verfügbaren Kandidaten in den Details prüfen.
- Nur den ausgewiesenen unterstützten Aktualisierungsweg verwenden.
- Nach dem Folgescan prüfen, ob die Ursache historisch geworden ist.
Betriebsprotokolle und Störungsnachweise
Die geschützte Ansicht Betriebsprotokolle zeigt Plattformadministratoren, ob die technischen Protokollquellen der Plattform aktiv, zugriffsgeschützt, begrenzt aufbewahrt und ordnungsgemäß rotiert werden. Aufklappbare Details nennen den letzten Nachweis, Speicherverbrauch und Aufbewahrungsstatus, ohne vollständige Rohprotokolle offenzulegen.
Für eine technische Störung lässt sich ein begrenzter Zeitraum auswählen und chronologisch auswerten. Clientabbrüche, Dienstumschaltungen und Anwendungsfehler werden dabei getrennt eingeordnet. Die zeitliche Korrelation ist ein Betriebsnachweis und allein noch keine Aussage über die Ursache.
- Betriebsprotokolle in der Plattformadministration öffnen.
- Status und letzten Nachweis der benötigten Quelle prüfen.
- Zeitraum und bei Bedarf Quelle oder Bereitstellung filtern.
- Den Nachweis als PDF, JSON oder CSV herunterladen und die ausgewiesene Prüfsumme zum Vergleich festhalten.
Sicher und nachvollziehbar arbeiten
Administrationsaktionen folgen den sichtbaren Bestätigungs-, Prüf- und Protokollierungswegen der Plattform. Verwende keine administrativen Möglichkeiten als Ersatz für fehlende fachliche Zuständigkeit.
Interne technische Details, Sicherheitsverfahren und Betriebsdaten gehören nicht in öffentliche Anleitungen, Nachrichten oder Supportantworten.