১৮
CloudTrail — কে কী করেছে, আর কখন
Metric আর audit trail দুটো আলাদা প্রশ্নের উত্তর দেয়। Event history কত দিন থাকে আর কেন সেটা যথেষ্ট নয়, একটা trail বানানো, একটা event-এর ঘরগুলো পড়া, management আর data event-এর পার্থক্য, retention-এর খরচের ফাঁদ, আর একটা আসল তদন্ত ধাপে ধাপে।
cloudtrailauditloggingsecurityincidentcloudwatchretention⏱ ~৩৪ মিনিট
💡 ধারণা
দুটো প্রশ্ন, আর দুটো আলাদা সরঞ্জাম
পর্ব ৯-এ IAM-এর চারটে স্তম্ভের কথা বলেছিলাম, আর চতুর্থটা বাকি রেখেছিলাম: আসলে কী হলো?
অনুমতি দেওয়া আর অনুমতি ব্যবহৃত হয়েছে কি না জানা দুটো আলাদা জিনিস। আর এটা শুধু নিরাপত্তার প্রশ্ন নয় — এটা একটা ব্যবহারিক প্রশ্ন, যেটা প্রতিটা দলে কোনো একদিন ওঠে:
"ওই সার্ভারটা কোথায় গেল?"
ছবিটা দেখো, কারণ এখানে দুটো সম্পূর্ণ আলাদা প্রশ্ন আছে আর দুটো আলাদা সরঞ্জাম সেগুলোর উত্তর দেয়:
শেষ সারিটাই আসল কথা, আর এই দুটো মেলানোটাই সবচেয়ে সাধারণ ভুল। একটা dashboard ভরা গ্রাফ কখনো একজনের নাম বলতে পারে না। আর CloudTrail কখনো বলতে পারে না সাইটটা ধীর।
তাই একটা ঘটনার পরে দুটোই লাগে, আর এই ক্রমে:
১. Metric বলে কখন আচরণ বদলেছে — "০৯:৪১-এ ভুলের হার লাফ দিল"
২. Trail বলে ওই মুহূর্তে কী করা হয়েছিল, আর কে করেছিল
এক নম্বর দেয় সময়, দুই নম্বর দেয় কারণ। আর "গ্রাফটা ০৯:৪১-এ লাফ দিল" একটা অর্ধেক উত্তর — বাকি অর্ধেকটা একটা lookup দূরে।
CloudTrail আসলে কী রাখে, এটা জানা দরকার: প্রতিটা API কল। আর এখানে একটা জিনিস বোঝা জরুরি — AWS-এ সব কিছুই একটা API কল:
শেষ দুটো সারি লক্ষ্য করো — শুধু মানুষ নয়, যন্ত্র আর AWS-এর সেবাগুলোও এতে আসে। অর্থাৎ CloudTrail-এ একটা RunInstances দেখে সেটা মানুষ না scaling group, সেটাও বলা যায়।
আর একটা সুখবর, যেটা অনেকে জানে না: CloudTrail ডিফল্টে চালু।
তোমার অ্যাকাউন্টে এই মুহূর্তেই গত ৯০ দিনের প্রতিটা mutating API কলের হিসাব আছে, আর সেটা বিনামূল্যে। কিছু চালু করতে হবে না।
পরের সেকশনে দেখব এটা কেন যথেষ্ট নয় — কিন্তু আজ একটা প্রশ্নের উত্তর দরকার হলে উত্তরটা ইতিমধ্যেই আছে, আর এটা জানাই এই পর্বের সবচেয়ে ব্যবহারিক তথ্য।
💡 ধারণা
Event history — আর কেন এটা যথেষ্ট নয়
CloudTrail-এর যে অংশটা ডিফল্টে চালু, তার নাম Event history। আর এটা সত্যিই কাজের — কিন্তু চারটে সীমা আছে, আর প্রতিটা একটা নির্দিষ্ট পরিস্থিতিতে কামড়ায়।
সীমা ১ — ৯০ দিন।
ওই সময়ের বাইরের কিছুই নেই। আর এটা শুনতে অনেক মনে হয়, কিন্তু ভাবো: একটা ভুল কনফিগ যেটা চার মাস ধরে ওখানে আছে — কে এটা বসিয়েছিল, সেটা আর জানা যাবে না। আর সম্মতির নিয়মগুলো সাধারণত এক বছর বা সাত বছরের হিসাব চায়।
সীমা ২ — শুধু mutating কল।
Event history পড়ার কাজগুলো রাখে না — describe-instances, list-buckets, get-object। শুধু যা কিছু বদলায়।
এটা যুক্তিসঙ্গত (পড়ার কল হাজার গুণ বেশি), কিন্তু একটা নির্দিষ্ট প্রশ্নের উত্তর দেয় না: "কেউ কি আমাদের ডেটা পড়েছে?" — আর সেটাই একটা তথ্য-ফাঁসের তদন্তের কেন্দ্রীয় প্রশ্ন।
সীমা ৩ — এক region, এক অ্যাকাউন্ট।
কনসোলের event history তুমি যে region-এ আছ সেটার ঘটনা দেখায়। পর্ব ৪-এর সেই কথাটা মনে করো — কেউ একটা অপরিচিত region-এ কিছু বানালে, ওই region-এ না গিয়ে তুমি সেটা কখনো দেখবে না।
সীমা ৪ — প্রশ্ন করা কঠিন।
Event history-তে কয়েকটা ফিল্টার আছে — ব্যবহারকারী, event-এর নাম, সম্পদ। কিন্তু "গত মাসে যে যে ব্যবহারকারী একটা security group বদলেছে, নাম অনুযায়ী গুনে দাও" — এটা করা যায় না। কারণ ডেটাটা একটা অনুসন্ধানযোগ্য জায়গায় নেই।
এই চারটের সমাধান একটা জিনিস: একটা trail তৈরি করা।
একটা trail হলো একটা নির্দেশ: "প্রতিটা ঘটনা একটা S3 bucket-এ লিখে রাখো।" আর তার ফলে চারটে সীমাই সরে যায়:
বাকি অংশটা সাবস্ক্রাইবারদের জন্য
১৩৮টি অংশের ২৮টি দেখানো হয়েছে, ১১০টি বাকি