Sie mieten einen dedizierten physischen Mac mini statt einer virtuellen Maschine. CPU, GPU, Unified Memory und Speicher werden nicht mit anderen Kunden geteilt. Ihr Team verwaltet Quellcode, Zertifikate und Build-Artefakte nach den eigenen Vorgaben.
Klären Sie zuerst die Ressourcenzuweisung, richten Sie dann Zugriffsrechte ein und planen Sie schließlich Backups und den Ausstieg.
Physische Isolation verhindert gemeinsam genutzte Ressourcen zwischen Kunden. Benutzer, Prozesse, CI-Jobs und Geheimnisse innerhalb des Betriebssystems müssen weiterhin vom Team mit passenden Berechtigungen verwaltet werden. Werden diese beiden Ebenen getrennt betrachtet, lassen sich Sicherheitsmaßnahmen gezielt umsetzen.
Builds, Simulatoren und Inferenzaufgaben laufen auf dem Ihnen zugewiesenen physischen Rechner. Rechenressourcen dieses Geräts werden nicht auf andere Kunden aufgeteilt; Ihre Aufgaben sind auch nicht durch VM-Kontingente begrenzt.
Gesamter Rechner zugewiesenUnified Memory und lokaler Speicher des Rechners stehen während der Mietdauer Ihrer Arbeitsumgebung zur Verfügung. Projektverzeichnisse, DerivedData, Schlüsselbund und Runner-Cache sind keine gemeinsam genutzten Arbeitsbereiche, auf die andere Kunden zugreifen können.
Isolation zwischen KundenEin dedizierter Rechner ist kein Grund, dass Teammitglieder dieselben Admin-Zugangsdaten verwenden. Trennen Sie Systemkonten für die manuelle Entwicklung und automatisierte Builds, begrenzen Sie die Verzeichnisse, auf die Runner zugreifen können, und geben Sie Produktionsgeheimnisse nicht für alle Build-Jobs frei.
Rollenbasierte BerechtigungenBehandeln Sie Systemreset, sichere Datenlöschung und geschäftliche Backups als drei getrennte Maßnahmen. Die ersten beiden schaffen klare Kundengrenzen; Backups sorgen dafür, dass Ihr Projekt und Ihre Zertifikate auf einem anderen Rechner weiterverwendet werden können.
Nach der Zuweisung des physischen Rechners wird das System zurückgesetzt, um eine neue Mietumgebung einzurichten. Prüfen Sie nach Erhalt der Zugangsdaten zuerst die Instanz-ID und die Systemversion, bevor Sie Code und Zertifikate importieren. Übernehmen Sie keine gemeinsam genutzten Passwörter aus anderen Umgebungen.
Über die Konsole können Sie das System neu installieren. Dabei können lokale Dateien und Entwicklungseinstellungen verloren gehen. Exportieren Sie deshalb vorher alle benötigten Daten, stoppen Sie laufende Builds und stellen Sie sicher, dass keine Teamaufgabe von diesem Rechner abhängt.
Nach Mietende werden die Daten des Rechners sicher gelöscht, bevor er erneut bereitgestellt wird. Exportieren Sie alles Benötigte vor dem Ablauf. Verlassen Sie sich nach Mietende weder auf weiter gespeicherte Daten noch auf eine mögliche Wiederherstellung von Dateien als Backup.
SSH, grafischer Desktop und Konsole sind unterschiedliche Zugänge. Verwalten und widerrufen Sie die jeweiligen Zugangsdaten separat – etwa bei einem Austritt, einer Übergabe oder nach Ende einer Aufgabe. Verwenden Sie nicht dasselbe Passwort für alle Zugänge.
Verwenden Sie für jedes Teammitglied und jeden Automatisierungsjob einen eigenen Schlüssel. Prüfen Sie bei der ersten Verbindung den Host-Fingerabdruck und nach einer Übergabe die Liste der autorisierten Schlüssel. Entfernen Sie beim Entzug von Zugriffsrechten auch den zugehörigen öffentlichen Schlüssel.
Speichern Sie private Schlüssel weder im Code-Repository noch in Build-Protokollen.
Schützen Sie den grafischen Desktop mit einem einzigartigen, starken Passwort. Bei Rechnern, auf denen nur Builds über die Kommandozeile laufen, können Sie öffentliches VNC deaktivieren. Richten Sie bei Bedarf den Zugriffspfad passend zu den tatsächlichen Verbindungsanforderungen ein.
Prüfen Sie nach einem Passwortwechsel, welche Clients noch die alten Zugangsdaten verwenden.
Über Ihr Konsolenkonto verwalten Sie Instanzen und Abrechnungen. Schließen Sie die Zwei-Faktor-Authentifizierung bei der Anmeldung und sensiblen Aktionen wie auf der Seite beschrieben ab. Schützen Sie das Postfach, in dem Sie Verifizierungscodes empfangen, und leiten Sie diese nicht an andere Teammitglieder weiter.
Führen Sie Verwaltungsaktionen mit Ihrem persönlichen Konto durch und vermeiden Sie gemeinsam genutzte Sitzungen.
Lassen Sie nicht geprüfte externe Merge Requests nicht direkt auf Signatur-Schlüsselbunde oder Veröffentlichungszugänge zugreifen. Trennen Sie Test- und Release-Jobs. Geben Sie Geheimnisse in der Release-Phase nur für vertrauenswürdige Branches frei.
Runner-Tags steuern die Job-Zuweisung, sind aber keine Sicherheitsberechtigung.
Alle Rechner sind 365 Tage im Jahr durchgehend in Betrieb. Die Verfügbarkeitszusage bezieht sich auf die Verfügbarkeit des Dienstes. Sie sagt nichts über die Erfolgsquote der Builds eines bestimmten Projekts aus und garantiert auch nicht, dass jede Verbindung über jedes Netzwerk gleich schnell ist.
Monatliche Verfügbarkeitszusage
99.9%
Liegt die monatliche Verfügbarkeit unter 99,9 %, wird der Ausgleich anhand der Dauer der Unterschreitung in Form zusätzlicher Mietzeit berechnet.
Die folgenden 13 Zeitabschnitte zeigen lediglich den Zeitraum der Aufzeichnung, nicht erfolgreiche Betriebs- oder Ausfalltage. Auf dieser Seite werden keine ungeprüften Tagesstatus angezeigt; die Verfügbarkeitszusage ist kein gemessener Betriebswert.
Geben Sie in einem Konsolenticket die Instanz-ID, den betroffenen Zeitraum mit Start- und Endzeit sowie Zeitzone, die Verbindungsart und die Fehlermeldung an. Bewahren Sie bereinigte Protokolle auf, damit die Dauer einer Dienstausfallzeit geprüft werden kann.
Dienststörungen, eigene Nutzeraktionen, fehlgeschlagene Projekte und höhere Gewalt müssen getrennt geprüft werden. Maßgeblich sind die Servicebedingungen; die Grafik zum Aufzeichnungszeitraum dient nicht zur Berechnung eines Ausgleichs.
Es werden ausschließlich die folgenden zwei Zahlungsarten unterstützt; alle Zahlungen werden in US-Dollar (USD) abgerechnet. Welche Zahlungswege tatsächlich verfügbar sind, richtet sich nach der Rückmeldung der Backend-Schnittstelle. Als Zahlungsnachweis gilt der Bestellstatus in der Konsole, nicht ein E-Mail-Screenshot oder eine Browsermeldung.
Kartenzahlungen werden über Stripe abgewickelt; MergeMac speichert keine Kartennummern. Schließen Sie die Zahlung im Bestellvorgang ab und senden Sie vollständige Kartennummern, Sicherheitscodes oder Zahlungsbestätigungen weder per E-Mail noch über ein Ticket.
Abwicklung über StripeÜberweisen Sie den angezeigten Betrag an die in der Bestellung angegebene Adresse über das angegebene Netzwerk. Prüfen Sie den Bestellstatus, sobald die Transaktion auf der Blockchain bestätigt wurde. Geben Sie zur Prüfung der Zahlung die Bestell-ID und den Transaktions-Hash an – niemals Ihren privaten Wallet-Schlüssel oder Ihre Seed-Phrase.
Blockchain-Eingang prüfenQuellcode lässt sich erneut auschecken; Geheimnisse lassen sich nicht einfach wiederherstellen. Legen Sie im Übergabeprozess fest, wer Material importieren darf, welcher Job es entsperren kann und wann es widerrufen wird. So stellen Sie sicher, dass vor Ablauf der Mietdauer ein verwendbares Zertifikatsbackup vorhanden ist.
Richten Sie für CI-Signaturen einen separaten Schlüsselbund ein und importieren Sie nur die Zertifikate und privaten Schlüssel, die das aktuelle Projekt benötigt. Entsperren Sie ihn nur bei Bedarf während des Builds und sperren Sie ihn danach wieder. Geben Sie nicht allen interaktiven Sitzungen Zugriff auf Release-Material.
Speichern Sie sensible Werte als verschlüsselte Geheimnisvariablen in Ihrer CI-Plattform und beschränken Sie ihren Zugriff auf geschützte Branches oder Release-Umgebungen. Deaktivieren Sie Debug-Befehle, die Geheimnisse ausgeben könnten, und prüfen Sie vor dem Teilen von Protokollen auf Token, Pfade und Umgebungsvariablen.
Exportieren Sie vor Ende der Mietdauer oder einer Neuinstallation alle Signaturmaterialien, die Sie behalten müssen, und speichern Sie diese verschlüsselt außerhalb des Rechners. Prüfen Sie, ob das Backup verwendbar ist, und melden Sie anschließend den Runner ab sowie nicht mehr benötigte Token und Zugangsschlüssel ab.
Bei offengelegten Zugangsdaten, verdächtigen Anmeldungen oder mutmaßlichen unbefugten Zugriffen widerrufen Sie zunächst die betreffenden Schlüssel und Token und beschränken Sie den Zugriff auf betroffene Zugänge. Bewahren Sie notwendige Protokolle auf, weiten Sie Tests nicht aus und lesen oder verbreiten Sie keine Daten anderer Kunden.
Melden Sie Vorfälle zu bestehenden Bestellungen bevorzugt über die Konsole. Geben Sie die Instanz-ID, Zeitpunkt und Zeitzone, bereits ergriffene Maßnahmen zur Schadensbegrenzung und die kürzestmöglichen Schritte zur Reproduktion an.
Anmelden und Ticket erstellenSenden Sie eine Beschreibung an support@mergemac.com und nennen Sie im Betreff „Sicherheitsmeldung“. Senden Sie zunächst eine bereinigte Zusammenfassung. Hängen Sie keine privaten Zertifikatsschlüssel, Bestätigungscodes, vollständigen Zugangspasswörter oder Wallet-Geheimnisse an.
Sicherheits-Support per E-Mail kontaktierenWir prüfen Sicherheitsmeldungen entsprechend ihrem Risiko und Umfang mit Priorität und informieren Sie über das ursprüngliche Ticket oder per E-Mail über den Bearbeitungsstand. Eine erste Antwort bedeutet nicht, dass das Problem bereits gelöst ist. Bleiben Sie im selben Meldungsverlauf und ergänzen Sie neue Hinweise dort, damit der Zusammenhang erhalten bleibt.
Der dedizierte physische Rechner sorgt für Ressourcenisolation; für die Sicherheit Ihrer Workloads sind Ihre Berechtigungen, Backups und Zertifikatsprozesse verantwortlich. Wenn Sie bereit sind, wählen Sie die passende Mietdauer und bestellen Sie.