Metode Enkripsi Terbaik untuk Keamanan AI API

Jika saya harus merangkumnya dalam satu kalimat: TLS 1.3 adalah dasarnya, mTLS membuktikan identitas mesin, dan enkripsi payload melindungi data yang masih penting setelah TLS berakhir.

Serangan AI API melonjak 681% dari paruh pertama 2022 ke paruh pertama 2023. Jadi jika saya mengamankan sebuah AI API, saya tidak mencari satu perbaikan. Saya melihat lapisan. Artikel ini membandingkan 7 metode enkripsi dari sisi poin-poin yang paling penting:

• cakupan keamanan
• biaya kinerja
• upaya manajemen kunci
• cakupan lapisan transport vs. aplikasi
• kecocokan untuk deployment di AS

Berikut versi singkatnya:

• Enkripsi simetris paling baik untuk payload besar dan data tersimpan.
• Enkripsi kunci-publik paling baik untuk pertukaran kunci dan tanda tangan.
• Enkripsi hibrida mencampur keduanya, jadi ia cocok untuk sebagian besar kasus penggunaan lapisan aplikasi.
• TLS 1.2/1.3 melindungi data dalam transit, dengan TLS 1.3 sebagai default.
• mTLS memeriksa kedua sisi sebuah koneksi.
• Enkripsi tingkat-bidang hanya melindungi bidang yang harus tetap tersembunyi.
• Enkripsi amplop membuat rotasi kunci berskala besar jauh lebih mudah.

Poin utamanya: keamanan transport berhenti di terminasi TLS. Jika prompt, gambar, audio, log, antrean, atau cadangan masih membutuhkan perlindungan setelah titik itu, saya membutuhkan lapisan lain.

Melindungi data sensitif di aplikasi AI

Perbandingan Cepat

Jadi jika Anda ingin jawaban singkat, ini dia: gunakan TLS 1.3 secara default, tambahkan mTLS untuk identitas layanan, dan gunakan enkripsi tingkat-bidang, hibrida, atau amplop ketika data harus tetap terlindungi di luar koneksi itu sendiri.

1. Enkripsi Simetris

Enkripsi simetris adalah cara cepat untuk melindungi data massal. Tetapi ia tidak menyelesaikan pertukaran kunci dengan sendirinya. Ia menggunakan satu kunci bersama untuk enkripsi maupun dekripsi, yang menjadikannya bagian inti dari keamanan AI API. Pilihan yang biasa adalah AES-256-GCM karena ia cepat dan menyertakan pemeriksaan integritas bawaan ^[4][10].

Cakupan Keamanan

AES-256-GCM bekerja dengan baik di dua tempat: data saat diam dan data dalam transit. Itu mencakup set pelatihan tersimpan, bobot model, keluaran terarsip, dan enkripsi massal yang digunakan di dalam TLS 1.3 ^[3][2]. Karena GCM adalah mode AEAD, ia melindungi kerahasiaan dan menambahkan tag autentikasi yang membantu mendeteksi perusakan pada prompt atau payload multi-modal ^[4].

Ada satu batas yang tidak bisa Anda abaikan: enkripsi simetris hanya melindungi data hingga mencapai model. Selama inferensi, model harus bekerja dengan teks biasa. Itu berarti data biasa masih dapat terekspos di RAM atau memori GPU ^[7].

Dampak Kinerja

AES-256-GCM dapat mencapai 4,2 GB/s pada CPU server standar yang mendukung AES-NI ^[8]. Dalam bahasa sederhana, mengenkripsi prompt kecil memakan waktu mikrodetik, yang jauh lebih sedikit daripada penundaan jaringan atau waktu jalan model ^[8].

Pada klien seluler atau perangkat edge tanpa AES-NI, ChaCha20-Poly1305 biasanya merupakan pilihan yang lebih baik. Ia disetel untuk kinerja perangkat lunak, mencapai 3,4 GB/s pada perangkat keras seperti Apple A17 Pro, dan memberikan tingkat keamanan 256-bit yang sama ^[8].

Manajemen Kunci

Ini tangkapannya: kedua sisi membutuhkan rahasia yang sama. Jadi bagian yang sulit adalah membagikan kunci itu dengan aman, yang biasanya berarti mendatangkan kriptografi asimetris.

