Immer mehr Unternehmen nutzen Apache Pulsar für das Echtzeit-Messaging. Der zunehmende Einsatz in geschäftskritischen Bereichen bringt jedoch neue Security-Herausforderungen mit sich. Wie Sie Apache Pulsar sicher konfigurieren und vor Missbrauch, Datendiebstahl und anderen Risiken schützen, zeigt dieses Whitepaper.
Inhalt:
Apache Pulsar ist ein cloud-nativer, verteilter Messaging- und Streaming-Dienst, der ursprünglich von Yahoo kreiert wurde. Heute führt die Apache Software Foundation Pulsar als Open-Source-Projekt fort.
Apache Pulsar zeichnet sich unter anderem durch einen nativen Support von Multi-Cluster-Umgebungen, sehr niedrige Latenzzeiten und eine nahtlose Skalierbarkeit aus. Eine einfache Client-API ermöglicht den Zugriff aus gängigen Programmiersprachen wie Java, Go, Python oder C++.
Die zunehmende Verbreitung von Pulsar für Echtzeit-Messaging auch in geschäftskritischen Umgebungen stellt allerdings auch erhöhte Anforderungen an die Sicherheit der Plattform. Hier setzt dieses Whitepaper an und stellt Best Practices für die Apache-Pulsar-Sicherheit vor.
Sie lernen unter anderem:
- Welche vier Ebenen Sie in Ihrem Security-Ansatz berücksichtigen müssen.
- Wie Sie Daten bei der Echtzeitübertragung vor Missbrauch und Diebstahl schützen.
- Wie Sie Identity and Access Management in ihre Messaging-Umgebung integrieren.
- Wie Sie mit Luna Streaming die Sicherheit von Apache Pulsar erhöhen.
Originalauszug aus dem Dokument:
Message Retention and Purging
One standard way to prevent data leaks is to simply delete data that is no longer required. Pulsar provides several mechanisms to assist with this. The first is that for a given topic, you have the option of configuring it as either persistent or non-persistent (ephemeral). Topics of either type can be easily identified by inspecting the fully qualified topic name. Persistent and non-persistent topics will begin with persistent:// and non-persistent:// respectively.
Non-persistent topics will never have their data persisted to BookKeeper. This can be convenient for use cases which need to be optimized for performance or for cases where message data loses its value if not immediately processed. This same capability can also be beneficial for cases where you want to avoid persisting sensitive data all together such as in the context of payment use cases or where patient medical data is involved.
For cases where message persistence is desired, but where you want to purge data after a certain period of time, you can configure message retention policies at the namespace level within Pulsar. This is convenient if you have data which is subject to regulatory compliance such as GDPR where the commonly recommended practice is to retain applicable personal data for only as long as necessary before purging it from your system. Using this capability in Pulsar you can set a retention period that is appropriate for your organization, say 60 or 90 days, after which message data will be automatically purged from the system.