Einen kurzzeitig gemieteten Cloud Mac sicher absichern

Wird eine Woche vor dem Release kurzfristig ein zusätzlicher Cloud Mac bereitgestellt, gerät meist nicht die Build-Geschwindigkeit aus dem Blick, sondern die Abgrenzung der Zugriffsrechte. Häufig kopieren Entwickler ihre dauerhaft genutzten privaten SSH-Schlüssel, Repository-Tokens und Signaturmaterialien direkt auf den Rechner und löschen nach Abschluss der Aufgabe lediglich das Projektverzeichnis. Sicherer ist es, jeden Mietzeitraum als eigenständigen Sicherheitszyklus zu behandeln: beim Einrichten einen Ausgangszustand erfassen, Anmeldedaten während des Betriebs begrenzen und vor der Rückgabe den Export sowie die Bereinigung überprüfen.

Zuerst die Vertrauensgrenzen der Anmietung festlegen

Dokumentieren Sie zunächst den Verwendungszweck des Knotens, die verantwortliche Person, das Ende des Mietzeitraums und die Daten, auf die zugegriffen werden muss. Ein Rechner zum Testen öffentlichen Codes und ein Build-Knoten, der Signaturmaterial verarbeitet, sollten nicht dieselben Anmeldedaten verwenden. Bei der Zusammenarbeit im Team erhält jedes Mitglied einen eigenen Anmeldeweg. Private Schlüssel dürfen nicht gemeinsam genutzt und Administratorzugänge nicht in der Teamdokumentation hinterlegt werden.

Das Sicherheitsziel eines kurzzeitig gemieteten Knotens besteht nicht darin, Anmeldedaten unbegrenzt gültig zu halten. Jede Zugangsberechtigung soll vielmehr einem eindeutigen Zweck dienen, minimale Rechte besitzen und zu einem überprüfbaren Zeitpunkt ungültig werden.

Prüfungen in den ersten fünfzehn Minuten nach der Anmeldung

Importieren Sie das Projekt nicht sofort nach der ersten Anmeldung. Prüfen Sie zunächst den aktuellen Benutzer, die Systemversion sowie den Status der entfernten Anmeldung und der Firewall und bewahren Sie die Ergebnisse auf. Ob Systemupdates umgehend installiert werden, sollte von den Versionsanforderungen der aktuellen Build-Toolchain abhängen. So vermeiden Sie, die Umgebung mitten in einer Release-Aufgabe zu verändern.

whoami
sw_vers
sudo systemsetup -getremotelogin
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
softwareupdate --list

Einen eigenen SSH-Schlüssel für den Mietzeitraum anlegen

Erzeugen Sie den dedizierten Schlüssel auf einer kontrollierten Workstation, statt einen vorhandenen, dauerhaft verwendeten privaten Schlüssel zu kopieren. Nachdem Sie den öffentlichen Schlüssel auf dem Cloud Mac hinterlegt haben, öffnen Sie zunächst ein zweites Terminal und testen die neue Verbindung. Erst danach sollten Sie Änderungen an der bisherigen Zugriffsmethode erwägen.

umask 077
mkdir -p ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/armmacs-rental -C "temporary-build-node"
chmod 700 ~/.ssh
chmod 600 ~/.ssh/armmacs-rental

In der lokalen Datei ~/.ssh/config können Sie dem Knoten einen eigenen Alias zuweisen. Mit IdentitiesOnly yes verhindern Sie, dass der SSH-Client weitere Schlüssel ausprobiert. Knotenadresse, Benutzername und Schlüsselpfad müssen aus den Unterlagen der aktuellen Bestellung stammen. Übertragen Sie die tatsächliche Adresse nicht in das Code-Repository.

Host rented-mac
    HostName <node-address>
    User <node-user>
    IdentityFile ~/.ssh/armmacs-rental
    IdentitiesOnly yes
    ServerAliveInterval 30

Geheimnisse nur bei Bedarf verfügbar machen

Schreiben Sie Tokens weder in Skripte und Projektkonfigurationen noch in Startdateien der Shell. Verwenden Sie bevorzugt interaktive Eingaben, eingeschränkt verfügbare Umgebungsvariablen oder den macOS-Schlüsselbund. Stellen Sie außerdem sicher, dass Build-Protokolle keine Variablenwerte ausgeben. Temporäre Dateien gehören in ein Verzeichnis mit kontrollierten Zugriffsrechten; standardmäßig sollten sie ausschließlich für den aktuellen Benutzer lesbar sein.

