Staffbase Protect

Learn all about Staffbase Protect and how it provides you with a secure platform.

Employee App
Front Door Intranet

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.

How Staffbase Protect works

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.

Staffbase Protect

How Staffbase Protect works based on your hosting infrastructure

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.

DNS setup

DNS (Domain Name System) translates human-readable web addresses into Internet Protocol (IP) addresses that allow clients and servers to communicate with each other.

A standard DNS setup for your App or Intranet involves the following steps:

  1. The Staffbase client uses a custom domain, such as example.customer.com, to access the App or Intranet.
  2. The custom domain has a Canonical Name (CName) record, which points back to the domain. For example, examplecompany-custom.staffbase.com
  3. The CName domain, in this case, examplecompany-custom.staffbase.com, then points to a fallback domain. For example, fallback.de1.staffbase.com
  4. 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 platforms have DNS already configured this way and do not need additional setup to implement Staffbase Protect.

Example

    ➜  ~ 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