ডেস্কটপ অ্যাপ্লিকেশন থেকে আপনি কীভাবে ডাটাবেস সুরক্ষা পরিচালনা করবেন?


12

প্রায় 10 বছর ধরে আমি এসকিউএল সার্ভার ডেটা স্টোরের সাথে বিভিন্ন ইন-হাউস ডেস্কটপ ক্লায়েন্ট অ্যাপ্লিকেশনগুলিতে কাজ করেছি। খুব কমই আমি এই প্রকল্পগুলি শুরু করেছিলাম - বেশিরভাগটি টেকওভারের কাজ।

একটি জিনিস যা সর্বত্র স্থির বলে মনে হয়েছিল তা হ'ল একটি একক গ্লোবাল এসকিউএল সার্ভার ব্যবহারকারীর অ্যাকাউন্ট ছিল যা এই অ্যাপ্লিকেশনটি ব্যবহার করে এটি সাধারণ ডাটাবেসটিকে অনুমতি দিয়েছে এবং হ্যাঁ কিছু নিষ্পাপ পরিস্থিতিতে এটি saব্যবহারকারীর অ্যাকাউন্টটি ব্যবহার করেছে , যা আমি সাধারণত যখন সম্ভব হয়েছিল তখন ঠিক করার চেষ্টা করেছি ।

অ্যাপ্লিকেশনটি ডাটাবেস অ্যাক্সেস করতে ব্যবহার করে এমন ব্যবহারকারীর নাম এবং পাসওয়ার্ডটি আপনি কার্যকরভাবে আড়াল করতে পারবেন না। এগুলি সাধারণত কোনও iniবা configফাইলে সংরক্ষণ করা হয় বা সম্ভবত কার্যকর কার্যকর অবস্থায় বেকড থাকে। সমস্ত ক্ষেত্রে, তারা যদি কিছুটা খনন করে তবে তারা ব্যবহারকারীর কাছে দৃশ্যমান। একটি ক্ষেত্রে আমরা প্রকৃতপক্ষে একটি configফাইল ব্যবহার করেছি তবে এটি এনক্রিপ্ট করেছি, তবে অবশ্যই এনক্রিপশন কীটি এক্সিকিউটেবলের মধ্যে সংরক্ষণ করতে হয়েছিল (আমরা এর সীমাবদ্ধতার জন্য নিখুঁত ছিলাম না, তবে এটি কার্যকরভাবে যারা যথেষ্ট বুদ্ধিমান ছিল তাদের লোকজনকে পোঁতা দেওয়া থেকে বিরত করেছিল) সন্ধান করার জন্য configফাইল)।

এই সমস্ত সিস্টেমে অ্যাপ্লিকেশনটিতে একটি ব্যবহারকারী-প্রমাণীকরণ সিস্টেম তৈরি করা হয়েছিল, তবে অবশ্যই সেগুলি সমস্ত অ্যাপ্লিকেশনটির মাধ্যমেই পরিচালিত হয়েছিল, যার অর্থ ব্যবহারকারীর তথ্য ডাটাবেসে সংরক্ষিত ছিল। অ্যাপ্লিকেশনটি আপনার অ্যাক্সেস স্তরের ভিত্তিতে আপনি কী করতে পারেন তা সীমাবদ্ধ করে, তবে আপনি কেবল ডাটাবেসের সাথে সংযোগ করতে এবং অ্যাড-হক অনুসন্ধানগুলি চালাতে পারলে এটি সমস্ত ধরণের মোট।

