দু-হাজার কর্মীর জন্য দু-হাজার IAM ব্যবহারকারী কেন ভুল উত্তর, federation আসলে কী, সাইন-ইনের প্রবাহটা ধাপে ধাপে, permission set কীভাবে কাজ করে, একজন ডেভেলপারের দিন কেমন দেখতে, CI pipeline-ও কীভাবে চাবিহীন হয়, আর STS-এর চারটে দরজা।
পর্ব ৯-এ আমরা ছ-জনের একটা দল নিয়ে কাজ করেছি, আর user-group-policy দিয়ে সেটা সুন্দরভাবে সাজানো গেছে।
এখন সংখ্যাটা বদলাও। দু-হাজার কর্মী, আর বারোটা AWS অ্যাকাউন্ট — development, staging, production, প্রতিটা দলের নিজের, এরকম। পর্ব ৯-এর পদ্ধতি এখানে চালালে কী দাঁড়ায়?
দু-হাজার IAM ব্যবহারকারী — প্রতিটা অ্যাকাউন্টে। অর্থাৎ চব্বিশ হাজার ব্যবহারকারী। আর সেটা শুধু সংখ্যার সমস্যা নয়, পাঁচটা আলাদা সমস্যা:
১. Onboarding — কেউ যোগ দিলে।
নতুন একজন ডেভেলপার এলো। তার জন্য বারোটা অ্যাকাউন্টে ব্যবহারকারী বানাতে হবে, প্রতিটায় সঠিক দলে রাখতে হবে, বারোটা পাসওয়ার্ড দিতে হবে, আর বারোটা MFA ডিভাইস নিবন্ধন করতে হবে।
এটা শুধু পরিশ্রম নয় — এটা ভুলের জায়গা। বারোটার মধ্যে একটায় ভুল দল, আর কেউ টের পাবে না যতক্ষণ না সেটা সমস্যা হয়।
২. Offboarding — কেউ চলে গেলে।
আর এটাই আসল বিপদ। কেউ চাকরি ছাড়লে বারোটা অ্যাকাউন্টে তার ব্যবহারকারী নিষ্ক্রিয় করতে হবে। একটা বাদ পড়লে?
একজন প্রাক্তন কর্মীর কাজ করা প্রবেশাধিকার থেকে যায় — আর ওটা মাসের পর মাস কারো চোখে পড়ে না, কারণ কেউ খোঁজে না।
৩. পাসওয়ার্ড আর MFA — দুটো আলাদা ব্যবস্থা।
কোম্পানির ইতিমধ্যেই একটা পরিচয় ব্যবস্থা আছে — যেটা দিয়ে মানুষ ইমেইল খোলে, ল্যাপটপে ঢোকে, ছুটির আবেদন করে। ওখানে পাসওয়ার্ডের নিয়ম আছে, MFA আছে, মেয়াদ আছে।
IAM ব্যবহারকারী বানানো মানে দ্বিতীয় একটা ব্যবস্থা তৈরি করা, যার নিজের নিয়ম, নিজের পাসওয়ার্ড, নিজের MFA। আর মানুষ দুটো আলাদা জায়গায় দুটো আলাদা পাসওয়ার্ড রাখলে যা হয়, সেটা পূর্বানুমেয়: একটা ঝুঁকি যোগ হয়, নিরাপত্তা বাড়ে না।
৪. অ্যাকাউন্ট-ভিত্তিক access key-র বিস্ফোরণ।
প্রত্যেকে যদি CLI ব্যবহার করে, তাহলে প্রত্যেকের বারোটা অ্যাকাউন্টে চাবি দরকার। সেগুলো তাদের ল্যাপটপে ফাইলে থাকবে, আর পর্ব ১০-এর সব সমস্যা এখানে দু-হাজার গুণ।
৫. অডিট — "কে কী করতে পারে" প্রশ্নের উত্তর নেই।
চব্বিশ হাজার ব্যবহারকারী আর তাদের দল-policy-র জালে "অর্থ বিভাগের কেউ কি প্রোডাকশন সার্ভার মুছতে পারে?" — এই প্রশ্নের উত্তর পড়ে বের করা অসম্ভব।
এই পাঁচটা সমস্যার একটা সাধারণ শিকড় আছে, আর সেটা দেখা গেলে সমাধানটা স্বতঃসিদ্ধ হয়ে যায়: আমরা একটা পরিচয় ব্যবস্থার নকল বানাচ্ছি, যেটা ইতিমধ্যেই আছে।
আর সেটাই পরের সেকশন।
সমাধানের ধারণাটা এক বাক্যে:
AWS-এ কর্মীদের জন্য ব্যবহারকারী বানাবে না। কোম্পানির যে পরিচয় ব্যবস্থা আছে, AWS-কে সেটাকেই বিশ্বাস করতে বলো।
এটাকে বলে federation। শব্দটা জটিল শোনায়, কিন্তু ধারণাটা আমরা রোজ ব্যবহার করি: যখন একটা ওয়েবসাইটে "Google দিয়ে সাইন ইন করুন" লেখা থাকে, তখন ওই সাইটটা তোমার জন্য একটা পাসওয়ার্ড রাখছে না — ওটা Google-কে বিশ্বাস করছে যে তোমার পরিচয়ের বিষয়ে সে সত্যি বলবে।
১১৩টি অংশের ২৩টি দেখানো হয়েছে, ৯০টি বাকি