Für IT-, Sicherheits- und Compliance-Teams im Gesundheitswesen gilt: Klärt zuerst Zuständigkeiten und Konto, legt dann Schlüssel und Identitätsmodell fest und richtet Dokumentzugriffe sowie Protokollierung ein, bevor Amazon Quick Daten mit PHI verarbeitet. PHI steht für „Protected Health Information“, also geschützte Gesundheitsdaten im US-Rechtsrahmen HIPAA. AWS bezeichnet Amazon Quick als HIPAA-geeignet. Diese Einstufung allein macht die Umgebung eines Kunden jedoch nicht HIPAA-konform.

Was die HIPAA-Eignung von Amazon Quick bedeutet

AWS zufolge gilt die HIPAA-Eignung für die Web-, Desktop- und Mobilclients von Amazon Quick. Die detaillierte Einrichtungsanleitung des Anbieters bezieht sich auf die Webversion. Für die jeweilige AWS-Umgebung bleiben die Kunden verantwortlich: Sie müssen das Business Associate Agreement (BAA) für das betreffende Konto akzeptieren, geeignete Dienste verwenden und ihre Konfiguration, Governance und Schutzmaßnahmen selbst festlegen.

Ein BAA, das über AWS Artifact für ein AWS-Konto akzeptiert wird, gilt laut AWS nicht automatisch für weitere Konten, ungeeignete Dienste oder die Konfiguration des Kunden. Die Einrichtung beginnt deshalb mit dem konkreten Konto und den Zuständigkeiten für den geplanten Workflow.

Amazon Quick in der passenden Reihenfolge einrichten

  1. BAA und Kontozuständigkeiten klären. Akzeptiert das BAA für das AWS-Konto, in dem Amazon Quick eingesetzt werden soll, und grenzt ab, welche Dienste und Schutzmaßnahmen zu diesem Workflow gehören. So bleibt die Vereinbarung dem Konto zugeordnet, für das sie gilt.
  2. Den Verschlüsselungsschlüssel vor der ersten Datenerstellung festlegen. AWS zufolge wird der Schlüssel für Amazon-Quick-Daten beim ersten Anlegen von Quick-Daten im Konto bestimmt und lässt sich später nicht ändern. Die Verschlüsselung ruhender Daten ist standardmäßig mit AWS-eigenen oder AWS-verwalteten Schlüsseln aktiviert. Kundenverwaltete Schlüssel sind optional, erfordern laut AWS aber ein Enterprise-Abonnement. Wer einen solchen Schlüssel benötigt, muss die Entscheidung vor der ersten Datenerstellung treffen.
  3. Das Identitätsmodell auswählen. AWS nennt IAM Identity Center, Active Directory, IAM-Föderation und lokale Amazon-Quick-Benutzer als Optionen. Die Auswahl betrifft auch die Verwaltung von Berechtigungen und Bereichsmitgliedschaften: Ein Wechsel des Identitätsanbieters erfordert laut AWS, diese Zuweisungen erneut einzurichten. Die Erkennung inaktiver Nutzer beschreibt AWS nur für IAM Identity Center und Active Directory.
  4. Dokumenten-ACLs beim Erstellen der Knowledge Base aktivieren. Eine ACL ist eine Zugriffskontrollliste, die festlegt, wer auf ein Dokument zugreifen darf. AWS zufolge muss die dokumentbezogene ACL-Auswertung bei einer unterstützten Knowledge Base bereits bei deren Erstellung ausgewählt werden; nachträglich lässt sie sich nicht hinzufügen. Prüft die Zuordnung von Identitäten zu ACLs vor der Aufnahme geschützter Dokumente sorgfältig. Falsche Zuordnungen können laut AWS Dokumente zugänglich machen, ohne dass ein Fehler oder Alarm ausgelöst wird.AWS nennt für die Aktualisierung einer Knowledge Base einen Standardzyklus von 24 Stunden. Wenn Änderungen an Zugriffsrechten schneller übernommen werden müssen, empfiehlt der Anbieter einen kürzeren Aktualisierungszyklus.
  5. Dokumente und strukturierte Daten getrennt absichern. Für unstrukturierte Dokumente beschreibt AWS eine Amazon Quick Knowledge Base mit Dokument-ACLs. Strukturierte Daten benötigen andere Kontrollen: Amazon Quick Sight kann den Zugriff auf Zeilen und Spalten steuern; Berechtigungen im vorgelagerten Datensee liegen bei AWS Lake Formation und dem Glue Data Catalog.AWS veranschaulicht diese Trennung mit einem fiktiven Szenario: Dokumente liegen in Amazon S3 und fließen in eine ACL-fähige Knowledge Base. Strukturierte Schadendaten werden vorgelagert aufbereitet und de-identifiziert, durch Lake Formation geregelt und über Amazon Athena und Amazon Quick Sight abgefragt. Das Beispiel beschreibt eine Architektur, keinen realen Kundenfall.
  6. Die Audit-Protokolle vor der Verarbeitung von PHI einplanen. AWS unterscheidet AWS CloudTrail von den von Amazon CloudWatch bereitgestellten Amazon-Quick-Protokollen. CloudTrail erfasst unterstützte API-Aufrufe und ausgewählte Ereignisse außerhalb von APIs. Chat-Nachrichten und Antwortinhalte enthält CloudTrail laut AWS nicht.Für die KI-spezifischen Protokolle nennt AWS fünf Typen: CHAT_LOGS, FEEDBACK_LOGS, AGENT_HOURS_LOGS, INDEX_USAGE_LOGS und KB_FILE_SYNC_LOGS. Chat- und Feedback-Aufzeichnungen können laut AWS PHI enthalten. Diese Inhalte gehören deshalb in die Planung der Zugriffs- und Aufbewahrungskontrollen.
  7. Berechtigungen und Protokollierung vor dem Einsatz mit PHI prüfen. Kontrolliert, ob die Identitäten den vorgesehenen Dokument-ACLs korrekt zugeordnet sind und die geplanten Audit-Daten an den richtigen Stellen erfasst werden. AWS beschreibt Guardrails als probabilistisch, also nicht als sichere Schranke für jeden Einzelfall. Ergänzende, deterministische Kontrollen wie IAM-Richtlinien, ACLs und Netzwerkgrenzen bleiben daher Teil der Schutzarchitektur.