এই সমস্যাটি পেতে অন্যান্য সিস্টেমগুলি কী করে তা জানতে আগ্রহী। আমি জানি বিকল্পগুলি এখানে:

  1. কোনও ব্যবহারকারী এবং ভূমিকা তালিকা বজায় রাখতে এসকিউএল সার্ভারের সুরক্ষা ব্যবস্থাটি ব্যবহার করুন এবং ডেস্কটপ অ্যাপ্লিকেশনটিকে টি-এসকিউএল কোয়েরির মাধ্যমে ব্যবহারকারীদের যুক্ত এবং সরান।
  2. সরাসরি ডাটাবেসের সাথে সংযোগ স্থাপনের পরিবর্তে, এমন কোনও ওয়েব সার্ভিস তৈরি করুন যা সার্ভারে চলে এবং সেখানে প্রমাণীকরণের যুক্তি যুক্ত করে। সুরক্ষা বৈধতা প্রতিটি অনুরোধ করুন।

প্রথম বিকল্পগুলি কিছুটা কুৎসিত কারণ আপনি ব্যবহারকারীদের ডাটাবেস থেকে পৃথক করছেন সুতরাং ব্যবহারকারীরা আর প্রথম শ্রেণির সত্তা নেই এবং আপনি তাদের বিদেশী কী সম্পর্কগুলি ইত্যাদির সাথে উল্লেখ করতে পারবেন না etc.

দ্বিতীয়টি কেবল একটি বড় পারফরম্যান্স সমস্যা, এবং প্রচুর অতিরিক্ত কাজের মতো মনে হচ্ছে, তত সহজে আপনি NHibernate (যেমন আমার মনে হয়) এর মতো ORM ম্যাপারগুলি সহজে ব্যবহার করতে পারবেন না।

কাহারো কি এটির সাথে অভিজ্ঞতা আছে? সেরা অনুশীলন?

সম্পাদন করা

আরও কিছু চিন্তা করে, এসকিউএল সার্ভার প্রমাণীকরণ আসলে এই সমস্যাটি সমাধান করতে পারে? উদাহরণস্বরূপ, যদি আপনার ব্যবহারকারীর অবশ্যই টাইমশিট রেকর্ডগুলি সন্নিবেশ করতে এবং আপডেট করতে সক্ষম হয় যাতে আপনি নিজের টাইমশিটটি সম্পাদনা করতে পারেন, এসকিউএল সার্ভারের সময় পত্রকের বিবরণ সারণীতে অন্য সারিগুলিতে অ্যাক্সেসকে বঞ্চিত করার কোনও উপায় নেই, যার অর্থ আপনি অন্য ব্যক্তির টাইমশিটগুলিও পড়তে এবং লিখতে পারেন ।


বাঁধাইয়ের বিষয়টিতে; এনএইচবারনেটের মতো ওআরএম ব্যবহার না করা (আমার মনে হয়) এটি একটি নন ইস্যু। যদি আপনি উদাহরণস্বরূপ ওয়েব পরিষেবাদি ব্যবহার করেন, আপনি এক্সএমএলে আপনার ডেটা দক্ষতার সাথে আবদ্ধ করার জন্য অনেকগুলি উপায় পাবেন।
জেসনক

আপনি আপনার ওআরএমটিকে ব্যবসায়ের জিনিস এবং ডিবি সত্তাগুলির মধ্যে সরাসরি ম্যাপিং হিসাবে ব্যবহার করবেন না, এটি একটি দুর্বল পদ্ধতি যা ভঙ্গুর ইন্টারফেসগুলির জন্য তৈরি করে। এমন কোনও ব্যবসায়ের স্তরে অনুরোধ করুন যা কাঁচা ডিবি সত্তা পায় এবং ক্লায়েন্টকে কেবল প্রয়োজনীয় ডেটা ফেরত দেয়।
gbjbaanb

@gbjbaanb - অবশ্যই, আমি আজ বিকেলে পুরো আর্কিটেকচারটি পরিবর্তন করব। :)
স্কট হুইটলক

আমি মনে করি আপনি এটি পরিবর্তন করার আগে কেউ আপনাকে হ্যাক না করা পর্যন্ত অপেক্ষা করতে পারতেন, তবে উজ্জ্বল দিকে, কমপক্ষে তবে আপনার বসকে পুনর্নির্মাণের জন্য তহবিল সরবরাহ করতে আপনার কোনও সমস্যা হবে না :-)
gbjbaanb

