Opensolr Information Security Policy

This document attempts to cover the Opensolr Data Security and Data Privacy policies that are already implemented and active. This is subject to change, so please check back for updates, or, Contact Us, with your suggestions.

1. Introduction

   1. The data flow that gets processed by and is stored by the Opensolr systems, is composed of 2 main components:
      1. Logical data
         1. Mainly composed of User Identification data, User Profile data.
         2. This data is used by Opensolr in order to provide users with the main Service Logic, which is the Solr Cloud Hosting Platform, along with it's adjacent services and user interfaces, that are accessible via RBAC (Role-Based-Access-Control) throughout the Service Platform Control Panel.
      2. Solr Data
         1. Consists of the data that the Opensolr Users, will host on the Opensolr Platform, in their own designated environment / server.
         2. This data is stored by Opensolr in datacenters worldwide, using third party hosting providers infrastructure, which includes, but may not be limited to the following partners, depending on prior user preference:
            1. AWS
            2. Hetzner
            3. HostHatch
            4. Alibaba Cloud

2. Confidentiality

   1. Both types of data defined above, are subject to our GDPR Information Security Policies, and our main privacy policy.
   2. Logical Data, is securely stored on the Encrypted Opensolr Main Data Servers, located in the AWS Cloud infrastructure.
      1. This is the data that identifies an Opensolr User, either under a free, paid, or blocked status.
      2. User activity logs data, is the data generated by each user under the Logical Data, in order to provide complete transparency on every action taken inside each user's account. These logs are also stored on the Encrypted Opensolr Main Data Servers, located in the AWS Cloud infrastructure.
      3. The Logical Data is only available to the Opensolr Account Owner via the Opensolr Control Panel.
      4. The Opensolr Control Panel implements the following security policies:
         1. User/Password Authentication
         2. Two Factor Authentication, that may be enabled by each user, via Authy, or SMS
   3. Solr Data, is securely stored as defined at #1, in a datacenter and/or cloud platform of each user's choice.
      1. The Solr Data, implements the following security policies:
         1. SSL Data transmission
         2. HTTP Authentication
         3. IP Access Based Authorization
      2. The Solr Data, is only available to the Opensolr Account Owner User, and the user's team members.
         1. The team members are verified Opensolr Accounts, that the Opensolr Account Owner has approved and invited to manage the indexes within their account.
      3. The Solr Data is not made public, unless the Opensolr Account Owner explicitly asks or provides documentation, that it is OK to do so, only via our Support Helpdesk service, which also serves as a Non-Repudiation measure.

3. Integrity

   1. In order to maintain data integrity, the following policies are implemented:
      1. Logical Data (User Identity Data), may not be updated/removed or changed in any way, by any Opensolr Employee, except on the following scenarios:
         1. Account Owner explicitly requests such updates, via our Support Helpdesk service, which also serves as a Non-Repudiation measure.
         2. Account Owner makes such changes when updating personal information, using the Opensolr Control Panel, which also keeps a record of each change.
      2. Solr Data is only updated/deleted or otherwise changed by the Opensolr Account Owner, and the Team Members as described above, only after passing the implemented security policies.

4. Availability

   1. All Opensolr authorized users, have timely and easy access to the Opensolr Services at all times.
   2. The Opensolr infrastructure and built-in technologies, always ensure data and systems availability, even during adverse conditions, such as data systems failures, etc.
   3. Opensolr therefore provides the following risk mittigation measures and policies, in order to ensure High Availability and resiliency:
      1. Solr Data Backup management tools, that allows the Opensolr Users to create, download or restore the Solr Data or Solr Configuration of their hosted Solr Indexes.
      2. Solr Index Replication that enables the Opensolr Users to create direct replicas of each Index, into a different region worldwide, for High Availability and Data Redundancy
      3. Main Opensolr Systems replication and redundancy, worldwide, in order to provide High Availability of the Opensolr Control Panel, and the adjacent systems therein.
      4. Custom and Third Party WAF (Web Application Firewall) systems, such as Apache mod_security.

