DevOps বনাম DevSecOps: এক ব্যাঙ্কে কেমন লাগছিল

ব্যাংক তার প্রকল্পগুলি অনেক ঠিকাদারকে আউটসোর্স করে। "বাহ্যিক" কোড লিখুন, তারপর ফলাফলগুলি খুব সুবিধাজনক নয় এমন আকারে প্রেরণ করুন। বিশেষত, প্রক্রিয়াটি এইরকম দেখায়: তারা একটি প্রকল্প হস্তান্তর করেছিল যা তাদের সাথে কার্যকরী পরীক্ষায় উত্তীর্ণ হয়েছিল, এবং তারপরে একীকরণ, লোড ইত্যাদির জন্য ব্যাঙ্কিং পরিধির ভিতরে পরীক্ষা করা হয়েছিল। এটা প্রায়ই আবিষ্কৃত হয়েছে যে পরীক্ষা ব্যর্থ হয়েছে. তারপর সবকিছু বাহ্যিক বিকাশকারীর কাছে ফিরে গেল। আপনি অনুমান করতে পারেন, এটি বাগ ফিক্সের জন্য দীর্ঘ লিড টাইম বোঝায়।

ব্যাঙ্ক সিদ্ধান্ত নিয়েছে যে কমিট থেকে রিলিজ পর্যন্ত পুরো পাইপলাইনটিকে তার ডানার নীচে টেনে আনা সম্ভব এবং প্রয়োজনীয়। যাতে সবকিছু অভিন্ন এবং ব্যাঙ্কে পণ্যের জন্য দায়ী দলগুলির নিয়ন্ত্রণে থাকে। অর্থাৎ, যেন বহিরাগত ঠিকাদার অফিসের পাশের ঘরে কোথাও কাজ করছে। কর্পোরেট স্ট্যাকের উপর. এটি একটি সাধারণ devops.

সেক কোথা থেকে এসেছে? একটি বহিরাগত ঠিকাদার কীভাবে নেটওয়ার্ক বিভাগে কাজ করতে পারে, কারও কাছে কী অ্যাক্সেস রয়েছে, কীভাবে এবং কে কোডের সাথে কাজ করে তার উপর ব্যাঙ্কের নিরাপত্তা উচ্চ চাহিদা রেখেছে। এটা ঠিক যে আইবি এখনও জানত না যে ঠিকাদাররা যখন বাইরে কাজ করে, তখন কয়েকটি ব্যাঙ্কিং মান অনুসরণ করা হয়। এবং তারপর কয়েক দিনের মধ্যে প্রত্যেককে সেগুলি পর্যবেক্ষণ করা শুরু করতে হবে।

ঠিকাদার পণ্য কোড সম্পূর্ণ অ্যাক্সেস ছিল যে সহজ উদ্ঘাটন ইতিমধ্যে তাদের বিশ্বের উল্টাপাল্টা হয়েছে.

এই মুহুর্তে, DevSecOps এর গল্প শুরু হয়েছিল, যা আমি আপনাকে বলতে চাই।

এই পরিস্থিতি থেকে ব্যাংক কোন বাস্তবিক সিদ্ধান্তে এসেছে?

