People and applications often need temporary access to a data repository. Cyral enables you to offer fast access by allowing users to chat with a bot in Slack to request access and then, if the request is approved, granting temporary access according to your policies. This type of access grant is available for SSO-authenticated users.

Request and grant repository access in Slack

The Cyral Slack app is a ChatOps integration that lets employees get on-demand, authorized access to data repositories. By chatting with the /cyral bot in Slack, database users can find repositories, request read access, and be alerted when their request is approved. Admins can approve data access requests and find repositories and sidecars.

Once ChatOps ephemeral access has been set up for a repository, users can:

• request access to specific sensitive resources (for example tables and columns) in the repository; or

• request access to the repository without specifying tables or other specific resources in the repository. In this case, if the request is approved, your standing policies determine the user's access. For requests of this type, you as administrator can also set up automatic approvals for requests whose requested access duration fits within the limit you've specified.

Terminology of ephemeral access with the Cyral Slack app

• ephemeral access: Permission (typically for a limited time) to read data. Users request this permission by chatting with the Cyral chatbot in Slack. Ephemeral access cannot be used to grant users insert, update, or delete privileges.

• ephemeral policy: When a user asks the chatbot for access to specific sensitive resources, and that request is approved, an ephemeral policy is created to grant the user read access to data. These policies work along with your standing policies in Cyral, and, for data read operations only, the ephemeral policy overrides conflicting read limits from your standing policies. For chatbot requests that don't specify sensitive resources (requests to access the repository as a whole), no ephemeral policy is needed, and the standing policy determines access. 

• standing policy: These are the existing (typically long-term) sets of data access rules you've specified in the Policy tab of Cyral. They can be used to grant users read, insert, update, and delete privileges.

• datamap and sensitive resources: When you give users the ability to request ephemeral access to a repo, you have the option of declaring specific data locations in the repository (for example, tables and columns) as sensitive resources. You specify sensitive resources by including them in your datamap. The user can request access to these sensitive resources by name, and if approved, will have read access only to those resources listed in the approved request.

Policy interaction between ephemeral policies and standing policies

Your standing policies remain in effect when you use ephemeral access, but ephemeral access grants can override parts of them. Let's look at how policies interact:

1. If the approved request did not specify any sensitive resources, access to sensitive resources is governed by standing policies as usual.

2. If the approved request did specify sensitive resources (say R1 and R2), then for the duration of the grant:

   • the user can read resources R1 and R2, even if access to these resources is prohibited by standing policies.

   • the user cannot read any sensitive resources other than R1 and R2, even if access to these resources is permitted by standing policies.

   • write access (insert, update, delete) to all sensitive resources (including R1, R2, ...) is governed by standing policies. This is unaffected by the resources specified in the request.

Note: If a user already has ephemeral access to sensitive data and generates a new request, once the new request is approved, it will overwrite that user's existing ephemeral access with the new sensitive data requested and with the new duration, running from when it was approved

What happens when an access request is approved?

An ephemeral policy is generated when a grant request with sensitive resources is approved. This policy permits reading only the specified sensitive resources and no other. For the duration of the grant (and for this user), this ephemeral policy overrides standing policies with respect to read access to sensitive data. If the request does not specify any sensitive resources, this ephemeral policy is not generated and access is governed by standing policies as usual.

Write access to sensitive resources and all resources in the repository continues to be governed by standing policies.

Set up the Cyral self-service access integration for Slack

Prerequisites

• In Slack, find or create a channel where repository administrators can receive and handle access requests using the Cyral app.

  • This can be a public or private channel.

  • Cyral recommends that you dedicate a channel for this, so that requests don't get lost in the traffic of a busy channel.

• Before you begin to add the Cyral app, make sure you're logged into your Slack workspace using an account that has permission to add apps. By default, Slack allows any user to add the app to their workspace, but the manager of your Slack workspace may have placed limits on this.

Procedure