5. Authenticity

   1. Opensolr uses the most secure SSL standards and configurations in order to provide secure and authentic data transfers across the entire Opensolr ecosystem.
   2. Opensolr does not require nor transfer biometric, or location data.
   3. All data being transfered via the Opensolr ecosystem is subject to the following policies:
      
      1. WAF AI verification, blocking or whitelisting.
      2. SSL Security Keys and fingerprint verification of each data transfer via html form security keys, for verification of authentic transmissions.

6. Non-Repudiation

   1. Opensolr holds detailed logs and revisions of each important data transfer, that pertains to User Identification and User Actions.
   2. Opensolr holds detailed logs and revisions of each User support interaction via our Support Helpdesk System

Here are the security mechanisms implemented by Opensolr.com

• IP Access rules per Request Handlers
  • Users are able to se certain Request Handlers (/select, /update, etc...) to be accessible from certain IP address, OR the "all" wildcard.
• HTTP Authentication 
  • ​Users are able to set a username and password for their index, so that every Request Handler in the index is only accessible upon valid HTTP Authentication.
• SSL connections
  • ​All connections throughout the entire Opensolr.com website, and throughout all of the opensolr cloud servers, are powered by state of the art SSL encryption.

In order to perform AJAX HTTP Authenticated requests, you will have to submit a support ticket, and let us know what are the origins where you are making your requests from, so that we can whitelist those, in our cloud infrastructure settings.

You will also have to indicate your index/cluster name, and account registration email address. 

• It is now mandatory, that every Opensolr index is password protected.
• When creating a new index, the default HTTP Auth credentials, are:
  • Username: opensolr
  • Password: Your account's Automation REST API KEY, that can be found in your dashboard, at: https://opensolr.com/admin/solr_manager/dashboard
• You can always change your HTTP Auth credentials, from your Opensolr Index Control Panel, by clicking on the Security tab, on the left side of the index administration menu.
• IMPORTANT!
  • When generating a new API KEY from your Control Panel Dashboard, that will NOT also change that as the password of your EXISTING indexes.
  • Only the NEWLY CREATED indexes, will adopt the new API KEY, as the password.
  • The existing indexes will continue to use the OLD API KEY from the time before you generated a new one.

• What is the log4j exploit?
  • Without going into too much detail, to make a long story short:
  • The log4j vulnerability (CVE-2021-44228) is an exploit that can be used by attackers (or anybody else) to execute remote code, on a vulnerable system, because log4j will actually grab any line in the log file, that matches a certain format, and execute that line as if it was a native command / program.
• Is the Opensolr service vulnerable to the lg4j exploit?
  • No. This vulnerability has been fully patched throughout the entire Opensolr ecosystem, on Dec. 11 2021.
• Did this vulnerability affect aything on my servers?
  • No. However, you should probably do the due dilligence of patching any Java application you may be running on your end or in your organization, if they are using log4j (which they most probably do).
• I am running Solr version 1 2 3 4 5 6 7 or 8. Am I safe?
  • Yes. This patch applies to all Solr versions. So you can keep running your Solr version that you are running now.
  • This is not a Solr vulnerability. It is a log4j vulnerability, which affects ANY Java applications that use the log4j library. So having log4j patched, will solve this issue for any Solr version.
  • However if you must use a different Solr version, you can go to your Opensolr Control Panel and add a new index, in a more recent Solr Version Container (server).
  • We can do that for you, but it's not going to be free.
• I am running Solr, and/or other Java applications with log4j on my own. What do I have to do?
  • Google is your friend (as opposed to the popular belief).
  • The websites it finds while searching for this topic, will give you hints and ideas about how to mitigate this exploit.

Dataimport (DIH) can not be reached

