Proses atau alat apa yang memungkinkan Pemisahan Tugas ketika para insinyur menggunakan dan menjalankan kode?

Dalam lingkungan yang sangat diatur, seperti sektor Jasa Keuangan, Pemisahan Tugas merupakan mekanisme penting untuk menghindari tabrakan di antara individu dengan tanggung jawab pembangunan dan hak istimewa produksi.

Secara tradisional ini berarti bahwa Pengembang mengembangkan kode dan kemudian menyerahkannya ke Operasi namun dalam banyak Model Pengoperasian DevOps pemisahan antara Pengembangan dan Operasi, minimal, kabur:

• Dalam Rekayasa Keandalan Situs Google , atau SRE, praktikkan ada fungsi SRE terpisah di Google, namun, Pengembang diminta untuk mendukung SRE di saat beban operasional tinggi.

• Dalam model "Anda Membangunnya, Anda Menjalankannya" tidak ada fungsi operasi terpisah.

Setelah menghabiskan berbulan-bulan menelusuri sampai ke akar penyebab mekanisme Pemisahan Tugas, tampaknya ini ada untuk memuaskan Sarbanes Oxley Bagian 404 : Penilaian Manajemen Pengendalian Internal:

(a) Diperlukan Aturan. Komisi akan menetapkan aturan yang mensyaratkan setiap laporan tahunan yang disyaratkan oleh bagian 13 (a) atau 15 (d) dari Undang-Undang Bursa Efek tahun 1934 untuk memuat laporan pengendalian internal, yang harus--

(1) menyatakan tanggung jawab manajemen untuk menetapkan dan memelihara struktur dan prosedur pengendalian internal yang memadai untuk pelaporan keuangan; dan

(2) berisi penilaian, pada akhir tahun fiskal terbaru dari penerbit, dari efektivitas struktur pengendalian internal dan prosedur penerbit untuk pelaporan keuangan.

(B) Evaluasi dan Pelaporan Kontrol Internal. Pada penilaian pengendalian internal yang disyaratkan oleh ayat (a), setiap kantor akuntan publik terdaftar yang menyiapkan atau menerbitkan laporan audit untuk penerbit harus membuktikan, dan melaporkan, penilaian yang dilakukan oleh manajemen penerbit. Pengesahan yang dibuat berdasarkan ayat ini harus dibuat sesuai dengan standar untuk pengikatan pengesahan yang dikeluarkan atau diadopsi oleh Dewan. Pengesahan semacam itu tidak akan menjadi subjek perjanjian terpisah.

Berdasarkan komentar, penting untuk memanggil beberapa asumsi yang saya buat:

• Saya terutama mempertimbangkan layanan keuangan pasar massal, yaitu volume transaksi tinggi tetapi nilainya relatif rendah. Ini akan bertentangan dengan layanan keuangan komersial yang memiliki profil nilai transaksi yang berbeda.
• Penawaran online lembaga keuangan akan terdiri dari banyak komponen yang memiliki pertimbangan risiko berbeda:
  • Pindahkan Uang - Memindahkan uang antar akun atau transfer antar akun dari pemilik yang berbeda. Satu operasi yang harus mempertimbangkan negara-negara Anti Pencucian Uang, Penipuan, dan Embargo untuk menyebutkan beberapa.
  • Akuisisi Pelanggan - Lebih sedikit "Berisiko" karena memiliki volume transaksi yang rendah dibandingkan dengan Uang Bergerak tetapi masih perlu dipertimbangkan.
  • Internet Banking - Meliputi berbagai layanan dengan berbagai tingkat risiko, Pindah Uang akan dianggap bagian dari ini.
• Dapat dibayangkan suatu pendekatan yang berbeda dapat diambil untuk masing-masing tergantung pada risikonya, namun, demi menjaga kesederhanaannya, saya bekerja menuju solusi yang akan diterapkan pada beberapa operasi paling berisiko.

TL; DR : Merupakan tanggung jawab manajemen untuk memastikan bahwa kontrol internal yang memadai telah sesuai dengan peraturan Komisi Sekuritas dan Bursa .

Sarbanes Oxley 404 biasanya puas melalui penyelesaian Top-Down Risk Assessment, yang sebagian akan menilai risiko kolusi dan mengedepankan strategi mitigasi.

Dalam sebuah perusahaan yang menggunakan praktik dan budaya DevOps, di mana Pengembang secara rutin memiliki akses ke kontrol sumber dan produksi bagaimana Segregasi Tugas dapat dicapai, atau lebih umum bagaimana risiko kolusi dapat dikurangi.

