بهترین روش های امنیتی AWS: استفاده از IAM برای احراز هویت و مجوز سرویس به سرویس

یکی از جنبه های حیاتی سرویس های ابری، ارتباط سرویس به سرویس است و انجام ایمن آن ضروری است. به عنوان یک معمار که خدمات احراز هویت و مجوز متمرکز را در CyberArk، ارائه‌دهنده امنیت سایبری SaaS، طراحی کرده است، دیدگاه خود را در مورد ایجاد یک مکانیسم مجوز امن بین سرویس‌های مبتنی بر ابر AWS، خواه بدون سرور یا کانتینر، به اشتراک می‌گذارم.

با پایان خواندن این پست، نه تنها اهمیت احراز هویت و مجوز سرویس را درک خواهید کرد، بلکه به دانش عملی برای پیاده سازی آن نیز مجهز خواهید شد. این شامل فعال کردن ایمن دسترسی بین حساب به منابع برای الگوهای ارتباطی همزمان و ناهمزمان با استفاده از AWS IAM است.

این پست شامل سیاست های JSON IAM و نمونه کدهای پایتون است.

این پست اولین مورد از بسیاری از موضوعات امنیتی در مجموعه های آینده است.

این پست وبلاگ در ابتدا در وب سایت من، “Ran The Builder” منتشر شد.

فهرست مطالب

1. مفاهیم احراز هویت و مجوز

2. الگوهای ارتباطی سرویس به سرویس

3. احراز هویت و مجوز مبتنی بر IAM

4. راه حل IAM ارتباط همزمان

5. راه حل ارتباط ناهمزمان

6. انتخاب بین نقش فرضی و سیاست های مبتنی بر منابع

7. خلاصه

8. ضمیمه: درگاه های API خصوصی و عمومی

مفاهیم احراز هویت و مجوز

احراز هویت عبارت است از:

احراز هویت عمل اثبات یک ادعا است، مانند هویت کاربر سیستم کامپیوتری – ویکی پدیا

و مجوز از طرف دیگر عبارت است از:

عملکرد مشخص کردن حقوق/امتیازات دسترسی به منابع – ویکی‌پدیا است

در یک سرویس ایمن، احراز هویت و مجوز دست به دست هم می دهند.

به‌عنوان یک توسعه‌دهنده سرویس که یک REST API را افشا می‌کند، بسیار مهم است که درک کنید که باز گذاشتن API خود برای جهان بدون احراز هویت و اقدامات مجوز مناسب می‌تواند منجر به دسترسی غیرمجاز و دستکاری داده‌ها شود.

شما می‌خواهید که خدمات شما ابتدا درخواست‌های ارتباطی از سوی سرویس‌های تأیید شده (اصول) را بپذیرد، خدماتی که هویت آنها قابل اعتماد و شناخته شده است. پس از شناسایی، می‌خواهید مطمئن شوید که فقط سرویس‌های مجاز می‌توانند API شما را فعال کنند یا با سرویس شما ارتباط برقرار کنند.

یا به عبارت دیگر:

1. هدف احراز هویت، تأیید و شناسایی اینکه یک اصل همان چیزی است که ادعا می کند است.

2. هدف مجوز تعریف رابطه بین اصول، اقدامات و منابع است.

می‌توانیم مجوز را به‌عنوان رابطه بین اصلی‌ها (سرویس‌ها)، اقداماتی که می‌خواهند انجام دهند (مثلاً اجرای یک API) و منابع (نقطه پایانی REST API واقعی و نوع عمل HTTP) که اقدامات آنها بر اساس آنها فراخوانی می‌شود، تجسم کنیم.

بنابراین، امنیت ارتباط سرویس به سرویس به دو بخش تقسیم می شود:

• ابتدا مطمئن شوید که خدمات تماس گیرنده همان چیزی است که ادعا می کند.

• سپس، ادعا کنید که مجوز اقدام در مورد منبع را دارد.

