EUDI Walleti esituse vastuvõtmine on usaldusotsus ja just teie integratsioonikoodis see otsus tehakse. Artikkel on mõeldud tugevatele osapooltele (relying party): omavalitsustele ja teenusepakkujatele, kes hakkavad rahakoti esitusi vastu võtma, mitte rahakotte arendavatele tiimidele. Siin on küsimused, millele tahaksime vastust enne, kui rahakott päris kasutajatele sisse lülitatakse. See on ülevaatuse kontrollnimekiri, mitte valmis lahendusdisain.
Teadke, millise spetsifikatsiooni alusel te arendate
Tehniline alus on arhitektuuri- ja viiteraamistik (Architecture and Reference Framework, ARF). See on avaldatud avalikus GitHubi hoidlas ja seda arendatakse ühtse liidu tööriistakomplekti (Common Union Toolbox) raames. Hoidla kohaselt on kehtiv autoriteetne versioon viimane sildistatud väljalase. Haru (branch) või blogipostituse kokkuvõte ei ole autoriteetne allikas.
Õiguslik alus on määrus (EL) nr 910/2014, mida on muudetud määrusega (EL) 2024/1183, koos komisjoni rakendusmäärustega. ARF viitab nende hallatavale loetelule oma peatükkides Introduction ja References.
Esimesed küsimused on seega haldusküsimused, kuid need on olulised:
- Millise ARF-i väljalaske alusel on teie tarnija või integraator arendanud?
- Kes teie poolel jälgib uusi sildistatud väljalaskeid ja rakendusmäärusi ning kuidas jõuavad muudatused teie arendusbacklogi?
- Kas teie leping identiteedilahenduse tarnijaga nimetab konkreetset versiooni või ainult fraasi "eIDAS 2.0 nõuetele vastav"?
Küsimused väite kohta
Rahakott annab teie teenusele esituse. Enne kui sellest saab sessioon, peate teadma, mida te tegelikult kontrollisite.
- Kes selle välja andis? Teie teenus peaks võtma esitusi vastu ainult väljastajatelt, keda olete otsustanud usaldada, ja ainult nende atribuuditüüpide osas, mida olete otsustanud aktsepteerida. "Mis tahes kehtiv allkiri" ei ole poliitika. Pange aktsepteeritavate loetelu kirja, nimetage vastutaja ja määratlege, kuidas kirjeid lisatakse ja eemaldatakse.
- Kas see on seotud just selle tehinguga? Esitus, mida saab teie sisselogimise lõpp-punkti vastu uuesti kasutada (replay), on varastatud mandaat, mis ootab oma aega. Küsige tarnijalt, kuidas esitus teie sessiooniga seotakse, ja testige, et vana esitus lükatakse tagasi.
- Mis juhtub, kui kontroll ebaõnnestub või pole kättesaadav? Otsustage, kas süsteem ebaõnnestub turvaliselt (fail closed). Veenduge, et veakäsitlus ja koormustingimused ei suuna kasutajaid nõrgemale varuteele.
- Mida te logite? Logist peab piisama intsidendi uurimiseks, ilma et hoiustaksite isikuandmeid, mille minimaalsena hoidmiseks rahakott loodi.
Märkus esimese punkti kohta: väljastajate ja atribuutide aktsepteerimise poliitika on kontroll, mida meie soovitame. See ei ole ARF-ist pärit nõue.
Küsimused atribuutide kohta
Euroopa Komisjon kirjeldab rahakotti kui vahendit, mis võimaldab kasutajal avaldada ainult vajalikke andmeid, näiteks vanuse või kodakondsuse, jättes muud isikuandmed avaldamata. See seab ootuse, millele teie integratsioon tugeva osapoolena peab vastama.
Kui teie teenus peab teadma, et inimene on teatud east vanem, küsige seda, mitte sünniaega. Kui vajate teie omavalitsuse elanikku, küsige atribuuti, mis seda tõendab, mitte täielikku aadressi. Iga lisaatribuut suurendab andmemahtu, mida peate kaitsma ja oma privaatsusmõju hindamises põhjendama.
Seejärel küsige, mida atribuut tegelikult tõendab. Riigi väljastatud atribuut ja eraõigusliku väljastaja atribuut võivad olla samas rahakotis ning teie koodis välja näha ühesugused. Siduge kumbki otsusega, mida see toetab. Raamatukogukaardi number ei tohiks anda juurdepääsu maksudeklaratsiooni esitamisele.
Aktsepteerimispoliitika üks rida võiks välja näha selline. Väärtused illustreerivad vormingut, mitte ei ole soovitus:
| Väljastaja | Atribuut | Tugeva osapoole otsus | Vastutaja | Ülevaatuse intervall |
|---|---|---|---|---|
| Riiklik ID väljastaja (näide) | Vanus üle 18 | Lubada juurdepääs vanusepiiranguga teenusele; sünniaega mitte salvestada | Teenuse omanik | Iga kuue kuu järel |
Kui te ei saa kõiki viit veergu täita, ei ole kirje loetellu kandmiseks valmis.
Organisatsiooniliseks kasutuseks testivad pilootprojektid ühe kasutusjuhtumina organisatsiooni digitaalseid identiteete, st tõendamist, et isik on organisatsiooni seaduslik esindaja. Kui teenindate ettevõtteid, otsustage juba praegu, kuidas te kohtlete ettevõtte nimel tegutsevat isikut ja kuidas saate teada, millal selle isiku volitus lõpeb.
Küsimused allkirjastamisvoogude kohta
Lepingute allkirjastamine on üks pilootstsenaariume, seega käsitlege seda sisselogimisest eraldi tagatisjuhtumina.
- Millistest teenustest teie allkirjastamis- või pitseerimisvoog sõltub ja kes neid haldab?
- Mida te allkirja tõendina salvestate ja kui kauaks?
- Kui allkiri vaidlustatakse kahe aasta pärast, kas suudate näidata, mida tol hetkel esitati ja kontrolliti?
Ärge eeldage, et edukas sisselogimine tähendab kehtivat allkirjaahelat. Need on eraldi kontrollid eraldi tõrkerežiimidega. Teie juriidiline ja turvatiim peaksid enne esimese lepingu allkirjastamist kokku leppima, mis loetakse vastuvõetavaks tõendiks.
Testige integratsiooni ja seejärel testige uuesti
Euroopa Komisjoni prototüüprahakott sisaldab koodiraamatukogusid ja näiterakendust ning viiteimplementatsioon on avatud lähtekoodiga. ARF-i hoidla viitab vastavustestimise veebisaidile. Kasutage neid testimiseks, mitte tootmissõltuvusena, mida te pole kunagi üle vaadanud.
Suuremahulistes pilootprojektides osaleb üle 350 üksuse 26 liikmesriigist, Norrast, Islandilt ja Ukrainast ning need hõlmavad valdkondi nagu valitsusteenused, pangandus ja maksed. Teie enda lõpp-punktid, varuteed ja sessioonihaldus vajavad siiski eraldi testimist.
Käsitlege integratsiooni kui uut autentimiskoodi. See tähendab ohumudelit, väärkasutusjuhtumite testimist kordusrünnakute (replay), moonutatud esituste ja ootamatute väljastajate vastu ning valmis voo penetratsioonitesti enne käivitamist. Olenemata sellest, mida rahakoti tarnija on testinud, vajab teie tugeva osapoole teenus oma ülevaatust.
Kust alustada
- Fikseerige sihtmärk: dokumenteerige ARF-i väljalase ja rakendusmäärused, mille alusel teie integratsioon on ehitatud, ning määrake keegi muudatusi jälgima.
- Koostage aktsepteerimispoliitika: loetlege väljastajad ja atribuuditüübid, mida usaldate, igaühe toetatav otsus, vastutaja ja ülevaatuse intervall.
- Vähendage atribuudipäringud miinimumini, mida iga teenus vajab, ja dokumenteerige tulemus oma privaatsusmõju hindamises.
- Koostage testiplaan viiteimplementatsiooni ja vastavustestimise ressursside põhjal, sh kordusrünnakute, vale väljastaja, tõrkerežiimide ja varuteede juhtumid.
- Eraldage sisselogimine allkirjastamisest: otsustage, millist tõendit kummagi kohta säilitate ja kes selle heaks kiidab.
- Laske enne tootmisse minekut teha sõltumatu ülevaatus. Kui soovite abi selle ulatuse määratlemisel, pöörduge meie konsultatsioonimeeskonna poole.