Due to certain security concerns, the dataimport (DIH) Solr feature is now globally disabled, form the entire Opensolr ecosystem.
However, you are still free to use the dataimport (DIH) Solr feature, by requesting that we enable it for your index(es), using our Support Helpdesk, at: https://opensolr.freshdesk.com/ or, directly via email, at support@opensolr.com

Important:

• It is now mandatory, that every Opensolr index is password protected.
• When creating a new index, the default HTTP Auth credentials, are:
  • Username: opensolr
  • Password: Your account's Automation REST API KEY, that can be found in your dashboard, at: https://opensolr.com/admin/solr_manager/dashboard
• You can always change your HTTP Auth credentials, from your Opensolr Index Control Panel, by clicking on the Security tab, on the left side of the index administration menu.

1. General data privacy terms

Becoming an Opensolr member, is only possible via the Opensolr Registration Form.
By becoming an Opensolr member, you agree with the Terms of Service, the General Privacy Policy, and this GDPR Privacy Agreement.

2. Data Collected by Opensolr

Opensolr collects mandatory minimal information about the user for the purpose of registration.
Such mandatory data is limited to: Email, Chosen Password.
Opensolr members, may at any time alter the Chosen Password.
The registration email address may only be updated through a formal request to support@opensolr.com
Opensolr members have the right, to optionally add more personal data, such as (but not limited to): Personal Website, Facebook ID, etc.
Opensolr members have the right, to optionally create Opensolr Cloud Index(es) and store any type of data in them.
Opensolr does not directly collect, store or process any personal, billing, or payment information from the Opensolr members or any other 3rd parties, whatsoever.
Your Opensolr Index Data (the data in your Solr Index), will never be reachable to the Opensolr staff, Opensolr Subcontractors, Upstream Service Providers, or any other 3rd party, without your consent, or, only if required by critical technical emergencies, in order to restore the Service to it's normal parameters.

3. Opensolr Personal Data Processing

Opensolr will never make public, any member's personal data information, nor will Opensolr ever sell or trade this information with any 3-rd party.
Opensolr will use the email as identification upon every login action.
Opensolr provides strict security measures for the data that is being stored and processed via the Opensolr Shared or Dedicated Cloud Servers.
Details on the Opensolr Cloud Data Security can be found at: https://opensolr.com/faq/view/security.
As stated at #2, Opensolr will never directly collect, store or process any billing or payment information from the Opensolr members, or any other 3rd parties, whatsoever.
All payments, and billing present on the Opensolr website, and, inside the Opensolr Billing Control Panel, is a front-end to the highly secure PCI Compliant, APIs of Stripe.com

4. Data Security

All data going through any Opensolr container, server, or other Opensolr infrastructure, is secured by SSL.
Our SSL certificates are re-keyed and re-issued every 1 year.
The Opensolr.com website, will alaways use EV-SSL.
All Opensolr accounts have the option to activate the Two Factor Authentication (TFA), via SMS or the Authy app. The TFA implementation is made via SSL requests to our TFA provider: Twillio.com

5. Communication

Opensolr will never send any unsolicited emails, postal letters, of any kind.
All Opensolr communications are fully mandatory when becoming an opensolr member.
All Opensolr communications will be limited to the following:

• System maintenance alerts
• System emergency failure or action alerts
• Membership alerts, such as (but not limited to):
  • Free trial expiration
  • Resource depletion (bandwidth exceeded, disk space exceeded, etc)
  • Other alerts which are otherwise vital to the Opensolr member, and the service provided by Opensolr.
  • Registration Welcome messages
  • Password retreival messages
• Periodic Opensolr Cloud Systems developments that are relevant to all Opensolr members.

To opt out of any of the above communications, please send a request to support@opensolr.com, for canceling your opensolr membership.

You can enable TFA in your Opensolr account as follows:

• Login to your account at: https://opensolr.com/users/login
• Navigate to User->Two Factor Authentication
• Enter your phone number
• Enjoy Two Factor Authentication the next time you logout/login!