دانلود رایگان مقاله مدل کنترل دسترسی مبتنی بر مستاجر معماری های چند اجاره ای

چکیده

        نرم افزار بعنوان سرویس (SaaS) معماری چند اجاره ای (MTA) را معرفی می کند معماری اجاره در جاره (STA) یک بسط از MTA است که به مستاجر اجازه می دهد خدمات را به توسعه دهندگان مستاجر دست دوم برای شخصی سازی کاربردهایشان در زیر ساخت SaaS ارائه کنند. در یک سیستم SaaS مستاجرها می توانند مستاجر دست دوم ایجاد کرده و منابع خود را در اختیار مستاجر دست دوم قرار دهند. جداسازی روابط شراکت بین مستاجرهای والدـ فرزند، مستاجر خواهر ـ برادر یا دو مستاجر غیر مرتبط پیچیده تر از روابط بین مستاجرها در MTA است. خصوصی نگه داشتن داده یا مولفه های خدمات و در همان زمان به اشتراک گذاشتن آنها و حمایت از شخصی سازی کاربردها به مستاجران مهم است برای حل این مشکل این مقاله یک تعریف رسمی از یک مدل کنترل دسترسی مبتی بر مستاجر برای کنترل دسترسی مبتنی بر نقش مدیریتی (ARBAC) برای MTA و STA در SaaS های با منشاء خدماتی (به نام TMS-ARBAC) فراهم می کند. نواحی خود مختار (AA ) و درخت AA برای توصیف خود مختاری مستاجران شامل روابط جداسازی و اشتراک گذاری آنها ارائه شده است . عملیات مجاز سازی روی AA و استراتژی های مختلف تسهیم منابع تعریف شده اند تا یک طرح کنترل درسترس در مدلهای STA دو پیاده سازی شود. مدل TMS-ARBAC برای طراحی یک پلت فرم علم الکترونیک جغرافیا بکار رفته است.