সব কিছু ভুল পদ্ধতিতে করা হচ্ছে তা নিয়ে অনেক বিতর্ক ছিল। ডেভেলপাররা বলেছেন যে নিরাপত্তা শুধুমাত্র উন্নয়নে হস্তক্ষেপ করার চেষ্টা করছে, এবং তারা, প্রহরীর মতো, চিন্তা না করে নিষেধ করার চেষ্টা করে। পরিবর্তে, নিরাপত্তা বিশেষজ্ঞরা দৃষ্টিভঙ্গিগুলির মধ্যে নির্বাচন করতে দ্বিধা বোধ করেন: "বিকাশকারীরা আমাদের সার্কিটে দুর্বলতা তৈরি করে" এবং "বিকাশকারীরা দুর্বলতা তৈরি করে না, তবে তারা নিজেরাই।" নতুন বাজারের চাহিদা এবং DevSecOps দৃষ্টান্তের উত্থান না হলে বিরোধ দীর্ঘ সময়ের জন্য অব্যাহত থাকত। এটি ব্যাখ্যা করা সম্ভব ছিল যে তথ্য সুরক্ষা প্রয়োজনীয়তাগুলিকে বিবেচনায় নিয়ে প্রক্রিয়াগুলির এই স্বয়ংক্রিয়তা "বাক্সের বাইরে" সবাইকে খুশি থাকতে সহায়তা করবে। এই অর্থে যে নিয়মগুলি অবিলম্বে লিখে রাখা হয় এবং গেমের সময় পরিবর্তন হয় না (তথ্য সুরক্ষা অপ্রত্যাশিতভাবে কিছু নিষিদ্ধ করবে না), এবং বিকাশকারীরা যা ঘটে তা সম্পর্কে তথ্য সুরক্ষাকে অবহিত রাখে (তথ্য সুরক্ষা হঠাৎ করে কিছুর মুখোমুখি হয় না) . প্রতিটি দল চূড়ান্ত নিরাপত্তার জন্যও দায়ী, এবং কিছু বিমূর্ত বড় ভাই নয়।

1. যেহেতু বহিরাগত কর্মচারীদের ইতিমধ্যেই কোড এবং বেশ কয়েকটি অভ্যন্তরীণ সিস্টেমে অ্যাক্সেস রয়েছে, তাই সম্ভবত নথিগুলি থেকে "বিকাশ সম্পূর্ণভাবে ব্যাঙ্কের অবকাঠামোর উপর করা উচিত" প্রয়োজনটি সরিয়ে ফেলা সম্ভব।
2. অন্যদিকে, যা ঘটছে তার উপর আমাদের নিয়ন্ত্রণ জোরদার করতে হবে।
3. সমঝোতা ছিল ক্রস-ফাংশনাল টিম তৈরি করা, যেখানে কর্মীরা বাইরের লোকদের সাথে ঘনিষ্ঠভাবে কাজ করে। এই ক্ষেত্রে, আপনাকে নিশ্চিত করতে হবে যে দলটি ব্যাঙ্কের সার্ভারের সরঞ্জামগুলিতে কাজ করে। শুরু থেকে শেষ পর্যন্ত।

অর্থাৎ, ঠিকাদারদের অনুমতি দেওয়া যেতে পারে, তবে তাদের আলাদা সেগমেন্ট দিতে হবে। যাতে তারা বাইরে থেকে ব্যাঙ্কের পরিকাঠামোতে কোনও ধরণের সংক্রমণ না আনে এবং যাতে তারা প্রয়োজনের চেয়ে বেশি দেখতে না পায়। ওয়েল, যাতে তাদের কর্ম লগ করা হয়. ফাঁসের বিরুদ্ধে সুরক্ষার জন্য ডিএলপি, এই সমস্ত অন্তর্ভুক্ত ছিল।

নীতিগতভাবে, সমস্ত ব্যাংক শীঘ্রই বা পরে এটি আসে। এখানে আমরা মারধরের পথে নেমেছি এবং "বাহ্যিক" কাজ করে এমন পরিবেশের প্রয়োজনীয়তার বিষয়ে একমত হয়েছি। অ্যাক্সেস কন্ট্রোল টুলস, দুর্বলতা চেকিং টুলস, সার্কিট, অ্যাসেম্বলি এবং পরীক্ষায় অ্যান্টি-ভাইরাস বিশ্লেষণের সর্বাধিক পরিসর উপস্থিত হয়েছিল। একে বলা হয় DevSecOps।

হঠাৎ করেই এটা স্পষ্ট হয়ে গেল যে যদি DevSecOps এর আগে ব্যাঙ্কিং নিরাপত্তার বিকাশকারীর পক্ষে যা ঘটবে তার উপর কোনও নিয়ন্ত্রণ না থাকে, তাহলে নতুন দৃষ্টান্তে নিরাপত্তা অবকাঠামোতে সাধারণ ঘটনাগুলির মতোই নিয়ন্ত্রিত হয়। শুধুমাত্র এখন সমাবেশ, লাইব্রেরি নিয়ন্ত্রণ, এবং তাই সতর্কতা আছে.

