बिजनेस डेटा एन्क्रिप्शन: कस्टमर चैट के लिए गाइड

हर WhatsApp ऑर्डर, Instagram DM और Telegram सपोर्ट चैट अपने पीछे ग्राहक का डेटा छोड़ जाती है: फोन नंबर, डिलीवरी के पते, चैट लॉग और वे access token जो आपके चैनलों को जोड़ते हैं। बिजनेस डेटा एन्क्रिप्शन इस सबको ऐसे ciphertext में बदल देता है जिसे key के बिना कोई पढ़ नहीं सकता — तब भी जब डेटा नेटवर्क पर चल रहा हो, और तब भी जब वह डेटाबेस और बैकअप में पड़ा हो।

मुख्य बातें

डेटा एन्क्रिप्शन की दो परतें होती हैं: encryption in transit (TLS) चलते हुए डेटा को बचाता है, और encryption at rest (आमतौर पर AES) स्टोर किए गए डेटा को।
चैनल access token, API key और webhook secret — ये सब credential हैं। लीक हुआ एक token हमलावर को आपके बिजनेस की तरह काम करने दे सकता है, इसलिए इन्हें field level पर एन्क्रिप्ट करें।
डिस्क एन्क्रिप्शन चोरी हुई ड्राइव बचाता है, चलते हुए सर्वर को नहीं। डेटाबेस के बाहर रखी key के साथ field-level एन्क्रिप्शन उन fields को लीक हुए dump में भी सुरक्षित रखता है।
AES-256-GCM authenticated encryption है: यह डेटा छिपाता भी है और छेड़छाड़ पकड़ता भी है, और इसकी शर्त यह है कि एक ही key के साथ nonce कभी दोबारा इस्तेमाल न हो।
एन्क्रिप्शन उसे नहीं रोकता जिसे decrypt करने की इजाजत है। AI ऑटो-रिप्लाई प्लेटफॉर्म को जवाब लिखने के लिए मैसेज पढ़ने ही पड़ते हैं, इसलिए access control और retention उतने ही मायने रखते हैं जितने cipher।

चैट-फर्स्ट कंपनी में बिजनेस डेटा एन्क्रिप्शन में क्या-क्या आना चाहिए

जो कंपनी चैट पर बेचती है — मसलन WhatsApp AI इनबॉक्स के जरिए — उसकी अपनी डेटा इन्वेंट्री होती है:

Credential और secret. Facebook Page और WhatsApp Business के access token, Telegram bot token, AI provider की key, पेमेंट provider की key और webhook secret।
ग्राहक की PII. फोन नंबर, ईमेल पते, डिलीवरी के पते और customer ID। चैट कॉमर्स में फोन नंबर ही अक्सर ग्राहक की पहचान होता है।
चैट लॉग और मीडिया. ट्रांसक्रिप्ट, वॉइस नोट, फोटो और वे इनवॉइस जो ग्राहक भेजते हैं।
स्टाफ के पासवर्ड. इन्हें एन्क्रिप्ट नहीं, hash किया जाना चाहिए (आगे इस पर और बात है)।
स्टाफ के डिवाइस. वे लैपटॉप और फोन जिन पर इनबॉक्स खुलता है या एक्सपोर्ट रखे रहते हैं। FileVault या BitLocker, डिवाइस passcode और remote wipe चालू रखें।
कॉपियां. बैकअप, CSV एक्सपोर्ट, लॉग और staging डेटाबेस — ये अक्सर प्रोडक्शन से कम सुरक्षित होते हैं।

ग्राहक डेटा एन्क्रिप्शन का एक सीधा नियम: जो चीज या तो एक्सेस देती है या किसी व्यक्ति की पहचान बताती है, उसे field level पर सुरक्षित करें, और हर कॉपी को वही सुरक्षा दें जो असली डेटा को दी है।

एट रेस्ट बनाम इन ट्रांजिट एन्क्रिप्शन

