Vvmebel.com

Новости с мира ПК
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Role based access control

Интернет, компьютеры, софт и прочий Hi-Tech

Сервисы
Избранные доки
Метки (все метки)
Дополнительно

Контроль доступа на основе ролей

Из Википедии, — свободной энциклопедии

В системах компьютерной безопасности, контролем доступа на основе ролей (RBAC, — role-based access control) [1] [2] называется способ построения систем разграничения доступа авторизованных пользователей. С недавних пор он является альтернативой мандатному контролю доступа (MAC, — mandatory access control) и дискреционному контролю доступа (DAC, — discretionary access control).

Технология контроля доступа RBAC достаточно гибка и сильна, чтобы смоделировать как дискреционный контроль доступа (DAC) [3] , так и мандатный контроль доступа (MAC) [4] .

До разработки RBAC, единственными известными моделями контроля доступа были MAC и DAC: если модель была не MAC, то она была DAC, и наоборот. Исследования в 90-х показали, что RBAC не попадает ни в ту, ни в другую категорию.

Роли создаются внутри организации для различных рабочих функций. Определенным ролям присваиваются полномочия (‘permissions’) для выполнения тех или иных операций. Штатным сотрудникам (или другим пользователям системы) назначаются фиксированные роли, через которые они получают соответствующие привилегии для выполнения фиксированных системных функций. В отличие от контроля доступа на основе контекста (CBAC, — context-based access control), RBAC не принимает во внимание текущую ситуацию (такую как, например, откуда было установлено соединение).

Так как привилегии не назначаются пользователям непосредственно, и приобретаются ими только через свою роль (или роли), управление индивидуальными правами пользователя по сути превращается в простое присвоение ему ролей. Это упрощает общие операции, такие как добавление пользователя или смена подразделения пользователем.

RBAC отличается от списков контроля доступа (ACL, — access control lists), используемых в традиционных дискреционных системах контроля доступа, тем что может присваивать привилегии на сложные операции с составными данными, а не только на атомарные операции с низкоуровневыми объектами данных. Например, лист контроля доступа может предоставить или лишить права записи в такой-то системный файл, но он не может сказать, каким образом этот файл может быть изменен. Система, основанная на RBAC, позволяет создать такую операцию как открытие ‘кредита’ в финансовом приложении или заполнение записи ‘тест на уровень сахара в крови’ в медицинском приложении. Присвоение привилегии на выполнение такой-то операции многозначно, так как операции являются дробящимися в пределах приложения.

Концепции иерархии ролей и ограничений позволяют создать или смоделировать контроль доступа на основе решетки (LBAC, — lattice-based access control) средствами RBAC. Таким образом, RBAC может быть основанием и расширением LBAC.

Для определения модели RBAC используются следующие соглашения:

  • S = Субъект (Subject) = Человек или автоматизированный агент
  • R = Роль (Role) = Рабочая функция или название, которое определяется на уровне авторизации
  • P = Разрешения (Permissions) = Утверждения режима доступа к ресурсу
  • SE = Сессия (Session) = Соответствие между S, R и/или P
  • SA = Назначение субъекта (Subject Assignment)
  • PA = Назначение разрешения (Permission Assignment)
  • RH = Частично упорядоченная иерархия ролей (Role Hierarchy). RH может быть еще записана так: ≥
  • Один субъект может иметь несколько ролей.
  • Одну роль могут иметь несколько субъектов.
  • Одна роль может иметь несколько разрешений.
  • Одно разрешение может принадлежать нескольким ролям.

На возможность наследования разрешений от противоположных ролей накладывается ограничительная норма, которая позволяет достичь надлежащего разделения режимов. Например, одному и тому же лицу может быть не позволено создать учетную запись для кого-то, а затем авторизоваться под этой учетной записью.

Используя нотацию теории множеств:

  • при этом разрешения назначаются связям ролей в отношении «многие ко многим».
  • при этом субъекты назначаются связям ролей и субъектов в отношении «многие ко многим».

Обозначение: x ≥ y означает, что x наследует разрешения y.

Субъект может иметь множество одновременных сессий с различными разрешениями.

