Physikknoten und Zugriffsgrenzen

Sicherheit beginnt mit einem dedizierten Physikknoten – nicht mit vagen Versprechen

Jede gültige Bestellung erhält einen dedizierten Apple-Silicon-Physikknoten. VMOak trennt Verwaltung, Bereitstellung und Kunden-Workloads und begrenzt Verwaltungszugriffe durch Zugangsdaten, Wartungsfreigaben und Aktivitätsprotokolle.

Sicherheit ist keine einseitige Funktion. Wir verantworten die Knotenbereitstellung, Plattformkonten und notwendige Wartungszugriffe; Kunden verantworten Repository-Berechtigungen, Deployment-Token, Arbeitsdateien, Verbindungsendpunkte und Teamzugriffe.

Cloud-Mac mieten Leitfaden für sichere Verbindungen
Knotenzuordnung
1 gültige Bestellung entspricht 1 dedizierten Physikknoten
Zugriffsmethode
Temporäre Zugangsdaten werden nach der Übergabe vom Kunden erstmals geändert
Supportgrenzen
Keine vollständigen privaten Schlüssel oder Repository-Token erforderlich
SESSION SECURITY RECORD

Protokoll zur Ausstellung von Remotesitzungen

Grenzen bestätigt
01
Bestellung und Knoten verknüpft Modell, Knoten und Bestellinhaber werden bestätigt; physische Rechenressourcen werden nicht mit anderen Bestellungen geteilt.
Abgeschlossen
02
Prüfung vor der Übergabe Systemstart, Netzwerkverbindung, Speicherkapazität und Status des Zugriffskontos werden geprüft.
Abgeschlossen
03
Temporäre Zugangsdaten ausgestellt Sie werden über einen kontrollierten Übergabeweg bereitgestellt und müssen nach der ersten Verbindung sofort geändert werden.
Ausgestellt
04
Wartungsberechtigungen begrenzt Zugriff erfolgt nur im autorisierten Fehlerfall und im erforderlichen Umfang; Grund und Ergebnis werden protokolliert.
Begrenzt
Sitzungsprinzipien Minimale Berechtigungen · Nachvollziehbar · Widerrufbar
Vertrauensmodell

Plattform- und Kundenkontrolle haben klar abgegrenzte Zuständigkeiten

Die grundlegende Grenze von VMOak ist die Zuordnung eines Physikknotens, nicht ein logisches Kontingent auf einem gemeinsam genutzten Host. Solange die Bestellung gültig ist, steht der zugewiesene Mac ausschließlich diesem Kunden zur Verfügung. Die Verwaltung übernimmt Bestellung, Bereitstellung und notwendige Wartung; Kunden-Workloads laufen auf dem zugewiesenen Knoten.

01

Isolation des Physikknotens

Jede Bestellung erhält einen dedizierten Physikknoten. Prozessor, Arbeitsspeicher und lokaler Speicher werden nicht mit anderen Kundenbestellungen geteilt. Remote-Desktop-, SSH- und Build-Prozesse laufen auf demselben zugewiesenen Gerät.

  • Knotenidentität und Bestellaufzeichnung verknüpft
  • Modell und Speicherkapazität vor der Übergabe prüfen
  • Nach Ende der Bestellung werden die bisherigen Zugriffswege deaktiviert
02

Trennung von Verwaltung und Workloads

Die Konsole dient dem Bestellstatus, der Übergabe von Zugangsdaten und Supportanfragen; sie ist kein Arbeitsverzeichnis für Kundencode, Build-Artefakte oder Projektdateien. Kundenaufgaben werden auf dem zugewiesenen Physikknoten ausgeführt.

  • Supportanfragen erfassen nur zur Fehleranalyse notwendige Informationen
  • Verwaltungsaktionen erfolgen im erforderlichen Umfang
  • Temporäre Berechtigungen werden nach Abschluss der Fehlerbehebung entzogen
03

Verantwortung des Kunden

Der Kunde entscheidet, wer eine Verbindung zum Knoten herstellen darf, welche Repository-Token gültig sind und welche Daten auf den Remote-Mac gelangen. Änderungen von Teamrechten, der Widerruf von Schlüsseln und die Sicherung von Geschäftsdaten sollten in interne Abläufe integriert werden.

  • Geltungsbereich und Laufzeit von Repository-Token begrenzen
  • Zugriff nach Austritt oder Rollenwechsel sofort entfernen
  • Vertrauliche Dateien verschlüsseln und unabhängig sichern