1. مقدمه

        محاسبات ابری دارای سه مولفه اصلی است: زیر ساخت بعنوان خدمات (IaaS) پلتفرم بعنوان خدمات (PaaS) و فرم افزار بعنوان خدمات (SaaS) معماری های چند مستاجری (MTA) اغلب در SaaS  بکار می رود که در آن چندین مستاجر می توانند از پایگاه کد یکسان ذخیره شده در SaaS برای توسعه کاربردها استفاده کنند. یک برنامه مستاجر ممکن است تحت توسعه باشد در حالیکه SaaS برنامه مستاجر دیگری را بطرو همزمان اجرامی کند. 

        یک مستاجر می تواند یک برنامه یا یک نهاد سازمانی باشد یک برنامه مستاجر می تواند توسط چند کاربر نهایی سازمان به کار رود. امروزه سازمانهای بسیاری دارای زیر سازمان هستند، مثلاً یک تعاونی می تواند چند کمیته زیر مجموعه داشته باشد و این شرکت های تابعه در حالی که متفاوت از هم هستند دارای ملزومات مشترکی می باشند بعنوان مثال بانک ولزفارگو یک مستاجر سطح سرمایه گذاری Sales forece. Com است. که بیش از 2000 شعبه بانک حدود 270 هزار کارمند داشته و به 3600 مشتری در هر شعبه خدمات می دهد. یک شعبه ممکن است در آمریکا کار کند، در حالیکه دیگری در آسیا است و این دو طوری تنظیم شده اند که با قوانین علی سازگاری داشته باشند اما هر دو کارهای تجاری مهم یکسانی دارند. در این مورد شرکت ممکن است یک مستاجر باشد در حالیکه این دو شرکت تابعه مستاجر دست دوم هستند. این STA است تعمیمی از MTA بوه و در STA یک برنامه مستاجر می تواند شخصی سازی شود تا برنامه های مستاجر دست دوم را تشکیل دهد و مستاجران دست دوم می توانند داده و نرم افزار را با مستاجران دست دوم خودشان یا مستاجران والد خود به اشتراک بگذارند. به لحاظ تکنیکی یک مستاجر دست دوم می تواند مستاجران دست دوم خودش را داشته باشد، امّآ مدیریت این مستاجران دست دوم ممکن است لحاظ شوند علاوه بر این یک MTA ممکن است. بعنوان یک مورد فرعی برای STA لحاظ شود که هیچ مستاجری، مستاجر دست دوم ندارد.

       همانگونه که قبلاً بطور رسمی به عنوان STA مدلسازی شده برخی تامین کنندگان خدمات ابری مانند salesforce ، Netsuit و openStack از گروه کاربران و زیر مجموعه های برنامه روی MTA برای تمرین چند مستاجری سلسله مراتبی و ملزومات مختلف برنامه های آنها استفاده می کند. در MTA هر شرکت تابعه از هر مستاجر بعنوان یک مستاجر مستقل ساخته می شود که در این حالت به اشتراک گذاشتن منابع شخصی سازی شده یا شخصی سازی مجدد بین مستاجران مرتبط سخت است یا می تواند بعنوان کاربر این مستاجر باشد که روابط سلسله مراتبی جهان واقعی جداسازی منابع و روابط اشتراک گذاری با تخصیص نقش و محدودیت های پیچیده اعمال می شود.

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

       در حال حاضر بسیاری از مدل های کنترل دسترسی موجود برای MTA مبتنی بر RBAC یا ARBAC هستند این مدلها می تواند به سه دسته تقسیم شوند: 1) با استفاده ازطرح و استراتژی این در ابرهای دیتا محور بدون لحاظ کردن اشتراک گذاری مولفه خدمات (2) با اضافه کردن انواع مختلف سلسله مراتب به محدودیت ها یا جداسازی دانه مدیریت برای جداسازی مستاجر چند گانه و (3) اضافه کردن فدرال های مستاجر ـ صادر کننده برای اشتراک گذاری مستاجر متقابل مولفه های برون سپاری علاوه بر این استراتژی های اسمن فراهم شده با MTA کنترل دسترسی STA باید مسائل زیر را حل کند:

      1) اشتراک گذاری حریم شخص: مستاجران و مستاجران دست دوم آنها ممکن است در داده و مولفه های خدمات خصوصی شریک باشند. یک مستاجر می تواند منابع خودش شامل داده و مولفه های مشخص شده را در اختیار مستاجران دست دوم خود قرار دهد و همچنین می تواند دسترسی مستاجران دست بالا و مدیران سیستم به آنها را قطع کند. بعنوان مثال، شکل 1) نشام می دهد که منابع خصوصی مستاجر T1 (PR1)  بطور جزئی با مستاجر دست دوم T1 شریک شده است. یک مستاجر می هراسد مولفه های خصوصی خود را با خواهر ـ برادر خود شریک شود بعنوان مثال PR1  توسط مستاجر برادر ـ خواهر T2 به اشتراک گذاشته شده است و منابع خصوصی T11 ، PR11 توسط مستاجر دست دوم برادر (هم رده) اش T12 به اشتراک گذاشته شده است.

      2) مستاجران خود مختار: با توجه به اعطا کردن مزایا به مستاجران دست دوم ، مستاجران همانند عوامل خود مختار عمل می کنند حتی اگر عملیات آنها توسط زیر ساخت SaaS محدود شده باشد. یک مستاجر منابع خود را مدیریت کرده و می تواند مستاجران دست دوم خود را ایجاد کرد و اجازه دسترسی به منابع خودش را به آنها اعطا کند یک مدیر سیستم می تواند مستاجران را ایجاد کرد و منابع را به آنها اجاره دهد اما نمی تواند در امور داخلی مستاجران دخالت کند علاوه بر این بعلت  جداسازی حریم خصوصی به ارث بردن مزایای نقش در دانه سیستم وجود ندارد. اینکه چه مزیت دسترسی می تواند یا نمی تواند بر ارث برسد یا اینکه چه منابعی یا نمی تواند بطور سطح متقابل کنترل شود متفاوت از سیستم های MTA سنتی است.اینها باید دوباره تعریف شوند.

       3) روابط اشتراک گذاری بین مستاجران: اشتراک گذاری ممکن است بین هر مستاجر برادر (مانند T1 و T2 یا T11 و T12 در شکل 1) یا مستاجران والد ـ فرزند (مانندT1 به T11 در شکل 1) باشد اشتراک گذاری منابع شامل همه انواع منابع از قبیل مولفه برنامه ها و داده در SaaS خدمات محور است مولفه های منابع خصوصی می تواند برای سایر مستاجران برای دسترسی با اجازه مالک خود اعطا شود. جهات اشتراک گذاری ممکن است از یک به مستاجر والد به مستاجران دست دوم یا از یک مستاجر دست دوم به مستاجر والد یا از یک مستاجر به برادر خودش باشد.

       4) مولفه های به اشتراک گذاشته شده: مولفه هایی مانند GUI ها، گردش کارها، خدمات و مولفه های دیتا می تواند به اشتراک گذارد شود اما مولفه های مختلف با ویژگی های دسترسی مختف باید متمایز شوند.و یک مولفه ممکن است یک مولفه ترکیب، با مولفه های فرعی ازتامین کننده های مختلفی یا انتقالی از مستاجران مختلف باشد. مدیر سیستم ممکن است تنها مالک منابع نباشد یک مستاجر می تواند یک تامین کننده مولفه و یک اجاره دهنده برنامه باشد کنترل دسترسی مولفه های مرکب مشترک پیچیده است.