RBAC широко используется для управления пользовательскими привилегиями в пределах единой системы или приложения. Это является наилучшей практикой. Список таких систем включает в себя Microsoft Active Directory, SELinux, FreeBSD, Solaris, СУБД Oracle, PostgreSQL 8.1, SAP R/3 и множество других, эффективно применяющих RBAC.

В организациях с разнородной IT-инфраструктурой, в диапазоне от дюжины до сотен систем и приложений, следует создавать иерархию ролей и наследование привилегий. Без этого использование RBAC становится крайне запутанным. В статье «Дополнительные роли: практический подход к обслуживанию пользователей предприятия» обсуждаются стратегии, альтернативные большому масштабу присвоения привилегий пользователям. Современные системы расширяют старую модель NIST [5] ограничениями RBAC для развертывания на больших предприятиях. Существует несколько академических документов и по меньшей мере одна коммерческая система, — Beyond NIST.

Для больших систем с сотнями ролей, тысячами пользователей и миллионами разрешений управление ролями, пользователями, разрешениями и их взаимосвязями является сложной задачей, которую нереально выполнить малой группой администраторов безопасности. Привлекательной возможностью является использование самой RBAC для содействия децентрализованному управлению RBAC. Административные модели для контроля доступа на основе ролей (ARBAC, — Administrative Models for Role Based Access Control) обсуждаются здесь [6]

Смотрите также

  • Контроль доступа на основе решетки (LBAC, — Lattice-based access control), — эквивалент мандатного контроля доступа (MAC).
  • Метки безопасности
  • Классификация защиты
  • Секретный канал
  • Китайская стена
  • Идентификация
  • Слепая рекомендация
  • Программа Sudo (superuser do) для Unix
  • Подлинность управляемой сети
  • XACML Модель контроля доступа на основе атрибутов (ABAC, — Attribute Based Access Control), включающая RBAC
  • grsecurity

Источники

  1. ^ Ferraiolo, D.F. and Kuhn, D.R. (October 1992). » Role Based Access Control» (PDF). 15th National Computer Security Conference: 554-563.
  2. ^ Sandhu, R., Coyne, E.J., Feinstein, H.L. and Youman, C.E. (August 1996). «Role-Based Access Control Models» (PDF). IEEE Computer 29 (2): 38-47.
  3. ^ Ravi Sandhu, Qamar Munawer (October 1998). «How to do discretionary access control using roles». 3rd ACM Workshop on Role-Based Access Control: 47-54.
  4. ^ Sylvia Osborn, Ravi Sandhu, and Qamar Munawer (2000). «Configuring role-based access control to enforce mandatory and discretionary access control policies». ACM Transactions on Information and System Security (TISSEC): 85-106.
  5. ^ Sandhu, R., Ferraiolo, D.F. and Kuhn, D.R. (July 2000). «The NIST Model for Role Based Access Control: Toward a Unified Standard». 5th ACM Workshop Role-Based Access Control: 47-63.
  6. ^ Qamar Munawer (April 2000). «The Administrative Models For Role Based Access Control» (PDF). PhD Thesis.

Ссылки

  • FAQ по моделям и стандартам RBAC
  • Отождествление
  • Контроль доступа на основе ролей в NIST — большой американский государственный вебсайт с большим количеством информации по теории и практике RBAC
  • Ядро XACML и разбор контроля доступа на основе иерархических ролей — стандарт XACML от OASIS. (файл PDF)
  • RBAC для WebApps с использованием LDAP
  • Руководство по системному администрированию: служба безопасности — настройка ролей, профилирование прав и привилегий для операционной системы Solaris
  • RBAC: альтернатива модели суперпользователя — контроль доступа на основе ролей для операционной среды Solaris (обзор)
  • Дополнительные роли: практический подход к обслуживанию пользователей предприятия
  • «Тонконастраиваемая» система RBAC на PHP
  • ActiveRBAC — библиотека RBAC для «Ruby on Rails»
  • Разбор примеров RBAC

Последнее редактирование: 2007-09-02 16:19:37

Role based access control

Role Based Access Control is an approach to access control that is newer than MAC or DAC.

The complexities and limitations of the two previous approaches boiled down to this:

  • It’s a huge hassle to deal with access control lists: Whenever anything changes (a user must be downgraded in terms of access, for example) the system administrator must comb through all files that user has access to, and revoke their privileges.
  • Processes run with the same access permissions as the user that called them. In the canonical example, Solitare on Windows has access to your printer, network stack, data files, etc, even though there’s no reason it should.
