Nachvollziehbare Sicherheitsgrenzen

Sicherheitskontrollen für dedizierte Knoten – von physischen Grenzen bis zur Ereignisreaktion

Jede Bestellung umfasst einen eigenen physischen Mac-mini-Knoten, keine virtuelle Maschine. HexVM übernimmt Bereitstellung, Basisnetzwerk und Plattformbetrieb; Kunden verwalten Konten, Build-Schlüssel, Repository-Zugriffe und Daten auf dem Knoten.

Dedizierten Mac mieten Sicherheitsteam kontaktieren

Sicherheitsberichte werden ausschließlich über Konsolen-Tickets oder support@hexvm.com angenommen. Senden Sie niemals echte private Schlüssel, vollständige Zugriffstoken oder ungeschwärzte Anmeldedaten.

Dedizierter HexVM Mac-mini-Knoten und Oberfläche zur Steuerung des Sicherheitsstatus

Knotengrenzen prüfen Normal

Ressourcenzuordnung: Exklusiv pro Bestellung
Rechenform: Physischer Knoten
Verwaltungszugang: Anmeldedaten und Tickets kontrolliert

Knotenisolierung 1 pro Bestellung

Betriebsabdeckung 365 Tage

Serviceziel 99,9 %

Berichtskanäle 2

Verantwortungsaufteilung

Zuerst klären, wer was kontrolliert

Dedizierte physische Rechner verringern die gemeinsame Nutzung von Rechenressourcen. Sicherheit erfordert dennoch Maßnahmen von Plattform und Kunden. Im Folgenden werden Ressourcen, Berechtigungen, Plattformbetrieb und Kundenaufgaben getrennt erläutert.

Physische Ressourcengrenzen

Jede Bestellung entspricht einem unabhängigen Mac mini; CPU, Arbeitsspeicher und lokaler Speicher werden nicht mit Instanzen anderer Kunden geteilt. Verfügbar sind die M4-Basiskonfiguration (16 GB, 256 GB) und die M4-Pro-Konfiguration (64 GB, 2 TB).

Der Knoten ist einer Bestellung exklusiv zugeordnet und wird nicht nach virtuellen CPUs oder gemeinsamem Speicher abgerechnet.
Region und Modell werden bei der Bestellung festgelegt; die Verfügbarkeit liefert die Konsole in Echtzeit.
Vor Ablauf der Mietdauer sollten Daten migriert, Schlüssel widerrufen und lokale Sicherungen erstellt werden.

Kundenverwaltete Berechtigungen

Kunden verwalten Entwicklungsumgebung, Mitgliederrechte, SSH-Schlüssel, Repository-Anmeldedaten, Build-Cache und Automatisierungsaufgaben auf dem Knoten. Änderungen müssen vom Bestellverantwortlichen dokumentiert und geprüft werden.

Nach der ersten Verbindung temporäre Anmeldedaten aktualisieren und bevorzugt auf Schlüsselauthentifizierung umstellen.
Für CI-Runner, manuellen Betrieb und Veröffentlichungsaufgaben unterschiedliche Berechtigungsgrenzen festlegen.
Dasselbe Administratorkonto darf nicht dauerhaft von mehreren Personen gemeinsam genutzt werden.

Grenzen des Plattformbetriebs

HexVM übernimmt Bestellbereitstellung, Knotengesundheitsprüfungen, grundlegende Netzwerkkonnektivität, Servicestatus und Ticketbearbeitung. Vor Knotenaktionen werden Bestellzugehörigkeit und Umfang der Anfrage geprüft.

HexVM fordert niemals echte private Schlüssel oder vollständige Token per E-Mail an.
Anfragen zu Knotenaktionen sollten Knoten-ID, Region, Zeitpunkt und Auswirkungsbereich enthalten.
Maßnahmen der Plattform zielen auf die Wiederherstellung eines sicheren Zustands und die Klärung von Serviceauswirkungen.

Grundlage der gemeinsamen Verantwortung

HexVM stellt dedizierte physische Knoten und Plattformbetriebskontrollen bereit. Kunden sind für Konten, Code, Zertifikate, Schlüssel, Rechte in Drittanbieter-Repositories und Sicherungsstrategien auf dem Knoten verantwortlich. Bei Auffälligkeiten müssen beide Seiten eine geschwärzte Zeitleiste und reproduzierbare Belege teilen.

Zugriffskontrolle

Langzeitrisiken in fünf feste Maßnahmen aufteilen

Zugriffssicherheit hängt nicht von einer einmaligen Einrichtung ab. Teams sollten Aktualisierung von Anmeldedaten, geringste Rechte, Mitgliederentzug und Umgebungstrennung in Onboarding-, Release- und Offboarding-Prozesse aufnehmen.

Temporäre Anmeldedaten sofort aktualisieren

