DevOps Build Considerations for GDPR Readiness

What types of data flow through Build?

As a software deployment an integration engine, Build does not require sensitive personal data to be gathered from the client or the client's clients.

Personal data used for online contact with IBM

Build clients can submit online comments/feedback/requests to contact IBM about product topics in a variety of ways, primarily the comment areas of the following, as applicable:

Please review:

Typically, only the client name and email address are used, to enable personal replies for the subject of the contact, and the use of personal data conforms to the [IBM Online Privacy Statement] (https://www.ibm.com/privacy/us/en/).

Data Collection

Please review:

Data Storage

Deployments are orchestrated by the server and performed by agents distributed throughout the network. The file store, CodeStation, contains log files, artifacts, and other non-structured data objects. Reporting tools can connect directly to the relational database.

The file store manages artifacts in a secure and and tamper-proof repository that ensures deployed artifacts are identical to those tested in preproduction environments.

Protection

Build uses several technologies to provide security. Some features cannot be disabled, such as Transport Layer Security (TLS) for JMS communication. Other features can be configured to meet client requirements. Some features are enabled by default, such as end-to-end JMS encryption, while others are disabled by default, such as mutual authentication.

Please review:

Data Access

The Build team- and role-based security system manages user interactions and secures product features. Roles control virtually every product area, including the objects that users can create and who can modify the security system itself. User-created objects are managed by teams. Team members can only access objects, such as applications, managed by their team. Team members interact with team-managed objects according to the permissions granted to their role.

Read more: * UCB team-based security model.

Authentication:

Build uses mutual authentication for JMS-based server-agent communication. In this mode, the server provides a digital certificate to each agent and agent relay, and each agent and agent relay provides one to the server. Certificate checks are performed by the JVM according to its own algorithm. Certificates can be issued from a certification authority (CA) if desired, in which instance certificates do not have to be swapped. The integrity of the content is established by the mechanisms built into TLS technology.

Logging administration activity:

Administrative activity is kept in the system logs. instances when the admin user adds a user or changes a users role and permissions are tracked in the log.

Please review:

https://www.ibm.com/support/knowledgecenter/en/SS8NMD_6.1.3/com.ibm.ucbuild.doc/ucb61_welcome.html

Data Processing

Users control the way in which Build interacts with data passing through it by their definition of application processes. A process is commonly constructed by a user acting in the role of “developer” working with the component plug-in toolkit. A process is composed of discrete building blocks (known as steps) that are joined together by the developer.

Agents play a central role in Build processing. An agent is a lightweight process that runs on a deployment-target host and communicates with the Build server. Agents perform the actual work of software deployment which relieves the server of the task. All processes requested by the server are executed on hardware assigned to agents.

Who has access to the Data?

Most customers import users from external LDAP realms. Clients filter LDAP account data for the information they need, such as user IDs, email addresses, and passwords. Groups that the imported users belong to are also imported.

Permissions are assigned to roles and users and groups are placed into roles when they are placed onto teams. Users without roles have read-only privileges and cannot access data let alone modify it.

Encryption:

Communication between server and agents uses a JMS-based (Java Message Service) protocol and can be secured using SSL and TLS, with optional mutual key-based authentication for each end-point. This communication protocol is stateless and resilient to network outages. End-to-end JMS encryption ensures that agents cannot send messages to one another after they are connected to the JMS mesh. It also ensures that JMS clients cannot read messages that are not sent to them. End-to-end encryption ensures that agents do not accept messages from rogue servers or other malicious entities.

When mutual authentication mode is active, Build uses it for JMS-based server-agent communication. In this mode, the server provides a digital certificate to each agent and agent relay, and each agent and agent relay provides one to the server. Certificate checks are performed by the JVM according to its own algorithm. Certificates can be issued from a certification authority (CA) if desired. The integrity of the content is established by the mechanisms built into TLS technology.

Unless the client uses a certification authority, the server stores the certificate from each agent in its trust store, and each agent stores the server’s certificate in its trust store. If the client uses agent relays, certificates are swapped between agents, agent relays, and the server. Connections are rejected if the recipient cannot find the sender’s certificate in its trust store.

Please review:

https://www.ibm.com/us-en/marketplace/urbancode-build

https://developer.ibm.com/urbancode/products/urbancode-build/

https://developer.ibm.com/urbancode/plugins/development-community/

https://developer.ibm.com/urbancode/plugins/all/

https://developer.ibm.com/urbancode/blog/

https://developer.ibm.com/answers/smart-spaces/23/urbancode.html

Data Deletion

Please review: