IAM ১ — ব্যবহারকারী, দল আর ভূমিকাভিত্তিক অনুমতি

আটটা পর্ব ধরে আমরা একটা প্রশ্ন এড়িয়ে এসেছি। প্রতিটা পর্বের প্রথম কাজ ছিল aws configure — একটা চাবি বসানো। ওই চাবিটা কার? ও কী কী করতে পারে? আর কেন সে সব কিছু করতে পারা উচিত নয়?

একা শেখার সময় প্রশ্নটা ফাঁকা শোনায়। একটা অ্যাকাউন্ট, একজন মানুষ, একটা চাবি — সব কিছু করতে পারে, আর অসুবিধা কোথায়?

অসুবিধাটা দেখা যায় যখন দ্বিতীয় মানুষটা আসে। ধরা যাক ছ-জনের একটা দল:

• দুজন ডেভেলপার, যাদের অ্যাপ্লিকেশনের লগ পড়তে হয় আর কোড deploy করতে হয়

• একজন নতুন ইন্টার্ন, প্রথম সপ্তাহ

• একজন হিসাবরক্ষক, যাকে শুধু বিলটা দেখতে হয়

• একটা CI pipeline, যেটা রাত তিনটেয় নিজে নিজে deploy করে

• তুমি, যে পুরোটা চালাও

এখন "একটা চাবি সবাইকে দিয়ে দাও" — এই উত্তরটা কোথায় কোথায় ভাঙে, একটা একটা করে দেখো:

১. হিসাবরক্ষক সার্ভার মুছে ফেলতে পারবেন। তিনি মুছবেন না, নিশ্চয়ই। কিন্তু পারবেন — আর নিরাপত্তা "কেউ করবে না" ধারণার উপরে দাঁড়ায় না।

২. ইন্টার্ন প্রোডাকশন ডেটাবেস মুছে ফেলতে পারবে। প্রথম সপ্তাহে, একটা ভুল কমান্ডে। এটা দুষ্টুমি নয়, এটা শেখার স্বাভাবিক অংশ — আর সেজন্যই সীমানাটা দরকার।

৩. কে কী করেছে, জানার কোনো উপায় নেই। সবাই একই চাবি ব্যবহার করলে প্রতিটা কাজের পাশে একই নাম লেখা থাকবে। পর্ব ১৮-এ আমরা CloudTrail দেখব, যেটা প্রতিটা কাজের হিসাব রাখে — কিন্তু একটা অভিন্ন চাবি ওই হিসাবটাকে অর্থহীন করে দেয়।

৪. একজন চলে গেলে সবার চাবি বদলাতে হবে। ইন্টার্নশিপ শেষ হলে চাবিটা বাতিল করতে হবে — আর ওই এক চাবিতেই CI pipeline চলছে, তোমার ল্যাপটপ চলছে, সব চলছে। একজনের প্রস্থান মানে সবার কাজ বন্ধ।

৫. CI pipeline-এর চাবি একটা ফাইলে লেখা থাকে। আর ওই চাবিটা যদি সব কিছু করতে পারে, তাহলে ওই ফাইলটা ফাঁস হওয়া মানে পুরো অ্যাকাউন্ট ফাঁস। (পর্ব ১০-এ দেখব এর আসল সমাধান — চাবিটা একেবারেই না রাখা।)

IAM — Identity and Access Management — এই পাঁচটা সমস্যারই উত্তর। আর এটা AWS-এর সবচেয়ে গুরুত্বপূর্ণ সেবা, একটা কারণে: তুমি যা কিছু করো, সব কিছু এর ভেতর দিয়ে যায়। একটা run-instances কমান্ড, কনসোলের একটা ক্লিক, Boto3-এর একটা কল — প্রতিটার আগে IAM একই প্রশ্ন জিজ্ঞেস করে আর উত্তর দেয় হ্যাঁ বা না।

আর একটা ভালো খবর: IAM-এর কোনো দাম নেই। ব্যবহারকারী, দল, ভূমিকা, policy — সব বিনামূল্যে, যত খুশি।

