How You Can Use Our New Open-Source Database Access Control Tool 

We made this open-source tool to secure our most sensitive Apache Cassandra database and now you can use it too.

We’re releasing an open-source tool you can use now, which we developed as a homemade Just-In-Time database access control tool for our sensitive database. This tool syncs with our directory service, slack, SIEM, and finally, our Apache Cassandra database. Get the code here on Github.

We developed this open-source tool with two key priorities in mind:

1. Customers’ data is our top priority.
2. Risk management is an essential part of security management.

As a startup company, some of our our security controls controls rely on manual policies and processes. As our R&D team at Intezer grew, it became harder to follow manual security procedures, which presented new unnecessary risks. We decided to produce more automated and robust security controls on our Apache Cassandra database through risk management.

Requirements for Our Open-Source Access Control Tool

With automation and integration based on our current supportive products, we wanted to gain a better access control mechanism, better audit on What \ When \ Who, stronger RBAC and entities management, full password policy adherence, and last but not least – better visibility.

To address this wishlist, it was apparent we needed a service that will be capable of a few main goals:

1. Implementing an automatic Just-In-Time (JIT) secure access to the database.
2. Implement database access based on a least-privilege approach.
3. Implement an automatic Role-Based access control mechanism.
4. Implementing an automatic Database user provision and deprovision.
5. Reduce the effect of bad password practices.
6. Gain visibility on access requests and access grants.
7. Friendly and easy permissions request.
8. Deploy in a scalable and stable environment.
9. Support change management policy.

We had three options to meet these goals:

1. Find a commercial tool.
2. Find a relevant open-source project.
3. Develop and deploy in-house.

In the end, we chose # 3.

Let’s elaborate on each goal.

Implementing an automatic Just-In-Time (JIT) secure access to the database.

JIT is a fundamental security practice where the privilege granted to access applications or systems is limited to a period of time. Access is on an as-needed basis.

With JIT, we gain:

1. Reducing the risk of using standing privileges\passwords.
2. Grant time-based granular access that expires on a predefined due time.
3. Simplifying user and roles administration.
4. Adding a critical time dimension to the security equation.

One of the challenges we faced was creating an automatic JIT process rather than creating JIT accounts manually to manage privileges. This was an issue we’d need to solve.

Implement database access on a least-privilege approach.

We’ve applied a least privilege strategy by controlling:

1. The permissions\role levels a user can invoke.
2. Which actions users can perform once they have accessed the database.

This is mainly to enable the temporary elevation of privileges to allow human and non-human users to access specific privileged credentials and accounts or to run privileged commands.

Implement an automatic Role-Based access control mechanism.

RBAC’s approach also goes along with the least-privilege approach.
We described three types of roles a user can ask and grant:

1. SELECT – read-only level
2. MODIFY – read\write level
3. ADMIN – Database admin

Each Role is assigned with an expiration time.

Implementing an automatic Database user provision and de-provision.

Users, entities, and permissions management is a hassle. Manual user management is usually a recipe for disaster. Improper user management can generate risks such as forgotten elevated credentials of a leaving employee user.

So Intezer is using Jumpcloud. We are using Jumpcloud as a directory and group management, among its other features.

To implement Directory-based access control within the service, we’ve designed the process to gain Jumpcloud’s API and have the Database users provisioned and de-provisioned according to the Jumpcloud user group state. 

Reduce the effect of bad password practices.

Some Databases are not featured with user and password management, especially regarding password policy enforcement.

One of the prerequisites for this solution was to take out the user’s control of password creation and management and implement a self-generated password service that hands the credentials as a one-time temporary token aligned with the company’s password policy.

Gain visibility on access requests and access grants.

Visibility is an essential control for security.

A must-have defined prerequisite – record and privileged audited activity across all ephemeral accounts enable alerting and response to abnormal behavior or action.

Visibility is built in our SIEM.

Friendly and easy permissions request.

Security is a business enabler rather than a show-stopper.

One of the prerequisites was letting the database user ask and get his credentials in a seamless and friendly way, yet secured!

Requests for permissions will come from Slack, assuming that the existing Slack users are personal, authenticated, secured, and managed (provisioned\deprovisioned) with Jumpcloud.

Slack bots are fantastic. We have integrated the service with a current Slack bot used by the R&D users and other relevant stakeholders. The returned credentials are sent to the requester as a private Slack message to prevent credentials theft or misuse.

Deploy in a scalable and stable environment.

As the service is a gateway to production assets, it must run in a fault-tolerant environment.

Docker is the right way here.

Support change management policy.

We adhere to compliance and policies.

Change management is enforced with a Jira ticket once an employee is asked to access the database with MODIFY permission.

Service components:

1. Jit-Service is a REST API web service with five main capabilities:
   1. Accepts (with validation & authentication) HTTP(s) requests from slack.
   2. Invoke jumpcloud API for user validation.
   3. Invoke Cassandra for role settings and password\token management
   4. Returns HTTP response with a one-time token to access the database.
   5. Logging.
2. TTLING Service:
   1. Invoke jumpcloud API for user validation and provisioning.
   2. Revokes expired one-time tokens.

Both services are running in Kubernetes environment.

How TTL mechanism works:

Each role (SELECT\MODIFY\ADMIN) granted is attached with a value of time portion and a timestamp.

E.g., MODIFY: 1 hour.

TTling service is responsible for ensuring every couple of minutes that timestamp is not due.

Visibility & Alerting

Both services provide detailed logging.

We have pre-defined risks and security use cases and addressed logging for each. The services developed in-house made it easier to make sure we log precisely what we need for visibility and alerts.

• Visibility addressing audit such as database access, requested and granted permissions.
• Alerting addressing use cases such as abnormal behavior, service abuse, unauthorized requests.
• Logs are consumed with Splunk Universal forwarder, installed in each container when services are running.

Slack Execution

Conclusions

With the development and vast API capabilities on supportive systems such as Jumpcloud and Splunk, we minimized risks and strengthened our security. By sharing this information and open-source code, we hope it will help you automate access control and keep your organization secure.

Check out the open-source project on Github so you can start using automatic Just-In-Time (JIT) secure access for your databases too.