Полиция, Жалдау Стойкалары, Жұмыс Берушілер, Сақтандырушылар: Неліктен Олар Бірдей Деректерді Көрмеуі Керек

Болашақ Халықаралық Жүргізуші Куәлігін (ХЖК) жасаудың ең үлкен қателігі — әрбір тексерушіні бірдей тексеруші ретінде қарастыру болар еді. Полиция қызметкері, автокөлік жалдау стойкасы, жұмыс беруші және сақтандырушы бірдей сұрақ қоймайды — сондықтан олар бірдей жауап алмауы тиіс.

Бір жүргізуші. Жүруге бір негізгі құқық. Бір әмиян. Бірақ төрт мүлдем басқа тексеруші:

• Жол жиегіндегі полиция қызметкері
• Алу кезіндегі автокөлік жалдау стойкасы
• Автопарк мүмкіндігін тексеретін жұмыс беруші
• Талапты қарайтын сақтандырушы

Болашақ ХЖК төртеуіне де бірдей деректерді көрсетсе, жүйе қазірдің өзінде сәтсіздікке ұшыраған. Куәліктің қауіпсіз емес екендігі үшін емес, ашу моделі тым қарапайым болғандықтан.

Стандарттар қауымдастығы бұл қарапайым моделден бас тартып жатыр. W3C-тің тексерілетін куәліктер жұмысы эмитенттер, иелер және тексерушілер экожүйесін сипаттайды, жұмыс берушілер мен веб-сайттарды тексерушілерге мысал ретінде пайдаланады. Еуропалық Одақтың мобильді жүргізуші куәлігі жөніндегі жұмысы жол жиегіндегі тексерулер мен автокөлік жалдауды — жалдау үшін алдын ала қашықтан бөлісу және полиция үшін жеке тексерулерді қоса алғанда — бөлек тексеру сценарийлері ретінде қарастырады. Архитектура бірнеше тексеруші түрлері үшін жасалған. Қателік — пайдаланушы тәжірибесін тек бір тип бар сияқты жобалау болар еді.

Неліктен Физикалық Карта Бізді Дұрыс Емес Ойлауға Үйретті

Физикалық куәлік бізді барлығын көрсету тәсіліне үйретті. Сіз картаны береді. Екінші адам картада не барын көреді. Өзара әрекеттесудің барлығы осы.

Бұл тәсіл қағаз дүниесінде қолайлы, өйткені балама жоқ. Цифрлық әлемде ол қолайсыз болады.

W3C VC деректер моделі 2.0 тікелей айтады: жүргізуші куәлігінде ID нөмірі, бойы, салмағы, туған күні және үй мекенжайы болуы мүмкін — бірақ бұл берілген транзакция үшін қажеттіден әлдеқайда көп болуы мүмкін. Ағымдағы стандарттардың негізгі тұстары:

• W3C үздік тәжірибесі: таңдамалы ашуды қолдау және тек қатаң қажет нәрсені сұрау
• ЕО деректерді қорғау нұсқаулығы: өңдеу белгіленген мақсаттармен шектелуі тиіс, ал өңделетін деректер қажетті және пропорционалды болуы тиіс
• Болашақ ХЖК-ның бірінші принципі: бірдей куәлік тексеруге бірдей құқықты білдірмейді

Дұрыс Модель — Саясатқа Негізделген Ашу

Егер сіз серйозды архитектура қаласаңыз, дұрыс модель цифрлық карта ұсынысынан гөрі атрибутқа негізделген қатынасты басқаруға жақынырақ.

NIST SP 800-205 қатынасты басқару шешімдерін субъект, объект, сұралған операция және қоршаған орта шарттарымен байланысты атрибуттарды саясатқа қарсы бағалау ретінде анықтайды. Бұл болашақ ХЖК үшін дәл дұрыс құрылым:

• Субъект: жүргізуші
• Объект: сұралған деректер өрістері
• Әрекет: абстрактілі «куәлікті көру» емес, «жол жиегінде В санатын айдауға рұқсатты тексеру» немесе «брондауға жалдау мүмкіндігін тексеру» сияқты нақты нәрсе
• Қоршаған орта: жол жиегі, жалдау стойкасы, алдын ала қашықтан тексеру, автопаркке қосылу және шығын-шегу кейінгі талапты қарау — бұл әртүрлі орталар және әртүрлі шешімдерге алып келуі тиіс

NIST сонымен қатар атрибут жүйелерінде атрибуттарды азайту, топтастыру және минималдау үшін түйіршіктілік, басқару және механизмдер қажет екенін атап өтеді.

