Lewati ke konten utama

Persyaratan Keamanan Program Verifikasi Siber

Pelanggan harus memenuhi dan mempertahankan persyaratan keamanan berikut untuk setiap tingkat akses Program Verifikasi Siber yang dimiliki Pelanggan ("Tingkat Akses"). Persyaratan ini berlaku untuk Pengguna yang Disetujui dan untuk Ruang Kerja yang Diberikan.

1. Semua Tingkat Akses.

  1. Kontak Keamanan. Pelanggan harus menyediakan Anthropic dengan kontak keamanan bernama yang dapat menerima peringatan keamanan dan penyalahgunaan serta mampu bertindak atas peringatan tersebut.

  2. Pelaporan Insiden. Pelanggan harus melaporkan dugaan pelanggaran atau penyalahgunaan yang melibatkan hibah kepada Anthropic dalam waktu 72 jam, atau dalam waktu 24 jam untuk insiden keamanan. Pelaporan dapat dilakukan di [email protected] atau kontak tim Akun Anda.

  3. Kerja Sama. Pelanggan harus menyelidiki penyalahgunaan apa pun yang diidentifikasi Anthropic dalam waktu 48 jam, bekerja sama dengan Anthropic untuk memperbaikinya, dan merespons pertanyaan penyalahgunaan dalam waktu tujuh (7) hari.

  4. Akses Pribadi. Setiap Pengguna yang Disetujui harus masuk sebagai diri mereka sendiri. Masuk bersama, kursi bersama, sesi bersama, dan identitas beban kerja, serta ekstensi browser atau alat proxy yang mengekspos sesi kepada orang lain yang bukan secara eksplisit Pengguna yang Disetujui memenuhi semua persyaratan di bawah, tidak diizinkan.

  5. Atribusi Penggunaan. Profil pengguna harus tetap diaktifkan di Ruang Kerja yang Diberikan sehingga permintaan dapat dikaitkan dengan pengguna bernama atau identitas beban kerja.

  6. Pemberitahuan Perubahan. Pelanggan harus memberitahu Anthropic dalam waktu tiga puluh (30) hari tentang perubahan material pada postur keamanan, kepemilikan, kantor pusat, atau kontak keamanannya.

  7. Tinjauan Berkelanjutan. Anthropic dapat meminta agar Pelanggan memberikan bukti kepatuhan terhadap Persyaratan Keamanan Program Verifikasi Siber ini.

2. Akses Pertahanan.

  1. Autentikasi Multi-Faktor. Pada saat akses Pelanggan ke CVP, semua akun yang dapat masuk ke Ruang Kerja yang Diberikan, atau menyimpan kredensial untuknya, harus memiliki autentikasi multi-faktor diaktifkan. Pada 15 Desember 2026 ("Tanggal Batas"), semua akun tersebut harus menggunakan autentikasi multi-faktor yang tahan terhadap phishing seperti yang didefinisikan dalam lembar fakta CISA "Implementing Phishing-Resistant MFA" dan dengan NIST SP 800-63B-4, artinya (i) kunci keamanan FIDO2/WebAuthn, (ii) passkey, di perangkat atau di pengelola kata sandi, atau (iii) smartcard/PIV, dan masuk dengan tautan ajaib email harus dinonaktifkan. SMS, suara, kode yang dikirim email, kode aplikasi autentikator, dan persetujuan push tidak memenuhi syarat.

  2. Manajemen Kredensial. Pada Tanggal Batas, kredensial statis yang diunduh, diekspor, atau sebaliknya berumur panjang, termasuk kunci API, tidak boleh digunakan untuk mengakses model. Persyaratan berikut berlaku untuk Pelanggan berdasarkan platform penerapan melalui mana Pelanggan mengakses model. Untuk setiap platform yang berlaku, semua Pengguna yang Disetujui dan semua beban kerja harus melakukan autentikasi menggunakan kredensial berumur pendek yang dikeluarkan dan dikelola oleh layanan identitas asli platform tersebut.

    1. Anthropic (API pihak pertama dan Konsol). Kunci API statis atau berumur panjang tidak diizinkan, termasuk untuk akses interaktif ke Konsol Claude, Claude untuk Enterprise, Claude Code, dan permukaan aplikasi Anthropic lainnya.

    2. Google Vertex. File kunci JSON akun layanan yang diunduh tidak diizinkan.

    3. Amazon Web Services (Amazon Bedrock). Pasangan kunci akses pengguna IAM (ID kunci akses dan kunci akses rahasia) tidak diizinkan, dengan pengecualian kunci API Bedrock jangka pendek yang kedaluwarsa dalam 12 jam atau durasi sesi Bedrock, mana yang lebih pendek.

    4. Microsoft Azure (Azure AI Foundry). Kunci API dan rahasia klien prinsipal layanan yang diekspor atau sertifikat tidak diizinkan.

  3. Kunci API Sementara. Hingga Tanggal Batas, kunci API diizinkan di bawah hibah Akses Pertahanan hanya jika setiap kunci adalah (i) disimpan di pengelola rahasia atau pengelola kata sandi, (ii) ditugaskan kepada satu orang atau beban kerja, (iii) disimpan di luar kode sumber, dan (iv) diganti setidaknya setiap 7 hari. Anthropic dapat membatasi masa pakai kunci API di bawah hibah Akses Pertahanan hingga 7 hari, dan dapat menonaktifkan kunci API di Ruang Kerja yang Diberikan dari Tanggal Batas.

  4. Pengguna yang Disetujui. Tidak ada batasan default pada jumlah Pengguna yang Disetujui di Tingkat Akses ini.

