Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Confidential Space menyediakan lingkungan terisolasi untuk mengoperasikan data sensitif
dari beberapa pihak, sehingga pemilik data tersebut dapat menjaganya tetap rahasia.
Data sensitif dapat mencakup informasi identitas pribadi (PII),
informasi kesehatan terlindungi (PHI), kekayaan intelektual, rahasia
kriptografi, model machine learning (ML), atau lainnya.
Anda dapat menggunakan Confidential Space untuk mengoperasikan data sensitif yang hanya dapat dilihat oleh pemilik aslinya dan workload yang disepakati bersama. Atau, Anda
dapat menggunakannya untuk menawarkan privasi data yang lebih kuat kepada pelanggan akhir, karena operator atau
pemilik lingkungan Confidential Space tidak dapat mengakses data yang sedang
diproses.
Confidential Space menggunakan trusted execution environment (TEE) yang dapat digunakan untuk
merilis secret Anda hanya ke workload yang diizinkan. Proses pengesahan dan
OS image yang telah melalui proses hardening membantu melindungi workload dan data yang diproses oleh workload
dari operator.
Sistem Confidential Space memiliki tiga komponen inti:
Workload: Image dalam container yang berisi kode yang memproses
resource yang dilindungi. Ini dijalankan di atas
image Confidential Space, OS yang telah melalui proses hardening berdasarkan
Container-Optimized OS.
Selanjutnya, aplikasi ini berjalan di Confidential VM, TEE berbasis cloud yang menawarkan isolasi hardware dan kemampuan pengesahan jarak jauh. Workload biasanya terletak di project terpisah dari resource yang dilindungi.
Layanan pengesahan: Verifikasi pengesahan jarak jauh yang menampilkan bukti pengesahan dalam bentuk token OpenID Connect (OIDC). Token berisi atribut identifikasi untuk workload.
Layanan pengesahan berjalan di region yang sama dengan tempat workload berjalan.
Resource terlindungi: Resource terkelola yang dilindungi oleh sistem autentikasi dan otorisasi. Jika resource berada di Google Cloud,
resource tersebut dapat berupa resource cloud terkelola seperti kunci Cloud Key Management Service (Cloud KMS)
atau bucket Cloud Storage. Jika resource tidak ada di Google Cloud (misalnya, di lingkungan lokal atau di cloud lain), maka resource tersebut dapat berupa resource apa pun.
Peran Confidential Space
Komponen dalam sistem Confidential Space dikelola oleh orang-orang dengan tiga peran berbeda:
Kolaborator data: Orang atau organisasi yang memiliki resource
yang dilindungi yang dioperasikan oleh beban kerja. Kolaborator data dapat mengakses
data mereka sendiri, menetapkan izin pada data tersebut, dan bergantung pada output
beban kerja, dapat mengakses hasil berdasarkan data tersebut.
Kolaborator data tidak dapat mengakses data satu sama lain atau mengubah kode beban kerja.
Penulis workload: Orang yang membuat aplikasi yang mengakses dan
memproses data rahasia. Mereka menambahkan aplikasi ke image dalam container, misalnya, menggunakan Docker, dan mengupload image ke repositori seperti Artifact Registry.
Penulis workload tidak memiliki akses ke data atau hasil, dan tidak dapat
mengontrol akses ke data atau hasil tersebut.
Operator workload: Orang yang menjalankan workload. Operator workload biasanya memiliki hak istimewa administratif penuh pada project tempat mereka menjalankan workload. Misalnya, mereka dapat mengelola resource di project mereka (seperti instance Compute Engine, disk, dan aturan jaringan) dan dapat berinteraksi denganGoogle Cloud API apa pun yang menjalankannya.
Operator beban kerja tidak memiliki akses ke data, dan tidak dapat mengontrol akses ke data tersebut. Mereka tidak dapat memengaruhi atau mengubah kode workload atau lingkungan
eksekusi.
Lihat Men-deploy workload untuk mempelajari lebih lanjut peran operator workload.
Seseorang dapat mengemban satu atau beberapa peran ini. Untuk keamanan tertinggi, Confidential Space mendukung model kepercayaan di mana kolaborator data, penulis workload, dan operator workload adalah pihak yang terpisah dan saling tidak percaya. Semua
peran harus berkolaborasi satu sama lain untuk mendapatkan hasil yang mereka butuhkan.
Contoh alur Confidential Space
Confidential Space menggunakan beberapa layanan Google Cloud untuk membantu mengoperasikan informasi pribadi secara rahasia. Secara umum, penyiapan
Ruang Rahasia mungkin terlihat mirip dengan proses berikut:
Beberapa kolaborator data menyimpan data rahasia terenkripsi dalam
project Google Cloud terisolasi mereka sendiri, sering kali di organisasi yang berbeda. Mereka ingin
membandingkan dan memproses data tersebut tanpa mengungkapkannya kepada satu sama lain atau
pihak eksternal. Data terenkripsi mungkin berada di
Cloud Storage,
BigQuery, atau layanan lain.
Kolaborator data membuat data tiruan yang tidak rahasia untuk beban kerja pengujian yang akan dioperasikan. Data ini dapat berupa file yang berbeda, atau berada di
tempat yang berbeda seperti bucket Cloud Storage terpisah.
Kolaborator data membuat
workload identity pool (WIP).
Selanjutnya, workload yang berjalan di project terpisah dan terisolasi operator workload
dapat menggunakan WIP tersebut untuk mengakses data rahasia kolaborator.
Penulis workload menulis kode untuk memproses data rahasia. Dalam project yang terpisah dari kolaborator data dan operator beban kerja, mereka membuat image yang di-container dengan Docker dan menguploadnya ke Artifact Registry.
Operator workload membuat akun layanan dalam project terisolasi yang memiliki akses baca ke tempat data rahasia terenkripsi kolaborator data disimpan, dan akses tulis ke suatu tempat (misalnya, bucket Cloud Storage) untuk menghasilkan output dari pengoperasian data yang didekripsi. Kemudian, akun layanan ini dilampirkan ke Confidential VM yang menjalankan beban kerja.
Kolaborator data menambahkan
penyedia ke
workload identity pool mereka. Mereka menambahkan detail ke penyedia seperti
layanan pengesahan yang harus digunakan,
pemetaan atribut
untuk membuat jejak audit dalam log, dan
kondisi atribut.
Detail ini memverifikasi
pernyataan yang dibuat oleh
image Confidential Space, container workload, dan instance VM workload. Jika workload lulus verifikasi ini, workload diizinkan untuk mengakses dan mendekripsi data rahasia.
Workload diuji pada data non-rahasia dengan memulai instance Confidential VM di project operator workload. VM didasarkan pada
versi debug image Confidential Space yang memuat beban kerja
dalam container.
Setelah pengesahan VM diverifikasi dan beban kerja memenuhi kondisi kolaborator data, akun layanan yang terpasang ke VM diizinkan untuk mengakses data rahasia, memprosesnya, dan menghasilkan output.
Setelah pemantauan dan proses debug selesai, workload akan diperbarui untuk penggunaan produksi. Kolaborator data
memperbarui dan mengamankan penyedia identitas beban kerja mereka lebih lanjut jika diperlukan,
dan mereka dapat memilih untuk menguji beban kerja produksi pada data
non-rahasia terlebih dahulu.
Semua pihak menyetujui workload produksi, dan workload tersebut siap untuk mulai
memproses data rahasia.
Persyaratan
Confidential Space memerlukan Confidential VM agar dapat berfungsi. Instance Confidential VM harus menggunakan
AMD SEV, Intel TDX, atau Intel TDX dengan NVIDIA Confidential Computing (Pratinjau) sebagai teknologi Confidential Computing. Lihat
Konfigurasi yang didukung untuk mempelajari opsi konfigurasi hardware, dan lokasi tempat instance Confidential VM dapat dibuat.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-18 UTC."],[[["\u003cp\u003eConfidential Space offers a secure environment for processing sensitive data, ensuring that data owners retain confidentiality and control over who can access their information.\u003c/p\u003e\n"],["\u003cp\u003eThe system utilizes a trusted execution environment (TEE) with attestation processes and a hardened OS to safeguard workloads and data from unauthorized access, even from the operator.\u003c/p\u003e\n"],["\u003cp\u003eConfidential Space is built around three core components: a containerized workload, an attestation service for verifying workload identity, and protected resources managed by authentication and authorization systems.\u003c/p\u003e\n"],["\u003cp\u003eThree distinct roles—data collaborators, workload authors, and workload operators—manage the system, enabling a trust model where these parties can be separate and mutually distrusting for enhanced security.\u003c/p\u003e\n"],["\u003cp\u003eSetting up Confidential Space involves a detailed process that includes encrypted data storage, test workload creation, service account setup, code development, attestation verification, and rigorous testing before production use on confidential data.\u003c/p\u003e\n"]]],[],null,["# Confidential Space overview\n\n*** ** * ** ***\n\nConfidential Space provides an isolated environment to operate on sensitive data\nfrom multiple parties, so the owners of that data can keep it confidential.\nSensitive data might include personally identifiable information (PII),\nprotected health information (PHI), intellectual property, cryptographic\nsecrets, machine learning (ML) models, or otherwise.\n\nYou might use Confidential Space to operate on sensitive data that's only visible\nto its original owners and a mutually agreed-upon workload. Alternatively, you\ncould use it to offer end customers stronger data privacy, as the operator or\nowner of a Confidential Space environment can't access the data that is being\nprocessed.\n\nConfidential Space uses a trusted execution environment (TEE) that can be used to\nrelease your secrets only to authorized workloads. An attestation process and\nhardened OS image help protect the workload and the data that the workload\nprocesses from an operator.\n\nFor more detail about Confidential Space's use cases and security model, see\n[Confidential Space security overview](/docs/security/confidential-space).\n\nConfidential Space components\n-----------------------------\n\nA Confidential Space system has three core components:\n\n- **A workload** : A containerized image containing code that processes the\n protected resources. This is run on top of a\n [Confidential Space image](/confidential-computing/confidential-space/docs/confidential-space-images), a\n hardened OS based on\n [Container-Optimized OS](/container-optimized-os/docs/concepts/features-and-benefits).\n This in turn runs on a [Confidential VM](/confidential-computing/confidential-vm/docs), a cloud-based TEE\n that offers hardware isolation and remote attestation capabilities. The\n workload is typically located in a separate project from the protected\n resources.\n\n- **The attestation service** : A remote attestation verifier that returns\n attestation evidence in the form of\n [OpenID Connect](https://developers.google.com/identity/protocols/oauth2/openid-connect)\n (OIDC) tokens. The tokens contain identification attributes for the workload.\n The attestation service runs in the same region that the workload is running\n in.\n\n- **Protected resources**: Managed resources that are protected by an\n authentication and authorization system. If the resources are in Google Cloud,\n they can be managed cloud resources such as Cloud Key Management Service (Cloud KMS)\n keys or Cloud Storage buckets. If the resources aren't in Google Cloud (for\n example, in an on-premises environment or in another cloud), then they can be\n any resource.\n\nConfidential Space roles\n------------------------\n\nThe components in a Confidential Space system are managed by people with three\ndistinct roles:\n\n- **Data collaborators**: The people or organizations who own the protected\n resources being operated on by the workload. Data collaborators can access\n their own data, set permissions on that data, and depending on the workload's\n output might access results based on that data.\n\n Data collaborators can't access each other's data or modify the workload code.\n\n See\n [Create and grant access to confidential resources](/confidential-computing/confidential-space/docs/create-grant-access-confidential-resources)\n to learn more about the role of data collaborators.\n- **Workload author** : The person who creates the application that accesses and\n processes the confidential data. They add the application to a containerized\n image, for example, using [Docker](https://www.docker.com/), and upload the\n image to a repository such as [Artifact Registry](/artifact-registry/docs).\n\n The workload author has no access to the data or the results, and can't\n control access to them either.\n\n See\n [Create and customize workloads](/confidential-computing/confidential-space/docs/create-customize-workloads)\n to learn more about the workload author's role.\n- **Workload operator**: The person who runs the workload. The workload operator\n typically has full administrative privileges on the project they run the\n workload in. For example, they can manage resources in their project (such as\n Compute Engine instances, disks, and networking rules) and can interact with any\n Google Cloud API that acts on them.\n\n The workload operator has no access to the data, and can't control access to\n it either. They can't influence or modify the workload code or execution\n environment.\n\n See [Deploy workloads](/confidential-computing/confidential-space/docs/deploy-workloads) to learn more\n about the workload operator's role.\n\nA person can assume one or more of these roles. For the highest security,\nConfidential Space supports a trust model where data collaborators, workload\nauthors, and workload operators are separate, mutually distrusting parties. All\nroles must collaborate with each other to get the results they need.\n\nAn example Confidential Space flow\n----------------------------------\n\nConfidential Space makes use of multiple Google Cloud services to help private\ninformation be operated on confidentially. In general, setting up a\nConfidential Space might look similar to the following process:\n\n1. Multiple data collaborators store encrypted confidential data in their own\n isolated Google Cloud projects, often in different organizations. They want\n to compare and process that data without revealing it to each other or\n external parties. The encrypted data might live in\n [Cloud Storage](/storage/docs),\n [BigQuery](/bigquery/docs), or another service.\n\n2. The data collaborators create mock, non-confidential data for a test\n workload to operate on. This data might be different files, or live in a\n different place like a separate Cloud Storage bucket.\n\n3. The data collaborators create a\n [workload identity pool](/iam/docs/workload-identity-federation) (WIP).\n Later, a workload running in a workload operator's separate, isolated\n project can use that WIP to access the collaborators' confidential data.\n\n4. The workload author writes code to process the confidential data. In a\n project separate from the data collaborators and workload operator, they\n build a containerized image with Docker and upload it to\n [Artifact Registry](/artifact-registry).\n\n5. The workload operator creates a service account in an isolated project that\n has read access to where the data collaborators' encrypted confidential data\n is stored, and write access to somewhere (for example, a\n Cloud Storage bucket) to output the result of operating on the\n decrypted data. Later, this service account is attached to a Confidential VM\n which runs the workload.\n\n6. The data collaborators add a\n [provider](/iam/docs/workload-identity-federation#providers) to their\n workload identity pools. They add details to the provider like the\n attestation service that must be used,\n [attribute mappings](/iam/docs/workforce-identity-federation#attribute-mappings)\n to create an audit trail in logs, and\n [attribute conditions](/iam/docs/workload-identity-federation#conditions).\n These details verify the\n [assertions](/confidential-computing/confidential-space/docs/reference/attestation-assertions) made by\n the Confidential Space image, the workload container, and the workload VM\n instance. If the workload passes this verification, it's allowed to access\n and decrypt the confidential data.\n\n7. The workload is tested on the non-confidential data by starting a\n Confidential VM instance in the workload operator's project. The VM is based on\n a debug version of the Confidential Space image which loads the containerized\n workload.\n\n After the VM's attestations are verified and the workload passes the data\n collaborators' conditions, the service account attached to the VM is allowed\n to access the confidential data, process it, and output a result.\n8. After [monitoring and debugging](/confidential-computing/confidential-space/docs/monitor-debug) is\n complete, the workload is updated for production use. The data collaborators\n update and lock down their workload identity providers further if required,\n and they might choose to test the production workload on non-confidential\n data first.\n\n9. All parties sign off on the production workload, and it's ready to begin\n working on confidential data.\n\nRequirements\n------------\n\nConfidential Space requires Confidential VM to work. Confidential VM instances must use\nAMD SEV, Intel TDX, or Intel TDX with NVIDIA Confidential Computing ([Preview](/products#product-launch-stages)) as the\nConfidential Computing technology. See\n[Supported configurations](/confidential-computing/confidential-vm/docs/supported-configurations) to learn\nabout hardware configuration options, and what locations Confidential VM instances\ncan be created in.\n\nWhat's next\n-----------\n\n- Learn more about\n [Confidential Space images](/confidential-computing/confidential-space/docs/confidential-space-images).\n\n- [Create your first Confidential Space environment](/confidential-computing/confidential-space/docs/create-your-first-confidential-space-environment)."]]
