Laporan Resmi Enkripsi

Terakhir Diperbarui: 21 Oktober 2019

Pendahuluan

Mengapa banyak perusahaan pindah ke cloud? Kebanyakan alasannya adalah karena lingkungan cloud dapat diperluas, andal, dan selalu tersedia. Namun, hal tersebut bukanlah satu-satunya pertimbangan- keamanan dapat mengalahkan keunggulan cloud lainnya.

Maka penyedia layanan cloud harus memiliki strategi keamanan yang komprehensif. Strategi keamanan Zoho mencakup berbagai dimensi, dan enkripsi adalah salah satu bagian yang penting.

Halaman ini memiliki semua informasi penting mengenai strategi enkripsi Zoho dan bagaimana kami menggunakannya untuk menjaga keamanan data Anda.

Apa itu Enkripsi?

Enkripsi biasanya digunakan untuk menjaga konten pesan agar hanya dapat dibaca oleh penerima yang dituju. Caranya, kami mengganti konten dengan data yang tidak dapat dikenali dan hanya dapat dipahami oleh penerima yang dituju. Dengan demikian, enkripsi merupakan metode untuk melindungi data dari pencurian.

Enkripsi adalah proses perubahan data dengan proses enkode khusus sehingga data menjadi tidak dikenali (dienkripsi). Setelah itu Anda dapat menerapkan proses dekode khusus untuk mendapatkan kembali data asli (didekripsi). Karena proses dekode bersifat rahasia, tidak ada orang lain yang dapat memulihkan data asli dari data terenkripsi.

Proses enkode mengikuti algoritme enkripsi seperti AES 256 yang bersifat publik. Namun, proses tersebut bergantung pada kunci, yang digunakan dalam proses enkripsi dan dekripsi data untuk mengambil data asli.

Kunci harus selalu dijaga kerahasiaannya. Tanpa kunci tersebut, semua orang yang berhasil mengakses data hanya akan melihat "Teks cipher", yang tidak berarti apa-apa. Singkatnya, data sudah terlindungi.

Mengapa kami mengenkripsi data Anda

Lapisan perlindungan terakhir: Meskipun strategi keamanan yang komprehensif dapat melindungi data perusahaan dari peretas, tetapi enkripsi merupakan langkah terakhir untuk mencegah data Anda dari pencurian. Hal ini melengkapi perlindungan data karena data Anda tidak akan rusak atau dicuri jika terjadi pelanggaran keamanan.

Privasi- Enkripsi merupakan jaminan atas berbagai masalah privasi di internet. Enkripsi membantu melindungi privasi dengan mengubah informasi pribadi menjadi data “khusus untuk Anda lihat” yang hanya ditujukan bagi pihak yang membutuhkannya. Saat Anda berinteraksi dan menyimpan data di server, enkripsi membantu menjamin privasi Anda.

Yang dimaksud dengan 'data'

Ada dua jenis data yang kami tangani-

  1. Data pelanggan- Data yang disimpan di layanan Zoho. Biasanya, data tersebut ditangani oleh layanan Zoho melalui akun pelanggan yang dapat diidentifikasi di database IAM (Manajemen Identitas dan Akses).

    Penerapan enkripsi data pelanggan bergantung pada sensitivitas data dan persyaratan pengguna. Data sensitif adalah data yang dapat membahayakan individu atau organisasi terkait saat diketahui orang lain.

  2. Data turunan- Data yang tidak Anda berikan secara langsung, namun berasal dari data Anda. Misalnya, token autentikasi, ID unik, URL, laporan, dll. akan kami simpan.

    Penerapan enkripsi data turunan bergantung pada sensitivitas data tersebut.

Di bagian berikutnya, 'data' mengacu pada data yang dienkripsi.

Enkripsi Dalam Transit

Saat menggunakan Layanan Zoho, data Anda berpindah dari browser ke pusat data kami atau pihak ketiga lainnya (saat menggunakan integrasi pihak ketiga) melalui internet. Mengenkripsi data yang berada dalam transit akan melindungi data dari serangan di tengah proses.

