Multi-tenancy pada Cloud, Pertimbangan dan Resiko Keamananya

Anda tentu sudah tidak asing lagi dengan istilah “cloud” yang sejak beberapa tahun silam menjadi sangat populer di telinga kita bahkan sampai saat ini terus berkembang dan para raksasa IT di dunia terus bersaing untuk menjadi penyedia layanan cloud yang terbaik. Kali ini kita akan coba eksplorasi walau tidak secara medalam tentang ide dibalik arsitektur cloud yaitu multi-tenancy.

Multi-tenancy adalah arsitektur cloud yang memungkinkan setiap tenant dari suatu layanan cloud berbagi daya komputasi dengan tenant lainnya. Tenant dalam hal ini bisa disebut sebagai pengguna atau pihak yang menyewa suatu layanan cloud. (sepanjang artikel ini istilah tenant akan tetap dalam bahasa inggris karena agak membingungkan bila diartikan ke bahasa indonesia).

Sebagai analogi, multi-tenancy seperti makan sepiring berdua atau bertiga bahkan lebih banyak lagi. Penyedia cloud memiliki resource yang sangat besar dan setiap tenant nya akan menggunakan resource yang sama. Anggaplah resource yang besar ini seperti piring yang besar dimana banyak orang yang ingin makan bisa menaruh makanannya diatas piring tersebut lalu makan dari piring tersebut. (Ya mungkin kurang lebih seperti itu. hehe). Sebelum membahas lebih jauh lagi, mari kita perhatikan berbagai definisi dari multi-tenancy

Definisi Multi-tenancy

(1) Sebuah cloud multi-tenant adalah arsitektur komputasi cloud yang memungkinkan pelanggan (tenant) berbagi sumber daya komputasi baik di cloud publik ataupun cloud privat. Setiap data dari masing-masing tenant diisolasi dan tetap tidak terlihat oleh tenant lainnya.

(2) Multi-tenancy di cloud berarti berbagi sumber daya dan layanan untuk menjalankan instance perangkat lunak yang melayani beberapa konsumen dan organisasi klien (tenant). Artinya sumber daya fisik (seperti komputasi, jaringan komputer, penyimpanan) dan layanan dibagi rata ke semua tenant, juga fungsi administratif dan bahkan fungsi pendukungnya juga dapat dibagi. Alasan utamanya adalah mengurangi biaya dengan berbagi dan menggunakan kembali sumber daya di antara pengguna layanan (tenant).

(3) Multi-tenancy adalah ide dibalik lahirnya komputasi cloud. Multi-tenancy adalah kemampuan untuk menjalankan beberapa tenant (pengguna) dalam sistem yang sama.

Multi-tenancy digunakan untuk tujuan ekonomis karena dengan arsitektur ini pengembangan perangkat lunak dan biaya perawatan dari layanan dibagi untuk semua tenant. Berbeda sekali dengan single-tenancy, sebuah arsitektur di mana setiap pelanggan memiliki perangkat lunak mereka sendiri dan diberi akses untuk melakukan coding. Keuntungan dengan arsitektur multi-tenancy, provider hanya harus melakukan update sekali. Dengan arsitektur single-tenancy, provider mengakses tiap instance dari perangkat lunak untuk melakukan pembaruan.

Multi-tenancy Isolation

Hal yang menjadi pertimbangan paling besar dari cloud (terlebih untuk arsitektur multi-tenant) adalah pengisolasian untuk tiap tenant. Keuntungan ekonomis yang didapat dari berbagi resource komputasi yang sama berarti mengorbankan aspek keamanan. Bayangkan setiap tenant memiliki data sensitif mereka masing-masing dan memiliki layanan masing-masing, jika tidak ada sekat antara tiap tenant maka data dan bisnis proses mereka akan transparan karena mereka berada pada sistem yang sama dan bekerja dari source yang sama. Sekat yang tadi disebut dalam cloud sebagai isolation.

Dengan multi-tenancy, cloud dapat memilih tingkat isolasi mulai dari berbagi perangkat keras yang sama menggunakan Vitual Machine (VM) untuk berbagi proses yang sama yang dilakukan dengan teknik pemrograman yang cerdik.

Multi-tenancy berdasarkan Ekekusi (Execution Multi-Tenancy)

Cloud dapat menerapkan pembagian daya komputasi pada level berikut:

1. Memberi setiap tenant mesinnya sendiri.
2. Memberi setiap tenant VMnya sendiri
3. Memberi setiap penyewa kontainernya sendiri (misal: docker)
4. Membiarkan beberapa penyewa berbagi proses yang sama (misalnya JVM)

Dari daftar level tersebut, semakin ke bawah levelnya maka masing-masing tenant mendapatkan lebih banyak daya komputasi namun semakin kurang terisolasi. Platform IaaS menyediakan pelayanan level dua berdasarkan daftar di atas. Sedangkan penyedia layanan PaaS dan SaaS harus memilih di antara level #2 atau #3.

Multi-tenancy berdasarkan Data (Data Multi-Tenancy)