Encryption in transit डेटा को तब बचाता है जब वह ब्राउज़र, आपके सर्वर और थर्ड-पार्टी API के बीच चल रहा होता है। Encryption at rest उस डेटा को बचाता है जो डिस्क, डेटाबेस और बैकअप में स्टोर है।

पहलू	Encryption in transit	Encryption at rest
किससे बचाता है	ताक-झांक, छेड़छाड़, नकली सर्वर	चोरी हुई डिस्क, लीक हुए dump, खुले पड़े बैकअप
सामान्य स्टैंडर्ड	TLS 1.2 या TLS 1.3	AES-256, अक्सर AES-256-GCM
कहां लागू होता है	ब्राउज़र से ऐप तक, webhook, API कॉल	डिस्क, डेटाबेस, अलग-अलग fields, बैकअप
क्या कवर नहीं करता	पहुंचने और decrypt होने के बाद का डेटा	चलते हुए ऐप्लिकेशन में इस्तेमाल हो रहा डेटा

NIST SP 800-52 Rev. 2 के मुताबिक अमेरिकी सरकारी TLS सर्वरों को TLS 1.2 सपोर्ट करना जरूरी है, और जनवरी 2024 तक TLS 1.3 भी। किसी भी बिजनेस के लिए यही समझदारी वाला baseline है: TLS 1.2 और 1.3 स्वीकार करें, और उससे पुराना सब बंद कर दें।

TLS सिर्फ रास्ते की हिफाजत करता है। WhatsApp Cloud API webhook को HTTPS पर भेजता है, और Meta के डॉक्यूमेंटेशन में लिखा है कि Cloud API आने वाले मैसेज decrypt करता है और उन्हें बिजनेस तक पहुंचाता है, और मैसेज ज्यादा से ज्यादा 30 दिन रखता है। उसके बाद जिम्मेदारी स्टोरेज और access control की हो जाती है।

डिस्क, डेटाबेस और field-level एन्क्रिप्शन

Encryption at rest परतों में आता है:

डिस्क या वॉल्यूम एन्क्रिप्शन चोरी हुई या फेंकी गई ड्राइव को बचाता है। सर्वर चलते समय ऑपरेटिंग सिस्टम डेटा अपने आप decrypt करता रहता है, इसलिए सर्वर के भीतर पहुंचे हमलावर को सादा डेटा दिखता है।
डेटाबेस फाइल एन्क्रिप्शन की सीमा भी वही है: जो डेटाबेस पर query चला सकता है, उसे plaintext ही मिलता है।
Field-level एन्क्रिप्शन खास कॉलम — जैसे कोई token या फोन नंबर — को ऐप्लिकेशन के भीतर, डेटाबेस तक पहुंचने से पहले एन्क्रिप्ट करता है। Key कहीं और रहती है, इसलिए लीक हुए dump या कॉपी किए गए बैकअप में उन fields की जगह ciphertext दिखता है।

इसकी कीमत search में चुकानी पड़ती है: एन्क्रिप्टेड कॉलम पर आप सामान्य SQL filter नहीं चला सकते। व्यावहारिक तरीका यह है कि field-level एन्क्रिप्शन को secrets और ज्यादा जोखिम वाली संपर्क जानकारी तक सीमित रखें। जिन टीमों को फोन या ईमेल से ग्राहक ढूंढ़ने ही होते हैं, वे ciphertext के साथ एक keyed hash (blind index) रख सकती हैं और search उसी पर कर सकती हैं।

AES-256-GCM: key size और mode

AES की परिभाषा FIPS 197 में है, 128-, 192- और 256-bit key के साथ। AES-256 इन तीनों में सबसे बड़ी key इस्तेमाल करता है।

