जर्मनी में GDPR होस्टिंग

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

यह गाइड प्रैक्टिकल जानकारी है, कानूनी सलाह नहीं। कानूनी महत्व वाले फ़ैसलों के लिए किसी डेटा प्रोटेक्शन विशेषज्ञ से पूछें।

GDPR आपसे क्या माँगता है

जनरल डेटा प्रोटेक्शन रेगुलेशन (जर्मन में: DSGVO) तब लागू होता है जब आप EU के लोगों का पर्सनल डेटा प्रोसेस करते हैं। सर्वर पर वेबसाइट, ऐप या SaaS चलाने वाले के लिए मुख्य ज़िम्मेदारियाँ ये हैं:

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

आपकी होस्टिंग का चुनाव इनमें से तीन को सीधे प्रभावित करता है: प्रोसेसर, ट्रांसफ़र और सुरक्षा।

सर्वर की लोकेशन क्यों मायने रखती है

डेटा भौतिक रूप से कहाँ रखा है, इससे तय होता है कि कौन-सा कानून उस तक पहुँच सकता है और क्या कोई ट्रांसफ़र होता है।

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

यूरोपियन ऑडियंस के लिए जर्मन सर्वर का मतलब यूरोप के केंद्र से कम लेटेंसी भी है, इसलिए प्राइवेसी और परफ़ॉर्मेंस दोनों के लिहाज़ से चुनाव एक ही दिशा में जाता है।

प्रोसेसर के रूप में आपका प्रोवाइडर

जब कोई होस्टिंग प्रोवाइडर आपकी ओर से पर्सनल डेटा स्टोर या हैंडल करता है, तो वह प्रोसेसर है और आप कंट्रोलर हैं। GDPR का आर्टिकल 28 एक लिखित एग्रीमेंट (DPA, जर्मन में AVV) ज़रूरी बनाता है, जिसमें ये बातें हों:

• केवल आपके निर्देशों पर प्रोसेसिंग;
• स्टाफ़ की गोपनीयता;
• सुरक्षा उपाय;
• सब-प्रोसेसर के नियम;
• डेटा सब्जेक्ट अनुरोधों और ब्रीच में मदद;
• अंत में डेटा का डिलीट या वापसी।

उसके सर्वरों पर पर्सनल डेटा रखने से पहले अपने प्रोवाइडर से उसका DPA और सब-प्रोसेसर की सूची माँगें।

Wolkra इसे कैसे संभालता है

Wolkra आज एक लोकेशन चलाता है: फ़्रैंकफ़र्ट आम माइन, जर्मनी। सर्वर, ब्लॉक स्टोरेज वॉल्यूम, बैकअप और स्नैपशॉट वहीं स्टोर होते हैं, और डेटा जर्मनी और EU में रहता है। प्राइवेसी पॉलिसी उन सर्विसेज़ के नाम बताती है जो अकाउंट डेटा प्रोसेस करती हैं: ईमेल AWS के फ़्रैंकफ़र्ट रीजन से भेजे जाते हैं, कार्ड पेमेंट Stripe से होते हैं, और Cloudflare वेबसाइट और कंसोल की सुरक्षा करता है। सवाल कंसोल में टिकट के ज़रिए भेजें। EU VPS और GDPR पर और पढ़ें।

आपके सर्वर के आसपास की सर्विसेज़

GDPR की समस्याएं अक्सर सर्वर से शुरू नहीं होतीं। आम तौर पर गड़बड़ी अतिरिक्त चीज़ों में होती है:

हर सर्विस की एक आसान सूची बनाएं: उसे कौन-सा पर्सनल डेटा मिलता है, वह कहाँ है, और क्या आपके पास DPA है। यही सूची आपके प्रोसेसिंग गतिविधियों के रिकॉर्ड (आर्टिकल 30) की शुरुआत है।

VPS पर तकनीकी उपाय

"उचित उपाय" जोखिम के साथ बढ़ते हैं। एक सामान्य सर्वर के लिए मज़बूत बेसलाइन यह है:

एक्सेस

• केवल SSH की, कोई पासवर्ड नहीं (SSH की गाइड)।
• होस्टिंग अकाउंट और एडमिन पैनल पर टू-फ़ैक्टर ऑथेंटिकेशन।
• टीम के सदस्यों को केवल उतना ही रोल जितनी ज़रूरत है। Wolkra owner, admin, billing और member रोल वाले ऑर्गनाइज़ेशन, प्रति-प्रोजेक्ट रोल और एक्टिविटी लॉग सपोर्ट करता है (टीमें और सुरक्षा)।