Nach Erhalt der Verbindungsdaten zunächst Knoten-ID, Region und Host-Fingerabdruck prüfen, dann das temporäre Passwort ändern. Anfangsdaten dürfen nicht in Team-Chats, öffentlichen Dokumenten oder Pipeline-Protokollen gespeichert werden.

SSH-Schlüssel bevorzugen

Jedem Mitglied und jeder Automatisierungsaufgabe einen eigenen Schlüssel zuweisen und Fingerabdruck sowie Zweck dokumentieren. Bei Geräte- oder Aufgabenwechseln oder vermutetem Schlüsselverlust den öffentlichen Schlüssel sofort entfernen und neu ausstellen.

Berechtigungen aufgabenbezogen begrenzen

Build-Aufgaben erhalten nur Rechte zum Lesen von Code, Schreiben in Build-Verzeichnisse und Hochladen von Artefakten. Werkzeuginstallation, Systemänderungen und Mitgliederverwaltung auf wenige Verantwortliche beschränken.

Beim Ausscheiden sofort Zugriffe entziehen

Persönliche öffentliche Schlüssel, Repository-Deploy-Schlüssel, CI-Runner-Registrierungstoken und Freigaben für gemeinsame Verzeichnisse entziehen und aktuelle Anmeldungen prüfen. Nicht nur ein einzelnes Kollaborationstool deaktivieren, während der Knotenzugriff bestehen bleibt.

Entwicklung, Test und Release trennen

Für jede Umgebung eigene Konten, Schlüssel und Repository-Berechtigungen verwenden. Release-Anmeldedaten gehören nicht in tägliche Entwicklungsskripte; Testaufgaben dürfen keine Schreibzugänge zum Produktionsspeicher für Artefakte lesen.

Datenschutz

Den Weg aus dem Knoten vor dem Dateneingang festlegen

Code, Build-Artefakte und Signaturmaterial haben unterschiedliche Sensibilitätsstufen. Für jeden Typ sind Übertragung, Speicherort, Zugriffsberechtigte und Löschzeitpunkt festzulegen.

Übertragung

Daten über geschützte SSH- oder VNC-Verbindungen übertragen und beim ersten Zugriff den Host-Fingerabdruck prüfen. Bei großen Dateien die Integrität kontrollieren und Build-Material nicht über öffentliche Links austauschen.

Verarbeitung

Code, Cache, Artefakte und sensible Materialien in eindeutig benannte Verzeichnisse legen. Temporäre Skripte dürfen Schlüssel nicht in Befehlsverlauf, Terminalausgabe oder Testberichte schreiben.

Aufbewahrung

Build-Schlüssel und Zertifikate nur Aufgaben mit Signatur- oder Veröffentlichungsbedarf zugänglich machen. Exportrechte begrenzen und Verantwortliche für Import, Rotation und Widerruf dokumentieren.

Freigabe

Vor Ende der Mietdauer benötigte Artefakte und Prüfprotokolle exportieren, Repository- und CI-Anmeldedaten widerrufen und Arbeitsverzeichnisse, Cache, temporäre Dateien sowie lokale Schlüsselkopien löschen.

Empfohlene Kontrollen für gängige Datentypen
Datentyp	Empfohlener Speicherort	Berechtigungsgrenze	Maßnahmen vor der Freigabe
Quellcode und Abhängigkeiten	Kontrolliertes Arbeits- und Build-Cache-Verzeichnis	Entwickler und zugewiesene Runner	Commit-Status prüfen und nicht versionierte sensible Dateien löschen
Build-Schlüssel und Zugriffstoken	Beschränkter Anmeldedatenspeicher oder Laufzeitinjektion	Nur zugehörige Pipeline-Aufgabe und Verantwortliche	Widerrufen, rotieren und lokale Kopien entfernen
Zertifikate und Bereitstellungsprofile	Berechtigungsgeschützte Signierumgebung	Signieraufgaben und Release-Verantwortliche	Erforderliche Sicherung exportieren und Kopie auf dem Knoten entfernen
Build-Artefakte	Artefaktverzeichnis oder vom Team freigegebener Speicherort	Test-, Release- und Prüfrollen	Prüfsummen kontrollieren und temporäre Versionen nach der Migration löschen
Protokolle und Diagnosepakete	Protokollverzeichnis mit begrenzter Aufbewahrungsdauer	Betrieb, Sicherheit und Aufgabenbesitzer	Nach Schwärzung archivieren und Originale mit Anmeldedaten löschen

Netzwerk und Protokolle

Jede Auffälligkeit mit Zeit, Umfang und Belegen erfassen

Verbindungs- und Build-Protokolle sollen die Analyse unterstützen, nicht unbegrenzt gespeichert werden. Einheitliche Zeitangaben, Felder und Aufbewahrungsregeln ermöglichen den Abgleich von Knotenereignissen mit Repository-, CI- und Artefaktsystemen.

