Control Access to Your Data with Slack Enterprise Key Management and AWS KMS

By Joe Norman, Partner Solutions Architect at AWS

We see more and more organizations adopting software-as-a-service (SaaS) for their workloads, gaining benefits like easy implementation, quick update cycles, and simplified costing.

One of the trade-offs of SaaS, however, is that you have to trust the provider with access to your data. For today’s security-conscious organizations, this can seem like a deal breaker.

Slack, an AWS Partner Network (APN) Advanced Techology Partner, has become a vital tool for collaboration for teams and companies around the world, and we are excited about the launch of Slack Enterprise Key Management (EKM).

By integrating with AWS Key Management Service (KMS) in a customer’s AWS account, Slack EKM gives you tighter control over access to data that is stored in Slack.

How it Works

With Slack EKM, you can use KMS in your own AWS account to create a Customer Master Key (CMK) that always stays under your control. Then, using key policies, you grant Slack access to use your CMK to generate and decrypt data keys.

Figure 1 – KMS provides the ability to add optional encryption context.

With this level of access to your master key, Slack can perform envelope encryption on customer data stored in Slack. At a high level, the encryption process looks like this:

1. Slack receives a new message or other data from a customer enrolled in EKM, holding it in plaintext initially.
2. Before storing the data, Slack checks its key cache for a suitable data key and, if none is found, generates one using the KMS GenerateDataKey API, using the permission granted by the key policy associated with that key. AWS KMS uses the CMK to generate a data key and returns a plaintext copy and encrypted copy to Slack.
3. Slack uses the plaintext copy of the data key to encrypt the data and, finally, stores the encrypted copy of the key along with the encrypted data.

When it comes time to decrypt the data, the process works in reverse. Slack makes a Decrypt request to KMS, sending along the encrypted data key. KMS then uses the CMK to decrypt the passed-in key and returns the data key in plaintext. From there, Slack is able to decrypt the data.

The important point is that you always control access to use the CMK to generate and decrypt the data keys, using a key policy. You can choose to revoke access to your CMK at any time, making it impossible for Slack to decrypt your data until you restore access.

Benefits of Slack EKM with AWS KMS

This integration between Slack EKM and AWS KMS provides you with following benefits:

• Visibility into key usage: AWS KMS is integrated with AWS CloudTrail, giving you visibility of every API request. You can log and analyze every request made of your keys stored in KMS. Slack EKM also sends data points to Amazon CloudWatch, giving you visibility into every action taken with the CKM and data keys.
  .
• Granularity of control: Slack EKM was designed to allow you to revoke access on a granular level, rather than all-or-nothing. Slack never has access to your CMK other than via the key policy you create and control. Access to encrypted messages and files can be revoked at the organization, workspace, channel, time-frame, and file level in Slack. We’ll go through an example of this in the next section.
  .
• Non-breaking access revocation: Even if you choose to revoke access to some data in Slack, your teams will continue to be able to use the software, though they’ll be unable to access the data that has been restricted.
  .
• FIPS-validated hardware security modules: AWS KMS allows you to control permissions to use your keys while taking care of their durability and physical security. Plaintext CMKs never leave KMS-controlled FIPS-validated hardware security modules.

Example: Locking Down a Time Period

In that call to GenerateDataKey shown in Figure 1, KMS provides the ability to add optional encryption context. Encryption context is a set of key-value pairs that are cryptographically bound to the encrypted copy of the data key—such that it cannot be decrypted without an exact match of the context being sent in the Decrypt request.

Slack EKM takes advantage of encryption context, so you can use them to create more granular key policies.

Below is an example of the key policy you would initially apply to your CMK during Slack EKM setup to grant Slack the access it needs to freely encrypt and decrypt your data:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "Grant Slack EKM access to decrypt and generate data keys",
    "Effect": "Allow",
    "Principal": {
        "AWS": [
            "arn:aws:iam::111111111111:root",
            "arn:aws:iam::222222222222:root"
        ]
    },
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
    ]
    "Resource": "*",
  }]
}

This policy gives Decrypt and GenerateDataKey KMS API access for the associated CMK to two Slack AWS accounts. These two account numbers will be provided to you by Slack during EKM setup.

Let’s say you learned of a discussion in a particular channel on March 18, 2019 that covered sensitive information you don’t want to keep available in Slack. Add the statement below to your key policy on the CMK used by Slack EKM:

{
    "Sid": "Revoke a channel for a period of time",
    "Effect": "Deny",
    "Principal": {
        "AWS": [
            "arn:aws:iam::111111111111:root",
            "arn:aws:iam::222222222222:root"
        ]
    },
    "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "kms:EncryptionContext:C": "C0G8QF9DF"
        },
        "StringLike": {
            "kms:EncryptionContext:H": "2019-03-18T*"
        }
    }
}

The key policy statement shown above blocks two Slack accounts (the accounts will be provided by Slack as part of Slack EKM setup) from decrypting any data keys, and therefore any data encrypted by those data keys, as well as making new keys, when the channel context is C0G8QF9DF and the hour context is any time on March 18, 2019.

Each top-level element of the policy statement is described below:

• Sid: This is just a free entry field to allow you to identify different statements in the policy.
  .
• Effect: This can be Allow or Deny. In this case, we want to Deny access to some actions on the CMK.
  .
• Principal: Here, you list the actors to which you want to grant or deny permission. The actors are the two AWS accounts Slack provides during EKM setup and uses to access your CMK. You use an Amazon Resource Name (ARN) with the 12-digit account number and “root,” which makes the statement include the entire account, not just the root user. You can also use an alternative shortened format that foregoes the “arn::…” structure and just lists the 12-digit account numbers.
  .
• Action: List the actions you want to deny. We’re blocking the ability to decrypt data keys and make new ones—the only two permissions used by Slack EKM—but these will only be denied if the conditions that follow are true.
  .
  If you deny key generation and try to write new messages in this same time period, like if you block access for today’s date, Slack will give you an error message. You can also opt to continue to allow GenerateDataKey and only deny Decrypt. This setup allows Slack to encrypt new messages in a matching encryption context, but prevents Slack from decrypting them later.
  .
• Resource: Using an asterisk in the key policy just makes the statement apply to “this CMK.” Key policies only apply to the CMKs they’re attached to.
  .
• Condition: Here, we’re providing two strings for comparison. If a request has matching strings for both conditions, the policy will deny access to the actions. So we’re looking for two encryption contexts defined by Slack: “C” indicates the Slack channel ID, and “H” is the date and time down to hour granularity.
  .
  To get the channel ID of a Slack channel, if you know the name, you can use Slack’s channels.list method or from the URL, if you view the channel in a browser.

While this is one small example, hopefully you can start to see how you can combine key policies with the encryption contexts provided by Slack EKM to take full control over access to the data you store throughout Slack.

Getting Started

Slack Enterprise Key Management (EKM) is available for Slack Enterprise Grid customers.

Visit the Slack EKM website and Slack will guide you through the requirements for setting up the service and creating the required keys and permissions in your AWS account.

The content and opinions in this blog are those of the third party author and AWS is not responsible for the content or accuracy of this post.

.

Slack – APN Partner Spotlight

Slack is an APN Advanced Technology Partner. It’s collaboration hub brings the right people, information, and tools together to get work done. From Fortune 100 companies to corner markets, millions of people around the world use Slack to connect teams, unify systems, and drive business forward.

Contact Slack | Solution Overview

*Already worked with Slack? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.