برای درک بهتر اهمیت احراز هویت و مجوز، اجازه دهید چند نمونه واقعی از ارتباطات سرویس به سرویس را در نظر بگیریم. این مثال‌ها نقش مهمی را که این اقدامات در تضمین امنیت و یکپارچگی سرویس‌های REST API ایفا می‌کنند برجسته می‌کند.

الگوهای ارتباطی سرویس به سرویس

توسعه دهندگان زمان زیادی را صرف طراحی API های REST مشتری می کنند. این APIها مفهوم کاربران را به سیستم معرفی می کنند (انسانی یا غیر انسانی). AWS چندین گزینه احراز هویت کاربر و سرویس مانند Amazon Cognito (Cognito) و AWS Identity and Access Management (IAM) را ارائه می دهد، که IAM گزینه اصلی برای مدیریت کاربر داخلی است، در حالی که Cognito می تواند به ارائه دهندگان هویت خارجی مانند CyberArk و دیگران متصل شود.

در این پست، می‌خواهم بر روی AWS IAM و نقش آن در یک جنبه مهم از خدمات ابری تمرکز کنم: احراز هویت سرویس به سرویس و مجوز.

الگوی ارتباط همزمان

در این مورد، سه سرویس وجود دارد: A، B و C، که هر کدام در حساب AWS خود هستند.

سرویس A بدون سرور است، B مبتنی بر EC2 است، و C یک API REST با API Gateway ارائه می دهد. هر دو سرویس A و B از API سرویس C استفاده می کنند.

*این قسمت در مورد دروازه های API عمومی بحث می کند. برای API Gateway خصوصی، به پیوست زیر مراجعه کنید.

با این حال، سرویس C می‌خواهد اطمینان حاصل کند که فقط این سرویس‌های خاص می‌توانند API خود را فراخوانی کنند و شاید حتی آن را به گونه‌ای تنظیم کنند که کمترین امتیاز را داشته باشد به طوری که فقط یک عملکرد لامبدا خاص یا یک ماشین EC2 بتواند آن را راه‌اندازی کند.

بیایید به الگوی دوم ادامه دهیم.

الگوی ارتباط ناهمزمان

در این مورد استفاده، ما سه سرویس خود را مانند قبل داریم:

• A، B و C هر کدام مانند قبل در حساب AWS خود هستند.

• C دارای یک موضوع SNS است که به عنوان یک سرویس ارتباطی ناهمزمان ناشر-مشترک متمرکز در سازمان استفاده می شود.

سرویس A ناشر است و سرویس B از طریق یک صف SQS در موضوع SNS مشترک می شود.

سرویس C می‌خواهد اطمینان حاصل کند که فقط سرویس A می‌تواند پیام‌هایی را برای موضوع SNS منتشر کند و فقط SQS سرویس B می‌تواند در موضوع مشترک شود زیرا موضوع حاوی داده‌هایی است که باید خصوصی نگه دارید.

این یک الگوی استاندارد است. می توانید موضوع SNS را با گذرگاه EventBridge یا هر سرویس پیام رسانی که ممکن است داشته باشید، مانند Amazon MSK تغییر دهید.

حساب های تک یا چندگانه

به عنوان یک نکته جانبی، سرویس‌های A، B و C ممکن است یک حساب مشترک داشته باشند که راه‌حل IAM را ساده‌تر می‌کند. با این حال، پیروی از شیوه های IAM در این پست ضروری است، حتی اگر همه خدمات یک حساب مشترک داشته باشند از میانبر استفاده نکنید ممکن است در آینده متوجه شوید که آنها را به حساب های مختلف منتقل می کنید. در این صورت، اگر بهترین روش ها را دنبال نکنید، کار سختی خواهید داشت و تغییرات شکسته زیادی (از تجربه!) پیش روی شماست. بهتر است همیشه بهترین شیوه ها را دنبال کنید، به خصوص زمانی که امنیت در میان باشد.

