Symptom: Die Analyse benötigt macOS, aber Ihr Team weiß nicht, ob NIH-Daten dafür auf einen externen Remote Mac dürfen.
Schnellste Lösung: Übertragen Sie nichts, bevor Projektfreigabe, Hochschulprüfung und konkrete Servicebedingungen bestätigt sind.

Dieser Leitfaden ist für PI und Projektverantwortliche, die eine Analyseumgebung freigeben müssen.
Datenverantwortliche und Hochschul-IT erhalten Prüfpunkte für Zugriffe, Datenwege und das Projektende.
Als Forschende testen Sie die Software zunächst mit öffentlichen oder synthetischen Daten.

NIH-Daten mit kontrolliertem Zugriff auf einem Remote Mac: erst Freigabe, dann Technik

Ein Remote Mac kann technisch für eine Analyse geeignet sein. Das beantwortet aber nicht, ob Ihr Projekt die Verarbeitung dort erlaubt. Bei NIH-Daten mit kontrolliertem Zugriff müssen Sie drei Fragen getrennt beantworten: Deckt die Datenfreigabe die geplante Nutzung ab? Erfüllt die Umgebung die Anforderungen Ihrer Hochschule? Sind die tatsächlichen Zugriffs-, Speicher- und Löschbedingungen des Dienstes akzeptabel?

Diese Prüfungen ersetzen einander nicht. Eine NIH-Freigabe genehmigt nicht automatisch jede externe Umgebung. Eine erfolgreiche IT-Sicherheitsprüfung erweitert nicht den genehmigten Forschungszweck. Verschlüsselung wiederum ist eine technische Maßnahme, keine Projektgenehmigung.

Die NIH-Anforderungen an Nutzerinnen und Nutzer kontrollierter Daten sind der Ausgangspunkt für die Projektprüfung. Für eine konkrete Entscheidung brauchen Sie zusätzlich die geltende Data Use Certification, institutionelle Richtlinien und Angaben zur tatsächlichen Dienstkonfiguration. Dieser Beitrag ist ein Prüfrahmen, keine Rechtsberatung und keine Zusage, dass ein bestimmter Remote-Mac-Dienst die Vorgaben eines Projekts erfüllt.

PI und Projektleitung: den genehmigten Umfang abgleichen

Prüfen Sie zuerst die Unterlagen, die den Datenzugriff für Ihr Projekt regeln. Entscheidend ist nicht nur, ob der Datensatz grundsätzlich verfügbar ist. Maßgeblich ist, ob die geplante Analyse, die beteiligten Personen und die vorgesehenen Arbeitsbedingungen von der Genehmigung gedeckt sind.

Die NIH-Informationen zur Data Use Certification helfen Ihnen, den vereinbarten Nutzungsrahmen zu identifizieren. Legen Sie die Projektunterlagen neben den geplanten Arbeitsablauf und beantworten Sie schriftlich:

  • Entspricht die Analyse dem genehmigten Forschungszweck?
  • Sind alle Personen, die auf Daten oder Arbeitskopien zugreifen könnten, für das Projekt zugelassen?
  • Sind die geplante Verarbeitung und die dazugehörigen Systeme mit den Zugriffsbedingungen vereinbar?
  • Müssen Sie die neue Umgebung der zuständigen Stelle, dem Data Access Committee oder einer Hochschulstelle melden beziehungsweise zur Prüfung vorlegen?

Bei der NIH GDS Policy sollten Sie nicht aus einer allgemeinen Beschreibung der Cloud-Nutzung schließen, dass jede Cloud- oder Remote-Umgebung freigegeben ist. Lesen Sie die aktuellen NIH-Best-Practices für kontrollierte Daten im Rahmen der NIH GDS Policy zusammen mit den projektbezogenen Bedingungen. Fragen Sie nach, wenn Ihre Unterlagen die konkrete Ausführungsumgebung nicht eindeutig abdecken.