যা অবশিষ্ট থাকে তা হল দলগুলিকে নতুন মডেলে স্থানান্তর করা। ঠিক আছে, পরিকাঠামো তৈরি করুন। তবে এগুলি তুচ্ছ জিনিস, এটি একটি পেঁচা আঁকার মতো। প্রকৃতপক্ষে, আমরা অবকাঠামোতে সাহায্য করেছি, এবং সেই সময়ে উন্নয়ন প্রক্রিয়াগুলি পরিবর্তন হচ্ছিল।

কি বদলে গেছে

আমরা ছোট পদক্ষেপে এটি বাস্তবায়ন করার সিদ্ধান্ত নিয়েছি, কারণ আমরা বুঝতে পেরেছিলাম যে অনেকগুলি প্রক্রিয়া বিচ্ছিন্ন হয়ে পড়বে এবং অনেক "বহিরাগত" সকলের তত্ত্বাবধানে নতুন কাজের পরিস্থিতি সহ্য করতে সক্ষম হবে না।

প্রথমত, আমরা ক্রস-ফাংশনাল টিম তৈরি করেছি এবং নতুন প্রয়োজনীয়তা বিবেচনায় নিয়ে প্রকল্পগুলি সংগঠিত করতে শিখেছি। সাংগঠনিক অর্থে আমরা কী প্রক্রিয়াগুলি নিয়ে আলোচনা করেছি। ফলাফলটি সমস্ত দায়ীদের সাথে সমাবেশ পাইপলাইনের একটি চিত্র ছিল।

• সি আই: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• সিডি: উত্তরযোগ্য, পুতুল, টিমসিটি, গিটল্যাব টিএফএস, লিকুইডবেস।
• পরীক্ষা: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Atacama.
• উপহার (প্রতিবেদন, যোগাযোগ): গ্রাফানা, কিবানা, জিরা, সঙ্গম, রকেটচ্যাট।
• অপারেশনস (রক্ষণাবেক্ষণ, ব্যবস্থাপনা): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF সার্ভিস ম্যানেজার, Jira, Confluence, MS Project.

নির্বাচিত স্ট্যাক:

• জ্ঞানের ভিত্তি - আটলাসিয়ান সঙ্গম;
• টাস্ক ট্র্যাকার - আটলাসিয়ান জিরা;
• আর্টিফ্যাক্ট ভান্ডার - "নেক্সাস";
• ক্রমাগত ইন্টিগ্রেশন সিস্টেম - "Gitlab CI";
• ক্রমাগত বিশ্লেষণ সিস্টেম - "সোনারকিউব";
• অ্যাপ্লিকেশন নিরাপত্তা বিশ্লেষণ সিস্টেম - "মাইক্রো ফোকাস ফরটিফাই";
• যোগাযোগ ব্যবস্থা - "গিটল্যাব ম্যাটারমোস্ট";
• কনফিগারেশন ম্যানেজমেন্ট সিস্টেম - "Ansible";
• মনিটরিং সিস্টেম - "ELK", "TICK Stack" ("InfluxData")।

তারা একটি দল তৈরি করতে শুরু করে যা ঠিকাদারদের ভিতরে টেনে আনতে প্রস্তুত হবে। একটি উপলব্ধি আছে যে বেশ কয়েকটি গুরুত্বপূর্ণ জিনিস রয়েছে:

• অন্তত কোড প্রেরণ করার সময় সবকিছু একত্রিত হওয়া উচিত। কারণ সেখানে অনেক ঠিকাদার ছিল, তাদের নিজস্ব বৈশিষ্ট্য সহ অনেকগুলি বিভিন্ন উন্নয়ন প্রক্রিয়া ছিল। প্রত্যেককে আনুমানিক একের মধ্যে মাপসই করা প্রয়োজন ছিল, কিন্তু বিকল্পগুলির সাথে।
• অনেক ঠিকাদার আছে, এবং পরিকাঠামো ম্যানুয়াল তৈরি করা উপযুক্ত নয়। যে কোনো নতুন কাজ খুব দ্রুত শুরু হওয়া উচিত - অর্থাৎ, দৃষ্টান্তটি প্রায় তাত্ক্ষণিকভাবে স্থাপন করা উচিত যাতে বিকাশকারীদের তাদের পাইপলাইন পরিচালনা করার জন্য সমাধানের একটি সেট থাকে।

