কার্যকরী প্রমাণীকরণ এবং অনুমোদন সিস্টেম ডিজাইন করা

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

• প্রমাণীকরণ হল প্রমাণ করার প্রক্রিয়া, আপনি, আপনি কে বলছেন, একটি অ্যাপ্লিকেশন অ্যাক্সেস করার সময়।
• অনুমোদন হল অ্যাক্সেস নীতিগুলি সংজ্ঞায়িত এবং প্রয়োগ করার প্রক্রিয়া - অর্থাৎ, আপনি একবার প্রমাণীকরণ হয়ে গেলে আপনি যা করতে পারেন৷

এই নিবন্ধে, আমরা দেখতে পাব:

• কেন প্রমাণীকরণ এবং অনুমোদন ব্যাপার
• প্রমাণীকরণ কিভাবে কাজ করে
• অনুমোদন কিভাবে কাজ করে
• প্রমাণীকরণ সিস্টেম ডিজাইন
• উপসংহার

কেন প্রমাণীকরণ এবং অনুমোদন ব্যাপার?

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

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

প্রমাণীকরণ কিভাবে কাজ করে?

একজন ব্যক্তিকে প্রমাণীকরণ করার জন্য, আমরা প্রতিটি ব্যক্তির জন্য একটি অনন্য বাক্যাংশ বরাদ্দ করতে পারি, এবং সেই ব্যক্তিটি সঠিকভাবে বাক্যাংশটি এবং তাদের নাম বলে দেয়। আমরা বলতে পারি ঠিক আছে, আমরা ব্যক্তিটিকে চিহ্নিত করেছি। এটি সাধারণ ব্যবহারকারীর নাম এবং পাসওয়ার্ড পদ্ধতি। যখন সঠিক শংসাপত্র দেওয়া হয়, একটি সিস্টেম পরিচয়টিকে বৈধ বলে মনে করে এবং অ্যাক্সেস মঞ্জুর করে। এটি 1FA বা একক-ফ্যাক্টর প্রমাণীকরণ (SFA) নামে পরিচিত।

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

• একক-ব্যবহারের পিন নম্বর / ওটিপি
• প্রমাণীকরণ অ্যাপগুলি নিরাপদ 3য় পক্ষ দ্বারা চালিত (উদাঃ Google/Microsoft প্রমাণীকরণকারী)
• বায়োমেট্রিক্স

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

ব্যবহারকারীকে প্রমাণীকরণ করার 2টি উপায়:

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

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

টোকেন-ভিত্তিক প্রমাণীকরণের জন্য, আমরা বেশিরভাগই JWTs (JSON ওয়েব টোকেন) ব্যবহার করি।

অনুমোদন কিভাবে কাজ করে?

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

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

ACL প্রায়শই ABAC বা RBAC-এর চেয়ে দানাদার স্তরে ব্যবহৃত হয় - উদাহরণস্বরূপ, একটি নির্দিষ্ট ফাইলে পৃথক ব্যবহারকারীদের অ্যাক্সেস দেওয়ার জন্য। ABAC এবং RBAC সাধারণত কোম্পানি-ব্যাপী নীতি হিসাবে প্রতিষ্ঠিত হয়।

প্রমাণীকরণ সিস্টেম ডিজাইন

প্রয়োজনীয়তা

প্রথমে সিস্টেমের কার্যকরী প্রয়োজনীয়তা সংজ্ঞায়িত করে শুরু করা যাক:

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

কিছু অ-কার্যকর প্রয়োজনীয়তা যা আমরা এই নিবন্ধের সুযোগ বিবেচনা করতে যাচ্ছি না:

• মাল্টি-ফ্যাক্টর প্রমাণীকরণ (MFA) : একটি শক্তিশালী MFA সিস্টেম বাস্তবায়ন করুন।
• নিরাপত্তা : এনক্রিপশন, নিরাপদ সঞ্চয়স্থান এবং নিরাপদ যোগাযোগের মাধ্যমে ডেটা নিরাপত্তাকে অগ্রাধিকার দিন।
• পরিমাপযোগ্যতা : ক্রমবর্ধমান ব্যবহারকারী এবং লেনদেন পরিচালনা করার জন্য সিস্টেম ডিজাইন করুন।
• নির্ভরযোগ্যতা : সিস্টেম ডাউনটাইম মিনিমাইজ করুন এবং উচ্চ প্রাপ্যতা নিশ্চিত করুন।
• ব্যবহারযোগ্যতা : একটি বিরামহীন অভিজ্ঞতার জন্য একটি স্বজ্ঞাত ব্যবহারকারী ইন্টারফেস বিকাশ করুন।

ক্ষমতা অনুমান

ট্রাফিক অনুমান