Abstract

       Software-as-a-Service (SaaS) introduces multitenancy architecture (MTA). Sub-tenancy architecture (STA), is an extension of MTA, allows tenants to offer services for subtenant developers to customize their applications in the SaaS infrastructure. In a STA system, tenants can create subtenants, and grant their resources (including private services and data) to their subtenants. The isolation and sharing relations between parent-child tenants, sibling tenants or two non-related tenants are more complicated than those between tenants in MTA. It is important to keep service components or data private, and at the same time, allow them to be shared, and support application customizations for tenants. To address this problem, this paper provides a formal definition of a new tenant-based access control model based on administrative role-based access control (ARBAC) for MTA and STA in service-oriented SaaS (called TMS-ARBAC). Autonomous areas (AA) and AA-tree are proposed to describe the autonomy of tenants, including their isolation and sharing relationships. Authorization operations on AA and different resource sharing strategies are defined to create and deploy the access control scheme in STA models. TMS-ARBAC model is applied to design a geographic e-Science platform.

1 Introduction

      Cloud computing often has three principal components: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). Multi-tenancy architecture (MTA) is often used in SaaS where multiple tenants can use the same code base stored in the SaaS to develop applications. One tenant application may be under development, while the SaaS is executing other tenant applications at the same time.

      A tenant can be a single user or an organizational entity. A tenant application can be used by many end users of the organization. Many organizations today have sub-organizations, e.g., a corporation can have multiple subsidiary companies, and these subsidiaries while different may share the significant requirements. For example, Wells Fargo Bank is an enterprise-level tenant of Salesforce.com. It has over 9 000 bank branches, about 270 000 employees, and serves 3 600 customers per branch1). One branch may operate in the USA, while the other may operate in Asia, and these two are set up to meet local regulations, but both share the significant business operations. In this case, the company may be a tenant, while these two subsidiaries are subtenants. This is the sub-tenancy architecture (STA) [1] and this is an extension of MTA, and in STA, a tenant application can be further customized to form subtenant applications, and subtenants may share data and software with fellow subtenants or their parent tenants. Technically, a subtenant can also have its own sub-subtenants, however, the management of these subsubtenants may be involved. Furthermore, a MTA may be considered as a sub-case for STA where no tenant has subtenants.

       Before formally modeled as STA [1], some cloud service providers, such as Salesforce, NetSuite and OpenStack, use user groups and application subsets on MTA to practice hierarchical multi-tenants and their different application requirements. In MTA, each subsidiary of a tenant is built either as an independent tenant that is difficult for customized resource sharing or re-customization among relative tenants, or as a user of such tenant where the real world hierarchical relations, resource isolation and sharing relations are implied by complicated role assignment and constraints.

     STA is a more flexible and extensible architecture for hierarchical multi-tenancy applications. In STA, multiple tenants co-exist. Each tenant should be autonomous and can authorize its subtenants to access its own resources, including private service components and data. Each subtenant may not only inherit its tenant’s resources, but also customize its own applications and allow or forbid others to access its resources. Sibling-tenants may also share their service components or data with each other.

      Currently, most existing access control models for MTA are based on role-based access control (RBAC) [2] or administrative role-based access control (ARBAC) [3]. These models can be divided into three categories: 1) using database schema and security strategies in data-centric clouds [4] without considering of service component sharing; 2) adding various kinds of hierarchy, constraints or management scope separation for multiple tenants isolation [5–10]; and 3) adding issuer-tenant federals for cross-tenant sharing of outsourcing components [11–13].

