Цагдаа, Түрээсийн Тоолол, Ажил Олгогч, Даатгагч: Яагаад Тэд Ижил Өгөгдлийг Харж Болохгүй Вэ

Ирээдүйн Олон Улсын Жолооны Үнэмлэх (ОУЖ)-ний хамгийн том дизайны алдаа бол бүх баталгаажуулагчийг ижил баталгаажуулагч гэж үзэх явдал байх болно. Цагдаагийн ажилтан, автомашин түрээслэх тоолол, ажил олгогч, даатгагч нар ижил асуулт асуудаггүй — тиймээс тэд ижил хариулт авах ёсгүй.

Нэг жолооч. Нэг суурь жолоодох эрх. Нэг хэтэвч. Гэхдээ дөрвөн огт өөр баталгаажуулагч:

• Замын хажуу дахь цагдаагийн ажилтан
• Автомашин хүлээн авах үеийн түрээсийн тоолол
• Тээврийн хэрэгслийн паркийн эрхийг шалгаж буй ажил олгогч
• Нэхэмжлэлийг хянаж буй даатгагч

Ирээдүйн ОУЖ дөрвөн баталгаажуулагч бүрт ижил өгөгдлийг харуулбал, систем аль хэдийн бүтэлгүйтсэн гэсэн үг. Итгэмжлэл аюулгүй бус учраас биш, харин мэдээлэл задруулалтын загвар хэтэрхий энгийн учраас.

Стандартын хамт олон аль хэдийн тэр энгийн загвараас холдож байна. W3C-ийн баталгаажуулагдах итгэмжлэлийн ажил нь гаргагч, эзэмшигч, баталгаажуулагч нарын экосистемийг тодорхойлж, ажил олгогч болон вэбсайтуудыг баталгаажуулагчийн жишээ болгон ашиглаж байна. Европын Холбооны гар утасны жолооны үнэмлэхний ажил нь замын хажуугийн шалгалт болон автомашин түрээслэлтийг аль хэдийн тусдаа баталгаажуулалтын хувилбар болгон авч үзэж байна — түрээслэлтэд зориулсан алсын урьдчилсан хуваалцалт болон цагдаад зориулсан биечлэн шалгалтыг оруулаад. Архитектур нь олон төрлийн баталгаажуулагчид зориулагдсан байна. Алдаа нь зөвхөн нэг төрөл байгаа мэт хэрэглэгчийн туршлагыг дизайн хийх явдал байх болно.

Яагаад Биет Карт Биднийг Буруу Сэтгэхэд Сургасан Вэ

Биет үнэмлэх биднийг бүх зүйлийг харуулах хандлагад сургасан. Та картаа өгнө. Нөгөө хүн карт дээр байгааг харна. Энэ бол бүхэл бүтэн харилцан үйлчлэл юм.

Тэр хандлага нь цаасан ертөнцөд хүлээн зөвшөөрөгдөх боломжтой, учир нь өөр хувилбар байхгүй. Дижитал ертөнцөд хүлээн зөвшөөрөгдөхгүй болно.

W3C VC өгөгдлийн загвар 2.0 шууд зааж байна: жолооны үнэмлэх нь ID дугаар, өндөр, жин, төрсөн өдөр, гэрийн хаяг агуулж болно — гэхдээ тэр нь өгөгдсөн гүйлгээнд шаардлагатайгаас хамаагүй илүү байж болно. Одоогийн стандартуудын гол цэгүүд:

• W3C шилдэг туршлага: сонгомол мэдээлэл задруулалтыг дэмжих, зөвхөн зайлшгүй шаардлагатай зүйлийг хүсэх
• Европын Холбооны өгөгдөл хамгаалах заавар: боловсруулалт нь заасан зорилгоор хязгаарлагдах ёстой, боловсруулсан өгөгдөл нь шаардлагатай, хувь тэнцүүтэй байх ёстой
• Ирээдүйн ОУЖ-ний эхний зарчим: ижил итгэмжлэл нь шалгах ижил эрх гэсэн үг биш

Зөв Загвар Нь Бодлогод Суурилсан Мэдээлэл Задруулалт

Хэрэв та цэгцтэй архитектур хүсэж байвал, зөв загвар нь дижитал карт үзүүлэхээс илүү атрибутад суурилсан хандалтын хяналтад ойр байна.