احراز هویت و مجوز مبتنی بر IAM

اکنون که ما اصول اولیه سرویس برای احراز هویت و مسائل مربوط به مجوز را پوشش دادیم، اجازه دهید راه حل را مورد بحث قرار دهیم و شروع به استفاده از AWS IAM کنیم.

این راه حل هم احراز هویت و هم مجوز بین حساب و یک حساب را پوشش می دهد.

احراز هویت IAM به این معنی است که یک اصل، به عنوان مثال، سرویس A، باید با استفاده از اعتبار خود برای ارسال درخواست به سایر خدمات و منابع AWS یا سرویس C در مثال ما، احراز هویت شود (ورود به AWS). پس از احراز هویت، می‌توانیم دوباره از IAM استفاده کنیم تا مطمئن شویم که سرویس A مجاز به دسترسی به سرویس C است.

ما دو جنبه از IAM، سیاست‌های مبتنی بر هویت و مبتنی بر منبع را ترکیب خواهیم کرد و راه‌حل‌های مجوز برای ارتباطات همزمان و ناهمزمان ارائه خواهیم کرد. ما همچنین دسترسی بین حساب‌ها، به عنوان مثال، خدمات مجوز از حساب‌های مختلف AWS را با استفاده از «نقش بر عهده» یا مکانیسم تفویض اختیار ارائه می‌کنیم.

سیاست های مبتنی بر منابع

طبق اسناد AWS:

خط‌مشی‌های مبتنی بر منبع، مجوز اصلی مشخص‌شده را برای انجام اقدامات خاص روی آن منبع می‌دهند و مشخص می‌کنند که تحت چه شرایطی این کار اعمال می‌شود.

خط‌مشی‌های مبتنی بر منبع، اسناد خط‌مشی JSON هستند که به منبعی مانند API Gateway، SNS، S3 یا منبع دیگری پیوست می‌کنید. با سیاست‌های مبتنی بر منبع، می‌توانید مشخص کنید چه کسی به منبع دسترسی دارد و چه اقداماتی می‌تواند روی آن انجام دهد. علاوه بر این، می توان از آنها برای اجازه دسترسی بین حساب ها استفاده کرد. عالی به نظر می رسد، درست است؟ خوب، محدودیت هایی دارد و همه انواع منابع از آن پشتیبانی نمی کنند.

اجازه دهید جوانب مثبت و منفی این مکانیسم IAM را مرور کنیم.

طرفداران:

1. ساده برای تعریف

2. دسترسی بین حسابی را فعال کنید.

معایب:

1. همه منابع AWS از سیاست های مبتنی بر منبع پشتیبانی نمی کنند.

2. خط‌مشی‌های مبتنی بر منبع مانند همه سیاست‌های IAM دارای محدودیت اندازه هستند. وقتی منابع بیشتری تعریف می‌کنید و به حداکثر اندازه می‌رسید، راهی برای غلبه بر آن وجود ندارد جز تهیه یک منبع جدید (در اصل، بخشی از سرویس C را کپی کنید).

مکانیسم نقش را فرض کنید

مکانیسم تفویض اختیار دسترسی IAM، یا همان طور که من آن را «برعهده گرفتن نقش» می نامم، در ارتباطات بین حسابی بسیار مهم است. با این حال، می توان از آن در یک سناریوی حساب AWS نیز استفاده کرد.

مکانیسم تفویض اختیار دسترسی IAM توسط سیاست های هویت محور به نقش IAM متصل است. در مثال ما، نقش C در حساب سرویس C قرار دارد و به منبع مورد نظر دسترسی می دهد، که می تواند دروازه API سرویس C یا موضوع SNS باشد.

هر کسی که اجازه به عهده گرفتن نقش C را داشته باشد می‌تواند مجموعه‌ای از اعتبارنامه‌های امنیتی موقت IAM را دریافت کند که می‌تواند برای احراز هویت و مجوز برای برقراری ارتباط با سرویس C استفاده شود، چه برای اجرای یک تماس API REST یا انتشار یک پیام به یک موضوع SNS.

