Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
315 lines
14 KiB
Markdown
315 lines
14 KiB
Markdown
# Policy Identity and Access Management
|
|
|
|
| Document information | Value |
|
|
|-----------------------|------|
|
|
| Document type | Policy |
|
|
| Scope | {{ISMS_SCOPE}} |
|
|
| Organisation | {{ORG_NAME}} |
|
|
| Responsible | {{ROLE_IT_LEAD}} |
|
|
| Approved by | {{ROLE_MANAGEMENT}} |
|
|
| Version | {{DOC_VERSION}} |
|
|
| Date | {{DOC_DATE}} |
|
|
| Status | {{DOC_STATUS}} |
|
|
|
|
|
|
## 1. Purpose
|
|
|
|
This policy governs means of identification, secure log-on, account management as well as the granting and control of access rights. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.
|
|
|
|
## 2. Scope
|
|
|
|
This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).
|
|
|
|
## 3. Requirements and implementation
|
|
|
|
> Structure per section: **Requirement** (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and **Implementation at {{ORG_NAME}}** (consolidated, to be adjusted where necessary).
|
|
|
|
### 3.1 Handling of means of identification
|
|
|
|
<!-- FW:REF-START ORIG:(ISA 4.1.1) -->
|
|
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.16{{/if}}
|
|
<!-- FW:REF-END -->
|
|
|
|
**Requirement**
|
|
|
|
<!-- FW:TISAX-REQ-START -->
|
|
{{#if FLAG_FW_TISAX}}
|
|
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
|
|
|
|
<!-- REQ 4.1.1-M1 -->
|
|
- **[MUST]** The requirements for handling means of identification throughout the entire lifecycle are determined and met; the relevant aspects are taken into account.
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.1-S1 -->
|
|
- **[SHOULD]** Means of identification can only be created under controlled conditions.
|
|
{{/if}}
|
|
{{#if FLAG_HIGH_PROTECTION}}
|
|
<!-- REQ 4.1.1-H1 -->
|
|
- **[HIGH]** A strategy for blocking or invalidating means of identification in the event of loss is prepared and, as far as possible, implemented. (C, I, A)
|
|
{{/if}}
|
|
{{/if}}
|
|
<!-- FW:TISAX-REQ-END -->
|
|
<!-- FW:ISO-REQ-START -->
|
|
{{#if FLAG_FW_ISO27001}}
|
|
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
|
|
|
|
<!-- REQ A.5.16-1 -->
|
|
- **[ISO A.5.16]** The full life cycle of identities is managed.
|
|
{{/if}}
|
|
<!-- FW:ISO-REQ-END -->
|
|
|
|
**Implementation at {{ORG_NAME}}**
|
|
|
|
<!-- IMPL 4.1.1 -->
|
|
Means of identification (user IDs, tokens, certificates) are assigned throughout the lifecycle uniquely to a person and under controlled conditions via the central directory ({{TOOL_IAM}}); issuance, withdrawal and blocking are requested, approved and documented in {{TOOL_TICKET}} (BL-IAM-07, see {{LINK:VA-03}}).
|
|
|
|
{{#if FLAG_ELEVATED_PROTECTION}}
|
|
<!-- IMPL 4.1.1-elev -->
|
|
Where the protection need is high, an implemented strategy for blocking/invalidating means of identification in the event of loss is in place.
|
|
{{/if}}
|
|
|
|
### 3.2 Secure log-on
|
|
|
|
<!-- FW:REF-START ORIG:(ISA 4.1.2) -->
|
|
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.5{{/if}}
|
|
<!-- FW:REF-END -->
|
|
|
|
**Requirement**
|
|
|
|
<!-- FW:TISAX-REQ-START -->
|
|
{{#if FLAG_FW_TISAX}}
|
|
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
|
|
|
|
<!-- REQ 4.1.2-M1 -->
|
|
- **[MUST]** The user authentication procedures are selected on the basis of a risk assessment; possible attack scenarios (e.g. direct reachability via the internet) have been taken into account.
|
|
<!-- REQ 4.1.2-M2 -->
|
|
- **[MUST]** State-of-the-art user authentication procedures are applied.
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.2-S1 -->
|
|
- **[SHOULD]** The authentication procedures are defined and implemented on the basis of business and security requirements.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.2-S2 -->
|
|
- **[SHOULD]** Users are authenticated at least by strong passwords in line with established and recognised practices.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.2-S3 -->
|
|
- **[SHOULD]** For privileged user accounts, higher-grade procedures are used (e.g. privileged access management, two-factor authentication).
|
|
{{/if}}
|
|
{{#if FLAG_HIGH_PROTECTION}}
|
|
<!-- REQ 4.1.2-H1 -->
|
|
- **[HIGH]** Depending on the risk assessment, authentication and access control are strengthened by supplementary measures (e.g. continuous access monitoring, strong authentication, automatic log-off, lock upon inactivity, brute-force prevention). (C, I, A)
|
|
{{/if}}
|
|
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
|
<!-- REQ 4.1.2-V1 -->
|
|
- **[VERY HIGH]** Before accessing data with a very high protection need, users are authenticated by means of strong authentication (e.g. two-factor) in line with the state of the art. (C, I)
|
|
{{/if}}
|
|
{{/if}}
|
|
<!-- FW:TISAX-REQ-END -->
|
|
<!-- FW:ISO-REQ-START -->
|
|
{{#if FLAG_FW_ISO27001}}
|
|
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
|
|
|
|
<!-- REQ A.8.5-1 -->
|
|
- **[ISO A.8.5]** Secure authentication technologies and procedures are used on the basis of the access restrictions and the access control policy.
|
|
{{/if}}
|
|
<!-- FW:ISO-REQ-END -->
|
|
|
|
**Implementation at {{ORG_NAME}}**
|
|
|
|
<!-- IMPL 4.1.2 -->
|
|
The authentication procedures are selected on a risk basis and correspond to the state of the art; password requirements per BL-IAM-01 (at least {{PW_MIN_LENGTH}} characters, {{PW_COMPLEXITY}}, {{PW_ROTATION}}) are enforced via the central directory ({{TOOL_IAM}}). For remote access, administrative access and cloud services, MFA (BL-IAM-02) is enforced via {{TECH_MFA}}; privileged accounts use higher-grade procedures (PAM).
|
|
|
|
{{#if FLAG_ELEVATED_PROTECTION}}
|
|
<!-- IMPL 4.1.2-elev -->
|
|
Where the protection need is high, authentication/access control are strengthened by supplementary measures (access monitoring, auto-logout BL-IAM-03, lock BL-IAM-04, brute-force protection). {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, access is only granted after strong authentication (two-factor).{{/if}}
|
|
{{/if}}
|
|
|
|
### 3.3 User accounts and log-on information
|
|
|
|
<!-- FW:REF-START ORIG:(ISA 4.1.3) -->
|
|
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 4.1.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.17{{/if}}
|
|
<!-- FW:REF-END -->
|
|
|
|
**Requirement**
|
|
|
|
<!-- FW:TISAX-REQ-START -->
|
|
{{#if FLAG_FW_TISAX}}
|
|
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
|
|
|
|
<!-- REQ 4.1.3-M1 -->
|
|
- **[MUST]** The creation, modification and deletion of user accounts is carried out.
|
|
<!-- REQ 4.1.3-M2 -->
|
|
- **[MUST]** Unique and personalised user accounts are used.
|
|
<!-- REQ 4.1.3-M3 -->
|
|
- **[MUST]** The use of shared accounts is regulated (e.g. limited to cases where traceability is dispensable).
|
|
<!-- REQ 4.1.3-M4 -->
|
|
- **[MUST]** User accounts are deactivated immediately after the user leaves (e.g. upon end of contract).
|
|
<!-- REQ 4.1.3-M5 -->
|
|
- **[MUST]** User accounts are reviewed regularly.
|
|
<!-- REQ 4.1.3-M6 -->
|
|
- **[MUST]** The log-on information is provided to the user in a secure manner.
|
|
<!-- REQ 4.1.3-M7 -->
|
|
- **[MUST]** A policy for handling log-on information is defined and implemented; the relevant aspects are taken into account.
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.3-S1 -->
|
|
- **[SHOULD]** A base account with minimal access rights and functionalities exists and is used.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.3-S2 -->
|
|
- **[SHOULD]** Default accounts and passwords preconfigured by the manufacturer are deactivated (e.g. blocking or password change).
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.3-S3 -->
|
|
- **[SHOULD]** User accounts are created or authorised by the responsible body.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.3-S4 -->
|
|
- **[SHOULD]** The creation of user accounts is subject to an approval process (four-eyes principle).
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.3-S5 -->
|
|
- **[SHOULD]** User accounts of service providers are deactivated after completion of their task.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.3-S6 -->
|
|
- **[SHOULD]** Deadlines for deactivating and deleting user accounts are defined.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.3-S7 -->
|
|
- **[SHOULD]** The use of default passwords is prevented technically.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.3-S8 -->
|
|
- **[SHOULD]** In the case of strong authentication, the use of the medium (e.g. possession factor) is secure.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.3-S9 -->
|
|
- **[SHOULD]** User accounts are reviewed regularly; this also includes accounts in customers' IT systems.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.1.3-S10 -->
|
|
- **[SHOULD]** Interactive log-on for service accounts (technical accounts) is prevented technically.
|
|
{{/if}}
|
|
{{/if}}
|
|
<!-- FW:TISAX-REQ-END -->
|
|
<!-- FW:ISO-REQ-START -->
|
|
{{#if FLAG_FW_ISO27001}}
|
|
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
|
|
|
|
<!-- REQ A.5.17-1 -->
|
|
- **[ISO A.5.17]** Allocation and management of authentication information is controlled by a suitable management process.
|
|
{{/if}}
|
|
<!-- FW:ISO-REQ-END -->
|
|
|
|
**Implementation at {{ORG_NAME}}**
|
|
|
|
<!-- IMPL 4.1.3 -->
|
|
User accounts are managed via a defined lifecycle (joiner/mover/leaver) (see {{LINK:VA-03}}) uniquely personalised in the central directory ({{TOOL_IAM}}); triggers are {{TOOL_TICKET}} requests from HR/manager notifications. Accounts of leavers are deactivated without delay, accounts are reviewed regularly (including in customer systems), shared accounts are regulated. Log-on information is provided securely; default accounts/passwords are deactivated, base accounts with minimal rights are used, creation follows the four-eyes principle, and interactive log-on for technical accounts is prevented.
|
|
|
|
### 3.4 Access rights
|
|
|
|
<!-- FW:REF-START ORIG:(ISA 4.2.1) -->
|
|
*Requirement reference:* {{#if FLAG_FW_TISAX}}VDA ISA 4.2.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.15, A.5.18, A.8.2, A.8.3, A.8.18{{/if}}
|
|
<!-- FW:REF-END -->
|
|
|
|
**Requirement**
|
|
|
|
<!-- FW:TISAX-REQ-START -->
|
|
{{#if FLAG_FW_TISAX}}
|
|
{{#if FLAG_FW_ISO27001}}*Requirements per VDA ISA 2027:*{{/if}}
|
|
|
|
<!-- REQ 4.2.1-M1 -->
|
|
- **[MUST]** The requirements for managing access rights (authorisation) are determined and met; the relevant aspects are taken into account.
|
|
<!-- REQ 4.2.1-M2 -->
|
|
- **[MUST]** The access rights granted for normal and privileged user accounts as well as technical accounts are reviewed regularly, also in customers' IT systems.
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.2.1-S1 -->
|
|
- **[SHOULD]** Strategies for authorising access to information are prepared.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.2.1-S2 -->
|
|
- **[SHOULD]** Authorisation roles are used.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.2.1-S3 -->
|
|
- **[SHOULD]** Rights are granted according to the need-to-use principle and in line with role and/or area of responsibility.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.2.1-S4 -->
|
|
- **[SHOULD]** Normal user accounts do not receive privileged access rights.
|
|
{{/if}}
|
|
{{#if FLAG_INCLUDE_SHOULD}}
|
|
<!-- REQ 4.2.1-S5 -->
|
|
- **[SHOULD]** The user's access rights are updated after a change in their responsibilities.
|
|
{{/if}}
|
|
{{#if FLAG_HIGH_PROTECTION}}
|
|
<!-- REQ 4.2.1-H1 -->
|
|
- **[HIGH]** The access rights are approved by the responsible internal information officer. (C, I, A)
|
|
{{/if}}
|
|
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
|
<!-- REQ 4.2.1-V1 -->
|
|
- **[VERY HIGH]** Information is stored encrypted at content level (e.g. file level) to prevent unauthorised access (including by privileged users). Where encryption is not feasible, equivalent measures apply. (C)
|
|
{{/if}}
|
|
{{#if FLAG_VERY_HIGH_PROTECTION}}
|
|
<!-- REQ 4.2.1-V2 -->
|
|
- **[VERY HIGH]** Existing access rights are reviewed at shorter intervals (e.g. quarterly). (C)
|
|
{{/if}}
|
|
{{/if}}
|
|
<!-- FW:TISAX-REQ-END -->
|
|
<!-- FW:ISO-REQ-START -->
|
|
{{#if FLAG_FW_ISO27001}}
|
|
{{#if FLAG_FW_TISAX}}*Requirements per ISO/IEC 27001:*{{/if}}
|
|
|
|
<!-- REQ A.5.15-1 -->
|
|
- **[ISO A.5.15]** Rules to control physical and logical access to information and assets are established and implemented on the basis of business and information security requirements.
|
|
<!-- REQ A.5.18-1 -->
|
|
- **[ISO A.5.18]** Access rights are provisioned, reviewed, modified and removed in accordance with the access control policy.
|
|
<!-- REQ A.8.2-1 -->
|
|
- **[ISO A.8.2]** The allocation and use of privileged access rights is restricted and closely managed.
|
|
<!-- REQ A.8.3-1 -->
|
|
- **[ISO A.8.3]** Access to information and application functions is restricted in accordance with the access control policy.
|
|
<!-- REQ A.8.18-1 -->
|
|
- **[ISO A.8.18]** The use of utility programs capable of overriding system and application controls is restricted and tightly controlled.
|
|
{{/if}}
|
|
<!-- FW:ISO-REQ-END -->
|
|
|
|
**Implementation at {{ORG_NAME}}**
|
|
|
|
<!-- IMPL 4.2.1 -->
|
|
Access rights are granted according to the least-privilege principle (need-to-know/least privilege) on a role basis (RBAC) via the central directory ({{TOOL_IAM}}); request, technical review and approval take place in {{TOOL_TICKET}} (see {{LINK:VA-03}}). Rights are updated or revoked upon change/removal and recertified at least {{RECERT_FREQ}} (BL-IAM-05), also in customer systems; default accounts do not receive privileged rights.
|
|
|
|
{{#if FLAG_ELEVATED_PROTECTION}}
|
|
<!-- IMPL 4.2.1-elev -->
|
|
Where the protection need is high, access rights are approved by the responsible internal information officer. {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, information is stored with content-level encryption (protection also against privileged users) and access rights are reviewed at shorter intervals (e.g. quarterly).{{/if}}
|
|
{{/if}}
|
|
|
|
## 4. Binding nature
|
|
|
|
This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_IT_LEAD}}.
|
|
|
|
## 5. Roles and responsibilities
|
|
|
|
| Role | Responsibility in this policy |
|
|
|-------|-------------------------------------|
|
|
| {{ROLE_IT_LEAD}} | Technical implementation of IAM |
|
|
| Business units | Approval of authorisations |
|
|
| {{ROLE_ISB}} | Monitoring |
|
|
|
|
## 6. Review and update
|
|
|
|
This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_IT_LEAD}} and approved by {{ROLE_MANAGEMENT}}.
|
|
|
|
## 7. Evidence
|
|
|
|
The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).
|
|
|
|
## 8. Related documents
|
|
|
|
- Associated procedures: {{LINK:VA-03}}
|
|
- Technical security baseline: {{LINK:BASELINE}}
|
|
- ISA mapping matrix: {{LINK:ISA_MAPPING}}
|
|
- Evidence register: {{LINK:NACHWEISREGISTER}}
|
|
- Further: {{LINK:R02}}, {{LINK:R05}}, {{LINK:R10}}
|
|
|
|
<!-- Anforderungen 1:1 aus VDA ISA 2027; Mapping (REQ/IMPL) in mapping.json ueber Hidden-Anker. Im Lesemodus nicht sichtbar. -->
|