💡 Tam çalışan örnek GitHub’da mevcuttur: sanitize-office-document-pii-python

Göndermeden Önce Kimsenin İnceleme Yapmadığı Veriler

Üç aylık bir yönetim kurulu raporu dış denetçiye gönderilir. Metin kusursuzdur; üç inceleme döngüsü bunu garantilemiştir. Dosyanın kendisi başka bir hikaye. Özellikleri hâlâ raporu hazırlayan analisti, yeniden düzenleyen yöneticiyi, şablonu sahip olan şirket yan kuruluşunu, son teslim tarihinden bir gece önceki LastPrinted zaman damgasını ve iç onay iş akışından bir SharePoint onaylayıcı kimliğini içerir. Bunların hiçbiri herhangi bir sayfada görünmez. Hepsi dosyayla birlikte taşınır.

PII kaldırma, .NET üzerinden Python için bir GroupDocs.Metadata iş akışıdır ve bu kimlik bilgisi taşıyan özellikleri Word, Excel ve PowerPoint dosyalarından programlı olarak temizler. Bu makale API’nin sunduğu üç yaklaşımı karşılaştırıyor: kimlik alanları için etiket tabanlı kaldırma, yorumlar ve revizyonlar gibi özellik aileleri için ad‑deseni kaldırma ve her şeyi temizleyen tek çağrı sanitize(). Ayrıca çoğu temizleme betiğinin atladığı, temizliğin gerçekten gerçekleştiğini kanıtlayan bir doğrulama taramasını da göreceksiniz.

Neden Metadata PII Kendi İş Akışını Gerektirir

İçerik inceleme araçları insanların ne okuduğunu kontrol eder. Dosya sistemlerinin ne depoladığını kontrol etmezler ve bu boşluk, uyumluluk olaylarının kaynağıdır. GDPR talebi, yazar ve yönetici alanlarındaki kişisel verileri, metindeki veriler kadar kapsar. Hukuki keşif, bir pozisyon belgesinin ne kadar süreyle müzakere edildiğini yeniden oluşturmak için revizyon sayacı ve düzenleme süresi toplamlarını okur. Teklif inceleyenler, SharePoint iş akışı özelliklerinden organizasyon yapınızı haritalayabilir ve bir basın bülteni yorum alanları, taslak aşamasındaki notların yanında inceleyen isimlerini korur. Bunların her biri bir bulgudur. Hiçbiri belge gövdesinde görünmez.

Önkoşullar

  • pip ile Python 3
  • GroupDocs.Metadata for Python via .NET, örnek deposunda 26.5 sürümüne sabitlenmiş
  • Uygulama yapmak için gerçek özelliklere sahip bir Office dosyası

Kurulum

pip install groupdocs-metadata-net==26.5

Eşlik eden depo (companion repository) bir örnek DOCX oluşturur ve aşağıdaki her kod parçacığını doğrulanmış bir iş akışı olarak çalıştırır.

Yöntem 1: Etiket Tabanlı Kimlik Kaldırma

En hassas dört alan, Author, LastSavedBy, Manager ve Company, Office formatları arasında farklı iç adlara sahiptir. Etiket sistemi bunu çözer: özellikleri adlandırmak yerine, koşul (predicate) kişi veya şirket olarak etiketlenmiş her şeyi ister.

# Match identity properties by meaning, not by format-specific name
with Metadata("board-report.docx") as metadata:
    removed = metadata.remove_properties(lambda p:
        Tags.person.creator in list(p.tags)     # Author, LastSavedBy
        or Tags.person.editor in list(p.tags)
        or Tags.person.manager in list(p.tags)
        or Tags.corporate.company in list(p.tags))
    metadata.save("board-report-clean.docx")

print(f"{removed} identity properties removed")

Ana noktalar:

  • Format bağımsızlığı: aynı lambda, etiketler rol göre sınıflandırdığı için DOCX, XLSX ve PPTX dosyalarını temizler.
  • Sayılabilir sonuç: remove_properties eşleşen özellik sayısını döndürür; bu, denetim kaydınıza eklenmelidir.
  • Kopya semantiği: yeni bir yola kaydetmek, orijinali kayıtlarınız için tutar.