Ada dua skenario enkripsi saat data dalam transit:

  • Jika data berpindah dari browser Anda ke Server kami.
  • Jika data berpindah dari server kami ke server non-Zoho (pihak ketiga)

Antara Anda dan Zoho

Zoho menetapkan kebijakan ketat untuk menerapkan TLS (Transport Layer Security/Keamanan Lapisan Transportasi) ke semua koneksinya. TLS menjamin koneksi yang aman antara Anda dan Server Zoho dengan memungkinkan autentikasi kedua pihak yang terlibat dalam koneksi, dan melalui enkripsi data yang akan ditransfer. Protokol TLS menjamin agar pihak ketiga tidak dapat menguping atau mengutak-atik komunikasi antara Anda dan Zoho.

Kami mengikuti protokol TLS terbaru versi 1.2/1.3 dan menggunakan sertifikat yang diterbitkan oleh SHA 256 dan cipher (AES_CBC/AES_GCM kunci 256 bit/128 bit untuk enkripsi, SHA2 untuk autentikasi pesan, dan ECDHE_RSA sebagai mekanisme pertukaran kunci). Kami juga menerapkan kerahasiaan penerusan yang sempurna dan HTTPS Strict Transport Security (HSTS) di seluruh situs.

Antara Zoho dan pihak ketiga

Kami mengikuti protokol https saat berkomunikasi dengan pihak ketiga. Untuk transaksi data sensitif dan kasus penggunaan, kami menggunakan enkripsi asimetris yang menggunakan sistem kunci publik dan pribadi dalam proses enkripsi dan dekripsi data.

Metode ini menghasilkan sepasang kunci publik dan pribadi di KMS (Key Management Service/Layanan Manajemen Kunci), yang membuat, menyimpan, dan mengelola kunci di seluruh layanan. Kami mengenkripsi keduanya menggunakan kunci master dan pasangan kunci terenkripsi yang disimpan di KMS. Kunci master disimpan di server terpisah.

Kami menyediakan kunci publik bagi pihak ketiga melalui sertifikat, tetapi kunci pribadi tetap disimpan di KMS, dan setelah autentikasi, data yang dienkripsi akan didekripsi di KMS.

Enkripsi saat Tidak Aktif

Ada dua tingkat enkripsi utama-

  1. Enkripsi lapisan aplikasi
  2. Enkripsi disk lengkap berbasis perangkat keras

Strategi untuk mengenkripsi data pada tingkat aplikasi bergantung pada lokasi dan cara penyimpanan data-

  • Database (DB) - disimpan sebagai tabel
  • Sistem File Terdistribusi (DFS) - disimpan sebagai file
  • Enkripsi URL
  • Cadangan
  • Log
  • Cache

Gambar di bawah ini memberikan gambaran strategi enkripsi secara lengkap:

strategi enkripsi

Tingkat aplikasi

Semua layanan (atau aplikasi) Zoho yang digunakan melibatkan data: data yang Anda berikan dan data yang disimpan atas nama Anda sebagai bagian dari layanan. Data mungkin diterima sebagai file atau bidang data. Setiap kategori diperlakukan secara berbeda, bergantung pada cara enkripsinya.

Bagian ini menjelaskan enkripsi saat tidak digunakan pada tingkat aplikasi.

Enkripsi DB

Saat menggunakan layanan seperti Zoho Creator atau Zoho Forms, data yang Anda masukkan ke aplikasi, atau data layanan, disimpan di database sebagai tabel.

Data dalam tabel ini dienkripsi sesuai standar AES 256 dengan mode AES/CBC/PKCS5Padding. Namun, tingkat enkripsi dapat berbeda-beda, bergantung pada sensitivitas bidang data serta pilihan dan persyaratan pengguna.

Ada dua tingkat enkripsi DB-

  1. Bergantung pada sensitivitas data
  2. Bergantung pada fungsionalitas pencarian

Catatan: Selanjutnya, pelanggan atau organisasi yang menggunakan layanan Zoho dan memiliki jumlah pengguna yang terbatas disebut sebagai 'Org'.

Bergantung pada sensitivitas data

