الگوهای احراز هویت برای ایمن سازی حساب های فنی در فضای ابری | دانش مرکز داده

پیچ و خم ها یک چالش هستند – حداقل بدون دید پرنده. احراز هویت برای حساب های فنی چالش مشابهی را برای مهندسان ابری ایجاد می کند.

حساب‌های فنی ستون فقرات خطوط لوله CI/CD، زیرساخت به‌عنوان کد، و هر شکلی از اتوماسیون فرآیند برای فرآیندهای IT یا تجاری هستند. آنها مهندسان را قادر می سازند تا مستاجران یا برنامه های کاربردی ابری کامل را مستقر و پیکربندی کنند. این واقعیت حاکی از آن است که هکرها می توانند از آنها برای از بین بردن مستاجران کل ابر و مناظر برنامه های سازمانی سوء استفاده کنند. حساب‌های فنی برای پشتیبان‌گیری به همه داده‌های غیر حساس و حساس دسترسی دارند، معدن طلایی برای هکرها اگر بتوانند هر یک از آنها را تصاحب کنند. به طور خلاصه، حساب‌های فنی در صورت سوء استفاده، تأثیر بمب‌های هسته‌ای را بر جای می‌گذارند.

مربوط: حملات سایبری احراز هویت چند عاملی را دور می زند

در این مقاله، من مرتبط‌ترین الگوهای امنیتی و احراز هویت – و همچنین نمونه‌های مشخصی از ویژگی‌های کنترل دسترسی برای استفاده در Azure و AWS – را ارائه می‌دهم تا به مهندسان و معماران ابری کمک کنم تا در پیچ و خم حرکت کنند.

مربوط: AWS، آسیب‌پذیری‌های Azure اجازه دسترسی به حساب‌های دیگر مشتریان را می‌داد.

فایروال ها اولین فیلتر و لایه محافظ معمولی و بسیار خشن هستند (شکل 1). آنها ترافیک شبکه آشکارا نامشروع را مسدود می کنند، به عنوان مثال، ترافیک از قطب جنوب به یک سیستم ERP داخلی شرکت در ایتالیا. دومین فیلتر یا لایه ریزدانه تر، احراز هویت است. احراز هویت – با تأیید هویت کاربر – تضمین می‌کند که فقط افراد (یا سیستم‌ها) مناسب به آن دسترسی دارند. این موضوع اصلی است که در اینجا به آن خواهیم پرداخت.

احراز هویت با Cloud-Platform Identities

احراز هویت در ابر بسیار آسان است – اگر همه چیز در یک اکوسیستم ابری اجرا شود. اکثر شرکت ها این شرایط را ندارند. آنها دارای بار کاری ترکیبی هستند: یک ابر اصلی، خروجی های کوچکتر با سایر ارائه دهندگان ابر، سرورهای اولیه، به علاوه خدمات وب خارجی. بنابراین، مهندسان باید انواع الگوهای کنترل دسترسی را پیمایش کنند (شکل 2).

امن ترین روش برای احراز هویت در فضای ابری، بدون رمز عبور و مبتنی بر آن است هویت های مدیریت شده توسط ابر (شکل 1، شماره 1)، یا در اصطلاح Microsoft Azure، هویت های مدیریت شده. این الگو نیاز به احراز هویت و در نتیجه خطر اسرار نقض شده و دزدیده شده را از بین می برد. مهندسان فقط به بارهای کاری ابری حقوق دسترسی در IAM ابری اعطا می کنند. یک تابع Azure برای دسترسی به Cosmos DB یک سناریوی معمولی برای این الگو است.