Stoppbedingung: Ist die Genehmigung unklar, widersprechen sich Projektunterlagen oder ist nicht geklärt, wer eine Änderung freigeben darf, übertragen Sie keine kontrollierten Daten. Lassen Sie den PI oder die institutionell zuständige Stelle die Frage klären.

Datenverantwortliche: den gesamten Datenweg sichtbar machen

Die Prüfung darf nicht bei der Eingabedatei enden. Zeichnen Sie nach, wo Daten während der Arbeit entstehen, verarbeitet, angezeigt, exportiert und gegebenenfalls gesichert werden. Beziehen Sie dabei Menschen und Systeme ein: Mitarbeitende mit Kontozugriff, administrative Zugriffe, Support, lokale Rechner und mögliche externe Speicherdienste.

Für die Bestandsaufnahme sollten Sie mindestens diese Datenarten getrennt erfassen:

  • Ausgangsdaten: heruntergeladene oder übertragene Dateien und alle Kopien davon.
  • Arbeitsdaten: Zwischenergebnisse, temporäre Dateien, Cache-Inhalte und Skripte mit eingebetteten Daten oder Zugangsdaten.
  • Ergebnisse und Protokolle: abgeleitete Dateien, Exporte, Fehlermeldungen und Analyseprotokolle.
  • Sicherungskopien: Snapshots, automatische Backups und sonstige Kopien, soweit diese im geplanten Dienst oder Arbeitsablauf entstehen können.

Die NIH-Sicherheitsempfehlungen für Nutzer kontrollierter Daten und der NIH Code of Conduct für Genomdatennutzer bieten offizielle Bezugspunkte für den Umgang mit Zugriff und Nutzung. Übersetzen Sie diese Vorgaben in prüfbare Fragen für Ihren Fall: Wer darf welche Daten sehen? Wie werden Zugänge vergeben und entzogen? Wo liegen Kopien? Was wird protokolliert? Welche Schritte sind beim Projektende vorgesehen?

Verschlüsselung, De-Identifizierung oder ein Fernzugriff per Desktop beantworten diese Fragen nicht vollständig. Sie belegen für sich genommen weder, dass der Datenzugriff genehmigt ist, noch dass alle Kopien und Beteiligten den Projektbedingungen entsprechen.

Hochschul-IT: Dienst, Zuständigkeiten und Risiken prüfen

Die institutionelle Prüfung betrifft den tatsächlichen Betrieb. Lassen Sie sich nicht mit einer Produktbeschreibung zufriedengeben. Klären Sie, wer die Hardware und den Zugang betreibt, welche Personen oder Rollen auf die Umgebung zugreifen können und wie Konten, Supportfälle und Sicherheitsereignisse behandelt werden. Prüfen Sie außerdem, welche Unterlagen schriftlich vorliegen und ob sie zur Klassifizierung der Daten passen.

Trennen Sie dabei die Regelungsebenen:

  • Projektauflagen: Bedingungen der NIH-Datenfreigabe und projektbezogene Vereinbarungen.
  • Hochschulvorgaben: Datenklassifizierung, Beschaffung, Fernzugriff, Aufbewahrung und Sicherheitsfreigabe.
  • Anwendbare Vorschriften: etwa HIPAA, falls die konkrete Verarbeitung in dessen Anwendungsbereich fällt.

Für passende HIPAA-Szenarien erläutert das HHS die Anforderungen an Cloud Computing und die Verantwortung von Dienstanbietern. Lassen Sie die institutionell zuständige Stelle prüfen, ob HIPAA für Ihren Fall greift und welche Vereinbarungen oder Maßnahmen erforderlich sind. Leiten Sie aus Verschlüsselung, einem Anbieterhinweis oder einer allgemeinen Cloud-Aussage keine Compliance-Entscheidung ab. Auch Datenschutzvorgaben wie die DSGVO sind gesondert anhand des konkreten Projekts und der institutionellen Zuständigkeit zu bewerten.

