Pengaturan dan keamanan situs web untuk Azure DevOps lokal

TFS 2017 | TFS 2015 | TFS 2013

Latar Belakang

Untuk banyak rilis, pengaturan situs web default untuk Azure DevOps Server, yang sebelumnya dikenal sebagai 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) formulir http://machine-name:8080/tfs.

Manfaat utama dari pengaturan ini adalah bahwa mereka sangat mudah diatur dan nyaman untuk pengguna akhir dalam sebagian besar skenario. Khususnya:

• Menggunakan HTTP daripada HTTPS menghindari kebutuhan untuk mendapatkan dan menginstal sertifikat.
• Menggunakan 8080 daripada 80 menghindari potensi konflik dengan situs lain pada komputer yang sama.
• Menggunakan "tfs" sebagai direktori virtual untuk situs memudahkan untuk menghosting Azure DevOps Server dan situs web lainnya di port yang sama di server yang sama.
• Menggunakan nama mesin, daripada nama domain yang sepenuhnya memenuhi syarat (FQDN), di URL publik menghemat banyak pengetikan.
• Membiarkan nama host dalam pengikatan yang tidak ditentukan memungkinkan fleksibilitas dalam menyambungkan - nama komputer, FQDN, atau alamat IP semuanya akan berfungsi ketika pengguna mencoba terhubung 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 solusi lain seperti IPSec digunakan. Dengan demikian mereka berpotensi rentan terhadap pemantauan aktor jahat atau bahkan memodifikasi konten komunikasi. Masalah ini dikurangi hingga batas tertentu ketika Azure DevOps Server disebarkan pada intranet di bawah perlindungan firewall perusahaan, karena sebagian besar instans Azure DevOps Server memang demikian. Tetapi bahkan dalam skenario ini, data yang dikirim ke dan dari Azure DevOps Server menyertakan kode sumber, data item kerja, dan informasi lain yang sering dapat memperoleh manfaat dari keamanan tambahan.

Selain itu, dalam TFS 2017 ada skenario autentikasi baru, seperti autentikasi akun layanan agen build/rilis dan token akses pribadi, yang mengirimkan bearer token melalui jaringan. Jika token ini diperoleh oleh pengguna jahat, token tersebut kemudian dapat digunakan untuk meniru pengguna yang menjadi milik mereka.

Mengingat semua ini, kami memutuskan waktunya telah tiba untuk lebih kuat mengadvokasi penggunaan pengikatan HTTPS dalam penyebaran Azure DevOps Server.

Mengatur grup

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 kami rekomendasikan dan yakini akan paling umum digunakan. Untuk skenario di mana tidak ada grup pengaturan ini yang sesuai, pengaturan dapat sepenuhnya dikustomisasi menggunakan dialog Edit Pengaturan Situs.

Grup pengaturan default

Grup Pengaturan default menyertakan pengaturan yang sama yang digunakan di versi Azure DevOps Server sebelumnya. Untuk semua alasan yang tercantum di atas, pengaturan ini masih default untuk penyebaran Azure DevOps Server baru. Untuk implementasi yang ada, kami akan mencoba mempertahankan pengaturan yang ada, yang seringkali akan mengakibatkan grup pengaturan Default dipilih.

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 sebagai kenyamanan bagi pengguna akhir - pengalihan dikonfigurasi sehingga semua lalu lintas berakhir menggunakan pengikatan HTTPS pada port 443. URL Publik untuk grup pengaturan ini adalah formulir https://fully-qualified-domain-name. Secara default, grup pengaturan ini akan menyediakan sertifikat baru yang ditandatangani sendiri dan menggunakannya untuk pengikatan HTTPS. Kami biasanya tidak merekomendasikan penggunaan sertifikat self-signed untuk implementasi TFS dalam produksi. Lihat Opsi Sertifikat di bawah ini untuk informasi selengkapnya tentang kapan tepat untuk menggunakan sertifikat yang ditandatangani sendiri dan opsi lain apa 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 adalah formulir https://fully-qualified-domain-name, dan sertifikat yang ditandatangani sendiri akan disediakan secara default.

