Duomenų saugumas ir privatumas skaitmeniniuose gaminių pasuose

Skaitmeninių gaminių pasų saugumo paradoksas

Skaitmeniniuose gaminių pasuose slypi esminė įtampa: jie turi būti viešai prieinami vartotojams ir reguliavimo institucijoms, tačiau kartu apsaugoti komerciniu požiūriu jautrią tiekimo grandinės informaciją. Vartotojas turėtų matyti medžiagų sudėtį ir perdirbimo instrukcijas; konkurentas neturėtų matyti tiekėjų tapatybės, sąnaudų struktūros ar nuosavų gamybos procesų. Norint suvaldyti šį paradoksą, reikia brandaus, daugiasluoksnio požiūrio į duomenų saugumą ir prieigos kontrolę.

Tvarių gaminių ekologinio projektavimo reglamentas (ESPR) šią įtampą pripažįsta aiškiai. Jame nustatyti skirtingi prieigos lygiai skirtingoms suinteresuotosioms šalims: vieši duomenys, prieinami visiems, riboto naudojimo duomenys, prieinami tik notifikuotosioms įstaigoms ir rinkos priežiūros institucijoms, ir konfidencialūs duomenys, saugomi komercinių paslapčių nuostatomis. Tinkamas šių prieigos lygių įgyvendinimas yra ir techninis iššūkis, ir teisinė pareiga.

Rizika didelė. Duomenų saugumo pažeidimas, atskleidžiantis tiekėjų tapatybę, gali pakirsti per daugelį tiekimo grandinės plėtros metų sukurtus konkurencinius pranašumus. Privatumo pažeidimas, susijęs su asmens duomenimis, gali lemti BDAR vykdymo užtikrinimo veiksmus ir baudas iki keturių procentų pasaulinės apyvartos. O sistemos pažeidimas, leidžiantis suklastoti paso duomenis, galėtų sudaryti sąlygas plataus masto žaliajam smegenų plovimui ir pakirsti pačią DPP sistemos paskirtį.

Duomenų klasifikavimas ir prieigos lygiai

Veiksmingas DPP saugumas prasideda nuo duomenų klasifikavimo: reikia nustatyti, kurie duomenų elementai yra vieši, kurie riboto naudojimo, o kurie konfidencialūs. Šis klasifikavimas lemia kiekvieną tolesnį saugumo sprendimą, nuo prieigos kontrolės iki šifravimo strategijų.

ESPR nustato tris prieigos lygius, kuriuos turi įgyvendinti DPP sistemos:

• Viešas lygis: duomenys, prieinami bet kuriam asmeniui, nuskaitančiam QR kodą ar atidarančiam Digital Link, įskaitant medžiagų sudėtį, poveikio aplinkai duomenis, taisymo instrukcijas ir gyvavimo ciklo pabaigos rekomendacijas
• Įgaliotasis lygis: duomenys, prieinami tik autentifikuotoms suinteresuotosioms šalims, pavyzdžiui, rinkos priežiūros institucijoms, muitinės pareigūnams ir notifikuotosioms įstaigoms, galintys apimti bandymų ataskaitas, išsamią atitikties dokumentaciją ir tiekimo grandinės atsekamumo duomenis
• Konfidencialus lygis: komercinę paslaptį sudarantys duomenys, į kuriuos pasas gali nurodyti, tačiau kurie per jį nėra tiesiogiai prieinami, pavyzdžiui, tiksli tiekėjų tapatybė, nuosavos receptūros ir sąnaudų informacija

Šiems lygiams įgyvendinti reikia patikimos tapatybės ir prieigos valdymo (IAM) sistemos. Vieši duomenys teikiami be autentifikavimo. Įgaliotojo lygio duomenims reikia prisijungimo duomenų patikros; ESPR numato federacinę tapatybės sistemą, kurioje rinkos priežiūros institucijos autentifikuojasi per savo nacionalines sistemas. Konfidencialūs duomenys niekada neteikiami per DPP API; vietoj to pase gali būti metaduomenų, nurodančių, kad konfidenciali informacija egzistuoja, ir pateikiančių prieigos prašymų teisinį pagrindą.

Klasifikavimas turėtų būti taikomas lauko, o ne dokumento lygmeniu. Viename pase yra visų trijų lygių duomenų, todėl API turi gebėti filtruoti atsakymą pagal užklausos teikėjo prieigos lygį. Tai reiškia, kad tas pats GS1 Digital Link URI grąžina skirtingus duomenis, priklausomai nuo to, kas klausia: tai galinga galimybė, kurią būtina įgyvendinti atsargiai, kad būtų išvengta informacijos nutekėjimo.