প্রথম পদক্ষেপ নেওয়ার জন্য, কী করা হচ্ছে তা বোঝা দরকার ছিল। এবং সেখানে কিভাবে যেতে হবে তা আমাদের নির্ধারণ করতে হয়েছিল। আমরা পরিকাঠামো এবং সিআই/সিডি অটোমেশন উভয় ক্ষেত্রে লক্ষ্য সমাধানের আর্কিটেকচার আঁকতে সাহায্য করে শুরু করেছি। তারপর আমরা এই পরিবাহক একত্রিত করা শুরু. আমাদের একটি পরিকাঠামো দরকার, সবার জন্য একই, যেখানে একই কনভেয়র চলবে। আমরা গণনার সাথে বিকল্পগুলি অফার করেছি, ব্যাঙ্ক ভেবেছিল, তারপর সিদ্ধান্ত নিয়েছে কী তৈরি করা হবে এবং কী তহবিল দিয়ে।

পরবর্তী সার্কিট তৈরি - সফ্টওয়্যার ইনস্টলেশন, কনফিগারেশন। অবকাঠামো স্থাপন ও ব্যবস্থাপনার জন্য স্ক্রিপ্টের উন্নয়ন। পরবর্তী পরিবাহক সমর্থন পরিবর্তন আসে.

আমরা পাইলট সবকিছু পরীক্ষা করার সিদ্ধান্ত নিয়েছে. মজার বিষয় হল, পাইলটিং চলাকালীন, প্রথমবারের মতো ব্যাঙ্কে একটি নির্দিষ্ট স্ট্যাক উপস্থিত হয়েছিল। অন্যান্য জিনিসগুলির মধ্যে, একটি দ্রুত লঞ্চের জন্য পাইলটের সুযোগের জন্য সমাধানগুলির একটির একটি গার্হস্থ্য বিক্রেতাকে প্রস্তাব করা হয়েছিল। তিনি পাইলট করার সময় নিরাপত্তা তাকে চিনতে পেরেছিল এবং এটি একটি অবিস্মরণীয় ছাপ ফেলেছিল। যখন আমরা স্যুইচ করার সিদ্ধান্ত নিয়েছিলাম, সৌভাগ্যবশত, অবকাঠামো স্তরটি একটি Nutanix সমাধান দিয়ে প্রতিস্থাপিত হয়েছিল, যা আগে থেকেই ব্যাঙ্কে ছিল। তদুপরি, এর আগে এটি ভিডিআইয়ের জন্য ছিল, তবে আমরা এটি অবকাঠামো পরিষেবার জন্য পুনরায় ব্যবহার করেছি। ছোট ভলিউমে এটি অর্থনীতিতে মাপসই করা হয়নি, কিন্তু বড় পরিমাণে এটি উন্নয়ন এবং পরীক্ষার জন্য একটি চমৎকার পরিবেশ হয়ে উঠেছে।

স্ট্যাকের বাকিটা কমবেশি সবারই পরিচিত। Ansible-এ অটোমেশন টুল ব্যবহার করা হয়েছিল, এবং নিরাপত্তা বিশেষজ্ঞরা তাদের সাথে ঘনিষ্ঠভাবে কাজ করেছিলেন। অ্যাটলাসিন স্ট্যাকটি প্রকল্পের আগে ব্যাঙ্ক ব্যবহার করেছিল। Fortinet নিরাপত্তা সরঞ্জাম - এটি নিরাপত্তা মানুষ নিজেদের দ্বারা প্রস্তাবিত ছিল. পরীক্ষার ফ্রেমটি ব্যাংক দ্বারা তৈরি করা হয়েছিল, কোন প্রশ্ন জিজ্ঞাসা করা হয়নি। রিপোজিটরি সিস্টেম প্রশ্ন উত্থাপন করেছে; আমাকে এটিতে অভ্যস্ত হতে হয়েছিল।

