neuroncrm

در اين پست برخي از داخلي هاي مدل امنيتي CRM را شرح خواهم داد. من نحوه استفاده از نقش ها و امتيازات در پوشش ، نحوه اعمال امنيت براي عمليات مختلف و برخي ساختارهاي داخلي كه اين امكان را فراهم مي كند را شرح خواهم داد.

توجه بفرماييد كه بهترين راه براي بهينه سازي فرآيند هاي كسب و كار استفاده از مايكروسافت سي ار ام است

بررسي اجمالي

در صورت نياز به تجديد نظر سريع در اصول اوليه…

توجه بفرماييد كه بهترين راه براي بهينه سازي فرآيند هاي كسب و كار استفاده از سي ار ام است

مدل امنيتي CRM از احراز هويت مبتني بر Windows (Kerberos/NTLM) و مجوزهاي داخلي استفاده مي كند. اين اساساً يك مدل امنيتي مبتني بر نقش است ، كه در آن نقش به طور مفهومي طبقه اي از افراد (متخصص بازاريابي ، مدير سيستم و غيره) است. CRM از امنيت سطح شي (يعني سطح رديف) با پشتيباني از اشتراك گذاري و تعيين تكليف پشتيباني مي كند. بسته به نقش شما و اشتراك اطلاعات ، مي توانيد به يك شي دسترسي داشته باشيد حتي اگر مالك آن نباشيد.

پياده سازي

توجه بفرماييد كه بهترين راه براي بهينه سازي فرآيند هاي كسب و كار استفاده از مديريت ارتباط با مشتري است

در v1.0 و v1.2 ، CRM از توصيف كننده هاي امنيتي Windows و عملكرد Windows AccessCheck (در واقع AuthzAccessCheck) براي تأييد دسترسي كاربران استفاده كرد. توصيف كننده امنيت همان چيزي است كه حقوق شما را در پرونده ها ، فهرست ها و غيره كنترل مي كند. توصيف كننده امنيت CRM حاوي اطلاعاتي است كه كاربران ، تيم ها و نقش ها از چه حقوق خاصي بر روي يك شي برخوردار هستند و در رديف موارد ذخيره مي شود. هدف، كاربران ، تيمها و نقشها همه توسط يك شي AD (شي كاربر يا يك گروه AD) نشان داده مي شوند. براي بررسي دسترسي ، توصيف كننده امنيت را بازيابي مي كنيم و با استفاده از توكن AccessCheck با استفاده از نشانگر كاربري كه به CRM وارد شده است ، تماس مي گيريم ، كه شامل گروه هايي از همه نقش ها و تيم هايي است كه آنها عضو آن بودند.

در نسخه 3.0 ، ما به يك مدل امنيتي مبتني بر پايگاه داده نقل مكان كرديم زيرا مزاياي زيادي نسبت به مدل توصيف كننده امنيت به ما داد.

نقشها و امتيازات

امتياز از نظر مفهومي حق انجام عمل است. براي مثال ، داشتن امتياز “خواندن حساب” به شما اين حق را مي دهد كه بخواهيد يك حساب را بخوانيد. بدون امتياز ، ما حتي به خود زحمت نمي دهيم نهاد حساب را در UI نشان دهيم. ما اين را PrivilegeCheck مي ناميم. آنچه در واقع دسترسي شما به يك نمونه شيء (يا رديف) خاص را كنترل مي كند ، عمق امتياز و عمق نسبي واحد تجاري است كه شما به آن واحد تجاري تعلق داريد (شيء متعلق به آن است (مگر اينكه شيء متعلق به سازمان باشد)) به ما اين قسمت را AccessCheck مي ناميم. در اينجا يك مثال است:

