Jawaban atas pertanyaan umum tentang Microsoft Azure Attestation

Trusted Hardware Identity Management (THIM) mengambil garis besar keamanan Azure untuk simpul Komputasi Rahasia Azure (ACC) dari Intel dan menyimpan data. Azure Attestation juga menggunakan informasi cache dalam memvalidasi Trusted Execution Environments (TEEs).

THIM direkomendasikan karena alasan berikut:

• Menawarkan ketersediaan tinggi
• Mengurangi dependensi pada layanan yang dihosting secara eksternal dan konektivitas internet.
• Secara berkala mengambil versi sertifikat Intel, CRL, informasi Trusted Computing Base (TCB) yang lebih baru, dan Mengutip identitas Enklave dari node ACC dari Intel. Layanan ini mengonfirmasi garis besar keamanan Azure yang akan dirujuk oleh Azure Attestation saat memvalidasi TEEs, sangat mengurangi kegagalan pengesahan karena pembatalan atau pencabutan sertifikat Intel.

Tidak. Azure Attestation bergantung pada garis besar keamanan yang dinyatakan oleh Manajemen Identitas Perangkat Keras Tepercaya (THIM) untuk memvalidasi TEES. Layanan caching Azure PCK saat ini dirancang untuk hanya mendukung simpul komputasi Azure Confidential.

Selama proses pengesahan SGX, Azure Attestation melakukan validasi berikut:

• Memvalidasi apakah akar tepercaya dari kutipan enklave yang ditandatangani milik Intel
• Memvalidasi apakah kutipan TEE memenuhi garis besar keamanan Azure seperti yang didefinisikan oleh Manajemen Identitas Perangkat Keras Tepercaya (THIM)
• Jika pelanggan membuat penyedia pengesahan dan mengonfigurasi kebijakan kustom, selain validasi di atas, Azure Attestation mengevaluasi kutipan TEE terhadap kebijakan pengesahan. Pelanggan dapat menggunakan kebijakan pengesahan untuk menentukan aturan otorisasi untuk TEE dan juga menentukan aturan penerbitan untuk menghasilkan token pengesahan.

Secara umum, untuk model pengesahan dengan Intel sebagai akar kepercayaan, klien pengesahan berbicara dengan enclave API untuk mengambil bukti enklave. Enclave API memanggil secara internal layanan caching Intel PCK untuk mengambil sertifikat Intel dari simpul yang akan dibuktikan. Sertifikat digunakan untuk menandatangani bukti enklave sehingga menghasilkan jaminan yang dapat dibuktikan dari jarak jauh.

Proses yang sama dapat diimplementasikan untuk Azure Attestation. Namun untuk menuai manfaat yang ditawarkan oleh Trusted Hardware Identity Management (THIM), setelah menginstal komputer virtual ACC, disarankan untuk menginstal pustaka Azure DCAP. Berdasarkan perjanjian dengan Intel, saat pustaka Azure DCAP diinstal, permintaan untuk menghasilkan bukti enklave dialihkan dari layanan caching Intel PCK ke layanan penembolokan Azure PCK. Pustaka Azure DCAP didukung di lingkungan berbasis Windows dan Linux.

• Setelah menginstal komputer virtual komputasi Rahasia Azure, instal pustaka Azure DCAP (Windows/Linux) untuk menuai keuntungan yang ditawarkan oleh Trusted Hardware Identity Management (THIM).
• Klien pengesahan jarak jauh perlu ditulis yang dapat mengambil bukti enklave dan mengirim permintaan ke Azure Attestation. Lihat sampel kode untuk referensi.
• Permintaan pengesahan dapat dikirim ke titik akhir REST API penyedia default atau penyedia pengesahan kustom.
• Dalam versi API pratinjau 2018-09-01, klien perlu mengirim token akses Microsoft Entra bersama dengan bukti ke titik akhir API pengesahan SGX. Token akses Microsoft Entra bukan parameter yang diperlukan untuk melakukan pengesahan SGX dalam versi API 2020-10-01 .

Token pengesahan yang dihasilkan oleh Azure Attestation ditandatangani menggunakan sertifikat yang ditandatangani sendiri. Sertifikat penandatanganan diekspos melalui titik akhir metadata OpenID. Pihak yang mengandalkan dapat mengambil sertifikat penandatanganan dari titik akhir ini dan melakukan verifikasi tanda tangan token pengesahan. Sertifikat penandatanganan juga menyertakan kutipan SGX dari TEE di mana Azure Attestation berjalan. Jika pihak yang mengandalkan juga lebih suka memeriksa apakah Azure Attestation berjalan di dalam enklave SGX yang valid, kutipan SGX dapat diambil dari sertifikat penandatanganan dan divalidasi secara lokal. Untuk informasi selengkapnya, lihat sampel kode.

Waktu validitas token pengesahan adalah 8 jam. Saat ini tidak ada provisi untuk menyesuaikan nilai.

Beberapa sertifikat yang diekspos di titik akhir metadata OpenID sesuai dengan kasus penggunaan yang berbeda (misalnya, pengesahan SGX) yang didukung oleh Azure Attestation. Sesuai standar yang ditentukan oleh RFC 7515, sertifikat dengan ID kunci (anak) yang cocok dengan parameter anak di header token pengesahan akan digunakan untuk verifikasi tanda tangan. Jika tidak ditemukan anak yang cocok, maka diharapkan untuk mencoba semua sertifikat yang diekspos oleh titik akhir metadata OpenID.

Pada saat pembuatan bukti TEE, kode yang berjalan di dalam TEE dapat menyertakan informasi arbitrer dalam bukti. Misalnya, TEE dapat membuat satu atau beberapa pasangan kunci asimetris, menserialisasikan komponen kunci publik dari pasangan kunci ini sebagai string JWKS JSON dan menyertakan string JWKS JSON dalam bukti TEE sebagai RunTimeData { quote, string JWKS JSON }. Azure Attestation memeriksa apakah hash SHA256 dari RuntimeData cocok dengan 32 byte yang lebih rendah dari atribut "data laporan" kutipan. Pasca mengevaluasi bukti TEE, Azure Attestation menghasilkan JWT dengan JWKS yang tersedia sebagai klaim bernama "kunci" di bawah klaim "x-ms-runtime". RunTimeData dapat digunakan lebih lanjut dengan mengandalkan pihak untuk membuat saluran aman dan mengirimkan data dengan aman ke TEE.

Azure Attestation menyimpan data pelanggan saat tidak aktif, selama pemrosesan dan replikasi untuk tujuan BCDR dalam geografi tempat pelanggan menyebarkan instans layanan.