استراتيجية تحديث الكيان

Question

هناك بعض المناقشات في فريقي حول تحديث بيانات الكيان وأفضل طريقة للتعامل معها.هذا إطار أمني، وهنا بعض القيود والأفكار.

1. يحتوي كل جدول في قاعدة البيانات على PK وهو دليل، وهذا مطلوب لحل التجميع متعدد العقد لدينا.الفكرة هي أننا لا نريد الكشف عن ذلك على أحد الكيانات للعميل عبر واجهة برمجة التطبيقات (API) لأنه يمكن أن يفعل شيئين،
   1. منحهم المزيد من المعلومات اللازمة لعملهم وإعطاء المتسللين المزيد من المعلومات حول النظام.
   2. كابوس الدعم هو أن العميل يقوم بتشفير هذا المعرف بطريقة ما، وإذا كنا بحاجة إلى تغيير عملاء PK لدينا، فسيتأثرون.

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

هناك طريقة أخرى تتمثل في إنشاء مفتاح بديل وإظهاره للعميل حيث يمكنه استخدامه كما يريد ونحن لا نهتم لأنه غير مرتبط بـ PK الخاص بنا.

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

هناك مشكلة أخرى وهي كيفية دعم التحديثات الجزئية، والمشكلة هي أن لديك كيانًا يحتوي على 10 خصائص و4 مجموعات وما إلى ذلك...باستخدام مجموعة الاسم + المجال وحدد الخاصية المراد تحديثها بدلاً من سحب حقل تغيير الكائن بالكامل 1، أرسل مرة أخرى للتحديث.أقول كسولًا في تحميل المجموعات، ولكن لست متأكدًا مما إذا كان التحديث الجزئي منطقيًا.

أفكار؟

شكرًا!

Answer 1

سيكون نهجي لإطار الأمان كما يلي:

• امنح أي شيء في قاعدة البيانات معرفًا داخليًا (عمود الهوية، التسلسل، أيًا كان دعم قاعدة البيانات الخاصة بك."عمود المعرف الأصلي الذي تم إنشاؤه" في وضع السبات).في النهاية، ستحتاج إليها، كما أن تعديلها يتطلب الكثير من العمل.

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

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

Answer 2

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

هل يمكن أن تقدم المزيد من التفاصيل حول تلك التحديثات الجزئية؟ لم أحصل عليه. : /

Answer 3

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

هذا النهج هو الأكثر شيوعا في جميع الشركات. UID ليس كذلك PII. لذلك أنت بخير قانونيا كما كان من وجهة نظر أمنية.