عزل وصوامع لمستودعات البيانات في حلول متعددة العوامل

في إحدى المقالات السابقة ، قمنا بفحص عدة نقاط رئيسية لإنشاء مجموعة متعددة المستأجرين (يشار إليها فيما يلي بالعديد من المستأجرين ) Amazon EKS . فيما يتعلق بالأمن ، هذا موضوع واسع للغاية. من المهم أن نفهم أن الأمان لا يتعلق فقط بمجموعة التطبيقات ، ولكن أيضًا بمخزن البيانات.



AWS كمنصة لحلول SaaS لديها الكثير من التباين لمستودعات البيانات. ولكن ، كما هو الحال في أي مكان آخر ، يتطلب تكوين الأمان بكفاءة ، والعمل على بنية متعددة الأغراض له ، وتكوين مستويات مختلفة من العزلة معرفة معينة وفهمًا لخصائص العمل.

مستودع البيانات المتعددة

إدارة البيانات المتعددة الأغراض بشكل ملائم عبر القواديس ، Silo . الميزة الرئيسية هي فصل الإيجار البيانات (من الآن فصاعدا المستأجر ) في multitenant ادارة العلاقات مع الحلول . ولكن قبل أن نتحدث عن حالات محددة ، سنتناول قليلاً من النظرية العامة.

يجب أن يكون المستأجر فقط الوصول

يعد أمن البيانات أولوية لحلول SaaS . من الضروري حماية البيانات ليس فقط من التدخلات الخارجية ، ولكن أيضًا من التفاعل مع المستأجرين الآخرين . حتى في حالة تعاون مستأجرين مع بعضهما البعض ، ويتم التحكم في الوصول إلى البيانات المشتركة وتكوينها وفقًا لمنطق الأعمال.

معايير الصناعة للتشفير والأمن

قد تختلف معايير المستأجر حسب الصناعة. يتطلب البعض تشفير البيانات بتردد تغيير مفتاح محدد جيدًا ، بينما يتطلب البعض الآخر تيارات موجهة للمستأجر بدلاً من المفاتيح المشتركة . من خلال تحديد مجموعات البيانات مع مستأجرين محددين ، يمكن تطبيق معايير التشفير المختلفة وإعدادات الأمان على المستأجرين الأفراد كاستثناء.

ضبط الأداء على أساس اشتراك المستأجر

عادة ، يوصي مقدمو خدمات SaaS بسير عمل مشترك لجميع المستأجرين . من وجهة نظر الممارسة ، قد لا يكون هذا مناسبًا دائمًا فيما يتعلق بمنطق عمل معين. لذلك ، يمكنك القيام بذلك بشكل مختلف. يتم تعيين مجموعة مختلفة من الخصائص وحدود الأداء لكل مستأجر بناءً على معيار TIER . حتى يتمكن العملاء من الحصول على الأداء المنصوص عليه في اتفاقية SaaS ، يجب على مقدمي الخدمة تتبع استخدام المستأجرين الأفراد . بفضل هذا ، يحصل جميع العملاء على وصول متساوي إلى الموارد.

إدارة البيانات

كما ادارة العلاقات تنمو الخدمات، حتى لا عدد من المستأجرين . إذا قام العميل بتغيير الموفر ، فغالبًا ما يريد تحميل جميع البيانات إلى مورد آخر ، وحذف البيانات القديمة. إذا كان من الممكن تحدي الرغبة الأولى ، فإن تحقيق الثانية مضمون بموجب القواعد العامة لحماية البيانات في الاتحاد الأوروبي. من أجل التنفيذ الصحيح للقواعد ، يجب على موفر SaaS أولاً تحديد صفائف البيانات للمستأجر الفردي .

كيفية تحويل مستودع بيانات عادي إلى عدة عوامل

أود أن ألاحظ على الفور أنه لا يوجد رمز سحري. لا يمكنك فقط التقاط وتكوين صندوق مستودع بيانات المستأجر . يجب مراعاة الجوانب التالية:

• اتفاقية خدمات
• أنماط الوصول للقراءة والكتابة ؛
• الامتثال للوائح ؛
• نفقات.

ولكن هناك عدد من الممارسات المقبولة بشكل عام لفصل وعزل البيانات. دعونا نلقي نظرة على هذه الحالات باستخدام قاعدة بيانات أمازون أورورا العلائقية كمثال .

تقسيم بيانات المستأجر عبر المتاجر والمثيلات المشتركة

يتم استخدام الجدول من قبل جميع المستأجرين . تتم مشاركة البيانات الفردية وتحديدها بواسطة مفتاح tenant_id . يتم تطبيق مصادقة قاعدة البيانات العلائقية على مستوى الأمان . يعتمد الوصول إلى التطبيق على سياسة الوصول ويأخذ بعين الاعتبار مستأجر معين .



الإيجابيات:

• ليس غاليا.

السلبيات:

• إذن قاعدة البيانات. وينطوي هذا على العديد من آليات المصادقة ضمن الحل: AWS IAM وسياسات قواعد البيانات.
• لتحديد المستأجر ، سيكون عليك تطوير منطق التطبيق ؛
• بدون عزل تام ، لا يمكن تطبيق اتفاقية خدمة TIER ؛
• يحد تفويض قاعدة البيانات من تتبع الوصول باستخدام AWS CloudTrail . لا يمكن تعويض ذلك إلا بإضافة معلومات من الخارج. وسيكون من الأفضل تتبع واستكشاف الأخطاء وإصلاحها.

عزل البيانات عن مثيل مشترك