اگر باب داراي امتياز “خواندن حساب” در والدين باشد: عمق فرزند ، مي تواند حساب A را بخواند ، اما حسابهاي B يا C را نخواند. اگر اين امتياز را نداشت ، حسابها حتي در UI نشان داده نمي شوند به Depth قطعاتي است كه در رابط كاربري Role Editor مشاهده مي كنيد. بنابراين يك نقش در واقع مجموعه اي از {جفت ، عمق} جفت و يك بررسي كامل امنيتي است = PrivilegeCheck + AccessCheck (AccessCheck به طور ضمني امتيازات را نيز بررسي مي كند ، اما PrivilegeCheck كارآمدتر است زيرا ما براي رد كردن شخص به هيچ اطلاعات شيء نيازي نداريم كه حتي امتياز اوليه را ندارد).

اشتراك گذاري و واگذاري

CRM همچنين از اشتراك گذاري و تعيين تكليف پشتيباني مي كند. واضح است كه فقط تغيير مالك يك شي است. اشتراك گذاري امكان لغو محدوديت هاي AccessCheck را فراهم مي كند ، اما محدوديت هاي PrivilegeCheck هنوز اعمال مي شود. بنابراين در مثال بالا ، اگر حساب B با Bob با حقوق خواندن به اشتراك گذاشته شود ، او مي تواند B را بخواند ، اما هنوز هم نمي تواند C را بخواند. C ، حتي با اشتراك گذاري.

PrivilegeCheck و AccessCheck

بسيار خوب ، وقتي در حال مشاهده يك شبكه ، به روز رساني حساب و غيره هستيد ، در مورد امنيت چه اتفاقي مي افتد؟ بياييد با گذراندن جريان به روز رساني حساب شروع كنيم. من از ديدگاه SDK به آن نگاه مي كنم ، زيرا UI در واقع كارهاي اضافي انجام مي دهد. در اينجا جريان است:

پس از بررسي امتياز ، ما با منطق تجاري ديگر مانند تأييد اوليه ورودي بر خلاف قوانين كسب و كار يا ساير موارد خاص نهاد يا عمليات ادامه مي دهيم. براي بررسي دسترسي ، بايد برخي از اطلاعات امنيتي را از رديف حساب بازيابي كنيم. به طور خاص ، ما بايد كليد اصلي ، OwnerId و OwningBusinessUnit را بدانيم. هنگامي كه آن را دريافت كرديم ، مي توانيم بررسي دسترسي را انجام دهيم:

بياييد مراحل را در اينجا طي كنيم:

1. اگر كاربر صاحب ركورد باشد ، عمق موضوع مهم نيست (به ياد داشته باشيد ، ما قبلاً از قسمت PrivilegeCheck گذشته ايم) ، بنابراين آنها دسترسي دارند.
2. در مرحله بعد ، ما بايد حداقل عمق امتياز مورد نياز را تعيين كنيم:

آ. اگر كاربر در واحد تجاري مشابه شيء باشد ، كاربر به عمق “Business” (نيم پاي از UI) نياز دارد.

ب. اگر شيء در يكي از واحدهاي تجاري كودك كاربر است ، كاربر به عمق “والدين: كودك” (3/4 پاي از رابط كاربري) نياز دارد.

ج. در غير اين صورت ، كاربر براي خواندن شيء به عمق “سازمان” نياز دارد (به عنوان مثال ، اگر در واحد تجاري والدين يا خواهر و برادر باشد).

ما مي توانيم همه اين بررسي ها را در جستجوي حافظه پنهان انجام دهيم: كسب و كار كاربر و سلسله مراتب كسب و كار سازمان نيز ذخيره مي شوند.