ঠিকাদারদের নতুন স্ট্যাক দেওয়া হয়েছিল। তারা আমাদের GitlabCI এর জন্য এটি পুনরায় লেখার জন্য এবং জিরাকে ব্যাঙ্কিং বিভাগে স্থানান্তরিত করার জন্য সময় দিয়েছে, ইত্যাদি।

ধাপে ধাপে

স্টেজ 1। প্রথমত, আমরা একটি গার্হস্থ্য বিক্রেতার কাছ থেকে একটি সমাধান ব্যবহার করেছি, পণ্যটি একটি নতুন তৈরি ডিএসও নেটওয়ার্ক সেগমেন্টের সাথে সংযুক্ত ছিল। প্ল্যাটফর্মটি তার বিতরণের সময়, স্কেলিং নমনীয়তা এবং সম্পূর্ণ অটোমেশনের সম্ভাবনার জন্য বেছে নেওয়া হয়েছিল। পরিচালিত পরীক্ষা:

• ভার্চুয়ালাইজেশন প্ল্যাটফর্ম অবকাঠামোর নমনীয় এবং সম্পূর্ণ স্বয়ংক্রিয় ব্যবস্থাপনার সম্ভাবনা (নেটওয়ার্ক, ডিস্ক সাবসিস্টেম, কম্পিউটিং রিসোর্স সাবসিস্টেম)।
• ভার্চুয়াল মেশিন লাইফসাইকেল ম্যানেজমেন্টের অটোমেশন (টেমপ্লেটিং, স্ন্যাপশট, ব্যাকআপ)।

প্ল্যাটফর্মের ইনস্টলেশন এবং মৌলিক কনফিগারেশনের পরে, এটি দ্বিতীয় পর্যায়ের সাবসিস্টেম (ডিএসও সরঞ্জাম, খুচরা সিস্টেম বিকাশের রূপরেখা) স্থাপনের পয়েন্ট হিসাবে ব্যবহৃত হয়েছিল। পাইপলাইনগুলির প্রয়োজনীয় সেটগুলি তৈরি করা হয়েছিল - ভার্চুয়াল মেশিনগুলির তৈরি, মুছে ফেলা, পরিবর্তন, ব্যাকআপ। এই পাইপলাইনগুলি স্থাপনা প্রক্রিয়ার প্রথম পর্যায় হিসাবে ব্যবহৃত হয়েছিল।

ফলাফল হল যে প্রদত্ত সরঞ্জামগুলি কর্মক্ষমতা এবং ত্রুটি সহনশীলতার জন্য ব্যাঙ্কের প্রয়োজনীয়তা পূরণ করে না। ব্যাঙ্কের ডিআইটি নুটানিক্স সফ্টওয়্যার প্যাকেজের উপর ভিত্তি করে একটি কমপ্লেক্স তৈরি করার সিদ্ধান্ত নিয়েছে।

পর্যায় 2. আমরা সংজ্ঞায়িত স্ট্যাকটি নিয়েছি এবং সমস্ত সাবসিস্টেমের জন্য স্বয়ংক্রিয় ইনস্টলেশন এবং পোস্ট-কনফিগারেশন স্ক্রিপ্ট লিখেছি যাতে যত তাড়াতাড়ি সম্ভব পাইলট থেকে লক্ষ্য সার্কিটে সবকিছু স্থানান্তর করা হয়। সমস্ত সিস্টেম একটি ত্রুটি-সহনশীল কনফিগারেশনে স্থাপন করা হয়েছিল (যেখানে এই ক্ষমতা বিক্রেতার লাইসেন্সিং নীতি দ্বারা সীমাবদ্ধ নয়) এবং মেট্রিক্স এবং ইভেন্ট সংগ্রহের সাবসিস্টেমের সাথে সংযুক্ত ছিল। আইবি তার প্রয়োজনীয়তার সাথে সম্মতি বিশ্লেষণ করেছে এবং সবুজ আলো দিয়েছে।

