2009-02-27 8 views
43

उत्तरों का सारांश:
ऐसा न करें। कानूनी और वित्तीय प्रभाव विनाशकारी होगा। स्थापित तीसरे पक्ष के समाधान की तलाश करें या एक विशेषज्ञ को किराए पर लें। साझा सर्वर पर किसी भी संवेदनशील जानकारी को कभी भी स्टोर न करें। सबसे उपयुक्त एन्क्रिप्शन तंत्र के लिए अनुसंधान।
डेटाबेस में बैंक जानकारी को संग्रहीत करने के लिए सर्वोत्तम अभ्यास

मैं ऐसे ग्राहक के लिए एक वेबसाइट खरीद रहा हूं जिसे प्रत्यक्ष जमा के लिए डीबी में अपने ग्राहकों की बैंक जानकारी (रूटिंग + खाता संख्या) स्टोर करने की आवश्यकता है। यहां कुछ विनिर्देश दिए गए हैं:

1) वेबसाइट प्रारंभ में साझा होस्टिंग सर्वर पर होगी (यह मेरी पहली चिंता है)।
2) मैं PHP/MySQL का उपयोग कर रहा हूं।
3) मैं mcrypt का उपयोग करने की योजना बना रहा हूं।
4) कुंजी वेब रूट के बाहर स्थित होगी।

कृपया मुझे अपने विचार बताएं। यदि संभव हो, तो कृपया मुझे एसीएच प्रसंस्करण पर कुछ संसाधन प्रदान करें।

धन्यवाद!

संपादित करें: मुझे ऐसी प्रतिक्रिया की उम्मीद है क्योंकि मैं वहां सुरक्षा मुद्दों से डरता हूं। मैंने अपने ग्राहक को अपनी चिंता व्यक्त की है और यह एक अच्छा समर्थन होगा।

संपादित 2: इससे दूर चलेगा। पहली जगह में विचार से खुश नहीं था! पेपैल के मास भुगतान API की जांच करेगा।

+0

ईमानदारी से हालांकि, कुछ चीजें हैं जिन्हें आपको दूर जाना चाहिए और यह उनमें से एक है। मुझे नहीं पता कि आप व्यक्तिगत बैंकिंग जानकारी को स्टोर करने के लिए किसी साझा वेब होस्ट पर कभी भी पर्याप्त सुरक्षा प्रदान कर सकते हैं। –

+0

देयता के साथ भी एक बड़ी चिंता है। यदि डेटा समझौता किया गया है और आप सिस्टम बनाने वाले थे, तो एक मौका है कि यह आपके पास वापस आ सकता है। मैं इस सामान के बारे में एक वकील से बात करूंगा। – Paulo

+1

मैं देख रहा हूं ... एक भविष्य की शीर्षक ... 1000 उपभोक्ताओं के बारे में कुछ बैंकिंग जानकारी खो गई ... –

उत्तर

56

मुझे लगता है कि आप Paypal's Mass Payment API जैसे कुछ का उपयोग करके किसी भी बैंक की जानकारी को संग्रहीत किए बिना इस समस्या को हल कर सकते हैं। इस तरह, आपका ग्राहक लोगों का भुगतान कर सकता है, और पेपैल सभी जानकारी संग्रहीत करता है ताकि आपको यह नहीं करना पड़े।

आप चरणों तुम भी अपने ग्राहक की संवेदनशील वित्तीय डेटा को सुरक्षित करने के दूरदराज के एक possiblity है करने के लिए लेने की जरूरत के सभी के बारे में पढ़ने के लिए चाहते हैं, गूगल 'PCI Compliance'

आप वित्तीय भंडारण की मृत्यु डर नहीं कर रहे हैं ऑनलाइन डेटा, आप बहुत बेवकूफ़ हैं।

+9

ओह, मैं कैसे चाहता हूं कि मैं इसे एक से अधिक बार बढ़ा सकता हूं: 'यदि आप वित्तीय डेटा ऑनलाइन स्टोर करने से डरते नहीं हैं, तो आप बहुत ही बेवकूफ हैं।' –

+11

ओपी के लिए उचित होने के लिए - वह मूर्ख नहीं था।वह इस सवाल के स्वर से पूछ रहा था कि वह वास्तव में ऐसा लगता है कि वह वास्तव में इसमें नहीं था। – Tim

+3

टिम के साथ सहमत हैं। ऐसा लगता है जैसे ओपी जानता था कि यह एक बुरा विचार था, ऐसा करने के लिए एक जोखिम भरा बात है। – Ross

13

1) वेबसाइट प्रारंभ में साझा होस्टिंग सर्वर पर होगी (यह मेरी पहली चिंता है)। - वास्तव में बीएडी। सर्वर पर पूर्ण प्रशासनिक नियंत्रण नहीं है, और अन्य लोगों को बाहर रखने में सक्षम होना वास्तव में एक बड़ी समस्या है।

मैं वास्तव में चिंतित हूं कि आप सीधे अंत वेब सर्वर से डेटाबेस तक पहुंच रहे हैं। यह वित्तीय डेटा के साथ एक बड़ा नंबर नहीं है।

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

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

+2

एएमएनएन !! और इसलिए मेरे पास दस पात्र हैं: फिर से एमेन !! –

+1

+1, बहुत अच्छी तरह से कहा। – lpfavreau

+0

तो फिर उपयोगकर्ता बैंकिंग विवरण कैसे संग्रहीत करता है? मैं कहूंगा कि आज की दुनिया में यह काफी आम आवश्यकता है। ओपी को बताते हुए कि उसे उबर सुरक्षा विशेषज्ञ होने की जरूरत है, वह बहुत उपयोगी नहीं है। ज्यादातर लोग निश्चित रूप से नहीं हैं। तो आपका मानक डेवलपर इस तरह के विवरण संग्रहीत करने के बारे में कैसे होगा? – Zapnologica