Dalam skala besar, tim sering membungkus kunci simetris dengan KEK sehingga mereka dapat mengganti kunci data tanpa mengenkripsi ulang seluruh payload ^[2][11]. Rotasi KEK harus diotomatisasi, dan kunci harus disimpan di FIPS 140-3 Level 3 validated HSM atau pengelola rahasia khusus - bukan di berkas konfigurasi atau kode sumber aplikasi ^[11][10].

Persoalan kunci-bersama itulah tepatnya mengapa enkripsi asimetris menyusul berikutnya.

Kasus Penggunaan AI API yang Paling Cocok

Enkripsi simetris adalah pilihan yang tepat untuk payload massal. Pikirkan gambar resolusi tinggi, berkas video, klip audio panjang, dan body permintaan JSON besar ^[4]. Ia juga bekerja baik untuk pengarsipan jangka panjang dan isolasi per-tenant, di mana DEK dibungkus dengan kunci khusus tenant untuk menjaga data tetap terpisah ^[2][10].

Untuk transport dan pertukaran kunci, meski begitu, enkripsi simetris hanyalah satu bagian dari tumpukan.

2. Enkripsi Asimetris

Enkripsi asimetris mencakup bagian yang tidak ditangani dengan baik oleh enkripsi simetris: pertukaran kunci yang aman dan pemeriksaan identitas. Ia menggunakan dua kunci yang saling terkait:

• sebuah kunci publik yang dapat diakses siapa saja
• sebuah kunci privat yang hanya disimpan pemiliknya

Jika data dienkripsi dengan kunci publik, hanya kunci privat yang cocok yang dapat mendekripsinya.

Cakupan Keamanan

Enkripsi asimetris penting karena ia dapat menjaga payload sensitif tetap terlindungi setelah TLS berakhir. TLS mengamankan lalu lintas untuk hop pertama itu. Tetapi begitu lalu lintas bergerak melewatinya, lapisan itu hilang.

Di situlah enkripsi tingkat-pesan berperan. Ketika Anda mengenkripsi data dengan kunci asimetris, konten sensitif - seperti PII di dalam sebuah prompt - dapat tetap terenkripsi saat bergerak melalui sistem logging internal, service mesh, dan alur tracing terdistribusi ^[4][12].

Ia juga mendukung tanda tangan digital. Tanda tangan tersebut membantu memverifikasi bahwa sebuah prompt datang dari pengirim yang diklaim dan memberikan non-repudiation ^[4].

Trade-off-nya sederhana: tingkat perlindungan ini memakan biaya komputasi yang jauh lebih besar.

Dampak Kinerja

Enkripsi asimetris terlalu lambat untuk payload besar seperti gambar, video, atau audio. Gunakan untuk kunci dan tanda tangan, bukan data massal ^[14].

Untuk tanda tangan, ECC dan Ed25519 berkinerja lebih baik daripada RSA dan lebih cocok untuk autentikasi AI API modern ^[14].

Manajemen Kunci

Kunci privat harus disimpan di FIPS 140-3 Level 3 validated HSM atau Trusted Execution Environment (TEE) ^[10]. Kunci publik sering dibagikan melalui JWKS (JSON Web Key Set) endpoint, yang memungkinkan mitra API menemukan dan memeriksa kunci secara otomatis ^[5].

Rotasi kunci harus terjadi pada siklus 90-hari untuk membatasi kerusakan jika sebuah kunci disusupi ^[5].

Selisih biaya di sini sulit diabaikan. Di AWS KMS, operasi RSA asimetris dapat menelan biaya hingga $12.00 per 10,000 requests, sementara operasi simetris menelan biaya sekitar $0.03 per 10,000 requests ^[14].

Kasus Penggunaan AI API yang Paling Cocok

Enkripsi asimetris bekerja paling baik untuk pertukaran kunci dan autentikasi. Dalam AI API multi-tenant, ia paling sering digunakan untuk membungkus kunci simetris dan memverifikasi keaslian prompt ^[4]. Ia juga mendukung autentikasi klien melalui mTLS ^[1].

Ada masalah lain yang perlu tim rencanakan sekarang: migrasi pasca-kuantum. RSA dan ECC standar akan rentan terhadap serangan kuantum di masa depan. NIST memfinalkan standar kriptografi pasca-kuantum pertamanya - FIPS 203, 204, dan 205 - pada Agustus 2024, dan tolok ukur awal menunjukkan ML-KEM menambahkan overhead kinerja kurang dari 5% dibandingkan dengan RSA-2048 pada perangkat keras server standar ^[3][10].

