DevOps vs DevSecOps: seperti apa di satu bank

Bank melakukan outsourcing proyeknya ke banyak kontraktor. "Eksternal" menulis kode, lalu mengirimkan hasilnya dalam bentuk yang tidak nyaman. Secara khusus, prosesnya terlihat seperti ini: mereka menyerahkan sebuah proyek yang lulus uji fungsional bersama mereka, dan kemudian diuji di dalam perimeter perbankan untuk integrasi, pemuatan, dan sebagainya. Seringkali ditemukan bahwa pengujian gagal. Kemudian semuanya kembali ke pengembang eksternal. Seperti yang bisa Anda tebak, ini berarti waktu tunggu yang lama untuk perbaikan bug.

Bank Dunia memutuskan bahwa adalah mungkin dan perlu untuk menyeret seluruh pipa di bawah sayapnya, mulai dari komitmen hingga pelepasan. Agar semuanya seragam dan terkendali oleh tim yang bertanggung jawab terhadap produk di bank. Artinya, seolah-olah kontraktor eksternal hanya bekerja di suatu tempat di ruangan sebelah kantor. Di tumpukan perusahaan. Ini adalah pengembang biasa.

Darimana Sec berasal? Keamanan bank sangat menuntut bagaimana kontraktor eksternal dapat bekerja di segmen jaringan, akses apa yang dimiliki seseorang, bagaimana dan siapa yang bekerja dengan kode tersebut. Hanya saja IB belum mengetahui bahwa ketika kontraktor bekerja di luar, hanya sedikit standar perbankan yang diikuti. Dan kemudian dalam beberapa hari setiap orang harus mulai mengamatinya.

Pengungkapan sederhana bahwa kontraktor memiliki akses penuh terhadap kode produk telah menjungkirbalikkan dunia mereka.

Saat ini, kisah DevSecOps dimulai, yang ingin saya ceritakan kepada Anda.

Kesimpulan praktis apa yang diambil bank dari situasi ini?

Ada banyak kontroversi mengenai fakta bahwa segala sesuatu dilakukan dengan cara yang salah. Para pengembang mengatakan bahwa keamanan hanya sibuk mencoba mengganggu pembangunan, dan mereka, seperti penjaga, mencoba melarang tanpa berpikir. Pada gilirannya, pakar keamanan ragu-ragu antara memilih antara sudut pandang: “pengembang menciptakan kerentanan di sirkuit kita” dan “pengembang tidak menciptakan kerentanan, tetapi mereka sendiri.” Perselisihan ini akan berlanjut untuk waktu yang lama jika bukan karena tuntutan pasar yang baru dan munculnya paradigma DevSecOps. Dapat dijelaskan bahwa otomatisasi proses yang mempertimbangkan persyaratan keamanan informasi “di luar kotak” akan membantu semua orang tetap bahagia. Dalam artian peraturan segera dituliskan dan tidak berubah selama permainan (keamanan informasi tidak akan melarang sesuatu yang tidak terduga), dan pengembang terus memberikan informasi kepada keamanan informasi tentang segala sesuatu yang terjadi (keamanan informasi tidak menemui sesuatu secara tiba-tiba) . Setiap tim juga bertanggung jawab atas keselamatan tertinggi, dan bukan beberapa kakak laki-laki yang abstrak.

1. Karena karyawan eksternal telah memiliki akses terhadap kode etik dan sejumlah sistem internal, maka ada kemungkinan untuk menghapus persyaratan “pembangunan harus dilakukan seluruhnya pada infrastruktur bank” dari dokumen tersebut.
2. Di sisi lain, kita perlu memperkuat kendali atas apa yang terjadi.
3. Komprominya adalah pembentukan tim lintas fungsi, di mana karyawan bekerja sama dengan pihak eksternal. Dalam hal ini, Anda perlu memastikan bahwa tim mengerjakan alat di server bank. Dari awal hingga akhir.

Artinya, kontraktor boleh masuk, tapi perlu diberi segmen tersendiri. Agar mereka tidak membawa infeksi dari luar ke dalam infrastruktur bank dan agar mereka tidak melihat lebih dari yang diperlukan. Nah, agar tindakan mereka dicatat. DLP untuk perlindungan terhadap kebocoran, semua ini disertakan.

Pada prinsipnya, semua bank akan melakukan hal ini cepat atau lambat. Di sini kami menempuh jalur yang sulit dan menyetujui persyaratan untuk lingkungan tempat “eksternal” bekerja. Muncul berbagai macam alat kontrol akses, alat pemeriksaan kerentanan, analisis anti-virus di sirkuit, rakitan, dan pengujian. Ini disebut DevSecOps.

