Banyak organisasi men-deploy cloud data warehouse untuk menyimpan informasi sensitif, sehingga mereka dapat menganalisis data untuk berbagai tujuan bisnis. Dokumen ini menjelaskan cara menerapkan Framework Kontrol Utama Kemampuan Pengelolaan Data Cloud (CDMC), yang dikelola oleh Enterprise Data Management Council, dalam data warehouse BigQuery.
Framework Kontrol Utama CDMC sudah dipublikasikan terutama untuk penyedia layanan dan penyedia teknologi cloud. Framework ini menjelaskan 14 kontrol utama yang dapat diterapkan penyedia agar pelanggan dapat mengelola dan mengatur data sensitif di cloud secara efektif. Kontrol tersebut ditulis oleh CDMC Working Group, dengan lebih dari 300 profesional yang berpartisipasi dari lebih dari 100 perusahaan. Saat menulis framework, CDMC Working Group mempertimbangkan banyak persyaratan hukum dan peraturan yang ada.
Arsitektur referensi BigQuery dan Data Catalog ini sudah dinilai dan dan disertifikasi berdasarkan Framework Kontrol Kunci CDMC sebagai Solusi Cloud Tersertifikasi CDMC. Arsitektur referensi menggunakan berbagai layanan dan fitur Google Cloud serta library publik untuk menerapkan kontrol utama CDMC dan otomatisasi yang direkomendasikan. Dokumentasi ini menjelaskan cara Anda dapat menerapkan kontrol utama untuk membantu melindungi data sensitif dalam data warehouse BigQuery.
Microservice
Arsitektur referensi Google Cloud berikut ini selaras dengan Spesifikasi Uji Framework Kontrol Utama v1.1.1. Angka-angka pada diagram menunjukkan kontrol utama yang ditangani dengan layanan Google Cloud.
Arsitektur referensi dibangun berdasarkan blueprint data warehouse yang aman, yang menyediakan arsitektur yang membantu Anda melindungi data warehouse BigQuery mencakup informasi sensitif. Pada diagram sebelumnya, Project di bagian atas diagram (berwarna abu-abu) adalah bagian blueprint data warehouse yang aman, dan project tata kelola data (berwarna biru) mencakup layanan yang ditambahkan untuk memenuhi persyaratan Framework Kontrol Utama CDMC. Untuk menerapkan Framework Kontrol Utama CDMC, arsitektur memperluas project Tata kelola data. Project Tata kelola data menyediakan kontrol seperti klasifikasi, pengelolaan siklus proses, dan pengelolaan kelayakan data. Project ini juga menyediakan cara mengaudit arsitektur dan melaporkan temuannya.
Untuk informasi selengkapnya tentang cara menerapkan arsitektur referensi ini, lihat Arsitektur Referensi CDMC Google Cloud di GitHub.
Ringkasan Framework Kontrol Kunci CDMC
Tabel berikut merangkum Framework Kontrol Utama CDMC.
| # | Kontrol utama CDMC | Persyaratan kontrol CDMC |
|---|---|---|
| 1 | Kepatuhan kontrol data | Kasus bisnis pengelolaan data cloud yang ditetapkan dan diatur. Semua aset data yang berisi data sensitif harus dipantau kepatuhannya dengan Kontrol Utama CDMC, menggunakan metrik dan notifikasi otomatis. |
| 2 | Kepemilikan data ditetapkan untuk data yang dimigrasikan dan yang dihasilkan cloud | Kolom Kepemilikan dalam data catalog harus diisi untuk semua data sensitif atau dilaporkan ke workload yang ditentukan. |
| 3 | Sumber data dan konsumsi yang diatur dan didukung otomatis | Daftar sumber data dan titik penyedia resmi harus diisi untuk semua aset data yang berisi data sensitif atau harus dilaporkan ke workload yang ditentukan. |
| 4 | Kedaulatan data dan pergerakan data lintas batas dikelola | Kedaulatan data dan pergerakan lintas batas data sensitif harus dicatat, diaudit, dan dikontrol sesuai dengan kebijakan yang diterapkan. |
| 5 | Katalog data diterapkan, digunakan, dan dapat dioperasikan | Katalog harus diotomatiskan untuk semua data pada saat pembuatan atau penyerapan, dengan konsistensi di semua lingkungan. |
| 6 | Klasifikasi data ditetapkan dan digunakan | Klasifikasi harus bersifat otomatis untuk semua data pada saat
pembuatan atau penyerapan, dan harus selalu aktif. Klasifikasi bersifat
otomatis untuk hal berikut:
|
| 7 | Hak kepemilikan data dikelola, diterapkan, dan dilacak | Kontrol ini memerlukan hal berikut:
|
| 8 | Akses, penggunaan, dan hasil data yang etis dikelola | Tujuan konsumsi data harus disediakan untuk semua perjanjian berbagi data yang melibatkan data sensitif. Tujuannya harus menentukan jenis data yang diperlukan dan, untuk organisasi global, cakupan entitas hukum dan negara |
| 9 | Data diamankan dan kontrol dibuktikan | Kontrol ini memerlukan hal berikut:
|
| 10 | Framework privacy data yang ditetapkan dan beroperasi | Penilaian dampak perlindungan data (DPIA) harus dipicu secara otomatis untuk semua data pribadi sesuai dengan wilayah hukumnya. |
| 11 | Siklus proses data direncanakan dan dikelola | Retensi, pengarsipan, dan penghapusan permanen data harus dikelola sesuai dengan jadwal retensi yang ditentukan. |
| 12 | Kualitas data dikelola | Pengukuran kualitas data harus diaktifkan untuk data sensitif dengan metrik yang didistribusikan jika tersedia. |
| 13 | Prinsip pengelolaan biaya ditetapkan dan diterapkan | Prinsip desain teknis ditetapkan dan diterapkan. Metrik biaya yang terhubung dengan penggunaan, penyimpanan, dan perpindahan data secara langsung harus tersedia di katalog. |
| 14 | Asal dan silsilah data dipahami | Informasi silsilah data harus tersedia untuk semua data sensitif. Informasi ini harus setidaknya menyertakan sumber tempat data diserap atau dibuat di lingkungan cloud. |
1. Kepatuhan kontrol data
Kontrol ini mengharuskan Anda memverifikasi bahwa semua data sensitif dipantau untuk kepatuhan terhadap framework ini menggunakan metrik.
Arsitek ini menggunakan metrik yang menunjukkan sejauh mana setiap kontrol utama beroperasi. Arsitektur ini juga menunjukkan dasbor yang menunjukkan ketika metrik tidak memenuhi nilai minimum yang ditentukan.
Arsitektur mencakup pendeteksi yang memublikasikan temuan dan rekomendasi perbaikan saat aset data tidak memenuhi kontrol utama. Temuan dan rekomendasi ini memiliki format JSON dan dipublikasikan ke topik Pub/Sub untuk didistribusikan ke pelanggan. Anda dapat mengintegrasikan alat pengelolaan atau desktop layanan internal dengan topik Pub/Sub sehingga insiden dibuat secara otomatis di sistem tiket Anda.
Arsitektur ini menggunakan Dataflow untuk membuat pelanggan contoh ke peristiwa temuan, yang kemudian disimpan di instance BigQuery yang berjalan di project Tata Kelola Data. Menggunakan sejumlah tampilan yang disediakan, Anda dapat men-kueri data menggunakan BigQuery Studio di konsol Google Cloud. Anda juga dapat membuat laporan menggunakan Looker Studio atau alat business intelligence yang kompatibel dengan BigQuery lainnya. Laporan yang dapat Anda lihat mencakup hal berikut:
- Ringkasan temuan yang terakhir dijalankan
- Detail temuan yang terakhir dijalankan
- Metadata yang terakhir dijalankan
- Aset data yang terakhir dijalankan dalam cakupan
- Statistik set data yang terakhir dijalankan
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Pub/Sub memublikasikan temuan.
- Dataflow memuat temuan ke instance BigQuery.
- BigQuery menyimpan data temuan dan menyediakan tampilan ringkasan.
- Looker Studio menyediakan dasbor dan laporan.
Screenshot berikut menunjukkan contoh dasbor ringkasan Looker Studio.
Screenshot berikut menunjukkan tampilan contoh temuan menurut aset data.
2. Kepemilikan data ditetapkan untuk data yang dimigrasikan dan yang dihasilkan cloud
Untuk memenuhi persyaratan kontrol ini, arsitektur secara otomatis meninjau data di data warehouse BigQuery dan menambahkan tag klasifikasi data yang menunjukkan bahwa pemilik teridentifikasi untuk semua data sensitif.
Data Catalog, yang merupakan fitur Dataplex, menangani dua jenis metadata, metadata teknik dan metadata bisnis. Untuk project tertentu, Data Catalog secara otomatis membuat katalog set data, tabel, dan tampilan BigQuery, serta mengisi metadata teknis. Sinkronisasi antara katalog dan aset data ditangani mendekati real-time.
Arsitektur ini menggunakan Tag Engine untuk menambahkan tag metadata bisnis berikut ke
template tag CDMC controls di Data Catalog:
is_sensitive: apakah aset data berisi data sensitif (lihat) Kontrol 6 untuk klasifikasi data)owner_name: pemilik dataowner_email: alamat email pemilik
Tag yang diisi menggunakan default yang disimpan di tabel BigQuery referensi di project Tata kelola data.
Secara default, arsitektur menetapkan metadata kepemilikan pada tingkat tabel tetapi Anda dapat mengubah arsitektur sehingga metadata ditetapkan pada tingkat kolom. Untuk informasi lebih lanjut, lihat Tag Data Catalog dan template tag.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Dua data warehouse BigQuery: satu penyimpanan data rahasia dan satu penyimpanan default untuk kepemilikan aset data.
- Data Catalog menyiapkan metadata kepemilikan melalui template dan tag.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, memberi tag pada data di data warehouse yang aman.
- Pub/Sub memublikasikan temuan.
Untuk mendeteksi masalah yang terkait dengan kontrol ini, arsitektur akan memeriksa apakah data sensitif diberi tag nama pemilik.
3. Sumber dan konsumsi data diatur dan didukung oleh otomatisasi
Kontrol ini memerlukan klasifikasi aset data dan register
data dari sumber otoritatif dan distributor resmi. Arsitektur ini menggunakan
Data Catalog untuk menambahkan tag is_authoritative ke template tag CDMC
controls. Tag ini menentukan apakah aset data bersifat otoritatif.
Data Catalog menyusun katalog set data, tabel
dan tampilan BigQuery dengan metadata teknis dan metadata bisnis. Metadata teknis
diisi secara otomatis dan menyertakan URL resource, yang merupakan lokasi
titik penyediaan, Metadata bisnis yang ditentukan pada file konfigurasi
Tag Engine dan menyertakan tag is_authoritative.
Selama operasi terjadwal berikutnya, Tag Engin akan mengisi tagis_authoritative
pada template tag CDMC controls dari nilai default yang disimpan dalam tabel referensi
di BigQuery.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Dua data warehouse BigQuery: satu menyimpan data rahasia dan lainnya menyimpan resource otoritatif aset data secara default.
- Data Catalog menyimpan set data sumber otoritatif dalam tag.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
- Pub/Sub memublikasikan temuan.
Untuk mendeteksi masalah yang terkait dengan kontrol ini, arsitektur akan memeriksa apakah data sensitif diberi tag sumber otoritatif.
4. Kedaulatan data dan pergerakan data lintas batas dikelola
Kontrol ini memerlukan arsitektur untuk memeriksa registry data guna mengetahui persyaratan penyimpanan khusus region dan menerapkan aturan penggunaan. Laporan menjelaskan lokasi geografis dari aset data.
Arsitektur ini menggunakan Data Catalog untuk menambahkan
approved_storage_location tag ke template tag CDMC controls. Tag ini
menunjukkan lokasi geografis yang diizinkan untuk menyimpan
aset data.
Lokasi data sebenarnya disimpan sebagai metadata teknis dalam detail tabel BigQuery. BigQuery tidak memungkinkan administrator mengubah lokasi set data atau tabel. Sebaliknya, jika administrator ingin mengubah lokasi data, mereka harus menyalin set data.
Batasan Layanan Kebijakan Organisasi lokasi resource
menentukan region Google Cloud tempat Anda dapat menyimpan data. Secara default,
arsitektur menetapkan batasan pada project data Confidential, tetapi Anda
dapat menetapkan batasan di tingkat organisasi atau folder jika diinginkan. Tag
Engine mereplikasi lokasi yang diizinkan ke template tag Data Catalog
dan menyimpan lokasi di tag approved_storage_location. Jika Anda
mengaktifkan tingkat Security Command Center Premium, dan seseorang mengupdate lokasi resource
batasan Layanan Kebijakan Organisasi, Security Command Center menghasilkan
temuan kerentanan
untuk resource yang disimpan di luar kebijakan yang sudah diupdate.
Access Context Manager memerlukan lokasi geografis tempat pengguna harus berada sebelum mereka dapat mengakses aset data. Menggunakan tingkat askes, Anda dapat menentukan regions mana permintaan dapat berasal. Kemudian, tambahkan kebijakan akses ke perimeter Kontrol Layanan VPC untuk project data Rahasia.
Untuk melacak perpindahan data, BigQuery mempertahankan jejak audit lengkap untuk setiap job dan kueri terhadap setiap set data. Jejak audit disimpan di tampilan Tugas Skema Informasi BigQuery.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Layanan Kebijakan Organisasi menentukan dan memberlakukan batasan lokasi resource.
- Access Context Manager menentukan lokasi tempat pengguna dapat mengakses data.
- Dua data warehouse BigQuery: satu menyimpan data rahasia dan lainnya menghosting fungsi jarak jauh yang digunakan untuk memeriksa kebijakan lokasi.
- Data Catalog penyimpanan lokasi penyimpanan yang disetujui sebagai tag.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
- Pub/Sub memublikasikan temuan.
- Cloud Logging menulis log audit.
- Security Command Center melaporkan semua temuan yang terkait dengan lokasi resource atau akses data.
Untuk mendeteksi masalah yang terkait dengan kontrol ini, arsitektur menyertakan temuan jika tag lokasi yang disetujui menyertakan lokasi data sensitif.
5. Katalog data diterapkan, digunakan, dan dapat dioperasikan
Kontrol ini memerlukan katalog data agar tersedia, serta arsitektur dapat memindai aset yang baru dan yang diupdate untuk menambahkan metadata sesuai kebutuhan.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan Data Catalog. Secara otomatis, Data Catalog mencatat aset Google Cloud, termasuk set data, tabel, dan tabel virtual BigQuery. Saat Anda membuat tabel baru di BigQuery, Data Catalog mendaftarkan skema dan metadata tabel baru secara otomatis. Saat Anda mengupdate tabel di BigQuery, Data Catalog mengupdate entrinya nyaris secara instan.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Dua data warehouse BigQuery: satu data warehouse menyimpan data rahasia, satunya lagi menyimpan data tidak rahasia.
- Data Catalog menyimpan metadata teknis untuk tabel dan kolom.
Secara default, Data Catalog menyimpan metadata teknis dari BigQuery dalam arsitektur ini. Jika diperlukan, Anda dapat mengintegrasikan Data Catalog dengan sumber data lain.
6. Klasifikasi data ditetapkan dan digunakan
Penilaian ini memerlukan data agar dapat ditetapkan berdasarkan sensitivitasnya, seperti jika data tersebut merupakan PII, mengidentifikasikan klien, atau memenuhi beberapa standar lain yang ditetapkan oleh organisasi Anda. Untuk memenuhi persyaratan kontrol ini, arsitektur membuat laporan aset data dan sensitivitasnya. Anda dapat menggunakan laporan ini untuk memastikan jika setelan sensitivitas sudah benar. Selain itu, setiap aset data yang baru atau perubahan pada data yang ada akan menghasilkan update pada katalog data.
Klasifikasi data disimpan dalam tag sensitive_category di
template tag Data Catalog pada tingkat tabel dan kolom. Tabel
referensi klasifikasi memungkinkan Anda untuk menentukan peringkat jenis informasi
(infoType) Sensitive Data Protection
yang tersedia, dengan peringkat yang lebih tinggi untuk konten yang lebih sensitif.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan Sensitive Data Protection, Data Catalog, dan Tag Engine untuk menambahkan tag berikut ke kolom sensitif di tabel BigQuery:
is_sensitive: jika aset data memiliki informasi sensitifsensitive_category: kategori data. Kategori ini mencakup salah satu dari:- Informasi Identitas Pribadi yang Bersifat Sensitif
- Informasi Identitas Pribadi
- Informasi Pribadi yang Bersifat Sensitif
- Informasi Pribadi
- Informasi Publik
Anda dapat mengubah kategori Anda untuk memenuhi persyaratan. Misalnya, Anda dapat menambahkan klasifikasi Informasi Non-Publik Material (MNPI).
Setelah Sensitive Data Protection
memeriksa data,
Tag Engine akan membaca tabel DLP results per aset untuk mengompilasi temuannya. Jika
tabel berisi kolom dengan satu atau beberapa infoType sensitif, infoType yang
paling signifikan akan ditentukan. Kolom sensitif dan seluruh tabel akan
diberi tag sebagai kategori yang memiliki peringkat tertinggi. Tag Engine juga akan menetapkan
tag kebijakan
yang sesuai
ke kolom, lalu menetapkan tag boolean is_sensitive ke tabel.
Anda dapat menggunakan Cloud Scheduler untuk mengotomatiskan pemeriksaan Sensitive Data Protection.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Empat data warehouse BigQuery menyimpan informasi
berikut:
- Data rahasia
- Informasi hasil Sensitive Data Protection
- Data dari referensi klasifikasi data
- Informasi ekspor tag
- Data Catalog menyimpan tag klasifikasi.
- Sensitive Data Protection memeriksa aset untuk infoType sensitif.
- Compute Engine menjalankan skrip yang Memeriksa Set Data, serta yang memicu tugas Sensitive Data Protection untuk setiap set data BigQuery.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
- Pub/Sub memublikasikan temuan.
Untuk mendeteksi masalah yang terkait dengan kontrol ini, arsitektur mencantumkan temuan berikut:
- Jika data sensitif diberi tag kategori sensitif.
- Jika data sensitif diberi tag jenis sensitivitas tingkat kolom.
7. Hak kepemilikan data dikelola, diterapkan, dan dilacak
Secara default, hak dan askes ke data sensitif diberikan hanya kepada pembuat dan pemilik. Selain itu, kontrol ini memerlukan arsitektur untuk melacak semua akses ke data sensitif.
Untuk memenuhi persyaratan ke kontrol ini, arsitektur menggunakan taksonomi tag kebijakan cdmc
sensitive data classification di BigQuery untuk
mengontrol akses ke kolom yang berisi data rahasia dalam
tabel BigQuery. Taksonomi ini mencakup tag kebijakan
berikut:
- Informasi Identitas Pribadi yang Bersifat Sensitif
- Informasi Identitas Pribadi
- Informasi Pribadi yang Bersifat Sensitif
- Informasi Pribadi
Tag kebijakan memungkinkan Anda mengontrol siapa saja yang dapat melihat kolom sensitif dalam
tabel BigQuery. Arsitektur ini memetakan tag kebijakan ini ke
klasifikasi sensitivitas yang berasal dari infoType
Sensitive Data Protection. Misalnya, tag kebijakan
sensitive_personal_identifiable_information dan kategori sensitif dipetakan ke infoType seperti AGE, DATE_OF_BIRTH,
PHONE_NUMBER, dan EMAIL_ADDRESS.
Arsitektur ini menggunakan Identity and Access Management (IAM) untuk mengelola grup, pengguna, dan akun layanan yang memerlukan akses ke data. Izin IAM diberikan ke akses tertentu untuk akses tingkat tabel. Selain itu, akses tingkat kolom yang berdasarkan pada tag kebijakan memungkinkan akses terperinci ke aset data sensitif. Secara default, pengguna tidak memiliki akses ke kolom yang sudah menetapkan tag kebijakan.
Untuk membantu memastikan bahwa hanya pengguna yang diautentikasi yang dapat mengakses data, Google Cloud menggunakan Cloud Identity yang dapat digabungkan dengan penyedia identitas yang ada guna mengautentikasi pengguna.
Kontrol ini juga memerlukan arsitektur untuk melakukan pemeriksaan secara rutin pada aset data yang tidak memiliki hak yang ditetapkan. Pendeteksi yang dikelola oleh Cloud Scheduler memeriksa skenario berikut:
- Aset data mencakup kategori sensitif, tetapi tidak ada tag kebijakan yang terkait.
- Kategori tidak sesuai dengan tag kebijakan.
Saat skenario ini terjadi, pendeteksi menghasilkan temuan yang dipublikasikan
oleh Pub/Sub. Lalu, temuan ini ditulis ke tabel events di
BigQuery oleh Dataflow. Anda dapat menyebarkan
temuan tersebut ke alat perbaikan data, seperti yang dijelaskan dalam
1. Kepatuhan kontrol data.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Data warehouse BigQuery menyimpan data rahasia dan binding tag kebijakan untuk kontrol akses terperinci.
- IAM mengelola akses.
- Data Catalog menyimpan tag tingkat tabel dan kolom untuk kategori sensitif.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
Untuk mendeteksi masalah terkait kontrol ini, arsitektur akan memeriksa jika data sensitif memiliki tag kebijakan yang sesuai.
8. Akses, penggunaan, dan hasil data yang etis dikelola
Kontrol ini memerlukan arsitektur untuk menyimpan persetujuan berbagi data dari
penyedia data dan konsumen data, termasuk daftar tujuan
konsumsi data yang disetujui. Tujuan konsumsi data sensitif akan
dipetakan ke hak yang disimpan di BigQuery menggunakan
label kueri.
Saat konsumen membuat kueri data sensitif di BigQuery, konsumen
menentukan tujuan valid yang sesuai dengan hak mereka (misalnya, SET @@query_label = “use:3”;).
Arsitektur ini menggunakan Data Catalog untuk menambahkan tag berikut
pada template tag CDMC controls. Tag ini mewakili perjanjian berbagi
data dengan penyedia data:
approved_use: penggunaan atau pengguna aset data yang disetujuisharing_scope_geography: daftar lokasi geografis tempat aset data dapat dibagikansharing_scope_legal_entity: daftar entity yang disetujui yang dapat berbagi aset data
Data warehouse BigQuery yang terpisah mencakup
set data entitlement_management dengan tabel berikut:
provider_agreement: perjanjian berbagi data dengan penyedia data, termasuk entitas hukum dan cakupan geografis yang sudah disepakati. Data ini merupakan default untuk tagshared_scope_geographydansharing_scope_legal_entity.consumer_agreement: perjanjian berbagai data dengan konsumen data, termasuk entitas hukum dan cakupan geografis yang sudah disetujui. Setiap perjanjian dikaitkan dengan binding IAM untuk aset data.use_purpose: tujuan konsumsi data, seperti deskripsi penggunaan dan operasi yang diizinkan untuk aset datadata_asset: informasi tentang aset data, seperti nama aset dan detail mengenai pemilik data.
Untuk mengaudit perjanjian berbagi data, BigQuery mempertahankan jejak audit lengkap untuk setiap tugas dan kueri terhadap setiap set data. Jejak audit disimpan di tampilan Tugas Skema Informasi BigQuery. Setelah mengaitkan label kueri dengan sesi dan menjalankan kueri di dalam sesi tersebut, Anda dapat mengumpulkan log audit untuk kueri dengan label kueri tersebut. Untuk informasi selengkapnya, lihat Referensi log audit untuk BigQuery.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Dua data warehouse BigQuery: satu data warehouse menyimpan data rahasia, satunya lagi menyimpan data hak kepemilikan yang mencakup perjanjian berbagi data penyedia dan konsumen, serta tujuan penggunaan yang disetujui.
- Data Catalog menyimpan informasi perjanjian berbagi data penyedia sebagai tag.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
- Pub/Sub memublikasikan temuan.
Untuk mendeteksi masalah yang terkait dengan kontrol ini, arsitektur mencantumkan temuan berikut:
- Jika ada entri untuk aset data dalam
set data
entitlement_management. - Jika operasi dijalankan pada tabel sensitif dengan kasus penggunaan
yang sudah tidak berlaku (misalnya,
valid_until_datedalamconsumer_agreement tablesudah terlewati). - Jika operasi dijalankan pada tabel sensitif dengan kunci label yang salah.
- Jika operasi dijalankan pada tabel sensitif dengan nilai label kasus penggunaan yang kosong atau tidak disetujui.
- Jika tabel sensitif dikueri dengan metode operasi yang tidak disetujui
(misalnya,
SELECTatauINSERT). - Jika tujuan yang dicatat dan ditentukan konsumen saat membuat kueri data sensitif sesuai dengan perjanjian berbagi data.
9. Data diamankan dan kontrol dibuktikan
Kontrol ini memerlukan penerapan enkripsi dan de-identifikasi data untuk membantu melindungi data sensitif dan memberikan catatan mengenai kontrol ini.
Arsitektur ini dibangun berdasarkan keamanan default Google yang mencakup enkripsi dalam penyimpanan. Selain itu, arsitektur ini memungkinkan Anda untuk mengelola kunci Anda sendiri menggunakan kunci enkripsi yang dikelola pelanggan (CMEK). Cloud KMS memungkinkan Anda untuk mengenkripsi data dengan kunci enkripsi yang didukung software atau modul keamanan hardware (HSM) yang divalidasi FIPS 140-2 Level 3.
Arsitektur ini menggunakan dynamic data masking tingkat kolom yang dikonfigurasi melalui tag kebijakan, serta menyimpan data rahasia dalam perimeter Kontrol Layanan VPC yang terpisah. Anda juga dapat menambahkan de-identifikasi tingkat aplikasi yang dapat diterapkan, baik secara lokal maupun sebagai bagian dari pipeline penyerapan data.
Secara default, arsitektur menerapkan enkripsi CMEK dengan HSM. Namun, arsitektur tersebut juga mendukung Cloud External Key Manager (Cloud EKM).
Tabel berikut menjelaskan contoh kebijakan keamanan yang diterapkan arsitektur untuk region us-central1. Anda dapat menyesuaikan kebijakan untuk memenuhi persyaratan, termasuk dengan menambahkan kebijakan yang berbeda untuk region yang berbeda.
| Sensitivitas data | Metode enkripsi default | Metode enkripsi lain yang diizinkan | Metode de-identifikasi default | Metode de-identifikasi lain yang diizinkan |
|---|---|---|---|---|
| Informasi Publik | Enkripsi Default | Any | Tidak ada | Any |
| Informasi Identitas Pribadi yang Bersifat Sensitif | CMEK dengan HSM | EKM | Nullify | Hash SHA-256 atau Nilai Penyamaran Default |
| Informasi Identitas Pribadi | CMEK dengan HSM | EKM | Hash SHA-256 | Nullify atau Nilai Penyamaran Default |
| Informasi Pribadi yang Bersifat Sensitif | CMEK dengan HSM | EKM | Nilai Penyamaran Default | Hash SHA-256 atau Nullify |
| Informasi Pribadi | CMEK dengan HSM | EKM | Nilai Penyamaran Default | Hash SHA-256 atau Nullify |
Arsitektur ini menggunakan Data Catalog untuk menambahkan tag
encryption_method ke template tag CDMC controls tingkat tabel. encryption_method
menetapkan metode enkripsi yang digunakan oleh aset data.
Selain itu, arsitektur ini membuat tag security policy template untuk
mengidentifikasi metode de-identifikasi yang diterapkan ke kolom tertentu. Arsitektur
ini menggunakan platform_deid_method yang diterapkan menggunakan dynamic
data masking. Anda dapat menambahkan app_deid_method dan mengisinya menggunakan
pipeline penyerapan data Dataflow dan Sensitive Data Protection yang disertakan dalam
blueprint data warehouse yang aman.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Dua instance Dataflow yang bersifat opsional. Satu instance menjalankan de-identifikasi tingkat aplikasi, instance lain melakukan identifikasi ulang.
- Tiga data warehouse BigQuery: satu data warehouse menyimpan data rahasia, satunya lagi menyimpan data tidak rahasia, sedangkan yang ketiga menyimpan kebijakan keamanan.
- Data Catalog menyimpan template tag enkripsi dan de-identifikasi.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
- Temuan yang dipublikasikan Pub/Sub.
Untuk mendeteksi masalah yang terkait dengan kontrol ini, arsitektur mencantumkan temuan berikut:
- Nilai tag metode enkripsi tidak sesuai dengan metode enkripsi yang diizinkan untuk sensitivitas dan lokasi yang ditetapkan.
- Tabel berisi kolom sensitif, tetapi tag Template Kebijakan Keamanan berisi metode de-identifikasi tingkat platform yang tidak valid.
- Tabel berisi kolom sensitif, tetapi tag Template Kebijakan Keamanan tidak ditemukan.
10. Framework privacy data yang ditetapkan dan beroperasi
Kontrol ini memerlukan arsitektur agar memeriksa katalog dan klasifikasi data untuk menentukan pembuatan laporan penilaian dampak perlindungan data (DPIA) atau laporan penilaian dampak privasi (PIA). Penilaian privasi memiliki variasi yang signifikan antara wilayah geografis dan pembuat peraturan. Untuk menentukan jika penilaian dampak diperlukan, arsitektur harus mempertimbangkan residensi data dan residensi subjek data.
Arsitektur ini menggunakan Data Catalog untuk menambahkan tag berikut ke
template tag Impact assessment:
subject_locations: lokasi subjek yang dirujuk oleh data dalam aset ini.is_dpia: jika penilaian dampak privasi data (DPIA) untuk aset ini sudah selesai.is_pia: jika penilaian dampak privasi (PIA) untuk aset ini sudah selesai.impact_assessment_reports: link eksternal ke tempat laporan penilaian dampak disimpan.most_recent_assessment: tanggal penilaian dampak terbaru.oldest_assessment: tanggal penilaian dampak pertama.
Tag Engine menambahkan tag ini ke setiap aset data sensitif, seperti yang sudah ditetapkan oleh kontrol 6. Pendeteksi memvalidasi tag tersebut terhadap tabel kebijakan di BigQuery, meliputi kombinasi valid dari residensi data, lokasi subjek, sensitivitas data (misalnya, jika data tersebut merupakan PII), serta jenis penilaian dampak (baik PIA atau DPIA) yang diperlukan.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Empat data warehouse BigQuery menyimpan informasi
berikut:
- Data rahasia
- Data tidak rahasia
- Kebijakan penilaian dampak dan stempel waktu hak kepemilikan
- Ekspor tag yang digunakan untuk dasbor
- Data Catalog menyimpan detail penilaian dampak dalam template tag.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
- Pub/Sub memublikasikan temuan.
Untuk mendeteksi masalah yang terkait dengan kontrol ini, arsitektur mencantumkan temuan berikut:
- Data sensitif tersedia tanpa template penilaian dampak.
- Data sensitif tersedia tanpa link ke laporan DPIA atau PIA.
- Tag tidak memenuhi persyaratan dalam tabel kebijakan.
- Penilaian dampak ini lebih lama dari hak yang terakhir disetujui untuk aset data dalam tabel perjanjian konsumen.
11. Siklus proses data direncanakan dan dikelola
Kontrol ini memerlukan kemampuan untuk memeriksa semua aset data guna menentukan jika kebijakan siklus proses data ada dan sudah dipatuhi.
Arsitektur ini menggunakan Data Catalog untuk menambahkan tag berikut ke
template tag CDMC controls:
retention_period: waktu, dalam hari, untuk menyimpan tabelexpiration_action: untuk mengarsipkan atau menghapus permanen tabel saat periode retensi data berakhir
Secara default, arsitektur menggunakan periode retensi data dan tindakan saat masa berlaku berakhir berikut:
| Kategori data | Periode retensi data, dalam hari | Tindakan saat masa berlaku berakhir |
|---|---|---|
| Informasi Identitas Pribadi yang Bersifat Sensitif | 60 | Hapus |
| Informasi Identitas Pribadi | 90 | Arsip |
| Informasi Pribadi yang Bersifat Sensitif | 180 | Arsip |
| Informasi pribadi | 180 | Arsip |
Record Manager, aset open source untuk BigQuery, mengotomatiskan penghapusan permanen dan pengarsipan dari tabel BigQuery berdasarkan nilai tag di atas dan file konfigurasi. Prosedur penghapusan permanen menetapkan tanggal berakhirnya masa berlaku tabel dan membuat tabel snapshot dengan waktu berakhirnya masa berlaku yang ditetapkan dalam konfigurasi Record Manager. Secara default, waktu berakhirnya masa berlaku adalah 30 hari. Selama periode penghapusan sementara, Anda dapat memulihkan kembali tabel tersebut. Prosedur pengarsipan membuat tabel eksternal untuk setiap tabel BigQuery yang melewati periode retensi data. Tabel tersebut disimpan di Cloud Storage dalam format parquet dan diupgrade ke tabel BigLake yang memungkinkan file eksternal diberi tag dengan metadata di Data Catalog.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Dua data warehouse BigQuery: satu data warehouse menyimpan data rahasia, satunya lagi menyimpan kebijakan retensi data.
- Dua instance Cloud Storage instances. Satu instance menyediakan penyimpanan arsip, instance lain menyimpan kumpulan data.
- Data Catalog menyimpan periode retensi data, serta tindakan dalam template tag dan tag tersebut.
- Dua instance Cloud Run instances. Satu instance menjalankan Record Manager, instance lain men-deploy pendeteksi.
- Tiga instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
- Instance lain menjalankan Record Manager yang mengotomatiskan penghapusan permanen dan pengarsipan tabel BigQuery.
- Pub/Sub memublikasikan temuan.
Untuk mendeteksi masalah yang terkait dengan kontrol ini, arsitektur mencantumkan temuan berikut:
- Untuk aset sensitif, pastikan metode retensi sesuai dengan kebijakan untuk lokasi aset.
- Untuk aset sensitif, pastikan periode retensi data sesuai dengan kebijakan untuk lokasi aset.
12. Kualitas data dikelola
Kontrol ini memerlukan kemampuan dalam mengukur kualitas data berdasarkan pembuatan profil data atau metrik yang ditentukan pengguna.
Arsitektur ini mencakup kemampuan untuk menentukan aturan kualitas data untuk nilai individual atau gabungan dan menetapkan nilai minimum ke kolom tabel tertentu. Ini mencakup template tag untuk ketepatan dan kelengkapan. Data Catalog menambahkan tag berikut ke setiap template tag:
column_name: nama kolom tempat metrik diterapkanmetric: nama metrik atau aturan kualitasrows_validated: jumlah baris yang divalidasisuccess_percentage: persentase nilai yang memenuhi metrik iniacceptable_threshold: nilai minimum yang dapat diterima untuk metrik inimeets_threshold: apakah skor kualitas (nilaisuccess_percentage) memenuhi nilai minimum yang dapat diterimamost_recent_run: waktu terakhir kali metrik atau aturan kualitas dijalankan
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Tiga data warehouse BigQuery: pertama menyimpan data sensitif, kedua menyimpan data non-sensitif, dan ketiga menyimpan metrik aturan kualitas.
- Data Catalog menyimpan hasil kualitas data dalam template tag dan tag.
- Cloud Scheduler menentukan kapan Cloud Data Quality Engine berjalan.
- Tiga instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
- Ketiga, instance yang menjalankan Cloud Data Quality Engine.
- Cloud Data Quality Engine menentukan aturan kualitas data dan menjadwalkan pemeriksaan kualitas data untuk tabel dan kolom.
- Pub/Sub memublikasikan temuan.
Dasbor Looker Studio menampilkan laporan kualitas data untuk tingkat tabel dan tingkat kolom.
Untuk mendeteksi masalah yang terkait dengan kontrol ini, arsitektur mencantumkan temuan berikut:
- Data bersifat sensitif, tetapi tidak ada template tag kualitas data yang diterapkan (ketepatan dan kelengkapan).
- Data bersifat sensitif, tetapi tag kualitas data tidak diterapkan pada kolom sensitif.
- Data bersifat sensitif, tetapi hasil kualitas data tidak berada dalam nilai minimum yang ditetapkan dalam aturan.
- Data tidak bersifat sensitif dan hasil kualitas data tidak berada dalam nilai minimum yang ditetapkan oleh aturan.
Sebagai alternatif untuk Cloud Data Quality Engine, Anda dapat mengonfigurasi tugas kualitas data Dataplex.
13. Prinsip pengelolaan biaya ditetapkan dan diterapkan
Kontrol ini memerlukan kemampuan untuk memeriksa aset data untuk mengonfirmasi penggunaan biaya, berdasarkan persyaratan kebijakan dan arsitektur data. Metrik biaya harus komprehensif dan tidak hanya terbatas pada penggunaan penyimpanan dan pergerakannya.
Arsitektur ini menggunakan Data Catalog untuk menambahkan tag berikut
cost_metrics ke template tag:
total_query_bytes_billed: jumlah total byte kueri yang ditagih untuk aset data ini sejak awal bulan ini.total_storage_bytes_billed: jumlah total byte penyimpanan yang ditagih untuk aset data ini sejak awal bulan ini.total_bytes_transferred: jumlah byte yang ditransfer lintas region dalam aset data ini.estimated_query_cost: perkiraan biaya kueri, dalam dolar AS, untuk set data untuk bulan ini.estimated_storage_cost: perkiraan biaya penyimpanan, dalam dolar AS, untuk aset data untuk bulan ini.estimated_egress_cost: perkiraan traffic keluar dalam dolar AS untuk bulan ini saat aset data digunakan sebagai tabel tujuan.
Arsitektur ini mengekspor informasi harga dari Penagihan Cloud ke
tabel BigQuery yang bernama cloud_pricing_export.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Penagihan Cloud menyediakan informasi penagihan.
- Data Catalog menyimpan informasi biaya dalam template tag dan tag.
- BigQuery menyimpan informasi harga yang diekspor dan informasi tugas historis kueri melalui tampilan INFORMATION_SCHEMA bawaan.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
- Pub/Sub memublikasikan temuan.
Untuk mendeteksi masalah yang terkait dengan kontrol ini, arsitektur akan memeriksa apakah terdapat aset data sensitif tanpa berkaitan dengan metrik biaya.
14. Asal dan silsilah data dipahami
Kontrol ini memerlukan kemampuan untuk memeriksa penelusuran aset data dari sumbernya dan setiap perubahan pada silsilah aset data.
Untuk mempertahankan informasi tentang asal dan silsilah data, arsitektur ini menggunakan fitur Data Lineage bawaan di Data Catalog. Selain itu, skrip penyerapan data menentukan sumber akhir dan menambahkan sumber sebagai node tambahan ke grafik silsilah data.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan
Data Catalog untuk menambahkan tag ultimate_source ke template tag CDMC
controls. Tag ultimate_source menentukan sumber
untuk aset data ini.
Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Dua data warehouse BigQuery: yang pertama menyimpan data rahasia, dan yang kedua menyimpan data sumber akhir.
- Data Catalog menyimpan sumber akhir dalam template tag dan tag.
- Skrip penyerapan data memuat data dari Cloud Storage, yang menentukan sumber akhir, dan menambahkan sumber ke grafik silsilah data
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa jika tag diterapkan dan memublikasikan hasilnya.
- Kedua, instance yang menjalankan Tag Engine. Instance ini memberi tag pada data di data warehouse yang aman.
- Pub/Sub memublikasikan temuan.
Untuk mendeteksi masalah yang berkaitan dengan kontrol ini, arsitektur akan menyertakan pemeriksaan berikut:
- Data sensitif diidentifikasi tanpa tag sumber akhir.
- Grafik silsilah tidak diisi untuk aset data sensitif.
Tag reference
Bagian ini menjelaskan template tag dan tag yang digunakan arsitektur ini untuk memenuhi persyaratan kontrol kunci CDMC.
Template tag kontrol CDMC level tabel
Tabel berikut mencantumkan tag yang merupakan bagian dari template tag kontrol CDMC dan yang diterapkan pada tabel.
| Tag | ID Tag | Kontrol kunci yang berlaku |
|---|---|---|
| Lokasi Penyimpanan yang Disetujui | approved_storage_location |
4 |
| Penggunaan yang Disetujui | approved_use |
8 |
| Email Pemilik Data | data_owner_email |
2 |
| Nama Pemilik Data | data_owner_name |
2 |
| Metode enkripsi | encryption_method |
9 |
| Tindakan Saat Masa Berlaku Berakhir | expiration_action |
11 |
| Otoritatif | is_authoritative |
3 |
| Sensitif | is_sensitive |
6 |
| Kategori Sensitif | sensitive_category |
6 |
| Geografi Cakupan Berbagi | sharing_scope_geography |
8 |
| Entitas Hukum Cakupan Berbagi | sharing_scope_legal_entity |
8 |
| Periode Retensi Data | retention_period |
11 |
| Sumber Utama | ultimate_source |
14 |
Template tag Penilaian Dampak
Tabel berikut mencantumkan tag yang merupakan bagian dari template tag Penilaian Dampak dan yang diterapkan pada tabel.
| Tag | ID Tag | Kontrol kunci yang berlaku |
|---|---|---|
| Lokasi Subjek | subject_locations |
10 |
| Penilaian dampak DPIA | is_dpia |
10 |
| Penilaian dampak PIA | is_pia |
10 |
| Laporan penilaian dampak | impact_assessment_reports |
10 |
| Penilaian dampak terbaru | most_recent_assessment |
10 |
| Penilaian dampak terlama | oldest_assessment |
10 |
Template tag Metrik Biaya
Tabel berikut mencantumkan tag yang merupakan bagian dari template tag Metrik Biaya dan yang diterapkan pada tabel.
| Tag | Tab ID | Kontrol kunci yang berlaku |
|---|---|---|
| Perkiraan Biaya Kueri | estimated_query_cost |
13 |
| Perkiraan Biaya Penyimpanan | estimated_storage_cost |
13 |
| Perkiraan Biaya Traffic Keluar | estimated_egress_cost |
13 |
| Total Byte Kueri yang Ditagih | total_query_bytes_billed |
13 |
| Total Byte Penyimpanan yang Ditagih | total_storage_bytes_billed |
13 |
| Total Byte yang Ditransfer | total_bytes_transferred |
13 |
Template tag Sensitivitas Data
Tabel berikut mencantumkan tag yang merupakan bagian dari template tag Sensitivitas Data dan yang diterapkan pada kolom.
| Tag | ID Tag | Kontrol kunci yang berlaku |
|---|---|---|
| Bidang Sensitif | sensitive_field |
6 |
| Jenis Sensitif | sensitive_category |
6 |
Template tag Kebijakan Keamanan
Tabel berikut mencantumkan tag yang merupakan bagian dari template tag Kebijakan Keamanan dan yang diterapkan pada kolom.
| Tag | ID Tag | Kontrol kunci yang berlaku |
|---|---|---|
| Metode De-Identifikasi Aplikasi | app_deid_method |
9 |
| Metode De-Identifikasi Platform | platform_deid_method |
9 |
Template tag Kualitas Data
Tabel berikut mencantumkan tag yang merupakan bagian dari template tag Kualitas Data Kelengkapan dan yang diterapkan pada kolom.
| Tag | ID Tag | Kontrol kunci yang berlaku |
|---|---|---|
| Nilai minimum yang Dapat Diterima | acceptable_threshold |
12 |
| Nama Kolom | column_name |
12 |
| Memenuhi Nilai Minimum | meets_threshold |
12 |
| Metrik | metric |
12 |
| Operasi Terbaru | most_recent_run |
12 |
| Baris yang Divalidasi | rows_validated |
12 |
| Persentase Keberhasilan | success_percentage |
12 |
Tag kebijakan CDMC tingkat kolom
Tabel berikut mencantumkan tag kebijakan yang merupakan bagian dari taksonomi tag kebijakan Klasifikasi Data Sensitif CDMC dan diterapkan pada kolom. Tag kebijakan ini membatasi akses tingkat lapangan dan mengaktifkan data tingkat platform de-identifikasi.
| Klasifikasi Data | Nama Tag | Kontrol kunci yang berlaku |
|---|---|---|
| Informasi Identitas Pribadi | personal_identifiable_information |
7 |
| Informasi Pribadi | personal_information |
7 |
| Informasi Identitas Pribadi yang Bersifat Sensitif | sensitive_personal_identifiable_information |
7 |
| Informasi Pribadi yang Bersifat Sensitif | sensitive_personal_data |
7 |
Metadata teknis yang diisi otomatis
Tabel berikut mencantumkan metadata teknis yang disinkronkan secara default di Data Catalog untuk semua aset data BigQuery.
| Metadata | Kontrol kunci yang berlaku |
|---|---|
| Jenis Aset | — |
| Waktu Pembuatan | — |
| Waktu Habis Masa Berlaku | 11 |
| Location | 4 |
| URL Referensi | 3 |
Langkah selanjutnya
- Pelajari selengkapnya tentang CDMC.
- Baca kontrol keamanan yang digunakan oleh blueprint data warehouse yang aman.
- Temukan Data Catalog.
- Pelajari selengkapnya tentang Dataplex.
- Pelajari selengkapnya tentang Tag Engine.
- Terapkan solusi ini menggunakan Arsitektur Referensi CDMC Google Cloud di GitHub.