Sicherheitsmodell für Physikknoten

Die Sicherheitsgrenzen des Cloud-Macs bei jedem Zugriff durchsetzen

RunnerVPS liefert für jede Bestellung einen dedizierten Apple-Silicon-Physikknoten. Sicherheit hängt nicht nur von der exklusiven Nutzung des Geräts ab, sondern auch davon, wie Ihr Team SSH-Schlüssel verteilt, VNC nutzt, Build-Geheimnisse injiziert, Toolchains aktualisiert und vor Ende der Laufzeit Daten exportiert.

Knoten auswählen und bestellen Verbindungs- und Fehlerbehebungsdoku ansehen

Ressourcengrenze: Eine Bestellung entspricht einem Physikknoten
Lokaler Speicher: Nicht mit anderen Mandanten geteilt
Verwaltungsprinzip: Minimale Zugangsdaten, nachvollziehbare Aktionen

Sicherheitsübergabe bestätigt NODE ACCESS / READY

Dedizierter Knoten

Bestellzuordnung Gerät und Bestellung einander zugeordnet

Zugangsdatenübergabe Direkt nach dem ersten Zugriff rotieren

Teamzugriff Individuelle Schlüssel pro Mitglied

Laufzeitende Artefakte exportieren und Daten entfernen

Rechenressourcen: Dediziert
Fernzugriff: SSH / VNC
Prüfprotokolle: Regelmäßig durch den Nutzer erstellt
Herkunft der Geheimnisse: Eigener Prozess des Nutzers

Die Übergabe ist nicht das Ende des Sicherheitsprozesses VERIFY → LIMIT → ROTATE → REMOVE

Überblick über das Sicherheitsmodell

Dedizierte Physikknoten schaffen klare Ressourcengrenzen

RunnerVPS stellt dedizierte Cloud-Mac-Physikknoten statt gemeinsam genutzter virtueller Maschinen bereit. Rechenressourcen und lokaler Gerätespeicher werden nicht mit anderen Mandanten geteilt. Konten, Code, Schlüssel und Softwarekonfigurationen müssen jedoch weiterhin vom nutzenden Team verwaltet werden.

Geräteisolierung

Jede Bestellung entspricht einem dedizierten Physikknoten. CPU, Arbeitsspeicher und integrierte SSD werden nicht mit anderen Mandanten geteilt. So kann Ihr Team Inventar, Zugriffsliste und Übergabeprotokoll anhand einer eindeutigen Gerätekennung führen.

Bestellung ↔ Gerät Exklusive physische Ressourcen

Klare Zugriffsverantwortung

Sie entscheiden, wer sich am Gerät anmelden darf, welche Konten verwendet werden und wann Schlüssel widerrufen werden. Lassen Sie nicht mehrere Personen dauerhaft denselben privaten Schlüssel oder dasselbe Passwort verwenden, und speichern Sie Zugangsdaten weder in Projektdokumenten noch in Automatisierungsprotokollen.

Personenbezogene Berechtigungen Zeitnah widerrufen

Kontrollierbarer Datenlebenszyklus

Legen Sie vor Beginn der Aufgabe fest, wann Code, Build-Cache, Signaturmaterial und Artefakte auf das Gerät gelangen, wie lange sie dort bleiben und wie sie gesichert und gelöscht werden. Das Laufzeitende ersetzt keine Datensicherung.

Vorab planen Vor dem Ende bereinigen

Zugriffskontrolle

Jeder Anmeldung eine eigene Identität geben

Legen Sie vor dem Teamzugriff Konten, Schlüssel, Berechtigungen und Prüfintervalle fest. Teilen Sie nicht zuerst ein Administratorkonto und versuchen Sie anschließend, anhand von Chatverläufen nachzuvollziehen, wer was getan hat.

Ein Mitglied, ein SSH-Schlüssel

Hinterlegen Sie für jedes Mitglied mit Bedarf an Kommandozeilenzugriff einen eigenen öffentlichen Schlüssel. Der private Schlüssel bleibt ausschließlich auf einem kontrollierten Gerät des Mitglieds oder in einem vom Team freigegebenen Schlüsselverwaltungstool und wird nicht per E-Mail, Ticket oder Code-Repository übertragen.

Individuell widerrufbar

Standardmäßig Konten mit minimalen Rechten verwenden

Für das tägliche Abrufen von Code, Ausführen von Tests und Übertragen von Artefakten sind dauerhaft höchste Rechte nicht erforderlich. Erhöhen Sie Berechtigungen nur vorübergehend für klar definierte Aktionen wie Softwareinstallationen oder Systemänderungen.

Fehlbedienung reduzieren

Passwörter und Schlüssel getrennt verwalten

Verwenden Sie für grafische Konten jeweils ein einzigartiges, starkes Passwort und bevorzugen Sie für SSH die Schlüssel-Authentifizierung. Nutzen Sie nicht dieselben Zugangsdaten für Gerätepasswort, Code-Hosting, E-Mail oder andere Systeme.

Risiken durch Wiederverwendung senken

Fernanmeldungen regelmäßig prüfen