Pertanyaan Anda sepertinya tidak membuat asumsi tentang platform / OS tentang hal itu. Itulah sebabnya mengapa masuk akal untuk menambahkan jawaban tentang bagaimana hal ini biasanya dilakukan / ditangani dalam lingkungan mainframe, di mana "insinyur" (seperti dalam judul pertanyaan Anda) sebenarnya adalah sekelompok orang yang berpuluh-puluh (mungkin ratusan) orang terlibat. Jawaban saya didasarkan pada penggunaan produk SCM yang paling saya kenal (tidak yakin apakah perlu mengungkapkan nama produk).

---

1. Arsitektur

---

Berikut adalah hal-hal penting tentang bagaimana saya akan menjawab pertanyaan Anda:

• Semua kode (dan artefak terkait seperti executable, dll) disimpan dalam file yang, bersama-sama adalah apa yang kita sebut struktur pustaka .
• Untuk setiap lingkungan pada setiap sistem target (mungkin jarak jauh), ada server ("tugas yang dimulai" di mainframe berbicara), yang menangani SEMUA (ulangi: SEMUA) pembaruan untuk apa pun dalam struktur perpustakaan. Ada beberapa pengecualian (seperti petugas keamanan, atau tim manajemen ruang), tetapi selain itu, tidak ada (ulangi: tidak ada) yang memiliki otorisasi untuk menerapkan pembaruan ke file apa pun dalam struktur perpustakaan itu. Dengan kata lain: server mendapatkan otoritas pembaruan eksklusif untuk seluruh struktur perpustakaan . Perhatian: OPS-orang akan menjadi gila jika Anda masuk untuk membatasi akses mereka (pada awalnya mereka akan menolak ...), jadi pastikan Anda dilindungi oleh manajemen atas (CxO) untuk memaksakan aturan akses tersebut ...
• Perangkat lunak yang sebenarnya mengubah saya terdiri dari satu komponen (perbaikan kode kecil di tengah malam ...), atau mungkin juga ratusan atau ribuan sumber, dapat dieksekusi, atau apa pun artefak lainnya (selama akhir pekan rilis). Untuk membuatnya mudah dikelola, hal-hal yang harus dipindahkan (kurang lebih) bersamaan, pada saat bersamaan, digabungkan menjadi satu dalam apa yang disebut paket perubahan perangkat lunak .

Dengan hal tersebut di atas, segala jenis pembaruan yang diterapkan oleh server ke struktur perpustakaan, hanya akan dimungkinkan melalui alur kerja yang terdefinisi dengan baik, yang kami sebut siklus hidup paket perubahan perangkat lunak (SDLC jika Anda mau). Untuk benar-benar menjalankan berbagai langkah dalam alur kerja itu, inilah yang diperlukan untuk mewujudkannya:

• Hanya server yang akan menjalankan langkah-langkah yang diperlukan (dan sudah dikonfigurasikan).
• Server hanya akan melakukan langkah tertentu (= memperbarui sesuatu di suatu tempat dalam struktur perpustakaan), setelah persetujuan yang diperlukan (dari manusia) dikumpulkan untuk melakukan langkah tersebut.
• Persetujuan hanya dapat diberikan oleh pengguna yang memiliki peran yang memungkinkan mereka (= izin) untuk mengeluarkan persetujuan tersebut.

---

2. Peran dan izin

---

Server akan memastikan bahwa pengguna yang mencoba membuat sesuatu terjadi (seperti 'menyetujui sesuatu') hanya akan dapat melakukannya, jika izin pengguna sesuai. Bagian itu mudah. Tetapi Anda tidak ingin menggunakan sistem SCM untuk mengelola semua izin itu untuk semua pengguna yang terlibat, itulah yang termasuk dalam sistem keamanan Anda (bukan sistem SCM!), Sehingga Anda dapat menyesuaikan alur kerja Anda (dalam sistem SCM Anda) untuk pergi memeriksa izin tersebut kapan saja sesuai. Langkah-langkah di bawah ini memberikan beberapa detail lebih lanjut tentang itu.

Langkah 1: Konfigurasikan izin (dalam sistem keamanan)

• Tetapkan entitas keamanan dalam sistem keamanan Anda, dengan nama yang didefinisikan dengan baik untuk entitas tersebut. Beberapa sampel (tambahkan sebanyak mungkin yang serupa dengan kebutuhan Anda sendiri):

  • PrmUnit, digunakan untuk mendapatkan izin untuk meminta Promosi untuk mengatakan Unit -testing.
  • PrmQA, Digunakan untuk mendapatkan izin untuk meminta Promosikan mengatakan Qa -Ujilah (mari kita menganggap ini adalah tingkat tertinggi dari pengujian).
  • PrdEnduser, digunakan oleh pengguna akhir yang terlibat dalam beberapa tingkat pengujian, untuk menunjukkan bahwa mereka puas dengan hasil yang dihasilkan oleh beberapa jenis pengujian. Dan karena itu, para pengguna akhir setuju dengan perubahan yang bergerak maju dalam struktur perpustakaan.
  • PrdRelmgnt, digunakan oleh manajer rilis untuk mengesahkan Aktivasi dalam produksi (= level terakhir / tertinggi dalam struktur perpustakaan).

