DevOps vs DevSecOps: როგორ გამოიყურებოდა იგი ერთ ბანკში

ბანკი თავის პროექტებს უწევს ბევრ კონტრაქტორს. "გარე" წერენ კოდს, შემდეგ გადასცემენ შედეგებს არც თუ ისე მოსახერხებელი ფორმით. კონკრეტულად, პროცესი ასე გამოიყურებოდა: მათ გადასცეს პროექტი, რომელმაც მათთან ერთად გაიარა ფუნქციური ტესტები, შემდეგ კი საბანკო პერიმეტრის შიგნით ტესტირება ჩაუტარდა ინტეგრაციას, დატვირთვას და ა.შ. ხშირად აღმოჩენილი იყო, რომ ტესტები წარუმატებელი იყო. შემდეგ ყველაფერი დაუბრუნდა გარე დეველოპერს. როგორც მიხვდით, ეს ნიშნავდა შეცდომების გამოსწორების ხანგრძლივ პერიოდს.

ბანკმა გადაწყვიტა, რომ შესაძლებელი იყო და აუცილებელი იყო მთელი მილსადენის ფრთის ქვეშ გადატანა, ვალდებულებიდან გათავისუფლებამდე. რომ ყველაფერი ერთგვაროვანი იყოს და ბანკში პროდუქტზე პასუხისმგებელი გუნდების კონტროლის ქვეშ იყოს. ანუ, თითქოს გარე კონტრაქტორი უბრალოდ მუშაობდა სადღაც ოფისის გვერდით ოთახში. კორპორატიულ სტეკზე. ეს არის ჩვეულებრივი დევოპი.

საიდან გაჩნდა სეკი? ბანკის უსაფრთხოებამ დააყენა მაღალი მოთხოვნები, თუ როგორ შეუძლია გარე კონტრაქტორს იმუშაოს ქსელის სეგმენტში, რა წვდომა აქვს ვინმეს, როგორ და ვინ მუშაობს კოდით. უბრალოდ, IB-მ ჯერ არ იცოდა, რომ როდესაც კონტრაქტორები მუშაობენ გარეთ, რამდენიმე საბანკო სტანდარტი დაცულია. შემდეგ კი რამდენიმე დღეში ყველამ უნდა დაიწყოს მათზე დაკვირვება.

უბრალო გამოცხადებამ, რომ კონტრაქტორს სრული წვდომა ჰქონდა პროდუქტის კოდზე, უკვე თავდაყირა დააყენა მათი სამყარო.

ამ მომენტში დაიწყო DevSecOps-ის ამბავი, რომლის შესახებაც მინდა მოგითხროთ.

რა პრაქტიკული დასკვნები გამოიტანა ბანკმა ამ სიტუაციიდან?

ბევრი კამათი იყო იმაზე, რომ ყველაფერი არასწორი გზით კეთდება. დეველოპერებმა განაცხადეს, რომ უსაფრთხოება მხოლოდ განვითარებაში ჩარევის მცდელობითაა დაკავებული და ისინი, როგორც დარაჯები, ცდილობენ აკრძალონ დაუფიქრებლად. თავის მხრივ, უსაფრთხოების სპეციალისტები ყოყმანობდნენ არჩევანის გაკეთებას შორის: „დეველოპერები ქმნიან დაუცველობას ჩვენს წრეში“ და „დეველოპერები არ ქმნიან დაუცველობას, არამედ ისინი თავად არიან“. დავა კიდევ დიდხანს გაგრძელდებოდა, რომ არა ბაზრის ახალი მოთხოვნები და DevSecOps პარადიგმის გაჩენა. შესაძლებელი იყო იმის ახსნა, რომ პროცესების სწორედ ეს ავტომატიზაცია, ინფორმაციული უსაფრთხოების მოთხოვნების გათვალისწინებით, "გარეშე" დაეხმარება ყველას დარჩეს ბედნიერი. იმ გაგებით, რომ წესები დაუყოვნებლივ იწერება და არ იცვლება თამაშის დროს (ინფორმაციული უსაფრთხოება არ აკრძალავს რაიმეს მოულოდნელად), ხოლო დეველოპერები ინფორმაციას აწვდიან ინფორმაციას ინფორმაციული უსაფრთხოების შესახებ ყველაფერზე, რაც ხდება (ინფორმაციული უსაფრთხოება უცებ არ წააწყდება რაღაცას) . თითოეული გუნდი ასევე პასუხისმგებელია საბოლოო უსაფრთხოებაზე და არა ზოგიერთი აბსტრაქტული უფროსი ძმა.

