PHP अनुप्रयोग

Question

के लिए डेटाबेस लॉगिन प्रमाण-पत्र संग्रहीत करने के लिए हमारे पास एक विकास सर्वर और विभिन्न डेटाबेस कनेक्शन विवरण (उपयोगकर्ता नाम, पासवर्ड, आदि) के साथ एक लाइव सर्वर है।

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

क्या यह एक सुरक्षित दृष्टिकोण है? डीबी कनेक्शन सुरक्षा के प्रबंधन के लिए बेहतर/वैकल्पिक दृष्टिकोण क्या हैं? इस के

एक परिणाम यह है कि हर डेवलपर डेटाबेस कनेक्शन विवरण देख सकते हैं और कहा कि थोड़ा जोखिम भरा है ...

Answer 1

मैं एक .ini फ़ाइल है, जो तब parse_ini_file(INI_FILENAME_HERE, true) के माध्यम से पार्स किया गया है का उपयोग करें। यह फ़ाइल संस्करण नियंत्रण के अंतर्गत नहीं है (जैसा कि php-/template-/जो भी फ़ाइलें हैं)। तो प्रत्येक मशीन पर मैं संबंधित डेटाबेस कनेक्शन के लिए उस फ़ाइल (.database.ini) बनाता हूं।

उदाहरण एक MySQL-कनेक्शन के लिए .ini फ़ाइल का उपयोग करते हुए पीडीओ:

[db_general] 
driver = "mysql" 
user = "USERNAME" 
password = "PASSWORD" 

; DSN 
; see http://www.php.net/manual/en/pdo.drivers.php 
[db_data_source_name] 
host = "localhost" 
port = 3306 
dbname = "DATABASE_NAME" 

; specify PDO-options, provide keys without PDO:: 
; see http://www.php.net/manual/en/pdo.drivers.php 
[db_pdo_options] 
MYSQL_ATTR_INIT_COMMAND = "SET NAMES utf8" 

; specify more PDO-attributes, provide keys without PDO:: 
; see http://php.net/manual/en/pdo.setattribute.php 
[db_pdo_attributes] 
ATTR_CASE = "PDO::CASE_LOWER" 
ATTR_ERRMODE = "PDO::ERRMODE_EXCEPTION" 
ATTR_EMULATE_PREPARES = false 

के बाद से एक .ini-फ़ाइल-कुंजी भीतर :: उपयोग नहीं कर सकते, अपने कोड में constant('PDO::' . $iniKey) का उपयोग वांछित पीडीओ पाने के लिए -constants।

Answer 2

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

Answer 3

क्या यह एक सुरक्षित दृष्टिकोण है?

यह आपकी सुरक्षित परिभाषा पर निर्भर करता है।

हर डेवलपर डेटाबेस कनेक्शन विवरण देख सकते हैं

AFAIK, php.ini फ़ाइल में डिफ़ॉल्ट उपयोगकर्ता नाम/पासवर्ड/डेटाबेस का उपयोग कर के अलावा अन्य, यह समस्या काफी अपरिहार्य है (और चूक का उपयोग कर इसका मतलब है कि वे स्वचालित रूप से डेटाबेस तक पहुंच प्राप्त कर चुके हैं)।

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

Answer 4

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

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

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

सुंदर सुरक्षित - सिद्धांत रूप में, वैसे भी ...

Answer 5

एक और दृष्टिकोण सेटअप वातावरण चर को लाइव और विकास मशीन पर हो सकता है और कोड से उन तक पहुंच जाएगा ... मैं बहुत php पता नहीं है, लेकिन पाइथन में यह होगा:

import os 
password = os.environ('DB_PASS') 

इससे आपको डेवलपर्स और तैनात सर्वरों के लिए आवश्यक खातों और पासवर्ड वितरित करने देता है। उस मशीन पर उनकी अनुमतियों के आधार पर, डेवलपर्स को लाइव पासवर्ड तक पहुंचने से रोका जा सकता है।