All the micro-services are replicated and segregated among several virtual machines and isolated from the Internet through a VPN.

High availability is ensured by replicated and distributed services that scale up according to the number of connected products, connected clients, and the frequency of the data issued to the cloud.

Communications between micro-services are limited and allowed only within the segregated and encrypted network.

Critical services (blue services) are not directly reachable by the API Gateway and thus from the Internet, only the primary services (green services) have a counterpart interface exposed by the API Gateway.

All the public endpoints are hardened by a WAF (Web Application Firewall) with all the modern and up-to-date mechanisms to prevent hacking, any form of denial of service, Cross-Site Request Forgery (CSRF) and DDoS (Distributed Denial of Service) attacks.

All communications between Web clients and the API Gateway are allowed only through the secure HTTPS protocol.

The only opened port is 443, all other ports are not available and unsecured HTTP usage is not allowed.

The requests made on the 80 port are automatically forwarded to the 443 secure port.

Previous and deprecated versions of SSL (SSL*, TLS 1.0) have been disabled and not allowed, TLS 1.1 is deprecated and will be removed soon.

All API calls must be made by sending a JWT token obtained during the login with valid credentials.

The JWT token, obtained during the user authentication, has a predefined duration of 1 hour, after such a period the client has to refresh the token to keep using the API.

For more details about API endpoints refer to the How to deal with REST APIs article.

All the protection mechanisms described above for the Web Interface are also valid for mobile integration, which means a Mobile App is able to communicate with the Servitly backend.

As additional protection, logins performed from a Mobile App must be made by issuing an API Key (32 alpha-numeric characters). The Servitly backend will check the correctness of such an API key matching some specific properties, like the application identifier or package name.

The communication between the connected products and the IoT Connector is made by using one of MQTT, HTTP or CoAP protocols over a channel encrypted with TLS 1.2.

Previous and deprecated versions of SSL (SSL*, TLS 1.0, TLS 1.1) have been disabled and not allowed.

Encryption of the payloads exhanged through one of the built-in connectors is not support. In case the channel encryption is not enought, Servitly can be integrated with third-party IoT Connectors, like AWS IoT Core or Azure Service Bus.

The user authentication is made by issuing the personal email address and password provided during the registration phase, optionally, users may configure the Two-Factor Authentication based on one-time tokens.

No user sessions are handled or persisted by the backend.

During the login phase, the page and the underlying API will not return the error code indicating whether the email is invalid or the password is invalid.

Each user account registered in the DPS is associated with a set of permissions used to verify grant access to the API.

The login page is protected with a Google reCAPTCHA V3, and after 5 failed logins, the backend will ask the user to complete a challenge (Google reCAPTCHA v2). In case of 10 failed login, the account can be disabled for 30 minutes (optional).

User accounts inactive for a few months can be deactivated automatically after being notified several times; the period is configurable (default 1 month).

Account administrators can decide to delete the account, including all client data, device data, and user data.

Optionally, if the plugin is configured, users can log in by using an identity provider based on OpenID (e.g. Google, Microsoft, Ping One). 

Passwords

All the passwords configured by the users are stored with a one-direction encryption algorithm (BCrypt), which grants that no one except the caller is knowing the clear password.

To avoid simple passwords, all the passwords are validated during the initial entry with these constraints:

Optionally, the duration of users' passwords can be limited, otherwise, by default, there is no expiration.

Data Isolation

All the DPS data including customer data, user data, metric data, alerts, products, and accounts are stored within a segregated database that is not externally reachable.
To improve security and privacy, metric values are anonymized and stored separately from the product information data or user account data.

Servitly is a multi-tenant solution, which means that different tenants may share the same infrastructure including databases, but in any case, a user belonging to a tenant cannon access the data of another tenant. When a client obtains a JWT token, this is bound to a specific account, and for no reason, it can access the data of another account.

The isolation mechanism is applied from the tenant, and it descends through organizations, partners, customers, and locations also according to the account authorizations and permissions.  

For each request, the API Gateway verifies the account context in order to check whether the request can be performed, and add additional conditions to limit the final query on the database. 

Micro-services, front-end resources, and databases are installed on the following data centers and availability zones.

Thanks to the cloud provider and the distributed architecture, Servitly has high reliability with an uptime of up to 99.5% (less than 3.6 hours/month).

For more details about system status, refer to the status.servitly.com page, which is based on the third-party service Uptime.

A periodical security assessment is conducted on the Servitly platform, services, and source code to discover possible security issues and test if all the security requirements are verified time by time.

All the software, libraries, and operating systems composing Servitly are periodically updated with the last available stable versions and security patches, to grant maximum coverage against malicious use of the services or unauthorized access.

Each service, feature, and software composing Servitly is developed or configured by taking into account all the security principles and recommendations of each vendor.

Servitly has been developed considering the OWASP principles and best practices, whose updates are verified time by time and integrated.

Periodically, VA/PT tests are performed by an independent, certified company, and all discovered vulnerabilities are resolved according to their severity.