To add the Cyral Slack app:

1. Open the Cyral management console and navigate to the Integrations page.

2. On the Slack Bot tile, click Configure.

3. Click Add to Slack.

4. Slack displays a dialogue saying that the Cyral is requesting access to your workspace. Choose the channel where the app will chat with your employees, and click Allow. The Cyral app will also show Approve and Deny buttons in this channel, and it can DM users to notify them if their request was approved or denied.
   
   Once the app has been added to a Slack workspace, the bot will be visible to all users in the workspace and they can interact with it. Users can chat with the bot from anywhere by typing /cyral followed by a command. Type /cyral help to list the bot's commands.

5. Invite the repository administrators to the app's channel. This channel is where they will receive incoming access requests and approve and deny them.

6. Make sure each repository administrator has the Modify sidecars/repositories permission in Cyral, which is included in the default Admin and Super Admin roles.

7. All data users and repository administrators should connect their accounts using /cyral connect as explained in Connect your Slack account and Cyral account, below. It's important that administrators connect as soon as possible, so that they can start handling requests.

8. For each repository that will support access requests via Slack, you must enable SSO in Cyral. To do this, see Authenticate repository access with SSO

Set up local accounts to support access grants in Slack

1. Set up one or more local accounts on your repository (link  ) add them to Cyral ( link  ). These are the native accounts used to connect users to the repository.