3. Akses Pertahanan untuk Individu.

  1. Individu hanya memenuhi syarat untuk Akses Pertahanan. Jika hibah dipegang oleh individu, bagian ini berlaku

    1. Autentikasi Multi-Faktor. Individu harus masuk ke akun Anthropic yang memegang hibah hanya melalui Google atau penyedia identitas yang setara. Sejak tanggal akses diberikan, akun tersebut harus memiliki autentikasi multi-faktor diaktifkan. Pada 15 Desember 2026 ("Tanggal Batas"), akun tersebut harus menggunakan autentikasi multi-faktor yang tahan terhadap phishing, artinya kunci keamanan, passkey, atau smartcard/PIV, dan individu tidak boleh menggunakan masuk dengan tautan ajaib email. SMS, suara, kode yang dikirim email, kode aplikasi autentikator, dan persetujuan push tidak memenuhi syarat.

    2. Manajemen Kredensial. Pada Tanggal Batas, kredensial statis atau berumur panjang, termasuk kunci API, tidak boleh digunakan untuk mengakses model. Claude Code, Claude Console, dan claude.ai melakukan autentikasi melalui OAuth. Akses pemrograman untuk beban kerja, jika ditawarkan, harus menggunakan Workload Identity Federation. Hingga Tanggal Batas, satu kunci API diizinkan hanya jika (i) disimpan di pengelola kata sandi atau penyimpanan rahasia lokal, (ii) tidak pernah dibagikan atau ditempatkan dalam kode sumber, dan (iii) diganti setidaknya setiap 7 hari. Anthropic dapat membatasi masa pakai kunci API di bawah hibah hingga 7 hari, dan dapat menonaktifkan kunci API dari Tanggal Batas.

    3. Akses Pribadi. Individu adalah satu-satunya orang yang dapat menggunakan akses. Masuk bersama atau sesi bersama, dan ekstensi browser atau alat proxy yang mengekspos sesi kepada orang lain, tidak diizinkan.

    4. Pemantauan. Semua lalu lintas di bawah hibah disimpan dan dipantau. Retensi data nol tidak tersedia.

    5. Dari persyaratan Semua Tingkat Akses, Pelaporan Insiden, Kerja Sama, dan Tinjauan Berkelanjutan berlaku untuk individu.

