Learn all about Staffbase Protect and how it provides you with a secure platform.
A high-quality software as a service (SaaS) platform not only offers features and integrations that make business operations easier and drive growth, but also prioritizes the safety of your organization's and users' data. As the digital landscape rapidly evolves, providing strong platform security is becoming increasingly challenging due to the rise of sophisticated cyber threats that pose a significant risk to all SaaS providers. These malicious attacks can result in extended periods of downtime and make your App or Intranet more vulnerable to further attacks. For example, in a distributed denial of service (DDoS) attack, your network is flooded with a series of requests that exhaust Staffbase servers' resources, making your App or Intranet unavailable to users. Hackers can also exploit your platform's vulnerability during such attacks and steal sensitive information, causing even more security issues.
Staffbase Protect is a powerful tool that helps you mitigate these security risks. It uses Cloudflare solutions to detect and neutralize cyber attacks before they reach the Staffbase infrastructure. To achieve this, Secure Sockets Layer (SSL) connections, a security protocol that creates encrypted links between the Staffbase client and the servers, are terminated at Cloudflare's infrastructure. This enables Cloudflare to analyze the traffic flowing to the Staffbase infrastructure for potential threats. Staffbase Protect offers many benefits for your platform. Learn more.
The Cloudflare servers act as the initial destination for routed traffic. Once the traffic reaches the Cloudflare servers, it is decrypted to undergo a thorough inspection for potential cyber threats or signs of attacks. After the inspection, the traffic is re-encrypted and forwarded to the Staffbase servers. It's important to note that the traffic is always encrypted during transit. On the other hand, malicious traffic is blocked from reaching Staffbase servers.
If you are on the EU hosting infrastructure for Staffbase services, the traffic, including metadata, does not leave the EU in an unencrypted form. However, if you have opted for US hosting infrastructure, the traffic excluding metadata is only served from the US. Staffbase ensures this by using the Cloudflare Data Localization Suite.
If a user uses your App or Intranet from a location outside of Europe, their encrypted traffic is sent to a server in the EU before being decrypted for inspection. After inspection, the traffic is encrypted again and sent to the Staffbase infrastructure.
A standard If you are on the DNS setup for your App or Intranet involves the following steps:
- The Staffbase client uses a custom domain, such as example.customer.com, to access the App or Intranet.
- The custom domain has a Canonical Name (CNAME) record, which points back to the domain. For example,
examplecompany-custom.staffbase.com - The CName domain, in this case,
examplecompany-custom.staffbase.com, then points to a fallback domain. For example,fallback.de1.staffbase.com - Finally, the fallback domain
fallback.de1.staffbase.comis resolved to Cloudflare IP addresses that are geographically closest to the user’s device.
This way, Staffbase routes the traffic from your domain to Cloudflare to analyze the oncoming traffic. Cloudflare filters out malicious traffic and allows only legitimate traffic to reach the Staffbase servers. This ensures that your users do not experience any downtime due to malicious attacks and that your organization and user data remain protected.
Staffbase blocks network ports other than 80 and 443 on the higher layer in the network stack as per Cloudflare requirements. Cloudflare's edge nodes, which serve multiple customers as shared resources, have various ports open at a lower level of the network stack. As a result, if you perform a port scan on your domain, you might see some ports appearing as open, even though they are not accessible for your specific use. For more details on blocked traffic, see the Cloudflare documentation.
➜ ~ dig customer.example.com @1.0.0.1
; <<>> DiG 9.10.6 <<>> customer.example.com @1.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36321
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;customer.example.com. IN A
;; ANSWER SECTION:
customer.example.com. 108 IN CNAME example-custom.staffbase.com.
example-custom.staffbase.com. 181 IN CNAME fallback.de1.staffbase.com.
fallback.de1.staffbase.com. 181 IN A 141.101.90.98
fallback.de1.staffbase.com. 181 IN A 141.101.90.96
fallback.de1.staffbase.com. 181 IN A 141.101.90.99
fallback.de1.staffbase.com. 181 IN A 141.101.90.97
;; Query time: 52 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Tue Jan 23 14:30:01 CET 2024
;; MSG SIZE rcvd: 172