7. PAM

1.1 The product must allow system administrators to securely access target systems through a centralized authorization mechanism without needing to know or manually enter credentials. All activities during this access process must be thoroughly audited and logged.

1.2 The product must be developed with a microservices architecture to maintain performance under high concurrent user load and heavy processing demand. It should support horizontal scaling (Scale Out) and, when necessary, vertical scaling (Scale Up) to dynamically respond to increased resource needs.

1.3 The product must be fully compatible with common container orchestration platforms such as Kubernetes, OpenShift, Mesos, and Docker Swarm to facilitate the lifecycle management of its microservices.

1.4 To ensure uninterrupted access to critical systems, the product must support Active-Active and Active-Passive high availability (HA Cluster) configurations.

1.5 There must be no need to install any persistent software component on target systems whose passwords will be centrally managed. Management operations should be carried out through an agentless architecture using secure and standard protocols.

1.6 The initial installation, configuration, regular maintenance, and application of security updates for the database used for backend data storage must be managed by the product itself.

1.7 The product must operate smoothly on virtual machines using pre-configured OVF/OVA images for the organization's existing virtualization infrastructures such as VMware, KVM, Proxmox, and Microsoft Hyper-V. The product documentation must include virtual machine requirements (CPU, RAM, disk), configuration recommendations for optimal performance, and virtual network configuration requirements.

1.8 The product must include strategies for database backup and restore.

1.9 The network infrastructure requirements necessary for the product to operate properly and securely must be documented in detail.

1.10 The solution must support disaster recovery. In emergencies, a “break the glass” scenario must be activated. In this scenario, an encrypted copy will be sent over the network to a server or client outside the application at predefined intervals using a password defined by the administrator. This ensures access to required data when needed.

1.11 All system components must communicate with each other using encrypted (cryptographic) connections.

1.12 The product must be compatible with authentication methods such as LDAP, LDAPS, and RADIUS.

1.13 The product must be able to automatically synchronize Active Directory users and their group memberships and dynamically determine and authorize target resources to be accessed based on these group memberships.

1.14 The product must be able to automatically discover all user accounts existing on supported network device brands and models and list them with detailed information on a centralized interface. The discovery period and methods must be configurable.

1.15 It must be possible to import existing managed accounts and newly added accounts into the system in bulk using the CSV file format.

1.16 The product must be able to automatically discover local user accounts on different Linux distributions and list them with detailed information on a centralized interface.

1.17 The product must be able to automatically discover local user accounts on different Windows Server and client operating system versions and list them with detailed information on a centralized interface.

1.18 The product must be able to securely and centrally change the usernames of local user accounts on managed Windows operating systems.

1.19 The product must be able to centrally enable or disable local user accounts on managed Windows operating systems.

1.20 The product must allow authorized users to securely and centrally unlock user accounts that are locked out in the managed Active Directory environment for various reasons.

1.21 The product must ensure that application user accounts that show no activity for a specific period are automatically disabled, in compliance with the organization’s security policies.

1.22 The product must allow personnel who log in to the system as an authenticated Windows Active Directory (AD) user to securely access network devices, Windows, and Linux systems via Telnet, SSH, RDP, and VNC protocols without requiring additional credentials.

1.23 The proposed product must support Two-Factor Authentication (2FA) using either the local vendor’s authenticator software or third-party solutions such as Google Authenticator, Microsoft Authenticator, email, or SMS.

1.24 The product must provide 2FA support for all firewall SSL VPN users.

1.25 When required and in accordance with security policies, access to critical target servers, network devices, and applications must be restricted to occur only through the product, under complete supervision.

1.26 For access to critical systems, the product must offer additional security layers (such as IP address verification, time-based access restrictions – allowing access only during certain hours or days, and 2FA) to further strengthen user identity verification and authorization. These controls must be configurable on a policy basis.

1.27 The product must support a multi-step approval mechanism (two-factor or multi-factor approval) that requires the separate approval of multiple predefined authorities for sensitive administrative operations or access to sensitive information in password vaults. Approval workflows and authorization rules must be thoroughly configurable.

1.28 Users who need to access the system from outside the organization must be granted role-based access rights to view and use system accounts, connect securely to target systems, and use agentless access. However, these users must strictly not have permission to view or change the existing passwords on the target systems. Access privileges must be limited by the principle of least privilege, for a specific period and specific resources. External user access must be logged in detail.

1.29 The product must allow each authorized system administrator to view and manage only the accounts and passwords of the systems they are responsible for and authorized to access.