Fordern Sie vor einer Freigabe Antworten auf konkrete Betriebsfragen an: Wie wird der Zugriff eingerichtet und beendet? Welche Datenstandorte sind dokumentiert? Wie werden Sicherheitsvorfälle gemeldet? Welche Daten bleiben nach Ende des Miet- oder Nutzungszeitraums zurück? Wer bestätigt Rückgabe oder Löschung, und welche schriftlichen Nachweise kann die Hochschule erhalten? Ist eine Antwort unbekannt, markieren Sie den Punkt als offen. Ersetzen Sie ihn nicht durch eine Annahme.

Ein externer Mac kann gegenüber einem eigenen Arbeitsplatzrechner Vorteile für einen befristeten Softwaretest bieten: Das Team muss nicht sofort eigene Hardware beschaffen, und macOS lässt sich für einen klar eingegrenzten Versuch nutzen. Dem stehen neue Prüfpunkte gegenüber: Sie müssen Dienstzugriffe bewerten, den vollständigen Datenpfad dokumentieren und die Beendigung der Verarbeitung klären. Für kontrollierte NIH-Daten wiegt die offene Zuständigkeit schwerer als der Komfort des Fernzugriffs.

Forschungsteam: Technik ohne kontrollierte Daten abnehmen

Bevor Sie eine Freigabe beantragen, können Sie die technische Eignung testen, ohne NIH-Daten zu bewegen. Nutzen Sie öffentliche Daten oder synthetische Beispieldateien. Dokumentieren Sie, ob die benötigte Anwendung startet, welche Abhängigkeiten nötig sind und ob die Ergebnisse reproduzierbar erzeugt werden können.

Eine solche Probe beantwortet technische Fragen, keine Berechtigungsfragen. Ein erfolgreicher Import synthetischer Daten belegt nicht, dass die reale Datei übertragen werden darf. Auch ein funktionierender Zugang beweist nicht, dass Nutzerkonten, Datenablage oder Supportzugriffe institutionell akzeptiert sind.

Halten Sie die Testergebnisse so fest, dass PI, Datenverwaltung und IT damit arbeiten können:

  • Benennen Sie die benötigte Software und deren Datenformate.
  • Notieren Sie, welche Dateien die Anwendung beim Import, während der Analyse und beim Export erzeugt.
  • Dokumentieren Sie erforderliche Konten, Zugangsdaten und Verbindungen.
  • Beschreiben Sie, wie Ergebnisse an die Hochschule zurückgegeben werden sollen.
  • Markieren Sie Zugriffswege, die für das Projekt nicht akzeptabel wären.

Für einen Mac-Umgebungstest kann ein Remote-System eine Ergänzung zu den vorhandenen Linux- oder Windows-Arbeitsplätzen sein. Wenn Sie zunächst die verfügbaren Optionen prüfen möchten, finden Sie Informationen in der MACCOME-Übersicht für den deutschen Markt. Das ist keine Aussage darüber, ob ein konkretes Angebot die NIH-Bedingungen Ihrer Hochschule erfüllt. Dafür benötigen Sie die tatsächlichen Serviceunterlagen und die institutionelle Freigabe.

Häufige Fragen zur Datenfreigabe und zum Projektende

Verschlüsselung: Reicht sie für die Freigabe aus?
Nein. Verschlüsselung kann eine Sicherheitsmaßnahme sein, ersetzt aber weder die Genehmigung des Forschungszwecks noch die Prüfung von Personen, Datenwegen und institutionellen Vorgaben. Lassen Sie die Hochschule bewerten, welche Schutzmaßnahmen erforderlich sind und ob die konkrete Betriebsweise des Dienstes dazu passt.

Antrag: Muss die Cloud-Umgebung bereits angegeben werden?
Prüfen Sie Ihre Antragsunterlagen, die Data Use Certification und Hinweise der zuständigen NIH-Stelle. Ob eine Änderung oder zusätzliche Beschreibung erforderlich ist, hängt vom Projekt und den einschlägigen Bedingungen ab. Wenn die geplante Umgebung dort nicht abgebildet ist, bitten Sie die zuständige Stelle um eine schriftliche Klärung, bevor Sie Daten übertragen.

