By · Last updated 2026-06-05

Quay lại BlogBảo Mật AI

PII Trong Wiki Nội Bộ: Dữ Liệu Khách Hàng Trong Confluence

Nhóm hỗ trợ ghi lại quy trình bằng ảnh chụp màn hình tài khoản khách hàng. Sau 3 năm, đó là hàng nghìn vi phạm tối giản hóa dữ liệu GDPR trong wiki của bạn.

June 5, 20266 phút đọc
Confluence GDPRinternal wiki PIIcustomer datadocumentation privacydata minimization

Vấn Đề Tích Lũy PII Trong Tài Liệu

Cơ sở kiến thức nội bộ — Confluence, Notion, SharePoint, GitBook — tích lũy một loại vấn đề PII cụ thể gần như hoàn toàn vô hình với các công cụ tuân thủ tiêu chuẩn: dữ liệu cá nhân của khách hàng được nhúng vào ảnh chụp màn hình được sử dụng cho tài liệu quy trình.

Tình huống diễn ra trên hàng nghìn nhóm hỗ trợ và vận hành:

Một nhân viên hỗ trợ phát hiện một cấu hình tài khoản bất thường. Họ chụp màn hình trang tài khoản của khách hàng để ghi lại vấn đề cho bài viết cơ sở kiến thức đang được viết. Ảnh chụp màn hình chứa tên khách hàng trong tiêu đề UI, địa chỉ email của họ trong cài đặt tài khoản và chi tiết đăng ký của họ.

Bài viết cơ sở kiến thức được xuất bản lên wiki nội bộ. 150 nhân viên hỗ trợ hiện có thể truy cập nó. 12 nhà thầu làm việc từ bộ phận hỗ trợ bên ngoài có thể truy cập nó. Bài viết là tài liệu hữu ích về cách xử lý trường hợp ngoại lệ.

Ba năm sau, cơ sở kiến thức có 847 bài viết như vậy. Mỗi bài chứa ảnh chụp màn hình tài khoản khách hàng. Các khách hàng có dữ liệu tài khoản xuất hiện trong ảnh chụp màn hình chưa đồng ý với việc sử dụng thứ cấp dữ liệu của họ. Hầu hết không biết dữ liệu của họ có trong wiki nội bộ.

Phơi Nhiễm GDPR: Tại Sao Đây Không Phải Là Vấn Đề Nhỏ

Phân tích GDPR cho ảnh chụp màn hình tài liệu nội bộ:

Tối giản hóa dữ liệu (Điều 5(1)(c)): Dữ liệu cá nhân phải "đầy đủ, có liên quan và giới hạn ở những gì cần thiết." Một bài viết cơ sở kiến thức về các trường hợp ngoại lệ cấu hình tài khoản không yêu cầu tên và địa chỉ email thực của khách hàng. Một ảnh chụp màn hình được làm sạch (tên khách hàng bị làm mờ) sẽ phục vụ mục đích tài liệu cũng tốt. Việc đưa vào dữ liệu thực của khách hàng là không cần thiết.

Giới hạn mục đích (Điều 5(1)(b)): Dữ liệu cá nhân được thu thập cho một mục đích không thể được tái sử dụng cho một mục đích khác mà không có cơ sở pháp lý. Dữ liệu tài khoản của khách hàng được thu thập để cung cấp dịch vụ, không phải để ghi lại các trường hợp ngoại lệ nội bộ.

Kiểm soát truy cập (Điều 5(1)(f) và Điều 32): Các biện pháp kỹ thuật phù hợp phải bảo vệ dữ liệu cá nhân. Ảnh chụp màn hình tài khoản khách hàng trong wiki có thể truy cập cho tất cả 150 nhân viên và nhà thầu — bao gồm cả những người không có quyền truy cập vào hệ thống tài khoản khách hàng cơ bản — đại diện cho quyền truy cập rộng không phù hợp vào dữ liệu cá nhân.

Quyền xóa (Điều 17): Một chủ thể dữ liệu yêu cầu xóa dữ liệu cá nhân của họ có quyền xóa "không chậm trễ." Nếu dữ liệu của họ xuất hiện trong 23 bài viết cơ sở kiến thức dưới dạng ảnh chụp màn hình nhúng, yêu cầu xóa yêu cầu tìm và xử lý tất cả 23 bài viết — một nhiệm vụ vận hành khó khăn nếu không có phát hiện có hệ thống.

Việc Qua Mặt Kiểm Soát Truy Cập

Vấn đề tuân thủ quan trọng nhất với ảnh chụp màn hình wiki là việc qua mặt kiểm soát truy cập mà chúng tạo ra.

Các tổ chức hỗ trợ thường sử dụng RBAC để kiểm soát ai có thể truy cập hệ thống tài khoản khách hàng. Nhân viên cấp 1 truy cập thông tin tài khoản cơ bản. Nhân viên cấp 2 truy cập chi tiết thanh toán và kỹ thuật. Quản lý và quản trị viên truy cập hồ sơ tài khoản đầy đủ.