1. ვინაიდან გარე თანამშრომლებს უკვე აქვთ წვდომა კოდზე და მთელ რიგ შიდა სისტემაზე, ალბათ შესაძლებელია დოკუმენტებიდან ამოიღონ მოთხოვნა „განვითარება მთლიანად უნდა განხორციელდეს ბანკის ინფრასტრუქტურაზე“.
2. მეორე მხრივ, ჩვენ უნდა გავაძლიეროთ კონტროლი იმაზე, რაც ხდება.
3. კომპრომისი იყო ჯვარედინი ფუნქციური გუნდების შექმნა, სადაც თანამშრომლები მჭიდროდ მუშაობენ გარე ადამიანებთან. ამ შემთხვევაში, თქვენ უნდა დარწმუნდეთ, რომ გუნდი მუშაობს ინსტრუმენტებზე ბანკის სერვერებზე. თავიდან ბოლომდე.

ანუ კონტრაქტორების შეშვება შეიძლება, მაგრამ მათ ცალკე სეგმენტები უნდა მიეცეს. რათა ბანკის ინფრასტრუქტურაში გარედან რაიმე სახის ინფექცია არ შეიყვანონ და საჭიროზე მეტი არ დაინახონ. ისე, რომ მათი ქმედებები დარეგისტრირდეს. DLP გაჟონვისგან დაცვის მიზნით, ეს ყველაფერი შედიოდა.

პრინციპში, ყველა ბანკი ადრე თუ გვიან მიდის ამას. აქ ჩვენ გავემართეთ და შევთანხმდით მოთხოვნებზე ისეთი გარემოებისთვის, სადაც "ექსტერნები" მუშაობენ. გამოჩნდა წვდომის კონტროლის ხელსაწყოების მაქსიმალური დიაპაზონი, დაუცველობის შემოწმების ხელსაწყოები, ანტივირუსული ანალიზი სქემებზე, შეკრებებსა და ტესტებზე. ამას DevSecOps ჰქვია.

მოულოდნელად გაირკვა, რომ თუ ადრე DevSecOps საბანკო უსაფრთხოებას არ ჰქონდა კონტროლი დეველოპერის მხრიდან რა ხდებოდა, მაშინ ახალ პარადიგმაში უსაფრთხოება კონტროლდება ისევე, როგორც ჩვეულებრივი მოვლენები ინფრასტრუქტურაზე. მხოლოდ ახლა არის გაფრთხილებები შეკრებებზე, ბიბლიოთეკების კონტროლზე და ა.შ.

რჩება მხოლოდ გუნდების ახალ მოდელზე გადაყვანა. აბა, შექმენით ინფრასტრუქტურა. მაგრამ ეს წვრილმანებია, ეს ბუს დახატვას ჰგავს. ფაქტობრივად, ინფრასტრუქტურით ვეხმარებოდით და იმ დროს განვითარების პროცესები იცვლებოდა.

რა შეიცვალა

ჩვენ გადავწყვიტეთ მისი განხორციელება მცირე ნაბიჯებით, რადგან გვესმოდა, რომ ბევრი პროცესი დაიშლებოდა და ბევრი „ექსტერნალი“ შესაძლოა ვერ გაუძლოს ახალ სამუშაო პირობებს ყველას მეთვალყურეობის ქვეშ.

პირველ რიგში, ჩვენ შევქმენით მრავალფუნქციური გუნდები და ვისწავლეთ პროექტების ორგანიზება ახალი მოთხოვნების გათვალისწინებით. ორგანიზაციულად განვიხილეთ რა პროცესები. შედეგი იყო ასამბლეის მილსადენის დიაგრამა ყველა პასუხისმგებელით.

• IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: 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.

არჩეული დასტა:

• ცოდნის ბაზა - ატლასიის შესართავი;
• დავალების ტრეკერი - Atlassian Jira;
• არტეფაქტის საცავი - „Nexus“;
• უწყვეტი ინტეგრაციის სისტემა - “Gitlab CI”;
• უწყვეტი ანალიზის სისტემა - „SonarQube“;
• აპლიკაციის უსაფრთხოების ანალიზის სისტემა - „Micro Focus Fortify“;
• საკომუნიკაციო სისტემა - “GitLab Mattermost”;
• კონფიგურაციის მართვის სისტემა - "Ansible";
• მონიტორინგის სისტემა - "ELK", "TICK Stack" ("InfluxData").