Level 1- Ini adalah tingkat enkripsi default untuk data dari semua Orgs. Di tingkat ini, KMS mengalokasikan satu kunci untuk setiap org. Data yang sesuai dengan org tersebut akan dienkripsi menggunakan kunci ini. Kunci dienkripsi menggunakan kunci master yang kemudian disimpan di server terpisah.

Level 2- Tingkat enkripsi ini dilakukan untuk data sensitif dan Informasi Pribadi yang Dapat Diidentifikasi (PII). Kategori ini mencakup Nomor rekening bank, Nomor identifikasi, dan data biometrik.

Dalam tingkat ini, KMS membuat kunci unik untuk setiap kolom di tabel. Semua data dalam kolom akan dienkripsi menggunakan kunci yang dihasilkan untuk kolom tersebut. Kunci ini dienkripsi lagi menggunakan kunci master yang disimpan di server terpisah.

Bergantung pada fungsionalitas pencarian

Vektor Inisialisasi (IV) adalah nilai acak yang memulai proses enkripsi. Nilai acak ini memastikan bahwa enkripsi setiap blok/unit data berbeda. Artinya, enkripsi data yang sama dua kali akan menghasilkan teks cipher yang berbeda.

Mengapa IV penting?

Jika Anda tidak memiliki IV dan hanya menggunakan mode Cipher Block Chaining (CBC) dengan kunci, dua set data yang dimulai dengan data identik akan menghasilkan blok pertama yang identik. IV mencegah agar enkripsi dua data berbeda tidak menghasilkan pasangan input/output yang sama (pada tingkat cipher blok, dan menggunakan kunci yang sama), meskipun salah satunya berhubungan dengan yang lain (termasuk tetapi tidak terbatas pada: dimulai dengan blok pertama yang sama).

Jika setiap permintaan enkripsi memungkinkan penggunaan IV acak, blok yang pertama akan berbeda. Penyerang tidak dapat mengambil apa pun untuk melakukan dekode pada data yang dienkripsi.

Enkripsi yang Mempertahankan Kesetaraan: Ini adalah tingkat enkripsi default untuk semua tabel. Pada level ini, seluruh tabel data mendapatkan satu IV. Artinya, seluruh blok teks cipher dapat digunakan dalam kueri pencarian pada tabel. Karena IV untuk semua data pada tabel sama, maka pencarian akan mengambil data Anda.

Enkripsi Standar: Pada level ini, setiap entri data memiliki IV unik. Meskipun Anda mengenkripsi seluruh tabel dengan satu kunci, setiap entri data yang dienkripsi akan menghasilkan teks cipher unik. Selain itu, karena IV setiap data bersifat acak dan unik, maka kueri pencarian tidak akan mengambil data Anda. Ini merupakan opsi yang lebih aman daripada variasi "Mempertahankan Kesetaraan".

Dalam situasi apakah variasi ini digunakan?

Keputusan penggunaan variasi tertentu biasanya bergantung pada persyaratan. Jika data membutuhkan perlindungan tingkat tertinggi, sebaiknya gunakan Level-2 dengan enkripsi standar. Namun, jika hanya bidang terpilih yang membutuhkan perlindungan maksimal, perlindungan Level-2 dengan versi standar sudah cukup.

Tetapi, perlindungan bukanlah segalanya. Kadang, pengguna ingin mencari dan mengambil bidang seperti 'ID email' untuk memenuhi persyaratan mereka. Jika demikian, opsi standar tidak dapat memenuhinya, dan sebaiknya gunakan variasi "Mempertahankan Kesetaraan".

Enkripsi file atau DFS

Saat menggunakan layanan seperti Zoho Docs, file buatan Anda akan disimpan di Sistem File Terdistribusi (DFS).

Enkripsi dilakukan berdasarkan pada algoritme standar AES 256, tetapi mode enkripsinya adalah RKT atau mode penghitung. Di AES 256, teks biasa yang perlu dienkripsi akan dibagi ke dalam paket data atau blok. Karena kami mengenkripsi konten file di sini, maka algoritme harus memastikan bahwa setiap enkripsi blok bersifat independen, sehingga penyerang tidak akan mendapatkan informasi file apa pun, meskipun cipher blok berada dalam bahaya. Jika demikian, idealnya Anda menggunakan mode CTR.

