🌳 😵 🕵🏾 DevOps vs DevSecOps: tampilannya di satu bank 🏐 🤑 👸🏻

Bank mengalihkan proyeknya ke banyak kontraktor. "Orang luar" tulis kode itu, kemudian kirimkan hasilnya dalam bentuk yang tidak nyaman. Secara khusus, prosesnya terlihat seperti ini: mereka mentransfer sebuah proyek yang lulus tes fungsional dari mereka, dan kemudian sudah diuji dalam perimeter perbankan untuk integrasi, memuat, dan sebagainya. Seringkali ditemukan bahwa tes itu gagal. Kemudian semuanya kembali ke pengembang eksternal. Seperti yang bisa Anda tebak, ini berarti waktu yang lama untuk memperbaiki kesalahan.

Bank memutuskan bahwa adalah mungkin dan perlu untuk menyeret seluruh pipa ke dirinya sendiri "di bawah sayap" dari komitmen untuk melepaskan. Sehingga semuanya konsisten dan di bawah kendali tim yang bertanggung jawab atas produk di bank. Artinya, seolah-olah kontraktor eksternal hanya bekerja di suatu tempat di kamar sebelah kantor. Di tumpukan perusahaan. Ini adalah devopa biasa.

Dari mana Sec berasal? Keamanan Bank telah menetapkan tuntutan tinggi tentang bagaimana kontraktor eksternal dapat bekerja di segmen jaringan, siapa yang memiliki akses, bagaimana dan siapa yang bekerja dengan kode tersebut. Hanya saja IB belum tahu bahwa ketika kontraktor bekerja di luar, sedikit standar perbankan yang dihormati. Dan di sini dalam beberapa hari semua orang perlu mulai mengamati mereka.

Satu wahyu sederhana bahwa kontraktor memiliki akses penuh ke kode produk telah mengubah dunianya.

Pada saat itu, kisah DevSecOps dimulai, yang ingin saya ceritakan.

Bank mana yang membuat kesimpulan praktis dari situasi ini

Ada banyak kontroversi tentang kenyataan bahwa segala sesuatu yang dilakukan di bola salah. Pengembang mengatakan bahwa keamanan hanya sibuk dengan upaya untuk menghambat pembangunan, dan mereka, sebagai penjaga, mencoba untuk melarang tanpa berpikir. Pada gilirannya, penjaga keamanan ragu-ragu antara memilih antara sudut pandang: "pengembang menciptakan kerentanan di sirkuit kami" dan "pengembang tidak membuat kerentanan, tetapi mereka sendiri." Debat akan berlangsung untuk waktu yang lama, jika bukan karena persyaratan pasar baru dan munculnya paradigma DevSecOps. Dimungkinkan untuk menjelaskan bahwa proses otomasi ini dengan mempertimbangkan persyaratan keamanan informasi "out of the box" akan membantu setiap orang untuk merasa puas. Dalam arti bahwa aturan ditulis segera dan tidak berubah selama pertandingan (IS tidak akan melarang sesuatu yang tidak terduga), dan pengembang tetap mendapat informasi tentang segala sesuatu yang terjadi (IS tidak menemukan sesuatu yang tiba-tiba).Setiap tim bertanggung jawab atas keselamatan tertinggi, dan bukan beberapa kakak lelaki yang abstrak.

, , « ».
, , .
- , . , . .

Artinya, kontraktor dapat diizinkan, tetapi Anda harus membuatnya menjadi segmen yang terpisah. Sehingga mereka tidak menyeret keluar semacam infeksi ke dalam infrastruktur bank dan mereka tidak melihat lebih dari yang diperlukan. Nah, agar tindakan mereka dicatat. DLP untuk perlindungan terhadap "tenggelam", semua ini diterapkan.