Verbindungsprüfung und Erkennung von Auffälligkeiten

Verbindungszeit, Herkunftsbereich, Methode, Konto und Ergebnis protokollieren. Besonders auf wiederholte Fehler in kurzer Zeit, Anmeldungen zu ungewöhnlichen Zeiten, unbekannte öffentliche Schlüssel, plötzliche Rechteerhöhungen und wiederholt offline gehende Runner achten.

Erfolgreiche und fehlgeschlagene Anmeldungen mit einheitlichen Feldern erfassen.
Für Administrationsaktionen und Automatisierungsaufgaben unterschiedliche Konten verwenden.
Bei auffälliger Herkunft zuerst den Zugriff begrenzen und anschließend Belege sichern.

Zeitsynchronisierung und Protokollformat

Knoten, Repository-Plattform, CI-Scheduler und Artefaktsystem sollten dieselbe Zeitzone verwenden oder den Zeitzonenversatz eindeutig protokollieren. Zeitangaben in Tickets müssen mindestens minutengenau sein und Erstentdeckung sowie letzte Reproduktion nennen.

Knoten-ID, Aufgaben-ID, Commit-Kennung und Exit-Code aufbewahren.
Vor dem Versand Passwörter, Token, private Schlüssel und personenbezogene Daten entfernen.
Originalprotokolle getrennt von manuellen Analyseergebnissen speichern.

Empfehlungen zur Protokollaufbewahrung

Aufbewahrungsdauer nach Codesensibilität, Release-Häufigkeit und internem Prüfzyklus festlegen. Build-Ausgaben nur mit zur Analyse nötigen Feldern aufbewahren; Diagnosepakete mit sensiblen Inhalten kürzer speichern und Downloads begrenzen.

Für Entwicklungs-, Test- und Release-Umgebungen eigene Aufbewahrungsregeln festlegen.
Regelmäßig prüfen, ob Protokolle einer konkreten aufgabenverantwortlichen Person zugeordnet werden können.
Beim Löschen abgelaufener Protokolle auch exportierte Diagnosekopien entfernen.

Monitoring auf Kundenseite anbinden

Im Knoten können vorhandene Teamprüfungen für Prozesse, Speicher, Build-Warteschlangen und Runner eingebunden werden. Alarme sollten Knoten-ID, Region, Schwellenwert, Dauer und Wiederherstellungsstatus enthalten, statt nicht zuordenbare Screenshots zu senden.

Freien Speicher, wichtige Prozesse und Wartezeiten der Warteschlangen überwachen.
Serviceausfälle und einzelne fehlgeschlagene Builds getrennt alarmieren.
Nach der Wiederherstellung dieselbe Ereignisnummer für die Nachbesprechung beibehalten.

Betriebsstabilität

99,9-%-Serviceziel und Statusansicht der letzten 90 Tage

Alle Knoten laufen 365 Tage im Jahr normal. Die Statusansicht zeigt die Verfügbarkeit pro Tag; bei Auswirkungen verknüpfen Ereignismarkierungen Umfang, Dauer und Bearbeitungsprotokoll.

Serviceziel 99,9 %

Plattformseitige Auswirkungen gemäß den anwendbaren Servicebedingungen prüfen. Auswirkungen durch kundeneigene Konfigurationen, Anmeldedaten, Drittanbietersysteme oder höhere Gewalt werden nicht in die Plattformverfügbarkeit eingerechnet.

Beobachtungszeitraum: 90 Tage
Statusintervall: Täglich
Aktuelle Ereignismarkierung: Keine

Täglicher Servicestatus

Normal Serviceereignis

Vor 90 Tagen Vor 60 Tagen Vor 30 Tagen Heute

Zusammenfassung des Antrags auf Servicegutschrift

Wenn Sie der Ansicht sind, dass eine plattformseitige Auswirkung den in den Bedingungen festgelegten Umfang erreicht, reichen Sie über die Konsole ein Ticket mit Knoten-ID, Region, Start- und Endzeit, Verbindungs- oder Aufgabenergebnis sowie geschwärzten Protokollen ein. HexVM prüft Zeitleiste, Bestellzugehörigkeit und anwendbare Voraussetzungen und bearbeitet für berechtigte Bestellungen eine Servicegutschrift.

Konsolen-Ticket einreichen

Ereignisreaktion

Sechs Schritte von der Entdeckung bis zur Nachbesprechung

Bei Sicherheitsereignissen stehen Zugriffsschutz und Beweisintegrität an erster Stelle. Genaue Knoteninformationen und geschwärzte Protokolle von Kunden verringern Rückfragen und verkürzen die Analyse.

01

Entdecken