Übergabeprüfung

Vor der Ausstellung der Zugriffsdaten fünf Gerätekontrollen durchführen

Die Übergabeprüfung bestätigt, dass der zur Bestellung gehörende Physikknoten einsatzbereit ist. Geprüft werden Gerät, System, Netzwerk, Speicher und Zugriffskonto; nicht verifizierte Benchmarkwerte ersetzen keine Einsatzbereitschaft.

  1. 01

    Gerätestatus

    Identifikationsdaten des Physikknotens, bestelltes Modell und grundlegender Hardwarestatus werden abgeglichen, damit Übergabeprotokoll und tatsächlich zugewiesenes Gerät übereinstimmen.

    Nach Prüfung ausgestellt
  2. 02

    Systemstart

    Es wird bestätigt, dass macOS normal startet, grafische Oberfläche und Kommandozeile erreichbar sind und Systemzeit sowie Basisdienste den Übergabeanforderungen entsprechen.

    Start bestätigt
  3. 03

    Netzwerkverbindung

    Es wird geprüft, ob der Knoten notwendige eingehende Verbindungen und ausgehenden Zugriff ermöglicht; außerdem werden die für Remote Desktop und SSH erforderlichen Dienste kontrolliert.

    Verbindung bestätigt
  4. 04

    Speicherkapazität

    Integrierter Speicher und ausgewählte Zusatzoptionen werden abgeglichen; sichtbare Kapazität und Dateisystemstatus werden geprüft, damit Konfiguration und tatsächliche Kapazität übereinstimmen.

    Kapazität geprüft
  5. 05

    Zugriffskonto

    Es wird bestätigt, dass das temporäre Konto für die erste Verbindung funktioniert. Der Ausstellungsumfang wird protokolliert; die erste Änderung der Zugangsdaten ist die erste Sicherheitsmaßnahme nach der Übergabe.

    Änderung durch Kunden ausstehend
Sicherheit von Zugangsdaten

Temporäre Zugangsdaten gelten nur für den ersten Zugriff; der Kunde übernimmt den dauerhaften Zugriff

Zugangsdaten sind als einmalige Ausstellung zu behandeln, nicht als dauerhaft weitergebbares Passwort. Ändern Sie sie sofort nach der ersten Verbindung und trennen Sie Zugriffe nach Personen und Automatisierungsaufgaben, um das nicht nachvollziehbare Risiko gemeinsam genutzter Passwörter zu verringern.

Lebenszyklus der Zugangsdaten Von der Ausstellung bis zum Widerruf
Ausstellung

Zugriff mit temporärem Konto

Adresse, Benutzername und temporäre Zugangsdaten werden im Übergabeprotokoll bereitgestellt. Diese Informationen dürfen nicht an öffentliche Gruppen, Code-Repositories oder Build-Protokolle weitergeleitet werden.

Ändern

Nach der ersten Verbindung wechseln

Verwenden Sie ausreichend lange Zugangsdaten, die nicht bei anderen Diensten eingesetzt werden. Bei mehreren Teammitgliedern sollte nicht dauerhaft dieselbe interaktive Anmeldung gemeinsam genutzt werden.

Trennen

Personen und Automatisierung getrennt autorisieren

Interaktiver Remote Desktop, SSH-Administration und CI/CD-Runner verwenden unterschiedliche Berechtigungspfade. Automatisierungstoken erhalten nur den für Aufgabe und Repository erforderlichen Umfang.

Widerrufen

Nach Änderungen im Team sofort bereinigen

Bei Austritt, Rollenwechsel oder Verlust eines Geräts werden zugehörige Public Keys, Token und Kontoberechtigungen widerrufen; außerdem werden aktuelle Anmeldeprotokolle geprüft.

SSH-Schlüssel

Nur den Public Key hochladen, niemals den vollständigen privaten Schlüssel

Der private Schlüssel bleibt auf dem vom Kunden kontrollierten Endgerät oder in einem kontrollierten Schlüsselsystem. Verwenden Sie für Personen und Automatisierungsaufgaben jeweils eigene, erkennbare Schlüssel, damit ein Widerruf gezielt möglich ist.

  • Public Keys nach Benutzer oder Aufgabe benennen
  • Lokale Leserechte für private Schlüsseldateien begrenzen
  • Zugehörigen Public Key nach Ende der Nutzung löschen