Pada prinsipnya, semua bank datang ke ini cepat atau lambat. Kemudian kami keluar jalur dan menyepakati persyaratan untuk lingkungan seperti itu di mana "orang luar" bekerja. Muncul satu set maksimum alat kontrol akses, checker kerentanan, analisis antivirus di sirkuit, rakitan dan tes. Inilah yang mereka sebut DevSecOps.

Tiba-tiba menjadi jelas bahwa jika sebelum keamanan perbankan DevSecOps ini 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. Hanya sekarang ada peringatan tentang majelis, kontrol perpustakaan, dan sebagainya.

Tinggal memindahkan tim ke model baru. Nah, buat infrastruktur. Tapi ini hal-hal kecil, ini cara menggambar burung hantu. Sebenarnya, kami membantu dengan infrastruktur, dan saat ini proses pembangunan berubah.

Apa yang berubah?

Mereka memutuskan untuk menerapkannya dalam langkah-langkah kecil, karena mereka menyadari bahwa banyak proses akan berantakan, dan banyak "orang luar" mungkin tidak dapat menahan kondisi kerja baru di bawah pengawasan semua orang.

Pertama, kami membuat tim lintas fungsi dan belajar bagaimana mengatur proyek dengan mempertimbangkan persyaratan baru. Dalam hal diskusi organisasi, proses apa. Ternyata pipa perakitan dengan semua yang bertanggung jawab.

CI: Git, Jenkins, Maven, Roslyn, Gradle, jUnit, Jira, MF Fortify, CA Harvest, GitlabCI.
CD: Ansible, Wayang, TeamCity, Gitlab TFS, Liquidbase.
Uji: Sonarqube, SoapUI, jMeter, Selenium: MF Fortify, Pusat Kinerja, MF UFT, Atascama.
Presentasi (pelaporan, komunikasi): Grafana, Kibana, Jira, Confluence, RocketChat.
Operasi : Ansible, Zabbix, Prometheus, Elastic + Logstash, Manajer Layanan MF, Jira, Confluence, Proyek MS.

Tumpukan yang dipilih:

Basis Pengetahuan - Atlassian Confluence;
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 Mattermost”;
Sistem Manajemen Konfigurasi - “Ansible”;
Sistem pemantauan - "ELK", "TICK Stack" ("InfluxData").

Mereka mulai membuat tim yang siap untuk menarik kontraktor. Kesadaran telah datang bahwa ada beberapa hal penting:

. — . , .
, . — , .

Untuk mengambil langkah pertama, Anda harus memahami apa yang sedang dilakukan. Dan kami harus menentukan bagaimana melanjutkannya. Kami mulai dengan membantu menggambar arsitektur solusi target, baik dalam infrastruktur maupun dalam otomatisasi CI / CD. Kemudian kami mulai memasang conveyor ini. Kami membutuhkan satu infrastruktur, yang sama untuk semua orang, di mana conveyor yang sama akan berjalan. Kami menawarkan opsi dengan penyelesaian, pikir bank, kemudian membuat keputusan tentang apa dan apa artinya itu akan dibangun.

Selanjutnya pembuatan sirkuit - instalasi perangkat lunak, konfigurasi. Pengembangan skrip untuk infrastruktur dan manajemen penempatan. Berikutnya adalah transisi ke dukungan saluran pipa.

Kami memutuskan untuk menjalankan semuanya dengan pilot. Menariknya, selama uji coba, tumpukan tertentu muncul di bank untuk pertama kalinya. Antara lain, vendor domestik salah satu solusi untuk peluncuran awal diusulkan untuk volume pilot. Keselamatan mengenalnya selama uji coba, dan ini meninggalkan pengalaman yang tak terlupakan. Ketika mereka memutuskan untuk beralih, untungnya, lapisan infrastruktur digantikan oleh solusi nutanix yang sudah ada di bank sebelumnya. Dan sebelum itu untuk VDI, dan kami menggunakannya kembali untuk layanan infrastruktur. Pada volume kecil, itu tidak cocok dengan ekonomi, tetapi pada volume besar itu menjadi lingkungan yang sangat baik untuk pengembangan dan pengujian.

