IBM Robotic Process Automation security
The IBM Robotic Process Automation product was born on the cloud and is now available in on-premises deployments. Being cloud-native, IBM RPA is designed with strict security design principles that use built-in cloud security features. IBM RPA features IBM's world-class security practices and requirements.
Understanding IBM RPA's security posture requires a basic understanding of IBM RPA's component design and how those components work together to provide enterprise-ready features clients can depend on.
-
IBM RPA Control Center
The IBM RPA Control Center is the user interface collection of robot management features that enables administrators, developers, and business leaders to manage the client's robot assets. These features include the robot repository, publishing robot's for business users to easily run in an attended fashion, building and viewing business dashboards, and scheduling robots for unattended execution. The IBM RPA Control Center is hosted on the server-side service management of the IBM RPA topology. UI access paths are secured with HTTPS, and the management console adapts its features based on your configured role. -
IBM RPA's API server
This component provides the business logic for the IBM RPA Control Center, hosted on the server-side service management of the IBM RPA topology. Endpoints are secured with HTTPS over TLS 1.2. -
IBM RPA Studio
You can use the IBM RPA Studio to develop and test the robotic automation scripts, which are then published through the API server to the IBM RPA script repository. The repository is hosted in a service-side IBM RPA relational database. The IBM RPA Studio is a rich Windows client, and is hosted on the developers' Windows workstation or laptop. -
Bot Agent
The Bot Agent is a local client-side component of IBM RPA installed as a Windows service. Its primary responsibility is to manage the activities and settings of the host computer by communicating with the IBM RPA server. -
IBM RPA Launcher
The IBM RPA Launcher provides a simple interface for business users to start configured attended bots whenever necessary in their daily business. Users are required to authenticate with the security provider configured for IBM RPA. -
Bot Runtime
The Bot Runtime provides the container for a robot in operation. IBM RPA bots run on the configured Window's host. The client manages the robot computer resource for operation.The IBM RPA consumer is in full control of the client guests, the client guest security policies, maintenance schedules and policy, operating system's firewalls, and other security controls. You can ensure that sensitive data and access to sensitive internal systems stay in-house. The Bot Runtime runs under a configured system user, which can have less permission than the Windows administrator.
-
IBM RPA Vault
The IBM RPA Vault is hosted on the client's Windows host, and credentials for specific robotic access to system services are stored there. While IBM RPA allows credentials to be configured in the management server, it also provides facilities to use asymmetric keys. IBM RPA gives the public key to the management server for encrypting credentials and retaining the private key on-premises for decrypting credentials. The management service has no access to the private key. -
SDLC
IBM RPA enforces Secure software development lifecycle (SDLC) by following IBM's Security and Privacy by Design practices, an agile set of focused security and privacy practices.
IBM RPA security principles
Security cannot be bolted onto products, and IBM has a disciplined Security by Design approach to ensure that a methodical approach is used to design a strong security posture.
IBM has strict processes in place to consider alerting the customer to critical security considerations, including the IBM Product Security Incident Response Team (PSIRT) security remediations, periodic software as a service (SaaS) and on-premises third-party and internal penetration testing, and on-going security monitoring to identify threats. For more information, see Secure software development lifecycle.
IBM RPA networking
The following list defines the main security measures of IBM RPA networking:
-
HTTPS
Secure HTTPS traffic ensures that no man-in-the-middle attacks are possible between components and ensures that the request body is encrypted from the IBM RPA client's environment to the IBM RPA server's environment. -
Updates
For the SaaS offering, the IBM RPA product team regularly reviews and updates the minimal TLS algorithms, which can be used to transfer data on the wire. Staying current is paramount for secure networking. -
Client outbound port design
Client's communicate with the IBM RPA management components through SignalR two-way protocols, such as web-sockets. While the IBM RPA management components do send data to the client's over these protocols, the client components must first log in to the IBM RPA management components and establish a communication channel: client outbound port to IBM RPA management inbound port. Only then can the management server send the client data. For more information about ports, see the requirements topic of the Installation section for the offering you want. -
SaaS networking
IBM RPA SaaS offering uses Azure Web Application Firewall (WAF) on Azure Application Gateway to provide enterprise protection against security attacks on public websites, such as SQL Injection, cross-site scripting, among others. IBM RPA site reliability engineering (SRE) manages the policy in the Azure Security Center and is alert to key vulnerabilities, such as the configuration of the TLS policy. For more information about WAF, read Microsoft's Azure Application Gateway featuresdocumentation.
IBM RPA encryption
In the IBM RPA SaaS offering, all the server-side disks are encrypted, which means data at rest is encrypted at the disk level. The encryption keys are platform-managed by Microsoft. For more information, see Microsoft's Azure Data Encryption at rest security documentation.
Federal Information Processing Standards (FIPS) are standards that describe document processing, encryption algorithms, and other information technology standards. The National Institute of Standards and Technology (NIST) developed FIPS to use in computer systems by non-military American government agencies and government contractors.
Being FIPS compliant means that a Cryptographic Module meets the requirements for each level and can be validated, if necessary. Starting from version 21.0.1
, IBM RPA is FIPS 140-2 compliant if FIPS mode is enabled. See details
in FIPS control center interface.
To learn more about IBM RPA's data encryption, see the Data encryption topic for each IBM RPA component in this documentation.
-
Bot Agent data encryption
All the data traffic between the Bot Agent and the IBM RPA server is encrypted with the HTTPS protocol over TLS 1.2. -
Bot Runtime data encryption
Data traffic between the Bot Runtime and the IBM RPA server is encrypted with HTTPS over TLS 1.2. -
IBM RPA Control Center data encryption
The communication between IBM RPA Control Center and IBM RPA's API uses secure HTTPS over TLS 1.2 protocol. The communication between a user and IBM RPA Control Center uses the same protocol. -
IBM RPA Launcher data encryption
Data that is exchanged between the IBM RPA Launcher and the IBM RPA's API uses a secure HTTPS connection. -
IBM RPA Studio data encryption
Data traffic between IBM RPA Studio and the IBM RPA server, like scripts and machine learning models, are encrypted by using HTTPS. Sensitive information is secured by using the Windows Data Protection resource. -
IBM RPA Vault data encryption
IBM RPA Vault has two methods: the system and the local vault. Both of them use asymmetric encryption, and they both are responsible for the configuration and encryption of credentials.
IBM RPA authentication
The following list defines the authentication methods available in IBM RPA:
-
Custom User Registry
IBM RPA product was introduced with a custom-user registry to support SaaS accounts and provide the portals that are required to manage user accounts. Passwords are stored by using a salted hash algorithm and are unknown to the IBM RPA SRE team. Self-service resets are enabled through configured email account to ensure that only the registered email can request a password reset. A configurable login-token timeout value can be configured to ensure that logins expire at the frequency that is dictated by the organization. -
Single-Sign On
An alternative for IBM RPA on premises, SSO is supported by using the IAF ODIC provider, which allows integration with various enterprise directories. The specific enterprise directories and SSO providers can optionally be configured for Multi-Factor Authentication.
IBM logging and monitoring
You can view logs and monitor resources in the IBM RPA Control Center. For more information, see Data visualization in IBM RPA Control Center.