चेहरा एक सुविधाजनक क्रेडेंशियल है और एक बुरी तरह सुरक्षित भी। कोई भी इसे छाप सकता है, और अधिकांश लोग इसे ख़ुद प्रकाशित करते हैं। इसलिए फेस-आधारित एक्सेस उतना ही अच्छा है जितनी अच्छी वह जाँच है जो तय करती है कि कैमरा किसी व्यक्ति को देख रहा है या उसकी तस्वीर को।
यह कैसे बना है
परिसर तक नियंत्रित पहुँच किसी अलग उत्पाद से नहीं बल्कि प्लेटफ़ॉर्म के पास पहले से मौजूद हिस्सों से बनाई जाती है। आप एक व्यक्ति-सूची बनाते हैं जिसमें प्रवेश के हक़दार लोग होते हैं, आप FaceTrack Pro को प्रवेश-बिंदु के कैमरे पर लगाते हैं, और आप लॉक से कनेक्शन कॉन्फ़िगर करते हैं। सूची में मौजूद पहचाना गया चेहरा एक "Match" इवेंट बनाता है; जो सूची में नहीं है वह "No match" बनाता है। इसके बाद क्या होता है यह दरवाज़े का मामला है, कैमरे का नहीं।
IREX कोई लॉक नहीं है और न ही यह कोई बेचता है। यह चेहरा पहचानता है और वह एक्सेस-कंट्रोल हार्डवेयर चलाता है जो आपके पास पहले से है: दस्तावेज़ीकरण स्मार्ट लॉक जैसे बाहरी डिवाइस के इंटरफ़ेस बताता है, Sigur को एक्सेस-कंट्रोल इंटीग्रेशन के रूप में और Netping को बाहरी डिवाइस के रूप में दस्तावेज़ में दर्ज किया गया है, और इनके अलावा कोई भी अलार्म मॉनिटर अपने इवेंट, फ़्रेम सहित, किसी भी HTTP-पहुँच योग्य एंडपॉइंट पर भेज सकता है। फेस मैच से दरवाज़ा खुलना इंटीग्रेशन दस्तावेज़ीकरण का सिद्ध उदाहरण है।
जो नंबर सब कुछ तय करता है वह है समानता थ्रेशोल्ड, और उस पर मार्गदर्शन जान-बूझकर बेढब है: इसे सावधानी से सेट करें, क्योंकि यही उन लोगों को रोकने और जो नहीं हैं उन्हें अंदर आने देने के बीच का संतुलन है, जिनका हक़ बनता है। किसी दरवाज़े पर, वॉचलिस्ट के विपरीत, दोनों ग़लतियों के सामने कोई-न-कोई खड़ा होता है। वह थ्रेशोल्ड, और उसे फ़ीड करने वाले कैमरे की जगह, वही है जिसे तय करने के लिए एक कमीशनिंग विज़िट होती है।
मिलान के साथ-साथ, प्लेटफ़ॉर्म जिस चेहरे को देख रहा है उसके लिए एक स्पूफ़िंग संभावना का अनुमान लगाता है और इसे इवेंट पर समानता स्कोर के बग़ल में प्रतिशत के रूप में दिखाता है। यह केवल एक गेट नहीं है: यह अनुमान इवेंट पर सहेजा जाता है और खोजने-योग्य है, इसलिए "पिछले महीने स्टाफ़ एंट्रेंस पर हर उच्च-स्पूफ़िंग-संभावना वाला इवेंट दिखाओ" एक महीने के वीडियो की समीक्षा नहीं बल्कि एक क्वेरी है।
सेटिंग्स
वही module दोनों चलाता है, पर लगभग हर सेटिंग बदल जाती है। किसी कॉनकोर्स कैमरे को दूर से किसी ख़राब चेहरे पर भी पूरी कोशिश करनी चाहिए; एक रीडर को तब तक फ़ैसला करने से मना करना चाहिए जब तक सही व्यक्ति पर्याप्त पास और सामने न हो।
एक व्यक्ति-सूची में प्रवेश के हक़दार लोग होते हैं, जिन्हें बैच में आयात किया जाता है या एक-एक करके जोड़ा जाता है, और सूची तक पहुँच ख़ुद उपयोगकर्ता-समूह के अनुसार दी जाती है। सूची से बाहर किसी को भी नहीं पहचाना जाता: जो भी चलकर आए उसकी कोई खुली पहचान नहीं होती।
वह समानता स्कोर जिसे किसी मिलान को पार करना होता है। दर्ज निर्देश है कि इस पर ख़ास ध्यान दें और फ़ॉल्स-नेगेटिव व फ़ॉल्स-पॉज़िटिव के बीच संतुलन बनाए रखें, क्योंकि दरवाज़े पर दोनों अलग-अलग तरीक़ों से महँगे पड़ते हैं।
फ़्रेम पर एक आयत खींचकर आपके तय किए आकार से छोटे चेहरों को अनदेखा करता है। यही वह चीज़ है जो किसी रीडर को "match" या "no match" का फ़ैसला बहुत जल्दी करने से रोकती है, जबकि उम्मीदवार अभी चल ही रहा हो और लॉक से आँकने लायक़ दूरी पर न हो।
आपके तय किए दायरे से ज़्यादा झुके या मुड़े चेहरों पर पहचान को दबा देता है, जो त्रुटि-दर को सीधे घटाता है। दरवाज़ा वह एकमात्र जगह है जहाँ आप उचित रूप से यह ज़िद कर सकते हैं कि सब्जेक्ट सामने की ओर देखे।
जब तक चेहरा फ़्रेम में रहता है, पहचान आपके तय किए हर अंतराल पर दोहराई जाती है और हर नतीजे पर एक नया इवेंट बनाती है। जो व्यक्ति तीन मीटर पर नहीं पहचाना गया वह एक मीटर पर पहचान लिया जाता है, बिना उसे पीछे हटकर दोबारा कोशिश करने को कहे।
पहचान अधिकतम सटीकता या न्यूनतम देरी मोड में चलती है, और किसी दरवाज़े पर यह एक वास्तविक चुनाव है, न कि छोड़ देने लायक़ कोई स्लाइडर। जहाँ थ्रूपुट मायने रखता है वहाँ पहचान के लिए ही GPU एक्सेलरेशन उपलब्ध है।
कैमरे पर
एक फ़ोन, एक टैबलेट और काग़ज़ की एक शीट। यही वे हमले हैं जिनके लिए लाइवनेस जाँच मौजूद है, और ये इतने सस्ते हैं कि केवल पहचान से सुरक्षित दरवाज़ा असल में सुरक्षित नहीं है।
सबसे आम प्रेज़ेंटेशन अटैक, क्योंकि सामग्री पहले से ही सार्वजनिक है। कैमरे को जो मिलता है वह एक सपाट, समान रूप से रोशन, बिल्कुल स्थिर चेहरा है, जो ठीक वही है जिसे लाइवनेस जाँच खोजती है।
एक बड़ी स्क्रीन लगभग पूरे दृश्य-क्षेत्र को भर देती है और उसे सही ऊँचाई व दूरी पर रखा जा सकता है। इसे पकड़ने की असली वजह आकार और फ़्रेमिंग नहीं है, और यही चेहरा नापने के बजाय तस्वीर को स्कोर करने का मतलब है।
काग़ज़ की बनावट, सफ़ेद हाशिये, कोने पर एक मोड़: तीनों में सबसे सस्ता हमला और वह जिसके लिए किसी डिवाइस की भी ज़रूरत नहीं। यह वह भी है जिसके लिए बिना लाइवनेस जाँच वाला दरवाज़ा खुल जाएगा।
जाँच
प्लेटफ़ॉर्म अनुमान लगाता है कि कैमरे पर मौजूद चेहरा किसी व्यक्ति के बजाय एक प्रेज़ेंटेशन होने की कितनी संभावना है, और उस स्पूफ़िंग संभावना को प्रतिशत के रूप में इवेंट कार्ड पर, समानता स्कोर के बग़ल में दिखाता है, जहाँ किसी एंट्री की समीक्षा करने वाला ऑपरेटर दोनों एक साथ देख सकता है। यह बाद में सुनाया गया कोई फ़ैसला नहीं बल्कि निर्णय के लिए पेश किया गया एक अनुमान है, और यह API के ज़रिए दूसरी चेहरा-विशेषताओं के साथ इवेंट पर उपलब्ध रहता है।
क्योंकि यह अनुमान इवेंट पर सहेजा जाता है, स्पूफ़िंग संभावना पर भी किसी और मानदंड की तरह ही खोज चलाई जा सकती है। यह एंटी-स्पूफ़िंग को एक गेट से एक ऑडिट सतह में बदल देता है: किसी ख़ास दरवाज़े पर एक अवधि में परखे गए प्रयास, दिन के समय के अनुसार पैटर्न, एक ही प्रवेश-बिंदु पर दोहराए गए प्रयास। कोई दरवाज़ा जिसने पिछले मंगलवार चुपचाप तीन प्रेज़ेंटेशन ठुकरा दिए, वह एक निष्कर्ष है, और यह निष्कर्ष तभी है जब कोई उसे खोज सके।
देखें Ask IREX और वीडियो खोज →स्पूफ़िंग पहचान को ख़ास तौर पर फ़ील्ड में संदिग्ध की पहचान बेहतर करने के लिए मज़बूत किया गया, इसलिए यह अनुमान प्रवेश-बिंदुओं तक सीमित नहीं है: यह पूरे एस्टेट में फेस-इवेंट के साथ चलता है, जो वहाँ मायने रखता है जहाँ किसी कैमरे को व्यक्ति के बजाय एक तस्वीर दिखाई जा सकती है। पहचान वाले पक्ष पर यह किसी अधिकारी के कार्रवाई करने से पहले तौलने लायक़ एक और विशेषता है।
इसे जोड़ना
Sigur को एक्सेस-कंट्रोल इंटीग्रेशन और Netping को बाहरी डिवाइस के रूप में दस्तावेज़ में दर्ज किया गया है, दोनों Settings के तहत बनाए जाते हैं और उपयोगकर्ता-समूह के अनुसार दिए जाते हैं ताकि केवल सही टीमें ही किसी दरवाज़े तक पहुँच सकें। गाइड इस पैटर्न को सामान्य रूप से स्मार्ट लॉक जैसे बाहरी डिवाइस के इंटरफ़ेस बताती है, जो ईमानदार दायरा है: IREX पहचानता और संकेत देता है, एक्सेस-कंट्रोल सिस्टम फ़ैसला लेता और उसे अंजाम देता है।
जहाँ कोई नामित इंटीग्रेशन नहीं है, वहाँ कोई अलार्म मॉनिटर अपने इवेंट फ़्रेम सहित किसी भी HTTP-पहुँच योग्य एंडपॉइंट पर भेज सकता है, और REST API सूचियों, मॉनिटर और उपयोगकर्ताओं को कवर करता है। फेस मैच से दरवाज़ा खुलना दर्ज सिद्ध उदाहरण है। अगर आपका एक्सेस-कंट्रोल प्लेटफ़ॉर्म कोई HTTP कॉल स्वीकार करता है, तो उसे किसी मिलान से चलाया जा सकता है; अगर वह एक भेजता है, तो उसके इवेंट IREX कंसोल में पहुँच सकते हैं।
एक "No match" इवेंट अपनी ही प्राथमिकता वाला एक पूर्ण इवेंट है, इसलिए टेलगेटिंग समीक्षा, ऑफ़-आवर्स प्रयास या किसी संवेदनशील दरवाज़े पर दोहराया गया प्रेज़ेंटेशन किसी के न खोले जाने वाले लॉग की एक पंक्ति के बजाय एक रिस्पॉन्स-प्रोटोकॉल वाला अलार्म मॉनिटर बन जाता है। सूचनाएँ Sover सुरक्षित मैसेंजर के ज़रिए फ़्रेम और प्लेबैक-लिंक के साथ प्रतिक्रियाकर्ता तक पहुँचती हैं।
देखें रियल-टाइम अलर्ट और साक्ष्य →आवश्यकताएँ
नैतिक AI
एक्सेस कंट्रोल वह IREX उपयोग-मामला है जहाँ सिस्टम ख़ुद कार्रवाई करने के सबसे नज़दीक है, इसलिए यहाँ सीमाएँ कम नहीं बल्कि ज़्यादा मायने रखती हैं।
नहीं, और इसे इस रूप में बेचा भी नहीं जाता। IREX पहचान, लाइवनेस व स्पूफ़िंग का अनुमान, इवेंट, और ऑडिट ट्रेल देता है; आपका एक्सेस-कंट्रोल प्लेटफ़ॉर्म दरवाज़े, रीडर, क्रेडेंशियल, और खोलने का फ़ैसला अपने पास रखता है। कनेक्शन या तो एक दर्ज इंटीग्रेशन है, एक्सेस कंट्रोल के लिए Sigur और बाहरी डिवाइस के रूप में Netping, या फिर अलार्म-मॉनिटर वेबहुक, जो किसी भी HTTP-पहुँच योग्य एंडपॉइंट को कॉल कर सकता है। लॉक-एस्टेट के बारे में कुछ भी बदलने की ज़रूरत नहीं।
प्लेटफ़ॉर्म एक स्पूफ़िंग संभावना का अनुमान लगाता है और इसे इवेंट पर प्रतिशत के रूप में बताता है, और वह अनुमान बाद में खोजा भी जा सकता है। IREX इसके लिए कोई पहचान-दर प्रकाशित नहीं करता, जो बिना-आधार सटीकता-आँकड़ों और "गारंटीशुदा पहचान" जैसी भाषा के विरुद्ध स्थायी नीति के अनुरूप है। अगर स्पूफ़िंग-प्रतिरोध कोई निर्णय-मानदंड है, तो इसे एक लिखित पायलट-मानदंड बनाएँ: जिन प्रेज़ेंटेशन की आपको वाक़ई परवाह है उन्हें अपने ही रीडर और कैमरों के विरुद्ध चलाएँ, और मापा गया नतीजा अनुबंध में जाए।
यही ठीक वह हमला है जिसके लिए लाइवनेस जाँच मौजूद है, और इस पेज के तीन फ़्रेम इसके सस्ते रूप हैं: एक फ़ोन, एक टैबलेट, और एक छपी शीट। जाँच यह आँकती है कि कैमरा एक जीवित चेहरा देख रहा है या उसका एक प्रेज़ेंटेशन, और परिणामी संभावना ऑपरेटर के सामने रखी जाती है और इवेंट पर सहेजी जाती है। दरवाज़े को ऐसे डिज़ाइन करें कि इनकार का भी कोई समझदार रास्ता हो, क्योंकि किसी वैध व्यक्ति और उसके काम के कमरे के बीच कोई भी बायोमेट्रिक जाँच अकेली चीज़ नहीं होनी चाहिए।
कोई भी कैमरा जो ONVIF को सपोर्ट करता है या H.264 या H.265 के साथ RTSP स्ट्रीम करता है, पर असली सीमा इमेजिंग की शर्त है: रीजन ऑफ़ इंटरेस्ट में प्रति मीटर 500 पिक्सेल से अधिक और आँख-से-आँख कम-से-कम 50 पिक्सेल, सिर की ऊँचाई पर या थोड़ा ऊपर, 1.5 से 3 मीटर, टिल्ट +5° के भीतर, बिना बैकलाइट और बिना परावर्तन के। किसी गलियारे का कैमरा लगभग कभी यह पूरा नहीं करता। प्रवेश-बिंदु के लिए तय किया गया कैमरा आमतौर पर करता है।
यह एक "No match" इवेंट भेजता है, जिसे आप किसी और इवेंट की तरह प्राथमिकता दे सकते हैं और रूट कर सकते हैं, और री-रिकग्निशन अंतराल का मतलब है कि यह तब तक कोशिश करता रहता है जब तक व्यक्ति फ़्रेम में है, न कि ग़लत दूरी पर एक बार में फ़ैसला कर ले। परिचालन रूप से यही वजह है कि न्यूनतम चेहरा-आकार सेटिंग मौजूद है: एक रीडर जो बहुत जल्दी फ़ैसला कर लेता है, ऐसे इनकार देता है जो कभी वाक़ई फ़ैसले थे ही नहीं।
वह एक अलग module है और उस काम के लिए बेहतर विकल्प भी। अनुमति-प्राप्त वाहनों की सूची के साथ नंबर प्लेट रीडिंग किसी वाहन-गेट को कवर करती है, और जो वेबहुक फेस मैच पर दरवाज़ा खोलता है वही नंबर प्लेट मैच पर बैरियर खोलता है।
यह अपने-आप चलता है और किसी व्यक्ति को अलर्ट करता है। पहचानें किसी इंसान के सत्यापन के लिए संकेत हैं: कोई प्रतिक्रिया स्वायत्त रूप से नहीं चलती, और सत्यापन व निर्णय उसी Case ID के तहत दर्ज होते हैं जिसके तहत पहचान दर्ज हुई थी।
पढ़ते रहें
एक प्रवेश-बिंदु, एक दर्ज सूची, और वे प्रेज़ेंटेशन अटैक जिनकी आपको वाक़ई चिंता है। यह दो-हफ़्ते का पायलट है, और यह किसी डेटाशीट से कहीं बेहतर तरीक़े से सवाल तय करता है।