تور آشنایی با پلتفرم خودکار قسمت نوزدهم

متن صدای ویدیو :

با یکی دیگه از سری قسمت های تور آشنایی با پلتفرم خودکار در خدمتتون هستم

خب دوستان تو این قسمت میخواهیم راجع به امنیت صحبت کنیم ، امنیت پلتفرم با استفاده از AspNetIdentity هست که بر اساس owin و token base هست که بتونه از طریق device  های مختلف اجرا بشه و عملیات Authenticate و Authorize رو انجام بده

خود مدل Identity یک مدل role base هست یعنی شما یک سری role تعریف میکنید و وقتی میخواید یک متد رو اجرا کنید ، اون نقش هارو بررسی میکنید

من برای اینکه به شما نشون بدم ما از قسمت امنیت اول مدیریت نقش رو باز میکنیم ، تو مدیریت نقش ها وقتی پلتفرم رو نصب میکنید یک سری نقش پیشفرض هست مثلا تو قسمت توسعه دهندگان نقش دیباگ رو داریم و در قسمت کلیدی هم سه تا نقشه مدیر عمومی و کاربر داریم

خب اینها خیلی جنرال این نقش ها تعریف شده شما هم باید برای هرکار خاصی که میخواهید نقش اون کار رو انجام بدید

مثلا نقش انجام کار ایکس ، بعد این نقش ها به یک سری گروه ها وصل میشن ، باز من تو امنیت که بیام مدیریت گروه ها ، مثلا گروه دسترسی های مدیر همه نقش ها کلیدی رو داره ، مدیر عمومی کاربر

و شما اون نقش هایی که تعریف میکنید به گروه ها تخصیص می دهید مثلا گروه admin ، مشتریان ، کارشناسان ، حسابداران و ...

و هر کدوم برای نقش هایی که اون گروه تعیین شده به گروه ها دسترسی داده میشه سپس گروه هارو میام به کاربر ها اضافه میکنیم ، هر کاربر میتونه هر چقدر میخاد گروه عضو باشه ، من تو قسمت مدیریت کاربران بخش ویرایش اگر بزنم با دسترسی مدیر چندتا کاربر داری ، میبینید پیشرفض کاربر admin هست ، پس هر کاربر میتونه هر چقدر میخاد گروه داشته باشه و هر گروه هر چقدر میخواد نقش داشته باشه ، در سطح برنامه فقط نقش ها چک میشه و اصلا گروه ها بعنوان دسترسی چک نمیشه ، این خود role ها هستند که مهم اند ، گروه ها فقط به عنوان دسته بندی و ساده کردن دسترسی دادن ، شما وقتی گروه را آپدیت میکنی نقش هارو ویرایش میکنی ، کل کاربرای گروه ، نقش ها جدی گروه براشون اعمال میشه , اما سوای همه اینها ما تمام رکورد هامون در سطح دیتابیس ، من مثلا مدیریت نقش ها که برم سه تا نقش داره ، هر رکورد در دیتابیس ما ، اینم قبلا دیدین اینترفیس IAccessRole هست که تو base entity ما هست که تمام entity های ما از اون ارث می بره ، entity ها نقش مشاهده رو دارن یعنی چه کاربری بتونه رکورد رو در دیتابیس ببینه ، نقش دسترسی ، چه کاربری بتونه رکورد در دیتابیس رو دسترسی بده روش و نقش ویرایش چه کاربری بتونه در نقش ویرایشگر این رکورد در دیتابیس رو داشته باشه .

ما یک قسمتی هم داریم به اسم اطلاعات پایه که تو مدیریت محتوا  هست ، تو قسمت اطلاعات پایه ما تمام اطلاعات پایه پلتفرم اونجا وجود داره ، انواع و اقسام اطلاعات پایه هم اونجا داریم ، عملیات ها ، سرویس ها ، پروتکل ها ، خط ها ، گروه ها ، متن ها ، نوع فایل ها و حتی کد ها

کدهای تحت سیستم عامل ، تحت مرورگر که قبلا دیدین ، اینا همشون خودشون جزو اطلاعات پایه هستن

من الان مثلا عملیات هارو انتخاب میکنم ، این عملیات ها به چه منظور استفاده میشه

