[ क्षेत्रीय आवश्यकताएँ ]

रोगी-डेटा एक्सपोज़र का अनुमान लगाए बिना हेल्थकेयर-डोमेन प्रमाणीकरण पर शोध करें

DNS से ​​रोगी-डेटा एक्सपोज़र का अनुमान लगाए बिना देखभाल-सेटिंग और साझा-सिस्टम सीमाओं के आसपास हेल्थकेयर-डोमेन अनुसंधान डिज़ाइन करें।

EmailAuth अनुसंधान टीम द्वारा · 8 मिनट पढ़ा

[ प्रमुख बिंदु ]

  • एक अस्पताल का नमूना संपूर्ण स्वास्थ्य सेवा क्षेत्र नहीं है।
  • साझा सिस्टम और आपूर्तिकर्ता डोमेन को स्पष्ट मैपिंग और वेटिंग की आवश्यकता होती है।
  • सार्वजनिक प्रमाणीकरण अवलोकन रोगी के संपर्क या अनुपालन को स्थापित नहीं करते हैं।
इस पेज पर
  1. प्रमुख बिंदु
  2. सार्वजनिक डोमेन संपत्ति को मापें, रोगी के प्रदर्शन को नहीं
  3. देखभाल-निर्धारण करने वाली जनसंख्या को सटीक रूप से चुनें
  4. अलग सुविधाएँ, प्रणालियाँ और साझा ब्रांड
  5. प्रत्येक नमूना डोमेन की भूमिका की पहचान करें
  6. साझा बुनियादी ढाँचे को निर्भरता के रूप में समझें, श्रेय के रूप में नहीं
  7. एक प्रतिलिपि प्रस्तुत करने योग्य संग्रह विधि बनाए रखें
  8. संदेश और परिवहन साक्ष्य को अलग रखें
  9. एक स्वास्थ्य देखभाल अनुसंधान कार्यपत्रक
  10. काल्पनिक निदान: एक साझा वेबसाइट रोगी-जोखिम शीर्षक बन जाती है
  11. रिलीज़ स्थिति
  12. ले लेना
  13. भूमिका के अनुसार
  14. अक्सर पूछे जाने वाले प्रश्नों
  15. सूत्रों का कहना है
  16. शब्दकोष
  17. संबंधित मार्गदर्शिकाएँ

सार्वजनिक डोमेन संपत्ति को मापें, रोगी के प्रदर्शन को नहीं

हेल्थकेयर-डोमेन प्रमाणीकरण अनुसंधान एक परिभाषित नमूने के भीतर सार्वजनिक DNS कॉन्फ़िगरेशन का वर्णन कर सकता है। यह स्थापित नहीं कर सकता कि रोगी डेटा उजागर हुआ था, कि एक नैदानिक ​​​​प्रणाली असुरक्षित है या किसी संगठन ने कानूनी दायित्व का उल्लंघन किया है। एक सार्वजनिक वेबसाइट डोमेन रोगी के संचार को बिल्कुल भी प्रसारित नहीं कर सकता है। विधि को देखी गई तकनीकी संपत्ति, स्वास्थ्य सेवा इकाई मानचित्रण और किसी भी मापे न गए परिचालन जोखिम को शुरुआत से अलग रखना चाहिए।

इस पांडुलिपि में रोगी की कोई जानकारी, संगठनात्मक स्कैन या अनुपालन निष्कर्ष शामिल नहीं हैं। यह स्पष्ट सीमाओं के साथ एक प्रतिलिपि प्रस्तुत करने योग्य अध्ययन डिजाइन का प्रस्ताव करता है। यह तथ्य कि स्वास्थ्य देखभाल संवेदनशील है, सावधानीपूर्वक आरोपण को अधिक महत्वपूर्ण बनाता है, कम नहीं: एक कमजोर समर्थित शीर्षक साक्ष्य से एक गंभीर आरोप बना सकता है जो केवल एक संकीर्ण DNS अवलोकन का समर्थन करता है।

देखभाल-निर्धारण करने वाली जनसंख्या को सटीक रूप से चुनें

