Mutual TLS (mTLS) कार्यान्वयन पैटर्न

मानक TLS प्रमाणपत्र के माध्यम से केवल क्लाइंट के सामने सर्वर का प्रमाणीकरण करता है। पारस्परिक TLS (mTLS) इसका विस्तार है: दोनों पक्ष प्रमाणपत्र प्रस्तुत करते और उनका सत्यापन करते हैं। सर्वर द्वारा प्रमाणपत्र माँगे जाने के बाद क्लाइंट एक क्लाइंट प्रमाणपत्र प्रस्तुत करता है (TLS हैंडशेक में CertificateRequest के माध्यम से)। सर्वर क्लाइंट प्रमाणपत्र का सत्यापन किसी विश्वसनीय CA के विरुद्ध करता है। mTLS शून्य-विश्वास नेटवर्किंग का आधार है: नेटवर्क की परिधि-सुरक्षा पर निर्भर रहने के बजाय सेवाएँ प्रत्येक कनेक्शन पर क्रिप्टोग्राफ़िक रूप से एक-दूसरे का प्रमाणीकरण करती हैं। इस्तियो, लिंकर्ड और कॉन्सुल कनेक्ट जैसे सेवा-जाल माइक्रोसर्विसों के बीच mTLS को पारदर्शी रूप से लागू करते हैं।

mTLS हैंडशेक TLS 1.3 का इस प्रकार विस्तार करता है: ServerHello और सर्वर प्रमाणपत्र/समापन के बाद सर्वर CertificateRequest संदेश भेजता है, जिसमें स्वीकार्य प्रमाणपत्र प्राधिकरण और हस्ताक्षर एल्गोरिद्म निर्दिष्ट होते हैं। क्लाइंट अपने Certificate (क्लाइंट प्रमाणपत्र शृंखला) और CertificateVerify (क्लाइंट की निजी कुंजी का उपयोग करके ट्रांसक्रिप्ट पर किया गया हस्ताक्षर) से उत्तर देता है। सर्वर अपने विश्वसनीय CA भंडार के विरुद्ध क्लाइंट प्रमाणपत्र शृंखला का सत्यापन करता है और CertificateVerify हस्ताक्षर को मान्य करता है। दोनों सत्यापन सफल होने पर कनेक्शन पारस्परिक रूप से प्रमाणित हो जाता है। प्रमाणपत्र से संबद्ध निजी कुंजी के बिना क्लाइंट CertificateVerify जाली नहीं बना सकता।

सेवा-जाल परिवेशों में क्लाइंट प्रमाणपत्र आमतौर पर किसी आंतरिक CA द्वारा जारी किए जाते हैं। इस्तियो SPIFFE (सभी के लिए सुरक्षित उत्पादन पहचान ढाँचा) SVID का उपयोग करता है: प्रत्येक कार्यभार को SPIFFE URI SAN (विषय-वैकल्पिक नाम) वाला प्रमाणपत्र मिलता है, जैसे spiffe://cluster.local/ns/default/sa/payment-service। इनका जीवनकाल कम होता है (24 घंटे) और जाल का नियंत्रण-तल (istiod) इन्हें अपने-आप बदलता रहता है। उपयोगकर्ता-सामना करने वाले mTLS में (जैसे उद्यम VPN और API क्लाइंट), प्रमाणपत्र किसी कॉर्पोरेट CA द्वारा अधिक लंबे जीवनकाल के साथ जारी किए जा सकते हैं और कर्मचारी उपकरणों के लिए MDM (मोबाइल उपकरण प्रबंधन) के माध्यम से पहुँचाए जा सकते हैं।

सर्वर-पक्ष mTLS सत्यापन में कई चरण शामिल होते हैं: (1) शृंखला सत्यापन — जाँचें कि क्लाइंट प्रमाणपत्र सर्वर के क्लाइंट CA भंडार में मौजूद किसी विश्वसनीय मूल CA तक पहुँचता है। (2) वैधता-अवधि जाँच — सुनिश्चित करें कि प्रमाणपत्र की अवधि समाप्त नहीं हुई है और उसकी वैधता अभी शुरू होने वाली नहीं है। (3) निरस्तीकरण जाँच — OCSP या CRL के माध्यम से सत्यापित करें कि प्रमाणपत्र निरस्त नहीं किया गया है। (4) SAN/CN मिलान — प्रमाणपत्र के SAN से पहचान-दावे को निकालें (SPIFFE URI, DNS नाम या ईमेल)। (5) प्राधिकरण — जाँचें कि प्रमाणित पहचान को अनुरोधित संसाधन तक पहुँचने की अनुमति है। चरण 4 और 5 के लिए मूल TLS विन्यास से आगे अनुप्रयोग-स्तरीय तर्क आवश्यक होता है।