💡 İpucu: bu geçiş Title, Subject ve diğer tanımlayıcı alanları korur, böylece dosya arama ve DMS indekslemesi için dost kalır.

Yöntem 2: Özellik Aileleri için Ad‑Deseni Kaldırma

Etiketler sınıflandırılmış kavramları kapsar. Sızıntı yapan alanların tüm aileleri bu sınıflandırmanın dışındadır: yorum özellikleri, revizyon sayacı, SharePoint iş akışı damgaları. Bunlar için, doğrudan özellik adını eşleştirin.

# Comment fields often live in custom properties the tag system
# does not classify, so match them by name substring
with Metadata("board-report.docx") as metadata:
    removed = metadata.remove_properties(lambda p:
        p.name is not None and (
            "Comment" in p.name
            or "Reviewer" in p.name
            or "Reviewed" in p.name))
    metadata.save("board-report-no-comments.docx")

Aynı yapı diğer iki aileyi de işler; sadece alt dize listesi değişir:

Aile Eşleşecek Alt Dize
Revizyon izi Revision, TrackedChange, LastPrinted, TotalEditingTime, EditTime
Sunucu / iş akışı Server, Workflow, Approver, ContentType, Template

Bu, hassasiyeti kapsama genişliğiyle değiştirir: "Comment" aynı zamanda Comments ve CommentCount değerlerini de yakalar; bu genellikle bir temizleme geçişinin istediği şeydir. Geniş alt dizeler zararsız şablon alanlarını da eşleştirebilir, bu yüzden dönen sayıyı beklentilerle denetleyin.

💡 İpucu: denetim kaydınız kategori bazlı sayımlara ihtiyaç duyduğunda her aileyi ayrı bir geçiş olarak çalıştırın; ihtiyacınız yoksa alt dizeleri tek bir koşulda birleştirin.

Yöntem 3: Tek Çağrı Tam Temizleme

Dosya organizasyondan çıkarken ve metadata katmanında hiçbir şey kalmaması gerektiğinde, koşul (predicate) yazmayı bırakın.

# One call, every detected metadata package
with Metadata("board-report.docx") as metadata:
    removed = metadata.sanitize()
    metadata.save("board-report-final.docx")

print(f"sanitize() removed {removed} properties")

sanitize() kütüphanenin tespit ettiği her paketi temizler: belge‑bilgi kimlik alanları, yorumlar, revizyon geçmişi, izlenen değişiklik yazarları ve özel OOXML bölümleri. Davranış, Clean metadata sayfasında belgelenmiştir. Gücü aynı zamanda maliyetidir. Title ve Subject, PII ile birlikte kaybolur; bu yüzden iş birliği akışının ortasında değil, dışa aktarım noktasında kullanılmalıdır.

Dört Hedefli Geçişin Hepsine İhtiyacım Var mı?

Hayır. Her geçiş, farklı bir ekibin riski sahip olduğu için vardır. Kimlik alanları gizlilik görevlilerini, yorum izleri hukuk birimlerini, revizyon sayacı müzakerecileri ve sunucu alanları güvenliği rahatsız eder. İnceleme yapanlarınıza göre geçişleri, herhangi bir sırada çalıştırın; çünkü her biri kendi çıktı kopyasını yazar. Kimse hayatta kalan alanlara ihtiyaç duymadığında, doğrudan sanitize()‘a geçin ve doğrulayın.

Üç Yaklaşımı Karşılaştırma

Yöntem En İyi Kullanım Ana Avantajlar Sınırlamalar
Tag-driven removal Çalışan kopyalar, çoklu format iş akışları Format bağımsız, tanımlayıcı alanları korur Sadece etiket sınıflandırmalı kavramları kapsar
Name-pattern removal Yorumlar, revizyonlar, sunucu alanları Etiketlerin kaçırdığı özel özelliklere ulaşır Alt dizeler ortam başına ayarlanmalıdır
Full sanitize() Organizasyon dışındaki son dışa aktarım Unutulmuş bir özelliği kaçırmaz Zararsız alanları da siler