4. Akses Tim Merah.

  1. Manajemen Kredensial. Persyaratan berikut berlaku untuk Pelanggan berdasarkan platform penerapan melalui mana Pelanggan mengakses model. Untuk setiap platform yang berlaku, semua Pengguna yang Disetujui dan semua beban kerja harus melakukan autentikasi menggunakan kredensial berumur pendek yang dikeluarkan dan dikelola oleh layanan identitas asli platform tersebut.

    1. Anthropic (API pihak pertama dan Konsol). Kunci API statis atau berumur panjang tidak diizinkan, termasuk untuk akses interaktif ke Konsol Claude, Claude untuk Enterprise, Claude Code, dan permukaan aplikasi Anthropic lainnya.

    2. Google Vertex. File kunci JSON akun layanan yang diunduh tidak diizinkan.

    3. Amazon Web Services (Amazon Bedrock). Pasangan kunci akses pengguna IAM (ID kunci akses dan kunci akses rahasia) tidak diizinkan, dengan pengecualian kunci API Bedrock jangka pendek yang kedaluwarsa dalam 12 jam atau durasi sesi Bedrock, mana yang lebih pendek.

    4. Microsoft Azure (Azure AI Foundry). Kunci API dan rahasia klien prinsipal layanan yang diekspor atau sertifikat tidak diizinkan.

  2. Autentikasi Multi-Faktor. Pada saat akses Pelanggan ke CVP, autentikasi multi-faktor yang tahan terhadap phishing harus melindungi (i) semua akun yang dapat masuk ke Ruang Kerja yang Diberikan atau menyimpan kredensial untuknya, (ii) akun Pengguna yang Disetujui di penyedia identitas Pelanggan, (iii) identitas AWS, Google Cloud, atau Azure yang dapat memanggil model, (iv) akses administratif ke apa pun yang mengeluarkan atau menyimpan kredensial model, dan (v) desktop virtual atau enclave apa pun yang digunakan untuk memenuhi persyaratan ini. Autentikasi multi-faktor yang tahan terhadap phishing berarti (i) kunci keamanan FIDO2/WebAuthn, (ii) passkey, di perangkat atau di pengelola kata sandi, atau (iii) smartcard/PIV, konsisten dengan lembar fakta CISA "Implementing Phishing-Resistant MFA" dan NIST SP 800-63B-4. SMS, suara, kode yang dikirim email, kode aplikasi autentikator, dan persetujuan push tidak memenuhi syarat, dan masuk dengan tautan ajaib email harus dinonaktifkan.

  3. Akun Organisasi. Pengguna yang Disetujui harus masuk dengan akun di domain Pelanggan. Akun pribadi dan webmail tidak diizinkan.

  4. Pengguna yang Disetujui. Ruang Kerja yang Diberikan terbatas pada tujuh puluh lima (75) Pengguna yang Disetujui yang secara pribadi melakukan atau langsung mengawasi pekerjaan yang disetujui hibah. Identitas beban kerja tidak dihitung terhadap jumlah tersebut. Pelanggan dapat meminta kursi Pengguna yang Disetujui tambahan secara tertulis (email sudah cukup). Hanya administrator bernama yang dapat menambahkan anggota, mengubah peran, atau membuat identitas beban kerja atau kredensial di Ruang Kerja yang Diberikan.

  5. Gateway. Jika Pelanggan mengoperasikan gateway atau proxy di depan model, itu harus mengakui hanya Pengguna yang Disetujui atau identitas beban kerja mereka, menggunakan kredensial berumur pendek miliknya sendiri, dan menjaga log dan transkrip terbatas pada Pengguna yang Disetujui dan tim keamanan, administrasi IT, atau kepercayaan dan keselamatan Pelanggan.

  6. Sistem Kredensial yang Dioperasikan Pelanggan. Kredensial yang dikeluarkan oleh sistem Pelanggan sendiri harus kedaluwarsa dalam 12 jam, harus dikeluarkan hanya setelah autentikasi multi-faktor yang tahan terhadap phishing (untuk orang) atau identitas beban kerja yang terverifikasi (untuk layanan), dan tidak boleh meninggalkan kredensial statis di endpoint, dalam kode sumber, atau di penyimpanan bersama. Kunci dan rahasia yang dapat mengeluarkan kredensial model harus disimpan di pengelola rahasia atau layanan manajemen kunci dengan pencatatan akses.

  7. Pencabutan. Pelanggan harus dapat mencabut kredensial atau identitas apa pun yang dikompromikan dalam waktu 24 jam.

  8. Offboarding. Pelanggan harus menghapus Pengguna yang Disetujui yang pergi atau ditugaskan kembali, dan identitas beban kerja mereka, dari Ruang Kerja yang Diberikan dalam tiga (3) hari kerja.

  9. Egress Jaringan. Di mana pun model melakukan pekerjaan ofensif atau agentic, lalu lintas keluar harus dibatasi pada daftar izin yang ditegakkan di luar host, dan harus dicatat. Workstation yang digunakan hanya untuk prompting interaktif dapat menggunakan daftar izin di host jika pekerjaan agentic itu sendiri berjalan di sandbox yang tidak dapat mengubah daftar tersebut.

  10. Perangkat Terkelola. Pengguna yang Disetujui harus menjangkau Ruang Kerja yang Diberikan hanya dari perangkat yang dikendalikan Pelanggan yang menerima pembaruan sistem operasi otomatis atau terjadwal secara teratur, bukan perangkat pribadi.

  11. Pemeriksaan Latar Belakang. Setiap Pengguna yang Disetujui, termasuk kontraktor, harus telah lulus pemeriksaan identitas dan, jika sah, pemeriksaan riwayat kriminal. Jika hukum lokal membatasi pemeriksaan kriminal, verifikasi identitas, hak kerja, atau ketenagakerjaan diterima. Pemeriksa pemerintah atau izin memenuhi persyaratan ini.

  12. Prosedur Insiden. Pelanggan harus mempertahankan prosedur terdokumentasi untuk dugaan kompromi atau penyalahgunaan hibah yang mencakup pencabutan kredensial dan penangguhan kursi.

  13. Entitas Pemerintah. FISMA Authority to Operate dengan penilaian Inspektur Jenderal independen tahunan terhadap NIST SP 800-53, atau skema nasional yang setara, memenuhi persyaratan Perangkat Terkelola, Pemeriksaan Latar Belakang, dan Prosedur Insiden. Semua persyaratan lainnya terus berlaku.

