- This line was added.
- This line was removed.
- Formatting was changed.
Smart ID Digital Access component is shipped as a virtual appliance that uses an Ubuntu base image. If Digital Access component is deployed on a customer Docker host (not as virtual appliance), hardening has to be under control of the customer itself.
With every release of Digital Access component this base image is hardened in different areas:
- Only installing required software and services
- Restricted user management
- Continuous security updates
Once the appliance is deployed in the customer environment, upgrade of Digital Access component will only happen to the Docker containers inside. That means that after deployment, the customer is responsible for maintaining the virtual appliance and the operating system inside.
Read more about how to deploy here: Deploy Digital Access component.
The following topics only apply for appliances that get's created with each new Digital Access component release. Already deployed appliances are not changed afterwards.
During the installation, Digital Access component installs the OpenSSH server for communication from outside. A Postgres database is installed and only used for local communication. Connections from outside are disabled by default.
During the installation, the default firewall of Ubuntu is applied. Only features that comes by default with the corresponding Ubuntu base image (currently 20.04) are available within the Digital Access component appliance, including:
If Digital Access component is configured to use an external database for users, reporting and OATH, the internal Postgres database service can be turned off without any hassle.
To improve the hardening index of Digital Access component, an SSH configuration parameter (
To increase the amount of authentication attempts:
In case of Digital Access component upgrades, this change has to be done after the appliance has been upgraded successfully.
All services in Digital Access component inside the Docker containers are run by a separate user named pwuser. Authentication from outside is not allowed with that user. For authentication from outside, the user agadmin is created during installation.
Writing permissions to Digital Access component-related files are restricted to power users, such as pwuser and root.
Because of security reasons, the passwords of pwuser and root can be changed after installation. To do this, use sudo access of agadmin or root. The pwuser could still not be used to authenticate from outside after this change. All passwords are saved as part of the default location of passwords.
Change root password
With every release of Digital Access component, all binaries are updated to the latest versions to prevent security vulnerabilities as much as possible. Therefore, vulnerabilities like Spectre and Meltdown are taken care off as soon as updates are available. A steady release cycle ensures prompt security updates.
Once Digital Access component is deployed as virtual appliance, the customers have to make sure that security updates get applied on a regular basis.
The communication between Digital Access component nodes is secured with a Nexus proprietary protocol called LCP. The protocol is based on length, type and value. LCP uses a shared secret which is initialized during the system setup. Once the secret is shared among all the registered nodes the secret is never shared again. Although, it is possible to update the secret time-to-time for security purpose. To update the secret, use one of the two following methods:
The following types of data are encrypted over LCP:
On a regular basis, Nexus instructs specialized, external companies to perform penetration tests on the latest versions of Digital Access component, to ensure that it maintains it high security status.
Critical vulnerabilities found by PEN testing will be fixed as soon as possible and released with the next version (or an interim version if required).
This article is valid from Digital Access 6.0.0 till 6.0.3