By · Last updated 2026-06-05

Kembali ke BlogKeselamatan AI

PII Wiki Dalaman: Data Pelanggan Confluence

Pasukan sokongan mendokumentasikan proses dengan tangkapan skrin akaun pelanggan. Selama 3 tahun, itu adalah ribuan pelanggaran minimisasi data GDPR dalam wiki anda.

June 5, 20266 min baca
Confluence GDPRinternal wiki PIIcustomer datadocumentation privacydata minimization

PII Tangkapan Skrin dalam Pangkalan Pengetahuan Dalaman

Pangkalan pengetahuan dalaman — Confluence, Notion, SharePoint, GitBook — mengandungi jenis masalah PII khusus yang terlepas oleh alat pematuhan standard: data peribadi pelanggan yang tertanam dalam tangkapan skrin yang digunakan untuk dokumen proses.

Corak ini berlaku di ribuan pasukan sokongan dan operasi.

Ejen sokongan menemui persediaan akaun yang luar biasa. Mereka mengambil tangkapan skrin halaman akaun pelanggan untuk mendokumentasikan isu. Tangkapan skrin menunjukkan nama pelanggan dalam pengepala UI, e-mel mereka dalam tetapan akaun, dan butiran pelan mereka.

Artikel itu diterbitkan dalam pangkalan pengetahuan dalaman. Seratus lima puluh ejen sokongan kini boleh melihatnya. Dua belas kontraktor di meja bantuan luaran juga boleh melihatnya. Artikel itu berguna. Ia menunjukkan cara mengendalikan kes tepi itu. Setiap ejen yang menemui persediaan tersebut pada masa hadapan akan membacanya.

Tiga tahun kemudian, pangkalan pengetahuan mengandungi 847 artikel sedemikian. Setiap satu mengandungi tangkapan skrin akaun pelanggan. Pelanggan yang ditunjukkan tidak bersetuju dengan penggunaan sekunder rekod mereka ini. Kebanyakan tidak tahu data mereka disimpan di sana.

Ini bukan masalah kecil. Ia berkembang dengan setiap artikel baharu.

Pendedahan GDPR: Mengapa Ini Penting

Analisis GDPR untuk tangkapan skrin pangkalan pengetahuan adalah langsung.

Minimisasi data (Artikel 5(1)(c)): Data peribadi mestilah "mencukupi, relevan dan terhad kepada apa yang perlu." Artikel pangkalan pengetahuan tentang persediaan akaun tidak memerlukan nama dan e-mel pelanggan sebenar. Tangkapan skrin yang dikaburkan berfungsi sama baiknya. Menyertakan data pelanggan langsung adalah tidak perlu.

Pengehadan tujuan (Artikel 5(1)(b)): Data yang dikumpulkan untuk satu tujuan — perkhidmatan pelanggan — tidak boleh digunakan semula untuk tujuan lain — dokumen proses dalaman — tanpa asas undang-undang. Rekod akaun dikumpulkan untuk penyampaian perkhidmatan, bukan untuk dokumentasi dalaman. Ini adalah dua tujuan pemprosesan yang berbeza. Menggunakan rekod yang sama untuk kedua-duanya memerlukan asas undang-undang yang sah yang kebanyakan pasukan tidak pernah sediakan.

Kawalan akses (Artikel 5(1)(f) dan Artikel 32): Langkah teknikal yang sesuai mesti melindungi data peribadi. Tangkapan skrin akaun pelanggan dalam alat yang terbuka kepada semua 150 ejen dan kontraktor — termasuk mereka yang tidak mempunyai akses kepada sistem akaun asas — mencipta akses yang terlalu luas.

Hak untuk pemadaman (Artikel 17): Subjek data yang meminta pemadaman berhak untuk rekod mereka disingkirkan "tanpa kelewatan yang tidak wajar." Jika data mereka muncul dalam 23 artikel pangkalan pengetahuan sebagai tangkapan skrin tertanam, permintaan itu memerlukan pencarian dan pengemaskinian semua 23 artikel. Itu sukar tanpa sistem. Panduan hak pemadaman GDPR kami merangkumi langkah-langkahnya secara terperinci.

Tiada satu pun daripada ini adalah pembacaan kes tepi. Semuanya adalah aplikasi langsung teks peraturan kepada amalan biasa.

Pintas Kawalan Akses

Isu pematuhan yang paling serius dengan tangkapan skrin Confluence adalah pintas kawalan akses yang diciptanya.

Pasukan sokongan menggunakan kawalan akses berasaskan peranan (RBAC) untuk mengehadkan siapa yang boleh melihat sistem akaun pelanggan. Ejen Tahap 1 melihat butiran akaun asas sahaja. Ejen Tahap 2 melihat rekod pengebilan dan teknikal. Pengurus melihat profil akaun penuh.