Tiba-tiba menjadi jelas bahwa jika sebelumnya keamanan perbankan DevSecOps tidak memiliki kendali atas apa yang terjadi di pihak pengembang, maka dalam paradigma baru keamanan dikendalikan dengan cara yang sama seperti kejadian biasa pada infrastruktur. Baru sekarang ada peringatan tentang majelis, pengendalian perpustakaan, dan sebagainya.

Yang tersisa hanyalah mentransfer tim ke model baru. Nah, buat infrastrukturnya. Tapi ini sepele, seperti menggambar burung hantu. Sebenarnya kami membantu infrastruktur, dan saat itu proses pembangunan sedang berubah.

Apa yang telah berubah

Kami memutuskan untuk menerapkannya dalam langkah-langkah kecil, karena kami memahami bahwa banyak proses akan berantakan, dan banyak “eksternal” mungkin tidak mampu bertahan dalam kondisi kerja baru di bawah pengawasan semua orang.

Pertama, kami menciptakan tim lintas fungsi dan belajar mengatur proyek dengan mempertimbangkan persyaratan baru. Dalam artian secara organisatoris kita bahas proses apa saja. Hasilnya adalah diagram pipa perakitan dengan semua penanggung jawabnya.

• IC: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
• CD: Kemungkinan, Wayang, TeamCity, Gitlab TFS, Liquidbase.
• Uji: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Performance Center, MF UFT, Atacama.
• presentasi (pelaporan, komunikasi): Grafana, Kibana, Jira, Confluence, RocketChat.
• Operasi (pemeliharaan, manajemen): Ansible, Zabbix, Prometheus, Elastic + Logstash, MF Service Manager, Jira, Confluence, MS Project.

Tumpukan yang dipilih:

• Basis Pengetahuan - Pertemuan Atlassian;
• Pelacak tugas - Atlassian Jira;
• Repositori artefak - “Nexus”;
• Sistem integrasi berkelanjutan - “Gitlab CI”;
• Sistem analisis berkelanjutan - “SonarQube”;
• Sistem analisis keamanan aplikasi - “Micro Focus Fortify”;
• Sistem komunikasi - “GitLab Paling Penting”;
• Sistem manajemen konfigurasi - “Mungkin”;
• Sistem pemantauan - “ELK”, “TICK Stack” (“InfluxData”).

Mereka mulai membentuk tim yang siap menyeret kontraktor masuk. Ada kesadaran bahwa ada beberapa hal penting:

• Semuanya harus disatukan, setidaknya saat mengirimkan kode. Karena banyaknya kontraktor, banyaknya proses pembangunan yang berbeda-beda dengan kekhasannya masing-masing. Penting untuk memasukkan semua orang ke dalam satu kesatuan, tetapi dengan pilihan.
• Ada banyak kontraktor, dan pembuatan infrastruktur secara manual tidaklah sesuai. Setiap tugas baru harus dimulai dengan sangat cepat - yaitu, instance harus di-deploy hampir secara instan sehingga pengembang memiliki serangkaian solusi untuk mengelola pipeline mereka.

Untuk mengambil langkah pertama, penting untuk memahami apa yang sedang dilakukan. Dan kami harus menentukan bagaimana menuju ke sana. Kami memulai dengan membantu menggambar arsitektur solusi target baik di bidang infrastruktur maupun otomatisasi CI/CD. Kemudian kami mulai merakit konveyor ini. Kami membutuhkan satu infrastruktur, infrastruktur yang sama untuk semua orang, dimana konveyor yang sama akan beroperasi. Kami menawarkan pilihan dengan perhitungan, pikir bank, lalu memutuskan apa yang akan dibangun dan dengan dana apa.

Berikutnya adalah pembuatan sirkuit - instalasi perangkat lunak, konfigurasi. Pengembangan skrip untuk penerapan dan pengelolaan infrastruktur. Berikutnya adalah transisi ke dukungan konveyor.

Kami memutuskan untuk menguji semuanya pada uji coba. Menariknya, selama uji coba, tumpukan tertentu muncul di bank untuk pertama kalinya. Antara lain, salah satu solusi ditawarkan kepada vendor dalam negeri sebagai ruang lingkup uji coba untuk peluncuran yang cepat. Keamanan mengenalnya saat dia mengemudikan, dan itu meninggalkan kesan yang tak terlupakan. Saat kami memutuskan untuk beralih, untungnya lapisan infrastruktur diganti dengan solusi Nutanix yang sudah ada di bank sebelumnya. Apalagi sebelumnya untuk VDI, tapi kami gunakan kembali untuk layanan infrastruktur. Dalam volume kecil, teknologi ini tidak cocok untuk perekonomian, namun dalam volume besar, teknologi ini menjadi lingkungan yang sangat baik untuk pengembangan dan pengujian.

