একজন অতিথি আপনার হোটেলের WiFi-এ যুক্ত হলেন। একজন স্টাফ সদস্য Entra ID-এর মাধ্যমে একই নেটওয়ার্ক ফ্যামিলিতে সাইন ইন করলেন। একটি পয়েন্ট-অব-সেল ট্যাবলেট স্বয়ংক্রিয়ভাবে পুনরায় সংযুক্ত হলো। কাগজে-কলমে, আপনি কঠিন কাজটি করে ফেলেছেন। পরিচয় পরিচালনা করা হয়েছে, SSIDs আলাদা করা হয়েছে, সার্টিফিকেট ইস্যু করা হয়েছে এবং আপনার ফায়ারওয়াল নিয়মগুলো পরিষ্কার দেখাচ্ছে।
তারপর একটি শান্ত DNS অনুরোধ সেগুলোর সবগুলোকে এড়িয়ে চলে যায়।
এটি এমন একটি অংশ যা অনেক দল মিস করে। বেশিরভাগ ডিভাইস প্রথম যে প্রশ্নটি জিজ্ঞাসা করে তা কিন্তু "আমি কি এই নেটওয়ার্কে আসার অনুমতি পেয়েছি?" নয়। এটি হলো "আমি যেখানে পৌঁছাতে চাই তা কোথায়?" যদি আপনার DNS লেয়ার অন্ধভাবে সেই প্রশ্নের উত্তর দেয়, তবে একজন আক্রমণকারী এমন একটি প্রোটোকলের অপব্যবহার করতে পারে যা প্রায় প্রতিটি নেটওয়ার্ক ডিফল্টরূপে অনুমতি দেয়। ব্যস্ত আতিথেয়তা, খুচরা বিক্রয়, স্বাস্থ্যসেবা এবং মিশ্র-ব্যবহারের পরিবেশে, এটি অ্যাক্সেস কন্ট্রোল এবং প্রকৃত সুরক্ষার মধ্যে একটি গুরুতর ব্যবধান।
ভালো dns and security অনুশীলন সেই ব্যবধানটি বন্ধ করে দেয়। এটি DNS-কে কেবল ব্যাকগ্রাউন্ড অবকাঠামোর চেয়ে বেশি কিছু হিসাবে বিবেচনা করে। এটি সততা, গোপনীয়তা, নীতি এবং দৃশ্যমানতার জন্য একটি নিয়ন্ত্রণ পয়েন্ট হয়ে ওঠে, বিশেষ করে এমন নেটওয়ার্কগুলোতে যেখানে অতিথি ট্রাফিক, স্টাফ ট্রাফিক এবং অপারেশনাল ডিভাইসগুলো একসাথে সহাবস্থান করে।
আপনার নেটওয়ার্কের অদৃশ্য দুর্বলতা
একটি সাধারণ ব্যর্থতা কোনো নাটকীয় অ্যালার্ট দিয়ে শুরু হয় না। এটি শুরু হয় ছোট কিছু দিয়ে। একজন অতিথির ডিভাইস একটি ভেন্যু নেটওয়ার্কে যোগ দেয় এবং একটি ক্ষতিকারক অনুরূপ ডোমেন রিসলভ করে। একটি ব্যাক-অফিস ল্যাপটপ একটি পয়জনড DNS প্রতিক্রিয়ার মাধ্যমে ভুল পরিষেবাতে চলে যায়। একটি সংক্রমিত ডিভাইস একটি রিমোট কন্ট্রোলারের সাথে যোগাযোগ করতে DNS ব্যবহার করে কারণ আউটবাউন্ড ওয়েব ট্রাফিক কঠোরভাবে ফিল্টার করা হলেও, DNS-কে এখনও ব্যাপকভাবে বিশ্বাস করা হয়।
এই প্রক্রিয়াটি সাধারণ মনে হয় কারণ DNS ট্রাফিক প্রথমে সর্বদা সাধারণ দেখায়। প্রতিটি ফোন, ট্যাবলেট, ব্রাউজার, ক্যাশ রেজিস্টার, স্মার্ট টিভি এবং স্ক্যানার এর ওপর নির্ভর করে। প্রতিটি লগইন এবং অ্যাপ্লিকেশন কল যে নাম-রেজোলিউশন সিস্টেমের ওপর নির্ভর করে, দলগুলো প্রায়শই সেই সিস্টেমটিকে সুরক্ষিত করার চেয়ে লগইন ফ্লো সুরক্ষিত করার জন্য বেশি সময় ব্যয় করে।
কেন DNS বোর্ড-স্তরের মনোযোগ পাওয়ার যোগ্য
যুক্তরাজ্যের ডেটা উপেক্ষা করা কঠিন। এই DNS ইতিহাস এবং নিরাপত্তা ওভারভিউতে উদ্ধৃত যুক্তরাজ্যের NCSC ডেটা অনুসারে, ২০২১ থেকে ২০২২ সালের মধ্যে DNS অপব্যবহারের রিপোর্ট ৪৪% বৃদ্ধি পেয়ে ৩৫৬,৪৬৩টি ঘটনায় পৌঁছেছে। একই উৎস উল্লেখ করেছে যে ২০২৩ সালের মধ্যে, স্বাস্থ্যসেবা এবং পরিবহনের মতো গুরুত্বপূর্ণ খাতগুলোতে রিপোর্ট করা সমস্ত সাইবার ঘটনার ২৫% ছিল DNS-ভিত্তিক আক্রমণ।
এই পরিসংখ্যানগুলো গুরুত্বপূর্ণ কারণ প্রভাবিত খাতগুলো দেখতে অনেকটাই আধুনিক উচ্চ-ট্রাফিক WiFi পরিবেশের মতো। তারা অবিরাম সংযোগ, মিশ্র ডিভাইসের উপস্থিতি এবং এমন পরিষেবাগুলোর ওপর নির্ভর করে যেগুলোর নাম দ্রুত এবং নির্ভরযোগ্যভাবে রিসলভ করা প্রয়োজন। যদি DNS আপোস করা হয়, তবে ব্যবহারকারীর অভিজ্ঞতা হ্রাস পায় এবং একই সাথে নিরাপত্তা ভেঙে পড়ে।
DNS isn't just part of the path. In many environments, it's the first security decision a device encounters.
বাস্তব কার্যকলাপে এটি যেখানে প্রকাশ পায়
ব্যবসায়িক প্রভাব সাধারণত তিনটি ক্ষেত্রে লক্ষ্য করা যায়:
- নিরাপত্তা ঝুঁকি (Security exposure): ব্যবহারকারীদের ক্ষতিকারক গন্তব্যে রিডাইরেক্ট করা হতে পারে, ম্যালওয়্যার কমান্ড-অ্যান্ড-কন্ট্রোল ডোমেন রিসলভ করতে পারে এবং এমন কিছু চ্যানেলের মাধ্যমে নেটওয়ার্ক থেকে ডেটা বাইরে চলে যেতে পারে যা অনেক কন্ট্রোল উপেক্ষা করে।
- কার্যকরী ব্যাঘাত (Operational disruption): স্টাফ অ্যাপগুলো মাঝে মাঝে ব্যর্থ হয়, captive ওয়ার্কফ্লো অদ্ভুত আচরণ করে এবং ট্রাবলশুটিং ধীর গতির হয়ে যায় কারণ লক্ষণগুলো সাধারণ কানেক্টিভিটি সমস্যার মতো দেখায়।
- গ্রাহক অভিজ্ঞতা (Customer experience): গেস্টরা এটা ভাবেন না যে সমস্যাটি DNS স্পুফিং, ফিল্টারিং ত্রুটি বা রিজলভার টাইমআউটের কারণে হয়েছে। তারা কেবল এটাই বোঝেন যে WiFi নির্ভরযোগ্য মনে হচ্ছে না।
টিম যখন DNS-কে কেবল প্লাumbing-এর মতো না দেখে একটি সিকিউরিটি প্লেন বা স্তর হিসেবে বিবেচনা করা শুরু করে, তখন তারা প্রতিটি কানেক্টিভিটিতে কোনো ঝামেলা তৈরি না করেই ঝুঁকি নিয়ন্ত্রণ করার একটি পরিষ্কার পথ পেয়ে যায়।
DNS নিরাপত্তা সংক্রান্ত অন্ধ গলিপথ (DNS Security Blind Spot) বোঝা
"ইন্টারনেটের ফোনবুক" তুলনাটি বেশ পরিচিত। এটি দরকারী হলেও সম্পূর্ণ নয়। DNS কেবল নাম খুঁজে বের করে না। এটি ডিভাইসগুলোকে পরবর্তীতে কোথায় যেতে হবে তা নির্দেশ করে, প্রায়শই কোনো শক্তিশালী সিকিউরিটি কন্ট্রোল কাজ করার সুযোগ পাওয়ার আগেই। এটি এটিকে ফোনবুকের চেয়ে পুরো নেটওয়ার্কের একটি নির্দেশক সাইনপোস্ট সিস্টেমের মতো করে তোলে।
এই সিকিউরিটি ব্লাইন্ড স্পট বা অন্ধ গলিপথ তৈরি হয় DNS-এর আদিম ধারণার কারণে। এটি এমন একটি উন্মুক্ত ইন্টারনেটের জন্য তৈরি করা হয়েছিল, যেখানে রিজলভার এবং অথোরেটেটিভ সার্ভারগুলোকে বিশ্বস্ত মনে করা হতো। আধুনিক এন্টারপ্রাইজ এবং গেস্ট WiFi পরিবেশগুলো সেই জগতে কাজ করে না। এগুলোতে অবিশ্বাস্য ক্লায়েন্ট, রোমিং ডিভাইস, থার্ড-পার্টি সার্ভিস এবং এমন সব অ্যাপ্লিকেশন থাকে যা দ্রুত ও অবিচ্ছিন্ন রেজোলিউশনের ওপর নির্ভর করে।
লুকআপের সময় আসলে কী ঘটে
যখন কোনো ব্যবহারকারী একটি অ্যাপ খোলেন বা একটি সাইট ভিজিট করেন, তখন ডিভাইসটি প্রথমে একটি ডোমেন নামের সাথে লিঙ্ক করা ঠিকানার জন্য একটি রিজলভারকে জিজ্ঞাসা করে। যদি রিজলভারের কাছে ইতিমধ্যে উত্তরটি ক্যাশ করা থাকে, তবে এটি দ্রুত উত্তর দেয়। যদি না থাকে, তবে এটি উত্তর না পাওয়া পর্যন্ত DNS হায়ারার্কির মধ্য দিয়ে রিকোয়েস্টটি নিয়ে যায় এবং ক্লায়েন্টের কাছে ফেরত পাঠায়।
এটি সহজ শোনালেও, এই প্রক্রিয়ার মধ্যে কয়েকটি বিশ্বাসের ধারণা কাজ করে:
- ক্লায়েন্ট রিজলভারকে বিশ্বাস করে সঠিকভাবে উত্তর দেওয়ার জন্য।
- রিজলভার আপস্ট্রিম ডেটাকে বিশ্বাস করে যতক্ষণ না পর্যন্ত যাচাইকরণ সম্পন্ন হচ্ছে।
- ট্রান্সপোর্ট এনক্রিপ্ট করা না থাকলে যেকোনো ব্যক্তি এই পথটি পর্যবেক্ষণ করে কোয়েরিটি জেনে নিতে পারে।
- পলিসি সাধারণত পরে প্রয়োগ করা হয়, DNS ডিভাইসটিকে একটি গন্তব্যের দিকে নির্দেশ করার পর।
একটি শক্তিশালী আইডেন্টিটি স্ট্যাক একাই এই বিষয়গুলোকে ঠিক করতে পারে না। DNS-এর সততা বা গোপনীয়তা দুর্বল হলে একজন ব্যবহারকারী নিখুঁতভাবে প্রমাণীকরণ (authenticate) করার পরেও ভুল জায়গায় চলে যেতে পারেন।
টিমগুলো কেন এই সমস্যাটিকে অবমূল্যায়ন করে
DNS প্রায়শই নেপথ্যে চলে যায় কারণ এটি একটি শেয়ারড ইনফ্রাস্ট্রাকচার। এটি ঠিকঠাক কাজ করার সময় কেউ এটি খেয়াল করে না। কিন্তু এটি ব্যর্থ হলে, এর লক্ষণগুলো ব্রাউজার, অ্যাপ, API, ওয়্যারলেস অনবোর্ডিং এবং ক্লাউড অ্যাক্সেসের ওপর ছড়িয়ে পড়ে, যার ফলে টিমগুলো প্রথমে ভুল লেয়ারে সমস্যা খোঁজা শুরু করে।
এখানেই পাঠকরা সাধারণত বিভ্রান্ত হন: তারা ধরে নেন যে অ্যাপ্লিকেশন ট্রাফিক যেহেতু TLS ব্যবহার করে, তাই DNS ইতিমধ্যেই সুরক্ষিত। আসলে সাধারণত তা নয়। চূড়ান্ত সার্ভিসের সাথে এনক্রিপ্ট করা সেশন শুরু হওয়ার আগেই প্রথাগত DNS কুয়েরিগুলো দৃশ্যমান হতে পারে বা সেগুলোতে হস্তক্ষেপ করা হতে পারে।
ব্যবহারিক নিয়ম: আপনি যদি আইডেন্টিটি, WiFi অথেন্টিকেশন এবং অ্যাপ্লিকেশন সেশন সুরক্ষিত করেন কিন্তু DNS-কে আন-অথেন্টিকেটেড বা আন-এনক্রিপ্টেড রেখে দেন, তবে আপনি সংযোগের শুরুটাই সুরক্ষিত করতে পারেননি।
আর্কিটেকচারাল দুর্বলতা
আপনি নিজে উদ্যোগী হয়ে সমাধান না করা পর্যন্ত DNS-এর দুটি মূল দুর্বলতা রয়েই যায়:
| দুর্বলতা | ব্যবহারিক ক্ষেত্রে এর অর্থ কী | এটি কেন গুরুত্বপূর্ণ |
|---|---|---|
| কোনো বিল্ট-ইন অথেনটিসিটি নেই | একটি ক্লায়েন্ট কোনো জাল বা ম্যানিপুলেট করা উত্তর গ্রহণ করতে পারে | ইউজার এবং ডিভাইসগুলোকে অন্য দিকে রিডাইরেক্ট করা যেতে পারে |
| কোনো বিল্ট-ইন কনফিডেন্সিয়ালিটি নেই | অন্যান্য পক্ষ কুয়েরি পাথ পর্যবেক্ষণ করতে পারে | ব্রাউজিংয়ের উদ্দেশ্য, সার্ভিসের ব্যবহার এবং ডিভাইসের আচরণ প্রকাশ হয়ে যেতে পারে |
এই কারণেই আইডেন্টিটি, সেগমেন্টেশন এবং অ্যাক্সেস পলিসির মতোই একই আলোচনায় DNS এবং সিকিউরিটিকেও রাখা উচিত। টিমগুলোর অসাবধানতার কারণে DNS ব্যর্থ হচ্ছে না। এটি ব্যর্থ হচ্ছে কারণ অনেক ডেপ্লয়মেন্ট এখনও এমন ট্রাস্ট মডেলের ওপর নির্ভর করে যা বর্তমানের প্রকৃত নেটওয়ার্ক পরিস্থিতির সাথে আর সামঞ্জস্যপূর্ণ নয়।
আধুনিক DNS থ্রেট ল্যান্ডস্কেপ
আক্রমণকারীরা DNS পছন্দ করে কারণ ডিফেন্ডারদের এটি ব্যবহারের অনুমতি দিতেই হয়। যে ডিভাইস নাম রিসলভ করতে পারে না, সেটি প্রায় কোনো কাজই করতে পারে না, তাই DNS হলো এমন কয়েকটি প্রোটোকলের একটি যা প্রায় প্রতিটি নেটওয়ার্ক জুড়েই ব্যাপকভাবে অনুমোদিত থাকে। এটি একে রিডাইরেকশন, কোভার্ট সিগন্যালিং এবং বড় আকারের অপব্যবহারের জন্য একটি সুবিধাজনক পথ বানিয়ে তোলে।
এর পরিধি অনেক বড়। EfficientIP-এর DNS রিস্ক অ্যাসেসমেন্ট -এ উল্লেখ করা Forrester 2025-এর ডেটা অনুযায়ী, ৯৫% প্রতিষ্ঠান DNS-এর মাধ্যমে আক্রমণের শিকার হয়েছে। একই সোর্সে DNS এক্সফিল্ট্রেশনের একটি ব্যবহারিক লক্ষণ ব্যাখ্যা করা হয়েছে: হামলাকারীরা সাবডোমেইন ফিল্ডে পেলোড লুকিয়ে রাখতে পারে এবং যেখানে বৈধ রিকোয়েস্টের ক্ষেত্রে কুয়েরির দৈর্ঘ্য সাধারণত ৬৩ থেকে ২৫৫ অক্ষরের মতো হয়, সেখানে এক্সফিল্ট্রেশনের প্রচেষ্টায় এটি ৫০০ অক্ষর ছাড়িয়ে যেতে পারে।
ক্যাশে পয়জনিং এবং ভুল উত্তর
Cache poisoning টার্গেট করে রিজলভারের ওপর ভরসাকে। কোনো আক্রমণকারী যদি ক্যাশে একটি ভুল উত্তর ইনজেক্ট করতে পারে, তবে যে ব্যবহারকারীরা বৈধ প্রশ্ন করছেন তারা একটি ক্ষতিকারক গন্তব্যের তথ্য পেতে পারেন। একটি ভেন্যু পরিবেশে, এটি খুব দ্রুত অনেক ক্লায়েন্টকে প্রভাবিত করতে পারে কারণ শেয়ার্ড রিজলভারগুলো বিশাল সংখ্যক ব্যবহারকারীকে পরিষেবা দেয়।
বিপদ কেবল ফিশিং-এর মধ্যেই সীমাবদ্ধ নয়। ইন্টারনাল অ্যাপ্লিকেশন, ক্লাউড সার্ভিস, আপডেট সিস্টেম এবং ভেন্ডর প্ল্যাটফর্ম সবই সঠিক নেম রিজল্যুশনের ওপর নির্ভর করে। একবার রিজলভার ভুল ডেটা রিটার্ন করলে, সিস্টেমের বাকি অংশটি ডিজাইন অনুযায়ী কাজ করলেও ব্যবহারকারীদের ভুল জায়গায় নিয়ে যেতে পারে।
DNS tunnelling এবং ডেটা এক্সফিলট্রেশন
DNS tunnelling কোয়েরি ফিল্ডগুলোকে একটি গোপন ট্রান্সপোর্ট চ্যানেলে পরিণত করে। ঠিকানার জন্য শুধুমাত্র DNS ব্যবহার করার পরিবর্তে, ম্যালওয়্যার কোয়েরি নামের মধ্যেই তথ্য প্যাক করে দেয়। একটি ক্ষতিকারক অথরিটেটিভ সার্ভার তখন বাইরে থেকে সেই অংশগুলোকে পুনরায় জোড়া লাগায়।
অসংগতিগুলো অত্যন্ত গুরুত্বপূর্ণ। খুব দীর্ঘ কোয়েরি স্ট্রিং, অস্বাভাবিক সংখ্যার ডট, অথবা অদ্ভুত সাবডোমেনের জন্য বারবার অনুরোধ ইঙ্গিত করতে পারে যে একটি ডিভাইস রিজল্যুশন ছাড়া অন্য কিছুর জন্য DNS ব্যবহার করছে। একটি গেস্ট বা মাল্টি-টেন্যান্ট নেটওয়ার্কে এটি গুরুত্বপূর্ণ কারণ প্রথাগত নিয়ন্ত্রণগুলো ওয়েব ক্যাটাগরি এবং পরিচিত পোর্টগুলোর ওপর ফোকাস করতে পারে, যেখানে DNS-কে মূলত অবহেলিত রেখে দেওয়া হয়।
দীর্ঘ এবং অদ্ভুত DNS কোয়েরিগুলো সবসময়ই যে ক্ষতিকারক নয়, তা কিন্তু নয়। এগুলো নেটওয়ার্কের ক্ষেত্রে ফায়ার এক্সিট দিয়ে কেউ ফাইল চুরি করে নিয়ে যাওয়ার সমতুল্য হতে পারে।
অনুমোদিত ট্রাফিকের ওপর কমান্ড এবং কন্ট্রোল
আক্রমণকারীরা কমান্ড এবং কন্ট্রোলের জন্যও DNS ব্যবহার করে কারণ এটি সাধারণ ট্রাফিকের সাথে মিশে যায়। এমনকি একটি শক্তভাবে পরিচালিত নেটওয়ার্কও প্রায়শই অনুমোদিত রিজলভারগুলোতে DNS প্রবাহিত করার অনুমতি দেয়। ম্যালওয়্যার নির্দেশাবলী পুনরুদ্ধার করতে বা আক্রমণের পরবর্তী ধাপটি সনাক্ত করতে এই রুটিন পাথটির অপব্যবহার করতে পারে।
হসপিটালিটি এবং রিটেইল সেক্টরে এটি বিশেষভাবে জটিল কারণ এই পরিবেশগুলো খুবই কোলাহলপূর্ণ। ডিভাইসগুলো ক্রমাগত আসে এবং যায়। ব্রাউজার, অ্যাপ, লয়্যালটি প্ল্যাটফর্ম, গেস্ট অনবোর্ডিং সিস্টেম এবং অ্যাডভার্টাইজিং SDK প্রচুর পরিমাণে লুকআপ তৈরি করে। এই ব্যাকগ্রাউন্ড ট্রাফিকের কারণে দুর্বল মনিটরিং সহজেই আড়ালে পড়ে যায়।
DDoS অ্যামপ্লিফিকেশন এবং সার্ভিস স্ট্রেন
DNS-কে অ্যামপ্লিফিকেশনের জন্য হাতিয়ার হিসেবেও ব্যবহার করা যেতে পারে। উন্মুক্ত বা অপব্যবহৃত রিজলভারগুলো একটি বৃহত্তর ডিনায়েল-অফ-সার্ভিস প্যাটার্নের অংশ হতে পারে, হয় লক্ষ্য হিসেবে অথবা অনিচ্ছাকৃত অংশগ্রহণকারী হিসেবে। এমনকি আপনার সংস্থা যখন চূড়ান্ত শিকার নাও হতে পারে, তখনও অসুরক্ষিত DNS ডিজাইন অস্থিরতা তৈরি করতে পারে, রিসোর্স গ্রাস করতে পারে এবং ইন্সিডেন্ট রেসপন্সকে জটিল করে তুলতে পারে।
গেস্ট WiFi পরিচালনাকারী টিমগুলোর জন্য, এই কারণেই DNS লেয়ারে ফিল্টারিং এবং পলিসি প্রয়োগ করা সুরক্ষার পাশাপাশি অপারেশনাল দিক থেকেও কার্যকর হতে পারে। আপনি যদি ডোমেন-স্তরের নিয়ন্ত্রণ কীভাবে নিরাপত্তা এবং ব্যবহারকারীর অভিজ্ঞতা উভয়কে প্রভাবিত করে তা পর্যালোচনা করতে চান, তবে Purple-এর DNS filtering for guest WiFi blocking malware and inappropriate content গাইডটি পড়ার মতো একটি বিষয়।
বাস্তব ক্ষেত্রে এটি দেখতে কেমন হয়
DNS হুমকি সম্পর্কে চিন্তা করার একটি দরকারী উপায় হলো প্রোটোকল বিশদ বিবরণের চেয়ে ব্যবসার উপর এর প্রভাব বিবেচনা করা:
- ভুল ডিরেকশন (Misrouting): ব্যবহারকারীরা ভুল গন্তব্যে পৌঁছান।
- নীরব যোগাযোগ (Silent communication): সংক্রমিত ডিভাইসগুলো বাইরে যোগাযোগ অব্যাহত রাখে।
- লুকানো তথ্য চুরি (Hidden exfiltration): ডেটা এমন প্যাটার্নে বাইরে চলে যায় যা দেখতে স্বাভাবিক লুকআপের মতো মনে হয়।
- পরিষেবা ব্যাহত হওয়া (Service disruption): বৈধ অ্যাক্সেস ধীর, অস্থিতিশীল বা অনুপলব্ধ হয়ে পড়ে।
সেজন্য DNS সিকিউরিটি কেবল বিশেষজ্ঞদের জন্য কোনো বিশেষ নিয়ন্ত্রণ নয়। এটি একই সাথে এন্ডপয়েন্ট ডিফেন্স, অ্যাক্সেস কন্ট্রোল, ইন্সিডেন্ট রেসপন্স এবং গ্রাহক-মুখী নির্ভরযোগ্যতার অংশ।
আপনার ডিফেন্সিভ টুলকিট DNSSEC DoH এবং DoT
গুরুত্বপূর্ণ DNS সিকিউরিটি ডিজাইনে তিনটি প্রযুক্তি বারবার সামনে আসে: DNSSEC, DoH, এবং DoT। এগুলো বিভিন্ন সমস্যার সমাধান করে। টিমগুলো প্রায়শই এগুলোকে একসাথে মিলিয়ে ফেলে, এবং পরবর্তীতে কোনো একটি নিয়ন্ত্রণ তাদের কাঙ্ক্ষিত হুমকি প্রতিরোধ করতে না পারলে হতাশ হয়।
এগুলোকে আলাদা করার সবচেয়ে সহজ উপায় হলো - DNSSEC সত্যতা এবং অখণ্ডতা (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 Security প্রোটোকলের তুলনা
| প্রোটোকল | প্রাথমিক লক্ষ্য | কার্যপ্রণালী | যা থেকে রক্ষা করে | যার জন্য সবচেয়ে উপযুক্ত |
|---|---|---|---|---|
| DNSSEC | প্রামাণিকতা এবং অখণ্ডতা | DNS রেকর্ডে ক্রিপ্টোগ্রাফিক স্বাক্ষর | স্পুফিং, জাল প্রতিক্রিয়া, ক্যাশ পয়জনিং | DNS উত্তরগুলো যে আসল তা যাচাই করা |
| DoH | ট্রানজিটে গোপনীয়তা | HTTPS-এর মধ্যে DNS এনক্রিপ্ট করে | আড়িপাতা এবং ট্রানজিটকালীন হেরফের | ক্লায়েন্ট-মুখী পরিবেশ এবং ওয়েব-সংযুক্ত আর্কিটেকচার |
| DoT | ট্রানজিটে গোপনীয়তা | TLS-এর মাধ্যমে DNS এনক্রিপ্ট করে | আড়িপাতা এবং ট্রানজিটকালীন হেরফের | রিজলভার-টু-ক্লায়েন্ট বা পরিচালিত নেটওয়ার্ক DNS গোপনীয়তা |
সঠিক সমন্বয় নির্বাচন করা
যখন আপনি প্রতিটি নিয়ন্ত্রণকে একটি নির্দিষ্ট ঝুঁকির সাথে মিলিয়ে দেখেন, তখন অনেক বিভ্রান্তি দূর হয়ে যায়।
আপনি যদি ভুল DNS উত্তর নিয়ে চিন্তিত হন, তবে DNSSEC যাচাইকরণ দিয়ে শুরু করুন।
আপনি যদি বিশ্বস্ত নয় এমন নেটওয়ার্কে কুয়েরি দৃশ্যমানতা নিয়ে চিন্তিত হন, তবে 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 কনফারেন্স ২০২৫-এর আলোচনায় বলা হয়েছে যে সুরক্ষামূলক DNS সার্ভিসগুলো জনপ্রিয়তা পাচ্ছে, কিন্তু এর প্রয়োগ এখনও অসঙ্গতিপূর্ণ - যদিও DNS অপব্যবহারের মাধ্যমেই ফিশিং, র্যানসমওয়্যার এবং ডেটা চুরির মতো ঘটনা ঘটে। একই উৎস পাসওয়ার্ডহীন প্রমাণীকরণ সিস্টেম এবং Zero Trust নেটওয়ার্কে DNS চ্যানেলের মাধ্যমে ল্যাটারাল মুভমেন্ট এবং ডেটা এক্সফিল্ট্রেশন প্রতিরোধে DNS সিকিউরিটি সমন্বিত করার অমীমাংসিত চ্যালেঞ্জের দিকেও ইঙ্গিত করে।
পলিসি প্রয়োগের একটি মাধ্যম হিসেবে DNS
এই পর্যায়ে, DNS একটি সাধারণ সাপোর্ট সার্ভিস হিসেবে কাজ করা বন্ধ করে দেয় এবং একটি policy enforcement point হিসেবে কাজ করা শুরু করে। একটি রিসলভার খুব আগেই ব্যবহারকারীর উদ্দেশ্য দেখতে পায়। কোনো ব্যবহারকারী বা ডিভাইস কোনো অ্যাপ্লিকেশনে পৌঁছানোর আগে, এটি একটি নামের অনুরোধ করে। সেই কোয়েরিটি পলিসি, আইডেন্টিটি, ঝুঁকির সংকেত এবং থ্রেট ইন্টেলিজেন্সের সাথে মিলিয়ে পরীক্ষা করা যেতে পারে।
এই RSA Conference 2025 DNS security summary -এ NIST SP 800-81 রিভিশন ৩-এর এপ্রিল ২০২৫-এর আলোচনায় DNS-কে জিরো ট্রাস্ট ইঞ্জিনের ইনপুট হিসেবে কোয়েরি আচরণ ব্যবহার করে অ্যাক্সেসের সিদ্ধান্তগুলো প্রয়োগ করার একটি উপায় হিসেবে বর্ণনা করা হয়েছে, যা পলিসি লঙ্ঘন করার সাথে সাথে অনুরোধগুলোকে ব্লক বা রিডাইরেক্ট করার অনুমতি দেয়। আইডেন্টিটি-ভিত্তিক নেটওয়ার্কিংয়ের জন্য, এটিই হলো "এই ডিভাইসটি অথেন্টিকেটেড" এবং "এই ডিভাইসটি এখন এই ডেস্টিনেশন রিসলভ করতে পারে"-এর মধ্যকার অনুপস্থিত সংযোগ।
আইডেন্টিটি-অ্যাওয়ার DNS দেখতে কেমন হয়
একটি আধুনিক WiFi পরিবেশে, আপনি নিম্নোক্ত প্রাসঙ্গিক বিষয়ের সাথে DNS পলিসি সংযুক্ত করতে পারেন:
- ব্যবহারকারীর ধরন: অতিথি, কর্মী, ঠিকাদার, ভাড়াটে, আনম্যানেজড ডিভাইস
- অথেন্টিকেশন অবস্থা: লগইন করার পূর্বের অবস্থা, সদ্য যুক্ত হওয়া, সম্পূর্ণ বিশ্বস্ত
- ডিভাইসের অবস্থা: ম্যানেজড, আনম্যানেজড, লিগ্যাসি, শেয়ার্ড-ইউজ
- অবস্থান বা ভেন্যু ভূমিকা: ফ্রন্ট-অফিস, ব্যাক-অফিস, ক্লিনিক্যাল, রিটেইল ফ্লোর, রেসিডেন্ট নেটওয়ার্ক
একটি ডিরেক্টরি-ইন্টিগ্রেটেড ওয়ার্কফ্লোর মাধ্যমে অথেন্টিকেটেড হওয়া কর্মীর ল্যাপটপ এবং একজন অতিথির ফোন বা একটি IoT ডিসপ্লে একই ডেস্টিনেশন রিসলভ করা উচিত নয়। ফায়ারওয়াল ইন্সপেকশনের ওপর প্রতিটি সিদ্ধান্তের চাপ না দিয়েও DNS পলিসি এটি নিশ্চিত করতে পারে।
এই কারণেই সঠিক ডোমেন হাইজিন বজায় রাখা এখনো গুরুত্বপূর্ণ। আপনার রেকর্ড, নাম রাখার নিয়ম এবং মালিকানা মডেল যদি অগোছালো হয়, তবে পলিসিগুলো সব জায়গায় একইভাবে প্রয়োগ করা কঠিন হয়ে পড়ে। ডোমেন ও DNS গভর্নেন্সকে আরও ব্যাপক সিকিউরিটি কন্ট্রোলের সাথে সামঞ্জস্যপূর্ণ করার জন্য ওয়াননাইনের Strategies for domain and DNS management গাইডটি একটি প্রয়োজনীয় অপারেশনাল রেফারেন্স হতে পারে।
উচ্চ-ট্রাফিকযুক্ত WiFi-তে কেন এটি গুরুত্বপূর্ণ
আইডেন্টিটি-ভিত্তিক নেটওয়ার্কিং প্ল্যাটফর্মগুলো নির্ধারণ করতে পারে যে কে বা কী নেটওয়ার্কে যুক্ত হয়েছে। DNS এর পরবর্তী যৌক্তিক নিয়ন্ত্রণ যোগ করে: সেই এন্টিটি কোন নামগুলো রিসলভ করার অনুমতি পাবে। একটি Purple ডিপ্লয়মেন্ট মডেলে, এই সংযোগটি গুরুত্বপূর্ণ কারণ অতিথি, কর্মী এবং মাল্টি-টেন্যান্ট ব্যবহারকারীরা একই ইনফ্রাস্ট্রাকচার শেয়ার করে, অথচ তাদের জন্য ভিন্ন ট্রাস্ট বাউন্ডারির প্রয়োজন হয়। DNS পলিসি আপনাকে সেই বাউন্ডারিগুলো আগে এবং নির্বিঘ্নে প্রয়োগ করতে সাহায্য করে।
উদাহরণস্বরূপ, একটি অতিথি ডিভাইসকে সাধারণ ব্রাউজিংয়ের অনুমতি দেওয়া যেতে পারে কিন্তু ম্যালওয়্যার ছড়ানোর সাথে জড়িত ডোমেনগুলো রিসলভ করা ব্লক করা যেতে পারে। অন্যদিকে, একটি স্টাফ ডিভাইসকে অভ্যন্তরীণ SaaS এবং অপারেশনাল সার্ভিসগুলো অ্যাক্সেস করার অনুমতি দেওয়া যেতে পারে এবং একই সাথে সন্দেহজনক ডেস্টিনেশনগুলোতে অ্যাক্সেস ব্লক রাখা যেতে পারে। একটি লিগ্যাসি ডিভাইস যদি সমৃদ্ধ এন্ডপয়েন্ট কন্ট্রোল সমর্থন করতে নাও পারে, তবুও সেটিকে কঠোরভাবে সীমাবদ্ধ করা সম্ভব।
যদি আপনি আরও ব্যাপক অ্যাক্সেস মডেল ডিজাইন করছেন, তাহলে Purple-এর জিরো ট্রাস্ট নেটওয়ার্ক অ্যাক্সেস বাস্তবায়ন কৌশল এবং সর্বোত্তম অনুশীলন নির্দেশিকা নেটওয়ার্কের পরিচয় এবং নীতি কীভাবে একসাথে কাজ করে তার দরকারী প্রসঙ্গ প্রদান করে।
সবচেয়ে পরিচ্ছন্ন জিরো ট্রাস্ট নিয়ন্ত্রণ সাধারণত প্রাথমিক নিয়ন্ত্রণই হয়ে থাকে। কোনো ডিভাইস যদি গন্তব্যটি কখনই সমাধান করতে না পারে, তবে ঝুঁকিপূর্ণ সেশনটি কখনই শুরু হয় না।
একটি আরও ভালো মানসিক মডেল
পরিচয়কে পাসপোর্ট চেকের মতো এবং DNS-কে রুট নিয়ন্ত্রণের মতো মনে করুন। প্রমাণীকরণ আপনাকে বলে যে কে এসেছে। DNS পলিসি আপনাকে বলে যে তাদের একটি নির্দিষ্ট গন্তব্যের দিকনির্দেশ পাওয়ার অনুমতি আছে কিনা।
সেই দ্বিতীয় স্তরটি ছাড়া, জিরো ট্রাস্ট অদ্ভুতভাবে অনুমতিমূলক হয়ে উঠতে পারে। ব্যবহারকারীরা যাচাইকৃত হয়, কিন্তু তাদের ডিভাইসগুলো এখনও যেকোনো কিছু কোথায় আছে তা জিজ্ঞাসা করার ব্যাপক স্বাধীনতা পায়। মডেলে DNS যুক্ত করা সেই অমিল দূর করে।
DNS-কে আপনার সুরক্ষার প্রথম সারিতে পরিণত করা
DNS-এর পুরানো দৃষ্টিভঙ্গি ছিল প্রশাসনিক। রেকর্ডগুলো গুছিয়ে রাখুন, রেজোলিউশন দ্রুত রাখুন এবং "আসল" নিরাপত্তা স্তরগুলোতে চলে যান। এন্টারপ্রাইজ এবং গেস্ট কানেক্টিভিটি পরিবেশে সেই দৃষ্টিভঙ্গি আর কার্যকর নয় যেখানে প্রতিটি ডিভাইস যেকোনো দরকারী কাজ ঘটার আগে DNS-এর ওপর নির্ভর করে।
DNS এখন বিশ্বাসের শুরুতে অবস্থান করে। এটি ব্যবহারকারীরা সঠিক পরিষেবাতে পৌঁছাবে কিনা, ম্যালওয়্যার তার কন্ট্রোলার খুঁজে পাবে কিনা, ডেটা অলক্ষ্যে বাইরে চলে যেতে পারে কিনা এবং জিরো ট্রাস্ট পলিসি যথেষ্ট আগে কাজ করে কিনা তা প্রভাবিত করে। যদি সেই স্তরটি দুর্বল হয়, তবে আপনার বাকি নিয়ন্ত্রণগুলো সংযোগের একেবারে শুরুতে থাকা একটি ত্রুটি পূরণ করতেই তাদের সময় ব্যয় করবে।
ব্যবহারিক সমাধান
একটি টেকসই DNS এবং নিরাপত্তা কৌশলে সাধারণত চারটি ধারণা একসাথে কাজ করে:
- অখণ্ডতা নিয়ন্ত্রণ: যেখানে উত্তরের নির্ভরযোগ্যতা গুরুত্বপূর্ণ সেখানে DNSSEC ব্যবহার করুন।
- গোপনীয়তা নিয়ন্ত্রণ: যেখানে কোয়েরির গোপনীয়তা গুরুত্বপূর্ণ সেখানে DoH বা DoT ব্যবহার করুন।
- প্রতিরক্ষামূলক পলিসি: রিসলভারে ঝুঁকিপূর্ণ, ক্ষতিকারক বা অনুপযুক্ত রেজোলিউশন পথগুলো ব্লক করুন।
- পরিচয় প্রসঙ্গ: ব্যবহারকারী কে, তাদের কোন ডিভাইস আছে এবং তারা নেটওয়ার্কের কোথায় অবস্থান করছেন তার ওপর ভিত্তি করে বিভিন্ন DNS সিদ্ধান্ত প্রয়োগ করুন।
সেই সমন্বয়টি বিশেষ করে আতিথেয়তা, খুচরা বিক্রেতা, স্বাস্থ্যসেবা, পরিবহন এবং আবাসিক স্থাপনাগুলোতে উপযোগী যেখানে একটি এস্টেট একই সাথে গেস্ট অ্যাক্সেস, স্টাফ অ্যাক্সেস এবং অপারেশনাল ডিভাইসগুলো পরিচালনা করতে পারে।
পরিপক্ক দলগুলো কী ভিন্নভাবে করে
পরিপক্ক দলগুলো DNS লগগুলোকে ব্যাকগ্রাউন্ডের নয়েজ হিসেবে বিবেচনা করা বন্ধ করে। তারা সমস্যা সমাধান, ঘটনার প্রতিক্রিয়া এবং অ্যাক্সেস পরিচালনায় DNS প্রমাণ ব্যবহার করে। তারা প্রমাণীকরণ ইভেন্টগুলোর সাথে রিসলভারের আচরণ পর্যালোচনা করে। তারা সংযোগটিকে বিরূপ না করে ক্ষতি কমানোর জন্য গেস্ট WiFi পলিসি ডিজাইন করে।
আপনি যদি ওয়্যারলেস পরিবেশের জন্য ব্যাপক সুরক্ষা মডেলের মধ্যে DNS কীভাবে কাজ করে সে সম্পর্কে আরও ধারণা পেতে চান, তবে Purple-এর নেটওয়ার্ক এবং ওয়্যারলেস নিরাপত্তা সংক্রান্ত তথ্য পড়া একটি ভালো সিদ্ধান্ত হবে।
সবচেয়ে দরকারী পরিবর্তনটি হলো ধারণাগত। DNS-এর সাথে অতিরিক্ত নিরাপত্তা যুক্ত করার প্রয়োজন আছে কি না তা জিজ্ঞাসা করবেন না। বরং জিজ্ঞাসা করুন, আপনার নিরাপত্তা ব্যবস্থার কতটা ইতিমধ্যেই DNS-এর ওপর নির্ভর করছে, তা আপনি পরিকল্পনা করে থাকুন বা না থাকুন। একবার আপনি DNS-কে একটি কন্ট্রোল প্লেন হিসেবে দেখলে, অগ্রাধিকারগুলো আরও স্পষ্ট হয়ে ওঠে।
Purple বিভিন্ন প্রতিষ্ঠানকে অতিথি, কর্মী এবং মাল্টি-টেন্যান্ট পরিবেশের জন্য আইডেন্টিটি-ভিত্তিক WiFi অ্যাক্সেস প্রদান করতে সাহায্য করে, যেখানে একটি বৃহত্তর নিরাপদ কানেক্টিভিটি কৌশলের অংশ হিসেবে DNS-লেয়ার সুরক্ষার সুবিধা রয়েছে। আপনি যদি অথেন্টিকেশন, পলিসি এবং ব্যবহারকারীর অভিজ্ঞতা কীভাবে একসাথে কাজ করা উচিত তা নিয়ে নতুন করে ভেবে থাকেন, তবে Purple এক্সপ্লোর করুন।