Dalam praktiknya, enkripsi asimetris melindungi kunci, sementara enkripsi simetris melindungi payload.

3. Enkripsi Hibrida

Enkripsi hibrida melindungi payload dengan DEK simetris acak, lalu membungkus DEK itu dengan kunci publik asimetris. Sederhananya, ia menggunakan bagian cepat dari enkripsi untuk data itu sendiri dan bagian kunci-publik untuk kuncinya. Ini paling penting setelah TLS berakhir, ketika data mungkin masih melewati sistem internal.

Cakupan Keamanan

Enkripsi hibrida menjaga payload tetap terenkripsi bahkan setelah terminasi TLS, termasuk di dalam service mesh, proxy, dan log. Setiap permintaan mendapatkan DEK berumur pendeknya sendiri, yang memangkas radius ledakan jika satu kunci terekspos.

Menggunakan AES-256-GCM juga menambahkan tag autentikasi. Tag itu membantu menangkap perusakan sebelum sistem AI menyentuh payload. Untuk transport, lapisan ini bekerja bersama TLS, bukan menggantikannya.

Dampak Kinerja

Dalam penyiapan hibrida, langkah asimetris hanya membungkus DEK. AES melakukan pekerjaan berat untuk payload itu sendiri. Itu membuat model bekerja baik untuk permintaan multi-modal besar, seperti video, gambar resolusi tinggi, dan aliran audio, tanpa memperlambat segalanya hingga merangkak dalam skala besar.

Manajemen Kunci

Simpan KEK di HSM, hasilkan DEK berumur pendek untuk setiap permintaan, dan lampirkan key_id sehingga DEK dapat dibungkus ulang tanpa mengenkripsi ulang payload. Penyiapan itu membuat rotasi kunci jauh tidak menyakitkan.

Untuk platform AI multi-tenant, ia juga mendukung crypto-shredding. Jika Anda menghancurkan kunci master milik sebuah tenant, semua payload terenkripsi yang terkait menjadi tidak dapat dibaca, tanpa menyentuh setiap catatan atau cadangan satu per satu.

Kasus Penggunaan AI API yang Paling Cocok

Enkripsi hibrida masuk akal untuk jalur AI API di mana data melintasi batas kepercayaan setelah TLS berakhir, seperti:

• arsitektur multi-hop
• reverse proxy
• load balancer
• service mesh

Ia juga cocok untuk alur kerja zero-knowledge di mana penyedia tidak pernah menangani teks biasa.

Untuk migrasi pasca-kuantum, hanya lapisan pembungkus yang perlu berubah. Mengganti RSA atau ECDH dengan ML-KEM (FIPS 203) membantu melindungi ciphertext tersimpan yang bisa didekripsi belakangan, sementara lapisan simetris AES-256 tetap sama ^[10]. Enkripsi hibrida menangani perlindungan payload melampaui TLS; lapisan berikutnya adalah autentikasi transport dengan TLS dan mTLS.

4. TLS 1.2/1.3

TLS adalah lapisan keamanan transport dasar untuk AI API apa pun. TLS 1.3 harus menjadi default. Jika enkripsi hibrida melindungi data di luar tepi jaringan, TLS melindungi perjalanan melintasi jaringan itu sendiri. Sederhananya: TLS mengamankan data dalam transit, sementara enkripsi payload mencakup apa yang mungkin masih terekspos setelah TLS berakhir.

Cakupan Keamanan

TLS 1.3 membuang suite cipher lawas yang lemah seperti RC4, DES, dan 3DES. TLS 1.2 masih dapat mengizinkannya jika Anda tidak mematikannya sendiri ^[10][18]. TLS 1.3 juga mensyaratkan Perfect Forward Secrecy (PFS) dan mengenkripsi sertifikat klien selama handshake, yang membuat pemantauan pasif atas hubungan layanan internal jauh lebih sulit ^[15][17].

Dampak Kinerja

