Cloud security

Managing Access Control in Amazon Web Services (AWS)

August 31, 2017 by Sayaala

Security is one of the major prerequisites for any system. Any design should be secure from the point of the user, data, security from the point of business.

The common practices to date have been to be proactive with security, but now the need has changed to be more reactive than proactive.

Companies spend millions of dollars on the traditional security infrastructures such as firewalls and security devices. With the recent developments in data management and security, the users are provided with much advanced and secure systems than firewalls. This is because no one takes any steps to look after the people, who use, administer, and operate the computer systems. End users are the weakest link in the chain with regard to security.

Securing Core Amazon Web Service (AWS) infrastructure services includes the following to be understood:

  • Managing of identity and access
  • IAM users and group
  • Controlling access to resources
  • Understanding access keys
  • IAM Policies
  • Delegation and Federation
  • Best Practices when planning access control

Managing of identity and access

Identity management has synonymous terms which can be used interchangeably; some of them are authentication, user management, access control.

In AWS, the security is to be earned, and it is not easily granted. The rewards offered are minimal in AWS. The guest user receives the minimal amount of security access. A set of controls is defined for administration depending on the type of users after permission is granted for the accessing at AWS.

Permission is granted based on the privileges granted to the administrator by AWS, and then it is controlled by the administrator to utilize the resources.

The SOC-2 audit confirms that the security protocols are working properly and adhering to their functions around the year.

Management of identity and access includes resources which have storage and machines.

For the authentication policy purposes, one has to have a user account to access the AWS resources. Group user accounts are more beneficial as the group level management is simpler. The group users should have a password for the accounts.

After authentication, the authorization process is implemented based on the type of user whether it is an individual, a group or just for resource material

There are various ways of authentication of a user while making an AWS account

  1. E-mail address and password: The basic electronic mail address and its password can be used to access the AWS. The e-mail address of the first person who signs up for the AWS account is termed as the root account, but this is the least favored method.
  2. IAM user name: This is a method usually preferred in a group activity or for a group account.
  3. Access Keys: These are granted independent of the type of account, be it an e-mail account or an IAM account. The access key is used for authentication. Furthermore, secret access keys can be utilized for various activities like automation, controlling, accessibility.
  4. Key pairs: When a user wants to log on to an instance for the first time, administrator credentials are applied, Amazon supplies credentials, which is the only one time wherein it gives some credentials to the user.
  5. Multi Factor: For the authentication at Amazon, a code is sent to a cell phone, which can be used as a key for the authentication of the user.

IAM users and group

To understand security credentials aptly, it is essential to know where they exist in the AWS console. The security credentials can be accessed only through a root account. The security status of the company AWS account can be seen under the ‘my security credentials’ tab in the root account. Under the password option, the user is requested to log in using an email ID and gives you access to change the login credentials for the account including the password, name and email address linked to the account. The next option shown is multi-factor authentication, which allows the users to combine the password protection along with another virtual or hardware protection solution. Access key menu displays the status of every access key formed under the root account. It showed the date when it was created, the date when the previous access key was deleted, last used date, the region as well as service and the current status of the particular key. It must be noted that only two access keys can exist at the same time. Cloud front key pair gives the key pair for other users to access the data in the cloud. The other location for finding the key pair is under IAM account. Account identifiers give the AWS account ID and canonical user ID for the account.

Controlling access to resources

The first account created under AWS is the root account and cannot be deleted or locked out. This account has access to all the resources of the company account and is always active. There is no way to disable this account and hence, for security purposes, should not be used much often. Root account privileges and policies are beyond the control of IAM. Since this account is the most powerful account, it is essential to take due care about its safety and make sure the credentials do not get into anyone’s hand. The root account credentials are advised to be noted down physically and stores in an actual safe. As mentioned above, multi-factor authentication must be activated and must be supported by both physical as well as virtual devices. Since most of us would be confused about the steps to be taken to secure the root account, the following steps are the most preferable and simple:

  • Create an IAM account and assign all the admin rights to that account.
  • Set a new password for the root account which is random and make sure not to save it.
  • Note down the email ID linked with the root account and store it away in the physical safe.
  • When there arises a need for the root account, access the account through the ‘forgot password’ path.

The general situations where you may require the need for the root account are:

  • If you wish to change the security credentials of the root account itself.
  • Control the billing credentials for the AWS account.
  • Route 53 domain registration transfer.
  • Close down your AWS account.
  • Submit pen test request for scrutiny of the IP addresses.
  • To purchase services from AWS.

The main identification mark of a root account which sets it apart from other IAM accounts is that there are no policies displayed right after you log into the account since there is no need to specify any policies for this account since it has full control over the company policies.

Sometimes a company requires multiple AWS accounts to control and manage the activities of departments separately and to maintain an interdisciplinary relation between them. Different departments are assigned different accounts due to various reasons like security requirements, location issues and varied governance policies related to them. To facilitate inter-departmental data flow amongst these accounts, cross account access, a manually enabled service is provided by AWS to the users. This enables the IAM of a particular department account to access the resources of another account for their use. A single account is advisable for a company which has branch chains dependent on each other. A multiple account setup is favorable for the following cases:

  • For any departments in the company which are separate.
  • For a company with bases in different locations which need to be interlinked together.
  • In cases where the resources of the departments need to be isolated from each other.
  • To setup consolidated billing and ease the billing procedure.