ببینید شما فرض کنید که رکوردی که در دیتابیس هست ، حالا نقش modify و نقش اعطای دسترسی و نقش دیدنش هست ولی فرض کنید این رکوردی که در دیتابیس هست ، آدرس یک فایل هست روی یک دیسک ، آیا کسی که اجازه خوندن این رکورد در دیتا بیس رو داره ، خوندن خود اون فایل رو متنی هم داره ؟ یا خود فایل عکس رو میتونه ببینه ؟

پس این به یکسری مجوز اضافی ما نیاز داریم ما تمام این مجوز های اضافی رو در اصل بعنوان عملیات ها تمام عملیات های ممکن رو اومدیم تو پلتفرم تعریف کردیم و البته شما خودتون هم میتونید عملیات اضافه کنید

افزودن به خروجی ها ، خواندن از روی دیسک ، درخواست سرویس ، اتصال به یک ارتباط مثل Sql connection مثلا دیدن منبع یک کد ، دیدن سورس یک کد ، مشاهده رویداد های یک سرویس ، استفاده از یک اسمبلی کامپایل شده و حالا عملیات های دیگه ای که مثلا وجود داره ، مثلا عملیات نوشتن روی دیسک رو انتخاب میکنم ، شما میبینید که ما تو اطلاعات پایه میتونیم به یه سری فیلد پیشفرض برای اونا پر کنیم ، حالا چجوری از این نوشتن بر روی دیسک استفاده شده باز ما تو قسمت امنیت ، یه قسمتی داریم به اسم مدیریت مجوزهای عملیاتی ، همون مجوز ها بر روی عملیات ها رو ما اینجا تعریف میکنیم

مثلا ما مجوز های عملیات بر روی دیسک ، مجوزهای مثلا مسیر فایل ها ، اینا دسته بندی هایی هست که من انجام دادم ، شما هم به صورت دلخواه میتونین انجام بدید ، مثلا مجوز نوشتن در مسیر فایل ها .

من این رو انتخاب مبکنم ، اولا میبینید که عملیاتش انتخاب شده ، نوشتن بر روی دیسک پس باید نام دلخواه تون رو بدید به مجوز اون مثلا نوشتید مجوز نوشتن در مسیر فایل ها ، فایل ها یه فولدری هست که ما میتونیم فایل های کاربر رو در اونجا قرار بدیم ، بعد چه نقشی اینکار رو بکنه ، بصورت پیشفرض نوشته شده مدیر ، حالا شما میتونید یک نقش خاص برای این نوشتن روی مسیر فایل ها بسازید که حتما از اون نقش استفاده کنید ، ما برای سادگی کار ، یک نقش مدیر به صورت کلی گرفتیم و اکثر کارها رو به اون نقش دادیم به اسم مدیر ، اما شما بهتره که برای هر کار خاصی ، نقش خاص خودشو داشته باشه ، نوع اطلاعات پایه ، مسیر هاست ، حالا اطلاع پایه کدوم مسیر ، تو مسیر ها که میاین با یک رابطه پدر فرزندی میبینیم که فایل ها اینجا قرار داره، من اگه برگردم توی اطلاعات پایه تموم اطلاعات پایه ما به صورت پدر فرزندی هست، یعنی به صورت tree هست و شما می تونید تا n لول این اطلاعات رو تکمیل کنید، مثلا همین مسیر ها رو من اگر انتخاب کنم، نوع اصلاع پایه مسیرها ، توی مسیرها اگر من بیام توی فایل ها، خود فایل ها رو انتخاب کنم، شما میبینید که آدرسش اینجا هست، ریشه سایت فولدر Files.

 پس ما می خوایم دسترسی نوشتن بدیم به این فولدر، اومدیم یک مجوز تعریف کردیم، به اسم مجوز نوشتن در مسیر فایل ها، نوع عملیاتش رو گذاشتیم نوشتن بر روی دیسک، نقش اش رو گذاشتیم مدیر، نوع اطلاع پایه مسیر ها و اطلاع پایه مون خود فولدر فایل ها، حالا میبینید که اون سه تا نقش رو خود دیتابیس هم داره و اینرو ذخیره می کنیم، به این طریق این مجوز برای ما ساخته میشه و ما می تونیم ازش استفاده کنیم. من حالا یک اسلایدی هست که اینرو براتون نشون میدم که بیشتر توضیح میده اینو.