TLS 1.3 mengurangi handshake dari 2 RTT menjadi 1 ^[15][9]. Itu mungkin terdengar kecil, tetapi pada beban kerja frekuensi tinggi seperti streaming audio atau video real-time, ia membantu memangkas latensi p99 dan meringankan beban CPU.

TLS 1.3 juga mengizinkan resumption 0-RTT, sehingga sesi yang dilanjutkan dapat mengirim data segera. Itu cepat, tetapi ada trade-off: 0-RTT memiliki risiko replay. Untuk rute API yang sensitif, nonaktifkan 0-RTT ^[16].

Manajemen Kunci

Penanganan sertifikat adalah tempat banyak tim tetap tajam atau menjadi ceroboh. Jalur yang lebih aman itu sederhana:

• Rotasi sertifikat setiap 90 hari ^[16][9]
• Gunakan penerbitan otomatis untuk endpoint publik seperti Let's Encrypt ^[1]
• Simpan kunci privat di HSM atau TEE, bukan berkas PEM yang dapat diekspor ^[3][10]
• Dalam penyiapan yang teregulasi, gunakan modul FIPS 140-3 validated ^[10]
• Jika TLS 1.2 tidak dapat ditingkatkan, izinkan hanya suite cipher berbasis ECDHE sehingga forward secrecy tetap ada ^[10]
• Aktifkan OCSP stapling sehingga pemeriksaan sertifikat lebih cepat dan tidak menambah round trip jaringan lain selama handshake ^[9]

Kasus Penggunaan AI API yang Paling Cocok

TLS 1.3 adalah default yang tepat untuk endpoint publik, aplikasi browser, dan aliran WebSocket multimodal real-time ^[15][16]. TLS 1.2 masih dapat diterima sebagai batas kompatibilitas untuk integrasi enterprise yang lebih tua, tetapi hanya jika ia dikunci ketat pada suite cipher khusus-PFS ^[10].

Untuk lalu lintas antar-layanan, mTLS menambahkan verifikasi identitas.

5. Mutual TLS (mTLS)

mTLS dibangun di atas TLS dengan memeriksa kedua klien dan server dengan sertifikat sebelum data aplikasi apa pun dikirim.

Cakupan Keamanan

Ini mengisi celah yang ditinggalkan kunci API. Sebuah kunci API membuktikan sebuah rahasia. Ia tidak membuktikan beban kerja mana yang melakukan panggilan.

Untuk agen AI, microservice, dan identitas beban kerja lainnya, mTLS membatasi akses ke layanan yang terverifikasi. Itu penting pada endpoint model yang sensitif dan ketika sistem bertukar data multimodal seperti gambar dan suara ^[15][13][20].

Dampak Kinerja

Kelemahan utamanya adalah pekerjaan handshake tambahan. mTLS biasanya menambahkan sekitar 1–2 milidetik latensi dan 5–10% lebih banyak waktu handshake daripada TLS standar ^[21].

Cara umum untuk mengurangi dampak itu adalah menerminasi mTLS di gateway API atau firewall edge. Itu menjauhkan pekerjaan kripto asimetris dari waktu jalan model ^[17][15]. Connection pooling dan header keep-alive juga membantu menyebar biaya itu ke banyak permintaan alih-alih membayarnya dari awal setiap kali ^[21].

Manajemen Kunci

mTLS membutuhkan proses PKI yang kuat untuk penerbitan, rotasi, dan pencabutan sertifikat ^[6][19]. Bagian ini tidak bisa ditangani sembarangan. Jika pembaruan sertifikat terlewat, lalu lintas antar-layanan dapat gagal seketika ^[19].

Gunakan perkakas PKI otomatis untuk menangani penerbitan, rotasi, dan pencabutan dalam skala besar. Untuk kunci privat, penyimpanan berbasis perangkat keras seperti HSM atau TPM melalui PKCS#11 membantu menjaga kunci tetap tidak-dapat-diekspor ^[13]. Sertifikat berumur pendek juga memangkas risiko. SPIFFE merekomendasikan masa berlaku sesingkat 1 jam untuk identitas beban kerja ^[21].

Kasus Penggunaan AI API yang Paling Cocok

mTLS bekerja paling baik untuk lalu lintas mesin-ke-mesin. Pikirkan agen AI yang memanggil basis data internal, microservice yang mengoper data multimodal sensitif, dan integrasi teregulasi yang membutuhkan bukti kriptografis asal-usul. Dalam penyiapan ini, mTLS bertindak sebagai lapisan auth tambahan di samping autentikasi kunci API ^[15][20].

