Jede gültige Miete umfasst einen dedizierten physischen Mac mini – keine virtuelle Maschine und kein gemeinsam genutztes Gerät. Prozessor, Arbeitsspeicher und lokaler Speicher stehen ausschließlich dem jeweiligen Mieter zur Verfügung. Hier erläutern wir Sicherheitsgrenzen anhand von Kontrollzielen, Maßnahmen und prüfbaren Aufzeichnungen.
Die Sicherheitsbewertung erfolgt auf drei Ebenen: Besitz der Ressourcen, Zugriffswege und Bereitstellungsstatus. Während der Miete stehen die physischen Rechenressourcen des Mac mini dem aktuellen Mieter exklusiv zur Verfügung. Administrative Plattformaktionen sind durch Berechtigungen und Aktivitätsprotokolle begrenzt. Nach Mietende wird das Gerät gelöscht und vor der erneuten Bereitstellung geprüft.
Prozessor, Unified Memory und interner Speicher werden nicht mit anderen Mietern geteilt. Build-Warteschlangen, Caches, Testprozesse und Remote-Desktop-Sitzungen laufen auf demselben dedizierten Gerät.
Remote-Verbindungen verwenden bevorzugt Schlüssel; der interne Plattformzugriff folgt dem Prinzip der geringsten Rechte. Bei Problemen mit einem Knoten wird zunächst der Aufgabenbereich bestätigt und anschließend nur die dafür erforderliche Berechtigung erteilt.
Die Sicherheitskontrollen decken Bereitstellung, Nutzung, Mietende, Medienlöschung und die Prüfung vor der erneuten Bereitstellung ab. Die Datenverarbeitung wird nicht auf eine einzige Maßnahme am Mietende verschoben.
Senden Sie ein Support-Ticket mit Bestellnummer, Knoten, zu prüfenden Kontrollen und Zeitraum. Das Support-Team stellt verfügbare Nachweise zu Gerätezuordnung, Zugriff oder Löschstatus zusammen. Private Schlüssel, vollständige Credentials oder nicht anonymisierte Geschäftsdaten müssen nicht mitgesendet werden.
Im Kontrollzentrum ein Prüfticket erstellenZugriffskontrolle bedeutet mehr als ein einmalig festgelegtes Passwort. Zuverlässiger ist es, Benutzerzugriff, Plattformadministration und Störungsbehebung über klare Zugänge zu trennen und Credentials rotierbar, Berechtigungen widerrufbar sowie Aktionen nachvollziehbar zu machen.
Richten Sie nach der ersten Verbindung möglichst bald Ihren persönlichen SSH-Public-Key ein. Verwenden Sie für verschiedene Mitglieder, automatisierte Runner und Deployment-Aufgaben unterschiedliche Schlüssel. So kann der Zugriff einzelner Identitäten widerrufen werden, ohne alle Verbindungs-Credentials zu ersetzen.
ssh-keygen -t ed25519
Alltägliche Build-Konten erhalten nur die Rechte zum Abrufen von Code, Installieren von Abhängigkeiten, Ausführen von Tests und Schreiben in Artefaktverzeichnisse. Erweiterte Rechte müssen an konkrete Aufgaben gebunden sein, damit dauerhafte Runner keine über den Workload hinausgehenden Befugnisse behalten.
id && groups
Wenn Mitglieder ausscheiden, Automatisierungstoken offengelegt werden, Projekte enden oder sich der Zugriffsbereich ändert, müssen alte Credentials sofort widerrufen und neue erstellt werden. Verwenden Sie kein langfristiges Token für mehrere Pipelines und schreiben Sie Schlüssel niemals direkt in Repositorys oder Build-Logs.
Bei Verbindungen unbekannter Herkunft, ungewöhnlich vielen Fehlversuchen oder Aktivitäten außerhalb der üblichen Arbeitszeiten begrenzen Sie zuerst die Quelladressen und widerrufen die betreffenden Credentials. Sichern Sie anschließend Zeitraum, Quelladresse, Konto und erforderliche Logs und senden Sie anonymisierte Unterlagen über ein Ticket ein.
Jede Identität wird separat erkannt, damit Widerruf und Prüfung möglich sind.
Erreichbarkeit auf Teamnetzwerk und Toolchain begrenzen.
Entwicklungs- und Build-Aufgaben innerhalb der Mietergrenze ausführen.
Administrativer Zugriff dient der Gerätebereitstellung, Fehleranalyse und autorisierten Supportaktionen. Mieter-Traffic umfasst SSH, grafische Oberflächen, Codeabrufe, Abhängigkeitsdownloads, Builds und Artefaktübertragung. Beide Pfade dürfen aus Bequemlichkeit nicht in denselben Berechtigungsbereich fallen.
In den Administrationsprozess gelangen nur Aktionen, die für die Bereitstellung eines Knotens oder die Analyse von Hardware- und Netzwerkproblemen erforderlich sind. Bestätigen Sie vor dem Zugriff Ziel, Grund und Umfang. Hochrisikoaktionen erfordern eine erneute Bestätigung; temporäre Rechte werden danach geschlossen und notwendige Nachweise aufbewahrt.
Öffnen Sie nur tatsächlich genutzte Dienste und begrenzen Sie Quelladressen für Administrationsports. Verwenden Sie für Dateiübertragungen und Automatisierung separate Credentials. Temporäre Debug-Ports sind nach Abschluss sofort zu schließen; Datenbanken, Caches oder interne Dashboards dürfen nicht unnötig ins Netzwerk gelangen.
Geeignet für Teams in Südostasien und regionale Pipelines. Testen Sie vor der Verbindung die Route aus den wichtigsten Büronetzwerken und erlauben Sie nur erforderliche Adressen für Runner, Repositorys und Artefaktspeicher.
Prüfschwerpunkte: Quellbeschränkung, Abhängigkeitsausgänge, DateiübertragungswegeGeeignet für Projekte in Japan und Nordostasien. Protokollieren Sie Entwickler-Remotesitzungen und automatisierten Build-Traffic getrennt, damit persönliche Verbindungs-Credentials nicht in dauerhafte Runner kopiert werden.
Prüfschwerpunkte: Identitätstrennung, Build-Token, SitzungsprotokolleGeeignet für Teams in Südkorea und regionale Testaufgaben. Geben Sie dauerhaft laufenden Agenten eigene Konten, prüfen Sie autorisierte Schlüssel und Aufgaben-Tags regelmäßig und entfernen Sie nicht mehr benötigte Zugänge.
Prüfschwerpunkte: dauerhafte Agenten, autorisierte Schlüssel, AufgabentrennungGeeignet für Teams, die Repositorys und Kollaborationsnetzwerke in mehreren Teilen Asiens anbinden. Konfigurieren Sie Zugriffsregeln nach dem tatsächlichen Pfad und erweitern Sie wegen regionaler Zusammenarbeit nicht die Erreichbarkeit aller Ports.
Prüfschwerpunkte: regionale Routen, Portumfang, anonymisierte LogsSingapur, Japan (Tokio), Südkorea (Seoul) und Hongkong – 4 Knoten sind 365 Tage im Jahr verfügbar. Der Knoten bestimmt den Zugangsort, begrenzt aber nicht automatisch Quelladressen, trennt keine Team-Credentials und schließt keine unnötigen Dienste. Diese Kontrollen müssen passend zu Netzwerk und Pipeline eingerichtet werden.
Datensicherheit findet nicht nur am Mietende statt. Gerätezuordnung, Berechtigungsverwaltung während der Nutzung, Datenmigration, Medienlöschung und die Prüfung vor der erneuten Bereitstellung bilden gemeinsam eine vollständige Prozesskette.
Bestätigen Sie anhand der Bestellung Modell, Arbeitsspeicher, Speicher, Mietdauer und Zielknoten und verknüpfen Sie die physische Geräte-ID mit der aktuellen Miete. Prüfen Sie vor der Übergabe der Verbindungsdaten den Systemgrundzustand und den Remote-Zugriffsweg.
Prüfbare Punkte: Bestellnummer, Modell, Knoten, Status der GerätezuordnungCode, Abhängigkeits-Caches, Build-Artefakte und Experimentdateien werden auf dem Mietgerät oder einem vom Nutzer konfigurierten Remote-Speicher abgelegt. Teams sollten Konten trennen, vertrauliche Dateien verschlüsseln, Log-Inhalte begrenzen und wichtige Daten separat sichern.
Nutzeraktionen: Berechtigungstrennung, Datenverschlüsselung, Backup-Prüfung, Anonymisierung von LogsExportieren Sie vor Mietende benötigten Code, Artefakte und Konfigurationen und prüfen Sie, ob Backups lesbar sind. Widerrufen Sie anschließend die von diesem Knoten verwendeten Token und Schlüssel in Repositorys, CI/CD-Plattformen und Deploymentsystemen und stoppen Sie dauerhaft laufende Agenten.
Abschlusskriterien: Daten migriert, Backup lesbar, externe Credentials widerrufenNach Ende der aktuellen Miete wird das Gerät einem Löschprozess unterzogen. Dabei werden lokale Nutzerdaten, Projektdateien, Caches, Schlüssel, Token und Remote-Zugriffskonfigurationen verarbeitet. Die Löschung wird mit dem Gerätestatus verknüpft, damit das Gerät nicht nach bloßem Entfernen sichtbarer Verzeichnisse weitergegeben wird.
Kontrollziel: Daten und Credentials des vorherigen Mieters gelangen nicht in die nächste BereitstellungPrüfen Sie vor der erneuten Bereitstellung, ob alte Benutzer, Schlüssel, dauerhaft laufende Aufgaben und Projektdaten entfernt wurden, und bestätigen Sie, dass der Remote-Zugriff neue Übergabe-Credentials verwendet. Erst nach bestandener Prüfung wird das Gerät der nächsten Miete zugeordnet.
Prüfumfang: Benutzer, Schlüssel, Aufgaben, Datenverzeichnisse, VerbindungskonfigurationPrüfprotokolle dienen der Fehleranalyse, Berechtigungsprüfung und Sicherheitsuntersuchung. Der Umfang konzentriert sich auf notwendige Fakten und nicht auf die Erfassung von Geschäftsinhalten des Mieters. Knoten, ausführende Identität, Autorisierungsgrund, Zeitraum und Ergebnis sind die wichtigsten Verknüpfungsfelder.
Bei Zugriffszurücksetzungen, systemweiten Konfigurationsänderungen, Datenverarbeitung oder Aktionen mit Einfluss auf den Verbindungsstatus müssen Knoten, Umfang und erwartetes Ergebnis vorab eindeutig feststehen.
Aufgabenbegründung, Bestätigungsumfang, AusführungsergebnisBewahren Sie Identität, Knoten, Zeit, Aktionstyp und Status auf, soweit dies für die Fehleranalyse erforderlich ist. Private Schlüssel, vollständige Token oder Geschäftsdaten gehören nicht in die Aufzeichnungen.
Identität, Knoten, Zeitraum, AktionskategorieInterner Zugriff wird nach Verantwortlichkeiten vergeben; temporäre Aufgaben erhalten nur passende Rechte. Ändern sich Verantwortlichkeit oder Aufgabenstatus, sind nicht mehr benötigte Befugnisse zeitnah zu entziehen.
Autorisierte Identität, Grund, Berechtigungsumfang, StatusSupportaktionen werden dem konkreten Knoten und Problem zugeordnet. So lässt sich später prüfen, ob der Autorisierungsrahmen überschritten wurde, und die Reihenfolge wichtiger Aktionen kann bei einer Untersuchung rekonstruiert werden.
Ticketverknüpfung, Aktionsfolge, BearbeitungsergebnisBestätigen Sie Zielknoten, Fehlerbild, zulässige Aktionen und die Datengrenzen, die nicht berührt werden dürfen. Bei unzureichenden Informationen zunächst Belege ergänzen, statt den Zugriff zur Fehleranalyse auszuweiten.
Bevorzugen Sie möglichst wenig eingreifende und rücksetzbare Aktionen. Weicht das Problem von der ursprünglichen Aufgabe ab, stoppen Sie die Ausweitung, bestätigen Sie Autorisierung und Auswirkungen erneut.
Widerrufen Sie nach Abschluss der Aufgabe den temporären Zugriff und dokumentieren Sie tatsächlich ausgeführte Aktionen, Knotenstatus und Empfehlungen, damit die nächste Prüfung nicht auf mündlichen Angaben beruht.
Bei unbekannten Anmeldungen, offengelegten Credentials, ungewöhnlichen Netzwerkaktivitäten, versehentlich gelöschten Daten oder unerwartetem Knotenverhalten begrenzen Sie zuerst die Auswirkungen und sichern Sie Beweise. Überschreiben Sie zur schnellen Wiederherstellung keine wichtigen Logs und verwenden Sie möglicherweise kompromittierte Credentials nicht weiter.
Dokumentieren Sie Zeitpunkt der ersten Entdeckung, Knoten, Konto, Quelladresse, Auffälligkeit und den letzten normalen Zustand. Sichern Sie erforderliche Original-Logs und erstellen Sie für die Übermittlung eine anonymisierte Kopie.
Begrenzen Sie auffällige Quellen, widerrufen Sie mutmaßlich offengelegte Schlüssel oder Token und pausieren Sie betroffene Automatisierungsaufgaben. Die Isolation sollte möglichst auf den konkreten Zugang beschränkt bleiben, damit andere Beweise erhalten bleiben.
Erstellen Sie anhand von Konto, Knoten, Zeitraum, Netzwerkquelle und Aktionsfolge eine Zeitleiste. Unterscheiden Sie Änderungen durch Nutzerkonfiguration, Verhalten automatisierter Aufgaben und Knotenereignisse, bei denen Plattformunterstützung erforderlich ist.
Entfernen Sie ungewöhnliche Zugänge, rotieren Sie betroffene Credentials, stellen Sie erforderliche Konfigurationen wieder her und prüfen Sie Builds, Remote-Verbindungen und Dateizugriff. Kontrollieren Sie danach erneut autorisierte Schlüssel, dauerhaft laufende Prozesse und offene Ports.
Übermitteln Sie per Ticket oder Support-E-Mail bestätigte Fakten, Auswirkungsumfang, Maßnahmen und die nächsten Schritte für den Nutzer. Neue Belege werden weiterhin derselben Bestellung und demselben Vorfall zugeordnet.
Bitte geben Sie Bestellnummer, Knoten, Zeitraum der Entdeckung, Auswirkungsbeschreibung, Reproduktionsschritte und anonymisierte Logs an. Wenn Sie sich nicht im Kontrollzentrum anmelden können, senden Sie eine E-Mail an support@macrents.com. Bitte fügen Sie keine privaten Schlüssel, vollständigen Zugriffstoken, Zertifikatspasswörter oder unverarbeiteten personenbezogenen Daten bei.
Die Plattform stellt die Isolation physischer Knoten und administrative Kontrollen bereit. Mieter müssen weiterhin Projektkonten, Netzwerkzugänge, Schlüssel, Token und Geschäftsdaten verwalten. Diese Checkliste eignet sich für Remote-Entwicklung, Xcode-Builds, dauerhaft laufende Runner und KI-Experimente.
Alle drei Modelle sind dedizierte physische Geräte, keine virtuellen Maschinen, und in 4 Knoten in Singapur, Japan (Tokio), Südkorea (Seoul) und Hongkong bestellbar. Die tatsächliche Verfügbarkeit wird in Echtzeit vom Kontrollzentrum angezeigt.