অডিট লগ কি? ফিল্ড, রিটেনশন এবং কমপ্লায়েন্স
অডিট লগ কি? এটি যেসব ফিল্ড রেকর্ড করে, কতক্ষণ সংরক্ষণ করতে হয় এবং কমপ্লায়েন্স ও তদন্তের জন্য কীভাবে এটিকে নির্ভরযোগ্য করতে হয় তা জানুন।
একটি অডিট লগ হলো ক্রমানুসারে সাজানো, গঠনমূলক রেকর্ড যেখানে উল্লেখ থাকে কে, কখন, কোথা থেকে, কোন অবজেক্টে, কী কাজ করেছে এবং তার ফলাফল কী হয়েছে - যা পরবর্তীতে সেই কার্যক্রম যাচাই করার জন্য সংরক্ষণ করা হয়। আপনি যদি দেখতে পান যে কোনো একটি কাজ ঘটেছে কিন্তু কর্মী, অবজেক্ট বা ফলাফল চিহ্নিত করতে না পারেন, তবে সেটি কি প্রমাণ নাকি কেবল কোনো ঘটনা ঘটার একটি সাধারণ নোট?
এই প্রশ্নটি লগিং সম্পর্কে দলগুলি কীভাবে আলোচনা করে তার ব্যবধানকে তুলে ধরে। অনেক সিস্টেম ইভেন্টে পূর্ণ ফাইল রাখে, এবং অনেক ভেন্ডর এই ফাইলগুলির যেকোনো একটিকে audit log হিসেবে বর্ণনা করে। কেবল নামটি আপনাকে কিছুই বলে না। আসল বিষয় হলো, জড়িত ছিলেন না এমন কেউ কয়েক মাস পরেও একটি রেকর্ড যাচাই করতে পারেন কিনা, এবং এটি প্রমাণ করে কিনা যে নিয়ন্ত্রণগুলি যেভাবে করার কথা ছিল সেভাবেই পরিচালিত হয়েছিল।
সূচিপত্র
- অডিট লগ কী এবং কেন প্রতিষ্ঠানগুলো এটি সংরক্ষণ করে
- প্রতিটি এন্ট্রি কী রেকর্ড করে এবং কী বাদ দেয়
- ট্রেইল, অ্যাপ লগ এবং মনিটরিং ফিডের সাথে অডিট লগের তুলনা
- কোন স্ট্যান্ডার্ডগুলো অডিট লগ প্রত্যাশা করে
- অখণ্ডতা রক্ষা এবং সংরক্ষণের সময়সীমা নির্ধারণ
- একটি অডিট লগ থেকে কীভাবে ঘটনা পুনর্নির্মাণ করবেন
- প্রমাণ ধ্বংস না করে গোপনীয়তার অনুরোধগুলো পরিচালনা করা
- ভুল ধারণা এবং আপনার লগকে বিশ্বাস করার আগে একটি গভর্ন্যান্স চেক
অডিট লগ কী এবং কেন সংস্থাগুলি এটি সংরক্ষণ করে
একটি পরীক্ষাযোগ্য সংজ্ঞা দিয়ে শুরু করা যাক। একটি অডিট লগ হলো একটি কালানুক্রমিক, কাঠামোগত রেকর্ড যে কে, কখন, কোথা থেকে, কোন অবজেক্টে, কী করেছে এবং তার ফলাফল কী ছিল। অডিট লগের NIST শব্দকোষের সংজ্ঞা এটিকে একটি কালানুক্রমিক রেকর্ড হিসেবে বর্ণনা করে যা নির্দিষ্ট সময়সীমায় পরিচালিত অ্যাক্সেস এবং অপারেশনসহ নির্দিষ্ট সিস্টেম ইভেন্টগুলোর প্রামাণ্য নথি প্রদান করে।
কালানুক্রমিক মানে হলো ক্রম গুরুত্বপূর্ণ। কাঠামোগত মানে প্রতিটি এন্ট্রি একই ফিল্ড বহন করে, যাতে আপনি মুক্ত পাঠ্য পড়ার পরিবর্তে এন্ট্রিগুলি অনুসন্ধান এবং তুলনা করতে পারেন। প্রমাণ মানে হলো রেকর্ডটি অন্য কারো পরে নির্ভর করার জন্য রয়েছে, কেবল কোডটি লিখেছেন এমন ইঞ্জিনিয়ারের জন্য নয়।
রেকর্ডটি কেন বিদ্যমান
প্রতিষ্ঠানগুলি চারটি সম্পর্কিত কারণে একটি অডিট লগ রাখে। দায়বদ্ধতা কোনো একটি কাজকে এমন একজন ব্যক্তি, প্রক্রিয়া বা সিস্টেমের সাথে যুক্ত করে যা এর জবাব দিতে পারে। তদন্ত কোনো সমস্যা হওয়ার পর একটি দলকে ক্রমানুসারে ঘটনা পুনর্গঠন করতে দেয়। কমপ্লায়েন্স প্রমাণ করে যে একটি প্রয়োজনীয় নিয়ন্ত্রণ পরিচালিত হয়েছে। পরিবর্তন পুনর্গঠন দেখায় কিভাবে একটি রেকর্ড বা সেটিং তার বর্তমান অবস্থায় পৌঁছেছে।
এই উদ্দেশ্যগুলি একটি জেনেরিক এরর ফাইল থেকে অডিট লগ-কে আলাদা করে। একটি এরর ফাইল একজন ডেভেলপারকে বাগ খুঁজে পেতে সাহায্য করে। এটি একটি স্ট্যাক ট্রেস রেকর্ড করতে পারে কিন্তু কে কাজটি শুরু করেছে সে সম্পর্কে কিছুই নাও জানাতে পারে। একটি অডিট লগ সফল ও ব্যর্থ লগইন, পাসওয়ার্ড পরিবর্তন, প্রিভিলেজ ব্যবহার, কনফিগারেশন পরিবর্তন, ডেটা সংশোধন, প্রশাসনিক পদক্ষেপ এবং অ্যাক্সেসের চেষ্টা নথিভুক্ত করতে পারে, প্রযুক্তিগতভাবে কোনো ব্যর্থতা ঘটুক বা না ঘটুক।
যে ছয়টি তথ্য একটি কার্যকর এন্ট্রি প্রতিষ্ঠা করে
NIST নির্দেশিকা একটি কার্যকর অডিট রেকর্ডের জন্য অন্তত ছয়টি তথ্য প্রতিষ্ঠা করার প্রত্যাশা করে। সেই তথ্যগুলি হলো কী ইভেন্ট ঘটেছে, এটি কখন ঘটেছে, কোথায় ঘটেছে, এর উৎস, এর ফলাফল এবং এতে জড়িত ব্যক্তি, প্রক্রিয়া বা সত্তার পরিচয়। একটি মিস হলে এন্ট্রি দুর্বল হয়ে পড়ে। ফলাফলহীন একটি এন্ট্রি আপনাকে বলতে পারে না যে কোনো পরিবর্তন কার্যকর হয়েছে কিনা। পরিচয়হীন একটি এন্ট্রি দায়বদ্ধতাকে সমর্থন করতে পারে না।
এই ফিল্ডগুলি তদন্তকারীদের একটি টাইমলাইন আবার তৈরি করতে, অনুমোদিত কার্যক্রমকে সন্দেহজনক আচরণ থেকে আলাদা করতে, ক্ষতিগ্রস্ত সিস্টেম চিহ্নিত করতে এবং একটি কাজকে একজন দায়িত্বশীল পরিচয়ের সাথে যুক্ত করতে সাহায্য করে। এটিই প্র্যাকটিক্যাল পরীক্ষা। যেকোনো একটি এন্ট্রি বেছে নিন এবং জিজ্ঞাসা করুন যে কোনো অপরিচিত ব্যক্তি কেবল সেই এন্ট্রি থেকেই কি এই ছয়টি প্রশ্নের উত্তর দিতে পারবে?
ট্রাবলশুটিং থেকে জবাবদিহিতা পর্যন্ত
অডিট লগিং সিস্টেমের ত্রুটি সমাধানের একটি উপায়ে অপারেশনাল কাজের অংশ হিসেবে শুরু হয়েছিল। এটি আনুষ্ঠানিক দায়বদ্ধতা এবং সাইবার সুরক্ষার প্রমাণ হিসেবে রূপ নিয়েছে কারণ প্রতিষ্ঠানগুলির বেআইনি বা অননুমোদিত কার্যকলাপের পর্যবেক্ষণ, বিশ্লেষণ, তদন্ত এবং রিপোর্টিং সমর্থন করে এমন রেকর্ডের প্রয়োজন ছিল। এই রূপান্তরটি আপনার রেকর্ড করার ধরন বদলে দেয়। আপনি আর নিজের জন্য নোট লিখছেন না। আপনি ভবিষ্যতের এমন একজন পাঠকের জন্য প্রমাণ লিখছেন যিনি এটি নিয়ে প্রশ্ন তুলতে পারেন।
ধরা যাক একটি ভেন্যু প্ল্যাটফর্ম অতিথির পরিচয়, সম্মতির পরিবর্তন, ক্যাম্পেইন অনুমোদন, ইন্টিগ্রেশন এবং বার্তা পরিচালনা করে। একটি উপযুক্ত এন্ট্রি রেকর্ড করে কে সম্মতির স্ট্যাটাস পরিবর্তন করেছে, কখন একটি অনুমোদন ঘটেছে, কোন রেকর্ড বা দর্শক প্রভাবিত হয়েছে এবং অপারেশনটি সফল হয়েছে কিনা। এটি যদি কেবল বলে "update completed," তবে ফাইলটির নাম যাই হোক না কেন, এটি অডিটের কাজ করছে না।
প্রতিটি এন্ট্রিতে কী রেকর্ড করা হয় এবং কী বাদ দেওয়া হয়
প্রতিটি ইভেন্টকে চারটি প্রশ্নের উত্তর দিতে হবে। এটি কখন ঘটেছে, কোথায় ঘটেছে, কে এটি শুরু করেছে বা কার দ্বারা এটি প্রভাবিত হয়েছে, এবং কী ঘটেছে? OWASP Logging Cheat Sheet এই প্রশ্নগুলির উপর ভিত্তি করে এর স্কিমা তৈরি করে এবং একটি সামঞ্জস্যপূর্ণ, মেশিন রিডেবল ফরম্যাটের সুপারিশ করে।
মেশিন-রিডেবল বা যন্ত্রের পাঠযোগ্য হওয়া গুরুত্বপূর্ণ কারণ এন্ট্রিগুলো কেবল একটি সিস্টেমে সীমাবদ্ধ থাকে না। আপনি বিভিন্ন অ্যাপ্লিকেশন, আইডেন্টিটি সিস্টেম, API, এবং ইনফ্রাস্ট্রাকচারের মাধ্যমে সেগুলোতে কুয়েরি করবেন এবং পারস্পরিক সম্পর্ক স্থাপন করবেন। OWASP একটি লগ সার্ভার বা SIEM-এ অ্যাপ্লিকেশন লগ কেন্দ্রীভূত করার পরামর্শ দেয়, কারণ ঘটনা প্রতিক্রিয়ার (incident response) সময় স্থানীয় রেকর্ডগুলোর মধ্যে সম্পর্ক চিহ্নিত করা কঠিন। এন্ট্রিগুলো যদি বিভিন্ন সার্ভারে ভিন্ন ফর্ম্যাটে থাকে, তবে তদন্ত করার বদলে আপনাকে সময় ব্যয় করতে হবে অনুবাদে।
একটি অডিট লগ এন্ট্রির মূল ক্ষেত্রসমূহ
| ফিল্ড | যে প্রশ্নের উত্তর দেয় | নমুনার মান |
|---|---|---|
| Event ID | এটি ঠিক কোন ইভেন্ট? | evt_7Qx2, পরিবর্তনাতীত |
| Timestamp | এটি কখন ঘটেছে? | 2026-03-14T09:12:04Z, UTC |
| Actor | কে এটি শুরু করেছেন? | j.smith, কর্মী অ্যাকাউন্ট, ভূমিকা মারকেটিং ম্যানেজার |
| Authentication context | ব্যবহারকারীকে কীভাবে যাচাই করা হয়েছিল? | MFA সহ সিঙ্গেল সাইন অন সম্পন্ন হয়েছে |
| Scope | কোন টেন্যান্ট বা ভেন্যু প্রভাবিত হয়েছিল? | ভেন্যু 214, লন্ডন সাইট |
| Source system | কোন অ্যাপ্লিকেশন বা সার্ভিস এটি রেকর্ড করেছে? | সম্মতি সার্ভিস, ওয়েব অ্যাডমিন কনসোল |
| Action | কী করা হয়েছিল? | consent.status.change |
| Object | কোন রেকর্ড বা অডিয়েন্স প্রভাবিত হয়েছিল? | গেস্ট রেফারেন্স G-48192 |
| Before and after | কী পরিবর্তিত হয়েছে? | ইমেল সম্মতি, অপ্ট-ইন থেকে অপ্ট-আউট করা হয়েছে |
| Authorization decision | কর্মটি কি অনুমোদিত ছিল এবং কোন নিয়মের অধীনে? | অনুমোদিত, রোল রুল ADMIN_CONSENT |
| Correlation or approval ID | এটি কোন ব্যাচ, অনুমোদন বা ক্যাম্পেইনের সাথে যুক্ত? | অনুমোদন APR-2210, ব্যাচ B-88 |
| Outcome | এটি কি সফল বা ব্যর্থ হয়েছে? | সফল |
| Origin | কোন নেটওয়ার্ক বা ডিভাইস থেকে? | অফিস IP রেঞ্জ, পরিচালিত ল্যাপটপ |
দুটি ফিল্ড সবচেয়ে বেশি বাদ পড়ে যায়, এবং পরবর্তীতে তদন্তকারীদের এগুলিরই প্রয়োজন হয়। অধিপ্রমাণ সিদ্ধান্ত (Authorization decision) আপনাকে বলে যে ব্যবহারকারীকে কাজটি করার অনুমতি দেওয়া হয়েছিল কিনা, কেবল তিনি এটি করেছিলেন তা নয়। কোরিলেশন আইডি (Correlation ID) শত শত পৃথক পরিবর্তনকে একটি বাল্ক আপডেট এবং এর অনুমোদনের সাথে যুক্ত করে। এটি ছাড়া, একটি বাল্ক এক্সপোর্টকে শত শত সম্পর্কহীন ইভেন্টের মতো মনে হয়, এবং কে এই ব্যাচটি অনুমোদন করেছে তা আপনি প্রমাণ করতে পারবেন না।
ব্যবহারিক নিয়ম: আপনি যদি একটি একক পরিবর্তনকে ব্যাচটির অনুমোদনকারী সম্মতির সাথে পুনরায় যুক্ত করতে না পারেন, তবে আপনার কাছে সেই পরিবর্তনের কোনো সম্পূর্ণ রেকর্ড নেই।
রেকর্ড করার মতো ইভেন্ট
অ্যাপ্লিকেশন যা পাঠায় তার ভিত্তিতে নয়, বরং ঝুঁকির ভিত্তিতে ইভেন্ট নির্বাচন গ্রুপ করুন।
- অফেনটিকেশন: সফল এবং ব্যর্থ লগইন, লকআউট, এবং MFA পরিবর্তন।
- অথরাইজেশন: অনুমতির স্বীকৃতি, প্রত্যাখ্যাত অ্যাক্সেসের চেষ্টা, এবং প্রিভিলেজ ব্যবহার।
- ডেটা পরিবর্তন: তৈরি, সম্পাদনা, মুছে ফেলা, এক্সপোর্ট, এবং বাল্ক আপডেট।
- প্রশাসনিক এবং কনফিগারেশন পরিবর্তন: পলিসি সম্পাদনা, API কী তৈরি, এবং ওয়েবহুক পরিবর্তন, যার মধ্যে ওয়েবহুক ভেরিফিকেশন ব্যর্থতা অন্তর্ভুক্ত।
- গোপনীয়তা এবং সম্মতি: অপ্ট-ইন, অপ্ট-আউট, অ্যাক্সেসের অনুরোধ, এবং মুছে ফেলার অনুরোধ।
- মেসেজিং অ্যাক্টিভিটি: অনুমোদনের সিদ্ধান্ত, বার্তা পাঠানো, এবং ডেলিভারি ব্যর্থতা।
এই গ্রুপিংটি আপনাকে কভারেজ সম্পর্কে স্বচ্ছ রাখে। দলগুলি প্রায়শই ডেটা পরিবর্তনগুলি পুঙ্খানুপুঙ্খভাবে লগ করে এবং অ্যাডমিনিস্ট্রেটর অ্যাক্সেসের কথা পুরোপুরি ভুলে যায়, যা ঠিক সেই কার্যকলাপ সম্পর্কে একজন অডিটর প্রথমে জানতে চান।
যা একটি এন্ট্রিতে কখনো থাকা উচিত নয়
একটি অডিট লগ মূল সিস্টেমের চেয়ে বেশি লোক দ্বারা পড়া হয় এবং এটি দীর্ঘ সময়ের জন্য সংরক্ষণ করা হয়। এটি গোপনীয়তার জন্য এটিকে একটি ঝুঁকিপূর্ণ স্থান করে তোলে। কখনোই পাসওয়ার্ড, টোকেন, সেশন কুকিজ, এনক্রিপশন কি, পেমেন্ট কার্ড ডাটা বা অপ্রয়োজনীয় ব্যক্তিগত তথ্য রেকর্ড করবেন না।
এর বদলে সংবেদনশীল মানগুলিকে বিভাগ, মাস্ক করা মান বা স্থায়ী রেফারেন্স দিয়ে উপস্থাপন করুন। কার্ডের নম্বর নয়, বরং "পেমেন্টের পদ্ধতি আপডেট করা হয়েছে" এবং পেমেন্ট রেকর্ডের একটি রেফারেন্স রেকর্ড করুন। প্রতিটি এন্ট্রিতে গেস্টের ইমেল ঠিকানা এবং ফোন নম্বরের পুনরাবৃত্তি না করে কেবল একটি গেস্ট রেফারেন্স রেকর্ড করুন।
একই কারণে নির্বাচনটি ইচ্ছাকৃত হতে হবে। সবকিছু লগ করলে তা গোপনীয়তার ঝুঁকি এবং স্টোরেজ খরচ বাড়ায়, এবং গুরুত্বপূর্ণ ইভেন্টগুলিকে লুকিয়ে ফেলে। খুব কম লগ করলে এমন ফাঁক তৈরি হয় যা পরে পূরণ করা যায় না। আপনি কখনোই এমন কোনো ইভেন্ট পুনরুদ্ধার করতে পারবেন না যা আপনি লেখেননি, তাই কোনো তদন্তে আপনাকে কী প্রমাণ করতে হবে তার ভিত্তিতে কাভারেজ নির্বাচন করুন, এবং তারপর সেই যুক্তিটি ডকুমেন্ট করুন।
ট্রেইল, অ্যাপ লগ এবং মনিটরিং ফিডের সাথে অডিট লগের তুলনা
মানুষ অডিট লগ এবং অডিট ট্রেইল শব্দ দুটিকে একে অপরের পরিবর্তে ব্যবহার করে, এবং এই শব্দগুলি নিয়ে তর্ক করে কোনো লাভ হয় না। আসল পার্থক্য হলো গভর্ন্যান্স - অর্থাৎ রেকর্ডটি কীভাবে সুরক্ষিত করা হয়, সংরক্ষণ করা হয় এবং অনুরোধের ভিত্তিতে উপস্থাপন করা হয়। দুটি সিস্টেমে একই ধরনের ইভেন্ট থাকতে পারে। কিন্তু যাকে প্রমাণ হিসেবে গভর্ন করা হয়, সেটিই হলো অডিট রেকর্ড।
সম্পর্কিত রেকর্ডসমূহের সাথে অডিট লগের তুলনা
| রেকর্ড টাইপ | প্রধান উদ্দেশ্য | সাধারণ পাঠক | সংরক্ষণের নিয়মাবলি |
|---|---|---|---|
| Audit log | কে, কখন এবং কী ফলাফলের সাথে কী করেছে তার প্রমাণ | কমপ্লায়েন্স, তদন্তকারী, অডিটর | পলিসি অনুযায়ী নির্ধারিত, হট এবং কোল্ড টায়ার সহ কয়েক মাস থেকে বছর|
| Audit trail | একই প্রমাণমূলক উদ্দেশ্য, প্রায়শই প্রতিশব্দ হিসেবে ব্যবহৃত হয় | কমপ্লায়েন্স, অডিটর | এটি যে অডিট লগ বর্ণনা করে তার মতোই |
| Application or debug log | ত্রুটি এবং আচরণ সম্পর্কিত সমস্যা সমাধান করা | ডেভেলপার, সাপোর্ট ইঞ্জিনিয়ার | প্রায়শই কয়েক দিন থেকে সপ্তাহ, অডিট রেকর্ডের চেয়ে ছোট |
| Security monitoring feed (SIEM) | বিভিন্ন সিস্টেম জুড়ে দ্রুত হুমকি শনাক্ত করা | সিকিউরিটি অপারেশন অ্যানালিস্ট | মনিটরিং টিম দ্বারা নির্ধারিত অনুসন্ধানযোগ্য সময়সীমা |
| Database transaction log | ডেটা পরিবর্তনের রিকভারি এবং রেপ্লিকেশন | ডাটাবেস অ্যাডমিনিস্ট্রেটর | রিকভারির প্রয়োজন দ্বারা পরিচালিত, অডিটের প্রয়োজন দ্বারা নয় |
| Version history | প্রতিটি সংশোধনে একটি রেকর্ড কেমন ছিল তা দেখানো | কন্টেন্ট মালিক, এডিটর | প্রায়শই রেকর্ডের সাথেই রাখা হয় |
সবচেয়ে গুরুত্বপূর্ণ পার্থক্যটি
একটি audit log-কে অবশ্যই defensible historical evidence সংরক্ষণ করতে হবে। একটি monitoring feed দ্রুত ইভেন্ট সনাক্ত করার জন্য অপটিমাইজ করা হয়। এই লক্ষ্যগুলি বিপরীত দিকে কাজ করে। একটি ফিড দ্রুত থাকার জন্য স্যাম্পল, এগ্রিগেট এবং বিস্তারিত বাদ দিতে পারে। একটি সাক্ষ্যমূলক রেকর্ড কোনো অপ্রীতিকর এন্ট্রি বাদ দিয়ে বিশ্বাসযোগ্য থাকতে পারে না।
এটি তাদের প্রতিদ্বন্দ্বী করে তোলে না। একটি কেন্দ্রীয় লগ সার্ভার বা SIEM-এ অ্যাপ্লিকেশন লগ পাঠানো ভালো অনুশীলন, এবং একই ইভেন্ট প্রায়শই উভয়কেই ফিড করে। সনাক্তকরণ উন্নত হয় কারণ বিশ্লেষকরা এক জায়গায় বিভিন্ন সিস্টেমজুড়ে কার্যকলাপ দেখতে পান। কিন্তু একজন তদন্তকারী চাওয়ার আগেই যদি ইভেন্টগুলি ফিল্টার করে বাদ দেওয়া যায়, সারসংক্ষেপ করে দেওয়া হয়, বা ঘুরিয়ে সরানো যায়, তবে একটি SIEM ফিড একা প্রমাণীকরণের প্রয়োজন মেটায় না।
আপনাকে দ্রুত সতর্ক করার জন্য তৈরি একটি রেকর্ড এবং পরে বিশ্বাসযোগ্য হওয়ার জন্য তৈরি একটি রেকর্ড ভিন্ন কাজ করে, এমনকি যখন তাদের মধ্যে একই ইভেন্ট থাকে।
আপনি কোন রেকর্ডটি দেখছেন তা চিহ্নিত করা
জিজ্ঞাসা করুন রেকর্ডটি কোন প্রশ্নের উত্তর দেওয়ার জন্য তৈরি করা হয়েছিল। "কেন এই অনুরোধটি ব্যর্থ হয়েছে?" debug log-এর দিকে নির্দেশ করে। "কেউ কি এই মুহূর্তে আমাদের আক্রমণ করছে?" monitoring feed-এর দিকে নির্দেশ করে। "আমরা কি ডাটাবেসটি রোল ব্যাক করতে পারি?" transaction log-এর দিকে নির্দেশ করে। "গত মঙ্গলবার এই পৃষ্ঠাটি কী বলেছিল?" সংস্করণ ইতিহাসের দিকে নির্দেশ করে।
অডিট প্রশ্নটি আলাদা। এটি হলো "কে এটি করেছে, তারা কি এটি করার অনুমতি পেয়েছিল, এবং আমরা কি তা প্রমাণ করতে পারি?" রেকর্ড যদি সেই উত্তর দিতে না পারে, তবে পলিসি ডকুমেন্টে এটিকে অডিট লগ বলা হলেও তা অডিট লগ হয়ে যাবে না।
কোন স্ট্যান্ডার্ডগুলো অডিট লগ প্রত্যাশা করে
একটি অডিট লগ তখনই আনুষ্ঠানিক নিয়ন্ত্রণ প্রয়োজনীয়তা হয়ে ওঠে যখন কোনো ঘটনার তদন্তে এমন ইতিহাসের প্রয়োজন হয় যা ঘটনার আবিষ্কারের পরও টিকে থাকে। নীচের প্রতিটি স্ট্যান্ডার্ডের মূল কথা এটাই। প্রতিটি স্ট্যান্ডার্ডই ধরে নেয় যে কার্যক্রমটি ঘটে যাওয়ার পর আপনি একটি সমস্যা সম্পর্কে জানতে পারবেন, এবং তা সত্ত্বেও ঠিক কী ঘটেছিল তা আপনাকে দেখাতে হবে।
পেমেন্ট কার্ডের প্রত্যাশা
পেমেন্ট কার্ড স্ট্যান্ডার্ডের অধীনে থাকা সংস্থাগুলো সবচেয়ে নির্দিষ্ট কাঠামোর মুখোমুখি হয়। PCI সিকিউরিটি স্ট্যান্ডার্ডস কাউন্সিল গাইডলাইন অডিট ট্রেইল হিস্ট্রির জন্য একটি ন্যূনতম সংরক্ষণের সময়সীমা নির্ধারণ করে, এবং সেই হিস্ট্রির একটি অংশ অবিলম্বে বিশ্লেষণের জন্য প্রস্তুত রাখতে হয় - যা কোনো আর্কাইভে জমিয়ে রেখে পরে রিস্টোর করার মতো বিষয় নয়। এই বিভাজনটি পরিচালনাগতভাবে গুরুত্বপূর্ণ। টেকসই স্টোরেজ পুরো সময় জুড়ে প্রমাণ রক্ষা করে। আর অবিলম্বে ব্যবহারযোগ্য স্টোরেজ আপনাকে অপেক্ষা না করেই শনাক্ত এবং প্রতিক্রিয়া জানানোর সুবিধা দেয়।
এই প্রয়োজনীয়তা কেবল পেমেন্ট কার্ড স্ট্যান্ডার্ডের আওতাভুক্ত সংস্থাগুলির জন্যই প্রযোজ্য। আপনি যদি কার্ডের ডাটা প্রসেস না করেন, তবে এটি আপনার ক্ষেত্রে সরাসরি প্রযোজ্য নয়। তবুও এটি একটি দরকারী রেফারেন্স কারণ এটি দুটি ধারণা - প্রমাণ রাখা এবং তা দ্রুত অনুসন্ধান করতে পারা - কে আলাদা করে, যা বিভিন্ন টিম গুলিয়ে ফেলে।
NIST এবং OWASP নির্দেশিকা
NIST নির্দেশিকা একটি ভিন্ন পদ্ধতি গ্রহণ করে। এটি আশা করে যে প্রতিষ্ঠানগুলি তারা লগ করতে পারে এমন ইভেন্টের ধরনগুলি সনাক্ত করবে, তাদের সুরক্ষা এবং গোপনীয়তার উদ্দেশ্য অনুযায়ী ইভেন্টগুলি নির্বাচন করবে, ঘটনার পর তদন্তের জন্য কেন সেই নির্বাচন পর্যাপ্ত তা নথিভুক্ত করবে এবং পর্যায়ক্রমে নির্বাচনটি পর্যালোচনা করবে। কোনো সার্বজনীন ইভেন্ট তালিকা নেই। বাধ্যবাধকতা হল একটি সমর্থনযোগ্য পছন্দ করা এবং আপনার যুক্তি লিখে রাখা।
OWASP নির্দেশিকা মূলত অনুশীলনকারীদের জন্য তৈরি। এটি ধীরগতির ঘটনাগুলি তদন্ত করার জন্য এবং প্রযোজ্য বাধ্যবাধকতাগুলি পূরণ করার জন্য যথেষ্ট সময় ধরে লগ সংরক্ষণ করার, এবং অ্যাপ্লিকেশন লগগুলিকে একটি লগ সার্ভার বা SIEM-এ কেন্দ্রীভূত করার পরামর্শ দেয় যাতে আপনি সেগুলিকে সম্পর্কিত করতে পারেন। একসাথে পড়লে, NIST আপনাকে কাভারেজ যুক্তিসঙ্গত করার পরামর্শ দেয় এবং OWASP সেই কাভারেজকে ব্যবহারযোগ্য করতে বলে।
DORA এবং সেক্টর নির্দিষ্ট দায়িত্বসমূহ
ইইউ-এর Digital Operational Resilience Act, যা DORA নামে পরিচিত, অন্তর্ভুক্ত আর্থিক প্রতিষ্ঠান এবং প্রাসঙ্গিক ICT প্রদানকারীদের ক্ষেত্রে প্রযোজ্য। এটি আশা করে যে ICT কার্যক্রম এমন একটি ফর্মে রেকর্ড করা হবে যা তদন্ত এবং অডিটকে সমর্থন করে, যেমন ডাটা অ্যাক্সেস, সিস্টেম পরিবর্তন এবং প্রশাসনিক ক্রিয়াগুলির মতো ক্ষেত্রগুলি কভার করে। দিকনির্দেশনা স্পষ্ট। কোথাও লগ থাকাই শেষ পরীক্ষা নয়। সেগুলি থেকে তদন্ত করতে সক্ষম হওয়াটাই আসল কথা।
আপনার জন্য কোনটি প্রযোজ্য তা নির্ধারণ করা
স্কোপই সবকিছু নির্ধারণ করে, তাই ইভেন্ট ক্লাস বা সংরক্ষণের সময়সীমা বেছে নেওয়ার আগেই এটি ঠিক করুন। একটি কার্ড প্রসেসিং ব্যবসার PCI বাধ্যবাধকতা থাকতে পারে। একটি ব্যাংকের DORA বাধ্যবাধকতা থাকতে পারে। একাধিক স্থান পরিচালনকারী কোনো ভেন্যু অপারেটর হয়তো দুটির কোনোটির অধীনেই সরাসরি পড়ে না, তবুও তাদের নিজেদের গভর্ন্যান্স, চুক্তি এবং তথ্য সুরক্ষা দায়িত্বের জন্য নির্ভরযোগ্য প্রমাণের প্রয়োজন হতে পারে।
ঠিক এই শেষ পয়েন্টটিতেই টিমগুলো আটকে যায়। নির্দিষ্ট কোনো স্ট্যান্ডার্ডের আওতাভুক্ত না থাকার অর্থ এই নয় যে জবাবদিহিতার প্রয়োজনীয়তা শেষ হয়ে গেছে। এর সহজ অর্থ হলো, আপনি নিজেই প্রয়োজনীয়তা নির্ধারণ করবেন এবং তা ডকুমেন্ট করবেন। আপনি যদি অতিথিদের ডেটা প্রসেস করতে কোনো প্ল্যাটফর্ম ব্যবহার করেন, তবে অডিট তথ্য এবং সাবপ্রসেসরের বিষয়ে চুক্তিতে কী বলা আছে তা পরীক্ষা করুন। আমাদের ডেটা প্রসেসিং চুক্তি-তে আমরা সেই সমস্ত গ্রাহকদের জন্য লিখিত প্রতিশ্রুতিগুলো নির্ধারণ করেছি যাদের এটি প্রয়োজন।
আপনি যে স্ট্যান্ডার্ডের অধীনে নন সেখান থেকে একটি সংখ্যাসূচক রিটেনশন মান কপি করে সেটিকে সর্বজনীন নিয়ম হিসেবে বিবেচনা করবেন না। এটিকে কেবল একটি প্রাসঙ্গিক প্রেক্ষাপট হিসেবে ব্যবহার করুন, তারপর আপনার বাধ্যবাধকতা, আপনার তদন্তের প্রয়োজন এবং আপনার সংস্থান খরচের সাথে মিল রেখে নিজস্ব সময়কাল নির্ধারণ করুন।
অখণ্ডতা সুরক্ষা এবং সংরক্ষণ সময়সীমা নির্ধারণ
একটি audit log কেবল তখনই দরকারী যদি এর এন্ট্রিগুলি বিশ্বাসযোগ্য থাকে। রেকর্ডগুলি কে অ্যাক্সেস করতে বা ডিলিট করতে পারে তা নিয়ন্ত্রণ করুন, প্রতিটি ইভেন্ট ক্লাস কতক্ষণ রাখা হবে তা নির্ধারণ করুন, এবং লগিং কাজ চালিয়ে যাচ্ছে কিনা তা পরীক্ষা করুন। যদি একই অ্যাডমিনিস্ট্রেটর সম্মতির স্ট্যাটাস পরিবর্তন করতে পারেন এবং সেই পরিবর্তনের রেকর্ডটি মুছে ফেলতে পারেন, তবে রেকর্ডটি কী ঘটেছে তা নির্ভরযোগ্যভাবে দেখাতে পারে না।
অখণ্ডতার নিয়ন্ত্রণসমূহ যা একটি এন্ট্রিকে বিশ্বাসযোগ্য করে তোলে
অডিট রেকর্ডগুলি একটি append-only বা tamper-evident repository-তে সংরক্ষণ করুন, যার সাথে থাকবে সীমিত ডিলিট করার অধিকার এবং আলাদাভাবে মনিটর করা প্রশাসনিক অ্যাক্সেস। Append-only স্টোরেজ নতুন এন্ট্রি যোগ করার অনুমতি দেয় কিন্তু সাধারণ প্রোডাক্ট ফাংশনগুলিকে বিদ্যমান এন্ট্রিগুলি সম্পাদনা বা অপসারণ করতে বাধা দেয়। আলাদা মনিটরিংয়ের অর্থ হলো লগে অ্যাক্সেস নিজেই একটি রেকর্ড তৈরি করে।
বেশ কয়েকটি পদ্ধতি অখণ্ডতাকে আরও শক্তিশালী করতে পারে:
- হ্যাশ চেইনিং: প্রতিটি এন্ট্রির হ্যাশ পূর্ববর্তী এন্ট্রির ওপর নির্ভর করে। কোনো এন্ট্রি পরিবর্তন বা অপসারণ করলে চেইনটি ভেঙে যায়।
- স্বাক্ষরিত ইভেন্ট: ক্রিপ্টোগ্রাফিক সিগনেচার যাচাই করতে সাহায্য করে যে এন্ট্রিগুলি সেই সিস্টেম থেকেই এসেছে যা সেগুলি লেখার দাবি করছে।
- রাইট-ওয়ান্স স্টোরেজ: একটি এন্ট্রি লেখা হয়ে গেলে স্টোরেজ লেয়ার কোনো পরিবর্তন প্রতিরোধ করে।
- স্বাধীন টাইমস্ট্যাম্পিং: একটি পৃথক সময় উৎস নিশ্চিত করে যে একটি এন্ট্রি কখন বিদ্যমান ছিল।
- গ্যাপ অ্যালার্টিং: সতর্কবার্তাগুলি সিকোয়েন্স গ্যাপ বা অপ্রত্যাশিত অপসারণ চিহ্নিত করে।
এমন নিয়ন্ত্রণ চয়ন করুন যা আপনার সিস্টেমের সাথে খাপ খায় এবং সেগুলি কীভাবে কাজ করে তা ডকুমেন্ট করুন। লক্ষ্য হলো অননুমোদিত পরিবর্তনগুলি শনাক্তযোগ্য এবং ব্যাখ্যাযোগ্য করা। সম্পন্ন হওয়া কাজের পাশাপাশি চেষ্টা করা কাজগুলিও রেকর্ড করুন: অথরাইজেশন ব্যর্থতা, অনুমোদন, এক্সিকিউশন ফলাফল এবং প্রশাসনিক পরিবর্তন। গেস্ট ডেটা এক্সপোর্ট করার একটি প্রত্যাখ্যাত চেষ্টা একটি রুটিন সফল সম্পাদনার চেয়ে বেশি গুরুত্বপূর্ণ হতে পারে।
সংরক্ষণের রেফারেন্স মানসমূহ
| প্রয়োজনীয়তা | রেফারেন্স মান | প্রেক্ষিত |
|---|---|---|
| PCI DSS অডিট ট্রেইল সংরক্ষণ | কমপক্ষে ১ বছর | পেমেন্ট কার্ড স্ট্যান্ডার্ডের আওতাভুক্ত সংস্থাসমূহ |
| PCI DSS অবিলম্বে উপলব্ধ ইতিহাস | কমপক্ষে ৩ মাস | আর্কাইভ রিস্টোর না করেই বিশ্লেষণের জন্য উপলব্ধ |
| হট পিরিয়ডের পর কোল্ড স্টোরেজ | অবশিষ্ট সংরক্ষণ সময়ের জন্য কম খরচের আর্কাইভ | স্টোরেজ খরচ কমানোর পাশাপাশি পুরোনো রেকর্ডগুলি উপলব্ধ রাখে |
এই মানগুলি নির্দিষ্ট প্রসঙ্গে প্রযোজ্য, সার্বজনীন নিয়ম হিসাবে নয়। হট এবং কোল্ড স্টোরেজ স্তরগুলি অনুসন্ধানের গতি এবং খরচ সামঞ্জস্য করতে সাহায্য করতে পারে: সাম্প্রতিক এন্ট্রিগুলি দ্রুত অনুসন্ধানযোগ্য থাকে, অন্যদিকে পুরানো রেকর্ডগুলি এমন একটি আর্কাইভে চলে যায় যা পুনরুদ্ধার করতে বেশি সময় নেয়। যদি সবকিছু হট স্টোরেজে থাকে, তবে খরচ খুব আগেই মুছে ফেলার চাপ তৈরি করতে পারে। যদি সবকিছু সরাসরি কোল্ড স্টোরেজে চলে যায়, তবে পুনরুদ্ধার একটি তদন্তে বিলম্ব করতে পারে।
প্রযোজ্য বাধ্যবাধকতা এবং তদন্তের চাহিদার ওপর ভিত্তি করে ইভেন্ট শ্রেণি অনুযায়ী ডেটা সংরক্ষণের সময়সীমা নির্ধারণ করুন। অনির্দিষ্টকালের জন্য তথ্য সংরক্ষণ প্রাইভেসির ঝুঁকি, স্টোরেজ খরচ এবং অনুসন্ধানের সময় বাড়িয়ে দিতে পারে। প্রতিটি সময়সীমার কারণ নথিভুক্ত করুন, তারপর নির্ধারিত সময়সূচী অনুযায়ী রেকর্ডগুলো মুছে ফেলুন। ছোট সংস্থাগুলো একটি বাস্তবসম্মত নীতি তৈরির ক্ষেত্রে, Networking2000 এর ছোট ব্যবসার জন্য ডেটা সংরক্ষণের পরামর্শ শুরুর একটি দিকনির্দেশনা হিসেবে দেখতে পারে।
সংরক্ষণের নিয়ম: দেরিতে চিহ্নিত হওয়া ঘটনাগুলো তদন্ত করার জন্য প্রয়োজনীয় সময় পর্যন্ত এন্ট্রিগুলো সংরক্ষণ করুন, তবে লিখিতভাবে যুক্তি দেওয়া যায় না এমন সময়ের চেয়ে বেশি দিন নয়।
একটি সমর্থনযোগ্য বাস্তবায়নের জন্য যে নথিপত্র প্রয়োজন
আপনি কোন ইভেন্ট ক্লাসগুলি রেকর্ড করছেন এবং কেন, আপনার সংরক্ষণ এবং আইনি হোল্ড নীতিগুলি, কার কী অ্যাক্সেস ভূমিকা রয়েছে, কীভাবে এক্সপোর্ট তৈরি ও প্রমাণীকরণ করা হয়, কীভাবে ঘড়িগুলি সিঙ্ক্রোনাইজ করা হয়, আপনি কী অ্যালার্ট থ্রেশহোল্ড ব্যবহার করেন এবং কী ব্যাকআপ নিয়ন্ত্রণ স্টোরটিকে সুরক্ষিত রাখে তা নথিভুক্ত করুন। তারপর পর্যায়ক্রমে পরীক্ষা করে দেখুন যে লগিং এখনও কাজ করছে কিনা। একটি নীরব লগিং ব্যর্থতা একটি শান্ত সিস্টেমকেও স্বাভাবিক দেখাতে পারে।
ঘড়ির সিঙ্ক্রোনাইজেশন অত্যন্ত গুরুত্বপূর্ণ কারণ সিস্টেমের সময় পিছিয়ে বা এগিয়ে থাকলে তা বিভ্রান্তিকর টাইমলাইন তৈরি করতে পারে। সিস্টেমগুলিকে UTC-এর সাথে সিঙ্ক্রোনাইজ করুন এবং নিশ্চিত করুন যে এই সিঙ্ক্রোনাইজেশন অব্যাহত রয়েছে।
একজন ভেন্ডর মূল্যায়ন করার সময়, তাদের সুরক্ষা এবং গভর্নেন্স চর্চা সম্পর্কিত লিখিত তথ্যের জন্য অনুরোধ করুন। Purple Engage-এর সুরক্ষা এবং গভর্নেন্স তথ্য IT এবং কমপ্লায়েন্স প্রধানদের প্ল্যাটফর্মটি মূল্যায়ন করতে সাহায্য করতে পারে।
একটি অডিট লগ থেকে কীভাবে একটি ঘটনা পুনর্গঠন করবেন
পুনর্গঠনের জন্য ইতিহাসের প্রয়োজন কারণ লঙ্ঘনগুলি প্রায়শই সাথে সাথে লক্ষ্য করা যায় না। কার্যকর দৈনিক লগ পর্যবেক্ষণের বিষয়ে PCI সিকিউরিটি স্ট্যান্ডার্ডস কাউন্সিলের নির্দেশিকা অনুসারে প্রাসঙ্গিক পেমেন্ট কার্ড স্ট্যান্ডার্ডের আওতাভুক্ত সংস্থাগুলিকে কমপক্ষে ১ বছরের জন্য অডিট ট্রেইল ইতিহাস সংরক্ষণ করতে হবে, পাশাপাশি সর্বনিম্ন ৩ মাস অবিলম্বে বিশ্লেষণের জন্য উপলব্ধ রাখতে হবে।
ফরেনসিক কারণেই এই প্রয়োজনীয়তা রয়েছে। অননুমোদিত কার্যক্রম কখন শুরু হয়েছিল, কতক্ষণ চলেছিল এবং কোন সিস্টেম বা রেকর্ডগুলি ক্ষতিগ্রস্ত হয়েছিল তা নির্ধারণ করতে তদন্তকারীদের পর্যাপ্ত ইতিহাসের প্রয়োজন হয়। আপনার লগ যদি কেবল গত কয়েক সপ্তাহের তথ্য কভার করে, তবে আপনি আজ যা পেয়েছেন কেবল সেটুকুই বর্ণনা করতে পারবেন, এটি কীভাবে শুরু হয়েছিল সে সম্পর্কে কিছুই বলতে পারবেন না।
নিচের চিত্রটি পরবর্তী ধাপগুলির আগে পুনর্গঠন প্রক্রিয়াটি তুলে ধরে।
একটি সাত ধাপের পুনর্গঠন
প্রশ্ন এবং সময়সীমা নির্দিষ্ট করুন। আপনি ঠিক কী প্রতিষ্ঠা করার চেষ্টা করছেন তা লিখে রাখুন, যেমন গত 30 দিনে একটি ভেন্যুর জন্য সম্মতি পরিবর্তন। একটি অস্পষ্ট প্রশ্ন একটি অস্পষ্ট অনুসন্ধান তৈরি করে। একটি নির্দিষ্ট প্রশ্ন আপনাকে বলে দেবে যে কোন ফিল্ডগুলোতে ফিল্টার করতে হবে।
কভারেজ এবং ঘড়ি নিশ্চিত করুন। লগ সোর্সটি সেই সময়সীমাকে কভার করে কিনা এবং এর ঘড়িগুলো UTC-তে সিঙ্ক্রোনাইজ করা আছে কিনা তা পরীক্ষা করে দেখুন। সময়সীমার অংশ যদি কোল্ড স্টোরেজে থাকে, তবে সিদ্ধান্ত টানা শুরু করার আগে এটি পুনরুদ্ধার করুন।
অ্যাকশনের ধরণ এবং স্কোপ দ্বারা ফিল্টার করুন। অ্যাকশনের সাথে মেলে এমন ইভেন্টগুলো টানুন, যেমন consent.status.change, যা ভেন্যু 214-এর মধ্যে সীমাবদ্ধ। প্রথমে স্কোপ নির্ধারণ করুন, কারণ অন্যথায় মাল্টি-সাইট অ্যাক্টিভিটি আপনার প্রয়োজনীয় এন্ট্রিগুলোকে ডুবিয়ে দেবে।
অ্যাক্টর, অথেনটিকেশন কনটেক্সট এবং অরিজিন টানুন। প্রতিটি মেলানো ইভেন্টের জন্য, কে কাজটি করেছে, কীভাবে তারা যাচাইকৃত হয়েছে এবং তারা কোন নেটওয়ার্ক বা ডিভাইস ব্যবহার করেছে তা নোট করুন। একটি অপরিচিত অরিজিন থেকে একজন পরিচিত অ্যাক্টরের উপস্থিতি এমন একটি প্যাটার্ন যেখানে থামা উচিত।
অথরাইজেশন সিদ্ধান্ত এবং করেলেশন ID পরীক্ষা করুন। প্রতিটি অ্যাকশনের অনুমতি ছিল কিনা তা নিশ্চিত করুন এবং বাল্ক আপডেটগুলোকে তাদের অনুমোদনের সাথে লিঙ্ক করুন। একটি করেলেশন ID শেয়ার করা এন্ট্রিগুলো একটি সিদ্ধান্তের অধীনে থাকে, তাই এগুলোকে একটি একটি করে পর্যালোচনা না করে একসাথে মূল্যায়ন করুন।
টাইমলাইন তৈরি করুন এবং মানগুলো তুলনা করুন। টাইমস্ট্যাম্প অনুযায়ী ইভেন্টগুলো সাজান এবং প্রতিটি পরিবর্তনের আগে ও পরের মান তুলনা করুন। এই ধাপটি প্রকাশ করে যে একটি রেকর্ড একবার পরিবর্তিত হয়েছে নাকি পরিবর্তন, পূর্বাবস্থায় ফেরানো এবং পুনরায় পরিবর্তন করা হয়েছে।
অনুমোদিত এবং সন্দেহজনক অ্যাক্টিভিটি আলাদা করুন, তারপর ফলাফলগুলো রেকর্ড করুন। কোন অ্যাক্টিভিটি একটি অনুমোদনের সাথে মেলে এবং কোনটি মেলে না তা চিহ্নিত করুন এবং প্রমাণের রেফারেন্স হিসাবে ইভেন্ট ID সহ ফলাফলগুলো লিখে রাখুন। আপনার সিদ্ধান্তটি কোনো সাধারণ ধারণার উপর নয়, বরং নির্দিষ্ট এন্ট্রিগুলোর দিকে নির্দেশ করা উচিত।
নিচের সংক্ষিপ্ত ওয়াকথ্রুটি একই ফিল্ড-বাই-ফিল্ড পদ্ধতি ব্যবহার করে অনুশীলনে সেই টাইমলাইন তৈরি দেখায়।
যেখানে পুনর্গঠন ব্যর্থ হয়
তিনটি সমস্যা বারবার দেখা দেয়। অনুপস্থিত ইভেন্টগুলি সবচেয়ে খারাপ, কারণ আপনি "কিছুই ঘটেনি" থেকে "কিছুই রেকর্ড করা হয়নি" আলাদা করতে পারবেন না। মেলানো না থাকা সময় অঞ্চলগুলি ক্রমকে বিশৃঙ্খল করে তোলে, তাই একটি অনুমোদন সেটি অনুমোদন করার পরের অ্যাকশন হিসাবে উপস্থিত হয়। খুব আগে মাস্ক করা রেকর্ডগুলি আপনার প্রয়োজনীয় রেফারেন্স সরিয়ে দেয় যা কোনো অতিথি বা প্রচারণার সাথে একটি এন্ট্রি সংযুক্ত করতে প্রয়োজন ছিল।
মাল্টি-সাইট অপারেশনের জন্য, সম্মতি, অডিয়েন্স, অফার, অনুমোদন, ইন্টিগ্রেশন এবং মেসেজিং অ্যাকশন জুড়ে append-only রেকর্ডগুলি বিভিন্ন স্থানে কাজটিকে কার্যকর করে তোলে। একটি শেয়ার্ড স্কোপ ফিল্ড ছাড়া, আপনি বলতে পারবেন না যে একটি প্যাটার্ন কোনো একটি নির্দিষ্ট স্থানের সমস্যা নাকি পুরো গ্রুপের সমস্যা। এটি এমন একটি ডিজাইন সিদ্ধান্ত যা আপনি যেকোনো ঘটনার অনেক আগেই নেন।
প্রমাণ নষ্ট না করে গোপনীয়তার অনুরোধগুলো পরিচালনা করা
একজন অতিথি আপনাকে তাদের ডাটা মুছে ফেলতে বলেন। আপনার অডিট লগে সেই অতিথি সম্পর্কে এন্ট্রি রাখা হয়, যার মধ্যে আপনি যে সম্মতির পরিবর্তনের জন্য দায়বদ্ধ সেগুলিও অন্তর্ভুক্ত রয়েছে। সবকিছু মুছে ফেললে আপনার প্রমাণ ধ্বংস হয়ে যায়। সরাসরি প্রত্যাখ্যান করা অনুরোধটিকে উপেক্ষা করে। আপনার একটি প্যাটার্ন প্রয়োজন যা উভয়কেই সম্মান করে।
দ্বন্দ্বটি বাস্তব তবে এটি যতটা মনে হয় তার চেয়ে বেশি সীমিত। একটি অডিট এন্ট্রির কাজটি করার জন্য অতিথির ব্যক্তিগত তথ্য ধারণ করার প্রয়োজন নেই। এটি প্রমাণ করা প্রয়োজন যে একটি কাজ ঘটেছে, কে এটি করেছে এবং ফলাফল কী ছিল। এই দুটি জিনিসকে আলাদা করুন এবং বেশিরভাগ উত্তেজনা দূর হয়ে যাবে।
পাঁচটি ধাপে একটি কাজের প্যাটার্ন
প্রথমে অনুরোধটি নিজে নিবন্ধিত করুন। আপনি এটি নিয়ে কাজ করার আগে অনুরোধটিকে একটি ইভেন্ট হিসাবে রেকর্ড করুন, এর ধরন, প্রাপ্তির সময়, প্রক্রিয়াকারী ব্যক্তি এবং অবশেষে এর ফলাফল সহ। পরবর্তীতে কেউ এটি কীভাবে পরিচালনা করেছেন জানতে চাইলে, সেই পরিচালনার প্রমাণ সংরক্ষিত থাকবে।
ইভেন্ট রেকর্ড থেকে ব্যক্তিগত ডেটা আলাদা করুন। নাম, যোগাযোগের বিবরণ বা মূল সম্মতির লেখার পরিবর্তে অডিট এন্ট্রিটিতে একটি স্থায়ী গেস্ট রেফারেন্স রাখুন। এই রেফারেন্সটি আপনাকে এন্ট্রিগুলির মধ্যে সম্পর্ক স্থাপন করতে দেয়, যখন ব্যক্তিগত ডেটা মূল রেকর্ডটিতে থাকে যা সহজেই মুছে ফেলা যায়।
মূল রেকর্ডে মুছে ফেলার প্রক্রিয়া প্রয়োগ করুন। প্রয়োজন অনুযায়ী গেস্টের রেকর্ড মুছে ফেলুন বা সীমিত করুন, এবং কোনো লিখিত নিয়ম আগে সরানোর অনুমতি না দিলে অডিট এন্ট্রিটি তার সংরক্ষণের সময়কালের জন্য রেখে দিন। এন্ট্রিটি এখন এমন একটি রেফারেন্স নির্দেশ করে যা আর ব্যক্তিগত ডেটা প্রকাশ করে না, যা সাধারণত আপনার কাঙ্ক্ষিত ফলাফল।
প্রয়োজনে লিগ্যাল হোল্ড প্রয়োগ করুন। যদি কোনো চলমান তদন্ত বা বিরোধের জন্য নির্দিষ্ট এন্ট্রিগুলির প্রয়োজন হয়, তবে অনানুষ্ঠানিকভাবে মুছে ফেলা স্থগিত না রেখে আনুষ্ঠানিকভাবে হোল্ড করুন। কারণ এবং দায়িত্বপ্রাপ্ত ব্যক্তি সহ একটি নির্দিষ্ট হোল্ড কর্মীদের পরিবর্তনের পরেও বজায় থাকে। মৌখিক সমঝোতা থাকে না।
সিদ্ধান্ত এবং এর ভিত্তি রেকর্ড করুন। কেন একটি ফিল্ড হাইড বা অপসারণ করা হয়েছে, আপনি কোন নিয়ম প্রয়োগ করেছেন এবং কে এটি অনুমোদন করেছেন তা নোট করুন। কোনো ব্যাখ্যার উল্লেখ না রেখে একটি লুকানো ফিল্ড খুঁজে পেলে অডিটর এটিকে একটি ঘাটতি হিসাবে বিবেচনা করবেন। একজন অডিটর যিনি একটি লিখিত সিদ্ধান্ত পাবেন, তিনি সাধারণত পরবর্তী বিষয়ে এগিয়ে যাবেন।
লিগ্যাল কাউন্সেলের সাথে নিশ্চিত হওয়ার মতো প্রশ্নসমূহ
ইঞ্জিনিয়ারিং সিদ্ধান্তের চেয়ে দুটি প্রশ্নে আইনি মতামতের বেশি প্রয়োজন। আপনার সেক্টর এবং চুক্তি বিবেচনা করে কোন রিটেনশন সময়কাল প্রতিটি ইভেন্ট ক্লাসের জন্য প্রযোজ্য? এবং আপনি যে উদ্দেশ্যে রেকর্ডটি রেখেছেন, তার জন্য একটি মাস্কড এন্ট্রি কি এখনও একটি সম্পূর্ণ রেকর্ড হিসেবে গণ্য হবে?
একটি ঢালাও বিবৃতির বদলে প্রতিটি ইভেন্ট ক্লাসের জন্য এই উত্তরগুলি পান। একটি সম্মতির পরিবর্তন এবং একটি ব্যর্থ লগইন একই প্রমানমূলক গুরুত্ব বহন করে না, এবং তাদের একই রকম রিটেনশনের বাধ্যবাধকতা নাও থাকতে পারে। এই পার্থক্যটি নথিভুক্ত করাই আপনার অবস্থানকে আত্মপক্ষ সমর্থনের যোগ্য করে তোলে।
স্বচ্ছতা অতিথিদের দিক থেকেও সাহায্য করে। অনুরোধ করা ব্যক্তিরা জানতে চান আপনার কাছে কী রয়েছে এবং এটির সাথে কী ঘটে। আমাদের গোপনীয়তা বিজ্ঞপ্তি সেট করে আমরা কীভাবে সেই পরিচালনা বর্ণনা করি, এবং আপনার নিজের বিজ্ঞপ্তিতে সাধারণ শব্দে ব্যাখ্যা করতে সক্ষম হওয়া উচিত যে মুছে ফেলার পরেও অনুরোধটির একটি ন্যূনতম রেকর্ড রেখে দেওয়া হতে পারে।
গেস্ট রেকর্ড মুছে ফেলা এবং আপনি যে এটি মুছে ফেলেছেন তার প্রমাণস্বরূপ কেবল একটি রেফারেন্স এন্ট্রি রাখা পরস্পরবিরোধী নয়। দ্বিতীয় কাজটি করাই হলো প্রথমটির প্রমাণ দেওয়ার উপায়।
আপনার লগকে বিশ্বাস করার আগে ভুল ধারণা এবং গভর্নেন্স যাচাই
একটি অডিট লগ কি বিশ্বাসযোগ্য হতে পারে, এবং একজন তদন্তকারী যখন এটি চান তখন কী পরিবর্তন হয়? এটিই সেই প্রশ্ন যা বেশিরভাগ প্রাথমিক ব্যাখ্যায় এড়িয়ে যাওয়া হয়। অডিট রেকর্ড তৈরির জন্য NIST SP 800-171 কন্ট্রোল রেফারেন্স সেই প্রত্যাশাকে প্রতিফলিত করে যে প্রতিষ্ঠানগুলি নির্বিচারে লগিং করার বদলে নির্ধারণ এবং নথিভুক্ত করবে যে কোন ঘটনাগুলি চলমান অডিটিং চাহিদার জন্য গুরুত্বপূর্ণ এবং প্রাসঙ্গিক।
সেই প্রত্যাশা চারটি সাধারণ ভুল ধারণাকে সংশোধন করে।
চারটি ভুল ধারণা যা বাদ দেওয়া উচিত
বেশি লগ মানেই ভালো প্রমাণ। এটি সঠিক নয়। গুরুত্বপূর্ণ ইভেন্টগুলির আইনিভাবে গ্রহণযোগ্য কভারেজই আসল বিষয়, এবং তথ্যের অতিরিক্ত পরিমাণ গোপনীয়তার ঝুঁকি বাড়ায় এবং আপনার প্রয়োজনীয় এন্ট্রিগুলিকে আড়াল করে ফেলতে পারে।
শুধু লগ রাখাই যথেষ্ট। অডিট করার ক্ষমতা অখণ্ডতা, সম্পূর্ণতা, অ্যাক্সেস নিয়ন্ত্রণ এবং পুনরুদ্ধার-এর ওপর নির্ভর করে, কেবল সংরক্ষণের ওপর নয়। যে লগ আপনি অনুসন্ধান করতে পারেন না বা যা অপরিবর্তিত আছে বলে প্রমাণ করতে পারেন না, তা কোনো তদন্ত এগিয়ে নিতে পারবে না।
একটি অডিট লগ হলো একটি ব্যাকআপ। এটি কার্যকলাপ রেকর্ড করে। এটি মুছে ফেলা ডাটা পুনরুদ্ধার করে না এবং এটি আপনার হারিয়ে যাওয়া একটি গেস্ট রেকর্ড পুনরায় তৈরি করবে না।
অডিট লগ আক্রমণ প্রতিরোধ করে। এটি ঘটনা ঘটার পর তদন্তে সহায়তা করে এবং ডিটেকশনে সাহায্য করতে পারে, তবে এটি একা কোনো আক্রমণ রোধ করতে পারে না।
DORA নির্দেশ করে রেগুলেশন কোন দিকে যাচ্ছে। এটি জানুয়ারি ২০২৫ এ কার্যকর হয়েছে এবং কভার করা আর্থিক সত্তা এবং প্রাসঙ্গিক ICT প্রদানকারীদের ডাটা অ্যাক্সেস, সিস্টেম পরিবর্তন এবং প্রশাসনিক ক্রিয়া সহ ICT কার্যকলাপগুলি এমন একটি ফর্মে রেকর্ড এবং লগ করার প্রয়োজন যা তদন্ত এবং অডিটকে সমর্থন করে। পরিবর্তনটি "লগ থাকা" থেকে "তদন্ত করতে সক্ষম হওয়া" এর দিকে।
একটি গভর্ন্যান্স চেক যা আপনি এই সপ্তাহে চালাতে পারেন
প্রমাণ সহ প্রতিটি প্রশ্নের উত্তর দিন, কোনো আশ্বাস দিয়ে নয়।
- ইভেন্ট স্কোপ: আমরা যে ইভেন্টগুলো রেকর্ড করি সেগুলো কি আমাদের ঝুঁকি এবং নিয়মের জন্য সঠিক, এবং তা কি নথিভুক্ত?
- এন্ট্রির পূর্ণতা: প্রতিটি এন্ট্রিতে কি UTC সময়, অ্যাক্টর, স্কোপ, ফলাফল এবং করেলেশন ID রয়েছে?
- অখণ্ডতা: স্টোরটি কি অ্যাপেন্ড অনলি বা ট্যাম্পার এভিডেন্ট, যেখানে সীমিত মুছে ফেলার সুবিধা এবং আলাদাভাবে পর্যবেক্ষণ করা অ্যাডমিন অ্যাক্সেস রয়েছে? একজন অ্যাডমিন কি কোনো এন্ট্রি পরিবর্তন বা মুছে ফেলতে পারেন?
- সংরক্ষণ (Retention): ইভেন্ট ক্লাস অনুযায়ী সংরক্ষণ কি নথিভুক্ত করা হয়েছে, যেখানে হট ও কোল্ড টায়ার এবং লিগ্যাল হোল্ড রয়েছে?
- পুনরুদ্ধার: আমরা কি একজন অডিটর-এর জন্য রেকর্ড রপ্তানি করতে পারি এবং সেই রপ্তানি প্রমাণীকরণ করতে পারি?
- ঘড়ি: ক্লক সিঙ্ক্রোনাইজেশন কি যাচাই করা হয়েছে, নাকি কেবল ধরে নেওয়া হয়েছে?
- গোপনীয়তা পরিচালনা: আমরা কি সাক্ষ্যপ্রমাণ সংক্রান্ত ইতিহাস ধ্বংস না করেই সম্মতি বা মুছে ফেলার অনুরোধ রক্ষা করতে পারি?
একবারে সবকিছু ঠিক করার চেষ্টা করবেন না। সম্মতি পরিবর্তন বা বাল্ক এক্সপোর্টের মতো একটি উচ্চ ঝুঁকিপূর্ণ ওয়ার্কফ্লো বেছে নিন, চেকলিস্টের মাধ্যমে এটি ট্র্যাক করুন এবং আপনার পাওয়া প্রথম ফাঁকটি সমাধান করুন। দীর্ঘ তালিকা তৈরি করে কিন্তু কোনো পরিবর্তন আনে না এমন একটি গ্রুপ ওয়াইড পর্যালোচনার চেয়ে একটি সম্পূর্ণ প্রমাণিত ওয়ার্কফ্লো আপনাকে অনেক বেশি শিক্ষা দেয়।
আপনার কেনা প্ল্যাটফর্মগুলি মূল্যায়নের জন্যও এটি একটি সঠিক দৃষ্টিভঙ্গি। Purple Engage একটি মার্কেটিং প্ল্যাটফর্মের অনুমোদনকারী ব্যক্তিদের জন্য অডিট রেকর্ড, API এবং ওয়েবহুক সহ এন্টারপ্রাইজ ফিচারগুলি অফার করে এবং এটি প্রতিটি চ্যানেলে একটি গেস্ট রেকর্ড, একটি সম্মতি লেজার এবং একটি পরিমাপ ব্যবস্থা প্রদান করে, যা WiFi, টিল, বুকিং এবং হোটেল স্টে সোর্স থেকে ডেটা যুক্ত করে। Engage প্রতিটি গেস্টের জন্য ৬০টিরও বেশি ইভেন্ট টাইপ রেকর্ড করে, যার মধ্যে রয়েছে WiFi সাইন ইন, কেনাকাটা, বুকিং, চেক আউট, ফর্ম জমা, ক্যাম্পেইন অ্যাক্টিভিটি এবং সার্ভে রেসপন্স। এই বিবরণগুলি কেবল তখনই সাহায্য করে যদি সেগুলির পিছনের রেকর্ডটি সঠিকভাবে পরিচালিত হয়, যার কারণে ফিচারের তালিকার চেয়ে চেক তালিকাটি বেশি গুরুত্বপূর্ণ।
লগের পরিমাণের চেয়ে কারচুপি প্রতিরোধ ক্ষমতা এবং ব্যাখ্যা করার ক্ষমতা বেশি গুরুত্বপূর্ণ। যখন কেউ জিজ্ঞাসা করে যে আপনার নিজস্ব স্ট্যাকে অডিট লগ কী, তখন আপনি যদি একটি পরীক্ষা মনে রাখেন তবে সেটি ব্যবহার করুন। আপনি কি এই রেকর্ডটি একজন সন্দেহপ্রবণ বহিরাগতকে দিতে পারেন এবং তারা কি এটি বিশ্বাস করবে?
আপনার ভেন্যুগুলোতে কীভাবে সম্মতির পরিবর্তন, অনুমোদন, এক্সপোর্ট এবং বার্তা পাঠানো প্রমানিত হচ্ছে তা যদি আপনি মূল্যায়ন করেন, তবে Purple Engage আপনাকে একটি গেস্ট রেকর্ড এবং অনুমোদনের সময় ও প্রতিটি বার্তার আগে যাচাইকৃত একটি সম্মতি লেজারের পাশাপাশি একটি অডিট রেকর্ড প্রদান করে। এই রেকর্ডটি কীভাবে গঠিত, এটি কোন কোন ইভেন্টের ধরন কভার করে এবং আপনার সংস্থায় নেওয়ার আগে কীভাবে আপনার IT এবং কমপ্লায়েন্স লিডরা এটি পর্যালোচনা করতে পারেন তা দেখতে আমাদের সাইট দেখুন।