با فرض اینکه یک نقش شامل برقراری تماس AWS SDK با Amazon STS (سرویس رمز امنیتی AWS) و استفاده از اعتبارنامه‌های موقت از پاسخ SDK برای شروع یک جلسه ارتباطی با سرویسی است که قصد دارید با آن ارتباط برقرار کنید، نمونه‌های کد را بعداً در این پست بررسی خواهیم کرد. تا اطمینان حاصل شود که درک جامعی از فرآیند دارید.

با این حال، ما باید تعریف کنیم که چه کسی می‌تواند این نقش را بر عهده بگیرد و به سرویس C دسترسی پیدا کند. به سیاست‌های منابع نیاز داریم و تعریف می‌کنیم که فقط نقش‌های سرویس‌های A و B می‌توانند نقش C را بر عهده بگیرند و به سرویس C دسترسی پیدا کنند.

اجازه دهید جوانب مثبت و منفی این مکانیسم IAM را مرور کنیم.

طرفداران:

1. تا زمانی که بتوانید یک خط مشی IAM تعریف کنید، از همه انواع منابع پشتیبانی می کند.

2. منبع و ARN آن را خلاصه می کند. نقشی دریافت می کنید که دسترسی شما را فراهم می کند. این منبع می‌تواند فردا تغییر کند، اما تنها چیزی که می‌دانید نقش ARN و آنچه API برای استفاده از آن فراخوانی می‌کند است. فرض کنید تماس در یک SDK سازمانی انتزاعی شده است که منبع را کپسوله می کند. در آن صورت، می‌توانید منابع – موضوع SNS را به گذرگاه EventBridge – تغییر دهید و تغییرات در سیاست‌های نقش و سطوح اجرای SDK را حفظ کنید، اما نقش ARN‌ها ثابت می‌ماند.

3. خط مشی مبتنی بر منبع نقش C، که تعیین می کند چه کسی می تواند نقش را به عهده بگیرد، دارای محدودیت اندازه است. با این حال، اگر بخواهیم خدمات بیشتری اضافه کنیم، می‌توانیم نقش جدیدی را برای سرویس‌های جدید ارائه کنیم. برخلاف مکانیسم قبلی، ارائه یک منبع جدید اشکالی ندارد زیرا منبع محافظت شده بدون تغییر باقی می ماند (مبحث API Gateway یا SNS).

معایب:

1. تعریف آن پیچیده تر است و به یک نقش اضافی در سرویس C نیاز دارد.

2. فرض اینکه یک نقش یک فراخوان دیگر AWS SDK است که زمان اجرای کلی سرویس‌های A و B و کدهای مستعد خطا را برای نگهداری بیشتر می‌کند.

بیایید ببینیم چگونه می‌توانیم مشکلات احراز هویت و مجوز خود را در الگوهای ارتباطی همزمان و ناهمزمان با سیاست‌های مشخص IAM و نمونه‌های کد پایتون حل کنیم.

راه حل IAM ارتباط همزمان

بیایید با تقویت امنیت سرویس C، دروازه API شروع کنیم. ابتدا یک مجوز IAM را به تمام نقاط انتهایی API آن اضافه می کنیم. با انجام این کار، به طور پیش فرض، تمام درخواست های احراز هویت نشده و غیرمجاز رد می شوند.

وقتی مجوز IAM فعال است، مشتریان باید از Signature نسخه 4 برای امضای درخواست های خود با اعتبارنامه AWS استفاده کنند. API Gateway فقط در صورتی مسیر API شما را فراخوانی می‌کند که کلاینت مجوز execute-api برای مسیر را داشته باشد. – اسناد AWS