12

ऐसा मत करो।

बु, अगर आपको सार्वजनिक/निजी कुंजी क्रिप्टो का उपयोग करना है। डेटाबेस में जा रहे डेटा को एन्क्रिप्ट करने के लिए केवल सार्वजनिक कुंजी को स्टोर करें और उपयोग करें। निजी कुंजी को एक सुरक्षित स्थान पर संग्रहीत करें (अर्थ: होस्टेड सर्वर नहीं, बल्कि उपयुक्त पहुंच नियंत्रण वाले "सुरक्षित" स्थानीय मशीन)। जब आवश्यक हो, स्थानीय मशीन पर डेटा डाउनलोड करें, इसे डिक्रिप्ट करने के लिए निजी कुंजी का उपयोग करें, और दूर जाएं।

लेकिन गंभीरता से, यदि आप संभवतः ऐसा कर सकते हैं तो ऐसा करने से बचने का एक तरीका खोजें।

3

बैंकिंग जानकारी के लिए, आपका सर्वर उनके नियंत्रण में नहीं होना चाहिए साझा किया जाना चाहिए।

इसके अलावा, mcrypt बहुत सुरक्षित नहीं है। मुझे पता है कि यह बनाया गया है लेकिन मैं ऐसा कुछ सुझाव दूंगा जो आरएसए जैसे इतने हैकबल नहीं है। अगर किसी को जानकारी प्राप्त हो जाती है, तो उसे निजी कुंजी के बिना इसे हैक करने में सक्षम नहीं होना चाहिए।

4

जारी रखने से पहले अपनी संभावित देनदारियों के बारे में एक वकील से बात करें। किसी साझा-होस्टिंग सर्वर पर संग्रहीत व्यक्तिगत बैंकिंग डेटा होने पर इसके बारे में सब कुछ लिखा गया है। आपके पास इस पर कोई नियंत्रण नहीं है कि आखिरकार डेटा पर कौन अपना हाथ ले सकता है।

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

2

मैं दूसरों से सहमत हूं - यह एक बहुत बुरा विचार है।

समर्पित सर्वर $ 79- $ 99 के बीच एक महीने के बीच हो सकते हैं, अगर यह सस्ती नहीं है, तो मुझे सच में आश्चर्य होगा कि वे बैंक जानकारी को किस प्रकार शुरू कर रहे हैं। इस उदाहरण में वेब बॉक्स से डाटाबेस अलग होने का पसंदीदा तरीका भी होगा। अधिमानतः कुछ फ़ायरवॉल और उनके बीच अन्य सुरक्षा (यानी, 2 फ़ायरवॉल, वेब सर्वर के सामने एक और वेब सर्वर और डेटाबेस के बीच एक) के साथ।

लेकिन साझा होस्टिंग का उपयोग करने से कुछ भी बेहतर होगा। मेरा मतलब है, आप SQL सर्वर से सीधे कनेक्ट कर सकते हैं और सभी उपलब्ध डेटाबेस देख सकते हैं - न्यूनतम हैकिंग के साथ सही कूदना कितना आसान होगा?

इसके अलावा, कृपया मुझे साइट का नाम बताएं ताकि मैं कभी साइन अप न करूं और अपनी बैंकिंग जानकारी डालूं !!! :)

इसके अलावा, सुनिश्चित करें कि साझा होस्टिंग के साथ आगे बढ़ने से पहले आपको त्रुटियां और ओमिशन बीमा है।

1

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

0

मुझे लगता है कि यहाँ हर कोई पर्याप्त स्थिति के अपने अरुचि की घोषणा की है, तो मैं बस जब क्रिप्टो के किसी भी प्रकार कर एक और समस्या पर एक संकेत छोड़ देंगे (जो हम सहमत होंगे आवश्यक है):

डेटा के लिए है कहीं एन्क्रिप्टेड हो!

यदि आप इसे सर्वर पर करते हैं, तो एक समझौता सर्वर केवल आपके एन्क्रिप्शन को ही करेगा और उन्हें एन्क्रिप्ट करने पर w/o को पास करेगा।

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

अंत में: अगर तुम सच में एक सर्वर है कि 110% सुरक्षित नहीं हो सकता है, की पैदल दूरी पर पर ऐसा करने पर विचार करें।

2

मुझे आपके जैसी ही स्थिति का सामना करना पड़ रहा था, और इसे इस तरह हल किया गया।

  1. चूंकि आप एसीएच प्रसंस्करण नहीं कर रहे हैं, तो पता लगाएं कि एसीएच प्रोसेसिंग एपीआई में ग्राहक बनाने की क्षमता है या नहीं।
  2. यदि हां, तो यह ग्राहक ऑब्जेक्ट, आमतौर पर खाता संख्या, रूटिंग नंबर इत्यादि शामिल करेगा, और आपके डेटाबेस में टोकन स्टोर करेगा। (इसलिए जब उपयोगकर्ता अपनी जानकारी देता है, तो आप इसे सीधे अपने एसीएच प्रोसेसर पर HTTPS पर पास करते हैं, और टोकन को सहेजते हैं)।
  3. जब भी आपको अपना खाता डेबिट करना होगा, प्रोसेसर को यह टोकन पास करें, और यह है !!

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

मैंने स्ट्रिप का उपयोग करके क्रेडिट कार्ड के लिए समान किया है।

शुभकामनाएं!

संबंधित मुद्दे