Share via

Pengaturan dan keamanan situs web untuk Azure DevOps lokal

  • Artikel

TFS 2017 | TFS 2015 | TFS 2013

Latar belakang

Untuk banyak perilisan, pengaturan situs web default untuk Azure DevOps Server, yang sebelumnya bernama Team Foundation Server (TFS), adalah:

  • Satu pengikatan HTTP untuk situs web Azure DevOps Server pada port 8080, tanpa nama host atau alamat IP yang ditentukan.
  • URL publik (sebelumnya disebut sebagai URL Pemberitahuan) dari formulirhttp://machine-name:8080/tfs.

Manfaat utama pengaturan ini adalah pengaturannya sangat sederhana dan nyaman bagi pengguna akhir di sebagian besar skenario. Secara khusus:

  • Menggunakan HTTP daripada HTTPS menghindari kebutuhan untuk mendapatkan dan memasang sertifikat.
  • Menggunakan 8080 daripada 80 dapat menghindari potensi konflik dengan situs lain pada komputer yang sama.
  • Menggunakan "tfs" sebagai direktori virtual untuk situs memudahkan untuk menghosting Azure DevOps Server serta situs web lain pada port dan server yang sama.
  • Menggunakan nama komputer, daripada nama domain yang sepenuhnya memenuhi syarat (FQDN) di URL publik akan mengurangi banyak pengetikan.
  • Membiarkan nama host dalam pengikatan tidak ditentukan memungkinkan fleksibilitas dalam menyambungkan - nama komputer, FQDN, atau alamat IP semuanya akan berfungsi ketika pengguna mencoba menyambungkan ke server mereka.

Namun, pengaturan ini tidak aman secara default. Secara khusus, dengan tidak menggunakan pengikatan HTTPS, komunikasi ke dan dari Azure DevOps Server tidak dienkripsi saat transit, kecuali jika solusi lain seperti IPSec digunakan. Dengan demikian, server berpotensi rentan terhadap pelaku kejahatan yang memantau atau bahkan mengubah konten komunikasi. Masalah ini dikurangi sampai batas tertentu ketika Azure DevOps Server disebarkan di intranet di belakang firewall perusahaan, seperti sebagian besar instans Azure DevOps Server. Tetapi bahkan dalam skenario ini, data yang dikirim ke dan dari Azure DevOps Server menyertakan kode sumber, data item kerja, dan informasi lain yang kerap kali diuntungkan dari keamanan tambahan.

Selain itu, di TFS 2017, terdapat skenario autentikasi baru (membangun/merilis autentikasi akun layanan agen, token akses pribadi) yang mengirimkan token pembawa melalui kabel. Jika token ini diperoleh oleh pengguna yang berbahaya, token tersebut dapat digunakan untuk menyamar sebagai pengguna yang mereka miliki.

Mengingat semua ini, kami memutuskan bahwa sudah saatnya menganjurkan penggunaan pengikatan HTTPS dalam penyebaran Azure DevOps Server.

Grup pengaturan

TFS 2017 menyajikan opsi konfigurasi pengaturan situs web di semua skenario konfigurasi server. Beberapa grup pengaturan disediakan, yang menggabungkan kombinasi pengikatan situs, direktori virtual, dan URL publik yang disarankan serta diyakini akan paling sering digunakan. Untuk skenario saat tidak ada grup pengaturan ini yang sesuai, pengaturan dapat sepenuhnya disesuaikan menggunakan dialog Edit Pengaturan Situs.

Grup pengaturan default

Grup pengaturan default menyertakan pengaturan yang sama dengan yang digunakan dalam versi Azure DevOps Server sebelumnya. Dengan semua alasan yang tercantum di atas, pengaturan ini masih menjadi default untuk penyebaran Azure DevOps Server baru. Untuk penyebaran yang ada, kami akan mencoba memelihara pengaturan yang ada, yang akan sering memilih grup pengaturan Default.

HTTPS dan HTTP dengan grup pengaturan pengalihan.

