it-swarm-id.com

Risiko memberi pengembang hak admin ke PC mereka sendiri

Saya perlu meyakinkan departemen TI internal saya untuk memberikan hak admin tim pengembang baru saya ke PC kami sendiri. Mereka tampaknya berpikir ini akan membuat beberapa risiko keamanan ke jaringan. Adakah yang bisa menjelaskan mengapa ini terjadi? Apa risikonya? Apa yang biasanya diatur oleh departemen TI untuk pengembang yang membutuhkan kemampuan untuk menginstal perangkat lunak pada PC mereka.

Pertanyaan ini adalah Pertanyaan Keamanan IT Minggu Ini.
Baca 8 Juni 2012 entri blog untuk lebih jelasnya atau kirim milik Anda sendiri Pertanyaan dalam Pekan.

78
carolineggordon

Di setiap tempat saya telah bekerja (sebagai pengembang kontrak), pengembang diberikan hak admin lokal di desktop mereka.

Alasannya adalah:

1) Perkakas pengembang sering dimutakhirkan dengan sangat teratur. Perpustakaan grafik, pembantu kode, pembaruan studio visual; mereka akhirnya memiliki pembaruan hampir setiap minggu yang perlu diinstal. Dukungan desktop biasanya sangat lelah mendapatkan 20 tiket setiap minggu untuk menginstal perangkat lunak yang diperbarui pada semua mesin dev sehingga mereka hanya memberikan hak admin pengembang untuk melakukannya sendiri.

2) Alat Debugging/Pengujian kadang-kadang membutuhkan hak admin untuk dapat berfungsi. Tidak ada akses admin berarti pengembang tidak dapat melakukan kode debug mereka. Manajer tidak suka itu.

3) Pengembang cenderung lebih sadar akan keamanan dan karenanya cenderung menjalankan/menginstal malware berbahaya. Jelas, itu masih terjadi tetapi semua dalam semua pengembang biasanya dapat dipercaya untuk memiliki akses tingkat yang lebih tinggi untuk dapat melakukan pekerjaan mereka.

63
Alan Barber

Ini sebagian tergantung pada jenis perangkat lunak yang diharapkan dikembangkan oleh tim pengembang. Beberapa jenis perangkat lunak lebih mudah dikembangkan tanpa hak administratif daripada yang lain.

Misalnya, Anda dapat melakukan cukup banyak pengembangan berbasis web Java menggunakan Eclipse dengan artefak Maven, semuanya dipasang secara lokal (dan biasanya diuji pada port 8080), tanpa memerlukan banyak hak admin (Anda mungkin perlu membuka port tertentu). Mengembangkan alat-alat yang memerlukan akses lebih dekat ke perangkat keras mungkin terbukti tidak mungkin tanpa hak admin. Ini dikatakan, bahkan untuk pengembangan web, adalah praktik yang baik untuk dapat membangun kembali mesin uji dari awal ( biasanya VM), yang mungkin memerlukan hak admin.

Jika ini tentang kepercayaan (mis. Beberapa anggota tim dev Anda bisa memiliki niat jahat), Anda tetap dalam masalah. Tidak mungkin bahwa sysadmin yang akan menyetujui/menolak hak-hak tertentu akan dapat memeriksa kode apa yang mereka tulis secara rinci. Itu tidak berarti bahwa Anda harus memberikan akses kepada tim pengembang Anda tanpa batas ke layanan produksi Anda, atau bahwa mereka seharusnya memiliki akses admin pada lebih banyak mesin daripada yang mereka butuhkan, tentu saja. Ada baiknya memiliki mekanisme untuk mengurangi risiko, tetapi Anda membutuhkan tingkat kepercayaan dasar agar organisasi Anda berfungsi. Menempatkan tim pengembang di jaringan fisik yang terpisah adalah langkah pertama untuk mengurangi masalah kepercayaan dan kemungkinan kesalahan.

Risiko khas dengan meminta seseorang dengan akses admin adalah dapat menangkap paket di jaringan. Ini adalah risiko yang mungkin harus Anda terima tergantung pada sifat dari apa yang dikembangkan. Alat seperti Wireshark terkadang berguna untuk pengembangan. Bahkan di dalam organisasi Anda, orang-orang TI atau non-IT harus menggunakan layanan dengan SSL/TLS diaktifkan jika memungkinkan, ini akan membantu melawan serangan penyadapan dan MITM.