আপনি কোনও ব্যবহারকারীর অন্য কারও রেকর্ড আপডেট করতে বাধা দিতে পারেন - রেকর্ডগুলি আপডেট করার একমাত্র উপায় হিসাবে স্টোরেজ পদ্ধতি ব্যবহার করে এবং যে ব্যবহারকারীর অনুসন্ধানের অংশ হিসাবে চালাচ্ছেন তা ব্যবহার করে। দেখুন CURRENT_USER
gbjbaanb

উত্তর:


9

আমার ভয় হচ্ছে একটি ওয়েব পরিষেবা স্তর যুক্ত করা সম্ভবত আপনার সমস্যার সঠিক সমাধান।

অন্তর্নিহিত ডাটাবেস বাস্তবায়ন থেকে ক্লায়েন্টকে আলাদা করা সম্ভবত আপনাকে দীর্ঘমেয়াদে সহায়তা করবে।

একটি ওয়েব পরিষেবা স্তর যুক্ত করার কারণে অগত্যা কর্মক্ষমতা ক্ষতিগ্রস্থ হবে না ...

প্রকৃতপক্ষে, একটি উপযুক্ত এপিআই দিয়ে, একটি ওয়েব পরিষেবা ডাব্লু ডাব্লুএইচএলকে একাধিক রাউন্ড ট্রিপের প্রয়োজনের পরিবর্তে ডেটা সেন্টার ল্যানের মধ্যে একাধিক ডাটাবেস ক্যোয়ারী একসাথে জড়ো করে কার্য সম্পাদনকে উন্নত করতে পারে।

এবং অবশ্যই একটি ওয়েব পরিষেবা স্তরটি প্রায়শই অনুভূমিকভাবে পরিমাপ করা যায় এবং আপনার ডেটাবেস কোয়েরিতে যথাযথ ক্যাশে যোগ করতে পারে, সম্ভবত একটি পরিবর্তন বিজ্ঞপ্তি প্রক্রিয়াও।

একটি সার্ভার স্তর সুরক্ষা যোগ করে যা আপনি সম্ভবত কোনও দূরবর্তী ক্লায়েন্টে চলমান অ্যাপ্লিকেশনগুলির সাথে এটি নিশ্চিত করতে পারবেন না। ক্লায়েন্টের উপর যে কোনও কিছু চলতে পারে সেটিকে "হ্যাক" করা যেতে পারে এবং কোনওভাবেই এটি বিশ্বাসযোগ্য নয়। আপনার কেবলমাত্র ক্লায়েন্টে উপস্থাপনা যুক্তি রাখা উচিত, এবং হার্ডওয়ারে আপনার গুরুত্বপূর্ণ নিয়ন্ত্রণের জন্য গুরুত্বপূর্ণ কিছু হোস্ট করা উচিত।

আমি আপনার অ্যাপ্লিকেশনগুলি সম্পর্কে জানি না, তবে আমার ওয়েব অ্যাপ্লিকেশনগুলি স্বাভাবিকভাবে কয়েকটি স্তরে বিভক্ত হয়ে গেছে, উপস্থাপনা কোডটি দৃ business়তা স্তর থেকে কমপক্ষে এক স্তরের ব্যবসায়িক যুক্তির দ্বারা পৃথক করে দেয় যা দুটি পৃথক করে রাখে। আমি এটি দেখতে পেয়েছি এটি আমার অ্যাপ্লিকেশন সম্পর্কে যুক্তিযুক্ত করা আরও সহজ করে তোলে এবং কার্যকারিতা যুক্ত করতে বা সংশোধন করার জন্য এত দ্রুত। স্তরগুলি যদি যাইহোক পৃথক করা হয় তবে উপস্থাপনা স্তরটি ক্লায়েন্টে রাখা অপেক্ষাকৃত সহজ এবং বাকীটি আমার নিয়ন্ত্রণে থাকা একটি সার্ভারে থাকা।

