BerryVM stellt einem einzelnen Kunden während der Mietdauer einen dedizierten physischen Mac-mini-Knoten bereit, keine virtuelle Maschine. Das Sicherheitsmodell basiert auf Geräteisolierung, Zugriffskontrolle, nachvollziehbaren Aktionen und klaren Datengrenzen – einschließlich der Konfigurationen, für die der Kunde verantwortlich ist.
BerryVM teilt Prozessor, Arbeitsspeicher oder lokalen Speicher eines Geräts nicht zwischen mehreren Kunden auf. Nach der Übergabe wird das zugewiesene Gerät während der Mietdauer ausschließlich von diesem Kunden genutzt; danach wird der Zugriff deaktiviert und die Beendigung verarbeitet.
Chip, Arbeitsspeicher und integrierter Speicher gehören zum vollständig zugewiesenen Mac mini. Der Dienst ist ein dedizierter physischer Mac, keine gemeinsam genutzte virtuelle Maschine, und wird nicht über Überbuchungsquoten beschrieben.
Gerätekennung, Knoten und Zugangsdaten werden mit dem Auftrag übergeben. Der Kunde sollte den Zugriff nur autorisierten Mitgliedern gewähren und Zugangsdaten bei geänderten Zuständigkeiten, Ausscheiden von Mitarbeitenden oder vermuteter Offenlegung sofort rotieren.
Supportmitarbeitende erhalten nicht standardmäßig dauerhaften Zugriff auf die Kundenumgebung. Ist eine Unterstützung bei der Analyse erforderlich, müssen Problemumfang, erlaubte Aktionen und Zeitraum über ein Konsolenticket festgelegt werden; bevorzugt werden anonymisierte Protokolle verwendet.
Die Zugangsdaten enthalten nur die Informationen, die für die erste sichere Sitzung erforderlich sind. Nach Erhalt sollten Sie zunächst Gerät und Knoten prüfen, anschließend Zugangsdaten aktualisieren, Quellen beschränken und autorisierte Mitglieder dokumentieren.
Vergleichen Sie Auftragskennung, Gerätekonfiguration, ausgewählten Knoten und erhaltene Zugangsdaten. Bei Abweichungen pausieren Sie die Verbindung und erstellen ein Konsolenticket.
Verwenden Sie das initiale Passwort nicht weiter für die tägliche Zusammenarbeit. Legen Sie nach den Richtlinien Ihres Teams neue starke Zugangsdaten fest, bevorzugt per Schlüssel-Authentifizierung, und bewahren Sie Wiederherstellungsinformationen sicher auf.
Öffnen Sie nur die für die Aufgabe erforderlichen Fernzugriffsdienste und Quelladressen, deaktivieren Sie ungenutzte Freigaben und verwenden Sie für automatisierte Runner eigene, widerrufbare Berechtigungen.
Dokumentieren Sie, wer Zugriffsrechte besitzt, wann Zugangsdaten rotiert wurden, welche Pipelines das Gerät verwenden und wer bei Änderungen im Team für den Entzug des Zugriffs zuständig ist.
Die Fehlersuche beginnt standardmäßig mit Gerätestatus, Netzwerkpfad und anonymisierten Protokollen. Nur bei ausdrücklicher Kundenfreigabe und tatsächlicher Notwendigkeit einer Ferndiagnose wird innerhalb des im Ticket vereinbarten Umfangs geholfen.
Bei vermuteter Offenlegung von Zugangsdaten stoppen Sie zunächst betroffene Automatisierungsaufgaben, widerrufen den zugehörigen Zugriff und rotieren die Zugangsdaten. Bewahren Sie Auftragskennung, Knoten, Zeitpunkt, Quelladresse und anonymisierte Protokolle auf und erstellen Sie anschließend ein Konsolenticket.
Sicherheitsticket erstellenProjektdaten des Kunden liegen hauptsächlich auf dem zugewiesenen dedizierten physischen Mac. Kontaktdaten des Kontos, Bestellungen, Zahlungsstatus, Supportkommunikation und erforderliche Betriebsaufzeichnungen werden jeweils zweckgebunden verarbeitet. Einzelheiten zu Aufbewahrung und Nutzerrechten finden Sie in der Datenschutzerklärung.
Wir verarbeiten Kontaktdaten des Kontos, Konfiguration, Mietdauer, Knoten und Zahlungsstatus, um den Auftrag zu bestätigen, ein Gerät zuzuweisen und Zugangsdaten bereitzustellen. In der Aktivierungsphase müssen Kunden keinen Quellcode oder Produktionsdaten übermitteln.
Während der Mietdauer ist der Kunde für Repositorys, Build-Caches, Modelldateien, Schlüssel und Artefaktberechtigungen auf dem zugewiesenen Gerät verantwortlich. BerryVM verarbeitet nur für Betrieb, Sicherheit und Support erforderliche Aufzeichnungen.
Nach Bestätigung der Verlängerung wird die Gerätenutzung gemäß Auftrag fortgesetzt. Das Team sollte Zugangsdaten weiterhin nach seinem eigenen Turnus rotieren, veraltete Mitgliedsberechtigungen entfernen und die von Automatisierungsaufgaben verwendeten Schlüssel prüfen.
Nach Ende der Mietdauer wird der Kundenzugriff geschlossen und die Verarbeitung der Gerätedaten gemäß dem Dienstablauf eingeleitet. Exportieren Sie benötigte Artefakte rechtzeitig, widerrufen Sie Tokens externer Systeme und stellen Sie sicher, dass keine einzige Kopie auf dem Gerät benötigt wird.
Die Datenschutzerklärung erläutert die Grenzen der Verarbeitung von Kontodaten, Bestellaufzeichnungen, Supportkommunikation, erforderlichen Protokollen und Gerätedaten.
Risiken bei Fernsitzungen entstehen häufig durch dauerhafte Zugangsdaten, zu weit geöffnete Quellen, ungenutzte Dienste und nicht nachvollziehbare gemeinsame Zugriffe. Die folgende Liste eignet sich als Ausgangsbasis nach der Geräteübergabe.
Aktivieren Sie nur die für die Aufgabe erforderlichen Fernzugriffsdienste und Ports. Nicht benötigte Freigabe-, Erkennungs- und Testdienste sollten deaktiviert bleiben, damit aus einer vorübergehenden Analyse kein dauerhafter Zugang entsteht.
Prüfpunkt: Dienste, Ports, Listening-AdressenAutomatisierungsaufgaben und Teammitglieder sollten jeweils widerrufbare Authentifizierungsdaten verwenden. Teilen Sie keine dauerhaften Passwörter und schreiben Sie private Schlüssel weder direkt in Repositorys noch in Build-Skripte oder Tickettexte.
Prüfpunkt: Schlüsselbesitz, Aufbewahrung, WiderrufBeschränken Sie Zugriffe auf Team-Ausgangspunkte, kontrollierte Bastionpfade oder Aufgabennetze. Bei länderübergreifender Zusammenarbeit sollte die Quellenstrategie zuerst geprüft werden; die dauerhafte Freigabe aller Adressen ist keine Lösung.
Prüfpunkt: Quellenumfang, Ausnahmen, AblaufzeitPrüfen Sie regelmäßig Mitglieder, automatisierte Runner, Fernzugriffsdienste und externe Tokens. Wenn Mitglieder das Projekt verlassen, Pipelines deaktiviert werden oder sich die Gerätenutzung ändert, widerrufen Sie nicht mehr benötigte Berechtigungen sofort.
Prüfpunkt: Mitglieder, Aufgaben, Tokens, Auffälligkeitsprotokolle| Prüfobjekt | Empfohlene Aktion | Auslöser | Aufzubewahrende Aufzeichnungen |
|---|---|---|---|
| Personenzugriff | Mitgliedsberechtigungen prüfen und abgelaufene Zugriffe widerrufen | Änderung der Zuständigkeit oder Ausscheiden aus dem Projekt | Autorisierende Person, Widerrufszeitpunkt, betroffenes Gerät |
| Automatisierungszugangsdaten | Schlüssel rotieren und Wiederherstellung der Pipeline prüfen | Turnusmäßige Rotation oder vermutete Offenlegung | Schlüsselkennung, Rotationszeitpunkt, Prüfergebnis |
| Fernzugriffsdienste | Ungenutzte Dienste deaktivieren und Quellenbereich verkleinern | Aufgabenende oder Änderung der Netzwerkregeln | Port, Quellenregel, verantwortliche Person |
| Supportfreigabe | Temporären Zugriff schließen und zugehörige Zugangsdaten aktualisieren | Ende der Ticketanalyse | Ticketkennung, Freigabeumfang, Ergebnis der Schließung |
Die Bearbeitung von Sicherheitsvorfällen konzentriert sich auf Fakten und eine Zeitachse. Bei einer Meldung müssen keine Zugangspasswörter übermittelt werden; Auftragskennung, Knoten, Zeitpunkt, Auswirkungsumfang, Reproduktionsschritte und anonymisierte Protokolle helfen meist schneller bei der Einschätzung.
Geben Sie Auftragskennung, Knoten, Zeitpunkt der ersten Feststellung, betroffene Aufgaben und bereits ergriffene Maßnahmen an. Anonymisieren Sie Schlüssel, Tokens, Kundendaten und Angaben zu Mitgliedern, bevor Sie Protokolle anhängen.
Prüfen Sie, ob der Vorfall noch andauert, ob ein Gerät oder externe Abhängigkeiten betroffen sind und ob Zugangsdaten sofort widerrufen, Pipelines gestoppt oder Netzwerkquellen beschränkt werden müssen.
Schließen Sie betroffene Zugänge, widerrufen Sie entsprechende Berechtigungen oder pausieren Sie Aufgaben auf Grundlage der Fakten. Isolationsmaßnahmen müssen nachvollziehbar sein; löschen Sie wichtige Protokolle nicht, bevor Belege gesichert wurden.
Nach Zugangsdatenrotation, Korrektur der Quellenregeln, Aktualisierung von Abhängigkeiten oder Zurücksetzen der Konfiguration bestätigen Sie mit einer minimalen Prüfausführung, dass Verbindung, Build und Artefaktpfad wieder funktionieren.
Ordnen Sie Zeitachse, Ursache, Auswirkungsumfang und Folgemaßnahmen und legen Sie fest, welche Überwachung, Berechtigungsrücknahme, Rotationsmechanismen oder Team-Checklisten ergänzt werden müssen.
Bei Maßnahmen auf Dienstseite teilen Sie bestätigte Ergebnisse, Fortschritt und erforderliche Mitwirkung des Kunden über einen nachvollziehbaren Supportweg mit. Unbestätigte Vermutungen dürfen keine Schlussfolgerungen ersetzen.
BerryVM verwendet 99,9 % als Ziel für die Dienstverfügbarkeit. Alle Knoten laufen 365 Tage im Jahr durchgehend; regelmäßige Abschaltungen sind nicht vorgesehen. Messumfang, Ausschlüsse, Fristen und mögliche Kompensationen richten sich nach den Servicebedingungen.
Wenn Sie einen bestimmten Ausfall im laufenden Betrieb prüfen möchten, übermitteln Sie Auftragskennung, Knoten, Zeitpunkt, Dauer und Auswirkungsumfang. Aufzeichnungen des Dienstes und Kundenprotokolle sollten dieselbe Zeitzone verwenden oder die Zeitzone eindeutig angeben.
Meldungen zu Schwachstellen, Sicherheitsfragen oder laufenden Auffälligkeiten können über ein Konsolenticket oder an support@berryvm.com gesendet werden. Fügen Sie Auftragskennung, Knoten, Zeitachse, Auswirkungsumfang und anonymisierte Protokolle bei. Senden Sie keine Zugangsdaten, privaten Schlüssel oder nicht anonymisierten Projektdaten.