Cross linking between different accounts is done either for consolidated billing or for sharing resources. Consolidated billing can be setup from the billing dashboard. All it requires is the user to sign up for consolidated billing and link the account which needs to be added and send a request for consolidated billing. Cross access of resources can be done through IAM. Under IAM, cross access is granted by assigning the designated roles. These roles are assigned to the account to whom the access needs to be granted. The other account to whom access is granted can avail that role under switch role in its IAM.

IAM or identity access management plays an extremely important role in managing the users under the company account. Post the formation of the root account; the other users need to be created through the IAM. The major role of an IAM is to control user authentication and resource access, and it successfully manages it using the concept of users and groups, roles, and policies. These policies can either be the default, linked to a certain role or user defined. IAM is used to provide the users with access to the database as well as the S3 bucket. The users need to be added to specific groups with particular policies providing access to the desired database.

Adding users to the account using IAM is the simplest yet the most crucial task. For the same, the root account user needs to get into IAM and add new users under IAM. Adding new user requires you to follow certain steps. The first step includes adding username and specifying the user access type as well as password. The second step includes assigning permissions to the user. This option lets you choose between adding the user to a group, copying permissions from an existing user or attach the existing policies to the user directly. The next step in this process is the review of permissions given to the user, and the last step is the confirmation of user information and completion of the process. The best way to give permissions to the user is by creating groups with the desired permission policies and adding the user to that group. The policy list provided by AWS is also a comprehensive one with apt functionalities and can be effectively used to assign permissions.

The next and most important matter of concern after adding new users is the providing access to the company resources stored over AWS. The process of resource access is broadly classified under the administrative head, programmer head and AWS pre-configured processes. The resource access for administrative purposes is carried out either by using IAM under the AWS management console or through the access keys linked to the user accounts using the command line interface. For the programmers, resources can be accessed using a secure virtual network path using APIs through the software development kits. The level of pre-configured access lies at the administrative level and the programmer level. Access to resources outside of the AWS encrypted server is out of control of the IAM. It is extremely important to note that the company servers out of the reach of AWS need to be added to an external security group to manage the access to its data. This is generally carried out at the operating system level.

Understanding access keys

Any instance of accessing the AWS resources requires an API call. To eliminate the use of API calls and to facilitate access to the programs which require constant access to the resources, AWS provides every user to have a secret access key other than the access ID. This acts as an active access key for every instance of resource access. Access key forms a pair with the access key ID and is always linked together. To maintain the security of the access key, the user is advised to use two access keys simultaneously. For the same, while the first access key is active, generate the second access key and update your programs to accept the new access key. Once this is done, change the status of the first access key to inactive, make sure all the programs are still running smoothly and then, delete the inactive access key. This complete procedure can be termed as rotating access keys. For instances where the end user needs to access the console, a password is necessary. Managing password can be done using IAM where the users can set their password and change it when required. Password control is also possible using CloudTrail in combination with other applications which track and manage all of the API calls.

Since AWS focuses on keeping your data secure, the user is provided with a host of security tools. The admin has complete access to the access data and can also change permissions if required. Under IAM, the user gets a credential report where they can get a report of all the API calls performed in the last four hours. IAM also provides the admin with an access advisor who lets them keep track of the policies assigned to any individual user and review the use of each of the permission and right assigned to the user by the policies. CloudTrail is yet another important security tool which can also be used for auditing purposes. As mentioned earlier, CloudTrail gives detailed data about each API call. Cloudwatch is a modified form of CloudTrail which gives the admin the flexibility to keep track of any particular event and also notify the admin about it or automatically perform a certain pre-assigned task once the event occurs.

IAM Policies

The permission to grant or deny access to resources is controlled using IAM policies. Any IAM policy performs in an explicit fashion and any exceptions for the same need to be specified by the admin. It must be noted that every IAM policy is restrictive in nature and in cases of conflict, the explicit decision is the winner. An IAM policy can be attached either to a group or an individual user or even a role. These policies are generally of two types, predefined policies, and user defined policies. As the names suggest, a predefined policy is defined by AWS in their policy library. These policies are either of managed type or inline type. Both these types can be assigned either to an individual user or a group or any role. The managed policies each are given an Amazon resource name, are read only, and define permissions for general instances. A maximum of 10 managed policies are permitted per user, group, or role. The inline policies are applicable only to a single mentioned group, user, or role. If that particular entity is deleted, the policy stays redundant. User defined policies can either be tag based or resource based. The tag based policies are the ones which allow only the tagged users to access the defined set of files. Resource policies are linked directly with the AWS resources to specified.

Delegation and Federation

Resource access to any user who is not an IAM user can be granted through the method of federation. In this method, the access policies are assigned to a particular role. The person who performs this role, in turn, takes up the access policy and is granted access to the resources. Creating an IAM role is an extremely crucial and meticulous task. It includes defining the trust policy for the external users accessing the defined resources. This precisely defines the actions which are allowed for the user to perform on the resources. Lastly, it also requires you to define the type of users allowed to perform the specified role. A yet another secure way to gain temporary access to the resources is the AWS security token services or STS. This provides the users with temporary security credentials including a short-lived access key, secret access key and session token. All the API calls over STS access are tracked by Cloud Trail by default.

Posted: August 31, 2017
View Profile

Sayaala is a graduate from India. Sayaala has interest in the field of information security and also other environmental studies. Sayaala would like to explore more and more about different aspect of information security domain such as AWS, Common threats in infosec, Malware, Vulnerability assessment etc. My Blog link