सीएमएस का अस्पताल गुणवत्ता पहल सार्वजनिक-रिपोर्टिंग पृष्ठ देखभाल तुलना और प्रदाता डेटा कैटलॉग पर अस्पताल की जानकारी का वर्णन करता है। इसमें कहा गया है कि अस्पताल का प्रदर्शन आम तौर पर निर्दिष्ट अस्पताल प्रकारों तक सीमित होता है और इसमें मेडिकेयर-प्रमाणित अस्पतालों का डेटा शामिल होता है। यह एक सीमित आधिकारिक स्रोत संदर्भ है, न कि प्रत्येक स्वास्थ्य सेवा संगठन, चिकित्सक, बीमाकर्ता, प्रयोगशाला या देखभाल सुविधा की जनगणना।

उस स्रोत का उपयोग करने वाले अध्ययन को अपना दायरा और रिलीज की तारीख बरकरार रखनी चाहिए। किसी अन्य देश या देखभाल सेटिंग के अध्ययन के लिए अपनी स्वयं की आधिकारिक आबादी या स्पष्ट रूप से बंधे हुए नमूने की आवश्यकता होती है। जो छोड़ा गया है उसे बताए बिना किसी अस्पताल को स्वास्थ्य सेवा क्षेत्र का नमूना न कहें। इस ड्राफ्ट के लिए कोई सीएमएस डेटासेट या सुविधा सूची डाउनलोड नहीं की गई थी; स्रोत केवल जनसंख्या-डिज़ाइन प्रश्नों का समर्थन करता है।

अलग सुविधाएँ, प्रणालियाँ और साझा ब्रांड

एक स्वास्थ्य प्रणाली एक डोमेन के तहत कई अस्पतालों, क्लीनिकों और सार्वजनिक ब्रांडों को संचालित कर सकती है, जबकि एक सुविधा अधिग्रहण के बाद कई वेबसाइटों या विरासत में मिले डोमेन का उपयोग कर सकती है। सुविधा पहचानकर्ता, मूल प्रणाली, ब्रांड संबंध और जहां समर्थित हो वहां प्रभावी तिथियां रिकॉर्ड करें। प्रत्येक सुविधा के साझा डोमेन को बार-बार गिनने से स्वतंत्र तकनीकी टिप्पणियों को जोड़े बिना अध्ययन का महत्व बदल सकता है।

तय करें कि विश्लेषण सुविधा-भारित है, संगठन-भारित है या डोमेन-भारित है। रिश्तों को सुरक्षित रखें ताकि कोई अन्य विश्लेषक बिना अनुमान लगाए एक अलग दृष्टिकोण की गणना कर सके। संगठनों का विलय केवल इसलिए न करें क्योंकि उनके नाम या वेबसाइट डिज़ाइन एक-दूसरे से मिलते जुलते हैं। मैपिंग को बनाए गए स्रोतों पर निर्भर होना चाहिए, और अनसुलझे रिश्ते बहिष्करण या अनिश्चितता लॉग में दिखाई देने चाहिए।

प्रत्येक नमूना डोमेन की भूमिका की पहचान करें

एक सार्वजनिक अस्पताल की वेबसाइट, एक रोगी पोर्टल, एक भर्ती साइट, एक धन उगाहने वाला मंच और एक अनुस्मारक सेवा में अलग-अलग ऑपरेटर और मेल पहचान हो सकती हैं। अध्ययन को यह पहचानना चाहिए कि नमूना डोमेन के लिए वास्तव में कौन सी भूमिका प्रमाणित है। आधिकारिक जनसंख्या स्रोत में एक वेबसाइट लिंक नियुक्ति अनुस्मारक, नैदानिक ​​​​पत्राचार या बिलिंग संदेशों के लिए उपयोग किए जाने वाले डोमेन को स्थापित नहीं करता है।

RFC 7208 और RFC 9989 विशिष्ट SMTP और संदेश-डोमेन पहचान के संदर्भ में प्रमाणीकरण को परिभाषित करें। केवल DNS अवलोकन लुप्त संदेश संदर्भ को नहीं भर सकता। बिना किसी अलग अधिकृत कार्य के उन पहचानों का अनुमान लगाने के लिए परीक्षण संदेश न भेजें, रोगी पोर्टलों के साथ बातचीत न करें या निजी संचार का निरीक्षण न करें। इनमें से कोई भी कार्रवाई यहां नहीं हुई.