Grup pengaturan HTTP Only menyediakan satu pengikatan HTTP pada port 80 tanpa Nama Host yang ditentukan. URL Publik untuk grup pengaturan ini adalah formulir 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 dapat menampilkan halaman kosong. Meskipun biasanya dimungkinkan untuk mengambil alih pengaturan browser default dan memungkinkan konten yang tidak aman, ini akan menghasilkan pengalaman yang mirip dengan 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 di mana berbagai dokumentasi sudah ada. Kami tidak akan mencoba mencakup semua kompleksitas di sini, melainkan akan fokus pada opsi tingkat tinggi untuk mengonfigurasi pengikatan HTTPS untuk penyebaran Azure DevOps Server. Banyak organisasi memiliki kebijakan khusus sekeliling 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 pengaturan konfigurasi TFS menghasilkan sertifikat yang ditandatangani sendiri untuk digunakan oleh implementasi.
• Mendapatkan sertifikat dari Otoritas Sertifikat internal.
• Mendapatkan sertifikat dari Otoritas Sertifikat eksternal.

Sertifikat yang ditandatangani sendiri

Sertifikat yang ditandatangani sendiri berguna untuk penyebaran uji coba Azure DevOps Server, karena sangat mudah untuk disediakan dan digunakan. Mereka kurang sesuai untuk penyebaran produksi Azure DevOps Server, dan kami tidak menyarankan mereka digunakan untuk penyebaran Azure DevOps Server yang terekspos ke internet publik. Umumnya, sertifikat yang ditandatangani sendiri rentan terhadap serangan man-in-the-middle. Mereka juga menyebabkan masalah bagi pengguna, karena mereka akan menyebabkan peringatan dan kesalahan sertifikat sampai sertifikat akar mereka diinstal pada setiap komputer klien. Misalnya, browser Edge akan menampilkan kesalahan di bawah ini.

Ketika wizard konfigurasi TFS menghasilkan sertifikat penandatanganan sendiri untuk penyebaran Anda, akan dibuat dua sertifikat - satu ditempatkan di penyimpanan Otoritas Sertifikasi Akar Tepercaya di server, dan satu lagi, yang ditandatangani oleh sertifikat pertama, ditempatkan di penyimpanan Pribadi di server dan digunakan oleh Azure DevOps Server. Menyiapkan hal-hal dengan cara ini membantu mengurangi kemungkinan serangan man-in-the-middle dan memungkinkan rotasi sertifikat yang digunakan dalam pengikatan HTTPS tanpa juga 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 menginstalnya di komputer klien. Ada beberapa cara untuk mencapai hal ini, termasuk:

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

Otoritas Sertifikat internal dan eksternal

Banyak organisasi besar memiliki infrastruktur kunci publik mereka sendiri, dan dapat mengeluarkan 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 Anda memiliki infrastruktur kunci publik sendiri, ini bisa menjadi opsi yang baik untuk penyebaran Azure DevOps Server Anda.

Ketika opsi lain tidak sesuai atau tersedia, sertifikat dapat diperoleh (biasanya dengan biaya) 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 Nama Umum yang disediakan dalam permintaan sertifikat cocok dengan nama host yang Anda inginkan di URL publik Anda - misalnya, tfs.contoso.com.
• Pada Properti Penyedia Layanan Kriptografi, sebaiknya pilih Penyedia Kriptografi Microsoft RSA SChannel dan panjang bit 2048 atau lebih besar.

Mengubah URL publik Anda

Perlu juga dicatat bahwa saat meningkatkan penyebaran Azure DevOps Server yang ada, mengubah URL publik akan memengaruhi pengguna akhir. Meskipun kami masih merekomendasikan untuk mengonversi pengikatan dari HTTP ke HTTPS, koneksi klien Visual Studio perlu dihubungkan kembali, bookmark lama tidak akan dapat diakses dengan benar, dan sebagainya. Oleh karena itu penting untuk mengoordinasikan perubahan semacam ini dengan pengguna penyebaran Azure DevOps Server Anda untuk menghindari gangguan yang signifikan.