Šifravimas ir duomenų apsauga perdavimo ir saugojimo metu

Šifravimas yra techninis DPP duomenų apsaugos pagrindas. Duomenys turi būti šifruojami tiek perdavimo metu (kai jie keliauja tarp sistemų), tiek saugojimo metu (kai jie laikomi duomenų bazėse ir failų sistemose). Konkretūs šifravimo reikalavimai priklauso nuo duomenų klasifikavimo lygio.

Visi perduodami DPP duomenys turi naudoti TLS 1.3 (arba bent TLS 1.2) su stipriais šifrų rinkiniais. HSTS antraštės turėtų priverstinai taikyti HTTPS visuose galiniuose taškuose. Sertifikatų prisegimas (certificate pinning) gali būti tinkamas patikimų partnerių mašinų tarpusavio API ryšiams, nors jis apsunkina sertifikatų keitimą.

Saugomiems duomenims turėtų būti taikomas AES-256 šifravimas duomenų bazės laukams, kuriuose yra riboto naudojimo ar konfidencialių duomenų. Raktų valdymas yra kritiškai svarbus: šifravimo raktai turėtų būti saugomi aparatiniame saugumo modulyje (HSM) arba debesijos raktų valdymo paslaugoje (KMS), niekada ne programos konfigūracijos failuose ar aplinkos kintamuosiuose kartu su užšifruotais duomenimis. Raktų keitimo politika turėtų būti apibrėžta ir automatizuota.

Lauko lygmens šifravimas DPP sistemose nusipelno ypatingo dėmesio. Užuot šifravę visą duomenų bazę, selektyviai šifruokite tik laukus, priskirtus riboto naudojimo ar konfidencialiems. Toks požiūris leidžia duomenų bazės užklausoms ir indeksavimui veikti su viešais laukais be iššifravimo sąnaudų, o jautrūs duomenys lieka apsaugoti net ir pažeidus duomenų bazę. Paso API iššifruoja riboto naudojimo laukus tik aptarnaudama autentifikuotas užklausas su tinkamu įgaliojimu.

BDAR laikymasis DPP duomenims

Skaitmeniniuose gaminių pasuose gali būti asmens duomenų arba nuorodų į juos, todėl atsiranda BDAR pareigos. Akivaizdžiausias atvejis, kai paso duomenyse nurodomi gaminio kūrime dalyvavusių asmenų vardai ir pavardės: amatininkų, dizainerių, kokybės inspektorių ar tiekimo grandinės vadovų. Tačiau asmens duomenys gali atsirasti ir mažiau akivaizdžiais būdais: IP adresai prieigos žurnaluose, el. pašto adresai duomenų kilmės įrašuose ir net unikalūs gaminių identifikatoriai, kuriuos galima susieti su konkrečiais pirkėjais.

DPP sistemų atitikčiai BDAR reikia kelių konkrečių priemonių. Duomenų kiekio mažinimo principas reikalauja, kad pasuose būtų tik tie asmens duomenys, kurie griežtai būtini jų reguliavimo tikslui. Jei amatininko vardo nereikalauja ESPR deleguotasis aktas, jo nereikėtų įtraukti, net jei jis galėtų būti komerciškai įdomus. Tikslo apribojimo principas užtikrina, kad DPP atitikčiai surinkti asmens duomenys nebūtų pakartotinai naudojami rinkodarai ar profiliavimui.

Teisė reikalauti ištrinti duomenis („teisė būti pamirštam“) DPP sistemoms kelia ypatingų iššūkių. Jei dizaineris, kurio vardas nurodytas gaminių pasuose, pasinaudoja teise reikalauti ištrinti duomenis, sistema turi gebėti pašalinti arba nuasmeninti jo asmens duomenis visuose susijusiuose pasuose, nepakenkdama paso atitikčiai reguliavimo reikalavimams. Tam reikia kruopščiai suprojektuotos architektūros, atskiriančios asmens identifikatorius nuo atitikties duomenų.

