Sichere Dateiübergabe auf Cloud Macs

Wenn ein Team Signaturmaterial, Testdaten oder noch abzunehmende Build-Artefakte auf einen Cloud Mac überträgt, besteht der häufigste Fehler darin, die Dateien direkt im Stammverzeichnis des Repositorys abzulegen. Sobald sie dort liegen, können Indexer, Build-Skripte und Bereinigungsaufgaben unmittelbar darauf zugreifen. Enthält ein Archiv Pfade außerhalb des vorgesehenen Verzeichnisses, falsche Berechtigungen oder nicht dokumentierte erweiterte Attribute, breiten sich die Probleme direkt in den Arbeitsbereich aus. Sicherer ist es, „Übertragung“ und „Nutzung“ in zwei getrennte Phasen aufzuteilen.

Übergabegrenzen zuerst festlegen

Für jede Übergabe müssen mindestens vier Punkte feststehen: Absender, Empfänger, Verwendungszweck der Dateien und Aufbewahrungsdauer. Quellcode-Patches, Test-Fixtures, Build-Artefakte und Zugangsdaten dürfen nicht gemeinsam in einem Archiv liegen. Zugangsdaten sind über kontrollierte Injektionsmechanismen bereitzustellen und gehören weder in Chatverläufe noch in Build-Protokolle oder gewöhnliche Dateipakete.

Auch auf dedizierten physischen Nodes von VMRunner sollte für jede Aufgabe ein eigenes temporäres Übergabeverzeichnis angelegt werden, anstatt dauerhaft vorhandene Verzeichnisse wie Downloads wiederzuverwenden. Als Verzeichnisname eignen sich Ticket- oder interne Auftragsnummern, nicht jedoch Kundennamen, E-Mail-Adressen oder andere vertrauliche Angaben.

umask 077
handoff_root="$HOME/Handoffs/task-4821"
install -d -m 700 "$handoff_root/incoming"
install -d -m 700 "$handoff_root/verified"
install -d -m 700 "$handoff_root/logs"
stat -f '%Su %Sg %Sp %N' "$handoff_root" "$handoff_root/incoming"

Mit umask 077 sind anschließend erstellte Dateien standardmäßig nur für den aktuellen Benutzer zugänglich. install -d erstellt das Verzeichnis und setzt gleichzeitig seine Berechtigungen. So entsteht kein kurzes Zeitfenster, in dem das Verzeichnis bereits vorhanden, aber noch nicht ausreichend geschützt ist.

Der temporäre Bereich ist nicht zur dauerhaften Aufbewahrung bestimmt. Er dient als kontrollierbarer Puffer, in dem Dateien geprüft, abgelehnt und bereinigt werden können, bevor sie in den Projektarbeitsbereich gelangen.

Vor dem Versand ein prüfbares Manifest erstellen

Der Absender sollte den Verzeichnisinhalt zunächst unveränderlich festlegen und erst danach die Prüfsummen erzeugen. Build-Prozesse dürfen Artefakte nicht weiter verändern, während deren Hashes berechnet werden. Andernfalls kann das beim Empfänger eintreffende Manifest zu einer anderen Version gehören. Empfehlenswert ist, die Dateien zunächst in ein schreibgeschütztes Übergabeverzeichnis zu kopieren, ihre Anzahl zu prüfen und anschließend ein SHA-256-Manifest zu erstellen.

Überflüssige Inhalte beim Paketieren vermeiden

Bei der Übergabe von Quellcode sind .git, lokale Caches, abgeleitete Daten und Umgebungsdateien auszuschließen. Bei Build-Artefakten müssen dagegen erforderliche Signaturstrukturen und erweiterte Attribute erhalten bleiben. Anwendungsverzeichnisse sollten nicht allein zur Verringerung der Dateigröße ohne Not neu gepackt werden.

cd "$HOME/Delivery/task-4821"
find . -type f ! -name 'SHA256SUMS' -print0 \
  | sort -z \
  | xargs -0 shasum -a 256 > SHA256SUMS
shasum -a 256 SHA256SUMS

Der Empfänger muss die Prüfsumme von SHA256SUMS selbst separat über einen bestätigten internen Kanal erhalten. Treffen Manifest und Dateien über denselben ungeprüften Übertragungsweg ein, könnte ein Angreifer beides gleichzeitig austauschen.

Vor dem Entpacken prüfen

Dateien müssen zuerst im Verzeichnis incoming abgelegt werden, statt das Repository direkt zu überschreiben. Nach Abschluss der Übertragung sind zunächst Namen, Größen, Eigentümer und Berechtigungen zu protokollieren und danach die Prüfsummen abzugleichen. Bei jeder Abweichung muss der Vorgang abgebrochen werden. Die Dateien sollten nicht „repariert und anschließend weiterverwendet“ werden, da die Ursache eine unterbrochene Übertragung, ein neu gepacktes Paket des Absenders oder ein Austausch der Dateien sein kann.

cd "$handoff_root/incoming"
shasum -a 256 -c SHA256SUMS
find . -maxdepth 2 -print0 \
  | xargs -0 stat -f '%z %Su %Sg %Sp %N' \
  > "$handoff_root/logs/received-files.txt"

Pfade im Archiv vorab kontrollieren