این الگو همچنین برای برنامه هایی که روی یک ماشین مجازی ابری اجرا می شوند و برای دسترسی به منابع در همان ابر، اما فقط با یک انطباق جزئی کار می کند (شکل 1، #2). IAM ابری برنامه های موجود در VM را نمی شناسد، بنابراین نمی توان نقش هایی را به برنامه ها اختصاص داد. اما یک ترفند وجود دارد: پلتفرم ابری ماشین مجازی را می‌شناسد و ما می‌توانیم حق دسترسی به VM را اعطا کنیم. سپس، برنامه های در حال اجرا بر روی ماشین مجازی خاص می توانند یا ارث ببرند از دسترسی VM استفاده کنید حقوق (شکل 1، شماره 3).

در Azure، این کار به شرح زیر است: اول، VM به یک هویت نیاز دارد تا آن را به IAM ابری بشناسد (شکل 3، #1). سپس، نقش‌های لازم را به این ماشین مجازی اختصاص می‌دهیم، به عنوان مثال، نقش خواننده برای یک حساب ذخیره‌سازی خاص (شکل 3، شماره 2). اکنون، برنامه‌هایی که روی این ماشین مجازی اجرا می‌شوند، می‌توانند نقش‌هایی را که به VM اعطا شده است بدون احراز هویت خود درخواست کنند – یک راه‌حل ساده، حداقل برای نرم‌افزارهای خودساخته یا استاندارد که این رویکرد را پیاده‌سازی می‌کنند.

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

احراز هویت از طریق نمایندگان پلتفرم

هنگامی که یک برنامه کاربردی در یک ابر اجرا نمی شود، اما نیاز به دسترسی به منابع ابری خاص دارد، همه چیز را تغییر می دهد (شکل 1، #4). پیچیده ترین مدیریت دسترسی و الگوی احراز هویت برای این سناریو بر اساس آن است نمایندگان برنامه در ابر IAM. مایکروسافت با آنها تماس می گیرد مدیران خدمات. برنامه خارجی خود را با استفاده از یک گواهی مخفی احراز هویت می کند. پس از آن، می تواند به تمام منابعی که مدیر سرویس به آنها دسترسی دارد دسترسی داشته باشد (شکل 4).

مزیت قابل توجه نمایندگان برنامه شفافیت است: IAM ابری آنها را می شناسد و می تواند گزارشی با تمام حقوق دسترسی ابری آنها ارائه دهد. به علاوه، مدیریت دسترسی مبتنی بر نقش کار می کند.

شکل 5 یک ساختار AWS مشابه را نشان می دهد. در حالی که Azure به طور جدی بین مدیران خدمات به عنوان تمایز قائل می شود هویت های حجم کار و حساب‌های کاربر معمولی، AWS حساب‌های کاربر را می‌شناسد – و حساب‌های کاربری می‌توانند کلیدهای دسترسی اضافی برای دسترسی برنامه‌ای توسط برنامه‌ها داشته باشند.

پیوند ضعیف در این ساختار AWS احراز هویت از طریق یک API در معرض اینترنت تنها با یک عامل است: کلید دسترسی. Azure به طور مشابه کار می کند – اگر یک مهندس به اشتباه چنین کلیدی را در معرض دید قرار دهد (یا در صورت بیکاری آن را کپی کند)، دسترسی ناخواسته بازی کودکانه است. این همه بهترین شیوه‌های امنیتی و ریسک را نقض می‌کند تا حساب‌های فنی را تا این حد در معرض خطر قرار دهد. محدودیت های IP یک راه حل است، یعنی محدود کردن محدوده IP که از آن درخواست های احراز هویت قابل قبول است. محدوده IP داخلی یک نقطه شروع آشکار است. لاجوردی دسترسی مشروط ویژگی یکی از راه های اجرای چنین الزاماتی است.

یک نوع نهایی برای تنظیمات پیچیده تر IAM سازمانی مرتبط است. گزینه ای برای احراز هویت یک نماینده برنامه از طریق یک ارائه دهنده هویت خارجی وجود دارد که IAM ابری به آن اعتماد دارد (شکل 1، شماره 5). Azure AD Workload Identity Federation در این دسته قرار می گیرد.

تامین دسترسی محلی با مدیریت خدمات

رویکرد نهایی برای احراز هویت در ابر یک تغییر اساسی ایجاد می‌کند: دسترسی به منابع ابری با دور زدن کاربران و نقش‌ها در IAM ابری. شکل 6 دو نمونه از نحوه پیاده سازی Azure این الگو را نشان می دهد که هر دو مربوط به Storage Accounts هستند. اولین مورد یک کلید دسترسی است. هر برنامه‌ای که کلید را می‌داند (و حساب ذخیره‌سازی) می‌تواند به داده‌ها متصل شده و به آن دسترسی داشته باشد. این یک مدل دسترسی ساده و بدون نقش است (شکل 6، #1).

مثال دوم یک ویژگی پیچیده تر برای دسترسی به حساب ذخیره سازی است: امضاهای دسترسی مشترک. آنها نقش‌های «واقعی» را ارائه نمی‌کنند، بلکه مفاهیم حفاظتی را برای محدود کردن دسترسی ارائه می‌کنند، به عنوان مثال، دوره اعتبار برای امضا یا دامنه IP که ورود به سیستم مجاز است (شکل 6، شماره 2).

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

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

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