1 November Akan Datang - Apakah Server Exchange Anda Siap?

1 November 2015: Aturan Baru Mulai Berlaku

Teman-teman Anda di SSL.com ingin memberi tahu Anda bahwa permulaan November 1st, 2015, beberapa perubahan yang sangat penting tentang apa yang bisa dibahas sertifikat SSL mulai berlaku:

• Sertifikat baru yang berisi nama internal tidak akan lagi diterbitkan oleh otoritas sertifikat apa pun yang mengikuti pedoman CA / Forum Browser (yaitu, semua yang memiliki reputasi baik)
  
  Perhatikan bahwa untuk beberapa waktu sekarang SSL.com belum menerbitkan sertifikat intranet untuk nama internal dengan tanggal kedaluwarsa setelah 1 November 2015 dan dengan demikian pelanggan SSL.com tidak akan mengalami masalah langsung - namun, kami sangat menganjurkan Anda untuk memeriksa kembali sertifikat Anda untuk mengetahui kemungkinan dampak dari keputusan ini bagi Anda.
• Sertifikat yang sudah ada yang berisi nama internal tidak akan diterbitkan kembali setelah 1 November 2015.
  
  Sekali lagi, SSL.com telah bekerja untuk memastikan Anda tidak akan mengalami masalah karena ini - namun, kami telah menyajikan skenario terburuk untuk pendidikan Anda di bawah ini.
• Sertifikat yang sudah ada yang berisi nama internal akan DIHAPUS SECARA OTOMATIS pada tanggal 1 November 2016.
  
  Ini adalah kebijakan menyeluruh, karena beberapa arsitektur keamanan mungkin memiliki sertifikat lama yang sudah lama tidak mematuhi aturan ini.

Perubahan ini berarti bahwa email - alat internet yang pertama dan masih paling berguna - mungkin terpengaruh secara negatif oleh perubahan, terutama jika Anda menggunakan Microsoft Exchange Server (yang menurut riset pasar adalah 63 persen dari Anda semua). Dengan demikian arsitektur keamanan Anda dapat mulai terpengaruh mulai Hari All Saint yang akan datang ini.

Apakah Anda siap?

Apa Maksud Anda Saat Mengatakan "Nama Internal"?

Definisi paling sederhana dari nama internal adalah pengenal jaringan apa pun bagian dari jaringan pribadi dan tidak dapat dijangkau menggunakan nama menggunakan domain tingkat atas (TLD) atau alamat IP unik. Implikasinya, ID jaringan apa pun yang terdaftar secara publik dengan otoritas pusat seperti ICAAN akan dapat digunakan dalam sertifikat

Di masa lalu, hari-hari sederhana internet, arsitektur DNS internal hanya perlu khawatir tentang menghindari serangkaian TLD terbatas - dengan demikian, intranet AwfulBigCo.com tidak hanya dapat mendukung ABC.nyc dan ABC. London tapi 1600.pennsylvania.ave, surat dan Gandalf. Selain itu, beberapa rentang alamat IPv4 dan IPv6 dikesampingkan untuk penggunaan lokal murni - rentang yang dicadangkan ini mencakup "192.168. *. *" untuk perutean dan 10. *. *. * untuk jaringan lokal. Mengamankan intranet dengan sertifikat SSL tentu saja merupakan Ide yang Baik, dan hingga keputusan baru, admin jaringan mana pun dapat meminta dan menerima sertifikat yang menyertakan semua ini.

Mulai 1 November 2015, hal ini tidak akan berlaku lagi - sertifikat tidak akan lagi diterbitkan - atau, yang terpenting, diterbitkan kembali - yang berisi nama internal. Aturan baru ini dirancang untuk meningkatkan keamanan dan memungkinkan penggunaan yang tepat dari nama domain tingkat atas baru (misalnya, baik .london dan .nyc sekarang TLD publik). Namun, mereka mengharuskan setiap pengguna Exchange untuk memperhatikan jaringan dan pengaturan keamanan mereka dan membuat perubahan untuk mengakui aturan baru ini. Karena banyak desain keamanan Exchange yang secara historis menggunakan nama internal, hal ini dapat menyebabkan masalah serius dengan layanan email Anda saat dan saat sertifikat Anda kedaluwarsa, karena sertifikat baru dengan nama internal tidak dapat diterbitkan untuk menggantikan yang sudah ada - lebih buruk lagi, sertifikat multi-domain apa pun berisi bahkan satu nama internal akan gagal saat pembaruan, berpotensi mengekspos lalu lintas email Anda ke eksploitasi berbahaya.

Gagal melakukan ini dapat berdampak negatif terhadap lalu lintas email Anda, bisnis Anda dan / atau reputasi Anda.

Kedengarannya Dire.

Bisa jadi - itu benar-benar tergantung pada seberapa siap Anda. Ini bisa menjadi masalah yang sangat mudah untuk dilewatkan, dan konsekuensinya bisa sangat fatal bagi bisnis Anda - if Anda gagal bertindak sebelumnya.

Lihat, penyedia sertifikat AwfulBigCo menjalankan permintaan mereka melewati robot mereka, mendeteksi nama-nama internal tersebut dan (sesuai dengan aturan CA / B Forum) menolak perpanjangan.

