Halaman ini berisi daftar masalah umum pada Perlindungan Data Sensitif, beserta cara menghindari atau memulihkan masalah berikut.
Menyimpan hasil ke BigQuery
Saat tugas atau pemindaian penemuan menyimpan hasil ke BigQuery, error Already exists
akan muncul di log. Error ini tidak menunjukkan bahwa
ada masalah; hasil Anda akan disimpan seperti yang diharapkan.
Pemindaian BigQuery
Bagian ini menjelaskan masalah yang mungkin Anda alami saat memeriksa atau membuat profil data BigQuery.
Masalah umum pada operasi inspeksi dan pembuatan profil
Masalah berikut berlaku untuk operasi inspeksi dan pembuatan profil BigQuery.
Baris dengan keamanan tingkat baris tidak dapat dipindai
Kebijakan keamanan tingkat baris dapat mencegah Perlindungan Data Sensitif memeriksa dan membuat profil tabel BigQuery yang dilindungi. Jika Anda menerapkan kebijakan keamanan tingkat baris ke tabel BigQuery, sebaiknya tetapkan filter TRUE dan sertakan agen layanan dalam daftar penerima hibah:
- Jika Anda membuat profil data di tingkat organisasi atau folder, sertakan agen layanan project penampung dalam daftar penerima hibah.
- Jika Anda membuat profil data di tingkat project atau menjalankan tugas pemeriksaan pada tabel, sertakan agen layanan project dalam daftar penerima hibah.
Baris duplikat
Saat menulis data ke tabel BigQuery, Perlindungan Data Sensitif dapat menulis baris duplikat.
Data yang baru-baru ini di-streaming
Sensitive Data Protection tidak memindai data yang baru-baru ini di-streaming (sebelumnya dikenal sebagai buffering streaming). Untuk mengetahui informasi selengkapnya, lihat Ketersediaan streaming data dalam dokumentasi BigQuery.
Masalah pemeriksaan BigQuery
Masalah berikut hanya berlaku untuk operasi pemeriksaan pada data BigQuery. Profil data tidak terpengaruh.
Temuan yang diekspor tidak memiliki nilai untuk kolom row_number
Saat Anda mengonfigurasi Perlindungan Data Sensitif untuk menyimpan temuan ke BigQuery, kolom location.content_locations.record_location.record_key.big_query_key.row_number
di tabel BigQuery yang dihasilkan disimpulkan pada saat tabel input dipindai. Nilainya tidak deterministik, tidak dapat dikueri, dan dapat berupa
null untuk tugas inspeksi.
Jika Anda perlu mengidentifikasi baris tertentu tempat temuan berada, tentukan
inspectJob.storageConfig.bigQueryOptions.identifyingFields
saat pembuatan tugas.
Kolom identifikasi dapat ditemukan di tabel BigQuery yang dihasilkan, di
kolom location.content_locations.record_location.record_key.id_values
.
Membatasi pemindaian ke konten BigQuery baru
Jika Anda membatasi pemindaian hanya pada konten baru, dan menggunakan BigQuery Storage Write API untuk mengisi tabel input, Perlindungan Data Sensitif mungkin akan melewati pemindaian beberapa baris.
Untuk mengatasi masalah ini, di tugas pemeriksaan, pastikan timestampField
objek
TimespanConfig
adalah stempel waktu commit yang dibuat secara otomatis oleh BigQuery.
Namun, masih belum ada jaminan bahwa tidak ada baris yang dilewati, karena
Perlindungan Data Sensitif tidak membaca dari
data yang baru-baru ini di-streaming.
Jika Anda ingin membuat stempel waktu commit secara otomatis untuk kolom, dan Anda menggunakan API streaming lama untuk mengisi tabel input, lakukan hal berikut:
Dalam skema tabel input, pastikan kolom stempel waktu berjenis
TIMESTAMP
.Contoh skema
Contoh berikut menentukan kolom
commit_time_stamp
dan menetapkan jenisnya keTIMESTAMP
:... { "name": "commit_time_stamp", "type": "TIMESTAMP" } ...
Di kolom
rows[].json
metodetabledata.insertAll
, pastikan nilai di kolom stempel waktu ditetapkan keAUTO
.Contoh JSON
Contoh berikut menetapkan nilai kolom
commit_time_stamp
keAUTO
:{ ... "commit_time_stamp": "AUTO", ... }
Membatasi pemindaian dengan menetapkan persentase atau baris maksimum
Jika Anda menetapkan batas pengambilan sampel berdasarkan persentase jumlah total baris
tabel
(rowsLimitPercent
),
Sensitive Data Protection dapat memeriksa lebih banyak baris dari yang diharapkan. Jika Anda perlu
membatasi jumlah baris yang dipindai, sebaiknya tetapkan jumlah maksimum baris
(rowsLimit
)
sebagai gantinya.
Masalah pembuatan profil BigQuery
Masalah berikut hanya berlaku untuk operasi pembuatan profil pada data BigQuery. Untuk mengetahui informasi selengkapnya, lihat Profil data untuk data BigQuery.
Organisasi atau project dengan lebih dari 500 juta tabel
Perlindungan Data Sensitif akan menampilkan error jika Anda mencoba membuat profil organisasi atau project yang memiliki lebih dari 500 juta tabel. Jika Anda mengalami error ini, ikuti petunjuk dalam pesan error.
Jika jumlah tabel organisasi Anda lebih dari 500 juta tabel, dan Anda memiliki project dengan jumlah tabel yang lebih rendah, coba lakukan pemindaian tingkat project.
Untuk mengetahui informasi tentang batas tabel dan kolom, lihat Batas pembuatan profil data.
Template inspeksi
Template inspeksi harus berada di
region yang sama dengan data yang akan diprofilkan. Jika Anda memiliki data di beberapa region, gunakan beberapa template pemeriksaan—satu untuk setiap region tempat Anda memiliki data.
Anda juga dapat menggunakan template pemeriksaan yang disimpan di region global
.
Jika Anda menyertakan template di region global
, Perlindungan Data Sensitif akan menggunakannya
untuk data apa pun yang tidak memiliki template khusus region. Untuk mengetahui informasi selengkapnya, lihat Pertimbangan residensi data.
infoTypes yang Disimpan
InfoType tersimpan (juga dikenal sebagai detektor kamus kustom tersimpan) yang dirujuk dalam template inspeksi Anda harus disimpan di salah satu lokasi berikut:
- Wilayah
global
. - Region yang sama dengan template pemeriksaan.
Jika tidak, operasi pembuatan profil akan gagal dengan error, Resource not found
.
Visibilitas resource
Dalam profil data tabel, klasifikasi visibilitas resource yang diberikan ke tabel BigQuery bergantung pada visibilitas set data yang berisi tabel, bukan visibilitas tabel. Oleh karena itu, jika izin IAM tabel berbeda dengan izin IAM set data, visibilitas resource tabel yang ditunjukkan dalam profil data dapat salah. Masalah ini memengaruhi penemuan untuk BigQuery dan penemuan untuk Vertex AI.
Di konsol Google Cloud , visibilitas resource ditunjukkan dalam profil data tabel
di kolom Publik. Di Cloud Data Loss Prevention API, visibilitas resource ditunjukkan di kolom resourceVisibility
dari
TableDataProfile
.
Pemindaian Cloud Storage
Bagian ini menjelaskan masalah yang mungkin Anda alami saat memeriksa atau menghilangkan identitas data.
Pemeriksaan file XLSX dengan pendeteksi kamus kustom berukuran besar
Saat Anda menggunakan
pendeteksi kamus kustom besar (juga
dikenal sebagai pendeteksi kamus kustom tersimpan) untuk memeriksa file Microsoft Excel
.xlsx
, tugas inspeksi dapat berjalan lambat, tampak macet, dan menimbulkan sejumlah besar
operasi Cloud Storage Class B.
Hal ini karena Sensitive Data Protection mungkin membaca daftar istilah sumber dari
kamus kustom besar sekali untuk setiap sel dalam file .xlsx
. Volume operasi baca dapat menyebabkan tugas pemeriksaan Perlindungan Data Sensitif menunjukkan sedikit progres dan tampak macet.
Untuk mengetahui informasi selengkapnya tentang biaya penagihan Cloud Storage yang relevan, lihat biaya untuk operasi Kelas B di Biaya operasi.
Pemeriksaan file XLSX Ketat tidak didukung
File dengan ekstensi .xlsx
dapat berupa salah satu dari dua jenis. Salah satu jenisnya adalah spreadsheet Strict Office Open XML, yang tidak didukung oleh Sensitive Data Protection.
Jenis lainnya adalah buku kerja Microsoft Excel default, yang didukung.
File terstruktur yang dipindai dalam mode biner
Dalam kasus tertentu, file yang biasanya dipindai dalam mode parsing terstruktur mungkin dipindai dalam mode biner, yang tidak menyertakan peningkatan mode parsing terstruktur. Untuk mengetahui informasi selengkapnya, lihat Memindai file terstruktur dalam mode penguraian terstruktur.
Melakukan de-identifikasi file delimited
Saat Anda menghilangkan identitas
file yang dibatasi (misalnya, file CSV) dengan tugas inspeksi,
output mungkin memiliki sel kosong tambahan di beberapa baris. Solusi untuk menghindari sel tambahan ini adalah dengan menghapus identitas data menggunakan metode content.deidentify
.
Discovery untuk Cloud SQL
Temuan duplikat Security Command Center
Pembuatan profil data Cloud SQL mendukung pemublikasian temuan ke Security Command Center.
Sebelum 25 April 2024, bug menyebabkan Sensitive Data Protection terkadang membuat temuan duplikat untuk instance Cloud SQL di Security Command Center. Temuan ini dibuat dengan ID temuan unik, tetapi berkaitan dengan instance Cloud SQL yang sama. Masalah telah diselesaikan, tetapi temuan duplikat masih ada. Anda dapat menonaktifkan duplikat untuk menyembunyikannya di halaman Temuan Security Command Center.
Penemuan untuk Amazon S3
Temuan untuk Amazon S3 yang dikirim Sensitive Data Protection ke Security Command Center mungkin tidak memiliki informasi tentang ID akun atau nama tampilan AWS resource yang terpengaruh. Hal ini biasanya terjadi dalam kasus berikut:
- Konektor AWS hanya valid selama sekitar 24 jam pada saat temuan dikirim ke Security Command Center.
- Akun AWS hanya disertakan dalam konektor AWS selama sekitar 24 jam pada saat temuan dikirim ke Security Command Center.
Untuk mengatasi masalah ini, setelah sekitar 24 jam, buat ulang profil data dengan menghapusnya atau dengan menetapkan jadwal pembuatan profil. Detail lengkap temuan dikirim ke Security Command Center.
Penguraian dokumen cerdas
Bagian ini berisi masalah umum terkait penguraian dokumen.
Objek DocumentLocation
tidak diisi
Kolom location.content_locations.document_location.file_offset
tidak diisi untuk mode pemindaian Penguraian Dokumen Cerdas.
Deteksi
Masalah umum berikut menjelaskan masalah terkait deteksi, terlepas dari operasi yang Anda lakukan—pemeriksaan, penghapusan identitas, atau penemuan.
Kata-kata kamus
Kata-kata dalam kamus yang berisi karakter dalam Supplementary Multilingual Plane dari standar Unicode dapat menghasilkan temuan yang tidak terduga. Contoh karakter tersebut adalah emoji, simbol ilmiah, dan skrip historis.
Aturan pengecualian
Aturan pengecualian tidak dapat diterapkan ke infoType objek.