Сондықтан болашақ ХЖК: Бұл тексеруші куәлікті оқи ала ма? деп сұрамауы тиіс. Ол: Бұл тексеруші қандай талаптарды, қандай мақсатқа, осы ортада, қандай сақтау ережелерімен ала алады? деп сұрауы тиіс.

Тексеруші Кез Келген Нәрсені Сұрамас Бұрын Өзін Таныстыруы Тиіс

Болашақ ХЖК әмияннан деректер көрсетуден басталмауы тиіс. Ол тексерушінің кім екенін дәлелдеуінен басталуы тиіс.

EUDI архитектурасы бұл туралы айқын. Сенімді тараптар мыналарды жасауы тиіс:

• Олардың қандай атрибуттарды және қандай мақсатта сұрауды ниет ететінін тіркеу
• Қол жеткізу сертификаттарын алу
• Кез келген ашу жасалмас бұрын әмиянда аутентификациялану
• Тіркеу ақпараты қол жетімді болған жерде тіркелген аясына қарсы тексерілу

Пайдаланушы кімнің сұрап жатқанын, не сұралып жатқанын және сұраудың тіркелген аяға сәйкес келетінін немесе келмейтінін көре алады.

ETSI-дің ағымдағы әмиян-сенімді тарап сертификаты жұмысы мұны нақтырақ етеді. Әмиян-сенімді тарапты тіркеу сертификаты сенімді тараптың мақсатын және ол тіркелген сұрауға атрибуттарды сипаттай алады. Байланысты қол жеткізу сертификаты сұраудың заңды, уәкілетті тараптан келетінін қамтамасыз ету үшін бар. ETSI сондай-ақ сенімді тарап метадеректерін қамтиды, мысалы:

• Сауда атауы
• Қолдау URI
• Мақсаты
• Өкілеттіктер
• Тізілім URI
• Қадағалау органының ақпараты

Болашақ ХЖК-ның екінші принципі: тексеруші сәйкестігі жоқ — ашу жоқ.

Неліктен Келісім Экрандары Жеткіліксіз

Мұнда тағы бір қателік бар: пайдаланушының мақұлдауын заңды негізбен бірдей нәрсе ретінде қарастыру.

EUDI архитектурасы тікелей айтады: атрибуттарды ұсынуға пайдаланушының мақұлдауы сенімді тараптың жеке деректерді өңдеуі үшін заңды негіз ретінде қарастырылмауы тиіс. Сенімді тараптың өз заңды негізі болуы тиіс. EUDI сонымен қатар сенімді тарап құқық қорғау органдарының немесе басқа мемлекеттік органның бөлігі болуы мүмкін жағдайларды қоса алғанда, барлық пайдалану жағдайларында пайдаланушының мақұлдауын талап етеді.

Жақсы әмиян интерфейсі көмектесе алады, бірақ ол тексерушінің шектен шығуын өзі шеше алмайды. Ереже интерфейске дейін болуы тиіс.

Сондықтан болашақ ХЖК-ға екеуі де қажет:

• Криптографиялық тексеруші аутентификациясы кімнің сұрап жатқанын растау үшін
• Саясат шектеулері сол тексеруші санатының не сұрай алатыны туралы

Екеуінсіз «пайдаланушының таңдауы» саясат сәтсіздігін жекеге аудару тәсіліне айналады.

1. Полиция: Адамның Барлығын Емес, Айдауға Құқығын Тексеру

Полицияның жол жиегі сценарийі ең бағытталған сценарий.

Еуропалық Одақтың mDL нұсқаулығы мұны тікелей сипаттайды: полиция немесе басқа лауазымды тұлғалар куәліктің жарамдылығы мен көлік мүмкіндіктерін қоса алғанда, талап етілген кезде куәлікті тексереді. Пайдаланушы сапарында офицер QR-код арқылы іске қосылатын ағын, Bluetooth, Wi-Fi Aware немесе NFC арқылы куәлікті тексереді. Бұл бағытталған тексеру тапсырмасы:

• Бұл адам куәліктің иесі ме?
• Куәлік жарамды ма?
• Қандай көлік мүмкіндіктері мен шектеулер қолданылады?

Әдепкі бойынша рұқсат етілген:

• Аты-жөні
• Суреті
• Куәлік мәртебесі
• Берілген және мерзімі аяқталатын күндер
• Санаттар
• Айдауға қатысты шектеулер
• Эмитент пен юрисдикция
• Жаңалық/мәртебе нәтижесі