Gunakan mTLS untuk identitas di lapisan koneksi. Gunakan enkripsi tingkat-bidang ketika bidang tertentu harus tetap terlindungi bahkan setelah transport.

6. Enkripsi Tingkat-Bidang

mTLS memberitahu Anda siapa yang memanggil. Enkripsi tingkat-bidang melindungi nilai-nilai sensitif di dalam apa yang mereka kirim.

Perbedaan kuncinya sederhana: alih-alih mengenkripsi seluruh payload, enkripsi tingkat-bidang hanya mencakup bidang yang harus tetap tersembunyi setelah transport berakhir. Itu berarti perlindungan tetap penting bahkan setelah TLS dan mTLS menyelesaikan bagian mereka.

Cakupan Keamanan

TLS melindungi data dalam transit. Enkripsi tingkat-bidang melindungi data itu sendiri setelah TLS berakhir.

Pendekatan ini hanya mengenkripsi bidang yang membutuhkan perhatian ekstra, seperti nomor Jaminan Sosial, catatan medis, dan nomor kartu pembayaran lengkap. Akibatnya, nilai-nilai tersebut tetap terenkripsi di tempat data sering tertinggal, seperti log, antrean, cadangan, dan dump basis data.

Ada trade-off, meski begitu. Model hanya dapat bekerja dengan bidang yang dibiarkan dalam teks biasa. Jadi jika model membutuhkan sebuah nilai untuk menjalankan tugasnya, bidang itu tidak bisa tetap terenkripsi saat inferensi. Dalam praktiknya, itu berarti Anda hanya boleh mengenkripsi apa yang tidak dibutuhkan model. Ada juga biaya pemrosesan kecil untuk setiap bidang yang dilindungi.

Dampak Kinerja

Enkripsi tingkat-bidang biasanya menambahkan 5% hingga 10% latensi karena setiap bidang yang dilindungi harus dienkripsi dan didekripsi secara terpisah.

Biaya itu biasanya baik-baik saja, tetapi hanya jika penanganan kunci dan ID bidang dijaga bersih. Jika tidak, overhead dapat menumpuk dengan cepat.

Manajemen Kunci

Enkripsi tingkat-bidang datang dengan tiga kontrol yang paling penting:

• Gunakan isolasi kunci per-tenant. Jika semua tenant berbagi satu kunci, satu penyusupan dapat mengekspos data semua orang ^[10].
• Sertakan Key ID atau tag versi di samping setiap bidang terenkripsi sehingga data lawas masih dapat didekripsi setelah rotasi tanpa merusak catatan yang ada ^[1].
• Gunakan kunci bidang per-tenant untuk membatasi paparan jika satu tenant disusupi.

Kasus Penggunaan AI API yang Paling Cocok

Enkripsi tingkat-bidang bekerja paling baik ketika hanya sebagian kecil dari prompt yang harus tetap rahasia, sementara sisanya masih perlu tetap dapat digunakan oleh model.

• AI SaaS multi-tenant - kunci per-tenant membatasi radius ledakan jika satu tenant disusupi.
• Alur logging eksternal - PII tetap terenkripsi bahkan ketika log dikirim ke luar platform.
• AI API layanan kesehatan atau keuangan - bidang sensitif tetap terenkripsi di log, dump basis data, antrean, dan cadangan.
• Alur kerja inferensi-parsial - model hanya membaca bidang yang tidak sensitif.

7. Enkripsi Amplop

Enkripsi amplop adalah cara praktis untuk melindungi payload besar tanpa menjadikan rotasi kunci sebagai mimpi buruk. Idenya sederhana: Anda mengenkripsi data dengan DEK, lalu mengenkripsi DEK itu dengan KEK.

Beginilah cara kerjanya dalam bahasa sederhana. Sebuah Data Encryption Key (DEK) acak mengenkripsi payload AI yang sebenarnya, entah itu teks, gambar, atau berkas video, menggunakan enkripsi simetris cepat seperti AES-256. Lalu sebuah Key Encryption Key (KEK), disimpan di KMS atau HSM, mengenkripsi DEK itu sendiri. Objek yang Anda simpan atau kirim mencakup dua hal: payload terenkripsi dan DEK yang dibungkus. Penyiapan itu menjadikan enkripsi amplop kecocokan yang baik ketika ukuran payload dan rotasi kunci lebih penting daripada kontrol per-bidang.