AWS IAM تضمین می‌کند که فقط درخواست‌ها با احراز هویت و مدارک معتبر IAM که هستند مجاز است C API سرویس را اجرا خواهد کرد. تنها چیزی که باقی می ماند این است که سرویس C تعریف کند که کدام سرویس ها (هویت ها) و حساب های AWS می توانند API های خود را اجرا کنند.

دو راه برای رسیدن به آن وجود دارد:

1. سیاست مبتنی بر منابع

2. سیاست‌های مبتنی بر هویت مکانیسم‌های نقشی را فرض می‌کنند.

بیایید با یک سیاست مبتنی بر منابع شروع کنیم.

سیاست مبتنی بر منابع

در این مورد، ما باید خط مشی مبتنی بر منبع API Gateway سرویس C را تغییر دهیم تا به سرویس‌های A و B (مثلاً نقش تابع Lambda آنها یا کل حساب یا نقطه پایانی VPC و غیره) اجازه دهیم API و نقاط پایانی آن را اجرا کنند. ما می توانیم یک تعریف دقیق تعریف کنیم و دقیقاً تصمیم بگیریم که هر سرویس با چه نقطه پایانی می تواند ارتباط برقرار کند.

در اینجا مثالی از چنین سیاست منابعی برای سرویس C API Gateway آورده شده است:

در خطوط 8 تا 9، می‌توانیم یک حساب کامل (اصلی) مانند حساب سرویس A یا حساب B یا یک نقش خاص ARN را در یک حساب دیگر (گزینه بهتر، کمترین امتیاز)، عمل (خط 12) مجاز کنیم. اجرای یک نقطه پایانی API ما می توانیم نقطه پایانی دقیق و دستور HTTP را در خط 14 تنظیم کنیم.

توجه داشته باشید که در حال حاضر، نمی‌توانید از این مکانیسم در یک HTTP API Gateway، فقط در نوع REST استفاده کنید.

در سمت سرویس‌های A و B، آنها باید نقش‌های خود را (نقش تابع لامبدا برای سرویس A) با مجوزهای هویتی برای همان عملکرد مشخص‌شده در خط‌مشی منبع تعریف کنند. برای دسترسی متقابل حساب، شما باید سیاست را به این صورت دو طرفه تعریف کنید. سرویس A نقش تابع Lambda خود را با مجوز برای فراخوانی سرویس C API Gateway تعریف می کند و سرویس C به سرویس A اجازه می دهد تا آن را از حساب دیگر فراخوانی کند.

علاوه بر این، سرویس‌های A و B باید اعتبار IAM خود (Sig v4) را در هدر مجوز HTTP هنگام تماس با سرویس C’s API Gateway ارسال کنند.

در اینجا یک مثال پایتون برای این فرآیند آورده شده است:

در این مثال، ما از نقش سرویس خود برای احراز هویت با IAM استفاده می کنیم، هدرهای احراز هویت را در خط 7 ایجاد می کنیم و آنها را در خط 15 ارسال می کنیم.

نقش را فرض کنید

در این مورد، ما باید یک نقش در حساب سرویس C با مجوز برای اجرای دروازه API ایجاد کنیم و اجازه دهیم یک اصلی در سرویس های A و B آن را فرض کند.

ما می توانیم با تعریف خط مشی اعتماد نقش شروع کنیم – در این خط مشی، منبع، خود نقش است.

ما به نقش‌های خاص (اصول) از سرویس‌های A و B اجازه می‌دهیم این نقش (عمل) را بر عهده بگیرند. می‌توانیم دامنه وسیع‌تری را برای سرویس‌های A یا B، یا به کل حساب یا نقشی با پیشوند از پیش تعریف‌شده ارائه کنیم. با این حال، معمولاً بهتر است دامنه را به حداقل برسانید، بنابراین یک پیشوند نقش یا یک نقش خاص بهتر و امن تر است.

در مرحله بعد، باید مجوزهای نقش را برای اجرای API سرویس C به نقش اضافه کنیم:

در نهایت، کد سرویس A با اضافه شدن کد نقش فرضی، بسیار شبیه به قبل است.

می توانید نمونه کدهای چند سرویس را در اینجا بیابید یا به کد زیر مراجعه کنید.

برای «RoleArn»، باید نقشی را ارائه کنید که سرویس C ایجاد می‌کند و ARN خود را با شما به اشتراک می‌گذارد. به طور معمول، تیم های خدماتی ARN ها را به صورت دستی مبادله می کنند. من توصیه می کنم آن ARN را به عنوان یک متغیر محیطی در تابع Lambda ذخیره کنید. همچنین، مطمئن شوید که نقش Lambda شما دارای مجوزهای لازم برای به عهده گرفتن نقش است.

همانطور که در زیر مشاهده می کنید، کد بسیار شبیه به نمونه کد قبلی است، فقط با اضافه شدن فراخوانی STS API در خطوط 5-10 و استفاده از مقادیر پاسخ در خطوط 11-18.

اگر می خواهید در مورد موارد استفاده از API Gateway خصوصی بیاموزید، به پیوست مراجعه کنید.

راه حل ارتباط ناهمزمان

هدف ما این است که به سرویس A اجازه دهیم پیام های SNS را برای سرویس موضوع SNS C منتشر کند و به سرویس B اجازه دهیم از طریق SQS در پیام های SNS مشترک شود.

بیایید دو گزینه پیاده سازی IAM را که در اختیار داریم بررسی کنیم.

سیاست مبتنی بر منابع

در این مورد، ما یک خط مشی دسترسی SNS تعریف می کنیم که به سرویس A (اصلی) اجازه می دهد پیام ها (عمل) را در موضوع SNS سرویس C (منبع) و سرویس B برای اشتراک پیام ها منتشر کند. توصیه می شود که بهتر است این مجوزها را با نقشی که می تواند منتشر کند و SQS خاصی که می تواند مشترک شود تنظیم کنید.

در سمت سرویس A، نقش Lambda مجوزهای خود را برای انتشار در موضوع SNS تعیین می کند. داشتن مجوزهای تعریف شده توسط دو طرف به آنها امکان می دهد در هنگام برخورد با دسترسی بین حساب ها کار کنند.

هنگام انتشار پیامی به موضوع، تابع Lambda سرویس A از AWS SDK برای برقراری تماس API استفاده می کند. SDK از اعتبار نقش تابع برای مراقبت از سمت تأیید اعتبار و مجوز IAM استفاده می کند.

در سمت سرویس B، باید با دنبال کردن مستندات اینجا، یک اشتراک SQS برای موضوع SNS تعریف کنیم.

نقش را فرض کنید

در این مورد، باید یک نقش در اکانت سرویس C با مجوز انتشار پیام‌ها به موضوع SNS ایجاد کنیم. سپس، اجازه می دهیم نقش خاصی از سرویس A این نقش را بر عهده بگیرد.

ما می توانیم این کار را با تعریف خط مشی اعتماد نقش انجام دهیم.

می‌توانیم دامنه وسیع‌تری برای سرویس A به کل حساب یا نقشی با پیشوند از پیش تعریف‌شده بدهیم. با این حال، معمولاً بهتر است دامنه را به حداقل برسانید. از این رو، یک پیشوند نقش یا یک نقش خاص بهتر و امن تر است.

در مرحله بعد، باید مجوز انتشار پیام‌ها را برای سرویس موضوع SNS C به نقش اضافه کنیم:

اکنون، در سمت سرویس A، باید این نقش را به عهده بگیریم و از AWS SDK برای ارسال پیام‌های SNS استفاده کنیم. همچنین مهم است که مطمئن شویم نقش تابع Lambda دارای مجوزهای ‘sns:Publish’ و ‘sts:AssumeRole’ است. در غیر این صورت، تماس های AWS SDK کار نمی کنند.

