Isolasi dan silo untuk gudang data dalam solusi multitenant

Dalam salah satu artikel sebelumnya , kami membahas beberapa poin penting dalam menyiapkan kluster Amazon EKS multitenant (selanjutnya multitenant ) . Sejauh menyangkut keamanan, ini adalah topik yang sangat luas. Penting untuk dipahami bahwa keamanan tidak hanya berlaku untuk aplikasi cluster, tetapi juga untuk data warehouse. AWS sebagai platform untuk solusi SaaS memiliki banyak variabilitas untuk gudang data. Tetapi, seperti di tempat lain, pengaturan keamanan yang kompeten, yang mengerjakan arsitektur multitenant untuk itu, pengaturan berbagai tingkat isolasi memerlukan pengetahuan dan pemahaman tertentu tentang spesifik pekerjaan.

Gudang data multitenant

Lebih mudah untuk mengelola data multitenant menggunakan silo, Silo . Fitur utama adalah pemisahan data sewa (selanjutnya disebut penyewa ) dalam solusi SaaS multitenant . Tetapi sebelum kita berbicara tentang kasus-kasus tertentu, kita akan menyentuh sedikit teori umum.

Hanya penyewa yang memiliki akses

Keamanan data adalah prioritas untuk solusi SaaS . Penting untuk melindungi data tidak hanya dari intrusi eksternal, tetapi juga dari interaksi dengan penyewa lain . Bahkan dalam kasus ketika dua penyewa bekerja sama satu sama lain, dan akses ke data bersama dikendalikan dan dikonfigurasi sesuai dengan logika bisnis.

Standar Industri untuk Enkripsi dan Keamanan

Standar penyewa dapat bervariasi menurut industri. Beberapa memerlukan enkripsi data dengan frekuensi perubahan kunci yang jelas, sementara yang lain memerlukan kunci berorientasi penyewa bukan kunci bersama . Dengan mengidentifikasi dataset dengan penyewa tertentu , standar enkripsi dan pengaturan keamanan yang berbeda dapat diterapkan pada penyewa individu sebagai pengecualian.

Penyesuaian kinerja berdasarkan langganan penyewa

Biasanya, penyedia SaaS merekomendasikan alur kerja umum untuk semua penyewa . Dari sudut pandang praktik, ini mungkin tidak selalu nyaman dalam kaitannya dengan logika bisnis tertentu. Karena itu, Anda dapat melakukannya secara berbeda. Setiap penyewa diberi serangkaian properti dan batas kinerja yang berbeda berdasarkan standar TIER . Agar pelanggan mendapatkan kinerja yang dinyatakan dalam perjanjian SaaS , penyedia harus memantau penggunaan penyewa individu . Berkat ini, semua pelanggan menerima akses yang sama ke sumber daya.

Manajemen data

Dengan pertumbuhan layanan SaaS , jumlah penyewa juga meningkat . Jika klien mengubah penyedia, paling sering ia ingin semua data dimuat ulang ke sumber daya lain, dan yang lama dihapus. Jika keinginan pertama dapat diperdebatkan, maka pemenuhan keinginan kedua dijamin oleh Peraturan Perlindungan Data Umum Uni Eropa. Untuk pelaksanaan aturan yang benar, penyedia SaaS pada awalnya harus mengidentifikasi set data penyewa individu .

Bagaimana mengubah Gudang Data biasa menjadi multitenant

Hanya ingin mencatat bahwa kode ajaib tidak ada. Anda tidak bisa begitu saja pergi dan menyiapkan silo gudang data penyewa . Aspek-aspek berikut harus dipertimbangkan:

• Perjanjian Layanan;
• Akses pola untuk membaca dan menulis;
• Kepatuhan terhadap peraturan;
• Beban.

Tetapi ada sejumlah praktik yang diterima secara umum untuk memisahkan dan mengisolasi data. Mari kita lihat kasus-kasus ini menggunakan database relasional Amazon Aurora sebagai contoh .

Partisi data penyewa dalam repositori dan instance bersama

Tabel ini digunakan oleh semua penyewa . Data individual dibagikan dan diidentifikasi oleh kunci tenant_id . Otorisasi database relasional diimplementasikan pada tingkat keamanan baris . Akses ke aplikasi berfungsi berdasarkan kebijakan akses dan memperhitungkan penyewa tertentu .



Pro:

• Itu tidak mahal.

Minus:

• Otorisasi tingkat basis data. Ini menyiratkan beberapa mekanisme otorisasi dalam solusi: AWS IAM dan Kebijakan Database;
• Untuk mengidentifikasi penyewa, Anda harus mengembangkan logika aplikasi;
• Tanpa isolasi sepenuhnya, perjanjian layanan TIER tidak dapat ditegakkan ;
• Basis Data Level Authorization membatasi pelacakan akses dengan AWS CloudTrail . Ini hanya dapat dikompensasi dengan menambahkan informasi dari luar. Lebih baik melakukan pelacakan dan troubleshooting.

Isolasi data pada instance bersama

Sewa ( sewa ) masih rassharivat di tingkat instance. Tetapi pada saat yang sama, bunkering data terjadi di tingkat basis data. Ini memungkinkan otentikasi dan otorisasi IAM AWS.



Pro:

• Itu tidak mahal;
• AWS IAM bertanggung jawab penuh atas otentikasi dan otorisasi;
• AWS IAM memungkinkan Anda menyimpan log audit di AWS CloudTrail tanpa kruk sebagai aplikasi terpisah.