Auffälligkeit, Zeitpunkt der ersten Entdeckung, betroffene Knoten und Geschäftsbereich bestätigen. Originalfehler, Anmeldeprotokolle und Aufgabenkennungen sichern; keine Aktionen wiederholen, die Belege überschreiben könnten.
Kundenbeitrag: Knoten-ID, Region, Zeitleiste und Quelle der Entdeckung bereitstellen.
02

Isolieren

Je nach Risiko Zugriffseinstiege begrenzen, verdächtige öffentliche Schlüssel entfernen, relevante Automatisierungsaufgaben pausieren und unbeeinträchtigte Build- und Release-Ketten schützen.
Kundenbeitrag: Bestätigen, welche Konten, Repositories und Aufgaben pausiert werden können.
03

Untersuchen

Knoten-Anmeldungen, Rechteänderungen, Build-Aufgaben, Repository-Aktionen und Artefaktprotokolle verknüpfen, um Einstieg, Dauer, betroffene Objekte und Datenumfang zu bestimmen.
Kundenbeitrag: Geschwärzte Protokolle, Reproduktionsschritte und aktuelle Änderungsaufzeichnungen bereitstellen.
04

Beheben

Betroffene Anmeldedaten widerrufen, Rechte und Konfiguration korrigieren, auffällige Aufgaben bereinigen und die Wiederherstellung von Verbindungen, Builds, Signierung und Artefakt-Uploads prüfen.
Kundenbeitrag: Erforderliche Rotation von Repository-Token, Schlüsseln und Zertifikaten durchführen.
05

Benachrichtigen

Auswirkungsbereich, aktuellen Status, abgeschlossene Maßnahmen und nächsten Aktualisierungszeitpunkt über den verifizierten Bestellkontakt abstimmen. Sensible Informationen nicht über ungeprüfte Kanäle austauschen.
Kundenbeitrag: Verantwortliche benennen, die technische und geschäftliche Auswirkungen bestätigen können.
06

Nachbesprechen

Ursache, Erkennungslücken, Wiederherstellungsschritte und weitere Verantwortliche dokumentieren und dauerhafte Verbesserungen in Berechtigungsprüfung, Monitoring und Release-Checks aufnehmen.
Kundenbeitrag: Prüfen, dass Verbesserungen im Teamprozess tatsächlich umgesetzt werden.

Zugang für Sicherheitsberichte

Sicherheitslücken, verdächtige Anmeldungen oder Anmeldedatenrisiken melden

Sicherheitsprobleme werden ausschließlich über Konsolen-Tickets oder support@hexvm.com angenommen. Bei bestehenden Bestellungen und Knotenproblemen bevorzugt ein Ticket verwenden, damit die Bestellzugehörigkeit geprüft und der Vorgang verfolgt werden kann.

Sicherheits-Ticket in der Konsole

Für verdächtige Verbindungen, Änderungen von Knotenrechten, Serviceauswirkungen und Ereignisse bestehender Bestellungen, die eine Plattformprüfung erfordern. Ticket mit Knoten-ID, Region, Zeitpunkt, Auswirkungsbereich und geschwärzten Belegen ausfüllen.

In der Konsole ein Ticket einreichen

E-Mail für Sicherheitsberichte

Für noch keiner Bestellung zugeordnete Schwachstellenhinweise, reproduzierbare Sicherheitsprobleme oder Fragen zu Anmeldedatenrisiken. Der Betreff sollte Problemtyp und betroffene Komponente nennen; Anhänge müssen zuvor geschwärzt werden.

An support@hexvm.com senden

Ein bearbeitbarer Bericht sollte enthalten

Problemtyp, Zeitpunkt der Entdeckung und ob das Problem weiterhin reproduzierbar ist.
ID und Region des betroffenen Knotens sowie Seite oder Funktionspfad.
Minimale Reproduktionsschritte, erwartetes und tatsächliches Ergebnis.
Geschwärzte Anfragen, Fehlermeldungen, Protokollausschnitte oder Screenshots.
Durchgeführte Isolierungsmaßnahmen und Änderungen, die die Untersuchung beeinflussen könnten.

Nicht mit dem Bericht einreichen

Echte private Schlüssel, vollständige Zugriffstoken, vollständige Passwörter, ungeschwärzte Zertifikatsdateien oder direkt nutzbare Zugänge zu Repositories und Artefakten. Wenn sensible Felder geprüft werden müssen, zuerst den Feldtyp im Ticket nennen; das Supportteam gibt den sicheren Bearbeitungsweg vor.

Dediziertes Apple Silicon

Deinen Cloud-Mac mit klaren Grenzen betreiben

Vergleichen Sie Konfigurationen und Mietdauer der beiden dedizierten physischen Knoten und wählen Sie die passende Lösung für Xcode-Builds, CI/CD oder kontinuierliche Entwicklungsaufgaben. Alle Preise werden in US-Dollar (USD) abgerechnet.

Dedizierten Mac mieten Mietoptionen ansehen