Beispiel für die Berechtigungsprüfung 
identity: build-runner
scope: repository-read
interactive-login: false
expires: project-policy
owner: mobile-ci-team

Das Beispiel veranschaulicht das Prinzip minimaler Berechtigungen und bedeutet nicht, dass die Plattform Repository-Zugriffsrichtlinien für den Kunden erstellt.

Wartungszugriff

Wenn menschliches Eingreifen nötig ist, braucht der Zugriff einen Grund, einen Umfang und ein Ende

Eine Supportanfrage erzeugt nicht automatisch Zugriff auf Kunden-Workloads. Nur wenn der Kunde ausdrücklich autorisiert und ein Remote-Fehler nicht anhand von Statusinformationen, anonymisierten Protokollen oder kundenseitigen Maßnahmen gelöst werden kann, beginnt eine notwendige manuelle Analyse.

01

Problem und Autorisierung bestätigen

Bestellnummer, Knoten, Zeitpunkt, Auswirkungsumfang und bereits durchgeführte Prüfungen des Kunden werden protokolliert. Vor dem Zugriff auf den Knoten wird der Zweck erläutert.

02

Erforderlichen Umfang begrenzen

Der Zugriff umfasst nur Systemstatus, Dienstkonfiguration oder Protokolle, die für den aktuellen Fehler erforderlich sind. Unbeteiligter Code und Geschäftsdaten werden nicht zur Fehleranalyse durchsucht.

03

Vorgang protokollieren

Wichtige Aktionen, Beobachtungen und Konfigurationsänderungen werden festgehalten, damit eine spätere Prüfung Kundenaktionen, Systemstatus und Supportaktionen unterscheiden kann.

04

Beenden und Berechtigungen entziehen

Nach Abschluss der Fehlerbehebung werden temporäre Zugriffswege geschlossen; der Kunde erhält eine Erklärung zu Ergebnis, Änderungen und weiter zu beobachtenden Signalen.

Häufige Supportfälle und zulässiger Informationsumfang
Szenario Vom Kunden bevorzugt bereitzustellen Mögliche Wartungsaktion Nicht übermitteln
Fehler bei der Remote-Verbindung Zeitpunkt, Clientnetzwerk, Fehlermeldung, Knotenkennung Dienststatus, Portpfad und Kontostatus prüfen Vollständiger privater Schlüssel, nicht anonymisiertes Repository-Token
Build-Prozess unterbrochen Befehl, Exit-Code, anonymisierte Protokolle, beobachtete Ressourcennutzung Systemprozesse, Speicherplatz und Basisdienste prüfen Vollständiger Projektquellcode, Produktionsschlüssel
Ungewöhnliche Speicherkapazität Zusammenfassung des Verzeichnisverbrauchs, Bestellkonfiguration, erwartete Kapazität Dateisystem, Mount-Status und Bestelloptionen prüfen Inhalte von Geschäftsdaten, unverschlüsselte Datenkopien
Netzwerk und Remotesitzungen

Sichere Verbindungen hängen von Übertragung, Ports, Endgeräten und dem Sitzungsabschluss ab

Die Netzwerkkontrolle eines Remote-Mac lässt sich nicht darauf reduzieren, ob eine Verbindung möglich ist. Fähigkeiten des Endgeräts, offene Ports, Gerätestatus des Clients und das Beenden der Sitzung bestimmen gemeinsam das tatsächliche Risiko. Kunden sollten verschlüsselte Verbindungen bevorzugen und unnötige Netzwerkzugänge begrenzen.

Remote-Desktop-Sitzung

Stellen Sie sicher, dass der Client die erforderliche Verschlüsselung unterstützt, und speichern Sie keine dauerhaften Zugangsdaten auf nicht vertrauenswürdigen Endgeräten. Beenden Sie die Sitzung aktiv und schließen Sie nicht mehr benötigte Clientfenster.

Vor der Verbindung
Adresse, Konto und Herkunft des Clients prüfen; sicherstellen, dass das lokale Gerät aktualisiert ist und eine Bildschirmsperre verwendet.
Während der Verbindung
Keine dauerhaften Schlüssel über die Zwischenablage übertragen und vertrauliche Konfigurationen nicht bei geteilter Bildschirmansicht anzeigen.
Nach der Verbindung
Grafische Sitzung beenden, temporäre Downloads löschen und prüfen, dass vertrauliche Anwendungen nicht im Vordergrund geöffnet bleiben.