• Tentukan grup pengguna di sistem keamanan Anda. Beberapa sampel (tambahkan sebanyak mungkin yang serupa dengan kebutuhan Anda sendiri):

  • GrpDevs, yang (misalnya) sesuai dengan pengembang Anda (mungkin lebih dari hanya 1).
  • GrpEnduser, yang (misalnya) sesuai dengan pengguna akhir Anda (setidaknya 1, lebih disukai dengan pengguna yang lebih mirip).
  • GrpRelMgnt, yang (misalnya) sesuai dengan manajer rilis Anda (setidaknya 1, lebih disukai beberapa pengguna).

• Berikan izin , juga menggunakan sistem keamanan Anda, untuk memungkinkan akses ke " entitas keamanan " yang dipilih untuk " grup pengguna " yang dipilih. Untuk melanjutkan contoh di atas, inilah yang tampaknya cocok (sesuaikan dengan kebutuhan Anda):

  • Grup GrpDevsmendapat akses ke entitas keamanan (hanya!) PrmUnit.
  • Grup GrpEndusermendapat akses ke entitas keamanan (hanya!) PrdEnduser.
  • Grup GrpRelMgntmendapat akses ke entitas keamanan (keduanya!) PrmQADan PrdRelmgnt.

Langkah 2: Konfigurasikan alur kerja (dalam sistem SCM)

Setelah izin dikonfigurasikan dalam sistem keamanan Anda (seperti pada Langkah 1), yang tersisa untuk dilakukan dalam sistem SCM Anda adalah mengonfigurasi bagaimana berbagai langkah dalam siklus hidup cocok dengan entitas keamanan terkait di sistem keamanan Anda. Artinya, hanya pengguna yang memiliki akses yang sesuai ke entitas keamanan yang diperlukan, diizinkan untuk meminta server untuk melakukan langkah yang sesuai dalam alur kerja.

Berikut adalah beberapa contoh bagaimana Anda mengkonfigurasi sistem SCM Anda untuk membuat keajaiban terjadi:

• Jika pengguna memiliki akses ke PrmUnit, maka pengguna tersebut diperbolehkan untuk meminta Promosi ke Unit -testing. Jelas, pengguna dalam grup GrpDevsadalah pengguna yang diotorisasi untuk ini (catatan: tidak, misalnya, pengguna dalam grup GrpRelMgnt).
• Jika pengguna memiliki akses ke PrmQA, maka pengguna tersebut diizinkan untuk meminta Promosi ke QA -testing. Jelas, pengguna dalam grup GrpRelMgntadalah pengguna yang diotorisasi untuk ini (catatan: tidak, misalnya, pengguna dalam grup GrpDevs, atau dalam grup GrpEnduser).
• Jika pengguna memiliki akses ke PrdEnduser, maka pengguna tersebut diizinkan untuk mengotorisasi perubahan yang bergerak maju dalam struktur perpustakaan (yang biasanya merupakan prasyarat bagi pengguna dalam grup GrpRelMgntbahkan untuk dapat meninjau perubahan). Jelas, pengguna dalam grup GrpEnduseradalah (hanya) pengguna yang diotorisasi untuk ini.
• Jika pengguna memiliki akses ke PrdRelmgnt, maka pengguna tersebut diizinkan untuk mengotorisasi Aktivasi dalam produksi (= level terakhir / tertinggi dalam struktur perpustakaan).

---

3. Harapkan yang tak terduga, dan bersiaplah untuk itu

---

Di atas hanyalah cetak biru, yang semoga membantu untuk memahami bagaimana pada akhirnya itu adalah server yang menangani pemisahan tugas ... asalkan Anda memiliki CxO yang melindungi Anda untuk menerapkan beberapa aturan akses yang tidak semua orang akan suka.

Untuk melengkapi gambar seperti yang dijelaskan di atas, server membuat jejak audit (logging) dari segala sesuatu yang terjadi di sistem. Sehingga pada suatu titik waktu, selalu mungkin untuk menjawab pertanyaan seperti

Apa yang terjadi kapan dan mengapa, dan pengguna resmi mana yang benar-benar menyetujuinya ... dimuka?

Tapi, mungkin bagian terberat adalah memiliki alat pelaporan yang memadai (dan tahu cara menggunakannya). Setidaknya untuk (dengan mudah) memenuhi permintaan dari auditor TI (pertanyaan mereka bisa sangat menantang). Tetapi juga untuk menunjuk ke catatan log yang relevan dalam sistem SCM Anda untuk menjawab semua jenis "Apa yang terjadi" - pertanyaan dalam situasi krisis di mana (bagian dari) produksi turun.