Untuk sebagian besar aplikasi, kita perlu menggunakan sistem database yang berjalan di atas perangkat keras yang tepat. Di perangkat keras tersebut, kita perlu berbagi penyimpanan ke sesama tenant. Ada beberapa opsi yang tersedia yaitu sebagai berikut:

1. Database server per tenant
2. Database per tenant (satu server untuk banyak tenant)
3. Tabel per tenant
4. Tabel dibagi antara tenant
5. Multi-tenant aware database

Pendekatan #1 dan #2, berbagi database server atau database, dapat diterima dalam IaaS, namun sangat mahal untuk implementasi PaaS atau SaaS. Sebagai contoh, sangat tidak praktis menyimpan jutaan basis data satu per setiap penyewa. Pendekatan #3, memberi satu table per tenant, lebih baik dari #1 dan #2, namun tetap mahal jika kita berbicara tentang jutaan tenant yang bisa saja terjadi. Pendekatan # 4, memiliki satu tabel yang dibagi antara banyak penyewa, dapat memberikan kinerja sesuai kebutuhan. Namun, semua penyewa perlu berbagi skema yang sama dengan metode ini, yang dapat diterima untuk kebanyakan skenario PaaS dan SaaS. Sama seperti in-process multi-tenancy, untuk isolasi, kita perlu mempercayai programmer sistem database kita ini tidak melakukan suatu kesalahan. Atau sebagai solusi tiap tenant bisa memverifikasi SQL filtering daripada memverifikasi kode (Java atau C ++ atau bahasa lainnya) yang digunakan untuk proses multi-tenancy. Pendekatan #5 (misalnya, Oracle sekarang memiliki server basis data multi-tenant) akan memberikan yang terbaik dari semua opsi. Jika diimplementasikan dengan hati-hati, ia dapat memberikan kinerja dan isolasi tingkat #4 bahkan bisa lebih baik. Meskipun kita harus mempercayai pengembang RDBMS tidak membuat kesalahan.

Kelemahan Multi-Tenancy

Seiring bertambahnya jumlah pelanggan pada cloud multi-tanent, basis data terpusat memudahkan penyedia layanan cloud untuk mempertahankan sistem dan mengakomodasi pertumbuhan dan kebutuhan pengguna. Tapi, apa yang terbaik di sisi penyedia layanan cloud tidak selalu yang terbaik bagi pelanggan. Masalah utamanya adalah bahwa semua pelanggan terpaksa untuk berbagi infrastruktur terpusat yang sama.

Tiga kelemahan utama dari multi-tenancy:

  1. Data commingling (pencampuran data): Data Anda berada dalam database yang sama seperti orang lain, jadi Anda mengandalkan perangkat lunak untuk pemisahan dan isolasi. Ini berimplikasi besar bagi pelanggan pemerintah, kesehatan, dan keuangan yang sangat diatur oleh kebijakan mereka masing-masing dan memerlukan pemisahan data yang jelas. Selanjutnya, pelanggaran keamanan terhadap penyedia cloud dapat mengekspos data Anda bersama dengan orang lain yang menggunakan basis data terpusat yang sama di lingkungan multi-tenant.
  2. Pemeliharaan yang berlebihan menyebabkan downtime yang berlebihan: Arsitektur multi-tenant mengandalkan database besar dan kompleks yang memerlukan perangkat keras dan perangkat lunak untuk pemeliharaan secara teratur, sehingga menimbulkan masalah ketersediaan (availability) bagi pelanggan. Sebagai contoh aplikasi penjualan atau pemasaran, dapat mentolerir downtime mingguan setelah jam kerja normal atau pada akhir pekan. Tapi ada daftar aplikasi perusahaan yang berkembang yang perlu dioperasikan harus mencapai layanan 24x7x365.
  3. Satu masalah pelanggan (tenant) adalah masalah setiap orang: Setiap tindakan yang mempengaruhi basis data multi-tenant mempengaruhi semua pelanggan lain. Ketika masalah perangkat lunak atau perangkat keras ditemukan di database multi-tenan, ini menyebabkan pemadaman untuk semua pelanggan, dan upgrade di satu  database tenant berarti upgrade ke semua tenant (bisa memunculkan isu kompatibilitas). Ketersediaan dan upgrade Anda terkait dengan semua pelanggan lain yang berbagi multi-tenancy dengan Anda. Pelanggan enterprise tidak ingin mentolerir pendekatan bersama pada aplikasi yang kritis bagi kesuksesan mereka. Mereka perlu ketersediaan data mereka benar-benar terisolasi dari tenant lain dan jika ada permasalahan harus diselesaikan dengan cepat terlepas dari perusahaan lain yang mungkin akan terpengaruh hal ini dan mereka ingin melakukan upgrade yang sesuai dengan jadwal operasional mereka sendiri.

Resiko Keamanan Multi-Tenancy (Cloud-10 OWASP: Multi-tenancy and Phsycal Security)