Prüfen Sie Anmeldezeit, Herkunft, Konto und fehlgeschlagene Versuche. Stimmen Einträge nicht mit Arbeitszeiten oder Netzwerken Ihres Teams überein, widerrufen Sie zuerst die betreffenden Zugangsdaten, sichern Sie die erforderlichen Protokolle und melden Sie den Sicherheitsvorfall.

Ermittlungshinweise bewahren

VNC-Sicherheit

Auch die grafische Oberfläche braucht einen kontrollierten Verbindungsweg

VNC eignet sich für die entfernte Nutzung der grafischen macOS-Oberfläche. Dauerhaft offene Verbindungen und gemeinsam genutzte Zugangsdaten sind jedoch kein sinnvoller Komfort. Stellen Sie die Verbindung bevorzugt über ein kontrolliertes Netzwerk oder einen SSH-Tunnel her.

Vor dem Verbinden

Bestätigen Sie, dass Verbindungsziel, Bestellgerät und Knotenname übereinstimmen.
Prüfen Sie zunächst den SSH-Host-Fingerabdruck und richten Sie erst danach die Portweiterleitung ein.
Beschränken Sie lokale Geräte und Teammitglieder, die Verbindungen herstellen dürfen.

Während der Sitzung

Sperren Sie die macOS-Sitzung beim Verlassen des Bildschirms, damit der Desktop nicht bedienbar bleibt.
Zeigen Sie Passwörter, Token und private Schlüssel weder in geteilten Bildschirmen noch in Aufzeichnungen oder Protokollen.
Prüfen Sie vor der Übertragung vertraulicher Dateien das Zielverzeichnis und dessen Zugriffsrechte.

Nach dem Ausscheiden eines Mitglieds

Widerrufen Sie sofort den SSH-Schlüssel und den Systemkontozugriff des Mitglieds.
Rotieren Sie zuvor geteilte Passwörter der grafischen Oberfläche und Projekttoken.
Prüfen Sie aktuelle Fernanmeldungen und aktualisieren Sie die Zugriffsliste.

Dauerhafte Zugangsdaten nicht teilen

Richten Sie bei Zusammenarbeit für jedes Mitglied einen separat widerrufbaren Zugriffsweg ein. Gemeinsame Zugangsdaten erschweren Widerruf, Nachverfolgung von Aktionen und Untersuchung von Vorfällen.

Verwaltung von Build-Geheimnissen

Geheimnisse zur Laufzeit injizieren, nicht mit dem Code weitergeben

Zertifikate, Signaturdateien, Zugriffstoken und Umgebungsvariablen sollten aus dem eigenen Geheimnisverwaltungsprozess Ihres Teams stammen. RunnerVPS stellt Gerät und grundlegende Verbindung bereit, ersetzt aber keine Governance für Projektzugangsdaten.

Checkliste für die Injektion in Build-Aufgaben RUN SCOPE: ONE JOB

Signaturzertifikat Zu Beginn der Aufgabe importieren Nach Abschluss der Aufgabe entfernen

Signaturdatei Dateiberechtigungen beschränken Nicht ins Repository übernehmen

Zugriffstoken Auf das Projekt begrenzen Eigenständige Rotationsstrategie festlegen

Umgebungsvariable Vom Runner injiziert Nicht in Protokolle ausgeben

Build-Artefakte An kontrollierten Speicher übertragen Kopien nach der Prüfung bereinigen

Nicht ins Code-Repository übernehmen

Übernehmen Sie private Schlüssel, Zertifikatpasswörter, Signaturdateien, Token oder Konfigurationsdateien mit Geheimnissen in keinen Branch. Selbst nach dem Löschen können Inhalte in der Historie erhalten bleiben.

Nicht in Build-Protokolle übernehmen

Deaktivieren Sie die Ausgabe vertraulicher Werte bei der Befehlsausführung und anonymisieren Sie Protokolle, Screenshots und Fehlerberichte. Bewahren Sie bei der Fehlersuche den Fehlerkontext, aber kopieren Sie keine vollständigen Zugangsdaten.

Gültigkeitsbereich pro Aufgabe begrenzen

Token dürfen nur für das aktuelle Repository, die aktuelle Pipeline und die erforderlichen Aktionen berechtigt sein. Rotieren Sie sie sofort nach Abschluss der Aufgabe, beim Ausscheiden eines Mitglieds oder bei vermuteter Offenlegung.

System- und Softwareupdates

Toolchain zuerst prüfen, dann macOS und Xcode aktualisieren

Systemupdates können SDKs, Kommandozeilentools, Simulatoren und Signaturverhalten verändern. Bei dauerhaft laufenden Build-Knoten muss die Kompatibilität vor Änderungen in der Produktionsumgebung geprüft werden.

01

Aktuelle Basis dokumentieren

Sichern Sie Versionen von macOS, Xcode, Kommandozeilentools, Paketmanager, wichtigen Abhängigkeiten und Runner. Dokumentieren Sie den kleinsten erfolgreichen Testlauf und die Prüfungsmethode für Artefakte.
02