সুতরাং যখন আপনি "ওয়েব সার্ভিস" স্তরটি প্রবর্তন না করেই আপনার সমস্যার সমাধান করতে পারেন, আপনি যখন স্ট্যান্ডার্ড ডাটাবেস সুরক্ষা বাস্তবায়নের গর্তগুলি পূরণ করার জন্য প্রয়োজনীয় সমস্ত সঞ্চিত পদ্ধতি (বা সমতুল্য) লিখেছেন, আপনি সম্ভবত লেখার চেয়ে আরও ভাল হবেন একটি সার্ভার-সাইড অ্যাপ্লিকেশন যার জন্য আপনি সঠিক ইউনিট পরীক্ষা লিখতে পারেন।


আমি স্বীকার করি যে এটির জন্য কোনও পারফরম্যান্স বাধা নেই, তবে এটি অবশ্যই স্থাপত্যে একটি অতিরিক্ত স্তর যুক্ত করেছে, যার অর্থ অনেক বেশি রক্ষণাবেক্ষণ।
স্কট হুইটলক

3
এটি একটি স্তর যোগ করে তবে রক্ষণাবেক্ষণের প্রয়োজন হয় না। বিবেচনা করুন যে ক্লায়েন্ট নয়, পরিষেবাতে রাখা সমস্ত যুক্তি দিয়ে, ব্যবহারকারীদের তাদের ক্লায়েন্ট অ্যাপ্লিকেশনগুলি আপডেট করার প্রয়োজন ছাড়াই পরিবর্তনগুলি 'ঘূর্ণিত' করা যেতে পারে।
গ্র্যান্ডমাস্টারবি

5

জোরমোরোর উত্তরের অনুরূপ, আপনি কোনও ব্যবহারকারীর সঞ্চিত পদ্ধতিতে এক্সিকিউটি অনুমতিগুলি বাদ দিয়ে সমস্ত কিছুতে অ্যাক্সেস অস্বীকার করতে পারেন, তারপরে সারণী পদ্ধতিতে প্রয়োজনীয় ক্রিয়াকলাপ সঞ্চালনের জন্য মালিকানা শৃঙ্খলার সুবিধা নিন।

বিস্তারিত জানার জন্য এখানে দেখুন https://msdn.microsoft.com/en-us/library/bb669058(v=vs.110).aspx

যখন ব্যবহারকারী তাদের ব্যবহারকারীর নাম / পাসওয়ার্ড ক্লায়েন্টের পাশে প্রবেশ করে, আমি সেগুলি সঞ্চয় করি এবং প্রতিটি সঞ্চিত পদ্ধতি কলগুলিতে পরামিতি হিসাবে প্রেরণ করি। তারপরে কাঙ্ক্ষিত ক্রিয়াকলাপ সম্পাদনের আগে আপনি কোনও টেবিলে সঞ্চিত মানগুলির বিরুদ্ধে তাদের যাচাই করতে পারেন।

অবশ্যই সুরক্ষার জন্য শেষ শব্দ নয়, তবে আপনার পিসিগুলিতে জেনেরিক লগইন থাকলে অনুমতিগুলির জন্য AD গ্রুপ ব্যবহারের আপনার ক্ষমতা সীমাবদ্ধ করে রাখা বা AD এ নিজেই সীমিত অ্যাক্সেস থাকলে প্রয়োজনীয় হতে পারে।


2