Su visomis šalimis, tvarkančiomis DPP duomenis, kuriuose yra asmeninės informacijos, turi būti sudarytos duomenų tvarkymo sutartys (DPA). Tai apima debesijos prieglobos paslaugų teikėjus, CDN paslaugas, analitikos platformas ir bet kokias trečiųjų šalių priemones DPP procese. Sutartyje turi būti nurodytos tvarkomų asmens duomenų rūšys, tvarkymo tikslai ir taikomos techninės bei organizacinės saugumo priemonės.

API saugumas ir autentifikavimas

DPP API yra pagrindinis piktavalių veikėjų atakos paviršius. Jai apsaugoti reikia daugiasluoksnės gynybos: kelių apsaugos sluoksnių, kuriuos visus reikia įveikti, kad ataka pavyktų.

Autentifikavimo mechanizmai turėtų atitikti prieigos lygį. Vieši galiniai taškai, teikiantys vartotojams skirtus paso duomenis, nereikalauja autentifikavimo, tačiau turėtų taikyti užklausų dažnio ribojimą, kad būtų išvengta piktnaudžiavimo. Įgaliotieji galiniai taškai turėtų naudoti OAuth 2.0 su JWT (JSON Web Tokens), koduojančiais užklausos teikėjo tapatybę, organizaciją ir prieigos teises. Mašinų tarpusavio integracijos turėtų naudoti OAuth 2.0 client credentials srautą su trumpalaikiais žetonais.

Įvesties tikrinimas būtinas kiekviename API galiniame taške. Visi užklausos parametrai, kelio parametrai ir užklausų turinys turi būti tikrinami pagal griežtas schemas. GS1 Digital Link identifikatorių formatas ir kontrolinio skaitmens teisingumas turi būti patikrinti. Laisvo teksto paieškos parametrai turi būti išvalyti, kad būtų išvengta įterpimo atakų. API turėtų atmesti bet kokią užklausą, neatitinkančią dokumentuotos schemos, ir grąžinti aiškius klaidų pranešimus, padedančius teisėtiems naudotojams pataisyti užklausas, bet neatskleidžiančius vidinių sistemos detalių.

Papildomos API saugumo priemonės:

• Užklausų dažnio ribojimas kiekvienam API raktui, taikant pakopines ribas pagal prenumeratos lygį
• Webhook turinio užklausų pasirašymas, kad būtų išvengta klastojimo
• Leidžiamų IP adresų sąrašai administraciniams galiniams taškams
• Išsamus visų autentifikuotų API iškvietimų audito žurnalas
• CORS konfigūracija, ribojanti naršyklės prieigą prie API tik įgaliotais domenais
• Content Security Policy antraštės HTML atsakymuose, apsaugančios nuo XSS atakų

Išsamių API diegimo gairių rasite mūsų skaitmeninių gaminių pasų API integracijos vadove.

Tiekimo grandinės duomenų apsauga

Tiekimo grandinės skaidrumas ir komercinių paslapčių apsauga vienas kito neatmeta, tačiau jų pusiausvyrai pasiekti reikia sąmoningų architektūrinių sprendimų. ESPR reikalauja atsekamumo informacijos, leidžiančios reguliavimo institucijoms patikrinti teiginius apie gaminius, tačiau nereikalauja viešai atskleisti kiekvieno grandinės tiekėjo.

Tiekimo grandinės duomenų apsaugos DPP metodai apima agregavimą (medžiagų kilmės nurodymą pagal regionus, o ne pagal konkrečius tiekėjus), pseudonimizavimą (tiekėjų tapatybės pakeitimą nuosekliais, bet neatskleidžiančiais identifikatoriais) ir atrankinį atskleidimą (išsamios tiekimo grandinės informacijos atskleidimą tik autentifikuotoms reguliavimo institucijoms).

Nulinių žinių įrodymai (zero-knowledge proofs) yra besiformuojantis tiekimo grandinės tikrinimo metodas. Gamintojas gali įrodyti, kad jo gaminys atitinka tam tikrus tvarumo kriterijus, pavyzdžiui, kad nė vienas jo grandinės tiekėjas nėra įtrauktas į sankcijų sąrašą, neatskleisdamas tų tiekėjų tapatybės. Nors ESPR šios technologijos dar nereikalauja, ji gali tapti aktuali, kai DPP reikalavimai kis.

Praktinis tiekimo grandinės saugumas taip pat apima užtikrinimą, kad tiekėjų DPP sistemai teikiami duomenys būtų apsaugoti. Tiekėjų portaluose turėtų būti naudojamas stiprus autentifikavimas, šifruoti ryšiai ir vaidmenimis grindžiama prieigos kontrolė. Duomenų dalijimosi sutartyse turėtų būti tiksliai nurodyta, kokia informacija bus įtraukta į viešus pasus, kad tiekėjai matytų ir kontroliuotų, kaip naudojami jų duomenys.

