Security Framework

Architectural Security

The architecture behind the DPS is designed following the principles of defense-in-depth, with the goal of minimizing the attack surface and isolating potential security breaches.

• Layered System Design

  The layered architecture model separates responsibilities across different tiers, including presentation, application, processing engines and data layers.
  Each layer enforces strict access controls and validation, ensuring that unauthorized access is blocked even if another layer is compromised.

• Network Segmentation and Isolation
  Critical services (blue blocks) are deployed within isolated network segments using a virtual private cloud (VPC), subnets, and security groups.
  Public-facing components such as the Web Frontend and the API Gateway reside in a demilitarized zone (DMZ), while backend services and databases are shielded within private subnets with no direct internet access.
  Only non-critical services (green blocks) are accessible from the API gateway.

• Web Application Firewall

  All the public endpoints are hardened by a WAF 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.

• Microservices and Container Security

  The platform leverages a microservices architecture deployed through virtual containers.
  Each microservice operates with the principle of least privilege, and it is restricted via network policies.

• Zero Trust Principles

  No component is trusted by default, authentication and authorization are always enforced.
  Any communication is secured via mutual TLS, and identity is verified continuously through short-lived tokens.

• Secure Cloud Infrastructure

  The platform is hosted on a leading cloud provider (AWS, MS Azure) with built-in physical and infrastructure-level security.
  Infrastructure as Code (IaC) tools are used to manage cloud resources, enabling consistent configurations and security policy enforcement across environments, and reducing the risk of human error during update activities.

• Redundancy and Fault Tolerance

  Security is also about resilience, so the architecture includes load balancing, automated failover, and multi-zoned deployments to ensure the availability also during attacks or infrastructure outages.
  For more details about the architecture you can refer to the DPS Architecture article.

Account and Identity Security

Protecting user identities and access is in the first place of a good security strategy.
A robust identity management system ensures that only authorized users can access specific resources, and every action in the DPS is verified and traced.

• Strong Authentication Mechanisms

  The user authentication is made by issuing the personal email address and password provided during the registration phase.
  OpenID Connect is used for single sign-on (SSO) and identity federation.
  The Two-factor Authentication (MFA) enforces an additional layer of security preventing the theft of ceredentials.
  The session duration can be limited forcing the user to perform a periodic login (configurable).

• Secure Password Policies

  All passwords are stored using strong, adaptive one-way hashing algorithms, with unique salts per user. In this way only the user knows his password.
  Password complexity rules (8 chars min length, one lower char, one upper char, one special char, no dictionary nor public words) can be configured, and in combination with API rate-limiting mechanisms, brute-force attacks are prevented.

• Role-Based Access Control

  Each user is assigned to a User Type providing the minimum permissions necessary to perform their duties, minimizing the impact of a compromised account.
  Access to data (including single properties) is governed by role-based access control (RBAC) .
  For more redetails refer to the Business Entities article.

• Session and Token Management
  All sessions are secured via HTTPS-only with a short-lived JSON Web Tokens (JWT) for stateless authentication.
  The JWT token has a predefined duration of 1 hour, after such a period the client has to refresh it to keep using the API.

• Account Recovery and Identity Verification

  Critical account management workflows (e.g. password reset) require secure identity verification (OTP via email), CAPTCHA protection (Google reCAPTCHA v3).
  After 5 failed logins, the application ask the user to complete a challenge (Google reCAPTCHA v2). In case of 10 failed attempts, the account can be disabled for 30 minutes (configurable).
  User accounts inactive for a few months are deactivated automatically after being notified several times; the period is configurable (default 6 month).

• Logging

  User update operations are logged and also include the user who performed the update.
  Login attends, user activities are logged and made available through the audit.
  

REST API Security

All communication within and across the DPS is designed with confidentiality, integrity, and authenticity.
Every data transmission through APIs is protected against interception and tampering.

• End-to-End Encryption

  All data in transit is encrypted using Transport Layer Security (TLS) version 1.3.
  Previous and deprecated versions of SSL (SSL*, TLS 1.0) have been disabled and not allowed, TLS 1.2 is deprecated and will be removed soon.
  The HTTPS is enforced across all API endpoints and frontend static resources.
  Non-secure HTTP requests are automatically redirected to their secure equivalents.
  The HTTP/2 protocol and ALPN are supported.

• Certificate Management

  TLS certificates are issued by a trusted Certificate Authority (Let’s Encrypt CAs), and certificate renewal is automated (every 2 months).
  Strict Transport Security (HSTS) headers are applied to protect against downgrade attacks.
  For more details abut certificates refer to the SSL Certificates article.

• Secure API Access

  APIs are protected using OAuth 2.0-based token authentication.
  Clients must issue a signed JSON Web Tokens (JWTs), which is validated for each request and renewed periodically.
  A request rate limiter prevents the abuse of API requests.

• Secure WebSockets and Messaging

  Real-time features such as WebSockets and message queues are secured using encrypted channels and authenticated endpoints.
  Only authenticated sessions can initiate or maintain real-time connections, and message brokers enforce ACLs (Access Control Lists) per topic and queue.

• DNS Security

  The DPS uses the Amazon Route 53 DNS server to map tenants names and domain to the specific environment.
  For more details about DNS security refer to the Security in Amazon Route 53 page.

• Content Security Policies and Headers

  All frontend responses include HTTP security headers such as Content-Security-Policy (CSP), X-Content-Type-Options, X-Frame-Options, and Referrer-Policy to reduce attack vectors like XSS, clickjacking, and content injection.

