Jede Bestellung entspricht während einer klar festgelegten Laufzeit einem dedizierten physischen Gerät, keiner virtuellen Maschine. ZoomMini betreibt den physischen Knoten und die Konsole; der Kunde ist für Systemkonten, Anwendungskonfiguration, Code, Geheimnisse und Backups verantwortlich. Klare Grenzen machen Berechtigungen auditierbar und widerrufbar.
Ein dediziertes physisches Gerät hält die Workloads des Kunden innerhalb einer klaren Gerätegrenze. Geräteexklusivität bedeutet jedoch nicht automatisch, dass alle Konten, Remote-Zugänge und Anwendungsdaten sicher sind. Ein umsetzbares Isolationsmodell umfasst gemeinsam die physische, Kontroll-, System- und Workload-Ebene.
Jede gültige Bestellung entspricht einem dedizierten physischen Gerät mit klarer Laufzeit. Das Gerät ist keine gemeinsam genutzte virtuelle Maschine; Prozessor, Arbeitsspeicher und lokaler Speicher werden anderen Kunden nicht als mandantenfähige virtuelle Sitzungen zugewiesen.
Die Konsole dient zum Abrufen von Gerätestatus und Verbindungsinformationen; VNC, Bildschirmfreigabe und SSH ermöglichen den Systemzugang. Konsolen- und Betriebssystemsitzungen bilden getrennte Berechtigungsebenen und sollten separat geschützt werden; schwache gemeinsame Zugangsdaten sind zu vermeiden.
Ein Remote-Adresszugang sollte nicht automatisch vollständige Systemberechtigungen gewähren. Administratorrechte, tägliche Entwicklerkonten, CI-Runner und temporäre Konten zur Fehleranalyse sollten getrennt und aufgabenbezogen vergeben werden. Nach Abschluss der Aufgabe sind sie zeitnah zu entziehen.
Ziel der Zugriffskontrolle ist nicht, zusätzliche Anmeldeschritte zu schaffen, sondern drei Fragen beantworten zu können: Wer hat das Gerät betreten, welche Berechtigungen wurden verwendet und ist der Zugriff nach dem Projektende entzogen?
Mehrere Personen sollten nicht dauerhaft dasselbe Systemkonto verwenden. Eindeutige Konten verknüpfen Terminalhistorie, Dateibesitz, Runner-Aktionen und Fehleranalysen mit konkreten Personen und ermöglichen den individuellen Entzug des Zugriffs beim Ausscheiden.
Verwenden Sie für verschiedene Personen und Automatisierungsaufgaben unterschiedliche Schlüssel und dokumentieren Sie Zweck und Inhaber. Private Schlüssel gehören ausschließlich auf kontrollierte Endgeräte oder in ein Schlüsselverwaltungssystem und dürfen nicht über Tickets, E-Mail, Chats oder Code-Repositories weitergegeben werden.
Für tägliche Builds sollten keine dauerhaften Administratorrechte verwendet werden. Begrenzen Sie Arbeitsverzeichnis, Repository-Umfang und erforderliche Befehle des CI-Runners. Bei vorübergehender Rechteerhöhung zuerst den Änderungszweck bestätigen und danach die ursprünglichen Rechte wiederherstellen.
Das Team sollte Systempasswörter, SSH-Schlüssel und Repository-Token gemäß internen Richtlinien regelmäßig rotieren. Bei Ausscheiden von Mitgliedern, Geräteübergabe, Schlüsseloffenlegung oder verdächtigen Logins ist die Rotation sofort durchzuführen, ohne den regulären Turnus abzuwarten.
Nicht mehr benötigte öffentliche Schlüssel, Konten, Runner-Registrierungen, gespeicherte Remote-Desktop-Einträge und Automatisierungsaufgaben löschen. Wird nur das Personenkonto deaktiviert, ein gemeinsam genutztes Token jedoch behalten, bleibt ein schwer zuzuordnender dauerhafter Zugangsweg bestehen.
ZoomMini stellt Gerät und Remote-Zugang bereit. Der Kunde entscheidet, welche Code-, Build-, Test- und Geheimnisdaten auf das Gerät gelangen, und ist dafür verantwortlich, vor Ende der Laufzeit Prüfung, Backup und Migration abzuschließen.
Wählen Sie für Remote-Arbeiten je nach Aufgabe VNC, Bildschirmfreigabe oder SSH. Prüfen Sie vor dem Verbinden die von der Konsole bereitgestellte Adresse und Geräteinformation. Kontrollieren Sie bei der ersten SSH-Verbindung den Hostschlüssel-Fingerabdruck; bei Änderungen Verbindung abbrechen und Ursache prüfen.
Repository-Zugangsdaten, Signaturmaterial, Deployment-Schlüssel und Dienst-Token verwaltet der Kunde selbst. Verwenden Sie bevorzugt ein kontrolliertes Schlüsselverwaltungssystem zur aufgabenbezogenen Injektion, legen Sie Gültigkeitsbereich und Widerrufsweg fest und schreiben Sie Geheimnisse nicht in Versionskontrollsysteme.
Entfernen Sie vor der Weitergabe von Informationen zur Fehleranalyse Passwörter, private Schlüssel, vollständige Token, vollständige Zahlungsdaten und nicht problembezogene personenbezogene Daten. Bewahren Sie Zeitpunkt, Befehle, Fehlercodes und notwendigen Kontext auf, damit der Fehler reproduzierbar bleibt.
Migrieren Sie Code, Build-Artefakte, Protokolle und Geschäftsdaten vor dem Ablauf und prüfen Sie, ob Backups lesbar sind. Widerrufen Sie anschließend Repository-Token, Deployment-Zugangsdaten und Runner-Registrierungen und löschen Sie nicht mehr benötigte lokale Kopien.
CI-Umgebungen verfügen häufig über Berechtigungen zum Lesen von Repositories, Signieren, Testen und Veröffentlichen. Teilen Sie diese Fähigkeiten in separate Geheimnisse auf, injizieren Sie sie phasenbezogen und stellen Sie sicher, dass jedes Geheimnis einzeln rotiert und widerrufen werden kann.
Token dürfen nur die benötigten Repositories und Aktionen abdecken. Ein Runner, der ausschließlich abruft, darf keine Administrationsrechte erhalten; temporäre Aufgaben dürfen keine langfristigen Veröffentlichungs-Token wiederverwenden.
Der Runner verwendet ein eigenes Konto und Arbeitsverzeichnis. Die Herkunft von Abhängigkeits-Caches sollte überprüfbar sein; Build-Skripte dürfen keine Geheimnisse aus Umgebungsvariablen oder Anfrage-Headern ausgeben.
Signaturzertifikate und zugehörige private Schlüssel gehören in ein kontrolliertes Schlüsselverwaltungssystem und werden nur für Signaturaufgaben injiziert. Nach Abschluss sind temporäre Dateien und Prozessumgebungen zu bereinigen.
Veröffentlichungs- und Repository-Token sind getrennt zu halten; Test-Pipelines dürfen keine Produktionsrechte erben. Bei Änderungen an Personen oder Projekten muss der Zugriff einzeln widerrufbar sein, ohne andere Aufgaben zu beeinträchtigen.
Prüfen Sie, ob Build-Skripte Umgebungsvariablen ausgeben, Fehlerbehandlungen vollständige Befehle anzeigen, Cache-Verzeichnisse Zugangsdaten enthalten oder Artefaktarchive versehentlich Konfigurationsdateien aufnehmen. Gelangt ein Geheimnis in ein Protokoll, löschen Sie nicht nur das Protokoll, sondern rotieren Sie auch die zugehörigen Zugangsdaten.
$ git grep -nE "TOKEN|PRIVATE_KEY|PASSWORD" -- .
$ find build/ -type f -name "*.env" -o -name "*.key"
$ security find-identity -v -p codesigning
$ launchctl list | grep runner
Prüfergebnis:
✓ Keine Geheimnisse im Klartext im Repository gefunden
✓ Build-Archiv enthält keine Zugangsdaten-Dateien
✓ Runner verwendet ein eigenes Systemkonto
✓ Signaturmaterial wird durch einen kontrollierten Prozess injiziertDas Ziel von ZoomMini für die Serviceverfügbarkeit beträgt 99,9 %. Alle Knoten laufen 365 Tage im Jahr stabil. Der Betriebsverlauf wird täglich dargestellt; Ereignismarkierungen weisen auf prüfbedürftige Statusänderungen hin und bedeuten nicht automatisch einen vollständigen Tagesausfall.
Wenn der Kunde der Ansicht ist, dass das Serviceziel nicht erreicht wurde, sollte er über die Konsole ein Ticket mit Bestellkennung, Knoten, betroffenen Zeiträumen, reproduzierbaren Symptomen und anonymisierten Protokollen einreichen. Berechtigte Anfragen werden gemäß den Servicebedingungen geprüft und durch Serviceguthaben ausgeglichen.
Servicebedingungen und Prüfkriterien ansehenBei verdächtigen Konten, unbefugtem Zugriff oder offengelegten Geheimnissen sollten Sie keine privilegierten Aufgaben weiterlaufen lassen, während Sie auf eine vollständige Bewertung warten. Begrenzen Sie zuerst den Einflussbereich, sichern Sie anschließend notwendige Aufzeichnungen, informieren Sie das Support-Team und rotieren Sie Geheimnisse.
Dokumentieren Sie Entdeckungszeit, Gerätekennung, Knoten, verdächtiges Konto, relevante Prozesse und betroffene Workloads. Unterscheiden Sie Anomalien der Konsole, Systemkonten, Repository-Token und Anwendungen, damit verschiedene Berechtigungsebenen nicht vermischt werden.
Verdächtige Automatisierungsaufgaben pausieren, ungewöhnliche Sitzungen widerrufen, betroffene Konten oder öffentliche Schlüssel deaktivieren und risikoreiche Token einschränken. Lassen Sie bekannten verdächtigen Zugriff nicht weiter anwachsen, nur um den Zustand zu bewahren; dokumentieren Sie auch Zeitpunkt und Ausführenden der Begrenzung.
Sichern Sie ereignisbezogene Login-Aufzeichnungen, Befehlshistorien, Runner-Ausgaben, Prozessinformationen und Fehlercodes. Anonymisieren Sie Daten vor dem Export und versenden Sie keine Passwörter, privaten Schlüssel, vollständigen Zahlungsdaten oder nicht ereignisbezogenen personenbezogenen Daten.
Senden Sie über ein Konsolenticket oder an support@zoommini.com Bestellkennung, Knoten, Zeitpunkt, bereits ausgeführte Begrenzungsmaßnahmen und anonymisierte Protokolle. Besteht weiterhin ein Risiko, kennzeichnen Sie den Betreff eindeutig mit „Sicherheitsvorfall“, damit die Anfrage schnell weitergeleitet werden kann.
Rotieren Sie abhängig vom Einflussbereich Systemzugangsdaten, SSH-Schlüssel, Repository-Token, Runner-Schlüssel, Signaturmaterial und Deployment-Zugangsdaten. Bestätigen Sie vor der Wiederaufnahme, dass alte Zugangsdaten ungültig sind, neue Berechtigungen minimal ausfallen und keine verdächtigen Prozesse mehr laufen.
Reichen Sie ein Ticket über die Konsole ein, damit die Anfrage mit Bestellung, Knoten und Gerätestatus verknüpft werden kann.
Senden Sie eine E-Mail an support@zoommini.com; geben Sie im Betreff „Sicherheitsvorfall“ und die Bestellkennung an.
Klare Verantwortungsgrenzen reduzieren Wartezeiten und wiederholte Rückfragen bei der Fehleranalyse. Physische Knoten, Konsole und Gerätebereitstellung gehören zum Betriebsumfang von ZoomMini; Konten, Anwendungen, Code, Geheimnisse und Backups innerhalb des Systems liegen im Kontrollbereich des Kunden.
| Kontrollbereich | Verantwortung von ZoomMini | Verantwortung des Kunden | Empfohlene Prüfpunkte |
|---|---|---|---|
| Physischer Knoten | Exklusive Zuordnung von Gerät und Bestellung, grundlegender Knotenbetrieb und Gerätestatus in der Konsole. | Gerät entsprechend dem Bestellzweck nutzen sowie Workloads und Datenmigration während der Laufzeit verwalten. | Gerätekennung, Knoten, Beginn und Ende der Laufzeit. |
| Konsolenkonto | Kontozugriff, Bestellverwaltung, Instanzstatus und Ticketzugang bereitstellen. | Anmeldedaten schützen, verdächtige Zugriffe erkennen und Berechtigungen zeitnah aktualisieren oder widerrufen. | Letzte Zugriffe, Bestelländerungen, Ticketverlauf. |
| Remote-Verbindung | Verbindungsinformationen und Status des zugehörigen Geräts in der Konsole bereitstellen. | Adresse und Hostschlüssel-Fingerabdruck prüfen, Remote-Zugangsdaten schützen und vertrauenswürdige Clients konfigurieren. | Knoten, Adresse, Fingerabdruck, Verbindungskonto. |
| Systemkonto | Nutzbare grafische macOS-Oberfläche und Befehlszeilenumgebung bereitstellen. | Eindeutige Konten anlegen, minimale Berechtigungen umsetzen, Zugangsdaten rotieren und ausgeschiedene Mitglieder entfernen. | Kontenliste, Liste öffentlicher Schlüssel, Administratorrechte. |
| Anwendungen und CI/CD | Betrieb der physischen Knoten und der Konsole aufrechterhalten. | Xcode, Abhängigkeiten, Runner, Skripte, Repository-Berechtigungen und Veröffentlichungsprozesse verwalten. | Runner-Konto, Arbeitsverzeichnis, Token-Umfang. |
| Code und Schlüssel | Nicht an Stelle des Kunden über Speicherung, Autorisierung oder Rotation von Code und Geheimnissen entscheiden. | Kontrolliertes Schlüsselverwaltungssystem verwenden und Klartext in Skripten, Repositories und Protokollen vermeiden. | Zweck, Umfang, Inhaber und Widerrufsverfahren der Geheimnisse. |
| Protokolle und Support | Anhand der Ticketinformationen Probleme an physischem Knoten und Konsole analysieren. | Genaue Zeitpunkte, Reproduktionsschritte und anonymisierte Protokolle einreichen; keine Geheimnisse senden. | Fehlercode, Version, Zeitleiste, ausgeführte Maßnahmen. |
| Backups und Migration | Laufzeitinformationen von Bestellung und Gerät in der Konsole anzeigen. | Backup-Strategie festlegen, Wiederherstellbarkeit prüfen und Daten vor Laufzeitende migrieren. | Backup-Integrität, Wiederherstellungstest, Token-Widerruf. |
Der Bestellung zugeordnetes dediziertes physisches Gerät, grundlegender Knotenbetrieb, Gerätestatus, Bestellverwaltung und Bearbeitung von Support-Tickets.
Betriebssystemberechtigungen, Remote-Zugangsdaten, Anwendungskonfiguration, Code, Schlüssel, Build-Pipelines, Protokollanonymisierung, Backups und Migration.
Der Kunde liefert Bestellung, Knoten, Zeitleiste und anonymisierte Protokolle; ZoomMini grenzt den Infrastrukturstatus anhand der Verantwortungsgrenzen ein, und beide Seiten prüfen ihre jeweiligen Berechtigungsebenen.
Wählen Sie Modell und Laufzeit und konfigurieren Sie die Umgebung anhand einer Checkliste für eindeutige Konten, SSH-Schlüssel, minimale Berechtigungen, kontrollierte Schlüssel-Injektion und Migration vor Ablauf.