কেন ব্যবহারকারীদের পাসওয়ার্ড একেবারে সংরক্ষণ করা?


10

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

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

উদাহরণস্বরূপ, যদি কোনও ব্যবহারকারীর এক্স আমার ওয়েব অ্যাপ্লিকেশনটিতে অ্যাকাউন্ট ব্যবহারকারী পাসওয়ার্ড ওয়াই তৈরি করতে চায় তবে নীচের ক্যোয়ারীটি কীভাবে ভুল প্রদান করা হচ্ছে:

CREATE USER X WITH ENCRYPTED PASSWORD Y IN GROUP baseuser;

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

আমি এই পদ্ধতির একাধিক সুবিধা দেখছি:

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

তবে কার্যত প্রতিটি প্রশ্নের উপরে আমি এই বিষয়টিতে দেখছি, সেখানে একটি সাধারণ toক্যমত্য বলে মনে হচ্ছে যে জিনিসগুলি করতে হবে এমন নয়। আমার প্রশ্ন: কেন?

দ্রষ্টব্য: তৃতীয় দফা দ্বারা অনুমোদিত হয় নীতি পোস্টগ্রি, এবং নিরাপত্তা নীতি মাইক্রোসফট SQL সার্ভার হবে। আমি বুঝতে পারি যে এই ধারণাগুলি নবাগত, তবে যাইহোক, এখন তারা এখানে রয়েছে, আমি যে কৌশলটি বর্ণনা করি তা ব্যবহারকারীর অ্যাকাউন্টগুলি পরিচালনা করার মানক উপায় হয়ে ওঠে না কেন?


2
মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।
পল হোয়াইট 9

ঘটনাচক্রে, স্বাভাবিক উত্তরটি ভুল। আপনার পাসওয়ার্ডটি নুন দেওয়া উচিত, তারপরে একে ধীরে অ্যালগোরিদম যেমন বিক্রিপ্ট বা আর্গোন 2 দিয়ে হ্যাশ করা উচিত ।
টিজিআর

উত্তর:


27

কারণ অনেক অ্যাপ্লিকেশনগুলির জন্য, তারা পৃথক ব্যবহারকারীর অ্যাকাউন্টগুলি ডেটাবেসে সংযুক্ত হতে চায় না। ব্যবহারকারী / পাসওয়ার্ড / অধিকার / অনুমতিগুলি সমস্ত অ্যাপ্লিকেশন স্তরে পরিচালিত হয় এবং ডাটাবেসের ব্যাক-এন্ডে সংযোগ করতে একটি একক উত্সর্গীকৃত পরিষেবা অ্যাকাউন্ট ব্যবহৃত হয়।

ডিবিএ হিসাবে, আমি ডাটাবেস পর্যায়ে, কিছু মাঝারি আকারের পাবলিক-ফেসিং ওয়েব অ্যাপ্লিকেশনের 10,000 সক্রিয় ব্যবহারকারী অথবা কিছু হঠাৎ জনপ্রিয় অ্যাপের 2+ মিলিয়ন ব্যবহারকারীকে পরিচালনা করতে চাই না।

সত্যিকার অর্থে, অ্যাপ্লিকেশন বিকাশকারী এবং ডাটাবেস বিকাশকারী / ডিবিএর মধ্যে দর্শনের মধ্যে এটি একটি পার্থক্য।

অনেক / বেশিরভাগ অ্যাপ্লিকেশন বিকাশকারী অ্যাপ্লিকেশন কার্যকারিতা এবং / অথবা ব্যবসার নিয়মের বড় দিকগুলির জন্য ডেটাবেস স্তরটিতে দায়বদ্ধ করতে চান না। পরিবর্তে, তারা ডেটাবেসটিকে কেবল ডেটা সঞ্চয় এবং পুনরুদ্ধারের সরঞ্জাম হিসাবে দেখে।

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

তবে এই কয়েকটি শীতল বৈশিষ্ট্যগুলি কেবলমাত্র নতুন সংস্করণগুলিতে উপলভ্য রয়েছে এবং সংস্থাগুলি সর্বদা বিদ্যমান পরিবেশগুলিকে আপগ্রেড করতে তাত্পর্যপূর্ণ হয় না ( 2014 থেকে এই চার্টটি দেখুন )।

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


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

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

সেখানে একটি ওয়েব পরিষেবা এবং একটি টমক্যাট অ্যাপ্লিকেশন সার্ভার নিক্ষেপ করুন এবং আপনি আইবিএম
নিক.এমসিডার্মেইডের

8

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

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