Cakupan Keamanan

Enkripsi amplop melindungi data di lapisan aplikasi. Jadi bahkan setelah TLS berakhir, payload tetap terlindungi di tempat seperti log, antrean, dan cadangan.

Ada satu batas yang tidak bisa Anda abaikan: data masih harus didekripsi di memori selama inferensi AI. Kecuali Anda memasangkan enkripsi amplop dengan Confidential Computing, seperti TEE, masih ada jendela di mana teks biasa berada di memori GPU atau CPU ^[3][7]. Itu trade-off-nya. Kemenangan besar muncul ketika Anda berurusan dengan data dalam skala besar dan tidak ingin mengenkripsi ulang sejumlah besar dari itu setiap kali kunci berubah.

Dampak Kinerja

Enkripsi amplop jauh lebih praktis daripada enkripsi asimetris langsung. Mengapa? Karena AES-GCM menangani pekerjaan berat pada payload, sementara kripto asimetris hanya melindungi DEK kecil.

Penyiapan itu menambahkan sekitar 3% hingga 7% overhead di beberapa lingkungan ^[5].

Untuk AI API multi-modal yang memproses gambar atau video resolusi tinggi, AES-GCM adalah pilihan kuat karena ia menyediakan enkripsi terautentikasi, atau AEAD. Singkatnya, ia membantu mengonfirmasi payload tidak diubah dalam transit ^[4].

Manajemen Kunci

Di sinilah enkripsi amplop bersinar. Korpus pelatihan AI dapat tumbuh hingga terabyte atau bahkan petabyte ^[2]. Mengenkripsi ulang seluruh kumpulan data setiap kali sebuah kunci berubah akan menjadi tugas operasional yang brutal.

Dengan enkripsi amplop, Anda tidak menyentuh payload. Anda cukup membungkus ulang DEK kecil dengan KEK baru ^[2].

Beberapa aturan dasar penting di sini:

• Simpan KEK di KMS atau HSM cloud-native, bukan di variabel lingkungan aplikasi.
• Tambahkan metadata versi ke catatan berumur panjang sehingga data lebih lama masih dapat didekripsi setelah perubahan kunci ^[1].

Kasus Penggunaan AI API yang Paling Cocok

Enkripsi amplop bekerja baik untuk payload besar, isolasi multi-tenant, dan data tersimpan berumur panjang di mana rotasi kunci perlu tetap waras. Jika payload besar, disimpan lama, atau mahal untuk diproses ulang, pola ini biasanya masuk akal.

Kelebihan dan Kekurangan berdasarkan Skenario Deployment

Tidak ada satu metode enkripsi pun yang cocok untuk setiap kasus. Pilihan yang tepat bergantung pada apa yang Anda lindungi - teks, gambar, audio, video, dan metadata teregulasi - ke mana data itu bergerak, dan seberapa banyak latensi yang dapat Anda toleransi. Matriks di bawah menggunakan lensa yang sama seperti bagian sebelumnya: cakupan, latensi, manajemen kunci, dan apakah perlindungan masih bertahan setelah terminasi.

Tabel ini mengubah perbandingan metode-demi-metode sebelumnya menjadi pilihan deployment.

Skenario-skenario ini memperjelas satu hal: keamanan transport punya titik berhenti, dan perlindungan lapisan-aplikasi dimulai di tempat transport berakhir.

Gunakan perlindungan hanya-transport ketika data tetap berada di dalam batas tepercaya dan tidak membutuhkan perlindungan setelah terminasi TLS. Begitu TLS berakhir, teks biasa mencapai layanan yang memprosesnya. Itulah celah yang dimaksudkan untuk ditutup oleh enkripsi lapisan-aplikasi.

Untuk beban kerja multi-modal teregulasi, tumpukan default biasanya:

• TLS 1.3 untuk transport
• mTLS untuk identitas
• Enkripsi tingkat-bidang atau amplop untuk data yang harus tetap terlindungi setelah terminasi

Tumpukan berlapis itu adalah default praktis untuk AI API teregulasi.

