Files
craftvia/seed/isms-vorlagenpaket-v2-en/richtlinien/R08_Identitaets-und-Zugriffsmanagement.md
T
msolarczekandClaude Opus 5 c8e6f30a27
CI / build-and-check (push) Canceled after 0s
CI / audit (push) Canceled after 0s
CI / sbom (push) Canceled after 0s
Basis: Certvia dev@a48c5fb als Fundament für Craftvia
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>
2026-09-14 11:05:39 +02:00

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. -->