Third party Software Integration

In case a third party client must integrate the DPS APIs, an API Key (32 alphanumeric characters) used to limit the requests rate and permissions is required.
An API Key can be defined:

• directly in the DPS by a customer, partner or organization.
  For more details refer to the End-user API Keys article.

• in the Servitly Console to integrate external services more broadly.
  For more details refer to the API Keys article.

The Servitly backend, at each request, verifies the correctness of the API Key by matching some specific information, like the domain name or application ID for Mobile applications.
In addition to user credentials (email and password), authentication can occur by issuing PATs (Personal Access Tokens) that are managed directly by DPS users.

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

IoT Connectors Security

• End-to-End Encryption

  All data in transit is encrypted using Transport Layer Security (TLS) version 1.3.
  Previous and deprecated versions of SSL (SSL*, TLS 1.0) have been disabled and not allowed, TLS 1.2 is deprecated and will be removed soon.

• Certificate Management

  TLS certificates used by built-in IoT Connectors are issued by a trusted Certificate Authority (Let’s Encrypt CAs), and certificate renewal is automated (every 2 months).
  For more details about certificates refer to the SSL Certificates article.

• Data Publishing Limits

  A Publishing Rate Limit prevents publishing too much data, which can cause servers to slow down or, even worse, denial of service.

• DNS Security

  The DPS uses the Amazon Route 53 DNS server to map tenants names and domain to the specific environment.
  For more details about DNS security refer to the Security in Amazon Route 53 page.

• Content Security Policies and Headers

  All frontend responses include HTTP security headers such as Content-Security-Policy (CSP), X-Content-Type-Options, X-Frame-Options, and Referrer-Policy to reduce attack vectors like XSS, clickjacking, and content injection.

• Messaging
  Invalid and not compliant messages are automatically discarded.

In addition to these security features here are specific features for each IoT Connector.

Third party IoT Connectors

When product data is transferred to Servitly via an external IoT platform, the communication between the IoT Connector and the external platform is permanently established via an encrypted and authenticated cloud-to-cloud channel.
The security of the communication channel depends on the third party provider.
For more details refer to the Third Party Connectors article.

Data Isolation

Data isolation is essential to preserve confidentiality, maintain regulatory compliance (e.g. GDPR, SOC2, ISO27001), and ensure that users access only the data they are authorized to see.
The Servitly platform is designed to enforce strict boundaries between tenant, user, and data, both logically and physically.

• Physical Isolation
  All the DPS data including customer data, user data, metric data, alerts, products, and accounts are stored within segregated databases that are not reachable by any external API.
  To improve security and privacy, metric values are anonymized and stored separately from the product information data or user account data.

• Multi-Tenant Isolation

  In the Servitly multi-tenant architecture, each tenant’s data is logically separated.
  Every request includes a tenant-specific context, which is validated at every layer, from API Gateway to database query, preventing data leakage across tenants.

• Row-Level Security and Access Control

  Row-level security (RLS) is enforced to ensure users can only query data they are authorized to access.
  Combined with tenant isolation, this prevents horizontal privilege escalation across users (Customer-A cannot access data of Customer-B).
  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 includes additional conditions to limit the final query on the database.

• Environments Isolation

  The Develop and Staging environments use data with the same isolation principles mentioned above.
  Non-production environments cannot access production data as the environments are physically separated, event if the tenant is the same.

Secure Development Practices

At Servitly we embrace the security-by-design approach, where security is built into our development life cycle, from the first line of code to deployment and maintenance.
Our development practices ensure that vulnerabilities are identified early, mitigated, and prevented.

• Secure Software Development Life Cycle (SDLC)

  We follow a secure SDLC model that integrates security activities into each phase, from requirements and design to coding, testing, and deployment.
  Security requirements are documented, and a threat analysis is conducted during the design phase for major features.

• Code Analysis and Review

  All code is scanned using automated static code analysis tools to detect vulnerabilities.

  Peer reviews are mandatory for every critical code commit.
  Reviewers use security checklists and are trained to recognize insecure coding patterns.
  For critical modules, we implement pair programming and assign a senior developer to perform in-depth security reviews.

• Library Management
  All libraries and packages are checked and monitored for new vulnerabilities (CVE).
  Unused libraries are regularly removed.
  New library versions are installed as soon as they are available and sufficiently tested.

• Secure Coding Standards

  Developers follow language-specific secure coding guidelines (e.g. OWASP Top 10).
  Each included third party software is integrated and configured by taking into account all the security principles and recommendations of the vendor.

• Environment Hardening and Secrets Management

  Development and staging environments use the same security settings as the production environment.
  Secrets such as API keys, tokens, and certificates are stored in encrypted vaults and securely injected into runtime environments.
  Each environment before its deployment has passed a hardening procedure in order to:

  • remove/disable all unnecessary system services/daemons and insecure tools;

  • disable all unnecessary ports;

  • change/disable/remove all default credentials;

  • configure ACL;

  • configure the firewall and iptables;

  • configure security rules from the cloud provider management interface.

• Continuous Integration and Security Testing

  Security checks are integrated into CI/CD pipelines.
  Periodically, VA/PT tests are performed, and all discovered vulnerabilities are resolved according to their impact and risk.

• Developer Training and Awareness

  All developers undergo regular security training, including workshops and internal documentation.
  Periodically, disaster recovery simulation sessions are conducted to train the team and highlight any gaps or weaknesses in the procedures.