Saya dapat memikirkan beberapa kerugian ketika tidak memberikan akses admin devs (kecuali mereka benar-benar tidak membutuhkannya):

  • Ini dapat menciptakan budaya "mereka vs kita" antara devs dan sysadmin di organisasi Anda. Ini sudah ada di banyak tempat, tetapi umumnya bukan hal yang baik. Setiap tim cenderung menganggap yang lain sebagai rasa sakit. Keamanan bukanlah masalah teknis semata, tetapi interaksi manusia juga. Saya pikir komunikasi manusia yang baik harus membantu tujuan keseluruhan organisasi Anda secara umum, bukan hanya dari sudut pandang keamanan. (Saya selalu menemukan dapat menemukan solusi yang lebih baik setelah berbicara langsung kepada sysadmin dengan siapa saya perlu menyelesaikan masalah daripada membalas tiket tanpa wajah.)

  • Sifat manusia sedemikian rupa sehingga orang menjadi kreatif ketika terbatas, tetapi tidak harus dengan cara yang benar. Anda mungkin menemukan bahwa para dev akhirnya berakhir dengan upaya yang adil (dan sering berhasil) dalam menghindari batasan yang dikenakan pada mereka dalam organisasi. Mereka harus menggunakan kreativitas mereka pada apa yang seharusnya mereka lakukan.

  • Sistem TI rumit dan debugging adalah seni yang gelap. Jika Anda perlu men-debug produk Anda terhadap pustaka XYZ versi a.b.c_13 dan a.b.c_24, pengembang mungkin harus dapat menginstal dan menghapus instalasi setiap versi, yang pada gilirannya mungkin memerlukan akses admin. Mengejar bug yang tergantung pada nomor versi sudah menyebalkan. Jika Anda harus menaikkan tiket dan menunggu (mungkin berjam-jam atau berhari-hari) untuk orang lain menginstal/mencopot versi yang tepat akan menjadikannya mimpi buruk: itu akan meningkatkan masalah budaya "mereka vs kita" dan, yang lebih penting, biayanya lebih ke organisasi. Anda dapat memikirkan hal ini dari perspektif penilaian risiko/biaya.

28
Bruno

Risiko adalah peningkatan fungsi akses

Ada aturan sederhana perhitungan risiko yang menjelaskan rasa takut kolega Anda dari tim TI. Semakin banyak akses yang Anda miliki pada sistem operasi apa pun semakin tinggi dampak dari setiap kesalahan atau serangan.
Misalnya, jika salah satu kolega Anda, katakanlah Bob, diserang melalui serangan phishing standar, maka akun Bob tersedia untuk penjahat cyber dan dijual di Internet dalam beberapa menit. Jika akun Bob memiliki hak istimewa admin, maka akun ini akan digunakan untuk mengirim SPAM dalam skala besar di Internet, kemudian mencuri akun lain dengan serangan phishing dalam skala besar, dan dengan sangat cepat (dalam beberapa menit) akan membuka pintu belakang untuk Anda jaringan (ini dimungkinkan karena akun Bob adalah admin satu) yang memungkinkan kendali jarak jauh total PC Bob (melalui alat sebagai ssh, VNC, VPN...) . Serangan ini dimulai dari PC internal, dari akun yang memiliki hak istimewa dapat memecah firewall apa pun, menghentikan semua antivirus, perlindungan anti-spam.

Kejahatan ada di dalam.

Bahkan admin jaringan, admin sistem, atau admin keamanan terbaik Anda dapat membiarkan PC yang rusak ini tidak terlindungi selama berbulan-bulan (lih. Stuxnet).

Pengurangan risiko palsu

Jika rekan pengembangan Anda pandai mengelola OS di mana mereka bekerja, dan memiliki akses fisik ke komputer, maka perbedaan dalam risiko ini adalah nol.

Insinyur apa saja di OS apa pun
dapat memberikan dirinya sendiri akses admin
jika ia memiliki akses fisik ke komputer.

Memblokir akses admin pada OS apa pun adalah pendekatan pengurangan risiko yang valid untuk pengguna yang tidak dapat membuat perbedaan antara hak istimewa admin dan hak pengguna normal. Inilah pertanyaan kunci yang akan saya ajukan kepada rekan tim pengembang Anda dan bertindak berdasarkan kesadaran mereka akan risiko:

"Apa yang akan kamu tangani jika kamu diberikan
hak istimewa admin di OS Anda? "

