Logo

TL;DR:

L'objectif de cet article est de fournir un "squelette" exhaustif de document d'architecture (DAT) pour un projet de déploiement d'un PAM CyberArk, en particulier en mode Privilege Cloud.

Ce document est issu de plusieurs projets réels déployés récemment et en représente une synthèse.

A titre indicatif, en fonction du niveau de détail développé, le DAT cible devrait faire entre 100 et 200 pages.

Concepts et outils:

Windows Server, CyberArk Privilege Cloud, Active Directory, PSM, CPM, Vault

Date: 07/2023

Mise à jour: 07/2026

Attention

1. Ce document ne décrit pas CyberArk, il décrit une manière de structurer la documentation technique d'un projet CyberArk.

2. Ce squelette de DAT pour un PAM CyberArk peut aussi être adapté à d'autres types de projets de déploiement d'un composant logiciel d'infrastructure.

3. Ce document est en français mais comme on rédige presque toujours un DAT en anglais, tous les exemples donnés ci-dessous dans les encadrés "Exemple" sont en anglais.

4. Il y a plein de façons possibles de structurer un DAT ; ce document en présente une seule, et ce n'est certainement pas la plus aboutie. Néanmoins j'espère qu'il pourra être utile.

Sommaire

1. Introduction

1.1 Noms et acronymes utilisés dans le projet
1.2 Contenu et division du document
1.3 Infos générales sur le document
1.4. Ressources projet
1.5. Contacts clés

2. Enjeux de sécurité

2.1. Modèle de sécurité
2.2. Directives générales
2.3. Contraintes de configuration
2.4. Séparation des tâches
2.5. Conformité

3. High-Level Design (HLD)

3.1. Résumé
3.2. Previous situation (facultatif)
3.3. Justification du changement (rationale for change)
3.4. Diagramme HLD
3.5. Liste des composants
3.6. Utilisateurs
3.7. Principes généraux d'architecture
3.8. Contraintes et pré-requis
3.9. Transition depuis la situation précédente
3.10. Matrice RACI
3.11. Processus de cycle de vie

4. Low-Level Design (LLD)

4.1. Architecture technique et inventaire des composants
4.2. Login accounts
4.3. Onboarded accounts
4.4. Comptes de réconciliation
4.5. Modèle de sécurité pour la délégation des permissions (Safe model)
4.6. Types de Safes
4.7. Standards pour la gestion des Safes
4.8. Contraintes de sécurité dans l'implémentation
4.9. Intégration LDAP/Active Directory
4.10. Accès administratif au PAM
4.11. Réseau
4.12. Conventions de nommage
4.13. Périodes de maintenance
4.14. Limitations
4.15. Policies
4.16. Configuration des connecteurs PSM
4.17. Load-balancing des PSM
4.18. Gestion des plateformes CPM
4.19. Configuration de Secure Tunnel
4.20. Continuité et résilience
4.21. Hardening des serveurs
4.22. Intégration ITSM
4.23. Versions déployées des composants
4.24. Gestion des exceptions

5. Document d'exploitation (DEX)
6. Document d'installation (DIN)
7. Notes

1. Introduction

Fournir une brève explication du produit.

Exemple

This document details the target architecture definition of the CyberArk Privilege Cloud PAM solution in use at <COMPANY>, in terms of design and integration into the existing environment, in particular the Microsoft Active Directory domains.

1.1 Noms et acronymes utilisés dans le projet

Donner quelques descriptions. Par exemple:

1.2 Contenu et division du document

Décrire la division du DAT en plusieurs parties:

Exemple:

High-Level Design (HLD)

The HLD provides a global overview of the architecture of the project, and identifies its main components, as well as their function and characteristics, in terms of technical design.

Low-Level Design (LLD)

The LLD provides technical configuration details of every component involved in the project. All information provided in the LLD is specific to this particular deployment instance of CyberArk. This includes configuration parameters such as IP addresses and so, as detailed in the LLD section.

Document for Exploitation (DEX)

This section provides a series of technical procedures meant to be played during the normal operating lifetime of the project.

Document for Installation (DIN)

The DIN provides an installation procedure for every component of the project and can be used by a contributor who wishes to install an instance of the project or one of its components.

1.3 Infos générales sur le document

1.3.1. Audience cible
Exemple:

Exemple: This document is intended for system administrators who will either install the product or perform its global administration or manage Safes.

1.3.2. Liens avec d'autres documents du projet

Mettre les liens vers: notes de projet, doc end-user, référentiels de configuration, documents livrés par un intégrateur, etc.

1.3.3. Liens avec d'autres documents liés hors du projet

PSSI, conventions de nommage internes; etc.

1.4. Ressources projet

1.4.1. Externe (éditeur)

Mettre les liens vers: site web de l'éditeur, portail client, docs éditeur, guide de référence de l'API REST, etc.

1.4.2. Interne

Mettre les liens vers:

1.4.3. Autres

Mettre les liens vers: documentation utile trouvée sur internet. Par exemple:

1.5. Contacts clés

Fournir les points de contact importants à l'exploitation du PAM: supports internes N1, N2, N3, contact de référence (tech lead), contacts éditeur, etc.

Le mieux étant de mettre un tableau:

Rôle Nom Email/tél
xxx xxx xxx
xxx xxx xxx

2. Enjeux de sécurité

S'agissant d'un produit destiné à l'élévation du niveau de sécurité dans l'organisation par la mise en place d'une gestion réfléchie des secrets sensibles concernant les comptes à hauts privilèges, cette section est particulièrement importante à faire figurer dans le DAT.

2.1. Modèle de sécurité

Par exemple sur un environnement Active Directory, on va parler (rapidement) du Tiering ou de l'Enterprise Access Model, mettre un petit diagramme, et fournir les liens vers la doc interne AD.

2.2. Directives générales

