सुरक्षित रखें, सहेजें और साबित करें

🌐 28 अन्य भाषाओं में भी उपलब्ध

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI से बनाई गई इमेज

AI द्वारा अनुवादित। समुदाय ने अभी इसकी समीक्षा नहीं की है। अंग्रेज़ी में पढ़ें

मॉड्यूल 6 (कुल 6 में से) — अध्याय डेटा गुणवत्ता और गवर्नेंस, Data Architect कोर्स का अध्याय 5। हर मॉड्यूल अपने आप में पूरा है। पिछला: सहमति और भुला दिए जाने का अधिकार · अगला: अगला अध्याय, मास्टर डेटा और पहचान

यह मॉड्यूल किस सवाल का जवाब देता है: आप डेटा को सुरक्षित कैसे रखें, उसे ज़रूरी समय तक कैसे सहेजें, और यह साबित कैसे करें?

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

गवर्नेंस डेटा के पीछे चलती है

मैं गवर्नेंस को एक फ़ीचर के रूप में नहीं देखता। मैं सोचता हूँ कि डेटा के आने के पल से लेकर हमारे उसके साथ काम खत्म करने तक उसके साथ क्या होता है:

कैप्चर → वर्गीकरण → सुरक्षा → उपयोग → रिटेंशन → डिलीशन → ऑडिट

ये सात तकनीकी प्रक्रियाएँ नहीं हैं: ये सात सवाल हैं जिनका जवाब आर्किटेक्चर को देना है। कैप्चर और वर्गीकरण हम कवर कर चुके हैं: महँगी गलतियों को बाहर रखें (मॉड्यूल 2), और जानें कि कौन-सा डेटा संवेदनशील है (मॉड्यूल 3)। वर्गीकरण तय करता है कि बाद के हर चरण में क्या होता है, इसलिए यह मॉड्यूल वहीं से आगे बढ़ता है।

Click to enlarge

डेटा के पूरे जीवन में सात सवाल। टूल नीति को सहारा देते हैं; उसे परिभाषित नहीं करते।

सुरक्षा: कंट्रोल को डेटा के हिसाब से चुनें

इसे कौन देख सकता है, बदल सकता है, पा सकता है? क्या इसे एन्क्रिप्ट किया जाए, प्रोडक्शन के बाहर मास्क किया जाए, एक्सपोर्ट होने दिया जाए, किसी एजेंट की पहुँच में रखा जाए? यहीं Salesforce सिक्योरिटी डेटा गवर्नेंस का हिस्सा बनती है: शेयरिंग, ऑब्जेक्ट और फ़ील्ड परमिशन, एन्क्रिप्शन, मास्किंग, इंटीग्रेशन एक्सेस। इन विषयों पर पूरे-पूरे कोर्स हैं, इसलिए मैं उन्हें दोबारा नहीं पढ़ाऊँगा। गवर्नेंस की बात यह है: सुरक्षा वर्गीकरण और नीति के पीछे चलती है। हर फ़ील्ड को एक जैसी सुरक्षा नहीं चाहिए, हर यूज़र को एक जैसा एक्सेस नहीं, हर डाउनस्ट्रीम सिस्टम को हर फ़ील्ड नहीं।

एन्क्रिप्शन एक कंट्रोल है, कम्प्लायंस नहीं

विनियमित डेटा के लिए at rest एन्क्रिप्शन ज़रूरी हो सकता है, और मेरा पक्ष है कि ऐसी अहम नियामक आवश्यकताओं के लिए Shield ही जवाब है। Shield Platform Encryption फ़ील्ड और फ़ाइलों को at rest एन्क्रिप्ट करता है। लेकिन “हमने इसे एन्क्रिप्ट कर दिया, तो हम कम्प्लायंट हैं” दो तरह से गलत है। एन्क्रिप्शन एक्सेस, रिटेंशन, ऑडिट, सहमति, मॉनिटरिंग, न्यूनतम डेटा और डिलीशन के साथ कई कंट्रोल में से एक है। और इसके कामकाजी ट्रेड-ऑफ़ हैं जिनके लिए आप पहले से डिज़ाइन करते हैं। डिफ़ॉल्ट probabilistic स्कीम के साथ, एन्क्रिप्टेड फ़ील्ड SOQL के WHERE, GROUP BY या ORDER BY क्लॉज़ में या डेटा-मैनेजमेंट फ़िल्टर में इस्तेमाल नहीं हो सकता; deterministic एन्क्रिप्शन थोड़ी मज़बूती छोड़ता है ताकि आप उस फ़ील्ड पर फ़िल्टर कर सकें। एन्क्रिप्टेड फ़ील्ड criteria-based शेयरिंग रूल नहीं चला सकते, और आप उनसे list view सॉर्ट नहीं कर सकते (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab))। इसलिए एन्क्रिप्शन आखिर में टिक किया जाने वाला कोई चेकबॉक्स नहीं है। यह एक आर्किटेक्चर फ़ैसला है। डेटा सिक्योरिटी वाला अध्याय इसमें गहराई से जाता है।