Gunakan masking, bukan enkripsi, ketika model membutuhkan konteks bidang tetapi bukan nilai mentahnya sendiri. Masking menjaga makna. Enkripsi menghapusnya. Sebagai contoh, mengganti [email protected] dengan [EMAIL] tetap memungkinkan model membaca kalimat dengan benar tanpa pernah melihat alamat sebenarnya.

Kesimpulan

Tidak ada satu metode enkripsi pun yang melakukan semuanya. Pilihan bermuara pada cakupan, latensi, dan satu pertanyaan sederhana: di mana data Anda masih terekspos setelah TLS berakhir? Dalam praktiknya, keputusan jatuh ke dalam tiga lapisan: transport, identitas, dan perlindungan payload.

TLS 1.3 adalah lapisan transport default untuk AI API. TLS 1.2 hanya boleh digunakan sebagai cadangan untuk sistem lawas. Dari sana, metode lain masuk untuk menutup celah yang ditinggalkan TLS. Enkripsi hibrida adalah model paling praktis di lapisan aplikasi karena ia menyelesaikan distribusi kunci tanpa memperlambat enkripsi massal. Gunakan mTLS untuk memverifikasi identitas mesin. Lalu gunakan enkripsi tingkat-bidang atau amplop untuk data yang perlu tetap terlindungi bahkan setelah TLS terminasi. Enkripsi amplop terutama berguna untuk beban kerja AI besar karena merotasi KEK menghindari enkripsi ulang petabyte data ^[2].

Ketika Anda menyatukan lapisan-lapisan ini, mereka melindungi seluruh jalur permintaan. Dalam deployment keamanan-tinggi, pelapisan bukan opsional: TLS menangani transport, mTLS menangani identitas, dan enkripsi tingkat-bidang atau amplop melindungi data yang harus tetap aman setelah TLS berakhir.

Pertanyaan yang Sering Diajukan

Kapan TLS 1.3 tidak cukup?

TLS 1.3 membantu melindungi data saat ia bergerak antar sistem. Tetapi perlindungan itu berhenti di batas server.

Begitu data mencapai server AI, ia harus didekripsi agar model dapat memprosesnya. Dan itu menciptakan celah: data kemudian dapat terekspos di memori, log, atau cache.

Itulah sebabnya TLS 1.3 saja tidak cukup ketika data membutuhkan perlindungan di luar transit.

Ia juga tidak menangani beberapa masalah lain:

• Integritas data di seluruh siklus hidup payload
• Keaslian pihak yang melakukan komputasi, sehingga Anda tahu siapa yang memproses data
• Perlindungan jangka panjang terhadap serangan berbasis kuantum

Jadi jika Anda membutuhkan kontrol yang lebih ketat, Anda akan menginginkan lapisan ekstra di atas TLS 1.3, seperti enkripsi tingkat-payload dan token bertanda tangan.

Haruskah saya menggunakan mTLS untuk setiap AI API?

Tidak selalu. Apakah Anda harus menggunakan mTLS untuk setiap AI API bermuara pada kebutuhan keamanan Anda dan seberapa banyak kompleksitas yang dapat ditangani penyiapan Anda.

Ia paling masuk akal untuk koneksi bernilai-tinggi. Itu mencakup lalu lintas antar-layanan internal, API administratif, dan transfer yang melibatkan data sensitif. Dalam banyak kasus, penyiapan berjenjang bekerja paling baik: gunakan TLS 1.3 standar untuk lalu lintas umum, dan wajibkan mTLS hanya pada rute sensitif.

Bagaimana saya memilih antara enkripsi tingkat-bidang dan amplop?

Pilih enkripsi tingkat-bidang ketika Anda membutuhkan perlindungan ketat untuk nilai sensitif spesifik, seperti token API atau pengenal pribadi. Ia menjaga nilai-nilai tersebut tetap terenkripsi bahkan ketika muncul di log, cache, atau cadangan. Itu membantu membatasi kerusakan dari sebuah pelanggaran dan dapat mendukung kebutuhan kepatuhan.

Pilih enkripsi amplop ketika Anda membutuhkan perlindungan efisien untuk payload yang lebih besar. Ia mengenkripsi data dengan DEK, lalu membungkus kunci itu dengan KEK. Penyiapan ini membuat rotasi kunci dan manajemen kunci lebih mudah.