تیم های خدماتی باید ARN های منبع و شماره حساب ها را مبادله کنند تا خط مشی ها کار کنند.

سرویس A نقش تماس SDK را بر عهده می گیرد و از اعتبارنامه موقت IAM برای ایجاد یک کلاینت بوتو برای تماس انتشار پیام SDK SNS استفاده می کند.

سرویس B مانند مثال خط مشی مبتنی بر منبع باقی می ماند. فقط می تواند به عنوان یک خط مشی منبع کار کند که به SQS خود اجازه می دهد مشترک شود. با این حال، سرویس A به برخی تغییرات کد نیاز دارد.

انتخاب بین نقش فرضی و سیاست های مبتنی بر منابع

ارتباط سرویس شما با احراز هویت و مجوز ایمن خواهد بود، چه خط‌مشی‌های مبتنی بر منابع را انتخاب کرده باشید یا راه‌حل‌های نقش فرضی را انتخاب کنید. با این حال، هر پیاده سازی مزایا و معایب خود را دارد که اگر آنها را نادیده بگیرید می تواند زندگی شما را در آینده سخت تر کند.

من توصیه خود را بر اساس پارامترهای مختلف تقسیم می کنم.

فرض کنید من مجبور بودم فقط یک پیاده سازی را انتخاب کنم. در این صورت، من مسیر «نقش را برعهده بگیرم» پیش می‌روم، زیرا به سرویس من اجازه می‌دهد تا چندین سرویس را در آینده به راحتی پشتیبانی کند. من می‌توانم نقش‌های بیشتری برای پشتیبانی از سرویس‌های بیشتری ایجاد کنم که آنها را در نظر می‌گیرند و به اندازه خط‌مشی IAM محدود نمی‌شوم.

با این حال، اگر فقط به عملکرد اهمیت می دهید، خط مشی های مبتنی بر منابع بهتر هستند، بنابراین برای بر عهده گرفتن این نقش، تماس دیگری از SDK اضافه نکنید. به خاطر داشته باشید که این سیاست ها دارای حداکثر اندازه هستند. فرض کنید انتظار دارید بسیاری از خدمات و حساب های مختلف AWS را به هم متصل کنید (یک حساب مرکزی pub-sub یا مرکزی API را در نظر بگیرید). در این صورت در آینده با این محدودیت ها مواجه خواهید شد. از آنجایی که تکرار موضوع SNS یا دروازه API برای ادغام با سرویس‌های جدید منطقی نیست، بهتر است مسیر «نقش فرضی» را انتخاب کنید. ارائه نقش‌های جدید آسان‌تر از کپی کردن یک موضوع SNS یا یک دروازه API است، که منطقی نیست.

عامل تعیین کننده دیگر این است که آیا سرویس ها در یک حساب هستند و چه کسی آنها را نگه می دارد – همان تیم یا نه. خط‌مشی مبتنی بر منبع برای سرویس‌های داخلی یا ارتباطات میکرو سرویس، زمانی که همان تیم آن‌ها را حفظ می‌کند، بسیار عالی است، زیرا درجاتی از اتصال را معرفی می‌کند. با این حال، از آنجایی که در خانواده “می ماند” قابل قبول است. با این حال، فرض کنید حساب ها و تیم های مختلفی درگیر هستند. در آن صورت، مسیر “نقش فرض” بهتر است زیرا منابع و تیم های مورد نظر را جدا می کند و از برنامه های افزودنی بی پایان آینده پشتیبانی می کند.

در نهایت، شما همیشه می توانید پیاده سازی را تغییر دهید، بنابراین از انتخاب نترسید. فقط مطمئن شوید که یکی از این دو گزینه را انتخاب کرده اید.

خلاصه

در این پست با احراز هویت و مجوز آشنا شدیم. ما همچنین با دو الگوی ارتباط سرویس به سرویس آشنا شده ایم: ناهمزمان و همزمان.

