4 ms·
The place I work has a list of security guidelines that is, like, ten pages long and full of links to more detailed explanations. The exact advice depends on h
by klodolph 2y ago
The place I work has a list of security guidelines that is, like, ten pages long and full of links to more detailed explanations.
The exact advice depends on how you’re running your services. My starting advice, for cloud, is this:
1. Run in multiple, separate accounts. Don’t put everything in one account. This could be as simple as having a beta account for testing and a separate production account.
2. Use cloud-based permissions systems when possible. For example, if you are running something on AWS Lambda, you create an IAM role for the Lambda to run as and manage permissions by granting them to the IAM role.
3. If that’s not possible, put your credentials in some kind of secrets management system. Create a process to rotate the secret on a schedule. I’d say 90 days is fine if you have to rotate it manually. If you can rotate it automatically, rotate it every 24 hours.
4. Set up logging systems like CloudTrail so you can see events afterwards.
Finally, as a note—people at your company should always authenticate as themselves. If you are TheBigDuck234, then you access your cloud resources using a TheBigDuck234 account, always.
This is just the start of things.
- morkalork 2y agoCloud platforms for development really shine here. They've mostly solved all the problems for you, you just have to use their services. When running code locally, a service will use my account to access the dev secret manager and when running in the cloud it uses its own account to grab whatever it needs. At no point are secrets ever stored on my machine and I'm happy with that.
- throw0101d 2y ago> If you are TheBigDuck234, then you access your cloud resources using a TheBigDuck234 account, always. Or have a 'sudo' TheBigDuck234-to-AdminAcct mechanism if possible, or TheBigDuck234_admin account. On my Linux machines I do sudo-to-root, but on macOS, my daily driver account does not have sudo access so I have to first su to "admin" and then can sudo from there (for GUI requests I enter "admin" (or whatever)).
- klodolph 2y agoSo, this would be done in AWS by having e.g. IAM roles that you can assume from your user account. Your user account is your identity, and the IAM role that you assume is what grants you permissions. You can then log something like “this action was performed by Admin assumed by TheBigDuck234”, because the original identity is also recorded. There are some rough edges around the experience here if you really do want the best security posture, but you don’t have to go all the way. You can just create your one IAM user (just one per person) and then create multiple roles. When you log into the console, you authenticate as the user and then choose the account + role you want to use. I recommend creating a “read only” role. The purpose is to let people poke around in the console and debug problems without risking creating problems in production infrastructure—this is more of an operations than a security problem, though.