The attack on Codespaces.com this week highlights how sensitive your cloud provider login data is. Three days ago, a user with malicious intent got control of their Amazon EC2 console and deleted everything. Their data. Customer data. Backups. Everything. They're offline and not sure when they're coming back. Read more at The Register.
Every DevOps team has to delegate access to sensitive management consoles to get work done. It is a common practice, and Authentic8 is no different. But we are a bit different in how we control the environment. We built Silo to help businesses secure and manage sensitive web based apps, like finance and HR apps. But we also use Silo for access to all our DevOps portals.
The Amazon Web Services admin console in Silo.
Here’s how it works:
- In Silo Admin, we set up a group structure for DevOps personnel. We could put everyone in a single group, but at Authentic8 we split the team into sub-groups based on roles.
- Then we provision each of our key DevOps accounts, like Amazon, SoftLayer, CrashPlan, Google Compute Engine, etc. to either a user or a group. We can assign each user their own credential, or we can share credentials across a group of users.
- And we set policies. We require 2-factor authentication to get in to Silo, and we block access from untrusted devices.
With this, we’ve done a few things that improve our controls:
- Since users never type in credentials (Silo does it for them securely), they can’t be phished or snooped.
- Since their cloud accounts are contained in their Silo account, we get a single kill-switch for account revocation.
- And Silo lets us set common controls across multiple providers. We’re not relying on different providers to manage security and content controls. Instead, we use the browser as a primary control point. And with the Admin Console, we get to manage configs ourselves.