प्रोडक्शन का जोखिम सैंडबॉक्स में कॉपी न करें

प्रोडक्शन कसकर बंद है। फिर कोई एक full sandbox रिफ़्रेश करता है, और अब डेवलपर, टेस्टर, कॉन्ट्रैक्टर और टेस्ट इंटीग्रेशन के पास असली व्यक्तिगत डेटा की कॉपियाँ हैं, जिनकी उन्हें कभी ज़रूरत नहीं थी। एनवायरनमेंट बदल गया; डेटा की संवेदनशीलता नहीं। Salesforce के मास्किंग टूल ठीक इसी के लिए हैं। एक बदलाव पर ध्यान दें: Data Mask managed package की सर्विस 31 दिसंबर 2026 को खत्म होती है, और उसका उत्तराधिकारी Data Mask & Seed है (Data Mask (Legacy) (opens in a new tab))। लेकिन टूल नीति को सहारा देता है, और सवाल पहले आता है: क्या इस एनवायरनमेंट को असली संवेदनशील डेटा की ज़रूरत है भी? अगर असली जैसा दिखने वाला, गैर-संवेदनशील डेटा टेस्टिंग कर सकता है, तो वही बेहतर जवाब है।

उपयोग: अनुमति सिर्फ़ लोगों की बात नहीं है

यूज़र, इंटीग्रेशन, एनालिटिक्स, पार्टनर, ऑटोमेशन और एजेंट, सभी डेटा इस्तेमाल करते हैं। सहमति (मॉड्यूल 5), स्वामित्व (मॉड्यूल 1) और वर्गीकरण (मॉड्यूल 3) यहाँ रनटाइम पर मिलते हैं। क्या इस यूज़र को प्राप्तकर्ता का फ़ोन नंबर दिखना चाहिए? क्या इस इंटीग्रेशन को मिलना चाहिए, या Snowflake को, या इस एजेंट को grounding के रूप में? जवाब यह नहीं हो सकता कि “तकनीकी रूप से तो हो सकता है।” क्षमता और गवर्नेंस में यही फ़र्क है: आर्किटेक्चर तय करता है कि ऐसा होना चाहिए या नहीं।

रिटेंशन: सब कुछ हमेशा के लिए रखना तटस्थ नहीं है

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

और आर्काइव करना रिटेंशन को हल करने जैसा नहीं है। “हमने इसे आर्काइव कर दिया।” क्या रिटेंशन की आवश्यकता चली गई? प्राइवेसी की आवश्यकता? सिक्योरिटी? आपने बदला कि डेटा कहाँ रहता है, यह नहीं कि वह क्या है। आर्काइव को एक्सेस कंट्रोल, रिटेंशन और डिलीशन के नियम, डिस्कवरी और ऑडिट चाहिए। व्यक्तिगत डेटा को ऐसे आर्काइव में डाल दें जिसे सब भूल जाते हैं, और गवर्नेंस बस और खराब हो गई।

डिलीशन: जीवनचक्र को एक निकास चाहिए

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

इतिहास भी डेटा है

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

स्टैंडर्ड फ़ील्ड हिस्ट्री ट्रैकिंग हर ऑब्जेक्ट पर 20 फ़ील्ड तक ट्रैक करती है और बदलाव 18 महीने तक रखती है, और 24 महीने तक सिर्फ़ API के ज़रिए, Data Loader या queryAll() से (Field History Tracking Overview (opens in a new tab))। और लंबे टेक्स्ट फ़ील्ड के लिए यह सिर्फ़ इतना दर्ज करती है कि फ़ील्ड बदला गया, यह नहीं कि उसमें क्या लिखा था: अगर वही आपका सबूत है, तो यह एक कमी है। Field Audit Trail, जो Shield का हिस्सा है या अलग से खरीदा जा सकता है, हर ऑब्जेक्ट पर 200 फ़ील्ड तक ट्रैक करता है और इतिहास को तब तक रखता है जब तक आप उसे डिलीट न करें, एक आर्काइव में जिस तक आप API से पहुँचते हैं (Field Audit Trail (opens in a new tab))। मेरा पक्ष: स्टैंडर्ड फ़ील्ड हिस्ट्री डिफ़ॉल्ट है; Field Audit Trail तब इस्तेमाल करें जब कोई नियम या कम्प्लायंस दायित्व लंबा, साबित किया जा सकने वाला इतिहास माँगे। इसलिए नहीं कि “ऑडिट सुनने में अच्छा लगता है।”

ऑडिटिंग और मॉनिटरिंग एक जैसे नहीं हैं