Mode उतना ही मायने रखता है जितनी key size। GCM (NIST SP 800-38D) authenticated encryption है: यह डेटा को गोपनीय रखता है और यह भी पकड़ता है कि किसी ने ciphertext बदला तो नहीं। एक ही key के साथ nonce कभी दोबारा इस्तेमाल न करें: nonce दोहराते ही GCM की गारंटी टूट जाती है, इसलिए nonce बनाने का काम किसी मेंटेन की जा रही लाइब्रेरी पर छोड़ें, और अपनी खुद की क्रिप्टोग्राफी कभी न लिखें।

API key और access token सुरक्षित तरीके से कैसे स्टोर करें

चुनाव इस पर करें कि आपको असली value वापस चाहिए या नहीं:

Encrypt करें उन secrets को जो आपको किसी और को भेजने होते हैं: WhatsApp और Instagram के access token, Telegram bot token, AI provider की key और पेमेंट key। field-level AES-GCM इस्तेमाल करें, और key डेटाबेस के बाहर रखें।
Hash करें उन secrets को जिन्हें आप सिर्फ verify करते हैं: पासवर्ड, पार्टनर API key और one-time code। Hash को वापस असली value में नहीं बदला जा सकता, लेकिन छोटी या आसानी से अंदाजा लगने वाली values brute-force हो सकती हैं, इसलिए पासवर्ड के लिए Argon2id या bcrypt जैसा धीमा hash और कोड के लिए keyed HMAC इस्तेमाल करें।
इन्हें लॉग से बाहर रखें — एरर मैसेज, analytics और URL से भी।
Scope तय करें और rotate करें। token को सिर्फ उतनी permissions दें जितनी उसे चाहिए, और जब एक्सेस रखने वाला कोई व्यक्ति कंपनी छोड़े तो token बदल दें।

Encryption at rest उस token को नहीं बचाता जो API कॉल के दौरान मेमोरी में decrypt होकर पड़ा है। सर्वर hardening और least privilege इस जोखिम को घटाते हैं।

एन्क्रिप्शन key management की बुनियादी बातें

एन्क्रिप्शन उतना ही मजबूत है जितनी वह जगह जहां key रखी है। सबसे पुरानी गलती यही है — key को डेटा के ठीक बगल में, उसी डेटाबेस में या commit की गई config फाइल में रख देना।

Key को डेटा से अलग रखें। Key किसी secrets manager, KMS या ऐसे सर्वर कॉन्फिगरेशन में रखें जहां डेटाबेस की पहुंच न हो।
बड़े पैमाने पर envelope encryption इस्तेमाल करें। एक master key data keys को एन्क्रिप्ट करती है, इसलिए उसे rotate करने पर सब कुछ दोबारा एन्क्रिप्ट नहीं करना पड़ता।
हर काम के लिए अलग key निकालें — HKDF जैसे key derivation function से।
Rotation और recovery की योजना बनाएं। Key खोई तो डेटा गया, बैकअप वाला भी।

एक्सेस कंट्रोल और least privilege: एन्क्रिप्शन काफी नहीं है

एन्क्रिप्शन उन्हें रोकता है जिनके पास key नहीं है, उन लोगों या सिस्टम को नहीं जिन्हें decrypt करने की इजाजत है। AI ऑटो-रिप्लाई प्लेटफॉर्म को जवाब लिखने के लिए ग्राहक का मैसेज पढ़ना ही होता है, इसलिए उसके सर्वर पढ़े जा सकने वाले मैसेज प्रोसेस करते हैं।

यही तर्क ऊपर की तरफ भी लागू होता है। WhatsApp का सिक्योरिटी व्हाइटपेपर Cloud API इस्तेमाल करने वाले बिजनेस के साथ हुई चैट को एंड-टू-एंड एन्क्रिप्टेड नहीं मानता, क्योंकि मैसेज सीधे बिजनेस के नियंत्रण वाले endpoint तक नहीं पहुंचते। सेटअप चुनने से पहले WhatsApp Business Cloud API बनाम Business App पढ़ लें।

तो अगली परत यह तय करती है कि डेटा तक कौन पहुंच सकता है:

Least privilege access control: हर साथी को सबसे छोटी वह भूमिका दें जिससे काम चल जाए। चैट का जवाब देने वाले एजेंट को बिलिंग की जरूरत नहीं है।
मजबूत sign-in: एक दूसरा verification स्टेप जोड़ें और logout पर session खत्म करें।
Tenant isolation: हर request को यह साबित करना चाहिए कि उसे भेजने वाला उसी बिजनेस का है।
Audit log और retention: विशेषाधिकार वाले कामों का रिकॉर्ड रखें, और चैट लॉग उतने ही समय तक रखें जितनी जरूरत है।

बैकअप, एक्सपोर्ट और retention

बैकअप ग्राहक डेटा की पूरी कॉपियां हैं, जो अक्सर प्रोडक्शन से ज्यादा समय तक रखी जाती हैं और उन पर नजर भी कम रहती है। बैकअप फाइलें एन्क्रिप्ट करें, डाउनलोड करने वालों की सूची सीमित रखें, restore की टेस्टिंग करें — key recovery समेत — और ईमेल या चैट पर शेयर किए गए पुराने CSV एक्सपोर्ट मिटा दें।

एन्क्रिप्शन का कानूनी वजन भी है। GDPR का Article 32 एन्क्रिप्शन को एक सुरक्षा उपाय के तौर पर गिनाता है, और Article 34(3)(a) controller को यह छूट देता है कि अगर एन्क्रिप्शन के कारण डेटा अनधिकृत लोगों के लिए पढ़ने लायक ही नहीं बचा, तो प्रभावित लोगों को ब्रीच की सूचना देना जरूरी नहीं। Article 33 के तहत ब्रीच का पता चलने के 72 घंटे के भीतर रेगुलेटर (supervisory authority) को सूचना देने की जिम्मेदारी इससे अलग है। सऊदी अरब का PDPL और तुर्की का KVKK भी रेगुलेटर के लिए 72 घंटे की समयसीमा तय करते हैं।

यह सामान्य जानकारी है, कानूनी सलाह नहीं। GDPR या कोई दूसरा कानून आप पर लागू होता है या नहीं, और किसी खास ब्रीच पर कोई छूट लागू होती है या नहीं — यह आपकी स्थिति पर निर्भर करता है, इसलिए किसी योग्य वकील से सलाह लें।

किसी भी चैट या CRM वेंडर से पूछने लायक सवाल

अपने चैनल जोड़ने से पहले चैटबॉट वेंडर से सुरक्षा के ये सवाल एक लिखित प्रश्नावली की तरह पूछें:

आपके endpoints कौन-कौन से TLS वर्जन स्वीकार करते हैं?
कौन-सा डेटा at rest एन्क्रिप्टेड है, और किस परत पर? क्या उसमें मैसेज का कंटेंट भी शामिल है?
क्या चैनल token और API key field level पर एन्क्रिप्टेड हैं, और key कहां रखी जाती है?
क्या बैकअप एन्क्रिप्टेड हैं, और उन तक किसकी पहुंच है?
क्या आपका स्टाफ हमारी बातचीत पढ़ सकता है, और क्या उस एक्सेस का लॉग बनता है?
अपनी टीम के लिए हम कौन-कौन सी roles और permissions सेट कर सकते हैं?
हमारा डेटा दूसरे ग्राहकों के डेटा से कैसे अलग रखा जाता है?
क्या हमारी चैट का इस्तेमाल AI मॉडल ट्रेन करने में होता है — आपके द्वारा या आपके AI providers द्वारा?
आपके sub-processors कौन हैं, और डेटा कहां स्टोर होता है?
क्या आप DPA साइन करेंगे, और हमारे जाने के बाद डेटा कितनी जल्दी डिलीट होता है?