1.30 System administrators must be strictly prevented from viewing or managing the accounts and passwords of end users utilizing the system. This separation must be clearly and strictly enforced through a Role-Based Access Control (RBAC) mechanism, and privilege delegation must be supported.

ers with administrative roles should have the right to securely reset the passwords of other users within their area of authority.

1.32 The product should provide personal password vaults where end users can securely store their personal and sensitive information (passwords, API keys, certificates, etc.), encrypted with a strong key defined by the user. Access to these vaults should only be possible if the user provides the correct key, and the contents of the vault should not be visible even on the server side.

1.33 The product should offer customizable shared password vaults tailored to different security requirements and usage scenarios. These vaults should be configurable for specific resources, applications, projects, or teams, and should support various access control mechanisms and security policies. Vault creation and management permissions should be controlled based on roles.

1.34 The product should support role-based password vaults where access rights to target systems and applications can be defined and managed centrally according to users’ organizational roles and responsibilities. This ensures that users only have access to the passwords related to their roles and simplifies privilege management processes. Role definitions should include detailed permission levels.

1.35 The product should securely manage the passwords of service accounts used by applications and services centrally and should be able to change them either periodically or on demand. All successful and failed password change attempts must be logged in detail. When dealing with service accounts linked to Active Directory (AD) users, the system should automatically discover all service connections of these users across all servers and reflect the password change across all relevant services without causing any service interruptions.

1.36 The product should allow configuring password change policies for service accounts, including password complexity, change frequency, and expiration times. These policies must be definable separately for each account or group of accounts.

1.37 The product should allow detailed authorization to be defined over the use of stored passwords, such as "allow connection only," "allow password viewing only," or "allow both password viewing and connection." These permissions must be defined based on roles.

1.38 The product must log every access and operation performed on all types of vaults (personal, shared, role-based, service account) in detail and in a tamper-proof manner. These logs should include date/time, user information, operation performed, and the target resource.

1.39 In cases where direct access to target systems and devices is not possible, the product should support connection methods via jump server (proxy/jump host) and should manage user access in a controlled and secure manner.

1.40 The product should support flexible session recording and monitoring capabilities during user access to target systems. It must record RDP, SSH, Telnet, and VNC sessions end-to-end, and these records must be replayable in video format.

1.41 Session recording files must be protected against deletion or modification. All session activities (keyboard usage, screen transitions, mouse movements, etc.) should be clearly visible and audible when played back.

1.42 The product must support real-time session monitoring. Authorized administrators must be able to watch active sessions live and have the ability to instantly terminate a session if deemed risky.

1.43 The product should support a keystroke logging feature for command-line-based access (SSH, Telnet, etc.). These logs should be searchable, indexable, and accessible to authorized users.

1.44 The product should support automated risk detection and alerting mechanisms during sessions. It must be able to detect high-risk behaviors (such as running unauthorized commands, copying data, accessing unauthorized files) and instantly notify authorized persons.

1.45 The product should have integration support with SIEM (Security Information and Event Management) systems. All logs and alerts generated by the product should be transferable in real-time or at configurable intervals using standard protocols/formats such as Syslog, CEF, LEEF.

1.46 The product should be able to generate customizable reports based on various criteria (user-based, system-based, time-based, session-based, etc.), and these reports should be exportable in formats such as PDF, CSV, and XLS.

1.47 Reports should support scheduled automatic generation and distribution to designated users or groups via email or a secure access link.

1.48 The product must allow the definition of access workflows, and access to critical systems and accounts must be able to proceed through an approval mechanism.

1.49 The product must support ticket system integration (such as ServiceNow, Jira, etc.) and be able to validate access requests based on active tickets.

1.50 The product must be able to provide emergency access authorization to administrators for critical systems, even outside standard workflows, while logging and reporting such accesses in detail.

1.51 During RDP connections, the product should support detailed controls such as allowing or blocking secure file and clipboard transfers between endpoints (client and server) in full compliance with the organization's security policies.

1.52 The product should support secure real-time collaboration by allowing two or more authorized users to join the same active RDP session simultaneously, share the screen, and collaborate (including mouse and keyboard control sharing) when needed.

1.53 The product must be capable of monitoring user activities (commands, clicks, data entries, etc.) in detail on target systems without requiring any agent software installation.

1.54 The session video recording feature (for graphical sessions like RDP, VNC, etc.) must not cause any noticeable and unacceptable degradation in the performance of the target system (CPU usage, memory consumption, disk I/O, etc.).