Jika mereka cukup baik untuk sadar risiko, maka mereka cukup baik untuk mendapatkan akses yang mereka inginkan. Maka tidak ada pengurangan risiko dalam menolak mereka akses admin ini. Hati-hati: ada risiko agunan bagi perusahaan Anda secara keseluruhan jika Anda menolak mereka akses yang mereka dapat dengan mudah: mereka akan melakukannya dengan cara kotor, mereka akan bertindak sebagai penjahat, mereka tidak akan dapat meminta bantuan apa pun, mereka Saya harus menutup kecelakaan apa pun.

10
dan

Anda memberi mereka hak admin lokal ke stasiun kerja mereka dan apa pun yang mereka inginkan. Lingkungan pengembangan selalu terisolasi dari jaringan utama. Adalah tugas IT untuk memastikan Anda memberi mereka pengaturan apa pun yang mereka butuhkan sambil memastikan tidak ada apa pun di lingkungan pengembang yang dapat membahayakan jaringan utama. Rencanakan ke depan dan bekerja sama dengan manajemen untuk membeli peralatan/perangkat lunak yang Anda butuhkan untuk mencapai ini.

8
wrb

Beberapa hal yang belum disebutkan dalam jawaban dan komentar sebelumnya yang akan menjadi argumen bagi pengembang yang bekerja di bawah hak istimewa:

  1. Bergantung pada industri tempat Anda bekerja, mungkin ada alasan hukum atau peraturan yang membatasi karyawan untuk memiliki hak istimewa yang lebih tinggi di stasiun kerja mereka. Mengizinkan akses administratif ke pengembang dapat menempatkan organisasi dalam risiko tidak patuh.

  2. Ketika komponen dikembangkan dengan hak istimewa yang ditingkatkan, mungkin ada risiko kegagalan selama penempatan ke lingkungan lain yang tidak memiliki hak istimewa tersebut. Pengembang mungkin secara tidak sengaja meningkatkan atau menambahkan pustaka ke mesin lokal mereka yang tidak ada di lingkungan lain, dan komponen mungkin memiliki ketergantungan pada versi tertentu dari pustaka tersebut. Juga akun pengguna di mana komponen akan berjalan di lingkungan lain mungkin tidak memiliki database yang diperlukan atau akses lain yang diasumsikan oleh pengembang yang bekerja dengan hak istimewa yang ditinggikan. Saya telah melihat ini terjadi berkali-kali di masa lalu. Terkadang jelas mengapa penyebaran gagal, kadang tidak, dan Anda harus mengembalikan semuanya sampai Anda bisa mengetahuinya.

  3. Jika pengembang memasang alat atau pustaka sumber terbuka dan menggunakannya untuk pengembangan, mungkin ada pembatasan lisensi yang tidak disengaja tentang bagaimana perangkat lunak yang mereka hasilkan akhirnya didistribusikan, terutama di mana istilah "copyleft" adalah bagian dari lisensi. Tidak ada yang salah dengan menggunakan alat sumber terbuka atau perpustakaan, itu harus disengaja. Anda tidak ingin mengetahui setelah pengiriman bahwa Anda sekarang harus melepaskan semua kode sumber Anda kembali ke komunitas karena pengembang Anda menggunakan beberapa komponen sumber terbuka yang memiliki ketentuan copyleft yang ketat dalam lisensi yang mereka tidak benar-benar baca sebelum mereka menginstalnya.

Sesuatu yang telah saya lihat lakukan adalah membuat para pengembang bekerja di bawah hak istimewa paling tidak, tetapi memungkinkan mereka meminta hak istimewa yang ditingkatkan untuk jangka waktu tertentu. Kemudian, permintaan "panggilan api" ini untuk hak-hak tinggi yang direkam dan dipantau, dan diatur ulang secara otomatis pada akhir waktu yang diminta.

8
Todd Dill

Anda memiliki beberapa pertanyaan untuk dijawab.

  1. Aplikasi apa yang perlu digunakan oleh pengembang ini setiap hari membutuhkan hak admin dan apakah ada cara untuk mengatur aplikasi ini sehingga tidak demikian?
  2. Apa alasan pengembang ini memerlukan hak istimewa admin untuk melakukan tugas-tugas sepele sehari-hari dan apakah ada cara untuk menghindari ini?
  3. Apakah mesin pengembang ini terhubung ke internet?

Pertanyaannya seharusnya bukan apa risikonya, pertanyaannya harus (yang hanya bisa Anda jawab) apa alasan pengembang bahkan perlu memiliki akun admin. Anda dapat membuatnya dengan akun "pengguna daya" dan memberi mereka kemampuan untuk melakukan apa yang mereka butuhkan tetapi juga membatasi kemampuan mereka untuk membahayakan jaringan Anda.