1. سپس متوجه مي شويم كه آيا كاربر داراي تمام امتيازات مورد نياز در حداقل عمق مورد نياز است يا خير. در اطلاعات امتيازاتي كه براي كاربر ذخيره مي كنيم حداكثر عمق موجود در آن است.
2. اگر كاربر از طريق چك هاي مالك يا چك هاي مبتني بر نقش دسترسي پيدا نمي كند ، در مرحله بعد اشتراك گذاري را بررسي مي كنيم. CRM تمام اطلاعات اشتراك گذاري را در جدولي به نام PrincipalObjectAccess ذخيره مي كند كه كاربران و تيم ها را به اشيايي كه به طور صريح يا از طريق عمليات آبشاري با آنها به اشتراك گذاشته شده است ترسيم مي كند.
3. اگر كاربر هنوز در اين نقطه دسترسي نداشته باشد ، خطاي Access-Denied را برمي گردانيم.

بنابراين اساساً اين قسمت امنيتي مواردي است كه هنگام استفاده از API به روز رساني يا هنگامي كه روي يك فرم روي «ذخيره» كليك مي كنيد اتفاق مي افتد (هرچند اگر شما اين امتياز را نداريد حتي دكمه «ذخيره» را نيز ارائه نمي دهيم).

وقتي يك شبكه را مشاهده مي كنيد چطور؟ خوب ، ما نمي خواهيم دسته اي از پرونده ها را بازيابي كنيم و سپس دسترسي سطر به رديف را در سطح مياني انجام دهيم. ما مي خواهيم بتوانيم بررسي هاي امنيتي را در SQL انجام دهيم تا بتوانيم عملكرد صفحه بندي خوبي داشته باشيم و سوابق بيشتري را كه براي برآوردن درخواست كاربر لازم است بازيابي نكنيم.

بنابراين ما روند را كمي وارونه مي كنيم. به جاي تعيين حداقل عمق امتياز “خواندن” با نگاه كردن به موقعيت هاي نسبي كاربر و شي در سلسله مراتب كسب و كار ، ما حداكثر عمق امتياز “خواندن” را در نهادهاي مورد درخواست دريافت مي كنيم و از آن براي محدود كردن پرس و جو به آن واحدهاي تجاري كه كاربر قادر به خواندن آنها خواهد بود. ما همچنين چك مالكيت و اشتراك گذاري چك ها را به عنوان بخشي از پرس و جو انجام مي دهيم (البته ما هنوز در مورد نهادهايي كه ابتدا مورد پرسش قرار مي گيرند PrivilegeCheck را براي “خواندن” انجام مي دهيم):

اين يك درخواست ساده براي كاربري است كه داراي امتياز حساب “Read” در عمق “Parent: Child” است. كاربر مي تواند از طريق مالكيت ، دسترسي به نقش يا اشتراك گذاري دسترسي پيدا كند. بررسي مالكيت بسيار ساده است. براي بررسي نقش ، بايد به اشياء در مشاغل كاربر يا مشاغل كودك نگاه كنيم زيرا آنها دسترسي “والدين: كودك” را دارند. ما از يك جدول كاربردي ، BusinessUnitMap استفاده مي كنيم كه سلسله مراتب كسب و كار را به صورت يك ليست واحد براي هر واحد تجاري غير عادي مي كند.

براي بررسي اشتراك گذاري ، بايد سطرهاي موجوديتي را كه جدول PrincipalObjectAccess براي موجوديت داراي دسترسي خواندن (قسمت “& 1”) كه مدير اصلي كاربر است يا هر تيمي كه كاربر از آنها عضو دارد ، بازيابي كنيم. ما از جدول ابزار SystemUserPrincipals براي بدست آوردن يك ليست مسطح از تمام اصولي كه كاربر عضو آن است (از جمله خود نگاشتن به كاربر) استفاده مي كنيم. “51 برتر” فقط به اين معني است كه ما اولين صفحه يك شبكه را با 50 ركورد در هر صفحه بازيابي مي كنيم. از ركورد اضافي براي اطلاع تماس گيرنده استفاده مي شود كه آيا ركوردهاي بيشتري وجود دارد يا خير.

بسته شدن

اميدواريم اين نگاه مختصر در زير جلد براي شما جالب بوده باشد.