eBooks & Reports

O'Reilly's Automating Security in the Cloud

Issue link: https://resources.threatstack.com/i/872576

Contents of this Issue


Page 20 of 32

Reducing access management complexity may in-turn reduce opportunity for a prin‐ cipal to inadvertently receive or retain excessive privileges. Leveraging Roles for elevated access A role is similar to a user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have any credentials (password or access keys) associated with it. Instead, if a user is assigned to a role, access keys are created dynamically and provided to the user. Roles are recommended for security-sensitive capabilities, as the act of assuming a role generates a set of ephemeral credentials using the Security Token Service (STS) and these credentials - being a token, an AWS Access Key and an AWS Secret Access Key - are needed to make API calls in the con‐ text of the role. STS credentials expire after a configurable period (default 12 hours, minimum 15 minutes, maximum 36 hours), and this reduces the risk of engineers hard-wiring these keys into code, and therefore further reduces the risk of the keys being mishandled. Logging and Monitoring in the cloud Logging and monitoring takes on a whole new meaning in the cloud. Enabling log‐ ging should be the second action you do within your cloud security journey. As we referenced in the last section your initial account within your cloud environed is con‐ sidered a root account. The root account should not be used for routine administra‐ tion, however in-order to capture the full chain of administration for your cloud account you should log-in initially to set up at least two privileged roles. Prior to set‐ ting up those privileged roles logging should be turned on for all environments. An example is using AWS CloudTrail which is a web service that records all AWS API calls for your account and delivers log files to a storage container you designated and secure. 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. CloudTrail provides a history of AWS API calls for an account, including API calls made via the Management Con‐ sole, SDKs, command line tools, and higher-level AWS services (such as CloudFor‐ mation). The rationale for enabling AWS CloudTrail for all API calls enables security analysis, resource change tracking, and compliance auditing. Additionally, when you set up AWS CloudTrail for the first time you want to ensure that a multi-regions trail exists to ensure that unexpected activity occurring in other‐ wise unused regions is detected when a user launches or starts a service in another region you can capture the event. Setting up a trail that applies to all regions has the following advantages: The configuration settings for the trail apply consistently across all regions. Identity & Access Management (IAM) | 19

Articles in this issue

view archives of eBooks & Reports - O'Reilly's Automating Security in the Cloud