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

در عصری که توسعه چابک روشی برای انتشار سریع ویژگی‌ها و بازخورد است، نادیده گرفتن امنیت و انطباق آسان است. این ممکن است ایمن سازی خطوط لوله CI/CD، حفاظت از داده های کاربر، یا مدیریت دسترسی به علامت گذاری ویژگی در محیط های تولید باشد.

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

به همین دلیل، درک اهمیت امنیت و انطباق در DevOps بسیار مهم است. همچنین باید بیاموزید که چگونه تیم شما می تواند از مفاهیم امنیتی محبوبی مانند کنترل دسترسی مبتنی بر رول (RBAC) استفاده کند، که در اینجا بر روی آن تمرکز خواهیم کرد.

این نه تنها برای تیم‌های DevOps (به عنوان یک روش سازگار برای اختصاص دسترسی به تیم‌ها) مفید است، بلکه به عنوان یک ویژگی کامل که پلتفرم‌های SaaS مانند Flagsmith (یک پلتفرم پرچم‌گذاری ویژگی منبع باز) در اختیار مشتریان خود قرار می‌دهند نیز مفید است.

اما ممکن است بپرسید - چرا RBAC مهم است؟ خوب، ما در این آموزش به آن و موارد دیگر خواهیم پرداخت.

فهرست مطالب:

چرا RBAC مهم است؟

ویژگی پرچم گذاری و پرچمدار

درک کاربران، گروه ها، نقش ها و مجوزها
- ایجاد پروژه
- ایجاد گروه
- یک نقش ویرایشگر ایجاد کنید
- مجوزها را به نقش ویرایشگر اختصاص دهید
- نقش ویرایشگر را به یک گروه اختصاص دهید
– مجوزهای اختصاص داده شده را تست کنید

مورد استفاده: هرج و مرج در "NetGlobal Solutions"
- چگونه مشکل را کاهش دهیم

چگونه یک فرآیند DevOps استاندارد ایجاد کنیم

بسته بندی

چرا RBAC مهم است؟

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

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

این نه تنها به ایمن سازی چرخه عمر یک ویژگی منتشر شده در تولید کمک می کند، بلکه به نحوه مدیریت آن پس از انتشار نیز کمک می کند - آیا باید آن را فعال یا غیرفعال کرد؟ کدام کاربران باید بتوانند از آن استفاده کنند؟ و چه کسی مسئول انجام این عمل خواهد بود؟

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

به هر حال پرچم‌گذاری ویژگی چیست و چرا RBAC برای مدیریت آن مهم است؟

ویژگی پرچم گذاری و پرچمدار

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

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

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

اگرچه شرکت‌ها روش‌های انطباق برای رسیدگی به پرچم‌گذاری ویژگی‌ها دارند، همیشه این احتمال وجود دارد که شخصی کاری انجام دهد که به تولید آسیب برساند (عمدا یا ناخواسته).

پس ، برای اینکه شما و تیمتان دید بهتری داشته باشید و کنترل دقیقی بر تغییر ویژگی داشته باشید، ابزارهای پرچم‌گذاری ویژگی‌ها مانند Flagsmith به شما کمک می‌کنند تا به چنین مشکلات امنیتی و مجوز رسیدگی کنید.

اما ممکن است تعجب کنید - Flagsmith چگونه مجوزها و کاربران را مدیریت می کند؟ RBAC را وارد کنید که در مجموعه ابزار Flagsmith تعبیه شده است. این کار تیم های بزرگتر را برای همکاری در پروژه ها و محیط ها و مدیریت دسترسی برای شرکت ها آسان تر می کند. بیایید عمیق تر غواصی کنیم تا بفهمیم چگونه کار می کند.

درک کاربران، گروه ها، نقش ها و مجوزها

Flagsmith دو نقش اصلی در سیستم RBAC دارد: مدیر سازمان و کاربران ساده.

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

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

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

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

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

قبل از اینکه به مطالعه موردی بپردازیم، بیایید یک پروژه دلخواه در Flagsmith ایجاد کنیم و به کاربر اجازه دهیم تا بتواند شروع به ایجاد پرچم های ویژگی برای پروژه کند. ما اقدامات زیر را انجام خواهیم داد:

ایجاد یک پروژه در داخل یک سازمان

یک گروه "front_end_devs" ایجاد کنید و کاربران را به این گروه اضافه کنید

یک نقش ویرایشگر ایجاد کنید

مجوزهای سطح سازمان، پروژه و محیط را اختصاص دهید

نقش را به گروه تازه ایجاد شده اختصاص دهید