De-Identifizierung: Darf eine bereinigte Datei vorab hochgeladen werden?
Nicht ohne vorherige Klassifizierung. Eine bereinigte oder abgeleitete Datei kann weiterhin unter Projektbedingungen fallen oder sensible Informationen enthalten. Legen Sie die konkrete Datei der zuständigen Daten- oder Sicherheitsstelle zur Bewertung vor. Bis dahin verwenden Sie nur öffentliche oder synthetische Testdaten.

Projektende: Wie lässt sich Löschung nachvollziehen?
Vereinbaren Sie vor Beginn, welche Arbeitskopien und abgeleiteten Dateien erfasst werden, wer sie zurückgibt oder löscht und wie der Abschluss dokumentiert wird. Berücksichtigen Sie auch Sicherungskopien und temporäre Dateien. Die NIST-Leitlinie zur Bereinigung von Speichermedien ist eine technische Referenz, aber kein Nachweis, dass ein bestimmter Dienst Ihre Projektanforderungen erfüllt.

Freigabe-Gate: erst weiter, wenn alle Punkte bestätigt sind

Nutzen Sie diese Liste als gemeinsame Übergabe zwischen PI, Datenverwaltung, Forschungsteam und IT. Setzen Sie ein Häkchen erst, wenn die zuständige Person die Aussage anhand der Projektunterlagen oder schriftlichen Serviceangaben geprüft hat.

  • [ ] Der genehmigte Forschungszweck deckt die geplante Analyse ab.
  • [ ] Die zugelassenen Personen und ihre Zugriffsrollen sind geklärt.
  • [ ] Die Data Use Certification und weitere Projektbedingungen wurden mit der geplanten Umgebung abgeglichen.
  • [ ] Die Hochschule hat Dienst, Verantwortlichkeiten und Zugriffswege geprüft.
  • [ ] Eingaben, Zwischenstände, Ergebnisse, Protokolle und mögliche Sicherungskopien sind im Datenweg erfasst.
  • [ ] Verfahren für Sicherheitsvorfälle und Zugriffsentzug sind dokumentiert.
  • [ ] Rückgabe, Löschung und deren Nachweis sind für das Projektende geklärt.
  • [ ] Die zuständigen Personen haben offene regulatorische Fragen bewertet.

Fehlt auch nur eine notwendige Bestätigung, migrieren Sie die kontrollierten Daten nicht. Nutzen Sie bis zur Klärung eine bereits institutionell genehmigte Umgebung. So bleibt der technische Test möglich, ohne dass ein erfolgreicher Login mit einer Datenfreigabe verwechselt wird.

Remote-Mac-Miete erst nach institutioneller Prüfung auswählen

Ein vorhandener Linux- oder Windows-HPC-Arbeitsplatz kann für etablierte Workflows geeigneter sein: Die Hochschule kennt möglicherweise bereits dessen Zuständigkeiten, Datenpfade und Freigaben. Seine Nachteile zeigen sich, wenn die benötigte Software macOS voraussetzt, ein Mac-Kompatibilitätstest fehlt oder die vorhandene Umgebung den konkreten Analyseablauf nicht abbildet. Ein gemieteter Mac kann dann eine befristete technische Option sein, bringt aber zusätzliche Fragen zu Zugriffsrechten, Datenstandort und Löschung mit sich.

Wenn Ihre Hochschule einen Remote-Mac-Einsatz grundsätzlich genehmigt hat, vergleichen Sie anschließend die schriftlich verfügbaren Servicedaten mit den Anforderungen Ihres Projekts. MACCOME kann für die Prüfung einer zeitlich begrenzten Mac-Umgebung in Betracht kommen; verlassen Sie sich jedoch nicht auf eine pauschale Aussage zur Eignung für NIH- oder HIPAA-Daten. Prüfen Sie die Angaben zum Mac-Angebot von MACCOME und lassen Sie die tatsächlichen Unterlagen von PI und Hochschul-IT bewerten. Solange die Freigabe oder Datenbehandlung offen ist, bleibt der Remote Mac ein Techniktest ohne kontrollierte Forschungsdaten.