On 2014-02-18 at 09:35 -0700, Yves Dorfsman wrote: > We have an EC2 environment, our developers have access to the console and > API, > and start and stop instances etc... as part of their work. Most of them work > from their laptop. I am starting to look at the security aspect, right now, > specifically the case where a laptop gets stolen:
Use per-user accounts, granted access in the IAM console, and use a permissions configuration which restricts access heavily. Most access should be by automated systems (eg, CloudFormation) and the more that people have access to do directly via tools, the less automated your systems are. This is fine for test instances not holding customer data, where the devs are using this to _write_ the automated tools and processes, but arbitrary unconstrained access to do "anything" with no locally-controlled audit / constraints, on a cluster with sensitive data, is just a Fail waiting to happen. In my case, I put in a fixed naming scheme for IAM users for remote access using the AWS CLI tool and in the Permissions tab I set the policy using the ReadOnly template, modified only to add "ec2:GetConsoleOutput" permission. This lets me mess around able to read cluster state and boot consoles, but not log into the systems or make changes. Note that all sorts of SOX-style access controls mean that the developers shouldn't have access to the "live" clusters anyway; so it's probably worth sitting down with an Eng lead and carving up what master accounts need to exist, what clusters should run under which accounts, what sort of data can live in which clusters, and provide the tooling and resources to make it easy to work with this and hard to work against it. Eg, packages of dummy data readily available in S3 in the Dev environment. The rest of it is similarly damage mitigation: FileVault must be turned on, etc etc. For credentials which need to be shared and people are turning to git, look into setting up git-crypt for a sub-tree. It's not perfect, you still have a shared secret and need to deal with staff turnover issues, but it's "better". -Phil _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