Rappeler des règles de sécurité importantes et mettre un lien vers la partie de la PSSI qui les énumère en ce qui concerne le contexte du PAM (l'objectif est de se prévaloir de ces règles édictées pour l'ensemble de l'organisation et qui ont valeur de contraintes obligatoires). Par exemple:

Ensuite, indiquer en quoi projet en question contribue à satisfaire ces règles.

Exemple:

A PAM (Privileged Access Management) solution provides process and tools for exerting control over the privileged session access on servers (or services) for users. It covers the following areas:

• Controlling and tracking privileged sessions access.
• Managing account credentials (passwords safe functionality with automatic password changes that meet complexity requirements).
• Monitoring and recording of privileged sessions access.
• Provide an additional level of control over privileged sessions access with the help of analysis tools to proactively identify and automatically block suspicious activities.
• Includes a bastion host for accessing privileged sessions.

Properly configuring and using a PAM should help enforce the principle of least privilege, adopt a security-centric rights delegation model, and condense the organization's attack surface.

2.2.1 Terminologie

Expliciter les éléments de langage utilisés dans le document.

Exemple:

Onboarded accounts can be of several types:

• Local administrative accounts: provide privileged access to a single server.
• Domain administrative accounts: provide an AD domain-wide privileged access to servers and workstations.
• Break glass (or emergency or firecall): account that provides administrative access in case of an emergency.
• Service account: local or domain account with privileges at the application level.
• Domain service accounts: enable specialized tasks such as password changes or password resets to accounts.
• Application accounts: used by applications to access databases, run batch jobs or scripts, or provide access to other applications.

2.2.2 Règles de sécurité

En plus des règles générales évoquées plus haut, on va parler ici des règles de sécurité

Exemple:

• Isolation of desktop accounts from privileged accounts:
  ◦ Desktop accounts should not be allowed to access any elevated privilege.
  ◦ Desktop accounts should only be allowed to make use of non-privileged RDP-login-enabled accounts.
• A dedicated type of user account (using a dedicated account prefix) should be used to access the user interface of the PAM.
• Access to the PAM user interface should require a two-factor authentication.
• In case the central user interface for the PAM is not located on-prem but is available online, access to this interface should be restricted to the corporate IP addresses.

The following objects shall be considered as privileged accounts:
• Accounts that are member of built-in (predefined) AD groups such as domain admins, enterprise admins, operator accounts, etc.
• Accounts that are member of the local Administrators local on servers and workstations.
• Accounts having at least one sensible privilege on servers or workstations.
• Accounts having a delegation on the administration of a part of the Active Directory.
• Accounts that are owners of an object (of type User, Group, Computer, GPO, etc.).
• Accounts that are approved for delegating administration.
• Cross-domains trust accounts.

2.2.3. Gestion du cycle de vie des comptes

Décrire succinctement la gestion du cycle de vie des comptes, spécifiquement dans le cadre de l'implémentation du PAM.

Exemple:

A workflow process should exist in the company for managing the lifecycle of user accounts. It must be fully documented, enforced and audited, especially on the following points: creation of accounts (enrolment, activation), maintenance of accounts (regular use, password resets for various cases, regular review/audit, eventual updates in terms of privileges), and deactivation of accounts (expiration, archival, deletion).

Particular cases must also be taken into consideration: user leaving the company for a determined or undetermined time period, user moving into another subsidiary/branch/site of the company, etc.

Account and group objects must make appropriate and consistent use of the optional AD attributes in order to provide all needed information. A detailed use of optional AD attributes for the target configuration is provided in the Naming Convention section.

Moreover, users must be aware that they are responsible for their password. It is recommended that they receive and sign a document detailing their responsibilities in terms of password when an account is assigned to them.

2.2.4. Revue des comptes

Décrire le nécessaire processus périodique de revue des comptes.

Exemple:

A process must be implemented for a regular review of accounts. A periodic re-evaluation of user roles, access rights and privileges must be performed. The goal is to re-ensure periodically the least required privilege principle for all users, in order to reduce the risk of a security breach by limiting access to critical data and resources.

Special attention must be paid to employees who have worked in the organization for a long time and/or who have moved from a service to another within the organization. These accounts are the most likely to have excessive access privileges or commit mistakes or abuse with elevated privileges (privilege creep situation).

Reviewing accounts periodically is a requirement of security regulations such as ISO 27001.

Accounts into deprovisioning process can represent security deviances and should thus be reviewed as well. Specific additional instructions for reviewing these accounts are provided below (Monitoring deprovisioning process).

2.3. Contraintes de configuration

2.3.1. Contraintes générales
Exemple:

The following security issues are to be addressed, resulting in a specific configuration of the CyberArk infrastructure:

• A desktop account must not be used to access all kinds of privileges.
• A desktop account must not be used to access either Tier 0 privileges or CyberArk administration rights. Instead, ADM accounts must be used for this purpose.
• Single Sign-On (SSO) must be disabled for accessing the CyberArk Password Vault Web Access (PVWA) portal. In order to avoid that login accounts be directly logged onto the CyberArk PVWA without having to enter their password and/or validate their MFA.
• Action must be taken in order to restrict the valid locations from which it is possible to login to the PVWA (when it is reachable in Privilege Cloud mode). By default, the Privilege Cloud URL is reachable from any IP address/location. When using Azure AD accounts to open a session onto the PVWA, additional rules for conditional access can be set to enforce the origination of access to be in a whitelist of acceptable locations.
• Reconciliation accounts must only have rights over a perimeter that doesn’t exceed their field of action. In this purpose, onboarded accounts must be placed into one or more dedicated Organizational Units (OU) so that reconciliation accounts only have password reset rights over objects in these OUs.
• All logs from CyberArk must be uploaded in a logging facility.

2.3.2. Gestion du cycle de vie des comptes (IAM)
Exemple:

The accounts lifecycle management process is already outlined in a section above. To supplement this information, the following security recommendations should be considered:

• Define and apply a lifecycle management process for accounts and groups in the AD.
• Create one or more Organizational Unit(s) (OU) for holding deprovisioned accounts.
• Accounts that have entered the progress of deprovisioning should be deactivated.
• The naming convention for accounts and groups should take into account the deprovisioning process. For instance, some attribute (usually the CN or Description) should be formatted to indicate that the object is under deprovisioning.
• Use templates for creating user accounts, in order to ensure that all users in a same team have the adequate same permissions and group membership.

2.4. Séparation des tâches

Faire figurer dans cette section une matrice de séparation des tâches (SoD): pour éviter qu'un même profil cumule création de compte + validation + accès.

2.5. Conformité

Expliciter dans cette partie:

La politique de rétention des enregistrements de session: durée légale/contractuelle, stockage (Vault vs SIEM vs archivage froid), qui peut y accéder.

La classification des données/RGPD: si des sessions enregistrées ou logs contiennent des données personnelles.

le threat model/analyse de risques: scénarios de compromission envisagés (compromission du Vault, insider threat) et mesures compensatoires.

3. High-Level Design (HLD)

3.1. Résumé

Exemple:

The CyberArk PAM has two main functions:

1. Managing secrets that focus on privileged users credentials. This is done through the Safes components.

2. Providing a secure Bastion Hosts functionality with additional features such as connection constraints (specific timeslots for logging in, individual workflows for connection approval, etc.) and the logging of all session events through the recording and archiving of all sessions.

3.2. Previous situation (facultatif)

Décrire les enjeux et les objectifs (surtout si le déploiement de CyberArk vient remplacer un projet précédent)

On peut ajouter des sous-sections 3.2.x pour décrire la situation précédente que le projet vient solutionner en termes de (exemples):

3.3. Justification du changement (rationale for change)

Cette section explique les buts (= directives générales de ce qui doit être réalisé/atteint) et les objectifs (stratégies pour les étapes d'implémentation permettant d'atteindre les buts) du projet.

3.3.1. Buts
Exemple:

The general guidelines of what needs to be achieved are the following:

• Put in place a forced segregation of duties with different accounts for users making use of different levels of privileges.
• Ensure that only Domain Admins can populate security groups dedicated to CyberArk.
• Secure access to the CyberArk PAM portal.
• Make use of reconcile accounts with restricted permissions so that they can only change passwords of accounts onboarded into CyberArk.

3.3.2. Objectifs
Exemple:

The strategies for implementation steps to attain the goals are defined as follows:

• Three new types of Active Directory accounts will be defined in order to provide access to the CyberArk PAM in accordance with the segregation model: standard users, domain admins, CyberArk admins.
• All Active Directory security groups used to access the CyberArk PAM will be created in the CONTOSO.LOCAL domain within a Tier 0 restricted Organizational Unit, so that only Tier 0 Domain Administrators will be able to populate them.
• All Active Directory user accounts created to access the CyberArk PAM will be placed into a restricted OU as well.
• User accounts used to access the CyberArk PAM will be provisioned into Azure AD and configured with the following parameters:
  ◦ Conditional access rules (to ensure access is only made from authorized locations),
  ◦ MFA authentication,
  ◦ and a session timeout of 30 minutes.

Securing access will be done by using only Azure-provisioned accounts to log in to the PAM (along with conditional access rules) in order to benefit from a MFA functionality for these accounts when connecting to the PAM, and also prevent the possibility of connecting to the PAM from locations considered as non-secure (ie all locations except those of the company).

• Grant reconcile account with just the necessary privileges to perform a password reset over a single Organizational Unit containing all TA accounts. Do not perform password reconciliation over other types of accounts.
• The overall action plan that will be described with more details later in the document in the Low-Level Design section to perform tasks to secure credentials managed by CyberArk.

3.3.3. Parties prenantes (stakeholders)

Définir les équipes qui vont utiliser le PAM et leurs rôles. Par exemple:

3.3.4. Changement apportés par le projet
3.3.5. Accord d'utilisation des hauts privilèges (Sensitive privileges use agreement)

Dire qu'on va mettre en place une charte et fournir le lien vers cette charte à signer pour les destinataires de comptes à hauts privilèges

Exemple complet de charte:

Privileged Access Agreement

Privileged access enables an individual to take actions that may affect computing systems, network communication, or the accounts, files, data, or processes of other users. Privileged access is typically granted to system administrators, network administrators, staff performing computing account administration or other such employees whose job duties require special privileges over a computing system or network.

Individuals with privileged access must respect the rights of the system users, respect the integrity of the systems and related physical resources, and comply with any relevant laws or regulations. Individuals also have an obligation to keep themselves informed regarding any procedures, business practices, and operational guidelines pertaining to the activities of their local department.

In particular, the principle of privacy of information holds important implications for computer system administration at <COMPANY>. Individuals with privileged access must comply with applicable policies, laws, regulations, precedents, and procedures while pursuing appropriate actions required to provide high-quality, timely, reliable computing services. For example, individuals must comply with provisions of the <COMPANY> Cybersecurity Framework mandating the least perusal of contents and the least action necessary to resolve a situation.

[ mettre ici le lien vers la PSSI de l'organisation ]

GENERAL PROVISIONS

Privileged access is granted only to authorized individuals. Privileged access shall be granted to individuals only after they have read and signed this Agreement.

Privileged access may be used only to perform assigned job duties.

If methods other than using privileged access will accomplish an action, those other methods must be used unless the burden of time or other resources required clearly justifies using privileged access.

Privileged access may be used to perform duties only on machines and networks whose responsibility is part of assigned job duties.

Privileged access may be used to grant, change, or deny resources, access, or privilege to another individual only for authorized account management activities or under exceptional circumstances. Such actions must follow any existing organizational guidelines and procedures.

In all cases, access to other individuals' electronic information shall be limited to the least perusal of contents and the least action necessary to resolve a situation.

Individuals with privileged access shall take necessary precautions to protect the confidentiality of information encountered in the performance of their duties.

If, during the performance of their duties, individuals with privileged access inadvertently see information indicating serious misuse, they are advised to consult with their supervisor. If the situation is an emergency, intervening action may be appropriate.

SEGREGATION OF DUTIES – TIERING

A strict separation must be observed between servers and workstations, as specified by the Enterprise access model in effect. As such, administrative accounts used to perform tasks on servers (referred to as Tier 1) must be distinct from administrative accounts used on workstations (referred to as Tier 2).

Active Directory Domain Controllers, because of their role, represent a specific set of servers referred to as Tier 0. Tier 0 has the highest level of criticality, as its compromission could have an impact on the whole IT infrastructure.

Administrators working on multiple Tiers are provided multiple distinct administration accounts.

Having the same password for several accounts is prohibited. Each account must have a different password.

Administration accounts must be dedicated to either Tier 2 or Tier 1 or Tier 0. Using an account provisioned for a given Tier onto another Tier is prohibited.

In particular, when an administration account is used to perform RDP connections on servers, it is forbidden to use this account on any workstation.

PASSWORD MANAGEMENT

Storing passwords in a browser (eg. Chrome, Firefox, Edge, etc.) is prohibited.

Storing passwords in a session management software for RDP or SSH or other (mRemoteNG, Remote Desktop Manager, MobaXterm, etc.) is prohibited.

The only acceptable way of storing passwords is to use one of the corporate solutions:

• Keepass software (install from the Enterprise portal), or
• 1password web utility (request access by writing to <emailaddress@company.com>).

Passwords that are managed in a PAM (namely Cyberark) can only be changed by the latter. Requesting a password reset of such objects is prohibited.

AGREEMENT

I have read this Privileged Access Agreement and the <COMPANY> Security Framework computer use policy and I agree to comply with them.

Privileged Access Recipient name, date, department, and signature:

_____________________________________________________________________________

Administration account(s) concerned + System(s) or resource(s) approved for privileged access:

_____________________________________________________________________________

Authorizer name, date, department, and signature:

_____________________________________________________________________________

Important

Faire en sorte que la charte tienne sur une page (ou 2 max).

3.3.6. Evolutions futures (facultatif)

Décrire ici les évolutions attendues du point de vue de l'architecture de la solution dans le futur. Par exemple:

Note

Ouvrir le contexte sur les futures améliorations possibles, ou best-practices qu'on souhaiterait implémenter dans une prochaine évolution de la plate-forme, qui ne seraient pas possible pour le moment.

3.4. Diagramme HLD

Fournir ici des diagrammes originaux représentant les composants déployés dans le cadre du projet et le principe de fonctionnement du PAM.

Note

Ces diagrammes doivent être spécifiques à l'environnement réel, sinon ça ne sert à rien (des diagrammes sont disponibles dans les docs officielles, autant les recopier). Donc on fera figurer des noms de sites, de pays/régions, des noms de domaines AD, etc.

Voici des exemples de diagrammes plus ou moins corrects générés avec ChatGPT en un prompt (juste pour donnée une idée générale):

HLD global. Exemple:

(image générée par IA)

Diagramme représentant une phase de connexion: récupération d'un fichier rdp sur le pvwa puis lancement de la connexion vers bastion vers target. Exemple:

(image générée par IA)

Autre exemple plus succinct:

(image générée par IA)

3.5. Liste des composants

Inventorier ici l'ensemble des composants déployés dans le cadre du projet:

Exemple:

• PSM

The Privileged Session Manager is the bastion host, strictly speaking, that CyberArk uses to connect users to RDP or SSH target sessions while also monitoring and recording them. This component must be installed in a machine within the network, not necessarily dedicated to this usage.

• CPM

The Central Policy Manager is the component that performs password changes. This component must be installed in a machine within the network, not necessarily dedicated to this usage.

• PVWA

The Password Vault Web Access is the web interface of the CyberArk PAM, reachable at the following URL: https://tenantaddress.privilegecloud.cyberark.com/

• Vault

The Vault is the software component and data structure that stores all secrets (privileged credentials) entrusted to CyberArk. In Privilege Cloud mode as for the current deployment, the Vault runs in a public cloud service operated by the editor.

• Safes

Secrets (privileged credentials) are stored into Safes. One or more Safes are stored within the Vault. Using multiple Safes enables administrators to separate credentials for access by different users and groups as defined in the Safe permissions.

3.5.1. Objets gérés

Décrire les types d'objets gérés par le PAM et leur rôle:

3.6. Utilisateurs

Dépend des types de comptes gérés dans l'organisation.

Faire un tableau qui indique tous les types de comptes qui seront gérés par le PAM:

Account type Tier Support level Description Nominative RDP use
Desktop 2 - desktop account
(use: office, messaging)		 Yes No
ADM 0,1,2 L1,L2,L3 administration account Yes Yes
OP 1 L1,L2 operator account No Yes
OP 2 L1,L2 operator account No No
DA 0 L3 domain admin
(Active Directory)		 Yes Yes
SA 0,1,2 - service account No No

...Etc. à adapter à chaque contexte.

3.7. Principes généraux d'architecture

Décrire et distinguer les deux types de comptes du point de vue du PAM:

Exemple de petit schéma illustrant les deux types de comptes

3.8. Contraintes et pré-requis

3.8.1. Environnements

Ici on va décrire le besoin pour différents types d'environnements de PAM et lesquels sont destinés à être déployés:

3.8.2. SLAs cible

Définir ici les SLA cibles pour l'infrastructure déployée.

Exemple pour Privilege Cloud:

CyberArk Privilege Cloud is committed to a 99.9% SLA. In case of an unavailability of the CyberArk PAM service, users who legitimately need to use onboarded credentials will need to make use of alternate credentials. Typically, the Domain Administrators own an “ice-breaking” emergency account that is stored in a secure place outside of CyberArk and can be used outside of CyberArk. The activation and use of the emergency account must be strictly audited so that alerts are generated every single time it is used.

A Domain Administrator making use of an emergency account with Domain Admin privileges is then able to create additional accounts for other users until the situation is solved.

3.8.3. Performance cible
3.8.3.1. Composants PSM

Parler ici du dimensionnement des PSM en fonction de l'utilisation cible de l'infrastructure déployée.

Exemple:

Regular users of the CyberArk PAM expect their sessions to behave with the same responsiveness as their direct non-PAM counterpart. CyberArk uses PSM (Privileged Session Manager) components to accommodate RDP and SSH connections and sessions along with monitoring and recording features.

Requirements for the PSM in terms of computing resources in order to ensure a proper level of performance are provided in the following document: Recommended Server Specifications.

The choice of implementation (small, mid-range, large) depends on the number of concurrent sessions:

Tableau:
Type CPU RAM Storage
Small implementation
(1 to 10 concurrent RDP/SSH sessions)		 8 CPU/vCPU cores 8 GB RAM 80 GB storage
Mid-range implementation
(11 to 50 concurrent RDP/SSH sessions)		 16 CPU/vCPU cores 16 GB RAM 80 GB storage
Large implementation
(50 to 100 concurrent RDP/SSH sessions)		 32 CPU/vCPU cores 32 GB RAM 250 GB storage

Notes

• The concurrency of 100 sessions per PSM server must not be exceeded.
• The concurrent session’s ranges assume PSM is running on a dedicated server.
• The concurrent session’s ranges are based on performance measurements while video recording user’s activities in HD resolution (one screen). Video recording resolution is affected by the desktop resolution of the client machine from which the connection was made (performing connections from client machines with more than one HD screen, or with a higher resolution screen, will result in lower concurrency).
• Installing the PSM server on a virtual machine requires allocating virtual hardware resources that are equivalent to the physical hardware specifications.
• The maximum concurrency is up to 40% less when installing the PSM server on a virtual machine.
• For additionals details regarding the installation of PSM on a VM, refer to Recommended settings for installing PSM on a virtual machine.

Other System Prerequisites:

• Windows 2019, Windows 2016 Standard
• For Windows 2016, verify that Windows update KB4458842 is installed
• .NET Framework 4.8
• Microsoft Remote Desktop Services (RDS) Session Host
• Microsoft Remote Desktop Services Gateway (optional)
• PSM can be installed on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platforms

3.8.3.2. Composants CPM

Décrire ici le dimensionnement des CPM en fonction de l'utilisation cible de l'infrastructure déployée.

Exemple:

Similar requirements for the CPM component in terms of computing resources in order to ensure a proper level of performance are provided in the Recommended Server Specifications document.

Type CPU RAM Storage
Small implementation
(<1,000 managed passwords)		 4 CPU/vCPU cores 8 GB RAM 80 GB storage
Mid-range implementation
 8 CPU/vCPU cores 16 GB RAM 80 GB storage
Large implementation
(20,000 to 100,000 managed passwords)		 16 CPU/vCPU cores 32 GB RAM 80 GB storage
Very large implementation
(more than 100,000 managed passwords)		 32 CPU/vCPU cores 64 GB RAM 80 GB storage

Other System Prerequisites:

• Windows 2019, Windows 2016
• .NET Framework 4.8
• CPM can be installed on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platforms

3.8.3.3. Autres composants
Exemple pour Privilege Cloud:

Sizing and performance matters for other CyberArk components are not covered here as the deployment in question in this document is a Privilege Cloud setup. All information from the editor about sizing of components is available in the Recommended Server Specifications document.

3.8.4. Croissance anticipée et besoins de stockage
Exemple:

The PSM component needs to have enough storage space available in order to store session recordings. The storage space use for session recordings typically uses between 50 and 250 KB per minute and is affected by the type of session (GUI or CLI), the screen resolution (when in GUI) and especially the user activity.

Average high to take into account:

Session type Storage consumption
RDP 250 KB/minute
SSH 100 KB/minute

A guide for planning storage capacity of PSM servers is available in the Considerations for installing PSM document.

3.8.5. Standards pertinents
3.8.5.1. Niveaux de support

Description des niveaux de support dans l'organisation (L1, L2, L3, ... et leurs rôles).

3.8.5.2. Environnements

Description des environnements courants dans l'organisation (test, dev, acceptance, prod, ...).

3.9. Transition depuis la situation précédente

Cette section va servir à décrire la transition organisée depuis la situation précédent le déploiement du PAM CyberArk. Ne pas oublier notamment:

Plan de migration si remplacement d'un PAM existant: stratégie de coexistence, ordre de bascule par périmètre.

Plan de tests (UAT): scénarios de recette fonctionnelle avant mise en prod.

Modèle de support post-go-live: SLA, niveaux de support (N1/N2/N3), astreinte ?

3.9.1. Phase pilote et fonctionnement parallèle (parallel run)
Exemple à adapter selon contexte:

The transition to the new operation mode is planned to happen with login accounts and groups existing in both the FOO.LAB and BAR.LAB legacy domains and the target CONTOSO.LOCAL domain.

• The creation of target groups in the CONTOSO.LOCAL domain is done in a first step.
• The creation of CyberArk portal user accounts in the CONTOSO.LOCAL domain is then performed for users who will be CyberArk administrators.
• The parallel run starts when user accounts are being progressively transferred from the FOO.LAB and BAR.LAB domains to the target CONTOSO.LOCAL domain. Safes are updated for their membership:
  ◦ For nominatives Safes, this change can be performed quickly, as there is only one user to warn.
  ◦ For shared Safes, this change will be done progressively by warning and migrating all members.
• Safes that were created by an owner who did not grant the CyberArk Administrators group with full permissions will be re-created with proper permissions.
  ◦ Moving accounts between Safes: [link].

3.9.2. AD security groups inventory

Fournir par exemple ici des données provenant d'un audit des comptes et groupes à hauts privilèges, leur catégorisation, etc.

3.10. Matrice RACI

Over important

Ne pas négliger cette partie pour éviter un certain nombre de problèmes !

Je conseille fortement de mettre d'abord un mot sur la signification de R,A,C,I pour être clair car il y a souvent des confusions entre le français et l'anglais.

Par exemple:

RACI stands for Responsible, Accountable, Consulted, Informed. When transcripted into French these terms are sometimes referred to as Responsable, Acteur, Consulté, Informé which reverts the roles between the R and the A. To keep the RACI matrix consistent across English and French languages, the following terms are being used thereafter:

Letter EN FR
R Responsible Réalisateur
A Accountable Autorité responsable
C Consulted Consulté
I Informed Informé
3.10.1 Liste des tâches

Détailler ici les tâches unitaires ou récurrentes liées au cycle de vie de l'infrastructure en question. Par exemple:

3.10.2. Matrice cible
Exemple de base de matrice RACI

Cet exemple partiel dépend largement de chaque organisation et est à adapter et compléter à chaque cas spécifique !

CyberArk admin Security Team Windows AD (T0) Team HelpDesk/WKS Team Manager RDP Users (T1) UNIX Team (T1) Other Team (T1)
Governance
Project phase
Define the safe model A,R C,I R,C I
Define naming convention for safes A,R C,I R,C I
Define constraints for PVWA login accounts A,R C,I R,C I
Define naming convention for PVWA login accounts R,C C,I A,R I
Define constraints for onboarded accounts (RDP or so) A,R C,I R,C I
Define naming convention for onboarded accounts (RDP or so) R,C C,I A,R I
Production phase periodic action
Review policies and delegation model. Ensure admins understand importance of role R,C A C I
Review and rationalize credentials. Reduce number of privileged credentials to the strict required minimum. Remove dormant/unused credentials R,C A R,C I
Review and rationalize identities. Remove dormant/unused identities R,C A R,C C,I
CyberArk Deployment
Infrastructure Deployment
Deploy infrastructure A,R C,I R,C I
Implement the safe model based on the above A,R C,I I I
Application deployment A,R C,I R,I I
Functional Testing A,R C,I R,C,I I
Platform Deployment
AD DS Admins R A R,C I
Windows Server local Admins R A R,C I
UNIX/Linux root R A R,C I C,I
Other R A R,C I C,I
Current Operations
Account Management Activities
Validate request to create login accounts into Active Directory for new CyberArk users C A,R I I I
Create new (unprivileged) login accounts for new CyberArk users I I I R A
Validate request to create new privileged accounts into Active Directory I R A,C
Create new privileged accounts into Active Directory I I A,I R
Add privileged accounts into AD security groups providing privileges over target systems I A,C R
Validate request to onboard account into CyberArk I A,R I C,I I I I
Validate request for Safe access I A,R I C,I I I I
Scope and review user requests A,R C C I I I
Onboard Accounts into CyberArk (PAM task) A,R I C,I I I I
Onboard AD Accounts into CyberArk (Active Directory task) C,I I A,R
Onboard UNIX/Linux local accounts into CyberArk (sysadmin task) C,I I A,R
Onboard Other local accounts into CyberArk (sysadmin task) C,I I A,R
Provision Safe Access for Privileged Users A,R I C I I I I
Manual Password Resets A,R I C I I I
Troubleshoot Password Change Issues A,R I R,C C,I C,I C,I
Troubleshoot PSM Connections Issues A,R I R,C I I I
Operational Support Activities
Create internal documentation A,R R,C,I C,I I I I I
Security Activities
Perform Security Assessments R,C A,R I I
Perform Pen Tests R,C A,R C,I I
Remediate Security Issues R,C A,R R,C I

3.11. Processus de cycle de vie

Patch management/montées de versions

Décrire la cadence des upgrades CyberArk et la procédure de test dans les grandes lignes (préprod puis prod).

Gestion du changement

Décrire le processus de gestion du changement (change management): qui valide une modification de policy, de Safe, ou d'architecture après le go-live.

4. Low-Level Design (LLD)

Note

Si on veut livrer un document de bonne qualité, c'est la partie à laquelle il faut apporter le plus grand soin, sans oublier qu'il s'agit de la partie la plus "vivante", qui devra être mise à jour au fur et à mesure de l'évolution de l'infrastructure.

4.1. Architecture technique et inventaire des composants

4.1.1. Bastions

Produire un tableau listant les PSM configurés:

Server Identifier Domain IP Address Roles Location System account
PSM3 1ab234d contoso.lab 192.168.168.123 PSM+CPM Paris datacenter _SA_PSM3
... ... ... ... ... ... ...

Joindre un petit diagramme LLD montrant l'ensemble des PSM et leur répartition dans les DC/clouds si nécessaire.

4.1.2. Serveurs d'administration

Produire un tableau listant les principaux serveurs de rebond existants "connus" utilisés par les équipes d'admins. Exemple:

Server IP Address Description
toto7.contoso.lab 192.168.168.124 admin server for VMware team
... ... ...
4.1.3. Logging

Donner ici les informations sur l'intégration du PAM avec le puits de log d'entreprise.

Exemple:

CyberArk shall be integrated with Splunk SIEM in order to centralize all logs, including user and Safe activities. Sending of CyberArk logs to the SIEM must make use of a securely encrypted protocol using TLS. The general parameters for configuring event forwarding are the following:

Parameter Value
SIEM server name ...
Type (internal/external) ...
TCP port ...
Transport (TLS) ...
Event format ...
Facility ...
Syslog filter codes ...
Private key identifier ...
Certificate ...

Fournir le lien vers la doc interne d'intégration SIEM.

4.1.3.1 Détail du logging

Fournir ici une checklist assez détaillée: quels indicateurs sont remontés au SIEM/SOC (health checks Vault, échecs CPM, sessions PSM), outils utilisés (PTA, syslog, SNMP).

4.2. Login accounts

Décrire les différents types de comptes qui peuvent être utilisés pour se connecter au portail CyberArk PAM. Cela est fait conjointement et en cohérence avec la documentation de l'équipe AD qui décrit les standards, notamment le modèle de ségrégation et les types de comptes.

Chaque type de compte a ses normes qu'il convient de synthétiser ici: nommage/préfixe, niveau de Tier, placement OU, utilisation cible, etc.

Il peut y avoir par exemple:

4.2.1. Comptes de connexion permettant d'accéder à des crédentials de Tier 1

4.2.2. Comptes de connexion permettant d'accéder à des crédentials de Tier 0

4.2.3. Comptes de connexion au portail ne permettant d'accéder à aucun crédential mais donnant des privilèges d'administration du portail lui-même (admins CyberArk)

4.3. Onboarded accounts

Là on parle des types de comptes qui sont onboardés dans CyberArk, donc les secrets protégés dans des Safes.

Encore une fois on rappelle le rôle de chaque type de compte et les normes internes qui lui sont associées.

Il peut y avoir par exemple:

4.3.1. Comptes d'administration

4.3.2. Comptes d'administration de domaine (Domain Admins)

4.3.3. Comptes opérateurs

4.3.4. Comptes de service

4.4. Comptes de réconciliation

Ce sont les types de comptes spéciaux utilisés par CyberArk pour forcer le reset des mots de passes lors d'une désynchronisation entre le mot de passe stocké dans le PAM et le mot de passe réel du compte.

Il y a plusieurs approches concernant ces types de comptes de service, qui ne sont pas obligatoires.

On peut considérer que par commodité les comptes de réconciliation permettent de diminuer les tickets d'incidents au support.

D'un autre coté on peut considérer que c'est une surface d'attaque supplémentaire, que les utilisateurs n'ont qu'à mieux gérer leurs comptes à privilèges et que cette situation est exceptionnelle. Il n'y a pas de bonne façon universelle d'appréhender la question, tout dépend de l'environnement spécifique auquel le déploiement du PAM en question se destine.

Détailler dans cette section la stratégie adoptée quant à l'utilisation des comptes de réconciliation.

4.5. Modèle de sécurité pour la délégation des permissions (Safe model)

C'est la partie la plus structurante de la manière d'utiliser un PAM ; une description détaillée du modèle de sécurité mis en oeuvre doit figurer dans le dossier d'architecture.

Quelques modèles couramment utilisés

*Le modèle "Role-Based" organise les Safes en fonction des équipes ou des rôles métier. Chaque Safe contient les comptes nécessaires à une équipe donnée (administrateurs, SOC, développeurs, etc.) et les accès sont accordés via des groupes d'administration. Cette approche est souple et s'adapte facilement aux besoins des métiers, mais peut entraîner la duplication de comptes ou la création de Safes partagés lorsqu'un même identifiant est utilisé par plusieurs équipes.

*Le modèle "Rule-Based" organise quant à lui les Safes selon des critères techniques, tels que la plateforme, la technologie ou le type de compte (administrateurs Windows, comptes root Linux, comptes Oracle, etc.). Plus rigide, il offre en contrepartie une organisation homogène, facilite l'automatisation des opérations d'administration et convient particulièrement aux comptes standardisés.

Quel que soit le modèle retenu, il est essentiel de définir une convention de nommage claire, concise et cohérente (The three C's - Clear, Concise, Consistent). Les noms des Safes doivent suivre une structure identique, composée de champs décrivant par exemple l'environnement, le type de compte, la plateforme ou la technologie. Une nomenclature homogène facilite les recherches, la maintenance et l'exploitation de la plateforme.

Enfin, les autorisations doivent être gérées exclusivement au travers de rôles et de groupes, en évitant autant que possible les permissions attribuées directement aux utilisateurs. Cette approche simplifie l'administration, améliore la lisibilité du modèle de sécurité et facilite les évolutions de l'organisation.

*Dans la pratique, de nombreux déploiements adoptent une approche "hybride" : les comptes techniques génériques sont organisés selon un modèle Rule-Based, tandis que les comptes spécifiques à une application ou à une équipe sont regroupés dans des Safes Role-Based. Cette combinaison permet de concilier simplicité d'administration et flexibilité.

Exemple tiré de la doc officielle CyberArk

Rappeler les best practices.

Rappeler le fait que le nommage des Safes doit permettre d'identifier leur type de contenu et leurs groupes owners.

4.6. Types de Safes

Décrire ici quels sont les types de Safes qui sont implémentés dans le déploiement en question. Par exemple:

4.6.1. Safes personnels
Exemple:

Personal Safes can have only one single member to whom they belong personally. The member is a single domain user account (not a group).

4.6.2. Safes partagés
Exemple:

• Shared Safes (or Application Safes) are created for a shared access to a common resource.
• Shared safes can have several members. This is managed by using AD domain security groups only.
  ◦ For clarity, the permissions management over Shared Safes should be done by adding only members of type AD groups (not individual accounts).
• These safes typically contain Operator Accounts
• Shared Safes can implement a role-based model, in which safes are created based on onboarding credentials associated with a role or team.
• On the other hand, Shared Safes can also implement a rule-based model, in which access is granted to users for a technology or layer within the business.

4.6.3. Keystores

On peut aussi vouloir créer des Safes pour stocker des secrets n'étant pas destinés à établir des sessions (équivalent d'un keepass partagé). Décrire ici ces types de Safes et leurs permissions.

4.7. Standards pour la gestion des Safes

C'est probablement le plus gros sujet dans CyberArk.

4.7.1. Généralités

Aborder en détail les questions concernant la gestion des Safes:

4.7.2. Convention de nommage

Fournir ici la convention de nommage des Safes.

4.7.3. Détail des permissions par type de Safe

Indiquer le standard des permissions à fournir pour chaque type de Safe. Par exemple:

Exemple:

- Shared or Personal Safes:

Category Permissions Members Safe Admins Auditors CyberArk Admins
Access Access Use accounts ● ● - ●
Retrieve accounts - - - ●
List accounts ● ● - ●
Account
management		 Add accounts - ● - ●
Update account content - ● - ●
Update account properties - ● - ●
Initiate CPM account management operations - ● - ●
Specify next account content - ● - ●
Rename accounts - ● - ●
Delete accounts - ● - ●
Unlock accounts - ● - ●
Safe
management
and
monitoring		 Manage Safe - ● - ●
Manage Safe members - ● - ●
Backup Safe - ● - ●
View audit log - - ● ●
View Safe members - ● ● ●
Workflow Access without confirmation ● ● - ●
Requests authorization Level 1 - ● - -
Requests authorization Level 2 - - - ●
Advanced Move accounts and folders - ● - ●
Create folders - ● - ●
Delete folders - ● - ●

- Keystore Safes:

Category Permissions Members Safe Admins Auditors CyberArk Admins
Access Access Use accounts - ● - ●
Retrieve accounts ● ● - ●
List accounts ● - - ●
Account
management		 Add accounts ● ● - ●
Update account content ● ● - ●
Update account properties ● ● - ●
Initiate CPM account management operations - ● - ●
Specify next account content - ● - ●
Rename accounts ● ● - ●
Delete accounts ● ● - ●
Unlock accounts - ● - ●
Safe
management
and
monitoring		 Manage Safe - ● - ●
Manage Safe members - ● - ●
Backup Safe - ● - ●
View audit log ● - ● ●
View Safe members ● ● ● ●
Workflow Access without confirmation ● ● - ●
Requests authorization Level 1 - - - -
Requests authorization Level 2 - - - ●
Advanced Move accounts and folders - ● - ●
Create folders - ● - ●
Delete folders - ● - ●
Notes

1. Il faut fournir ce tableau rempli pour chaque type de Safe implémenté dans le déploiement.

2. Cet exemple n'est pas une vérité, il faut adapter les permissions (on/off) à chaque modèle de sécurité selon le contexte.

4.8. Contraintes de sécurité dans l'implémentation

4.8.1. Tiering/Enterprise Access Model

Rappeler que l'implémentation du PAM se fait en respectant les règles de tiering/modèle de délégation en place au niveau de l'Active Directory.

Exemple:

Access segregation security is implemented by specifying the perimeter (= Tier) of each type of account and of each Safe, and making sure that only login accounts and onboarded accounts of the same Tier are used.

Note: Login accounts in Tier 1/Tier 2 can only be used to access Safes containing Tier 1/Tier 2 credentials.

- Login accounts in Tier 0 can only be used to access Safes containing Tier 0 credentials.

- Periodically checking Safes against these rules is part of the Safes review that must be automated.

- In all cases, Safe members are granted access to their respective safes through the population of dedicated Security Groups in the Active Directory. The following diagram sums up the rules stated above:

4.8.2. Séparation des droits sur les Safes partagés

Le cas échéant, ajouter une section sur ce sujet.

Exemple:

In the Safe model defined above, as far as Shared Safes are concerned, credentials are placed into safes following a set of rules defined by Security Groups in the Active Directory. This implementation makes it easier to manage permissions granted through CyberArk by a central team managing the AD.

However it can happen that some team or operator legitimately requires administration access to some (but not all) of the credentials located in a safe belonging to another team.

In the following example:

• the Windows Sysadmin team is member of the WIN-SRV safe, providing credentials for the local Administrator accounts to the Windows operating systems.
• The DBA team is member of the DB-ORA safe, providing credentials to the Oracle databases.

Now, the DBA team needs to access the credentials for the local Administrator accounts of all Windows servers hosting Oracle databases. Two solutions can be implemented to satisfy this requirement:

• An additional local account can be created on all Windows servers hosting databases, and the credential be stored in the DB-ORA Safe.
• Alternatively, a third Safe can be created to store the credentials of the local Administrator accounts of those Windows servers hosting Oracle databases. Membership to the three Safes would then be arranged as described below:

4.9. Intégration LDAP/Active Directory

4.9.1. Mapping de domaine
Note

Ceci est valable pour un déploiement Privilege Cloud.

Exemple:

The target domain mappings for LDAP integration have been defined as follows:

Priority Name Mapping Group Vault authorizations
1 Vault Admins GRP_XXX All
2 End Users GRP_YYY None
... ... ... ...

This part must be kept up-to-date.

4.9.2. Détail du mapping de domaine
Note

Ceci est valable pour un déploiement Privilege Cloud.

Fournir les informations générales suivantes:

Exemple de tableau pour le détail des binding accounts:
Order Name Mapping criteria
1 Privilege Cloud Vault Admins Query:(&(objectclass=person)(memberof:1.2.840.113556.1.4.1941:=CN=CYB_ADMINS,OU=CyberArkPrivilegeCloud,DC=contoso,DC=local))
2 End Users Query:(&(objectclass=person)(memberof:1.2.840.113556.1.4.1941:=CN=CYB_USERS,OU=CyberArkPrivilegeCloud,DC=contoso,DC=local))
... ... ...
4.9.3. Unités d'Organisation (OU) des groupes AD

Ici on va décrire la répartition dans des OU des groupes AD utilisés pour fournir aux utilisateurs de CyberArk leurs appartenance à des Safes (en rappelant la ségrégation en place dans l'annuaire AD et l'impérieuse nécessité de respecter les permissions sur les objets, en particulier en les plaçant aux bons endroits).

Exemple:
Organizational Unit Description
/path/to/organizational/unit Accounts providing access to CyberArk for users
/path/to/organizational/unit Groups providing access to CyberArk Safes for users
/path/to/organizational/unit Accounts providing access to CyberArk for administrators
/path/to/organizational/unit Groups providing access to CyberArk Vault and Safes for administrators
4.9.4. Objets AD cibles

Cette section va catégoriser l'ensemble des objets AD concernés (impactés) par le déploiement du PAM.

4.9.4.1. Groupes

Description des groupes AD concernés par le PAM.

Exemple:
Tier Security group Type Description
T0 GRP0_CYBERARK_ADMINS Vault Admins Global administrators (all safes)
T0 GRP0_CYBERARK_ENDUSERS Vault members All CyberArk end-users in Tier 0
T1 GRP1_CYBERARK_ENDUSERS Vault members All CyberArk end-users in Tier 1
T1 GRP1_CYBERARK_DBA Safe members Database administrators
T0 GRP0_CYBERARK_AZURE Safe members Azure Cloud team (Tier 0)
T1 GRP1_CYBERARK_AZURE Safe members Azure Cloud team (Tier 1)
T0 GRP0_CYBERARK_VMWARE Safe members VMware team
T1 GRP1_CYBERARK_VMWARE_RO Safe members VMware auditors (read-only access to vCenter)
T1 GRP1_CYBERARK_WINTEL Safe members Windows sysadmins (Tier 1)
T1 GRP1_CYBERARK_LINUX Safe members Linux sysadmins (Tier 1)
Note

Tout ceci dépend largement de l'organisation et est à adapter.

4.9.4.2. Comptes

Décrire ici les standards de normalisation des comptes en termes de remplissage des attributs AD: samaccountname, adresse mail, UPN, types de groupes cibles d'appartenance:

4.10. Accès administratif au PAM

Fournir ici la description des comptes qui sont utilisés pour administrer le PAM à proprement parler et leus droits (en termes de PAM modules / Vault Authorizations):

Exemple:

The following profiles are defined for the administration of the CyberArk PAM:

• Built-in account for full administration access,
• CyberArk administrator (Global),
• CyberArk Safe administrator,
• CyberArk Auditor.

The following table shows the CyberArk modules visible to different user profiles and the associated Vault authorizations as defined by the LDAP user mapping:

admin Administrator Safe Admin Auditor EndUser
PAM modules
System Health ● ● ● ● -
Accounts ● ● ● ● ●
Privileged Sessions ● - - ● -
Policies ● ● ● ● ●
Applications ● ● - - -
Reports ● - - ● -
User Provisioning ● ● - - -
Administration ● ● - - -
Vault Authorizations
Activate users ● ● ● - -
Add network areas ● ● - - -
Add Safes ● ● ● - -
Add/Update users ● ● ● - -
Audit users ● ● - ● -
Backup all safes ● ● ● - -
Manage file server categories ● ● - - -
Reset user's password ● ● - - -
Restore all safes ● ● ● - -
4.10.1. Accès d'urgence (Emergency Access)

Décrire la présence éventuelle d'un compte de secours (break-glass account) builtin (non-AD) et qui le gère.

Exemple:

One internal (builtin) account have full admin rights on the CyberArk PAM:

internal_admin

The password for this administrator account is stored in a CyberArk Safe and automatically changed every 30 days. In order to use this account, it is necessary to connect to the CyberArk PAM with a user account with retrieve account rights over the Safe CyberarkInternal.

Note: this account is only member of a few internal, built-in Safes. It does not have particular permissions over most of the Safes in the Vault, so it can be used for general Vault administration but not for Safes administration.

4.10.2. Autres comptes spécifiques

Décrire ici les autres comptes internes configurés, le cas échéant (compte auditeur ayant un accès limité en API, compte de création d'objets en masse via API, etc.)

4.11. Réseau

4.11.1. Matrice de flux

Mettre dans un tableau une matrice de flux détaillée regroupant toutes les règles firewall mises en place entre chaque composant pour le besoin de l'infrastructure PAM déployée

Ne pas oublier:

Modèle standard de matrice de flux:
Source Destination Port Proto Purpose
... ... ... ... ...
... ... ... ... ...
4.11.2. Accès conditionnel

Si un accès conditionnel au PVWA ou au portail Privilege Cloud est mis en place, détailler dans cette section la liste des points d'entrée:

Modèle:
Type (internal, VPN, external) Location Public IP address
... ... ...
... ... ...
4.11.3. Gestion des certificats/PKI

Le cas échéant (self-hosted ou Privilege Cloud): TLS pour PVWA, LDAPS vers l'AD, certificats du HTML5 Gateway, etc.

Ne pas oublier de faire figurer ici:

4.11.4. Dépendances techniques

Lister ici comme pour tout projet les dépendances techniques usuelles (avec les IP des services et le mode de connexion).

Voici une checklist de base:

4.12. Conventions de nommage

4.12.1. Safes

Rappeler ici que la question du nommage des Safes du PAM est déjà abordée dans la section 4.7.1 et produire éventuellement un tableau récapitulant cette convention.

4.12.2. Comptes de login

Produire ici un tableau récapitulant la convention de nommage adoptée pour les différents types de comptes de connexion au PAM.

4.12.3. Comptes onboardés

Ne pas paraphraser la doc AD / mettre ici un lien vers la doc de l'équipe AD

4.12.4. Groupes

Produire ici un tableau récapitulant la convention de nommage adoptée pour les groupes de sécurité concernant l'organisation du PAM.

4.12.5. Unités d'Organisation (OUs)

Produire ici un tableau récapitulant la convention de nommage adoptée pour les Organizational Units représentant la structure logique dans l'annuaire AD des objets utilisés pour le PAM.

4.12.6. Plateformes CPM

Produire ici un tableau récapitulant la convention de nommage adoptée pour les plateformes CPM.

4.13. Périodes de maintenance

Détailler ici les fenêtres de maintenance négociées durant lesquelles le service est susceptible d'être dégradé ou interrompu de façon programmée.

Exemple de section sur la fenêtre de maintenance sur Privilege Cloud:

Some administration actions performed on CyberArk require that the Vault component be restarted to take effect. For instance: removing orphan Safes, configuring domains for user provisioning, mass setting of permissions on Safes, etc.

Restarting the Cyberark Vault causes approximately 20 minutes of downtime. This stops all open sessions (RDP or other) since session activity is saved in the Vault for monitoring and audit requirements.

In the Privilege Cloud version of CyberArk, the restart operation can only performed by the editor support, and possible timeslots are the following:

• 9am to 5pm IST (= 04:30 to 12:30 CET)
• 9am to 5pm EST (= 15:00 to 23:00 CET)

Consequently, a fixed maintenance window of 30 minutes is defined for CyberArk in order to cover all possible outages due to planned maintenance. The frame is the following:

• Time: from 7.00 am to 7.30 am CET.
• Periodicity: every month.
• Week days: 7/7 Monday to Sunday.

4.14. Limitations

4.14.1. Known limitations

Faire état des éventuelles limitations de la solution déployée au regard du cahier des charges initial.

Exemple pour Privilege Cloud:

When using Privilege Cloud (instead of an on-prem deployment of the CyberArk PAM) there are a few limitations and restrictions:

• It is not possible to send the logs of the Vault to a SIEM. Only the logs from the on-prem components (the CPM servers) can be sent to a SIEM.

Reference:

https://cyberark-customers.force.com/s/article/Vault-Can-all-ITALog-log-entries-be-forwarded-to-a-SIEM-Security-Information-and-Event-Management-tool

To configure the redirection of logs from the bastions (CPM/PSM) to a SIEM, it is necessary to configure the Secure Tunnel component and issue a request case to the CyberArk support in order to setup or update the configuration.

Connect to SIEM :

https://docs.cyberark.com/Product-Doc/OnlineHelp/PrivCloud/Latest/en/Content/Privilege%20Cloud/privCloud-connect-siem.htm#Syslogauditcodes

Deploy Secure Tunnel :

https://docs.cyberark.com/Product-Doc/OnlineHelp/PrivCloud/Latest/en/Content/Privilege%20Cloud/privCloud-deploy-ST.htm?tocpath=Setup%7CDeploy%20and%20maintain%20Privilege%20Cloud%20connectors%7CDeploy%20Secure%20Tunnel%7C_____0

• It is impossible to remove orphan Safes. When such objects exist, it is necessary to issue a request ticket to the CyberArk support to remove them.

• As of Dec. 2022 it is not possible to configure domain mappings through the PVWA portal interface. Although the configuration pane exists for this matter, it can only be used to remove domain mappings but it does not work when trying to add domain mappings.

When it is necessary to add or update domain mappings, one must issue a request ticket by the CyberArk support.

4.14.2. Assumptions

Indiquer ici quelles sont les hypothèses de départ issues des contraintes de l'environnement spécifique dans lequel le PAM est déployé et qui sont susceptibles d'introduire des limitations qui ne sont pas dues au produit lui-même mais aux spécificités de l'environnement.

4.14.3. Out of scope

Indiquer ici toutes les gestions d'accès privilégiés qui sont hors du périmètre du déploiement, soit parce que le PAM ne peut pas les gérer (systèmes anciens/spécifiques, applications internes, ...) soit parce que des arbitrages les ont exclues du périmètre (pour des questions de niveaux de criticité, consommation de licences, etc.).

4.15. Policies

Description des policies mise en oeuvre dans le PAM.

4.15.1. Master policy
Exemple:

• Privileged Access Workflows
  ◦ Require dual control password access approval: Inactive
  ◦ Enforce check-in/check-out exclusive access: Inactive
  ◦ Enforce one-time password access: Inactive
  ◦ Allow EPV transparent connections ('Click to connect'): Active
  ◦ Require users to specify reason for access: Inactive

• Password Management
  ◦ Require password change every X days: 30 days
  ◦ Require password verification every X days: 2 days

• Session Management
  ◦ Require privileged session monitoring and isolation: Active
  ◦ Record and save session activity: Active

• Audit
  ◦ Activities audit retention period: 90 days

4.15.2. Exceptions
Exemple:

Three exceptions are defined in order to enforce One-Time Password (OTP) access for the following platforms:

• Exception: Azure Portal
  ◦ Enforce one-time password access: Active

• Exception: Windows Domain
  ◦ Enforce one-time password access: Active

• Exception: Windows Domain TOTO.LAB
  ◦ Enforce one-time password access: Active

4.16. Configuration des connecteurs PSM

Fournir dans cette section la liste des connecteurs PSM utilisés (RDP, SSH, etc.) et leur logique de sélection.

4.16.1. RDP

Liste des PSM de type RDP déployés:

Exemple:
Identifier Name PSM Server Address User parameters Target Settings
PSM_TOTO-LAB RDP for TOTO psmtoto.toto.lab 192.168.168.123 AllowMappingLocalDrives: Visible=Yes ; Value=No
LogonDomain: Value=empty
AllowConnectToConsole: Visible=No ; Value=No		 Protocol = RDP
ClientApp = mstsc.exe
ClientDispatcher = PSMRdpClient.exe
... ... ... ... ... ...

Voici d'autres exemples de types de PSM à inclure, en fonction de l'environnement:
(Même chose que pour la section précédente, fournir les détails)

4.16.2. SSH

4.16.3. vSphere

4.16.4. Web/PSMP

4.16.5. Connecteurs custom

4.17. Load-balancing des PSM

Le cas échéant, si on a mis en place du load-balancing au niveau des adresses des PSM, décrire ici la configuration déployée.

4.18. Gestion des plateformes CPM

4.18.1. Active Directory

Fournir ici le détail des plateformes utilisées/customisées et la logique de rotation par type de plateforme (Windows, Unix, DB, réseau, ...etc.):

Exemple:
Identifier Name Password change Reconcile account Use PSM connectors Preferred PSM server
WindowsAD AD accounts 30 days none This is the default platform for the management of all Active Directory credentials used for RDP and SSH targets PSM_TOTO, PSM_TATA PSMServer_b6d4a16
... ... ... ... ... ... ...

Voici d'autres exemples de plateformes à inclure, en fonction de l'environnement:

Même chose que pour la section précédente, fournir les détails

4.18.2. *NIX
4.18.3. Cloud
4.18.4. Bases de données
4.18.5. Equipements réseau
4.18.6. Applications
4.18.7. Accès DRAC
4.18.8. Sites web

4.19. Configuration de Secure Tunnel

Ceci est valable pour Privilege Cloud.

Le cas échéant, si le logiciel CyberArk Secure Tunnel a été installé, décrire ici la configuration déployée.

Exemple:

- Customer ID: ...

- Login: ...

- PDC for domain CONTOSO.LAB:
  > Server name: ...
  > Server port: ...

Component type Host address Remote port Secure tunnels
... ... ... ...
... ... ... ...

4.20. Continuité et résilience

Détailler dans cette section le plan de sauvegarde/restauration:

Détailler les méthodes appliquées pour effectuer les sauvegardes. Par exemple:

Note:

Cette section concerne principalement un déploiement self-hosted mais il peut être utile de détailler ce plan pour les composants on-prem d'un déploiement Privilege Cloud.

4.21. Hardening des serveurs

Faire figurer ici une checklist de tous les points mis en application concernant le hardening de chacun des composants déployés, et indiquer quel est le référentiel utilisé (CIS Benchmark, guide CyberArk Vault Hardening, ou autre).

4.22. Intégration ITSM

Mettre un schéma d'intégration ITSM si les demandes d'accès passent par un outil comme ServiceNow.

4.23. Versions déployées des composants

Indiquer dans cette section les versions déployées de tous les composants.

4.24. Gestion des exceptions

Lister ici les cas faisant exception à l'usage général du PAM dans son contexte et les raisons. Par exemple:

5. Document d'exploitation (DEX)

Ceci figure généralement dans un document séparé. Cependant quelques procédures d'exploitation peu courantes peuvent figurer dans le DAT. Pour le reste, fournir ici le(s) lien(s) vers les procédures d'exploitation.

A titre indicatif, voici une liste de procédures d'exploitation à ne pas oublier dans le DEX:

6. Document d'installation (DIN)

On ne va pas développer cette partie ici. D'abord, le DIN figure le plus souvent dans un document séparé du DAT. Ensuite, il est abondamment illustré de captures d'écran et de tableau de données qui sont spécifiques à un environnement donné et deviennent périmés à chaque changement de version.

On se contentera le plus souvent, de fournir dans le DAT le lien vers le DIN.

Cela dit, le DIN fait aussi partie des livrables à fournir au terme d'un déploiement.

7. Notes

--
TG - 07/2026
Cet article a été généré à 98~99% par un humain