Әдепкі бойынша рұқсат етілмеген:

• Үй мекенжайы
• Жол жиегінде пайдалану үшін қажет емес ішкі идентификаторлар
• Басқа куәліктерден байланысты емес атрибуттар
• Тарихи ұсыну журналдары
• Коммерциялық метадеректер

AAMVA-ның іске асыру нұсқаулығы сурет тұрғысынан мынаны нығайтады: егер сурет сұралса және кез келген басқа элемент шығарылса, тексеруші деректерді ұсынып жатқан адаммен байланыстыра алатындай сурет бөлісілуі тиіс. Сол нұсқаулықта сонымен қатар мүдделі тараптар заңмен талап етілген жерлерден басқасында mDL иелерін немесе mDL пайдалануын бақыламауы тиіс делінген.

Полиция жағдайы мемлекеттің барлығын алуы туралы емес. Ол мемлекеттің жол жиегінде орындауды қамтамасыз ету үшін қажетті айдауға тән деректерді алуы туралы. Бұл маңызды айырмашылық.

2. Жалдау Стойкалары: Мүмкіндік, Жеке Куәлік Сәйкестігі және Қажетсіз Ештеңе

Жалдау жағдайы толығырақ, өйткені шынымен де екі сәт бар: келуден бұрын алдын ала қашықтан тексеру және адам немесе киоск кілттерді берген кездегі алу.

Еуропалық Одақтың mDL нұсқаулығы екеуін де модельдейді. Автокөлік жалдау қызметі брондау кезінде жеке куәліктің дәлелімен бірге mDL сұрауы, куәліктерді растауы және кейінірек көлік ұсынылмас бұрын алу кезінде тұтынушыны жеке тексеруі мүмкін. Пайдаланушылар өздерінің mDL-дерін автокөлік жалдау компанияларымен жеке немесе алдын ала қашықтан бөлісе алады.

Жалдау стойкасы бастапқыда оқиғаны тергеуі керек емес. Оған шешім керек: Осы брондау мен саясат бойынша осы тұтынушыға осы көлікті жалдай аламын ба?

Алдын ала қашықтан тексеруге мыналар кіруі тиіс:

• Жеке куәлік байланысы
• Сурет немесе баламалы жеке куәлікті байластыру элементі
• Тиісті көлік санаты
• Берілген және мерзімі аяқталатын күндер
• Ағымдағы жарамдылық
• Мүмкін жас шегі немесе жас тобы

Алу мыналарды растауы тиіс:

• Иесі алдын ала тексеруді аяқтаған адаммен бірдей екенін
• Ағымдағы жарамдылықты
• Тиісті мүмкіндіктерді

Әдепкі бойынша қажет емес:

• Брондау профилінде байланыс деректері бар болса толық үй мекенжайы
• Жас шегі немесе жас тобы жеткілікті болғанда толық туған күн
• Байланысты емес жеке куәлік атрибуттары
• Брондау куәлігі бар болса толық куәліктің қайта-қайта ұсынылуы

NIST-тің ағымдағы mDL архитектурасы сенімді тараптың тек қажетті атрибуттарды сұрау үшін DCQL пайдаланатынын көрсетеді және бұл куәлікті бір бүтін ретінде қарастырудың орнына сұрауды құрылымдау арқылы деректерді азайтуды және иесінің келісімін қолдайды деп тікелей айтады. AAMVA қолданба деректердің не сұралғанын және тексерушінің ақпаратты сақтауды ниет ететінін айқын көрсетуі тиіс деп қосады.

3. Жұмыс Берушілер: Тексеруші Санаты, Толық Жеке Куәлікке Кіру Емес

W3C-тің шолуы жұмыс берушінің цифрлық жүйесі университет дипломын тексергенді тексеруші мысалы ретінде пайдаланады. Бұл жұмыс беруші тексеруінің куәлік экожүйелерінде тіркелген үлгі екенін еске салады.

Жұмыс беруші немесе автопарк операторы заңды түрде мыналарды білуге мұқтаж болуы мүмкін:

• Жұмысшы қазіргі уақытта белгілі бір көлік санаттарын айдауға рұқсатты ма
• Негізгі шектеулер бар ма
• Рұқсат жарамды ма

Бұл нақты бизнес қажеттілігі. Бірақ ол автоматты түрде барлық айдауға куәлікке, толық жеке куәлік деректеріне немесе қайталанатын ұсыныстардың үздіксіз ағынына тұрақты қол жеткізуді негіздемейді.

