Das Split-Trust Encryption Tool (STET) bietet einen Verteilungsmechanismus, der eine sichere Schlüsseldatenübertragung in und aus Google Cloud ermöglicht, die nachweislich und kryptografisch vor Google Cloud -Insidern geschützt ist.
Dazu werden zwei Schlüsselverwaltungssysteme (Key Management Systems, KMS) verwendet, eines intern inGoogle Cloudund eines extern. Selbst wenn ein KMS manipuliert wird, ist das zweite KMS vorhanden, um Ihre Daten zu schützen.
Im Folgenden finden Sie eine Reihe von Beispielen für Daten, die an Cloud Storage übertragen und mit Compute Engine-VMs berechnet werden. Die Beispiele veranschaulichen schrittweise zunehmende Sicherheitsebenen, um zu erklären, wie STET in Ihren Sicherheitsablauf passt.
Stufe 1: Cloud Storage
Wenn Sie Daten in Google Cloudaufnehmen, können Sie sie mit Cloud Storage für Ihre Cloud-Arbeitslasten verfügbar machen. Sie können die Daten aus Ihren lokalen Rechenumgebungen in einen Cloud Storage-Bucket hochladen, Ihrer Arbeitslast Zugriff auf diesen Bucket gewähren, sodass die Arbeitslast (oder mehrere Arbeitslasten) diese Daten bei Bedarf nutzen können. Diese Strategie vermeidet die Komplexität, direkt eine aktiven Verbindung zur Arbeitslast zu erstellen, um ihr die benötigten Daten zu senden.
Cloud Storage verschlüsselt Ihre inaktiven Daten immer. Wenn Sie Cloud Storage jedoch diese Verschlüsselung anvertrauen, hat Cloud Storage vor der Verschlüsselung notwendigerweise Zugriff auf die unverschlüsselten Daten (Klartext) sowie auf die Verschlüsselungsschlüssel, die zum Erstellen der verschlüsselten Daten (Geheimtext) verwendet werden. Abhängig von Ihrem Bedrohungsmodell können Sie die Daten verschlüsseln, bevor Sie sie an Cloud Storage senden, sodass Cloud Storage niemals den Klartext sieht.
Stufe 2: Clientseitige Verschlüsselung
Bei Verwendung der clientseitigen Verschlüsselung verschlüsseln Sie die Daten, bevor sie in Cloud Storage hochgeladen werden, und entschlüsseln sie erst, nachdem sie in Ihre Arbeitslast heruntergeladen wurden. Entsprechend hat Cloud Storage Zugriff auf den Geheimtext, nicht jedoch auf den Klartext. Cloud Storage fügt vor dem Speichern eine weitere Verschlüsselungsebene hinzu. Der Hauptschutz für die Daten ist jedoch die Verschlüsselung, die vor dem Hochladen durchgeführt wird.
Bei diesem Ansatz müssen Sie der Arbeitslast jetzt Zugriff auf den Verschlüsselungsschlüssel gewähren, der zum Entschlüsseln der Daten erforderlich ist. Dies ist selbst eine potenziell schwierige Aufgabe, da der Verschlüsselungsschlüssel die Möglichkeit bietet, Ihre ursprüngliche Verschlüsselungsebene zu entfernen und Einblick in die Daten zu erhalten.
Stufe 3: Externe Schlüsselverwaltung
Ein häufiger Ansatz für dieses Schlüsselverwaltungsproblem ist die Verwendung eines dedizierten Key Management Service (KMS), der die Schlüssel enthält und den Zugriff darauf verwaltet. Bei jedem Verschlüsselungs- oder Entschlüsselungsversuch muss eine Anfrage an den KMS gesendet werden. Der KMS hat die Möglichkeit, den Zugriff auf Basis verschiedener Kriterien zu gewähren, damit nur geeignete Parteien die Daten entschlüsseln können.
KMS-Systeme können eine Reihe verschiedener Kriterien anfordern, bevor sie den Zugriff auf den Verschlüsselungsschlüssel autorisieren. Sie erfordern jedoch normalerweise Anmeldedaten, die mit einer im KMS konfigurierten Richtlinie übereinstimmen. Daher kann jede Partei, die diese Anmeldedaten hat, auf den Verschlüsselungsschlüssel zugreifen und die Daten entschlüsseln.
Stufe 4: Confidential Computing
Confidential VM-Instanzen werden mit verschlüsseltem Arbeitsspeicher ausgeführt. Sie bieten während der Verwendung zusätzlichen Schutz vor unbeabsichtigtem Zugriff auf die Daten. Für viele Bedrohungsmodelle sind Confidential VM-Instanzen vertrauenswürdiger als Standardinstanzen, sodass sie für vertrauliche Arbeitslasten verwendet werden können.
Wenn Ihr Bedrohungsmodell das Confidential Computing nutzt, besteht ein Problem darin, dass eine Arbeitslast in einer Confidential VM-Instanz ausgeführt wird. Die Remote-Attestierung ist ein Mittel, mit dem die Arbeitslast einem Remote-Partner beweisen kann, dass sie tatsächlich in einer Confidential VM-Instanz ausgeführt wird. Gleichzeitig ist die Attestierung vieler anderer Attribute der Konfiguration und Umgebung der Arbeitslast möglich. Da die Attestierungen von der Plattform generiert werden, kann die Arbeitslast keine falschen Attestierungen erstellen, die nicht ihre tatsächliche Umgebung widerspiegeln.
Ein KMS kann diese Attestierungen anfordern und auswerten, bevor der Zugriff auf Schlüssel zugelassen wird. Durch diese Anforderung wird bewirkt, dass nur die vorgesehene Arbeitslast die Daten entschlüsseln kann, auch wenn die normalen Anmeldedaten manipuliert wurden.
Stufe 5: Split Trust
Bei Verwendung eines einzelnen KMS hat dieser allein die Kontrolle über die Verschlüsselungsschlüssel. Wenn der KMS-Operator den Geheimtext der verschlüsselten Daten abruft, erhält er alles, was zum Entschlüsseln in den Klartext erforderlich ist. Dieses Risiko kann akzeptabel sein, wenn der KMS von einer vollständig vertrauenswürdigen Entität betrieben wird. Einige Bedrohungsmodelle erfordern jedoch die Entfernung einer einseitigen Kontrolle aus dem KMS.
Mit STET haben Sie die Möglichkeit, dieses Vertrauen zwischen zwei KMS-Systemen aufzuteilen, wobei keines der beiden KMS-Systeme genügend Informationen zum Entschlüsseln Ihrer Daten hat. Zum Entschlüsseln Ihrer Daten ist eine Verknüpfung zwischen beiden KMS-Operatoren (und Zugriff auf den Geheimtext) erforderlich.
Wenn Sie Confidential VM verwenden, vereinfacht STET auch die Ver- und Entschlüsselung von Daten mithilfe von Schlüsseln, die in einem KMS gespeichert sind und Attestierungen erfordern.
STET sorgt dafür, dass die einzigen Entitäten, die Zugriff auf Ihre Klartextdaten haben, die Urheber der Daten (z. B. ein lokales System) und der Nutzer der Daten (z. B. eine Arbeitslast, die in einer Confidential VM-Instanz ausgeführt wird) sind.
Weitere Informationen zur Verwendung von STET finden Sie im GitHub-Repository und in der Kurzanleitung.
Confidential Space mit STET
Wenn Sie Confidential Space verwenden, kann STET das Attestierungstoken aus Confidential Space als Attestierungsnachweis beim Zugriff auf den in Cloud KMS gespeicherten Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) verwenden.
STET verwaltet den Zugriff auf Cloud KMS-Schlüssel für Ihre Arbeitslast und unterstützt die Verwendung von Confidential Space für die Attestierung des Verschlüsselungs-, Entschlüsselungs- oder beider Workflows.
Sie können eine STET-Konfiguration erstellen, die Informationen wie den Namen des Workload Identity Pool (WIP), Cloud KMS-URIs und Informationen zur Entschlüsselung enthält. STET verwendet diese Informationen dann, um sie in Ihre vertrauliche Gruppenbereichseinrichtung einzubinden.
Weitere Informationen finden Sie im GitHub-Repository und im Leitfaden zur Integration vertraulicher Gruppenbereiche.