PII de captures de pantalla en bases de coneixement internes
Les bases de coneixement internes: Confluence, Notion, SharePoint, GitBook, contenen un tipus especific de problema de PII que les eines de compliment estandard passen per alt: dades personals de clients incrustades en captures de pantalla usades per a documentacio de processos.
El patro es repeteix en milers d'equips de suport i operacions.
Un agent de suport troba una configuracio inusual de compte. Fa una captura de pantalla de la pagina del compte del client per documentar el problema. La captura mostra el nom del client a la capçalera de la interficie, el seu correu electronic a la configuracio del compte i els detalls del seu pla.
L'article es publica a la base de coneixement interna. Cent cinquanta agents de suport el poden veure ara. Dotze contractistes del helpdesk extern tambe el poden veure. L'article es util. Mostra com gestionar aquell cas limit. Cada agent que trobi aquella configuracio en el futur el llegira.
Tres anys despres, la base de coneixement te 847 articles d'aquest tipus. Cadascun conte captures de pantalla de comptes de clients. Els clients mostrats no van donar el seu consentiment per a aquest us secundari dels seus registres. La majoria no saben que les seves dades hi son emmagatzemades.
No es un problema petit. Creix amb cada nou article.
Exposicio al RGPD: per que importa
L'analisi del RGPD per a les captures de pantalla de les bases de coneixement es directa.
Minimitzacio de dades (Article 5(1)(c)): Les dades personals han de ser "adequades, pertinents i limitades al que es necessari". Un article de la base de coneixement sobre configuracio de comptes no necessita el nom i el correu electronic reals del client. Una captura difuminada compleix la mateixa finalitat. Incloure dades de clients reals no es necessari.
Limitacio de finalitat (Article 5(1)(b)): Les dades recollides per a una finalitat, el servei al client, no es poden reutilitzar per a una altra finalitat, la documentacio interna de processos, sense una base juridica. Els registres de compte es van recollir per a la prestacio del servei, no per a la documentacio interna. Aquests son dos proposits de tractament diferenciats. Usar els mateixos registres per als dos requereix una base juridica valida que la majoria d'equips no han establert.
Control d'acces (Article 5(1)(f) i Article 32): Les mesures tecniques adequades han de protegir les dades personals. Les captures de pantalla de comptes de clients en una eina oberta a tots els 150 agents i contractistes, inclosos aquells sense acces al sistema de compte subjacent, creen un acces excessivament ampli.
Dret a la supressi (Article 17): Un interessat que demana la supressi te el dret a que els seus registres siguin eliminats "sense dilaci indeguda". Si les seves dades apareixen en 23 articles de la base de coneixement com a captures de pantalla incrustades, la sollicitud requereix trobar i actualitzar els 23 articles. Aixo es dificil sense un sistema. La nostra guia del RGPD sobre el dret a la supressi cobreix els passos en detall.
Cap d'aquestes son lectures de casos extrems. Son aplicacions directes del text del reglament a una practica habitual.
El bypass del control d'acces
El problema de compliment mes greu amb les captures de pantalla a Confluence es el bypass del control d'acces que creen.
Els equips de suport utilitzen el control d'acces basat en rols (RBAC) per limitar qui pot veure els sistemes de comptes de clients. Els agents de nivell 1 veuen nomes els detalls basics del compte. Els agents de nivell 2 veuen els registres de facturacio i tecnics. Els gestors veuen el perfil complet del compte.
Quan un agent de nivell 2 crea un article de la base de coneixement amb una captura de pantalla del compte complet del client, aquesta captura es visible per a tots els usuaris de l'eina. Els agents de nivell 1 que no haurien de veure els registres de facturacio ara els poden veure. Els contractistes sense acces al sistema els poden veure. El personal nou en la incorporacio els pot veure.
La captura de pantalla eludeix els controls RBAC del sistema de comptes de clients. Les dades personals que el RBAC estava dissenyat per protegir ara estan obertes a tothom amb acces a la base de coneixement.
Aixo no es un risc teorico. Es el resultat normal del flux de treball de documentacio. La captura es queda alli sense data de caducitat, sense registre d'acces i sense rastre d'auditoria.
Passos practics de remediacio
Per als equips que troben aquest problema durant una auditoria del RGPD:
Remediacio retroactiva:
- Identifica totes les pagines de la base de coneixement amb adjunts d'imatge
- Executa la deteccio de PII en imatges en cada adjunt
- Revisa les imatges marcades: les coincidencies d'alta confianca van a la cua de revisio
- Per a cada imatge marcada: substitueix-la per una versio saneada o restringeix l'acces a la pagina
- Registra les accions de remediacio per als registres del RGPD
L'escala del treball retroactiu depen de la mida de la base de coneixement. Per a una base de coneixement de tres anys d'antiguitat en un equip de suport de 50 persones, el recompte d'imatges pot arribar a milers. El processament d'imatges per lots fa aixo factible. La revisio humana de les imatges marcades es el principal coll d'ampolla.
Controls prospectius:
- Forma tot el personal de suport per sanejar les captures de pantalla abans de publicar a la base de coneixement
- Proporciona eines: eines d'anotacio de captures que difuminen els noms dels clients abans d'enganxar
- Afegeix un pas de revisio: un revisor designat comprova els articles abans de publicar-los, buscant especificament PII de clients en les imatges
- Executa una exploracio d'imatges per lots trimestral en tots els adjunts de Confluence
Control minim viable: Una llista de comprovacio de publicacio: "Elimina o difumina tots els noms de clients, correus electronics i ID de compte de les captures de pantalla abans de publicar." Poc tecnic, no automatitzat, pero crea un control documentat. Per a equips petits, aquest es el punt de partida.
Consulteu el nostre resum de compliment RGPD per al marc legal mes ampli, i per que la politica sense controls tecnics falla per entendre per que els enfocaments basats nomes en llistes de comprovacio fallen a escala.
Per que el problema creix amb el temps
Sense controls sistematic, l'exposicio de PII a la base de coneixement s'acumula.
Volum: Cada nou article amb una captura de pantalla d'un client s'afegeix a l'exposicio total. A mesura que l'equip de suport creix i la base de coneixement s'expandeix, el PII acumulat tambe creix. Les propietats que fan utils aquestes eines: facilitat de publicacio, permanencia, acces ampli, son les que empitjoren el problema del PII.
Articles oblidats: Els articles sobre casos extrems antics que ja no es presenten segueixen sent accessibles. Contenen PII de clients que des d'aleshores han presentat sollicituds de supressi. Ningu comprova un article actualitzat per ultima vegada el 2022.
Difusio entre equips: Les bases de coneixement sovint es fan interfuncionals. Un article de suport amb captures de pantalla de clients es pot compartir amb l'equip de producte, l'equip d'enginyeria o contractistes externs per al context d'una sollicitud de funcionalitat o informe d'error. Cada comparticio amplia el public de les dades personals.
Acumulacio de sollicituds de supressi: A mesura que mes registres de clients s'acumulen a la base de coneixement, respondre a les sollicituds de supressi es fa mes complex. Sense un sistema, no hi ha manera fiable de confirmar que cada instancia dels registres d'un interessat ha estat trobada i eliminada. L'equip no pot fer una atestacio de supressi creible.
La PII de la base de coneixement es mes facil de prevenir que de solucionar. Els controls implementats ara eviten el problema de remediacio acumulada. Cada article publicat sense una captura difuminada es una tasca de remediacio ajornada al futur.