خب دوستان مدل امنیتی پلتفرم رو ما اینجا میبینیم که اصطلاحا بهش میگیم شیر شارپ، مدل به این صورت هست که درخواستی که از سمت کاربر میاد یا آدرس یک صفحه هست یا آدرس یک سرویس که در هر دو صورت دسترسی چه آدرس صفحه چه آدرس سرویس چک میشه که یوزر دسترسی داشته باشه و در مرحله بعد اگر از این مرحله عبور کنه توی این مرحله هم مشاهده صفحه که از همون سه تا role ، view، modify و access هست ولی این چک کردن دسترسی اجرای سرویس رو من بعد از این اسلاید براتون توضیح میدم که روی پلتفرم کجا هست. اگر از این مرحله عبور کنیم میاد مرحله بعد دوباره روی دیتابیس که هر رکوردی اون سه تا دسترسی view، modify و access رو داره چک میشه و توی سمت business هم کنترل دسترسی اجرای عملیات خاص بر روی منبع که همین چند لحظه پیش براتون توضیح دادم که ما یکسری عملیات تعریف میکنیم و برای عملیات بر روی هر منبع یک مجوز تعریف میکنیم که اون مجوز رو چک میکنیم.

حالا من برمیگردم توی پلتفرم تا این قسمت کنترل کردن سرویس رو هم براتون توضیح بدم، دوستان توی همین قسمت مدیریت مجوزهای عملیاتی ما یه قسمتی داریم به عنوان مجوزهای عملیات برروی سرویس ها، از این مجوزهای عملیات بر روی سرویس ها ما در اصل دسته بندی های مختلف داریم توی سرویس ها، سرویس های مدیریت فایل سیستم، سرویس های مدیریت محتوا، سرویس های توسعه و سرویس های امنیتی، من مثلا اگر وارد این قسمت سرویس های توسعه بشم باز خودش به یکسری زیر مجموعه تقسیم میشه مثلا مجوز عملیات بر روی سرویس های مدیریت وب کانفیگ و مجوز عملیات بر روی سرویس های مدیریت تنظیمات وب کانفیگ، وارد این زیر مجموعه که بشم میبینید که چندتا مجوز وجود داره که درخواست اجرای سرویس ایجاد ویرایش یک تنظیم، درخواست اجرای سرویس حذف یک تنظیم، درخواست اجرای سرویس لیست تنظیمات با صفحه بندی و مرتب سازی، درخواست اجرای سرویس لیست فیلدهای اطلاعات پایه .

اولا اگه یادتون باشه از ویدیوی قبلی توضیح دادیم که پلتفرم service bace هست و هر عملیات و action ایی که قراره توی دیتابیس توی پلتفرم انجام بشه حتما باید یک سرویس ما به اذاش تعریف بشه و به ازای هر سرویسی که تعریف میشه، شما حتما باید بیایید یک مجوز درخواست اجرای اون سرویس رو تعریف کنید، من الان درخواست اجرای سرویس ایجاد ویرایش یک تنظیم رو انتخاب کنم، باز میبینید مثل مجوز قبلی هست، اولا عملیات اش درخواست یک سرویس یا اجرای یک سرویس هست یعنی شما به عنوان یک کاربر یک سرویس رو اجرا کنید یعنی یک نقش داره که ما در پلتفرم به طور پیش فرض نقش مدیر رو برای اکثر سرویس ها قرار دادیم ، نقش مدیر به اکثر مجوزها داده شده، نوع اطلاعات پایه اش از نوع سرویسه و اطلاع پایه اش سرویس ایجاد و ویرایش یک تنظیم هست برای مدریت تنظیمات وبکانفیگ .

خود سرویس ها هم یک اطلاع پایه هست با اینکه یک صفحه جدا برای ایجاد و ویرایش داره ولی به عنوان اطلاع پایه هم هست که بتونیم روش مجوزهای مختلف تعریف کنیم ، پس این مجوزها

همونطور که تو اسلاید قبل نشون دادم ، اینجا تعریف میشه تا توی اون مدل امنیتی بعدا" همونطور که تو اسلاید نشون دادم ازش استفاده بشه ، حالا من دوباره بر می گردم تو اسلاید تا بقیه رو توضیح بدم .

خب دوستان ما تو مدل امنیتی پلتفرم دو تا استراتژی امنیتی داریم که با تغییر یک true به false و برعکس این دو تا استراتژی رو میشه با هم جایگزین کرد.

این تغییر true به false رو من جلوتر توی سورس کد بهتون نشون میدم کجا باید تغییر کنه که این اتفاق بیفته .

اما اول خود استراتژی ها :

