Domain 5. Chapter 14 Flashcards
- Access Control Models
A subject is an active entity that accesses a passive object, and an object is a passive entity that provides information to active subjects. For example, when a user accesses a file, the user is the subject, and the file is the object.
Permissions In general, permissions refer to the access granted for an object and determine what you can do with it. If you have read permission for a file, you’ll be able to open it and read it. You can grant user permissions to create, read, edit, or delete a file on a file server. Similarly, you can grant a user access rights to a file, so in this context, access rights and permissions are synonymous. For example, you may be granted read and execute permissions for an application file, which gives you the right to run the application. Additionally, you may be granted data rights within a database, allowing you to retrieve or update information in the database.
Rights A right primarily refers to the ability to take an action on an object. For example, a user might have the right to modify the system time on a computer or the right to restore backed-up data. This is a subtle distinction and not always stressed. However, you’ll rarely see the right to take action on a system referred to as a permission.
Privileges Privileges are a combination of rights and permissions. For example, an administrator for a computer will have full privileges, granting the administrator full rights and permissions on the computer. The administrator will be able to perform any actions and access any data on the computer.
Субъект — это активная сущность, которая обращается к пассивному объекту, а объект — это пассивная сущность, предоставляющая информацию активным субъектам. Например, когда пользователь обращается к файлу, пользователь является субъектом, а файл — объектом.
Разрешения Как правило, разрешения относятся к доступу, предоставленному объекту, и определяют, что вы можете с ним делать. Если у вас есть разрешение на чтение файла, вы сможете открыть его и прочитать. Вы можете предоставить пользователям разрешения на создание, чтение, редактирование или удаление файла на файловом сервере. Аналогичным образом вы можете предоставить пользователю права доступа к файлу, поэтому в этом контексте права доступа и разрешения являются синонимами. Например, вам могут быть предоставлены разрешения на чтение и выполнение файла приложения, что дает вам право запускать приложение. Кроме того, вам могут быть предоставлены права на данные в базе данных, что позволит вам извлекать или обновлять информацию в базе данных.
Права Право в первую очередь относится к возможности совершать действия над объектом. Например, пользователь может иметь право изменять системное время на компьютере или право восстанавливать данные из резервной копии. Это тонкое различие, и оно не всегда подчеркивается. Однако вы редко увидите право на действие в системе, называемое разрешением.
Привилегии Привилегии — это сочетание прав и разрешений. Например, администратор компьютера будет иметь полные права, предоставляя ему полные права и разрешения на компьютере. Администратор сможет совершать любые действия и получать доступ к любым данным на компьютере.
1.1 Authorization Mechanisms
Implicit Deny A fundamental principle of access control is implicit deny, and most authorization mechanisms use it. The implicit deny principle ensures that access to an object is denied unless access has been explicitly granted to a subject. You can also think of this as deny by default.
Access Control Matrix In short, an access control matrix is a table that includes subjects, objects, and assigned privileges. When a subject attempts an action, the system checks the access control matrix to determine if the subject has the appropriate privileges to perform the action. For example, an access control matrix can include a group of files as the objects and a group of users as the subjects. It will show the exact permissions authorized for each user for each file. Note that this covers much more than a single access control list (ACL). In this example, each file listed within the matrix has a separate ACL that lists the authorized users and their assigned permissions.
Capability Tables Capability tables are another way to identify privileges assigned to subjects. They are different from ACLs in that a capability table is focused on subjects (such as users, groups, or roles). For example, a capability table created for the accounting role will include a list of all objects that the accounting role can access as well as the specific privileges assigned to the accounting role for these objects. In contrast, ACLs are focused on objects. An ACL for a file would list all the users and/or groups that have authorized access to the file and the specific access granted to each.
Неявное запрещение Основным принципом контроля доступа является неявное запрещение, и его использует большинство механизмов авторизации. Принцип неявного запрета гарантирует, что доступ к объекту запрещен, если доступ не был явно предоставлен субъекту. Вы также можете думать об этом как об отказе по умолчанию.
Матрица контроля доступа Короче говоря, матрица управления доступом — это таблица, которая включает субъектов, объекты и назначенные привилегии. Когда субъект пытается выполнить действие, система проверяет матрицу контроля доступа, чтобы определить, имеет ли субъект соответствующие привилегии для выполнения действия. Например, матрица контроля доступа может включать группу файлов в качестве объектов и группу пользователей в качестве субъектов. Он покажет точные разрешения, разрешенные каждому пользователю для каждого файла. Обратите внимание, что это охватывает гораздо больше, чем просто один список управления доступом (ACL). В этом примере каждый файл, указанный в матрице, имеет отдельный список управления доступом, в котором перечислены авторизованные пользователи и назначенные им разрешения.
Таблицы возможностей Таблицы возможностей — это еще один способ определить привилегии, назначенные субъектам. Они отличаются от списков ACL тем, что таблица возможностей ориентирована на субъекты (такие как пользователи, группы или роли). Например, таблица возможностей, созданная для роли учета, будет включать список всех объектов, к которым может получить доступ роль учета, а также конкретные привилегии, назначенные роли учета для этих объектов. Напротив, списки ACL ориентированы на объекты. В списке ACL для файла будут перечислены все пользователи и/или группы, имеющие авторизованный доступ к файлу, а также конкретный доступ, предоставленный каждому.
1.1 Authorization Mechanisms
Constrained Interface Applications use constrained interfaces or restricted interfaces to restrict what users can do or see based on their privileges. Users with full privileges have access to all the capabilities of the application. Users with restricted privileges have limited access. The Clark–Wilson model discusses the technical details of how it implements a constrained interface.
Content-Dependent Control Content-dependent access controls restrict access to data based on the content within an object. A database view is a content-dependent control. A view retrieves specific columns from one or more tables, creating a virtual table.
Context-Dependent Control Context-dependent access controls require specific activity before granting users access. The system denies access to the download page if users don’t go through the purchase process first. It’s also possible to use date and time controls as context-dependent controls. If users attempt to access the resource outside the allowed time, the system denies them access.
Need to Know This principle ensures that subjects are granted access only to what they need to know for their work tasks and job functions. Subjects may have clearance to access classified or restricted data but are not granted authorization to the data unless they actually need it to perform a job.
Least Privilege The principle of least privilege ensures that subjects are granted only the privileges they need to perform their work tasks and job functions. This is sometimes lumped together with need to know. The only difference is that least privilege will also include rights to take action on a system.
Separation of Duties and Responsibilities The separation of duties and responsibilities principle ensures that sensitive functions are split into tasks performed by two or more employees. It helps prevent fraud and errors by creating a system of checks and balances.
Ограниченный интерфейс Приложения используют ограниченные или ограниченные интерфейсы, чтобы ограничить то, что пользователи могут делать или видеть, в зависимости от их привилегий. Пользователи с полными правами имеют доступ ко всем возможностям приложения. Пользователи с ограниченными привилегиями имеют ограниченный доступ. В модели Кларка–Уилсона ( обсуждаются технические детали реализации ограниченного интерфейса.
Управление, зависящее от содержимого Управление доступом, зависящее от содержимого, ограничивает доступ к данным на основе содержимого внутри объекта. Представление базы данных — это элемент управления, зависящий от содержимого. Представление извлекает определенные столбцы из одной или нескольких таблиц, создавая виртуальную таблицу.
Контекстно-зависимый контроль Контекстно-зависимый контроль доступа требует выполнения определенных действий, прежде чем предоставлять пользователям доступ. Система отказывает в доступе к странице загрузки, если пользователи сначала не проходят процесс покупки. Также можно использовать элементы управления датой и временем в качестве контекстно-зависимых элементов управления. Если пользователи попытаются получить доступ к ресурсу вне разрешенного времени, система откажет им в доступе.
Необходимость знать Этот принцип гарантирует, что субъектам предоставляется доступ только к тому, что им необходимо знать для выполнения своих рабочих задач и должностных функций. Субъекты могут иметь разрешение на доступ к секретным или ограниченным данным, но им не предоставляется разрешение на доступ к данным, если они действительно не нужны им для выполнения работы. Наименьшие привилегии
Принцип наименьших привилегий гарантирует, что субъектам предоставляются только те привилегии, которые им необходимы для выполнения своих рабочих задач и должностных функций. Иногда это смешивают с необходимостью знать. Единственное отличие состоит в том, что минимальные привилегии также включают права на выполнение действий в системе.
Разделение обязанностей и ответственности Принцип разделения обязанностей и ответственности обеспечивает разделение важных функций на задачи, выполняемые двумя или более сотрудниками. Это помогает предотвратить мошенничество и ошибки, создавая систему сдержек и противовесов.
- Defining Requirements with a Security Policy
A security policy is a document that defines the security requirements for an organization. It identifies assets that need protection and the extent to which security solutions should go to protect them.
Policies are an important element of access control because they help personnel within the organization understand what security requirements are important.
However, a security policy usually does not go into details about how to fulfill the security needs or how to implement the policy. For example, it may state the need to implement and enforce separation of duties and least privilege principles but not state how to do so. Professionals within the organization use the security policies as a guide to implement security requirements.
- Access Control Models
3.1 Discretionary Access Control
3.2 Role-Based Access Control
3.3 Rule-Based Access Control
3.4 Attribute-Based Access Control
3.5 Mandatory Access Control
3.6 Risk-Based Access Control
3.4 Attribute-Based Access Control
Attribute-Based Access Control A key characteristic of the Attribute-Based Access Control (ABAC) model is its use of rules that can include multiple attributes. This allows it to be much more flexible than a rule-based access control model that applies the rules to all subjects equally. Many software-defined networks (SDNs) use the ABAC model. Additionally, ABAC allows administrators to create rules within a policy using plain language statements such as “Allow Managers to access the WAN using a mobile device.”
However, an advanced implementation of a rule-based access control is an Attribute-Based Access Control (ABAC) model. ABAC models use policies that include multiple attributes for rules.
Attributes can be almost any characteristic of users, the network, and devices on the network. For example, user attributes can include group membership, the department where they work, and devices they use such as desktop PCs or mobile devices. The network can be the local internal network, a wireless network, an intranet, or a wide area network (WAN). Devices can include firewalls, proxy servers, web servers, database servers, and more.
Mobile device management (MDM) systems, discussed in can use attributes to identify mobile devices. Attributes: some attribute examples such as somewhere you are, somewhere you aren’t, and context-aware authentication.
Управление доступом на основе атрибутов Ключевой характеристикой модели управления доступом на основе атрибутов (ABAC) является использование правил, которые могут включать несколько атрибутов. Это позволяет ей быть гораздо более гибкой, чем модель управления доступом на основе правил, которая одинаково применяет правила ко всем субъектам. Многие программно-определяемые сети (SDN) используют модель ABAC. Кроме того, ABAC позволяет администраторам создавать правила в политике, используя простые формулировки, такие как «Разрешить менеджерам доступ к глобальной сети с помощью мобильного устройства».
3.5 Mandatory Access Control
Mandatory Access Control A key characteristic of the Mandatory Access Control (MAC) model is the use of labels applied to both subjects and objects. For example, if a user has a label of top secret, the user can be granted access to a top-secret document. In this example, both the subject and the object have matching labels. When documented in a table, the MAC model sometimes resembles a lattice (such as one used for a climbing rosebush), so it is referred to as a lattice-based model.
Each classification label represents a security domain, or a realm of security. A security domain is a collection of subjects and objects that share a common security policy. For example, a security domain could have the label Secret, and the MAC model would protect all objects with the Secret label in the same manner.
Users have labels assigned to them based on their clearance level, which is a form of privilege.
Using compartmentalization with the MAC model enforces the need to know principle. Users with the Confidential label are not automatically granted access to compartments within the Confidential section.
The MAC model is prohibitive rather than permissive, and it uses an implicit deny philosophy. The MAC model is more secure than the DAC model, but it isn’t as flexible or scalable.
Classifications within a MAC model use one of the following three types of environment:
- Hierarchical Environment A hierarchical environment relates various classification labels in an ordered structure from low security to medium security to high security, such as Confidential, Secret, and Top Secret, respectively. Each level or classification label in the structure is related. Clearance in one level grants the subject access to objects in that level as well as to all objects in lower levels but prohibits access to all objects in higher levels.
- Compartmentalized Environment In a compartmentalized environment, there is no relationship between one security domain and another. Each domain represents a separate isolated compartment. To gain access to an object, the subject must have specific clearance for the object’s security domain.
- Hybrid Environment A hybrid environment combines both hierarchical and compartmentalized concepts so that each hierarchical level may contain numerous subdivisions that are isolated from the rest of the security domain. A subject must have the correct clearance and the need to know data within a specific compartment to gain access to the compartmentalized object. A hybrid MAC environment provides granular control over access but becomes increasingly difficult to manage as it grows.
Мандатный контроль доступа Ключевой характеристикой модели обязательного контроля доступа (MAC) является использование меток, наносимых как на субъекты, так и на объекты. Например, если у пользователя есть гриф «Совершенно секретно», ему может быть предоставлен доступ к совершенно секретному документу. В этом примере и субъект, и объект имеют совпадающие метки. В таблице модель MAC иногда напоминает решетку (например, ту, которая используется для вьющегося розового куста), поэтому ее называют моделью на основе решетки.
3.6 Risk-Based Access Control
Risk-Based Access Control A risk-based access control model grants access after evaluating risk. It evaluates the environment and the situation and makes risk-based decisions using policies embedded within software code. It uses machine learning to make predictive conclusions about current activity based on past activity.
Risk-based access control is relatively new, and the implementation can be quite complex. The model attempts to evaluate risk by considering several different elements, such as:
The environment
The situation
Security policies
In this context, a security policy is software code that makes risk-based decisions based on available data. An organization would modify the choices within the software to support their needs.
Two other things can be checked or required before the policy grants access:
Multifactor Authentication The system will deny access to users logging on with just one factor of authentication.
Compliant Mobile Devices The policy may require that smartphones and tablets meet specific security requirements, such as an up-to-date operating system and device encryption.
A risk-based access control model that examines mobile devices for compliance may interact with an existing mobile device management (MDM) system.
Контроль доступа на основе рисков Модель управления доступом на основе рисков предоставляет доступ после оценки риска. Он оценивает окружающую среду и ситуацию и принимает решения с учетом рисков, используя политики, встроенные в программный код. Он использует машинное обучение, чтобы делать прогнозные выводы о текущей деятельности на основе прошлой деятельности.
3.1 Discretionary Access Control
Discretionary Access Control A key characteristic of the Discretionary Access Control (DAC) model is that every object has an owner and the owner can grant or deny access to any other subjects. For example, if you create a file, you are the owner and can grant permissions to any other user to access the file. The New Technology File System (NTFS), used on Microsoft Windows operating systems, uses the DAC model.
Within the DAC model, every object has an owner (or data custodian), and owners have full control over the objects they own. Permissions (such as read and modify for files) are maintained in an ACL, and owners can easily change permissions. This makes the model very flexible.
It does not offer a centrally controlled management system because owners can alter the ACLs on their objects at will.
Microsoft Windows systems use the DAC model to manage files. Each file and folder has an ACL (also known as a DACL) identifying the permissions granted to any user or group, and the owner can modify permissions.
In a nondiscretionary access control model, access does not focus on user identity. Instead, a static set of rules governing the whole environment manages access. Non-DAC systems are centrally controlled and easier to manage (although less flexible). In general, any model that isn’t a discretionary model is a nondiscretionary model.
Дискреционный контроль доступа Ключевой характеристикой модели дискреционного контроля доступа (DAC) является то, что у каждого объекта есть владелец, и владелец может предоставлять или запрещать доступ любым другим субъектам. Например, если вы создаете файл, вы являетесь его владельцем и можете предоставить любому другому пользователю разрешения на доступ к файлу. Файловая система новой технологии (NTFS), используемая в операционных системах Microsoft Windows, использует модель DAC.
3.2 Role-Based Access Control
A key characteristic of the Role-Based Access Control (RBAC) model is the use of roles or groups. Instead of assigning permissions directly to users, user accounts are placed in roles and administrators assign privileges to the roles. These roles are typically identified by job functions. If a user account is in a role, the user has all the privileges assigned to the role. Microsoft Windows operating systems implement this model with the use of groups.
Administrators often implement Role-Based Access Control (RBAC) using groups.
This approach helps enforce the principle of least privilege by preventing privilege creep. Privilege creep is the tendency for users to accrue privileges over time as their roles and access needs change.
Microsoft operating systems implement RBAC with the use of groups. Some groups, such as the local Administrators group, are predefined.
In the DAC model, objects have owners, and the owner determines who has access. In the RBAC model, administrators determine subject privileges and assign appropriate privileges to roles or groups.
Another method related to RBAC is task-based access control (TBAC). TBAC is similar to RBAC, but instead of being assigned to one or more roles, each user is assigned an array of tasks. As an example, Microsoft Project uses TBAC. Each project has multiple tasks. The project manager assigns tasks to project team personnel. Team personnel can address their own tasks (adding comments, indicating progress, and so on), but they cannot address other tasks. Microsoft Project handles the underlying details.
Управление доступом на основе ролей Ключевой характеристикой модели управления доступом на основе ролей (RBAC) является использование ролей или групп. Вместо того, чтобы назначать разрешения непосредственно пользователям, учетные записи пользователей помещаются в роли, а администраторы присваивают ролям привилегии. Эти роли обычно определяются должностными функциями. Если учетная запись пользователя входит в роль, у пользователя есть все привилегии, назначенные этой роли. Операционные системы Microsoft Windows реализуют эту модель с использованием групп.
3.3 Rule-Based Access Control
A key characteristic of the rule-based access control model is that it applies global rules to all subjects. As an example, a firewall uses rules that allow or block traffic to all users equally. Rules within the rule-based access control model are sometimes referred to as restrictions or filters.
A rule-based access control model uses a set of rules, restrictions, or filters to determine what can and cannot occur on a system. It includes granting a subject access to an object, or granting the subject the ability to perform an action. A distinctive characteristic about rule-based access control models is that they have global rules that apply to all subjects.
One common example of a rule-based access control model is a firewall. Firewalls include a set of rules or filters within an ACL, defined by an administrator. Firewalls include a final rule (referred to as the implicit deny rule), denying or blocking all other traffic.
Ключевой характеристикой модели управления доступом на основе правил является то, что она применяет глобальные правила ко всем субъектам. Например, брандмауэр использует правила, которые одинаково разрешают или блокируют трафик для всех пользователей. Правила в модели управления доступом на основе правил иногда называют ограничениями или фильтрами.
- Implementing Authentication Systems
Authentication systems simplify the management of authentication on the internet and in internal networks.
FIM ( federated identity management) allows different organizations to use federations for SSO (single sign-on).
4.1 Implementing SSO on the Internet
XML, SAML, OAuth, OpenID ( OIDC)
4.2 Implementing SSO on Internal Networks
AAA Protocols, Kerberos, RADIUS, TACACS+
4.1 Implementing SSO on the Internet
Imagine you want to transfer money from Bank A to Bank B. You could give Bank B your credentials to Bank A and have them transfer the money. Sound scary? You bet. You should never be required to give your credentials to any third party. Solutions such as SAML, OAuth, OpenID, and OIDC help solve this problem. They share authentication, authorization, or profile information about a user, and some solutions share all three.
4.1.1XML
Extensible Markup Language (XML) goes beyond describing how to display the data by actually describing the data. XML can include tags to describe data as anything desired.
Databases from multiple vendors can import and export data to and from an XML format, making XML a common language used to exchange information. Many specific schemas exist, and if companies agree on what schema to use, they can easily share information. Many cloud-based providers use XML-based languages to share information for authentication and authorization. They don’t use XML as it is but instead use other languages based on XML.
4.1.2 SAML
Security Assertion Markup Language (SAML) is an open XML-based standard commonly used to exchange authentication and authorization (AA) information between federated organizations. It provides SSO capabilities for browser access.
The SAML 2.0 specification utilizes three entities: the principal, the service provider, and the identity provider.
- Principal or User Agent For simplicity, think of Sally as the principal. She’s trying to access her investment account at ucanbeamillionaire.com.
- Service Provider (SP) In this scenario, the ucanbeamillionaire.com site is providing the service and is the service provider.
- Identity Provider (IdP) This is a third party that holds the user authentication and authorization information.
When Sally accesses the site, it prompts her to enter her credentials. When she does, the site sends her credentials to the IdP. The IdP then responds with XML messages validating (or rejecting) Sally’s credentials and indicating what she is authorized to access. The site then grants her access to her account.
The IdP can send three types of XML messages known as assertions:
- Authentication Assertion This provides proof that the user agent provided the proper credentials, identifies the identification method, and identifies the time the user agent logged on.
- Authorization Assertion This indicates whether the user agent is authorized to access the requested service. If the message indicates access is denied, it indicates why.
- Attribute Assertion Attributes can be any information about the user agent.
Many cloud service providers include SAML in their solutions because it simplifies the services for their customers. SAML provides authentication assertion, attribute assertion, and authorization assertion.
4.1.3 OAuth
OAuth 2.0 (implying open authorization) is an authorization framework described in RFC 6749 and maintained by the Internet Engineering Task Force (IETF). Many companies on the internet use it to share account information with third-party websites.
For example, imagine you have a Twitter account, and you download an app called Acme that can interact with your Twitter account and schedule Tweets in advance. When you try to use the feature in the Acme app, it redirects you to Twitter. Twitter prompts you to log on, shows you what permissions the Acme app will access, and then asks if you want to authorize the Acme app to access your Twitter app. If you approve, Twitter sends the Acme app an authorization token. The app may accept and enter the authorization token directly, or you may need to enter it into the app’s settings. When the app accesses the Twitter account, it sends an API message and includes the token. Note that this doesn’t provide authentication. Instead, it authorizes access to the account. A primary benefit is that you never provide your Twitter credentials to the Acme app. Even if the Acme app is compromised, it does not expose your credentials.