Seperti enkripsi DB, enkripsi file juga memiliki dua tingkat:

Level 1- Pada tingkat ini, masing-masing Org diberi kunci. Setiap file Org dienkripsi menggunakan kunci ini, tapi dengan IV acak unik yang disimpan bersama file tersebut. Kunci ini kemudian dienkripsi lagi menggunakan kunci master dan disimpan di KMS.

Level 2- Pada tingkat ini, setiap file memiliki kunci unik dan dienkripsi menggunakan kunci tersebut. Setiap kunci yang digunakan untuk mengenkripsi file akan dienkripsi lagi menggunakan kunci master, dan kunci yang terenkripsi disimpan bersama file di DFS. Kunci master ini bersifat unik bagi layanan atau aplikasi, serta disimpan dan dikelola di KMS.

Enkripsi URL

Tautan undangan atau komunikasi lainnya mungkin melibatkan data sensitif yang diteruskan dalam URL. Untuk mengamankan komunikasi, kami mengenkripsi bagian URL. Jika ada hal yang dapat dikenali pada URL, misalnya ID dokumen, maka bagian itu akan dienkripsi.

Enkripsi ini memiliki dua level- Satu kunci per Org atau Satu kunci per URL. Hal ini juga ditentukan berdasarkan sensitivitas data pada URL.

Enkripsi cadangan

Kami membuat cadangan berdasarkan dua jadwal: harian dan mingguan. Server cadangan dilengkapi dengan tingkat perlindungan yang sama dengan server utama. Semua data yang diambil sebagai cadangan akan dienkripsi saat tidak digunakan. Kami menggunakan algoritme AES 256 untuk enkripsi dan menyimpan kuncinya di server terpisah. Kami juga memiliki Pusat Data (DC) redundan agar ketersediaan selalu terjamin. DC juga memiliki salinan data terenkripsi, yang juga dicadangkan seperti DC utama.

Enkripsi Log

Log Zoho menggunakan Sistem File Terdistribusi Hadoop (HDFS) untuk menyimpan dan mengelola log. Kami menggunakan teknologi enkripsi Hadoop Inc untuk mengenkripsi data, dan KMS untuk mengelola manajemen kunci.

Enkripsi cache

Kami menggunakan perangkat lunak sumber terbuka Redis untuk menyimpan dan mengelola data cache. Cache berisi data yang digunakan berulang kali pada pengoperasian layanan, dan harus disimpan dalam jangka waktu tertentu. Kadang, data Anda mungkin dicache untuk meningkatkan layanan atau memecahkan masalah. Jika ada data yang berisi informasi pribadi sensitif, kami akan mengenkripsinya.

Manajemen Kunci

Layanan Manajemen Kunci (KMS) membuat, menyimpan, dan mengelola kunci di seluruh layanan. Kami memiliki dan mengelola kunci menggunakan KMS. Saat ini, kami tidak memiliki ketentuan untuk mengenkripsi data dengan kunci milik pelanggan.

Ada berbagai jenis kunci yang digunakan pada beragam tahap enkripsi:

Kunci Enkripsi Data (DEK): Kunci yang digunakan untuk mengonversi data dari teks biasa menjadi teks cipher, atau kunci yang digunakan untuk mengenkripsi data.

Kunci Enkripsi Kunci (KEK): Kunci yang digunakan untuk mengenkripsi DEK, dan disesuaikan dengan layanan. Hal ini menjadi lapisan keamanan tambahan.

Kunci Master: Kunci yang digunakan untuk mengenkripsi KEK. Kunci disimpan di server terisolasi demi keamanan.

Bagaimana cara kerja KMS?

Semua jenis enkripsi sesuai dengan algoritme AES 256. Menurut algoritme ini, data diperlakukan sebagai 'blok' yang akan dienkripsi. Proses enkripsi bidang di database atau file di DFS akan dimulai saat blok data dienkripsi menggunakan DEK.

