دانلود رایگان مقاله کنترل دسترسی ویژگی - محور چند مستاجری برای خدمات زیرساخت ابری

چکیده

          رایانش ابری، به عنوان موج جدیدی از فناوری های ICT (فناوری اطلاعات و ارتباطات) بوده، که رویکرد مشترکی را در ارتباط با تامین شرایط محاسبات درخواستی، ذخیره سازی، و منابع شبکه معرفی کرده، که معمولا تحت عنوان خدمات زیرساختی نامیده می شوند. اکثر خدمات ابری تجاری قابل دسترس کنونی، ایجاد و سازماندهی شده تا به بازتاب روابط بین ارائه دهنده خدمات و مشتریان، توسط مدل اطمینان و امنیت ساده،بپردازد.مدل های طراحی شده جدید،باید به ارائه بستر خدمات ابری ناهمگن از طرف چند ارائه کننده خدمات، به مشتریان سازمانی پرداخته که نماینده گروه های کاربری چندگانه هستند.این مدل ها باید توسط عملکرد خدمات امنیتی پایدار، در بستر ابری ارائه دهند گان خدمات چندگانه در محیط مجازی اجرا گردند. این مدل ها باید به ادغام مکانیسم کنترل دسترسی پیچیده و رابطه اعتماد در میان فعالان خدمات ابری بپردازند. . در این مقاله، به تحلیل مجموعه ای از رویدادهای ارائه خدمات ابری پرداخته، و به ارائه مدل کنترل دسترسی، برای خدمات ابری چند مستاجری، با استفاده از مدل کنترل دسترسی ویژگی- محورمی‌پردازیم. همچنین این مدل را در حوزه سناریوهای بین ابری، توسط رویکرد تبادل نشانه ها، تعمیم می دهیم. به منظور تسهیل ارزیابی و پیاده سازی روش ویژگی-محور مدل پیشنهادی، مکانیسم کارآمدی را در این شیوه برای تبدیل عبارات منطقی پیچیده، به یک نمودار تصمیم گیری فشرده، بکار می گیریم. نمونه اولیه مورد نظر ما،برای سیستم کنترل دسترسی ویژگی-محور چند مستاجری در مورد خدمات بین ابری، ایجاد،و آزمایش شده و در پروژه جیسرز  ادغام شد. ارزیابی ها نشان می دهد که روش ما دارای عملکرد مناسبی از نظر تعداد منابع ابری و تعداد مشتریان (کلاینت ها) است.

1. مقدمه

          رایانش ابری، مشخصا به منظور بهبود مقیاس پذیری، قابلیت دسترسی، انعطاف پذیری و امنیت مدیران IT  در بسیاری از حوزه های کاربردی مورد استفاده قرار می گیرد. این فرایند، دارای مزیت های فناوری زیادی از جمله مجازی سازی، معماری سرویس گرا، و محاسبات کاربردپذیر بوده، که این امکان را برای مشتریان و ارائه دهندگان خدمات به منظور کاهش هزینه ها در زمینه بکارگیری و عملیات سیستم، ایجاد می کند. بسیاری از مطالعات و اسناد معتبر مرتبط با بکارگیری رایانش ابری، طراحی، توسعه، عملیات و مدیریت، در ادغام با فناوری های بالا مطرح شده اند (دیلون و همکاران، 2010؛ فاستر و همکاران، 2008؛ فاکس و همکاران، 2009؛ هوگان و همکاران، 2011؛ هافر و کاراگیانیس،2011؛ مل و گرانس، 2011). رایانش ابری در چنین رویکردی، این امکان را برای کاربران داده ایجاد می کند تا بر روی زیرساخت های ابری مجازی مشترک، به ذخیره سازی اطلاعات پرداخته، که در تاسیسات ارائه دهنده خدمات، بر حسب تقاضا، در دسترس افراد قرار می گیرد. ارائه دهندگان خدمات ابری،سیستم شان را بر مبنای طرح های چندمستاجری ایجاد می کنند (چانگ و همکاران، 2006؛ گارسیا- اسپین و همکاران، 2012؛ ژو و همکاران، 2007؛ مل و گرانس، 2011)  . بنابراین در زمینه امنیت و همچنین کنترل دسترسی، مدیران خدمات ابری باید از الگوهای چندمستاجری در این طرح، آگاهی داشته باشند.

          در مدیریت منابع ابری، منابع در محیط ابری به صورت مجازی بوده و در حوضچه منابع مشترک مدیریت شوند (چانگ و همکاران، 2006؛ گارسیا- اسپین و همکاران، 2012؛ قیجسن و همکاران، 2013؛ هوگان و همکاران، 2011؛ مل و گرانس، 2011).  این منابع، بسته به چرخه عمرش، می تواند توسط یک یا چندین نهاد در الگوی چندمستاجری، مدیریت شود:

• در مرحله ابتدایی، منابع توسط ارائه دهندگان، به عنوان صاحبان مدیریتی و اقتصادی منابع موجود، مدیریت می-شود.

• زمانیکه یک مستاجر (منتفع)، در مجموعه ای از منابع ابری ثبت نام می کند، مالکیت اجرایی و اقتصادی آن ها، منحصرا به این افراد در طی دوره ثبت نام منتقل می شود.

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

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

          مجموعه ای از رویدادهای مرتبط با الگوی چندمستاجری می تواند بصورت زیر است: ارائه دهنده خدمات ابری، به ارائه این خدمات به شرکت تجاری (مستاجر) پرداخته، که کارمندان آن می توانند به منابع ابری موردنظر ( به عنوان مثال ذخایر، ماشین مجازی (VM)، بانک های اطلاعاتی، صفحات گسترده، و غیره) در طی زمان ثبت نام، دسترسی داشته باشند.ارائه دهنده خدمات، باید تضمینی بابت تفکیک بین منابع ثبت نامی مستاجر دهد. از طرف دیگر، مستاجران (منتفعان) ممکن است بخواهند از طریق اشتراک منابع، با هم همکاری کنند. به عنوان نمونه، شرکت تجاری C، می خواهد به حسابرسی صورت وضعیت مالی خود بپردازد، بنابراین فراردادی را با شرکت حسابرسی A امضا می کند، تا به کارشناسان شرکت A این امکان را دهد که تنها بخشی از منابع شرکت C را در طی چارچوب زمانی خاصی، بخوانند.

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

         خدمات انتخابی درخواستی و ویژگی های انعطاف پذیری سریع (مل و گرانس، 2011)  نیازمند این است که طرح کنترل دسترسی باید، به مدیریت تغییرات پویای نهادها، و همچنین کسب مجوز از پایین ترین سطح بپردازد. برای نمونه، خدمات زیرساخت به عنوان سرویس ابری (IaaS)  طرح های مختلفی (همچون اندازه ذخایر، سرعت، توان محاسبه، پهنای باند، مدت زمانی و غیره) را به ارائه می دهد که تعداد ثبت نام کنندگان می تواند به هزاران نفر برسد. هر یک از این افراد می تواند به مدیریت صدها کاربر نهایی دیگر بپردازد. در این موارد، اهداف منبع بیشماری، با گذر زمان با معرف های پویا ایجاد می شود. علاوه بر این، بخش های ابری، باید به مدیریت دسترسی کاربرانی که از کلاینت های متنوعی از نظر تعداد و انواع استفاده می کنند (همچون دستگاه های موبایل، لپ تاپ ها، ایستگاه های کاری)، بپردازد.

          مدل های کنترل دسترسی سنتی، به منظور مدیریت دسترسی ها از موضوعات تا اهداف، با عملیات خاصی از طریق صدور مجور، طراحی شد. دستورات سه جزئی به صورت سه تایی (یعنی موضوع، هدف، عملکرد) بوده، که در آن، (هدف، عملکرد) به عنوان مجوز شناخته می شود. روش های کنترل دسترسی نقش- محور (RBAC) (آنسی، 2004؛ فرایولو و همکاران،2001؛ سندهو و همکاران، 1996)  با در نظر گرفتن نقش به عنوان لایه انتزاعی تفکیک موضوعات و مجوز ها، معرفی شد. روش RBAC، با توحه به حمایت در حوزه های مختلفی، شامل مستقل، سطح شرکتی یا بینا شرکتی بکار گرفته شد. به هر حال، حتی هدف طراحی RBAC، افزایش سیستم های شرکتی با صدها و هزاران نقش و ده ها هزار کاربر است (ساندو و همکاران، 1999) ، چنین سیستم هایی دارای مشکلاتی در زمینه مقیاس پذیری در افزایش نقش و هدف است (فرانکویرا و ویرینگا، 2012؛ کوهن و همکاران، 2010) . تجزیه و تحلیل فرانکویرا و ویرینگا، (2012)  برآورد کرده است که RBAC باید برای سیستم هایی با ساختار پایدار مورد استفاده قرار گیرد، به صورتی که نقش ها و سلسله مراتب مشخصا تعریف شده باشند؛ موجودیت و مکان محدود بوده، و اهداف مدیریت شده پایدار هستند. سیستم های مدیریت خدمات ابری در مقیاس بالا، معمولا دارای پویایی اهداف ادغام شده مقرر، تنوع هویت و مجوز در سطوح پایین تر پیچیده، با در نظر گرفتن ویژگی مختص به شرایط بوده، که رویکردهای RBAC، در این مورد نمی توانند مناسب باشند.

          به منظور غلبه بر محدودت های RBAC، کنترل دسترسی ویژگی- محور (ABAC) با در نظر گرفتن این مفهوم اصلی تشخیص داده می شود که، دسترسی می تواند بر مبنای ویژگی های کنونی اهداف، اقدامات، موضوعات و محیط در بافت مجوز، تعیین گردد (هو 2014؛ جین و همکاران، 2012؛ یوان و تانگ، 2005) . ABAC، می-تواند برای مدلسازی RBAC). خصوصیات مجوز سطح پایین تر ABAC، آن را انعطاف پذیر تر و مقیاس پذیرتر از RBAC کرده است.  بنابراین، ABAC اساسا برای خدمات مدیریت ابری متاسب است.

          به هر حال، با استفاده تعداد زیادی ازصفات در ABAC، و انعطاف پذیری رایانش ابری، چالش های را در مدیریت و صف آرایی ایجاد می کند. پبچیدگی معیار خصوصیات در قوانین و بیانیه های مورد اختلاف، ممکن است در طی پیاده سازی ABAC در کنترل دسترسی برای سیستم های مقیاس بزرگ همانند رایانش ابری، ایجاد گردد. پیاده سازی ABAC همانند استاندارد زبان نشانه گذاری کنترل دسترسی (XACML) (اوسیس، 2013)  ، تنها محدود به تعریف زبان روش کلی ABAC بوده اما هیچ نشانی از این ندارد که چکونه با مدل های اطلاعات منابع سیستمی به منظور مدیریت خصویات، ادغام می گردد. همچنین هیچ پژوهش مرتبطی در مورد ABAC وجود ندارد که به تعریف محدودیت ها در ایجاد روش، و مدیریت مجوزهای چندگانه در سیستم های چندمستاجری بپردازد. 

