Saat ini, sebagai bagian dari implementasi pengembangan baru dan strategi transformasi digital, VTB secara aktif memperkenalkan DevOps, mengintegrasikan praktik pengembangan perangkat lunak yang aman ke dalam proses rekayasa, meningkatkan tingkat otomatisasi, dan mengoptimalkan proses produksi rutin. Tujuan dari perubahan ini dapat dirumuskan dalam tiga poin utama: kecepatan, keandalan dan efisiensi. Secara alami, ketika melakukan transformasi global seperti itu, penting untuk mengadakan pertemuan informal terbuka, di mana Anda dapat berbagi pengalaman Anda sendiri, mendiskusikan berbagai persimpangan jalan dan nuansa memperkenalkan berbagai praktik produksi. Mitapas adalah format yang sangat baik untuk meningkatkan keterlibatan secara keseluruhan, kesadaran dan pertukaran pengalaman baik dengan kolega dari bank dan dengan mitra dari perusahaan lain.
Di bawah potongan - yang paling menarik dari pertemuan VTB pertama "DevSecOps: jawaban praktis untuk pertanyaan-pertanyaan non-sepele", yang diadakan pada bulan November di situs WeWork. Pertemuan dihadiri oleh lebih dari 200 spesialis.
Bagaimana semuanya dimulai
Seperti yang Anda ketahui, VTB adalah bank kedua di Rusia dalam hal jumlah pelanggan, aset, dan indikator keuangan. Sejak 2018, bank, sebagai bagian dari strategi pengembangan, mulai secara aktif mengubah arah teknologinya dan memutuskan transisi bertahap ke pengembangan sistem TI secara in-house. Sebelum ini, sebagian besar sistem dan solusi dipasok oleh vendor. Sekarang menjadi penting untuk meningkatkan kualitas, keamanan, dan kecepatan pengiriman dengan membentuk tim internal dan membangun proses TI produksi kami sendiri. Segalanya tampak sederhana dan jelas: ada kasus, ada solusi - ambil dan implementasikan.
Namun dalam kenyataannya, semuanya jauh lebih rumit. Di jalur ini, bank harus menghadapi banyak kesulitan. Igor Shvakov, kepala departemen otomatisasi proses pengembangan VTB, membicarakan hal ini dalam laporannya.
Tantangan utama adalah keunikan VTB dalam hal IT. Secara historis, bank berkembang melalui akuisisi dan integrasi pemain besar, yang masing-masing memiliki arsitektur IT sendiri, perangkat keras, proses bisnis, dll. Sejak 2018, VTB, VTB24 dan Bank Moskow telah menjadi satu VTB dengan IT uniknya sendiri lanskap, heterogen, dan infrastruktur terisolasi. Tentu saja, untuk melakukan perubahan transformasional, secara simultan membangun bisnis (seperti strategi bisnis) dan mengimplementasikan DevOps (dan terutama DevSecOps) dalam kondisi seperti itu adalah cerita yang tidak sepele.
Kesulitan pertama yang muncul di awal adalah sejumlah besar vendor dan, sebagai konsekuensinya, kompetensi sendiri yang sempit. Kami perlu mentransfer kontraktor eksternal yang bekerja di luar perimeter ke infrastruktur dan proses bank. Kesulitan kedua adalah bahwa pelanggan bisnis menuntut pengembangan aktif sistem TI untuk memastikan pencapaian kinerja bisnis yang tinggi. Oleh karena itu, kami harus bekerja dalam situasi meningkatnya aktivitas transaksional pelanggan dan ketergantungan tinggi pada sistem.
Awalnya, kami berencana untuk melakukan transisi ke in-house rails secara bertahap: memilih sistem dan menentukan tujuan, kemudian menyiapkan tim dan infrastruktur, dan pada tahap terakhir memilih alat dan mengonfigurasi DevSecOps Pipeline. Namun pada kenyataannya, kami harus melakukan semuanya sekaligus, dan pada saat yang sama menyelesaikan masalah yang muncul.
Pengalaman Replikasi Sistem
Karena kami tidak memiliki infrastruktur untuk pengembangan in-house, diputuskan untuk melakukan virtualisasi semuanya dan beralih ke arsitektur x86 untuk meminimalkan biaya dan pengeluaran. Sebagai hasilnya, platform infrastruktur dibangun berdasarkan solusi Nconix hyperconverged yang sudah ada, dan kami mentransfer semua alat pengembangan sebanyak mungkin.
Tetapi besi adalah besi, dan orang-orang mengerjakannya. Dalam hal ini, muncul pertanyaan tentang bagaimana membentuk tim. Kami memutuskan untuk fokus pada hubungan berikut: dua pengembang in-house harus memiliki satu teknolog, tim 10 pengembang harus memiliki satu insinyur DevOps dan dua penguji otomatisasi. Inilah yang kami alami dengan pengalaman kami sendiri, bekerja dengan lebih dari dua lusin sistem. Dan pendekatan ini sangat efektif.
Pertanyaan menarik berikutnya adalah bagaimana mentransfer sistem ke sirkuit bank.
Sebagai aturan, siklus terjemahan standar dari satu sistem membutuhkan 7-8 bulan. Itu ditata sebagai berikut.
- Selama dua bulan pertama ada seleksi staf. Pada saat yang sama, hubungan kontrak dengan kontraktor eksternal dianalisis untuk kemungkinan mentransfer mereka untuk bekerja di sirkuit bank.
- Pada bulan ketiga, kompetensi inti dalam sistem sedang dibentuk dan tim DevOps sedang diselesaikan dalam hal pengembangan, pengaturan pipa dan pengujian otomatis. Pada saat yang sama, akses ke sistem informasi untuk tim eksternal diatur dan disediakan.
- Bulan keempat - melatih tim dan mentransfer kode ke repositori bank dari vendor.
- Kelima - pengembangan bersama oleh tim bank dan kontraktor eksternal, Pipeline fine tuning dan peluncuran pengiriman pertama di atasnya.
- Pada bulan keenam dan ketujuh, revisi percontohan melewati seluruh proses yang sudah langsung pada infrastruktur bank.
- Hasil - untuk bulan ketujuh, tim gabungan sudah bekerja dalam lingkaran pengembangan yang sama di bank.
Pengalaman menunjukkan bahwa dengan pendekatan ini dimungkinkan untuk mengatur tim yang terkoordinasi dengan baik dan melaksanakan sejumlah besar proyek dalam satu setengah tahun. Dengan kata-kata, semuanya lancar, tetapi dalam proses transisi kami memiliki masalah. Salah satunya adalah sejumlah besar tim dari penyedia eksternal. Misalnya, tim salah satu vendor terdiri dari lebih dari 200 pengembang. Sekarang sebagian besar dari mereka bekerja dalam sirkuit umum pada infrastruktur perbankan. Dan ada banyak nuansa serupa.
Saat ini, bank telah memiliki lebih dari dua puluh tim pengembangan (lebih dari 500 pengembang penuh waktu dan eksternal), yang masing-masing menggunakan pipa sendiri dalam hal CI. Untuk sebagian besar dari perintah ini, langkah CD diimplementasikan. Ada juga beberapa sistem yang sudah menggunakan pengiriman perubahan secara otomatis ke sirkuit industri.
Pendekatan yang diterapkan memungkinkan pembangunan saluran pipa dan transfer ke segmen internal, tidak hanya untuk sistem baru dengan arsitektur layanan mikro yang fleksibel, tetapi juga untuk sejumlah besar sistem monolitik yang kompleks berdasarkan pada solusi "kotak" yang disesuaikan dengan persyaratan bank.
Sejak awal, kami tidak mencari cara yang mudah dan membuktikan bahwa dengan kompetensi karyawan yang tepat, Anda dapat menerapkan praktik DevOps untuk sistem apa pun dengan kompleksitas apa pun.
Sekarang prosesnya mendapatkan momentum, sistem baru ditambahkan, tumpukan teknologi terstandarisasi, satu tahap pipa, pelaporan, aturan kerja. Juga, pendekatan untuk mereplikasi praktik ke tim lain dan blok bank sedang bergerak ke tingkat kematangan baru, proses sedang dioptimalkan, peran dan kompetensi yang diperlukan dalam tim, dan tanggung jawab peserta ditentukan. Secara umum, proses replikasi telah diletakkan di atas rel dan sedang diubah dari startup di dalam bank besar menjadi solusi perusahaan teknologi tinggi. Jalur ini tercakup dalam lebih dari satu setengah tahun dari saat memasang besi di pusat data untuk meluncurkan perubahan dalam mode otomatis ke sirkuit industri atau pra-industri.
Perangkap
Sebagai bagian dari strategi baru VTB, transisi ke praktik DevSecOps telah dipilih sebagai salah satu aliran strategis di tingkat bank. Alexander Kalabukhov, kepala Pusat Praktek Teknik Departemen Pengembangan Sistem Produksi TI dan Pemeliharaan VTB, menceritakan hal ini dalam laporannya.
Diputuskan untuk mengubah layanan yang terlibat dalam pengembangan, pengujian dan operasi menjadi tim lintas fungsional yang bekerja pada fungsi bisnis yang sama. Tim termasuk spesialis arsitektur dan pengembangan, teknologi, penguji, dan insinyur DevOps. Dalam layanan terpusat, hanya yang tersisa yang memiliki kompetensi unik atau hidup dalam ritme unik (24/7) - administrasi sistem dan diterapkan, keamanan informasi.
Transisi seperti itu ke tim lintas fungsi menimbulkan persyaratan baru untuk proses manajemen kode (sumber, pengujian, penyebaran, dll.), Pengujian dan manajemen pengembangan. Di mana celah proses sebelumnya dapat diterima, mereka sekarang menjadi rintangan kritis, dan kami meningkatkan lanskap DevSecOps kami dalam hal alat dan menjembatani kesenjangan proses.
Berbicara tentang alat. Salah satu masalah adalah bahwa bank berada di bawah persyaratan peraturan tertentu yang terkait dengan kerahasiaan bank dan pembatasan serupa lainnya. Setiap sistem di bank melewati tahap tes penerimaan untuk kepatuhan dengan persyaratan keamanan informasi, termasuk dalam hal alat-alat DevOps. Sayangnya, sebagian besar insinyur DevOps tidak pernah bekerja di lingkungan yang diatur sedemikian keras, dan mereka sering tahu sedikit tentang audit alat ini, tentang bagaimana akses jaringan dan akses data harus dibatasi, apa yang harus dilakukan dengan rahasia yang dipertukarkan antara alat DevOps dll.
Tugas utama membangun perlindungan data di dalam bank adalah memastikan bahwa tidak ada satu orang yang memiliki akses ke semua data sekaligus. Itulah sebabnya pengembang tidak dapat melakukan fungsi aplikasi dan administrator sistem. Keterbatasan serupa ada untuk insinyur DevSec. Secara alami, tidak satu pun dari spesialis ini yang dapat menjadi administrator keamanan informasi. Setelah semua peran dan batas otoritas mereka ditetapkan, Anda dapat menanamkan proses standar untuk memberikan hak alat DevOps ke proses umum pemberian hak di bank.
Aspek penting adalah keamanan jaringan. Anda harus mematuhi aturan bahwa koneksi hanya dapat dibuat dari sirkuit yang lebih tepercaya ke yang kurang tepercaya. Jika proses dilakukan dalam arah yang berlawanan, perlu untuk menyediakan celah jaringan menggunakan cara khusus. Koneksi jaringan harus dibuat dengan aman dan masih terenkripsi di antara mereka sendiri. Jika tidak, virus dan perangkat lunak berbahaya lainnya dapat memasuki rantai, yang dapat menyebabkan kebocoran data dan insiden di lingkungan industri.
Masalah keamanan dipengaruhi oleh cara data diatur, karena ada berbagai lingkungan pengembangan dan pengujian, ada kebutuhan untuk bergabung dengan sirkuit bank melalui VPN sehingga kontraktor dapat bekerja dari laptop mereka. Plus, ada sirkuit khusus di mana akses ke lingkaran orang terbatas diperbolehkan, data tidak boleh melampaui sirkuit ini.
Oleh karena itu, terlepas dari segala kekayaan alat DevOps yang ada, perlu untuk menstandarkannya. Dengan pendekatan yang tepat, keamanan informasi di bank memperkenalkan pembatasan pada pengembangan dan proses operasi, tetapi tidak mencegah pengenalan teknologi baru.
Cybersecurity Above All
Dalam konteks transformasi bisnis dan waktu yang lebih singkat untuk meluncurkan produk digital baru di pasar, tantangan industri utama adalah memastikan keamanan informasi di semua tahap proses produksi berkelanjutan. Topik integrasi praktik pengembangan perangkat lunak aman di DevOps adalah subjek dari laporan oleh Yuri Sergeyev, mitra pengelola Swordfish Security dan pemimpin industri DevSecOps di Rusia.
Implementasi paradigma cybersecurity di DevOps adalah proses yang agak rumit, di mana lapisan praktik Keamanan menyelimuti seluruh siklus rekayasa produksi. Praktik keamanan informasi itu sendiri didukung oleh tumpukan instrumental yang diintegrasikan ke dalam semua tahapan proses.
Praktik IS yang diperlukan meliputi:
- Kontrol komponen open source ketika mereka jatuh ke pengembangan perimeter (Open Source Analysis, OSA);
- Analisis kode statis (Pengujian Keamanan Aplikasi Statis, SAST);
- Memantau komposisi komponen perangkat lunak (Analisis Komposisi Perangkat Lunak, SCA);
- Semua jenis analisis dinamis (Pengujian Keamanan Aplikasi Dinamis, Pengujian Keamanan Aplikasi DAST / Aplikasi Interaktif, Pengujian Keamanan Aplikasi Aplikasi Beast / Beast, BAST);
- Analisis kode biner dan kontrol komposisi wadah (Bytecode dan Analisis Kontainer, BCA);
- Implementasi WAF (Web Application Firewall).
Pada saat yang sama, aspek yang paling penting ketika menskalakan dan mentransformasikan proses DevOps ke dalam paradigma DevSecOps yang diturunkan adalah:
- Penggunaan perpustakaan yang aman, kerangka kerja dan komponen perangkat lunak secara default selama proses pengembangan (Secure-by-Default);
- Integrasi praktik teknologi IS di awal pipa CI / CD (pendekatan Shift-Kiri);
- Otomatisasi semua proses dalam konsep Everything-as-a-Code;
- Pembentukan komunitas juara keamanan yang bertanggung jawab atas tugas keamanan informasi di tim produksi dan merupakan panduan budaya keamanan rekayasa;
- Penerapan model jatuh tempo DevSecOps baik untuk menilai proses yang ada dan untuk perbaikan berkelanjutan;
- Memastikan transparansi semua kegiatan keamanan untuk semua peserta dalam proses produksi teknik.
Secara terpisah, ada baiknya menekankan pentingnya praktik DevSecOps-orkestrasi (Aplikasi Keamanan Pengujian Orkestrasi, ASTO), yang menyediakan integrasi ujung-ke-ujung tumpukan alat IS dengan alat pengembangan, manajemen otomatis dari jalur pipa keamanan (jalur pipa), serta pengumpulan, konsolidasi, dan analisis semua data secara berkelanjutan proses pengembangan perangkat lunak yang aman. Praktik orkestrasi dapat secara signifikan menghemat sumber daya dan mengurangi lebih dari 10 kali total waktu implementasi inisiatif DevSecOps dalam lingkungan rekayasa heterogen yang kompleks.
Jika kita berbicara tentang transformasi secara keseluruhan, maka kita dapat membedakan faktor kunci keberhasilan berikut:
- Pengenalan alat atau elemen terpisah dari proses cybersecurity, tentu saja, merupakan langkah penting, tetapi dalam hal apapun tidak ada peluru perak untuk mengatasi masalah keamanan perangkat lunak yang dikembangkan pada skala industri. Kunci keberhasilan hanya aplikasi terintegrasi dari seluruh kumpulan praktik keamanan informasi.
- Penerapan praktik orkestrasi akan melindungi tim teknik dan tim keamanan informasi dari kekacauan teknologi integrasi instrumen "setinggi lutut" dan otomatisasi "tambal sulam" yang tidak terkendali.
- Pengumpulan data dan visualisasi metrik selanjutnya akan memungkinkan Anda untuk mengelola proses ujung ke ujung, mewujudkan transparansi penuh, dan juga menciptakan dasar yang diperlukan untuk penerapan praktik pembelajaran mesin di masa mendatang.