Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Kebijakan MXC menjelaskan apa yang dapat diakses beban kerja. Mulailah dengan izin default-menolak, tambahkan hanya sumber daya yang diperlukan untuk tugas tertentu, dan validasi hasilnya dengan input representatif di setiap platform yang didukung aplikasi Anda. Setiap backend juga menyediakan sumber daya sistem operasi yang diperlukan untuk memulai beban kerja; ditolak secara default tidak berarti proses berjalan tanpa lingkungan sistem.
Pertahankan keputusan kebijakan dalam kode aplikasi tepercaya. Alat, plugin, skrip, atau perintah yang dihasilkan AI dapat melaporkan apa yang dibutuhkannya, tetapi tidak boleh memilih model pembatasannya sendiri atau memperluas aksesnya sendiri.
Memahami kebijakan dan konfigurasi
MXC memisahkan izin sumber daya dari pengaturan untuk menjalankan perintah:
- Pengaturan kebijakan menjelaskan maksud lintas platform, seperti jalur yang dapat dibaca, jalur bisa-tulis, tujuan jaringan, akses UI, dan batas waktu.
- Pengaturan eksekusi menambahkan perintah, direktori kerja, lingkungan, dan pilihan kontainmen.
Di SDK V1, ContainerRequest membawa keduanya. Di .NET, buat ContainerRequest dari perintah, atur properti kebijakan dan eksekusinya, dan panggil MxcContainer.RunAsync atau API spawn. Di TypeScript, teruskan ContainerRequest objek ke run atau fungsi spawn. Di Rust, buat ContainerRequest struct dan teruskan ke v1::run atau fungsi spawn. Gunakan maksud containment abstrak Process kecuali beban kerja Anda memerlukan backend tertentu.
Pengaturan kebijakan netral bahasa berikut menjelaskan tugas dalam cakupan repositori. Mereka menggunakan nama properti TypeScriptContainerRequest; .NET menggunakan struktur yang sama dengan nama PascalCase seperti ReadonlyPaths, dan Rust menggunakan nama snake_case seperti readonly_paths. Itu bukan permintaan lengkap: itu tidak berisi perintah atau memilih backend. Buat direktori dan ganti path sebelum mengadaptasinya.
{
"filesystem": {
"readonlyPaths": ["C:\\src\\my-app"],
"readwritePaths": ["C:\\src\\mxc-output"],
"deniedPaths": ["C:\\src\\my-app\\.env"]
},
"network": {
"egress": { "default": "deny" },
"ingress": { "default": "deny", "hostLoopback": "deny" }
},
"ui": {
"disable": true,
"clipboard": "none",
"allowInputInjection": false
},
"timeoutMs": 30000
}
Gunakan jenis SDK alih-alih menyalin properti permintaan ke dalam konfigurasi eksekusi mentah. Bentuknya berbeda: misalnya, timeoutMs pada permintaan dipetakan ke process.timeout pada konfigurasi, ui.allowInputInjection dipetakan ke ui.injection, dan network.runtimeConfig dipetakan ke bagian runtimeConfig tingkat atas. Lihat panduan cepat SDK untuk contoh C#, TypeScript, dan Rust yang lengkap.
Pilih skema yang kompatibel
Pisahkan ketiga pertanyaan ini:
| Sumbu kompatibilitas | Apa yang harus diperiksa |
|---|---|
| SDK dan rilis produk | API dan komponen runtime apa saja yang disediakan paket |
| Skema kebijakan | Kontrak konfigurasi yang tepat yang diterima oleh rilis |
| Kemampuan host | Pembatasan apa yang dapat diterapkan oleh lingkungan yang dipilih saat runtime |
SDK MXC 1.0 V1 menggunakan skema stabil 1.0.0 secara internal, sehingga Anda tidak menentukan versi skema dalam ContainerRequest. Versi skema hanya berlaku saat Anda menyusun konfigurasi eksekusi JSON mentah, seperti file untuk alat baris perintah wxc-exec.
Konfigurasi mentah harus mendeklarasikan version yang terdaftar secara tepat. MXC 1.0 menerima 1.0.0, skema stabil saat ini, dan 0.9.0-alpha, skema minimum yang didukung. MXC menolak versi yang hilang, versi yang dipensiunkan sebelum 0.9.0-alpha, seperti 0.8.0-alpha, dan ejaan yang tidak terdaftar seperti 1.0 atau 1.0.1. Kontrak 1.1.0-alpha pengembangan dapat berubah sebelum publikasi, jadi jangan gunakan untuk konfigurasi produksi. Memilihnya tidak mengaktifkan backend eksperimental.
Jaga SDK dan komponen runtime asli dari rilis yang sama bersama-sama. Lihat pembuatan versi skema MXC untuk kontrak terdaftar.
Cakup akses file
Klasifikasikan setiap jalur dengan cara beban kerja menggunakannya:
| Access | Gunakan untuk itu |
|---|---|
| Hanya dapat dibaca | Sumber, alat, pustaka, dan konfigurasi yang harus diperiksa oleh beban kerja tetapi tidak boleh diubah |
| Baca-tulis | Output, cache, atau direktori sementara khusus untuk tugas tertentu |
| Ditolak | Kredensial, repositori yang tidak terkait, konfigurasi sensitif, dan jalur yang lebih sempit di dalam izin akses yang lebih luas |
Berikan izin untuk jalur paling sempit yang masih praktis. Misalnya, berikan direktori hasil pengujian alih-alih akar repositori ketika perintah hanya menulis output pengujian. Perlakukan jalur yang ditemukan dari variabel lingkungan, manajer paket, atau pencarian alat sebagai kandidat untuk ditinjau, bukan pemberian otomatis.
Sertakan biner alat, pustaka, konfigurasi, dan jalur sementara yang sebenarnya dibutuhkan workload. SDK menyediakan fungsi bantuan filesystem-discovery, tetapi hasilnya bukan kebijakan yang disetujui. Tinjau setiap jalur calon sebelum menambahkan jalur tersebut.
Mengatur direktori kerja tidak memberikan akses ke direktori tersebut. Tambahkan ke daftar sistem file yang sesuai secara eksplisit.
Hindari mengandalkan aturan jalur yang tumpang tindih kecuali Anda telah mengujinya dengan backend yang dipilih. Backend menggunakan mekanisme akses file yang berbeda, dan beberapa tidak dapat mewakili aturan penolakan di dalam direktori yang dipetakan atau dipasang.
Kontrol akses jaringan
Jaga agar akses jaringan ditolak kecuali tugas memerlukannya. Pilih model jaringan yang dapat diterapkan oleh backend yang dipilih:
| Model | Gunakan untuk itu |
|---|---|
| Tidak ada akses eksternal | Analisis atau transformasi yang hanya memerlukan sumber daya lokal yang diizinkan |
| Akses langsung dengan IP/CIDR, protokol, dan aturan port | Tugas yang membutuhkan koneksi langsung tertentu, seperti TCP ke titik akhir layanan yang diketahui |
| HTTP(S) melalui proksi yang disediakan aplikasi | Permintaan yang tujuannya atau izin tingkat aplikasi yang dikendalikan oleh proksi Anda |
Kebijakan jaringan terarah memisahkan:
- Egress dari beban kerja ke tujuan jaringan.
- Ingress dari jaringan privat atau lokal ke listener dalam workload.
- Loopback host antara workload dan layanan pada host, di kedua arah.
IP/CIDR dan aturan port tidak mengidentifikasi protokol aplikasi atau nama host. Mengizinkan port TCP 443 tidak memastikan bahwa koneksi menggunakan HTTPS atau hanya mencapai satu layanan bernama. Permintaan DNS juga dapat memerlukan akses saat beban kerja melakukan resolusi tujuan secara langsung.
Skema yang didukung menolak bidang jaringan yang dihentikan, seperti defaultPolicy, blockedHosts, allowedHosts, dan network.proxy. Gunakan kolom arah egress dan ingress sebagai gantinya. Lihat contoh kebijakan jaringan.
Menggunakan proksi jaringan kustom
aplikasi host Anda menyediakan dan memulai proksi sebelum memulai beban kerja. MXC tidak menyediakan atau mengelola proksi produksi. Proksi menentukan permintaan dan tujuan mana yang diizinkan; MXC mengonfigurasi klien yang didukung untuk menggunakannya dan menerapkan pembatasan jaringan backend.
Permintaan terarah menggunakan pengaturan runtimeConfig.networkProxy bagian jaringan untuk mengidentifikasi titik akhir loopback HTTP(S) dengan port eksplisit. Dalam konfigurasi eksekusi mentah, pengaturan ini adalah runtimeConfig.networkProxy tingkat atas. Endpoint ini adalah konfigurasi runtime, bukan allowlist lapisan aplikasi. Mode proksi memerlukan egress default-deny dan tidak dapat dikombinasikan dengan aturan izinkan atau tolak direct egress.
Perutean dan penegakan klien berbeda. Variabel lingkungan proksi atau pengaturan platform memberi tahu klien HTTP yang mendukung pengaturan ini tempat mengirim permintaan. Jalur enforcement khusus proxy juga harus mencegah koneksi internet langsung; konfigurasi proxy kooperatif saja tidak memastikan pembatasan tersebut.
MXC tidak secara transparan mengalihkan SSH, TCP/UDP arbitrer, atau protokol non-HTTP lainnya melalui proksi HTTP(S). Perilaku host-loopback dan jaringan privat juga bervariasi menurut backend. Tinjau contoh konfigurasi proksi kustom dan prasyaratnya alih-alih mengasumsikan fragmen yang sama berfungsi di mana-mana.
Batasi akses UI
Secara default, jangan izinkan beban kerja latar belakang untuk membuat jendela, membaca atau menulis clipboard, atau menyuntikkan input keyboard dan penunjuk. Tambahkan akses UI hanya ketika merupakan bagian dari pengalaman pengguna yang dimaksudkan untuk beban kerja.
Input injection berarti masukan keyboard atau penunjuk sintetis, bukan injeksi kode arbitrer ke proses lain.
Kontrol UI bergantung pada host dan backend. Gunakan informasi dukungan runtime untuk memverifikasi setiap batasan yang disyaratkan oleh desain keamanan Anda.
Eksekusi terikat konteks
Atur batas waktu untuk setiap tindakan agen, panggilan alat, atau skrip yang harus selesai dalam periode yang diketahui. Hanya sediakan variabel lingkungan yang dibutuhkan proses, dan jauhkan rahasia dari keduanya, yaitu lingkungan proses dan jalur file yang dapat dibaca. Jangan berasumsi bahwa menghilangkan environment tidak berarti akan membuat environment kosong: default backend dan opsi pewarisan SDK berbeda.
Pilih siklus hidup yang cocok dengan tugas. Gunakan eksekusi sekali jalan untuk perintah yang independen. Gunakan sandbox yang menyadari status hanya ketika perintah harus berbagi alat yang terinstal, identitas, file, atau status sistem operasi.
Validasi kebijakan yang berlaku
Sebelum Anda mengirimkan polis:
- Gunakan penemuan runtime SDK Anda dan periksa prasyarat backend yang dipilih.
- Buat konfigurasi dan tangani kesalahan validasi kebijakan atau backend tidak tersedia tanpa melemahkan kebijakan.
- Jalankan kasus sukses yang representatif dengan sumber daya yang harus digunakan workload.
- Jalankan kasus negatif yang mencoba membaca rahasia, menulis di luar direktori output, menggunakan jalur jaringan yang tidak disetujui, atau mengakses UI yang tidak diizinkan.
- Gunakan Mode Pembelajaran untuk menyelidiki akses yang hilang, dan tinjau setiap hasil sebelum mengubah kebijakan.
- Hapus semua pengaturan pembelajaran atau audit dan jalankan satu uji penerapan akhir.
Gagal ketika host tidak dapat menerapkan kontrol yang diperlukan. Jangan memilih backend secara diam-diam dengan akses yang lebih luas atau menghapus bidang kebijakan untuk membuat beban kerja berjalan. Penguraian atau peluncuran yang berhasil bukanlah bukti bahwa setiap pembatasan yang dimaksudkan berlaku.
Konten terkait
Windows developer