VPN ব্যবহারকারীর নাম লগ পাইপলাইন থেকে কোথায় হারায়?
লগের গোপনীয়তা নিয়ন্ত্রণ পরিবর্তনের আগে গেটওয়ে ইভেন্ট, সংগ্রাহকের কাঁচা অনুলিপি, সূচিবদ্ধ ইভেন্ট এবং অনুসন্ধান-সময়ের ফিল্ড তুলনা করুন।
সেশনগুলো ড্যাশবোর্ডে দেখা যায় অথচ ব্যবহারকারীর নামের কলামটি খালি থাকে, আর প্রথম প্রবৃত্তি হলো পার্সারকে দোষ দেওয়া। সেই প্রবৃত্তি আগের তিনটি ধাপ এড়িয়ে যায় যেখানে মানটি হারিয়ে যেতে পারত। একটি গেটওয়ে নীতিমালা অনুযায়ী পরিচয় মাস্ক করতে পারে, একটি ইনজেশন নিয়ম সূচিবদ্ধ করার আগেই তা মুছে ফেলতে পারে, আর অনুসন্ধান-সময়ের নিষ্কাশন কেবল তার নাম বলতেই ব্যর্থ হতে পারে। সমাধান নির্ভর করে কোন সীমান্তটিকে আপনি দায়ী বলে প্রমাণ করতে পারেন তার উপর, তাই কাজটি হলো তুলনা, কনফিগারেশন নয়।
ড্যাশবোর্ড থেকে নয়, একটি ইভেন্ট থেকে শুরু করুন
একটি মাত্র প্রমাণীকরণ ইভেন্ট বেছে নিন এবং লিখে রাখুন কী তাকে চিহ্নিত করে: গেটওয়ের মডেল ও সংস্করণ, প্রমাণীকরণ পদ্ধতি, ইভেন্ট শনাক্তকারী, সময়চিহ্ন এবং উৎস ঠিকানা। ব্যবহারকারীর নামটি ঠিক যেমন ব্যক্তিটি টাইপ করেছে তেমনভাবে যোগ করুন, বড়-ছোট হাতের অক্ষরসহ, কারণ হাতের অক্ষরে সংবেদনশীল অনুসন্ধান একটি বিদ্যমান ফিল্ড লুকিয়ে ফেলতে পারে। পরবর্তী প্রতিটি তুলনার জন্য সেই ইভেন্টটিকেই মানদণ্ড ধরুন।
ইভেন্টের ধরনগুলো একই স্কিমা ভাগ করে না। একটি ব্যর্থ প্রচেষ্টা, ক্লায়েন্টবিহীন সফল লগইন এবং একটি টানেল পুনঃসংযোগ প্রত্যেকটি ভিন্ন ফিল্ড তৈরি করতে পারে, আর কিছু গেটওয়ে পরিচয় বাদ দেয় যখন প্রচেষ্টাটি ব্যবহারকারী প্রমাণীকরণ পর্যন্ত পৌঁছায়নি। তাই এক ধরনের ইভেন্টে খালি কলাম পাইপলাইনের সমস্যার দুর্বল প্রমাণ।
বাস্তব কর্মীর অ্যাকাউন্টের বদলে অনুমোদিত পরীক্ষামূলক পরিচয় নিয়ে কাজ করুন, আর তুলনাটি লগ ডেটার উপর ইতিমধ্যে প্রযোজ্য অ্যাক্সেস নিয়মের ভেতরেই রাখুন। নমুনা পেতে বিস্তৃতভাবে বিস্তারিত প্রমাণীকরণ লগিং চালু করা সেই সিস্টেমটিকেই বদলে দেয় যা আপনি মাপতে চাইছেন।
চারটি সীমান্ত ধারাবাহিকভাবে তুলনা করুন
মানটি চারটি বিন্দুর একটিতে হারিয়ে যেতে পারে। প্রতিটি বিন্দুর মালিক আলাদা এবং মেরামতও আলাদা।
| Boundary | What to compare | A gap means |
|---|---|---|
| Gateway event view | The device's own event display and logging policy | The identity was masked or never emitted |
| Collector receive | The raw event as received, before parsing | Transport, filter or source selection dropped it |
| Index-time pipeline | Transforms applied before storage | Redaction or rewriting removed the value |
| Search-time extraction | The field name and regex used by the query | The label does not match the stored key |
যে প্রথম সীমান্তে মানটি হারিয়ে যায় সেখানেই থামুন। ডিভাইসের দৃশ্য ও কাঁচা অনুলিপির মধ্যে অমিল পরিবহন বা সংগ্রাহক কনফিগারেশনের দিকে ইঙ্গিত করে; সেখানে মিল থাকলেও সূচিবদ্ধ ইভেন্টে মান অনুপস্থিত থাকা কোনো রূপান্তরের দিকে ইঙ্গিত করে; সূচিবদ্ধ ইভেন্টে মান থাকা সত্ত্বেও ড্যাশবোর্ডে না থাকা নিষ্কাশন বা কোয়েরির দিকে ইঙ্গিত করে।
এই ক্রমটি গুরুত্বপূর্ণ কারণ প্রতিটি পরবর্তী ধাপ কেবল তথ্য হারাতে পারে, কখনও তা ফিরিয়ে আনতে পারে না। একটি রেগুলার এক্সপ্রেশন সেই স্ট্রিং ফিরিয়ে আনতে পারে না যা আগের ধাপ প্লেসহোল্ডার দিয়ে বদলে দিয়েছে, আর একটি গোপনীয়তা সেটিং এমন মান ব্যাখ্যা করতে পারে না যা কখনও পাঠানোই হয়নি।
উৎসে মাস্কিং নীতিমালা, পার্সারের বাগ নয়
Cisco-র ASA লগিং ডকুমেন্টেশন ব্যবহারকারীর নাম লুকানোকে একটি কনফিগারযোগ্য আচরণ হিসেবে বর্ণনা করে, যার মধ্যে অবৈধ বা অজানা ব্যবহারকারীর নাম কীভাবে উপস্থাপিত হয় তাও আছে। তাই উৎস ইভেন্টে মাস্ক করা পরিচয় ঠিক তাই হতে পারে যা গোপনীয়তা নীতিমালা দাবি করে, আর এটিকে পার্সিং ব্যর্থতা হিসেবে দেখা এমন একটি অনুরোধের দিকে নিয়ে যায় যা নিয়ন্ত্রণটিকে দুর্বল করে।
সঠিক উপস্থাপনা নির্ভর করে সংস্করণ ও বার্তার ধরনের উপর। একটি ইভেন্ট প্লেসহোল্ডার বহন করতে পারে, আরেকটি ফিল্ডটি সম্পূর্ণ বাদ দিতে পারে, আর একটি প্রমাণীকরণ ব্যর্থতায় কখনও নাম নাও থাকতে পারে। প্রতিটি অনুপস্থিত পরিচয়ে পুরোনো বাগ রিপোর্ট প্রয়োগ না করে নির্দিষ্ট ইভেন্টের জন্য নথিভুক্ত আচরণটি যাচাই করুন।
যখন মাস্কিং ইচ্ছাকৃত, তখন প্রশ্নটি বদলে যায় — ফিল্ডটি কীভাবে ফিরিয়ে আনা যায় তা নয়, বরং নিরীক্ষার প্রয়োজনীয়তা অন্য উপায়ে পূরণ করা যায় কি না। সেশন শনাক্তকারী, ছোট একটি দলের হাতে থাকা নিয়ন্ত্রিত পরিচয় ম্যাপিং, বা সংকীর্ণ অনুমোদিত ইভেন্ট ফিড প্রায়ই প্রতিটি প্রচেষ্টার ব্যবহারকারীর নাম প্রতিটি লগ পাঠকের সামনে না রেখেই প্রয়োজন মেটায়।
সূচিবদ্ধ করার আগে বেনামিকরণ ফেরানো যায় না
ইভেন্ট প্রসেসিং নিয়ে Splunk-এর ডকুমেন্টেশন sed এক্সপ্রেশন এবং রূপান্তরের মাধ্যমে বেনামিকরণের বর্ণনা দেয় যা সূচিবদ্ধ করার আগে ডেটা পুনর্লিখন বা মুছে ফেলে। ঠিক সেই অবস্থানটাই মূল বিষয়: কাঁচা ইভেন্টটি ভেতরে ঢোকার পথেই বদলে যায়, তাই অনুসন্ধান-সময়ের নিষ্কাশনের খুঁজে পাওয়ার মতো কিছুই থাকে না।
সূচি-সময়ের সম্পাদনা ও অনুসন্ধান-সময়ের ফিল্ড নিষ্কাশন ভিন্ন সমস্যার সমাধান করে। সম্পাদনা সীমিত করে কে মানটি কখনও দেখতে পাবে; নিষ্কাশন কেবল ঠিক করে কোয়েরি কোন নামটি ব্যবহার করবে। হ্যাশিং একটি মধ্যবর্তী বিকল্প যা সম্পর্কধারা সংরক্ষণ করে, কিন্তু ছোট ব্যবহারকারীর নামের পরিসরে স্থির হ্যাশ তবুও শনাক্তকারী যখন কেউ তার বিরুদ্ধে সম্ভাব্য নাম পরীক্ষা করতে পারে।
যদি সংরক্ষিত ইভেন্টে এখনও পরিচয়টি থাকে, সমস্যাটি নিচের দিকে: উৎসের ধরন, লাইন ভাঙা, বিভাজক পরিচালনা, ফিল্ড উপনাম বা কোয়েরিটি নিজেই। এগুলো সাধারণ পার্সিং মেরামত এবং এরা গোপনীয়তার সীমান্ত স্পর্শ করে না।
সীমান্তের সাথে মেলে এমন সমাধান বেছে নিন
তিনটি শর্ত প্রতিক্রিয়া নির্ধারণ করে। প্রথমত, গোপনীয়তা নীতিমালা কি পরিচয়টি বাদ দিতে চায়? দ্বিতীয়ত, নিরীক্ষা বা তদন্ত প্রক্রিয়ার কি পরিচয়, ছদ্মনাম, নাকি কেবল সেশনটি দরকার? তৃতীয়ত, মানটি কোন সীমান্তে দরকার — সংগ্রহ, সংরক্ষণ নাকি উপস্থাপন?
যদি নীতিমালা বাদ দিতে চায়, তাহলে নিয়ন্ত্রণ নয়, প্রয়োজনীয়তা বা উপস্থাপনা বদলান। যদি নীতিমালা পরিচয় অনুমোদন করে কিন্তু সংগ্রহ তা ফেলে দেয়, সংগ্রাহক ঠিক করুন এবং কাঁচা ইভেন্ট নিশ্চিত করুন। যদি সংরক্ষণ অক্ষত থাকে, নিষ্কাশন মেরামত করুন এবং শুরুতে ধারণ করা অনুমোদিত ইভেন্টের বিরুদ্ধে তা পরীক্ষা করুন।
পরিবর্তন রেকর্ডে সীমান্তটির নাম দিয়ে তদন্ত শেষ করুন: উৎসে মাস্ক করা, ইনজেশনের সময় সরানো, বা নিষ্কাশনে বাদ পড়া। ওই একটি বাক্য পরবর্তী প্রকৌশলীকে বলে দেয় প্রথমে কোথায় দেখতে হবে, আর এটি ড্যাশবোর্ডের অভিযোগকে নিঃশব্দে নিষ্ক্রিয় করা গোপনীয়তা বৈশিষ্ট্যে পরিণত হতে দেয় না।