YubiKey FIPS Series: Untuk Regulated Industries di Indonesia

Ketika sebuah RFP meminta bukti modul kriptografi tervalidasi, tim procurement sering langsung mencari YubiKey FIPS. Langkah itu masuk akal, tetapi belum cukup. Pertanyaan yang menentukan justru: sertifikat mana yang diminta, untuk model dan konfigurasi apa, serta siapa yang bertanggung jawab menjaga perangkat tetap berada dalam mode operasi yang disetujui?

Untuk organisasi yang bekerja dengan induk usaha global, kontrak pemerintah asing, atau kebijakan keamanan internal yang ketat, yubikey fips dapat menjadi bagian dari jawaban. Namun FIPS bukan cap kepatuhan untuk seluruh organisasi. Ini adalah validasi atas modul kriptografi dalam kondisi yang spesifik. Keputusan pembelian harus tetap menghubungkan bukti sertifikat, kompatibilitas identitas, proses penerbitan, pemulihan, dan jejak audit.

TL;DR

• FIPS menilai modul kriptografi, bukan keseluruhan program compliance perusahaan.
• Per 22 September 2026, pembeli baru perlu membedakan validasi FIPS 140-2 yang historis dari validasi FIPS 140-3 yang aktif.
• Bukti yang perlu diuji mencakup sertifikat, model, konfigurasi mode approved, pemilik proses, dan lifecycle perangkat.
• Jangan menganggap varian FIPS selalu diperlukan; mulai dari requirement yang terdokumentasi.

Mengapa Validasi FIPS Menjadi Pertanyaan Procurement

FIPS adalah singkatan dari Federal Information Processing Standards. Dalam konteks ini, yang diperiksa adalah persyaratan keamanan untuk modul kriptografi. Program CMVP milik NIST dan Canadian Centre for Cyber Security memvalidasi modul tersebut agar lembaga federal memiliki metrik saat membeli peralatan yang menggunakan kriptografi. Lihat penjelasan resmi CMVP untuk batas ruang lingkupnya.

Artinya, FIPS relevan ketika requirement pembeli memang meminta modul tervalidasi. Ini umum dijumpai pada kebijakan induk usaha, kontrak lintas negara, atau lingkungan yang mengadopsi baseline keamanan tertentu. Untuk perusahaan Indonesia, label regulated industries tidak otomatis berarti FIPS diwajibkan. Tim Compliance perlu membuktikan sumber requirement itu: peraturan sektoral yang berlaku, klausul kontrak, kebijakan grup, atau keputusan risk committee.

💡 Insight: Mulailah dari dokumen requirement, bukan dari SKU. Tanpa requirement yang jelas, organisasi berisiko membeli perangkat yang lebih ketat dari kebutuhan atau justru tidak memenuhi bukti yang diminta auditor.

FIPS 140-2 dan FIPS 140-3: Apa yang Harus Diverifikasi

FIPS 140-2 masih sering muncul pada dokumen procurement dan referensi produk lama. Namun statusnya perlu dibaca berdasarkan waktu dan tujuan pengadaan. NIST menyatakan bahwa validasi baru FIPS 140-3 diterima sejak 2020; modul FIPS 140-2 yang sebelumnya aktif dipindahkan ke Historical List setelah 21 September 2026 untuk konteks sistem federal baru. Karena artikel ini ditujukan untuk pembelian setelah tanggal itu, meminta bukti yang hanya menyebut FIPS 140-2 tanpa memeriksa statusnya menciptakan celah procurement.

FIPS 140-3 bukan sekadar nomor baru. Standar ini merujuk pada ISO/IEC 19790 untuk persyaratan modul dan ISO/IEC 24759 untuk pengujian. Pembeli tidak perlu menafsirkan standar tersebut sendiri, tetapi harus meminta bukti yang tepat: nomor sertifikat, nama modul, status, level keseluruhan, caveat, serta Security Policy yang mengatur instalasi dan konfigurasi.

CMVP mencatat Certificate #5291 untuk YubiKey 5 Cryptographic Module sebagai aktif pada FIPS 140-3 Overall Level 2, dengan Physical Security Level 3. Entri itu juga menyatakan syarat mode approved serta inisialisasi dan konfigurasi sesuai Security Policy. Jadi, sertifikat tidak boleh dipisahkan dari prosedur operasionalnya.