একটি পদ্ধতি হ'ল এডি গ্রুপ এবং সঞ্চিত প্রক্রিয়া ব্যবহারকারীরা কী করতে পারে তা সীমাবদ্ধ করতে ব্যবহার করতে পারেন - উদাহরণস্বরূপ আপনার টাইমশিট ডিবি, ব্যবহারকারীদের ঘন্টা ইনসেট, আপডেট এবং মুছতে অনুমতি দিতে পারে তবে অন্য কারও ঘন্টা আপডেট করার অনুমতি দেয় না। ব্যবহারকারীর আইডি ডিবি ইঞ্জিন দ্বারা সরবরাহ করা হবে, ব্যবহারকারীর ডিবি টেবিলগুলিতে সরাসরি অ্যাক্সেস থাকতে পারে না, কেবল এসপি এর লগইন আইডির উপর ভিত্তি করে অনুসন্ধান চালানো হয়েছিল।

অবশ্যই এটি সবসময় সম্ভব হয় না, তবে এটি হতে পারে। সেরা পদ্ধতির আপনার প্রয়োজনীয়তা এবং সংস্থান উপর নির্ভর করবে।


এটি এমন কিছু যা আমি বিবেচনা করি নি। আমি নিশ্চিত না যে এটি দুর্দান্ত ফিট, তবে এটি কার্যকর হবে।
স্কট হুইটলক

1

আপনি 'ওয়েব সার্ভিস' হিসাবে যে ইঙ্গিতটি দিয়েছেন তাকে এন-টায়ার আর্কিটেকচার বলে । সুরক্ষা বা কনফিগারেশন সংক্রান্ত সমস্যাগুলির ক্ষেত্রে সাধারণত এটি যাওয়ার উপায় (উদাহরণস্বরূপ, অনেক অফিসে কোনও অ্যাপ্লিকেশন বিতরণ)। যদিও এটি 'ওয়েব ভিত্তিক' হতে হবে না। অনেকে অন্যান্য প্রোটোকল নিয়ে কাজ করেন।

আপনি ক্লায়েন্ট এবং ডাটাবেস (এবং অন্যান্য সংস্থানসমূহ) এর মধ্যস্থতাকারী হিসাবে কাজ করতে একটি অ্যাপ্লিকেশন সার্ভার তৈরি করেন। অ্যাপ্লিকেশন সার্ভার আপনার অ্যাপ্লিকেশন ভিত্তিক প্রমাণীকরণ পরিচালনা করে এবং ক্লায়েন্টের পক্ষে ক্রিয়া করে। আসলে, আদর্শভাবে আপনি আপনার ক্লায়েন্টে কোনও এসকিউএল করছেন না - বরং আপনি অ্যাপ্লিকেশন সার্ভারে পদ্ধতিগুলি কল করেন। অ্যাপ্লিকেশন সার্ভার সমস্ত ডেটা ম্যানিপুলেশন পরিচালনা করবে।

পদ্ধতির অনেকগুলি সুবিধা রয়েছে। আপনার ক্লায়েন্টগুলিতে ডাটাবেস সংযোগ এবং ড্রাইভারগুলি কনফিগার করতে হবে না। আপনি ডাটাবেস ব্যবহারকারী, পাসওয়ার্ড এবং সার্ভার সঞ্চয় করবেন না। ক্লায়েন্টদের কনফিগারেশন এমনকি প্রয়োজনীয় নয় - কেবলমাত্র তাদের ডান ইউআরএল বা ঠিকানায় কোডটি দেখান। এছাড়াও, অ্যাপ্লিকেশন সার্ভারে 'লজিক' দিয়ে, অন্যান্য অ্যাপ্লিকেশনগুলি বিকাশ করার সময় আপনাকে নিজেকে পুনরাবৃত্তি করতে হবে না - একই অ্যাপ্লিকেশন সার্ভারটি বিভিন্ন ধরণের ক্লায়েন্টরা পুনরায় ব্যবহার করতে পারে।


আরও ভাল, যদি (বা কখন) কেউ আপনার ডেস্কটপগুলি হ্যাক করে (বা ওয়েব ভিত্তিক সমতলে ওয়েবসার্ভার) আক্রমণকারীটির ওএস-তে সম্পূর্ণ অ্যাক্সেস থাকতে পারে তবে তাদের ডিবিতে এখনও কোনও অ্যাক্সেস নেই। এবং তাই তারা "ব্যবহারকারীদের কাছ থেকে নির্বাচন করুন" চালাতে পারে না এমন কোনও ফাইলের পাইপ যা তারা নিয়ে যায়, তাদের অবসরকে টানুন এবং আপনার সিইও মিডিয়াকে আপনার সুরক্ষিত সিস্টেমের সাথে কেন আপস করা হয়েছে তা বোঝাতে দিন। আপনি যদি ডিবিতে স্প্রোকগুলি ব্যবহার করেন যা কেবল অ্যাক্সেস কার্যকর করতে দেয় তবে আক্রমণকারী আপনার অ্যাপ্লিকেশনটিও হ্যাক করতে পারে এবং তারা এখনও আপনার সম্পূর্ণ ব্যবহারকারী ডাটাবেস পেতে পারে না।
gbjbaanb

1

প্রযুক্তি কিছুটা বদলেছে। আপনি যদি প্রতিটি ব্যবহারকারীর ডাটাবেসে নিজেই প্রমাণীকরণ করেন এবং ডাটাবেস রোলগুলি ব্যবহার করেন তবে কমপক্ষে এসকিউএল সার্ভারে আপনি এখন এই সমস্যাটি সমাধান করতে আপডেটড ভিউ বলে যা ব্যবহার করতে পারেন।

এখানে একটি আপডেটযোগ্য ভিউ এমন কোনও টেবিলের মতো দেখতে দেখতে পারে SomeTableযেখানে সেই টেবিলের প্রতিটি সারি কোনও কর্মীর সাথে সংযুক্ত থাকে। কর্মচারীর সারিগুলি তাদের সাথে যুক্ত দেখতে পারা উচিত এবং এইচআর ভূমিকার সদস্যদের সমস্ত সারি দেখতে সক্ষম হওয়া উচিত, উদাহরণস্বরূপ:

CREATE VIEW [dbo].[vwSomeTable]
AS
    SELECT SomeTable.*
    FROM SomeTable
        INNER JOIN Employee ON SomeTable.Employee_ID = Employee.Employee_ID
    WHERE Employee.Username = USER_NAME() OR IS_MEMBER('HR_Role')=1

GO

তারপর কি কি পড়তে দিন (এবং সম্ভবত লিখন) অনুমতি দৃশ্য ( vwSomeTableসকল ব্যবহারকারীর জন্য), এবং কোন অনুমতি দিতে টেবিল ( SomeTable)।

আপনি এটির মতো পরীক্ষা করতে পারেন:

EXECUTE AS USER = 'Some_Regular_Username'
SELECT * FROM vwSomeTable

... যা কেবল তাদের সারিগুলি ফিরিয়ে আনবে। বা:

EXECUTE AS USER = 'Some_HR_Username'
SELECT * FROM vwSomeTable

... যা সমস্ত সারি ফিরিয়ে দেবে। নোট করুন যে এই পরীক্ষাটি করার জন্য আপনার (ছদ্মবেশী) অনুমতি হিসাবে কার্যকর করতে হবে।

দর্শনগুলি হালনাগাদযোগ্য, তাই যতক্ষণ না সারিটি তাদের Employeeসারির সাথে যুক্ত থাকে ততক্ষণ নিয়মিত ব্যবহারকারীও এটি করতে পারেন :

UPDATE vwSomeTable
SET SomeColumn = 5
WHERE SomeTable_ID = 'TheID'

0

শংসাপত্র ভিত্তিক প্রমাণীকরণ ব্যবহার করা ভাগ করা স্কিল অ্যাকাউন্ট বাস্তবায়নের "সঠিক" উপায়। লক্ষ্যটি হ'ল এটি এই জাতীয় জিনিসের জন্য পাসওয়ার্ডের ব্যবহারকে বাদ দেয়।