পর্যায় 3. নতুন PAC-তে সমস্ত সাবসিস্টেম এবং তাদের সেটিংসের স্থানান্তর। অবকাঠামো স্বয়ংক্রিয়করণ স্ক্রিপ্টগুলি পুনরায় লেখা হয়েছিল, এবং ডিএসও সাবসিস্টেমগুলির স্থানান্তর সম্পূর্ণ স্বয়ংক্রিয় মোডে সম্পন্ন হয়েছিল। আইপি ডেভেলপমেন্টের কনট্যুরগুলি ডেভেলপমেন্ট টিমের পাইপলাইন দ্বারা পুনরায় তৈরি করা হয়েছিল।

স্টেজ 4। অ্যাপ্লিকেশন সফ্টওয়্যার ইনস্টলেশনের অটোমেশন। এই কাজগুলি নতুন দলের দলের নেতৃত্ব দ্বারা সেট করা হয়েছিল।

স্টেজ 5। শোষণ.

দূরবর্তী প্রবেশাধিকার

উন্নয়ন দলগুলি সার্কিটের সাথে কাজ করার ক্ষেত্রে সর্বাধিক নমনীয়তার জন্য বলেছিল এবং প্রকল্পের একেবারে শুরুতে ব্যক্তিগত ল্যাপটপ থেকে দূরবর্তী অ্যাক্সেসের প্রয়োজনীয়তা উত্থাপিত হয়েছিল। ব্যাঙ্কের ইতিমধ্যেই দূরবর্তী অ্যাক্সেস ছিল, কিন্তু এটি ডেভেলপারদের জন্য উপযুক্ত ছিল না। আসল বিষয়টি হ'ল স্কিমটি একটি সুরক্ষিত ভিডিআই-তে ব্যবহারকারীর সংযোগ ব্যবহার করেছিল। এটি তাদের জন্য উপযুক্ত ছিল যাদের শুধুমাত্র তাদের কর্মক্ষেত্রে মেল এবং একটি অফিস প্যাকেজ প্রয়োজন। বিকাশকারীদের প্রচুর সংস্থান সহ ভারী ক্লায়েন্ট, উচ্চ কার্যক্ষমতার প্রয়োজন হবে। এবং অবশ্যই, তাদের স্থির থাকতে হবে, যেহেতু VStudio (উদাহরণস্বরূপ) বা অন্যান্য SDK এর সাথে কাজ করে তাদের জন্য ব্যবহারকারীর সেশনের ক্ষতি অগ্রহণযোগ্য। সমস্ত ডেভেলপমেন্ট টিমের জন্য প্রচুর সংখ্যক পুরু স্ট্যাটিক ভিডিআই সংগঠিত করা বিদ্যমান ভিডিআই সমাধানের ব্যয়কে ব্যাপকভাবে বৃদ্ধি করেছে।

আমরা উন্নয়ন বিভাগের সংস্থানগুলিতে সরাসরি দূরবর্তী অ্যাক্সেস নিয়ে কাজ করার সিদ্ধান্ত নিয়েছি। জিরা, উইকি, গিটল্যাব, নেক্সাস, তৈরি এবং পরীক্ষা বেঞ্চ, ভার্চুয়াল অবকাঠামো। নিরাপত্তা রক্ষীরা দাবি করেছে যে প্রবেশাধিকার শুধুমাত্র নিম্নলিখিত বিষয়গুলি প্রদান করা যেতে পারে:

1. ব্যাঙ্কে ইতিমধ্যে উপলব্ধ প্রযুক্তি ব্যবহার করা।
2. পরিকাঠামোতে বিদ্যমান ডোমেন কন্ট্রোলার ব্যবহার করা উচিত নয় যা উৎপাদনশীল অ্যাকাউন্ট বস্তুর রেকর্ড সংরক্ষণ করে।
3. অ্যাক্সেস শুধুমাত্র একটি নির্দিষ্ট দলের দ্বারা প্রয়োজনীয় সংস্থানগুলির মধ্যে সীমাবদ্ধ হওয়া উচিত (যাতে একটি পণ্য দল অন্য দলের সংস্থানগুলি অ্যাক্সেস করতে পারে না)।
4. সিস্টেমে RBAC এর উপর সর্বাধিক নিয়ন্ত্রণ।