Jika mesin-mesin ini terhubung ke internet .... maka Anda akan memperkenalkan sejumlah besar risiko karena kemampuan mereka untuk menjalankan apa pun dan menginstal apa pun di mesin-mesin ini. Pengembang ini adalah pengembang yang baik, mereka bukan pakar keamanan, hanya pertanyaan KAPAN mereka akan membuat kesalahan yang membuat jaringan terkena malware.

Lihatlah Google misalnya. Seorang karyawan Google mengklik tautan yang terkandung dalam jendela MSN Messenger, malware yang diunduh yang mengambil keuntungan dari eksploitasi yang telah diperbaiki oleh Microsoft, dan menginfeksi seluruh jaringan.

Saya harus menambahkan karyawan Google mengklik tautan tidak ada hubungannya dengan pertanyaan ini, itu menunjukkan, orang AKAN membuat kesalahan sehingga membatasi ekspos Anda.

4
Ramhound

Risiko keamanan yang terkait dengan menyediakan pengembang kemampuan untuk menginstal komputer mereka sangat banyak. Inilah mengapa saya akan keberatan (berbicara sebagai admin sys)

1) Potensi pelanggaran praktik keamanan terbaik - Salah satu dari 8 aturan keamanan adalah aturan yang paling tidak istimewa - hanya memberikan karyawan akses ke apa yang mereka butuhkan untuk menyelesaikan tugas mereka. Jika seseorang mengatakan kepada saya bahwa dev mereka memerlukan akses admin untuk menginstal perangkat lunak untuk melakukan pekerjaan mereka maka saya akan menjawab dengan "Mengapa salah satu staf saya tidak dapat menginstalnya untuk mereka?". Memiliki titik terpusat untuk menginstal perangkat lunak memastikan bahwa departemen TI tahu persis perangkat lunak apa pada mesin apa.

2) Alasan Hukum - Mungkin salah satu dev Anda memiliki Etika yang kurang mengagumkan dan memutuskan untuk menginstal perangkat lunak bajakan. Tidak hanya perangkat lunak yang mungkin penuh dengan malware, tetapi Anda kemudian dapat membuka cacing untuk litigasi jika Anda tertangkap dengan perangkat lunak bajakan di komputer Anda. Departemen TI dianggap bertanggung jawab atas komputer-komputer itu dan, karena itu, mereka bertanggung jawab untuk mengauditnya dan memastikan bahwa lisensi sesuai dengan TOS dari setiap perangkat lunak. Meskipun nyaman bagi pengembang karena mereka dapat menginstal perangkat lunak mereka sendiri dan tidak mengganggu departemen TI, Anda membuat lebih banyak pekerjaan untuk departemen TI.

3) Instalasi Malware yang tidak disengaja - disebutkan sebelumnya, tetapi ini bisa cukup tidak bersalah. Meningkatkan hak pengguna sehingga mereka dapat menginstal malware membuat mereka rentan terhadap malware dengan membuka PDF yang mereka dapatkan melalui email, atau drive melalui unduhan. Membatasi akses pengguna sehingga mereka tidak bisa menginstal perangkat lunak akan membantu mengurangi ancaman malware.

4) Aktivitas berbahaya - Serupa dengan poin 2, tetapi apa yang harus dikatakan bahwa salah satu dev Anda tidak akan menginstal pintu belakang atau dengan sengaja membuka ancaman keamanan lain di jaringan Anda. Anda akan terkejut betapa banyak profesional TI melakukan ini untuk membalas dendam jika mereka diberhentikan atau bos mereka membuat mereka kesal.

Secara keseluruhan, saya harus menyarankan untuk tidak melakukannya. Sementara orang mungkin berpendapat itu akan menghemat waktu dalam mencegah mereka dari selalu menyadap TI untuk menginstal perangkat lunak, saya akan melawan bahwa dengan "itu membutuhkan waktu lebih sedikit untuk melakukan itu daripada untuk menambal lubang keamanan yang dibuat dengan memungkinkan pengguna untuk menginstal perangkat lunak mereka sendiri" . Jika dianggap ini IS perlu, mereka harus benar-benar diletakkan di jaringan yang tidak memiliki akses langsung ke dunia luar.

4
DKNUCKLES

Solusinya adalah memasang mesin virtual, tidak terhubung ke domain. Ini akan cukup merepotkan, tetapi lebih baik daripada dilumpuhkan oleh kebijakan.

2
Louis Somers