SSH und Automatisierungsverbindungen

Verwenden Sie eigene Public Keys und Token mit minimalen Berechtigungen für Automatisierungsaufgaben. Nicht öffentlich benötigte Dienste sollten keine zusätzlichen Ports öffnen; temporäre Debug-Zugänge sind nach Abschluss der Aufgabe zu schließen.

Portkontrolle
Nur für die Aufgabe erforderliche Zugänge offenlassen und irrelevante Dienste nicht dauerhaft aus Bequemlichkeit freigeben.
Schlüssel trennen
Personen- und Runner-Schlüssel sowie Repository-Lese- und Veröffentlichungsberechtigungen getrennt verwalten.
Anomalien untersuchen
Bei unbekannten Anmeldungen zuerst die zugehörigen Schlüssel widerrufen und anschließend Zeitlinie, Quelladresse und Prozessinformationen sichern.
Grenzen der Abrechnungsdaten

Zahlungsstatus wird der Bestellung zugeordnet; vollständige Kartendaten gelangen nicht in die VMOak-Seite

Der Zahlungsprozess speichert nur die für Bestellabschluss, Statusprüfung und Abrechnungsfragen erforderlichen Informationen. Beide Zahlungsarten werden in US-Dollar (USD) abgerechnet; das tatsächlich verfügbare Gateway richtet sich nach dem Ergebnis beim Bezahlvorgang.

Kartenzahlung

Visa / Mastercard / Amex

Kartenzahlungen werden über Stripe verarbeitet. VMOak vermeidet die Speicherung vollständiger Kartennummern, Sicherheitscodes und anderer vollständiger Kartendaten; die Bestellung erhält nur für Zahlung und Abrechnung notwendige Statusinformationen.

  • Abrechnung in US-Dollar (USD)
  • Bestellprotokoll enthält Zahlungsstatus und notwendige Transaktionsreferenz
  • Abrechnungsfragen werden über ein Konsolen-Ticket oder die Support-E-Mail bearbeitet
On-Chain-Zahlung

USDT-TRC20

USDT-TRC20-Bestellungen werden anhand der On-Chain-Transaktion geprüft. Bei Abrechnungsfragen können Kunden Bestellnummer, Transaktionskennung und Zahlungszeitpunkt angeben, jedoch keine Wallet-Private-Keys oder andere Kontrollzugangsdaten.

  • Preisangabe in US-Dollar (USD)
  • Abgleich anhand von Bestellung und On-Chain-Transaktionskennung
  • Private Schlüssel und Wiederherstellungsinformationen bleiben stets beim Kunden
VMOak benötigt Bestellnummer, Zahlungsstatus, notwendige Transaktionsreferenz VMOak benötigt nicht Vollständige Kartendaten, Wallet-Private-Keys, Zugangsdaten zu nicht beteiligten Konten
Reaktion auf Sicherheitsvorfälle

Zuerst Fakten bestätigen, dann Auswirkungen isolieren, anschließend wiederherstellen und auswerten

Bei der Bearbeitung von Sicherheitsvorfällen ersetzen Vermutungen keine Belege. Nach Eingang eines Berichts bestätigt VMOak zunächst Bestellung, Knoten, Konto und Zeitraum, begrenzt dann risikobasiert die Zugriffswege, sichert notwendige Informationen und führt die Untersuchung weiter.

  1. 01

    Bestätigen

    Berichtsteller, Bestellnummer, Knoten, Zeitpunkt der ersten Feststellung, Auffälligkeiten und anhaltende Auswirkungen abgleichen; Verbindungs-, Konto- und potenzielle Sicherheitsprobleme unterscheiden.

    Zeitlinie erstellen
  2. 02

    Isolieren

    Verdächtige Sitzungen, Zugangsdaten oder Netzwerkzugänge entsprechend dem Auswirkungsumfang begrenzen. Ziel ist, eine Ausweitung des Risikos zu verhindern und zugleich Beweise für die weitere Untersuchung zu erhalten.

    Auswirkungsumfang begrenzen
  3. 03

    Untersuchen

    Zugehörige Anmeldeprotokolle, Prozessinformationen, Konfigurationsänderungen, Supportaktionen und vom Kunden bereitgestellte anonymisierte Belege prüfen, um Einstiegspunkt, betroffene Objekte und Dauer zu bestimmen.

    Belege prüfen
  4. 04

    Wiederherstellen

    Nach dem Schließen des Risikozugangs erforderliche Zugriffe wiederherstellen, betroffene Zugangsdaten oder Konfigurationen aktualisieren und erforderliche Repository-Token-Widerrufe, Schlüsselrotationen und Dateiprüfungen durch den Kunden benennen.

    Betriebsbereitschaft wiederherstellen
  5. 05

    Benachrichtigen und auswerten

    Betroffene Kunden über bestätigte Fakten, Maßnahmen, verbleibende Risiken und empfohlene Schritte informieren. Nicht bestätigbare Punkte werden klar gekennzeichnet und nicht als Schlussfolgerung dargestellt.

    Bearbeitungsprotokoll erstellen