Ini adalah sebuah masalah. UCC TIDAK akan diperbarui dan tidak hanya layanan yang menggunakan nama internal yang dilarang (yaitu, semua email perusahaan dan cadangan FTP) tidak lagi dilindungi - juga tidak akan ada domain LAIN yang disertakan dalam UCC, seperti primer dan .co. domain uk untuk AwfulBigCo.

Tentu, ini adalah skenario kasus terburuk yang ekstrim - tetapi kami benar-benar percaya bahwa keamanan penuh bergantung pada persiapan untuk itu.

Oke, Saya Takut Sah - Apa yang Harus Saya Lakukan Sekarang?

Jika Anda menggunakan nama internal dalam sertifikat SSL Anda, Anda AKAN perlu mengambil tindakan untuk mengatasi ini, dan semakin cepat semakin baik.

Pada dasarnya, ada beberapa opsi yang dapat Anda pilih:

1. Konfigurasikan ulang sistem untuk menggunakan hanya nama domain yang terdaftar secara publik.
   Ini mungkin solusi terbaik - ini membuat masalah nama internal diperdebatkan dan akan lebih sederhana secara keseluruhan untuk dipelihara dan diperluas ke depannya. Sayangnya, opsi ini mungkin membutuhkan banyak pekerjaan di depan, tetapi server Microsoft Exchange dapat diatur untuk menggunakan nama domain publik yang sepenuhnya memenuhi syarat (dan CA / Forum Browser ini laporan resmi menjelaskan lebih lanjut tentang penerapan FQDN di jaringan Active Directory). Administrasi setelah peralihan hampir pasti akan menjadi sesederhana atau lebih sederhana dari sebelumnya (nilai tambah yang besar bagi Bob) dan selanjutnya AwfulBigCo akan dapat menggunakan sertifikat yang dipercaya secara publik untuk mengamankan semua lalu lintas baik secara internal maupun eksternal. Kelemahan yang mungkin dari metode ini adalah metode ini memungkinkan informasi tentang infrastruktur internal perusahaan ditemukan melalui DNS, tetapi konfigurasi zona DNS yang cerdas dapat membantu mengatasi hal ini - misalnya, menggunakan subdomain seperti nama domain "internal" atau terpisah dan membatasi resolusi ini di luar jaringan perusahaan.
2. Daftarkan nama internal sebagai FQDN.
   Sayangnya, tidak ada opsi untuk alamat IP yang dicadangkan itu, dan "Mail" dan "Gandalf" tentu saja benar. (Kami akan berasumsi demi kewarasan Bob bahwa domain .com dan .co.uk sudah terdaftar dengan aman - harinya cukup sulit seperti sekarang.)
   Juga, bahkan jika abc.pertukaran tersedia - dan ingat bahwa .exchange adalah salah satu TLD baru yang perkenalannya membantu mendorong perubahan aturan ini - ini bisa saja diperhitungkan dan hanya tersedia dengan harga selangit - alternatif yang lebih mudah dan lebih murah mungkin tersedia.
3. Menyiapkan CA Perusahaan
   Ini adalah metode yang sudah digunakan oleh entitas yang sangat besar yang terutama perlu mengamankan komunikasi internal. CA perusahaan berfungsi sebagai otoritas sertifikat perusahaan - pada dasarnya, alih-alih rantai kepercayaan yang berjalan ke CA eksternal, semua sertifikat pada akhirnya diamankan dengan sertifikat akar yang dibuat secara internal. Meskipun hal ini memberikan penyesuaian yang lebih besar (dan akan memungkinkan Bob untuk mempertahankan struktur penamaan lama yang dimiliki AwfulBigCo) ada masalah keamanan serius yang perlu dipertimbangkan - peretasan gaya Sony dapat mengekspos sertifikat akar perusahaan dan / atau kunci pribadi, yang memungkinkan eksploitasi jaringan yang hampir tidak terbatas. Selain itu, sertifikat yang diterbitkan sendiri TIDAK akan dipercaya di tempat lain - ini adalah metode yang mengamankan komunikasi internal tetapi tidak dapat memperluas kepercayaan di luar dinding jaringan bisnis Anda. Terakhir, menyiapkan CA perusahaan bukanlah solusi dalam semalam, dan mungkin jauh lebih sulit daripada opsi lain yang tercantum di sini, dan dengan demikian hanya dapat dijalankan untuk jaringan yang sangat besar (atau berkembang).
   
   SSL.com dengan senang hati menawarkan layanan konsultasi dan manajemen untuk membantu Anda menegosiasikan jalur penyiapan CA Perusahaan Anda sendiri - cukup kirim pesan ke perusahaanca@ssl.com dan salah satu administrator senior kami akan segera menghubungi Anda.
4. Gunakan sertifikat yang ditandatangani sendiri
   Opsi ini memiliki kekurangan yang mirip dengan Enterprise CA, tetapi tidak dapat diskalakan dengan baik - karena setiap sertifikat yang ditandatangani sendiri tidak memiliki rantai kepercayaan di luar dirinya, setiap sertifikat individu harus diinstal pada setiap klien untuk menghindari pesan kesalahan . Manajemen di seluruh jaringan yang luas juga akan membuat sakit kepala baru bagi Bob yang malang - sesuatu yang sederhana seperti pembaruan peramban otomatis dapat menyebabkan malapetaka kecuali kewaspadaan berkelanjutan dipertahankan di setiap perangkat.

Selalu, atau hubungi kami di SSL.com jika Anda memiliki pertanyaan. Ingat - internet yang lebih aman adalah internet yang lebih baik.