Data Security

Column-Level security

Column-Level Security (CLS) enables access control to virtual database table columns based on the user’s group membership, allowing for example to implement restrictions on column access to protect sensitive data or ensuring that specific users can access only certain columns of a table pertinent to their department. The virtual database applies the access restrictions every time that data access is attempted.

Row-Level security

Row-Level Security (RLS) enables you to use group membership to control access to rows in a table.

Row-Level Security simplifies the design and coding of security in your application. RLS helps you implement restrictions on data row access. For example, you can ensure that workers access only those data rows that are pertinent to their department. Another example is to restrict customers’ data access to only the data relevant to their company.

The access restriction logic is located in Lyftrondata which applies the access restrictions every time that data access is attempted.

Here are design examples of how RLS can be used

• A hospital can ensure that allows nurses to view data rows for their patients only.
• A bank can ensure that access to financial data rows based on an employee’s business division or role in the company.
• A multi-tenant application can enforce a logical separation of each tenant’s data rows from every other tenant’s rows. Each tenant can see only its data rows.

RLS filter predicates are functionally equivalent to appending a WHERE clause to each query that attempts to access the table that has RLS condition defined. The predicate can be as sophisticated as business practices dictate, or the clause can be as simple as WHERE TenantId = 42.

In more formal terms, RLS introduces predicate based access control. The predicate is used as a criterion to determine if the user has the appropriate access to the data based on user attributes.

Data masking

Data masking is the process of applying a mask on data to hide sensitive information and replace it with new data or scrubbed data.

For more information see Data masking.

Data Pseudonymization

Data pseudonymization (encryption) in Lyftrondata works transparently to the end user.

Here are the steps needed to make use of Lyftrondata's automatic data pseudonymization:

• classify data as sensitive in the pass-through database (VDB directly connected to the source), using metadata editing. For example, set “Lastname” column from CRM as holding sensitive information.

• classify connection to the data processing system that handles the cache as untrusted and provide a seed value to use

If any user decides to cache sensitive data to the untrusted system, Lyftrondata will automatically detect that sensitive data is being stored and will encrypt the data. The user will not detect that encryption happened because he or she will see real data from Lyftron, even if processed by the untrusted system.

Properties of data encryption built into Lyftrondata :

• Data is encrypted using reversible encryption and obfuscation, for example, a text will not be human-readable, while numbers and dates will and will hold fake data.

• Encrypted data types are preserved, for example, varchar(80) and datetime types will not change in the encrypted result. Encrypted data types can be changed manually in a view using specialized SQL functions: QUA_SHUFFLE and QUA_DESHUFFLE.