"मिलिट्री-ग्रेड एन्क्रिप्शन" या "सारा डेटा पूरी तरह एन्क्रिप्टेड" जैसे जवाबों पर शक करें। भरोसेमंद वेंडर algorithm का नाम बताता है, परत बताता है और कमियां भी बताता है।

Raabt आज क्या एन्क्रिप्ट और सुरक्षित करता है

नीचे की हर बात सितंबर 2026 तक के Raabt के कोड के मुताबिक है।

Field-level एन्क्रिप्शन: संवेदनशील fields ऐप्लिकेशन स्तर पर AES-256-GCM से एन्क्रिप्ट होती हैं। नई writes उस key से होती हैं जो HKDF-SHA256 से निकाली गई है, और पुरानी values अगली बार सेव होने पर उसी key से दोबारा एन्क्रिप्ट हो जाती हैं। कम से कम 32 अक्षर की key के बिना ऐप चालू ही नहीं होता।
क्या एन्क्रिप्ट होता है: credentials और token (Facebook, Instagram, WhatsApp और Telegram के चैनल access token, AI और पेमेंट provider की API key, webhook secret) और चुनी हुई संपर्क जानकारी (ग्राहकों के फोन नंबर, ईमेल और ऑर्डर के पते)।
Hashing: पासवर्ड Argon2id (19 MiB मेमोरी, 2 iterations) से hash होते हैं, और पुराने bcrypt hash लॉगिन के समय अपग्रेड हो जाते हैं। पार्टनर API key के secrets सिर्फ SHA-256 hash के रूप में रखे जाते हैं।
Sign-in: ईमेल और पासवर्ड से लॉगिन पर session बनने से पहले यूजर के ईमेल पर भेजा गया one-time code जरूरी है (Google sign-in में यह कोड नहीं लगता)। कोड सिर्फ HMAC-SHA256 hash के रूप में रखे जाते हैं, उनकी मियाद खत्म हो जाती है और वे एक ही बार चलते हैं।
टीम एक्सेस: चार roles (owner, admin, agent, viewer), हर सेक्शन के लिए अलग permissions। बिलिंग का एक्सेस owner के अलावा किसी को नहीं सौंपा जा सकता।
Isolation: बिजनेस endpoints पहले यह पक्का करते हैं कि request भेजने वाला उस बिजनेस का सक्रिय सदस्य है, वरना "not found" लौटाते हैं।
Webhook और मीडिया: Meta के webhook बिना वैध X-Hub-Signature-256 signature के खारिज कर दिए जाते हैं, Telegram के webhook के लिए secret token जरूरी है, और अटैचमेंट सिर्फ signed, expiring URL से ही दिए जाते हैं।
इन्फ्रास्ट्रक्चर: ऐप्लिकेशन सीधे इंटरनेट पर खुला नहीं है; सार्वजनिक ट्रैफिक उस तक Cloudflare Tunnel से पहुंचता है। डेटाबेस के एरर लॉग में query parameters कभी नहीं जाते, इसलिए फोन नंबर और ईमेल उन लॉग से बाहर रहते हैं।
प्लेटफॉर्म एडमिन audit log: प्लेटफॉर्म एडमिन के काम एक append-only audit log में लिखे जाते हैं (कौन, क्या, कब, IP, साथ में पहले/बाद के snapshot और redact किए गए secrets)। यह ग्राहकों के मैसेज का लॉग नहीं है।

यहां एन्क्रिप्शन क्या नहीं कर सकता: AI इनबॉक्स को जवाब लिखने के लिए मैसेज का टेक्स्ट पढ़ना ही पड़ता है, इसलिए बातचीत का कंटेंट सर्वर पर पढ़े जाने लायक रूप में प्रोसेस होता है। ठीक इसीलिए ऊपर बताए गए access control, retention और बैकअप वाले बिंदु उतना ही वजन रखते हैं जितना आपका चुना हुआ cipher।

