Dokumen ini menjelaskan cara menerapkan 14 kontrol utama Kemampuan Pengelolaan Data Cloud (CDMC) dalam data warehouse BigQuery untuk membantu melindungi dan mengatur data sensitif. Organisasi men-deploy cloud data warehouse untuk menyimpan informasi sensitif untuk analisis bisnis, sehingga memerlukan tata kelola yang ketat dan kepatuhan terhadap peraturan.
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 Knowledge Catalog ini sudah dinilai dan disertifikasi berdasarkan Framework Kontrol Kunci CDMC sebagai Solusi Cloud Tersertifikasi CDMC. Arsitektur referensi menggunakan berbagai layanan dan fiturGoogle Cloud serta library publik untuk menerapkan kontrol utama CDMC dan otomatisasi yang direkomendasikan. Dokumen ini menjelaskan cara Anda dapat menerapkan kontrol utama untuk membantu melindungi data sensitif dalam data warehouse BigQuery.
Arsitektur
Arsitektur referensi Google Cloud berikut ini selaras dengan Spesifikasi Uji Framework Kontrol Utama CDMC v1.1.1. Angka-angka dalam 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 yang mencakup informasi sensitif. Pada diagram sebelumnya, project di bagian atas diagram (berwarna abu-abu) adalah bagian dari blueprint data warehouse yang aman. 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 kualitas data. Project ini juga menyediakan cara mengaudit arsitektur dan melaporkan temuannya.
Untuk mengetahui contoh template deployment dan skrip otomatisasi, lihat implementasi referensi open source Google Cloud Arsitektur Referensi CDMC yang diarsipkan di GitHub.
Alternatif arsitektur: Mesh data terdesentralisasi
Arsitektur yang dijelaskan dalam dokumen ini menggunakan project tata kelola data terpusat untuk memantau dan mengelola data warehouse BigQuery terpusat. Jika organisasi Anda memerlukan model berbasis domain, Anda dapat menerapkan 14 kontrol utama CDMC menggunakan arsitektur data mesh dengan tata kelola gabungan. Dalam model ini, setiap domain memiliki produk datanya sendiri, sementara kebijakan CDMC, standar klasifikasi, dan pelaporan audit diatur secara terpusat.
Arsitektur mesh data memungkinkan Anda menerapkan kontrol utama CDMC sebagai berikut:
- Mengelompokkan domain logis: Gunakan data lake dan zona data untuk mengatur data di beberapa project, set data BigQuery, dan bucket Cloud Storage ke dalam domain bisnis yang berbeda tanpa memindahkan data. Google Cloud Untuk silsilah dan pengkatalogan, gunakan Knowledge Catalog.
- Memvalidasi kualitas data: Tentukan dan jadwalkan pemindaian kualitas data otomatis Knowledge Catalog untuk memvalidasi kontrak data tanpa mengandalkan pipeline pemberian tag pusat.
- Mengelola siklus proses data: Konfigurasi masa berlaku partisi tabel BigQuery, masa berlaku tabel, dan pengelolaan siklus proses objek Cloud Storage pada aset domain.
- Melacak silsilah data lintas domain: Gunakan silsilah data Knowledge Catalog untuk melacak pergerakan dan transformasi data di seluruh batas domain dan project.
- Mendukung lingkungan hybrid dan multi-cloud: Gunakan BigQuery Omni untuk menganalisis data di tempat.
Untuk men-deploy data mesh tingkat perusahaan yang mengintegrasikan kontrol CDMC, lihat Men-deploy platform pengelolaan dan analisis data tingkat perusahaan dan cetak biru data mesh tingkat perusahaan Terraform yang terkait. Cetak biru ini menerapkan model gabungan dengan menyandingkan lingkungan produsen dan konsumen domain yang terdesentralisasi dengan project tata kelola data pusat di folder bersama.
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 kepada pelanggan. Anda dapat mengintegrasikan alat pengelolaan layanan 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 Data 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.
- Data Studio menyediakan dasbor dan laporan.
Screenshot berikut menunjukkan contoh dasbor ringkasan Data 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.
Knowledge Catalog menangani dua jenis metadata: metadata teknis dan metadata bisnis. Untuk project tertentu, Knowledge 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
Knowledge 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 selengkapnya, lihat Mengelola aspek dan memperkaya metadata.
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 satu menyimpan default untuk kepemilikan aset data.
- Knowledge Catalog menyimpan metadata kepemilikan melalui template dan tag.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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
Knowledge Catalog untuk menambahkan tag is_authoritative ke
template tag CDMC controls. Tag ini menentukan apakah aset data bersifat otoritatif.
Knowledge Catalog mengatalogkan 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 ditentukan dalam
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 satu lagi menyimpan default untuk sumber tepercaya aset data.
- Knowledge Catalog menyimpan metadata sumber otoritatif melalui tag.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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 Knowledge Catalog untuk menambahkan
tag approved_storage_location 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 Google Cloud region 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 Knowledge Catalog
dan menyimpan lokasi di tag approved_storage_location. Jika Anda mengaktifkan tingkat Security Command Center Premium, dan seseorang mengupdate batasan Organization Policy lokasi resource, Security Command Center akan menghasilkan temuan kerentanan untuk resource yang disimpan di luar kebijakan yang diupdate.
Access Context Manager menentukan lokasi geografis tempat pengguna harus berada sebelum mereka dapat mengakses aset data. Dengan tingkat akses, Anda dapat menentukan wilayah asal permintaan. Kemudian, tambahkan kebijakan akses ke perimeter Kontrol Layanan VPC untuk project data Rahasia.
Untuk melacak perpindahan data, BigQuery mempertahankan jejak audit lengkap untuk setiap tugas 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:
- 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.
- Knowledge Catalog menyimpan lokasi penyimpanan yang disetujui sebagai tag.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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 Knowledge Catalog. Knowledge Catalog secara otomatis mencatat aset Google Cloud, termasuk set data, tabel, dan tampilan BigQuery. Saat Anda membuat tabel baru di BigQuery, Knowledge Catalog secara otomatis mendaftarkan skema dan metadata teknis tabel baru. Saat Anda mengupdate tabel di BigQuery, Knowledge Catalog akan mengupdate entrinya hampir 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 menyimpan data rahasia dan satunya lagi menyimpan data tidak rahasia.
- Knowledge Catalog menyimpan metadata teknis untuk tabel dan kolom.
Secara default, Knowledge Catalog menyimpan metadata teknis dari BigQuery dalam arsitektur ini. Jika diperlukan, Anda dapat mengintegrasikan Knowledge 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 Knowledge Catalog pada tingkat tabel dan
kolom. Tabel referensi klasifikasi memungkinkan Anda 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, Knowledge 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
- Knowledge Catalog menyimpan tag klasifikasi.
- Sensitive Data Protection memeriksa aset untuk infoType sensitif.
- Compute Engine menjalankan skrip Inspect Datasets, 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 apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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 kemudian 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.
- Knowledge Catalog menyimpan tag tingkat tabel dan tingkat kolom untuk kategori sensitif.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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 kemudian dipetakan ke hak yang disimpan di BigQuery menggunakan label kueri. Saat konsumen
membuat kueri data sensitif di BigQuery, mereka harus menentukan
tujuan valid yang sesuai dengan hak mereka (misalnya, SET @@query_label =
"use:3";).
Arsitektur ini menggunakan Knowledge Catalog untuk menambahkan
tag berikut ke 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 memberikan nilai default untuk tagsharing_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 data.data_asset: informasi tentang aset data, seperti nama aset dan detail tentang 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 mengetahui 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 dan satunya lagi menyimpan data hak kepemilikan, yang mencakup perjanjian berbagi data penyedia dan konsumen, serta tujuan penggunaan yang disetujui.
- Knowledge Catalog menyimpan informasi perjanjian berbagi data penyedia sebagai tag.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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:
- Apakah 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_datedalam tabelconsumer_agreementsudah 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 mengelola kunci Anda sendiri menggunakan kunci enkripsi yang dikelola pelanggan (CMEK). Cloud Key Management Service memungkinkan Anda 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 Anda terapkan 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 Knowledge Catalog untuk menambahkan
tag encryption_method ke template tag CDMC controls tingkat tabel. encryption_method
menentukan 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 menjalankan identifikasi ulang.
- Tiga data warehouse BigQuery: satu data warehouse menyimpan data rahasia, satu lagi menyimpan data tidak rahasia, dan yang ketiga menyimpan kebijakan keamanan.
- Knowledge Catalog menyimpan template tag enkripsi dan de-identifikasi.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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:
- 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 Knowledge 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: apakah 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. Tabel kebijakan menentukan kombinasi valid dari residensi data, lokasi subjek, sensitivitas data (misalnya, apakah data tersebut merupakan PII), dan 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
- Knowledge Catalog menyimpan detail penilaian dampak dalam tag di dalam template tag.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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 Knowledge 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 | Arsipkan |
| Informasi Pribadi | 180 | Arsipkan |
Anda dapat menggunakan opsi berikut untuk menerapkan pengelolaan siklus proses data:
Gabungkan fitur siklus proses BigQuery dengan orkestrasi serverless. Dalam hal ini, nilai tag sebelumnya menentukan kebijakan tata kelola. Cloud Scheduler memicu alur kerja serverless menggunakan Workflows atau Cloud Run function. Alur kerja ini membaca metadata tag dan mengevaluasi tindakan habis masa berlaku. Jika tindakan adalah penghapusan permanen, alur kerja akan membuat snapshot tabel dengan waktu berakhir untuk mendukung penghapusan sementara dan pemulihan, serta menerapkan kebijakan akhir masa berlaku tabel atau akhir masa berlaku partisi BigQuery ke tabel sumber. Jika tindakannya adalah mengarsipkan, alur kerja akan menyelesaikan hal berikut:
- Mengekspor data tabel ke Cloud Storage dalam format Parquet.
- Mendaftarkan tabel BigLake untuk mendukung pemberian tag metadata eksternal.
- Menyalin tag metadata dan kebijakan dari tabel sumber ke tabel BigLake (atau menerapkan kembali tag menggunakan Tag Engine).
- Menghapus atau mengakhiri masa berlaku tabel sumber.
Deploy Record Manager, aset open source untuk BigQuery, guna menghapus permanen dan mengarsipkan tabel BigQuery berdasarkan nilai tag sebelumnya 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 Knowledge Catalog. Kemudian, Pengelola Catatan akan menghapus tabel sumber untuk menyelesaikan proses pengarsipan.
Di kedua opsi, setelah data diarsipkan ke Cloud Storage, Anda dapat mengonfigurasi pengelolaan siklus proses objek Cloud Storage untuk secara otomatis mentransisikan file lama ke kelas penyimpanan yang lebih murah.
Diagram berikut menunjukkan layanan yang berlaku untuk kontrol ini saat Anda menggunakan fitur siklus proses BigQuery.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Dua data warehouse BigQuery: satu menyimpan data rahasia dan satunya lagi menyimpan kebijakan retensi data.
- Cloud Storage menyediakan penyimpanan arsip.
- Knowledge Catalog menyimpan periode retensi dan tindakan dalam template tag dan tag tersebut.
- Dua instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa apakah tag diterapkan, mengevaluasi tabel berdasarkan kebijakan retensi, dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang memberi tag pada data di data warehouse yang aman berdasarkan aturan kebijakan perusahaan yang disimpan di data warehouse tata kelola.
- Cloud Scheduler memicu alur kerja untuk memberlakukan tindakan pengarsipan atau masa berlaku.
- Alur kerja atau fungsi Cloud Run menjalankan alur kerja serverless.
- Pub/Sub memublikasikan temuan.
- BigLake memungkinkan kontrol akses dan pemberian tag metadata pada data yang diarsipkan.
Diagram berikut menunjukkan layanan yang berlaku untuk kontrol ini saat Anda menggunakan Pengelola Catatan.
Untuk memenuhi persyaratan kontrol ini, arsitektur menggunakan layanan berikut:
- Dua data warehouse BigQuery: satu menyimpan data rahasia dan satunya lagi menyimpan kebijakan retensi data.
- Dua bucket Cloud Storage, satu bucket menyediakan penyimpanan arsip dan bucket lainnya menyimpan kumpulan data.
- Knowledge Catalog menyimpan periode retensi dan tindakan dalam template tag dan tag tersebut.
- Tiga instance Cloud Run, sebagai berikut:
- Pertama, instance yang menjalankan Report Engine. Instance ini memeriksa apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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:
- Tindakan habis masa berlaku untuk aset sensitif tidak sesuai dengan kebijakan untuk lokasi aset.
- Periode retensi untuk aset sensitif tidak sesuai dengan kebijakan untuk lokasi aset.
- Data sensitif tersedia tanpa tag periode retensi atau tindakan habis masa berlaku.
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. Knowledge 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.
- Knowledge 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 apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang memberi tag pada data di data warehouse yang aman.
- Instance ketiga 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 Data 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 kualitas data otomatis Knowledge Catalog.
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 terbatas pada penggunaan penyimpanan dan pergerakannya.
Arsitektur ini menggunakan Knowledge Catalog untuk menambahkan
tag berikut ke template tag cost_metrics:
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 ke dalam aset data ini.estimated_query_cost: perkiraan biaya kueri, dalam dolar AS, untuk aset 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.
- Knowledge 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 apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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 Knowledge 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
Knowledge 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: satu menyimpan data rahasia, dan yang lainnya menyimpan data sumber akhir.
- Knowledge Catalog menyimpan sumber akhir dalam template tag dan tag.
- Skrip penyerapan data memuat data dari Cloud Storage, 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 apakah tag diterapkan dan memublikasikan hasilnya.
- Instance lain menjalankan Tag Engine, yang 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 | ID Tag | 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 Knowledge 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 berikutnya
- Pelajari lebih lanjut framework CDMC di situs EDM Council.
- Baca kontrol keamanan yang digunakan oleh blueprint data warehouse yang aman.
- Lacak provenance data pelatihan dan transformasi pipeline untuk beban kerja AI dan machine learning dengan silsilah data Knowledge Catalog.
- Pelajari lebih lanjut Tag Engine.
- Tinjau skrip otomatisasi contoh di repositori Google Cloud Arsitektur Referensi CDMC yang diarsipkan di GitHub.