Continuing our Summer of IoT blog series, we'll delve into the exciting new release of Cogent DataHub V11. For those that may have missed our previous post on Cogent DataHub V11 Features to Be Excited About, the entirely revamped security profile provides a Secure out-of-the-box experience for V11 users that opens a variety of customized options. Today we take a deep dive into a part of the security improvements, and next month we’ll take a second deep dive into security.
With this latest release, DataHub continues to boast a strong platform for MQTT Connectivity, through both its dedicated MQTT Broker and MQTT Client capabilities receiving updates to the compatible specifications of MQTT v5 and Sparkplug V3 adding on to existing MQTT V3 and Sparkplug B support.
One of the most significant security improvements in Cogent DataHub V11 is the introduction of enhanced role-based permissions. This feature allows you to define granular access controls for users, restricting their ability to publish or subscribe to specific MQTT topics. This enhanced security is crucial for:
The main function of a MQTT Broker is to act as a central hub of information, managing the flow of data across various connected clients. The decoupled nature of MQTT communications allows devices to operate individually of each other without the need of being online at the same time to exchange data, or even know about each other, or communicate directly between them in a many to many architecture. They simply publish or subscribe to relevant topics as needed and the broker handles the details.
Now, what if certain topics hold sensitive information that only certain users should have access to? Typically, if a client is connected with valid permissions to the Broker, it can easily find all the available topics maintained on the Broker. However, with the granular security controls available in DataHub V11 users can customize and control this access.
If you’re not already subscribed to our blog you’ll want to ensure you do as we have upcoming posts diving deeper into the new security model of DataHub V11 along with the continuation of our Summer of IoT series!
Now that we’ve overviewed the new enhancements to both MQTT and Security in this latest release, let’s look at how we can utilize these features in tandem.
Starting from the default state of a new DataHub V11 installation, there are a few important security settings to be aware of. In this new release, there is now the concept of Security Principals, which are a combination of specific allowed client IP ranges and protocols (“Interfaces”) in the example below.
The Internal Security Organization organizes the user accounts managed by the DataHub application inherently. By default, two Principals are already configured for the MQTT user. This means that user can access data via the Interface (protocol) shown and from the specified IP patterns, but for different roles.
The difference between these is their IP Pattern and assigned roles. Selecting the MQTT User and the principal associated with the local loopback address (127.0.0.1) will display the roles assigned. In this case, MQTT users connecting locally have both Basic Connectivity & All Data Full Access permissions enabled. The other Principal has different roles as you will see.
Let’s look at what the MQTT Client experiences with the above security configuration for the different principals and associated role sets. For the following examples we will utilize MQTT Explorer to connect with the DataHub Broker. First making a connection without any specified Username/Password from the local machine, the client has full access to available topics & data maintained in the Broker.
Comparing the same connection parameters from an instance of the client on a remote host machine, we can establish a connection, but none of the topics in the Broker are returned.
Looking into the DataHub Event log, we can see the Client connection is made but the subscriptions to all requested topics are denied.
Due to the enhanced default security settings of DataHub V11, remote connections are not inherently provided Data Access rights, only simple connectivity, which you can adjust this through configuration settings to further meet your needs. This secure by default approach will be appealing to your company cybersecurity teams.
Taking a step back into the security settings for MQTT, Principals require an IP Pattern utilizing the industry standard and well-known in IT CIDR notation. The usage of 0.0.0.0/0 signifies any connecting IP will adhere to the permissions, in comparison to the pattern 127.0.0.1/32 requires the first 32-bits of the connection IP to match what is specified, therefore only the local address of 127.0.0.1 adheres to these permissions.
Now, for users that may want to open the security policy for all remote connections while testing, simply select the Show Available box to list available Roles and check the AllDataFullAccess permission to allow any remote connection the same data access rights as you would have locally. It’s important to note, this is not a security recommendation nor considered best practice. Relevant permissions for users should be discussed with respective IT teams before making changes.
In the screenshot below, the Effective Permissions area at the right is very powerful for understanding the impact of changes before you apply them, and can help prevent unintended consequences, either from allowing too much access, or locking out critical access. You'll also notice the red "Change Report" tab and the red color on "AllDataFullAccess". Any uncommitted changes are shown in red intentionally, and the Change Report summarizes them. This provides another "are you sure" ability to check step before committing security changes.
Once the additional role is applied to the principal, and security changes are saved, let’s revisit the remote MQTT Client connection.
With the same connection parameters as previously utilized, reconnecting the client results in all topics appearing in the remote client connection. This has now allowed any external client to connect to the DataHub broker without any specified user information to access any topic.
Now that we've explored the internal users for MQTT and fully opened data access to all clients for testing purposes, we’d also like to cover the usage of creating additional roles to limit accessible data topics.
An important precursor in the DataHub MQTT Broker settings is to ensure Place all Points in this Data Domain remains unchecked. Unchecking this setting allows pre-configured Data Domains within the DataHub to be automatically defined as topics within the MQTT Broker. It will also allow us to limit which topics, within the DataHub Broker, MQTT Clients can publish and subscribe to when configuring custom Roles and User security settings. This will be important in our next example when creating a custom role. As you may have realized, but to be clear, DataHub Data Domains have nothing to do with Windows Domains in the Active Directory system. They are just a way to organize data within the DataHub.
While working with the new security model, it’s key to understand that Roles and Users are separate. Creating a new role will allow a permission set to be applied to a variety of users, including the internal users maintained by DataHub. Roles are also used with Security Principals that we discussed earlier as a way to manage permissions at scale. In this example, I will be creating a new user to independently observe the effects of the role applied. However, these practices can be applied to existing users as well.
Let's look at a use case of wanting to share a small subset of data with a specific business partner, part of the empowering secure sharing benefits of V11. Below I’ve added a new built-in user, Vendor1. This user currently has the role of BasicConnectivity applied to the single Principal to match any IP interfacing with MQTT.
In this scenario, let’s assume multiple outside vendors/users are interfacing with our DataHub MQTT Broker to both publish and subscribe to. There are multiple topics currently managed by the Broker, however, only certain topics are relevant to Vendor1, and we’d like to manage their access directly.
Opening the Roles tab from the Security Configuration presents a new window for users to create and modify custom roles. In the below image, we’ve created a new Role Vendor1_Source1Only which has its own list of Permissions Sets to select and modify.
Editing a Permission Set allows users to declare a Domain Pattern. This will limit the Data Domains Vendor1_Source1Only will have access to. Remember, previously we configured our Broker to automatically utilize the pre-configured DataHub Data Domains as the topics by unchecking "Place all Points in this Data Domain." Because of this, we can define our Domain Pattern to match a pre-configured Data Domain within the DataHub configuration.
In our previous example, our MQTT Broker contained four topics. In this example we are now limiting our new role to only apply the DataFullAccess permission set to the Source 1 domain.
Navigating back to the Users tab of the Security Configuration Window, we can now see the newly created role, Vendor1_Source1Only, is available under the Roles section. Selecting Vendor1_Source1Only provides a list of the effective permissions on the right, allowing us to review all permissions specific to our role in addition to Connect.
At this point, we’ve configured a new user for our DataHub and assigned it a custom Role to limit data access to a single domain/topic. With this configuration complete let’s connect the remote MQTT Client once again but with the Vendor1 user information.
Once the connection is established, we’ll also need to specify the topic request to only include the information we’ve defined access for. Attempting to utilize the default topic identifier # will be denied by the Broker due to insufficient user permissions. Below I have configured the client subscribe to our configured Domain Pattern, topic Source 1/#. The addition of the number sign indicates to include any sub-topics within Source 1.
With the topic defined, we have finalized the configuration of the client and can review our results. With the username provided by the remote Client we can successfully subscribe to all topics under the Source 1 data domain, without retrieving additional topics defined in the Broker.
Cogent DataHub V11 empowers users to build and maintain secure IoT communications through its newly expanded security model. With enhanced MQTT capabilities and granular user access controls, V11 ensures that your data is protected while facilitating seamless communication within your IoT environment.
As we continue our Summer of IoT series, we'll delve deeper into other powerful features and enhancements with Cogent DataHub, along with our broader product portfolio, helping users get the most out of their investments in Cogent DataHub or decide that it’s time for DataHub to be part of their solution stack.
Ready to try out DataHub V11 for yourself? Download the free trial today.