হালনাগাদ:

আমি মনে করি প্রশ্নটি ভুল বুঝেছি। আমি ভেবেছিলাম এটি একটি অ্যাপ্লিকেশন কনফিগারেশনে একটি ডিবি ব্যবহারকারীর নাম এবং পাসওয়ার্ড রাখার বিকল্প সন্ধান করার চেষ্টা করে বা অ্যাপ্লিকেশনটিতেই ব্যাকড করে।

পরিবর্তে ক্লায়েন্ট সাইড শংসাপত্র ব্যবহার করে আপনি অ্যাপ্লিকেশনগুলিতে পাসওয়ার্ড পরিচালনা করার সমস্যাটি দূর করতে পারেন। শংসাপত্রটি নিজেই যথেষ্ট নয়, আপনার কাছে শংসাপত্র প্রত্যাহারের মতো ক্রিয়াকলাপে সক্ষম একটি বিতরণ এবং পরিচালনা ব্যবস্থা থাকতে হবে।

তথ্যসূত্র: http://en.wikedia.org/wiki/Public-key_inf पाया


আপনি কি এই সম্পর্কে আরও কিছু তথ্য সরবরাহ করতে পারেন? এটি আমার আসল প্রশ্নের অভিপ্রায় অনুসৃত হতে পারে বলে মনে হচ্ছে তবে এটি আকর্ষণীয়।
স্কট হুইটলক

0

একটি নতুন ডেস্কটপ সুরক্ষা সমাধান তৈরি করে আমরা ওয়েব পরিষেবা সমাধানটি বেছে নিয়েছি, বেলো বর্ণনা করার চেষ্টা করব।

আমরা বিকাশকারীদের থেকে পৃথক পরিবেশে ডেস্কটপ অ্যাপ্লিকেশন এক্সিকিউটেবলকে সংকলন করি। এবং সেই এক্সিকিউটেবল থেকে একটি হ্যাশ গণনা করুন যা ডাটাবেসে রেকর্ড করা আছে।

একটি ওয়েব পরিষেবা যা অ্যাপ্লিকেশনটি চালানোর জন্য প্রয়োজনীয় সমস্ত তথ্য সরবরাহ করে, ডিবি পাসওয়ার্ড, সংযোগের স্ট্রিংয়ের তথ্য, ব্যবহারকারীর অনুমতি ইত্যাদি,

আমরা প্রতি প্রয়োগে একক ডিবি লগ ইন ব্যবহার করি এবং রেকর্ড অডিট করতে সক্ষম হতে সেশন ভেরিয়েবলগুলিতে ডাটাবেসে ব্যবহারকারীর বিবরণ রেকর্ড করি।

একটি ডিএলএল ডেস্কটপ অ্যাপ্লিকেশন থেকে ওয়েব-পরিষেবাতে সমস্ত যোগাযোগ পরিচালনা করে, যা কেবলমাত্র ডিএলএলে টোকেন বিল্ডের মাধ্যমে অ্যাক্সেসযোগ্য।

ওয়েব সার্ভিস থেকে অ্যাপ্লিকেশন ডিবি পাসওয়ার্ড পেতে সক্ষম হবার জন্য ডিএলএল রানটাইমের সময় ডিএলএল কলারদের এইচএএসএইচ গণনা করে এবং ওয়েব সার্ভিসে একটি পরামিতি হিসাবে পাস করে যা ডিএলএল টোকেনকে বৈধ করে এবং কার্যকর করার সময় রানটাইম গণনা করা HASH এটি রেকর্ডকৃত রেকর্ড করা হয় (অ্যাপ্লিকেশনটি কেবলমাত্র একটি একক নেটওয়ার্ক শেয়ারড ইনস্টলেশনতে উপলব্ধ)।

