۳۰ شهریور ۱۴۰۳

Techboy

اخبار و اطلاعات روز تکنولوژی

۴ مدل برای افزایش مجوزهای دسترسی در مواقع اضطراری

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

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

هنگام ساخت برنامه‌های کاربردی مدرن، مدیریت مجوزهای دسترسی در طول رویدادهای عملیاتی مشکل است.

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

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

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

اما چگونه یک مهندس می تواند مجوزهای خود را افزایش دهد بدون اینکه توانایی افزایش مجوزهای خود را به یک آسیب پذیری امنیتی تبدیل کند؟

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

BTG یا شکستن شیشه

مدل BTG یا Break the Glass به مهندس در حال تماس اجازه می‌دهد تا از فرآیند سیستم درخواست افزایش مجوزها را بدهد تا فقط در شرایط اضطراری استفاده شود. هنگامی که مهندس این مجوزهای اضافی را درخواست می کند، یک سیستم خودکار مجوزهای لازم را به آنها می دهد، اما بلافاصله درخواست را ثبت می کند و یک اعلان به مدیریت مربوطه ارسال می کند تا آنها را از درخواست مطلع کند. از آنجایی که مهندس از این اعلان آگاه است، آنها می‌دانند که فقط در شرایط اضطراری واقعی می‌توانند «شیشه را بشکنند» و باید اقدامات خود را بعداً توضیح دهند، مثلاً در طول بررسی حادثه آتی. این امر بعید می‌سازد که کسی این مجوزهای اضافی را درخواست کند مگر در موارد ضروری.

JetBrains IDEs ترمینال جدید را پیش‌نمایش می‌کند

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

تشدید ثبت شده

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

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

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

تشدید دو نفره

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

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

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

ابزارهای محدوده محدود

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

به عنوان مثال، اگر یک مهندس در حال تماس باید سرور تولید را راه اندازی مجدد کند، معمولاً به عنوان “root” وارد سرور تولید می شود و سرور را راه اندازی مجدد می کند. این به سطحی از مجوزها نیاز دارد که در اکثر محیط های تولید غیرقابل قبول است. با این حال، یک کنسول وب را تصور کنید که به یک مهندس عملیات این امکان را می‌دهد که با فشار دادن دکمه، راه‌اندازی مجدد سرورهای تولید را آغاز کند. آن‌ها می‌توانند با استفاده از مجوزهای عادی خود، اقدام خاصی را انجام دهند که معمولاً به مجوزهای افزایش یافته نیاز دارد.

5 نکته برای ساخت اپلیکیشن های بومی ابری بسیار مقیاس پذیر

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

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

به این ترتیب، در حالی که ابزارهای محدوده محدود به طور کلی بهترین و ایمن‌ترین مدل هستند، اغلب به تنهایی استفاده نمی‌شود، بلکه همراه با یکی از مدل‌های دیگر برای مجوزهای پیش‌بینی نشده‌ای که ممکن است مورد نیاز باشد استفاده می‌شود. با این حال، این می تواند مزایای امنیتی ذاتی در این مدل را کاهش دهد.

کدام مدل بهترین است؟

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