برای آزمایش مجوزهای اختصاص داده شده با حساب کاربری وارد شوید

پروژه را ایجاد کنید

پس از ورود با حساب مالک بر روی دکمه ایجاد پروژه کلیک کنید. نام این پروژه را Dev Test می گذاریم.

گروه را ایجاد کنید

به تب اعضا بروید، روی ایجاد گروه کلیک کنید، سپس جزئیات مورد نیاز را پر کنید.

ما یک گروه " front_end_devs " ایجاد کردیم و جان اسمیت را مدیر گروه قرار دادیم. هنگام ایجاد یک گروه، این را به عنوان یک مجوز درون خطی در نظر بگیرید. جان اکنون می تواند کاربران داخل این گروه را مدیریت کند.

یک نقش ویرایشگر ایجاد کنید

روی Roles در کنار Groups کلیک کنید و یک نقش به نام " Editor " ایجاد کنید.

ما نقشی به نام Editor ایجاد کردیم، پس اجازه دهید مجوزهای مناسب را به این نقش اختصاص دهیم. به ویرایشگر در هر سه سطح - سازمان، پروژه و محیط، مجوز داده می شود.

مجوزها را به نقش ویرایشگر اختصاص دهید

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

این نقش ویرایشگر اکنون می تواند پروژه هایی را در این سازمان ایجاد کند و گروه ها و اعضای آنها را در این سازمان مدیریت کند.

در مرحله بعد، مجوزهای سطح پروژه را به آن می دهیم. روی نام پروژه در زیر تب Project کلیک کنید و مانند تصویر زیر عمل کنید:

همانطور که می بینید، ما به این نقش دو مجوز در سطح پروژه اختصاص دادیم: View Project و Create Feature . پس هر کاربر یا مجموعه ای از کاربران با این نقش تنها قادر به مشاهده یک پروژه و ایجاد یک ویژگی خواهند بود.

اکنون برای گرانول ترین مجوزها، که در سطح محیطی هستند. روی تب Environment کلیک کنید، پروژه Dev Test را از منوی بازشو انتخاب کنید و روی Development Environment کلیک کنید.

همانطور که می بینید، ما به این نقش دو مجوز در سطح محیطی اختصاص دادیم: View Environment و Update Feature State. هر کاربر یا مجموعه ای از کاربران با این نقش فقط می توانند یک محیط را مشاهده کنند و مقدار وضعیت ویژگی آن را در پروژه به روز کنند.

نقش ویرایشگر را به یک گروه اختصاص دهید

اکنون این نقش را به گروه " front_end_devs" اختصاص می دهیم. برای انجام این کار، نقش ویرایشگر را انتخاب کنید، به تب اعضا بروید، سپس روی متن " گروه های اختصاص داده شده " کلیک کنید. نام گروه خود را در نوار جستجو وارد کرده و آن را انتخاب کنید.

مجوزهای اختصاص داده شده را آزمایش کنید

پس از گذراندن مراحل فوق، کاربران گروه “ front_end_devs” فقط باید بتوانند عملیات زیر را انجام دهند.

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

ایجاد و حذف ویژگی ها در Dev Test Project

مقادیر حالت ویژگی را در پروژه تست برنامه نویس به روز کنید

اکنون ما از حساب جان اسمیت، یک کاربر آزمایش کننده از گروه " front_end_devs" وارد می شویم تا تحلیل کنیم که مجوزهای اختصاص داده شده به درستی کار می کنند.

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

می بینید که کاربر با موفقیت توانسته یک پروژه جدید ایجاد کند. و از آنجایی که او خالق این پروژه است، جان ادمین است و اختیار کامل برای مدیریت آن را دارد.

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

برای ایجاد این ویژگی کافی است بر روی دکمه ایجاد ویژگی کلیک کنید، نامی را به ویژگی بدهید و مقدار دلخواه خود را وارد کنید.

پس از ایجاد ویژگی چیزی شبیه به این را خواهید دید:

اکنون باید درک اولیه ای از این که Flagsmith's RBAC چگونه تکالیف مجوز را انجام می دهد و کاربران، گروه ها و نقش ها را مدیریت می کند، داشته باشید.

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

مورد استفاده: آشوب در «راه‌حل‌های NetGlobal»

بیایید فرض کنیم که شرکتی به نام NetGlobal Solutions وجود دارد که یک غول جهانی در صنعت شبکه است. آنها راه حل های شبکه ای مختلفی مانند CDN، مدیریت DNS، موقعیت جغرافیایی، امنیت سایبری ابری و کاهش DDoS را برای مشتریان خود ارائه می دهند.