फ़ील्ड हिस्ट्री चुने हुए फ़ील्ड में बदलावों के सवालों का जवाब देती है। व्यापक सवाल (किसने लॉग इन किया, किसने डेटा एक्सपोर्ट किया, कौन-से API कॉल हुए, किसने क्या देखा) मॉनिटरिंग हैं, और वह है Event Monitoring। मेरे अनुभव में इसकी ज़रूरत आम तौर पर ज़्यादा विनियमित ग्राहकों के साथ पड़ती है, और इस अध्याय में यह मेरा सबसे मज़बूत पक्ष है: ज़रूरत पड़ने से पहले इसे सेट करें, और इवेंट्स को पहले से ही किसी रिपॉज़िटरी, जैसे Splunk या किसी दूसरे SIEM, में भेजते रहें।

वजह यह है। ऐड-ऑन के बिना इवेंट लॉग फ़ाइलें 1 दिन रखी जाती हैं, और सिर्फ़ कुछ इवेंट टाइप के लिए; Shield या Event Monitoring ऐड-ऑन के साथ डिफ़ॉल्ट रूप से 30 दिन, और रिटेंशन बढ़ाने पर 365 दिन तक (Event Monitoring FAQ (opens in a new tab))। इससे पुराना सब कुछ चला जाता है, जब तक आपने उसे एक्सपोर्ट न किया हो। और पेड लॉग आपके कॉन्ट्रैक्ट शुरू होने से पहले की किसी अवधि के लिए वापस नहीं मिल सकते (वही FAQ): घटना के बाद ऐड-ऑन खरीदने से अतीत वापस नहीं आता। इसलिए एक आर्किटेक्ट की सबसे बुरी बातचीतों में से एक ऐसी होती है: “क्या हम देख सकते हैं कि छह महीने पहले क्या हुआ था?” “नहीं।” “क्यों नहीं?” “हम उसे कैप्चर नहीं कर रहे थे।” ऐसा नहीं होना चाहिए कि कोई समस्या सामने आए और तब पता चले कि आप उन इवेंट्स को कैप्चर और स्टोर ही नहीं कर रहे थे। तब तक जवाब बस गायब हो चुका होता है।

Click to enlarge

ज़रूरत पड़ने से पहले इसे सेट करें।

लेकिन “सब कुछ लॉग करो” की ओर न झुक जाएँ। आप क्या साबित करना चाहते हैं? कौन-से इवेंट मायने रखते हैं, उनकी ज़रूरत किसे है, कितने समय, लॉग कौन पढ़ सकता है, और क्या खुद लॉग में संवेदनशील डेटा हो सकता है? लॉगिंग डेटा बनाती है, और उस डेटा को भी गवर्नेंस चाहिए। और सबूत को एक मालिक चाहिए: रिपॉज़िटरी का मालिक कौन है, अलर्ट की समीक्षा कौन करता है, कौन जाँचता है कि रिटेंशन काम कर रहा है, कौन देखता है कि फ़ीड तीन महीने पहले चुपचाप फ़ेल हो गई थी? बिना मालिक की टेक्नोलॉजी गवर्नेंस नहीं है; हम वापस मॉड्यूल 1 के मालिक, स्टीवर्ड और कस्टोडियन पर आ गए हैं।

कंट्रोल को साबित करें, सिर्फ़ कॉन्फ़िगरेशन को नहीं

“प्राप्तकर्ता का डेटा सिर्फ़ उन क्रू को उपलब्ध है जो उस स्टॉप पर असाइन हैं।” हमें कैसे पता? सिक्योरिटी कॉन्फ़िगरेशन दिखाता है कि क्या होना चाहिए। ऑपरेशनल सबूत (किसने असल में उसे एक्सेस किया, असामान्य एक्सपोर्ट, कोई इंटीग्रेशन जो उसे खींच रहा है, एक्सेस कंट्रोल में बदलाव) दिखाता है कि क्या हुआ। अच्छी गवर्नेंस को अक्सर दोनों चाहिए।

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

Steve Trucking: एक फ़ील्ड पर पूरा जीवनचक्र

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

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

गवर्नेंस कभी पूरी नहीं होती

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

आर्किटेक्ट यहाँ क्या तय करता है

• वर्गीकरण, नीति और असली इस्तेमाल के आधार पर, एन्क्रिप्शन के ट्रेड-ऑफ़ सहित, डेटा की हर श्रेणी को सुरक्षा के कौन-से कंट्रोल मिलते हैं।
• डेटा और उसका इतिहास कितने समय रखा जाता है, घड़ी किससे शुरू होती है, और अंत में क्या होता है।
• कब स्टैंडर्ड फ़ील्ड हिस्ट्री काफ़ी है और कब कोई नियम Field Audit Trail माँगता है।
• कौन-से इवेंट कैप्चर होते हैं, प्लेटफ़ॉर्म के रिटेंशन से आगे सबूत कहाँ स्टोर होता है, और उसका मालिक कौन है।
• आर्किटेक्चर इंसानों, इंटीग्रेशन और एजेंटों की अहम कार्रवाइयों को बाद में कैसे साबित करता है।

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

और जानें

• Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) और Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Field History Tracking Overview (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Field Audit Trail (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।
• Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (अंग्रेज़ी में, 2026-10-14 को जाँचा गया)।