कम-जीवनकाल वाले प्रमाणपत्र स्पष्ट निरस्तीकरण की आवश्यकता समाप्त कर देते हैं: यदि कोई प्रमाणपत्र 24 घंटे में समाप्त हो जाता है, तो उसके साथ समझौता होने का प्रभाव सीमित अवधि तक रहता है। प्रमाणपत्र बदलने के लिए आवश्यक है: (1) पूर्व-बदलाव — पुराने प्रमाणपत्र की अवधि समाप्त होने से पहले नया प्रमाणपत्र जारी करें (जीवनकाल के 80% पर बदलें)। (2) बिना रुकावट बदलाव — संक्रमण अवधि में सेवा को पुराने और नए दोनों प्रमाणपत्र स्वीकार करने चाहिए। (3) सुचारु पुनःलोड — TLS स्टैक को मौजूदा कनेक्शन गिराए बिना प्रमाण-पत्रिकाएँ फिर से लोड करनी चाहिए (nginx: nginx -s reload; Envoy: गतिशील xDS प्रमाणपत्र अद्यतन)। SPIFFE Workload API (SPIRE द्वारा लागू) यूनिक्स डोमेन सॉकेट API के माध्यम से प्रमाणपत्र पहुँचाने और बदलने की प्रक्रिया को स्वचालित करता है।

Istio प्रत्येक पॉड में इंजेक्ट किए गए Envoy साइडकार प्रॉक्सी के माध्यम से mTLS को पारदर्शी रूप से लागू करता है। नियंत्रण तल (istiod) मेष के रूट CA द्वारा हस्ताक्षरित मध्यवर्ती प्रमाणपत्र का उपयोग करके CA की भूमिका निभाता है। प्रत्येक पॉड के साइडकार को SDS (गुप्त खोज सेवा) एपीआई के माध्यम से एक SPIFFE SVID प्राप्त होता है। PeerAuthentication नीतियाँ mTLS मोड कॉन्फ़िगर करती हैं: STRICT (mTLS आवश्यक), PERMISSIVE (mTLS और सादा पाठ दोनों स्वीकार्य, स्थानांतरण के लिए), या DISABLE। AuthorizationPolicy संसाधन परिभाषित करते हैं कि कौन-सी सेवाएँ एक-दूसरे से संचार कर सकती हैं; इसकी जाँच क्लाइंट प्रमाणपत्र में मौजूद SPIFFE पहचान के आधार पर की जाती है। इससे अनुप्रयोग कोड में बदलाव किए बिना क्लस्टर के भीतर शून्य-विश्वास लागू होता है।

बाहरी एपीआई क्लाइंट के लिए, mTLS एपीआई कुंजियों या OAuth टोकनों की तुलना में अधिक मजबूत प्रमाणीकरण प्रदान करता है। क्लाइंट एक निजी कुंजी को सुरक्षित भंडारण (HSM, OS कुंजी-भंडार, या पासफ़्रेज़ वाली सॉफ़्टवेयर कुंजी) में रखता है। क्लाइंट प्रमाणपत्र को एपीआई एंडपॉइंट के अपेक्षित CA से पिन किया जाता है। प्रत्येक एपीआई अनुरोध का प्रमाणीकरण TLS परत पर होता है—अलग से प्राधिकरण हेडर आवश्यक नहीं होता। Cloudflare का API Shield, AWS API Gateway क्लाइंट प्रमाणपत्र और Google Cloud का सेवा-खाता mTLS—सभी इसी मॉडल को लागू करते हैं। समझौता की गई एपीआई कुंजी का उपयोग कहीं से भी किया जा सकता है; लेकिन समझौता की गई mTLS निजी कुंजी के मामले में क्लाइंट चलाने वाले उपकरण की चोरी भी करनी होगी।

mTLS परिनियोजन में कई संचालनात्मक चुनौतियाँ होती हैं। (1) प्रमाणपत्र वितरण—सभी सेवाओं को सुरक्षित रूप से क्लाइंट प्रमाणपत्र पहुँचाना, विशेषकर ऐसे गतिशील वातावरणों में जहाँ पॉड की संख्या बढ़ती और घटती रहती है। (2) CA से समझौता—आंतरिक CA एक अत्यंत मूल्यवान लक्ष्य होता है; इसके साथ समझौता होने पर सभी सेवा प्रमाणपत्र अमान्य कर दिए जाते हैं। HSM-समर्थित CA और ऑफ़लाइन रूट CA इस जोखिम को कम करते हैं। (3) समस्या-निवारण—एन्क्रिप्टेड mTLS ट्रैफ़िक मानक समस्या-निवारण उपकरणों के लिए अपारदर्शी होता है; इसके लिए सेवा-मेष प्रेक्षणीयता (Jaeger, Kiali) आवश्यक होती है। (4) मध्यवर्ती उपकरणों के साथ संगतता—TLS निरीक्षण प्रॉक्सी mTLS को बाधित करते हैं, जब तक कि उन्हें क्लाइंट प्रमाणपत्र आगे भेजने के लिए स्पष्ट रूप से कॉन्फ़िगर न किया जाए। (5) प्रमाणपत्र की समय-सीमा समाप्त होने की घटनाएँ—प्रमाणपत्र रोटेशन विफल होने पर पूरी सेवा बंद हो सकती है।