მათ დაიწყეს გუნდის შექმნა, რომელიც მზად იქნებოდა კონტრაქტორების შიგნით ჩათრევისთვის. არსებობს გაცნობიერება, რომ არსებობს რამდენიმე მნიშვნელოვანი რამ:

• ყველაფერი უნდა იყოს ერთიანი, ყოველ შემთხვევაში კოდის გადაცემისას. იმიტომ, რომ იმდენი კონტრაქტორი იყო, რამდენი განსხვავებული განვითარების პროცესი იყო თავისი თავისებურებებით. საჭირო იყო ყველას მორგება დაახლოებით ერთში, მაგრამ ვარიანტებით.
• ბევრი კონტრაქტორია და ინფრასტრუქტურის ხელით შექმნა არ არის შესაფერისი. ნებისმიერი ახალი ამოცანა უნდა დაიწყოს ძალიან სწრაფად - ანუ, ინსტანცია უნდა განლაგდეს თითქმის მყისიერად, რათა დეველოპერებს ჰქონდეთ გადაწყვეტილებების ნაკრები მათი მილსადენის მართვისთვის.

პირველი ნაბიჯის გადასადგმელად საჭირო იყო იმის გაგება, თუ რა კეთდებოდა. და ჩვენ უნდა განვსაზღვროთ, როგორ მივსულიყავით იქ. ჩვენ დავიწყეთ სამიზნე გადაწყვეტის არქიტექტურის შედგენაში დახმარებით, როგორც ინფრასტრუქტურაში, ასევე CI/CD ავტომატიზაციაში. შემდეგ დავიწყეთ ამ კონვეიერის აწყობა. ჩვენ გვჭირდებოდა ერთი ინფრასტრუქტურა, ყველასთვის ერთნაირი, სადაც ერთი და იგივე კონვეიერები გაივლიდა. ჩვენ შევთავაზეთ ვარიანტები გათვლებით, დაფიქრდა ბანკმა, შემდეგ გადავწყვიტეთ, რა აშენდებოდა და რა სახსრებით.

შემდეგი არის მიკროსქემის შექმნა - პროგრამული უზრუნველყოფის ინსტალაცია, კონფიგურაცია. ინფრასტრუქტურის განლაგებისა და მართვის სკრიპტების შემუშავება. შემდეგი მოდის კონვეიერის მხარდაჭერაზე გადასვლა.

გადავწყვიტეთ ყველაფერი გამოგვემოწმებინა პილოტზე. საინტერესოა, რომ პილოტირების დროს ბანკში პირველად გამოჩნდა გარკვეული დასტა. სხვა საკითხებთან ერთად, ერთ-ერთი გადაწყვეტის შიდა გამყიდველს შესთავაზეს პილოტის ფარგლები სწრაფი გაშვებისთვის. დაცვამ ის პილოტირებისას გაიცნო და დაუვიწყარი შთაბეჭდილება დატოვა. როდესაც გადავწყვიტეთ გადართვა, საბედნიეროდ, ინფრასტრუქტურული ფენა შეიცვალა Nutanix-ის ხსნარით, რომელიც ადრე უკვე ბანკში იყო. უფრო მეტიც, მანამდე ეს იყო VDI-სთვის, მაგრამ ჩვენ ხელახლა გამოვიყენეთ ინფრასტრუქტურული სერვისებისთვის. მცირე მოცულობებში ის არ ჯდებოდა ეკონომიკაში, მაგრამ დიდი მოცულობით გახდა შესანიშნავი გარემო განვითარებისა და ტესტირებისთვის.

დატის დანარჩენი ნაწილი მეტ-ნაკლებად ყველასთვის ნაცნობია. Ansible-ში ავტომატიზაციის ხელსაწყოები გამოიყენეს და უსაფრთხოების სპეციალისტები მჭიდროდ თანამშრომლობდნენ მათთან. ატლასინის სტეკი ბანკმა გამოიყენა პროექტამდე. 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-თან ინტეგრაცია, უსაფრთხოების პარამეტრები ბანკის სტანდარტების მიხედვით.

შედეგად, გადაწყდა გამოეყენებინათ მინიმალური სურათები, რათა მინიმუმამდე შემცირებულიყო მათი განახლების ღირებულება. საბაზისო OS-ის განახლება ბევრად უფრო ადვილია, ვიდრე POPPO-ს ახალი ვერსიებისთვის თითოეული სურათის დაყენება.