Читать еще:  Подключение odbc access

Role Based Access Control is an attempt to address these two problems.

To deal with the complexity issue, RBAC groups users into roles, and permissions into Rights. Thus, changing a user’s permissions can be achieved just by changing the roles they are allowed to assume.

This approach has more benefits. Since users are allowed to change roles, they can change to a lower-level (less permissions) role before executing untrusted code.

That insight allows us to tackle the second limitation of the MAC/DAC approach. Through judicious use of roles, it is easier for users to limit the power/access rights of code they execute. For example, before running a photo-editing program, a user might drop to «photo-edit» role, which only has rights to access use the webcam, and read/write access to the photo folder. The operating system might, in fact, take care of all of that behind the scenes.

Thus, Role-Based Access Control allows us to specify the access rights of processes, as well as users. A process might have access rights than the user that spawned them, something not possible under either MAC or DAC.

The Old Model — Access Control Matrix:

Using RBAC to manage access:

Under the RBAC framework, users are granted membership into roles based on their competencies and responsibilities in the organization. The operations that a user is permitted to perform are based on the user’s role. User membership into roles can be revoked easily and new memberships established as job assignments dictate. Role associations can be established when new operations are instituted, and old operations can be deleted as organizational functions change and evolve. This simplifies the administration and management of privileges; roles can be updated without updating the privileges for every user on an individual basis.

When a user is associated with a role: the user can be given no more privilege than is necessary to perform the job. This concept of least privilege requires identifying the user’s job functions, determining the minimum set of privileges required to perform that function, and restricting the user to a domain with those privileges and nothing more. In less precisely controlled systems, this is often difficult or costly to achieve. Someone assigned to a job category may be allowed more privileges than needed because is difficult to tailor access based on various attributes or constraints. Since many of the responsibilities overlap between job categories, maximum privilege for each job category could cause unlawful access.

Role-Based Access Control

Amazon Cognito identity pools assign your authenticated users a set of temporary, limited privilege credentials to access your AWS resources. The permissions for each user are controlled through IAM roles that you create. You can define rules to choose the role for each user based on claims in the user’s ID token. You can define a default role for authenticated users. You can also define a separate IAM role with limited permissions for guest users who are not authenticated.

Creating Roles for Role Mapping

It is important to add the appropriate trust policy for each role so that it can only be assumed by Amazon Cognito for authenticated users in your identity pool. Here is an example of such a trust policy:

This policy allows federated users from cognito-identity.amazonaws.com (the issuer of the OpenID Connect token) to assume this role. Additionally, the policy restricts the aud of the token, in this case the identity pool ID, to match the identity pool. Finally, the policy specifies that the amr of the token contains the value authenticated .

Granting Pass Role Permission

To allow an IAM user to set roles with permissions in excess of the user’s existing permissions on an identity pool, you grant that user iam:PassRole permission to pass the role to the set-identity-pool-roles API. For example, if the user cannot write to Amazon S3, but the IAM role that the user sets on the identity pool grants write permission to Amazon S3, the user can only set this role if iam:PassRole permission is granted for the role. The following example policy shows how to allow iam:PassRole permission.

In this policy example, the iam:PassRole permission is granted for the myS3WriteAccessRole role. The role is specified using the role’s ARN. You must also attach this policy to your IAM user or role to which your user belongs. For more information, see Working with Managed Policies.

Lambda functions use resource-based policy, where the policy is attached directly to the Lambda function itself. When creating a rule that invokes a Lambda function, you do not pass a role, so the user creating the rule does not need the iam:PassRole permission. For more information about Lambda function authorization, see Manage Permissions: Using a Lambda Function Policy.

Using Tokens to Assign Roles to Users

For users who log in through Amazon Cognito user pools, roles can be passed in the ID token that was assigned by the user pool. The roles appear in the following claims in the ID token:

The cognito:preferred_role claim is the role ARN.

The cognito:roles claim is a comma-separated string containing a set of allowed role ARNs.

The claims are set as follows:

The cognito:preferred_role claim is set to the role from the group with the best (lowest) Precedence value. If there is only one allowed role, cognito:preferred_role is set to that role. If there are multiple roles and no single role has the best precedence, this claim is not set.

The cognito:roles claim is set if there is at least one role.

When using tokens to assign roles, if there are multiple roles that can be assigned to the user, Amazon Cognito identity pools (federated identities) chooses the role as follows:

Use the GetCredentialsForIdentity CustomRoleArn parameter if it is set and it matches a role in the cognito:roles claim. If this parameter doesn’t match a role in cognito:roles , deny access.

If the cognito:preferred_role claim is set, use it.

If the cognito:preferred_role claim is not set, the cognito:roles claim is set, and CustomRoleArn is not specified in the call to GetCredentialsForIdentity , then the Role resolution setting in the console or the AmbiguousRoleResolution field (in the RoleMappings parameter of the SetIdentityPoolRoles API) is used to determine the role to be assigned.

Using Rule-Based Mapping to Assign Roles to Users

Rules allow you to map claims from an identity provider token to IAM roles.

Each rule specifies a token claim (such as a user attribute in the ID token from an Amazon Cognito user pool), match type, a value, and an IAM role. The match type can be Equals , NotEqual , StartsWith , or Contains . If a user has a matching value for the claim, the user can assume that role when the user gets credentials. For example, you can create a rule that assigns a specific IAM role for users with a custom:dept custom attribute value of Sales .

Читать еще:  Ms access web

In the rule settings, custom attributes require the custom: prefix to distinguish them from standard attributes.

Rules are evaluated in order, and the IAM role for the first matching rule is used, unless CustomRoleArn is specified to override the order. For more information about user attributes in Amazon Cognito user pools, see Configuring User Pool Attributes.

You can set multiple rules for an authentication provider in the identity pool (federated identities) console. Rules are applied in order. You can drag the rules to change their order. The first matching rule takes precedence. If the match type is NotEqual and the claim doesn’t exist, the rule is not evaluated. If no rules match, the Role resolution setting is applied to either Use default Authenticated role or DENY.

In the API and CLI, you can specify the role to be assigned when no rules match in the AmbiguousRoleResolution field of the RoleMapping type, which is specified in the RoleMappings parameter of the SetIdentityPoolRoles API.

For each user pool or other authentication provider configured for an identity pool, you can create up to 25 rules. If you need more than 25 rules for a provider, please open a Service Limit Increase support case.

Token Claims to Use in Rule-Based Mapping

An Amazon Cognito ID token is represented as a JSON Web Token (JWT). The token contains claims about the identity of the authenticated user, such as name , family_name , and phone_number . For more information about standard claims, see the OpenID Connect specification . Apart from standard claims, the following are the additional claims specific to Amazon Cognito:

The following claims, along with possible values for those claims, can be used with Login with Amazon:

sub : sub from the Login with Amazon token

The following claims, along with possible values for those claims, can be used with Facebook:

sub : sub from the Facebook token

All of the claims in the Open Id Token are available for rule-based mapping. For more information about standard claims, see the OpenID Connect specification . Refer to your OpenID provider documentation to learn about any additional claims that are available.

Claims are parsed from the received SAML assertion. All the claims that are available in the SAML assertion can be used in rule-based mapping.

Best Practices for Role-Based Access Control

If the claim that you are mapping to a role can be modified by the end user, any end user can assume your role and set the policy accordingly. Only map claims that cannot be directly set by the end user to roles with elevated permissions. In an Amazon Cognito user pool, you can set per-app read and write permissions for each user attribute.

If you set roles for groups in an Amazon Cognito user pool, those roles are passed through the user’s ID token. To use these roles, you must also set Choose role from token for the authenticated role selection for the identity pool.

You can use the Role resolution setting in the console and the RoleMappings parameter of the SetIdentityPoolRoles API to specify what the default behavior is when the correct role cannot be determined from the token.

Role-Based Access Control (RBAC)

Learning Objectives

After reading this article you will be able to:

  • Understand what is RBAC
  • Know other types of access control
  • Learn how to implement RBAC
  • Understand RBAC with Imperva

What is RBAC

