درمان انواع بیماری ها با مصرف آب قلیایی
ثبت رپورتاژ آگهی در ارم بلاگ و امتیازات آن
اعداد فرشته در عشق و روابط عاشقانه! ✓ورود به کانال یوتیوب
✓ ارم بلاگ | در 60 ثانیه وبلاگ خودتو بساز !!
در این پست برخی از داخلی های مدل امنیتی 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 ، حتی با اشتراک گذاری.
بسیار خوب ، وقتی در حال مشاهده یک شبکه ، به روز رسانی حساب و غیره هستید ، در مورد امنیت چه اتفاقی می افتد؟ بیایید با گذراندن جریان به روز رسانی حساب شروع کنیم. من از دیدگاه SDK به آن نگاه می کنم ، زیرا UI در واقع کارهای اضافی انجام می دهد. در اینجا جریان است:
پس از بررسی امتیاز ، ما با منطق تجاری دیگر مانند تأیید اولیه ورودی بر خلاف قوانین کسب و کار یا سایر موارد خاص نهاد یا عملیات ادامه می دهیم. برای بررسی دسترسی ، باید برخی از اطلاعات امنیتی را از ردیف حساب بازیابی کنیم. به طور خاص ، ما باید کلید اصلی ، OwnerId و OwningBusinessUnit را بدانیم. هنگامی که آن را دریافت کردیم ، می توانیم بررسی دسترسی را انجام دهیم:
بیایید مراحل را در اینجا طی کنیم:
آ. اگر کاربر در واحد تجاری مشابه شیء باشد ، کاربر به عمق “Business” (نیم پای از UI) نیاز دارد.
ب. اگر شیء در یکی از واحدهای تجاری کودک کاربر است ، کاربر به عمق “والدین: کودک” (3/4 پای از رابط کاربری) نیاز دارد.
ج. در غیر این صورت ، کاربر برای خواندن شیء به عمق “سازمان” نیاز دارد (به عنوان مثال ، اگر در واحد تجاری والدین یا خواهر و برادر باشد).
ما می توانیم همه این بررسی ها را در جستجوی حافظه پنهان انجام دهیم: کسب و کار کاربر و سلسله مراتب کسب و کار سازمان نیز ذخیره می شوند.
بنابراین اساساً این قسمت امنیتی مواردی است که هنگام استفاده از API به روز رسانی یا هنگامی که روی یک فرم روی «ذخیره» کلیک می کنید اتفاق می افتد (هرچند اگر شما این امتیاز را ندارید حتی دکمه «ذخیره» را نیز ارائه نمی دهیم).
وقتی یک شبکه را مشاهده می کنید چطور؟ خوب ، ما نمی خواهیم دسته ای از پرونده ها را بازیابی کنیم و سپس دسترسی سطر به ردیف را در سطح میانی انجام دهیم. ما می خواهیم بتوانیم بررسی های امنیتی را در SQL انجام دهیم تا بتوانیم عملکرد صفحه بندی خوبی داشته باشیم و سوابق بیشتری را که برای برآوردن درخواست کاربر لازم است بازیابی نکنیم.
بنابراین ما روند را کمی وارونه می کنیم. به جای تعیین حداقل عمق امتیاز “خواندن” با نگاه کردن به موقعیت های نسبی کاربر و شی در سلسله مراتب کسب و کار ، ما حداکثر عمق امتیاز “خواندن” را در نهادهای مورد درخواست دریافت می کنیم و از آن برای محدود کردن پرس و جو به آن واحدهای تجاری که کاربر قادر به خواندن آنها خواهد بود. ما همچنین چک مالکیت و اشتراک گذاری چک ها را به عنوان بخشی از پرس و جو انجام می دهیم (البته ما هنوز در مورد نهادهایی که ابتدا مورد پرسش قرار می گیرند PrivilegeCheck را برای “خواندن” انجام می دهیم):
این یک درخواست ساده برای کاربری است که دارای امتیاز حساب “Read” در عمق “Parent: Child” است. کاربر می تواند از طریق مالکیت ، دسترسی به نقش یا اشتراک گذاری دسترسی پیدا کند. بررسی مالکیت بسیار ساده است. برای بررسی نقش ، باید به اشیاء در مشاغل کاربر یا مشاغل کودک نگاه کنیم زیرا آنها دسترسی “والدین: کودک” را دارند. ما از یک جدول کاربردی ، BusinessUnitMap استفاده می کنیم که سلسله مراتب کسب و کار را به صورت یک لیست واحد برای هر واحد تجاری غیر عادی می کند.
برای بررسی اشتراک گذاری ، باید سطرهای موجودیتی را که جدول PrincipalObjectAccess برای موجودیت دارای دسترسی خواندن (قسمت “& 1”) که مدیر اصلی کاربر است یا هر تیمی که کاربر از آنها عضو دارد ، بازیابی کنیم. ما از جدول ابزار SystemUserPrincipals برای بدست آوردن یک لیست مسطح از تمام اصولی که کاربر عضو آن است (از جمله خود نگاشتن به کاربر) استفاده می کنیم. “51 برتر” فقط به این معنی است که ما اولین صفحه یک شبکه را با 50 رکورد در هر صفحه بازیابی می کنیم. از رکورد اضافی برای اطلاع تماس گیرنده استفاده می شود که آیا رکوردهای بیشتری وجود دارد یا خیر.
بسته شدن
امیدواریم این نگاه مختصر در زیر جلد برای شما جالب بوده باشد.
در 60 ثانیه وبلاگ خودتو بساز !!
راجع به اعداد رند اشتباه نکن! ✓ورود به کانال یوتیوب
جهت ورود به اینستاگرام من اینجا را کلیک کنید
تبلیغات نامحدود افزایش بازدید و افزایش فروش
رپورتاژ آگهی ثبت کن و دیده شو !!
مشاهده
وبلاگ neuroncrm