Grup pengaturan HTTPS dan HTTP (dengan pengalihan) menyediakan dua pengikatan:

  • Satu pengikatan HTTPS pada port 443, dengan nama domain yang sepenuhnya memenuhi syarat (FQDN) komputer sebagai Nama Host.
  • Satu pengikatan HTTP pada port 80, sekali lagi dengan FQDN komputer sebagai Nama Host.

Pengikatan HTTP pada port 80 ditambahkan hanya untuk kenyamanan bagi pengguna akhir - pengalihan dikonfigurasi agar semua lalu lintas akhirnya menggunakan pengikatan HTTPS pada port 443. URL Publik untuk grup pengaturan ini berbentuk https://fully-qualified-domain-name. Secara default, grup pengaturan ini akan menyediakan sertifikat baru yang ditandatangani sendiri dan menggunakannya untuk pengikatan HTTPS. Biasanya kami tidak menyarankan penggunaan sertifikat yang ditandatangani sendiri untuk penyebaran TFS produksi. Lihat Opsi Sertifikat di bawah ini untuk informasi selengkapnya tentang waktu yang tepat untuk menggunakan sertifikat yang ditandatangani sendiri dan opsi lainnya yang tersedia.

Grup pengaturan HTTPS hanya menyediakan satu pengikatan HTTPS pada port 443, dengan FQDN komputer sebagai Nama Host. Sekali lagi, URL Publik untuk grup pengaturan ini berbentuk https://fully-qualified-domain-name, dan sertifikat yang ditandatangani sendiri akan disediakan secara default.

Grup pengaturan Hanya HTTP menyediakan satu pengikatan HTTP pada port 80 tanpa Nama Host yang ditentukan. URL Publik untuk grup pengaturan ini berbentuk http://machine-name.

Saat menggunakan grup pengaturan HTTPS dan HTTP (dengan pengalihan), penggunaan URL publik HTTP tidak disarankan. Sebagian besar browser modern akan menganggap konten HTTP dan HTTPS campuran tidak aman secara default dan mungkin akan menampilkan halaman kosong. Meskipun biasanya dimungkinkan untuk mengambil alih pengaturan browser default dan mengizinkan konten yang tidak aman, ini akan menghasilkan pengalaman yang mirip seperti menelusuri situs dengan sertifikat SSL yang kedaluwarsa.

Opsi sertifikat

Menyebarkan situs web menggunakan pengikatan HTTPS dan enkripsi SSL/TLS terkait erat dengan topik infrastruktur kunci publik (PKI) yang lebih luas, yang merupakan topik yang kaya dan menarik saat telah tersedia berbagai dokumentasi. Kami tidak akan membahas semua kompleksitas di sini, dan akan berfokus pada opsi tingkat tinggi untuk mengonfigurasi pengikatan HTTPS bagi penyebaran Azure DevOps Server. Banyak organisasi memiliki kebijakan khusus tentang penyebaran sertifikat, jadi langkah pertama dalam memutuskan sertifikat apa yang akan digunakan untuk penyebaran Azure DevOps Server seringkali untuk berbicara dengan grup teknologi informasi tingkat organisasi.

Opsinya meliputi:

  • Mengizinkan wizard konfigurasi TFS untuk membuat sertifikat yang ditandatangani sendiri untuk digunakan dalam penyebaran.
  • Memperoleh sertifikat dari Otoritas Sertifikat internal.
  • Memperoleh sertifikat dari Otoritas Sertifikat eksternal.

Sertifikat yang ditandatangani sendiri

Sertifikat yang ditandatangani sendiri berguna untuk penyebaran percobaan Azure DevOps Server karena sangat mudah untuk disediakan dan digunakan. Sertifikat tersebut kurang tepat untuk penyebaran produksi Azure DevOps Server, dan kami tidak menyarankan untuk menggunakannya dalam penyebaran Azure DevOps Server yang terpapar ke internet publik. Umumnya, sertifikat yang ditandatangani sendiri rentan terhadap serangan pembajakan. Sertifikat tersebut juga menyebabkan masalah bagi pengguna, sebab akan memicu peringatan dan kesalahan sertifikat sampai sertifikat akarnya dipasang pada setiap komputer klien. Misalnya, browser Edge akan menampilkan kesalahan di bawah ini.