ফলস্বরূপ, এই বিভাগের জন্য একটি পৃথক ডোমেইন তৈরি করা হয়েছিল। এই ডোমেনে ব্যবহারকারীর শংসাপত্র এবং অবকাঠামো উভয়ই উন্নয়ন বিভাগের সমস্ত সংস্থান রয়েছে। এই ডোমেনের রেকর্ডের জীবনচক্র ব্যাঙ্কে বিদ্যমান আইডিএম ব্যবহার করে পরিচালিত হয়।

ব্যাংকের বিদ্যমান সরঞ্জামের ভিত্তিতে সরাসরি দূরবর্তী অ্যাক্সেস সংগঠিত হয়েছিল। অ্যাক্সেস কন্ট্রোল AD গ্রুপে বিভক্ত ছিল, যার সাথে প্রেক্ষাপটের নিয়মগুলি সঙ্গতিপূর্ণ ছিল (একটি পণ্য গ্রুপ = নিয়মের একটি গ্রুপ)।

ভিএম টেমপ্লেট ম্যানেজমেন্ট

একটি সমাবেশ এবং টেস্টিং লুপ তৈরির গতি উন্নয়ন ইউনিটের প্রধান দ্বারা সেট করা প্রধান কেপিআইগুলির মধ্যে একটি, কারণ পরিবেশ প্রস্তুত করার গতি সরাসরি পাইপলাইনের সামগ্রিক সম্পাদনের সময়কে প্রভাবিত করে। বেস ভিএম ইমেজ প্রস্তুত করার জন্য দুটি বিকল্প বিবেচনা করা হয়েছিল। প্রথমটি হল ন্যূনতম চিত্রের আকার, সমস্ত সিস্টেম পণ্যের জন্য ডিফল্ট, সেটিংস সংক্রান্ত ব্যাঙ্কের নীতিগুলির সাথে সর্বাধিক সম্মতি। দ্বিতীয়টি হল বেস ইমেজ, যেখানে একটি ভারী-শুল্ক POPPO ইনস্টল করা আছে, যার ইনস্টলেশনের সময়টি পাইপলাইনের কার্যকরী গতিকে ব্যাপকভাবে প্রভাবিত করতে পারে।

উন্নয়নের সময় অবকাঠামো এবং নিরাপত্তা প্রয়োজনীয়তাগুলিও বিবেচনায় নেওয়া হয়েছিল - ছবিগুলি আপ টু ডেট রাখা (প্যাচ, ইত্যাদি), এসআইইএম-এর সাথে একীকরণ, ব্যাঙ্কের মান অনুযায়ী নিরাপত্তা সেটিংস।

ফলস্বরূপ, তাদের আপ টু ডেট রাখার খরচ কমানোর জন্য ন্যূনতম চিত্রগুলি ব্যবহার করার সিদ্ধান্ত নেওয়া হয়েছিল। POPPO এর নতুন সংস্করণগুলির জন্য প্রতিটি চিত্র প্যাচ করার চেয়ে বেস OS আপডেট করা অনেক সহজ।

ফলাফলের উপর ভিত্তি করে, অপারেটিং সিস্টেমের ন্যূনতম প্রয়োজনীয় সেটগুলির একটি তালিকা তৈরি করা হয়েছিল, যার আপডেটটি অপারেশন টিম দ্বারা করা হয় এবং পাইপলাইন থেকে স্ক্রিপ্টগুলি সফ্টওয়্যার আপডেট করার জন্য সম্পূর্ণরূপে দায়ী এবং প্রয়োজনে সংস্করণটি পরিবর্তন করুন। ইনস্টল করা সফ্টওয়্যারটির - শুধুমাত্র প্রয়োজনীয় ট্যাগটি পাইপলাইনে স্থানান্তর করুন। হ্যাঁ, এর জন্য devops পণ্য দলের আরও জটিল স্থাপনার পরিস্থিতি প্রয়োজন, তবে এটি বেস ইমেজগুলিকে সমর্থন করার জন্য প্রয়োজনীয় অপারেশনাল সময়কে ব্যাপকভাবে হ্রাস করে, যা অন্যথায় বজায় রাখতে শতাধিক বেস VM চিত্রের প্রয়োজন হতে পারে।