2. Optional: If this local account will be used to service requests to the repository as a whole (requests that don't specify which sensitive resources the user wants to access), then you have the option of setting up auto-approvals for access requests for this account. To do this:

   1. In the Auto Approval section, toggle the checkbox on.

   2. In the fields just below that, specify the maximum duration that the user can request and still have their request auto approved.

3. Click Track.

Define sensitive resources

Defining sensitTo define sensitive resources:

1. Click the Datamap tab in the Cyral control plane UI.

2. Edit your datamap to include the data locations of all sensitive resources in the repository.

3. Save the datamap.

Once you've created a local account with access to this repository, your users can request access to any of the resources you've listed in the datamap.

Here's an example datamap entry for a repo called customer-accts-pg. Once you define a local account for this repository, the attributes listed here will become available for users to the request in the Sensitive Resources field of the chatbot:

CS_SLACKBOT_ACCESS:

  - repo: customer-accts-pg

    attributes:

      - cs.customer.city

      - cs.customer.id

      - cs.customer.name

      - cs.customer.zip_code

Set up your standing policy to default to deny access

If you wish to ensure that users will not have access to sensitive data except that granted through this mechanism (that is, if the users should not have any data access in the repository unless they request it through the chatbot), then you should define your standing policies so that all access is denied (except possibly to specified exempt users). In other words, for any repository where you've defined sensitive resources, your standing policy should include no rules that grant the local account access to data resources you don't want to expose through ephemeral access grants. In addition, make sure your policy does not have a default rule providing access to such resources.

Provide Cyral permissions for your chatbot requesters and approvers

Both the requesters and the approvers who use the chatbot must have appropriate permissions in Cyral to interact with repositories and their details. In most installations, all requesters are SSO users mapped to the User role in Cyral, and all approvers are SSO users mapped to the Admin role. In this case, no further permissions setup steps are needed.

If your Cyral installation does not use the standard role mappings, set up the following permissions. For details, see https://cyral.com/docs/account-administration/acct-manage-cyral-roles#map-an-sso-group-to-a-cyral-administrator-role 

1. Map the SSO accounts of all requesters to a role with the following permissions in Cyral. (These are provided in the pre-configured User role)

   • View Sidecars and Repositories

   • View Datamaps

2. Map the SSO accounts of all approvers to a role with the following permissions in Cyral. (All of these are provided in the pre-configured Admin role.)

   • View Sidecars and Repositories

   • View Datamaps

   • Modify Sidecars and Repositories

   • Modify Policies

Using the Cyral app in Slack

Connect your Slack account and Cyral account

Before you can perform actions with the Cyral app in Slack, you must connect your Slack user account to the account you use in Cyral. This allows the Cyral app to report on who's doing what and to check which repository-related actions you're authorized to do. Both users and administrators need to do this.

To connect your account:

1. From anywhere in Slack (for example in your personal channel) type /cyral connect to log in to your Cyral account:
   

2. In your browser, Cyral shows a page where you can authorize the Cyral app, allowing it to see your profile information. Click Yes to authorize, and you'll see a notification in the browser and in Slack.

Cyral app commands in Slack

Once you've connected your Slack account to Cyral, you can use the app's commands from anywhere in Slack. Start by using the /cyral help command to show a list of commands:

Listing repositories and sidecars

/cyral list repos

/cyral list sidecars

Requesting access to a repository

To request access:

1. Type /cyral request to launch the dialog window.

2. Provide the request details: 

   • Data Repository is the name of the repository

   • Local Account is the name of the database native account you'll use to connect.

   • Sensitive Resources lists the data resources (like tables or columns) you'd like to access. When a resource has a set-member structure, as in a table with columns, you'll have the option to choose individual members  or the set. For example, if your sensitive resources are two columns in the table sales, columns sales.prod_name and sales.sku, then the drop down will let you choose from sales.prod_name, sales.sku, and sales, which includes both sales.prod_name and sales.sku.

The chatbot won't force you to make a selection here; follow your administrator's guidance and specify resources if required. Click on the field to expand the list, click on the names of the desired resources, and click outside the list to close it.

• Access Duration is the length of time for which you want to have access, expressed as a number and a single-letter abbreviation: m for minutes, h for hours, or d for days.

• Note is an optional message to the approver, telling them why you want access.

3. Click Request Access to submit your request. You'll receive a response in chat when the administrator approves or denies it.

Once you run the command, your data repository administrators get a notification in the Cyral app's Slack channel. Once they approve it, you'll get a direct message in Slack similar to:

Approve an on-demand access request

Prerequisite

Make sure you're a Cyral administrator with at least the Modify sidecars/repositories permission in Cyral.

Procedure

When someone requests access to a data repository, the request will appear in your Slack access-requests channel. (Ask your Cyral administrator for the exact name of the channel).

For information about how on-demand access works in Cyral, see grant timed access to a user or group.

Once you approve, Cyral informs the person via the access-request channel in Slack, and they can log in to the repository using their SSO credentials.

Revoke an access grant

If you approve a request in error, you can revoke it by clicking the Revoke button in the Slack channel. Alternatively, you can find and revoke sessions in the Cyral management console by going to the Data Repos section, clicking your repository's name, clicking the Identity to Account Map tab, finding the session you want to revoke, and clicking the trash can icon.

Cyral informs the user via the access-request channel in Slack that their access has been revoked. If the person has a current session in the data repository, that session ends and no new session can start until the user gets a new approval.

Manage on-demand access requests

To manage on-demand access sessions go to the Data Repos section, clicking your repository's name, clicking the Identity to Account Map tab, and find the session you want to manage. Here, you can view and revoke current on-demand sessions, as well as enable and disable ephemeral access for this repository.

Read the audit logs from chatops requests and approvals

In the Audit Logs section of the Cyral control plane UI, you can track the following events related to access requests, approvals, and denials:

• Requests for data access

• Administrator approvals of data access requests

• Automatic approvals of data access requests

• Denials of data access requests

• Revocations of data access requests

Here's an example entry for an approved access request:

{

  "approver": "rdiez@cyral.com",

  "duration": "1h",

  "localAccount": "bob",

  "repo": "rafael-pg",

  "requester": "jlo@cyral.com",

  "sensitiveResources": [

    "public.slackbot_demo.city",

    "public.slackbot_demo.id"

  ],

  "source": "slack",

  "status": "success"

}