তবুও আপনার ডাটাবেস স্তরে প্রতি-অ্যাপ্লিকেশন-ব্যবহারকারী অ্যাকাউন্টগুলি থাকা সত্ত্বেও আপনার অ-অনুমোদনপ্রাপ্ত অনুরোধগুলি মোকাবেলার জন্য এখনও অ্যাপ্লিকেশন স্তরের ব্যবহারকারীর অ্যাকাউন্টগুলি প্রয়োজন - যেমন যদি অ্যাপ্লিকেশনটির সফলভাবে প্রমাণীকরণের আগে অ্যাপ্লিকেশনটির ডাটাবেস থেকে তথ্য প্রয়োজন হয় (সম্ভবত স্বাগতম / লগইন স্ক্রিনে স্থিতির তথ্য প্রদর্শন করুন?)।

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


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

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

3
আমি একমত যে সুরক্ষার দিক থেকে ডাটাবেস স্তরের ব্যবহারকারীরা আরও ভাল হতে পারবেন। তবে এটি মূলতঃ অনলাইন শপগুলির সাথে পরিচালনা করা অসম্ভব যেখানে আপনার ৫০ মিলিয়ন নিবন্ধিত ব্যবহারকারী থাকতে পারে। প্রত্যেকের একটি ডাটাবেস ব্যবহারকারী হতে হবে। প্লাস: এটি সাধারণত একটি সংযোগ পুল ব্যবহার করে ওয়েব অ্যাপ্লিকেশনগুলির সাথে ভাল খেলতে পারে না।
a_horse_with_no_name

6

প্রশ্ন পুনরায়

কেন ব্যবহারকারীদের পাসওয়ার্ড একেবারে সংরক্ষণ করা?

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

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

আপনি যা সত্যিই জিজ্ঞাসা করছেন বলে মনে হচ্ছে তা হ'ল

ইতিমধ্যে ডাটাবেস থাকা অবস্থায় কেন অ্যাপ্লিকেশন স্তরের প্রমাণীকরণের স্কিম ব্যবহার করবেন?

নিরাপত্তা

আপনি আরও সুরক্ষিত সংস্করণ লিখতে পারেন এমন সম্ভাবনা উপেক্ষা করে অন্যরা বিভিন্ন কারণের পরামর্শ দিয়েছেন। আমি সাধারণত একমত। তবে আরেকটি আছে যা এখনও কেউ উল্লেখ করেনি। আপনি আপনার ডাটাবেসের সুরক্ষার সাথে আপস করছেন।

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

সুরক্ষা পেঁয়াজের স্তরগুলিতে, সাধারণ সিস্টেমটি হ'ল:

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

এই সিস্টেমে:

  • শেষ ব্যবহারকারীরা ব্যবহারকারীর / পাসওয়ার্ডের সংমিশ্রণগুলি জানেন যা খুব কম সুযোগ-সুবিধার সাথে স্বীকার করে, ডাটাবেসে কাজ করবে।
  • কেবলমাত্র একটি সার্ভার তৈরি করা বা দৃ or়ভাবে একটি অনুমোদিত সার্ভার হিসাবে ভান করা দরকার।

সুরক্ষার পুরো প্রয়োগ স্তরটি আমরা হারিয়ে ফেলেছি। এবং আমরা স্বেচ্ছায় ডাটাবেস স্তরটির কিছু অংশ ছেড়ে দিয়েছি। সুতরাং আমাদের কেবল দুটি শোষণ দরকার:

  1. অনুমোদিত কোনও সার্ভারকে স্পুফ বা আপোস করুন।
  2. সীমিত সুবিধা অ্যাকাউন্টের অ্যাক্সেস বৃদ্ধি করুন।