Yaklaşımlar doğal olarak birleştirilebilir: belge hâlâ aktifken hedefli geçişler, gönderilirken sanitize().

Güvenmeden Önce Doğrulayın

Bir kaldırma çağrısının bir sayı döndürmesi, dosyanın temiz olduğunun kanıtı değildir. Depo, her çalıştırmayı temizlenmiş çıktıyı yeniden açarak ve find_properties ile tarayarak sonlandırır; bu, yukarıdaki tüm geçişlerin etiket kurallarını ve ad kurallarını birleştiren bir koşul (predicate) kullanır.

def is_pii(p):
    if p.name is None:
        return False
    return (
        Tags.person.creator in list(p.tags)
        or Tags.person.editor in list(p.tags)
        or Tags.person.manager in list(p.tags)
        or Tags.corporate.company in list(p.tags)
        or any(n in p.name for n in (
            "Comment", "Reviewer", "Revision", "TrackedChange",
            "Classification", "Department", "Server", "Workflow")))

with Metadata("board-report-final.docx") as metadata:
    for p in metadata.find_properties(is_pii):
        value = (str(p.interpreted_value) if p.interpreted_value is not None
                 else (str(p.value) if p.value is not None else ""))
        if value and value not in ("0", "0.0"):
            print(f"LEAK {p.name}={value}")

Depodaki tam sürüm, kalanları iki kovaya ayırır ve bu ayrım önemlidir. Metadata sızıntıları sıfır olmalıdır. İçerik seviyesindeki kalıntılar, word/document.xml içinde yaşayan Word yorum balonları ve izlenen değişiklikler, bir metadata API’sinin erişemediği gövde içeriğidir; bunları kaldırmak Aspose.Words gibi bir içerik düzenleme kütüphanesi gerektirir. Dürüst bir rapor, ilk aşamada zafer ilan etmek yerine her iki kovayı da adlandırır. Bu taramayı “temiz” bir dosyada ilk kez çalıştırdığımda, bir şirket şablonunun aylarca sessizce eklediği Department alanını işaretledi.

En İyi Uygulamalar ve İpuçları

  • Kopyaları temizleyin, asılları asla: burada her kod parçacığı yeni bir yola yazar, kaynağı kayıtlarınız ve saklama kurallarınız için tutar.
  • Sayıları kaydedin: remove_properties ve sanitize()‘ın dönüş değerleri denetim izinizdir. Bunları dosya başına, geçiş başına saklayın.
  • Doğrulamayı CI’ye entegre edin: derlemeyi başarısız kılan bir sızıntı kontrolü, şablon gerilemelerini gerçekleştiği gün yakalar, müşterinin fark ettiği gün değil.
  • metadata/içerik sınırına dikkat edin: gövde seviyesindeki yorumlar hâlâ mevcutken dosyayı temiz olarak raporlamayın; bunları ayrı bir bulgu olarak ortaya koyun.
  • Lisanslama: değerlendirme modu bu makaledeki her şeyi yeniden üretir; üretimde bir lisans kullanın, böylece değerlendirme işaretleri dışa çıkan dosyalara dokunmaz.

Sonuç

Üç yaklaşım, bir karar kuralı. Kavram sınıflandırılmışsa ve dosyanın kullanılabilir kalması gerekiyorsa etiketle eşleştirin. Aile özel özelliklerde ise adla eşleştirin. Dosya güven sınırını geçtiğinde sanitize()‘ı çağırın ve hangi yolu izlerseniz izleyin, geri okuma taramasıyla doğrulayın.

Daha derine gitmeye hazır mısınız? İşte bazı sonraki adımlar:

  • Predicate yüzeyini Remove metadata properties dokümantasyon sayfasında inceleyin
  • Aynı kod üzerine inşa edilmiş step-by-step use case guide rehberini izleyin
  • [sample repository]‘yi klonlayın ve doğrulanmış iş akışını kendi dosyalarınızda çalıştırın

Ek Kaynaklar

Sorularınız mı var ya da uygulamanızı paylaşmak mı istiyorsunuz? support forumda bize ulaşın.