साझा बुनियादी ढाँचे को निर्भरता के रूप में समझें, श्रेय के रूप में नहीं

कई स्वास्थ्य सेवा संगठन एक ही DNS होस्ट, ईमेल प्लेटफ़ॉर्म या रोगी-सगाई आपूर्तिकर्ता का उपयोग कर सकते हैं। देखी गई सामान्य निर्भरता साझा प्रशासनिक नियंत्रण या समान प्रमाणीकरण व्यवहार को साबित नहीं करती है। खाता-विशिष्ट कॉन्फ़िगरेशन, उत्पाद मार्ग और कस्टम-डोमेन विकल्प भिन्न हो सकते हैं। एक ग्राहक के परिणाम को प्रदाता के प्रत्येक दूसरे ग्राहक पर आरोपित किए बिना निर्भरता और उसके साक्ष्य को रिकॉर्ड करें।

इसी तरह, सार्वजनिक रिकॉर्ड में आपूर्तिकर्ता के स्वामित्व वाला डोमेन यह प्रदर्शित नहीं करता है कि रोगी की जानकारी उस सेवा के माध्यम से प्रवाहित होती है। अध्ययन में डेटा सामग्री या क्लिनिकल वर्कफ़्लो का अवलोकन नहीं किया गया है। कॉन्फ़िगरेशन संबंधों को डेटा प्रोसेसिंग के दावों से अलग रखें। रोगी-डेटा एक्सपोज़र के किसी भी मूल्यांकन के लिए उचित अधिकृत साक्ष्य और योग्य समीक्षा की आवश्यकता होगी, न कि DNS नामों से एक्सट्रपलेशन की।

एक प्रतिलिपि प्रस्तुत करने योग्य संग्रह विधि बनाए रखें

डोमेन मैपिंग को फ़्रीज़ करें और सटीक क्वेरीज़, रिज़ॉल्वर स्रोत, अवलोकन विंडो, पुनः प्रयास नियम और पार्सर संस्करण परिभाषित करें। जहां एकत्र किया गया है वहां आधिकारिक और पुनरावर्ती टिप्पणियों को अलग-अलग संरक्षित करें। RFC 1035 DNS संरचना को परिभाषित करता है; एक रिकॉर्ड के भीतर एकाधिक TXT स्ट्रिंग्स को एकाधिक रिकॉर्ड के साथ भ्रमित नहीं किया जाना चाहिए। प्रोटोकॉल-विशिष्ट व्याख्या को कच्चे उत्तर के विश्वसनीय संरक्षण का पालन करना चाहिए।

बिना डेटा, नाम त्रुटि, टाइमआउट, सर्वर विफलता, विकृत नीति और अनसुलझे खोज के लिए परिणाम श्रेणियां परिभाषित करें। प्रत्येक संग्रहण विफलता को प्रमाणीकरण की कमी वाले स्वास्थ्य सेवा संगठन के रूप में रिपोर्ट न करें। घोषित पुनः प्रयास नीति के तहत सभी प्रयासों को बनाए रखें ताकि बाद में समीक्षक क्षणिक विफलताओं का आकलन कर सकें। इस पांडुलिपि के लिए कोई DNS संग्रह नहीं किया गया था, और कोई आविष्कृत स्कैन परिणाम शामिल नहीं है।

संदेश और परिवहन साक्ष्य को अलग रखें

एक प्रकाशित DMARC नीति डोमेन प्रमाणीकरण व्यवहार से संबंधित है, न कि एन्क्रिप्टेड परिवहन या किसी विशिष्ट संदेश की गोपनीयता के प्रमाण से। RFC 8461 को परिभाषित करता है MTA-STS मेल प्राप्त करने की परिवहन नीति के लिए एक अलग तंत्र। यहां तक ​​कि परिवहन-नीति अवलोकन से भी यह पता नहीं चलता है कि क्या कोई विशेष नैदानिक ​​संदेश भेजा गया था, इसमें किस मार्ग का उपयोग किया गया था या इसमें क्या शामिल था।