Reagavimas į incidentus ir pažeidimų valdymas

Nepaisant geriausių prevencinių priemonių, saugumo incidentų gali pasitaikyti. Todėl būtinas išsamus, specialiai DPP duomenims skirtas reagavimo į incidentus planas. Jame turėtų būti apibrėžti vaidmenys ir atsakomybė, komunikacijos procedūros, techniniai reagavimo veiksmai ir pranešimo institucijoms reikalavimai.

Pagal BDAR apie asmens duomenų saugumo pažeidimus atitinkamai priežiūros institucijai turi būti pranešta per 72 valandas nuo jų nustatymo. Jei pažeidimas kelia didelį pavojų asmenims, apie jį taip pat turi būti pranešta susijusiems duomenų subjektams. DPP būdingiems pažeidimams taikomi papildomi aspektai: jei paso duomenys buvo suklastoti, turi būti informuotos rinkos priežiūros institucijos, kad jos galėtų įvertinti, ar susiję gaminiai kelia saugos ar atitikties riziką.

Reagavimo į incidentus plane turėtų būti konkrečios veiksmų instrukcijos dažniausiems DPP saugumo scenarijams:

• Neteisėta prieiga prie riboto naudojimo paso duomenų: pažeistų prisijungimo duomenų atšaukimas, duomenų atskleidimo mąsto įvertinimas, susijusių šalių informavimas
• Paso duomenų klastojimas: susijusių gaminių nustatymas, pataisytų pasų išdavimas, rinkos priežiūros institucijų informavimas
• DDoS atakos prieš pasų nustatymo infrastruktūrą: CDN lygmens apsaugos priemonių aktyvavimas, perjungimas į atsarginę infrastruktūrą, paslaugos palaikymas svarbiausioms reguliavimo užklausoms
• Tiekimo grandinės duomenų atskleidimas: susijusių tiekėjų informavimas, poveikio konkurencijai įvertinimas, teisininko įtraukimas komercinės paslapties pažeidimui įvertinti

Reguliarūs saugumo auditai ir įsiskverbimo testai turėtų patvirtinti DPP saugumo priemonių veiksmingumą. Šie vertinimai turėtų apimti ir techninę infrastruktūrą, ir žmogiškuosius procesus: socialinės inžinerijos atakos, nukreiptos į darbuotojus, turinčius prieigą prie konfidencialių paso duomenų, gali apeiti net stipriausias technines kontrolės priemones.

Saugumą pirmoje vietoje statančios DPP kultūros kūrimas

Techninės saugumo priemonės būtinos, tačiau be jas palaikančios organizacinės kultūros jų nepakanka. Visi, dalyvaujantys valdant DPP duomenis, nuo medžiagas parenkančių gaminių dizainerių iki infrastruktūrą administruojančių IT administratorių, turi suprasti savo sprendimų poveikį saugumui.

Saugumo sąmoningumo mokymai turėtų apimti DPP būdingus scenarijus: į paso duomenis nukreiptų sukčiavimo bandymų atpažinimą, duomenų klasifikavimo ir tvarkymo reikalavimų supratimą, tinkamų prieigos suteikimo ir atšaukimo procedūrų laikymąsi bei greitą pranešimą apie įtariamus saugumo incidentus. Šie mokymai turėtų būti kartojami kasmet ir atnaujinami atsižvelgiant į naujas grėsmes.

Organizacijoms, kuriančioms savo DPP gebėjimus, pirmojo skaitmeninio gaminio paso kūrimo vadove pateikiami pagrindiniai saugumo aspektai, kuriuos reikėtų spręsti nuo pat pradžių. Saugumo diegimas į jau veikiančią DPP sistemą vėliau yra kur kas brangesnis ir labiau trikdantis nei jo integravimas nuo pradžių.

Saugumas nėra funkcija, kuri įdiegiama vieną kartą ir pamirštama. Tai nuolatinė disciplina, kuri turi kisti kartu su grėsmių aplinka, reguliavimo aplinka ir DPP ekosistema. Organizacijos, kurios jau dabar investuoja į patikimą saugumo praktiką, bus geriau pasirengusios prisitaikyti, kai DPP reikalavimai bręs, o pasų duomenų kiekis augs.