⚠️ Penting: Cocokkan nama modul pada sertifikat dengan perangkat yang ditawarkan vendor. Algoritma yang disetujui atau merek produk saja bukan pengganti validasi modul.

Siapa yang Biasanya Meminta Bukti Kriptografi Tervalidasi

Ada tiga pola yang patut dipisahkan. Pertama, kontrak atau kebijakan global dapat menetapkan baseline FIPS untuk sistem tertentu. Kedua, procurement dapat menyaratkan modul tervalidasi sebagai bagian dari arsitektur yang menangani data sensitif. Ketiga, organisasi dapat menetapkan FIPS sebagai kontrol internal untuk menyederhanakan bukti pada audit lintas wilayah.

Setiap pola menghasilkan bukti yang berbeda. Kontrak membutuhkan klausul dan scope sistem. Kebijakan internal membutuhkan persetujuan pemilik risiko. Auditor membutuhkan jejak dari requirement ke model, konfigurasi, distribusi, dan review berkala. Tidak ada satu kalimat pemasaran yang dapat menggantikan rantai bukti tersebut.

Di Indonesia, pisahkan kebutuhan ini dari asumsi bahwa semua bank, instansi, atau kontraktor pertahanan harus memakai FIPS. Jika tim Legal atau Compliance menemukan kewajiban yang spesifik, kutip dokumen resminya dengan scope dan tanggal yang tepat. Jika tidak, jelaskan FIPS sebagai persyaratan pembeli atau kebijakan internal, bukan mandat nasional.

YubiKey FIPS dan Non-FIPS: Cara Membaca Perbedaan yang Relevan

Perbandingan yang berguna bukan daftar fitur panjang. Fokusnya adalah bukti apa yang diperlukan untuk use case Anda. Dokumentasi Yubico untuk konfigurasi FIPS 140-2 Level 2 menjelaskan bahwa tidak semua aplikasi perangkat berada pada mode approved secara default. Ada peran Crypto Officer yang perlu menetapkan dan mengawasi proses inisialisasi serta pengiriman perangkat. Pada konfigurasi itu, U2F tidak boleh digunakan sebagai autentikator Level 2. Detail seperti ini memengaruhi desain rollout, bukan hanya pilihan model.

Tabel ini bukan penetapan bahwa satu varian lebih baik. Varian FIPS mendukung kebutuhan bukti yang berbeda. Pilihan non-FIPS tetap dapat sesuai untuk banyak program passwordless bila requirement tidak meminta modul tervalidasi. Konfirmasikan model dan konfigurasi aktual melalui dokumentasi teknis Yubico sebelum membuat matriks SKU final.

Halaman Produk YubiKey

Pertanyaan Procurement untuk Lingkungan yang Teregulasi

Gunakan daftar pertanyaan ini saat menilai penawaran:

1. Requirement mana yang meminta FIPS, dan berlaku untuk sistem atau data apa?
2. Apakah penawaran menyebut model dan modul yang sama dengan sertifikat CMVP?
3. Apakah status sertifikat masih sesuai untuk sistem dan tanggal pengadaan yang direncanakan?
4. Security Policy mana yang mengatur inisialisasi, peran Crypto Officer, mode approved, dan perubahan konfigurasi?
5. Apakah protokol yang dibutuhkan aplikasi enterprise tetap dapat digunakan dalam konfigurasi yang dipilih?
6. Siapa pemilik inventory, penerbitan, penggantian, pencabutan, dan pemulihan perangkat?

Pendekatan yang disarankan Docotel adalah meninjau enam pertanyaan ini bersama pemilik aplikasi, Security, Procurement, dan Compliance sebelum memilih model. Hasilnya bukan sekadar keputusan perangkat, melainkan baseline test case untuk pilot dan bukti yang dapat ditelusuri ketika requirement berubah.

📌 Catatan: Harga, stok lokal, dan durasi pengadaan perlu dikonfirmasi pada penawaran yang berlaku. Jangan memasukkan angka asumsi ke business case atau kontrak kontrol.