প্রথমে ট্রাফিক অনুমান দিয়ে শুরু করা যাক। প্রতি মাসে গড়ে 100,000 ট্রাফিক অনুমান করা হচ্ছে৷ আমরা প্রতি মাসে 100k ব্যবহারকারীর ট্র্যাফিক অনুমান করছি৷ যা প্রতি সেকেন্ডে 0.04 অনুরোধে অনুবাদ করে। আমাদের প্রতিটি অনুরোধে 500ms 90% সময়ের মধ্যে সাড়া দিতে হবে, অর্থাৎ আমাদের 500ms এর p90 লেটেন্সি প্রয়োজন।

 assumed_traffic_per_month = 100000 #requests assumed_traffic_per_day = assumed_traffic_per_month / 30 ~= 3350 (assuming on higher end; 3333.33 to be precise) estimated_time_per_request = 500 #ms; P90 of 500ms traffic_per_second = (assumed_traffic_per_month) / (30*24*60*60) = 0.04

পরিষেবা স্তরের উদ্দেশ্য (SLO) : 500ms (সর্বোচ্চ গ্রহণযোগ্য বিলম্ব, সিস্টেমে লোডের অযৌক্তিক) গড় ক্ষমতা 1টি উদাহরণ নিতে পারে, আমাদের গণনার উপর ভিত্তি করে একটি অনুরোধ পরিবেশন করতে প্রায় 35ms হয়, ধরে নিলাম যে কোনও ভারী প্রক্রিয়াকরণ হচ্ছে না বিশেষ অনুরোধ।

উপরের মেট্রিকগুলি ব্যবহার করে আরও দুটি প্রাপ্ত মেট্রিক তৈরি করা যাক।

• ক্যাপাসিটি : প্রতি দৃষ্টান্তে গ্রহণযোগ্য ব্যাকলগ: SLO-এর সাথে আপস না করেই একটি উদাহরণের মাধ্যমে গ্রহণ করা যেতে পারে এমন অনুরোধের (লোড) সর্বাধিক সংখ্যা।
• চাহিদা : প্রতি দৃষ্টান্ত ব্যাকলগ: বর্তমান ট্রাফিকের উপর ভিত্তি করে একটি ইউনিট/উদাহরণে প্রবাহিত অনুরোধের মোট সংখ্যা (লোড)।

এইভাবে,

 SLO = 500ms approx_response_time_for_one_request = 35 #ms capacity = SLO/approx_response_time_for_one_request = 500 / 35 ~= 20 load_on_one_instance = 0.04 instances_available = 1 demand = traffic_per_second / instances_available = 0.04

চাহিদা এবং ক্ষমতা উপলব্ধ সহ, প্রয়োজনীয় দৃষ্টান্তের মোট সংখ্যা গণনা করা যাক।

 total_units_required = demand / capacity = 0.04 / 20 = 0.002 ~= 1

এইভাবে, আমরা সহজেই প্রতি মাসে 100k অনুরোধ পরিচালনা করতে সক্ষম হব, 0.04 রিকোয়েস্টস্পার সেকেন্ডে, 1টি উদাহরণ সহ। যেখানে প্রতিটি ইউনিট SLO নিয়ে আপস না করে প্রতি সেকেন্ডে 20টি অনুরোধ পরিচালনা করতে পারে।

স্টোরেজ অনুমান

প্রমাণীকরণ এবং অনুমোদন অ্যাক্সেসের জন্য আমাদের আদর্শভাবে প্রতিটি ব্যবহারকারীর জন্য ব্যবহারকারীর বিবরণ সংরক্ষণ করতে হবে। ধরে নিচ্ছি, 5kb/ব্যবহারকারী

 monthly_new_users = 500 monthly_additional_storage = 500 * 5kb = 2500kb ~= 2GB

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

 auth_request_size = 2kb #assumption monthly_storage = monthly_visitors * auth_request_size = 100,000 * 2KB ~= 200MB

সুতরাং, প্রতি মাসে আমাদের অতিরিক্ত 200MB প্রয়োজন হবে, মাসিক 100k ট্রাফিক অনুমান করে।

ডাটাবেস ডিজাইন

এখন আমরা যে ক্ষমতা অনুমান করা আছে. কার্যকরী প্রয়োজনীয়তা সমর্থন করার জন্য প্রয়োজনীয় ডাটাবেসের স্কিমা তৈরি করা যাক।

দ্রুত টেবিলের উপর যেতে দেয়. আমরা 6 টি টেবিল ব্যবহার করছি।

1. ব্যবহারকারী - সমস্ত ব্যবহারকারীর তথ্য সংরক্ষণ করতে
2. শংসাপত্র - ব্যবহারকারী অনুমোদিত হওয়ার পরে অ্যাক্সেস/রিফ্রেশ শংসাপত্রগুলি সংরক্ষণ করতে।
3. পাসওয়ার্ড - ব্যবহারকারীর এনক্রিপ্ট করা ব্যবহারকারীর পাসওয়ার্ড সংরক্ষণ করতে।
4. পাসওয়ার্ড অনুরোধ - পাসওয়ার্ড পরিবর্তনের অনুরোধগুলি সংরক্ষণ করতে যা একটি নির্দিষ্ট ব্যবহারকারীর জন্য আসে।
5. সেশন - ব্যবহারকারীর একটি সক্রিয় অধিবেশন কখন ছিল এবং তাদের শেষ কার্যকলাপ কখন ছিল তা সংরক্ষণ করতে।
6. কার্যকলাপ অনুমোদন - একটি নির্দিষ্ট ব্যবহারকারীর দ্বারা সম্পাদিত একটি কার্যকলাপের জন্য অনুমোদনের অনুরোধগুলি সঞ্চয় করতে, যা প্রশাসক দ্বারা যাচাই করা হবে।

