Microsoft Azure Atestasi

Microsoft Azure Attestation adalah solusi terpadu untuk memverifikasi jarak jauh keandalan sebuah platform dan integritas dari biner yang berjalan di dalamnya. Layanan ini mendukung pengesahan platform yang didukung oleh Modul Platform Tepercaya (TPM) bersama kemampuan untuk membuktikan status Trusted Execution Environments (TEEs) seperti enklave Intel® Software Guard Extensions (SGX), Enklave Keamanan berbasis virtualisasi (VBS), Modul Platform Tepercaya (TPM), Peluncuran tepercaya untuk VM Azure, dan VM rahasia Azure.

Proses pengesahan adalah cara untuk menunjukkan bahwa biner perangkat lunak telah diinstansikan dengan benar pada platform terpercaya. Pihak-pihak yang bergantung dari jarak jauh kemudian dapat memperoleh keyakinan bahwa hanya perangkat lunak yang dimaksud yang berjalan pada perangkat keras yang tepercaya. Azure Attestation adalah layanan terpadu yang berhadapan dengan pelanggan dan kerangka kerja untuk atestasi.

Azure Attestation memungkinkan paradigma keamanan mutakhir seperti Azure Confidential computing dan perlindungan Edge yang Cerdas. Layanan ini menerima bukti dari entitas komputasi, mengubahnya menjadi satu set klaim, memvalidasi mereka sesuai dengan kebijakan yang dapat dikonfigurasi, dan menghasilkan bukti kriptografi untuk aplikasi berbasis klaim (misalnya, pihak yang bergantung dan otoritas audit).

Azure Attestation mendukung baik atestasi platform maupun atestasi tamu dari VM Aman (CVMs) berbasis AMD SEV-SNP. Proses atestasi platform berbasis Azure Attestation terjadi secara otomatis selama jalur boot kritis dari CVMs, tanpa perlu tindakan dari pelanggan. Untuk informasi lebih lanjut tentang atestasi tamu, lihat Mengumumkan ketersediaan umum atestasi tamu untuk VM rahasia.

Kasus penggunaan

Azure Attestation menyediakan layanan atestasi yang komprehensif untuk berbagai lingkungan dan kasus penggunaan yang khas.

Pengesahan AMD SEV-SNP pada VM Rahasia

Azure Confidential VM (CVM) berdasarkan prosesor AMD dengan teknologi SEV-SNP. CVM menawarkan opsi enkripsi disk OS VM dengan kunci yang dikelola oleh platform atau kunci yang dikelola pelanggan dan mengikat kunci enkripsi disk ke TPM mesin virtual. Ketika CVM dinyalakan, laporan SNP yang berisi pengukuran firmware VM tamu dikirim ke Azure Attestation. Layanan ini memvalidasi pengukuran dan mengeluarkan token pengesahan yang digunakan untuk merilis kunci dari Managed-HSM atau Azure Key Vault. Kunci ini digunakan untuk mendekripsi status vTPM VM tamu, membuka kunci disk OS, dan memulai CVM. Proses atestasi dan pelepasan kunci dilakukan secara otomatis pada setiap boot CVM, dan proses ini memastikan bahwa CVM hanya boot setelah atestasi perangkat keras berhasil.

Attestasi AMD SEV-SNP pada Kontainer Rahasia

Azure Confidential Containers didasarkan pada prosesor AMD dengan teknologi SEV-SNP. Kontainer rahasia, yang dihosting di Azure Container Instances dan di Azure Kubernetes Service (dalam pratinjau), menawarkan kemampuan untuk menjalankan grup kontainer di lingkungan eksekusi tepercaya yang dilindungi SEV-SNP yang mengisolasi grup kontainer tersebut dari sarana kontrol manajemen kontainer dan kontainer lain yang sedang berjalan. Proses atestasi dalam container rahasia melibatkan pengambilan laporan atestasi perangkat keras AMD langsung dari prosesor. Anda dapat menyelesaikan tugas ini dengan kontainer sidecar SKR atau mengkompilasinya langsung ke logika aplikasi Anda. Laporan perangkat keras kemudian dapat dipertukarkan dengan Azure Attestation serta HSM terkelola atau Azure Key Vault (AKV) Premium untuk memperoleh rahasia. Anda juga dapat memberikan laporan perangkat keras ke sistem key vault Anda sendiri sesuai keinginan.

Pernyataan Peluncuran Tepercaya

Pelanggan Azure dapat mencegah infeksi bootkit dan rootkit dengan mengaktifkan peluncuran tepercaya untuk mesin virtual (VM) mereka. Ketika VM diaktifkan dengan Secure Boot dan vTPM, serta ekstensi atestasi tamu terpasang, pengukuran vTPM dikirimkan secara berkala ke Azure Attestation untuk memantau integritas boot. Kegagalan attestation menunjukkan kemungkinan malware, yang ditampilkan kepada pelanggan melalui Microsoft Defender untuk Cloud, melalui Peringatan dan Rekomendasi.

