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

দুটি দাবি, এবং তাদের একটি কেবল দর্শনার্থীর কাছে শুরু হয়

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

দ্বিতীয় দাবিটি একটি উপাদান সম্পর্কে: গেটওয়ে বা তার পেছনের অ্যাপ্লিকেশন প্রক্রিয়াটি অন্য কারও নিয়ন্ত্রণে আছে ধরা হয়। সেই অনুমান থেকে প্রশ্নটি বদলে যায়—কোন URL অনুমোদিত তা থেকে কোন গন্তব্য ও পরিচয় পর্যন্ত প্রক্রিয়াটি এখনো পৌঁছাতে পারে তা-তে।

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

একটি কাজ করা খরচ সেবা, এবং এটি হারানোর দুই উপায়

একটি খরচ সেবা ধরুন: 10.60.4.10-তে একটি পাবলিক গেটওয়ে কর্মীদের প্রমাণীকরণ করে এবং অনুমোদিত অনুরোধ 8443 পোর্টের একটি অ্যাপ্লিকেশন লিসেনারে পাঠায়, এবং সেই অ্যাপ্লিকেশনটি expenses_app ভূমিকায় 10.60.4.20:5432-তে একটি PostgreSQL লিসেনারে পৌঁছায়। কর্মীরা সাধারণ অভ্যন্তরীণ প্রবেশ পাওয়ার জন্য নয়। স্বাভাবিক পরিচালনায় নকশাটি সত্যিই ডেটাবেস লিসেনার কোথাও প্রকাশ না করেই অ্যাপ্লিকেশন-নির্দিষ্ট প্রবেশ দেয়। ঠিকানাগুলো গুরুত্বপূর্ণ, কারণ এই নিবন্ধের পরের প্রতিটি পরীক্ষা তাদের নাম নেয়।

এখন গেটওয়েটিকে বিশ্বস্ত সেট থেকে সরান। 10.60.4.10-এর প্রক্রিয়া আক্রমণকারীর হলে সেটি কোন গন্তব্যে পৌঁছাতে পারে? দর্শনার্থীদের সীমিত করা URL ফিল্টার গেটওয়ে হোস্টের ডেটাবেস সাবনেটের দিকে খোলা সংযোগ সম্পর্কে কিছুই বলে না।

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

প্রতিটি পক্ষের প্রকৃত ক্ষমতা মানচিত্রে আঁকুন

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

ComponentAuthority it actually holdsCheck that proves the denialOwner of the check
Identity providerIssues assertions and session cookies, and holds no network path of its ownA request to the application URL without a session is redirected to the login pageIdentity team
Public gateway hostTCP reachability to whatever its routing table and egress rules permitAn egress rule drops 10.60.4.20:5432 and the probe reports the port filteredNetwork platform team
Application roleSQL privileges granted to expenses_app inside the expenses databaseA privilege query shows no ownership or create right on any other schemaApplication team
Database listenerAccepts connections only from the source ranges named in its host-based rulesA connection from an unlisted address is refused before authenticationDatabase administrator
Management pathAdministrative access reserved for patching, monitoring and recoveryA staff workstation cannot reach the administrative port or jump through itPlatform owner

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

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

গেটওয়ে কী কী পৌঁছাতে পারে তা দাবি না করে গণনা করুন

সীমার দাবি ততটুকুই ভালো যতটা তার পেছনের গণনা। গেটওয়ে হোস্টে তিনটি কমান্ড রুট নির্বাচন, জীবন্ত প্রোব ও ইগ্রেস নীতি ঢেকে দেয়:

ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter output

আউটপুট সেই ক্রমে পড়ুন। রুট বলে 10.60.4.20 আদৌ সেই হোস্ট থেকে নির্বাচিত হয় কি না; প্রোব বলে লিসেনার উত্তর দেয় কি না; নিয়মের তালিকা দেখায় নীতি প্যাকেট থামায়, নাকি তার পথে কখনো কিছুই ছিল না।

অ্যাপ্লিকেশন হোস্ট থেকে গণনাটি পুনরাবৃত্তি করুন। সেখান থেকে ডেটাবেসের দিকটি অ্যাপ্লিকেশন ভূমিকায় চালানো একটি কোয়েরি:

psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'

অন্য স্কিমা পড়তে পারে না এমন ভূমিকার অধীনে সফল সংযোগ, মালিক ভূমিকার অধীনে সফল সংযোগ থেকে ভিন্ন ফলাফল। কেবল দ্বিতীয়টিই একটি অনুসন্ধান।

প্রত্যাখ্যানগুলো লিপিবদ্ধ করুন, তারপর পর্যালোচনার তারিখ দিন

গ্রহণযোগ্যতা উদ্দেশ্য নয়, ফলাফল হিসেবে লেখা হয়: কর্মীর সেশন লিসেনারে পৌঁছাতে পারে না, গেটওয়ে হোস্ট অসম্পর্কিত সাবনেটে পৌঁছাতে পারে না, এবং অ্যাপ্লিকেশন ভূমিকা ডেটাবেস তৈরি করতে পারে না। প্রত্যেকটি নামকৃত মালিক ও তারিখসহ আলাদা পরীক্ষা।

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

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

সম্পর্কিত নিবন্ধ