NIST SP 800-205 нь хандалтын хяналтын шийдвэрийг субъект, объект, хүссэн үйлдэл, орчны нөхцөлтэй холбоотой атрибутуудын бодлогын эсрэг үнэлгээ гэж тодорхойлдог. Энэ бол ирээдүйн ОУЖ-д яг тохирох бүтэц юм:

• Субъект: жолооч
• Объект: хүссэн өгөгдлийн талбарууд
• Үйлдэл: хийсвэрээр “үнэмлэхийг харах” биш, харин “замын хажуу дээр B ангиллын тээврийн хэрэгсэл жолоодох эрхийг баталгаажуулах” эсвэл “захиалгад зориулсан түрээсийн эрхийг баталгаажуулах” зэрэг тодорхой зүйл
• Орчин: замын хажуу, түрээсийн тоолол, алсын урьдчилсан шалгалт, паркийн бүртгэл болон алдагдлын дараах нэхэмжлэлийн хяналт нь өөр өөр орчин бөгөөд өөр өөр шийдвэрт хүргэх ёстой

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 нь дахин ашиглагдах таних тэмдэг байнга дамжуулах болон хэрэглэгчдийг таних тэмдэг агуулсан итгэмжлэлийг байнга танилцуулахад дасгаж нөхцөлдүүлэх нь хүсээгүй зүйл болохыг анхааруулж, өдөр тутмын аутентификаци нь passkeys зэрэг аутентификацид зориулагдсан технологиудад найдах ёстойг зааж байна. NIST нь нууцлалыг илүү сайн хамгаалдаг учраас сервер талын биометрийн тааруулалтаас илүү орон нутгийн төхөөрөмжийн аутентификацийг илүүд үздэг.

Ирээдүйн ОУЖ ажлын байрны хандалтын тэмдэг болох ёсгүй.

Ажил олгогч болон паркийн хэрэглээнд зөв хэв маяг нь ихэвчлэн:

• Ажилтай холбоотой эрх олгомжийн шалгалт
• Магадгүй үе үеийн нийцлийн гэрчлэл
• Магадгүй эзэмшигч заасан ангиллуудад хүчинтэй хэвээр байгааг тодорхойлох нэхэмжлэл
• Гэхдээ ажилтан системд нэвтэрэх эсвэл ажлын ээлж эхлэх бүрт бүх үнэмлэхийн өгөгдлийг өгөгдмөл байдлаар шилжүүлэх биш

Паркийн нийцэл нь тусдаа зорилгот хэрэглээтэй, тусдаа мэдээлэл задруулалтын профайлтай тусдаа найдварлаж буй тал ангилал юм.

4. Даатгагчид: Нэхэмжлэлүүд Нь Тасралтгүй Харагдах Байдлын Зөвшөөрөл Биш

Даатгалтын тохиолдол ихэвчлэн бодит байдаг. Европын Холбооны mDL хэрэглээний тохиолдлын материалд даатгагчид түрээсийн хувилбарт шууд бусаар гардаг: даатгалтын компаниуд автомашин түрээслэх компаниудаас машин түрээслэж буй хүн жолоодох эрхтэй эсэхийг шалгахыг шаарддаг. Даатгалт аль хэдийн жолоодлогын баталгаажуулалтын урсгалд нөлөөлдөг.

Гэхдээ энэ нь даатгагч цагдаатай ижил өгөгдөл, эсвэл итгэмжлэлд хандах байнгын эрх авах ёстой гэсэн үг биш.

Ирээдүйн ОУЖ даатгагчдыг тусдаа зорилгот хэрэглээтэй тусдаа баталгаажуулагчийн ангилал болгон авч үзэх ёстой:

• Даатгалт бичих
• Түрээсийн эрсдэлийн баталгаажуулалт
• Алдагдлын дараах нэхэмжлэлийн шийдвэрлэлт
• Залилангийн хяналт

Эдгээр нь ижил зорилго биш. Европын Холбооны өгөгдөл хамгаалах зарчмуудын дагуу хувийн мэдээлэл нь заасан зорилгоор цуглуулагдах ёстой бөгөөд тэр зорилгод шаардлагатай, хувь тэнцүүтэй зүйлсээр хязгаарлагдах ёстой. W3C-ийн VC заавар техникийн хувьд ижил дүгнэлтэд хүрдэг: баталгаажуулагчид зөвхөн зайлшгүй шаардлагатай зүйлийг хүсэх ёстой.