Kebijakan rilis Azure Key Vault dapat memvalidasi token dari otoritas Microsoft Azure Attestation yang kompatibel, termasuk klaim boot terukur vTPM yang dihasilkan oleh VM Trusted Launch (secureboot, x-ms-azurevm-attested-pcr-values.*)—bukan hanya klaim TEE perangkat keras. Lihat Melindungi kekayaan intelektual pada VM Azure dengan Rilis Kunci Aman yang terjaga pengesahannya.

Pengesahan TPM

Trusted Platform Modules (TPM) berdasarkan atestasi penting untuk memberikan bukti tentang keadaan suatu platform. TPM berfungsi sebagai akar kepercayaan dan koprosesor keamanan untuk memberikan validitas kriptografi pada pengukuran (bukti). Perangkat dengan TPM dapat mengandalkan atestasi untuk membuktikan bahwa integritas boot tidak terganggu dan menggunakan klaim tersebut untuk mendeteksi pengaktifan status fitur selama booting.

Aplikasi klien dapat dirancang untuk memanfaatkan pengesahan TPM dengan mendelegasikan tugas-tugas yang sensitif terhadap keamanan agar hanya dilakukan setelah platform dinyatakan aman. Aplikasi semacam itu kemudian dapat menggunakan Azure Attestation untuk secara rutin membangun kepercayaan pada platform dan kemampuannya untuk mengakses data sensitif.

Pengesahan enklave SGX

Intel® Software Guard Extensions (SGX) mengacu pada isolasi tingkat perangkat keras, yang didukung pada model CPU Intel tertentu. SGX memungkinkan kode untuk berjalan di dalam kompartemen yang terjaga kebersihannya yang dikenal sebagai enclave SGX. Akses dan izin memori kemudian dikelola oleh perangkat keras untuk memastikan permukaan serangan minimal dengan isolasi yang tepat.

Aplikasi klien dapat dirancang untuk memanfaatkan enclaves SGX dengan mendelegasikan tugas-tugas yang sensitif terhadap keamanan agar dilakukan di dalam enclaves tersebut. Aplikasi semacam itu kemudian dapat menggunakan Azure Attestation untuk secara rutin membangun kepercayaan dalam enclave dan kemampuannya untuk mengakses data sensitif.

Prosesor Intel® Xeon® Scalable hanya mendukung solusi atestasi berbasis ECDSA untuk mengatestasi enclave SGX dari jarak jauh. Dengan menggunakan model atestasi berbasis ECDSA, Azure Attestation mendukung validasi prosesor Intel® Xeon® E3 dan platform server berbasis prosesor Intel® Xeon® Scalable.

Catatan

Untuk melakukan atestasi pada platform server berbasis prosesor Intel® Xeon® Scalable menggunakan Azure Attestation, pengguna diharapkan menginstal Azure DCAP versi 1.10.0 atau lebih tinggi.

Atestasi Open Enclave

Open Enclave (OE) adalah kumpulan pustaka yang ditujukan untuk menciptakan satu abstraksi enclave yang seragam bagi pengembang guna membangun aplikasi berbasis TEE. Ini menawarkan model aplikasi universal yang aman yang mengurangi keunikan platform. Microsoft melihatnya sebagai langkah penting menuju mendemokratisasi teknologi enclave berbasis perangkat keras seperti SGX dan meningkatkan penggunaannya di Azure.

OE menetapkan persyaratan khusus untuk verifikasi bukti enclave. Ini memenuhi syarat OE sebagai konsumen atestasi yang sangat sesuai untuk Azure Attestation.

Azure Attestation berjalan di dalam TEE

Azure Attestation sangat penting untuk skenario Komputasi Rahasia, karena melakukan tindakan berikut:

  • Memverifikasi apakah bukti enclave itu valid.
  • Mengevaluasi bukti enklaf terhadap kebijakan yang ditentukan oleh pelanggan.
  • Mengelola dan menyimpan kebijakan khusus penghuni.
  • Menghasilkan dan menandatangani token yang digunakan oleh pihak yang bergantung untuk berinteraksi dengan enclave.

Untuk menjaga Microsoft secara operasional keluar dari basis komputasi tepercaya (TCB), operasi penting Azure Attestation seperti validasi kutipan, pembuatan token, evaluasi kebijakan, dan penandatanganan token dipindahkan ke dalam kontainer rahasia berbasis AMD SEV-SNP.

Mengapa Menggunakan Azure Attestation

Azure Attestation adalah pilihan yang lebih disukai untuk membuktikan TEE karena menawarkan manfaat berikut:

  • Kerangka kerja terpadu untuk membuktikan beberapa lingkungan seperti TPM, enklave SGX, dan enklave VBS.
  • Memungkinkan pembuatan penyedia attestation kustom dan konfigurasi kebijakan untuk membatasi pembuatan token.
  • Melindungi datanya saat sedang digunakan melalui implementasi di TEE.
  • Layanan dengan ketersediaan tinggi.

