MiniRent stellt dedizierte physische Cloud-Mac-Knoten bereit, deren virtuelle Ressourcen nicht mit anderen Mietern geteilt werden. Hier erfahren Sie, wer Plattformsteuerung, Geräteaccounts, SSH-Verbindungen, Build-Artefakte und Tools von Drittanbietern verwaltet – und wie bei Auffälligkeiten vorzugehen ist.
Ein dediziertes physisches Gerät verhindert Ressourcenkonflikte zwischen Mietern in gemeinsam genutzten virtuellen Maschinen, ersetzt aber weder Account-Berechtigungen noch Schlüsselrotation oder die Bereinigung von Build-Artefakten. Das Sicherheitsmodell funktioniert nur, wenn Plattform, Mietteam und verwendete Tools gemeinsam abgesichert sind.
Zuständig für die Zuweisung physischer Knoten, den Zugang zur Konsole, die Bereitstellung von Verbindungsdaten, die Dokumentation von Bestellungen und Gerätestatus sowie die Bearbeitung bestätigter Servicevorfälle.
Zuständig für Geräteaccounts, SSH-Public-Keys, Repository-Tokens, Signaturmaterial, Umgebungsvariablen, Mitgliederberechtigungen und die Datenbereinigung vor Mietende.
Xcode, fastlane, Paketmanager und Pipeline-Runner speichern jeweils eigene Konfigurationen, Caches und Logs. Das Team sollte Versionen, Berechtigungen und Bereinigungsregeln entsprechend den Möglichkeiten jedes Tools festlegen.
Die erste Verbindung besteht nicht darin, eine Adresse einzugeben und sofort fortzufahren. Rufen Sie zuerst die Verbindungsdaten in der Konsole ab, prüfen Sie den Host-Fingerabdruck und bauen Sie die Sitzung anschließend mit einem registrierten SSH-Public-Key auf. Private Schlüssel dürfen nicht über Chatverläufe, öffentliche Dokumente oder Repository-Dateien weitergegeben werden.
Erstellen Sie Schlüssel getrennt nach Personen oder Automatisierungsaufgaben. Mehrere Mitglieder dürfen nicht denselben privaten Schlüssel verwenden.
Vergleichen Sie beim ersten Verbindungsaufbau oder bei einer Änderung des Zugangs den lokal angezeigten Host-Fingerabdruck mit dem Eintrag in der Konsole.
Verwenden Sie für alltägliche Builds einen Standardaccount und erhöhen Sie Berechtigungen nur vorübergehend, wenn Komponenten installiert oder Systemeinstellungen geändert werden.
Das häufigste Risiko bei automatisierten Builds ist nicht die gemeinsame Nutzung von Geräteressourcen, sondern dass langlebige Tokens in Skripten, Logs oder Caches landen. Planen Sie Berechtigungen, Gültigkeitsdauer, Injektionsort und Bereinigung sensibler Daten gemeinsam.
| Artefakt | Berechtigungsgrenze | Empfohlene Injektion | Aktion nach Abschluss |
|---|---|---|---|
| Repository-Token | Auf erforderliche Repositories und Aktionen begrenzen, vorzugsweise schreibgeschützt | Über kontrollierte Umgebungsvariablen oder Pipeline-Secrets injizieren | Kurzlebiges Token widerrufen, Arbeitsbereich und Remote-Adressen prüfen |
| Signaturzertifikat und privater Schlüssel | Nur dem Account für Signaturaufgaben Zugriff gewähren | Zu Build-Beginn in einen kontrollierten Schlüsselbund importieren | Temporären Schlüsselbund und Importdateien löschen |
| Provisioning-Profil | Auf die Ziel-App und den Build-Zweck begrenzen | Durch einen kontrollierten Job in ein temporäres Verzeichnis kopieren | Temporäre Kopie löschen und Archivinhalt prüfen |
| Umgebungsvariable | Nach Projekt und Umgebung trennen, nicht aufgabenübergreifend wiederverwenden | Zur Laufzeit der Pipeline in die Prozessumgebung schreiben | Prozess beenden, temporäre Konfiguration und Shell-History-Reste löschen |
| Build-Artefakte und Logs | Nur für Projektmitglieder und den Auslieferungsprozess lesbar | In ein separates Aufgabenverzeichnis ausgeben | Benötigte Artefakte übertragen und übrige Dateien gemäß Aufbewahrungsregeln löschen |
Wenn der Build nur Code abrufen muss, gewähren Sie weder Schreibrechte für das Repository noch Rechte zur Mitgliederverwaltung. Signaturmaterial eines einzelnen Projekts darf anderen Projektaufgaben nicht zugänglich sein.
Aufgabenspezifisch ausgestellte Credentials nicht dauerhaft speichern. Statische Credentials gehören in einen kontrollierten Secret-Speicher mit klar definierten Auslösern für die Rotation.
Prüfen Sie gleichzeitig temporäre Verzeichnisse, Schlüsselbunde, Umgebungsdateien, Shell-History, Abhängigkeitskonfigurationen, Build-Logs und Artefaktverzeichnisse – löschen Sie nicht nur den Quellcode.
Beide bei MiniRent verfügbaren Gerätestufen können in Singapur, Japan (Tokio), Südkorea (Seoul), Hongkong und den östlichen USA gewählt werden. Der Knoten sollte sich nahe am wichtigsten Entwicklungsteam oder Repository befinden; die tatsächliche Verfügbarkeit zeigt die Konsole in Echtzeit.
Geeignet für Teams in Südostasien und regionale Pipeline-Einstiegspunkte.
Geeignet für Entwicklungs- und Build-Aufgaben in Japan und Ostasien.
Geeignet für koreanische Teams und regionale Kollaborationsumgebungen.
Geeignet für die regionsübergreifende Zusammenarbeit zwischen Südchina und Südostasien.
Geeignet für Workflows im Osten Nordamerikas und über den Atlantik hinweg.
Für Bestellungen, Gerätestatus, Verbindungsdaten und Supporttickets. Verwaltungsaktionen sollten nicht als Datenkanal für Build-Skripte verwendet werden.
SSH- und VNC-Sitzungen dienen direkt der Gerätebedienung. Begrenzen Sie die Quellnetzwerke, prüfen Sie die Verbindungsdaten und beenden Sie die Sitzung beim Verlassen des Geräts.
Wenn ein Knoten gewechselt werden muss, reichen Sie über die Konsole ein Ticket ein. Sichern Sie vor der Migration erforderliche Artefakte, widerrufen Sie temporäre Credentials und prüfen Sie den Host-Fingerabdruck des neuen Zugangs.
Gerätekennung, Knoten, Zeitzone und Zeitraum des Auftretens prüfen.
Kürzlich hinzugefügte Public-Keys, Geräteaccounts, Runner-Registrierungen und Berechtigungsänderungen prüfen.
Verdächtige Schlüssel und Tokens widerrufen, zugehörige Automatisierungsaufgaben pausieren und bereinigte Logs sichern.
Reproduzierbare Informationen über ein Konsolen-Ticket oder an support@minirents.com senden.
Alle Knoten werden durchgehend betrieben. Servicevorfälle werden anhand von Konsolenaufzeichnungen, Knotenstatus und bestätigten Supportergebnissen beurteilt.
Bei einem Sicherheitsproblem sind Gerätekennung, Knoten, Zeitraum, Reproduktionsschritte, Auswirkungsbereich und bereinigte Logs am wertvollsten. Vollständige Schlüssel, Passwörter und Zugriffstokens helfen bei der Analyse nicht, sondern erhöhen das Risiko.
Dokumentieren Sie Auffälligkeiten, Gerätekennung, Knoten, Zeitzone, erstes Auftreten und den letzten normalen Vorgang. Unterscheiden Sie Verbindungsfehler, Berechtigungsänderungen, ungewöhnliche Prozesse und offengelegte Build-Artefakte.
Widerrufen Sie betroffene SSH-Public-Keys, Repository-Tokens und Pipeline-Schlüssel und stoppen Sie verdächtige Runner oder Aufgaben. Überschreiben Sie Logs nicht gesammelt, bevor wichtige Informationen gesichert sind.
Sichern Sie Befehlszeitpunkte, Fehlercodes, Prozessinformationen und erforderlichen Kontext. Verbergen Sie Passwörter, private Schlüssel, vollständige Tokens, Signaturmaterial und Befehlszeilen mit sensiblen Parametern.
Melden Sie sich an der Konsole an und reichen Sie ein Ticket ein oder senden Sie eine E-Mail an support@minirents.com. Betreff: „Sicherheitsbericht“. Geben Sie Auswirkungsbereich, Reproduktionsschritte und bereits ergriffene Begrenzungsmaßnahmen an.
Rotieren Sie betroffene Credentials, prüfen Sie Mitgliederberechtigungen und Automatisierungskonfigurationen und testen Sie anschließend Verbindung, Abhängigkeiten, Signatur und Artefaktausgabe mit einer minimalen Aufgabe. Erst danach die volle Parallelität wiederherstellen.
Die Checkliste gilt für Einzelentwicklung, Team-Build-Farmen und selbst gehostete Runner. Ordnen Sie jeden Punkt einer verantwortlichen Person und einem Automatisierungsskript zu, statt ihn nur intern zu dokumentieren.
Verbindungsdaten aus der Konsole abrufen und Knoten, Gerätekennung sowie Host-Fingerabdruck prüfen.
Für Arbeits-E-Mail, Code-Repository und Pipeline-System starke Authentifizierung aktivieren und Wiederherstellungs-Credentials schützen.
Jedes Mitglied und jede Automatisierungsaufgabe verwendet eine eigene Identität, damit keine nicht nachvollziehbaren gemeinsamen Schlüssel entstehen.
Versionen festlegen und Updates bewerten; Sicherheitskorrekturen für Build-Tools, Paketmanager und Runner bevorzugt bearbeiten.
Verhindern, dass Build-Caches die Festplatte füllen, und prüfen, ob Logs versehentlich Umgebungsvariablen oder Zugriffstokens enthalten.
Code, Schlüssel, Tokens, Signaturmaterial, temporäre Schlüsselbunde, Build-Artefakte und nicht mehr benötigte Caches entfernen.
Beide Gerätestufen unterstützen fünf verfügbare Standorte. Nach der Bestellung erhalten Sie Gerätestatus und Verbindungsdaten über die Konsole; bei Problemen mit einem vorhandenen Gerät können Sie direkt ein Ticket einreichen.