Куда я попал?
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022
Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А
А.8.2
Для проведения оценки соответствия по документу войдите в систему.
Похожие требования
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014 "Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения":
Р. 7 п. 8 п.п. 4
7.8.4. Работники организации БС РФ, в том числе администраторы автоматизированных систем и средств защиты информации, не должны обладать полномочиями для бесконтрольного создания, авторизации, уничтожения и изменения платежной информации, а также проведения несанкционированных операций по изменению состояния банковских счетов.
Р. 7 п. 2 п.п. 3
7.2.3. С целью предупреждения возникновения и снижения рисков нарушения ИБ не допускается совмещения в рамках одной роли следующих функций: разработки и сопровождения АБС/ПО, их разработки и эксплуатации, сопровождения и эксплуатации, администратора системы и администратора ИБ, выполнения операций в АБС и контроля их выполнения.
CIS Critical Security Controls v8 (The 18 CIS CSC):
5.4
5.4 Restrict Administrator Privileges to Dedicated Administrator Accounts
Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Conduct general computing activities, such as internet browsing, email, and productivity suite use, from the user’s primary, nonprivileged account.
Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Conduct general computing activities, such as internet browsing, email, and productivity suite use, from the user’s primary, nonprivileged account.
12.8
12.8 Establish and Maintain Dedicated Computing Resources for All Administrative Work Devices
Establish and maintain dedicated computing resources, either physically or logically separated, for all administrative tasks or tasks requiring administrative access. The computing resources should be segmented from the enterprise’s primary network and not be allowed internet access.
Establish and maintain dedicated computing resources, either physically or logically separated, for all administrative tasks or tasks requiring administrative access. The computing resources should be segmented from the enterprise’s primary network and not be allowed internet access.
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 6
6.6. Кредитные организации в части нейтрализации информационных угроз со стороны внутреннего нарушителя разрабатывают и принимают организационные и технические меры в отношении субъектов доступа, привлекаемых в рамках выполнения технологических процессов, направленные на исключение возможности несанкционированного использования предоставленных указанным субъектам доступа полномочий.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РД.35
РД.35 Запрет выполнения пользователями бизнес-процессов с использованием привилегированных прав логического доступа, в том числе работы пользователей с правами локального администратора АРМ
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
ЗСВ.22
ЗСВ.22 Выделение отдельных сегментов управления, в которых располагаются АРМ эксплуатационного персонала, используемые для выполнения задач администрирования серверных компонент виртуализации и системы хранения данных (допускается использование единых сегментов управления, выделяемых в рамках выполнения меры ЗСВ.22 и меры СМЭ.9)
3-Н 2-Н 1-Т
3-Н 2-Н 1-Т
NIST Cybersecurity Framework (RU):
PR.AC-1
PR.AC-1: Для авторизованных устройств, пользователей и процессов выдаются, управляются, верифицируются, аннулируются и проверяются идентификационные и учетные данные
PR.AC-4
PR.AC-4: При предоставлении разрешения на доступ и авторизации используется принцип наименьших привилегий и разделения обязанностей
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
УПД.5
УПД.5 Назначение минимально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функционирование информационной системы
УПД.4
УПД.4 Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы
ЗИС.1
ЗИС.1 Разделение в информационной системе функций по управлению (администрированию) информационной системой, управлению (администрированию) системой защиты персональных данных, функций по обработке персональных данных и иных функций информационной системы
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
УИ.16.6
УИ.16.6 Разграничение доступа и контроль несанкционированного изменения стандартов конфигурирования;
Russian Unified Cyber Security Framework (на основе The 18 CIS CSC):
5.4
5.4 Ограничены административные привилегии до выделенных учетных записей администраторов
Стандартные офисные задачи, вроде почтовой переписки и поиска в интернете, решаются с помощью непривилегированных учетных записей.
Стандартные офисные задачи, вроде почтовой переписки и поиска в интернете, решаются с помощью непривилегированных учетных записей.
12.8
12.8 Реализовано и поддерживается выделение отдельных вычислительных ресурсов для любых задач администрирования
Ресурсы для работы под учетной записью администратора находятся в отдельном сетевом сегменте, физически или логически.
Ресурсы для работы под учетной записью администратора находятся в отдельном сетевом сегменте, физически или логически.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 7.2.6
7.2.6
Defined Approach Requirements:
All user access to query repositories of stored cardholder data is restricted as follows:
Defined Approach Requirements:
All user access to query repositories of stored cardholder data is restricted as follows:
- Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges.
- Only the responsible administrator(s) can directly access or query repositories of stored CHD.
Customized Approach Objective:
Direct unfiltered (ad hoc) query access to cardholder data repositories is prohibited, unless performed by an authorized administrator.
Applicability Notes:
This requirement applies to controls for user access to query repositories of stored cardholder data.
See Requirements 7.2.5 and 7.2.5.1 and 8.6.1 through 8.6.3 for controls for application and system accounts.
Defined Approach Testing Procedures:
Direct unfiltered (ad hoc) query access to cardholder data repositories is prohibited, unless performed by an authorized administrator.
Applicability Notes:
This requirement applies to controls for user access to query repositories of stored cardholder data.
See Requirements 7.2.5 and 7.2.5.1 and 8.6.1 through 8.6.3 for controls for application and system accounts.
Defined Approach Testing Procedures:
- 7.2.6.a Examine policies and procedures and interview personnel to verify processes are defined for granting user access to query repositories of stored cardholder data, in accordance with all elements specified in this requirement.
- 7.2.6.b Examine configuration settings for querying repositories of stored cardholder data to verify they are in accordance with all elements specified in this requirement.
Purpose:
The misuse of query access to repositories of cardholder data has been a regular cause of data breaches. Limiting such access to administrators reduces the risk of such access being abused by unauthorized users.
Definitions:
“Programmatic methods” means granting access through means such as database stored procedures that allow users to perform controlled actions to data in a table, rather than via direct, unfiltered access to the data repository by end users (except for the responsible administrator(s), who need direct access to the database for their administrative duties).
Good Practice:
Typical user actions include moving, copying, and deleting data. Also consider the scope of privilege needed when granting access. For example, access can be granted to specific objects such as data elements, files, tables, indexes, views, and stored routines. Granting access to repositories of cardholder data should follow the same process as all other granted access, meaning that it is based on roles, with only the privileges assigned to each user that are needed to perform their job functions.
The misuse of query access to repositories of cardholder data has been a regular cause of data breaches. Limiting such access to administrators reduces the risk of such access being abused by unauthorized users.
Definitions:
“Programmatic methods” means granting access through means such as database stored procedures that allow users to perform controlled actions to data in a table, rather than via direct, unfiltered access to the data repository by end users (except for the responsible administrator(s), who need direct access to the database for their administrative duties).
Good Practice:
Typical user actions include moving, copying, and deleting data. Also consider the scope of privilege needed when granting access. For example, access can be granted to specific objects such as data elements, files, tables, indexes, views, and stored routines. Granting access to repositories of cardholder data should follow the same process as all other granted access, meaning that it is based on roles, with only the privileges assigned to each user that are needed to perform their job functions.
Requirement 7.2.3
7.2.3
Defined Approach Requirements:
Required privileges are approved by authorized personnel
Customized Approach Objective:
Access privileges cannot be granted to users without appropriate, documented authorization.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Required privileges are approved by authorized personnel
Customized Approach Objective:
Access privileges cannot be granted to users without appropriate, documented authorization.
Defined Approach Testing Procedures:
- 7.2.3.a Examine policies and procedures to verify they define processes for approval of all privileges by authorized personnel.
- 7.2.3.b Examine user IDs and assigned privileges, and compare with documented approvals to verify that:
- Documented approval exists for the assigned privileges.
- The approval was by authorized personnel.
- Specified privileges match the roles assigned to the individual.
Purpose:
Documented approval (for example, in writing or electronically) assures that those with access and privileges are known and authorized by management, and that their access is necessary for their job function.
Documented approval (for example, in writing or electronically) assures that those with access and privileges are known and authorized by management, and that their access is necessary for their job function.
Requirement 3.6.1.3
3.6.1.3
Defined Approach Requirements:
Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary.
Customized Approach Objective:
Access to cleartext cryptographic key components is restricted to necessary personnel.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary.
Customized Approach Objective:
Access to cleartext cryptographic key components is restricted to necessary personnel.
Defined Approach Testing Procedures:
- 3.6.1.3 Examine user access lists to verify that access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary.
Purpose:
Restricting the number of people who have access to cleartext cryptographic key components reduces the risk of stored account data being retrieved or rendered visible by unauthorized parties.
Good Practice:
Only personnel with defined key custodian responsibilities (creating, altering, rotating, distributing, or otherwise maintaining encryption keys) should be granted access to key components.
Ideally this will be a very small number of people.
Restricting the number of people who have access to cleartext cryptographic key components reduces the risk of stored account data being retrieved or rendered visible by unauthorized parties.
Good Practice:
Only personnel with defined key custodian responsibilities (creating, altering, rotating, distributing, or otherwise maintaining encryption keys) should be granted access to key components.
Ideally this will be a very small number of people.
Requirement 7.2.1
7.2.1
Defined Approach Requirements:
An access control model is defined and includes granting access as follows:
Defined Approach Requirements:
An access control model is defined and includes granting access as follows:
- Appropriate access depending on the entity’s business and access needs.
- Access to system components and data resources that is based on users’ job classification and functions.
- The least privileges required (for example, user, administrator) to perform a job function.
Customized Approach Objective:
Access requirements are established according to job functions following least-privilege and need-toknow principles
Defined Approach Testing Procedures:
Access requirements are established according to job functions following least-privilege and need-toknow principles
Defined Approach Testing Procedures:
- 7.2.1.a Examine documented policies and procedures and interview personnel to verify the access control model is defined in accordance with all elements specified in this requirement.
- 7.2.1.b Examine access control model settings and verify that access needs are appropriately defined in accordance with all elements specified in this requirement.
Purpose:
Defining an access control model that is appropriate for the entity’s technology and access control philosophy supports a consistent and uniform way of allocating access and reduces the possibility of errors such as the granting of excessive rights.
Good Practice:
A factor to consider when defining access needs is the separation of duties principle. This principle is intended to prevent fraud and misuse or theft of resources. For example, 1) dividing missioncritical functions and information system support functions among different individuals and/or functions, 2) establishing roles such that information system support activities are performed by different functions/individuals (for example, system management, programming, configuration management, quality assurance and testing, and network security), and 3) ensuring security personnel administering access control functions do not also administer audit functions.
In environments where one individual performs multiple functions, such as administration and security operations, duties may be assigned so that no single individual has end-to-end control of a process without an independent checkpoint. For example, responsibility for configuration and responsibility for approving changes could be assigned to separate individuals.
Definitions:
Key elements of an access control model include:
Defining an access control model that is appropriate for the entity’s technology and access control philosophy supports a consistent and uniform way of allocating access and reduces the possibility of errors such as the granting of excessive rights.
Good Practice:
A factor to consider when defining access needs is the separation of duties principle. This principle is intended to prevent fraud and misuse or theft of resources. For example, 1) dividing missioncritical functions and information system support functions among different individuals and/or functions, 2) establishing roles such that information system support activities are performed by different functions/individuals (for example, system management, programming, configuration management, quality assurance and testing, and network security), and 3) ensuring security personnel administering access control functions do not also administer audit functions.
In environments where one individual performs multiple functions, such as administration and security operations, duties may be assigned so that no single individual has end-to-end control of a process without an independent checkpoint. For example, responsibility for configuration and responsibility for approving changes could be assigned to separate individuals.
Definitions:
Key elements of an access control model include:
- Resources to be protected (the systems/devices/data to which access is needed),
- Job functions that need access to the resource (for example, system administrator, call-center personnel, store clerk), and
- Which activities each job function needs to perform (for example, read/write or query).
Once job functions, resources, and activities per job functions are defined, individuals can be granted access accordingly.
Examples:
Access control models that entities can consider include role-based access control (RBAC) and attribute-based access control (ABAC). The access control model used by a given entity depends on their business and access needs.
Examples:
Access control models that entities can consider include role-based access control (RBAC) and attribute-based access control (ABAC). The access control model used by a given entity depends on their business and access needs.
Requirement 3.7.6
3.7.6
Defined Approach Requirements:
Where manual cleartext cryptographic keymanagement operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control.
Customized Approach Objective:
Cleartext secret or private keys cannot be known by anyone. Operations involving cleartext keys cannot be carried out by a single person.
Applicability Notes:
This control is applicable for manual keymanagement operations or where key management is not controlled by the encryption product. A cryptographic key that is simply split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:
Defined Approach Requirements:
Where manual cleartext cryptographic keymanagement operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control.
Customized Approach Objective:
Cleartext secret or private keys cannot be known by anyone. Operations involving cleartext keys cannot be carried out by a single person.
Applicability Notes:
This control is applicable for manual keymanagement operations or where key management is not controlled by the encryption product. A cryptographic key that is simply split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:
- Using an approved random number generator and within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device, OR
- According to ISO 19592 or equivalent industry standard for generation of secret key shares.
Defined Approach Testing Procedures:
- 3.7.6.a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define using split knowledge and dual control.
- 3.7.6.b Interview personnel and/or observe processes to verify that manual cleartext keys are managed with split knowledge and dual control.
Purpose:
Split knowledge and dual control of keys are used to eliminate the possibility of a single person having access to the whole key and therefore being able to gain unauthorized access to the data.
Definitions:
Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of other components or of the original cryptographic key.
Dual control requires two or more people to authenticate the use of a cryptographic key or perform a key-management function. No single person can access or use the authentication factor (for example, the password, PIN, or key) of another.
Good Practice:
Where key components or key shares are used, procedures should ensure that no single custodian ever has access to sufficient key components or shares to reconstruct the cryptographic key. For example, in an m-of-n scheme (for example, Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian should not then be assigned component B or C, as this would give the custodian knowledge of two components and the ability to recreate the key.
Examples:
Key-management operations that might be performed manually include, but are not limited to, key generation, transmission, loading, storage, and destruction.
Further Information:
Industry standards for managing key components include:
Split knowledge and dual control of keys are used to eliminate the possibility of a single person having access to the whole key and therefore being able to gain unauthorized access to the data.
Definitions:
Split knowledge is a method in which two or more people separately have key components, where each person knows only their own key component, and the individual key components convey no knowledge of other components or of the original cryptographic key.
Dual control requires two or more people to authenticate the use of a cryptographic key or perform a key-management function. No single person can access or use the authentication factor (for example, the password, PIN, or key) of another.
Good Practice:
Where key components or key shares are used, procedures should ensure that no single custodian ever has access to sufficient key components or shares to reconstruct the cryptographic key. For example, in an m-of-n scheme (for example, Shamir), where only two of any three components are required to reconstruct the cryptographic key, a custodian must not have current or prior knowledge of more than one component. If a custodian was previously assigned component A, which was then reassigned, the custodian should not then be assigned component B or C, as this would give the custodian knowledge of two components and the ability to recreate the key.
Examples:
Key-management operations that might be performed manually include, but are not limited to, key generation, transmission, loading, storage, and destruction.
Further Information:
Industry standards for managing key components include:
- NIST SP 800-57 Part 2, Revision 1 -- Recommendation for Key Management: Part 2 – Best Practices for Key Management Organizations [4.6 Keying Material Distribution]
- ISO 11568-2 Banking — Key management (retail) — Part 2: Symmetric ciphers, their key management and life cycle [4.7.2.3 Key components and 4.9.3 Key components]
- European Payments Council EPC342-08 Guidelines on Cryptographic Algorithms Usage and Key Management [especially 4.1.4 Key installation].
Requirement 7.2.2
7.2.2
Defined Approach Requirements:
Access is assigned to users, including privileged users, based on:
Defined Approach Requirements:
Access is assigned to users, including privileged users, based on:
- Job classification and function.
- Least privileges necessary to perform job responsibilities.
Customized Approach Objective:
Access to systems and data is limited to only the access needed to perform job functions, as defined in the related access roles.
Defined Approach Testing Procedures:
Access to systems and data is limited to only the access needed to perform job functions, as defined in the related access roles.
Defined Approach Testing Procedures:
- 7.2.2.a Examine policies and procedures to verify they cover assigning access to users in accordance with all elements specified in this requirement.
- 7.2.2.b Examine user access settings, including for privileged users, and interview responsible management personnel to verify that privileges assigned are in accordance with all elements specified in this requirement.
- 7.2.2.c Interview personnel responsible for assigning access to verify that privileged user access is assigned in accordance with all elements specified in this requirement.
Purpose:
Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings. Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access to a user ID.
Good Practice:
Access rights are granted to a user by assignment to one or several functions. Assess is assigned depending on the specific user functions and with the minimum scope required for the job.
When assigning privileged access, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). For example, the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator.
Once needs are defined for user functions (per PCI DSS requirement 7.2.1), it is easy to grant individuals access according to their job classification and function by using the alreadycreated roles.
Entities may wish to consider use of Privileged Access Management (PAM), which is a method to grant access to privileged accounts only when those privileges are required, immediately revoking that access once they are no longer needed.
Assigning least privileges helps prevent users without sufficient knowledge about the application from incorrectly or accidentally changing application configuration or altering its security settings. Enforcing least privilege also helps to minimize the scope of damage if an unauthorized person gains access to a user ID.
Good Practice:
Access rights are granted to a user by assignment to one or several functions. Assess is assigned depending on the specific user functions and with the minimum scope required for the job.
When assigning privileged access, it is important to assign individuals only the privileges they need to perform their job (the “least privileges”). For example, the database administrator or backup administrator should not be assigned the same privileges as the overall systems administrator.
Once needs are defined for user functions (per PCI DSS requirement 7.2.1), it is easy to grant individuals access according to their job classification and function by using the alreadycreated roles.
Entities may wish to consider use of Privileged Access Management (PAM), which is a method to grant access to privileged accounts only when those privileges are required, immediately revoking that access once they are no longer needed.
Guideline for a healthy information system v.2.0 (EN):
29 STANDARD
/STANDARD
Numerous users, including at the top management level, are tempted to ask their IT department to be able to provide them, in line with their personal use, with higher privileges on their workstations: installation of software, system configuration, etc. By default, it is recommended that an information system user, whatever his responsibility level and allocations, should not have administration privileges on his workstation. This measure, which appears restrictive, aims to limit the consequences of malicious executions from malware. The availability of a well-rounded application store, validated by the organization from the security point of view, will be able to respond to the majority of needs.
Consequently, only administrators responsible for the administration of workstations must have these rights during their interventions.
If delegating privileges to a workstation is really necessary to respond to a one-off need from the user, it must be monitored, for a limited time, and be withdrawn afterwards.
Numerous users, including at the top management level, are tempted to ask their IT department to be able to provide them, in line with their personal use, with higher privileges on their workstations: installation of software, system configuration, etc. By default, it is recommended that an information system user, whatever his responsibility level and allocations, should not have administration privileges on his workstation. This measure, which appears restrictive, aims to limit the consequences of malicious executions from malware. The availability of a well-rounded application store, validated by the organization from the security point of view, will be able to respond to the majority of needs.
Consequently, only administrators responsible for the administration of workstations must have these rights during their interventions.
If delegating privileges to a workstation is really necessary to respond to a one-off need from the user, it must be monitored, for a limited time, and be withdrawn afterwards.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.2.3
A.9.2.3 Управление привилегированными правами доступа
Мера обеспечения информационной безопасности: Распределение и использование привилегированных прав доступа следует ограничивать и контролировать
Мера обеспечения информационной безопасности: Распределение и использование привилегированных прав доступа следует ограничивать и контролировать
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 11.6
CSC 11.6 Use Dedicated Machines For All Network Administrative Tasks
Ensure network engineers use a dedicated machine for all administrative tasks or tasks requiring elevated access. This machine shall be segmented from the organization's primary network and not be allowed Internet access. This machine shall not be used for reading email, composing documents, or surfing the Internet.
Ensure network engineers use a dedicated machine for all administrative tasks or tasks requiring elevated access. This machine shall be segmented from the organization's primary network and not be allowed Internet access. This machine shall not be used for reading email, composing documents, or surfing the Internet.
CSC 4.8
CSC 4.8 Log and Alert on Changes to Administrative Group Membership
Configure systems to issue a log entry and alert when an account is added to or removed from any group assigned administrative privileges.
Configure systems to issue a log entry and alert when an account is added to or removed from any group assigned administrative privileges.
CSC 4.1
CSC 4.1 Maintain Inventory of Administrative Accounts
Use automated tools to inventory all administrative accounts, including domain and local accounts, to ensure that only authorized individuals have elevated privileges.
Use automated tools to inventory all administrative accounts, including domain and local accounts, to ensure that only authorized individuals have elevated privileges.
CSC 3.3
CSC 3.3 Protect Dedicated Assessment Accounts
Use a dedicated account for authenticated vulnerability scans, which should not be used for any other administrative activities and should be tied to specific machines at specific IP addresses.
Use a dedicated account for authenticated vulnerability scans, which should not be used for any other administrative activities and should be tied to specific machines at specific IP addresses.
CSC 4.3
CSC 4.3 Ensure the Use of Dedicated Administrative Accounts
Ensure that all users with administrative account access use a dedicated or secondary account for elevated activities. This account should only be used for administrative activities and not internet browsing, email, or similar activities.
Ensure that all users with administrative account access use a dedicated or secondary account for elevated activities. This account should only be used for administrative activities and not internet browsing, email, or similar activities.
CSC 4.6
CSC 4.6 Use Dedicated Workstations For All Administrative Tasks
Ensure administrators use a dedicated machine for all administrative tasks or tasks requiring administrative access. This machine will be segmented from the organization's primary network and not be allowed Internet access. This machine will not be used for reading e-mail, composing documents, or browsing the Internet.
Ensure administrators use a dedicated machine for all administrative tasks or tasks requiring administrative access. This machine will be segmented from the organization's primary network and not be allowed Internet access. This machine will not be used for reading e-mail, composing documents, or browsing the Internet.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 7.2.6
7.2.6
Определенные Требования к Подходу:
Доступ всех пользователей к хранилищам запросов сохраненных данных о держателях карт ограничен следующим образом:
Определенные Требования к Подходу:
Доступ всех пользователей к хранилищам запросов сохраненных данных о держателях карт ограничен следующим образом:
- С помощью приложений или других программных методов, с доступом и разрешенными действиями на основе ролей пользователей и минимальных привилегий.
- Только ответственный администратор (ы) может напрямую обращаться к хранилищам сохраненных CHD или запрашивать их.
Цель Индивидуального подхода:
Прямой нефильтрованный (специальный) доступ по запросу к хранилищам данных о держателях карт запрещен, если только он не выполняется уполномоченным администратором.
Примечания по применению:
Это требование применяется к элементам управления доступом пользователей к хранилищам запросов сохраненных данных о держателях карт.
См. Требования 7.2.5 и 7.2.5.1 и 8.6.1-8.6.3 для элементов управления учетными записями приложений и систем.
Определенные Процедуры Тестирования Подхода:
Прямой нефильтрованный (специальный) доступ по запросу к хранилищам данных о держателях карт запрещен, если только он не выполняется уполномоченным администратором.
Примечания по применению:
Это требование применяется к элементам управления доступом пользователей к хранилищам запросов сохраненных данных о держателях карт.
См. Требования 7.2.5 и 7.2.5.1 и 8.6.1-8.6.3 для элементов управления учетными записями приложений и систем.
Определенные Процедуры Тестирования Подхода:
- 7.2.6.a Изучить политики и процедуры и опросить персонал для проверки того, определены ли процессы для предоставления пользователю доступа к хранилищам запросов сохраненных данных о держателях карт в соответствии со всеми элементами, указанными в этом требовании.
- 7.2.6.b Изучите параметры конфигурации для запроса хранилищ сохраненных данных о держателях карт, чтобы убедиться, что они соответствуют всем элементам, указанным в этом требовании.
Цель:
Неправильное использование доступа к запросам к хранилищам данных о держателях карт является регулярной причиной утечек данных. Ограничение такого доступа администраторам снижает риск злоупотребления таким доступом неавторизованными пользователями.
Определения:
“Программные методы” означают предоставление доступа с помощью таких средств, как хранимые процедуры базы данных, которые позволяют пользователям выполнять контролируемые действия с данными в таблице, а не через прямой, нефильтрованный доступ конечных пользователей к хранилищу данных (за исключением ответственного администратора (администраторов), которым необходим прямой доступ к базе данных для их административные обязанности).
Надлежащая практика:
Типичные действия пользователя включают перемещение, копирование и удаление данных. Также учитывайте объем привилегий, необходимых при предоставлении доступа. Например, доступ может быть предоставлен к определенным объектам, таким как элементы данных, файлы, таблицы, индексы, представления и хранимые процедуры. Предоставление доступа к хранилищам данных о держателях карт должно осуществляться по тому же процессу, что и любой другой предоставленный доступ, что означает, что он основан на ролях, при этом каждому пользователю назначаются только те привилегии, которые необходимы для выполнения его должностных функций.
Неправильное использование доступа к запросам к хранилищам данных о держателях карт является регулярной причиной утечек данных. Ограничение такого доступа администраторам снижает риск злоупотребления таким доступом неавторизованными пользователями.
Определения:
“Программные методы” означают предоставление доступа с помощью таких средств, как хранимые процедуры базы данных, которые позволяют пользователям выполнять контролируемые действия с данными в таблице, а не через прямой, нефильтрованный доступ конечных пользователей к хранилищу данных (за исключением ответственного администратора (администраторов), которым необходим прямой доступ к базе данных для их административные обязанности).
Надлежащая практика:
Типичные действия пользователя включают перемещение, копирование и удаление данных. Также учитывайте объем привилегий, необходимых при предоставлении доступа. Например, доступ может быть предоставлен к определенным объектам, таким как элементы данных, файлы, таблицы, индексы, представления и хранимые процедуры. Предоставление доступа к хранилищам данных о держателях карт должно осуществляться по тому же процессу, что и любой другой предоставленный доступ, что означает, что он основан на ролях, при этом каждому пользователю назначаются только те привилегии, которые необходимы для выполнения его должностных функций.
Requirement 7.2.3
7.2.3
Определенные Требования к Подходу:
Необходимые привилегии утверждаются уполномоченным персоналом
Цель Индивидуального подхода:
Права доступа не могут быть предоставлены пользователям без соответствующей документированной авторизации.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Необходимые привилегии утверждаются уполномоченным персоналом
Цель Индивидуального подхода:
Права доступа не могут быть предоставлены пользователям без соответствующей документированной авторизации.
Определенные Процедуры Тестирования Подхода:
- 7.2.3.a Изучите политики и процедуры, чтобы убедиться, что они определяют процессы утверждения всех привилегий уполномоченным персоналом.
- 7.2.3.b Проверьте идентификаторы пользователей и назначенные привилегии и сравните с документально подтвержденными утверждениями, чтобы убедиться, что:
- Для присвоенных привилегий существует документально подтвержденное утверждение.
- Одобрение было получено уполномоченным персоналом.
- Указанные привилегии соответствуют ролям, назначенным данному лицу.
Цель:
Документально оформленное одобрение (например, в письменной или электронной форме) гарантирует, что лица, обладающие доступом и привилегиями, известны и авторизованы руководством, и что их доступ необходим для выполнения их должностных функций.
Документально оформленное одобрение (например, в письменной или электронной форме) гарантирует, что лица, обладающие доступом и привилегиями, известны и авторизованы руководством, и что их доступ необходим для выполнения их должностных функций.
Requirement 3.6.1.3
3.6.1.3
Определенные Требования к Подходу:
Доступ к компонентам криптографических ключей с открытым текстом ограничен минимальным количеством необходимых хранителей.
Цель Индивидуального подхода:
Доступ к компонентам криптографического ключа открытого текста ограничен необходимым персоналом.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Доступ к компонентам криптографических ключей с открытым текстом ограничен минимальным количеством необходимых хранителей.
Цель Индивидуального подхода:
Доступ к компонентам криптографического ключа открытого текста ограничен необходимым персоналом.
Определенные Процедуры Тестирования Подхода:
- 3.6.1.3 Изучите списки доступа пользователей, чтобы убедиться, что доступ к компонентам криптографических ключей открытого текста ограничен наименьшим количеством необходимых хранителей.
Цель:
Ограничение числа людей, имеющих доступ к компонентам криптографического ключа с открытым текстом, снижает риск получения сохраненных данных учетной записи или их отображения неавторизованными сторонами.
Надлежащая практика:
Доступ к ключевым компонентам должен предоставляться только персоналу с определенными обязанностями по хранению ключей (создание, изменение, ротация, распространение или иное обслуживание ключей шифрования).
В идеале это будет очень небольшое количество людей.
Ограничение числа людей, имеющих доступ к компонентам криптографического ключа с открытым текстом, снижает риск получения сохраненных данных учетной записи или их отображения неавторизованными сторонами.
Надлежащая практика:
Доступ к ключевым компонентам должен предоставляться только персоналу с определенными обязанностями по хранению ключей (создание, изменение, ротация, распространение или иное обслуживание ключей шифрования).
В идеале это будет очень небольшое количество людей.
Requirement 3.7.6
Определенные Процедуры Тестирования Подхода:
3.7.6
Определенные Требования к Подходу:
Там, где персонал выполняет операции по управлению ключами с открытым текстом вручную, политики и процедуры управления ключами включают управление этими операциями с использованием разделенных знаний и двойного контроля.
Цель Индивидуального подхода:
Секретные или закрытые ключи открытого текста не могут быть известны никому. Операции, связанные с ключами открытого текста, не могут выполняться одним человеком.
Примечания по применению:
Этот элемент управления применим для операций ручного управления ключами или там, где управление ключами не контролируется продуктом шифрования. Криптографический ключ, который просто разделяется на две части, не соответствует этому требованию. Секретные или закрытые ключи, хранящиеся в качестве ключевых компонентов или общих ключей, должны быть сгенерированы одним из следующих способов:
Определенные Требования к Подходу:
Там, где персонал выполняет операции по управлению ключами с открытым текстом вручную, политики и процедуры управления ключами включают управление этими операциями с использованием разделенных знаний и двойного контроля.
Цель Индивидуального подхода:
Секретные или закрытые ключи открытого текста не могут быть известны никому. Операции, связанные с ключами открытого текста, не могут выполняться одним человеком.
Примечания по применению:
Этот элемент управления применим для операций ручного управления ключами или там, где управление ключами не контролируется продуктом шифрования. Криптографический ключ, который просто разделяется на две части, не соответствует этому требованию. Секретные или закрытые ключи, хранящиеся в качестве ключевых компонентов или общих ключей, должны быть сгенерированы одним из следующих способов:
- С использованием одобренного генератора случайных чисел и в защищенном криптографическом устройстве (SCD), таком как аппаратный модуль безопасности (HSM) или устройство точки взаимодействия, одобренное PTS,
ИЛИ
- В соответствии с в соответствии с ISO 19592 или эквивалентным отраслевым стандартом для генерации общих секретных ключей.
Определенные Процедуры Тестирования Подхода:
- 3.7.6.a Изучите документированные политики и процедуры управления ключами для ключей, используемых для защиты хранимых данных учетной записи, и убедитесь, что они определены с использованием разделенных знаний и двойного контроля.
- 3.7.6.b Опрашивать персонал и / или наблюдать за процессами, чтобы убедиться, что ручные ключи открытого текста управляются с разделенными знаниями и двойным контролем.
Цель:
Разделение знаний и двойной контроль ключей используются для устранения возможности того, что один человек имеет доступ ко всему ключу и, следовательно, может получить несанкционированный доступ к данным.
Определения:
Разделение знаний - это метод, при котором два или более человека по отдельности владеют ключевыми компонентами, где каждый человек знает только свой собственный ключевой компонент, а отдельные ключевые компоненты не передают никаких знаний о других компонентах или об исходном криптографическом ключе.
Двойной контроль требует, чтобы два или более человека проверяли подлинность использования криптографического ключа или выполняли функцию управления ключами. Ни один человек не может получить доступ или использовать фактор аутентификации (например, пароль, PIN-код или ключ) другого человека.
Надлежащая практика:
Там, где используются ключевые компоненты или общие ресурсы ключей, процедуры должны гарантировать, что ни один хранитель никогда не будет иметь доступа к достаточному количеству ключевых компонентов или общих ресурсов для восстановления криптографического ключа. Например, в схеме m-of-n (например, Shamir), где для восстановления криптографического ключа требуются только два из любых трех компонентов, хранитель не должен иметь текущих или предварительных знаний более чем об одном компоненте. Если хранителю ранее был назначен компонент A, который затем был переназначен, хранителю не следует назначать компонент B или C, поскольку это дало бы хранителю знания о двух компонентах и возможность воссоздать ключ.
Примеры:
Операции управления ключами, которые могут выполняться вручную, включают, но не ограничиваются ими, генерацию, передачу, загрузку, хранение и уничтожение ключей.
Дополнительная информация:
Отраслевые стандарты для управления ключевыми компонентами включают:
Разделение знаний и двойной контроль ключей используются для устранения возможности того, что один человек имеет доступ ко всему ключу и, следовательно, может получить несанкционированный доступ к данным.
Определения:
Разделение знаний - это метод, при котором два или более человека по отдельности владеют ключевыми компонентами, где каждый человек знает только свой собственный ключевой компонент, а отдельные ключевые компоненты не передают никаких знаний о других компонентах или об исходном криптографическом ключе.
Двойной контроль требует, чтобы два или более человека проверяли подлинность использования криптографического ключа или выполняли функцию управления ключами. Ни один человек не может получить доступ или использовать фактор аутентификации (например, пароль, PIN-код или ключ) другого человека.
Надлежащая практика:
Там, где используются ключевые компоненты или общие ресурсы ключей, процедуры должны гарантировать, что ни один хранитель никогда не будет иметь доступа к достаточному количеству ключевых компонентов или общих ресурсов для восстановления криптографического ключа. Например, в схеме m-of-n (например, Shamir), где для восстановления криптографического ключа требуются только два из любых трех компонентов, хранитель не должен иметь текущих или предварительных знаний более чем об одном компоненте. Если хранителю ранее был назначен компонент A, который затем был переназначен, хранителю не следует назначать компонент B или C, поскольку это дало бы хранителю знания о двух компонентах и возможность воссоздать ключ.
Примеры:
Операции управления ключами, которые могут выполняться вручную, включают, но не ограничиваются ими, генерацию, передачу, загрузку, хранение и уничтожение ключей.
Дополнительная информация:
Отраслевые стандарты для управления ключевыми компонентами включают:
- NIST SP 800-57 Часть 2, Редакция 1 – Рекомендация для управления ключами: Часть 2 - Лучшие практики для организаций по управлению ключами [4.6 Распределение материалов по ключам]
- ISO 11568-2 Банковское дело — Управление ключами (розничная торговля) — Часть 2: Симметричные шифры, их управление ключами и жизненный цикл [4.7.2.3 Ключевые компоненты и 4.9.3 Ключевые компоненты]
- Руководство Европейского Платежного совета EPC342-08 по использованию криптографических алгоритмов и управлению ключами [особенно установка ключа 4.1.4].
Requirement 7.2.2
7.2.2
Определенные Требования к Подходу:
Доступ назначается пользователям, включая привилегированных пользователей, на основе:
Определенные Требования к Подходу:
Доступ назначается пользователям, включая привилегированных пользователей, на основе:
- Классификации должностей и функций.
- Минимум привилегий, необходимых для выполнения должностных обязанностей.
Цель Индивидуального подхода:
Доступ к системам и данным ограничен только доступом, необходимым для выполнения рабочих функций, как определено в соответствующих ролях доступа.
Определенные Процедуры Тестирования Подхода:
Доступ к системам и данным ограничен только доступом, необходимым для выполнения рабочих функций, как определено в соответствующих ролях доступа.
Определенные Процедуры Тестирования Подхода:
- 7.2.2.a Изучите политики и процедуры, чтобы убедиться, что они охватывают предоставление доступа пользователям в соответствии со всеми элементами, указанными в этом требовании.
- 7.2.2.b Изучите настройки доступа пользователей, в том числе для привилегированных пользователей, и опросите ответственный управленческий персонал, чтобы убедиться, что назначенные привилегии соответствуют всем элементам, указанным в этом требовании.
- 7.2.2.c Опросите персонал, ответственный за назначение доступа, чтобы убедиться, что привилегированный доступ пользователя назначен в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Назначение минимальных привилегий помогает предотвратить неправильное или случайное изменение конфигурации приложения или параметров его безопасности пользователями, не имеющими достаточных знаний о приложении. Применение минимальных привилегий также помогает свести к минимуму ущерб, если неавторизованное лицо получит доступ к идентификатору пользователя.
Надлежащая практика:
Права доступа предоставляются пользователю путем назначения одной или нескольким функциям. Оценка назначается в зависимости от конкретных функций пользователя и с минимальным объемом, необходимым для выполнения задания.
При назначении привилегированного доступа важно назначать отдельным лицам только те привилегии, которые им необходимы для выполнения их работы (“наименьшие привилегии”). Например, администратору базы данных или администратору резервного копирования не следует назначать те же привилегии, что и общему системному администратору.
Как только потребности определены для пользовательских функций (в соответствии с требованием PCI DSS 7.2.1), легко предоставить отдельным лицам доступ в соответствии с их классификацией должностей и функциями, используя уже созданные роли.
Организации могут пожелать рассмотреть возможность использования Управления привилегированным доступом (PAM), которое представляет собой метод предоставления доступа к привилегированным учетным записям только тогда, когда эти привилегии требуются, и немедленного отзыва этого доступа, как только они больше не нужны.
Назначение минимальных привилегий помогает предотвратить неправильное или случайное изменение конфигурации приложения или параметров его безопасности пользователями, не имеющими достаточных знаний о приложении. Применение минимальных привилегий также помогает свести к минимуму ущерб, если неавторизованное лицо получит доступ к идентификатору пользователя.
Надлежащая практика:
Права доступа предоставляются пользователю путем назначения одной или нескольким функциям. Оценка назначается в зависимости от конкретных функций пользователя и с минимальным объемом, необходимым для выполнения задания.
При назначении привилегированного доступа важно назначать отдельным лицам только те привилегии, которые им необходимы для выполнения их работы (“наименьшие привилегии”). Например, администратору базы данных или администратору резервного копирования не следует назначать те же привилегии, что и общему системному администратору.
Как только потребности определены для пользовательских функций (в соответствии с требованием PCI DSS 7.2.1), легко предоставить отдельным лицам доступ в соответствии с их классификацией должностей и функциями, используя уже созданные роли.
Организации могут пожелать рассмотреть возможность использования Управления привилегированным доступом (PAM), которое представляет собой метод предоставления доступа к привилегированным учетным записям только тогда, когда эти привилегии требуются, и немедленного отзыва этого доступа, как только они больше не нужны.
Requirement 7.2.1
7.2.1
Определенные Требования к Подходу:
Определена модель управления доступом, которая включает в себя предоставление доступа следующим образом:
Определенные Требования к Подходу:
Определена модель управления доступом, которая включает в себя предоставление доступа следующим образом:
- Соответствующий доступ в зависимости от бизнеса организации и потребностей в доступе.
- Доступ к системным компонентам и ресурсам данных, основанный на классификации и функциях пользователей.
- Наименьшие привилегии, необходимые (например, пользователь, администратор) для выполнения рабочей функции.
Цель Индивидуального подхода:
Требования к доступу устанавливаются в соответствии с должностными функциями в соответствии с принципами наименьших привилегий и необходимости знать
Определенные Процедуры Тестирования Подхода:
Требования к доступу устанавливаются в соответствии с должностными функциями в соответствии с принципами наименьших привилегий и необходимости знать
Определенные Процедуры Тестирования Подхода:
- 7.2.1.a Изучите документированные политики и процедуры и опросите персонал, чтобы убедиться, что модель контроля доступа определена в соответствии со всеми элементами, указанными в этом требовании.
- 7.2.1.b Изучите настройки модели управления доступом и убедитесь, что потребности в доступе определены надлежащим образом в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Определение модели управления доступом, соответствующей технологии организации и философии управления доступом, поддерживает последовательный и единообразный способ распределения доступа и снижает вероятность ошибок, таких как предоставление чрезмерных прав.
Надлежащая практика:
Фактором, который следует учитывать при определении потребностей в доступе, является принцип разделения обязанностей. Этот принцип предназначен для предотвращения мошенничества и неправильного использования или кражи ресурсов. Например, 1) разделение критически важных функций и функций поддержки информационной системы между различными лицами и/или функциями, 2) установление ролей таким образом, чтобы деятельность по поддержке информационной системы выполнялась различными функциями/лицами (например, управление системой, программирование, управление конфигурацией, обеспечение качества и тестирование, а также сетевая безопасность), и 3) обеспечение того, чтобы сотрудники службы безопасности, выполняющие функции контроля доступа, не выполняли также функции аудита.
В средах, где один человек выполняет несколько функций, таких как администрирование и операции безопасности, обязанности могут быть распределены таким образом, чтобы ни один отдельный человек не имел сквозного контроля над процессом без независимой контрольной точки. Например, ответственность за настройку и ответственность за утверждение изменений могут быть возложены на отдельных лиц.
Определения:
Ключевые элементы модели контроля доступа включают в себя:
Определение модели управления доступом, соответствующей технологии организации и философии управления доступом, поддерживает последовательный и единообразный способ распределения доступа и снижает вероятность ошибок, таких как предоставление чрезмерных прав.
Надлежащая практика:
Фактором, который следует учитывать при определении потребностей в доступе, является принцип разделения обязанностей. Этот принцип предназначен для предотвращения мошенничества и неправильного использования или кражи ресурсов. Например, 1) разделение критически важных функций и функций поддержки информационной системы между различными лицами и/или функциями, 2) установление ролей таким образом, чтобы деятельность по поддержке информационной системы выполнялась различными функциями/лицами (например, управление системой, программирование, управление конфигурацией, обеспечение качества и тестирование, а также сетевая безопасность), и 3) обеспечение того, чтобы сотрудники службы безопасности, выполняющие функции контроля доступа, не выполняли также функции аудита.
В средах, где один человек выполняет несколько функций, таких как администрирование и операции безопасности, обязанности могут быть распределены таким образом, чтобы ни один отдельный человек не имел сквозного контроля над процессом без независимой контрольной точки. Например, ответственность за настройку и ответственность за утверждение изменений могут быть возложены на отдельных лиц.
Определения:
Ключевые элементы модели контроля доступа включают в себя:
- Ресурсы, подлежащие защите (системы/устройства/данные, к которым необходим доступ),
- Рабочие функции, которым требуется доступ к ресурсу (например, системный администратор, персонал колл-центра, продавец в магазине), и
- Какие действия должна выполнять каждая функция задания (например, чтение /запись или запрос).
Как только рабочие функции, ресурсы и действия для каждой рабочей функции определены, отдельным лицам может быть предоставлен соответствующий доступ.
Примеры:
Модели управления доступом, которые могут учитывать организации, включают управление доступом на основе ролей (RBAC) и управление доступом на основе атрибутов (ABAC). Модель управления доступом, используемая данной организацией, зависит от их бизнеса и потребностей в доступе.
Примеры:
Модели управления доступом, которые могут учитывать организации, включают управление доступом на основе ролей (RBAC) и управление доступом на основе атрибутов (ABAC). Модель управления доступом, используемая данной организацией, зависит от их бизнеса и потребностей в доступе.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
УПД.5
УПД.5 Назначение минимально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функционирование информационной системы
УПД.4
УПД.4 Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы
ЗИС.1
ЗИС.1 Разделение в информационной системе функций по управлению (администрированию) информационной системой, управлению (администрированию) системой защиты информации, функций по обработке информации и иных функций информационной системы
Strategies to Mitigate Cyber Security Incidents (EN):
2.1.
Restrict administrative privileges to operating systems and applications based on user duties. Regularly revalidate the need for privileges. Don’t use privileged accounts for reading email and web browsing.
Relative Security Effectiveness: Essential | Potential User Resistance: Medium | Upfront Cost: High | Ongoing Maintenance Cost: Medium
Relative Security Effectiveness: Essential | Potential User Resistance: Medium | Upfront Cost: High | Ongoing Maintenance Cost: Medium
SWIFT Customer Security Controls Framework v2022:
1 - 1.2 Operating System Account Control
1.2 Operating System Privileged Account Control
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УПД.5
УПД.5 Назначение минимально необходимых прав и привилегий
УПД.4
УПД.4 Разделение полномочий (ролей) пользователей
ЗИС.1
ЗИС.1 Разделение функций по управлению (администрированию) информационной (автоматизированной) системой с иными функциями
NIST Cybersecurity Framework (EN):
PR.AC-1
PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes
PR.AC-4
PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties
Стандарт Банка России № РС БР ИББС-2.5-2014 от 01.06.2014 "Менеджмент инцидентов информационной безопасности":
Р. 6 п. 5 п.п. 6
6.5.6. В организации БС РФ рекомендуется реализовать процедуры контроля соответствия фактических настроек технических средств заданным в эксплуатационной документации. Не рекомендуется наличие субъектов доступа, обладающих единоличными и бесконтрольными возможностями по изменению настроек технических средств. Все действия по изменению настроек технических средств рекомендуется протоколировать и осуществлять под контролем работников службы ИБ по предварительно согласованной программе.
Доступ к информации протоколов изменений настроек технических средств осуществляется только эксплуатирующим персоналом (только чтение), администраторами ИБ и (или) работниками службы ИБ.
Доступ к информации протоколов изменений настроек технических средств осуществляется только эксплуатирующим персоналом (только чтение), администраторами ИБ и (или) работниками службы ИБ.
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УПД.5
УПД.5 Назначение минимально необходимых прав и привилегий
УПД.4
УПД.4 Разделение полномочий (ролей) пользователей
ЗИС.1
ЗИС.1 Разделение функций по управлению (администрированию) информационной (автоматизированной) системой с иными функциями
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.2
А.8.2 Privileged access rights
The allocation and use of privileged access rights shall be restricted and managed.
The allocation and use of privileged access rights shall be restricted and managed.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.