استراتژی پیش فرض :یعنی اون چیزی که وقتی پلتفرم رو نصب می کنید ، اجرا میشه . کاربر برای استفاده از سرویس S برای اجرای عملیات X دارای مجوز XS بر روی منبع Y  داری مجوز اجرای عملیاتی XY :

باید مجوز اجرای سرویس xs را داشته باشد

باید مجوز اجرای عملیات xy را داشته باشد.

این قسمت اول یعنی که فرض کنید یک کاربری میخواد تو یک فولدری بنویسه، پس اولا باید به سرویس نوشتن روی دیسک دسترسی داشته باشه، یعنی مجوز اجرای اون سرویس رو داشته باشه و در ثانی مجوز نوشتن در اون فولدر رو هم باید داشته باشه. پس 2 تا مجوز رو با هم نیاز داره و چون کاربر هر دو مجوز رو داره کار بدون مشکل انجام میشه .

اما در حالت دوم , کاربر برای استفاده از سرویس s برای اجرای عملیات  x دارای مجوز xs بر روی منبع y بدون مجوز اجرای عملیات (کاربر بدون مجوز XY ) قادر به اجرای عملیات X  نخواهد بود.

یعنی فرض کنید که کاربر مجوز اجرای سرویس S رو داره ، تمام سرویس ها باید مجوز اجرای اون سرویس براشون تعریف شده باشه و یک نقشی بهش داده باشند ، اما فرض کنید برای نوشتن تو اون فولدر اصلا admin این سایت فراموش کرده که مجوز تعریف کنه ، یعنی اون فولدر رو به عنوان اطلاعات پایه تعریف نکرده و بعد هم بهش دسترسی نوشتن نداده.

در نتیجه user هم قادر به اجرای نوشتن تو اون folder  نیست. یعنی مزیت این استراتژی این که خیلی سخت گیرانه هست، یعنی اگر admin فراموش کنه روی یک منبعی مانند پرینتر مجوز پرینت گرفتن بده ، کاربر هم نمیتونه یعنی خیلی سختگیرانه و خیلی عمد هست. ولی از اون طرف مشکلی هم که داره admin باید روی تک تک منابعش هم مجوز های مختلف رو بده ، مثلا روی همین فولدر مجوز نوشتن و خوندن و حذف و ...

اما استراتژی دوم که استراتژی جایگزین هست یعنی دقیقا برعکس استراتژی پیش فرض

خب اون حالت اولش که دقیقا یکیه اما تو حالت دو که admin سایت برای منبع Y  مجوز تعیین نکرده ، کاربر فقط با صرف داشتن مجوز اجرای سرویس xs میتونه کارش رو انجام بده ، یعنی دیگه نیازی نیست که حتما رو اون منبع هم مجوز رو داشته باشه. صرف داشتن مجوز اجرای سرویس نوشتن میتونه برای اون منبع هم که براش مجوز تعیین نشده بنویسه.

این استراتژی جایگزینی که استفاده نمیشه اما من توی سورس کد به شما نشون میدم که چجوری میتونید اون رو عوض کند اما قبلش اسلاید بعدی .

این قسمت همون توضیح منه که تک تک منابع رو مجوز های مختلف بهش دادن، میتونه وقت گیر باشه به خصوص در مورد دیسک ، منتها راه حلی که ما توی پلتفرم داریم استفاده از ویژگی پدر فرزندی هست .

یعی اگر کاربر به مسید c:/test  دسترسی خوندن داشته باشه به طور اتوماتیک به مسیر c:/test/subtest هم دسترسی خوندن داره . بنابراین شما نباید به هیچ کاربری دسترسی به Root  وبسایت تون رو بدید که اون در اصل کل وبسایت شما رو میتونه در اختیار داشته باشه.

دومین نکته  هم در رابطه با منابع کد ها هست که برای هر کدام از منابع سورس کد، کدهای تحت سیستم عامل و دیتابیس و مرورگر و سرویس و سورس دیباگ اسکریپت ها ، توابع خاص امنیتی وجود دارد.

اگه یادتون باشه تو ویدیو های قبلی بهتون نشون دادم که سورس اسکریپت های شما minify میشه و هر کسی نمیتونه اون سورس رو ببینه مگر اینکه مجوز داشته باشه . باز عملیات دیدن منبع یک سورس کد هست که شما میتونید نقش براش تعریف کنید تا کاربر بتونه سورس کد رو ببینه .