नेटवर्क

• डिफ़ॉल्ट-डिनाई फ़ायरवॉल, जिसमें डेटाबेस और एडमिन टूल्स कभी पब्लिक न हों।
• अपने सर्वरों के बीच ट्रैफ़िक के लिए प्राइवेट नेटवर्क, ताकि डेटाबेस का कोई पब्लिक IP ही न हो।
• हर जगह TLS। Caddy जैसा रिवर्स प्रॉक्सी सर्टिफ़िकेट अपने-आप संभालता है (Caddy गाइड)।

डेटा

• सर्वर से बाहर जाने वाले बैकअप एन्क्रिप्ट करें, उदाहरण के लिए restic या age से।
• ऐप्लिकेशन में खास तौर पर संवेदनशील फ़ील्ड एन्क्रिप्ट करें।
• रिटेंशन तय करें: लॉग और पुराने रिकॉर्ड एक शेड्यूल पर डिलीट करें।

journald के साथ लॉग रिटेंशन का एक आसान उदाहरण:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/retention.conf >/dev/null <<'EOF'
[Journal]
MaxRetentionSec=30day
SystemMaxUse=1G
EOF
sudo systemctl restart systemd-journald

वेब सर्वर लॉग के लिए या तो IP एड्रेस हटा दें या उसे छोटा कर दें। कई टीमें सुरक्षा के लिए कुछ दिनों तक पूरे लॉग रखती हैं और फिर उन्हें एनॉनिमाइज़ कर देती हैं।

पैचिंग और मॉनिटरिंग

• ऑटोमैटिक सिक्योरिटी अपडेट (Ubuntu सर्वर को सुरक्षित करें)।
• रिसोर्स ग्राफ़ में असामान्य उछाल पर नज़र रखें, जो दुरुपयोग का संकेत हो सकते हैं।

रिकवरी

GDPR "पर्सनल डेटा की उपलब्धता और उस तक एक्सेस को समय पर बहाल करने की क्षमता" का ज़िक्र करता है। व्यवहार में इसका मतलब है: ऐसे बैकअप जिन्हें आपने टेस्ट किया है। देखें बैकअप स्ट्रैटेजी गाइड।

डेटा सब्जेक्ट अनुरोधों को संभालना

किसी के पूछने से पहले ही योजना बना लें कि आप कैसे जवाब देंगे:

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

SQL क्वेरी या एडमिन स्टेप्स वाला एक छोटा इंटरनल नोट बाद में बहुत तनाव बचाता है।

ब्रीच

अगर पर्सनल डेटा खो जाए, लीक हो जाए या बिना अनुमति एक्सेस हो:

1. उसे रोकें: की बदलें, कमज़ोरी बंद करें, ज़रूरत हो तो सर्वर ऑफ़लाइन करें।
2. प्रभावित लोगों के लिए जोखिम का आकलन करें।
3. अगर जोखिम है तो 72 घंटे के अंदर अपनी सुपरवाइज़री अथॉरिटी को सूचित करें।
4. अगर जोखिम ज़्यादा है तो प्रभावित लोगों को बताएं।
5. क्या हुआ, उसे डॉक्यूमेंट करें, भले ही आप सूचना न देने का फ़ैसला करें।

सफ़ाई से पहले लिए गए स्नैपशॉट बाद में यह समझने में मदद करते हैं कि क्या हुआ था।

एक प्रैक्टिकल चेकलिस्ट

• सर्वर और बैकअप EU में (उदाहरण के लिए फ़्रैंकफ़र्ट)
• होस्टिंग प्रोवाइडर और दूसरे प्रोसेसर के साथ DPA
• पर्सनल डेटा पाने वाली सभी सर्विसेज़ की सूची
• प्राइवेसी नोटिस अपडेट
• SSH की, 2FA, कम से कम अधिकार वाले रोल
• फ़ायरवॉल डिफ़ॉल्ट डिनाई, डेटाबेस के लिए प्राइवेट नेटवर्क
• हर पब्लिक एंडपॉइंट पर TLS
• लॉग रिटेंशन सेट, ऑफ़साइट बैकअप एन्क्रिप्टेड
• रिस्टोर टेस्ट किया
• एक्सेस, डिलीट और ब्रीच अनुरोधों के लिए योजना

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