একজন অতিথি আপনার হোটেলের WiFi-এ যুক্ত হলেন। একজন স্টাফ মেম্বার Entra ID-এর মাধ্যমে একই নেটওয়ার্ক পরিবারে সাইন ইন করলেন। একটি পয়েন্ট-অফ-সেল ট্যাবলেট স্বয়ংক্রিয়ভাবে পুনরায় সংযুক্ত হলো। কাগজে-কলমে, আপনি কঠিন কাজটি করে ফেলেছেন। আইডেন্টিটি ম্যানেজ করা হয়েছে, SSIDs সেগমেন্ট করা হয়েছে, সার্টিফিকেট ইস্যু করা হয়েছে এবং আপনার ফায়ারওয়াল নিয়মগুলো বেশ পরিপাটি দেখাচ্ছে।
তারপর একটি শান্ত DNS অনুরোধ সেগুলোর সবকটি এড়িয়ে চলে যায়।
এই অংশটিই অনেক টিম মিস করে। বেশিরভাগ ডিভাইস প্রথম যে প্রশ্নটি জিজ্ঞাসা করে তা হলো "আমাকে কি এই নেটওয়ার্কে প্রবেশ করার অনুমতি দেওয়া হয়েছে?" তা নয়। এটি জিজ্ঞাসা করে "আমি যে জিনিসটিতে পৌঁছাতে চাই সেটি কোথায়?" যদি আপনার DNS লেয়ার অন্ধভাবে সেই প্রশ্নের উত্তর দেয়, তবে একজন আক্রমণকারী এমন একটি প্রোটোকলের অপব্যবহার করতে পারে যা প্রায় প্রতিটি নেটওয়ার্ক ডিফল্টরূপে অনুমতি দেয়। ব্যস্ত আতিথেয়তা, খুচরা বিক্রয়, স্বাস্থ্যসেবা এবং মিশ্র-ব্যবহারের পরিবেশে, এটি অ্যাক্সেস কন্ট্রোল এবং প্রকৃত সুরক্ষার মধ্যে একটি মারাত্মক ব্যবধান।
সঠিক DNS এবং সুরক্ষা অনুশীলন এই ঘাটতি পূরণ করে। এটি DNS-কে কেবল একটি ব্যাকগ্রাউন্ড পরিকাঠামো হিসেবে দেখার চেয়ে বেশি কিছু করে। এটি সততা, গোপনীয়তা, নীতি এবং দৃশ্যমানতার জন্য একটি কন্ট্রোল পয়েন্টে পরিণত হয়, বিশেষ করে এমন নেটওয়ার্কগুলোতে যেখানে গেস্ট ট্রাফিক, কর্মীদের ট্রাফিক এবং অপারেশনাল ডিভাইসগুলো একসাথে অবস্থান করে।
আপনার নেটওয়ার্কের অদৃশ্য দুর্বলতা
একটি সাধারণ ব্যর্থতা কোনো নাটকীয় সতর্কবার্তা দিয়ে শুরু হয় না। এটি শুরু হয় ছোট কিছু দিয়ে। একটি গেস্ট ডিভাইস কোনো ভেন্যু নেটওয়ার্কে যুক্ত হয় এবং একটি ক্ষতিকারক লুকঅ্যালাইক ডোমেন রিসলভ করে। একটি ব্যাক-অফিস ল্যাপটপ একটি পয়জনড DNS প্রতিক্রিয়ার মাধ্যমে ভুল সার্ভিসে চলে যায়। একটি সংক্রমিত ডিভাইস একটি রিমোট কন্ট্রোলারের সাথে যোগাযোগ করতে DNS ব্যবহার করে কারণ আউটবাউন্ড ওয়েব ট্রাফিক কঠোরভাবে ফিল্টার করা হলেও, DNS-কে এখনও ব্যাপকভাবে বিশ্বাস করা হয়।
এই সিকোয়েন্সটি সাধারণ মনে হয় কারণ প্রথম দেখায় DNS ট্রাফিক সবসময় সাধারণই দেখায়। প্রতিটি ফোন, ট্যাবলেট, ব্রাউজার, ক্যাশ রেজিস্টার, স্মার্ট টিভি এবং স্ক্যানার এর ওপর নির্ভর করে। প্রতিটি লগইন এবং অ্যাপ্লিকেশন কল যে নাম-রেজোলিউশন সিস্টেমের ওপর নির্ভর করে, তা সুরক্ষিত করার চেয়ে টিমগুলো প্রায়শই লগইন ফ্লো আরও কঠোর করতে বেশি সময় ব্যয় করে।
কেন DNS বোর্ড-স্তরের মনোযোগ পাওয়ার যোগ্য
যুক্তরাজ্যের ডেটা উপেক্ষা করা কঠিন। এই DNS ইতিহাস এবং নিরাপত্তা ওভারভিউতে উদ্ধৃত যুক্তরাজ্যের NCSC ডেটা অনুযায়ী, ২০২১ থেকে ২০২২ সালের মধ্যে DNS অপব্যবহারের রিপোর্ট ৪৪% বৃদ্ধি পেয়েছে এবং ৩৫৬,৪৬৩টি ঘটনায় পৌঁছেছে। একই সূত্র উল্লেখ করে যে ২০২৩ সালের মধ্যে, স্বাস্থ্যসেবা এবং পরিবহনের মতো গুরুত্বপূর্ণ ক্ষেত্রগুলোতে রিপোর্ট করা সমস্ত সাইবার ঘটনার ২৫% ছিল DNS-ভিত্তিক আক্রমণ।
এই সংখ্যাগুলি গুরুত্বপূর্ণ কারণ ক্ষতিগ্রস্ত সেক্টরগুলি দেখতে আধুনিক হাই-ট্রাফিক WiFi পরিবেশের মতোই। এগুলি অবিচ্ছিন্ন কানেক্টিভিটি, মিশ্র ডিভাইস পপুলেশন এবং এমন পরিষেবাগুলির ওপর নির্ভর করে যেগুলির নাম দ্রুত এবং নির্ভরযোগ্যভাবে রিসলভ করা প্রয়োজন। যদি DNS আপস করা হয়, তবে ব্যবহারকারীর অভিজ্ঞতা হ্রাস পায় এবং একই সাথে নিরাপত্তা ভেঙে পড়ে।
DNS কেবল পথের একটি অংশ নয়। অনেক পরিবেশেই, এটি প্রথম নিরাপত্তা সিদ্ধান্ত যা একটি ডিভাইসের সামনে আসে।
বাস্তব অপারেশনে এটি যেখানে প্রকাশ পায়
ব্যবসায়িক প্রভাব সাধারণত তিনটি ক্ষেত্রে পড়ে:
- নিরাপত্তার ঝুঁকি: ব্যবহারকারীদের ক্ষতিকারক গন্তব্যে রিডাইরেক্ট করা হতে পারে, ম্যালওয়্যার কমান্ড-অ্যান্ড-কন্ট্রোল ডোমেন সমাধান করতে পারে এবং এমন চ্যানেলগুলোর মাধ্যমে ডেটা নেটওয়ার্ক থেকে বেরিয়ে যেতে পারে যা অনেক নিয়ন্ত্রণ উপেক্ষা করে।
- পরিচালনগত ব্যাঘাত: কর্মীদের অ্যাপগুলো মাঝে মাঝে ব্যর্থ হয়, captive ওয়ার্কফ্লো অদ্ভুত আচরণ করে এবং ট্রাবলশুটিং ধীর হয়ে যায় কারণ লক্ষণগুলো সাধারণ সংযোগ সমস্যার মতো দেখায়।
- গ্রাহকের অভিজ্ঞতা: অতিথিরা এটি পরোয়া করেন না যে ব্যর্থতাটি DNS স্পুফিং, ফিল্টারিং ত্রুটি বা রিজলভার টাইমআউট থেকে এসেছে কিনা। তারা কেবল জানেন যে WiFi নির্ভরযোগ্য মনে হচ্ছে না।
যখন টিমগুলি DNS-কে কেবল একটি পাইপলাইনের পরিবর্তে একটি সিকিউরিটি প্লেন হিসেবে বিবেচনা করতে শুরু করে, তখন তারা প্রতিটি কানেকশনে জটিলতা না বাড়িয়েই ঝুঁকি নিয়ন্ত্রণের একটি পরিচ্ছন্ন উপায় খুঁজে পায়।
DNS নিরাপত্তার অন্ধ স্থান বা ব্লাইন্ড স্পট বোঝা
"ইন্টারনেটের ফোনবুক" উপমাটি বেশ পরিচিত। এটি দরকারী, তবে অসম্পূর্ণ। DNS কেবল নাম খুঁজে বের করে না। এটি ডিভাইসগুলোকে পরবর্তী নির্দেশ দেয় তারা কোথায় যাবে, প্রায়শই কোনো শক্তিশালী নিয়ন্ত্রণ কাজ শুরু করার আগেই। এটি একে একটি ফোনবুকের চেয়ে পুরো নেটওয়ার্কের জন্য একটি দিকনির্দেশক সাইনপোস্ট সিস্টেমের মতো করে তোলে।
এই অন্ধত্বটি আসে DNS-এর মূল ধারণা থেকে। এটি একটি আরও উন্মুক্ত ইন্টারনেটের জন্য তৈরি করা হয়েছিল, যেখানে রিসলভার এবং অথরিটেটিভ সার্ভারগুলি বিশ্বস্ত হবে বলে আশা করা হতো। আধুনিক এন্টারপ্রাইজ এবং গেস্ট WiFi পরিবেশগুলি সেই জগতে কাজ করে না। এগুলিতে অবিশ্বাস্য ক্লায়েন্ট, রোমিং ডিভাইস, থার্ড-পার্টি সার্ভিস এবং এমন অ্যাপ্লিকেশন থাকে যা দ্রুত, অবিচ্ছিন্ন রেজোলিউশনের উপর নির্ভর করে।
লুকআপের সময় আসলে কী ঘটে
যখন একজন ব্যবহারকারী একটি অ্যাপ খোলেন বা একটি সাইট ভিজিট করেন, তখন ডিভাইসটি প্রথমে একটি রিজলভারের কাছে ডোমেন নামের সাথে যুক্ত অ্যাড্রেসটি জানতে চায়। যদি রিজলভারের কাছে উত্তরটি ইতিমধ্যেই ক্যাশ করা থাকে, তবে এটি দ্রুত উত্তর দেয়। যদি না থাকে, তবে এটি উত্তর না পাওয়া পর্যন্ত DNS হায়ারার্কির মাধ্যমে অনুরোধটি পরিচালনা করে এবং ক্লায়েন্টের কাছে ফেরত পাঠায়।
এটি শুনতে সহজ মনে হলেও, সেই প্রক্রিয়ার ভেতরে কয়েকটি বিশ্বাসের অনুমান লুকিয়ে থাকে:
- ক্লায়েন্ট রিসলভারকে বিশ্বাস করে যাতে এটি নির্ভুল উত্তর দিতে পারে।
- রিসলভার আপস্ট্রিম ডেটাকে বিশ্বাস করে যদি না যাচাইকরণের ব্যবস্থা থাকে।
- পাথ পর্যবেক্ষণকারী যে কেউ কোয়েরিটি জেনে যেতে পারে যদি ট্রান্সপোর্ট এনক্রিপ্ট করা না থাকে।
- পলিসি প্রায়শই পরবর্তীতে প্রয়োগ করা হয়, DNS ইতিমধ্যে ডিভাইসটিকে একটি গন্তব্যের দিকে নির্দেশ করার পরে।
একটি শক্তিশালী আইডেন্টিটি স্ট্যাক একাই এই বিষয়গুলি সমাধান করতে পারে না। DNS ইন্টিগ্রিটি বা প্রাইভেসি দুর্বল হলে একজন ব্যবহারকারী সফলভাবে অথেন্টিকেট করার পরেও ভুল জায়গায় চলে যেতে পারেন।
কেন টিমগুলো সমস্যাটিকে ছোট করে দেখে
DNS প্রায়শই নেপথ্যে হারিয়ে যায় কারণ এটি একটি শেয়ার্ড অবকাঠামো। যখন এটি কাজ করে তখন কেউ এটি লক্ষ্য করে না। যখন এটি ব্যর্থ হয়, তখন এর লক্ষণগুলো ব্রাউজার, অ্যাপস, APIs, ওয়্যারলেস অনবোর্ডিং এবং ক্লাউড অ্যাক্সেসের মধ্যে ছড়িয়ে পড়ে, যার ফলে টিমগুলো প্রথমে ভুল লেয়ার নিয়ে ব্যস্ত হয়ে পড়ে।
এখানেই পাঠকেরা প্রায়ই বিভ্রান্ত হন: তারা মনে করেন যেহেতু অ্যাপ্লিকেশন ট্রাফিক TLS ব্যবহার করে, তাই DNS ইতিমধ্যেই সুরক্ষিত। সাধারণত তা নয়। মূল পরিষেবার সাথে এনক্রিপ্ট করা সেশন শুরু হওয়ার আগেই প্রচলিত DNS কোয়েরিগুলো দৃশ্যমান হতে পারে বা সেগুলোতে হস্তক্ষেপ করা যেতে পারে।
ব্যবহারিক নিয়ম: আপনি যদি আইডেন্টিটি, WiFi অথেন্টিকেশন এবং অ্যাপ্লিকেশন সেশন সুরক্ষিত করেন কিন্তু DNS-কে আন-অথেন্টিকেটেড বা আন-এনক্রিপ্টেড রেখে দেন, তবে আপনি কানেকশনের শুরুটা সুরক্ষিত করতে পারেননি।
আর্কিটেকচারাল বা কাঠামোগত দুর্বলতা
আপনি স্বেচ্ছায় সমাধান না করা পর্যন্ত DNS-এর দুটি মূল দুর্বলতা রয়েছে:
| দুর্বলতা | বাস্তবে এর অর্থ কী | এটি কেন গুরুত্বপূর্ণ |
|---|---|---|
| কোনো বিল্ট-ইন সত্যতা যাচাই নেই | একটি ক্লায়েন্ট জাল বা পরিবর্তিত উত্তর গ্রহণ করতে পারে | ব্যবহারকারী এবং ডিভাইসগুলিকে অন্য ঠিকানায় রিডাইরেক্ট করা যেতে পারে |
| কোনো বিল্ট-ইন গোপনীয়তা নেই | অন্যান্য পক্ষ কোয়েরির পথ পর্যবেক্ষণ করতে পারে | ব্রাউজিংয়ের উদ্দেশ্য, পরিষেবা ব্যবহার এবং ডিভাইসের আচরণ প্রকাশ পেয়ে যেতে পারে |
এই কারণেই DNS এবং সুরক্ষাকে আইডেন্টিটি, সেগমেন্টেশন এবং অ্যাক্সেস পলিসির মতো একই আলোচনায় রাখা উচিত। টিমগুলোর অসাবধানতার কারণে DNS ব্যর্থ হচ্ছে না। এটি ব্যর্থ হচ্ছে কারণ অনেক ডেপ্লয়মেন্ট এখনও এমন ট্রাস্ট মডেলের ওপর নির্ভর করে যা বর্তমানের আসল নেটওয়ার্ক অবস্থার সাথে আর খাপ খায় না।
আধুনিক DNS হুমকির পরিমন্ডল
আক্রমণকারীরা DNS পছন্দ করে কারণ ডিফেন্ডারদের এটি অনুমতি দিতেই হয়। যে ডিভাইস নাম রেজোলিউশন করতে পারে না, সেটি প্রায় কিছুই করতে পারে না, তাই DNS হলো এমন কয়েকটি প্রোটোকলের একটি যা প্রায় প্রতিটি নেটওয়ার্ক জুড়েই ব্যাপকভাবে অনুমোদিত থাকে। এটি একে রিডাইরেকশন, গোপন সংকেত আদান-প্রদান এবং বড় আকারে অপব্যবহারের জন্য একটি সুবিধাজনক পথ করে তোলে।
এর পরিধি অত্যন্ত বিস্তৃত। Forrester 2025-এর তথ্য অনুযায়ী ৯৫% প্রতিষ্ঠান DNS-এর মাধ্যমে সাইবার আক্রমণের শিকার হয়েছে, যা EfficientIP-এর DNS ঝুঁকি মূল্যায়নে উল্লেখ করা হয়েছে। একই উৎস থেকে DNS এক্সফিল্ট্রেশনের একটি বাস্তব লক্ষণ ব্যাখ্যা করা হয়েছে: হামলাকারীরা সাবডোমেইন ফিল্ডে ক্ষতিকারক পে-লোড লুকিয়ে রাখতে পারে, এবং সাধারণত বৈধ অনুরোধের ক্ষেত্রে কোয়েরির দৈর্ঘ্য যেখানে প্রায় ৬৩ থেকে ২৫৫ অক্ষরের হয়, সেখানে এক্সফিল্ট্রেশন প্রচেষ্টার ক্ষেত্রে তা ৫০০ অক্ষর ছাড়িয়ে যেতে পারে।
ক্যাশ পয়জনিং এবং ভুল উত্তর
ক্যাশে পয়জনিং-এর লক্ষ্য হলো রিজলভারের প্রতি বিশ্বাস নষ্ট করা। যদি কোনো আক্রমণকারী ক্যাশে একটি মিথ্যা উত্তর ইনজেক্ট করতে পারে, তবে যে ব্যবহারকারীরা বৈধ প্রশ্ন জিজ্ঞাসা করছেন তারাও ক্ষতিকারক গন্তব্যে পৌঁছাতে পারেন। একটি ভেন্যু পরিবেশে, এটি খুব দ্রুত অনেক ক্লায়েন্টকে প্রভাবিত করতে পারে কারণ শেয়ার্ড রিজলভারগুলো বিপুল সংখ্যক ব্যবহারকারীকে পরিষেবা দেয়।
বিপদ কেবল ফিশিংয়ের মধ্যেই সীমাবদ্ধ নয়। ইন্টারনাল অ্যাপ্লিকেশন, ক্লাউড পরিষেবা, আপডেট সিস্টেম এবং ভেন্ডর প্ল্যাটফর্ম - সবই সঠিক নেম রেজোলিউশনের ওপর নির্ভর করে। রিজলভার একবার ভুল ডেটা ফেরত দিলে, বাকি স্ট্যাকটি তার ডিজাইন অনুযায়ী কাজ করলেও ব্যবহারকারীদের ভুল জায়গায় নিয়ে যেতে পারে।
DNS টানেলিং এবং ডেটা এক্সফিল্ট্রেশন
DNS টানেলিং কুয়েরি ফিল্ডগুলোকে একটি গোপন ট্রান্সপোর্ট চ্যানেলে পরিণত করে। ঠিকানার জন্য জিজ্ঞাসা করতে শুধুমাত্র DNS ব্যবহার করার পরিবর্তে, ম্যালওয়্যার কুয়েরির নামের মধ্যেই তথ্য প্যাক করে ফেলে। একটি ক্ষতিকারক অথরিটেটিভ সার্ভার তখন বাইরে থেকে সেই টুকরোগুলোকে আবার পুনর্গঠন করে।
অঙ্গতিগুলি অত্যন্ত গুরুত্বপূর্ণ। খুব দীর্ঘ কুয়েরি স্ট্রিং, অস্বাভাবিক সংখ্যক ডট, অথবা অদ্ভুত সাবডোমেনের জন্য বারবার অনুরোধ ইঙ্গিত করতে পারে যে একটি ডিভাইস রেজোলিউশন ছাড়া অন্য কোনও কাজের জন্য DNS ব্যবহার করছে। একটি অতিথি বা মাল্টি-টেন্যান্ট নেটওয়ার্কে এটি অত্যন্ত গুরুত্বপূর্ণ কারণ প্রচলিত কন্ট্রোলগুলি সাধারণত ওয়েব ক্যাটাগরি এবং পরিচিত পোর্টগুলির ওপর ফোকাস করে, যেখানে DNS বেশিরভাগ ক্ষেত্রেই উপেক্ষিত থেকে যায়।
দীর্ঘ ও অস্বাভাবিক DNS কুয়েরিগুলি সর্বদা ক্ষতিকারক নয় এমন মনে করা ভুল হতে পারে। এটি নেটওয়ার্কের ক্ষেত্রে ফায়ার এক্সিট দিয়ে কারো ফাইল চুরি করে নিয়ে যাওয়ার সমতুল্য হতে পারে।
অনুমোদিত ট্রাফিকের উপর কমান্ড এবং কন্ট্রোল
আক্রমণকারীরা কমান্ড এবং নিয়ন্ত্রণের জন্যও DNS ব্যবহার করে কারণ এটি সাধারণ ট্রাফিকের সাথে মিশে যায়। এমনকি একটি কঠোরভাবে পরিচালিত নেটওয়ার্কেও প্রায়শই অনুমোদিত রিজলভারের কাছে DNS প্রবাহিত হতে দেওয়া হয়। ম্যালওয়্যার সেই নিয়মিত পথটিকে কাজে লাগিয়ে নির্দেশনা পুনরুদ্ধার করতে বা আক্রমণের পরবর্তী ধাপটি খুঁজে বের করতে পারে।
এটি বিশেষ করে হসপিটালিটি এবং রিটেল ক্ষেত্রে বেশ জটিল, কারণ সেখানে পরিবেশটি অত্যন্ত কোলাহলপূর্ণ থাকে। ডিভাইসগুলো ক্রমাগত আসে এবং চলে যায়। ব্রাউজার, অ্যাপ, লয়্যালটি প্ল্যাটফর্ম, গেস্ট অনবোর্ডিং সিস্টেম এবং বিজ্ঞাপন SDKs উচ্চ মাত্রার লুকআপ তৈরি করে। সেই ব্যাকগ্রাউন্ড ট্রাফিক দুর্বল মনিটরিংকে সহজেই এর ভেতরে লুকিয়ে রাখতে সাহায্য করে।
DDoS অ্যামপ্লিফিকেশন এবং সার্ভিসের ওপর চাপ
DNS-কে অ্যামপ্লিফিকেশনের জন্য হাতিয়ার হিসেবেও ব্যবহার করা যেতে পারে। ওপেন বা অপব্যবহৃত রিজলভারগুলি একটি বড় ডিনায়াল-অফ-সার্ভিস প্যাটার্নের অংশ হয়ে উঠতে পারে, তা লক্ষ্যবস্তু হিসেবে হোক বা অনিচ্ছাকৃত অংশগ্রহণকারী হিসেবে। এমনকি যখন আপনার সংস্থা সরাসরি ভিকটিম নাও হয়, তবুও অনিরাপদ DNS ডিজাইন অস্থিরতা তৈরি করতে পারে, রিসোর্স ব্যবহার করতে পারে এবং ইনসিডেন্ট রেসপন্সকে জটিল করে তুলতে পারে।
যেসব টিম গেস্ট WiFi পরিচালনা করছেন, তাদের জন্য DNS লেয়ারে ফিল্টারিং এবং নীতি প্রয়োগ করা যেমন প্রতিরক্ষামূলক, তেমনই কার্যকরীভাবে দরকারী হতে পারে। ডোমেইন স্তরের নিয়ন্ত্রণ কীভাবে নিরাপত্তা এবং ব্যবহারকারীর অভিজ্ঞতা উভয়কেই প্রভাবিত করে তা বিশদভাবে বুঝতে Purple-এর DNS filtering for guest WiFi blocking malware and inappropriate content গাইডটি পড়া অত্যন্ত প্রয়োজনীয়।
বাস্তব ক্ষেত্রে এটি দেখতে কেমন লাগে
DNS হুমকি সম্পর্কে চিন্তা করার একটি দরকারী উপায় হলো প্রোটোকলের বিবরণের চেয়ে ব্যবসার উপর এর প্রভাব বিবেচনা করা:
- ভুল রাউটিং: ব্যবহারকারীরা ভুল গন্তব্যে পৌঁছান।
- নীরব যোগাযোগ: সংক্রমিত ডিভাইসগুলি বাইরে যোগাযোগ চালিয়ে যায়।
- লুকানো এক্সফিল্ট্রেশন: ডেটা এমন প্যাটার্নে বাইরে চলে যায় যা দেখতে স্বাভাবিক লুকআপের মতো মনে হয়।
- পরিষেবা ব্যাহত হওয়া: বৈধ অ্যাক্সেস ধীর, অস্থিতিশীল বা অনুপলব্ধ হয়ে পড়ে।
এই কারণেই DNS সিকিউরিটি বিশেষজ্ঞদের জন্য কোনো নির্দিষ্ট বা ছোট বিষয় নয়। এটি এন্ডপয়েন্ট ডিফেন্স, অ্যাক্সেস কন্ট্রোল, ইনসিডেন্ট রেসপন্স এবং গ্রাহকদের মুখোমুখি নির্ভরযোগ্যতার এক অবিচ্ছেদ্য অংশ।
আপনার সুরক্ষামূলক টুলকিট DNSSEC DoH এবং DoT
গুরুত্বপূর্ণ DNS সুরক্ষার ডিজাইনে তিনটি প্রযুক্তি বারবার সামনে আসে: DNSSEC, DoH এবং DoT। এগুলো বিভিন্ন সমস্যার সমাধান করে। টিমগুলো প্রায়শই এগুলোকে একসাথে গুলিয়ে ফেলে, তারপর যখন কোনো একটি কন্ট্রোল তাদের প্রত্যাশিত হুমকি প্রতিরোধ করতে পারে না, তখন হতাশ হয়।
এদের আলাদা করার সবচেয়ে সহজ উপায়টি হলো - DNSSEC সত্যতা ও সততা (authenticity and integrity) রক্ষা করে। DoH এবং DoT ট্রানজিটে গোপনীয়তা রক্ষা করে। আপনার আর্কিটেকচারে সাধারণত এই উভয় ধারণারই প্রয়োজন হয় কারণ "এই উত্তরটি কি আসল?" এবং "পথে কি কেউ এই কুয়েরিটি দেখতে বা পরিবর্তন করতে পারে?" সম্পূর্ণ ভিন্ন দুটি প্রশ্ন।
ডিজিটাল মোমের সীলমোহর হিসেবে DNSSEC
DNSSEC DNS ডেটাতে স্বাক্ষর করে যাতে রিজলভাররা যাচাই করতে পারে যে উত্তরটি সঠিক উৎস থেকে এসেছে এবং এতে কোনো পরিবর্তন করা হয়নি। এটিকে একটি অফিসিয়াল চিঠির উপর মোমের সিলের মতো মনে করতে পারেন। সিলটি চিঠির বিষয়বস্তু লুকিয়ে রাখে না, তবে এটি আপনাকে জালিয়াতি সনাক্ত করতে সহায়তা করে।
এটি DNSSEC-কে স্পুফিং এবং ক্যাশ পয়জনিংয়ের বিরুদ্ধে বিশেষভাবে উপযোগী করে তোলে। যদি একটি রিজলভার DNSSEC যাচাই করে এবং সিগনেচার চেইনটি মেলার ক্ষেত্রে কোনো সমস্যা পায়, তবে এটি অন্ধভাবে বিশ্বাস করার পরিবর্তে উত্তরটি প্রত্যাখ্যান করতে পারে।
DNSSEC কুয়েরি এনক্রিপ্ট করে না। এটি মানুষ প্রায়ই খেয়াল করে না। এটি আপনাকে জানায় যে উত্তরটি নির্ভরযোগ্য। কিন্তু কোনো নামের জন্য অনুরোধ করা হয়েছিল তা পর্যবেক্ষকদের দেখা থেকে এটি আটকাতে পারে না।
এনক্রিপ্টেড কুরিয়ার হিসেবে DoH এবং DoT
DNS over HTTPS (DoH) এবং DNS over TLS (DoT) উভয়ই ক্লায়েন্ট এবং রিজলভারের মধ্যে, অথবা আপনার ডিজাইন অনুযায়ী নেটওয়ার্ক উপাদানগুলির মধ্যে DNS ট্রাফিক এনক্রিপ্ট করে। এদের কাজ হলো গোপনীয়তা এবং ট্রান্সপোর্ট সিকিউরিটি রক্ষা করা।
একটি সহজ উপমা দেওয়া যাক। DNSSEC যদি মোমের সিল হয়, তবে DoH এবং DoT হলো সুরক্ষিত কুরিয়ার খাম। এগুলি সাধারণ আড়ি পাতা বন্ধ করে এবং ট্রানজিটের সময় হস্তক্ষেপ করা কঠিন করে তোলে।
এই দুটির মধ্যে পার্থক্য মূলত অপারেশনাল বা কার্যপ্রণালী সংক্রান্ত:
- DoH এটি HTTPS-এর ভেতরে DNS পাঠায়। এটি ওয়েব-কেন্দ্রিক পরিবেশ এবং কিছু অ্যাপ্লিকেশন আর্কিটেকচারের সাথে চমৎকারভাবে খাপ খাইয়ে নিতে পারে।
- DoT এটি বিশেষভাবে DNS-এর জন্য TLS ব্যবহার করে। অনেক টিম এটিকে বেশি পছন্দ করে যখন তারা DNS ট্রাফিকের আরও স্পষ্ট বিভাজন এবং আরও সুনির্দিষ্ট নিয়ন্ত্রণ চায়।
DNS নিরাপত্তা প্রোটোকলসমূহের তুলনা
| প্রোটোকল | প্রাথমিক লক্ষ্য | কার্যপ্রণালী | যা থেকে রক্ষা করে | যার জন্য সবচেয়ে উপযোগী |
|---|---|---|---|---|
| DNSSEC | সত্যতা এবং অখণ্ডতা | DNS রেকর্ডে ক্রিপ্টোগ্রাফিক স্বাক্ষর | Spoofing, জাল প্রতিক্রিয়া, cache poisoning | DNS উত্তরগুলি খাঁটি কিনা তা যাচাই করা |
| DoH | ট্রানজিটে গোপনীয়তা | HTTPS-এর ভিতরে DNS এনক্রিপ্ট করে | Eavesdropping এবং ট্রানজিটকালীন হেরফের | ক্লায়েন্ট-মুখী পরিবেশ এবং ওয়েব-সংযুক্ত আর্কিটেকচার |
| DoT | ট্রানজিটে গোপনীয়তা | TLS-এর মাধ্যমে DNS এনক্রিপ্ট করে | Eavesdropping এবং ট্রানজিটকালীন হেরফের | রিজলভার-টু-ক্লায়েন্ট বা পরিচালিত নেটওয়ার্ক DNS গোপনীয়তা |
সঠিক মিশ্রণটি বেছে নেওয়া
আপনি যখন প্রতিটি কন্ট্রোলকে একটি নির্দিষ্ট ঝুঁকির সাথে ম্যাপ করবেন, তখন অনেক বিভ্রান্তি দূর হয়ে যাবে।
আপনি যদি ভুল DNS উত্তর নিয়ে চিন্তিত হন, তাহলে DNSSEC validation দিয়ে শুরু করুন।
আপনি যদি অনিরাপদ নেটওয়ার্কে কুয়েরির দৃশ্যমানতা নিয়ে চিন্তিত হন, তাহলে DoH বা DoT যোগ করুন।
আপনি যদি উভয়ের বিষয়েই গুরুত্ব দেন, তাহলে সত্যতা এবং এনক্রিপশন একত্রিত করুন।
প্রধান পার্থক্য: DNSSEC উত্তর দেয় "আমি কি এই উত্তরটি বিশ্বাস করতে পারি?" DoH এবং DoT উত্তর দেয় "যাওয়ার পথে কেউ কি এই কথোপকথনটি দেখতে বা এতে হস্তক্ষেপ করতে পারে?"
সাধারণ ডিজাইন বা নকশাগত ভুলসমূহ
টিমগুলো সাধারণত এড়ানো সম্ভব এমন তিনটি ভুল করে থাকে:
যাচাইকরণ ছাড়াই এনক্রিপশন মোতায়েন করা
কোয়েরিগুলো ট্রানজিটের সময় সুরক্ষিত থাকে, কিন্তু রিজলভার এখনও আপস্ট্রিমে অপ্রমাণিত ডেটা গ্রহণ করতে পারে।পরিচালনগত পরিকল্পনা ছাড়াই যাচাইকরণ সক্ষম করা
রেকর্ড বা ডেলিগেশন ভুলভাবে পরিচালিত হলে DNSSEC ব্যর্থতার পরিস্থিতি তৈরি করে, তাই পর্যবেক্ষণ এবং পরিবর্তন শৃঙ্খলা অত্যন্ত গুরুত্বপূর্ণ।গেস্ট নেটওয়ার্কে রিজলভারের আচরণ উপেক্ষা করা
গেস্ট ডিভাইসগুলো তাদের নিজস্ব DNS পছন্দগুলো ব্যবহার করতে পারে, যদি না আপনার নেটওয়ার্ক পলিসি এবং অনবোর্ডিং ডিজাইন সেটি বিবেচনা করে।
এন্টারপ্রাইজ এবং হাই-ট্রাফিক WiFi পরিবেশে, সবচেয়ে শক্তিশালী প্যাটার্নটি হলো লেয়ারড। যেখানে সত্যতা গুরুত্বপূর্ণ সেখানে যাচাই করুন। যেখানে কুয়েরির গোপনীয়তা গুরুত্বপূর্ণ সেখানে এনক্রিপ্ট করুন। রিজলভারে সুরক্ষামূলক পলিসি যুক্ত করুন যাতে DNS শুধুমাত্র একটি লুকআপ সার্ভিস না হয়ে একটি সক্রিয় কন্ট্রোল হিসেবে কাজ করতে পারে।
বাস্তব ক্ষেত্রে নিরাপদ DNS ডেপ্লয় করা
ডিজাইন করার ক্ষেত্রে প্রশ্নটি "আমাদের কি DNS সুরক্ষিত করা উচিত?" তা নয়। এটি হলো "আমরা এটি কোথায় প্রয়োগ করব এবং কীভাবে ব্যবহারকারীর অভিজ্ঞতা ব্যাহত করা এড়াব?" একটি পরিচালিত এন্টারপ্রাইজ নেটওয়ার্ক এবং একটি পাবলিক বা আধা-পাবলিক WiFi সার্ভিসের ক্ষেত্রে এর উত্তর ভিন্ন হয়।
আপনার আইডেন্টিটি প্ল্যাটফর্মে নিবন্ধিত একটি কর্পোরেট ল্যাপটপ আপনাকে কঠোর পলিসি প্রয়োগের সুযোগ দেয়। কিন্তু একটি হোটেলের লবিতে থাকা কোনো গেস্টের ফোন তা দেয় না। উভয়ের জন্যই এখনও নিরাপদ DNS প্রয়োজন, তবে কন্ট্রোলগুলো আলাদা জায়গায় কাজ করে।
এন্টারপ্রাইজ বা প্রাতিষ্ঠানিক দিক থেকে
কর্মী এবং পরিচালিত ডিভাইসগুলির জন্য, আপনার আর্কিটেকচার যতটুকু অনুমতি দেয় সেই অনুযায়ী DNS পলিসিকে কেন্দ্রীভূত করুন। এর অর্থ সাধারণত অনুমোদিত রিজলভার, যাচাইকৃত উত্তর, উপযুক্ত ক্ষেত্রে এনক্রিপ্ট করা ট্রান্সপোর্ট এবং আপনার মনিটরিং স্ট্যাকের মধ্যে স্পষ্ট টেলিমেট্রি রাখা।
একটি ব্যবহারিক ডেপ্লয়মেন্ট প্যাটার্ন দেখতে এইরকম হয়:
- পরিচালিত রিজলভার ব্যবহার করুন: কর্মীদের ডিভাইসগুলিকে আপনার নিয়ন্ত্রিত বা স্পষ্টভাবে বিশ্বস্ত রিজলভারের সাথে সংযুক্ত রাখুন, যাতে নীতি এবং লগিং সামঞ্জস্যপূর্ণ থাকে।
- সত্যতা যাচাই করুন: অভ্যন্তরীণ ব্যবহারকারী এবং গুরুত্বপূর্ণ ওয়ার্কফ্লোতে পরিষেবা প্রদানকারী রিজলভারগুলিতে DNSSEC যাচাইকরণ সক্ষম করুন।
- সংবেদনশীল পথগুলি এনক্রিপ্ট করুন: যেখানে কোয়েরির গোপনীয়তা গুরুত্বপূর্ণ সেখানে DoH বা DoT ব্যবহার করুন, বিশেষ করে কম বিশ্বস্ত সেগমেন্ট বা বাহ্যিক লিঙ্ক জুড়ে।
- শনাক্তকরণ কার্যক্রম পরিচালনায় যুক্ত করুন: রিজলভার লগগুলি আরও অনেক বেশি মূল্যবান হয়ে ওঠে যখন আপনার SOC বা NOC সেগুলিকে পরিচয়, এন্ডপয়েন্ট এবং ওয়্যারলেস ইভেন্টের সাথে মেলাতে পারে।
প্রতিরক্ষামূলক DNS সার্ভিসের জন্য এটিই সঠিক জায়গা যা কোনো কানেকশন তৈরি হওয়ার আগেই পরিচিত ক্ষতিকারক বা পলিসি লঙ্ঘনকারী গন্তব্যগুলোকে ব্লক করে দেয়। এটি ভালোভাবে ব্যবহার করলে, ট্রাফিকের গভীরে প্যাকেট ইন্সপেকশনের ওপর নির্ভর করার চেয়ে অনেক নিখুঁত নিয়ন্ত্রণ পাওয়া যায়।
গেস্ট WiFi-তে
গেস্ট WiFi-এর ক্ষেত্রে কিছুটা শিথিল হওয়া প্রয়োজন। মানুষ দ্রুত ও ঝামেলাহীন অ্যাক্সেস আশা করে। অতিরিক্ত কঠোর ফিল্টারিং বা রিজলভার নির্বাচন যা বিলম্ব বাড়িয়ে দেয়, তা ব্যবহারকারীরা আপনার সিকিউরিটি পরিস্থিতি বোঝার অনেক আগেই সাপোর্ট কলের পরিমাণ বাড়িয়ে দেবে।
উদ্দেশ্যটি সহজ: ব্রাউজিংকে মসৃণ রেখে দৃশ্যত ক্ষতিকারক বা অনুপযুক্ত রেজোলিউশন পথগুলি বন্ধ করা।
প্রথমে কোনটিকে অগ্রাধিকার দেবেন
- সুরক্ষিত আপস্ট্রিম DNS সরবরাহকারী নির্বাচন করুন: এমন সরবরাহকারী বেছে নিন যারা আধুনিক নিরাপত্তা নিয়ন্ত্রণ এবং স্থিতিশীল কর্মক্ষমতা সমর্থন করে।
- ক্যাটাগরি এবং হুমকি ফিল্টারিং সাবধানে প্রয়োগ করুন: ম্যালওয়্যার, ফিশিং এবং স্পষ্টতই অবাঞ্ছিত গন্তব্যগুলি ব্লক করুন, তবে সাধারণ অতিথি আচরণের সাথে নীতিগুলি পরীক্ষা করুন।
- রিজলভার পাথ অনুমানযোগ্য রাখুন: আপনার গেটওয়ে, কন্ট্রোলার বা এজ পরিষেবাগুলি এমনভাবে ডিজাইন করুন যাতে অতিথি DNS অনিয়ন্ত্রিত পাথে চলে না যায়।
- শুধুমাত্র পরিচিত ক্ষতিকারক ডোমেইন নয়, অসঙ্গতির দিকেও নজর রাখুন: টানেলিং এবং ডেটা চুরি প্রায়শই ব্লক তালিকায় উপস্থিত হওয়ার আগে অদ্ভুত কোয়েরি প্যাটার্ন হিসাবে দেখায়।
এই ক্যাটাগরিতে একটি ব্যবহারিক বিকল্প হলো Purple Shield, যা WiFi পরিবেশের জন্য DNS-লেয়ার ফিল্টারিং প্রয়োগ করে। একটি মিশ্র ভেন্যু এস্টেটে, এই ধরণের কন্ট্রোল বিদ্যমান নেটওয়ার্ক হার্ডওয়্যারের উপরে কাজ করতে পারে এবং সেশন স্থাপন করার আগেই ঝুঁকিপূর্ণ ডোমেনগুলোকে ব্লক করতে পারে।
সবচেয়ে গুরুত্বপূর্ণ অপারেশনাল অভ্যাসসমূহ
কনফিগারেশন কেবল কাজের অর্ধেক অংশ। অপারেশনাল হাইজিন বা স্বাস্থ্যবিধি শিথিল হয়ে পড়লে কোনো নোটিশ ছাড়াই DNS নিরাপত্তা ব্যর্থ হতে পারে।
| কার্যক্ষম অনুশীলন | এটি কেন গুরুত্বপূর্ণ |
|---|---|
| DNS রেকর্ড এবং রিজলভারের জন্য পরিবর্তন নিয়ন্ত্রণ | আকস্মিক বিভ্রাট এবং যাচাইকরণ ব্যর্থতা হ্রাস করে |
| ফিল্টারিং সিদ্ধান্তের নিয়মিত পর্যালোচনা | অতিথিদের ত্রুটিপূর্ণ অভিজ্ঞতা এবং অতিরিক্ত ব্লকিং প্রতিরোধ করে |
| পরিচয় বা ব্যবহারকারীর ধরন অনুযায়ী টেলিমেট্রি পর্যালোচনা | কর্মীদের ঝুঁকি থেকে অতিথিদের কার্যকলাপ আলাদা করতে সহায়তা করে |
| ঘটনা সম্পর্কিত প্লেবুক যাতে DNS প্রমাণ অন্তর্ভুক্ত থাকে | যখন লক্ষণগুলি একাধিক সিস্টেমে ছড়িয়ে পড়ে তখন তদন্তের গতি বাড়ায় |
যদি আপনার ইনসিডেন্ট প্রসেস ঘটনার আগে ডিভাইসটি কী রিজলভ করেছিল তা বিশ্লেষণ না করে, তবে আপনি প্রায়শই অনেক দেরিতে কাজ শুরু করছেন।
যেখানে টিমগুলো আটকে যায়
অধিকাংশ ডিপ্লয়মেন্ট সংক্রান্ত সমস্যা দুটি ধারণার যেকোনো একটি থেকে তৈরি হয়। প্রথমত, টিমগুলো মনে করে সিকিউর DNS শুধুমাত্র পেরিমিটার বা বাহ্যিক সীমানার বিষয়। বিষয়টি কিন্তু তা নয়। ইন্টারনাল রিজলভারের আচরণও ঠিক সমভাবেই গুরুত্বপূর্ণ। দ্বিতীয়ত, তারা ধরে নেয় কোনো ঝামেলা তৈরি না করে গেস্ট ট্রাফিককে অর্থপূর্ণভাবে সুরক্ষিত করা সম্ভব নয়। সেটিও সঠিক নয়। সঠিকভাবে ডিজাইন করা DNS কন্ট্রোল সাধারণত ব্যবহারকারীর অভিজ্ঞতাকে আরও উন্নত করে, কারণ ব্যবহারকারীরা দেখার আগেই এটি ক্ষতিকারক ক্ষতিকর পথগুলো দূর করে দেয়।
বাস্তব ক্ষেত্রে সুরক্ষিত DNS কোনো একটি নির্দিষ্ট প্রোডাক্ট বা প্রোটোকলের চেয়ে সঠিক স্থানে নিয়ন্ত্রণের ওপর বেশি নির্ভর করে। রিজলভার-এ সঠিক নিয়ন্ত্রণ রাখুন, সেগুলিকে ব্যবহারকারীর ধরণের সাথে সামঞ্জস্যপূর্ণ করুন এবং DNS টেলিমেট্রিকে আপনার সাধারণ নেটওয়ার্ক অপারেশনের অংশ করে তুলুন।
আপনার Zero Trust নেটওয়ার্কে DNS একীভূত করা
বেশিরভাগ Zero Trust প্রোগ্রাম শুরু হয় আইডেন্টিটি দিয়ে। এটি যৌক্তিকও বটে। আপনি জানতে চান ব্যবহারকারী কে, তারা কোন ডিভাইসে আছেন এবং তাদের কী অ্যাক্সেস করার অনুমতি থাকা উচিত। কিন্তু অনেক পরিবেশ সেখানেই থেমে যায়। তারা সেশন অথেন্টিকেট করে, নেটওয়ার্ক সেগমেন্ট করে, এবং তবুও DNS-কে একটি উন্মুক্ত ইউটিলিটির মতো সচল রেখে দেয়।
সেই ব্যবধান আরও স্পষ্ট হয়ে উঠেছে। Zero Trust কৌশলে DNS-কে অনুপস্থিত সংযোগকারী হিসেবে Cygnalabs-এর বিশ্লেষণে উল্লেখিত RSA Conference 2025-এর আলোচনায় বলা হয়েছে যে সুরক্ষামূলক DNS পরিষেবাগুলোর ব্যবহার বাড়ছে, কিন্তু ফিশিং, র্যানসমওয়্যার এবং ডেটা চুরির মূলে DNS-এর অপব্যবহার থাকা সত্ত্বেও এর বাস্তবায়ন অসামঞ্জস্যপূর্ণ রয়ে গেছে। একই সূত্র নির্দেশ করে যে পাসওয়ার্ডহীন প্রমাণীকরণ ব্যবস্থা এবং Zero Trust নেটওয়ার্কে DNS সুরক্ষাকে একীভূত করার অমীমাংসিত চ্যালেঞ্জ রয়েছে, যাতে ল্যাটারাল মুভমেন্ট এবং DNS চ্যানেলের মাধ্যমে ডেটা নিষ্কাশন প্রতিরোধ করা যায়।
নীতি প্রয়োগের পয়েন্ট হিসেবে DNS
এই পর্যায়ে, DNS শুধুমাত্র একটি সাপোর্ট সার্ভিস হিসেবে কাজ করা বন্ধ করে এবং একটি পলিসি প্রয়োগের পয়েন্ট (policy enforcement point) হিসেবে কাজ করতে শুরু করে। একটি রিজলভার খুব শুরুতেই উদ্দেশ্য বুঝতে পারে। একজন ব্যবহারকারী বা ডিভাইস কোনো অ্যাপ্লিকেশনে পৌঁছানোর আগেই এটি একটি নাম জিজ্ঞাসা করে। সেই কুয়েরিটি পলিসি, আইডেন্টিটি, ঝুঁকির সংকেত এবং থ্রেট ইন্টেলিজেন্সের বিরুদ্ধে পরীক্ষা করা যেতে পারে।
এই RSA Conference 2025 DNS নিরাপত্তা সারসংক্ষেপে NIST SP 800-81 রিভিশন ৩-এর এপ্রিল ২০২৫-এর আলোচনায় DNS-কে Zero Trust ইঞ্জিনের ইনপুট হিসেবে কোয়েরি আচরণ ব্যবহার করে অ্যাক্সেসের সিদ্ধান্তগুলো কার্যকর করার একটি উপায় হিসেবে বর্ণনা করা হয়েছে, যা পলিসি লঙ্ঘন করলে অনুরোধগুলো ব্লক বা রিডাইরেক্ট করার অনুমতি দেয়। পরিচয়-ভিত্তিক নেটওয়ার্কিংয়ের জন্য, এটিই হলো "এই ডিভাইসটি প্রমাণীকৃত" এবং "এই ডিভাইসটি এখনই এই গন্তব্য সমাধান করতে পারে" এর মধ্যকার অনুপস্থিত সংযোগ।
আইডেন্টিটি-অ্যাওয়ার বা পরিচয়-সচেতন DNS দেখতে কেমন হয়
একটি আধুনিক WiFi পরিবেশে, আপনি নিম্নোক্ত বিষয়ের মতো কনটেক্সটের সাথে DNS নীতি যুক্ত করতে পারেন:
- ব্যবহারকারীর ধরন: গেস্ট, কর্মী, ঠিকাদার, টেন্যান্ট, আনম্যানেজড ডিভাইস
- অথেন্টিকেশন অবস্থা: প্রি-লগইন, নতুন অনবোর্ড করা, সম্পূর্ণ বিশ্বস্ত
- ডিভাইসের অবস্থা: ম্যানেজড, আনম্যানেজড, লেগ্যাসি, শেয়ার্ড-ইউজ
- অবস্থান বা ভেন্যু ভূমিকা: ফ্রন্ট-অফিস, ব্যাক-অফিস, ক্লিনিক্যাল, রিটেইল ফ্লোর, রেসিডেন্ট নেটওয়ার্ক
একটি ডিরেক্টরি-ইন্টিগ্রেটেড ওয়ার্কফ্লোর মাধ্যমে অথেন্টিকেট করা স্টাফ ল্যাপটপ এবং একটি গেস্ট ফোন বা IoT ডিসপ্লে একই গন্তব্যে পৌঁছানো উচিত নয়। DNS পলিসি প্রতিটি সিদ্ধান্তকে ফায়ারওয়াল ইন্সপেকশনের দিকে ঠেলে না দিয়েই এটি বাস্তবায়ন করতে পারে।
এই কারণেই সঠিক ডোমেইন হাইজিন বজায় রাখা অত্যন্ত গুরুত্বপূর্ণ। আপনার রেকর্ড, নামকরণের মানদণ্ড এবং মালিকানার মডেল যদি বিশৃঙ্খল হয়, তবে সুসংগতভাবে নীতি প্রয়োগ করা আরও কঠিন হয়ে পড়ে। একটি কার্যকরী এবং দরকারী রেফারেন্স হলো OneNine-এর ডোমেইন এবং DNS ব্যবস্থাপনার কৌশল বিষয়ক গাইড, বিশেষ করে সেইসব টিমের জন্য যারা সামগ্রিক সিকিউরিটি কন্ট্রোলের সাথে DNS গভর্নেন্সকে মেলাতে কাজ করছেন।
উচ্চ-ট্রাফিক বিশিষ্ট WiFi-তে কেন এটি গুরুত্বপূর্ণ
আইডেন্টিটি-ভিত্তিক নেটওয়ার্কিং প্ল্যাটফর্মগুলি নির্ধারণ করতে পারে কে বা কী নেটওয়ার্কে যুক্ত হয়েছে। DNS পরবর্তী যৌক্তিক নিয়ন্ত্রণ যুক্ত করে: সেই এন্টিটিকে কোন নামগুলি রিসলভ করার অনুমতি দেওয়া হয়েছে। একটি Purple ডেপ্লয়মেন্ট মডেলে, এই সংযোগটি গুরুত্বপূর্ণ কারণ গেস্ট, কর্মী এবং মাল্টি-টেন্যান্ট ব্যবহারকারীরা একই পরিকাঠামো শেয়ার করেন অথচ তাদের আলাদা ট্রাস্ট বাউন্ডারি বা বিশ্বাসের সীমানার প্রয়োজন হয়। DNS পলিসি আপনাকে সেই সীমানাগুলি দ্রুত এবং অলক্ষ্যে প্রয়োগ করতে সাহায্য করে।
উদাহরণস্বরূপ, একটি অতিথি ডিভাইসকে সাধারণ ব্রাউজিংয়ের অনুমতি দেওয়া যেতে পারে তবে ম্যালওয়্যার ছড়ানোর সাথে জড়িত ডোমেনগুলি রিসলভ করা থেকে ব্লক করা যেতে পারে। একটি কর্মী ডিভাইসকে অভ্যন্তরীণ SaaS এবং অপারেশনাল পরিষেবাগুলিতে অ্যাক্সেসের অনুমতি দেওয়া যেতে পারে তবে সন্দেহজনক গন্তব্যগুলি ব্লক রাখা যেতে পারে। একটি লেগ্যাসি ডিভাইসকে কঠোরভাবে সীমাবদ্ধ করা যেতে পারে, এমনকি যদি এটি আরও উন্নত এন্ডপয়েন্ট কন্ট্রোল সমর্থন করতে না পারে তবুও।
আপনি যদি আরও বিস্তৃত অ্যাক্সেস মডেল ডিজাইন করতে চান, তবে Purple-এর জিরো ট্রাস্ট নেটওয়ার্ক অ্যাক্সেস ইমপ্লিমেন্টেশন স্ট্র্যাটেজি এবং বেস্ট প্র্যাকটিস গাইডটি কীভাবে নেটওয়ার্ক আইডেন্টিটি এবং পলিসি একসাথে কাজ করে তার দরকারী প্রসঙ্গ প্রদান করে।
সবচেয়ে পরিচ্ছন্ন Zero Trust নিয়ন্ত্রণ প্রায়শই শুরুর দিকের পদক্ষেপ হয়ে থাকে। কোনো ডিভাইস যদি গন্তব্যটি সমাধানই করতে না পারে, তবে ঝুঁকিপূর্ণ সেশনটি কখনই শুরু হয় না।
একটি উন্নত মানসিক মডেল
পরিচয়কে একটি পাসপোর্ট চেকিংয়ের মতো এবং DNS-কে একটি রুট কন্ট্রোল বা পথ নিয়ন্ত্রণ হিসেবে বিবেচনা করুন। অথেন্টিকেশন আপনাকে জানায় কে প্রবেশ করেছে। আর DNS নীতি আপনাকে জানায় যে কোনো নির্দিষ্ট গন্তব্যের দিকে যাওয়ার অনুমতি তাদের আছে কি না।
এই দ্বিতীয় স্তরটি ছাড়া, জিরো ট্রাস্ট অদ্ভুতভাবে অতিরিক্ত অনুমতিমূলক হয়ে উঠতে পারে। ব্যবহারকারীরা ভেরিফাইড হন, কিন্তু তাদের ডিভাইসগুলি এখনও যেকোনো কিছুর অবস্থান জিজ্ঞাসা করার ক্ষেত্রে ব্যাপক স্বাধীনতা পায়। DNS-কে এই মডেলে যুক্ত করলে সেই ভারসাম্যহীনতা দূর হয়।
DNS-কে আপনার প্রতিরক্ষার প্রথম স্তর করে তোলা
DNS সংক্রান্ত পুরনো দৃষ্টিভঙ্গি ছিল কেবল প্রশাসনিক। রেকর্ডগুলো গুছিয়ে রাখা, রেজোলিউশন দ্রুত রাখা এবং তারপর "আসল" সুরক্ষা স্তরগুলোতে চলে যাওয়া। এন্টারপ্রাইজ এবং গেস্ট কানেক্টিভিটি পরিবেশে সেই দৃষ্টিভঙ্গি আর কার্যকর নয়, যেখানে যেকোনো দরকারী কাজ শুরু হওয়ার আগেই প্রতিটি ডিভাইস DNS-এর ওপর নির্ভর করে।
DNS এখন বিশ্বাসের সূচনাবিন্দুতে অবস্থান করে। ব্যবহারকারীরা সঠিক পরিষেবাতে পৌঁছাচ্ছেন কিনা, ম্যালওয়্যার তার কন্ট্রোলার খুঁজে পাচ্ছে কিনা, তথ্য অলক্ষ্যে বাইরে চলে যাচ্ছে কিনা এবং Zero Trust পলিসি যথাসময়ে কার্যকর হচ্ছে কিনা তা এটি নির্ধারণ করে। যদি সেই লেয়ারটি দুর্বল হয়, তবে আপনার অন্যান্য কন্ট্রোলগুলি কানেকশনের একদম শুরুতেই থাকা একটি ত্রুটি পূরণ করতেই তাদের বেশিরভাগ সময় ব্যয় করে।
বাস্তব শিক্ষণীয় বিষয়
একটি দীর্ঘস্থায়ী DNS এবং নিরাপত্তা কৌশলে সাধারণত চারটি ধারণা একসাথে কাজ করে:
- অখণ্ডতা নিয়ন্ত্রণ: যেখানে উত্তরের সত্যতা যাচাইয়ের বিষয় রয়েছে, সেখানে DNSSEC ব্যবহার করুন।
- গোপনীয়তা নিয়ন্ত্রণ: যেখানে কোয়েরির গোপনীয়তা রক্ষার বিষয় রয়েছে, সেখানে DoH বা DoT ব্যবহার করুন।
- প্রতিরক্ষামূলক নীতি: রিজলভারের মাধ্যমে ঝুঁকিপূর্ণ, ক্ষতিকারক বা অনুপযুক্ত রেজোলিউশন পাথ ব্লক করুন।
- পরিচয় সংক্রান্ত প্রসঙ্গ: ব্যবহারকারী কে, তাদের কাছে কী ডিভাইস আছে এবং নেটওয়ার্কে তাদের অবস্থান কোথায় - তার ওপর ভিত্তি করে বিভিন্ন DNS সিদ্ধান্ত প্রয়োগ করুন।
এই কম্বিনেশনটি বিশেষ করে হসপিটালিটি, রিটেইল, হেলথকেয়ার, ট্রান্সপোর্ট এবং রেসিডেন্সিয়াল ডেপ্লয়মেন্টের জন্য কার্যকর, যেখানে একটি একক এস্টেটে একই সাথে গেস্ট অ্যাক্সেস, স্টাফ অ্যাক্সেস এবং অপারেশনাল ডিভাইস চালু থাকতে পারে।
পরিপক্ক টিমগুলো কী ভিন্নভাবে করে
অভিজ্ঞ টিমগুলো DNS লগগুলোকে ব্যাকগ্রাউন্ডের কোলাহল হিসেবে বিবেচনা করা বন্ধ করে দেয়। তারা ট্রাবলশুটিং, ঘটনার প্রতিক্রিয়া এবং অ্যাক্সেস গভর্নেন্সে DNS প্রমাণ ব্যবহার করে। তারা অথেন্টিকেশন ইভেন্টের পাশাপাশি রিজলভারের আচরণ পর্যালোচনা করে। তারা কানেক্টিভিটিকে জটিল না করে ক্ষতি কমানোর জন্য গেস্ট WiFi পলিসি ডিজাইন করে।
ওয়্যারলেস পরিবেশের জন্য ব্যাপক সুরক্ষা মডেলের সাথে DNS কীভাবে খাপ খায় সে সম্পর্কে আরও জানতে চাইলে, Purple-এর নেটওয়ার্ক এবং ওয়্যারলেস সুরক্ষা সংক্রান্ত নিবন্ধটি আপনার পরবর্তী পড়ার জন্য একটি উপযুক্ত বিষয়।
সবচেয়ে দরকারী পরিবর্তনটি হলো ধারণাগত। DNS-এর সাথে সিকিউরিটি যুক্ত করার প্রয়োজন আছে কিনা তা জিজ্ঞাসা করবেন না। জিজ্ঞাসা করুন আপনার সিকিউরিটি কাঠামোর কতটা অংশ ইতিমধ্যে DNS-এর উপর নির্ভর করে, আপনি এর জন্য পরিকল্পনা করেছিলেন বা না করেছিলেন। একবার আপনি DNS-কে একটি কন্ট্রোল প্লেন হিসাবে দেখলে, অগ্রাধিকারগুলি আরও স্পষ্ট হয়ে ওঠে।
Purple সংস্থাগুলিকে অতিথি, কর্মী এবং মাল্টি-টেন্যান্ট পরিবেশের জন্য আইডেন্টিটি-ভিত্তিক WiFi অ্যাক্সেস প্রদান করতে সাহায্য করে, যার মধ্যে একটি বৃহত্তর সুরক্ষিত কানেক্টিভিটি কৌশলের অংশ হিসেবে DNS-লেয়ার সুরক্ষা সমর্থনকারী বিকল্পগুলি অন্তর্ভুক্ত রয়েছে। অথেন্টিকেশন, পলিসি এবং ব্যবহারকারীর অভিজ্ঞতা কীভাবে একসাথে কাজ করা উচিত তা নিয়ে আপনি যদি নতুন করে চিন্তা করেন, তবে Purple এক্সপ্লোর করুন।
