Least Privilege নীতি, ব্যাখ্যা করা

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

এটি আসলে কী অর্থ করে

Least privilege নীতি (PoLP) বলে যে একটি সিস্টেমের প্রতিটি সাবজেক্ট — একটি ব্যবহারকারী, একটি সেবা অ্যাকাউন্ট, একটি অ্যাপ্লিকেশন, একটি কন্টেইনার — তার কাজ সম্পূর্ণ করার জন্য প্রয়োজনীয় সর্বনিম্ন অনুমতির সেট নিয়ে কাজ করা উচিত। যে অনুমতিগুলি সুবিধাজনক নয়। যে অনুমতিগুলি কেউ তিন বছর আগে দিয়েছিল এবং প্রত্যাহার করতে ভুলেছে তা নয়। সর্বনিম্ন।

এটি প্রতিটি স্তরে প্রযোজ্য: ফাইল সিস্টেম অনুমতি, ডাটাবেস ভূমিকা, API স্কোপ, ক্লাউড IAM নীতি, ফায়ারওয়াল নিয়ম, sudo অ্যাক্সেস। একটি ওয়েব সার্ভার প্রক্রিয়া যা স্ট্যাটিক ফাইল পড়ছে তার /etc এ লেখার অ্যাক্সেসের প্রয়োজন নেই। একটি রিপোর্টিং স্ক্রিপ্ট যা শুধুমাত্র SELECT কোয়েরি চালায় তার DROP TABLE অধিকার সহ একটি ডাটাবেস ভূমিকার প্রয়োজন নেই। একজন মার্কেটিং ইন্টার্ন কে ডোমেইন অ্যাডমিন অ্যাক্সেসের প্রয়োজন নেই শুধুমাত্র কারণ এটি সঠিক গ্রুপ খুঁজে বের করার চেয়ে সহজ ছিল।

এটি যে পরিমাণ গুরুত্বপূর্ণ বলে মনে হয় তার চেয়ে বেশি কেন গুরুত্বপূর্ণ

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

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

এটি অনুশীলনে কোথায় দেখা যায়

ক্লাউড IAM। AWS, Azure এবং GCP সবই যদি আপনি সাবধান না হন তবে প্রশস্ত আচরণের ডিফল্ট করে — একটি IAM নীতি "Action": "*" এবং "Resource": "*" সহ যাচাইকরণ পাস করবে এবং ভাল কাজ করবে, যতক্ষণ না একটি লিক হওয়া অ্যাক্সেস কী একজন আক্রমণকারীকে সম্পূর্ণ অ্যাকাউন্ট নিয়ন্ত্রণ দেয়। ওয়াইল্ডকার্ডে পৌঁছানোর পরিবর্তে নীতিগুলি নির্দিষ্ট অ্যাকশন এবং রিসোর্স ARN-এ স্কোপ করুন।

সেবা অ্যাকাউন্ট। এগুলি প্রায়শই সবচেয়ে খারাপ অপরাধী কারণ কেউ তাদের মানব অ্যাকাউন্টগুলির মতো পর্যালোচনা করে না। একটি CI/CD পাইপলাইন যা একটি S3 বাকেটে স্থাপন করে তার অ্যাকাউন্টে প্রতিটি বাকেট পড়তে পারে এমন শংসাপত্র ধারণ করা উচিত নয়।

ডাটাবেস ভূমিকা। শুধুমাত্র-পড়া রিপোর্টিং ভূমিকাগুলিকে অ্যাপ্লিকেশন ভূমিকাগুলি থেকে আলাদা করুন যার INSERT/UPDATE প্রয়োজন, এবং সেগুলিকে DBA ভূমিকা থেকে আলাদা করুন যা স্কিমা পরিবর্তন করতে পারে। PostgreSQL এবং MySQL উভয়ই বিস্তারিত GRANT বিবৃতি সমর্থন করে — প্রতিটি অ্যাপ সংযোগকে রুটের সমতুল্য দেওয়ার পরিবর্তে সেগুলি ব্যবহার করুন।

Sudo এবং স্থানীয় অ্যাডমিন। Just-in-time উন্নয়ন (অ্যাক্সেস অনুরোধ করুন, এটি একটি সীমিত উইন্ডোর জন্য পান, স্বয়ংক্রিয়ভাবে এটি হারান) দাঁড়ানো অ্যাডমিন অধিকারের চেয়ে সর্বদা ভাল। সময়-সীমিত নিয়ম সহ sudo এর মতো সরঞ্জাম, বা এন্টারপ্রাইজ পরিবেশে PAM সমাধান, এই নির্দিষ্টভাবে উপস্থিত।

এর সাথে উত্তেজনা