umask 077
mkdir -p ~/secure-input
chmod 700 ~/secure-input
security add-generic-password -a build -s ci-token -w

Entfernen Sie die Variablen unmittelbar nach ihrer Verwendung aus der aktuellen Shell. Wird eine Zugangsberechtigung nur für ein einziges Release benötigt, sollte sie nicht sitzungsübergreifend gespeichert bleiben.

unset CI_TOKEN
security delete-generic-password -a build -s ci-token

Geheimnisse aus Protokollen und Caches fernhalten

Aktivieren Sie in Build-Skripten keinen Debug-Modus, der vollständige Befehle ausgibt. Prüfen Sie Fehlerprotokolle vor der Weitergabe auf Anfrage-Header, Umgebungsvariablen, Knotenadressen, Benutzernamen und Dateipfade. Derived Data, Paketmanager-Caches und Testanhänge können Projektnamen und interne Pfade enthalten. Ob diese Daten aufbewahrt werden, sollte von der Vertraulichkeit der Aufgabe abhängen, statt standardmäßig alles zu archivieren.

Während des Betriebs leichtgewichtige Audits durchführen

Prüfen Sie mindestens bei personellen Änderungen, beim Austausch von Anmeldedaten und vor kritischen Releases die aktiven Sitzungen, lauschenden Ports, Hintergrundprozesse und den verbleibenden Speicherplatz. Wenn Sie einen unbekannten Prozess entdecken, dokumentieren Sie zuerst seine Prozessnummer, den ausführenden Benutzer und den Befehlspfad. Entscheiden Sie erst danach, ob er beendet werden soll, damit kein laufender Build versehentlich abgebrochen wird.

who
ps -axo user,pid,ppid,command
lsof -nP -iTCP -sTCP:LISTEN
df -h
find ~/work -type f -perm -004

Der letzte Befehl findet Dateien im Arbeitsverzeichnis, die für andere Benutzer lesbar sind. Er ersetzt keine vollständige Berechtigungsprüfung, deckt jedoch offensichtliche Fehlkonfigurationen schnell auf. Wenn mehrere Personen denselben Knoten verwenden, sollten gemeinsame und persönliche Verzeichnisse voneinander getrennt sein. Verwenden Sie außerdem keine global beschreibbaren Verzeichnisse, um Signaturmaterial zu übertragen.

Vor Mietende in der richtigen Reihenfolge exportieren und bereinigen

Beenden Sie zunächst Runner, Build-Agenten und benutzerdefinierte Hintergrundaufgaben, damit während der Bereinigung keine neuen Dateien entstehen. Packen Sie anschließend die aufzubewahrenden Projekte, Protokolle und Artefakte, erzeugen Sie eine Prüfsumme und entpacken Sie die Daten stichprobenartig auf einem anderen kontrollierten Gerät. Löschen Sie die Arbeitskopien auf dem Knoten erst, nachdem der erfolgreiche Export bestätigt wurde.

mkdir -p ~/export
ditto -c -k --keepParent ~/work/project ~/export/project.zip
shasum -a 256 ~/export/project.zip
git -C ~/work/project status --short

Die Bereinigung muss mindestens die Projekt- und Exportverzeichnisse, Build-Caches, temporären Verzeichnisse, Schlüsselbundeinträge, SSH-Autorisierungen, Einträge öffentlicher Schlüssel und den Shell-Verlauf des dedizierten Kontos umfassen. Widerrufen Sie das Repository-Token außerdem bei der ausstellenden Stelle und löschen Sie den privaten Schlüssel für diesen Mietzeitraum von Ihrer eigenen Workstation. Das wiederholte Überschreiben einzelner Dateien auf einer SSD ersetzt nicht den plattformseitigen Prozess zur Wiederaufbereitung des Knotens. Die Anzahl der Überschreibvorgänge ist daher kein Nachweis für eine abgeschlossene Bereinigung.

Führen Sie vor dem Verlassen des Knotens eine abschließende Gegenprüfung durch: Ist eine Anmeldung mit dem dedizierten Schlüssel weiterhin möglich? Ist das temporäre Token wirklich ungültig? Laufen noch Hintergrundprozesse? Befinden sich weiterhin Exportdateien auf dem Knoten? Enthält das Arbeitsverzeichnis nicht übertragene Änderungen? Halten Sie die Ergebnisse im Übergabeprotokoll fest, damit zwischen vermeintlich gelöschten Daten und tatsächlich noch bestehenden Zugriffsmöglichkeiten keine Lücke bleibt.

Häufig gestellte Fragen