Minus:

• Mesin virtual basis data dibagi antara penyewa , oleh karena itu, aliran sumber daya dimungkinkan, yang tidak memungkinkan untuk sepenuhnya mematuhi perjanjian layanan TIER .

Isolasi instance database untuk penyewa

Diagram menunjukkan implementasi database penyewa saat mengisolasi instance. Saat ini, ini mungkin solusi terbaik yang menggabungkan keamanan dan keandalan. Ada AWS IAM , audit AWS CloudTrail , dan isolasi penyewa penuh .



Pro:

• AWS IAM menyediakan otentikasi dan otorisasi;
• Ada audit penuh;
• tenant.

:

• tenant — .

multitenant

Memastikan bahwa aplikasi memiliki akses yang tepat ke data lebih penting daripada menyimpan data dalam model penyewa yang memenuhi persyaratan bisnis. Tidak sulit jika Anda menggunakan AWS IAM untuk kontrol akses (lihat contoh di atas). Aplikasi yang menyediakan akses data untuk penyewa juga dapat menggunakan AWS IAM . Ini bisa dilihat pada contoh Amazon EKS .



Untuk memberikan akses ke IAM di tingkat pod di EKS , sangat cocok dengan OpenID the Connect (OIDC) , dengan anotasi ke akun Kubernetes . Akibatnya, JWT akan ditukar denganSTS , yang akan membuat akses sementara untuk aplikasi ke sumber daya cloud yang diperlukan. Dengan pendekatan ini, tidak perlu memperkenalkan izin canggih untuk workstation inti EKS Amazon . Sebagai gantinya, Anda hanya dapat mengonfigurasi izin IAM untuk akun yang terkait dengan pod . Ini dilakukan berdasarkan izin sebenarnya dari aplikasi yang berjalan sebagai bagian dari pod . Akibatnya, kami mendapatkan kontrol penuh atas izin aplikasi dan pod .





Integrasi IAM mendukung sistem otorisasi yang komprehensif untuk akses penyewa ke penyimpanan data. Dalam hal ini, akses ke basis data dikontrol hanya melalui otentikasi, yang berarti bahwa Anda perlu memasuki tingkat keamanan lain.

Amazon EKS mengakses database multitenant AWS DynamoDB

Melihat lebih dekat pada akses multitenant , baik aplikasi yang berjalan di Amazon EKS , mendapatkan akses ke database multitenant DynamoDB Amazon . Dalam banyak kasus, proses multitenant di Amazon DynamoDB diimplementasikan pada tingkat tabel (dalam rasio tabel 1: 1 dengan penyewa ). Sebagai contoh, pertimbangkan prinsip AWS IAM ( kebijakan aws-dynamodb-tenant1 ), yang secara sempurna menggambarkan pola akses di mana semua data terkait dengan Tenant1 .

{
   ...
   "Statement": [
       {
           "Sid": "Tenant1",
           "Effect": "Allow",
           "Action": "dynamodb:*",
           "Resource": "arn:aws:dynamodb:${region}-${account_id}:table/Tenant1"
       }
   ]
}

Langkah selanjutnya adalah mengaitkan peran ini dengan akun kluster EKS yang menggunakan OpenID .

eksctl utils associate-iam-oidc-provider \
      --name my-cluster \
      --approve \
      --region ${region}

eksctl create iamserviceaccount \
      --name tenant1-service-account \
      --cluster my-cluster \
      --attach-policy-arn arn:aws:iam::xxxx:policy/aws-dynamodb-tenant1-policy \
      --approve \
      --region ${region}

Definisi pod , yang berisi spesifikasi serviceAccountName yang diperlukan , akan membantu Anda menggunakan akun layanan akun tenant1-layanan-baru .

apiVersion: v1
kind: Pod
metadata:
 name: my-pod
spec:
serviceAccountName: tenant1-service-account
 containers:
 - name: tenant1
…

Sementara akun dan kebijakan penyewa IAM terfokus, statis, dan dikelola oleh alat-alat seperti Terraform dan Ansible , spesifikasi pod dapat dikonfigurasikan secara dinamis. Jika Anda menggunakan pembuat templat seperti Helm , serviceAccountName dapat disetel sebagai variabel dalam akun layanan penyewa terkait . Akibatnya, setiap penyewa akan memiliki penempatan aplikasi yang sama untuk aplikasi yang sama. Bahkan, setiap penyewa harus memiliki ruang nama khusus di mana aplikasi akan berjalan.

Kesimpulan

Untuk layanan SaaS , penting untuk berpikir hati-hati tentang bagaimana data akan diakses. Harus mempertimbangkan persyaratan penyimpanan, enkripsi, kinerja, dan manajemen dari penyewa . Dalam multitenant memiliki salah satu metode pemartisian data yang disukai. Keuntungan menjalankan beban kerja AWS multitenant adalah AWS IAM , yang dapat digunakan untuk menyederhanakan kontrol akses untuk data penyewa. Selain itu, AWS IAM dapat membantu Anda mengonfigurasi akses aplikasi ke data secara dinamis.



Fitur dan teknik yang dijelaskan yang mungkin berguna menyentuh sedikit teori. Tetapi dalam kasus khusus selalu diperlukan untuk secara independen menganalisis sumber informasi dan membuat solusi yang dipersonalisasi.