মাল্টি-সাইট নেটওয়ার্কের জন্য RADIUS-as-a-Service নির্দেশিকা
Published
হোটেলের গেস্ট নেটওয়ার্ক কাজ করে, কিন্তু স্টাফ SSID-এর জন্য প্রতিটি প্রোপার্টিতে একটি ভিন্ন শেয়ার্ড পাসওয়ার্ড রয়েছে, একটি টিল ভুল VLAN-এ চলে গেছে, এবং প্রাক্তন কোনো ঠিকাদারের ডিভাইসে এখনও অ্যাক্সেস আছে কিনা তা কেউ নিশ্চিত করতে পারছে না। নেটওয়ার্ক টিম স্থানীয়ভাবে প্রতিটি সমস্যা সমাধান করতে পারে, তবে স্থান, ফ্লোর এবং অ্যাক্সেস পয়েন্ট প্ল্যাটফর্ম জুড়ে একই কাজ বারবার ফিরে আসে।
RADIUS as a Service অ্যাক্সেস পয়েন্ট, সুইচ এবং কন্ট্রোলারগুলিকে বলবৎ করার সুযোগ দিয়ে হোস্ট করা প্ল্যাটফর্মে প্রমাণীকরণের সিদ্ধান্তগুলি স্থানান্তর করে। এটি একটি বিতরণ করা এস্টেট জুড়ে নীতি সহজ করতে পারে, তবে এটি নেটওয়ার্ককে WAN, পরিচয় প্রদানকারী বা সার্টিফিকেট পরিকাঠামো থেকে স্বাধীন করে তোলে না। একটি সঠিক মূল্যায়ন একটি SLA আছে কিনা তার চেয়ে কঠিন প্রশ্ন দিয়ে শুরু হয়: একটি নির্ভরতা ব্যর্থ হলে প্রতিটি শ্রেণীর ব্যবহারকারী এবং ডিভাইসের কী হবে?
সূচিপত্র
- কেন নেটওয়ার্কের সিদ্ধান্তগুলো কেন্দ্রীভূত করা সবকিছু পরিবর্তন করে দেয়
- আধুনিক হোস্ট করা RADIUS-এর পেছনের উৎপত্তি এবং মানসমূহ
- একটি RADIUS-as-a-Service আর্কিটেকচার প্রকৃতপক্ষে কীভাবে কাজ করে
- অন-প্রিমাইস ডেপ্লয়মেন্টের সাথে হোস্ট করা RADIUS-এর তুলনা
- SLA, মাল্টি-রিজিয়ন ফেলওভার এবং প্রকৃতপক্ষে কী সমস্যা তৈরি হয়
- নিরাপত্তা, কমপ্লায়েন্স এবং লেগ্যাসি RADIUS থেকে মাইগ্রেশন
- একটি হোস্ট করা RADIUS সেবা নির্বাচন এবং প্রয়োগ করা
কেন নেটওয়ার্কের সিদ্ধান্তগুলি কেন্দ্রীভূত করা সবকিছু বদলে দেয়
একটি হোটেল চেইনে একটি পরিচিত প্যাটার্ন হলো একটি গেস্ট SSID যা সময়ের সাথে সাথে বৃদ্ধি পেয়েছে, টিমগুলির মধ্যে কর্মীদের ক্রেডেনশিয়াল আদান-প্রদান করা হয়েছে, এবং সেই ফ্লোরে শেষ যে কাজ করেছে তার উপর ভিত্তি করে সুইচ পোর্টগুলি কনফিগার করা হয়েছে। সমস্যাটি কেবল কনফিগারেশনের অনিয়ন্ত্রিত বিস্তার নয়। সমস্যা হলো যে লোকাল ডিভাইসগুলি অ্যাক্সেস পলিসির কিছু অংশ ধরে রাখে, তাই একটি প্রপার্টিতে করা পরিবর্তন অন্য প্রপার্টির পরিবর্তনের সাথে নাও মিলতে পারে।
RADIUS সিদ্ধান্তসমূহ কেন্দ্রীয়করণ করার একটি উপায় প্রদান করে। একটি অ্যাক্সেস পয়েন্ট বা নেটওয়ার্ক অ্যাক্সেস সার্ভার একটি শেয়ার্ড সার্ভিসে প্রমাণীকরণের অনুরোধ পাঠায়, যা পরিচয় যাচাই করে এবং অ্যাক্সেসের সিদ্ধান্ত প্রদান করে। নেটওয়ার্ক ডিভাইসটি সেই সিদ্ধান্ত প্রয়োগ করে, তবে অপারেটর প্রতিটি কন্ট্রোলার বা সুইচে নিয়মের পুনরাবৃত্তি করার পরিবর্তে কেন্দ্রীয়ভাবে পরিচয় এবং নীতি পরিচালনা করতে পারেন।
সেই বিভাজনটি হোস্ট করা RADIUS এর পিছনের মূল ধারণা। একটি কেন্দ্রীয় পরিষেবা এমন বৈশিষ্ট্যগুলি ফিরিয়ে দিতে পারে যা একজন কর্মী, অতিথি, ঠিকাদার বা ডিভাইসকে একটি উপযুক্ত নেটওয়ার্ক বা VLAN এর সাথে মানচিত্র করে। যখন কেউ চলে যায়, স্থানীয় সেটিংস আপডেট করার জন্য প্রতিটি ভেন্যুর ওপর নির্ভর করার বদলে একটি কেন্দ্রীয়ভাবে পরিচালিত identity বাতিল করা যেতে পারে। Accounting রেকর্ডগুলি অপারেটরদের কোন identity একটি নেটওয়ার্ক ব্যবহার করেছে এবং কখন তা তদন্ত করতে সহায়তা করতে পারে।
পেজার এখনও গুরুত্বপূর্ণ
সেন্ট্রালাইজেশন কিছু ধরনের অপারেশনাল কাজ কমায়, কিন্তু এটি নেটওয়ার্ক ডিজাইনের দায়িত্ব দূর করে না। হোস্ট করা সার্ভিসটি একটি ভুল আইডেন্টিটি রেকর্ড, একটি ভুলভাবে ম্যাপ করা VLAN, বা একটি অ্যাক্সেস পয়েন্ট যা তার কনফিগার করা এন্ডপয়েন্টে পৌঁছাতে পারে না তা সংশোধন করতে পারে না। কোনো ব্র্যাঞ্চ কানেক্টিভিটি হারালে কোন ডিভাইসগুলির অ্যাক্সেস রাখা উচিত তাও এটি স্বয়ংক্রিয়ভাবে নির্ধারণ করে না।
পেজার বহনকারী ব্যক্তির জন্য, পরিবর্তনটি হলো স্থানীয় প্রমাণীকরণ সার্ভার এবং নীতিগুলি রক্ষণাবেক্ষণ করা থেকে একটি শেয়ার্ড সার্ভিসের নির্ভরতা এবং ব্যর্থতার আচরণ পরিচালনা করা। এর মধ্যে রয়েছে পৌঁছানোর ক্ষমতা পরীক্ষা করা, ফেরত দেওয়া বৈশিষ্ট্যগুলি যাচাই করা, অ্যাকাউন্টিং পর্যবেক্ষণ করা এবং বিভ্রাটের সময় কী হওয়া উচিত সে বিষয়ে একমত হওয়া।
অপারেটিং নিয়ম: রুটিন নীতি কেন্দ্রীভূত করুন, তবে প্রতিটি ব্যবহারকারী এবং ডিভাইস গ্রুপের জন্য ব্যর্থতার নীতি স্পষ্ট করুন।
একজন অতিথির সেশন, স্টাফ ল্যাপটপ, টিল, ক্যামেরা এবং বিল্ডিং সেন্সরের একই ফলব্যাকের প্রয়োজন নেই। এগুলিকে একটি সাধারণ "WiFi" জনসংখ্যা হিসাবে বিবেচনা করলে একটি প্রমাণীকরণ বিভ্রাটকে ব্যবসায়িক বাধা বা এড়ানো যায় এমন নিরাপত্তা ব্যতিক্রমে পরিণত করতে পারে।
আধুনিক হোস্ট করা RADIUS-এর পেছনের উৎপত্তি এবং মানসমূহ
Merit Network, NSFNET-এ ডায়াল-আপ অ্যাক্সেসের জন্য একটি কেন্দ্রীভূত অথেনটিকেশন সিস্টেমের অনুরোধ জানানোর পর 1991 সালে RADIUS-এর যাত্রা শুরু হয়। Livingston Enterprises তাদের PortMaster নেটওয়ার্ক অ্যাক্সেস সার্ভারের জন্য প্রথম বাস্তবায়ন তৈরি করেছিল। যে ডিজাইন সিদ্ধান্তটি এখনও ডিপ্লয়মেন্টের রূপরেখা তৈরি করে তা হলো প্রতিটি ফাংশনের জন্য পৃথক স্বত্বাধিকারী সিস্টেমের পরিবর্তে একটি একক ক্লায়েন্ট-সার্ভার মডেলে অথেনটিকেশন, অথরাইজেশন, এবং অ্যাকাউন্টিং-কে একত্রিত করা। RADIUS ইতিহাস এবং প্রোটোকল পটভূমি
সেই বিভাজনটি সামঞ্জস্যতার চেয়েও বেশি গুরুত্বপূর্ণ। কারণ NAS/অ্যাটেনটিকেটর বিভাজনটি প্রোটোকলে নির্দিষ্ট, তাই একটি WAN বা আইডেন্টিটি-প্রোভাইডার বিভ্রাট কে শেয়ার্ড সার্ভারে পৌঁছাতে পারে তা পরিবর্তন করে, ভূমিকাগুলি পরিবর্তন করে না - এই কারণেই প্রোটোকল পছন্দ নয়, ফলব্যাক ডিজাইন নির্ধারণ করে যে ভেন্যুতে কী ঘটবে।
মানদণ্ডের রেকর্ড দেখায় কীভাবে মডেলটি ইন্টারঅপারেবল হয়ে উঠেছে। IETF প্রমাণীকরণের জন্য RFC 2058 এবং অ্যাকাউন্টিংয়ের জন্য RFC 2059 হিসাবে জানুয়ারী 1997-এ RADIUS নথিভুক্ত করেছিল। RFC 2138 এবং RFC 2139 সেই বছরের শেষের দিকে সেগুলিকে স্থলাভিষিক্ত করে, তারপরে 2000 সালে RFC 2865 এবং RFC 2866 আসে। প্রাথমিক স্থাপনাগুলি বড় পরিসরে সমস্যা তৈরি করার পর RFC 2865 প্রোটোকলটিকে আরও উন্নত করেছিল, যা একটি দরকারী অনুস্মারক যে এই স্পেসিফিকেশনটি পরিষ্কারভাবে তৈরি করার চেয়ে পরিচালনগত ব্যর্থতার মাধ্যমে পরিমার্জিত হয়েছিল। IETF RADIUS ওয়ার্কিং-গ্রুপ ডকুমেন্টস
কেন পুরোনো স্ট্যান্ডার্ডগুলো এখনও গুরুত্বপূর্ণ
একটি হোটেল গ্রুপ বা ভেন্যু অপারেটরের জন্য, অ্যাক্সেস ডিভাইস এবং authentication সার্ভারের মধ্যকার ব্যবধান বেশ উপযোগী থাকে। একজন প্রস্তুতকারকের একটি ওয়্যারলেস কন্ট্রোলার এবং অন্যটির সুইচগুলি একটি সাধারণ নীতি পরিষেবাতে অনুরোধ পাঠাতে পারে, যদি তারা সামঞ্জস্যপূর্ণ RADIUS আচরণ বাস্তবায়ন করে। একটি বিক্রেতার সম্পূর্ণ অ্যাক্সেস-নিয়ন্ত্রণ স্ট্যাক না কিনেও কেন্দ্রীভূত identity এবং অ্যাক্সেসের সিদ্ধান্ত নেওয়া সম্ভব হয়।
পোর্ট অ্যাসাইনমেন্টগুলি দেখায় কীভাবে স্ট্যান্ডার্ডের কাজ দৈনিক ক্রিয়াকলাপকে প্রভাবিত করে। প্রাথমিক বাস্তবায়নগুলিতে সাধারণত UDP পোর্ট 1645 ব্যবহার করা হতো, যেখানে UDP পোর্ট 1812, RFC 2865-এর অধীনে অথেনটিকেশনের জন্য আনুষ্ঠানিক অ্যাসাইনমেন্ট হয়ে ওঠে। যে সরঞ্জামগুলি এখনও ডিফোল্ট হিসাবে 1645 ব্যবহার করে সেগুলি 1812 প্রত্যাশাকারী হোস্ট করা এন্ডপয়েন্টের সাথে কাজ করতে ব্যর্থ হবে, তাই ফায়ারওয়াল, আঞ্চলিক এন্ডপয়েন্ট এবং মাইগ্রেশন প্ল্যান কনফিগার করার আগে প্রতিটি ডিভাইস কী সমর্থন করে তা পরীক্ষা করে নিন।
ট্রান্সপোর্ট সুরক্ষা একটি বর্তমান উদ্বেগের বিষয়। RFC 6614 ডিফল্ট গন্তব্য এবং অখণ্ডতা সুরক্ষা প্রয়োজনীয়তা হিসাবে TCP পোর্ট 2083 সহ TLS এর মাধ্যমে RADIUS বা RadSec কে সংজ্ঞায়িত করে। এটি সতর্কও করে যে TLS কানেকশন স্টেট এবং প্রসেসিং ঐতিহ্যবাহী UDP এর চেয়ে বেশি লোড তৈরি করতে পারে, তাই একটি সুরক্ষিত ডিজাইনের জন্য কানেকশন পুনরায় ব্যবহার, সীমাবদ্ধ পুনরায় চেষ্টা এবং সক্ষমতা পরিকল্পনা প্রয়োজন, কেবল একটি নতুন পোর্ট নয়। সেই লোড সতর্কতাটিকে একটি ব্যর্থতা-মোড প্রশ্ন হিসাবে বিবেচনা করুন: একটি এন্ডপয়েন্ট যা WAN ব্লিপের পরে একসাথে শত শত অ্যাক্সেস পয়েন্ট পুনরায় সংযোগ করার সময় নতি স্বীকার করে, সেটি ধীরে ধীরে অবনতি হওয়ার চেয়ে খারাপ। TLS এর মাধ্যমে RADIUS এর উপর RFC 6614
IETF-এর 2025 RFC 9813 TLS প্রি-শেয়ার্ড কী এবং RADIUS/UDP থেকে RADIUS/TLS-এ মাইগ্রেশনের জন্য অপারেশনাল বিবেচ্য বিষয়গুলি ডকুমেন্ট করে। একজন প্রোভাইডার কীভাবে সার্টিফিকেট বা কী ম্যানেজমেন্ট, প্রক্সি সীমানা এবং ধাপে ধাপে মাইগ্রেশন পরিচালনা করে তা মূল্যায়ন করার সময় সেই কাজগুলো প্রাসঙ্গিক। IETF RADIUS স্ট্যান্ডার্ড এবং সম্পর্কিত কাজ
একটি RADIUS-as-a-Service আর্কিটেকচার প্রকৃতপক্ষে যেভাবে কাজ করে
একটি হোস্ট করা RADIUS ডিজাইন মূল্যায়ন করা সহজ হয় যখন আপনি এর তিনটি কাজকে এর তিনটি প্লেন থেকে আলাদা করেন। কাজগুলো হলো authentication, authorisation এবং accounting। প্লেনগুলো হলো identity, transport এবং reporting। একজন বিক্রেতা এগুলোকে একসাথে প্যাকেজ করে উপস্থাপন করতে পারে, তবে অপারেটরদের এখনো জানতে হবে কোন উপাদানটি পরিচয় যাচাই করে, কোনটি অনুরোধ বহন করে এবং সেশনের প্রমাণ কোথায় জমা হয়।
সংযোগের অনুরোধ থেকে নেটওয়ার্ক পলিসি পর্যন্ত
যখন কোনো ব্যবহারকারী বা ডিভাইস সংযোগ করার চেষ্টা করে, তখন একটি অ্যাক্সেস পয়েন্ট বা কন্ট্রোলার Network Access Server হিসেবে কাজ করে। এটি RADIUS-এ অনুরোধ পাঠায়। সার্ভিসটি প্রায়শই একটি সংযুক্ত আইডেন্টিটি প্রোভাইডার বা সার্টিফিকেট ট্রাস্ট অ্যারেঞ্জমেন্ট ব্যবহার করে জমা দেওয়া পরিচয় বা ডিভাইসের শংসাপত্র পরীক্ষা করে, তারপর একটি গ্রহণ বা প্রত্যাখ্যানের সিদ্ধান্ত প্রদান করে।
একটি গৃহীত অনুরোধে অথরাইজেশন অ্যাট্রিবিউট থাকতে পারে, যেমন VLAN অ্যাসাইনমেন্ট বা অন্যান্য নেটওয়ার্ক প্যারামিটার। অ্যাক্সেস পয়েন্ট বা কন্ট্রোলার সেই নির্দেশাবলী প্রয়োগ করে। একটি হোটেলের উদাহরণের সাথে তুলনা করলে, অ্যাক্সেস পয়েন্ট হলো ডোর অ্যাটেনডেন্ট, হোস্ট করা RADIUS সার্ভিস হলো আইডেন্টিটি ডিরেক্টরি, এবং ফেরত আসা অ্যাট্রিবিউটগুলি হলো সেই রিস্টব্যান্ড যা ব্যক্তিটি কোন কোন এলাকায় প্রবেশ করতে পারবে তা নির্ধারণ করে।
হোস্ট করা পরিষেবাটি identity প্লেনকে Microsoft Entra ID, Okta, Google Workspace, একটি মোবাইল ডিভাইস ম্যানেজমেন্ট প্ল্যাটফর্ম বা একটি প্রপার্টি ম্যানেজমেন্ট সিস্টেমের মতো সিস্টেমের সাথে সংযুক্ত করে। সঠিক ইন্টিগ্রেশন পরিষেবা এবং অ্যাক্সেস পদ্ধতির উপর নির্ভর করে। একটি কানেক্টর অর্থ এই ধরে নেবেন না যে প্রতিটি নীতি আপনার সাইটের প্রয়োজনীয় উপায়ে মূল্যায়ন করা যেতে পারে। লিভার, শেয়ার করা ডিভাইস এবং তৃতীয় পক্ষের ভাড়াটে সহ identity এবং ডিভাইস কেস পরীক্ষা করুন।
অ্যাকাউন্টিং কোনো ঐচ্ছিক অতিরিক্ত সুবিধা নয়
অ্যাকাউন্টিং প্রাথমিক অথেন্টিকেশন সিদ্ধান্তের বাইরে স্বতন্ত্রভাবে সেশন ইভেন্ট এবং ব্যবহারের তথ্য রেকর্ড করে। সেই রেকর্ডগুলি অডিট, ক্যাপাসিটি প্ল্যানিং, চার্জব্যাক এবং তদন্তে সহায়তা করতে পারে, যার মধ্যে অন্য কোনো সিস্টেম আইডেন্টিটি চেক অংশ সম্পাদন করলেও তা অন্তর্ভুক্ত। মাল্টি-সাইট অপারেশনের জন্য, বিলম্বিত আপডেট, পুনরায় ট্রান্সমিশন, মিসিং স্টপ রেকর্ড এবং আঞ্চলিক এন্ডপয়েন্ট ফেলওভার কীভাবে পরিচালনা করবেন তা নির্ধারণ করুন।
ট্রান্সপোর্ট প্লেন নেটওয়ার্ক ডিভাইস এবং RADIUS-এর মধ্যে অনুরোধ বহন করে। ঐতিহ্যবাহী RADIUS সাধারণত UDP ব্যবহার করে; RadSec ব্যবহার করে TCP এবং TLS। রিপোর্টিং প্লেন প্রমাণীকরণ এবং অ্যাকাউন্টিং তথ্য সংগ্রহ করে যাতে অপারেটররা কেবল ওয়্যারলেস-অ্যাসোসিয়েশন লগ থেকে অ্যাক্সেস অনুমান করার পরিবর্তে সিদ্ধান্ত পর্যালোচনা করতে পারেন।
সার্ভিসগুলির তুলনা করার সময়, স্বাক্ষর করার আগে প্রতিটি উপাদান এবং ডেটা ফ্লো ম্যাপ করুন। একটি দরকারী সহায়ক নির্দেশিকা হলো network access control solutions, বিশেষ করে যদি RADIUS একটি বৃহত্তর নীতি এবং প্রয়োগ ডিজাইনের একটি অংশ হয়।
Hosted RADIUS এবং অন-প্রিমিসেস ডিপ্লয়মেন্টের তুলনা
হোস্টেড এবং অন-প্রিমাইস RADIUS একই প্রোটোকল ব্যবহার করে। উভয় ক্ষেত্রেই অ্যাক্সেস ডিভাইসগুলি Network Access Server হিসেবে থাকে; যা পরিবর্তিত হয় তা হলো কে শেয়ার্ড অথেনটিকেশন সার্ভার পরিচালনা করছে এবং এটি ও আপনার ভেন্যুগুলির মাঝে কী অবস্থান করছে। এটি নিজে পরিচালনা করলে অ্যাভেইল্যাবিলিটি হলো আপনার সার্ভার রুমের একটি ইঞ্জিনিয়ারিং সমস্যা। হোস্টেড হিসেবে এটি কিনলে সেই একই সমস্যা আপনার WAN পাথ, আইডেন্টিটি চেইন এবং সার্টিফিকেট ট্রাস্টে স্থানান্তরিত হয়, যার কোনোটিরই মালিক প্রোভাইডার আপনার পক্ষ থেকে নয়।
| মানদণ্ড | Hosted RADIUS | On-Premises RADIUS |
|---|---|---|
| ইনফ্রাস্ট্রাকচার কাজ | প্রোভাইডার হোস্ট করা প্ল্যাটফর্ম পরিচালনা করে; আপনার টিম এখনও ক্লায়েন্ট কনফিগারেশন, পলিসি এবং ইন্টিগ্রেশন পরিচালনা করে। | আপনার টিম সার্ভার, সফটওয়্যার, অপারেটিং সিস্টেম, মনিটরিং এবং রিকভারি ব্যবস্থা পরিচালনা করে। |
| মাল্টি-সাইট পলিসি | কেন্দ্রীয় পলিসি সংযোগ এবং সামঞ্জস্যপূর্ণ বাস্তবায়নের ওপর ভিত্তি করে বিভিন্ন লোকেশনের ডিভাইসগুলোতে পরিষেবা দিতে পারে। | একটি কেন্দ্রীয় সার্ভার বা সাইট-বাই-সাইট ডিপ্লয়মেন্ট কাজ করতে পারে, তবে রেপ্লিকেশন এবং ধারাবাহিকতার মডেল আপনার নিয়ন্ত্রণে থাকে। |
| নেটওয়ার্ক-ডিভাইস সামঞ্জস্যতা | সমর্থিত RADIUS অ্যাট্রিবিউট, ট্রান্সপোর্ট অপশন এবং আপনার ডিপ্লয় করা অ্যাক্সেস ডিভাইসের ওপর নির্ভর করে। | আপনি সার্ভার কনফিগারেশন নিয়ন্ত্রণ করেন, তবে সুইচেস, কন্ট্রোলার এবং অ্যাক্সেস পয়েন্ট জুড়ে আচরণ যাচাই করতে হবে। |
| ট্রান্সপোর্ট সিকিউরিটি | সার্টিফিকেট ম্যানেজমেন্ট এবং ইঞ্জিনিয়ারিং করার মতো TLS ক্যাপাসিটিসহ RadSec সাপোর্ট ট্রান্সপোর্টকে সুরক্ষিত করতে পারে। | RadSec স্থানীয়ভাবেও ডিপ্লয় করা যেতে পারে, তবে আপনার টিম সার্টিফিকেট, কানেকশন এবং স্কেলিং পরিচালনা করে। |
| ব্যর্থতার মালিকানা | প্রোভাইডার প্ল্যাটফর্ম অপারেশন পরিচালনা করে; আপনার টিমকে অবশ্যই WAN, আইডেন্টিটি, এন্ডপয়েন্ট এবং লোকাল ফলব্যাক আচরণ পরীক্ষা করতে হবে। | আপনার টিম লোকাল অ্যাভেইলবিলিটি নিয়ন্ত্রণ করে, তবে অবশ্যই রেডানডেন্সি এবং রিকভারি ডিজাইন ও বজায় রাখতে হবে। |
| খরচের ধরন | প্রায়শই একটি সার্ভিস সাবস্ক্রিপশন হিসেবে প্রদান করা হয়; চুক্তি এবং অন্তর্ভুক্ত অপারেশনাল স্কোপ মূল্যায়ন করুন। | বিদ্যমান ইনফ্রাস্ট্রাকচার ব্যবহার করতে পারে, তবে কর্মীদের সময়, রক্ষণাবেক্ষণ এবং প্রতিস্থাপন আপনার দায়িত্ব থেকে যায়। |
স্লোগান দিয়ে নয়, ব্যর্থতার মোড দেখে সিদ্ধান্ত নিন
RFC 2865 অ্যাক্সেস ডিভাইস এবং শেয়ার্ড অথেন্টিকেশন সার্ভারের মধ্যে পার্থক্য নির্দিষ্ট করে (RFC 2865); হোস্ট করা ডেলিভারি কেবল সার্ভারটি কোথায় চলছে তা পরিবর্তন করে, আপনার সুইচ, কন্ট্রোলার এবং অ্যাক্সেস পয়েন্টগুলি কী ভূমিকা পালন করছে তা নয়। তাই উভয় মডেলের জন্যই দরকারী প্রশ্নটি একই: যখন অথেন্টিকেশন অলভ্য হয়ে যায়, তখন ভেন্যুতে এখনও কী কাজ করে?
হোস্ট করা ব্যবহার করুন যখন আপনি মেনে নিতে পারেন যে একটি হোটেল বা অ্যারেনায় একটি WAN পাথ ব্যর্থতা আপনার স্থানীয়ভাবে সমাধান করার সমস্যা, টিকে থাকার যোগ্য SSID, ক্যাশ করা বা ফলব্যাক নীতি এবং আপনার পরীক্ষিত AP আচরণের মাধ্যমে। অন-প্রিমেস ব্যবহার করুন যখন আপনি সার্বক্ষণিক সার্ভার অপারেশন পরিচালনা করতে পারেন এবং সার্টিফিকেট ঘূর্ণন, প্যাচিং এবং রেডানডেন্সির মালিক হবেন। একটি স্থানীয়ভাবে পরিচালিত সার্ভার ডিফল্টরূপে বেশি সহনশীল নয়। আমি মেয়াদোত্তীর্ণ সার্টিফিকেট এবং কোনো ফেলওভার ছাড়াই চলমান প্রচুর একক অন-প্রিমেস বক্স অডিট করেছি, যা ডিজাইনের চেয়ে অভ্যাসের মাধ্যমে একটি নেটওয়ার্ককে একসাথে ধরে রেখেছে।
ডিপ্লয়মেন্ট মডেলের চেয়ে এর চারপাশের ফেলিউর ডিজাইন অনেক বেশি সিদ্ধান্ত গ্রহণ করে।
সুরক্ষার অবস্থান অবস্থানের চেয়ে বাস্তবায়নকে অনুসরণ করে। জিজ্ঞাসা করুন কোথায় শেয়ার্ড সিক্রেট এবং সার্টিফিকেটগুলি সংরক্ষণ করা হয়, কে অ্যাকাউন্টিং ডেটা পড়তে পারে, ট্রানজিটে কীভাবে অনুরোধগুলি সুরক্ষিত থাকে এবং যে অনুরোধগুলির উত্তর পরিষেবাটি নিজে দিতে পারে না সেগুলিকে কীভাবে প্রক্সি করে। টিল, গেস্ট WiFi, ক্যামেরা এবং IoT ডিভাইসগুলি সাধারণত একটি প্রমাণীকরণ পথ ভাগ করে নেয়, তাই যেকোনো মডেলের একটি দুর্বল পয়েন্ট একই সাথে সর্বত্র প্রকাশিত হয়। আপনি যদি গ্রাহক-পরিচালিত পরিকাঠামোর বিরুদ্ধে একটি হোস্ট করা প্ল্যাটফর্ম বিবেচনা করেন, তবে একটি স্ব-হোস্ট করা RADIUS তুলনা আপনার কোন পরিচালন দায়িত্বগুলি ধরে রাখা উচিত তা নির্ধারণ করতে সহায়তা করে।
SLA, মাল্টি-রিজিয়ন ফেলওভার এবং প্রকৃতপক্ষে যা ব্যাহত হয়
একজন প্রোভাইডারের প্ল্যাটফর্ম আপটাইম, এর RADIUS সার্ভিস প্রতিশ্রুতি এবং একটি নির্দিষ্ট ভেন্যুতে অথেন্টিকেশনের প্রাপ্যতা সম্পর্কিত তবে পারস্পরিক পরিবর্তনযোগ্য নয়। একটি হোস্ট করা প্ল্যাটফর্ম সুস্থ থাকতে পারে যখন একটি হোটেল WAN বা DNS ব্যর্থতার কারণে এটিতে পৌঁছাতে পারে না। একটি ভেন্যু RADIUS-এ পৌঁছাতে পারে যদিও তার আইডেন্টিটি প্রোভাইডার বা সার্টিফিকেট চেইন সফল অথেন্টিকেশন প্রতিরোধ করে।
ব্যবহারকারী এবং ডিভাইস অনুযায়ী ফেলিউর রেসপন্স গ্রেড করুন
- WAN আউটেজ: নতুন ক্লাউড অথেন্টিকেশন ব্যর্থ হতে পারে। লোকাল নেটওয়ার্ক আচরণ এবং সেশন পলিসির ওপর নির্ভর করে বিদ্যমান সেশনগুলো চলতে পারে। আপনার অ্যাক্সেস পয়েন্ট এস্টেটে লোকাল সারভাইভেবিলিটি পরীক্ষা করা হয়েছে কিনা তা জিজ্ঞেস করুন।
- DNS ব্যর্থতা: ডিভাইসগুলোর কনফিগারেশন যদি DNS-এর ওপর নির্ভর করে তবে তারা সার্ভিস এন্ডপয়েন্ট রেজোলিউব নাও করতে পারে। এন্ডপয়েন্টগুলো কীভাবে প্রোভিশন করা হয় এবং রেজোলিউশন ব্যর্থ হলে অ্যাক্সেস সরঞ্জামগুলো কী করে তা নিশ্চিত করুন।
- আইডেন্টিটি-প্রোভাইডার আউটেজ: RADIUS সার্ভিসটি অ্যাক্সেসযোগ্য হতে পারে তবে একটি নতুন আইডেন্টিটি যাচাই করতে অক্ষম হতে পারে। ক্যাশে করা ক্রেডেনশিয়াল সাহায্য করতে পারে, তবে ব্যবহারকারীর স্ট্যাটাস পরিবর্তিত হওয়ার পরেও তারা অ্যাক্সেস বজায় রাখতে পারে।
- সার্টিফিকেট মেয়াদোত্তীর্ণ বা CA ব্যাঘাত: একটি প্রয়োজনীয় সার্টিফিকেট অকার্যকর, মেয়াদোত্তীর্ণ বা বিশ্বস্ত না হলে সার্টিফিকেট ভিত্তিক অথেন্টিকেশন ব্যর্থ হতে পারে। সার্টিফিকেট লাইফসাইকেল মনিটরিংয়ে শুধুমাত্র RADIUS সার্ভার নয়, সংশ্লিষ্ট ডিভাইস এবং ট্রাস্ট চেইন অন্তর্ভুক্ত থাকতে হবে।
- ম্যানেজমেন্ট-প্লেন আউটেজ: অথেন্টিকেশন চালু থাকলেও অপারেটররা পলিসি পরিবর্তন করার বা অ্যাক্সেস বাতিল করার ক্ষমতা হারাতে পারে। জরুরি পরিবর্তনগুলো কীভাবে করা হয় এবং রেকর্ড করা হয় তা নির্ধারণ করুন।
একটি শেয়ার্ড-পাসওয়ার্ড ইমার্জেন্সি SSID, MAC-ভিত্তিক অ্যাক্সেস এবং ক্যাশ করা শংসাপত্রগুলি সহনশীলতার সমতুল্য রূপ নয়। প্রতিটি তাত্ক্ষণিক উপলভ্যতা এবং সুরক্ষার মধ্যে আপস করে: শেয়ার্ড কীগুলি বাতিল করার জন্য টার্গেট করা কঠিন, MAC আইডেন্টিফায়ারগুলি স্পুফ করা যেতে পারে, এবং ক্যাশ করা সিদ্ধান্তগুলি পরিচয় অবস্থার চেয়ে বেশি সময় বেঁচে থাকতে পারে যা প্রতিফলিত করার জন্য সেগুলি তৈরি করা হয়েছিল।
ব্যবহারকারী-বাই-ব্যবহারকারী ব্যর্থতা নীতির জন্য জিজ্ঞাসা করুন: কর্মী, অতিথি, টিল, ক্যামেরা, বাসিন্দা এবং IoT ডিভাইসগুলির কি ফেইল ক্লোজড হওয়া উচিত, একটি সীমিত স্থানীয় ফলব্যাক ব্যবহার করা উচিত নাকি পূর্বে অনুমোদিত সেশনে চালিয়ে যাওয়া উচিত?
মাল্টি-রিজিয়ন হলো একটি ডিজাইন ইনপুট, কোনো প্রমাণ নয়
মাল্টি-রিজিয়ন RADIUS এন্ডপয়েন্টগুলি একটি একক পরিষেবা অঞ্চলের ওপর নির্ভরতা কমাতে পারে, তবে অ্যাক্সেস ডিভাইসগুলির এগুলিতে পৌঁছানোর এবং তাদের মধ্যে failover করার জন্য একটি কার্যকর উপায় প্রয়োজন। মোতায়েন করা অ্যাক্সেস পয়েন্ট এবং কন্ট্রোলারগুলি স্বয়ংক্রিয়ভাবে পুনরায় চেষ্টা করে কিনা, তারা কীভাবে একটি বিকল্প এন্ডপয়েন্ট বেছে নেয় এবং একটি রিজিয়ন হারানোর জন্য ম্যানুয়াল হস্তক্ষেপের প্রয়োজন হয় কিনা তা যাচাই করুন। এছাড়াও পুনঃপ্রচার এবং পুনরুদ্ধারের সময় accounting দেখতে কেমন তা পরীক্ষা করুন।
সংগ্রহের আগে জিজ্ঞাসা করুন যে ক্যাশ করা authentication কতক্ষণ কার্যকর থাকে, কে জরুরি অ্যাক্সেস বাতিল করতে পারে, কত ঘন ঘন failover পরীক্ষা করা হয় এবং পরীক্ষা থেকে সরবরাহকারী কী প্রমাণ দেখাতে পারে। হোটেল এবং বড় ভেন্যুগুলির জন্য, শুধুমাত্র কর্মীদের ল্যাপটপ নয়, প্রতিনিধি ডিভাইস এবং পরিষেবাগুলির সাথে পরীক্ষাটি চালান। একটি দরকারী ফলাফল হলো একটি লিখিত ব্যর্থতার ম্যাট্রিক্স যা প্রভাবিত জনসংখ্যা, প্রত্যাশিত আচরণ, মালিক এবং পুনরুদ্ধারের পদক্ষেপের নাম দেয়।
সিকিউরিটি, কমপ্লায়েন্স এবং লেগ্যাসি RADIUS থেকে মাইগ্রেশন
মাইগ্রেশনকে সার্ভার ঠিকানা পরিবর্তন হিসেবে না দেখে একটি নিরাপত্তা প্রকল্প হিসেবে বিবেচনা করুন। একটি "সুরক্ষিত RADIUS" দাবি বিভিন্ন বিষয় নির্দেশ করতে পারে: ট্রান্সপোর্ট সুরক্ষিত করা, নেটওয়ার্ক ডিভাইসগুলো অটেনটিকেশন করা, ব্যবহারকারী বা ডিভাইসের পরিচয় যাচাই করা, অথবা সঠিক অথরাইজেশন ফেরত পাঠানো। এই নিয়ন্ত্রণগুলো আলাদা আলাদা সমস্যার সমাধান করে।
RadSec RADIUS ট্রান্সপোর্ট সুরক্ষিত করতে TLS ব্যবহার করে, এবং পারস্পরিক সার্টিফিকেট অথেনটিকেশন সার্ভার এবং ক্লায়েন্ট ডিভাইসটি বিশ্বস্ত তা নিশ্চিত করতে সহায়তা করতে পারে। কিন্তু শুধুমাত্র এনক্রিপশনই এটি নিশ্চিত করে না যে সঠিক ব্যবহারকারী সঠিক VLAN পাচ্ছেন, অথবা কোনো পদত্যাগকারী কর্মীর অ্যাক্সেস সাথে সাথে বাতিল করা হয়েছে কিনা। যখন প্যাকেটগুলি পুনরায় চেষ্টা করা হয় বা এন্ডপয়েন্টগুলি পরিবর্তিত হয়, তখন সার্ভিসটি কীভাবে Message-Authenticator, রিপ্লে এবং স্পুফিং সুরক্ষা, প্রক্সি পরিদর্শন এবং অ্যাকাউন্টিং সততা পরিচালনা করে তা অপারেটরদের নিশ্চিত করা উচিত।
শুধু আশ্বাস নয়, প্রমাণ চান
একজন প্রোভাইডার মূল্যায়ন করার সময়, সরাসরি প্রশ্ন জিজ্ঞাসা করুন:
- সার্টিফিকেট ব্যবস্থাপনা: সার্টিফিকেট কি প্রতি গ্রাহক, টেন্যান্ট, সাইট, নাকি নেটওয়ার্ক ডিভাইস অনুযায়ী পরিচালিত হয়? মেয়াদ শেষ হওয়া এবং রোটেশন কীভাবে পর্যবেক্ষণ করা হয়?
- ট্রান্সপোর্ট সীমানা: TLS কোথায় শেষ হয়? ইন্টারমিডিয়েট প্রক্সিগুলো কি অনুরোধ পরিদর্শন বা ফরোয়ার্ড করতে পারে, এবং শেষ সীমা পর্যন্ত কী ধরনের সুরক্ষা অবশিষ্ট থাকে?
- অডিট প্রমাণ: আপনি কি অটেনটিকেশন সংক্রান্ত সিদ্ধান্ত, পলিসি পরিবর্তন, প্রশাসনিক অ্যাক্সেস এবং অ্যাকাউন্টিং রেকর্ডগুলো পর্যালোচনা করতে পারেন?
- নিরাপত্তা ব্যবস্থা: সেবাদাতার কাছে কী কী শংসাপত্র রয়েছে এবং সেগুলোর আওতা কতটুকু? আপনার যদি ISO 27001 বা Cyber Essentials Plus-এর প্রয়োজন হয়, তবে কেবল লোগোর ওপর নির্ভর না করে বর্তমান প্রমাণ এবং প্রয়োগযোগ্যতা যাচাই করুন।
- মাইগ্রেশন এবং রোলব্যাক: সেবাদাতা কি ধাপে ধাপে UDP-থেকে-TLS রূপান্তরে সহায়তা করতে পারে, এবং কোনো অ্যাক্সেস-ডিভাইস মডেল ভিন্নভাবে আচরণ করলে পরীক্ষা করা রোলব্যাক পথটি কী?
একটি মাইগ্রেশন সিকোয়েন্স RADIUS ক্লায়েন্ট, আইডেন্টিটি সোর্স, অথেনটিকেশন মেথড, VLAN নিয়ম, শেয়ার্ড সিক্রেট, সার্টিফিকেট এবং অ্যাকাউন্টিং কনজিউমারদের একটি ইনভেন্টরি দিয়ে শুরু হওয়া উচিত। এরপরে, টার্গেট পলিসি ডকুমেন্ট করুন এবং প্রতিনিধি আইডেন্টিটি ও ডিভাইস দিয়ে এটি পরীক্ষা করুন। একটি সাইটে পাইলট রান চালান, প্রাপ্ত সিদ্ধান্তের সাথে কাঙ্ক্ষিত ফলাফলের তুলনা করুন, তারপর সার্ভিস অনুযায়ী কাট ওভার করুন। প্রোডাকশনে অ্যাকাউন্টিং এবং অ্যাক্সেসের আচরণ পুরোপুরি না বোঝা পর্যন্ত একটি রোলব্যাক পাথ বজায় রাখুন।
আপনার পরিবেশ যে ট্র্যাফিক এবং রেকর্ডগুলি পরিচালনা করে তা সম্মতি মেনে চলতে হবে। একটি ব্যবহারিক নেটওয়ার্ক-নিয়ন্ত্রণ দৃষ্টিকোণ থেকে, PCI-DSS সম্মতি এবং WiFi সম্পর্কিত এই নির্দেশিকাটি দেখুন। দরকারী প্রশ্নটি এটি নয় যে একটি পণ্য সম্মতির দাবি করে কিনা, তবে আপনার মোতায়েন করা ব্যবস্থা আপনার সংস্থাকে প্রদর্শনের জন্য প্রয়োজনীয় নিয়ন্ত্রণের প্রমাণ তৈরি করে কিনা।
প্রোটোকল স্পেসিফিকেশন এবং ইনস্টল করা নেটওয়ার্কের মধ্যে আরও একটি ঝুঁকি রয়েছে। নিরাপত্তা নির্দেশিকা এমন কিছু যাচাইকরণের প্রয়োজনীয়তা তৈরি করতে পারে যা কিছু অ্যাক্সেস ডিভাইস বা প্রক্সি ধারাবাহিকভাবে প্রয়োগ করে না। ভেন্ডরদের জিজ্ঞাসা করুন তারা কোন নিয়ন্ত্রণগুলি প্রয়োগ করে, কোনটি ক্লায়েন্ট ফার্মওয়্যারের ওপর নির্ভর করে এবং তারা কীভাবে আপনার সরঞ্জাম জুড়ে আচরণ যাচাই করে।
একটি Hosted RADIUS সার্ভিস নির্বাচন এবং রোল আউট করা
শুধুমাত্র ক্লাউড লেবেল দেখে নয়, ব্যর্থতার আচরণ এবং অপারেটিং প্রমাণের দ্বারা একজন সরবরাহকারী চয়ন করুন যা আপনি যাচাই করতে পারেন। আঞ্চলিক কভারেজ, আইডেন্টিটি-প্রোভাইডার সাপোর্ট, প্রয়োজনে প্রতি-টেন্যান্ট কি ম্যানেজমেন্ট, অডিট অ্যাক্সেস, RadSec এবং সার্টিফিকেট প্রক্রিয়া এবং চুক্তি শেষ হলে কী ঘটে তা নিশ্চিত করুন।
একটি নিয়ন্ত্রিত ক্রমানুসারে রোল আউট করুন: বর্তমান AAA এবং ডিভাইসের নির্ভরতার ইনভেন্টরি তৈরি করুন; আইডেন্টিটি-টু-নেটওয়ার্ক পলিসি নির্ধারণ করুন; প্রতিনিধি সাইট এবং ডিভাইসের ধরন পাইলট করুন; ধাপে ধাপে কাট ওভার করুন; তারপর আইডেন্টিটি বা প্রপার্টি-ম্যানেজমেন্ট রেকর্ডের সাথে অ্যাক্সেসের সিদ্ধান্ত এবং অ্যাকাউন্টিং যাচাই করুন। ব্যর্থ অথেনটিকেশন, রেভোকেশন হ্যান্ডলিং, অ্যাকাউন্টিং রিকনসিলিয়েশন, এবং গেস্ট-নেটওয়ার্ক পারফরম্যান্সকে অপারেশনাল সিগন্যাল হিসেবে ট্র্যাক করুন, নিজস্ব স্থিতিস্থাপকতার প্রমাণ হিসেবে নয়।
Purple Access বিদ্যমান অ্যাক্সেস পয়েন্ট জুড়ে আইডেন্টিটি-চালিত অ্যাক্সেসসহ ওপেন, নিরাপদ এবং xPSK নেটওয়ার্ক বিকল্পের সাথে হোস্ট করা Cloud RADIUS অফার করে। আপনি যে কোনও সরবরাহকারীর কাছে অনুরোধ করবেন এমন একই ব্যর্থতার পরীক্ষা, নীতি প্রয়োজনীয়তা এবং প্রমাণের বিরুদ্ধে এটি মূল্যায়ন করুন।
আপনি যদি একটি মাল্টি-সাইট RADIUS রোলআউটের পরিকল্পনা করেন, তবে প্রমাণীকরণ পথ পরিবর্তন করার আগে আপনার WAN, পরিচয়, সার্টিফিকেট এবং স্থানীয় ফলব্যাক নির্ভরতা ম্যাপ করুন। গেস্ট, স্টাফ এবং ডিভাইস নেটওয়ার্কের জন্য Cloud RADIUS এবং নেটওয়ার্ক-অ্যাক্সেস বিকল্পগুলি পর্যালোচনা করতে Purple Access দেখুন।