Besides the security strategies provided by MTA, STA access control needs to address the following issues:

      1) Privacy sharing Tenants and their subtenants may share private service components and data. A tenant can grant its own resources including data and customized components to its subtenants, and meanwhile, may not allow its ancestortenants or system administrators to access to them, e.g., Fig. 1 shows that tenant T1’s private resource PR1 is partially shared by its subtenant T11. A tenant may also share its private components with its sibling, e.g., PR1 is partially shared by its sibling tenant T2, and T11’s private resource PR11 is partially shared by its sibling subtenant T12.

       2) Autonomous tenants With respect to granting privileges to subtenants, tenants act like autonomous agents even though their operations are still confined by the SaaS infrastructure. A tenant manages its own resources, and can create its subtenants and grant its resource access privileges to them. A system administrator can create tenants and rent resources to them, but cannot interfere with tenants’ internal affairs. Furthermore, due to privacy isolation, role privilege inheritance no longer exists in the system scope. What access privilege can/cannot be inherited and what resources can/cannot be cross-level controlled are different from traditional MTA systems. These need to be redefined.

        3) Sharing relationships among tenants The sharing may be between two sibling tenants (e.g., T1-to-T2, or T11-to-T12 in Fig. 1) or parent-child tenants (e.g., T1-to-T11 in Fig. 1). Sharing resources include all kinds of resources, such as application components and data in service-oriented SaaS. Private resource components can be granted for other tenants to access with their owner’s permissions. “Sharing directions” may be from a parent-tenant to its subtenants, or from a subtenant to its parent-tenant, or from a tenant to its sibling.

      4) Shared components Components such as GUIs, workflows, services, and data components can be shared [14]. But different components with different access properties need to be differentiated. And a component may be a composite one, with sub-components coming from different providers or transmitted from different tenants. System administrator may not be the only resource owner. A tenant can be both a component producer and an application renter. The access control of “shared composite components” is complicated.

چکیده

1. مقدمه

2. کارهای مرتبط

2.1 MTA و STA در SaaS 

2.2 کنترل دسترسی بر MTA

3. مدل کنترل دسترسی مبتنی بر مستاجر برای MTA , STA در SaaS های سرویس محور

3.1 کلیات TMS-ARBAC

3.2 مدیران سیستم

3.3 مدل TMS-ARBAC

 3.4نقش مدیر ارشد و مجوز مدیر ارشد

3.5 مجوزها (P)

3.6 استراتژی های اشتراک گذاری بین مستاجران

4. ارزیابی TMS-ARBAC

4.1 تحلیل ایمنی TMS-ARBAC

4.2 مشخشات TMS-ARBAC

5. یک مطالعه موردی

.6 نتیجه گیری و کار آتی

منابع

Abstract

1 Introduction

2 Related work

2.1 MTA and STA in SaaS

2.2 Access control in MTA

3 Tenant-based access control model for MTA and STA in service-oriented SaaS

3.1 Overview of TMS-ARBAC

3.2 Autonomous area tree management

3.3 TMS-ARBAC Model

3.4 Chief administrative role and chief administrative permissions

3.5 Permissions (P)

3.6 Sharing strategies among tenants

4 Evaluation of TMS-ARBAC

4.1 Security analysis of TMS-ARBAC

4.2 The characteristics of TMS-ARBAC

5 A case study

6 Conclusion and future work

References