Di mana menyimpan repositori sumber pusat?


10

Apa praktik terbaik industri terkait pengamanan akses ke kode sumber? Saya pikir hanya koneksi SSL melalui apache yang diizinkan ke server kami pada port yang tidak jelas yang tidak bertentangan dengan hal lain. Hal yang mengganggu saya adalah menyimpan kode sumber pada server yang menghadap publik, yaitu tidak hanya dapat diakses melalui LAN. Apalagi server ini memiliki beberapa kegunaan. Apache sudah melayani beberapa situs web perusahaan internal lainnya. Saya ingin semua orang dapat mengakses kode sumber dari mana saja (rumah, bandara, apa pun) asalkan mereka memiliki kredensial yang benar. Saran?

Jawaban:


13

Jika Anda khawatir itu berada di server yang menghadap publik tetapi ingin akses dari mana saja, Anda harus mempertimbangkan agar pengembang Anda menggunakan VPN berbasis klien untuk masuk ke jaringan Anda dari jarak jauh untuk mengakses server kontrol sumber internal.


1
Bisakah Anda menjelaskan alasan Anda mengapa Anda percaya bahwa VPN lebih aman daripada server berbasis SSL / TLS mengingat keduanya harus "menghadap publik"? VPN menggunakan enkripsi familar ke SSL / TLS. Jadi, jika Anda bisa meretas VPN, Anda mendapatkan segalanya.
Matt

1
@Matt Jika tidak ada alasan baginya untuk memiliki repositori di segmen publik, lalu mengapa meletakkannya di sana? Selain itu, VPN mungkin memiliki manfaat lain untuk pengembangnya. Anda juga akan mencatat bahwa saya tidak pernah mengatakan di mana pun bahwa "VPN lebih aman daripada SSL / TLS", jadi jangan menaruh kata-kata di mulut saya :)
phoebus

1
Benar. Saya merasa keamanan tersirat dalam pernyataan saya. Mungkin Anda dapat memenuhi syarat ini: "Jika Anda khawatir akan berada di server yang menghadap publik"
Matt

Menurut pendapat saya, memiliki server / layanan pribadi di belakang VPN adalah bagian dari pendekatan berlapis. Ini membantu melindungi terhadap kesalahan konfigurasi yang dapat mengekspos sumber kepada publik. Tidak wajib, tapi pintar.
Martijn Heemels

4

Saya tidak terlalu yakin mengapa orang berpikir pendekatan VPN adalah yang terbaik. Itu belum tentu lebih aman dan hanya menawarkan satu keuntungan yang bisa saya pikirkan.

PPTP misalnya diketahui memiliki keamanan yang kurang dari ideal, meskipun saya percaya itu agak membaik sejak pertama kali diperkenalkan ... jadi berhati-hatilah solusi VPN yang Anda gunakan. Saya akan menggunakan OpenVPN atau IPSEC.

Namun, Anda tidak dapat mengalahkan kenyamanan SSL / TLS tanpa VPN (baca selanjutnya di bawah). Dan untuk membuatnya lebih aman, Anda dapat membuatnya hanya sertifikat.

Namun, jika Anda berpikir Anda mungkin menawarkan layanan lain selain kontrol sumber maka pertimbangkan solusi VPN karena Anda akan membuat terowongan layanan lain di atasnya.

Kerugian dengan menggunakan VPN adalah PC Anda menjadi bagian dari jaringan yang terhubung secara efektif. Itu juga bisa menjadi keuntungan. Tetapi, jika Anda berada satu juta mil jauhnya dari rumah dan koneksi jaringan ke home base tidak terlalu cepat maka setiap kali Anda ingin melakukan kode diff atau check-in atau out, Anda mungkin menemukan diri Anda menghubungkan dan memutuskan VPN.

Saya dapat berbicara dari pengalaman pribadi di sini karena saya seorang pengembang dan sungguh menyebalkan untuk melakukan hal ini !!! Idealnya, kedua opsi lebih disukai.

Jadi jika Anda akan menjelajahi web dll maka mungkin membuat membaca berita dll agak lambat. Tetapi setidaknya Anda mendapatkan akses aman ke email. Jadi pertimbangkan bagaimana Anda akan menggunakannya terlebih dahulu ... Jika saya adalah Anda, saya akan mempertimbangkan untuk mengimplementasikan keduanya.