আমরা যেভাবে পড়েছি এটি হ'ল সুরক্ষা সমস্যাটির একটি ভাল সমাধান আমরা যেখানে সবচেয়ে বেশি উদ্বিগ্ন এবং কয়েকটি ডিজাইনের ত্রুটিগুলি সম্পর্কে ভালভাবে অবগত। প্রায় এই বাস্তবায়ন শেষ হয় এবং এখন পর্যন্ত আমরা ফলাফল নিয়ে খুশি।

সম্পাদনা করুন: আপনি ডিজিটাল স্বাক্ষর এবং X.509 শংসাপত্র ব্যবহার করে হ্যাশ ধারণাটি প্রতিস্থাপন করতে পারেন।


1
সুস্পষ্ট সুরক্ষা গর্তটি এটি যেখানে বেশ স্পষ্ট বলে মনে হচ্ছে। আপনি যে ডিএলএলের কথা বলছেন তা ক্লায়েন্টের সিস্টেমে রয়েছে এবং এটি আপনার ডিএলএল এর একটি বৈধ অনুলিপি বা হ্যাকড / দূষিত / নকলের সাথে কথা বলছে কিনা তা যাচাই করার জন্য আপনার সার্ভার কোডের কোনও উপায় নেই। আপনি অতিরিক্ত সুরক্ষা যোগ না করে সবেমাত্র নিজের জন্য প্রচুর কাজ তৈরি করেছেন। দূষিত ব্যক্তির সমস্ত প্রয়োজন হ'ল টোকেন এবং অ্যালগরিদম, উভয়ই ডিএলএলে রয়েছে যে কেউ দেখতে চান।
স্কট হুইটলক

@ স্কটউইটলক, হ্যাঁ, আমি সম্মত। আমরা ডিএলএল অবলম্বন করছি এবং এইচটিটিপিএস দিয়ে ট্রাফিক যাচ্ছি। আমরা এটির উন্নতি করার চেষ্টা করছি, আমি কীভাবে এটি উন্নত করতে চাইলে কোনও ইনপুট পছন্দ করি। কিন্তু সেই সমাধানটি ইতিমধ্যে নেটওয়ার্ক ফাইলে সঞ্চিত সরল পাঠ্য পাসওয়ার্ড সহ বর্তমান সিস্টেমের প্রচুর সমস্যার সমাধান করে। এছাড়াও ওয়েলসার্ভিসটি এখানে আমরা ব্যবহার করি এমন ক্লায়েন্টের যে কোনও ভাষা ব্যবহার করে প্রচুর কোডের পুনরায় ব্যবহারের অনুমতি দেয়, ডেল্ফি এবং ক্লিপার (হারবার) ক্লায়েন্ট সহ!
ভিজিটর আরবেেক্স

আপনার সিস্টেমে ব্যবহারকারী লগ ইন করে এবং সম্ভবত ওয়েব পরিষেবা দ্বারা প্রমাণীকৃত হয়। ধরে নিচ্ছি এইচটিটিপিএসের ব্যবহার, তা কি যথেষ্ট ভাল নয়? আপনাকে ক্লায়েন্ট সফ্টওয়্যার বিশ্বাস করতে হবে না, যেহেতু আপনি জানেন যে ব্যবহারকারী কে তারা বলে তারা এবং আপনি ওয়েব পরিষেবা নিয়ন্ত্রণ করেন, তাই নিশ্চিত হয়ে নিন যে প্রদত্ত ব্যবহারকারীর দেখার অনুমতি প্রাপ্ত ওয়েব সার্ভিস কেবল সেই তথ্যই হাতে দিয়েছে hands এমনকি যদি তারা ক্লায়েন্টকে বিপরীত ইঞ্জিনিয়ার করে এবং নিজস্ব লেখা দেয় তবে তারা কী ক্ষতি করতে পারে? কেবলমাত্র আপনার ওয়েব পরিষেবাটি ডিবি পাসওয়ার্ড জানে এবং এটি নিরাপদ হওয়া উচিত।
স্কট হুইটলক
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.