Metadata PII v regulovaných pracovních postupech dokumentů: Sanitizace souborů Office v Javě

💡 Kompletní funkční příklad je k dispozici na GitHubu:
remove-pii-from-office-metadata-java

Výzva v oblasti shody: Proč ruční kontrola metadat selhává při velkém objemu

Tým pro správu záznamů odešle 200 dokumentů externímu auditorovi. Někdo si přečetl každou stránku. Nikdo si neprohlédl vlastnosti, a právě v nich se nacházejí osobní údaje: analytik v Author, druhý analytik v LastSavedBy, vedoucí oddělení v Manager, dceřiná společnost v Company, časové razítko LastPrinted z noci před termínem a na všem, co prošlo SharePointem, ID schvalujícího a cesta pracovního postupu.

Sanitizace metadat je workflow GroupDocs.Metadata pro Java, které odstraňuje tyto identifikující vlastnosti z Word, Excel a PowerPoint souborů a poté výsledek načte zpět, aby nahlásilo, co přežilo. Tento článek provádí krok za krokem workflow, jak by jej postavila tým pro shodu: jaké skupiny vlastností existují, které pravidlo odstranění k nim patří, kdy úplné vymazání nahradí cílené průchody a proč by měla verifikace patřit do stejného úkolu místo kontrolního seznamu.

Problém měřítka není v tom, že je odstranění obtížné. Problém je v tom, že ruční kontrola nevytváří záznam. Auditor, který se ptá „která pole byla z tohoto souboru odstraněna a kdy“, potřebuje číslo, a dialog vlastností žádné neposkytuje.

Proč obecné nástroje na úklid zde nefungují

Dialog vlastností Windows upravuje jeden soubor najednou a dosahuje jen podmnožiny polí. Inspektor dokumentů v Office běží interaktivně, což ho vylučuje z nočního úkolu. Oba ponechávají neporušené vlastní OOXML části a žádný z nich neukládá nic, co by pipeline mohla zpětně načíst.

Týmy, které jdou o úroveň níž a upravují docProps/core.xml a docProps/custom.xml přímo, přebírají údržbové břemeno: XPath výraz pro každé pole, pro každý formát, který je nutné znovu projít pokaždé, když produkční aplikace změní název. Tato práce také špatně řeší otázku klasifikace. Názvy vlastností se liší mezi balíčky, takže seznam názvů tiše zastarává a pravidlo, které už neodpovídá, vypadá stejně jako soubor, který byl již čistý.

Řešení: GroupDocs.Metadata v workflow pro správu záznamů

GroupDocs.Metadata pro Java provádí vše přes jeden vyhledávač vlastností. Objekt Specification rozhoduje, které vlastnosti odpovídají, removeProperties každou shodu smaže a vrátí počet ovlivněných položek a findProperties spustí stejný predikát jen pro čtení. Vlastnosti nesou značky, takže Tags.getPerson().getCreator() identifikuje pole typu autor bez ohledu na formát nebo balíček, ze kterého pocházejí.

Java nemá lambda přetížení pro removeProperties, což se zde ukazuje jako výhoda: každé pravidlo je objekt a objekty jsou znovupoužitelné. Stejná instance specifikace, která vymaže skupinu, může být předána ověřovacímu skenu, takže kontrola nemůže odklonit od úklidu, který má testovat.

Implementace kroku sanitizace pipeline krok za krokem

Krok 1 – Vymazání skupiny identit podle značky

Čtyři specifikace značek spojené pomocí .or(...) pokrývají tvůrce, editora, manažera a společnost. Nic dalšího se nepřesouvá, takže Title, Subject a Keywords zůstávají dostupné pro index záznamů.

try (Metadata metadata = new Metadata(inputPath)) {
    if (metadata.getFileFormat() == FileFormat.Unknown) return 0;
    int affected = metadata.removeProperties(
            new ContainsTagSpecification(Tags.getPerson().getCreator())
                .or(new ContainsTagSpecification(Tags.getPerson().getEditor()))
                .or(new ContainsTagSpecification(Tags.getPerson().getManager()))
                .or(new ContainsTagSpecification(Tags.getCorporate().getCompany())));
    metadata.save(outputPath);
    return affected;
}

Ochrana FileFormat.Unknown má větší význam, než se na první pohled zdá. Bez ní nečitelné soubory vrátí nulu odstranění, což volající nemůže odlišit od dokumentu, který byl při přijetí již čistý.

Krok 2 – Vymazání rodin polí podle názvu

Vlákna komentářů, počítadla revizí a serverová pole nemají značku, takže jsou vyhledávána podle názvu. Malá podtřída Specification přijímá seznam podřetězců, což umožňuje jedné třídě sloužit třem průchodům:

public class NameContainsSpec extends Specification {
    private final String[] needles;

    public NameContainsSpec(String... needles) {
        this.needles = needles;
    }

    @Override
    public boolean isSatisfiedBy(MetadataProperty candidate) {
        String name = candidate.getName();
        if (name == null) return false;
        for (String n : needles) {
            if (name.contains(n)) return true;
        }
        return false;
    }
}