यदि कोई भावी अधिकृत अध्ययन प्राप्त-संदेश साक्ष्य जोड़ता है, RFC 8601 की ट्रस्ट सीमा पर ध्यान देने की आवश्यकता है Authentication-Results. इस तरह के साक्ष्य एक दायरे वाले संदेश अवलोकन का समर्थन करेंगे, न कि डिफ़ॉल्ट रूप से रोगी-प्रदर्शन निष्कर्षों का। जब सार्वजनिक कॉन्फ़िगरेशन वास्तविक विषय हो तो अनुसंधान डिज़ाइन को रोगी पहचानकर्ताओं या संदेश निकायों को एकत्र करने से बचना चाहिए।

एक स्वास्थ्य देखभाल अनुसंधान कार्यपत्रक

जनसंख्या स्रोत, रिलीज़ दिनांक, देखभाल सेटिंग, सुविधा पहचानकर्ता, सिस्टम संबंध, ब्रांड, डोमेन भूमिका और मैपिंग साक्ष्य के लिए फ़ील्ड बनाएं। डोमेन वेटिंग, क्वेरी इनपुट, टाइमस्टैम्प, कच्चे साक्ष्य हैश, पार्सर संस्करण, परिणाम श्रेणी, त्रुटि इतिहास और बहिष्करण कारण जोड़ें। एक स्पष्ट दावा-सीमा फ़ील्ड शामिल करें जिसमें कहा गया हो कि अवलोकन रोगी-डेटा प्रबंधन, एक्सपोज़र या नियामक अनुपालन स्थापित नहीं करता है।

समीक्षा में तकनीकी प्रतिलिपि प्रस्तुत करने योग्यता और प्रकाशन की भाषा दोनों का निरीक्षण करना चाहिए। नमूना किए गए वेब डोमेन पर कोई नीति नहीं देखी गई लेबल वाला परिणाम संगठन के असुरक्षित या जोखिम में रोगी डेटा से अधिक संकीर्ण है। साक्ष्य द्वारा समर्थित संकीर्ण शब्दों का प्रयोग करें। यदि कोई वास्तविक गंभीर मुद्दा बाद में अधिकृत कार्य के माध्यम से खोजा जाता है, तो सार्वजनिक अध्ययन को एक असमर्थित आरोप चैनल के रूप में उपयोग करने के बजाय उचित जिम्मेदार प्रक्रिया के तहत इसे संभालें।

काल्पनिक निदान: एक साझा वेबसाइट रोगी-जोखिम शीर्षक बन जाती है

एक काल्पनिक अध्ययन कई अस्पतालों को एक स्वास्थ्य-प्रणाली वेबसाइट पर मैप करता है और एक अनसुलझे प्रमाणीकरण प्रश्न का अवलोकन करता है। एक मसौदा शीर्षक में दावा किया गया है कि उन सभी अस्पतालों में मरीज़ उजागर हो रहे हैं। प्रस्तावित समीक्षा इस निष्कर्ष को खारिज करती है: क्वेरी ने परिचालन प्रेषक संपत्ति, संदेश सामग्री या किसी भी डेटा प्रकटीकरण को स्थापित नहीं किया, और बार-बार सुविधा पंक्तियाँ स्वतंत्र निष्कर्ष नहीं बनाती हैं।

टीम संकीर्ण अनसुलझे DNS परिणाम, दस्तावेज़ साझा-डोमेन वेटिंग को बनाए रखेगी और रोगी-एक्सपोज़र दावे को हटा देगी। यदि वैध आवश्यकता मौजूद है तो यह एक अलग, उचित रूप से अधिकृत मूल्यांकन का प्रयास कर सकता है। यह परिदृश्य काल्पनिक है और इसमें कोई वास्तविक अस्पताल, रोगी, स्कैन या घटना शामिल नहीं है। इसका उद्देश्य सार्वजनिक विन्यास अनुसंधान और संवेदनशील जोखिम आरोपों के बीच की सीमा को प्रदर्शित करना है।

रिलीज़ स्थिति

