One of the toughest challenges for companies is when your employees require access to actual production environments. This is usually not part of the development cycle itself, but can become necessary when stuff goes wrong, or when you need to investigate issues that can’t be reproduced in a simulated environment (such as dev or staging environments).
Access To Production Is Hard
Accessing production environments is an operational challenge, as instead of the possibility of becoming “that someone who dropped a stage” you can become “that someone who caused an outage in production”. This means that you need to take precautions to help solve problems in production environments, while lowering the operational risks that something will go wrong.
Moreover, accessing the production environment is also a security risk. The effect of misconfigurations and vulnerabilities in non-production environments are usually low. However, when one of your employees, by malice or negligence, enables a breach on production environments, the effects can be catastrophic.
Finally, this can also become a compliance problem. Uncontrolled access to production environments can be either something you will need to spend resources to create permanent processes around, or if a permanent solution is out of reach simply find an on-demand solution.
In other words, while you would like to avoid granting access to production environments as much as possible, in many cases, there is simply no way around it, and such access has to be granted. Therefore, you need to ensure that the risks of exposure are as low as possible.
Access To Production Data Is Even More Risky
Until now we have discussed production environments in general. Now let’s specifically talk about production data and understand why the risks of inappropriate access to sensitive data are greater in the productive environment than in an application.
Production data may include, for example, PII or PHI data, which most employees should not have access to. Even those who may have the ability to access production data should do so minimally and using controlled access procedures. For example, employees who access customers’ PII data could alter customers data, or knowingly or unknowingly enable data breaches or frauds.
Taking On The Challenge
Besides our own experience with operating large-scale production environments containing sensitive data, we discussed this issue with many data and security leaders and developed solutions to this problem. The first part of this solution is to map the main security gaps that exist with access to production data.
The following are the main gaps we identified:
Visibility And Auditing
The first gap is having visibility into what employees are doing when accessing production data. An audit log can be useful to identify user access as well as for compliance, but it may not provide a complete picture.Further, visibility may be difficult to achieve, as in many cases there are databases scattered in different regions and composed of different technologies. Furthermore, in many cases, generic user credentials are used to enable access to those databases. When an employee is using a generic user credential, it makes it harder (and sometimes virtually impossible) to determine which specific employee accessed the production data.
Reducing Exposure By Authorization
Another typical gap is that temporary access to production data may paradoxically be less secure than permanent access to data. Whereas when a data analyst requires access to a specific dataset that can be well defined the processes and rules reduce exposure of sensitive data.The same can’t be said about temporary access to production data. For example, when an engineer requires access at 02:00 am on the weekend, to debug a production issue, there’s usually no time to iterate and authorize access in a granular way. And when issues persist, it is common to have such over-privileged access to data remain for several engineering users, or even to generic users.
Anonymization of Sensitive Information
It is hard to map all the places where sensitive information is located in the database, and creating a dynamic anonymization that allows users to solve problems while not being exposed to sensitive information is very difficult. As an example, creating and maintaining dynamic masking in various production databases specifically for the times when engineers will require access to those systems is not an easy project, and is also one that’s hard to prioritize.
Temporary Access To Data
Finally, enabling temporary, “just-in-time” data access, that can be given effortlessly but will automatically be revoked when it’s no longer needed is a big gap. Some organizations build such internal applications to enable access to production data, but as that data may be distributed across locations and technologies, this can become a project that’s hard to maintain.
Satori Enables Simple & Secure Access To Production Data
Satori is built in a way that is very well suited to solve the security gaps in a simple way for companies. This is because our data access controllers are reverse proxies, where you do not need to make any changes to database schemas in order to enable secure and controlled access to data. Instead, the access control is implemented in the transparent proxy that is between the users and the data stores.
For example, when an engineer requires access to fix or investigate a production issue, they can get access automatically through the Data Portal, with built-in security policies enabling them to access only the types of data required, and have that access revoked when it’s no longer needed.
Let’s see how Satori specifically addresses the mentioned gaps:
Universal Auditing And Monitoring
Satori automatically creates an elaborate data access log across all your data stores. The Satori audit process contains rich metadata and is available from a single location. The metadata includes the queries and commands executed on the databases, the types of data being accessed, information about the identity of the users, and more. As this audit is centralized, you can view in a single auto-generated report all the actions performed by a specific user across multiple data platforms, including your databases, data warehouses, and data lakes.
Managing Access in a Simple Way
Satori enables breaking down data objects into logical datasets. These datasets can be composed of data across multiple databases or even across different technologies. As creating and managing datasets becomes a simpler process that can be performed by “non-data engineers”, it is much easier to enable data access to specific locations without granting universal access.
Dynamic Masking And Fine-Grained Access Policies
Your data and security operators can create security policies that apply to data access by all users or parts of them. This may include dynamically masking sensitive data as it is being accessed. This may also include setting row-level security policies that are applied dynamically, even if the underlying database does not have such a capability. As an example, when engineers query data, they can only access data of users from a limited region.
Temporary Access to Data
Finally, Satori supports temporary data access and temporary privilege elevations. This can be done using certain workflows. Such workflows can enable certain groups to get access after supplying business justification and for limited time periods. It may also enable granting access through a data portal or slack integration, by giving an approval that does not require running any commands or changing anything in the environment.
Getting started is easy, as Satori does not require changing the environment itself. To understand how we can help you best, schedule a meeting.