Transformacija u upitu
Brza demonstracija ili kontrolisan izveštaj, ali ne sprečava direktno čitanje izvornih podataka.
Kako implementirati PII maskiranje: metode, arhitektura i SQL primeri
Kako tehnički zaštititi podatke o ličnosti za analitiku: metode maskiranja, pristupna prava, testovi i primer sa sintetičkim podacima penzionog fonda u ClickHouse-u.
5. novembar 2026.
- PII maskiranje počinje klasifikacijom, svrhom i pristupnim pravima, a ne SQL funkcijom.
- Maskiranje u upitu, Views, politike po ulogama i transformacije pri unosu imaju različite granice.
- ClickHouse i fiktivni penzioni fond služe kao tehnički primer, ne kao centralna tema teksta.
Implementacija PII maskiranja: problem je pristup podacima
PII maskiranje skriva ili menja podatke o ličnosti za određene korisnike, tokove ili svrhe, a zadržava mogućnost dozvoljene analitike. To nije funkcija jednog proizvoda. Bilo da su podaci u bazi, warehouse sistemu, pipeline procesu ili API-ju, prvo treba odrediti osetljiva polja i granice pristupa.
SQL funkcija može sakriti ime, ali time nisu automatski zaštićeni izvorna tabela, druge uloge, eksport, backup ili male grupe. Prava implementacija polazi od potrebnog rezultata, bira odgovarajuću tačku kontrole i proverava ponašanje za dozvoljene i nedozvoljene korisnike.
Kao praktičan primer koristimo samo sintetičke podatke iz izmišljenog penzionog fonda i ClickHouse SQL. Ista logika važi za osiguranje, zdravstvo i druge organizacije.
Metode maskiranja i njihova ograničenja
Statičko maskiranje menja kopiju ili tok pre deljenja. Dinamičko maskiranje menja vrednost pri izvršavanju upita, često u zavisnosti od uloge. Potpuna redakcija zamenjuje celo polje, a delimično maskiranje ostavlja pojedine delove. Ako je za analitiku potreban samo zbirni pokazatelj, uklanjanje identifikatora ili agregacija mogu biti bolji izbor.
Maskiranje nije automatski anonimizacija. Izvorni podaci često ostaju sačuvani. Delimične vrednosti, stabilni ključevi i retke kombinacije mogu dovesti do identifikacije. Pseudonimizacija, tokenizacija i kriptografske metode imaju dodatne zahteve za čuvanje mapa, ključeva i upravljanje životnim ciklusom.
PII maskiranje je proces kroz ceo tok podataka
Najpre se evidentiraju podaci o ličnosti u izvornim tabelama, događajima, fajlovima, logovima i povezanim proizvodima. Definišu se dozvoljena svrha, osetljivost i korisnici kojima su pojedina polja stvarno potrebna. Katalog pomaže u dokumentaciji, ali pristup se sprovodi u bazi, identitetskom sistemu, API-ju i pri izvozu.
Zatim se definišu data proizvodi i uloge. Za zbirne izveštaje uklanjaju se nepotrebni identifikatori. Za detaljne upite bira se kontrolisani View, dinamička politika ili transformacija pre unosa. Na kraju se proveravaju dozvoljeni i zabranjeni pristupi i održavaju kontrole tokom promena šeme.
Penzioni fond služi samo kao ilustracija. Isto važi za podatke o polisama, pacijentima, zaposlenima i klijentima.
Kako odabrati postupak maskiranja
Kontrolisani View
Stabilan interfejs sa ograničenim poljima; korisnik ne sme imati alternativan pristup sirovim podacima.
Dinamička politika
Prikaz zavisi od uloge i mora biti podržan u konkretnom sistemu.
Transformacija pri unosu
Primerena kada originalni PII ne treba uopšte čuvati u analitičkom sloju.
Minimizacija i agregacija
Često najbolji pristup za zbirnu analitiku, uz proveru malih grupa i zaključivanja iz ponovljenih upita.
Praktičan primer: uloge, potrebe i model pretnji
Najpre razlikujemo zaposlene koji obrađuju pojedinačne zahteve članova, analitičare, administratore platforme i spoljne primaoce podataka. Obradi konkretnog predmeta mogu biti potrebni lični identifikatori. Analitici fonda su obično potrebne ukupne obaveze, trendovi i odobreni segmenti, ali ne i imena ili brojevi računa. Administratorski nalog ne znači automatski i pravo poslovnog uvida u podatke svih članova.
Klasifikacija ne obuhvata samo očigledne PII kolone. `member_id` i `pension_account` jesu stabilni identifikatori koji omogućavaju povezivanje. Čak i finansijski iznos može postati identifikujući kada u izabranoj grupi ima veoma malo članova. Retka kombinacija fonda, perioda i neuobičajeno velikog iznosa može otkriti osobu i bez prikazanog imena.
Iz ovoga proizlaze proverljivi zahtevi: ograničiti sirove identifikatore, razdvojiti uloge, beležiti pristup i izvoz, kontrolisati detaljne upite i razmotriti rizik malih grupa. Dinamičko maskiranje je samo jedna od mera.
Uloge u primeru, primenljive i u drugim sektorima
Operativna obrada članova
Identitet je dostupan za konkretan opravdan postupak, ne za masovni izvoz svih članova fonda.
Analitika i kontroling
Pristup odobrenim zbirnim pokazateljima. Identifikatori se uklanjaju ili maskiraju samo tamo gde je detaljan prikaz opravdan.
Administracija platforme
Najmanje potrebne privilegije i poseban, odobren i proverljiv postupak za privilegovani uvid.
Spoljni korisnici
Podaci ograničeni svrhom, definisanim nivoom detalja, kontrolom izvoza i rokovima čuvanja.
Sintetički podaci za demonstraciju
-- Primer: isključivo sintetički podaci
CREATE TABLE pension_members (
member_id UInt64,
full_name String,
email String,
pension_account String,
fund_id String,
accrued_pension_eur Decimal(14, 2)
) ENGINE = MergeTree
ORDER BY
(fund_id, member_id);
INSERT INTO
pension_members
VALUES
(
101,
'Mara Primer',
'mara@example.invalid',
'PF-000101',
'FUND-A',
128500.00
),
(
102,
'Luka Primer',
'luka@example.invalid',
'PF-000102',
'FUND-A',
91200.00
);
Pristup 1: maskiranje u samom SQL upitu
SQL funkcije mogu zameniti vrednosti u rezultatu. To je korisno za demonstraciju, ali samo po sebi ne ograničava prava na izvornu tabelu. Korisnik koji ima direktan pristup može pokrenuti drugi upit i videti originalne vrednosti.
Delimično sakrivanje e-mail adrese može biti korisno u određenim procesima podrške, ali i dalje otkriva identifikacione fragmente. Kada dodatni detalji nisu potrebni, prednost imaju potpuno maskiranje ili izostavljanje polja.
Maskiranje u upitu pomoću SQL funkcija
-- Ad-hoc masking does NOT restrict underlying table access
SELECT
fund_id,
'[MASKED]' AS member_name,
concat (
substring(email, 1, 2),
'****',
substring(email, position(email, '@'))
) AS email_preview,
accrued_pension_eur
FROM
pension_members
ORDER BY
fund_id;
Pristup 2: kontrolisani View
View definiše dozvoljena polja i menja prikaz direktnih identifikatora. Uloga koja koristi View ne sme imati i pristup izvornoj tabeli ili njenim kopijama. Prava i kontekst izvršavanja View-a moraju se praktično testirati.
Primeri različitih postupaka su alternative, ne skup SQL naredbi koje treba bez provere sve izvršiti u istoj bazi.
Prava pristupa i bezbednost kontrolisanog View-a
Običan ClickHouse View uglavnom zahteva da korisnik ima prava na izvornu tabelu. Za korisnika koji sme da vidi samo odobreni View koristimo SQL SECURITY DEFINER i namenski nalog sa minimalnim pravima. Analitičar dobija SELECT na View, a ne na sirovu tabelu. Prava definera i alternativni pristupi moraju se posebno proveriti.
Maskirani View za analitiku
-- Izvršiti kao namenski View owner sa minimalnim pravima
-- SQL SECURITY DEFINER ne zahteva raw-table prava za čitaoca
CREATE VIEW pension_members_masked DEFINER = CURRENT_USER SQL SECURITY DEFINER AS
SELECT
fund_id,
'[MASKIRANO]' AS full_name,
'[MASKIRANO]' AS email,
accrued_pension_eur
FROM
pension_members;
-- Posebno proveriti i ograničiti privilegije vlasnika.
Prava pristupa samo kontrolisanom View-u
-- This role must not also receive direct raw-table access
CREATE ROLE pension_view_reader;
GRANT
SELECT
ON pension_members_masked TO pension_view_reader;
-- This account must already exist; review inherited grants
GRANT pension_view_reader TO reporting_reader;
Klasifikacija polja pre definisanja pravila
Primer sadrži direktne identifikatore (`full_name`, `email`, `pension_account`), stabilni ključ (`member_id`) i polja za analitiku (`fund_id`, `accrued_pension_eur`). Klasifikaciju treba dokumentovati zajedno sa svrhom, vlasnikom podataka, dozvoljenim ulogama i rokovima čuvanja.
Dva sintetička reda dovoljna su za demonstraciju SQL-a, ali nisu dokaz statističke ili bezbednosne zaštite. U test okruženju treba obuhvatiti prazne vrednosti, duplikate, promene uloga, neobične JOIN operacije, alternativne naloge i male grupe.
Kada su potrebni samo agregati, analitičkom timu je često bolje ponuditi zaseban odobren data proizvod bez identifikatora. Dinamičko maskiranje ima smisla kada legitimni korisnici iste tabele treba da vide različite prikaze.
Inventar kolona nije automatska PII klasifikacija
Metapodaci prikazuju kolone i tipove, ali sami ne određuju rizik. Stabilni identifikator člana ili neuobičajen iznos mogu omogućiti povezivanje sa osobom i kada naziv kolone ne sadrži očigledan PII pojam.
Klasifikaciju dopunjuju poslovna svrha, vlasnik podataka, dozvoljene uloge, rokovi čuvanja i ograničenja izvoza.
Pregled kolona kao početak klasifikacije
-- Metadata inventory only; human classification still required
SELECT
name,
type
FROM
system.columns
WHERE
database = currentDatabase ()
AND table = 'pension_members'
ORDER BY
position;
Pristup 3: dinamičke masking politike po ulogama
Nativne politike maskiranja mogu biti primerene kada različite legitimne uloge koriste istu fizičku tabelu, ali ne smeju videti iste podatke. ClickHouse Cloud dokumentuje ovu funkcionalnost od verzije 25.12. Analitička uloga u primeru vidi fiksne zamenske vrednosti za direktne identifikatore.
Sama politika nije dovoljna. Prava se ograničavaju na potrebne kolone, nepotrebni member_id namerno se izostavlja, a nasleđene dozvole i alternativni pristupi sirovim podacima moraju se proveriti. Ista logika važi i za druge platforme, uz različitu sintaksu.
Masking Policy po ulogama
-- ClickHouse Cloud 25.12+: izvorna masking politika
CREATE ROLE pension_analyst;
CREATE MASKING POLICY pension_member_pii ON pension_members
UPDATE full_name = '[MASKIRANO]',
email = '[MASKIRANO]',
pension_account = '[MASKIRANO]' TO pension_analyst;
-- Samo potrebne kolone; member_id se namerno izostavlja
GRANT
SELECT
(
full_name,
email,
pension_account,
fund_id,
accrued_pension_eur
) ON pension_members TO pension_analyst;
-- Korisnik analytics_reader mora prethodno da postoji
GRANT pension_analyst TO analytics_reader;
Zašto masking politika ne zamenjuje ograničenje pristupa
Masking Policy menja vrednosti koje dobija dodeljena uloga u trenutku izvršavanja upita. Originalni podaci ostaju sačuvani. Pravilo ne ukida druga prava i ne štiti kopije u povezanim sistemima. Zato se prava pristupa i masking izraz moraju testirati zajedno.
Analitičkoj ulozi dodeljujemo samo potrebne kolone. Nepromenjeni `member_id` nije neophodan za agregatne analize i ne treba ga dodeljivati. Takođe se proveravaju nasleđene dozvole, dodatni nalozi, servisi i izvoz. Jedan uspešno maskiran SELECT nije dokaz zaštite celog sistema.
Nativne masking politike dokumentovane su za ClickHouse Cloud od verzije 25.12. Pre uvođenja proveriti stvarno izdanje, verziju i evaluaciju pravila: https://clickhouse.com/docs/products/cloud/guides/security/data-masking.
Provera efektivnih prava i politika
-- Izvršava administrator sa odgovarajućim pravima:
SHOW MASKING POLICIES;
SHOW GRANTS FOR analytics_reader;
-- Ponovo se povezati kao analitički korisnik:
SELECT
fund_id,
full_name,
email,
pension_account
FROM
pension_members
LIMIT
10;
-- Očekivanje: prikazane vrednosti identifikatora su maskirane.
-- Testirati i druge naloge, role i puteve pristupa.
Pozitivni i negativni testovi sa stvarnom ulogom
Pozitivnim testom proverava se da li analitički korisnik vidi maskirane vrednosti. Negativnim se proverava da li je zabranjen pristup nepotrebnom identifikatoru. Testovi se izvršavaju sa stvarnim korisničkim nalogom aplikacije, ne kao administrator.
Treba proveriti i nasleđene role, servisne naloge, direktna prava, izvoz, kopije i promene šeme. Jedan uspešan maskirani upit nije dokaz zaštite celog sistema.
Pozitivni test analitičke uloge
-- Reconnect as analytics_reader; ensure pension_analyst is active
SELECT
full_name,
email,
pension_account,
fund_id
FROM
pension_members
LIMIT
10;
-- Expect masked identifiers, not raw values.
Negativni test: zabranjena ID kolona
-- Run as analytics_reader, not as an administrator
SELECT
member_id
FROM
pension_members
LIMIT
1;
-- Expect ACCESS_DENIED; otherwise examine effective grants.
Bezbednija analitika: manje podataka i kontrolisani rezultati
Sledeći zbirni upit pokazuje predviđenu poslovnu upotrebu. U produkcionoj arhitekturi analitičari bi po pravilu trebalo da pristupaju jasno odobrenim data proizvodima. Čak i uz maskirana imena, detaljni zapisi mogu omogućiti zaključivanje o pojedincima.
Potrebni su klasifikacija podataka, odvojene uloge, revizijski logovi, kontrola izvoza i pravila čuvanja i brisanja. Za testiranje su pogodniji sintetički podaci ili zasebno provereni postupci pseudonimizacije.
Agregacija poslovnih pokazatelja
-- Upit analitičkog korisnika
SELECT
fund_id,
count() AS members,
sum(accrued_pension_eur) AS liabilities_eur
FROM
pension_members
GROUP BY
fund_id;
-- Provera pravila maskiranja
SHOW MASKING POLICIES;
I agregirani rezultati mogu otkriti pojedinca
U izveštaju nije neophodno prikazati ime da bi se otkrio osetljiv podatak. Ako izabrani segment sadrži samo jednog člana, prikaz njegovog penzijskog iznosa praktično otkriva podatak o toj osobi. Više preklapajućih upita može izdvojiti pojedinca oduzimanjem rezultata. Maskiranje direktnih identifikatora ne sprečava takvu analizu.
Primer ispod prikazuje minimalan broj članova po grupi. `HAVING` klauzula koju analitičar sam bira nije bezbednosna politika. U produkciji se dozvoljena granularnost mora nametnuti kroz kontrolisani data proizvod ili servisni sloj, uz proveru ponovljenih i kombinovanih upita.
Pošto testni skup sadrži samo dva reda, prag od deset članova namerno ne vraća nijedan rezultat. Odabir praga zavisi od procene rizika, a ne predstavlja univerzalni dokaz anonimnosti.
Minimalna veličina agregirane grupe
-- Ilustracija, ne kompletna kontrola otkrivanja podataka
SELECT
fund_id,
count() AS member_count,
sum(accrued_pension_eur) AS total_liabilities_eur
FROM
pension_members
GROUP BY
fund_id
HAVING
count() >= 10;
-- Dva sintetička člana ne ispunjavaju uslov.
Kako izabrati kontrolnu tačku za PII maskiranje
Ne postoji univerzalno najbolje maskiranje. Funkcija u upitu je jednostavna, ali se može zaobići ako je dozvoljeno direktno čitanje izvorne tabele. Kontrolisani View ograničava interfejs; dinamičke politike obezbeđuju prikaz po ulogama; maskiranje pre unosa sprečava čuvanje originalnog PII u analitičkom sloju.
Baza je detalj implementacije, a ne tema članka. ClickHouse primeri prikazuju različite tačke kontrole i ne treba ih bez razmišljanja kombinovati: korisnik može naslediti više uloga, delimično maskiranje može otkriti identitet, a politika ne štiti podatke već kopirane van baze.
Poređenje upita, View-a, politike i maskiranja pri unosu
**Izvorne Masking Policies** imaju smisla kada različite uloge legitimno koriste istu tabelu, ali ne smeju da vide iste vrednosti. Prednost je primena pri upitu; ograničenja su očuvani originalni podaci, alternativni pristupi i kopije izvan baze.
**Odobreni Views ili posebni data proizvodi** pogodni su kada su analitici potrebni zbirni pokazatelji i odabrane poslovne dimenzije. Uklanjanje nepotrebnih identifikatora smanjuje rizik, ali zahteva kontrolu definicija, prava, promena šeme i stvarnog izvršavanja upita.
**Pseudonimizacija pre učitavanja** omogućava povezivanje događaja tokom vremena bez unošenja direktnih identiteta u analitiku. Mapa i ključevi moraju ostati odvojeno zaštićeni; brisanje, ispravke i migracije zahtevaju poseban dizajn.
Ovi pristupi nisu međusobno isključivi. Za regulisane podatke često je primerena kombinacija minimalnih data proizvoda, uskih prava i dodatnog maskiranja.
Pristup 4: maskiranje pri unosu podataka
Alternativna arhitektura obrađuje podatke pre čuvanja u analitičkoj tabeli. ClickHouse EPHEMERAL polje može biti ulaz za MATERIALIZED izraz, a samo izvorno polje se ne čuva. Ovo je zaseban primer, ne dodatna konfiguracija prethodne tabele.
Delimično sakrivena e-mail adresa i dalje može biti lični podatak. Ako adresa nije potrebna, potpuno je ukloniti. Ako je potrebno povezivanje zapisa, koristiti zasebno zaštićenu tokenizaciju ili pseudonimizaciju.
EPHEMERAL i MATERIALIZED pri unosu
-- Separate demonstration: ingest-time reduction
CREATE TABLE pension_export_minimized (
email String EPHEMERAL,
email_preview String MATERIALIZED concat (
substring(email, 1, 2),
'****',
substring(email, position(email, '@'))
),
fund_id String,
accrued_pension_eur Decimal(14, 2)
) ENGINE = MergeTree
ORDER BY
fund_id;
INSERT INTO
pension_export_minimized (email, fund_id, accrued_pension_eur)
VALUES
('sample@example.invalid', 'FUND-A', 128500.00);
SELECT
fund_id,
email_preview,
accrued_pension_eur
FROM
pension_export_minimized;
-- The partial email remains potentially identifying.
Izmene pravila zahtevaju regresione testove
Promene masking politika verzionisati, pregledati i testirati sa dozvoljenim i nedozvoljenim ulogama. `CREATE OR REPLACE` je primer izmene prethodnog pravila, ne dodatni korak koji se uvek automatski izvršava.
Kontrolisana izmena Masking Policy
-- Alternative revision of the earlier policy, not an extra layer
CREATE
OR REPLACE MASKING POLICY pension_member_pii ON pension_members
UPDATE full_name = '[REDACTED]',
email = '[REDACTED]',
pension_account = '[REDACTED]' TO pension_analyst;
SHOW MASKING POLICIES;
Lista provera za produkciju – bez vezivanja za ClickHouse
Pregled privilegija
Popisati korisnike, servisne naloge, direktna prava, nasleđene uloge i mogućnosti izvoza.
Negativni testovi
Proveriti zabranjena polja, pogrešne uloge, ukinuta prava, druge API-je i kopije, ne samo uspešan maskirani upit.
Kopije i logovi
Proveriti backup, staging, BI izvoz, fajlove, tikete i aplikativne logove.
Kontrola granularnosti
Odrediti dozvoljene pokazatelje, grupe i dimenzije zajedno sa odgovornim timom.
Upravljanje promenama
Verzionisati politike, raditi regresione testove i ponovo proveravati promene šema i prava.
Incidenti i brisanje
Definisati revizijske tragove, ukidanje prava, brisanje i postupanje u slučaju incidenta.
Reference i ograničenja
Tehnička referenca: https://clickhouse.com/docs/products/cloud/guides/security/data-masking. Primer koristi izmišljene podatke i nije potvrđen u stvarnoj produkcionoj ClickHouse instanci. Verziju, nasleđivanje prava i sve putanje pristupa treba testirati u ciljnom sistemu.
Maskiranje i pseudonimizacija nisu automatska anonimizacija. U konkretnom penzionom fondu treba proveriti primenljive propise o zaštiti podataka i obaveze sektora, uz odgovorne pravne i bezbednosne timove. Povezano: https://valanor.co/sr/data-governance.
Maskiranje kao deo Data Governance arhitekture
Masking Policy je samo jedna kontrola u širem Data Governance modelu. Za kompletnu zaštitu potrebni su odgovornosti, ugovori o podacima, prava pristupa, evidencija i pravila izvoza. Više: https://valanor.co/sr/data-governance i https://valanor.co/sr/maskiranje-podataka.
Isti princip važi i van ClickHouse-a
ClickHouse, Snowflake, BigQuery, PostgreSQL i druge platforme koriste različitu sintaksu i semantiku prava. Osnovni postupak ostaje isti: klasifikacija, minimizacija, kontrola pristupa, testiranje svih puteva i nadzor izvoza.
U zdravstvu i osiguranju treba dodati sektorske obaveze i različite dozvoljene svrhe. SQL maskiranje samo po sebi nije garancija pravne usklađenosti. Više: https://valanor.co/sr/data-governance, https://valanor.co/sr/maskiranje-podataka i https://clickhouse.com/docs/products/cloud/guides/security/data-masking.
Česta pitanja o PII maskiranju
Može li analitička uloga potpuno da spreči pristup ličnim podacima?
Samo ako su ograničene sve dozvole, alternativni izvori, povezani servisi i izvozi. Masking Policy sama po sebi nije dovoljna.
Da li je maskiranje samo po sebi usklađeno sa propisima?
Maskiranje može biti odgovarajuća tehnička mera, ali su dodatno potrebni dozvoljena svrha, pravni osnov, procena rizika, minimizacija i organizacione kontrole.
Da li su hash vrednosti automatski anonimne?
Ne. Deterministički hash može se povezivati između izvora ili otkriti nagađanjem. Za trajne veze treba proceniti tokenizaciju ili druge bezbedne metode pseudonimizacije.
Da li CREATE MASKING POLICY radi u svakoj ClickHouse verziji?
Ne. Ovde prikazana izvorna funkcija dokumentovana je za ClickHouse Cloud od verzije 25.12. Izdanje i verziju treba proveriti.
Tehnički razgovor
Bezbedna analitika počinje od arhitekture.
Razgovarajmo o modelu pristupa, klasifikaciji i proveri vašeg konkretnog data proizvoda.
Aleksandar Basara
Managing Director
aleks@valanor.co
Bulevar Milutina Milankovića 7Đ, 11070 Beograd, Srbija