Sisa tumpukan lebih atau kurang akrab bagi semua orang. Alat otomatisasi di bagian Ansible digunakan, dan penjaga keamanan bekerja sama dengan mereka. Tumpukan Atlassinovsky digunakan oleh bank sebelum proyek. Fortinet Security Tools - Diusulkan oleh penjaga keamanan sendiri. Kerangka pengujian dibuat oleh bank, tidak ada pertanyaan. Pertanyaan disebabkan oleh sistem repositori, saya harus membiasakan diri dengannya.

Kontraktor diberi tumpukan baru. Mereka memberi waktu untuk menulis ulang di bawah GitlabCI, dan untuk memigrasi Jira ke segmen bank dan sebagainya.

Selangkah demi selangkah

Tahap 1. Pertama, kami menggunakan solusi dari vendor domestik, produk dialihkan ke segmen jaringan DSO yang baru dibuat. Platform dipilih untuk waktu pengiriman, skalabilitas, dan kemampuan otomatisasi penuh. Tes yang dilakukan:

Kemungkinan manajemen fleksibel dan sepenuhnya otomatis dari infrastruktur platform virtualisasi (jaringan, subsistem disk, subsistem sumber daya komputasi).
Otomasi manajemen siklus hidup mesin virtual (templating, snapshots, backup).

Setelah instalasi dan konfigurasi dasar platform, itu digunakan sebagai titik penempatan subsistem tahap kedua (alat DSO, garis besar pengembangan sistem ritel). Set pipa yang diperlukan diciptakan - membuat, menghapus, memodifikasi, membuat cadangan mesin virtual. Pipa-pipa ini digunakan sebagai tahap pertama dari proses penyebaran.

Hasil - peralatan yang disediakan tidak memenuhi persyaratan bank untuk kinerja dan toleransi kesalahan. DIT Bank memutuskan untuk membuat kompleks berdasarkan PAC Nutanix.

Tahap 2. Kami mengambil tumpukan yang ditentukan dan menulis skrip untuk instalasi otomatis dan pasca-konfigurasi untuk semua subsistem, sehingga semuanya akan ditransfer dari pilot ke sirkuit target secepat mungkin. Semua sistem dikerahkan dalam konfigurasi yang toleran terhadap kesalahan (di mana fitur ini tidak terbatas pada kebijakan berlisensi vendor), dan terhubung ke subsistem untuk mengumpulkan metrik dan acara. IB menganalisis kepatuhan dengan persyaratannya dan memberi lampu hijau.

Tahap 3 . Migrasi semua subsistem dan pengaturannya ke PAC baru. Skrip otomatisasi infrastruktur ditulis ulang, dan migrasi subsistem DSO dilakukan dalam mode yang sepenuhnya otomatis. Jalur pengembangan IS diciptakan kembali oleh jalur pipa tim pengembangan.

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

Tahap 5. Operasi.

Akses jarak jauh

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

Kami memutuskan untuk mencari akses jarak jauh langsung ke sumber daya segmen pengembangan. Jira, Wiki, Gitlab, Nexus, stan perakitan dan pengujian, infrastruktur virtual. Petugas keamanan telah menetapkan persyaratan bahwa akses hanya dapat diatur dengan ketentuan sebagai berikut:

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

Akibatnya, domain terpisah dibuat untuk segmen ini. Domain ini menampung semua sumber daya dari segmen pengembangan, baik kredensial pengguna dan infrastruktur. Siklus hidup catatan di domain ini dikelola menggunakan IdM yang ada di bank.

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

Kelola Template VM