Kesalahan sertifikat di Edge.

Ketika wizard konfigurasi TFS menghasilkan sertifikat yang ditandatangani sendiri untuk penyebaran Anda, wizard tersebut akan membuat dua - satu yang ditempatkan di penyimpanan Otoritas Sertifikasi Akar Tepercaya di server, dan yang kedua, ditandatangani oleh yang pertama, yang ditempatkan di penyimpanan Pribadi di server dan digunakan oleh Azure DevOps Server. Mengatur dengan cara ini akan membantu mengurangi kemungkinan serangan pembajakan dan memungkinkan rotasi sertifikat yang digunakan dalam pengikatan HTTPS tanpa perlu mendistribusikan sertifikat baru ke semua klien untuk menghindari kesalahan sertifikat seperti yang ditunjukkan di atas.

Untuk menghindari peringatan dan kesalahan sertifikat tersebut, Anda dapat mengekspor sertifikat akar dan memasangnya di komputer klien. Terdapat beberapa cara untuk melakukan hal ini, termasuk:

  • Menggunakan snap-in MMC Sertifikat untuk mengekspor sertifikat secara manual di server lalu mengimpornya di setiap klien.
  • Menggunakan cmdlet powershell Ekspor-Sertifikat, yang tersedia di sistem operasi Windows 8 / Windows Server 2012 dan yang lebih baru untuk mengekspor sertifikat. Impor-Sertifikat kemudian dapat digunakan untuk mengimpornya di setiap klien.
  • Menggunakan Kebijakan Grup untuk mengotomatiskan distribusi ke klien.

Otoritas Sertifikat internal dan eksternal

Banyak organisasi besar memiliki infrastruktur kunci publik mereka sendiri, serta dapat menerbitkan sertifikat dari Otoritas Sertifikat mereka sendiri. Biasanya, ketika ini terjadi, sertifikat akar tepercaya untuk otoritas ini sudah akan didistribusikan ke komputer klien, sehingga menghindari kebutuhan untuk mendistribusikan sertifikat tambahan untuk Azure DevOps Server. Jika organisasi memiliki infrastruktur kunci umum sendiri, ini dapat menjadi opsi yang baik untuk penyebaran Azure DevOps Server Anda.

Ketika opsi lain tidak sesuai atau tidak tersedia, sertifikat dapat diperoleh (biasanya berbiaya) dari Otoritas Sertifikat (CA) eksternal. Instruksi untuk proses ini, yang dimulai dengan membuat Permintaan Penandatanganan Sertifikat, dapat ditemukan di sebagian besar situs web CA. Beberapa catatan penting:

  • Pastikan bahwa Nama Umum yang disediakan dalam permintaan sertifikat cocok dengan nama host yang Anda inginkan di URL publik - misalnya, tfs.contoso.com.
  • Pada Properti Penyedia Layanan Kriptografi, sebaiknya pilih Penyedia Kriptografi Microsoft RSA SChannel dan panjang bit 2048 atau lebih.

Mengubah URL publik Anda

Perlu diperhatikan juga bahwa saat meningkatkan penyebaran Azure DevOps Server yang ada, mengubah URL publik akan berdampak ke pengguna akhir. Meskipun kami masih menyarankan untuk mengonversi dari pengikatan HTTP ke HTTPS, sambungan klien Visual Studio perlu dibuat kembali, marka buku lama tidak akan lagi diselesaikan dengan benar, dan sebagainya. Oleh karena itu, penting untuk mengoordinasikan perubahan seperti ini dengan pengguna penyebaran Azure DevOps Server Anda untuk menghindari gangguan signifikan.