Platform Securization
Security is an important topic on any application, but it requires a special attention when your propietary software is being exposed to external factors to avoid any risk. Here we expose a view of all the components and security concerns, so you can take decisions on your architecture and securization for your CachéQuality installation.
CI analysis lifecycle
Continous Integration is an important part of development lifecycle, and adding CachéQuality as an additional step brings in a suite of automated checks for everything from efficiency to security vulnerabilities in compliance to your development and architecture standards.
We choose Jenkins as our preferred CI tool, as it is one of the most popular CI tools, but you can work with either CI tool accordingly to your company preferences.
The Jenkins task to get the anlysis of your code is quite simple, and can vary slightly accordingly to you software development ecosystem. The most typical environment for COS is to hold your source code in a repository in XML format.
The steps of the Jenkins task are:
- Retrieve the source code from your repository, either if you have it only in Caché. If you have just code, with no source repository neither Caché database, you just need to copy your source code to the workspace folder.
- If your source code is in XML format, a transformation to text plain is required for the analysis. This transformation is done using cachedb-import, an open source conversor developed by Lite Solutions that you can find in GitHub.
- Finally, the task must run sonar-scanner on the text plain source code. On this step the analysis is performed and the results are bulked to SonarQube.
Additionally, we strongly recommend to include a previous and post operations to clean any source code in the local server disk.
Main components view
Our analyzer is a self-contained piece of code capable to analyze COS code and detect vulnerabilites, at the time that takes measures. You can view it as a black-box that receives source code and output a list of issues and metrics.
The analyzer always needs source code in plain text, but the output can be bulked to different systems. We always recommend to use an existing QA tool. CachéQuality analyzer comes by default with an interface to work with SonarQube. It means the output is bulked to SonarQube, where any user can browse the results.
While sources remains in the local disk and security concerns to the operative system, the output security concerns to your selected QA tool (SonarQube by default). If your machine is either exposed to the Internet or not, you should apply high security standars to avoid any risk on your source code.
Full components view
Next you can view the components of a regular installation:
Elements can be all in the same server or in different ones. The most common configuration is to hold Caché database and SCM in their own server each one, and all the other components in a CI server. Above we will deal with each of this components securization.
Jenkins securization
Security in Jenkins is an important part in the platform, as the task management use users with permissions to access your source code, the Caché database, and any other resource you require to deal with for your analysis.
User Access
Jenkins does not allow anonymous access and the authorization method can be decided as explained below.
Security Realm and Authorization
By default, the Security Realm in Jenkins is the Jenkins' own user database (a builtin user/password storage) , but you can choose to use your enterprise LDAP system or your own user/group database.
To setup the Security Realm, navigate to Jenkins > Manage Jenkins > Configure Global Security.
From this panel you can also manage your Authorization system. We recommend to use Matrix-based security to decide what can do each user group, and manage new groups aside the default Anonymous and Authenticated groups:
Web server security
It is recommended to use a reverse proxy to improve security.
To navigate on Jenkins (or your preferred CI tool), it is highly recommended to use HTTPS protocol using a valid certificate. In our documentation we explain how to configure Apache2 as a proxy for Jenkins.
Other concerns
Visit the official Securing Jenkins page to protect users of Jenkins from other threats.
SonarQube securization
User Access
SonarQube is configured by default to allow anonymous user to navigate on all the projects, sources and issues.
After checking that everything is working properly with SonarQube you must force user authentication to avoid anonymous users to access to SonarQube. So, after you login as administrator, navigate to Administration > Configuration > General Settings > Security and check the force authentication button.
Now you can manage your Users and Groups from Administration > Security.
It is recommended to delegate the authorization mechanism to your enterprise LDAP system. Please, check the LDAP plugin for SonarQube page for more information about compatibility and configuration.
Database security
The most important concern about database is to close any external access, so only local connections are permitted.
It is highly recommended to use a specific user for SonarQube which only have access to its own schema. Don't use the administrator user in the SonarQube configuration.
Web server security
To navigate on SonarQube (or your preferred QA tool), it is highly recommended to use HTTPS protocol using a valid certificate.
SonarQube server does not support HTTPS and is required to use a reverse proxy. In our documentation we explain how to configure Apache2 as a proxy for SonarQube.
If during installation you opened port 9000 to allow external navigation, close it after you configure your secured proxy.
Apache2 security
Having a point at which you can inspect, transform and route HTTP requests before they reach your web servers provides a whole host of benefits. Next we list those that are more relevant to the described architecture for CachéQuality:
- Hide the topology and characteristics of your back-end servers by removing the need for direct internet access to them.
- Place your reverse proxy in an internet facing DMZ, but hide your web servers inside a non-public subnet.
- Provide a single point of authentication for all HTTP requests.
- Handles incoming HTTPS connections, decrypting the requests and passing unencrypted requests on to the web servers. This has several benefits:
- Removes the need to install certificates on many back end web servers.
- Provides a single point of configuration and management for SSL/TLS
- Takes the processing load of encrypting/decrypting HTTPS traffic away from web servers.
- Makes testing and intercepting HTTP requests to individual web servers easier.
- Because all HTTP requests are routed through the reverse proxy, it makes an excellent point for logging and auditing.
SCM security
Be sure to hold a secure connection between the CI server and your SCM.
We recommend to use a read-only user with access only to the repositories to be analyzed.
We strongly recommend to use a SCM to hold your source code if you are not using it yet!
Caché database security
Be sure to hold a secure connection between the CI server and your Caché database server.
We recommend to use a user with %Developer role and access only to an empty namespace. Our plugin will never require access to you code or data in your Caché database.
If you have your source code only in Caché database, then you will need an additional user to retrieve your source code. This code won't be used by the CachéQuality plugin, but will be needed by Jenkins on the step to retrieve source code.
Updates
As for any software, your platform must be updated as frequently as possible. Just to remember, all the elements are:
- Operating System
- Tomcat
- Jenkins
- SonarQube
- Database (PostgreSQL by default)
- Proxy (Apache2 by default)
- CachéQuality plugin