Sisa tumpukannya kurang lebih familier bagi semua orang. Alat otomatisasi di Ansible digunakan, dan pakar keamanan bekerja sama dengan alat tersebut. Tumpukan Atlassin digunakan oleh bank sebelum proyek. Alat keamanan Fortinet - diusulkan oleh petugas keamanan itu sendiri. Kerangka pengujian dibuat oleh bank, tidak ada pertanyaan yang diajukan. Sistem repositori menimbulkan pertanyaan; saya harus terbiasa dengannya.

Kontraktor diberi tumpukan baru. Mereka memberi kami waktu untuk menulis ulang untuk GitlabCI, dan memigrasikan Jira ke segmen perbankan, dan seterusnya.

selangkah demi selangkah

Langkah 1. Pertama, kami menggunakan solusi dari vendor dalam negeri, produknya terhubung ke segmen jaringan DSO yang baru dibuat. Platform ini dipilih karena waktu pengirimannya, fleksibilitas penskalaannya, dan kemungkinan otomatisasi penuh. Tes yang dilakukan:

• Kemungkinan manajemen infrastruktur platform virtualisasi yang fleksibel dan sepenuhnya otomatis (jaringan, subsistem disk, subsistem sumber daya komputasi).
• Otomatisasi manajemen siklus hidup mesin virtual (pembuatan template, snapshot, pencadangan).

Setelah instalasi dan konfigurasi dasar platform, platform tersebut digunakan sebagai titik penempatan subsistem tahap kedua (alat DSO, garis besar pengembangan sistem ritel). Kumpulan saluran pipa yang diperlukan telah dibuat - pembuatan, penghapusan, modifikasi, pencadangan mesin virtual. Jalur pipa ini digunakan sebagai tahap pertama proses penerapan.

Hasilnya adalah peralatan yang disediakan tidak memenuhi persyaratan kinerja dan toleransi kesalahan bank. DIT bank memutuskan untuk membuat kompleks berdasarkan paket perangkat lunak Nutanix.

tahap 2. Kami mengambil tumpukan yang telah ditentukan, dan menulis instalasi otomatis dan skrip pasca-konfigurasi untuk semua subsistem sehingga semuanya ditransfer dari pilot ke sirkuit target secepat mungkin. Semua sistem diterapkan dalam konfigurasi yang toleran terhadap kesalahan (di mana kemampuan ini tidak dibatasi oleh kebijakan lisensi vendor) dan terhubung ke metrik dan subsistem pengumpulan peristiwa. IB menganalisis kepatuhan terhadap persyaratannya dan memberikan lampu hijau.

tahap 3. Migrasi semua subsistem dan pengaturannya ke PAC baru. Skrip otomatisasi infrastruktur ditulis ulang, dan migrasi subsistem DSO diselesaikan dalam mode otomatis penuh. Kontur pengembangan IP diciptakan kembali oleh jalur tim pengembangan.

Langkah 4. Otomatisasi instalasi perangkat lunak aplikasi. Tugas-tugas ini ditetapkan oleh pimpinan tim dari tim baru.

Langkah 5. Eksploitasi.

Akses jarak jauh

Tim pengembangan meminta fleksibilitas maksimum dalam bekerja dengan sirkuit, dan persyaratan untuk akses jarak jauh dari laptop pribadi diajukan pada awal proyek. Bank sudah memiliki akses jarak jauh, tetapi tidak cocok untuk pengembang. Faktanya adalah skema tersebut menggunakan koneksi pengguna ke VDI yang dilindungi. Ini cocok bagi mereka yang hanya membutuhkan surat dan paket kantor di tempat kerja mereka. Pengembang membutuhkan klien besar, kinerja tinggi, dan sumber daya yang banyak. Dan tentu saja, mereka harus statis, karena hilangnya sesi pengguna bagi mereka yang bekerja dengan VStudio (misalnya) atau SDK lain tidak dapat diterima. Mengorganisir VDI statis tebal dalam jumlah besar untuk semua tim pengembangan sangat meningkatkan biaya solusi VDI yang ada.

Kami memutuskan untuk mengerjakan akses jarak jauh langsung ke sumber daya di segmen pengembangan. Jira, Wiki, Gitlab, Nexus, membangun dan menguji bangku, infrastruktur virtual. Penjaga keamanan menuntut agar akses hanya dapat diberikan dengan ketentuan sebagai berikut:

1. Menggunakan teknologi yang sudah tersedia di bank.
2. Infrastruktur tidak boleh menggunakan pengontrol domain yang ada yang menyimpan catatan objek akun produktif.
3. Akses harus dibatasi hanya pada sumber daya yang diperlukan oleh tim tertentu (sehingga satu tim produk tidak dapat mengakses sumber daya tim lain).
4. Kontrol maksimum atas RBAC dalam sistem.