Apabila ejen Tahap 2 mencipta artikel pangkalan pengetahuan dengan tangkapan skrin akaun pelanggan penuh, tangkapan skrin itu menjadi kelihatan kepada setiap pengguna alat. Ejen Tahap 1 yang sepatutnya tidak melihat rekod pengebilan kini boleh melihatnya. Kontraktor tanpa akses sistem boleh melihatnya. Kakitangan baharu semasa orientasi boleh melihatnya.

Tangkapan skrin memintas kawalan RBAC pada sistem akaun pelanggan. Data peribadi yang RBAC dibina untuk melindunginya kini terbuka kepada semua orang yang mempunyai akses kepada pangkalan pengetahuan.

Ini bukan risiko teori. Ia adalah hasil biasa aliran kerja dokumen. Tangkapan skrin duduk di sana tanpa tamat tempoh, tanpa log akses, dan tanpa jejak audit.

Langkah Pemulihan Praktikal

Bagi pasukan yang menemui masalah ini semasa audit GDPR:

Pemulihan retroaktif:

  1. Kenal pasti semua halaman pangkalan pengetahuan dengan lampiran imej
  2. Jalankan pengesanan PII imej pada setiap lampiran
  3. Semak imej yang ditandai: padanan keyakinan tinggi pergi ke baris gilir semakan
  4. Untuk setiap imej yang ditandai: gantikan dengan versi yang dibersihkan atau hadkan akses halaman
  5. Log tindakan pemulihan untuk rekod GDPR

Skala kerja retroaktif bergantung pada saiz pangkalan pengetahuan. Untuk pangkalan pengetahuan berusia tiga tahun di pasukan sokongan 50 orang, bilangan imej boleh mencapai ribuan. Pemprosesan imej kelompok menjadikan ini boleh dilaksanakan. Semakan manusia terhadap imej yang ditandai adalah kesesakan utama.

Kawalan prospektif:

  1. Latih semua kakitangan sokongan untuk membersihkan tangkapan skrin sebelum menerbitkan ke pangkalan pengetahuan
  2. Sediakan alat: alat anotasi tangkapan skrin yang mengaburkan nama pelanggan sebelum menampal
  3. Tambah langkah semakan: penyemak yang ditetapkan menyemak artikel sebelum diterbitkan, mencari khusus PII pelanggan dalam imej
  4. Jalankan imbasan imej kelompok suku tahunan pada semua lampiran Confluence

Kawalan minimum yang boleh dilaksanakan: Senarai semak terbitkan: "Alih keluar atau kaburkan semua nama pelanggan, e-mel, dan ID akaun daripada tangkapan skrin sebelum menerbitkan." Teknologi rendah, tidak automatik, tetapi ia mencipta kawalan yang didokumentasikan. Bagi pasukan kecil, ini adalah titik permulaan.

Lihat gambaran keseluruhan pematuhan GDPR kami untuk rangka kerja undang-undang yang lebih luas, dan mengapa dasar tanpa kawalan teknikal gagal untuk sebab pendekatan senarai semak sahaja runtuh pada skala.

Mengapa Masalah Ini Berkembang dari Masa ke Masa

Tanpa kawalan sistematik, pendedahan PII pangkalan pengetahuan berganda.

Jumlah: Setiap artikel baharu dengan tangkapan skrin pelanggan menambah kepada jumlah pendedahan. Apabila pasukan sokongan berkembang dan pangkalan pengetahuan berkembang, PII yang terkumpul juga berkembang. Sifat yang menjadikan alat ini berguna — kemudahan penerbitan, keabadian, akses luas — adalah apa yang memburukkan masalah PII.

Artikel yang dilupakan: Artikel tentang kes tepi lama yang tidak lagi timbul kekal boleh diakses. Mereka mengandungi PII daripada pelanggan yang sejak itu telah mengemukakan permintaan pemadaman. Tiada seorang pun menyemak artikel yang terakhir dikemas kini pada 2022.

Penyebaran rentas pasukan: Pangkalan pengetahuan sering menjadi rentas fungsi. Artikel sokongan dengan tangkapan skrin pelanggan mungkin dikongsi dengan pasukan produk, pasukan kejuruteraan, atau kontraktor luaran untuk konteks tentang permintaan ciri atau laporan pepijat. Setiap perkongsian meluaskan penonton data peribadi.

Tunggakan pemadaman: Apabila lebih banyak rekod pelanggan terkumpul dalam pangkalan pengetahuan, respons terhadap permintaan pemadaman menjadi lebih kompleks. Tanpa sistem, tiada cara yang boleh dipercayai untuk mengesahkan bahawa setiap contoh rekod subjek data telah ditemui dan disingkirkan. Pasukan tidak dapat membuat pengesahan pemadaman yang kredibel.

PII pangkalan pengetahuan lebih mudah dicegah daripada diperbaiki. Kawalan yang diletakkan sekarang mengelakkan masalah pemulihan yang berganda. Setiap artikel yang diterbitkan tanpa tangkapan skrin yang dikaburkan adalah tugas pemulihan yang ditangguhkan ke masa hadapan.

Sumber

Sedia untuk melindungi data anda?

Mulakan pengenalan PII dengan 285+ jenis entiti dalam 48 bahasa.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.