Куда я попал?
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022
Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A
А.8.3
Для проведения оценки соответствия по документу войдите в систему.
Похожие требования
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 6
6.6. Кредитные организации в части нейтрализации информационных угроз со стороны внутреннего нарушителя разрабатывают и принимают организационные и технические меры в отношении субъектов доступа, привлекаемых в рамках выполнения технологических процессов, направленные на исключение возможности несанкционированного использования предоставленных указанным субъектам доступа полномочий.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
УЗП.21
УЗП.21 Реализация правил управления правами логического доступа, обеспечивающих запрет совмещения одним субъектом логического доступа следующих функций:
- эксплуатация и (или) контроль эксплуатации ресурса доступа, в том числе АС, одновременно с использованием по назначению ресурса доступа в рамках реализации бизнес-процесса финансовой организации;
- создание и (или) модернизация ресурса доступа, в том числе АС, одновременно с использованием по назначению ресурса доступа в рамках реализации бизнес-процесса финансовой организации;
- эксплуатация средств и систем защиты информации одновременно с контролем эксплуатации средств и систем защиты информации;
- управление учетными записями субъектов логического доступа одновременно с управлением правами субъектов логического доступа
3-Н 2-О 1-Т
РД.31
РД.31 Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод) при разграничении логического доступа к ресурсам доступа
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
РД.32
РД.32 Реализация ролевого метода (с определением для каждой роли прав доступа) при разграничении логического доступа в АС
3-Н 2-Н 1-Т
3-Н 2-Н 1-Т
РД.33
РД.33 Реализация необходимых типов (чтение, запись, выполнение или иной тип) и правил разграничения логического доступа к ресурсам доступа, в том числе АС
3-Т 2-Т 1-Т
3-Т 2-Т 1-Т
УЗП.9
УЗП.9 Контроль соответствия фактических прав логического доступа эталонной информации о предоставленных правах логического доступа
3-О 2-Т 1-Т
3-О 2-Т 1-Т
ЗСВ.6
ЗСВ.6 Реализация необходимых методов предоставления доступа к виртуальным машинам, обеспечивающих возможность доступа с использованием одних аутентификационных данных только к одной виртуальной машине
3-Н 2-Т 1-Н
3-Н 2-Т 1-Н
УЗП.7
УЗП.7 Предоставление прав логического доступа по решению распорядителя логического доступа (владельца ресурса доступа)
3-О 2-О 1-О
3-О 2-О 1-О
УЗП.6
УЗП.6 Назначение для всех ресурсов доступа распорядителя логического доступа (владельца ресурса доступа)
3-О 2-О 1-О
3-О 2-О 1-О
NIST Cybersecurity Framework (RU):
PR.DS-5
PR.DS-5: Реализована защита от утечки данных
PR.AC-4
PR.AC-4: При предоставлении разрешения на доступ и авторизации используется принцип наименьших привилегий и разделения обязанностей
Приказ ФСТЭК России № 21 от 18.02.2013 "Состав и содержание мер по обеспечению безопасности персональных данных, необходимых для обеспечения каждого из уровней защищенности персональных данных":
УПД.2
УПД.2 Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа
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 10.6.3
10.6.3
Defined Approach Requirements:
Time synchronization settings and data are protected as follows:
Defined Approach Requirements:
Time synchronization settings and data are protected as follows:
- Access to time data is restricted to only personnel with a business need.
- Any changes to time settings on critical systems are logged, monitored, and reviewed.
Customized Approach Objective:
System time settings cannot be modified by unauthorized personnel.
Defined Approach Testing Procedures:
System time settings cannot be modified by unauthorized personnel.
Defined Approach Testing Procedures:
- 10.6.3.a Examine system configurations and timesynchronization settings to verify that access to time data is restricted to only personnel with a business need.
- 10.6.3.b Examine system configurations and time synchronization settings and logs and observe processes to verify that any changes to time settings on critical systems are logged, monitored, and reviewed.
Purpose:
Attackers will try to change time configurations to hide their activity. Therefore, restricting the ability to change or modify time synchronization configurations or the system time to administrators will lessen the probability of an attacker successfully changing time configurations.
Attackers will try to change time configurations to hide their activity. Therefore, restricting the ability to change or modify time synchronization configurations or the system time to administrators will lessen the probability of an attacker successfully changing time configurations.
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 3.5.1.3
3.5.1.3
Defined Approach Requirements:
If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable, it is managed as follows:
Defined Approach Requirements:
If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable, it is managed as follows:
- Logical access is managed separately and independently of native operating system authentication and access control mechanisms.
- Decryption keys are not associated with user accounts.
- Authentication factors (passwords, passphrases, or cryptographic keys) that allow access to unencrypted data are stored securely
Customized Approach Objective:
Disk encryption implementations are configured to require independent authentication and logical access controls for decryption.
Applicability Notes:
Disk or partition encryption implementations must also meet all other PCI DSS encryption and keymanagement requirements.
Defined Approach Testing Procedures:
Disk encryption implementations are configured to require independent authentication and logical access controls for decryption.
Applicability Notes:
Disk or partition encryption implementations must also meet all other PCI DSS encryption and keymanagement requirements.
Defined Approach Testing Procedures:
- 3.5.1.3.a If disk-level or partition-level encryption is used to render PAN unreadable, examine the system configuration and observe the authentication process to verify that logical access is implemented in accordance with all elements specified in this requirement.
- 3.5.1.3.b Examine files containing authentication factors (passwords, passphrases, or cryptographic keys) and interview personnel to verify that authentication factors that allow access to unencrypted data are stored securely and are independent from the native operating system’s authentication and access control methods.
Purpose:
Disk-level encryption typically encrypts the entire disk or partition using the same key, with all data automatically decrypted when the system runs or when an authorized user requests it. Many diskencryption solutions intercept operating system read/write operations and perform the appropriate cryptographic transformations without any special action by the user other than supplying a password or passphrase at system start-up or at the beginning of a session. This provides no protection from a malicious individual that has already managed to gain access to a valid user account.
Good Practice:
Full disk encryption helps to protect data in the event of physical loss of a disk and therefore its use is best limited only to removable electronic media storage devices.
Disk-level encryption typically encrypts the entire disk or partition using the same key, with all data automatically decrypted when the system runs or when an authorized user requests it. Many diskencryption solutions intercept operating system read/write operations and perform the appropriate cryptographic transformations without any special action by the user other than supplying a password or passphrase at system start-up or at the beginning of a session. This provides no protection from a malicious individual that has already managed to gain access to a valid user account.
Good Practice:
Full disk encryption helps to protect data in the event of physical loss of a disk and therefore its use is best limited only to removable electronic media storage devices.
Requirement 3.4.1
3.4.1
Defined Approach Requirements:
PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.
Customized Approach Objective:
PAN displays are restricted to the minimum number of digits necessary to meet a defined business need.
Applicability Notes:
This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, legal or payment brand requirements for point-of-sale (POS) receipts.
This requirement relates to protection of PAN where it is displayed on screens, paper receipts, printouts, etc., and is not to be confused with Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted.
Defined Approach Testing Procedures:
Defined Approach Requirements:
PAN is masked when displayed (the BIN and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.
Customized Approach Objective:
PAN displays are restricted to the minimum number of digits necessary to meet a defined business need.
Applicability Notes:
This requirement does not supersede stricter requirements in place for displays of cardholder data—for example, legal or payment brand requirements for point-of-sale (POS) receipts.
This requirement relates to protection of PAN where it is displayed on screens, paper receipts, printouts, etc., and is not to be confused with Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted.
Defined Approach Testing Procedures:
- 3.4.1.a Examine documented policies and procedures for masking the display of PANs to verify:
- A list of roles that need access to more than the BIN and last four digits of the PAN (includes full PAN) is documented, together with a legitimate business need for each role to have such access.
- PAN is masked when displayed such that only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN.
- All roles not specifically authorized to see the full PAN must only see masked PANs.
- 3.4.1.b Examine system configurations to verify that full PAN is only displayed for roles with a documented business need, and that PAN is masked for all other requests.
- 3.4.1.c Examine displays of PAN (for example, on screen, on paper receipts) to verify that PANs are masked when displayed, and that only those with a legitimate business need are able to see more than the BIN and/or last four digits of the PAN.
Purpose:
The display of full PAN on computer screens, payment card receipts, paper reports, etc. can result in this data being obtained by unauthorized individuals and used fraudulently. Ensuring that the full PAN is displayed only for those with a legitimate business need minimizes the risk of unauthorized persons gaining access to PAN data.
Good Practice:
Applying access controls according to defined roles is one way to limit access to viewing full PAN to only those individuals with a defined business need.
The masking approach should always display only the number of digits needed to perform a specific business function. For example, if only the last four digits are needed to perform a business function, PAN should be masked to only show the last four digits. As another example, if a function needs to view to the bank identification number (BIN) for routing purposes, unmask only the BIN digits for that function.
Definitions:
Masking is not synonymous with truncation and these terms cannot be used interchangeably. Masking refers to the concealment of certain digits during display or printing, even when the entire PAN is stored on a system. This is different from truncation, in which the truncated digits are removed and cannot be retrieved within the system. Masked PAN could be “unmasked”, but there is no "un-truncation" without recreating the PAN from another source.
Further Information:
For more information about masking and truncation, see PCI SSC’s FAQs on these topics.
The display of full PAN on computer screens, payment card receipts, paper reports, etc. can result in this data being obtained by unauthorized individuals and used fraudulently. Ensuring that the full PAN is displayed only for those with a legitimate business need minimizes the risk of unauthorized persons gaining access to PAN data.
Good Practice:
Applying access controls according to defined roles is one way to limit access to viewing full PAN to only those individuals with a defined business need.
The masking approach should always display only the number of digits needed to perform a specific business function. For example, if only the last four digits are needed to perform a business function, PAN should be masked to only show the last four digits. As another example, if a function needs to view to the bank identification number (BIN) for routing purposes, unmask only the BIN digits for that function.
Definitions:
Masking is not synonymous with truncation and these terms cannot be used interchangeably. Masking refers to the concealment of certain digits during display or printing, even when the entire PAN is stored on a system. This is different from truncation, in which the truncated digits are removed and cannot be retrieved within the system. Masked PAN could be “unmasked”, but there is no "un-truncation" without recreating the PAN from another source.
Further Information:
For more information about masking and truncation, see PCI SSC’s FAQs on these topics.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.9.4.1
A.9.4.1 Ограничение доступа к информации
Мера обеспечения информационной безопасности: Доступ к информации и функциям прикладных систем должен быть ограничен в соответствии с политикой управления доступом
Мера обеспечения информационной безопасности: Доступ к информации и функциям прикладных систем должен быть ограничен в соответствии с политикой управления доступом
CIS Critical Security Controls v7.1 (SANS Top 20):
CSC 13.2
CSC 13.2 Remove Sensitive Data or Systems Not Regularly Accessed by Organization
Remove sensitive data or systems not regularly accessed by the organization from the network. These systems shall only be used as stand-alone systems (disconnected from the network) by the business unit needing to occasionally use the system or completely virtualized and powered off until needed.
Remove sensitive data or systems not regularly accessed by the organization from the network. These systems shall only be used as stand-alone systems (disconnected from the network) by the business unit needing to occasionally use the system or completely virtualized and powered off until needed.
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 10.6.3
10.6.3
Определенные Требования к Подходу:
Настройки и данные синхронизации времени защищены следующим образом:
Определенные Требования к Подходу:
Настройки и данные синхронизации времени защищены следующим образом:
- Доступ к данным о времени ограничен только персоналом, имеющим деловые потребности.
- Любые изменения настроек времени в критически важных системах регистрируются, отслеживаются и анализируются.
Цель Индивидуального подхода:
Настройки системного времени не могут быть изменены неавторизованным персоналом.
Определенные Процедуры Тестирования Подхода:
Настройки системного времени не могут быть изменены неавторизованным персоналом.
Определенные Процедуры Тестирования Подхода:
- 10.6.3.a Изучите системные конфигурации и настройки синхронизации времени, чтобы убедиться, что доступ к данным о времени ограничен только персоналом с бизнес-потребностями.
- 10.6.3.b Изучайте системные конфигурации и настройки синхронизации времени, а также журналы и наблюдайте за процессами, чтобы убедиться, что любые изменения настроек времени в критически важных системах регистрируются, отслеживаются и анализируются.
Цель:
Злоумышленники попытаются изменить временные настройки, чтобы скрыть свою активность. Следовательно, ограничение администраторам возможности изменять или изменять конфигурации синхронизации времени или системное время уменьшит вероятность успешного изменения злоумышленником временных конфигураций.
Злоумышленники попытаются изменить временные настройки, чтобы скрыть свою активность. Следовательно, ограничение администраторам возможности изменять или изменять конфигурации синхронизации времени или системное время уменьшит вероятность успешного изменения злоумышленником временных конфигураций.
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). Модель управления доступом, используемая данной организацией, зависит от их бизнеса и потребностей в доступе.
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 3.5.1.3
3.5.1.3
Определенные Требования к Подходу:
Если используется шифрование на уровне диска или раздела (а не шифрование базы данных на уровне файлов, столбцов или полей), чтобы сделать PAN нечитаемым, оно управляется следующим образом:
Определенные Требования к Подходу:
Если используется шифрование на уровне диска или раздела (а не шифрование базы данных на уровне файлов, столбцов или полей), чтобы сделать PAN нечитаемым, оно управляется следующим образом:
- Логический доступ управляется отдельно и независимо от собственных механизмов аутентификации и контроля доступа операционной системы.
- Ключи дешифрования не связаны с учетными записями пользователей.
- Факторы аутентификации (пароли, кодовые фразы или криптографические ключи), которые позволяют получить доступ к незашифрованным данным, хранятся надежно
Цель Индивидуального подхода:
Реализации шифрования диска настроены таким образом, чтобы для дешифрования требовалась независимая проверка подлинности и логический контроль доступа.
Примечания по применению:
Реализации шифрования диска или раздела также должны соответствовать всем другим требованиям к шифрованию PCI DSS и управлению ключами.
Определенные Процедуры Тестирования Подхода:
Реализации шифрования диска настроены таким образом, чтобы для дешифрования требовалась независимая проверка подлинности и логический контроль доступа.
Примечания по применению:
Реализации шифрования диска или раздела также должны соответствовать всем другим требованиям к шифрованию PCI DSS и управлению ключами.
Определенные Процедуры Тестирования Подхода:
- 3.5.1.3.a Если для того, чтобы сделать PAN нечитаемым, используется шифрование на уровне диска или раздела, проверьте конфигурацию системы и проследите за процессом аутентификации, чтобы убедиться, что логический доступ реализован в соответствии со всеми элементами, указанными в этом требовании.
- 3.5.1.3.b Изучите файлы, содержащие факторы аутентификации (пароли, кодовые фразы или криптографические ключи), и опросите персонал, чтобы убедиться, что факторы аутентификации, позволяющие получить доступ к незашифрованным данным, хранятся надежно и не зависят от методов аутентификации и контроля доступа собственной операционной системы.
Цель:
Шифрование на уровне диска обычно шифрует весь диск или раздел с использованием одного и того же ключа, при этом все данные автоматически расшифровываются при запуске системы или по запросу авторизованного пользователя. Многие решения для шифрования дисков перехватывают операции чтения/записи операционной системы и выполняют соответствующие криптографические преобразования без каких-либо специальных действий со стороны пользователя, кроме ввода пароля или ключевой фразы при запуске системы или в начале сеанса. Это не обеспечивает никакой защиты от злоумышленника, которому уже удалось получить доступ к действительной учетной записи пользователя.
Надлежащая практика:
Полное шифрование диска помогает защитить данные в случае физической потери диска, и поэтому его использование лучше всего ограничить только съемными электронными устройствами хранения данных.
Шифрование на уровне диска обычно шифрует весь диск или раздел с использованием одного и того же ключа, при этом все данные автоматически расшифровываются при запуске системы или по запросу авторизованного пользователя. Многие решения для шифрования дисков перехватывают операции чтения/записи операционной системы и выполняют соответствующие криптографические преобразования без каких-либо специальных действий со стороны пользователя, кроме ввода пароля или ключевой фразы при запуске системы или в начале сеанса. Это не обеспечивает никакой защиты от злоумышленника, которому уже удалось получить доступ к действительной учетной записи пользователя.
Надлежащая практика:
Полное шифрование диска помогает защитить данные в случае физической потери диска, и поэтому его использование лучше всего ограничить только съемными электронными устройствами хранения данных.
Requirement 3.4.1
3.4.1
Определенные Требования к Подходу:
При отображении PAN маскируется (ячейка и последние четыре цифры - это максимальное количество отображаемых цифр), так что только персонал с законными деловыми потребностями может видеть больше, чем ячейка и последние четыре цифры PAN.
Цель Индивидуального подхода:
PAN отображается минимальным количеством цифр, необходимым для удовлетворения определенных бизнес-потребностей.
Примечания по применению:
Это требование не отменяет более строгих требований, предъявляемых к отображению данных о держателях карт, например, юридических требований или требований к платежным маркам для чеков в точках продаж (POS).
Это требование относится к защите PAN, когда он отображается на экранах, бумажных квитанциях, распечатках и т.д., И его не следует путать с требованием 3.5.1 о защите PAN при хранении, обработке или передаче.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
При отображении PAN маскируется (ячейка и последние четыре цифры - это максимальное количество отображаемых цифр), так что только персонал с законными деловыми потребностями может видеть больше, чем ячейка и последние четыре цифры PAN.
Цель Индивидуального подхода:
PAN отображается минимальным количеством цифр, необходимым для удовлетворения определенных бизнес-потребностей.
Примечания по применению:
Это требование не отменяет более строгих требований, предъявляемых к отображению данных о держателях карт, например, юридических требований или требований к платежным маркам для чеков в точках продаж (POS).
Это требование относится к защите PAN, когда он отображается на экранах, бумажных квитанциях, распечатках и т.д., И его не следует путать с требованием 3.5.1 о защите PAN при хранении, обработке или передаче.
Определенные Процедуры Тестирования Подхода:
- 3.4.1.a Изучить документированные политики и процедуры для маскировки отображения лотков для проверки:
- Задокументирован список ролей, которым требуется доступ не только к BIN и последним четырем цифрам PAN (включая полный PAN), а также законная бизнес-потребность в том, чтобы каждая роль имела такой доступ.
- При отображении PAN маскируется таким образом, что только персонал, имеющий законную деловую потребность, может видеть больше, чем ячейку и последние четыре цифры PAN.
- Все роли, не имеющие специального разрешения на просмотр полного PAN, должны видеть только замаскированный PAN.
- 3.4.1.b Проверьте системные конфигурации, чтобы убедиться, что полный PAN отображается только для ролей с документированной бизнес-потребностью, и что PAN скрыт для всех других запросов.
- 3.4.1.c Изучите отображение PAN (например, на экране, на бумажных квитанциях), чтобы убедиться, что PAN маскируются при отображении и что только те, у кого есть законные деловые потребности, могут видеть больше, чем ячейка и / или последние четыре цифры PAN.
Цель:
Отображение полной информации на экранах компьютеров, квитанциях по платежным картам, бумажных отчетах и т.д. может привести к получению этих данных неуполномоченными лицами и их мошенническому использованию. Обеспечение того, чтобы полный PAN отображался только для тех, у кого есть законные деловые потребности, сводит к минимуму риск получения доступа к данным PAN посторонними лицами.
Надлежащая практика:
Применение элементов управления доступом в соответствии с определенными ролями - это один из способов ограничить доступ к просмотру полной панорамы только для тех пользователей, у которых есть определенные бизнес-потребности.
Подход маскирования всегда должен отображать только количество цифр, необходимое для выполнения определенной бизнес-функции. Например, если для выполнения бизнес-функции необходимы только последние четыре цифры, PAN следует замаскировать, чтобы показывать только последние четыре цифры. В качестве другого примера, если функции необходимо просмотреть идентификационный номер банка (BIN) для целей маршрутизации, снимите маску только с цифр BIN для этой функции.
Определения:
Маскировка не является синонимом усечения, и эти термины не могут использоваться взаимозаменяемо. Маскирование относится к сокрытию определенных цифр во время отображения или печати, даже если в системе хранится вся панорама целиком. Это отличается от усечения, при котором усеченные цифры удаляются и не могут быть восстановлены в системе. Замаскированный PAN может быть “разоблачен”, но нет никакого "удаления усечения" без воссоздания PAN из другого источника.
Дополнительная информация:
Для получения дополнительной информации о маскировании и усечении см. Часто задаваемые вопросы PCI SSC по этим темам.
Отображение полной информации на экранах компьютеров, квитанциях по платежным картам, бумажных отчетах и т.д. может привести к получению этих данных неуполномоченными лицами и их мошенническому использованию. Обеспечение того, чтобы полный PAN отображался только для тех, у кого есть законные деловые потребности, сводит к минимуму риск получения доступа к данным PAN посторонними лицами.
Надлежащая практика:
Применение элементов управления доступом в соответствии с определенными ролями - это один из способов ограничить доступ к просмотру полной панорамы только для тех пользователей, у которых есть определенные бизнес-потребности.
Подход маскирования всегда должен отображать только количество цифр, необходимое для выполнения определенной бизнес-функции. Например, если для выполнения бизнес-функции необходимы только последние четыре цифры, PAN следует замаскировать, чтобы показывать только последние четыре цифры. В качестве другого примера, если функции необходимо просмотреть идентификационный номер банка (BIN) для целей маршрутизации, снимите маску только с цифр BIN для этой функции.
Определения:
Маскировка не является синонимом усечения, и эти термины не могут использоваться взаимозаменяемо. Маскирование относится к сокрытию определенных цифр во время отображения или печати, даже если в системе хранится вся панорама целиком. Это отличается от усечения, при котором усеченные цифры удаляются и не могут быть восстановлены в системе. Замаскированный PAN может быть “разоблачен”, но нет никакого "удаления усечения" без воссоздания PAN из другого источника.
Дополнительная информация:
Для получения дополнительной информации о маскировании и усечении см. Часто задаваемые вопросы PCI SSC по этим темам.
Приказ ФСТЭК России № 17 от 11.02.2013 "Требования о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах":
УПД.2
УПД.2 Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.3
А.8.3 Ограничение доступа к информации
Доступ к информационным и иным связанным с ними активам должен быть ограничен в соответствии с установленной специфической тематической политикой управления доступом.
Доступ к информационным и иным связанным с ними активам должен быть ограничен в соответствии с установленной специфической тематической политикой управления доступом.
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
6.2.1.3.
Доступ к административным и сервисным УЗ строго ограничен. Для работы с системами используются отдельные персонифицированные УЗ с определенными наборами ролей и прав доступа к системам
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
УПД.2
УПД.2 Реализация политик управления доступа
УПД.0
УПД.0 Разработка политики управления доступом
NIST Cybersecurity Framework (EN):
PR.DS-5
PR.DS-5: Protections against data leaks are implemented
PR.AC-4
PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties
Приказ ФСТЭК России № 239 от 25.12.2017 "Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости":
УПД.2
УПД.2 Реализация модели управления доступом
УПД.0
УПД.0 Регламентация правил и процедур управления доступом
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
9.4.1
9.4.1 Ограничение доступа к информации
Мера обеспечения ИБ
Доступ к информации и функциям прикладных систем должен быть ограничен в соответствии с политикой управления доступом.
Руководство по применению
Ограничения доступа должны основываться на требованиях конкретных бизнес-приложений и соответствовать установленной политике управления доступом.
Для обеспечения выполнения требований по ограничению доступа следует учитывать следующее:
- a) предоставление меню для управления доступом к функциям прикладных систем;
- b) управление тем, какие данные могут быть доступны конкретному пользователю;
- c) управление правами доступа пользователей, например чтение, запись, удаление и выполнение;
- d) управление правами доступа других приложений;
- e) ограничение информации, содержащейся в выходных данных;
- f) обеспечение физических или логических мер управления доступом для изоляции чувствительных приложений, данных или систем.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.