ইন্টারনেট অ্যাক্সেস

ব্যাংকিং নিরাপত্তার সাথে আরেকটি হোঁচট খায় উন্নয়ন পরিবেশ থেকে ইন্টারনেট সম্পদের অ্যাক্সেস। উপরন্তু, এই অ্যাক্সেস দুটি বিভাগে বিভক্ত করা যেতে পারে:

1. অবকাঠামো অ্যাক্সেস।
2. বিকাশকারী অ্যাক্সেস।

Nexus এর সাথে বহিরাগত সংগ্রহস্থল প্রক্সি করার মাধ্যমে পরিকাঠামো অ্যাক্সেস সংগঠিত করা হয়েছিল। অর্থাৎ, ভার্চুয়াল মেশিন থেকে সরাসরি অ্যাক্সেস দেওয়া হয়নি। এটি তথ্য সুরক্ষার সাথে একটি সমঝোতায় পৌঁছানো সম্ভব করেছে, যা স্পষ্টতই উন্নয়ন বিভাগ থেকে বহির্বিশ্বে কোনও অ্যাক্সেস প্রদানের বিরুদ্ধে ছিল।

বিকাশকারীদের সুস্পষ্ট কারণে (স্ট্যাকওভারফ্লো) ইন্টারনেটে অ্যাক্সেসের প্রয়োজন ছিল। এবং যদিও উপরে উল্লিখিত সমস্ত কমান্ডের সার্কিটে দূরবর্তী অ্যাক্সেস ছিল, এটি সবসময় সুবিধাজনক নয় যখন আপনি IDE-তে ব্যাঙ্কে বিকাশকারীর কর্মক্ষেত্র থেকে ctrl+v করতে পারবেন না।

আইএসের সাথে একটি চুক্তি হয়েছে যে প্রাথমিকভাবে, পরীক্ষার পর্যায়ে, সাদা তালিকার ভিত্তিতে একটি ব্যাঙ্কিং প্রক্সির মাধ্যমে অ্যাক্সেস সরবরাহ করা হবে। প্রকল্পটি সম্পূর্ণ হওয়ার পরে, অ্যাক্সেসটি কালো তালিকায় স্থানান্তরিত হবে। বিশাল অ্যাক্সেস টেবিল প্রস্তুত করা হয়েছিল, যা মূল সংস্থান এবং ভান্ডারগুলি নির্দেশ করে যেগুলি প্রকল্পের শুরুতে অ্যাক্সেসের প্রয়োজন ছিল। এই অ্যাক্সেসগুলি সমন্বয় করতে যথেষ্ট সময় লেগেছে, যা কালো তালিকায় দ্রুততম স্থানান্তরের উপর জোর দেওয়া সম্ভব করেছে।

Результаты

প্রকল্পটি এক বছরেরও কম সময় আগে শেষ হয়েছে। অদ্ভুতভাবে, সমস্ত ঠিকাদার সময়মতো নতুন স্ট্যাকে স্যুইচ করেছে এবং নতুন অটোমেশনের কারণে কেউ বাকি নেই। IB ইতিবাচক প্রতিক্রিয়া শেয়ার করার জন্য কোন তাড়াহুড়ো করে না, তবে অভিযোগও করে না, যা থেকে আমরা উপসংহারে আসতে পারি যে তারা এটি পছন্দ করে। সংঘাত কমে গেছে কারণ তথ্য নিরাপত্তা আবার নিয়ন্ত্রণে বোধ করে, কিন্তু উন্নয়ন প্রক্রিয়ায় হস্তক্ষেপ করে না। দলগুলিকে আরও দায়িত্ব দেওয়া হয়েছিল, এবং তথ্য সুরক্ষার প্রতি সামগ্রিক মনোভাব আরও ভাল হয়ে উঠেছে। ব্যাঙ্ক বুঝতে পেরেছিল যে DevSecOps-এ রূপান্তর প্রায় অনিবার্য, এবং আমার মতে, সবচেয়ে মৃদু এবং সঠিক উপায়ে এটি করেছে।

আলেকজান্ডার শুবিন, সিস্টেম আর্কিটেক্ট।

উত্স: www.habr.com