Хүчинтэй, тохиолдол-тодорхой жишээнүүд:

• Тухайн мөчид үнэмлэх хүчинтэй байсны нотолгоо
• Холбогдох тээврийн хэрэгслийн эрх олгомжийн нотолгоо
• Нэхэмжлэлд шаардлагатай үед таних тэмдгийн холбоосын нотолгоо
• Нэхэмжлэл-тодорхой мэдээлэл задруулалт

Өгөгдмөлөөр зөвшөөрөгдөхгүй:

• Суурь итгэмжлэлд байнгын хандалт
• Хэрэглэгч даатгагчтай харилцах бүрт давтагдсан ерөнхий баталгаажуулалт
• Жолоодлогын итгэмжлэлийг нэвтрэлтийн токен болгон ашиглах
• Холбогдолгүй атрибутуудыг цуглуулах

Жолоодлогын итгэмжлэл нь хяналтын захиалга биш. Мөн чимээгүйхэн тийм болохгүй байх ёстой.

Яагаад Зуучлагчид Харагдах Байх Ёстой Вэ

Бодит зах зээлд зуучлагчид оролцдог. Түрээсийн платформ, паркийн нийлүүлэгчид, ажил олгогчийн HR системүүд, даатгалтын нэхэмжлэл боловсруулагчид ихэвчлэн гуравдагч этгээдээр дамжуулан ажилладаг.

EUDI архитектур үүнийг дараах байдлаар шийддэг:

• Зуучлагчдыг найдварлаж буй тал болгон авч үзэх
• Тэднийг бүртгүүлэхийг шаарддаг
• Зуучлагдсан найдварлаж буй талд хүссэн атрибутуудыг бүртгүүлэхийг шаарддаг
• Зуучлагч болон эцсийн найдварлаж буй талыг хоёулыг хэрэглэгчид харуулах
• Зуучлагчдад гүйлгээний агуулгын тухай өгөгдлийг хадгалахыг хориглох

Ирээдүйн ОУЖ хэрэглэгч түрээсийн компанид мэдээлэл задруулж байна гэж боддог боловч бодит байдал дээр харагдахгүй баталгаажуулалтын зуучлагч, аналитик боловсруулагч болон нэхэмжлэлийн нийлүүлэгчийн гинжинд мэдээлэл задруулж байгаа хэв маягийг хэзээ ч зөвшөөрч болохгүй.

ETSI энд тусалдаг. Түүний хэтэвч-найдварлаж буй тал гэрчилгээний загвар нь дэмжлэгийн URI, зорилгот хэрэглээ, бүртгэлийн URI болон хяналтын байгууллагын метадата агуулдаг. Энэ бол хэрэглэгчдэд хүсэлтийн нөгөө талд үнэхээр хэн байгааг болон устгах эсвэл засвар хийхийг хүсэх үед хаашаа явахыг ойлгоход шаардлагатай машинаар уншигдах дэд бүтцийн төрөл юм.

Хадгалалт Нь Хандалтын Хяналтын Нэг Хэсэг

Сонгомол мэдээлэл задруулалтын талаарх ихэнх хэлэлцүүлэг хэтэрхий эрт дуусдаг. Тэд юу задруулагдаж байгааг анхаарлын төвд тавьдаг. Дараа нь хэр удаан хэвээр байгааг хангалттай анхаарладаггүй.

Одоогийн заавар аль хэдийн нэгдэж байна:

• AAMVA: хэтэвч эзэмшигчид ямар өгөгдөл хүссэн болон баталгаажуулагч мэдээллийг хадгалах зорилготой эсэхийг тодорхой мэдэгдэх ёстой; оролцогч талууд хуулиар шаардлагатай газраас бусад тохиолдолд эзэмшигчид эсвэл mDL хэрэглээг хянах ёсгүй
• W3C: эзэмшигчийн програм хангамж нь баталгаажуулагчидтай хуваалцсан мэдээллийн бүртгэлийг өгөх ёстой, ингэснээр хэт их хүсэлтүүдийг тодорхойлж болно
• EUDI: хэрэглэгчид гүйлгээний бүртгэлд хандах, сэжигтэй хүсэлтүүдийг мэдэгдэх, устгалт хүсэх боломжтой байх ёстой