Bei ZIP-Archiven ist zunächst unzip -l package.zip, bei tar-Archiven zunächst tar -tf package.tar auszuführen. Pakete mit absoluten Pfaden, ../-Pfaden außerhalb des Zielverzeichnisses oder unerwarteten symbolischen Links sind abzulehnen. Nach erfolgreicher Prüfung darf das Archiv ausschließlich in ein leeres Verzeichnis entpackt werden. Anschließend sind Dateiliste und Berechtigungen erneut zu kontrollieren.

macOS-Dateien können außerdem erweiterte Attribute enthalten. Mit xattr -lr lassen sich Herkunftskennzeichnungen und weitere Attribute anzeigen. Sie sollten nicht routinemäßig rekursiv entfernt werden. Ein bestimmtes Attribut darf nur bei ausdrücklich bekannten Herkunfts- und Auswirkungsbedingungen und nur dann bearbeitet werden, wenn die jeweilige Aufgabe dies tatsächlich erfordert.

Berechtigungen bei der Übernahme einschränken

Nach erfolgreicher Prüfung werden die Dateien nach verified kopiert und anschließend durch die Projektverantwortlichen in den Arbeitsbereich übernommen. Dadurch bleibt eine geprüfte Fassung erhalten, die vom ursprünglich empfangenen Inhalt getrennt ist. Gewöhnliche Unterlagen können für den aktuellen Benutzer les- und schreibbar bleiben. Unveränderliche Eingaben, die nur vom Build gelesen werden, können schreibgeschützt gesetzt werden.

cp -R "$handoff_root/incoming/ProjectInput" \
  "$handoff_root/verified/"
chmod -R go-rwx "$handoff_root/verified"
find "$handoff_root/verified" -type f -exec chmod 600 {} +
find "$handoff_root/verified" -type d -exec chmod 700 {} +

Ein rekursives chmod darf nicht unbesehen auf das gesamte Projekt angewendet werden. Ausführbare Skripte, Anwendungspakete und Frameworks benötigen unterschiedliche Berechtigungen; eine pauschale Umstellung auf 600 kann nachfolgende Aufgaben beeinträchtigen. Die Einschränkung gilt ausschließlich für die temporäre Kopie. Bei der endgültigen Übernahme müssen erforderliche Berechtigungen anhand der Repository-Vorgaben oder Build-Regeln wiederhergestellt werden.

Wenn mehrere Personen über denselben Cloud Mac zusammenarbeiten, sollten getrennte Systembenutzer und Verzeichnisse verwendet werden. Vorübergehend globale Lese- und Schreibrechte zu vergeben ist zwar bequem, macht jedoch Herkunft und Verantwortlichkeit für Änderungen nicht mehr nachvollziehbar.

Zum Abschluss auf Rückstände prüfen

Vor Abschluss der Aufgabe ist zunächst sicherzustellen, dass das Projekt alle benötigten Dateien übernommen hat; außerdem muss die abschließende Prüfsumme protokolliert werden. Danach ist zu prüfen, ob entpackte Kopien, fehlgeschlagene Wiederholungspakete, Protokollanhänge oder Prozesse mit weiterhin geöffneten Dateien vorhanden sind. Da lsof +D bei großen Verzeichnissen langsam sein kann, sollte der Befehl nur für das temporäre Übergabeverzeichnis ausgeführt werden.

lsof +D "$handoff_root" 2>/dev/null
find "$handoff_root" -type f -maxdepth 4 -print
rm -rf "$handoff_root"
test ! -e "$handoff_root" && printf '%s\n' 'handoff removed'

Das Löschen des temporären Bereichs schließt die Verwaltung geheimer Werte nicht ab. Falls vertrauliche Werte in Befehlszeilenargumenten, dem Shell-Verlauf, Build-Protokollen oder Fehlerberichten gelandet sind, müssen auch diese Einträge bereinigt und die betroffenen Zugangsdaten rotiert werden. Für gewöhnliche Übergaben genügen minimale Auditinformationen: Aufgabenkennung, Sende- und Empfangszeitpunkt, Manifest-Prüfsumme, Prüfergebnis und Löschstatus. Die eigentlichen Dateiinhalte werden nicht aufbewahrt.

Ein stabiler Ablauf für die Remote-Zusammenarbeit darf nicht davon abhängen, dass „alle daran denken, vorsichtig zu sein“. Dateien müssen vier klar definierte Schritte durchlaufen: Isolierung, Prüfung, Autorisierung und Entfernung. Werden diese Befehle in Team-Skripte integriert, sollten Hash-Fehler, Pfadüberschreitungen und fehlerhafte Berechtigungen regelmäßig mit harmlosen Beispieldaten getestet werden. So bleibt nicht nur der reguläre Ablauf, sondern auch der Ablehnungspfad zuverlässig ausführbar.

Häufig gestellte Fragen

Warum sollten Dateien nicht direkt im Projektverzeichnis landen?

Build-Skripte und Indexer könnten ungeprüfte Inhalte sofort verarbeiten. Ein separater Eingang erlaubt die Kontrolle von Hashes, Rechten und Archivinhalt vor der Übernahme.

Beweist eine SHA-256-Summe die Identität des Absenders?

Nein. Sie bestätigt nur, dass die empfangene Datei zur veröffentlichten Prüfsumme passt. Die Prüfsumme muss über einen bereits authentifizierten Kanal kommen.

Was gehört zu einem sauberen Abschluss?

Prüfen Sie Kopien, Caches, Archive und noch laufende Prozesse, bevor Sie den Übergabebereich löschen. Geheimnisse sollten getrennt injiziert und bei möglicher Offenlegung erneuert werden.