Meta की डेटा डिलीशन रिक्वेस्ट पर एक confirmation code मिलता है, और स्टेटस लिंक हमारे डेटा डिलीशन पेज पर रहता है। अकाउंट डिलीट करने के लिए आपका पासवर्ड और ईमेल पर भेजा गया one-time code दोनों चाहिए, और फिर अकाउंट निष्क्रिय कर दिया जाता है और उसका ईमेल anonymize कर दिया जाता है।

बिजनेस डेटा एन्क्रिप्शन चेकलिस्ट: छोटी टीमों के लिए रोलआउट क्रम

छोटे बिजनेस में डेटा एन्क्रिप्शन एक तय क्रम में सबसे अच्छा चलता है — शुरुआत उससे करें जिसके लीक होने पर सबसे ज्यादा नुकसान होता है:

सब कुछ HTTPS पर दें, सिर्फ TLS 1.2 या 1.3 के साथ।
हर उस डिवाइस पर full-disk encryption और screen lock चालू करें जिस पर ग्राहकों की चैट खुलती है।
Token और API key को अलग keys वाले field-level एन्क्रिप्शन में ले जाएं।
पासवर्ड Argon2id या bcrypt से hash करें और sign-in में दूसरा स्टेप जोड़ें।
ग्राहकों के फोन नंबर, ईमेल और पते एन्क्रिप्ट करें।
बैकअप एन्क्रिप्ट करें, least-privilege roles तय करें और चैट का retention पीरियड सेट करें।
वेंडर वाले सवाल अपने हर चैट, CRM और AI टूल को भेजें।

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

बिजनेस का कौन-सा डेटा एन्क्रिप्ट करना चाहिए?

शुरुआत उससे करें जो या तो एक्सेस देता है या किसी व्यक्ति की पहचान बताता है: चैनल token, API key, webhook secret, और ग्राहकों के फोन नंबर, ईमेल और पते। इसके बाद चैट लॉग, स्टाफ के डिवाइस और हर बैकअप या एक्सपोर्ट को कवर करें।

Encryption at rest और in transit में क्या अंतर है?

Encryption in transit, यानी आमतौर पर TLS, उस डेटा को बचाता है जो डिवाइस, सर्वर और API के बीच चल रहा है। Encryption at rest, यानी आमतौर पर AES, स्टोर किए गए डेटा को बचाता है।

क्या AES-256 एन्क्रिप्शन ग्राहक डेटा बचाने के लिए काफी है?

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

API key और access token सुरक्षित तरीके से कैसे स्टोर करें?

जिन token को दोबारा इस्तेमाल करना है उन्हें field-level AES-GCM से एन्क्रिप्ट करें और key डेटाबेस के बाहर रखें। जिन secrets को सिर्फ verify करना है — जैसे पासवर्ड और पार्टनर API key — उन्हें hash करें।

अगर मैं HTTPS इस्तेमाल करता हूं, तो क्या सर्वर पर मेरा डेटा सुरक्षित है?

नहीं। HTTPS सिर्फ in transit डेटा को बचाता है। सर्वर पर सुरक्षा at-rest एन्क्रिप्शन, access control और बैकअप संभालने के तरीके पर निर्भर करती है।

चैटबॉट या CRM कंपनी से डेटा सुरक्षा के बारे में क्या पूछें?

पूछें कि वे कौन-से TLS वर्जन स्वीकार करते हैं, at rest क्या और किस परत पर एन्क्रिप्टेड है, keys कहां रखी जाती हैं, स्टाफ की चैट तक पहुंच का लॉग बनता है या नहीं, उनके sub-processors कौन हैं और डेटा कहां स्टोर होता है, क्या चैट से AI मॉडल ट्रेन होते हैं, और क्या वे डिलीशन की समयसीमा के साथ DPA साइन करेंगे।

ऐसे AI इनबॉक्स पर अपनी चैट चलाने के लिए तैयार हैं जो चैनल token और चुनी हुई ग्राहक संपर्क जानकारी एन्क्रिप्ट करता है? मुफ्त शुरू करें।