कैटलॉग को एक संस्करणित डेटासेट, क्वेरी विधि और त्रुटि/बहिष्करण लॉग की आवश्यकता होती है जिसे कोई अन्य विश्लेषक पुन: उत्पन्न कर सकता है। वे मूल कलाकृतियाँ खुली रहती हैं। मानव विशेषज्ञ समीक्षा, स्रोत प्रयोज्यता, उत्पादन मार्ग, पहुंच और मालिक की रिहाई भी खुली रहती है। यह मसौदा एक स्वास्थ्य देखभाल-विशिष्ट विधि प्रदान करता है, न कि कोई किया गया अध्ययन, किसी प्रदाता का निदान या रोगी की जानकारी के बारे में अनुमान।

[ ले लेना ]

स्वास्थ्य देखभाल इकाई की उत्पत्ति, DNS साक्ष्य और संवेदनशील जोखिम दावों को अलग रखें।

[भूमिका के अनुसार]

आपके लिए इसका क्या मतलब है

व्यावहारिक अगले चरणों के लिए अपनी भूमिका चुनें।

हेल्थकेयर शोधकर्ता

देखभाल सेटिंग को परिभाषित करें

अस्पताल के एक आधिकारिक सूत्र ने कवरेज सीमित कर दी है।

अगले कदम

  1. स्रोत रिलीज़ और सुविधा प्रकार को बनाए रखें।
  2. प्रत्येक प्रदाता का सामान्यीकरण न करें।

डेटा विश्लेषक

मॉडल साझा बुनियादी ढाँचा

कई सुविधाएं स्वतंत्र कॉन्फ़िगरेशन के बिना एक डोमेन साझा कर सकती हैं।

अगले कदम

  1. सिस्टम संबंधों को सुरक्षित रखें.
  2. राज्य भार और डोमेन भूमिका।

गोपनीयता और संपादकीय समीक्षक

असमर्थित एक्सपोज़र दावों को रोकें

केवल सार्वजनिक DNS परिणाम से कोई रोगी-डेटा निष्कर्ष नहीं निकलता है।

अगले कदम

  1. अनावश्यक संवेदनशील डेटा को बाहर रखें.
  2. संकीर्ण तकनीकी शब्दों का प्रयोग करें.

[ पूछे जाने वाले प्रश्न ]

अक्सर पूछे जाने वाले प्रश्नों

क्या सीएमएस अस्पताल की रिपोर्टिंग सभी स्वास्थ्य देखभाल का प्रतिनिधित्व करती है?

नहीं, उद्धृत पृष्ठ परिभाषित अस्पताल कवरेज और मेडिकेयर-प्रमाणित अस्पताल डेटा का वर्णन करता है, प्रत्येक स्वास्थ्य देखभाल इकाई का नहीं।

सीएमएस: अस्पताल गुणवत्ता पहल सार्वजनिक रिपोर्टिंग

क्या साझा सिस्टम डोमेन को बार-बार गिना जा सकता है?

केवल एक स्पष्ट सुविधा-भारित डिज़ाइन के तहत; रिश्ते को बनाए रखें ताकि महत्व दिखाई दे।

क्या कोई सार्वजनिक वेबसाइट रोगी-संदेश डोमेन की पहचान करती है?

नहीं, पोर्टल, रिमाइंडर, बिलिंग और भर्ती विभिन्न ऑपरेटरों और पहचान का उपयोग कर सकते हैं।

क्या एक सामान्य आपूर्तिकर्ता समान सुरक्षा व्यवहार साबित करता है?

नहीं, उत्पाद मार्ग और खाता कॉन्फ़िगरेशन भिन्न हो सकते हैं; साझा निर्भरता साझा-नियंत्रण प्रमाण नहीं है।

क्या DMARC प्रकाशन एन्क्रिप्टेड परिवहन स्थापित कर सकता है?

नहीं, MTA-STS एक अलग परिवहन-नीति तंत्र है, और न ही अवलोकन से संदेश सामग्री का पता चलता है।

RFC 8461 : SMTP एमटीए सख्त परिवहन सुरक्षा

क्या DNS खोज रोगी-डेटा एक्सपोज़र को साबित कर सकती है?

नहीं, इस तरह के निष्कर्ष के लिए अलग-अलग अधिकृत साक्ष्य और योग्य समीक्षा की आवश्यकता होती है।

क्या मरीज़ के डेटा या अस्पताल सिस्टम तक पहुंच बनाई गई थी?

नहीं, कोई मरीज की जानकारी, पोर्टल इंटरैक्शन या डोमेन स्कैन नहीं हुआ।