---

PS: Saya serahkan pada penilaian semua orang jika jawaban saya ya atau tidak sesuai dengan DevOps.

Jawaban berdasarkan pada pengetahuan saya tentang peraturan "Kontrol internal" dalam bahasa Perancis, sejenis dengan peraturan SEC yang Anda tunjukkan, saya berasumsi bahwa menghubungkan di sini dengan teks hukum Prancis tidak akan benar-benar berguna dan saya tahu tidak ada terjemahan yang baik untuknya.

Dalam model 'Anda membangunnya, Anda menjalankannya' yang ideal, semua orang di tim akan bertanggung jawab atas perubahan tersebut. Penilaian risiko tidak dapat ditegakkan dengan pemisahan tugas dan satu-satunya cara saya tahu untuk tetap mematuhi peraturan adalah dengan melakukan audit siklus pendek secara berkala bersama dengan pelacakan tindakan yang tidak dapat diubah untuk kembali ke orang yang melakukan rilis .
Ini berarti semua log transaksi dan tindakan didorong ke area terbatas yang tidak dapat diakses oleh tim, perubahan dalam apa yang dicatat "harus" ditangkap oleh tes fungsional yang tidak dapat diakses oleh tim dan yang lebih buruk akan ditangkap oleh audit dan dilacak ke penulisnya.

Ini tidak berlaku untuk semua produk, pada saat penulisan di Perancis perusahaan mana pun yang diizinkan untuk mengeluarkan uang (terutama bank), harus memastikan setiap transaksi akan dicatat dan dengan demikian tidak dapat mengambil risiko kehilangan transaksi.
Di sisi lain, mereka tidak memiliki kewajiban hukum untuk melacak penawaran komersial atau evaluasi risiko ketika seseorang meminta pinjaman, dan dengan demikian produk yang menangani pemilihan pelanggan ini dan menghitung biaya yang akan ditawarkan lebih mudah untuk dimasukkan ke dalam pos. Model audit -release

Gagasan utama adalah bahwa model rilis harus disesuaikan sesuai dengan kewajiban penilaian risiko.

Sumber daya terkait adalah norma ISO27001 .

IMHO, Pengembang & Operasi dapat diwakili oleh tidak lebih dari dua repositori git untuk basis kode yang sama , masing-masing dengan model izin yang berbeda, sehingga tim tidak akan ikut campur dalam pekerjaan satu sama lain, sama sekali.

Sebut saja mereka Dev.mygithub.co & ops.mygithub.co , hanya sebagai contoh.

Idenya adalah, bahwa Pengembang bebas untuk membuat / bercabang / menggabungkan ke isi hati mereka - git menyediakan penelusuran penuh dan itulah yang penting di sini - sementara itu, pada saat-saat kerangka peraturan menyiratkan upaya peninjauan, Permintaan Tarik dapat diajukan, untuk penggabungan terjadi secara terkendali.

Dengan membawa konsep itu ke tingkat berikutnya, cabang pengembangan dapat diperbanyak menuju produksi Ops jarak jauh melalui tindakan Tarik Permintaan lainnya . Bagian terakhir itu harus terjadi oleh tangan dan mata operasi, karena mereka memiliki tanggung jawab untuk memeriksanya menjadi produksi dan mereka memilih tingkat tinjauan.

Skema semacam itu memungkinkan fleksibilitas tak terbatas, keterlacakan penuh, kemampuan untuk menangkap masalah sejak dini melalui berbagai proses, pemisahan kekhawatiran dan pengalaman pengguna yang sangat masuk akal dalam proses !

NB Model yang dijelaskan di atas dapat diikuti bahkan jika Ops & Dev tumpang tindih total!

lebih tinggi lebih mahal:

• situs pengembang dan metode yang berbeda untuk melakukan pekerjaan dari satu ke yang lain
• sistem & metode dev dan ops berbeda seperti di atas
• repositori dev dan ops git / vcs yang berbeda & metode terkait
• cabang dev dan ops git / vcs yang berbeda (dilindungi) & metode terkait

Bergantung pada apa yang Anda lakukan, beberapa solusi lebih baik daripada yang lain, misalnya jika Anda memiliki kebutuhan untuk melayani dua tim dengan peran yang berbeda di dalamnya dan masing-masing memiliki kepemilikan di dalam dan memberikan penelusuran penuh, Anda berada di atas tiga yang pertama.

Singkatnya, apa pun yang memberlakukan bahwa seorang pria atau wanita tidak bisa mengambil bola sendirian dan menjalankannya, dan ia melintasi batas eksplisit yang berbeda di antara para pengembang. Sekarang, tergantung pada tingkat risiko, batas itu mungkin ditegakkan atau tidak.