SPIFFE (सभी के लिए सुरक्षित उत्पादन पहचान रूपरेखा) X.509 SVID के उपयोग से कार्यभार पहचान के लिए एक मानक परिभाषित करता है। SPIRE (SPIFFE रनटाइम वातावरण) इसका संदर्भ कार्यान्वयन है। SPIRE सर्वर पंजीकरण प्राधिकरण और CA के रूप में कार्य करता है। SPIRE एजेंट प्रत्येक नोड पर चलते हैं और नोड सत्यापकों (AWS इंस्टेंस पहचान, Kubernetes सेवा-खाता JWT, TPM) तथा कार्यभार सत्यापकों (Unix PID, कंटेनर रनटाइम मेटाडेटा) का उपयोग करके कार्यभार पहचान का सत्यापन करते हैं। कार्यभार एपीआई एक सरल gRPC एपीआई के माध्यम से Unix डोमेन सॉकेट का उपयोग करके कार्यभारों तक SVID पहुँचाता है। SPIRE, Envoy, Nginx और प्रमुख सेवा-मेषों के साथ प्रमाणपत्र स्रोत के रूप में एकीकृत होता है।

उच्च-सुरक्षा वाले mTLS परिनियोजनों में निजी कुंजियाँ सॉफ़्टवेयर कुंजी-भंडारों के बजाय हार्डवेयर सुरक्षा मॉड्यूल (HSM) में रखी जानी चाहिए। TLS लाइब्रेरी (OpenSSL, BoringSSL) PKCS#11 इंटरफ़ेस के माध्यम से निजी कुंजी लोड करती है, जो हस्ताक्षर संचालन को HSM की ओर भेज देता है। निजी कुंजी सादे पाठ के रूप में HSM की सीमा से बाहर कभी नहीं जाती। क्लाउड HSM विकल्पों में AWS CloudHSM, Azure Dedicated HSM और Google Cloud HSM शामिल हैं। उपकरण-स्तरीय mTLS (IoT, उद्यम लैपटॉप) के लिए TPM 2.0 समान कार्य करता है—TLS क्लाइंट कुंजी TPM से बंधी होती है और हस्ताक्षर के लिए TPM प्राधिकरण आवश्यक होता है, जिससे समझौता किए गए उपकरण से कुंजी निकालना अत्यंत कठिन हो जाता है।

mTLS के परीक्षण के लिए ऐसे उपकरण आवश्यक हैं जो क्लाइंट प्रमाणपत्र प्रस्तुत करने का समर्थन करते हों। OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. सेवा-मेष के परीक्षण के लिए, istioctl proxy-config secret pod/name वर्तमान प्रमाणपत्र और उसकी समय-सीमा समाप्ति दिखाता है। सक्रिय लिस्नर और उनके mTLS कॉन्फ़िगरेशन की जाँच करने के लिए किसी पॉड में kubectl exec चलाकर साइडकार के प्रशासनिक एंडपॉइंट (localhost:15000) पर curl करें। स्वचालित रोटेशन परीक्षण में यह सत्यापित किया जाना चाहिए कि प्रमाणपत्र रोटेशन की घटनाओं के दौरान कनेक्शन स्थिर बने रहें।

mTLS, TLS में क्लाइंट प्रमाणपत्र प्रमाणीकरण जोड़ता है—दोनों पक्ष एक-दूसरे के प्रमाणपत्रों का सत्यापन करते हैं। SPIFFE SVID, प्रमाणपत्र SAN में मौजूद SPIFFE URI के माध्यम से मानकीकृत कार्यभार पहचान प्रदान करते हैं। Istio, Envoy साइडकार के माध्यम से STRICT/PERMISSIVE मोड के साथ mTLS को पारदर्शी रूप से लागू करता है। कम-अवधि वाले प्रमाणपत्र (24 घंटे) निरस्तीकरण की आवश्यकता समाप्त करते हैं और समझौते की समय-सीमा सीमित करते हैं। SPIRE, कार्यभार एपीआई के माध्यम से प्रमाणपत्र जारी करने और रोटेशन को स्वचालित करता है। उच्च-सुरक्षा वाले परिनियोजनों में mTLS निजी कुंजियाँ HSM या TPM में रखी जानी चाहिए। संचालनात्मक चुनौतियों में CA कुंजी की सुरक्षा, मध्यवर्ती उपकरणों के साथ संगतता और बिना डाउनटाइम वाले रोटेशन शामिल हैं।