1.55 Ongoing active user sessions must be able to be immediately and securely terminated in case of a suspected security breach or emergency intervention. The administrator who terminates the session, along with the termination time and reason, should be thoroughly logged. A notification should be sent to the user about the termination.

1.56 Recorded sessions should be saved in high resolution and in color to provide a clear, detailed, and easily analyzable visual presentation. The recording quality should be configurable.

1.57 The product must be able to manage multiple simultaneous remote sessions established via Remote Desktop Protocol, SSH, and HTTP(S) through a unified and centralized management interface in real time (monitoring, terminating, interacting with sessions, etc.). The list of active sessions should be updated instantly.

1.58 The product must enable access through RDP Proxy and SSH Proxy with third-party applications using a uniquely generated ID. Accesses performed with this ID should be logged and necessary actions should be taken.

1.59 Secure and controlled remote access to specified websites should be provided.

1.60 Remote PowerShell support must be available.

1.61 With the remote app feature, the product should allow automatic filling of fields such as username, password, IP, and database by the system, enabling access to the application.

1.62 The remote app feature should allow the use of parameter options for the connected application.

1.63 Users should be able to initiate sessions through an HTML5-compatible browser.

1.64 Video recordings should be saved in a format that allows them to be played on any computer.

1.65 If needed, activity recording should be able to be disabled for specific users or groups.

1.66 The product should provide the ability to centrally define and restrict commands that users can execute during interactive sessions or via scripts on Linux and Windows systems. All other command inputs and keyboard interactions (e.g., special characters, command completion attempts) should be blocked. Defined rules should be customizable by user, group, or target system.

1.67 The product should provide the ability to centrally define and restrict commands that users can execute via the command-line interface on network devices. This feature should prevent unauthorized configuration changes and the execution of risky commands to ensure the security of the network infrastructure. All other command inputs and keyboard interactions (e.g., special characters, command completion attempts) should be blocked. Defined rules should be customizable by device role or individual device.

1.68 Command control rules should be customizable based on user, group, target system, or connection type.

1.69 If a user attempts to execute a command beyond their authority during a session, the system should automatically detect this in real time and send a warning message and notification to the user.

1.70 All characters typed in CLI commands must be logged, even if the Enter key has not yet been pressed.

1.71 The product must support blocking of bypass methods such as function keys and arrow keys during SSH connections.

1.72 The product must be usable as a TACACS server.

1.73 The TACACS server must support LDAP and LDAPS.

1.74 The product must be usable as a RADIUS server.

1.75 The RADIUS server must support LDAP and LDAPS.

1.76 The product must be capable of logging authentication, authorization, and accounting (AAA) activities performed over TACACS+ and RADIUS protocols.

1.77 The product must provide 2FA support at the login stage for the web interfaces of all systems with RADIUS support.

1.78 The product must be able to display bulk configuration commands for TACACS and RADIUS on network devices.

1.79 Reports must be customizable or pre-defined as templates.

1.80 The system must generate descriptive and detailed log records for all user and administrator activities and be able to securely integrate with the institution’s existing central log management system using standard and widely adopted formats (Syslog, CEF, LEEF). Logging levels must be configurable.

1.81 The product must be able to generate detailed reports of all successful and unsuccessful session start/end attempts and active sessions within a given time range. Session durations must also be included in the reports.

1.82 A detailed list of all roles and permissions defined in the system must be reportable.

1.83 Authorized audit personnel must be able to securely access all activity records through a user-friendly interface, with the ability to filter, sort, and examine the records in detail according to different criteria.

1.84 Audit records must be retained for long periods in accordance with legal regulations and corporate policies and must be protected against unauthorized access.

1.85 The product must offer separate dashboards and views for different administrative roles.

1.86 All interfaces presented to administrators and end-users must be modern, intuitive, and user-friendly web-based applications. The web interface must fully support the Turkish language and preferably offer options for other widely used languages (such as English). Language selection must be configurable on a per-user basis.

1.87 The product must provide a standards-compliant, responsive graphical user interface (GUI) that works seamlessly with the current stable versions of commonly used modern web browsers (Microsoft Edge, Google Chrome, Mozilla Firefox, Apple Safari) without requiring any additional plugins or extensions.

1.88 The product must support both the command-line interface (CLI) and the web-based graphical user interface (GUI) simultaneously.

1.89 The product must integrate securely with commonly used local CLI client applications such as SecureCRT, PuTTY, MobaXterm, and MRemoteng, and must offer centrally managed and audited access through these clients.

1.90 The product must provide secure and audited access as a platform to a wide range of operating systems, platforms, and applications.