Share your data securely
Privacy and security are built into Lianja Cloud. With account security features like two-factor authentication, Lianja Cloud helps keep your data secure, protects your privacy, and keeps you in control of your information. Additionally, Lianja Cloud is implemented in a multi-tenant containerised architecture preventing other subscribers from having any access to your private data.
User Roles and Permissions
Share your Apps and Data securely with others in your company, business or team using user specific Roles and Permissions.
You can control who can do what in your Apps by securing them using "Roles and Permissions".
After creating or editing users you can "Export" the users and "Import" them in the Lianja Admin Console.
Row Level Security
Row Level Security (RLS) is a concept that provides security at the row level within the database layer, instead of at the application layer. With this feature you can implement RLS without changing your application code.
Row-Level Security enables customers to control access to rows in a database table based on the roles (or groups) of the user accessing data.
Row-Level Security (RLS) simplifies the design and coding of security in your application. RLS enables you to implement restrictions on data row access. For example ensuring that workers can access only those data rows that are pertinent to their department, or restricting a customer's data access to only the data relevant to their company.
The access restriction logic is located in the database engine rather than away from the data in applications. The database system applies the access restrictions every time that data access is attempted.
While designing the architecture of this functionality we looked at how it is implemented in other industry standard SQL engines and found all of them to be overly complex and long winded, so we came up with a simpler approach which is more flexible.
Row level security in Lianja is accomplished using row filters. Each row filter is associated with a tenancy, database, table and role name.
When a user authenticates, the tenancy and username determine the roles assigned to the user.
Whenever a database table is accessed, the database engine will lookup the row filters associated with the table based on the roles that the authenticated user has been assigned.
If a user has a specific role and a row filter exists for that named role then the row filter associated with that role is included (OR) from the records that can be read.
If the role name is negated e.g. ~manager and the user does not have manager role, then the row filter is excluded (AND NOT) from the records that can be read.
These row filters operate across native Lianja tables and virtual tables, so you can use them with MSSQL, MySQL, PostgreSQL and other third party SQL databases also.
When defining row filters for Virtual tables you should specify the name of the virtual table as the table e.g. vt_customers.
Row filters are transparent to the application in desktop, web and mobile apps as well as OData API calls. In other words, no application changes are required in order to benefit from row level security in Lianja.
Row filters can be applied to a specified table in a specified database for one or more roles. Records that do not satisfy the row filter will be hidden for users with any of these roles. See documentation for further details.
Dynamic Data Masks
Dynamic data masking (DDM) limits sensitive data exposure by masking it to non-privileged users. It can be used to greatly simplify the design and coding of security in your application. Dynamic data masking helps prevent unauthorized access to sensitive data by providing the ability to designate how much of the sensitive data to reveal with minimal impact on the application layer. DDM can be configured on the database to hide sensitive data in the result sets of queries over designated database fields, while the data in the database is not changed. Dynamic data masking is easy to use with existing applications, since masking rules are applied in the query results. Many applications can mask sensitive data without modifying existing queries. See documentation for further details.
Database tenancies provide you with the ability to deploy an App once for multiple customers but have separate databases specific to each. See documentation for further details.
The Forensics tab in the Lianja Admin Console displays database timeline information showing details of record updates, inserts and deletions. The header buttons and fields allow the view to be configured for a specific database and/or table, date, user, location, operation or column. See Understanding Database Timelines for full information on database timelines.