Cloud Security Step by Step – Three Cloud Accounts
January 30, 2014 | DevOps | Kevin Gilpin
When you set up your cloud accounts: don’t create just one, create three.
You will use the first account for security purposes only. This account will host core services and data files that will ensure the security, access control, and technical compliance of the rest of the system.
The second account will be used for development. This is the account that you can use to hand out cloud credentials to your development and operations teams for development, testing and QA purposes.
The final account is for production use. Until you’re ready to go into production, you leave this account empty. When it’s time to go into production you will have a clean slate unpolluted by files or VMs, or unnecessary or excessively powerful user accounts.
Accounts in Detail
Your security account will form the basis of trust, security, and authorization for the rest of your cloud deployment. In the security account you can put services such as authentication and user/host directory. You can store critical files such as key back-ups and disaster recovery credentials. In AWS you should use bucket versioning to make sure that important files cannot be deleted, and termination protection on your VMs to make sure they are never shut down accidentally.
Only security personnel should have user logins in the security cloud account, and all logins should be protected by two factor authentication.
Your developers and operations personnel will need a place to learn and experiment and create with the cloud, and the dev account is the place to do that. You can grant a cloud console login to anyone on your development team and the permissions that you give here can be quite broad because any data related to security or to production is completely isolated in entirely separate accounts. Thanks to this precaution, even users with administrative and power-user permissions cannot accidentally view, modify or delete security- or production-related data.
The production account is for running production applications and you may have multiple of them. You may decide to create a separate cloud account for each customer that you have. The data and computing resources in each account remain completely separate, and this is a recommended practice by cloud providers. Your developers will not have logins in the production account. Logins will be limited primarily to operations personnel, and again you want to make sure that you have two factor authentication in place.
By splitting up your cloud system into multiple accounts, you have a much better control over access to resources than if you only had a single account. In development, you don’t have to worry so much about the specific permissions granted to each cloud user or system user because your compute and data resources are separated by a hard account boundary. In this way you, can demonstrate that you’ve taken initial measures to ensure that only appropriate and necessary personnel have access to security related and production customer data.