هر وقت متوجه شدید که با مدل دسترسی AWS کار می کنید، مبتدی یا یک DevOps با تجربه هستید، اصطلاحات زیادی برای هضم و یادگیری وجود دارد.
کاربران، نقش‌ها و خط‌مشی‌ها اصطلاحاتی هستند که ما در اوایل کارمان یاد می‌گیریم، با این حال یک مفهوم وجود دارد که معنای زیادی در پشت آن وجود دارد، و به نظر من، شایسته توضیح بیشتر است: مدیر IAM!
IAM Principal: تعریف
بیایید با ارائه یک تعریف استاندارد شروع کنیم: یک اصل یک کاربر انسانی یا حجم کاری است که می تواند درخواست یک اقدام یا عملیات را در یک منبع AWS ارائه دهد.
علاوه بر این، یک اصل هر چیزی است، مرتبط با AWS، که بتواند از طریق کنسول مدیریت، API AWS یا AWS CLI درخواستی به AWS ارسال کنید.
مدیر IAM: بازیگران
در AWS چی یا سازمان بهداشت جهانی آیا «بازیگران»ی که می‌توان به آنها به عنوان اصلی اشاره کرد؟
- کاربر ریشه
- کاربران IAM
- نقش های IAM/توکن های امنیتی موقت
تفاوت های اصلی بین آنها هستند چه کسی می تواند آنها را جعل کند، و چه اعتباری به آنها اعطا می شود.
کاربران توسط کاربران انسانی جعل هویت می شوند در حالی که نقش ها بر اساس خدمات یا به طور کلی حجم کاری.
همچنین در حالی که اولی ها اعطا می شوند اعتبار طولانی مدت، استفاده از نقش ها اعتبارنامه موقت.
کاربر ریشه
کاربر ریشه مالک حساب اصلی AWS است و باید توسط آن محافظت شود وزارت امور خارجه و الف رمز عبور قوی درست پس از ثبت نام ما باید از استفاده از کاربر ریشه به عنوان یک اصلی خودداری کنید، به دلایل امنیتی، و در عوض از IAM Users and Roles استفاده کنید.
او با ایمیل و رمز عبور به AWS دسترسی پیدا می کند: به همین دلیل است که ما باید از استفاده از آن برای کار عملیات خودداری کنیم!
کاربران IAM
کاربر IAM یک است مداوم نهادی که مجموعه ای از اعتبارنامه ها برای مدیریت خدمات در AWS به آن داده می شود. کاربر IAM می‌تواند با اعتبارنامه‌های بلندمدت یا کوتاه مدت مرتبط باشد (موردهای کوتاه مدت سخت بسیار ترجیح داده شده است).
یک کاربر IAM می تواند مجوز انجام اقدامات را مستقیماً از طریق یک خط مشی AWS متصل به آن یا از طریق یک خط مشی گروهی داشته باشد.
یک کاربر IAM از طریق:
- کنسول مدیریت AWS
- CLI
- SDK ها
نقش IAM
یک نقش IAM یک نقش اصلی است مستقیماً به منابع AWS مرتبط است یا توسط یک کاربر IAM، AWS CLI یا یکی از AWS SDK های موجود فرض شده است. این دارد مجوزهای اعطا شده از طریق اعتبارنامه های موقت. یک یا چند خط مشی به آن پیوست شده است.
برخی از موارد استفاده مرتبط با نقش های IAM عبارتند از:
- نقش های آمازون EC2: اعطای مجوز به برنامه هایی که روی نمونه آمازون EC2 اجرا می شوند.
- دسترسی بین حسابی: اعطای مجوز به کاربران از سایر حساب های AWS، چه در کنترل آن حساب ها باشد یا نه.
توکن های امنیتی موقت:
توکن های امنیتی موقت از سرویس توکن امنیتی AWS (STS) دریافت می شوند.
آنها همیشه تاریخ و زمان انقضا دارند و بین آنها طول عمر دارند 15 دقیقه و تا 36 ساعت.
این توکن ها معمولاً از طریق a به دست می آیند فرآیند فدراسیون، که شامل اعطای مجوز به کاربران است توسط یک سیستم خارجی قابل اعتماد تأیید شده است.
در اینجا خلاصه‌ای از AWS آمده است که برخی از انواع نقش‌ها/توکن‌های امنیتی موقت و آنچه از آنها به دست می‌آید را نشان می‌دهد:
اشاره ویژه به کاربران AWS SSO که هستند از طریق مجموعه های مجوز IAM Identity Center پیکربندی شده است برای دسترسی به متفاوت حساب هایی با نقش های مختلف. زمانی که کاربر روی یک حساب کاربری وارد می شود یک نقش به صورت شفاف داده می شود برای دسترسی به خدمات و منابع مطابق با سیاست های تنظیم شده توسط مدیر.
نقش های IAM، AWS SSO و نشانه های امنیتی موقت برای استفاده پیشرفته از AWS IAM در نظر گرفته شده اند و همیشه دارای یک مدت زمان مجموعه محدود.
زیرا این اصول هستند بسیار مهم و همه کاره، من اکیداً توصیه می کنم بیشتر در مورد استدلال بخوانید، از این مقاله و همچنین این مقاله شروع کنید و با این مقاله از AWS Hero به پایان برسانید. مت لوئیس.
IAM Principal: احراز هویت، درخواست‌ها و مجوز
هنگام کار با Principals باید دو اقدامی را که باید انجام دهیم تا در نهایت مجموعه ای از اعتبارنامه های معتبر را بدست آوریم، درک کنیم.
اولین احراز هویت موضوع در برابر AWS یا یک ارائه دهنده هویت معتبر، و سپس مجوز قادر به انجام اقدامات و دسترسی به منابع خاص.
IAM Principal: احراز هویت
یک Principal همیشه باید برای ارسال درخواست های AWS احراز هویت کند.
فقط آمازون S3، SQS، SNS، و AWS STS اجازه درخواست‌های محدود (و خاص) از کاربران ناشناس را می‌دهند. اما آنها استثنا هستند.
برای ورود به عنوان یک کاربر ریشه در کنسول، از خود استفاده کنید ایمیل و رمز عبور.
به عنوان یک کاربر فدرال، می توانید از طریق منابع AWS دسترسی داشته باشید نقش‌های IAM که توسط احراز هویت ارائه‌دهنده هویت شما اعطا می‌شوند.
شناسه کلید دسترسی و کلید دسترسی مخفی خود را برای احراز هویت به عنوان یک وارد کنید کاربر IAM.
برای احراز هویت بارهای کاری، استفاده کنید موقت یا مدارک بلند مدت (همیشه اولی را ترجیح می دهید).
بهترین شیوه های DevOps استفاده از MFA و اعتبارنامه های موقت را برای ایمن نگه داشتن حساب خود توصیه می کند.
IAM Principal: درخواست
هنگامی که یک مدیر سعی می کند با استفاده از کنسول مدیریت AWS، یک SDK یا CLI کاری را با AWS انجام دهد، یک پیام ارسال می کند. درخواست به AWS با اطلاعات زیر:
- اقدامات یا عملیات: اقداماتی که باید انجام شود
- منابع: خدمات یا اشیاء AWS برای دستکاری.
- مدیر اصلی: و حالا می دانیم که آنها چه می توانند باشند 😀!
- داده های محیطی: ابرداده های مختلف، مانند آدرس IP، عامل کاربر و غیره.
- داده های منابع: ابرداده بسته به منبع خاص AWS.
AWS همه اینها را در یک قرار می دهد زمینه درخواست، که برای ارزیابی و تأیید درخواست استفاده می شود.
IAM Principal: مجوز
پس از احراز هویت، باید مجوز تکمیل درخواست خود را نیز داشته باشید.
در طول فرآیند مجوز، AWS از زمینه درخواست برای بررسی سیاست هایی که با درخواست مطابقت دارند.
سپس آن را خط‌مشی‌ها را برای تعیین اجازه یا رد درخواست تجزیه می‌کند.
اکثر خط مشی ها در AWS به عنوان اسناد JSON ذخیره می شوند و مجوزهای موجودیت های اصلی را مشخص می کنند. چندین نوع سیاست وجود دارد که می تواند بر نتیجه درخواست تأثیر بگذارد.
اگر یک سیاست مجوز واحد شامل یک اقدام رد شده است، AWS کل درخواست را رد می کند و ارزیابی را متوقف می کند.
زیرا درخواست ها هستند به طور پیش فرض رد شد، فقط در صورتی می توانند تکمیل شوند که هر قسمت از درخواست توسط خط مشی های مجوز مجاز باشد.
قوانین کلی برای درک نحوه عملکرد مجوز به شرح زیر است:
- به طور پیش فرض، همه درخواست ها رد می شوند.
- یک اجازه صریح (بر اساس هویت یا منبع محور) رد پیش فرض را لغو می کند.
- SCP سازمان‌ها، مرزهای مجوز IAM یا خط‌مشی‌های جلسه اجازه را لغو می‌کنند. ولی اگر بیش از یکی از این خط‌مشی‌ها وجود داشته باشد، همه آنها باید به درخواست اجازه دهند.
- یک رد صریح در هر خط مشی، هرگونه اجازه را نادیده می گیرد.
برای کسب اطلاعات بیشتر در مورد نحوه ارزیابی این فرآیند، به منطق ارزیابی سیاست مراجعه کنید.
IAM Principal: اعتبارنامه
همانطور که دیدیم دو نوع اعتبار وجود دارد که به یک Principal اعطا می شود: عمر طولانی و موقت کوتاه مدت.
اعتبارنامه های طولانی مدت تا زمانی که یک مدیر باقی می ماند به صراحت آنها را حذف می کند از یک Principals و معمولا، به اعمال می شود کاربران ریشه و کاربران/گروه های IAM.
اعتبارنامه های کوتاه مدت موقتی هستند، و تاریخ و زمان انقضا صریح دارند.
آنها از طریق سرویس AWS STS تولید می شوند و با نقش های IAM، نقش های فرضی مرتبط هستند، یا حتی هویت های فدرال (AWS SSO، وب، SAML، OIDC، OAuth، Cognito، Azure AD، و غیره)
IAM Principal: Best Practices
از آنجایی که اعتبارنامه‌های کوتاه‌مدت را می‌توان برای یک گروه یا یک کاربر به لطف عمل فرض نقش اعمال کرد، من اکیداً توصیه می کنیم به بهترین شیوه های DevOps پایبند باشید و همیشه در صورت امکان از اعتبارنامه های کوتاه مدت استفاده کنید.
استفاده از اعتبارنامه های موقت ترجیح داده می شود زیرا آنها آسیب احتمالی وارده توسط مهاجمی که آنها را می دزدند کاهش می دهند (از نظر زمان محدود هستند).
همچنین زرنگی به سیاست های مرتبط با کاربران و نقش ها را به حداقل مجموعه منابع محدود کنید که برای کار خود به آن نیاز دارید همیشه از قوانین Deny First استفاده کنید!
با معرفی IAM Identity Center همیشه برای مدیران ترجیح داده می شود که از آن برای ایجاد کاربران جدید استفاده کنند زیرا آنها همچنین از یک پنل فرود برای انتخاب اکانت و نقش بهره خواهند برد.
خلاصه کردن
در این مقاله کوتاه، با اصول AWS IAM آشنا شدیم، نحوه دسته‌بندی آنها و معنای آنها.
ما آموخته‌ایم که مدیران IAM باید هم با یک فرآیند احراز هویت و هم با یک فرآیند مجوز سر و کار داشته باشند تا بتوانند با موفقیت در AWS کار کنند.
ما دیدیم که درخواستی که توسط یک مدیر به AWS ارائه شده است، شامل چه مواردی است.
ما دیدیم که یک حساب ریشه و یک کاربر IAM چیست، چه تفاوتی با نقش های IAM و علاوه بر آن با توکن های امنیتی موقت دارند.
ما تفاوت‌های بین اعتبارنامه‌های طولانی و کوتاه مدت و اینکه چرا دومی ارجح و ایمن‌تر هستند را تحلیل کرده‌ایم.
برای استفاده بهتر از اصول AWS شما، بهترین روش های اساسی را پیشنهاد کرده ایم.
بنابراین، از همه شما برای رسیدن به پایان مقاله متشکرم!
مثل همیشه، اگر پیشنهاد یا سوالی دارید، بیایید و در انجمن slack ما با ما گپ بزنید.
تا دفعه بعد، می بینمت و ایمن بمان! 🙂
