Sensitive data stored in Elasticsearch and OpenSearch is vulnerable to hackers. Secure it with searchable, drop-in, application-layer encryption.
Searchable encryption so you can encrypt and then search
Reduce risk by protecting data at the application layer
Application-layer encryption (ALE) provides strong protection against breaches, unauthorized insider access, injection attacks, and cloud misconfigurations.
Protects your sensitive data while allowing rich analytics
Secure personally identifiable info (PII) and other data without losing your ability to find or run analytics on it. Works with logs, user-generated content, and other enterprise data.
Comply with privacy and security regulations
Meet the strictest data security obligations without losing functionality. Comply with the data protection requirements in privacy laws by encrypting the data.
Drop-in protection without code changes
The Cloaked Search proxy sits in front of your search cluster and doesn't require code changes or plugins to use so you can seamlessly encrypt and search.
Why it matters
Your search service is a treasure trove of data and a hacker's dream
Too often companies focus on the primary data storage but ignore the secondary ones like the search service and log data, which can contain incredibly sensitive information and are rich targets for attackers and impulsively curious insiders.
Integrates with your existing search service
Data protection for always-on cloud servers
Encryption requires the correct key to unlock the data. But when you use low-level encryption like database or disk encryption, the key has already unlocked the data and stays in memory for as long as the server is running. This doesn’t do much to protect data in the cloud.
The alternative is application-layer encryption (ALE) which encrypts data before storing it and keeps the key(s) separate from the data. It’s a simple, but powerful concept that often prevents network breaches, cloud misconfigurations, and application vulnerabilities from turning into costly data breaches.
No key, no access
What is encrypted search?
A search index is much like a book index. It contains a list of words that point back to the locations where they appeared. But this data can be used to recreate the entire book. And in most cases, the search service actually retains the original book, too. Yet for most companies, the data in the search index isn’t protected at the same level as other data stores.
Encrypted search is a technique that encrypts both the raw data and the index. The data can still be searched over without decrypting it, but anyone who wants to search it must have the right key. The server is blind to the data it holds and to the meaning of the searches that are made.
All the search functionality you need without the risk
|Query logic||George AND (Coffee OR Mug)|
|Exact phrases||"IronCore Labs"|
|Phonetic matching||Kathryn == Catherine|
|Field and subdocument search||title:security author.name:george|
|Single and multi-tenant||Key per data segment|
|Complex result rankings||(weighted fields, etc.)|
|Multi-index||Search multiple indices at once|
You choose which fields to encrypt on which indices. You can do everything on unencrypted fields, and nearly everything on the encrypted ones.
Encryption is best suited to text fields such as name, email, address, health data, and user-generated content. Nearly all of the functionality you love from Elasticsearch and OpenSearch can be used over the encrypted data.
While not everything is supported, for example, you can’t do regular expression searches over the encrypted data, all of the most commonly used features are.
And most of the time, you don’t even have to change your code.
How it works
Drops in as a proxy between your app and your search service
Single key standalone mode
In standalone mode, a single key is loaded into the proxy at startup and that key is the root of trust for securing all the data. This is the simplest deployment available. Simply configure which fields you want encrypted in which indices, then point your code to the proxy instead of the search service.
Multi-key advanced key management
When you need different keys for different segments of data or when you want to make sure the service provider (eg, Amazon, Google) can’t gain access, then you can integrate SaaS Shield as a key orchestration component for keeping master keys in one or more independent key management servers. This is especially useful for multi-tenant SaaS and customer-held encryption key patterns.
Built for people who need to use the sensitive data they hold
Find your encrypted data without sacrificing security
Secure sensitive customer PII in Elasticsearch or OpenSearch without compromising on privacy or data security.
Encryption means customer PII remains safely locked away so you can comply with GDPR, CCPA, and more.
No need to reinvent the wheel or rewrite your code. Keep existing code and infrastructure.
Learn more or give it a try
Read our docs
Check out our thorough documentation that explains deployment, configuration, and internals in depth.Read the docs
Use the online demo
Explore an already-running instance seeded with data and a web interface for you to explore and learn.Try the live demo
Try it locally
Get started with a local
docker image to try it out. Just follow the instructions
in our try-cloaked-search GitHub repo.