DEK ini dienkripsi lebih lanjut dengan KEK. KEK dienkripsi lagi menggunakan kunci master yang disimpan di server terpisah. Jadi, berikut adalah elemen yang harus dikelola-

  • Data yang dienkripsi
  • DEK
  • DEK yang dienkripsi
  • KEK
  • KEK yang dienkripsi
  • Kunci master

KMS mengelola elemen tersebut dengan cara berikut:

kms1

1
Memulai Permintaan

Pengguna menerima autentikasi ke layanan Zoho dan meminta data

2
Enkripsi dalam transit

Enkripsi berbasis TLS

3
Ujung Depan Aplikasi

Mengarahkan lalu lintas ke server aplikasi

4
Server Aplikasi

Memulai proses enkripsi

5
Layanan Manajemen Kunci

Membuat/Mengambil Kunci Enkripsi Data (DEK)

6
Server Master

Membuat/Mengambil Enkripsi Kunci (KEK)

7
Database KMS

Menyimpan DEK yang dienkripsi

8
Layanan Manajemen Kunci

Mengembalikan DEK untuk proses enkripsi

9
Agen Enkripsi

Mengenkripsi data menggunakan DEK

10
Penyimpanan

Menyimpan data yang dienkripsi

Bagaimana cara membuat kunci?

KMS membuat kunci 256-bit dan Vektor Inisialisasi (IV) yang sesuai dengan protokol AES 256. IV, seperti yang telah dibahas, memastikan bahwa blok pertama data terenkripsi bersifat acak. Inilah sebabnya mengapa IV mengenkripsikan teks biasa yang sama menjadi teks cipher yang berbeda.

KMS membuat kunci tersebut, sedangkan IV menggunakan perpustakaan aman Java dan pembuat nomor acak aman. 

Di manakah kunci disimpan?

DEK yang dibuat di KMS akan dienkripsi menggunakan KEK. Hal ini merupakan lapisan keamanan tambahan. DEK yang dienkripsi disimpan di database KMS.

layers-security

Kami memisahkan kunci fisik (menyimpannya di lokasi yang berbeda) agar penyerang yang sudah mendapatkan satu kunci tidak dapat mengambil kunci lainnya. Kami mengenkripsi KEK menggunakan kunci master yang disimpan di server terpisah.

Untuk Zoho Docs, kami menyediakan lapisan keamanan tambahan untuk dokumen yang disimpan saat tidak digunakan.

layers-security1

Penyerang tidak dapat menyusupi data hanya dengan menargetkan perjalanan KMS.

Seberapa aman kunci ini?

Pemisahan fisik- Seperti yang dibahas sebelumnya, kunci master tetap berada di server aman yang terpisah secara fisik. Hal ini menyulitkan penyerang untuk menyusupi DEK dan KEK.

Kontrol akses- Kontrol akses membantu mencegah penyalahgunaan dan akses asing ke kunci. Daftar Kontrol Akses (ACL) hanya mengizinkan akses ke kunci terpilih untuk layanan tertentu. Setiap kali kunci diakses, kunci memerlukan autentikasi dan prosesnya akan dicatat. Audit log yang teratur membantu memantau proses.

Akses ke Server Manajemen Kunci dibatasi secara default, dan hanya diizinkan bagi personel Zohocorp tertentu. Akses lainnya disampaikan sebagai tiket dan hanya diizinkan setelah manajemen menyetujuinya. 

Rotasi Kunci- Kami menggunakan sistem rotasi kunci yang mengubah kunci Root Master secara berkala untuk memastikan keamanan tambahan. Setelah membuat kunci master dan IV baru, maka Anda juga harus merevisi kunci di database. Oleh sebab itu, semua kunci di database diambil dan didekripsi terlebih dahulu menggunakan kunci master yang lama, kemudian dienkripsi ulang menggunakan kunci master yang baru, lalu diperbarui di database.

Anda dapat menetapkan pemicu rotasi kunci secara manual untuk menangani situasi kritis yang mungkin terjadi.