Worauf sich die Sechsjahresfrist bezieht

45 CFR §164.316(b)(1) verlangt schriftliche Richtlinien und Verfahren sowie schriftliche Aufzeichnungen über Handlungen, Aktivitäten oder Bewertungen, wenn die Security Rule ihre Dokumentation vorschreibt. §164.316(b)(2)(i) setzt für diese Dokumentation eine Aufbewahrungsfrist von sechs Jahren an: gerechnet ab ihrer Erstellung oder ab dem Zeitpunkt, an dem sie zuletzt wirksam war, je nachdem, welcher Zeitpunkt später liegt. Den Wortlaut von 45 CFR §164.316 verknüpft die Frist mit dieser vorgeschriebenen Dokumentation, nicht pauschal mit jedem Roh-, Chat- oder Telemetrieprotokoll.

AWS empfiehlt in seiner Amazon-Quick-Anleitung unabhängig davon, Logs mindestens sechs Jahre aufzubewahren. Das ist die Empfehlung des Anbieters. Die genannte Vorschrift setzt dieselbe pauschale Frist nicht für jedes Amazon-Quick-Protokoll fest.

Betriebsgrenzen bei der Planung berücksichtigen

AWS beschreibt Amazon Quick als Dienst, der in einer einzelnen Region betrieben wird und kein regionsübergreifendes Failover bietet. Als mögliches Wiederherstellungsmuster nennt der Anbieter eine separate Bereitstellung samt unterstützenden Daten in einer anderen Region. Werden Daten über externe Konnektoren an ein anderes System gesendet, erstreckt sich die Verantwortung des Kunden laut AWS auch auf dieses System.

Vor dem Einsatz mit PHI sollten daher die Kontozuordnung des BAA, der festgelegte Schlüssel, das Identitätsmodell, die Knowledge-Base-ACLs und die vorgesehenen Audit-Protokolle zusammen geprüft werden.