5. Akses Khusus.

  1. Autentikasi Multi-Faktor. Pada saat akses Pelanggan ke CVP, autentikasi multi-faktor yang tahan terhadap phishing harus melindungi (i) semua akun yang dapat masuk ke Ruang Kerja yang Diberikan atau menyimpan kredensial untuknya, (ii) akun Pengguna yang Disetujui di penyedia identitas Pelanggan, (iii) identitas AWS, Google Cloud, atau Azure yang dapat memanggil model, (iv) akses administratif ke apa pun yang mengeluarkan atau menyimpan kredensial model, dan (v) desktop virtual atau enclave apa pun yang digunakan untuk memenuhi persyaratan ini. Autentikasi multi-faktor yang tahan terhadap phishing berarti (i) kunci keamanan FIDO2/WebAuthn, (ii) passkey, di perangkat atau di pengelola kata sandi, atau (iii) smartcard/PIV, konsisten dengan lembar fakta CISA "Implementing Phishing-Resistant MFA" dan NIST SP 800-63B-4. SMS, suara, kode yang dikirim email, kode aplikasi autentikator, dan persetujuan push tidak memenuhi syarat, dan masuk dengan tautan ajaib email harus dinonaktifkan.

  2. Manajemen Kredensial. Persyaratan berikut berlaku untuk Pelanggan berdasarkan platform penerapan melalui mana Pelanggan mengakses model. Untuk setiap platform yang berlaku, semua Pengguna yang Disetujui dan semua beban kerja harus melakukan autentikasi menggunakan kredensial berumur pendek yang dikeluarkan dan dikelola oleh layanan identitas asli platform tersebut.

    1. Anthropic (API pihak pertama dan Konsol). Kunci API statis atau berumur panjang tidak diizinkan, termasuk untuk akses interaktif ke Konsol Claude, Claude untuk Enterprise, Claude Code, dan permukaan aplikasi Anthropic lainnya.

    2. Google Vertex. File kunci JSON akun layanan yang diunduh tidak diizinkan.

    3. Amazon Web Services (Amazon Bedrock). Pasangan kunci akses pengguna IAM (ID kunci akses dan kunci akses rahasia) tidak diizinkan, dengan pengecualian kunci API Bedrock jangka pendek yang kedaluwarsa dalam 12 jam atau durasi sesi Bedrock, mana yang lebih pendek.

    4. Microsoft Azure (Azure AI Foundry). Kunci API dan rahasia klien prinsipal layanan yang diekspor atau sertifikat tidak diizinkan.

  3. Masuk Tunggal dan Akun Organisasi. Pengguna yang Disetujui harus masuk dengan akun di domain Pelanggan sendiri. Pengguna yang Disetujui harus masuk dengan identitas domain organisasi yang difederasikan melalui masuk tunggal Pelanggan. Akun pribadi, webmail, dan non-federasi tidak diizinkan.

  4. Pengguna yang Disetujui. Ruang Kerja yang Diberikan terbatas pada 25 Pengguna yang Disetujui yang secara pribadi melakukan atau langsung mengawasi pekerjaan yang disetujui hibah. Identitas beban kerja tidak dihitung terhadap jumlah tersebut. Pelanggan dapat meminta kursi Pengguna yang Disetujui tambahan secara tertulis (email sudah cukup). Hanya administrator bernama yang dapat menambahkan anggota, mengubah peran, atau membuat identitas beban kerja atau kredensial di Ruang Kerja yang Diberikan.

  5. Gateway. Jika Pelanggan mengoperasikan gateway atau proxy di depan model, itu harus mengakui hanya Pengguna yang Disetujui atau identitas beban kerja mereka, menggunakan kredensial berumur pendek miliknya sendiri, dan menjaga log dan transkrip terbatas pada Pengguna yang Disetujui dan tim keamanan, administrasi IT, atau kepercayaan dan keselamatan Pelanggan.

  6. Sistem Kredensial yang Dioperasikan Pelanggan. Kredensial yang dikeluarkan oleh sistem Pelanggan sendiri harus kedaluwarsa dalam 12 jam, harus dikeluarkan hanya setelah autentikasi multi-faktor yang tahan terhadap phishing (untuk orang) atau identitas beban kerja yang terverifikasi (untuk layanan), dan tidak boleh meninggalkan kredensial statis di endpoint, dalam kode sumber, atau di penyimpanan bersama. Kunci dan rahasia yang dapat mengeluarkan kredensial model harus disimpan di pengelola rahasia atau layanan manajemen kunci dengan pencatatan akses.

  7. Pencabutan. Pelanggan harus dapat mencabut kredensial atau identitas apa pun yang dikompromikan dalam waktu 24 jam.

  8. Offboarding. Pelanggan harus menghapus Pengguna yang Disetujui yang pergi atau ditugaskan kembali, dan identitas beban kerja mereka, dari Ruang Kerja yang Diberikan dalam 3 hari kerja.

  9. Egress Jaringan. Di mana pun model melakukan pekerjaan ofensif atau agentic, lalu lintas keluar harus dibatasi pada daftar izin yang ditegakkan di luar host, dan harus dicatat. Workstation yang digunakan hanya untuk prompting interaktif dapat menggunakan daftar izin di host jika pekerjaan agentic itu sendiri berjalan di sandbox yang tidak dapat mengubah daftar tersebut.

  10. Perangkat Terkelola dan Perlindungan Malware. Pengguna yang Disetujui harus menjangkau Ruang Kerja yang Diberikan hanya dari perangkat yang dikendalikan Pelanggan, bukan perangkat pribadi, dan yang menerima pembaruan sistem operasi otomatis atau terjadwal secara teratur. Setiap perangkat yang digunakan Pengguna yang Disetujui untuk menjangkau Ruang Kerja yang Diberikan harus dikelola oleh Pelanggan dan harus menjalankan daftar izin aplikasi atau daftar penolakan dalam mode penegakan, atau agen deteksi dan respons endpoint dalam mode blokir atau cegah. Desktop virtual terkelola atau enclave yang memenuhi standar ini juga memenuhi syarat.

  11. Pemeriksaan Latar Belakang. Setiap Pengguna yang Disetujui, termasuk kontraktor, harus telah lulus pemeriksaan identitas dan, jika sah, pemeriksaan riwayat kriminal. Jika hukum lokal membatasi pemeriksaan kriminal, verifikasi identitas, hak kerja, atau ketenagakerjaan diterima. Pemeriksa pemerintah atau izin memenuhi persyaratan ini.

  12. Prosedur Insiden. Pelanggan harus mempertahankan prosedur terdokumentasi untuk dugaan kompromi atau penyalahgunaan hibah yang mencakup pencabutan kredensial, penangguhan kursi, dan pemberitahuan Anthropic.

  13. Entitas Pemerintah. FISMA Authority to Operate dengan penilaian Inspektur Jenderal independen tahunan terhadap NIST SP 800-53, atau skema nasional yang setara, memenuhi persyaratan Perangkat Terkelola dan Perlindungan Malware, Pemeriksaan Latar Belakang, dan Prosedur Insiden. Semua persyaratan lainnya terus berlaku.

Apakah pertanyaan Anda terjawab?