الإيجار ( الإيجار ) لا يزال rassharivat على مستوى مثيل. ولكن في الوقت نفسه ، يتم تخزين البيانات على مستوى قاعدة البيانات. وهذا يجعل مصادقة AWS IAM والتفويض ممكنًا.



الإيجابيات:

• ليس غاليا؛
• AWS IAM هي المسؤولة الكاملة عن المصادقة والتفويض ؛
• يسمح لك AWS IAM بالاحتفاظ بسجلات التدقيق على AWS CloudTrail بدون عكازات كتطبيقات منفصلة.

السلبيات:

• يتم مشاركة مثيلات قاعدة البيانات الأساسية بين المستأجر ، وبالتالي ، من الممكن تدفق الموارد ، والذي لا يسمح بالامتثال الكامل لاتفاقية خدمة TIER .

عزل نسخة قاعدة البيانات للمستأجر

يوضح الرسم البياني تنفيذ قاعدة بيانات المستأجر لعزل سبيل المثال. اليوم ، ربما يكون هذا هو أفضل حل يجمع بين السلامة والموثوقية. هناك AWS IAM و AWS CloudTrail والتدقيق والعزل الكامل للمستأجر .



الإيجابيات:

• يوفر AWS IAM كلاً من المصادقة والتفويض ؛
• هناك مراجعة كاملة ؛
• tenant.

:

• tenant — .

multitenant

يعد ضمان وصول التطبيقات إلى البيانات بشكل صحيح أكثر أهمية من تخزين البيانات في نموذج مستأجر يلبي متطلبات العمل. ليس من الصعب إذا كنت تستخدم AWS IAM للتحكم في الوصول (انظر الأمثلة أعلاه). يمكن للتطبيقات التي توفر وصول المستأجر إلى البيانات أيضًا استخدام AWS IAM . يمكن ملاحظة ذلك في مثال Amazon EKS .



لتوفير الوصول إلى IAM على مستوى الجراب في EKS ، مناسب تمامًا لـ OpenID the Connect (OIDC) ، مع التعليقات التوضيحية لحساب Kubernetes . ونتيجة لذلك ، سيتم تبادل JWT معSTS ، التي ستنشئ وصولاً مؤقتًا للتطبيق إلى موارد السحابة الضرورية. مع هذا النهج ، ليست هناك حاجة لتقديم أذونات متقدمة لمحطات عمل Amazon EKS الأساسية . بدلاً من ذلك ، يمكنك تكوين أذونات IAM فقط للحساب المرتبط بجراب . يتم ذلك بناءً على الأذونات الفعلية للتطبيق الذي يتم تشغيله كجزء من جراب . ونتيجة لذلك ، نحصل على التحكم الكامل في أذونات التطبيقات والجراب .





يدعم تكامل IAM نظام ترخيص شامل للوصول للمستأجر إلى مخازن البيانات. في هذه الحالة ، يتم التحكم في الوصول إلى قاعدة البيانات فقط من خلال المصادقة ، مما يعني أنك بحاجة إلى إدخال مستوى آخر من الأمان.

يصل Amazon EKS إلى قاعدة بيانات متعددة AWS DynamoDB

بإلقاء نظرة فاحصة على الوصول متعدد العناصر ، كل من تطبيق يعمل على Amazon EKS ، يحصل على الوصول إلى قاعدة بيانات متعددة الأغراض من Amazon DynamoDB . في كثير من الحالات ، يتم تنفيذ العمليات المتعددة العناصر في Amazon DynamoDB على مستوى الجدول (في نسبة الجداول والمستأجر 1: 1). كمثال ، خذ بعين الاعتبار مبدأ AWS IAM ( aws-dynamodb-tenant1-policy ) ، الذي يوضح تمامًا نمط الوصول ، حيث ترتبط جميع البيانات بالمستأجر 1 .

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

الخطوة التالية هي ربط هذا الدور بحساب كتلة EKS يستخدم 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}

سيساعدك تعريف pod ، الذي يحتوي على مواصفات serviceAccountName المطلوبة ، على استخدام حساب خدمة tenant1-service-account الجديد .

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

على الرغم من أن IAM المستأجر والحساب وسياسة مركزة، ساكنة، وتدار بواسطة أدوات مثل Terraform و Ansible ، و جراب مواصفات يمكن تكوين حيوي. إذا كنت تستخدم منشئ قوالب مثل Helm ، فيمكن تعيين serviceAccountName كمتغير في حسابات خدمة المستأجر المقابلة . ونتيجة لذلك ، سيكون لكل مستأجر نشره الخاص لنفس التطبيق. في الواقع ، يجب أن يكون لكل مستأجر مساحة اسم مخصصة حيث سيتم تشغيل التطبيقات.

خاتمة

بالنسبة لخدمات SaaS ، من المهم التفكير بعناية في كيفية الوصول إلى البيانات. يجب مراعاة متطلبات التخزين والتشفير والأداء والإدارة من المستأجر . في multitenant لديك أي طريقة مفضلة لتقسيم البيانات. ميزة تشغيل أعباء العمل متعددة العناصر على AWS هي AWS IAM ، والتي يمكن استخدامها لتبسيط التحكم في الوصول إلى بيانات المستأجر. بالإضافة إلى ذلك ، يمكن لـ AWS IAM مساعدتك في تكوين وصول التطبيق إلى البيانات ديناميكيًا.



لقد أثرت الميزات والتقنيات الموصوفة التي قد تكون مفيدة على القليل من النظرية. ولكن في حالات خاصة ، من الضروري دائمًا تحليل معلومات المصدر بشكل مستقل وإنشاء حل شخصي.