NIST қайта пайдалануға болатын идентификаторды жиі жіберу және пайдаланушыларды жеке куәлік алатын куәлікті қайталап ұсынуға үйрету жағымсыз екенін ескертеді және күнделікті аутентификация парольсіз кілттер сияқты аутентификация үшін арнайы жасалған технологияларға сүйенуі тиіс дейді. NIST жеке өмірді жақсырақ сақтайтындықтан серверлік биометриялық сәйкестендіруден гөрі жергілікті құрылғы аутентификациясын жөн көреді.

Болашақ ХЖК жұмыс орнындағы кіру бейджіне айналмауы тиіс.

Жұмыс беруші мен автопарк пайдалану үшін дұрыс үлгі әдетте мынадай:

• Жұмысқа қатысты мүмкіндікті тексеру
• Мүмкін мерзімді сәйкестік куәлігі
• Мүмкін иесінің белгіленген санаттар үшін жарамды екені туралы талап
• Бірақ қызметкер жүйеге кірген немесе ауысымды бастаған сайын барлық куәлік деректерінің әдепкі тасымалдануы емес

Автопарктің сәйкестігі — бөлек сенімді тарап санаты, бөлек ниетті пайдалану және бөлек ашу профилімен.

4. Сақтандырушылар: Талаптар Үздіксіз Көрінуге Рұқсат Емес

Сақтандыру жағдайы жиі нақты болады. Еуропалық Одақтың mDL пайдалану жағдайы материалында сақтандырушылар жалдау сценарийінде жанама түрде пайда болады: сақтандыру компаниялары автокөлік жалдау компанияларынан автокөлік жалдап жатқан адамның айдауға рұқсаты бар-жоғын тексеруді талап етеді. Сақтандыру айдауды тексеру ағынына ықпал ете бастады.

Бірақ бұл сақтандырушы полициямен бірдей деректерді немесе куәлікке тұрақты кіру құқығын алуы тиіс дегенді білдірмейді.

Болашақ ХЖК сақтандырушыларды бөлек ниетті пайдалануы бар бөлек тексеруші санаты ретінде қарастыруы тиіс:

• Сақтандыру тарифін есептеу
• Жалдау тәуекелін тексеру
• Шығын кейінгі талапты өңдеу
• Алаяқтықты қарау

Бұл бірдей мақсат емес. Еуропалық Одақтың деректерді қорғау принциптері бойынша жеке деректер белгіленген мақсаттар үшін жиналуы және сол мақсат үшін қажетті және пропорционалды мөлшермен шектелуі тиіс. W3C-тің VC нұсқаулығы техникалық тұрғыдан бірдей қорытындыға келеді: тексерушілер тек қатаң қажет нәрсені сұрауы тиіс.

Заңды, оқиғаға тән мысалдар:

• Куәліктің тиісті сәтте жарамды болғанының дәлелі
• Тиісті көлік мүмкіндігінің дәлелі
• Талап үшін қажет болғанда жеке куәлік байланысының дәлелі
• Талапқа тән ашу

Әдепкі бойынша рұқсат етілмеген:

• Негізгі куәлікке тұрақты кіру
• Тұтынушы сақтандырушымен байланысқан сайын жалпы тексеруді қайталау
• Айдауға куәлікті кіру токені ретінде пайдалану
• Байланысты емес атрибуттарды жинау

Айдауға куәлігі — бақылау жазылымы емес. Және ол үнсіз сондай болмауы тиіс.

Неліктен Делдалдар Көрінетін Болуы Тиіс

Нақты нарықтар делдалдарды қамтиды. Жалдау платформалары, автопарк жеткізушілері, жұмыс беруші HR жүйелері және сақтандыру талаптарын өңдеушілер жиі үшінші тараптар арқылы жұмыс істейді.

EUDI архитектурасы мұны мынадай жолмен шешеді:

• Делдалдарды сенімді тараптар ретінде қарастыру
• Оларды тіркеуді талап ету
• Делдал сенімді тарап үшін сұралған атрибуттардың тіркелуін талап ету
• Пайдаланушыға делдалды да, соңғы сенімді тарапты да көрсету
• Делдалдарға транзакция мазмұны туралы деректерді сақтауға тыйым салу

Болашақ ХЖК пайдаланушы жалдау компаниясына ашып жатқанмын деп санайтын, бірақ шынымен де көрінбейтін тексеру брокеріне, аналитика процессоріне және талаптар жеткізушілер тізбегіне ашып жатқан үлгіге ешқашан рұқсат бермеуі тиіс.

