Why Cyral?
Identity Federation for Shared User and Service Accounts
Maximum Flexibility, Zero Trust.
Do you know who’s accessing your data?
Typical IAM solutions don’t work for databases and data lakes
Many popular databases don’t support SAML and OIDC protocols. Most business users access data using BI tools which use a single service account shared across all users, creating a security vulnerability that could be solved with better identity and access management.
Introducing Identity Federation
The age-old challenge with databases has been inability to manage which users access what data. This is because traditional databases like PostgreSQL and MySQL do not support native SSO capabilities. Organizations have to either painfully manage provisioning for each user individually, or, what is often the case, their users end up sharing credentials amongst each other.
When a modern database like Snowflake or Redshift does support native SSO, either through Okta or similar IAM, they are accessed using BI tools and apps such as Looker, Tableau, Thoughtspot, etc. Even though hundreds of users may be using these tools, the database only sees activity from a single service account.
Cyral provides Identitiy Federation which enables customers to get complete visibility and control over data activity by individual users.
Identity Federation provides:
Federated Authentication for User Accounts
The Cyral sidecar sits inline between users and data repositories, and brokers authentication requests. This enables users to authenticate themselves using their IDP credentials.
Service Account Resolution
Cyral provides protocol-specific logic that can extract user identity information from the request sent by the various apps and tools to the repositories.
Enriched Visibility
Cyral generates activity logs enriched with user identity information. This gives security teams complete visibility into who accessed which data, from where.
Dynamic Access Management
With Cyral you can create access-control permissions and restrictions based on well-defined rules that can include the job or role of the user, the account they want to access, and the data within the repo. The permissions can be pre-configured by administrators ahead of time, or granted just in time based on access requests from users.
Network Addresses
Cyral sidecar can be configured to limit the client IP addresses from where requests to the data repository can be allowed. This can be used to expose the underlying repo to applications on the internet, while protecting them from unwanted traffic.
SSO Groups
With Cyral, administrators can specify which accounts users can access within a database depending on their SSO group. This enables easy, role-based access administration and eliminates the need to create unique accounts for each user.
On-call Schedule
Cyral can restrict access to privileged accounts only for users who are on call at a given point in time. This helps ensure least privilege access, while fully enabling engineers working on incident resolution.
Ensure Least Privilege Access for your Data Mesh
Cyral enables administrators to ensure least privilege for all their databases and data lakes without impeding user workflows or creating organizational friction.
Access to a database can be configured for only specific users, and the permissions set to expire with time.
Customer databases can be set up without any standing access, with ad-hoc approvals to enable users to log in.
Activity from business users can be restricted while enabling them complete access to their tools and dashboards.