Traditional access management of the AWS console and other resources that a developer might need is seen as a speed bump: a point of friction that causes contention, breaks rhythm, grinds the gears of your developers, and proves a constant annoyance to the neighbors (whichever unlucky senior ops person has admin privileges).
Worse than the speed bump itself is the fear of it. Many companies delay establishing proper security controls because they know what a drag it can be on productivity and morale. The prospect of going from a startup where everyone moves fast to a bureaucratic organization where everyone needs a manager’s permission to read from dev can delay what is an increasingly necessary security baseline, especially for companies pursuing SOC 2 and other compliance certifications.
The traditional headache of permission management.
What if there were a way to manage access to AWS that doesn’t slow down developers and uses tools you already use? Something that could reduce the organizational burden of proper access controls without sacrificing data security?
Sym is a product by developers who felt this pain every day. We realized that, if an access control system could integrate into familiar, facile communications tools, it would have a huge impact on our mental overhead and development velocity.
That’s why we selected Slack as the communications hub of Sym.
Slack is a tool designed for instantaneous, internal, and remote communications — exactly the situations we want to be able to cover for permissioning! We may take it for granted today, but as a replacement for communications like IM, email, or telephones, Slack offers opportunities for changing fundamental workflows and providing alternatives to expensive pain points like traditional permissioning.
The first and most obvious advantage of using Slack to manage your permissions is that your entire team is already using it, all the time. It is integrated into everyone’s device, everyone has access, and the mature UI and back end make Slack a reliable spine to support a vital use case like access management. Perhaps most importantly, Slack is already a trusted tool for your entire team: there’s no learning curve or discomfort when moving your permissioning to the platform.
But the core advantage of implementing your permissioning using a low-friction, universally accessible tool like Slack is that it enables your team to be frugal with their access. Security should ideally apply the principle of least privilege (PoLP): generally limiting users as much as possible, granting only necessary permissions, and removing them again as soon as a task is completed. Traditionally, this comes at an enormous workflow cost to the developers requesting access and the admin granting it.
Luckily, with a Slack-based approach, the sort of highly restrictive, temporary access protocols that make for good security no longer disrupt the workflow of devs and admins.
With Slack, your developers are riding in the fast lane to AWS access.
When you grant permissions with Slack via Sym, you empower developers to move quickly but safely, reduce the burden on management, and ensure that security compliance is clearly documented with logs and hardcoded rules. But let’s address the elephant in the room …
One of the most common concerns we hear from prospective clients is a distrust of adding more software to the security stack — after all, doesn’t all this just mean there is more code to be compromised?
This concern is understandable, but Sym’s automation is really on your side in the event of a breach. Remember that Sym doesn’t create users or modify policies; it just toggles access for an existing user, in an existing system. By implementing a solution for continuous temporary access escalations, you are able to run an organization with many fewer standing permissions and therefore less risk of lateral movement in the event of a breach. For an escalation to occur in a system protected by Sym, multiple users must act (to request, and to approve) escalation – so an attacker compromising a single user in your system is unlikely to get very far.
Sym also makes you safer against socially engineered attacks. With a properly composed Sym access flow, escalation requests aren’t delivered to a single senior ops engineer who lacks context for the access. Rather, Sym’s automation can ensure that only people who can open the door to a given asset are those with a good idea of the current situation of that system.
How does Sym actually work? We wrap Slack, Terraform, and AWS together to allow you to regulate your AWS permission systems as code. You provision different access protocols (called “approval flows”) in Terraform and connect those to our Slack bot. When users need access, they operate a simple, customizable menu in Slack. Their request can be either forwarded to team members or automatically processed (for example, in on-call protocols.) Access is highly customizable and can be made to expire after any duration.
Here’s how this works in more detail.
It’s easy to bring Sym into your Slack: just install our app and access commands with /sym. The installation flow will ask you to create a Sym account. Within your organization’s Sym account, users have set access levels, including modifying Sym flows, authorizing access, and logging interactions. All of this is managed directly through the Sym CLI:
Once your Sym account is up and running, it's easy to create a basic flow.
Our 10 minute quickstart gives you a quick example of authorization requests. Set up a sample flow, and in a few minutes your sym-requests channel can be used to service the requests of anyone in your Slack workspace.
This is a nice proof of the Slack UI, but let’s dive deeper.
One common tool used by Sym customers is temporary escalation via an AWS Lambda function. This is quite easy to set up in Sym, AWS Lambda functions can be created, accessed and operated entirely using Terraform.
A real benefit of building out your security-infrastructure-as-code with Sym is its compatibility with security protocols and certifications such as SOC2. Because your security-relevant Lambda functions are easy to parse and applied formulaically by terraform, you can easily show auditors proof of your compliance during evaluations.
Hopefully, the demo above has given you a taste of what AWS access management can look like directly inside your Slack workspace.
If the built-in flows are not sufficient, it's easy to customize them. Our GitHub repo contains a number of examples. One popular flow there is designed to support the third-party tool PagerDuty, enabling organizations to automatically provide access during PagerDuty shifts. Other extensions enable users to pipe their access logs directly to DataDog — one can imagine developing customized flows to securely execute functions throughout the AWS ecosystem and other third-party tools.
If you’re as excited about the potential for a Slack-based AWS management system as we are, you can easily sign up for our product and work through our quickstart process!