توی source Code ، توی اسمبلی Core ، فضای نام Security  و Adapters ما یک BaseAuthorizeAdapter داریم که یک Base Class Abstract هست و شما میتونید از اون ارث ببرید و over write کنید و اون True و False با هم دیگه جایگزین کنید اما این که تو کدوم متد ها باید این کار رو انجام بدید ، روش رو بدونید متوجه میشید

چند تا متد هست ، توی این قسمیت که گفته اگر permission  نقیض null یعنی اگر permission برابر null بود حتما  false بر میگردونه یعنی این با این استراتژی هست که permission  حتما باید وجود داشته باشه. شما این false ها رو به True تبدیل کنید ، تبدیل میشه به اون استراتژی جایگزین که توصیه شده نیست چون امنیت تون میاد پایین تر.

اما یک نکته دیگه هم که میخوام توضیح بدم راجع به AuthorizeActionOnEntityIdbyVersion هست و همونطور که قبلا توضیح دادم ما روی version  کد ها هم میتونیم دسترسی بدیم و برای اینکه sample رو بهتون نشون بدم روی مجوز عملیات بر کدهای تحت سیستم عامل بر روی اجرای عملیاتEF Migration  برای یک کدConfiguration  نقش یک مدیر رو بهش دادیم ، نوع اطلاعات پایه مون کدهای تحت دات نت بوده و اطلاعات پایه مون کلاسConfiguration   بوده که این Class ، Configuration   صد در صد توی یک Dll  هست که اینجا ما حتی میتونیم ورژن Dll هم انتخاب کنیم.

یعنی فرضا شما با اون برنامه نویسی که مسئول اجرای Migration  های شماست و یک برنامه نویس دیگه هم فرضا Data Access  شما رو کار میکنه به اونی که داره Migration های شماره رو اداره میکنه فقط بهش اجازه میدی version 20  رو اجرا کنه چون اون  Stable  هست و اون نگارش دیگه ای که داره کامپایل میشه بهش دسترسی نمی دین.

شما تو ریز جزئیات تو این پلتفرم تو کدها از انتشار و استفاده و ... چه کدهای سمت client و چه کدهای سمت server میتونید دسترسی بدید

و اما نکته آخری که میخوام بگم راجه به مجوز دیدن Source جاوا اسکریپت هاست ، ما تو قسمت مجوزهای عملیات بر روی کدها ، یه قسمتی داریم :مجوز بر کدهای تحت مرورگر ، مجوز عملیات بر روی اسکریپت ها ،مجوز های دیدن منبع دیباگ یک کد ، و یک sample برای شما قرار داده شده به عنوان مجوز دیدن منبع دیباگ اسکریپت Boot Grid،

Boot Grid یکی از plugin های ما هست که این مجوز برای عملیات دیدن منبع دیباگ یک کد با نقش مدیر ، روی نوع اطلاعات پایه اسکریپت ها و نوع اطلاع پایه اسکریپت Boot Grid ایجاد شده . یعنی کاربر با نقش مدیر می تونه منبع این اسکریپت رو به منظور دیباگ ببینه .

سوالی که پیش میاد ، پس بقیه اسکریپت های ما چی ؟ ما کلی plugin داریم توی پلتفرم

جواب اینه که یک راه حل دیدن منبع دیباگ کد مجوز دادن از این طریق ولی راه حل دیگه اش اینه ما تو همون قسمت مدیریت کدها ، کدهای تحت مرورگر ، همون BootGrid رو انتخاب میکنیم . خود این رکورد سه تا نقش داره ، توی نقش ویرایش ، هر کس نقش ویرایش این منبع کد رو داره میتونه source code تمام bundle های این منبع کد رو هم ببینه . یعنی تو مدیریت bundle ها n  تا bundle هم داشت کسی که نقش ویرایش رو داره میتونه source تمام bundle ها رو ببینه .

اینم در اصل برای راحتی کار هست ، چون شما اگه قرار بود برای n  تا bundle اعطای دسنرسی بدین ، admin فقط باید دسترسی میداد

اما اینجوری شما میتونید یک منبع کد تعریف کنید و روی تمام bundle های اون با اون یک دونه نقش تعریف شده دسترسی دیدین بدین .

اما بعضی وقت ها هم شما میخواین دوستان تون یا هر کس دیگه ایی ،Source  رو ببین یا ازش ایده بگیرن ولی نمیخواین اجازه دیباگ بدین ، اونوقت یک مجوز دیدن منبع دیباگ رو براش تعریف می کنید ولی دیگه نمیتونه Modify بکنه source های شما رو .