Časová osa úprav je pro skupiny shody nejdůležitější, protože počet revizí a datum posledního tisku popisují, jak byl dokument vytvořen:

try (Metadata metadata = new Metadata(inputPath)) {
    if (metadata.getFileFormat() == FileFormat.Unknown) return 0;
    int affected = metadata.removeProperties(new NameContainsSpec(
            "Revision", "TrackedChange", "LastPrinted", "TotalEditingTime", "EditTime"));
    metadata.save(outputPath);
    return affected;
}

Průchod pro komentáře a průchod pro SharePoint jsou stejná volání s různými seznamy podřetězců: Comment, Reviewer, Reviewed pro stopy recenzí a Server, Workflow, Approver, ContentType, Template pro pole serveru dokumentu.

Krok 3 – Vymazání na hranici

Když soubor opustí organizaci, selektivita přestává mít cenu. Jedno volání vymaže každý balíček metadat, který knihovna detekuje, včetně vlastních OOXML částí, na které žádný cílený predikát nehlédá:

try (Metadata metadata = new Metadata(inputPath)) {
    if (metadata.getFileFormat() == FileFormat.Unknown) return 0;
    int affected = metadata.sanitize();
    metadata.save(outputPath);
    return affected;
}

Krok 4 – Ověření a klasifikace toho, co zůstalo

Sken provede sjednocení všech pravidel pomocí findProperties a rozřadí výsledky do dvou seznamů. Prázdné hodnoty a nulové počítadla jsou přeskočeny a položky, jejichž názvy začínají na Comment, Revision nebo Inspection, jsou obaly nad obsahem těla místo metadat:

String value = "";
if (p.getValue() != null && p.getValue().getRawValue() != null) {
    value = String.valueOf(p.getValue().getRawValue());
}
if (value.isEmpty() || value.equals("0") || value.equals("0.0")) continue;
String entry = p.getName() + "=" + value;
String name = p.getName() == null ? "" : p.getName();
if (name.startsWith("Comment") || name.startsWith("Revision")
        || name.startsWith("Inspection")) {
    report.contentLevelLeaks.add(entry);
} else {
    report.metadataLeaks.add(entry);
}

Rozdělení je to, co udržuje signál procházení/selhání poctivý. Úniky metadat musí být prázdné. Úniky na úrovni obsahu zůstávají informační, protože komentáře Wordu a autoři sledovaných změn žijí uvnitř word/document.xml a knihovna metadat je hlásí, aniž by je upravovala; jejich odstranění vyžaduje knihovnu pro úpravu obsahu, jako je Aspose.Words.

Kdy je cílený průchod lepší než úplná sanitizace?

Vždy, když dokument stále podléhá práci. Soubor cirkulující mezi recenzenty potřebuje Title, Subject a Keywords pro vyhledávání a klasifikaci záznamů, a sanitize() odstraní všechna tři. Proveďte průchody identit a komentářů během spolupráce, zachovejte popisná pole a úplné vymazání nechte na okamžik, kdy soubor přejde hranici k externí straně.

Reálný workflow: Exportní úloha pro externího auditora

Představte si noční úkol. Načte seznam ID dokumentů, zkopíruje každý soubor do pracovní složky, použije průchod identit a průchod serveru, zavolá sanitize() na vše, co je označeno jako opouštějící organizaci, a pak spustí kontrolu úniků proti uložené kopii. Každý krok přidá svůj počet ovlivněných položek do jednoho řádku logu na soubor a neprázdný seznam úniků metadat způsobí selhání úlohy místo varování v logu.

Jednou jsem strávil odpoledne verzí této úlohy, která hlásila nulu odstranění u 40 souborů a vypadala jako čistá dávka. Vstupní složka obsahovala staré binární .doc soubory, ochrana formátu vracela okamžitě u každého z nich a v logu se neodlišovalo „nic k odstranění“ od „nic nebylo načteno“. Zaznamenání formátu spolu s počtem to opravilo.

Obchodní dopad: Co se tím mění

Další scénáře, kde GroupDocs.Metadata zapadá

Stejný engine pro vlastnosti čte i odstraňuje. Porovnání metadat mezi dvěma verzemi dokumentu ukazuje, co změnil editovací kol, což je užitečné při sporech o vlastnictví a při hledání souboru, který byl přepsán mimo proces. Práce s metadata tags místo názvů je to, co dělá oba případy přenositelné mezi DOCX, XLSX, PPTX, PDF a obrazovými formáty.

Začínáme s GroupDocs.Metadata pro Java

Přidejte repozitář GroupDocs Java do pom.xml a závislost na com.groupdocs:groupdocs-metadata. Knihovna běží v režimu hodnocení bez licence, což stačí k provedení všech šesti operací na ukázkovém DOCX a ke zhlédnutí počtů. Začněte s průchodem identit, přidejte průchody rodin polí podle toho, co vaše zdroje dokumentů vyžadují, a zapojte kontrolu úniků dříve, než se cokoli dostane do produkce.

Zdroje

• Kompletní Java ukázkový projekt na GitHubu
• Průvodce krok za krokem – případové použití
• Odstraňování vlastností metadat
• Dokumentace GroupDocs.Metadata pro Java
• API reference
• Free support forum