ABSTRACT

          Cloud Computing is developed as a new wave of ICT technologies, offering a common approach to on-demand provisioning of computation, storage and network resources that are generally referred to as infrastructure services. Most of currently available commercial cloud services are built and organized reflecting simple relations between single provider and customers with the simple security and trust model. New architectural models should deliver multi-provider heterogeneous cloud services environments to organizational customers representing multiple user groups. These models need to be enforced by consistent security services operating in virtualized multi-provider cloud environment. They should incorporate complex access control mechanisms and trust relations among cloud actors. In this paper, we analyze cloud services provisioning use-cases and propose an access control model for multi-tenant cloud services using attribute-based access control model. We also extend the model for Intercloud scenarios with the exchanging tokens approach.To facilitate attributebased policy evaluation and implementing the proposed model, we apply an efficient mechanism to transform complex logical expressions in policies to compact decision diagrams. Our prototype of the multi-tenant attribute-based access control system for Intercloud is developed, tested and integrated into the GEYSERS project. Evaluations prove that our approach has a good performance in terms of numbers of cloud resources and numbers of clients.

1. Introduction

           Cloud Computing is effectively used to improve scalability, availability, elasticity and security of IT management in many application areas. It adopts advantages of many technologies such as virtualization, service-oriented architecture, and Utility computing to allow customers and providers to cut costs on system deployments and operations. Many studies and best practices documents related to clouds deployment, design, development, operations and management have been proposed to incorporate above technologies (Dillon et al., 2010; Foster et al., 2008; Fox et al., 2009; Hogan et al., 2011; Höfer and Karagiannis, 2011; Mell and Grance, 2011). Clouds in such approaches enable users’ data to store on share virtualized cloud infrastructures, which are on-demand provisioned at providers’ facilities. The virtualized infrastructures capacities can be elastically scaled up and down depending on varying users’ demands. Cloud providers build up their systems based on the multi-tenant architecture (Chong et al., 2006; Garcia-Espin et al., 2012; Guo et al., 2007; Mell and Grance, 2011). Thus, security in general as well as access control for cloud service management should be aware of the multi-tenancy pattern in this architecture.

         In cloud resource management, resources in cloud are virtualized and managed in a common resource pool (Chong et al., 2006; Garcia-Espin et al., 2012; Ghijsen et al., 2013; Hogan et al., 2011; Mell and Grance, 2011). Depending on the stage in its life cycle, the resource may be administrated by one or multiple entities in the the multi-tenancy pattern:

• At the initial stage, resources are managed by the provider, who is the economic and management owner of available idle resources.

• When a tenant subscribes set of cloud resources, their economic and administrative ownerships will be transferred exclusively to this tenant during subscribed period.

• The subscribed tenant may want to allow accesses from its users, or due to collaboration requirements, share part of its resources to another trusted tenant with specific conditions like allowed actions, time, location.

• The trusted tenant in turn can manage the shared resources by defining access control policies for its users, or share to another one.

          A use-case of multi-tenancy pattern could be as follows: a cloud provider offers cloud services to commercial companies (tenants) in which their employees can access subscribed cloud resources (e.g., storage, Virtual Machine (VM), databases, spreadsheets, etc.) during subscribing time. The provider should guarantee isolations between subcribed resources of tenants. On the other side, tenants may want to collaborate with each other by sharing resources. The commercial firm C, wants to audit its finance statements. It signs the contract with the auditing firm A to allow A’s consultants can read-only to parts of C’s resources during a specific time-frame.

         According to Hogan et al. (2011), cloud services relies mainly on virtualization, multi-tenant architecture, elasticity and diversity of accesses.The characteristics of multi-tenancy pattern bring distinctions between Cloud Computing and previous distributed systems. For this reason, access control for clouds should be designed to support such scenarios.

          The on-demand self-service and rapid elasticity properties in clouds (Mell and Grance, 2011) requires that the access control design must handle dynamic changes of entities as well as fine-grained authorization. For example, a typical cloud Infrastructure as a Service (IaaS) service provides different plans (e.g., storage size, speed, computing powers, bandwidth, lifetime, etc.) to customers in which the number of subscribers could reach thousands. Each of them can then manage hundreds of end-users. In these cases, numerous resource objects are provisioned over time with dynamic identifiers. Besides, clouds must handle accesses from users using diversity of clients in both types and numbers (e.g., mobile devices, laptops, workstations).

          Traditional access control models are designed to manage accesses from subjects to objects with specific operations via authorization statements. A trivial statement is a triple of ⟨subject, object, operation⟩, in which the ⟨object, operation⟩ is known as a permission. Role-based Access Control (RBAC) approaches (ANSI, 2004; Ferraiolo et al., 2001; Sandhu et al., 1996) were introduced with roles as an abstraction layer decoupling subjects and permissions. RBAC was supported to apply in different areas, from stand-alone, enterprise-level or cross-enterprise applications. However, even the design purpose of RBAC is to large enterprise systems with even hundreds or thousands of roles and users in tens thousands (Sandhu et al., 1999), such systems may have problems on scalability in role and object explosions (Franqueira and Wieringa, 2012; Kuhn et al., 2010). Analysis in Franqueira and Wieringa (2012) estimates that RBAC should be used for systems with static structure where roles and hierarchy are clearly defined; entities individuality and locality are limited; and managed objects are stable. Large-scale cloud services management systems often have dynamics of provisioned pooling objects, varieties of entities and sophisticated fine-grained authorization regarding dynamical contextspecific attributes, in which RBAC approaches may not be suitable.

         To overcome limitations of RBAC systems, Attribute-based Access Control (ABAC) was identified with the central idea that access can be determined based on present attributes of objects, actions, subjects and environment in the authorization context (Hu et al., 2014; Jin et al., 2012; Yuan and Tong, 2005). The ABAC can be used to model RBAC as well as other traditional access control models (Jin et al., 2012) The fine-grained authorization feature of ABAC makes it more flexible and scalable than RBAC. Thus, ABAC is mostly suitable for cloud management services.

         However, using large numbers of attributes in ABAC and the elasticity of clouds produce challenges in management and deployment. The complexity of attributes criteria in rules and conflict resolutions may arise during applying ABAC in access control for large-scale systems like cloud. ABAC implementation like eXtensible Access Control Markup Language (XACML) standard (OASIS, 2013) only limits at defining a general ABAC policy language but without indicating how to integrate with system resource information models for attribute management. There is also no related work on ABAC defining required constraints in policy composition and management for multiple authorities in multi-tenant systems.