Хадгалалтын ангилал нь мэдээлэл задруулалтын бодлогын нэг хэсэг байх ёстой:

• Цагдаагийн замын хажуу: хуулийн үйл ажиллагааны бүртгэлээс давж өгөгдмөлөөр хадгалахгүй
• Түрээсийн урьдчилсан шалгалт: захиалгатай холбогдсон гүйлгээний бүртгэл, дахин ашиглагдах таних тэмдгийн хуулбар биш
• Ажил олгогчийн паркийн нийцэл: нийцлийн бүртгэл эсвэл гэрчлэлийн үр дүн, түүхий итгэмжлэлийн өгөгдөл биш
• Даатгагчийн нэхэмжлэл: нэхэмжлэлд хязгаарлагдсан нэхэмжлэлийн бүртгэл, байнгын хандалт биш

Хадгалалтыг үл тоомсорлосон ирээдүйн ОУЖ нь зөвхөн хэсэгчлэн нууцлалыг хамгаалдаг.

Хэтэвч Юуг Үнэхээр Шийдэх Ёстой Вэ

Хэрэв би энэ нийтлэл бүхлийг нэг хэрэгжилтийн дүрэмд хүргэх ёстой байсан бол энэ байх болно:

Хэтэвч “Би энэ итгэмжлэлийг танилцуулж чадах уу?” гэж хариулах ёсгүй. Харин “Би энэ нэхэмжлэлүүдийн цуглуулгыг энэ баталгаажуулагдсан баталгаажуулагчид, энэ зорилгот хэрэглээнд, энэ нөхцөлд, энэ хадгалалтын ангилалын дагуу танилцуулж чадах уу?” гэж хариулах ёстой.

Тэр шийдвэр дор хаяж эдгээр оролтуудаар удирдагдах ёстой:

• Баталгаажуулагчийн таних тэмдэг
• Баталгаажуулагчийн ангилал
• Зорилгот хэрэглээ
• Бүртгэгдсэн атрибутын хамрах хүрээ
• Гаргагчаас ирсэн мэдээлэл задруулалтын бодлого, байгаа бол
• Орчин (замын хажуу, хүлээн авалт, алсын, парк, нэхэмжлэл)
• Эзэмшигчийн зөвшөөрөл
• Хамаарах хадгалалтын бодлого

Стандартууд аль хэдийн үүний тулд олон механизмыг агуулж байна: сонгомол мэдээлэл задруулалт, найдварлаж буй талын аутентификаци, бүртгэгдсэн зорилгот хэрэглээ, хандалтын гэрчилгээ, мэдээлэл задруулалтын бодлогын үнэлгээ болон зорилго-холбогдсон хүсэлтүүд. Одоо хэвээр дутагдаж буй зүйл нь тэдгээр хэсгүүдийг нэг цогц мэдээлэл задруулалтын архитектур болгон авч үзэх сахилга бат юм.

Гол Маргаан

Ирээдүйн ОУЖ өгөгдлийг задруулж болох эсэхийг асуух ёсгүй. Харин асуух ёстой:

• Хэн асуух вэ?
• Ямар зорилгоор?
• Ямар эрх мэдлийн дагуу?
• Ямар нөхцөлд?
• Ямар хадгалалтын үр дагавартайгаар?

Цагдаа, түрээсийн тоолол, ажил олгогч, даатгагч нар хүсэлтийн нөгөө талын дөрвөн лого биш. Тэд дөрвөн өөр эрсдэлийн загвар, дөрвөн өөр хуулийн нөхцөл, дөрвөн өөр асуух шалтгаан — мөн дөрвөн өөр мэдээлэл задруулалтын багцыг гаргах ёстой.

Энэ бол шаардлагагүй нарийн төвөгтэй байдал биш. Энэ бол орчин үеийн жолоодлогын итгэмжлэл бүх баталгаажуулагчийг ижил баталгаажуулагч гэж үзэхийг зогсоох үед ямар харагддаг вэ гэдгийг харуулдаг.