(1) AWS: Remove (or do not generate) root account access keys
To access Amazon Web Services (AWS), an access key is required to verify your identity and the identity of your applications. An access key consists of an access key ID and a secret access key. Anyone with the access key for your root account has unrestricted access to all of your account.
It is best practice to not have an access key for your root account. Instead, create AWS Identify and Access Management (IAM) users for each person so that you can give them specific permissions. When setting permissions, follow the standard security advice of granting least privilege. This means only giving a user permission which allows them to complete their specific tasks and no further access.
The following image shows an access key being used for the root account:
For more information, see: http://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html.
(2) AWS: Monitoring and logging
AWS provides several different logging options for different purposes. One particularly useful service is CloudTrail which “records AWS API calls for your account and delivers log files to you. The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters and the response elements returned by the AWS service”.
Monitoring API calls is a critical component of IT governance, security and compliance. CloudTrail helps you to build enhanced preventative and detective security controls for your AWS environment. You can also set up alerts so that you are notified when certain events happen.
The image below is a screenshot showing example API activity history:
For more information, see: https://aws.amazon.com/cloudtrail/.
(3) Cloud deployment processes
Many businesses use automated deployment processes for their applications. This involves using tools such as Chef and Jenkins to achieve continuous integration and delivery. The process is usually as follows:
A business might have their deployment process set up so that whenever code is pushed to the repository it automatically triggers a build followed by tests. If the tests pass, then the changes are deployed.
If someone wanted to hack an application, it is easier for them to hack the repository than hack the application. As a result, it is critical to secure the source code repository. Some steps that can be taken to increase the security of a repository are as follows:
• Using user role permissions and access levels (for example, different development teams might only need push access to certain branches. Furthermore, a non-development team might only require read access)
For example, different development teams might only need push access to certain branches. Furthermore, a non-development team might only require read access
• Using authentication methods such as SSH, external LDAP or 2-factor authentication
• Audit and access logging (this includes regularly checking commit logs).
• Building security into your DevOps cycle