This article explains how ZebraStream's keeps your transfer data safe.
Introduction
We regularly emphasize the wide range of data that ZebraStream can be used for. Naturally, if you hand over data to an intermediate party like ZebraStream, it really should be trustworthy. People often ask "How does ZebraStream process data?" and "Isn't ZebraStream using the cloud?". We always tend to say: "ZebraStream takes many safeguards to keep your data private, like all the other cloud services that you use. You can trust us, but ideally you shouldn't!". This seemingly paradoxical phrase is the most effective approach to IT security, the Zero Trust Model. At ZebraStream, we stick as close to this paradigm as feasible. This list of data protection measures ranges from a simple trust level to provability.
Access Tokens
Each ZebraStream address requires corresponding access tokens. These tokens are simple secrets, like traditional passwords, and are used to authenticate and authorize access. Access tokens always come with an expiration date and can be used to implement a robust rotation scheme. In addition, each stream address has a read and write end, so any data flow requires two independent valid secrets for both access modes (privilege separation).
The key strengths of using access tokens are that they are granular and time-bound, effectively isolating and minimizing the risk of data leakage, yet simple to use. That means that if you expose a single access token, it only affects a single stream address, and access can be easily revoked. However, access tokens are based on trust in our service and require that we validate them correctly.
Transient Data
Being a pure streaming data relay has an important advantage over, for instance, file exchange services or databases: every bit of data is transient. Even if someone illegally obtains a read access token, it only works during an active transfer and cannot be exploited retrospectively. ZebraStream applies the Principle of Least Data, which means that no data sent over a stream address is ever saved on disk. It needs no retention policy and no cleanup procedure.
You still need to trust ZebraStream and its infrastructure provider to discard your data after processing, but the fact that storing large amounts of data is expensive and makes no part of the operation service is a strong indicator that we do.
Transport Encryption
ZebraStream enforces the HTTPS protocol, which is based on the TLS transport encryption scheme. It is the same level of security that you probably use for any other web-based service, including your bank. This sounds good, but it is important to note that it simply means data cannot be intercepted traveling from the sender to the compute infrastructure, and again from there to the receiver. However, data traveling within ZebraStream's computing infrastructure is not secured by transport encryption. This is true again for every web-based service, including your bank.
Transport encryption eliminates so-called man-in-the-middle (MITM) attacks, if someone on the way, for example, in your local network or the internet provider, intercepts the data. However, you still need to trust ZebraStream and its infrastructure provider to do things right.
Open Source
ZebraStream requires software in three locations to operate: the sender, the relay, and the receiver. In other words, you run our software on your hardware and infrastructure. Whether this is a desktop computer, embedded device, web browser, or Linux container depends on the use case, but you must always assume that the software is not malicious and doesn't ship with faulty transport encryption, for instance. ZebraStream exercises maximum transparency by providing these client-side components as open source. This means that you don't have to take our word, but your experts can review the code or audit it externally.
End-to-end Encryption (E2EE)
E2EE can be considered the holy grail of the Zero Trust model. It turns trust into provable facts. For ZebraStream, using E2EE perfectly complements all other security features. When applied, a stolen access token can be used to gain access to data in the worst case, but not to read it. Not even ZebraStream's infrastructure providers can inspect transfer data. Storing such data would not only be costly, but also useless. Effective and provable E2EE requires open-source client software to prove that it is working and secure ("Hello WhatsApp!").
At ZebraStream, we are working on putting E2EE into client-side integrations using open and well-tested algorithms. However, E2EE is a client-side feature, and we can only promote and facilitate its use, but we cannot strictly enforce it. Mostly, it adds another layer of complexity to the integration code, making it less compatible with existing software. It remains our challenge to address this obvious conflict, and we help ZebraStream users to find the right compromise for their use case.
Summary
Simply put, the ZebraStream architecture minimizes security risks and the amount of trust users must put into the service. That being said, we ensure that we and our infrastructure providers are trustworthy and follow best practices and regulations, as laid out in our privacy policy.