Projektkompatibilität prüfen

Prüfen Sie zunächst Projektanforderungen, SDK-Unterstützung, gesperrte Abhängigkeiten und Signaturkonfiguration. Testen Sie kritische Projekte mit reproduzierbaren Aufgaben auf Kompilierung, Unit-Tests, Signatur und Artefaktexport.
03

Wiederherstellungsweg vorbereiten

Sichern Sie vor Änderungen benötigte Projektdaten, Konfigurationslisten und Build-Artefakte. Stellen Sie sicher, dass Abhängigkeiten erneut installiert und Geheimnisse über den eigenen Teamprozess wieder injiziert werden können.
04

Zeit mit geringem Risiko wählen

Vermeiden Sie laufende Release-Aufgaben und stoppen Sie neue Builds, bevor sie den Knoten erreichen. Prüfen Sie nach dem Update Fernzugriff, Firewall, Runner-Status und Speicherplatz erneut.
05

Mit einer Minimalaufgabe abnehmen

Führen Sie zunächst eine kontrollierte Prüfaufgabe aus und nehmen Sie danach die vollständige Pipeline wieder auf. Stimmen die Ergebnisse nicht mit der Basis überein, sichern Sie Protokolle, Versionsinformationen und Reproduktionsschritte.

Datenexport und Bereinigung

Benötigte Inhalte vor Ende der Laufzeit exportieren

Exportieren Sie vor Ende der Laufzeit Artefakte, entfernen Sie Konten und Schlüssel und bereinigen Sie Projektdateien. Betrachten Sie den lokalen Gerätespeicher nicht als einzige Sicherung und verschieben Sie die Bereinigung nicht auf die Zeit nach dem letzten Gerätezugriff.

Supportinformationen ansehen Konsole öffnen

01 Exportieren

Sichern Sie Build-Artefakte, Projektdaten, Protokolle und weiterhin benötigte Konfigurationslisten.

02 Prüfen

Prüfen Sie im kontrollierten Teamspeicher, dass Dateien geöffnet werden können, Prüfsummen übereinstimmen und Berechtigungen korrekt sind.

03 Widerrufen

Entfernen Sie Mitgliedskonten, SSH-Schlüssel, Projekttoken, Zertifikate und Signaturmaterial.

04 Bereinigen

Löschen Sie Projektverzeichnisse, Caches, temporäre Dateien, Downloads und lokale Artefaktkopien.

05 Bestätigen

Prüfen Sie den Laufzeitstatus in der Konsole und bewahren Sie die erforderlichen, mit der Bestellung verknüpften Übergabeprotokolle auf.

Zuständigkeitsgrenze

Der Nutzer ist dafür verantwortlich, benötigte Daten vor Ende der Laufzeit zu exportieren und zu prüfen. Nach Ende der Laufzeit darf nicht angenommen werden, dass das Gerät noch für nachträgliche Sicherungen, die Wiederherstellung von Projektdateien oder den Abruf nicht exportierter Build-Artefakte verfügbar ist.

Sicherheitsvorfall melden

Ausreichende Informationen liefern, damit die Untersuchung mit Fakten beginnt

Wenn Sie ungewöhnliche Anmeldungen, vermutlich offengelegte Zugangsdaten, fehlerhafte Zugriffsumfänge oder andere Sicherheitsprobleme feststellen, widerrufen Sie zunächst erforderliche Zugangsdaten und beschränken Sie den Zugriff. Wählen Sie anschließend auf der Kontaktseite die Kategorie für Sicherheitsmeldungen.

01 Auswirkungsbereich

Nennen Sie Gerätekennung, Knoten, Konten, Projekte und möglicherweise betroffene Datentypen. Übermitteln Sie keine Passwörter, privaten Schlüssel oder vollständigen Zahlungsdaten.

02 Zeitlicher Ablauf

Geben Sie Zeitpunkt der Entdeckung, Dauer des ungewöhnlichen Verhaltens, bereits durchgeführte Widerrufs- oder Isolationsmaßnahmen sowie den letzten Zeitpunkt mit bestätigtem Normalzustand an.

03 Reproduktionsschritte

Beschreiben Sie in tatsächlicher Reihenfolge Einstiegspunkt, Aktion, erwartetes und tatsächliches Ergebnis. Ist das Problem nicht zuverlässig reproduzierbar, nennen Sie Häufigkeit und Auslöser.

04 Anonymisierte Belege

Legen Sie erforderliche Protokollausschnitte, Fehlermeldungen, Anfragezeitpunkte und Screenshots vor. Verbergen Sie Token, Schlüssel, Passwörter, Zertifikatinhalte und nicht relevante personenbezogene Daten.

Mit einem Physikknoten mit klaren Grenzen starten

Wählen Sie Runner M4 oder Runner M4 Plus, Laufzeit und Knoten aus und richten Sie den Zugriff nach der Übergabe gemäß den eigenen Schlüssel- und Geheimnisverwaltungsprozessen Ihres Teams ein.

Knoten auswählen und bestellen Tarife und Preise ansehen