Kecepatan membuat rangkaian perakitan dan pengujian adalah salah satu KPI utama yang ditetapkan oleh kepala unit pengembangan, karena kecepatan persiapan lingkungan secara langsung mempengaruhi keseluruhan waktu pelaksanaan pipa. Dua opsi untuk menyiapkan gambar VM dasar dipertimbangkan. Yang pertama adalah ukuran gambar minimum, standar untuk semua produk / sistem, kepatuhan maksimum dengan kebijakan bank untuk pengaturan. Yang kedua adalah gambar dasar yang berisi perangkat lunak / perangkat lunak kelas berat yang terinstal, waktu instalasi yang dapat sangat mempengaruhi kecepatan pipa.

Infrastruktur dan persyaratan keamanan juga diperhitungkan selama pengembangan - menjaga agar gambar tetap terbaru (tambalan, dll.), Integrasi dengan SIEM, pengaturan keamanan sesuai dengan standar yang diadopsi oleh bank.

Sebagai hasilnya, diputuskan untuk menggunakan gambar minimal untuk meminimalkan biaya pemeliharaannya. Jauh lebih mudah untuk memperbarui OS dasar daripada menginstal tambalan di setiap gambar untuk versi baru perangkat lunak / perangkat lunak.

Berdasarkan hasil, daftar dikompilasi dari set minimum yang diperlukan sistem operasi, yang pembaruannya dilakukan oleh tim operasi, dan skrip dari pipa bertanggung jawab penuh untuk memperbarui perangkat lunak / perangkat lunak, dan jika perlu, mengubah versi perangkat lunak yang diinstal cukup untuk mentransfer tag yang diinginkan ke pipa. Ya, ini membutuhkan skenario penyebaran tim produk devops'a yang lebih kompleks, tetapi sangat mengurangi waktu operasi untuk mendukung gambar dasar, yang dapat jatuh pada layanan lebih dari seratus gambar VM dasar.

Akses ke internet

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

Akses Infrastruktur.
Akses ke pengembang.

Akses infrastruktur diorganisasikan dengan proksi repositori eksternal oleh Nexus. Artinya, akses langsung dari mesin virtual tidak disediakan. Ini memungkinkan untuk berkompromi dengan IS, yang secara kategoris menentang menyediakan akses ke dunia luar dari segmen pengembangan.

Akses internet untuk pengembang diperlukan karena alasan yang jelas (stackoverflow). Dan meskipun semua tim, seperti yang disebutkan di atas, memiliki akses jarak jauh ke sirkuit, itu tidak selalu nyaman ketika Anda tidak dapat melakukan ctrl + v dari tempat kerja pengembang di bank di IDE.

Telah disepakati dengan IS bahwa pada awalnya, pada tahap pengujian, akses akan diberikan melalui proxy bank berdasarkan daftar putih. Di akhir proyek - akses akan ditransfer ke daftar hitam. Tabel akses besar disiapkan, yang menunjukkan sumber daya utama dan repositori yang membutuhkan akses pada awal proyek. Koordinasi dari akses-akses ini membutuhkan waktu yang cukup lama, yang memungkinkan kami untuk menuntut transisi tercepat ke daftar hitam.

hasil

Proyek ini berakhir sedikit kurang dari setahun yang lalu. Anehnya, tetapi semua kontraktor tepat waktu beralih ke tumpukan baru dan tidak ada yang pergi karena otomatisasi baru. IB tidak terburu-buru untuk membagikan ulasan positif, tetapi dia tidak mengeluh, dari mana kita dapat menyimpulkan bahwa mereka suka. Konflik mereda, karena IS lagi-lagi merasa kontrol, tetapi pada saat yang sama tidak mengganggu proses pengembangan. Tim mendapat lebih banyak tanggung jawab, dan secara umum, sikap terhadap keamanan informasi telah menjadi lebih baik. Bank memahami bahwa transisi ke DevSecOps hampir tidak dapat dihindari, dan menurut saya melakukannya dengan paling lembut dan benar.

Alexander Shubin, arsitek sistem.

DevOps vs DevSecOps: tampilannya di satu bank