HTTP প্রকাশনাকে অ্যাপ্লিকেশন সম্পাদন এবং স্থায়ী ডেটা থেকে আলাদা করুন। একটি রিভার্স প্রক্সি রাউটিং এবং সীমা সংগঠিত করতে পারে, কিন্তু অরিজিন অ্যাক্সেস, অ্যাপ্লিকেশন অনুমোদন, আপস্ট্রিম ক্ষমতা এবং পুনরুদ্ধারের প্রত্যেকটির নিজস্ব নিয়ন্ত্রণ প্রয়োজন।
একটি ওয়েব অনুরোধ 여러 দায়িত্ব অতিক্রম করে
একটি ওয়েব সার্ভার HTTP অনুরোধ গ্রহণ করে এবং স্থির ফাইল পরিবেশন করতে পারে। একটি অ্যাপ্লিকেশন প্রক্রিয়া প্রকল্পের গতিশীল আচরণ সম্পাদন করে, যেমন একটি অ্যাকাউন্ট পরীক্ষা করা বা একটি ডেটাবেস কোয়েরি করা। একটি রিভার্স প্রক্সি সেই প্রক্রিয়ার পক্ষ থেকে অনুরোধ গ্রহণ করে এবং সেগুলি একটি আপস্ট্রিমে ফরওয়ার্ড করে। একটি প্রোগ্রাম একাধিক ভূমিকা পূরণ করতে পারে, কিন্তু দায়িত্বগুলি আলাদা করলে কনফিগারেশন এবং পুনরুদ্ধার সম্পর্কে চিন্তা করা সহজ হয়।
হোস্টনেম রেজোলিউশন থেকে প্রতিক্রিয়া পর্যন্ত একটি অনুরোধ ট্রেস করুন। TLS কোথায় শেষ হয়, কোন প্রক্রিয়া রুট নির্বাচন করে এবং কোন উপাদান অ্যাপ্লিকেশন ডেটা পড়তে পারে তা রেকর্ড করুন। একটি প্রশাসনিক অনুরোধের জন্যও একই কাজ করুন। এই অনুশীলনটি প্রায়শই একটি লিসেনার বা হোস্টনেম প্রকাশ করে যা পরীক্ষার জন্য তৈরি করা হয়েছিল এবং ভুলবশত পৌঁছানোর যোগ্য রয়ে গেছে। ডায়াগ্রামটি আপনার তৈরি করার আশা করা আর্কিটেকচারের পরিবর্তে স্থাপন করা পথ বর্ণনা করা উচিত।
HTTP আচরণ সংগঠিত করতে এজ ব্যবহার করুন
NGINX স্থির বিষয়বস্তু পরিবেশন এবং আপস্ট্রিমে অনুরোধ ফরওয়ার্ড উভয়ই নথিভুক্ত করে। এর ওয়ার্কার আর্কিটেকচার এবং HTTP মডিউল কনফিগারেশন প্রক্রিয়া প্রদান করে, কিন্তু একটি নির্দিষ্ট কনফিগারেশন এখনও আচরণ নির্ধারণ করে। হোস্টনেম, আপস্ট্রিম এবং ফাইলসিস্টেম রুট সচেতনভাবে সংজ্ঞায়িত করুন। পরিবেশন করা যায় এমন ফাইলগুলি সীমাবদ্ধ করুন যাতে কনফিগারেশন, শংসাপত্র এবং রিপোজিটরি মেটাডেটা কখনও ডাউনলোডযোগ্য না হয় কারণ সেগুলি অ্যাপ্লিকেশনের কাছে অবস্থিত।
অ্যাপ্লিকেশন অনুযায়ী অনুরোধ বডি, টাইমআউট এবং সংযোগের জন্য উপযুক্ত সীমা নির্ধারণ করুন। ক্যাশেকে একটি ডেটা সিদ্ধান্ত হিসাবে বিবেচনা করুন: একটি ব্যবহারকারী বা অনুমতির সাথে আবদ্ধ বিষয়বস্তু পর্যালোচনা ছাড়া একটি ভাগ করা ক্যাশিং নিয়ম নিরাপদে উত্তরাধিকারী হতে পারে না। প্রমাণীকরণ এবং ক্যাশ আচরণ একসাথে পরীক্ষা করুন। একটি পুনরুত্পাদনযোগ্য কনফিগারেশন রাখুন এবং পরিষেবা পুনরায় লোড করার আগে পরিবর্তনগুলি যাচাই করুন, পূর্ববর্তী কার্যকর সংস্করণে ফিরে যাওয়ার একটি পরিচিত পথ সহ।
| স্তর | উপযোগী দায়িত্ব | লঞ্চের আগে পরীক্ষা করুন |
|---|---|---|
| পাবলিক ওয়েব এজ | TLS, হোস্টনেম রাউটিং এবং HTTP সীমা | শংসাপত্র, রুট এবং উদ্দিষ্ট হোস্টনেম |
| অ্যাপ্লিকেশন প্রক্রিয়া | ব্যবসায়িক লজিক এবং অনুমোদন | প্রমাণীকরণ, ইনপুট পরীক্ষা এবং নির্ভরতা ব্যর্থতা |
| অভ্যন্তরীণ ডেটা পরিষেবা | স্থায়ী অ্যাপ্লিকেশন অবস্থা | সীমাবদ্ধ অ্যাক্সেস এবং পরীক্ষিত পুনরুদ্ধার |
| আপস্ট্রিম প্রদানকারী নেটওয়ার্ক | চুক্তিবদ্ধ নেটওয়ার্ক পরিষেবা | সুরক্ষা সুযোগ এবং এস্কেলেশন পথ |
একটি রিভার্স প্রক্সি অরিজিনের এক্সপোজার দূর করে না
যদি অরিজিন সর্বজনীনভাবে অ্যাক্সেসযোগ্য থাকে, তাহলে একটি ক্লায়েন্ট উদ্দিষ্ট প্রক্সি রুট ব্যবহার না করে এটিতে পৌঁছাতে পারে। যখন স্থাপনার সেই সীমানা প্রয়োজন হয় তখন নেটওয়ার্ক ডিজাইন এবং অ্যাপ্লিকেশন কনফিগারেশনের মাধ্যমে অরিজিন অ্যাক্সেস সীমাবদ্ধ করুন। একটি মেশিনে, একটি ব্যাকএন্ড প্রায়শই লুপব্যাক বা একটি স্থানীয় সকেটে শুনতে পারে। মেশিন জুড়ে, স্পষ্ট সীমাবদ্ধ রুট এবং আপস্ট্রিম সংযোগের জন্য উপযুক্ত সুরক্ষা ব্যবহার করুন।
ফরওয়ার্ডেড হেডারগুলিরও একটি বিশ্বাস নিয়ম প্রয়োজন। মূল ক্লায়েন্ট সম্পর্কে তথ্য শুধুমাত্র বিশ্বস্ত মধ্যস্থতাকারীদের কাছ থেকে গ্রহণ করুন, এবং নির্বিচারে কলকারীদের এমন মান সরবরাহ করতে বাধা দিন যা অ্যাপ্লিকেশন প্রামাণিক হিসাবে বিবেচনা করে। অ্যাক্সেস লগ এবং ত্রুটি প্রতিবেদনে কী প্রদর্শিত হয় তা নির্ধারণ করুন। একটি প্রক্সি প্রতিটি স্তরে উপলব্ধ তথ্য পরিবর্তন করতে পারে; এটি অ্যাকাউন্ট শনাক্তকারী মুছে ফেলে না বা অ্যাপ্লিকেশনকে তার নিজের অপারেটরের কাছে বেনামী করে না।
অ্যাপ্লিকেশনের ভিতরে অ্যাক্সেস সিদ্ধান্ত প্রয়োগ করুন
NIST-এর জিরো ট্রাস্ট আর্কিটেকচার শুধুমাত্র নেটওয়ার্ক অবস্থানের উপর ভিত্তি করে অন্তর্নিহিত বিশ্বাসের পরিবর্তে সম্পদের জন্য অ্যাক্সেস সিদ্ধান্তের উপর দৃষ্টি নিবদ্ধ করে। সেই নীতিটি সুনির্দিষ্টভাবে প্রয়োগ করুন: কলকারীকে প্রমাণীকরণ করুন, অনুরোধকৃত অপারেশন অনুমোদন করুন এবং পরিষেবা অ্যাকাউন্টগুলিকে শুধুমাত্র তাদের প্রয়োজনীয় সুযোগ দিন। একটি অভ্যন্তরীণ সাবনেট থেকে আসা একটি অনুরোধ স্বয়ংক্রিয়ভাবে প্রশাসক অনুরোধ হওয়া উচিত নয়।
যেখানে ব্যবহারিক সেখানে পাবলিক এবং প্রশাসনিক কার্যাবলী আলাদা করুন। শুধুমাত্র প্রাথমিক লগইনের উপর নির্ভর না করে যখন একজন ব্যবহারকারী একটি রেকর্ড অ্যাক্সেস করেন তখন অনুমতি পুনরায় পরীক্ষা করুন। প্রক্সি, অ্যাপ্লিকেশন এবং ডেটাবেসের জন্য শংসাপত্র আলাদা রাখুন। এমন পর্যায়ে পরিবর্তনগুলি প্রবর্তন করুন যা পরীক্ষা করা যায়, একটি সংকীর্ণ সংবেদনশীল পথ দিয়ে শুরু করে। একটি স্থাপনাকে জিরো ট্রাস্ট বলা তার জন্য দায়ী উপাদানে একটি নিষিদ্ধ ক্রিয়া প্রকৃতপক্ষে অস্বীকার করা প্রদর্শনের চেয়ে কম উপযোগী।
একাধিক স্তরে ডিনায়াল অফ সার্ভিস পরিকল্পনা করুন
একটি সম্পৃক্ত নেটওয়ার্ক লিঙ্ক এবং একটি ব্যয়বহুল অ্যাপ্লিকেশন অনুরোধ বিভিন্ন জায়গায় ব্যর্থ হয়। ওয়েব এজে রেট সীমাবদ্ধতা অনুরোধের ধরণগুলি সীমাবদ্ধ করতে সহায়তা করতে পারে, যখন অ্যাপ্লিকেশন সীমা অনুসন্ধান, আপলোড বা রপ্তানির মতো কাজ সীমাবদ্ধ করতে পারে। NGINX-এর অনুরোধ-সীমা মডিউল একটি প্রক্রিয়া সরবরাহ করে; কী এবং থ্রেশহোল্ডগুলি প্রকৃত ব্যবহারকারীদের সাথে মানানসই হতে হবে এবং বৈধ ট্রাফিক প্রত্যাখ্যান এড়াতে পরীক্ষা করতে হবে।
OWASP-এর ডিনায়াল-অফ-সার্ভিস নির্দেশিকা অ্যাপ্লিকেশন আচরণে সম্পদ নিঃশেষণও সম্বোধন করে। ব্যয়বহুল কাজের চারপাশে সময় এবং আকারের সীমা রাখুন, সীমাবদ্ধ সারি ব্যবহার করুন এবং ব্যর্থতার সংকেত নিরীক্ষণ করুন। স্থানীয় নিয়ন্ত্রণগুলি ইতিমধ্যে সম্পৃক্ত একটি আপস্ট্রিম লিঙ্কে ক্ষমতা তৈরি করতে পারে না। নির্বাচিত অফারে অন্তর্ভুক্ত নির্দিষ্ট নেটওয়ার্ক সুরক্ষা নিশ্চিত করুন এবং একটি এস্কেলেশন পথ প্রস্তুত করুন। একটি ক্যাটালগের Layer 3–4 সুরক্ষা প্রতিটি HTTP ওয়ার্কলোডের জন্য সুরক্ষাও প্রমাণ করে বলে কখনও ধরে নেবেন না।
পুনরুদ্ধারকে প্রকাশনার অংশ করুন
এর উদ্দিষ্ট হোস্টনেম ব্যবহার করে একটি বাহ্যিক ক্লায়েন্ট থেকে সাইটটি পরীক্ষা করুন। HTTPS, রিডাইরেক্ট, স্থির সম্পদ, লগইন এবং একটি প্রতিনিধি অ্যাপ্লিকেশন লেনদেন যাচাই করুন। প্রশাসনিক লিসেনার এবং ব্যক্তিগত ফাইলগুলি অ্যাক্সেসযোগ্য না থাকে তা নিশ্চিত করুন। একটি বন্ধ আপস্ট্রিম অনুকরণ করুন এবং পরীক্ষা করুন যে এজটি অভ্যন্তরীণ বিবরণ প্রকাশ না করে বা সীমা ছাড়া অপেক্ষা না করে একটি নিয়ন্ত্রিত ব্যর্থতা ফেরত দেয়।
Canvas-এর জন্য, হোস্টিং অ্যাকাউন্টের মধ্যে উপলব্ধ নিয়ন্ত্রণগুলি পড়ুন। একটি VPS-এর জন্য, আপনার নিজের অপারেটিং পরিকল্পনার অংশ হিসাবে ওয়েব এজ এবং অ্যাপ্লিকেশন বজায় রাখুন। একটি বড় নেটওয়ার্ক পোর্ট একটি ক্ষমতা স্পেসিফিকেশন, অ্যাপ্লিকেশনটি সেই থ্রুপুট বজায় রাখতে পারে তার প্রমাণ নয়। রানবুকে পর্যবেক্ষণ, পুনরুদ্ধার এবং প্রদানকারীর পরিচিতি রাখুন। প্রকৃত অনুরোধ পথ এবং একটি ব্যবহারিক পুনরুদ্ধার পথ যাচাই করার পরেই প্রকাশ করুন।
আপনার ব্যবহারিক চেকলিস্ট।
- একটি পাবলিক এবং একটি প্রশাসনিক অনুরোধ ট্রেস করুন।
- পরিবেশিত রুট এবং আপস্ট্রিম লিসেনার সংজ্ঞায়িত করুন।
- শুধুমাত্র অনুমোদিত মধ্যস্থতাকারীদের কাছ থেকে ফরওয়ার্ডেড হেডার বিশ্বাস করুন।
- অনুমোদন এবং ক্যাশ সীমানা পরীক্ষা করুন।
- নেটওয়ার্ক এবং অ্যাপ্লিকেশন ব্যর্থতার জন্য সীমা এবং এস্কেলেশন প্রস্তুত করুন।
যে বিবরণগুলো গুরুত্বপূর্ণ।
একটি ওয়েব সার্ভার কি রিভার্স প্রক্সি হিসাবেও কাজ করতে পারে?+
হ্যাঁ। NGINX একটি নথিভুক্ত উদাহরণ। এর ভূমিকা কনফিগারেশনের উপর নির্ভর করে, এবং অ্যাপ্লিকেশনের এখনও নিজস্ব অনুমোদন এবং রক্ষণাবেক্ষণ প্রয়োজন।
একটি রিভার্স প্রক্সি কি স্বয়ংক্রিয়ভাবে অরিজিন লুকায়?+
না। রাউটিং, ফায়ারওয়াল এবং লিসেনার সেটিংস উদ্দিষ্ট সীমানা প্রয়োগ না করলে অরিজিন পৌঁছানোর যোগ্য থাকতে পারে।
অনুরোধ সীমাবদ্ধতা কি প্রতিটি DDoS আক্রমণ বন্ধ করবে?+
না। এটি নির্বাচিত HTTP অনুরোধের ধরণগুলি সম্বোধন করে। নেটওয়ার্ক সম্পৃক্ততা এবং অন্যান্য সম্পদ ব্যর্থতার জন্য উপযুক্ত আপস্ট্রিম এবং অ্যাপ্লিকেশন নিয়ন্ত্রণ প্রয়োজন।
সূত্রে যান।
এই রেফারেন্সগুলি এই গাইডের প্রযুক্তিগত ধারণাগুলি সমর্থন করে। একটি উৎপাদন সিস্টেম পরিবর্তন করার আগে বর্তমান ডকুমেন্টেশন অনুসরণ করুন।
- NGINX: শিক্ষানবিস গাইড nginx.org
- NGINX: HTTP অনুরোধ সীমাবদ্ধতা nginx.org
- NIST SP 800-207: জিরো ট্রাস্ট আর্কিটেকচার nvlpubs.nist.gov
- OWASP: ডিনায়াল অফ সার্ভিস প্রতিরোধ cheatsheetseries.owasp.org
SwissOctet দ্বারা সম্পাদকীয় নির্দেশনা। উদাহরণগুলি উদাহরণমূলক। সেবা স্পেসিফিকেশন, উপলব্ধ অপশন এবং চুক্তিভিত্তিক শর্তগুলি আলাদাভাবে যাচাই করতে হবে।