Centralized key management
Key dibuat, dicatat, dan dikelola di satu tempat — bukan tersebar di konfigurasi tiap aplikasi.
Features
Tingkatkan postur keamanan dengan TILE VAULT
Kelola cryptographic key, secret, dan akses aplikasi dari satu platform — dengan otorisasi di tingkat aplikasi dan key yang tidak pernah meninggalkan KMS.
Langkah demi langkah
Amankan area risiko Anda satu per satu
Mulai dengan memusatkan key dan secret, lanjutkan dengan mengendalikan siapa yang boleh memakainya, lalu skalakan dengan lifecycle, audit, dan algoritma yang siap untuk jangka panjang.
1
Pusatkan key dan secret
Satu inventaris untuk setiap key dan secret aplikasi, dan satu API untuk memakainya.
Satu aplikasi, satu set key
Setiap aplikasi diprovisikan dengan slot REST, TRANSIT, SIGNING, dan MAC; algoritma dipilih per slot.
Encryption as a service
Enkripsi data, file, dan aliran file besar berbasis streaming, sehingga file tidak perlu dimuat seluruhnya ke memori.
Broadcast seal
Segel data satu kali untuk beberapa aplikasi penerima sekaligus.
Digital signature & token
Tanda tangani dan verifikasi data maupun token dengan key yang dikelola KMS.
Message authentication
MAC berbasis HMAC atau KMAC untuk memeriksa integritas data maupun token.
Secret per aplikasi
Simpan credential, API key, atau certificate per aplikasi. Portal hanya menampilkan metadata; nilainya dibuka satu per satu ketika diminta.
Data masking
Samarkan data sensitif dan pulihkan kembali melalui operasi mask dan unmask.
Key generation & TOTP
Turunkan key dengan DRBG atau KDF, serta buat dan validasi kode TOTP untuk aplikasi Anda.
2
Kendalikan akses
Setiap permintaan operasi diperiksa berlapis: pemanggil, device, aplikasi, key, dan operasinya.
Application-centric authorization
Penggunaan key diputuskan dari identitas, aplikasi, key, operasi, dan kebijakan — bukan hanya dari siapa yang login.
Scope per key
Setiap key dibatasi pada operasi yang dipilih saat pembuatannya; operasi di luar daftar itu ditolak.
Deny by default
Kebijakan dievaluasi dengan prinsip deny by default: apa pun yang tidak diizinkan secara eksplisit akan ditolak.
mTLS wajib
Jalur operasi kriptografi mewajibkan mTLS, pada HTTP maupun gRPC. Certificate klien diverifikasi, termasuk status pencabutannya.
Agent & device approval
Device didaftarkan dengan kode yang disetujui pemilik akun di portal, sekaligus menentukan aplikasi yang boleh dipakainya.
Client binding
Certificate aplikasi hanya diterima untuk aplikasinya sendiri. Mode Off, Audit, dan Enforce, dengan pratinjau pemakaian sebelum disimpan.
Filter source IP
Daftar alamat IP per aplikasi di setiap Agent, dengan mode Audit sebelum Enforce — termasuk untuk aplikasi di belakang load balancer L4.
Revocation
Agent dan client certificate dapat dicabut dari portal kapan saja, dan riwayat pencabutannya tercatat.
Login tanpa password
Portal memakai sign-in eksternal ditambah TOTP sebagai faktor kedua. Tidak ada password yang disimpan.
3
Skalakan dan siap masa depan
Lifecycle yang tegas, jejak yang dapat ditelusuri, dan algoritma untuk jangka panjang.
Key lifecycle
Status eksplisit dari PRE_ACTIVE sampai DESTROYED, dengan transisi mengikuti model NIST SP 800-57 Rev. 5.
Key rotation
Rotasi menerbitkan key version berikutnya tanpa menghentikan versi yang sedang berjalan.
Pemisahan kewenangan
Portal hanya menampilkan key. Aktivasi dan rotasi oleh admin TILE; transisi yang mencabut kemampuan key hanya oleh operator melalui CLI.
Audit log
Aktivitas pengelolaan aset kriptografi dicatat dalam audit log yang dilindungi dari perubahan, sehingga upaya mengubahnya dapat terdeteksi.
Post-quantum cryptography
ML-KEM untuk key encapsulation, ML-DSA dan SLH-DSA untuk tanda tangan digital, pada seluruh tingkat parameternya.
Crypto agility
Algoritma adalah properti key. Key dengan algoritma berbeda hidup berdampingan, sehingga perpindahan algoritma tidak mengubah aplikasi.
Pemakaian terpantau
Lihat pemakaian operasi per Agent dan per aplikasi langsung dari portal.
High availability
Layanan KMS berjalan sebagai klaster dan dirancang untuk ketersediaan tinggi.
Deployment fleksibel
Private datacenter, cloud pilihan Anda, atau hybrid. Penerbitan lisensi berjalan luring, cocok untuk lingkungan air-gap.
Detail teknis
Untuk tim yang sedang mengevaluasi
Empat jalur integrasi, semuanya sudah ada pada implementasi. Aplikasi Anda memilih yang paling sesuai dengan arsitekturnya.
API
Integrasikan KMS dengan aplikasi dan service Anda melalui HTTP API untuk operasi kriptografi dan secret.
gRPC
Service-to-service communication untuk aplikasi modern, termasuk streaming untuk file besar.
mTLS
Mutual authentication antara client dan service. Wajib pada jalur operasi kriptografi, bukan opsi tambahan.
Agent
Controlled connection antara aplikasi atau device dengan KMS, dengan daftar aplikasi yang diizinkan per device.
Cara sebuah device mulai dipercaya
-
1
Device meminta pendaftaran
Agent menampilkan kode untuk disetujui di portal.
-
2
Pemilik akun menyetujui
Persetujuan dilakukan dari portal, sekaligus menentukan aplikasi mana yang boleh dipakai device tersebut.
-
3
Device siap dipakai
Device yang disetujui dapat melayani aplikasi yang diizinkan untuknya.
-
4
Izin dapat ditarik kapan saja
Daftar aplikasi dapat diubah, dan pencabutan device berlaku seketika serta tercatat.
Daftar ini sama persis dengan pilihan pada formulir pembuatan aplikasi. Rujukan standar menunjukkan asal spesifikasi algoritmanya, bukan status sertifikasi produk.
| Kategori | Algoritma | Standar |
|---|---|---|
| Symmetric encryption | AES_GCM_128 · AES_GCM_192 · AES_GCM_256 | FIPS 197 · SP 800-38D |
| Symmetric encryption | CHACHA20_POLY1305 | RFC 8439 |
| Post-quantum key encapsulation | ML_KEM_512 · ML_KEM_768 · ML_KEM_1024 | FIPS 203 |
| Post-quantum signature | ML_DSA_44 · ML_DSA_65 · ML_DSA_87 | FIPS 204 |
| Post-quantum signature | SLH_DSA_SHA2_* · SLH_DSA_SHAKE_* (128/192/256, s dan f) | FIPS 205 |
| Message authentication | HMAC_SHA256 · HMAC_SHA384 · HMAC_SHA512 · HMAC_SHA3_256 · HMAC_SHA3_384 · HMAC_SHA3_512 | RFC 2104 · FIPS 198-1 |
| Message authentication | KMAC128 · KMAC256 | SP 800-185 |
Cloud KMS adalah pilihan yang matang dan banyak dipakai. Tabel berikut tidak menilai mana yang lebih aman, melainkan memperlihatkan perbedaan model: di mana key berada, siapa yang mengoperasikan infrastrukturnya, dan bagaimana otorisasi ditentukan.
| Kemampuan | Cloud KMS | TILE VAULT |
|---|---|---|
| Managed key management | Ya | Ya |
| Encryption | Ya | Ya — data, file, dan aliran file |
| Digital signature | Bergantung layanan | Ya |
| Key encapsulation | Bergantung layanan | Ya — ML-KEM |
| Message authentication (MAC) | Bergantung layanan | Ya — HMAC dan KMAC |
| Key lifecycle | Ya | Ya — NIST SP 800-57 Rev. 5 |
| Kontrol akses berbasis peran | Ya | Ya |
| Integrasi cloud-native | Erat dengan layanan penyedia | Melalui API, gRPC, dan agent |
| Deployment on-premise | Bergantung penyedia | Ya |
| Cloud independent | Terbatas pada ekosistem penyedia | Ya, sesuai deployment yang dipilih |
| Kontrol atas infrastruktur | Dikelola penyedia | Ya, sesuai deployment yang dipilih |
| Otorisasi berbasis aplikasi | Melalui IAM penyedia | Model aplikasi TILE — identitas, aplikasi, key, operasi, kebijakan |
| Kemampuan post-quantum | Bergantung penyedia | ML-KEM, ML-DSA, dan SLH-DSA |
| Cryptographic sovereignty | Bergantung penyedia | Deployment dikendalikan pelanggan |
"Bergantung layanan" dan "bergantung penyedia" berarti jawabannya berbeda antar penyedia dan antar tingkatan layanan, sehingga tidak dapat dinyatakan sebagai satu nilai. Kolom TILE mencerminkan kemampuan yang ada pada implementasi, dan beberapa di antaranya ditentukan oleh cara deployment dilakukan.
Apa itu TILE VAULT?
TILE VAULT adalah Key Management as a Service: platform untuk membuat, menggunakan, memutar, dan menghentikan cryptographic key secara terpusat, serta untuk menjalankan operasi kriptografi terhadap key tersebut atas permintaan aplikasi.
Aplikasi tidak menerima key material. Aplikasi meminta operasi, dan TILE mengembalikan hasilnya setelah memverifikasi identitas dan otorisasi pemanggil.
Apa perbedaan KMS dan HSM?
HSM adalah hardware yang menyimpan dan mengoperasikan key di dalam batas fisik yang terlindungi. KMS adalah lapisan pengelolaan: identitas, otorisasi, lifecycle, key version, kebijakan, dan audit.
Keduanya menjawab pertanyaan yang berbeda. HSM menjawab "di mana operasi kriptografi dijalankan"; KMS menjawab "siapa boleh memakai key yang mana, untuk operasi apa, dan sampai kapan". TILE adalah KMS.
Apakah TILE VAULT dapat digunakan on-premise?
Ya. TILE dapat berjalan pada infrastruktur yang Anda tentukan, termasuk private datacenter, dan dirancang untuk ketersediaan tinggi.
Apakah TILE VAULT harus menggunakan public cloud?
Tidak. Modul inti TILE tidak memiliki dependensi pada SDK penyedia cloud mana pun, dan penerbitan lisensi produk berjalan luring. TILE dapat dijalankan di cloud apabila Anda memilihnya, tetapi itu adalah keputusan deployment, bukan persyaratan.
Bagaimana aplikasi berkomunikasi dengan TILE VAULT?
Melalui HTTP API atau gRPC. Pada model yang dianjurkan, aplikasi berbicara dengan agent TILE yang berjalan di lingkungan aplikasi tersebut, dan agent itulah yang menjadi titik penegakan kebijakan sebelum permintaan diteruskan ke KMS.
Untuk file berukuran besar tersedia operasi berbasis streaming, sehingga seluruh file tidak perlu dimuat ke memori.
Apakah TILE VAULT mendukung mTLS?
Ya, dan pada jalur operasi kriptografi mTLS bersifat wajib — baik pada HTTP maupun gRPC. Sertifikat klien diverifikasi, termasuk pemeriksaan status pencabutannya.
Bagaimana key lifecycle dikelola?
Setiap key memiliki status eksplisit — PRE_ACTIVE, ACTIVE, SUSPENDED, DEACTIVATED, COMPROMISED, DESTROYED — dengan transisi yang dibatasi mengikuti model NIST SP 800-57 Rev. 5. SUSPENDED dapat kembali ACTIVE; DESTROYED bersifat terminal.
Aktivasi dan rotasi dijalankan admin TILE melalui web admin; portal pemilik akun hanya menampilkan key. Transisi yang mencabut kemampuan key sengaja dipisahkan dan hanya dapat dijalankan operator melalui jalur CLI yang memerlukan bukti tambahan.
Apakah TILE VAULT mendukung Post-Quantum Cryptography?
Ya. TILE mendukung ML-KEM untuk key encapsulation serta ML-DSA dan SLH-DSA untuk tanda tangan digital, pada seluruh tingkat parameter yang tercantum di bagian inventaris algoritma.
Rujukan FIPS 203, 204, dan 205 menunjukkan asal spesifikasi algoritma. Itu bukan pernyataan bahwa produk ini memegang sertifikasi apa pun.
Apa perbedaan TILE VAULT dengan cloud KMS?
Perbedaannya terletak pada model, bukan pada klaim keunggulan. Cloud KMS adalah layanan yang dikelola penyedia di dalam ekosistemnya, dengan integrasi cloud-native yang sangat erat. TILE dijalankan pada infrastruktur yang Anda kendalikan, dan otorisasinya dinyatakan dalam istilah aplikasi, key, dan operasi.
Bagi banyak organisasi, cloud KMS adalah pilihan yang tepat. TILE ditujukan untuk organisasi yang membutuhkan model kendali yang berbeda. Lihat tabel perbandingan untuk rinciannya.
Apakah TILE VAULT dapat digunakan pada hybrid environment?
Ya. Aplikasi berkomunikasi dengan TILE melalui API atau gRPC di atas mTLS, sehingga aplikasi di private datacenter maupun di cloud dapat memakai platform key management yang sama, sejauh jalur jaringannya tersedia.
Apakah TILE VAULT memiliki sertifikasi FIPS, Common Criteria, atau ISO?
Belum. TILE VAULT saat ini belum memegang sertifikat FIPS 140-3, Common Criteria, maupun ISO.
Yang dapat dinyatakan: algoritma diimplementasikan sesuai spesifikasi yang diterbitkan NIST dan IETF, key lifecycle mengikuti model NIST SP 800-57 Rev. 5, dan arsitektur keamanannya dirancang dengan mengacu pada prinsip yang dinilai dalam FIPS 140-3 dan Common Criteria. Rujukan tersebut adalah acuan desain, bukan status sertifikasi.
Apabila organisasi Anda memerlukan bukti sertifikasi untuk proses pengadaan, sampaikan kebutuhan tersebut agar dapat dijawab dengan status yang sebenarnya.
Siap mengendalikan cryptographic key Anda?
Bangun aplikasi yang lebih aman dengan cryptographic key management yang terpusat dan terkontrol.
Sudah menjadi pengguna? Masuk ke portal klien.