Menerapkan framework kontrol utama CDMC pada data warehouse BigQuery

Badge CDMC

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.

Komponen arsitektur CDMC.

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:
  • Hak dan akses ke data sensitif harus secara default ke pembuat dan pemilik hingga diberikan secara eksplisit dan secara resmi.
  • Akses harus dilacak untuk semua data sensitif.
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:
  • Kontrol keamanan yang sesuai harus diaktifkan untuk data sensitif.
  • Bukti kontrol keamanan harus dicatat pada data catalog untuk semua data sensitif.
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.

Komponen arsitektur Kontrol 1.

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.

Contoh dasbor ringkasan Looker Studio.

Screenshot berikut menunjukkan tampilan contoh temuan menurut aset data.

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:

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.

Komponen arsitektur Kontrol 2.

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.

Komponen arsitektur Kontrol 3.

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.

Komponen arsitektur Kontrol 4.

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.

Komponen arsitektur Kontrol 5.

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 sensitif
  • sensitive_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.

Komponen arsitektur Kontrol 6.

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.

Komponen arsitektur Kontrol 7.

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 disetujui
  • sharing_scope_geography: daftar lokasi geografis tempat aset data dapat dibagikan
  • sharing_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 tag shared_scope_geography dan sharing_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 data
  • data_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.

Komponen arsitektur Kontrol 8.

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_date dalam consumer_agreement table sudah 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, SELECT atau INSERT).
  • 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.

Komponen arsitektur Kontrol 9.

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.

Komponen arsitektur Kontrol 10.

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 tabel
  • expiration_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.

Komponen arsitektur Kontrol 11.

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 diterapkan
  • metric: nama metrik atau aturan kualitas
  • rows_validated: jumlah baris yang divalidasi
  • success_percentage: persentase nilai yang memenuhi metrik ini
  • acceptable_threshold: nilai minimum yang dapat diterima untuk metrik ini
  • meets_threshold: apakah skor kualitas (nilai success_percentage) memenuhi nilai minimum yang dapat diterima
  • most_recent_run: waktu terakhir kali metrik atau aturan kualitas dijalankan

Diagram berikut menampilkan layanan yang berlaku untuk kontrol ini.

Komponen arsitektur Kontrol 12.

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.

Komponen arsitektur Kontrol 13.

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.

Komponen arsitektur Kontrol 14.

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