Ketersediaan Kunci- Jika terjadi kegagalan pada penyimpanan utama disk di satu Pusat Data (DC), terdapat slave dan slave kedua sebagai cadangan data yang sama dengan DC master. Slave dan slave kedua memiliki DEK terenkripsi, sama seperti master.

Data apa yang dienkripsi dalam layanan kami?

Enkripsi data yang tidak digunakan bervariasi, bergantung pada layanan yang Anda pilih. Opsi dan tingkat enkripsi entri data tertentu ditentukan oleh Anda atau kami, atau konsensus keduanya.

Kolom tabel berikut menjelaskan data yang dienkripsi oleh berbagai layanan Zoho:

LayananBidang yang Dienkripsi
CRMBidang kustom yang berisi informasi pribadi, semua file
DocsSemua file
CreatorBidang kustom
CampaignsBidang yang berisi informasi pribadi, file yang diunggah oleh pengguna
CliqTranskrip Obrolan dan informasi pribadi
PeopleBidang Kustom, semua file
ConnectJudul, URL, dan konten - umpan, postingan forum, artikel, rapat umum, grup, pengumuman, tugas dan komentarnya, file video, serta lampiran
DeskKonten thread tiket, lampiran, dan token
FinanceDetail rekening bank, bidang kustom yang berisi informasi pribadi, detail karyawan yang berisi informasi pribadi, dokumen perjalanan, pernyataan bank, lampiran
ProjectsLampiran, bidang yang berisi informasi pribadi, token
NotebookKartu catatan dan Lampiran
SignDokumen, gambar tanda tangan, dan token
ReportsBidang kustom, file yang diunggah oleh pengguna, kueri kustom
MailSemua konten email, lampiran, dan bidang yang berisi informasi pribadi
RecruitBidang kustom, dokumen yang diimpor pengguna
SocialToken, bidang yang berisi informasi pribadi

Enkripsi disk penuh

Kami menerapkan drive enkripsi mandiri (SED) untuk mendukung Enkripsi disk penuh berbasis perangkat keras.

SED adalah hard disk drive (HDD) atau solid state drive (SSD) yang memiliki sirkuit enkripsi drive bawaan. Enkripsi mandiri artinya semua data yang ditulis ke media penyimpanan dienkripsi oleh drive disk sebelum ditulis dan didekripsi oleh drive disk saat dibaca.

Drive SED adalah drive yang memenuhi persyaratan FIPS 140-2 atau TCG. Algoritme enkripsi yang dikonfigurasikan untuk SED adalah algoritme AES. Kunci yang digunakan untuk mengenkripsi dan mendekripsi memiliki panjang 256.

Ada dua jenis kunci yang digunakan dalam SED, yaitu kunci enkripsi data (DEK) dan kunci autentikasi (AK).

Kunci Enkripsi Data - Kunci ini digunakan untuk mengenkripsi/mendekripsi data di drive. Kunci dibuat oleh vendor dalam proses produksi. Saat terdapat server baru dengan drive SED, kami membuat ulang kunci demi alasan keamanan.

Kunci Autentikasi - Kunci ini akan mengenkripsi DEK dan menggunakannya untuk mengunci dan membuka kunci drive. Kunci autentikasi dibuat dengan kebijakan yang ketat dan disimpan di Sistem Manajemen Kunci. Kunci yang sama akan ditransfer secara aman ke setiap server saat Anda mengaktifkan enkripsi di server. Kami menggunakan manajemen kunci lokal (LKM) untuk mengelola kunci autentikasi.

Catatan: Saat ini, enkripsi disk lengkap berbasis perangkat keras hanya berlaku di pusat data India (IN).

Kesimpulan

Kami mengenkripsi data sensitif pelanggan saat disimpan, dalam transit melalui internet, dan saat berpindah antar DC. Namun, enkripsi hanyalah sebagian dari Strategi keamanan kami. Kami terus berinovasi dan berupaya untuk meningkatkan perlindungan data dengan menerapkan protokol serta teknologi terbaru. Untuk mempelajari strategi keamanan lengkap kami, kunjungi https://www.zoho.com/security.html.