Cara membangun kepercayaan dengan Azure Attestation

  1. Verifikasi apakah token attestation dihasilkan oleh Azure Attestation - Token attestation yang dihasilkan oleh Azure Attestation ditandatangani menggunakan sertifikat mandiri. URL sertifikat penandatangan ditampilkan melalui endpoint metadata OpenID. Sebuah pihak yang bergantung dapat mengambil sertifikat penandatanganan dan melakukan verifikasi tanda tangan dari token pernyataan. Untuk informasi selengkapnya, lihat sampel kode.
  2. Verifikasi apakah Azure Attestation berjalan di dalam kontainer SEV-SNP - Sertifikat penandatanganan token menyertakan informasi tentang TEE di mana Azure Attestation berjalan. Data pendukung TEE ini adalah laporan SEV-SNP. Pihak yang mengandalkan dapat memeriksa apakah Azure Attestation berjalan di dalam TEE yang valid dengan memvalidasi laporan secara lokal. Untuk sampel kode, lihat SEV-SNP.
  3. Validasi keterikatan laporan TEE Azure Attestation dengan kunci yang menandatangani token atestasi - Pihak verifikator dapat memverifikasi apakah hash kunci publik yang menandatangani token atestasi cocok dengan bidang data laporan pada laporan TEE Azure Attestation. Untuk informasi selengkapnya, lihat sampel kode.
  4. Validasi apakah pengukuran kode Azure Attestation sesuai dengan nilai yang dipublikasikan oleh Azure - Kolateral TEE yang disematkan dalam sertifikat penandatanganan token attestation mencakup pengukuran kode TEE dari Azure Attestation. Pihak yang mengandalkan dapat memvalidasi bahwa laporan tersebut milik Azure Attestation dengan membandingkan nilai tertentu yang diambil dari jaminan TEE dalam sertifikat penandatanganan token pengesahan dengan nilai yang disediakan oleh tim Azure Attestation. Untuk SEV-SNP, HOST_DATA harus divalidasi. Untuk informasi selengkapnya, lihat sampel kode. Jika Anda tertarik untuk melakukan validasi ini, kirim permintaan di halaman Azure support. Tim Azure Attestation menghubungi Anda ketika nilai-nilai spesifik ini dijadwalkan untuk rotasi.
  5. Dapatkan jaminan dalam membangun bukti - Azure Attestation terintegrasi dengan Transparansi Penandatanganan (MST) Microsoft. MST merekam tanda tangan kode dalam buku besar yang tidak dapat diubah dan tahan manipulasi. Layanan MST memberikan tanda terima yang dapat diverifikasi secara kriptografis dan mematuhi SCITT yang memberikan visibilitas yang jelas ke dalam penyebaran Azure Attestation—memperkuat kepercayaan, auditbilitas, dan kepatuhan terhadap peraturan. Untuk mempelajari selengkapnya tentang MST dan cara memvalidasi artefak build, lihat Tentang buku besar Transparansi Penandatanganan Microsoft.

Nilai yang mengidentifikasi instansi Azure Attestation yang valid diperkirakan akan berubah saat sertifikat penandatanganan kode dirotasi atau ketika pembaruan keamanan memerlukan versi kebijakan yang baru. Tim Azure Attestation mengikuti jadwal peluncuran ini untuk setiap rotasi yang direncanakan:

  1. Tim Azure Attestation memberi tahu konsumen tentang nilai baru dengan masa tenggang dua bulan untuk menerapkan perubahan kode yang relevan.
  2. Setelah masa tenggang dua bulan, Azure Attestation mulai menggunakan nilai-nilai baru.
  3. Tiga bulan setelah tanggal pemberitahuan, Azure Attestation berhenti menggunakan nilai-nilai lama.

Untuk rotasi yang tidak direncanakan, termasuk yang diperlukan oleh pembaruan keamanan, tim Azure Attestation mengkomunikasikan nilai baru dengan masa tenggang satu bulan.

Dukungan kelangsungan bisnis dan pemulihan bencana (BCDR)

Kelangsungan Bisnis dan Pemulihan Bencana (BCDR) untuk Azure Attestation memungkinkan Anda mengurangi gangguan layanan yang diakibatkan oleh masalah ketersediaan signifikan atau kejadian bencana di suatu wilayah.

Klaster yang diterapkan di dua wilayah beroperasi secara mandiri dalam keadaan normal. Dalam hal terjadi kesalahan atau pemadaman di salah satu wilayah, hal berikut terjadi:

  • Azure Attestation BCDR menyediakan failover yang mulus di mana pelanggan tidak perlu mengambil langkah tambahan untuk pulih.
  • Azure Traffic Manager untuk wilayah tersebut mendeteksi bahwa probe kesehatan mengalami penurunan dan mengalihkan titik akhir ke wilayah pasangan.
  • Koneksi yang ada tidak berfungsi dan mengalami kesalahan server internal atau masalah timeout.
  • Semua operasi sarana kontrol diblokir. Pelanggan tidak dapat membuat penyedia pengesahan di wilayah utama.
  • Semua operasi sarana data, termasuk panggilan pengesahan dan konfigurasi kebijakan, dilayani oleh wilayah sekunder. Pelanggan dapat tetap menggunakan operasi bidang data dengan URI asli yang terkait dengan wilayah utama.

Langkah berikutnya

  • Terakhir diperbarui pada