შედეგების საფუძველზე, ჩამოყალიბდა ოპერაციული სისტემების მინიმალური საჭირო ნაკრების სია, რომლის განახლებას ახორციელებს ოპერაციების ჯგუფი, ხოლო მილსადენის სკრიპტები მთლიანად პასუხისმგებელია პროგრამული უზრუნველყოფის განახლებაზე და საჭიროების შემთხვევაში, ვერსიის შეცვლაზე. დაინსტალირებული პროგრამული უზრუნველყოფის - უბრალოდ გადაიტანეთ საჭირო ტეგი მილსადენზე. დიახ, ეს მოითხოვს devops პროდუქტის გუნდს ჰქონდეს უფრო რთული განლაგების სცენარები, მაგრამ ეს მნიშვნელოვნად ამცირებს საბაზისო სურათების მხარდასაჭერად საჭირო ოპერაციულ დროს, რაც სხვაგვარად შეიძლება მოითხოვოს ასზე მეტი საბაზისო VM სურათის შესანახად.

ინტერნეტი

კიდევ ერთი დაბრკოლება საბანკო უსაფრთხოებასთან იყო წვდომა ინტერნეტ რესურსებზე განვითარების გარემოდან. უფრო მეტიც, ეს წვდომა შეიძლება დაიყოს ორ კატეგორიად:

1. ინფრასტრუქტურის წვდომა.
2. დეველოპერის წვდომა.

ინფრასტრუქტურაზე წვდომა ორგანიზებული იყო გარე საცავების პროქსირებით Nexus-ით. ანუ ვირტუალური მანქანებიდან პირდაპირი წვდომა არ იყო გათვალისწინებული. ამან შესაძლებელი გახადა ინფორმაციული უსაფრთხოებასთან კომპრომისის მიღწევა, რომელიც კატეგორიულად ეწინააღმდეგებოდა განვითარების სეგმენტიდან გარე სამყაროში რაიმე სახის წვდომას.

დეველოპერებს სჭირდებოდათ ინტერნეტზე წვდომა გასაგები მიზეზების გამო (stackoverflow). და მიუხედავად იმისა, რომ ყველა ბრძანებას, როგორც ზემოთ აღვნიშნეთ, ჰქონდა დისტანციური წვდომა წრედზე, ყოველთვის არ არის მოსახერხებელი, როდესაც არ შეგიძლიათ Ctrl+v-ის გაკეთება დეველოპერის სამუშაო ადგილიდან ბანკში IDE-ში.

IS-თან მიღწეული იქნა შეთანხმება, რომ თავდაპირველად, ტესტირების ეტაპზე, წვდომა უზრუნველყოფილი იქნება საბანკო პროქსის მეშვეობით თეთრი სიის საფუძველზე. პროექტის დასრულების შემდეგ წვდომა გადაეცემა შავ სიას. მომზადდა ხელმისაწვდომობის უზარმაზარი ცხრილები, სადაც მითითებული იყო ძირითადი რესურსები და საცავი, რომლებზეც წვდომა იყო საჭირო პროექტის დაწყებისას. ამ წვდომის კოორდინაციას საკმაოდ დიდი დრო დასჭირდა, რამაც შესაძლებელი გახადა დაჟინებით მოითხოვოს შავ სიებში რაც შეიძლება სწრაფად გადასვლა.

დასკვნები

პროექტი ერთი წლის წინ დასრულდა. უცნაურია, მაგრამ ყველა კონტრაქტორი დროულად გადავიდა ახალ სტეკზე და არავინ დატოვა ახალი ავტომატიზაციის გამო. IB არ ჩქარობს დადებითი გამოხმაურების გაზიარებას, მაგრამ არც უჩივის, საიდანაც შეგვიძლია დავასკვნათ, რომ მოსწონთ. კონფლიქტები ჩაცხრა, რადგან ინფორმაციული უსაფრთხოება კვლავ გრძნობს კონტროლს, მაგრამ არ ერევა განვითარების პროცესებში. გუნდებს მეტი პასუხისმგებლობა მიენიჭათ და ინფორმაციული უსაფრთხოების მიმართ საერთო დამოკიდებულება გაუმჯობესდა. ბანკმა გააცნობიერა, რომ DevSecOps-ზე გადასვლა თითქმის გარდაუვალი იყო და ეს გააკეთა, ჩემი აზრით, ყველაზე ნაზი და სწორი გზით.

ალექსანდრე შუბინი, სისტემის არქიტექტორი.

წყარო: www.habr.com