প্রমাণীকরণ সিস্টেমের জন্য উচ্চ-স্তরের নকশা

সিস্টেম এন্ডপয়েন্ট

প্রয়োজনীয়তা পূরণ

এখন, সমস্ত জিনিস ঠিক রেখে দেখা যাক কিভাবে আমরা সমস্ত প্রয়োজনীয়তা পূরণ করতে পারি।

নিবন্ধন

• প্রয়োজনীয়তা - যখন একজন নতুন ব্যবহারকারী আমাদের অ্যাপ্লিকেশন পরিদর্শন করে। আমাদের ব্যবহারকারীর বিশদ সঞ্চয় করতে হবে যাতে আমরা পরের বার যখন ব্যবহারকারীকে পরিদর্শন করি তখন আমরা অনুমোদন/শনাক্ত করতে পারি।
• পূরণ করা হয়েছে - যখন একজন নতুন ব্যবহারকারী অ্যাপ্লিকেশনটি পরিদর্শন করে এবং তাদের ইমেল এবং পাসওয়ার্ড সহ ব্যবহারকারীর বিবরণ প্রবেশ করে। যে ডাটাবেসে ক্যাপচার করা হবে. ব্যবহারকারীর বিবরণ ব্যবহারকারী টেবিলে সংরক্ষণ করা হবে। এবং পাসওয়ার্ডটি একটি এনক্রিপ্টেড আকারে শংসাপত্র টেবিলে সংরক্ষণ করা হবে।

প্রবেশ করুন

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

সেশন ম্যানেজমেন্ট

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

পাসওয়ার্ড পুনরুদ্ধার

• প্রয়োজনীয়তা - যখন একজন ব্যবহারকারী তাদের পাসওয়ার্ড ভুলে যায়, তখন তাদের নিরাপদে তাদের পাসওয়ার্ড রিসেট করতে সক্ষম হতে হবে।
• পূরণ করা হয়েছে - যখন ব্যবহারকারী তাদের পাসওয়ার্ড ভুলে যায়, তারা ভুলে যাওয়া পাসওয়ার্ড পৃষ্ঠায় তাদের ইমেল ঠিকানা জমা দিতে পারে এবং আমরা একটি এককালীন কোড তৈরি করব এবং তাদের ইমেলে লিঙ্কটি পাঠাব। ব্যবহারকারী কোড এবং ইমেল ঠিকানা সহ এই লিঙ্কে ক্লিক করলে। আমরা নিরাপদে সনাক্ত করতে সক্ষম হব যে পাসওয়ার্ড পুনরুদ্ধারের অনুরোধটি খাঁটি। এবং ব্যবহারকারীকে তাদের নতুন পাসওয়ার্ড সেট করার জন্য প্রদান করুন। এবং এইভাবে পাসওয়ার্ড পুনরুদ্ধার করতে সক্ষম হচ্ছে.

প্রবেশাধিকার নিয়ন্ত্রণ

• প্রয়োজনীয়তা - যখন একজন ব্যবহারকারী একটি নির্দিষ্ট ক্রিয়া সম্পাদন করে, তখন আমাদের নিশ্চিত করতে হবে যে ব্যবহারকারী সেই ক্রিয়াটি সম্পাদন করার জন্য প্রমাণীকৃত হয়েছে এবং শুধুমাত্র তখনই ক্রিয়াটি ঘটতে দেয়৷
• পরিপূর্ণ - আমরা ক্রিয়াগুলির একটি তালিকা বজায় রাখব, আসুন 1-12 বলি, সরলতার জন্য। প্রতিটি ব্যবহারকারীর জন্য আমরা সেই ব্যবহারকারীর জন্য প্রমাণীকৃত ক্রিয়াগুলি বজায় রাখব। তাই এখন বলা যাক ব্যবহারকারী একটি অ্যাকশন #id 4 করার চেষ্টা করে। ব্যবহারকারীর কাছে অ্যাকশন 4 করার অনুমতি আছে কিনা তা আমরা পরীক্ষা করব। যদি হ্যাঁ, আমরা এগিয়ে যাব এবং অনুরোধটি সম্পূর্ণ করব। অন্যথায় আমরা দেখাই যে অনুমতির অভাবের কারণে অনুরোধটি সফল হয়নি।

নিরীক্ষা পথ

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

কর্মক্ষমতা

• প্রয়োজনীয়তা - ক্ষমতা অনুমান বিভাগে আলোচনা করা কর্মক্ষমতার জন্য প্রয়োজন, প্রতি মাসে 0.04 অনুরোধ/সেকেন্ড এবং 100k অনুরোধ।
• পূরণ করা হয়েছে - আমরা ইতিমধ্যে সক্ষমতা অনুমান বিভাগে যথেষ্ট সার্ভারের সাথে প্রয়োজনীয়তা পরিচালনা করেছি।

উপসংহার

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