ما هم احراز هویت و هم مجوز را برای آن الگوها با استفاده از AWS IAM پیاده‌سازی کرده‌ایم. ما چهار پیاده‌سازی مختلف را دیدیم و در مورد جوانب مثبت و منفی آن‌ها، چه مسیر سیاست‌های مبتنی بر منابع یا «نقش به عهده گرفتن» بحث کردیم.

در پست‌های بعدی، چالش‌هایی را که این الگوها ایجاد می‌کنند، نحوه حل آن‌ها و نحوه برداشتن مجوز یک گام دیگر به جلو در حوزه‌ی دقیق بحث خواهیم کرد.

ضمیمه: درگاه های API خصوصی و عمومی

AWS ساخت دروازه‌های API خصوصی را برای ارتباط سرویس به سرویس برای بهبود عملکرد، کاهش هزینه‌های شبکه (شما از شبکه AWS خارج نمی‌کنید) و امنیت را توصیه می‌کند.

… ترافیک به API خصوصی شما از اتصالات امن استفاده می کند و از شبکه آمازون خارج نمی شود – از اینترنت عمومی جدا شده است – اسناد AWS

در واقع، ساختن APIها به عنوان دروازه های API عمومی ممکن و آسان تر است. در این صورت، احراز هویت و مجوز حیاتی تر می شود و باید دستورالعمل های این پست را دنبال کنید.

دروازه های API خصوصی به VPC نیاز دارند. آنها پیچیدگی بیشتری به ارمغان می آورند زیرا خدمات اتصال همچنین نیاز به استفاده از نقاط پایانی VPC و VPC دارند.

AWS اتصال شبکه‌های VPC سرویس‌ها را از طریق سیاست‌های منبع برای نقاط پایانی VPC یا همتاسازی VPC توصیه می‌کند. در اینجا شما میتوانید اطلاعات بیشتری راجع به آن بخوانید.

هنگامی که از توابع بدون سرور و Lambda استفاده می کنید و می خواهید با یک API Gateway خصوصی ارتباط برقرار کنید، باید توابع Lambda خود را در VPC ها قرار دهید. این ایده آل نیست، زیرا VPC ها اثرات ناخواسته ای بر عملکرد لامبدا دارند، مانند شروع طولانی تر سرد و افزایش هزینه ها.

VPC ها جایگزین احراز هویت و مجوز نمی شوند

من می‌خواهم این نکته را درست بیان کنم.

راه‌اندازی یک اتصال شبکه بین نقاط پایانی مختلف VPC به این معنی نیست که شما احراز هویت یا مجوز سرویس را پیاده‌سازی کرده‌اید یا اینکه شما 100٪ ایمن هستید.

بله، یک لایه امنیتی اضافی ایجاد می کند، اما جایگزین احراز هویت و مجوز مبتنی بر IAM نمی شود.

اولا، این کمترین امتیاز نیست. هر سرویسی در داخل آن شبکه های VPC می تواند به سرویس شما دسترسی داشته باشد. این یک لایه امنیتی اضافی است اما جایگزین مجوز نمی شود. علاوه بر این، مقیاس نمی شود. هرچه سرویس‌های بیشتری اضافه کنید، سرویس شما «نقض» بیشتری پیدا می‌کند و VPC‌ها و سرویس‌های بیشتری دسترسی پیدا می‌کنند.

علاوه بر این، اگر مهاجمان به یکی از VPC ها دسترسی پیدا کنند، می توانند آزادانه با سرویس شما ارتباط برقرار کنند زیرا سرویس شما هر تماس ورودی را می پذیرد.

با این حال، ترکیب احراز هویت و مجوز IAM با VPC بهترین و جامع ترین امنیت را برای دروازه API شما فراهم می کند.

در این ویدیو می توانید در مورد چنین الگوهایی با API Gateways و VPC بیشتر بیاموزید: https://www.youtube.com/watch?v=H4hCygngTrU