Cloud Data Loss Prevention (Cloud DLP) kini menjadi bagian dari Sensitive Data Protection. Nama API tetap sama: Cloud Data Loss Prevention API (DLP API). Untuk informasi tentang layanan yang membentuk Perlindungan Data Sensitif, lihat Ringkasan Perlindungan Data Sensitif.

Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Masalah umum

Halaman ini berisi daftar masalah umum pada Sensitive Data Protection, 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 adanya 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 pemeriksaan dan pembuatan profil

Masalah berikut berlaku untuk operasi pemeriksaan dan pembuatan profil BigQuery.

Baris dengan keamanan tingkat baris tidak dapat dipindai

Kebijakan keamanan tingkat baris dapat mencegah Sensitive Data Protection 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:

Jika Anda membuat data profil di level organisasi atau folder, sertakan agen layanan project container dalam daftar penerima hibah.
Jika Anda membuat profil data di level project atau menjalankan tugas inspeksi pada tabel, sertakan agen layanan project dalam daftar penerima izin.

Baris duplikat

Saat menulis data ke tabel BigQuery, Sensitive Data Protection mungkin 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 buffer streaming). Untuk mengetahui informasi selengkapnya, lihat Ketersediaan data streaming dalam dokumentasi BigQuery.

Masalah pemeriksaan BigQuery

Masalah berikut hanya berlaku untuk operasi pemeriksaan pada data BigQuery. Aturan ini tidak memengaruhi profil data.

Temuan yang diekspor tidak memiliki nilai untuk kolom row_number

Saat Anda mengonfigurasi Sensitive Data Protection untuk menyimpan temuan ke BigQuery, kolom location.content_locations.record_location.record_key.big_query_key.row_number dalam tabel BigQuery yang dihasilkan akan disimpulkan pada saat tabel input dipindai. Nilainya bersifat nondeterministik, tidak dapat dikueri, dan dapat bernilai null untuk tugas inspeksi.

Jika Anda perlu mengidentifikasi baris tertentu tempat temuan berada, tentukan inspectJob.storageConfig.bigQueryOptions.identifyingFields pada waktu 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 untuk konten baru, dan menggunakan BigQuery Storage Write API (gRPC) untuk mengisi tabel input, Sensitive Data Protection mungkin akan melewati pemindaian beberapa baris.

Untuk mengurangi masalah ini, dalam tugas inspeksi Anda, pastikan timestampField objek TimespanConfig adalah stempel waktu commit yang dibuat otomatis oleh BigQuery. Namun, masih tidak ada jaminan bahwa tidak ada baris yang dilewati, karena Sensitive Data Protection tidak membaca dari data yang baru di-streaming.

Jika Anda ingin membuat stempel waktu commit secara otomatis untuk kolom, dan menggunakan legacy streaming API 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 ke TIMESTAMP:
```
...
{
 "name": "commit_time_stamp",
 "type": "TIMESTAMP"
}
...
```
Di kolom rows[].json pada metode tabledata.insertAll, pastikan nilai di kolom stempel waktu ditetapkan ke AUTO.

Contoh JSON

Contoh berikut menetapkan nilai kolom commit_time_stamp ke AUTO:
```
{
  ...
  "commit_time_stamp": "AUTO",
  ...
}
```

Membatasi pemindaian dengan menetapkan persentase atau baris maksimum

Saat Anda menetapkan batas pengambilan sampel berdasarkan persentase total jumlah baris tabel (rowsLimitPercent), Sensitive Data Protection dapat memeriksa lebih banyak baris daripada yang diharapkan. Jika Anda perlu menetapkan batas ketat pada jumlah baris yang akan dipindai, sebaiknya tetapkan jumlah maksimum baris (rowsLimit).

Masalah pembuatan profil BigQuery

Masalah berikut hanya berlaku untuk operasi pembuatan profil pada data BigQuery. Untuk mengetahui informasi selengkapnya, baca Profil data untuk data BigQuery.

Organisasi atau project dengan lebih dari 500 juta tabel

Sensitive Data Protection 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 memiliki lebih dari 500 juta tabel, dan Anda memiliki project dengan jumlah tabel yang lebih rendah, coba lakukan pemindaian level project.

Untuk mengetahui informasi tentang batas tabel dan kolom, lihat Batas pembuatan profil data.

Template pemeriksaan

Template pemeriksaan 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, Sensitive Data Protection 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 direferensikan dalam template pemeriksaan Anda harus disimpan di salah satu lokasi berikut:

Region 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 di kolom Public profil data tabel. Di Cloud Data Loss Prevention API, visibilitas resource ditunjukkan di kolom resourceVisibility dari TableDataProfile.

Stempel waktu masa berlaku salah untuk tabel yang tidak memiliki masa berlaku

Antara Juli 2025 dan Juni 2026, beberapa profil data tabel yang disimpan ke BigQuery berisi stempel waktu 1970-01-01 yang salah, bukan NULL di expiration_time untuk tabel yang tidak memiliki masa berlaku.

Pemindaian Cloud Storage

Bagian ini menjelaskan masalah yang mungkin Anda alami saat memeriksa atau melakukan de-identifikasi data.

Pemeriksaan file Strict XLSX 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 workbook Microsoft Excel default, yang didukung.

File terstruktur yang dipindai dalam mode biner

Dalam kasus tertentu, file yang biasanya dipindai dalam mode penguraian terstruktur mungkin dipindai dalam mode biner, yang tidak menyertakan peningkatan mode penguraian terstruktur. Untuk mengetahui informasi selengkapnya, lihat Memindai file terstruktur dalam mode penguraian terstruktur.

Melakukan de-identifikasi file yang dibatasi

Saat Anda melakukan de-identifikasi 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 melakukan de-identifikasi data menggunakan metode content.deidentify.

Penemuan untuk Cloud SQL

Temuan duplikat Security Command Center

Pembuatan profil data Cloud SQL mendukung publikasi temuan ke Security Command Center.

Sebelum 25 April 2024, bug menyebabkan Sensitive Data Protection terkadang menghasilkan 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 ini 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 AWS atau nama tampilan resource yang terpengaruh. Hal ini biasanya terjadi dalam kasus berikut:

Konektor AWS hanya berlaku selama sekitar 24 jam saat temuan dikirim ke Security Command Center.
Akun AWS hanya disertakan dalam konektor AWS selama sekitar 24 jam 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 temuan lengkap 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 Intelligent Document Parsing.

Deteksi

Masalah umum berikut menjelaskan masalah terkait deteksi, terlepas dari operasi yang Anda lakukan—pemeriksaan, de-identifikasi, atau penemuan.

Kata dari kamus

Kata kamus yang berisi karakter dalam Supplementary Multilingual Plane standar Unicode dapat menghasilkan temuan yang tidak terduga. Contoh karakter tersebut adalah emoji, simbol ilmiah, dan aksara sejarah.

Masalah umum Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.