Selain sertifikat, siapkan acceptance package untuk pilot. Paket ini dapat memuat salinan requirement, hasil pencocokan model ke Certificate Detail, catatan versi firmware bila relevan, keputusan konfigurasi, serta hasil uji pada aplikasi prioritas. Pemilik aplikasi perlu menyatakan bahwa alur login, smart card, atau integrasi yang digunakan tetap berfungsi sesuai kebijakan. Security kemudian menilai apakah mode operasi yang diterapkan mengikuti Security Policy yang dirujuk.

Pemisahan peran juga perlu terlihat jelas. Procurement mengelola kesesuaian penawaran dan dokumen pemasok. Security atau Crypto Officer mengelola inisialisasi dan perubahan yang memengaruhi mode operasi. IAM memastikan penerbitan perangkat terikat ke identitas yang tepat. Compliance dan Internal Audit menilai apakah bukti tersebut cukup untuk requirement yang ditetapkan. Ketika satu tim memegang seluruh keputusan tanpa handoff, risiko terbesar bukan perangkatnya, melainkan bukti yang tidak dapat direkonstruksi.

Menyiapkan Lifecycle, Recovery, dan Bukti Audit

Perangkat yang tervalidasi tetap perlu dikelola sebagai aset identitas. Catat pemilik, serial number internal, model, tanggal penerbitan, sistem yang diakses, dan status perangkat. Simpan bukti konfigurasi serta hasil uji kompatibilitas pada lokasi yang dapat diakses oleh pemilik kontrol.

Rancang recovery sebelum perangkat dibagikan. Tentukan siapa yang boleh menyetujui penggantian, bagaimana identitas pengguna diverifikasi kembali, kapan perangkat hilang dicabut dari sistem yang relevan, dan bagaimana kejadian tersebut dicatat. Recovery yang cepat tetapi melewati verifikasi identitas dapat membuka jalan bypass terhadap kontrol yang ingin diperkuat oleh hardware key.

Rekomendasi Docotel untuk rancangan lifecycle adalah menetapkan bukti minimum per tahap: approval pada enrolment, catatan konfigurasi saat penerbitan, hasil uji untuk aplikasi prioritas, serta catatan pencabutan atau penggantian. Dengan cara ini, tim audit tidak perlu menyusun bukti dari nol saat ada review.

Susun pula ritme review. Misalnya, pemilik kontrol dapat meninjau perangkat yang tidak lagi terkait dengan pengguna aktif, exception yang memakai metode login alternatif, dan recovery yang dilakukan selama periode tertentu. Tujuannya bukan membuat laporan panjang. Tujuannya memastikan daftar perangkat, status akses, dan alasan pengecualian tetap selaras dengan sistem identitas. Bila organisasi memakai beberapa platform, simpan bukti dari masing-masing platform pada referensi yang sama agar auditor dapat menelusuri satu peristiwa dari tiket sampai pencabutan akses.

Dokumenkan hasil review, penanggung jawab, dan tindakan korektif agar keputusan berikutnya memiliki konteks yang dapat diuji.

Checklist Keputusan sebelum Memilih YubiKey FIPS

Sebelum PO diterbitkan, pastikan keputusan dapat dijawab dalam satu paket bukti:

• Requirement FIPS dan scope sistem sudah disetujui pemilik risiko.
• Certificate CMVP, nama modul, status, dan caveat telah diperiksa terhadap penawaran.
• Tim teknis telah menilai mode approved serta dampaknya terhadap protokol dan aplikasi.
• Pilot mencakup kelompok pengguna dan sistem prioritas, termasuk skenario perangkat hilang.
• Inventory dan proses recovery memiliki owner, approval, serta retensi bukti yang jelas.
• Legal dan Procurement telah memeriksa klausul support, penggantian, serta dokumen yang harus diberikan pemasok.

Checklist ini dapat dipakai sebagai bagian dari Hubungi Docotel. Jangan menutupnya dengan pernyataan “compliant” tanpa kriteria penerimaan, bukti, dan pemilik proses yang terdokumentasi.

Frequently Asked Questions

Konsultasi Kebutuhan FIPS dengan Bukti yang Tepat

Mulai dari requirement yang dapat diuji, lalu turunkan ke sertifikat, konfigurasi, dan operasi. Docotel dapat membantu menyusun pertanyaan procurement, rencana pilot, dan daftar bukti untuk review lintas Security, Compliance, dan Procurement.

Disusun oleh: Tim Solution Architects Docotel
Dipublikasikan: 2026-10-19
Terakhir diperbarui: 2026-11-06