Vorfall melden

Bitte die kleinste Belegmenge bereitstellen, mit der sich eine Zeitlinie rekonstruieren lässt

Übermitteln Sie bevorzugt Bestellnummer, Knoten, Zeitpunkt der ersten Feststellung, Zeitpunkt des letzten normalen Zustands, auffällige Quelladresse, Fehlermeldung, betroffene Konten, bereits durchgeführte Isolationsmaßnahmen und anonymisierte Protokolle. Übermitteln Sie keine vollständigen privaten Schlüssel, Repository-Haupttoken oder nicht anonymisierten Geschäftsdaten.

Über die Konsole ein Support-Ticket einreichen Vorfall per E-Mail melden
Sicherheitscheckliste für Kunden

Diese Maßnahmen vor der Einbindung des Knotens in das Team einzeln abschließen

Die Checkliste gilt für Remote-Entwicklung, CI/CD, selbst gehostete Runner, KI-Experimente und kreative Workflows. Je größer das Team, desto wichtiger sind nachvollziehbare Verantwortliche und Intervalle für jeden Punkt.

01

Erste Zugangsdaten ändern

Temporäre Zugangsdaten unmittelbar nach der ersten Verbindung ändern und niemals dasselbe Passwort für persönliche E-Mail, Code-Hosting oder andere Server verwenden.

Verantwortlich: Knotenadministrator
02

Repository-Token begrenzen

Nur die für aktuelles Projekt und Aufgabe erforderlichen Berechtigungen vergeben, Lese-, Build-, Veröffentlichungs- und Verwaltungsrechte trennen und ein internes Erneuerungsintervall festlegen.

Verantwortlich: Repository-Administrator
03

Personen- und Runner-Schlüssel trennen

Automatisierungsaufgaben dürfen keine Anmeldeschlüssel von Personen wiederverwenden. Für jeden Runner eine eigene Identität verwenden, damit Deaktivierung, Untersuchung und Rotation möglich sind.

Verantwortlich: CI/CD-Administrator
04

Zugriffe regelmäßig bereinigen

Lokale Konten, SSH-Public Keys, Repository-Token und Automatisierungskonfiguration prüfen und Zugänge abgeschlossener Projekte oder nicht mehr verwendeter Dienste löschen.

Verantwortlich: Verantwortlicher für Teamzugriffe
05

Vertrauliche Dateien verschlüsseln

Vor dem Hochladen auf den Knoten prüfen, ob die Datei tatsächlich benötigt wird. Vertrauliche Daten mit einer vom Kunden kontrollierten Verschlüsselung schützen und unabhängig sichern.

Verantwortlich: Dateneigentümer
06

Teamzugriffe zeitnah entfernen

Bei Austritt, Rollenwechsel oder Ende eines externen Auftrags Remote-Konten, Public Keys, Token und Berechtigungen für gemeinsam genutzte Verzeichnisse gleichzeitig widerrufen.

Verantwortlich: Teamleitung
Bei jeder Änderung im Team Konten, Public Keys und Repository-Token prüfen
Bei jedem Projektabschluss Cache, Build-Artefakte und temporäre Zugangsdaten bereinigen
Bei jedem Vorfall Zuerst Belege sichern, dann Zugang schließen und Ticket einreichen
Mit klaren Grenzen beginnen

Einen Cloud-Mac wählen, der ausschließlich einer Bestellung zugeordnet ist

Prüfen Sie zunächst die Konfiguration M4 oder M4 Pro, die sechs verfügbaren Knoten und den Abrechnungszeitraum; schließen Sie die Bestellung anschließend in der Konsole ab. Der tatsächliche Verfügbarkeitsstatus des Knotens wird in Echtzeit von der Konsole angezeigt.

Cloud-Mac mieten Konfiguration und Preise ansehen