অভিনেতা আর নিয়মের বই আলাদা। Policy-র JSON ঘর ধরে ধরে, `Version` ঘরটা আসলে কী, Action আর ARN কীভাবে পড়ে, সিদ্ধান্তটা ঠিক কীভাবে নেওয়া হয়, explicit deny কেন অপরাজেয়, আর একটা দৃশ্যপট চালিয়ে প্রমাণ করা।
দুটো পর্ব ধরে আমরা কে নিয়ে কথা বলেছি — ব্যবহারকারী, দল, ভূমিকা। এই পর্বে কী করা যাবে, আর সেটা লেখা থাকে সম্পূর্ণ আলাদা জিনিসে।
ভাগটা এভাবে ভাবো:
আর এই ভাগটার একটা গুরুত্বপূর্ণ ফল আছে, যেটা অনেকে প্রথমে বোঝে না: একটা policy নিজে থেকে কিছু করে না। ওটা একটা নথি, একটা তালিকা। ওটা কারো সাথে জোড়া না হওয়া পর্যন্ত ওটার কোনো প্রভাব নেই।
এটাই কারণ কেন একই policy অনেক জায়গায় জোড়া যায় — একটা ব্যবহারকারীতে, একটা দলে, একটা role-এ। নিয়মের বইটা একটাই, আর পাঠকের সংখ্যা যত খুশি।
AWS-এ policy দুই ধরনের, আর শুরুতে প্রথমটাই ব্যবহার করা উচিত:
১. Managed policy — আলাদা একটা বস্তু হিসেবে থাকে, আর অনেক জায়গায় জোড়া যায়।
এর দুটো উপভাগ:
• AWS-এর নিজের — arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess। ARN-এ অ্যাকাউন্টের জায়গায় aws লেখা। সব অ্যাকাউন্টে একই, আর AWS নিজে এগুলো হালনাগাদ রাখে।
• তোমার নিজের — arn:aws:iam::123456789012:policy/MyCustomPolicy। তুমি লেখো, তুমি রাখো।
২. Inline policy — একটা নির্দিষ্ট ব্যবহারকারী, দল বা role-এর ভেতরে লেখা থাকে। আলাদা বস্তু নয়, পুনর্ব্যবহারযোগ্য নয়, আর ওই জিনিসটা মুছলে policy-ও মুছে যায়।
কখন কোনটা? একটা সহজ নিয়ম:
পুনর্ব্যবহারযোগ্য কিছু হলে managed, আর "শুধু এই একটা জিনিসের জন্য" হলে inline।
Inline-এর একটা আসল সুবিধা আছে: ওটা মূল বস্তুটার সাথে জন্মায় আর মরে। একটা role মুছলে তার inline policy-ও যায়, তাই পরিত্যক্ত policy জমে না। অসুবিধা হলো ওটা অদৃশ্য — একটা অ্যাকাউন্টে কতগুলো inline policy আছে তা এক কমান্ডে জানা যায় না, তাই অডিট করা কঠিন।
শুরুর জন্য পরামর্শ: AWS-এর managed policy দিয়ে শুরু করো, আর নিজের policy লিখতে শেখো তখন, যখন managed-গুলো যথেষ্ট সূক্ষ্ম নয়। এই পর্বটা সেই দ্বিতীয় অংশটার জন্য।
একটা policy একটা JSON নথি, আর তার গঠন ছোট — সাতটা ঘর, যার তিনটে বাধ্যতামূলক। নিচে একটা পূর্ণ উদাহরণ, আর তারপর ঘর ধরে ধরে।
প্রথমে বাইরের দুটো ঘর:
Version — একটা তারিখের মতো দেখতে লেখা, "2012-10-17"। এটা তোমার নথির সংস্করণ নয়, আর এটা পরের সেকশনের পুরো বিষয়।
Statement — একটা তালিকা। এখানেই আসল কাজ, আর একটা policy-তে অনেকগুলো statement থাকতে পারে।
এবার প্রতিটা statement-এর ভেতরে:
শেষ সারিটা আলাদা করে বোঝা দরকার, কারণ এটা একটা সাধারণ বিভ্রান্তি।
একটা সাধারণ permission policy-তে Principal থাকে না — আর থাকার দরকার নেই, কারণ policy-টা যার সাথে জোড়া, সেই-ই principal। তুমি rifat-dev-এর সাথে একটা policy জুড়েছ, তাই "কে" প্রশ্নের উত্তর ইতিমধ্যেই দেওয়া হয়ে গেছে।
Principal লাগে দুটো জায়গায়:
• Trust policy-তে (পর্ব ১০) — "কে এই role পরতে পারবে"
• Resource policy-তে — যেমন একটা S3 bucket-এর নিজের নীতি, যেটা জিনিসটার সাথে জোড়া থাকে, কোনো পরিচয়ের সাথে নয়
অর্থাৎ অনুমতির প্রশ্নটা দুদিক থেকে লেখা যায়: "এই ব্যবহারকারী ওই bucket-এ পড়তে পারবে" (identity policy), বা "এই bucket ওই ব্যবহারকারীকে পড়তে দেবে" (resource policy)। দুটোর যেকোনো একটা allow দিলেই যথেষ্ট — আর যেকোনো একটা deny দিলেই শেষ।
Condition ঘরটা ঐচ্ছিক কিন্তু খুব শক্তিশালী, আর কয়েকটা উদাহরণ দেখলেই ধারণাটা পরিষ্কার হয়:
• aws:MultiFactorAuthPresent — MFA ছাড়া এই কাজ করা যাবে না
• aws:SourceIp — শুধু অফিসের IP পরিসর থেকে
১৪৮টি অংশের ৩০টি দেখানো হয়েছে, ১১৮টি বাকি