چکیده

1. مقدمه

2. پژوهش های مرتبط

3. مقدمات

3.1 مدل اطلاعاتی برای زیرساخت ابری مجازی

3.2 کنترل دسترسی ویژگی-محور

3.3 مدل کنترل دسترسی ویژگی محور چندمستاجری

3.3.1 ارائه دهنده خدمات

3.2.2 مستاجر

3.3.3 کاربر 

3.3.4 منابع

3.3.5 مجوز

3.3.6 موقعیت (شرایط)

3.3.7 درخواست تایید

3.4 واگذاری ها در مدل MT-ABAC

3.4.1 انواع شرایط واگذاری

3.4.2 روابط بافتی

3.5 محدودیت های چندمستاجری

3.5.1 محدودیت های جداسازی

3.5.2 محدودیت های واگذار شده

3.6 فعالیت های MT-ABAC

4. تحلیل

5. مکانیسمی برای مدیریت شرایط در مدلMT-ABAC

5.1 نمودارهای تصمیم

5.2 ساختار شرایط

5.3 عملیات

5.4 پیچیدگی ها

6. روش MT-ABAC تعمیم یافته برای ارائه دهندگان خدمات چندگانه

6.1 بیان مسئله

6.2 محدودیت هایی در مجوز توزیع شده

6.3 تبادل نشانه ها در مدل بین ابری

6.3.1 نشانه واگذاری

6.3.2 نشانه دسترسی

7. طرح سیستم

7.1. یکپارچه سازی و طراحی DACI

7.2 ادغام MT-ABAC با INDL

7.2.1 مدل معنایی سیاست ویژگی-محور

7.2.2 سیاست گذاری از طریق توصیف زیرساخت های ابری

7.3 PDP سطح بالا برای سیاست های مستاجر

7.4 تفکیک شرایط و تبادل نشانه 

7.5 مدیریت سیستم مستاجر

8. پیاده سازی و ارزیابی

8.1 مرور پیاده سازی

8.2 پیاده سازی نشانه

8.3 نتایج ارزیابی

9. نتیجه گیری

منابع

ABSTRACT

1. Introduction

2. Related work

3. Preliminaries

3.1. Information model for virtual cloud infrastructure

3.2. Attribute-based access control

3.3. Multi-tenant attribute-based access control model

3.3.1. Provider

3.3.2. Tenant

3.3.3. User

3.3.4. Resource

3.3.5. Permission

3.3.6. Context

3.3.7. Authorization request

3.4. Delegations in MT-ABAC

3.4.1. Types of delegation contexts

3.4.2. Context relationships

3.5. Multi-tenancy constraints

3.5.1. Isolation constraint

3.5.2. Grant constraints

3.6. MT-ABAC operations

4. Analysis

5. Mechanism to manage contexts in MT-ABAC

5.1. Decision diagrams

5.2. Context structure

5.3. Operations

5.4. Complexities

6. Extended MT-ABAC for multiple providers

6.1. Problem statement

6.2. Constraints in distributed authorization

6.3. Exchanging tokens in Intercloud

6.3.1. Grant token

6.3.2. Access token

7. System design

7.1. DACI architecture and integration

7.2. Integration MT-ABAC with INDL

7.2.1. Attribute-based policy semantic model

7.2.2. Policy generation from cloud

7.3. High performance PDP for tenants policies

7.4. Context resolution and token exchange

7.5. Tenant policy administration

8. Implementation and evaluation

8.1. Implementation overview

8.2. Token implementation

8.3. Evaluation results

9. Conclusion

REFERENCES