Hasilnya, domain terpisah dibuat untuk segmen ini. Domain ini menampung semua sumber daya segmen pengembangan, baik kredensial pengguna maupun infrastruktur. Siklus hidup record di domain ini dikelola menggunakan IdM yang ada di bank.

Akses jarak jauh langsung diatur berdasarkan peralatan bank yang ada. Kontrol akses dibagi menjadi beberapa grup AD, yang sesuai dengan aturan konteksnya (satu grup produk = satu grup aturan).

Manajemen Templat VM

Kecepatan pembuatan loop perakitan dan pengujian adalah salah satu KPI utama yang ditetapkan oleh kepala unit pengembangan, karena kecepatan persiapan lingkungan secara langsung mempengaruhi waktu eksekusi keseluruhan pipeline. Dua opsi untuk menyiapkan image VM dasar telah dipertimbangkan. Yang pertama adalah ukuran gambar minimum, default untuk semua produk sistem, kepatuhan maksimum terhadap kebijakan bank mengenai pengaturan. Yang kedua adalah gambar dasar, yang berisi POPPO tugas berat yang terpasang, yang waktu pemasangannya dapat sangat mempengaruhi kecepatan eksekusi pipeline.

Persyaratan infrastruktur dan keamanan juga diperhitungkan selama pengembangan - menjaga gambar tetap terkini (tambalan, dll.), integrasi dengan SIEM, pengaturan keamanan sesuai dengan standar bank.

Oleh karena itu, diputuskan untuk menggunakan gambar minimal untuk meminimalkan biaya untuk selalu memperbaruinya. Jauh lebih mudah untuk memperbarui OS dasar daripada menambal setiap gambar untuk versi POPPO yang baru.

Berdasarkan hasil, daftar kumpulan sistem operasi minimum yang diperlukan dibentuk, yang diperbarui oleh tim operasi, dan skrip dari pipeline sepenuhnya bertanggung jawab untuk memperbarui perangkat lunak, dan jika perlu, mengubah versinya. dari perangkat lunak yang diinstal - cukup transfer tag yang diperlukan ke pipeline. Ya, hal ini mengharuskan tim produk pengembang untuk memiliki skenario penerapan yang lebih kompleks, namun hal ini sangat mengurangi waktu operasional yang diperlukan untuk mendukung citra dasar, yang mungkin memerlukan lebih dari seratus citra VM dasar untuk dipelihara.

Akses internet

Batu sandungan lain dalam keamanan perbankan adalah akses terhadap sumber daya Internet dari lingkungan pengembangan. Selain itu, akses ini dapat dibagi menjadi dua kategori:

1. Akses infrastruktur.
2. Akses pengembang.

Akses infrastruktur diatur dengan memproksi repositori eksternal dengan Nexus. Artinya, akses langsung dari mesin virtual tidak disediakan. Hal ini memungkinkan untuk mencapai kompromi dengan keamanan informasi, yang secara kategoris menentang pemberian akses apa pun ke dunia luar dari segmen pembangunan.

Pengembang memerlukan akses ke Internet karena alasan yang jelas (stackoverflow). Dan meskipun semua perintah, seperti disebutkan di atas, memiliki akses jarak jauh ke sirkuit, hal ini tidak selalu nyaman bila Anda tidak dapat melakukan ctrl+v dari tempat kerja pengembang di bank di IDE.

Kesepakatan dicapai dengan IS yang pada awalnya, pada tahap pengujian, akses akan diberikan melalui proxy perbankan berdasarkan daftar putih. Setelah proyek selesai, akses akan dialihkan ke daftar hitam. Tabel akses besar telah disiapkan, yang menunjukkan sumber daya utama dan repositori yang memerlukan akses pada awal proyek. Koordinasi akses-akses ini memakan banyak waktu, sehingga memungkinkan dilakukannya transisi secepat mungkin ke daftar hitam.

Temuan

Proyek ini berakhir kurang dari setahun yang lalu. Anehnya, semua kontraktor beralih ke tumpukan baru tepat waktu dan tidak ada yang keluar karena otomatisasi baru. IB tidak terburu-buru memberikan tanggapan positif, namun juga tidak mengeluh, sehingga kami dapat menyimpulkan bahwa mereka menyukainya. Konflik mereda karena keamanan informasi kembali terasa terkendali, namun tidak mengganggu proses pembangunan. Tim diberi tanggung jawab lebih besar, dan sikap keseluruhan terhadap keamanan informasi menjadi lebih baik. Bank memahami bahwa transisi ke DevSecOps hampir tidak bisa dihindari, dan menurut pendapat saya, bank melakukannya dengan cara yang paling lembut dan benar.

Alexander Shubin, arsitek sistem.

Sumber: www.habr.com