Role-based access control (RBAC), also known as role-based security, is a mechanism that restricts system access. It involves setting permissions and privileges to enable access to authorized users. Most large organizations use role-based access control to provide their employees with varying levels of access based on their roles and responsibilities. This protects sensitive data and ensures employees can only access information and perform actions they need to do their jobs.

An organization assigns a role-based access control role to every employee; the role determines which permissions the system grants to the user. For example, you can designate whether a user is an administrator, a specialist, or an end-user, and limit access to specific resources or tasks. An organization may let some individuals create or modify files while providing others with viewing permission only.

One role-based access control example is a set of permissions that allow users to read, edit, or delete articles in a writing application. There are two roles, a Writer and a Reader, and their respective permission levels are presented in this truth table. Using this table, you can assign permissions to each user.

In some cases, organizations will grant different levels of permission to distinct roles, or their permission levels may overlap. In the above example, one role (the reader) is a subset of another role which has more permissions (the writer).

See how Imperva Data Protection can help you with role-based access control.

Types of Access Control: Complementary Control Mechanisms

Access control measures regulate who can view or use resources in a computing system, often relying on authentication or authorization based on log-in credentials. They are essential to minimizing business risks. Access control systems can be physical, limiting access to buildings, rooms, or servers, or they can be logical, controlling digital access to data, files, or networks.

Role-based access control can be complemented by other access control techniques. Examples of such types of access control include:

Discretionary Access Control (DAC)

The owner of a protected system or resource sets policies defining who can access it. DAC can involve physical or digital measures, and is less restrictive than other access control systems, as it offers individuals complete control over the resources they own. However, it is also less secure, because associated programs inherit security settings and allow malware to exploit them without the knowledge of the end-user. You can use RBAC to implement DAC.

Mandatory Access Control (MAC)

A central authority regulates access rights based on multiple levels of security. MAC involves assigning classifications to system resources and the security kernel or operating system. Only users or devices with the required information security clearance can access protected resources. Organizations with varying levels of data classification, like government and military institutions, typically use MAC to classify all end users. You can use role-based access control to implement MAC.

Types of Access Control: RBAC Alternatives

Other access control mechanisms could serve as alternatives to role-based access control.

Читать еще:  Access не равно

Access Control List (ACL)

An access control list (ACL) is a table listing the permissions attached to computing resources. It tells the operating system which users can access an object, and which actions they can carry out. There is an entry for each user, which is linked to the security attributes of each object. ACL is commonly used for traditional DAC systems.

RBAC vs ACL

For most business applications, RBAC is superior to ACL in terms of security and administrative overhead. ACL is better suited for implementing security at the individual user level and for low-level data, while RBAC better serves a company-wide security system with an overseeing administrator. An ACL can, for example, grant write access to a specific file, but it cannot determine how a user might change the file.

Attribute-Based Access Control (ABAC)

ABAC evaluates a set of rules and policies to manage access rights according to specific attributes, such as environmental, system, object, or user information. It applies boolean logic to grant or deny access to users based on a complex evaluation of atomic or set-valued attributes and the relationship between them.

In practical terms, this allows you to write rules in eXtensible Access Control Markup Language (XACML), using key-value pairs like Role=Manager and Category=Financial.

RBAC vs ABAC

While RBAC relies on pre-defined roles, ABAC is more dynamic and uses relation-based access control. You can use RBAC to determine access controls with broad strokes, while ABAC offers more granularity. For example, an RBAC system grants access to all managers, but an ABAC policy will only grant access to managers that are in the financial department. ABAC executes a more complex search, which requires more processing power and time, so you should only resort to ABAC when RBAC is insufficient.

Implementing Role-Based Access Control

Role-based access control allows organizations to improve their security posture and comply with security regulations. However, implementing role-based access control across an entire organization can be complex and may result in pushback from stakeholders. To succeed in your move to RBAC, you should treat the implementation process as a series of steps:

  • Understanding your business needs—before you move to RBAC, you should run a comprehensive needs analysis to examine job functions, supporting business processes and technologies. You should also consider any regulatory or audit requirements and assess the current security posture of your organization. You may also benefit from other types of access control.
  • Planning the scope of implementation—identify the scope of your RBAC requirements and plan the implementation to align with the organization’s needs. Narrow your scope to focus on systems or applications that store sensitive data. This will also help your organization manage the transition.
  • Defining roles—it will be easier to define your roles once you have performed the needs analysis and understand how individuals perform their tasks. Watch out for common role design pitfalls like excessive or insufficient granularity, role overlap, and granting too many exceptions for RBAC permissions.
  • Implementation—the final phase involves rolling out the RBAC. Do this in stages, to avoid an overwhelming workload and reduce disruption to the business. First, address a core group of users. Start with coarse-grained access control before increasing granularity. Collect feedback from users and monitor your environment to plan the next stages of implementation.