3

Sebenarnya, saya suka saran Anda. Jika Anda membuat repositori kode sumber HANYA dapat diakses melalui SSL / TLS, dan Anda memastikan bahwa pengembang Anda tidak menggunakan frasa sandi yang mudah-kasar (atau lebih baik lagi, menggunakan sertifikat), maka itu harus seaman apa pun .

Anda bisa, sebaliknya, menyembunyikan server Anda di dalam LAN Anda dan memaksa pengembang untuk menggunakan VPN untuk mendapatkan akses, tetapi itu hanya berarti pengembang Anda perlu memasukkan nama pengguna / kata sandi (dan / atau sertifikat) mereka ke dalam kotak login yang berbeda. Saya akan merekomendasikan untuk tidak membuat titik masuk ke jaringan Anda yang implikasi keamanannya tidak selalu jelas, hanya untuk memungkinkan akses ke satu layanan. Jika Anda sudah memiliki VPN yang dikonfigurasi dan diamankan untuk penggunaan lain, maka tentu saja, itu adalah no-brainer, silakan dan gunakan. Jika tidak, mungkin lebih sederhana, dan dengan demikian lebih aman, untuk membuat layanan itu sendiri tersedia secara langsung melalui SSL / TLS.


3

Standar industri mungkin tergantung pada apa industri Anda (atau pelanggan Anda) :-)

Praktis Anda perlu mempertimbangkan siapa yang ingin Anda beri akses, dan apa yang bisa mereka tangani. Beberapa orang yang mungkin ingin / perlu Anda akses tidak akan mampu mengatasi lebih dari sekadar nama pengguna / kata sandi. Orang lain mungkin bisa mendapatkan kepala mereka sekitar ssh dan kunci pribadi, yang asalkan Anda bisa mendapatkan kunci dengan aman kepada mereka, tidak buruk. Klien TortoiseSVN dapat menangani ssh + svn dan mendukung kunci pribadi dengan sedikit memutar lengan. Itu sudah cukup baik untuk tujuan saya.

Terowongan VPN juga merupakan saran yang adil, meskipun di banyak tempat Anda akan dengan senang hati memberikan orang-orang eksternal akses hanya ke kontrol sumber Anda, tetapi tidak seluruh jaringan Anda!


2

Seperti yang lain, saya lebih suka VPN. Alternatifnya adalah terowongan SSH, yang menurut saya praktis adalah semacam VPN.


0

Jadikan internal saja dan terapkan solusi VPN pengguna jarak jauh. / Doh- duplikat.


0

Jika Anda ingin akses dari mana saja, maka Anda memerlukan server yang menghadap publik - yang jelas.

Di server itu, Anda ingin mengekspos sesedikit mungkin , lebih disukai hanya Mercurial / Subversion dan tidak ada yang lain. Ini untuk mencegah pelanggaran keamanan menyebar dari kontrol sumber ke seluruh perusahaan Anda. Untuk alasan itu, saya akan setuju dengan Matt ketika dia mengatakan bahwa VPN bisa berbahaya: memberikan akses yang lebih luas daripada yang dibutuhkan.

Untuk Mercurial, Anda dapat mengunci sesuatu dengan ketat dengan menggunakan hg-sshuntuk membatasi perintah yang tersedia untuk klien yang terhubung melalui SSH. Dengan menggunakan SSH, Anda dapat dengan mudah meminta klien menggunakan otentikasi kunci publik alih-alih kata sandi. Ini melindungi server Anda terhadap serangan masuk brute force.

Bahkan jika kunci SSH terganggu (mungkin memiliki frase sandi yang lemah dan laptop yang menyimpannya dicuri), maka kerusakan terburuk yang dapat dilakukan penyerang, adalah menambah riwayat sampah di Mercurial. Protokol yang digunakan secara inheren append-only, jadi tidak ada yang bisa dihapus hg push.

Untuk HTTPS, otentikasi dilakukan oleh server web front-end . Ini berarti bahwa Anda dapat memerlukan sertifikat situs klien jika Anda menginginkannya dan dapatkan keamanan seperti otentikasi kunci publik SSH di atas.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.