कौन सा मूल साक्ष्य खुला रहता है?

संस्करणित डेटासेट, क्वेरी विधि और त्रुटि/बहिष्करण लॉग खुले रहते हैं।

[ सूत्रों का कहना है ]

सूत्रों का कहना है

  1. RFC 1035 : डोमेन नाम कार्यान्वयन और विशिष्टता

    धारा §3.3.14 TXT आरडीएटीए प्रारूप · §4.1 प्रारूप · §5.1 प्रारूप

  2. RFC 9989: DMARC

    धारा §4.7 DMARC नीति रिकॉर्ड प्रारूप · §4.8 औपचारिक परिभाषा · §4.10 DNS ट्री वॉक · §5.3.2 निर्धारित करें कि क्या DMARC तंत्र लागू होता है · §4.4 पहचानकर्ता संरेखण समझाया गया · ए.6 पीसीटी टैग को हटाना

  3. RFC 8601: Authentication-Results

    धारा §1.2 विश्वास सीमा · §7. सुरक्षा संबंधी विचार

  4. RFC 7208 : प्रेषक नीति ढांचा

    धारा §2.4 पहचान से मेल · §3.2 एकाधिक DNS रिकॉर्ड · §4.5 रिकॉर्ड्स का चयन · §4.6.4 DNS लुकअप सीमाएं · §5.2 में शामिल · §6.1 रीडायरेक्ट · §8 परिणाम प्रबंधन

  5. RFC 8461 : SMTP एमटीए सख्त परिवहन सुरक्षा

    धारा §3.1 MTA-STS TXT रिकॉर्ड्स · §3.2 MTA-STS नीतियां · §3.3 एचटीटीपीएस नीति प्राप्त करना · §4.1 MX होस्ट सत्यापन · §5 नीति आवेदन · §8.1 नीति अपडेट

  6. सीएमएस: अस्पताल गुणवत्ता पहल सार्वजनिक रिपोर्टिंग

    धारा अस्पताल गुणवत्ता पहल सार्वजनिक रिपोर्टिंग

[ शब्दकोष ]

शब्दकोष

केयर-सेटिंग फ्रेम
अध्ययन के लिए सीमित स्वास्थ्य देखभाल आबादी का चयन किया गया।

सीएमएस: अस्पताल गुणवत्ता पहल सार्वजनिक रिपोर्टिंग

सुविधा भार
एक गणना दृष्टिकोण जो साझा-डोमेन संबंधों को बनाए रखते हुए सुविधाओं को इकाइयों के रूप में मानता है।
डोमेन भूमिका
किसी नमूना नाम का प्रमाणित उद्देश्य, जैसे सार्वजनिक वेबसाइट या ज्ञात भेजने वाली पहचान।
एक्सपोज़र अनुमान सीमा
DNS अवलोकन को रोगी की जानकारी के बारे में असमर्थित दावा बनने से रोकने वाली सीमा।

उद्यम उद्गम

शीर्ष वित्तीय संस्थान और सरकारें ही क्यों? अपने ईमेल सुरक्षा डैशबोर्ड हटा दिए।

पारंपरिक ईमेल प्रमाणीकरण प्लेटफ़ॉर्म आपको एक डैशबोर्ड बेचते हैं और आपके इंजीनियरों से काम करने के लिए कहते हैं। उच्च जोखिम वाले वातावरण में, मैन्युअल निरीक्षण का अर्थ है विलंबित प्रवर्तन, कॉन्फ़िगरेशन बहाव और अनियंत्रित छाया डोमेन।

EmailAuth एजेंटिक ईमेल उद्गम मंच है। हमारे एजेंट लागू करते हैं p=reject, तृतीय-पक्ष प्रेषकों को संरेखित रखें और अपने डोमेन को पूर्ण रूप से स्थानांतरित करें RFC 9989 अनुपालन, नया DMARC मानक, मानव-इन-द-लूप ऑडिटेबिलिटी के साथ।

सरकारों बड़े उद्यम टियर-1 वित्तीय संस्थान

सास · समर्पित किरायेदारी · एयर-गैप्ड ऑन-प्रिमाइसेस · BYOK एन्क्रिप्शन

ज्ञानधार