DevOps در مقابل DevSecOps: چگونه در یک بانک به نظر می رسید

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

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

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

افشای ساده این که پیمانکار به کد محصول دسترسی کامل دارد، دنیای آنها را وارونه کرده بود.

در این لحظه، داستان DevSecOps شروع شد که می خواهم در مورد آن برای شما بگویم.

بانک از این وضعیت چه نتایج عملی گرفت؟

در مورد اینکه همه چیز به روش اشتباه انجام می شود، بحث های زیادی وجود داشت. توسعه دهندگان گفتند که امنیت فقط مشغول تلاش برای مداخله در توسعه است و آنها نیز مانند دیده بانان، سعی می کنند بدون فکر کردن را ممنوع کنند. به نوبه خود، متخصصان امنیتی بین انتخاب بین این دیدگاه تردید داشتند: "توسعه دهندگان آسیب پذیری در مدار ما ایجاد می کنند" و "توسعه دهندگان آسیب پذیری ایجاد نمی کنند، بلکه خودشان هستند." اگر تقاضاهای جدید بازار و ظهور پارادایم DevSecOps نبود، این اختلاف برای مدت طولانی ادامه داشت. می توان توضیح داد که همین اتوماسیون فرآیندها با در نظر گرفتن الزامات امنیت اطلاعات "خارج از جعبه" به همه کمک می کند تا خوشحال بمانند. به این معنا که قوانین فوراً نوشته می شوند و در طول بازی تغییر نمی کنند (امنیت اطلاعات چیزی غیر منتظره را ممنوع نمی کند) و توسعه دهندگان امنیت اطلاعات را از هر اتفاقی که می افتد مطلع می کنند (امنیت اطلاعات به طور ناگهانی با چیزی مواجه نمی شود) . هر تیم همچنین مسئول ایمنی نهایی است و نه برخی از برادران بزرگتر انتزاعی.

1. از آنجایی که کارمندان خارجی قبلاً به کد و تعدادی از سیستم‌های داخلی دسترسی دارند، احتمالاً می‌توان شرط «توسعه باید به طور کامل در زیرساخت بانک انجام شود» را از اسناد حذف کرد.
2. از سوی دیگر، ما باید کنترل را بر آنچه در حال وقوع است تقویت کنیم.
3. سازش ایجاد تیم های متقابل کارکردی بود که در آن کارکنان از نزدیک با افراد خارجی کار می کنند. در این مورد، باید مطمئن شوید که تیم بر روی ابزارهای موجود در سرورهای بانک کار می کند. از ابتدا تا انتها.

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

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

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

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

چه چیزی تغییر کرده است

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

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

• مدار مجتمع: Git، Jenkins، Maven، Roslyn، Gradle، jUnit، Jira، MF Fortify، CA Harvest، GitlabCI.
• سی دی: Ansible، Puppet، TeamCity، Gitlab TFS، Liquidbase.
• تست: Sonarqube، SoapUI، jMeter، Selenium: MF Fortify، Performance Center، MF UFT، Ataccama.
• ارائه (گزارش، ارتباط): Grafana، Kibana، Jira، Confluence، RocketChat.
• عملیات (نگهداری، مدیریت): Ansible، Zabbix، Prometheus، Elastic + Logstash، MF Service Manager، Jira، Confluence، MS Project.

پشته انتخاب شده:

• پایگاه دانش - تلاقی اطلس;
• Task Tracker - Atlassian Jira;
• مخزن مصنوع - "Nexus"؛
• سیستم یکپارچه سازی مداوم - "Gitlab CI"؛
• سیستم تجزیه و تحلیل مداوم - "SonarQube"؛
• سیستم تجزیه و تحلیل امنیت برنامه - "Micro Focus Fortify"؛
• سیستم ارتباطی - "GitLab Mattermost"؛
• سیستم مدیریت پیکربندی - "Ansible"؛
• سیستم نظارت - "ELK"، "TICK Stack" ("InfluxData").

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

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

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

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

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

بقیه پشته برای همه کم و بیش آشناست. ابزارهای اتوماسیون در Ansible مورد استفاده قرار گرفت و متخصصان امنیتی از نزدیک با آنها کار کردند. پشته Atlassin قبل از پروژه توسط بانک استفاده می شد. ابزار امنیتی Fortinet - توسط خود افراد امنیتی پیشنهاد شده است. چارچوب تست توسط بانک ایجاد شده است، هیچ سوالی پرسیده نشده است. سیستم مخزن سوالاتی را مطرح کرد؛ من باید به آن عادت می کردم.

به پیمانکاران یک پشته جدید داده شد. آنها به ما زمان دادند تا آن را برای GitlabCI بازنویسی کنیم و جیرا را به بخش بانکی مهاجرت کنیم و غیره.

گام به گام

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

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

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

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

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