যদি আমরা এই দুটি জিনিস করতে পারি তবে আমাদের ডাটাবেসে অ্যাক্সেস রয়েছে। সুতরাং আমরা তিনটি স্তর থেকে নীচে নেমে যাই। (সাধারণ সিস্টেমে তৃতীয় স্তরটি হ'ল ডাটাবেসের সাথে সংযোগ করার জন্য আপনার একটি বৈধ ব্যবহারকারীর প্রয়োজন))

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

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


5

আপনি যা বর্ণনা করেছেন তা প্রমাণীকরণটি পরিচালনা করবে, তবে অনুমোদন নয় (ব্যবহারকারী কোন ডেটা ব্যবহার করতে পারবেন) বা কেবল ব্যবহারের ক্ষেত্রে সবচেয়ে সাধারণ ক্ষেত্রে।

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

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

আপনার সমাধানের সাহায্যে আপনি কেবল একটি পাসওয়ার্ড কলাম বাদ দিতে পারেন, যা পূরণ করা এত কঠিন নয়: এখানে কীভাবে / হ্যাশ পাসওয়ার্ডগুলি পরিচালনা করতে হয় তার জন্য ভাল লাইব্রেরি এবং ডকুমেন্টেশন রয়েছে।

অন্য একটি বিষয়: আপনি কীভাবে সংযোগ পুল তৈরি করবেন? আমি কেবল জেডিবিসি (জাভা <-> ডিবি) জানি, এবং সংযোগ পেতে আপনার একটি ব্যবহারকারীর নাম + পাসওয়ার্ড সরবরাহ করতে হবে, তারপরে আপনি পুল করতে পারেন।

আমি অন্য কয়েকটি পয়েন্টের কথা ভেবেছিলাম যা প্রতিষ্ঠিত উপায়ে অপেক্ষা বাস্তবায়ন করা আরও শক্ত / আরও সংঘবদ্ধ হবে:

  • পাসওয়ার্ড পুনরুদ্ধার পরিচালনা করছে
  • প্রাথমিক প্রয়োগের 2 বছর পরে, আপনার পণ্য পরিচালক আপনাকে ওউথ স্কিমের জন্য সমর্থন যোগ করতে, বা ডাবল ফ্যাক্টর লেখাকে অনুমোদন দিতে বলে

CREATE POLICY deleted_posts_high_rep ON posts FOR SELECT TO baseuser USING ((SELECT rep FROM users WHERE name = current_user()) > 10000)আপনার প্রথম প্রশ্নের উত্তর দেওয়ার মতো কিছু । আমি কখনও বলিনি যে আমার আর ব্যবহারকারীর টেবিলের দরকার নেই, এবং ডিবি ব্যবহারকারী সারণির সাথে সিঙ্ক নিশ্চিত করা কিছুটা জটিল তবে সম্ভব। আলোচিত কৌশলটির মূল বিষয়টি হল সুরক্ষা। সংযোগ পুলের বিষয়ে, আমি ওসিএএমএল এর সাথে কাজ করি এবং আমাকে বলতে হবে কেন আমার সংযোগের পুল প্রয়োজন হবে কেন আমি পাই না। আমি বর্তমানে সংযোগ প্রত্যাবর্তন করে 0-অ্যারি ফাংশনগুলিতে কুকি মানগুলিকে সংযুক্ত করে একটি হ্যাশ মানচিত্র ব্যবহার করছি :-)
ফ্যাবিয়ান পাইজেকে

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

3
ফ্যাবিয়ান, সংযোগ পুলিং যে কোনও ধরণের স্কেলে মৌলিক, এটি সত্যিই একটি ডিফল্ট যা আপনি এমনকি ব্যবহার না করে বিবেচনা করবেন না। এটি কতটা গুরুত্বপূর্ণ তা আপনাকে ধারণা দেওয়ার জন্য এখানে কয়েকটি মানদণ্ড দেওয়া হচ্ছে: সংযোগ পুলিংয়ের সাথে 600x পারফরম্যান্স বৃদ্ধি ( vladmihalcea.com/2014/04/17/the-ataty-of- সংযোগ- পুলিং ) এবং 4,000x এর বেশি পারফরম্যান্সের সাথে বৃদ্ধি সংযোগ পুলিং ( অগ্রগতি / টিউটোরিয়ালস / জেডিবিসি /… )। এটি কয়েকটি মাত্রার পার্থক্যের অর্ডার, এটি "ভাল লাগলে ভাল" নয়, অ্যাপসটি এগুলি ছাড়াই থামবে।
ইভান ম্যাকা

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

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

1

অন্য একটি বিষয়: অনেকগুলি [1] ওয়েব অ্যাপ্লিকেশন আপনাকে নিজেরাই অ্যাপ্লিকেশনটির মাধ্যমে অন লাইন একটি ব্যবহারকারী অ্যাকাউন্ট নিবন্ধন করতে এবং তৈরি করতে দেয়। যার অর্থ আপনার বেনাম ব্যবহারকারীর (যার ন্যূনতম সুবিধাগুলি হওয়ানো উচিত) ব্যবহারকারী তৈরি করার এবং অধিকার দেওয়ার অধিকার থাকতে হবে!

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

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

এছাড়াও, এটি পুল বা পুনরায় ব্যবহৃত ডিবি সংযোগগুলির কোনও ব্যবহার রোধ করবে।

[1] বেশিরভাগ আমিই বলব, তবে এটির ব্যাক আপ দেবার মতো চিত্রগুলি নয়

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.