डेटा मॉडलिंग में सुरक्षा दृष्टिकोण। भाग 3

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

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

डेटा मॉडल अंतराल को समाप्त करना

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

क्लब में डेटा संबंध बनाना

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

• Person
• Photo

इसके अलावा, हमारे पास चार डेटा थे जो मामूली रूप से संवेदनशील थे:

• Member
• Club
• Office
• Club_Office

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

तस्वीरों में जुड़े रिश्ते

Photo इसमें बहुत से अंतर्निहित संबंध शामिल हैं जिन्हें हमें पकड़ने की आवश्यकता है। मुख्य रूप से, हम Person . व्यक्ति-फ़ोटो संबंध को कैप्चर करने के लिए, मैं Photo_Content तालिका:

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

ठीक है, तो यह एक चारा और स्विच है। मैंने कहा Photo_Content लोगों . से संबंधित होगा तस्वीरों के लिए, तो "वस्तु चित्रित" के बारे में कुछ क्यों है? तार्किक रूप से, ऐसी तस्वीरें होंगी जहां हम व्यक्ति . की पहचान किए बिना सामग्री का वर्णन करेंगे . क्या मुझे इसके लिए एक और तालिका जोड़नी चाहिए, सामग्री भूमिकाओं के एक अलग सेट के साथ? मैंने फैसला किया नहीं। इसके बजाय, मैं Person तालिका बीज डेटा के रूप में, और गैर-व्यक्ति सामग्री उस व्यक्ति को संदर्भित करती है। (हां, प्रोग्रामर, यह थोड़ा और काम है। आपका स्वागत है।) 'नल पर्सन' के पास id होगा शून्य (0)।

मुख्य शिक्षा क्रमांक 1:

एक ही तालिका में समान संबंध संरचनाओं को ओवरले करके संवेदनशील डेटा वाली तालिकाओं को छोटा करें।

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

मुख्य शिक्षा संख्या 2:

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

Photo_Content_Role.max_per_person रहस्यमय भी हो सकता है। आप इसे आरेख में नहीं देख सकते, लेकिन Photo_Content_Role.id बिना . अपनी अनूठी बाधा रखता है max_per_person . संक्षेप में, वास्तविक प्राथमिक कुंजी केवल id है . max_per_person adding जोड़कर करने के लिए id प्राथमिक कुंजी में, मैं प्रत्येक रेफ़रिंग तालिका को उस जानकारी को आगे बढ़ाने के लिए बाध्य करता हूं जिसके द्वारा वह (चाहिए!) एक कार्डिनैलिटी चेक बाधा को लागू कर सकता है। Photo_Content ।

मुख्य शिक्षा संख्या 3:

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

आइए कुछ और देखें Photo_Content . यह मुख्य रूप से Photo और Person , संलग्न सामग्री भूमिका द्वारा निर्दिष्ट संबंध के साथ। जैसा कि मैंने पहले उल्लेख किया है, हालांकि, यह वह जगह है जहां हम सभी . स्टोर करते हैं तस्वीर के बारे में वर्णनात्मक जानकारी। इस तरह के खुलेपन को समायोजित करने के लिए, हमारे पास वैकल्पिक content_headline . है और content_detailed स्तंभ। किसी व्यक्ति और फोटो के बीच सामान्य जुड़ाव के लिए इनकी शायद ही कभी आवश्यकता होगी। लेकिन 'बॉब जानुस्किस रिसीव्स द एनुअल अचीवमेंट अवार्ड' जैसी शीर्षक का अनुमान लगाना आसान है। इसके अलावा अगर कोई व्यक्ति नहीं है - 'वस्तु चित्रित', व्यक्ति 0 — हमें content_headline . में कुछ चाहिए , जैसे 'माउंट अरारत का उत्तर पश्चिमी ढलान'।

द लास्ट मिसिंग फोटो रिलेशनशिप:एल्बम