Khi một nhân viên cấp 2 tạo một bài viết cơ sở kiến thức với ảnh chụp màn hình của hồ sơ tài khoản khách hàng đầy đủ, ảnh chụp màn hình đó trở nên có thể truy cập cho tất cả người dùng wiki — bao gồm nhân viên cấp 1 không nên có quyền truy cập vào chi tiết thanh toán, nhà thầu không có quyền truy cập hệ thống nào cả và nhân viên mới trong quá trình đào tạo.

Ảnh chụp màn hình qua mặt các kiểm soát RBAC trên hệ thống tài khoản khách hàng. Dữ liệu cá nhân mà RBAC được thiết kế để bảo vệ hiện có thể truy cập được cho tất cả mọi người có quyền truy cập wiki.

Khắc Phục Thực Tế: Hồi Tố và Tiền Tố

Đối với các tổ chức phát hiện vấn đề này trong quá trình kiểm tra GDPR:

Khắc phục hồi tố:

  1. Xác định tất cả các trang wiki nội bộ có tệp đính kèm hình ảnh
  2. Chạy phát hiện PII hình ảnh trên tất cả tệp đính kèm hình ảnh
  3. Phân loại kết quả: hình ảnh có phát hiện PII có độ tin cậy cao được đánh dấu để xem xét
  4. Đối với hình ảnh được đánh dấu: hoặc thay thế bằng phiên bản được làm sạch hoặc thêm kiểm soát truy cập phù hợp vào trang wiki
  5. Ghi lại các hành động khắc phục cho hồ sơ trách nhiệm GDPR

Quy mô của việc khắc phục hồi tố phụ thuộc vào kích thước cơ sở kiến thức. Đối với cơ sở kiến thức 3 tuổi tại nhóm hỗ trợ 50 người, số lượng hình ảnh có thể lên đến hàng nghìn. Xử lý hình ảnh hàng loạt làm cho điều này khả thi; điểm tắc nghẽn chính là xem xét của con người đối với các hình ảnh được đánh dấu.

Kiểm soát tiền tố:

  1. Tài liệu quy trình: tất cả thành viên nhóm hỗ trợ được đào tạo để làm sạch ảnh chụp màn hình trước khi sử dụng wiki
  2. Hỗ trợ kỹ thuật: công cụ chú thích ảnh chụp màn hình (làm mờ tên khách hàng trước khi dán)
  3. Bước xem xét: người xem xét được chỉ định phê duyệt các bài viết wiki trước khi xuất bản, đặc biệt kiểm tra PII khách hàng trong hình ảnh
  4. Kiểm tra định kỳ: quét PII hình ảnh hàng loạt hàng quý của tất cả tệp đính kèm wiki

Kiểm soát khả thi tối thiểu (cho nhóm bị hạn chế tài nguyên): Danh sách kiểm tra xuất bản wiki bao gồm "Xóa hoặc làm mờ tất cả tên, email và ID tài khoản khách hàng khỏi ảnh chụp màn hình trước khi xuất bản." Công nghệ thấp, không tự động, nhưng tạo tài liệu về kiểm soát.

Tại Sao Vấn Đề Trở Nên Tệ Hơn Theo Thời Gian

Không có kiểm soát có hệ thống, vấn đề PII wiki nội bộ tăng theo thời gian:

Khối lượng: Mỗi bài viết cơ sở kiến thức mới với ảnh chụp màn hình khách hàng bổ sung vào tổng rủi ro PII. Khi nhóm hỗ trợ phát triển và cơ sở kiến thức mở rộng, PII tích lũy tăng tỷ lệ.

Bài viết bị lãng quên: Các bài viết ghi lại các trường hợp ngoại lệ cũ không còn xảy ra có thể bị lãng quên trong wiki nhưng vẫn có thể truy cập — chứa PII từ các khách hàng đã nộp yêu cầu xóa kể từ đó.

Lan rộng liên nhóm: Cơ sở kiến thức thường trở thành liên chức năng. Một bài viết hỗ trợ với ảnh chụp màn hình khách hàng có thể được chia sẻ với nhóm sản phẩm, nhóm kỹ thuật hoặc nhà thầu bên ngoài như ngữ cảnh cho một yêu cầu tính năng hoặc báo cáo lỗi.

Tồn đọng yêu cầu xóa: Khi nhiều dữ liệu khách hàng hơn tích lũy trong wiki, việc phản hồi các yêu cầu xóa trở nên phức tạp hơn. Không có phát hiện có hệ thống, không có cách đáng tin cậy để xác nhận rằng tất cả các trường hợp thông tin của một chủ thể dữ liệu đã được xác định và xóa.

Để tuân thủ GDPR, phát hiện nhất quán là PII cơ sở kiến thức dễ ngăn ngừa hơn là khắc phục. Kiểm soát tiền tố — được triển khai ngay bây giờ — tránh vấn đề khắc phục ngày càng tăng theo hàm mũ.

Nguồn:

Sẵn sàng bảo vệ dữ liệu của bạn?

Bắt đầu ẩn danh PII với 285+ loại thực thể trên 48 ngôn ngữ.

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.