Role-Based Access Control with Imperva

Imperva enables precise control of user privileges using flexible role-based access controls. Users can be granted edit, view-only, or restricted access to specific objects and management functions. Organizations can also hierarchically manage and group IT assets into logical categories for fine-grained access control, even in large-scale enterprise and Managed Security Service Provider (MSSP) deployments.

Learn more about Imperva application security solutions, or see how we can help secure your data.

Делегирование прав доступа к консоли или Role-Based Access Control (RBAC)

Обычно, когда мы подключаемся к консоли маршрутизатора или коммутатора Cisco мы попадаем в так называемый режим доступа User mode. В этом режиме доступа можно выполнять лишь сильно ограниченный ряд команд. Для того, чтобы попасть в режим администрирования (Privileged mode), мы вводим команду enable. В результате пользователь получает права на выполнение любых команд. Иногда возникают ситуации, когда определенным лицам необходимо дать права на выполнение некоторых команд, — для этого мы можем использовать либо Custom Privilege levels либо Creating Parser Views.

Custom Privilege levels

Вообще существует несколько уровней привилигий (privilege levels).
По умолчанию используются два из них:
Самый низкий — privilege level 1 — это собственно User mode
Самый высокий — privilege level 15 — уровень администратора или Privileged mode

Создавая custom privilege level мы можем разрешить выполнение определенных команд на этом уровне.
Рассмотрим ситуацию, когда необходимо кому-то разрешить только смену IP адреса:

enable secret level 8 0 NewPa5s123&
enable secret zse4

privilege interface level 8 ip address
privilege interface level 8 ip
privilege configure level 8 interface
privilege exec level 8 configure terminal
privilege exec level 8 configure

line vty 0 4
access-class 23
exec-timeout 0 0
password 1357
login

Как видно, мы создали дополнительный восьмой уровень.
Теперь, для того чтобы поменять IP адрес необходимо подключится через SSH или telnet, ввести пароль 1357 (попадем в USer mode).
Затем мы вводим команду:
enable 8
И вводим пароль для enable secret level 8.
На этом уровне нам будет доступно только смена IP адреса.

Те же функции можно обеспечить и для login authentication, т.е. с использованием имени пользователя и пароля:
line vty 0 4
login local

username bob privilege 8 secret dksfbkfb
username admin privilege 15 secret dksfbkfb
Теперь при подключении система будет запрашивать логин и пароль. При вводе пользователь будет автоматически попадать в присвоенный ему уровень доступа.

Настройка Parser View

Parser View можно сравнить с ролями. Мы можем создавать несколько ролей и ассоциировать с ними группы команд. Пользователь может выполнять только команды, ассоциированные с его ролью.
Рассмотрим пример разрешения пользователю просматривать конфигурацию и править Access-lists
router(config)#enable secret 691691

Router#enable view
Password:
Где пароль есть enable password

parser view ACL
secret 5 $1$1KU6$LVXykpW58UV.nCF1e2v6q1
commands configure include terminal-queue
commands configure include ip access-list extended
commands configure include ip
commands configure include no terminal-queue
commands configure include all no ip access-list extended
commands configure include no ip
commands configure include no
commands exec include all ping ip
commands exec include ping
commands exec include configure terminal
commands exec include configure
commands exec include all show

router(config)#username alex view ACL password alexpass
username admin privilege 15 secret dksfbkfb

В этом случае пользователь будет заходить следующим образом:
Тогда юзер будет заходить следующим образом:

User Access Verification
Username: alex
Password:

router>enable view ACL
Password:

Использование сервера ACS

Для авторизации можно использовать сервер ACS, см. раздел Настройка авторизации через сервер ACS в статье Установка и настройка ACS 5

Ссылка на основную публикацию
Adblock
detector