ETSI мұнда көмектеседі. Оның әмиян-сенімді тарап сертификаты моделі қолдау URI-дерін, мақсатты пайдалануды, тізілім URI-дерін және қадағалау органының метадеректерін қолдауды қамтиды. Бұл пайдаланушылардың сұраудың екінші жағында кімнің бар екенін және жоюды немесе түзетуді қалаған кезде қайда бару керектігін түсіну үшін қажетті машинада оқылатын инфрақұрылым түрі.

Сақтау Қатынасты Басқарудың Бөлігі

Таңдамалы ашу туралы пікірталастардың көбі тым ерте аяқталады. Олар ашылатын нәрсеге назар аударады. Ал одан кейін қанша уақыт сақталатынына жеткілікті назар аудармайды.

Ағымдағы нұсқаулар қазірдің өзінде біріктірілуде:

• AAMVA: әмиян иесіне қандай деректердің сұралғанын және тексерушінің ақпаратты сақтауды ниет ететінін нақты хабарлауы тиіс; мүдделі тараптар заңмен талап етілген жерлерден басқасында иелерді немесе mDL пайдалануын бақыламауы тиіс
• W3C: иесінің бағдарламалық жасақтамасы тексерушілермен бөлісілген ақпараттың журналдарын ұсынуы тиіс, сондықтан артық сұраулар анықталуы мүмкін
• EUDI: пайдаланушылар транзакция журналдарына кіре алуы, күмәнді сұраулар туралы хабарлауы және жоюды сұрай алуы тиіс

Сақтау класы ашу саясатының өзінің бөлігі болуы тиіс:

• Полицияның жол жиегі: заңды жедел жазбадан тыс әдепкі бойынша сақтау жоқ
• Жалдауды алдын ала тексеру: брондаумен байланысты транзакция жазбасы, қайта пайдалануға болатын жеке куәлік көшірмесі емес
• Жұмыс берушінің автопарк сәйкестігі: сәйкестік жазбасы немесе куәлік нәтижесі, шикі куәлік деректері емес
• Сақтандырушы талабы: талаппен шектелген талап жазбасы, тұрақты кіру емес

Сақтауды елемейтін болашақ ХЖК жекелікті тек ішінара сақтайды.

Әмиян Шынымен Не Шешуі Тиіс

Бүкіл осы мақаланы бір іске асыру ережесіне дейін қысқартуым керек болса, ол мынадай болар еді:

Әмиян «Мен бұл куәлікті ұсына аламын ба?» деп жауап бермеуі тиіс. Ол «Мен бұл талаптар жиынтығын осы аутентификацияланған тексерушіге, осы мақсатқа, осы контексте, осы сақтау класы бойынша ұсына аламын ба?» деп жауап беруі тиіс.

Бұл шешім кем дегенде мына кірістер арқылы анықталуы тиіс:

• Тексеруші жеке куәлігі
• Тексеруші санаты
• Мақсаты
• Тіркелген атрибут аясы
• Бар болса эмитенттің ашу саясаты
• Қоршаған орта (жол жиегі, алу, қашықтан, автопарк, талап)
• Иесінің мақұлдауы
• Қолданыстағы сақтау саясаты

Стандарттар бұл үшін машинерияның көп бөлігін қазірдің өзінде қамтиды: таңдамалы ашу, сенімді тарапты аутентификациялау, тіркелген мақсаттылы пайдалану, қол жеткізу сертификаттары, ашу саясатын бағалау және мақсатпен байланысты сұраулар. Әлі жетіспейтін нәрсе — бұл бөліктерді бір тұтас ашу архитектурасы ретінде қарастыру тәртібі.

Негізгі Дәлел

Болашақ ХЖК деректерді ашуға болады ма деп сұрамауы тиіс. Ол мыналарды сұрауы тиіс:

• Кім сұрап жатыр?
• Қандай мақсатта?
• Қандай өкілеттік бойынша?
• Қандай контекстте?
• Қандай сақтау салдарымен?

Полиция, жалдау стойкалары, жұмыс берушілер және сақтандырушылар сұраудың екінші жағындағы төрт логотип емес. Олар — төрт түрлі тәуекел моделі, төрт түрлі заңды контекст, сұраудың төрт түрлі себебі — және олар төрт түрлі ашу жинақтарын жасауы тиіс.

Бұл артық күрделілік емес. Бұл заманауи айдауға куәлік әрбір тексерушіні бірдей тексеруші ретінде қарастыруды тоқтатқан кездегі көрінісі.