अब तक, हमने Photo s से Photo एस। सामाजिक नेटवर्क और फ़ोटो सेवाओं के लिए यह एक बड़ी बात है:Album एस। और आप उन्हें लौकिक शोबॉक्स में नहीं चाहेंगे, है ना? तो आइए इस स्पष्ट अंतर को भरें - लेकिन आइए इसके बारे में भी सोचें।

Album संलग्न करता है Photo हमारे द्वारा कवर किए गए अन्य रिश्तों की तुलना में एक अलग तरीके से। Photo s एक ही क्लब, एक समान तिथि, पास के GPS निर्देशांक, एक ही फोटोग्राफर, और इसी तरह से संबद्ध हो सकते हैं। हालांकि, Album स्पष्ट रूप से इंगित करता है कि संलग्न Photo s एक ही विषय या कहानी का हिस्सा हैं। जैसे, एक Photo Album . साथ ही, आदेश उन अनुमानों को बढ़ा या घटा सकता है। इसलिए केवल Album एक निर्दोष संग्रह के रूप में। संबंधित Photo s कुछ भी है लेकिन।

हालांकि सुरक्षा की दृष्टि से अहानिकर नहीं है, Album है एक शुद्ध Id . के साथ एक सीधी इकाई एक Club (नहीं Person ) Album_Photo हमें Photo s Photo_Order . आप देखेंगे कि मैंने Album id और order प्राथमिक कुंजी। संबंध वास्तव में Photo और Album , तो क्यों न उन्हें प्राथमिक कुंजी बनाया जाए? क्योंकि विषम मामलों में Photo Album निश्चित रूप से संभव हैं। इसलिए मैंने Photo_Order प्राथमिक कुंजी में, और कुछ विचार के बाद, एक Photo Album . अगर एक Photo एक Album उत्पन्न होती है, प्राथमिक कुंजी की तुलना में एक अद्वितीय कुंजी को निकालना आसान होता है।

मुख्य शिक्षा संख्या 4:

प्राथमिक कुंजी के लिए, ऐसी उम्मीदवार कुंजी का चयन करें जिसे बाद में खारिज किए जाने का कम से कम जोखिम हो।

फ़ोटो मेटाडेटा

जोड़ने के लिए अंतिम संभावित-संवेदनशील जानकारी मेटाडेटा है (आमतौर पर किसी भी डिवाइस द्वारा फ़ोटो लिए गए हैं)। यह डेटा नहीं है एक रिश्ते का हिस्सा है, लेकिन यह तस्वीर के लिए आंतरिक है। फोटो के साथ कैमरा स्टोर की जाने वाली जानकारी की प्राथमिक परिभाषा EXIF ​​है, जो जापान का एक उद्योग मानक (JEITA) है। EXIF एक्स्टेंसिबल है और दर्जनों या सैकड़ों फ़ील्ड का समर्थन कर सकता है, जिनमें से किसी की भी हमारी अपलोड की गई छवियों से आवश्यकता नहीं हो सकती है। यह गैर-आवश्यक स्थिति इसलिए है क्योंकि ये फ़ील्ड सभी फ़ोटो प्रारूपों के लिए सामान्य नहीं हैं और इन्हें अपलोड करने से पहले मिटाया जा सकता है। मैंने Photo कई सामान्य रूप से उपयोग किए जाने वाले क्षेत्रों के साथ, जिनमें शामिल हैं:

• कैमरा_एमएफआर
• कैमरा_मॉडल
• कैमरा_सॉफ्टवेयर_संस्करण
• image_x_resolution
• image_y_resolution
• image_resolution_unit
• image_exposure_time
• camera_aperture_f
• जीपीएस अक्षांश
• जीपीएस देशांतर
• GPSAltitude

GPS फ़ील्ड, स्वाभाविक रूप से पर्याप्त हैं, जो किसी Photo ।

हमारा मॉडल, परिभाषित सभी संवेदनशील और मूल्यवान डेटा के साथ

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

निष्कर्ष

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