Dalam lingkungan multi-tenancy, keamanan lebih banyak berfokus pada pemisahan logis (pada banyak lapisan) daripada pemisahan sumber daya secara fisik. Beberapa penyedia cloud karena menggunakan multi-tenancy berimbas sulitnyanya untuk melakukan audit dan penilaian oleh pengguna layanan tertentu di dalam infrastruktur yang berbagi dengan pengguna lainnya. Berikut resiko keamanan yang timbul dari arsitektur multi-tenancy pada cloud:

  1. Kontrol keamanan logikal yang idak memadai: Sumber daya fisik (CPU, jaringan, penyimpanan / database, tumpukan aplikasi) dibagi-bagi antara beberapa tenant. Itu berarti ketergantungan pada segregasi logis dan kontrol lainnya untuk memastikan bahwa satu penyewa secara sengaja atau tidak sengaja dapat mengganggu keamanan (kerahasiaan, integritas, ketersediaan) penyewa lainnya.
  2. Pengguna yang buruk dan jahat (ignorant and malicous tenant): Jika penyedia cloud memiliki kontrol logis yang lemah antara tenant, tenant yang jahat akan memanfaatkan ini atau bisa juga tenant yang buruk operasinya dapat mengurangi postur keamanan penyewa lainnya.
  3. Layanan bersama dapat menjadi titik tunggal kegagalan sistem: Jika penyedia layanan tidak mengimplementasi arsitektur yang baik untuk layanan mereka maka hal ini dapat dengan mudah menjadi titik kegagalan tunggal karena penyalahgunaan oleh tenant.
  4. Kontrol perubahan yang tidak terkoordinasi dan kesalahan konfigurasi: Bila para tenant berbagi infrastruktur yang dalam operasi mereka maka semua perubahan perlu dikoordinasikan dan diuji dengan baik.
  5. Co-mingled Tenant Data (data tenant yang berbaur): Untuk mengurangi biaya mungkin saja penyedia menyimpan data dari beberapa penyewa pada tabel-space dari database yang sama dan perlakuan yang sama juga mungkin dilakukan untuk data backup. Penghancuran data bisa menjadi tantangan dalam multi-tenancy terutama jika data disimpan di media bersama (database, backup, arsip).
  6. Resiko Kinerja: Salah satu penggunaan layanan yang menggunakan daya lebih banyak (untuk komputasi yang berat) dapat mempengaruhi kualitas layanan yang diberikan kepada tenant lainnya.
  7. Risiko pada Spesific XaaS
  • SaaS: Beberapa klien (tenant) mungkin berbagi tumpukan aplikasi yang sama (database, aplikasi / server web, jaringan). Itu berarti data dari beberapa penyewa mungkin tersimpan dalam database yang sama, mungkin didukung dan diarsipkan bersama-sama, mungkin bergerak pada perangkat jaringan umum (tidak dienkripsi), dan dikelola oleh proses aplikasi umum. Hal ini berarti keamanan sangat bergantung pada keamanan logis yang dibangun di dalam aplikasi untuk memisahkan satu pengguna penyewa dari orang lain.
  • PaaS: Tumpukan platform terbagi di antara penyewa. Kerentanan pada tumpukan platform dapat gangguan atau kesulitan di antara penyewa. Backup data bersama dan arsip.
  • IaaS: Cross Virtual Machine attack. Penyadapan antar mesin milik para tenant. Co-resident dengan postur keamanan yang rendah, kondisi di mana tenant kurang peduli untuk menjaga host mereka tetap tangguh dan ter-update. Khususnya jika salah satu atau lebih dari host dari tenant berhasil ditembus oleh penyerang (attacker).

Kunci untuk memahami tingkat keamanan bagi pelanggan di lingkungan multi-tenancy adalah meminta penyedia cloud Anda tentang perlindungan yang ada dan tentang tanggung jawab untuk memastikan kebijakan isolasi antar tenant tetap terjaga. Selain itu, pemahaman tentang seberapa banyak proses otomatis sangat penting. Hal ini penting mengingat sifat dinamis pada infrastruktur berbasis cloud juga kemungkinan kesalahan konfigurasi keamanan sumber daya sangat mungkin terjadi. Pelanggan (tenat) juga harus bertanya dan mengerti bagaimana mereka dapat berbagi tanggung jawab atas keamanan mereka. Terakhir, Anda harus bertanya kepada penyedia layanan Anda apakah Anda bisa mengaudit lingkungan virtual Anda. Dalam banyak kasus, ini mungkin merupakan persyaratan dari perspektif kepatuhan, namun juga bagus untuk memiliki kemampuan untuk memverifikasi penyedia layanan sesuai dengan kebijakan keamanan dan kontrol yang Anda miliki.

Reference
[1] http://searchcloudcomputing.techtarget.com/definition/multi-tenant-cloud
[2] https://hackernoon.com/multi-tenancy-after-10-years-of-cloud-computing-19de782ef899
[3] https://www.owasp.org/index.php/Cloud-10_Multi_Tenancy_and_Physical_Security
[4] https://www.juniper.net/us/en/local/pdf/whitepapers/2000381-en.pdf
[5] http://searchcloudsecurity.techtarget.com/tip/Securing-a-multi-tenant-environment
[6] https://www.enterpriseirregulars.com/14980/security-risks-of-multi-tenancy/

Leave a Reply

Your email address will not be published. Required fields are marked *