পরের চারটে পর্ব IAM নিয়ে, কারণ এটা একটা পর্বে বলার মতো জিনিস নয়। এই পর্বে কে — ব্যবহারকারী আর দল। পর্ব ১০-এ ভূমিকা, যেটা মানুষের বদলে যন্ত্রের জন্য। পর্ব ১১-এ নিয়মের বই — policy কীভাবে পড়তে হয় আর সিদ্ধান্তটা কীভাবে হয়। পর্ব ১২-এ বাইরের পরিচয় — পুরো কোম্পানির লোক কীভাবে নিজের পরিচয় দিয়েই ঢোকে।

IAM বোঝার আগে একটা জিনিস আলাদা করে নিতে হবে, কারণ এই দুটো মেলালে বাকি সব কিছু ঘোলা হয়ে যায়।

প্রতিটা অনুরোধে AWS দুটো সম্পূর্ণ আলাদা প্রশ্ন জিজ্ঞেস করে, আর ক্রম অনুসারে:

দুটো প্রশ্ন, আর দুটো সম্পূর্ণ আলাদা ব্যবস্থা তাদের উত্তর দেয়। আর এই আলাদা থাকাটাই গুরুত্বপূর্ণ — কারণ তোমার পরিচয় প্রমাণিত হওয়া মানে তুমি কিছু করতে পারবে, এমন নয়।

একটা তুলনা, যেটা আমি কাজের মনে করি: একটা লাইব্রেরি কার্ড। কার্ডটা দেখিয়ে তুমি প্রমাণ করো তুমি কে — ওটা প্রথম প্রশ্নের উত্তর। কিন্তু কার্ডটা দেখানোর পরেও তুমি বিরল সংগ্রহের ঘরে ঢুকতে পারবে না, গবেষণা কক্ষ ব্যবহার করতে পারবে না, আর বই নিয়ে বাড়ি যেতে পারবে না যদি ওই অনুমতিগুলো তোমার কার্ডে না থাকে। কার্ডটা তোমার নাম বলে; নামের সাথে কী কী যুক্ত, সেটা আলাদা তালিকা।

AWS-এ এই দুটোর যন্ত্রপাতি আলাদা:

প্রথম প্রশ্নের উত্তর দেয় credentials — তোমার কাছে কী আছে:

• কনসোলের জন্য: একটা পাসওয়ার্ড, আর (আশা করি) একটা MFA ডিভাইস

• CLI আর SDK-র জন্য: একটা access key id আর একটা secret access key

• একটা ভূমিকার জন্য: একটা অস্থায়ী token, যার মেয়াদ এক ঘণ্টা (পর্ব ১০)

দ্বিতীয় প্রশ্নের উত্তর দেয় policy — তোমার সাথে কী কী নিয়ম জোড়া আছে। এগুলো JSON নথি, আর পর্ব ১১ পুরোটা এই নিয়ে।

এই ভাগটা কাজে লাগে কোথায়? ভুলের বার্তা পড়ার সময়, আর এটা সময় বাঁচায়:

An error occurred (InvalidClientTokenId): The security token included
in the request is invalid.

এটা প্রথম প্রশ্নের ব্যর্থতা। চাবিটা ভুল, মেয়াদোত্তীর্ণ, বা মুছে ফেলা হয়েছে। Policy নিয়ে মাথা ঘামানোর কিছু নেই — AWS জানেই না তুমি কে।

An error occurred (AccessDenied): User: arn:aws:iam::123456789012:user/
rifat-dev is not authorized to perform: ec2:TerminateInstances

এটা দ্বিতীয় প্রশ্নের ব্যর্থতা, আর লক্ষ্য করো বার্তাটা কতটা তথ্যবহুল: কে (rifat-dev), কী (ec2:TerminateInstances)। চাবি ঠিক আছে, পরিচয় প্রমাণিত — শুধু ওই কাজটার অনুমতি নেই।