مرحله 3. مهاجرت تمامی زیرسیستم ها و تنظیمات آنها به PAC جدید. اسکریپت‌های اتوماسیون زیرساخت بازنویسی شدند و مهاجرت زیرسیستم‌های DSO در حالت کاملاً خودکار تکمیل شد. خطوط توسعه IP توسط خطوط لوله تیم های توسعه بازسازی شد.

مرحله 4. اتوماسیون نصب نرم افزارهای کاربردی این وظایف توسط رهبران تیم تیم های جدید تعیین شده است.

مرحله 5. بهره برداری.

دسترسی از راه دور

تیم های توسعه خواستار حداکثر انعطاف پذیری در کار با مدار بودند و الزام دسترسی از راه دور از لپ تاپ های شخصی در همان ابتدای پروژه مطرح شد. این بانک قبلاً دسترسی از راه دور داشت، اما برای توسعه دهندگان مناسب نبود. واقعیت این است که این طرح از اتصال کاربر به یک VDI محافظت شده استفاده می کند. این برای کسانی مناسب بود که فقط به پست و بسته اداری در محل کار خود نیاز داشتند. توسعه دهندگان به مشتریان سنگین، کارایی بالا، با منابع زیاد نیاز دارند. و البته، آنها باید ثابت باشند، زیرا از دست دادن جلسه کاربر برای کسانی که با VStudio (به عنوان مثال) یا سایر SDK کار می کنند غیرقابل قبول است. سازماندهی تعداد زیادی VDI استاتیک ضخیم برای همه تیم های توسعه، هزینه راه حل VDI موجود را به شدت افزایش داد.

ما تصمیم گرفتیم روی دسترسی از راه دور به طور مستقیم به منابع بخش توسعه کار کنیم. Jira، Wiki، Gitlab، Nexus، ساخت و تست نیمکت، زیرساخت مجازی. نگهبانان امنیتی خواستار ارائه دسترسی تنها با موارد زیر شده اند:

1. با استفاده از فناوری های موجود در بانک.
2. زیرساخت نباید از کنترلرهای دامنه موجود که سوابق اشیاء حساب تولیدی را ذخیره می کنند استفاده کند.
3. دسترسی باید فقط به منابع مورد نیاز یک تیم خاص محدود شود (به طوری که یک تیم محصول نتواند به منابع تیم دیگر دسترسی داشته باشد).
4. حداکثر کنترل روی RBAC در سیستم ها.

در نتیجه یک دامنه جداگانه برای این بخش ایجاد شد. این دامنه همه منابع بخش توسعه، هم اعتبار کاربر و هم زیرساخت را در خود جای داده است. چرخه عمر رکوردها در این دامنه با استفاده از IdM موجود در بانک مدیریت می شود.

دسترسی مستقیم از راه دور بر اساس تجهیزات موجود بانک سازماندهی شد. کنترل دسترسی به گروه‌های AD تقسیم شد که قوانین مربوط به زمینه‌ها با آنها مطابقت داشت (یک گروه محصول = یک گروه از قوانین).

مدیریت قالب VM

سرعت ایجاد یک حلقه مونتاژ و تست یکی از KPIهای اصلی تعیین شده توسط رئیس واحد توسعه است، زیرا سرعت آماده سازی محیط به طور مستقیم بر زمان اجرای کلی خط لوله تأثیر می گذارد. دو گزینه برای تهیه تصاویر پایه VM در نظر گرفته شد. اولین مورد حداقل اندازه های تصویر، پیش فرض برای همه محصولات سیستم، حداکثر انطباق با سیاست های بانک در مورد تنظیمات است. دومی تصویر پایه است که حاوی یک POPPO سنگین نصب شده است که زمان نصب آن می تواند تا حد زیادی بر سرعت اجرای خط لوله تأثیر بگذارد.

زیرساخت و الزامات امنیتی نیز در طول توسعه در نظر گرفته شد - به روز نگه داشتن تصاویر (وصله ها و غیره)، ادغام با SIEM، تنظیمات امنیتی مطابق با استانداردهای بانک.

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

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

دسترسی به اینترنت

یکی دیگر از موانع امنیت بانکی، دسترسی به منابع اینترنتی از محیط توسعه بود. علاوه بر این، این دسترسی را می توان به دو دسته تقسیم کرد:

1. دسترسی به زیرساخت
2. دسترسی برنامه نویس

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

توسعه دهندگان به دلایل واضح نیاز به دسترسی به اینترنت داشتند (stackoverflow). و اگرچه همه دستورات، همانطور که در بالا ذکر شد، دسترسی از راه دور به مدار داشتند، اما وقتی نمی‌توانید ctrl+v را از محل کار توسعه‌دهنده در بانک در IDE انجام دهید، همیشه راحت نیست.

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

یافته ها

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

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

منبع: www.habr.com