آنها تصمیم گرفتند یک سرویس جدید، NetGlobal load balancing (راه حلی برای مدیریت حجم عظیمی از ترافیک وب) برای مشتریان خود معرفی کنند.

خط مشی NetGlobal حکم می کند که یک ویژگی باید حداقل به مدت 3 ماه با تنها 10٪ از مشتریان آن قبل از اینکه به طور کامل در معرض بقیه کاربران قرار گیرد، آزمایش شود. پس آنها تصمیم گرفتند از علامت گذاری ویژگی برای آزمایش آن در تولید با 10٪ از مشتریان خود استفاده کنند - فرض کنید 10000 با توجه به اندازه بزرگ مشتریان آنها.

مقادیر پرچم ویژگی از یک جدول پایگاه داده مرکزی جدا شده از هر گونه رابطه با جداول دیگر به پایگاه کد خود منتقل می شوند. جدول دارای یک مقدار بولی است که نمایان بودن ویژگی جدید را مدیریت می کند و Devin، سرپرست تیم توسعه این ویژگی، مسئول مدیریت و پایداری آن است.

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

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

سیستم مانیتورینگ یک زنگ هشدار ایجاد می کند و تیم های توسعه دهنده و DevOps وارد عمل می شوند. در حدود 10-15 دقیقه مشکل را پیدا می کنند و مشکل را حل می کنند. اما از آنجایی که پایگاه کاربر بسیار زیاد است و استفاده از این ویژگی در انتهای کاربر کاملاً فنی بود، یک ضرر تأثیرگذار قبلاً رخ داده است.

چگونه مشکل را کاهش دهیم

حال، بیایید در نظر بگیریم که اگر تیم Devin از Flagsmith برای ایجاد پرچم‌گذاری ویژگی استفاده می‌کرد، چگونه می‌توانست این حادثه را کاهش دهد. ما همچنین نگاه خواهیم کرد که چگونه RBAC آن به امنیت دسترسی ارزش پرچم کمک کرده است.

مدیریت ارزش پرچم: با استفاده از SDK Flagsmith در کد برنامه، مقادیر پرچم را می‌توان مدیریت کرد و با دید واضح به برنامه منتقل کرد.

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

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

این مورد استفاده فرضی به ما کمک می‌کند تا درکی اساسی از اهمیت ابزار پرچم‌گذاری ویژگی برای انتشار تولید داشته باشیم. همچنین به ما نشان می دهد که چرا RBAC نقش مهمی در مدیریت مجوزها و سلسله مراتب در یک اکوسیستم ایفا می کند تا به تیم شما کمک کند تا از حوادث خرابی جلوگیری کند.

نکته کلیدی در اینجا این است که ایجاد یک فرآیند DevOps استاندارد و انتخاب ابزارهای DevOps که به بخشی سازگار از انتشار و مدیریت ویژگی تبدیل می شوند، مهم است.

نحوه ایجاد یک فرآیند DevOps استاندارد

یک فرآیند DevOps استاندارد باید برای چرخه عمر یک ویژگی تنظیم شود. باید تمام مراحل از مرحله ساخت تا انتشار تولید را تحلیل کند.

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

یک مثال اساسی از یک فرآیند DevOps استاندارد با ایجاد یک گردش کار یکپارچه سازی مداوم با مراحل زیر شروع می شود:

ساخت و اسکن: ساخت مصنوعات و اسکن آسیب پذیری قبل از فشار دادن به هاب مصنوعات.

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

سپس، می‌خواهید یک گردش کار مستمر مستمر با مراحل زیر ایجاد کنید:

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

انتخاب روش عرضه: بسته به نیاز خود استراتژی‌های عرضه را انتخاب کنید، مانند Rolling Updates، A/B Testing، Canary Deployments و Feature Flagging.

در مرحله بعد، باید با استفاده از سیستم‌های نظارتی مانند Prometheus برای نظارت، Grafana برای تجسم، و Grafana On Call برای ابزار مدیریت حادثه/در تماس، یک مکانیسم نظارت قوی برای برنامه‌ها اجرا کنید.

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

بسته شدن

در این مقاله، اهمیت RBAC در دنیای DevOps و اینکه چگونه تیم ها می توانند از آن در صنعت برای ایمن سازی محیط های تولید استفاده کنند، بحث کردیم.

همچنین در مورد اینکه پرچم‌گذاری ویژگی چیست، اهمیت آن برای انتشار ویژگی‌ها و اینکه چگونه از RBAC برای مدیریت مجوزهای کاربر استفاده می‌کند، بحث کردیم.

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

خبرکاو