AWS Identity Access Management 

Amazon Web Services (AWS)  offers high level data protection when compared to an on-premises environment, at a lower cost. Among various AWS security services, Identity and Access Management (IAM) is the most widely used one. It enables secure control access to AWS resources and services for the customers. Customers can create and manage AWS users as well as groups, and provides necessary permissions to allow or deny access to AWS resources. In a simple term IAM provides an infrastructure necessary to control authentication and authorization for its customers account.

AWS Identity access management capabilities 

  • AWS Identity and Access Management (IAM) enables customers to securely control access to AWS services and resources for their users. 
  • Using IAM, customers can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.
  •  IAM makes it easy to provide multiple users secure access to AWS resources.

AWS IAM Features

Enhanced security

IAM enables security best practices by allowing customers to grant unique security credentials to users and groups to specify which AWS service APIs and resources they can access. IAM is secure by default; users have no access to AWS resources until permissions are explicitly granted.

AWS clients can grant other people permission to administer and use resources in their AWS account without having to share their password or access key. Customers can also create users in IAM, assign them individual security credentials (such as access keys, passwords, and multi-factor authentication devices), or request temporary security credentials to provide users access to AWS services and resources. Customers are allowed to manage permissions in order to control which operations a user can perform. IAM users can be:

  • Privileged administrators who need console access to manage your AWS resources.
  • End users who need access to content in AWS.
  • Systems that need privileges to programmatically access your data in AWS.
Granular Permissions 

Granular permission enables customers to grant the permissions for different according to their resources. Customers can give the whole access to AWS services, while limiting the other users to read-only access along with the administrator EC2 instances in order to access the process of billing information. These services include; 

  • Amazon Elastic Compute Cloud (Amazon EC2).
  • Amazon Simple Storage Service (Amazon S3).
  • Amazon DynamoDB, Amazon Redshift.
  • For other users, customers can allow
    • Read-only access to just some S3 buckets, 
    • Permission to administer just some EC2 instances, or 
    • Access to customer billing information but nothing else.
    • IAM also enables customers to add specific conditions such as time of day to control how a user can use AWS,
      • Their originating IP address, whether they are using SSL, or 
      • Whether customers have authenticated with a multi-factor authentication device.

To assign permissions to a user, group, role, or resource, AWS customers need to create a policy that lets them specify:

  • Actions – Which AWS service actions allowed. For example, you might allow a user to call the Amazon S3 ListBucket action. Any actions that you don’t explicitly allow are denied.
  • Resources – Which AWS resources that is allowed the action on. For example, what Amazon S3 buckets will you allow the user to perform the ListBucket action on? Users cannot access any resources that you do not explicitly grant permissions to.
  • Effect – Whether to allow or deny access. Because access is denied by default, you typically write policies where the effect is to allow.
  • Conditions – Which conditions must be present for the policy to take effect. For example, you might allow access only to the specific S3 buckets if the user is connecting from a specific IP range or has used multi-factor authentication at login.
Securing Application Access

AWS Identity and Access Management (IAM) helps customers control access and permissions to thier AWS services and resources, including compute instances and storage buckets. they also can use IAM features to securely give applications that run on EC2 instances the credentials that they need in order to access other AWS resources, like S3 buckets and RDS and DynamoDB databases.

IAM helps to analyze access across customers AWS environment. The security teams and administrators can use IAM Access Analyzer to identify resources that can be accessed from outside an AWS account such as, validating public or cross-account permissions granted using policies for;

  • Amazon S3 buckets, AWS KMS keys, Amazon SQS queues, IAM roles, and AWS Lambda functions.
  • IAM helps easily identify and remove unused permissions by providing a timestamp of when an IAM entity last used a service.

By using resource policies, IAM allows customers to granularly control who is able to access a specific resource and how they are able to use it.

  • With the cloud, you can quickly spin up  as it needed, deploying thousands of servers in minutes.
  • IAM Access Analyzer generates comprehensive findings that identify resources that can be accessed from outside an AWS account. .
  • IAM provides “last accessed” data, which is a timestamp depicting when an IAM policy or entity, such as a user or role, last used a service or an action from supported services. 
  • From the AWS Organizations master account, it is possible to see the last time a service was accessed by the organization root, organizational units (OUs), and accounts.
Multi Factor Authentication 

AWS Multi-Factor Authentication (MFA) is a simple best practice that adds an extra layer of protection on top of customers user name and password. With MFA enabled, when a user signs in to an AWS Management Console, they will be prompted for their user name and password (the first factor—what they know), as well as for an authentication code from their AWS MFA device (the second factor—what they have). 

  • Customers can add two-factor authentication to their account and to individual customers (users) for extra security.
  • With MFA customers or their users must provide not only a password or access key to work with user account, but also a code from a specially configured device.
  • By using the Multi-factor authentication customers can easily add the two-factor authentication not only for their account but also for the individual users for more security.
  • AWS Identity and Access Management (IAM) lets customers manage several types of long-term security credentials for IAM users using the following
    • Passwords:- Used to sign in to secure AWS pages, such as the AWS Management Console and the AWS Discussion Forums. 
    • Access keys:- Used to make programmatic calls to AWS from the AWS APIs, AWS CLI, AWS SDKs, or AWS Tools for Windows PowerShell. 
    • Amazon CloudFront key pairs:- Used for CloudFront to create signed URLs. 
    • SSH public keys:- Used to authenticate to AWS CodeCommit repositories.
    • X.509 certificates:- Used to make secure SOAP-protocol requests to some AWS services.
Temporary credentials

In addition to defining access permissions directly to users and groups, IAM lets AWS clients to create roles. Roles that allows them to define a set of permissions and then let authenticated users or EC2 instances assume them, increasing your security posture by granting temporary access to the resources you define.

IAM roles allow customers to delegate access to users or services that normally don’t have access to their organization’s AWS resources. IAM users or AWS services can assume a role to obtain temporary security credentials that can be used to make AWS API calls. In other word AWS customers don’t have to share long-term credentials or define permissions for each entity that requires access to a resource.

Using the AWS Security Token Service (STS), that is a web service that enables customers to request temporary, limited-privilege credentials for IAM users or for users that they authenticate (federated users).

  • Customers do not have to distribute or embed long-term AWS security credentials with an application.
    • Customers can provide access to their AWS resources to users without having to define an AWS identity for them.
    • The temporary security credentials have a limited lifetime.
    • After temporary security credentials expire, they cannot be reused.
    • AWS STS are features of customers AWS account offered at no additional charge. However customers will bare that are charged they access other AWS services using your IAM users or AWS STS temporary security credentials. 
Managing IAM credentials

IAM allows customers to authenticate users in several ways, depending on how they want to use AWS services. The  security credentials including passwords, key pairs, and X.509 certificates, and multi-factor authentication (MFA) on users who access the AWS Management Console or use APIs.

AWS clients can grant other people permission to administer and use resources in their AWS account without having to share their password or access key. They can also create users in IAM, assign them individual security credentials (such as access keys, passwords, and multi-factor authentication devices), or request temporary security credentials to provide users access to AWS services and resources. You can manage permissions in order to control which operations a user can perform. IAM users can be:

  • Privileged administrators who need console access to manage your AWS resources.
  • End users who need access to content in AWS.
  • Systems that need privileges to programmatically access your data in AWS.

AWS Identity and Access Management (IAM) lets customers manage several types of long-term security credentials for IAM users:

  • Passwords – Used to sign in to secure AWS pages, such as the AWS Management Console and the AWS Discussion Forums.
  • Access keys – Used to make programmatic calls to AWS from the AWS APIs, AWS CLI, AWS SDKs, or AWS Tools for Windows PowerShell.
  • Amazon CloudFront key pairs – Used for CloudFront to create signed URLs.
  • SSH public keys – Used to authenticate to AWS CodeCommit repositories.

Using the API, CLI, or AWS Management Console, customers can assign AWS security credentials to your IAM users by 

Identity federation

AWS clients can allow users who already have passwords elsewhere—such as, in the corporate network or with an internet identity provider—to get temporary access to the AWS account.

  • Customers can enable identity federation to allow existing identities (users, groups, and roles) in their enterprise to access the AWS Management Console, call AWS APIs, and access resources, without the need to create an IAM user for each identity.
  •  Access and Federation :– User can grant other people permission to administer and use resources in your AWS account without having to share your password or access key.
  • AWS offers multiple options for federating customers identities in AWS. One of them being  AWS Identity and Access Management (IAM) which enable users to sign in to their AWS accounts with their existing given credentials.

Understanding How IAM Works

The “identity” aspect of AWS Identity and Access Management (IAM) helps customers with the question “Who is that user?”, often referred to as authentication. Instead of sharing their root user credentials with others, they can create individual IAM users within their account that correspond to users in their organization. IAM users are not separate accounts; they are users within customers’ accounts. Each user can have its own password for access to the AWS Management Console. 

These are most common terms in IAM; IAM terms.

  • Resources: The user, group, role, policy, and identity provider objects that are stored in IAM. As with other AWS services, you can add, edit, and remove resources from IAM.
  • Identities: The IAM resource objects that are used to identify and group. You can attach a policy to an IAM identity. These include users, groups, and roles.
  • Entities: The IAM resource objects that AWS uses for authentication. These include IAM users, federated users, and assumed IAM roles.
  • Principals: A person or application that uses the AWS account root user, an IAM user, or an IAM role to sign in and make requests to AWS.  

Using the following elements, IAM provides the infrastructure necessary to control authentication and authorization for customers’ accounts. They are Principal, Request, Authentication, Authorization, Actions (Operations), and Resource.

Principal 

A principal is a an IAM entity or application that is allowed to interact with AWS resources, or that can make a request for an action or operation on an AWS resource. The principal is authenticated as the AWS account root user. A principal can be permanent or temporary, and it can represent a human or an application. The administrative IAM user is the first principle, which can allow the user for the particular services in order to assume a role. 

  • There are three types of principals: root users, IAM users, and roles/temporary security tokens.

Root User

IAM User

An IAM user is an entity that customers create in AWS. The IAM user represents the person or service who uses the IAM user to interact with AWS. A primary use for IAM users is to give people the ability to sign in to the AWS Management Console for interactive tasks and to make programmatic requests to AWS services using the API or CLI. A user in AWS consists of a name, a password to sign into the AWS Management Console, and up to two access keys that can be used with the API or CLI. IAM user accounts are user accounts which customers can create for individual services offered by AWS.

Root Users can create IAM, and assign them individual security credentials such as words, access keys, passwords, and multi-factor authentication devices, or request temporary security credentials to provide users access to AWS services and resources. 

  • IAM user represents the person or service who uses the IAM user to interact with AWS. 
  • A primary use for IAM users is to give people the ability to sign in to the AWS Management Console for interactive tasks and to make programmatic requests to AWS services using the API or CLI.
  • Root users can create IAM users, attach group level policies or user level policies and share these IAM accounts with other entities. 
    • Group level and user level policies restrict and authorize individual IAM users to AWS services under Root user account.
  • IAM users are individuals who have been granted access to an AWS account. Each IAM user has three main components:
    • A user-name.
    • A password.
    • Permissions to access various resources.
  • Customers have persistent identities set up through the IAM service to represent individual people or applications. 
power user

The description of power user access given by AWS is “Provides full access to AWS services and resources, but does not allow management of Users and groups.” The power to manage user is the highest privilege operation in AWS thus it is provided to the administrative access policy only.

  • Power users are just below the Root user and have all the privileges the Root user has with the exception of the ability to manage the IAM users.

Security Tokens

Request
 

A Request is a process where a principal send to AWS in order to use the AWS Management Console, the AWS API, or the AWS CLI. The request includes:

  • Actions or operations – The actions or operations that the principal wants to perform. 
  • Resources – The AWS resource object upon which the actions or operations are performed.
  • Principal – The person or application that used an entity (user or role) to send the request. Information about the principal includes the policies that are associated with the entity that the principal used to sign in.
  • Environment data – Information about the IP address, user agent, SSL enabled status, or the time of day.
  • Resource data – Data related to the resource that is being requested. This can include information such as a DynamoDB table name or a tag on an Amazon EC2 instance.

AWS gathers the Request information into a request context, which is used to evaluate and authorize the request.

Authentication
 

A principal must be authenticated (signed in to AWS) using their credentials to send a request to AWS.

To authenticate from the console as a root user, customers need to sign in with their email address and password. 

  • IAM provide customers their account ID or alias, and then their users name and password. 
  • Principal can be authenticated three ways :
    • By using User name and Password
    • By using access key, that’s a combination of an access key ID (20 characters) and an access secret key (40 characters).
    • Access Key/Session Token—When a process operates under an assumed role, the temporary security token provides an access key for authentication.
Operations
 

After the request has been authenticated and authorized, AWS approves the actions or operations in customers’ request. Operations are defined by a service, and include things that the customer can do to a resource, such as viewing, creating, editing, and deleting that resource. IAM supports approximately 40 actions for a user resource, including the following actions: 

  • CreateUser 
  • DeleteUser 
  • GetUser 
  • UpdateUser 

To allow a principal to perform an operation, you must include the necessary actions in a policy that applies to the principal or the affected resource

Operations (Actions) are defined by a service that include things such as viewing, creating, editing, and deleting that resource by customers. In order to get granted in these Operations, Principals (Root user,IAM user, and Role) request need to pass Authentication and Authorization.

Resources

After AWS approves the operations of customers’ request, they can be performed on the related resources within their account. A resource is an object that exists within a service. the resources include an Amazon EC2 instance, an IAM user, and an Amazon S3 bucket. The service defines a set of actions that can be performed on each resource.

The  type of instance that client specify determines the hardware of the host computer used for their instance. Each instance type offers different compute, memory, and storage capabilities and are grouped in instance families based on these capabilities. Each instance type provides higher or lower minimum performance from a shared resource.

The resource types table

The Resource types table lists all the resource types that you can specify as an ARN in the Resource policy element. Not every resource type can be specified with every action. Some resource types work with only certain actions. If you specify a resource type in a statement with an action that does not support that resource type, then the statement doesn’t allow access. For more information about the Resource element, see IAM JSON policy elements: Resource.

  • The ARN column specifies the Amazon Resource Name (ARN) format that you must use to reference resources of this type. The portions that are preceded by a $ must be replaced by the actual values for your scenario. For example, if you see $user-name in an ARN, you must replace that string with either the actual IAM user’s name or a policy variable that contains an IAM user’s name. For more information about ARNs, see IAM ARNs.

  • The Condition keys column specifies condition context keys that you can include in an IAM policy statement only when both this resource and a supporting action from the table above are included in the statement.

Authorization

Authorization is a process of specifying exactly what actions a principal can and cannot perform in AWS resources. This will be possible after IAM has authenticated the principal, then IAM must manage the access of that principal to protect the client AWS infrastructure. Authorization is handled in IAM by defining specific privileges in policies and associating those policies with principals.

A policy is a JSON document that fully defines a set of permissions to access and manipulate AWS resources. JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write and it is also easy for machines to parse and generate. Policy documents contain one or more permissions, with each permission defining: 

  • Effect:– Allow or Deny. 
  • Service:– Most AWS Cloud services support granting access through IAM, including IAM itself. 
  • Resource:– The resource value specifies the specific AWS infrastructure for which this permission applies.
  • Action:– Action value specifies the subset of actions within a service that the permission allows or denies. 
  • Condition:–The condition value optionally defines one or more additional restrictions that limit the actions allowed by the permission.

policy

A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when a principal uses an IAM entity (user or role) to make a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents. Policies are documents that define permissions and can be applied to users, groups and roles.

  • Policy documents are written in JSON (key value pair that consists of an attribute and a value).
  • All permissions are implicitly denied by default.
  • The IAM policy simulator is a tool to help customers understand, test, and validate the effects of access control policies.
  • There are three basic steps where every user has to follow to get authenticated in an enormous way. Starting from selecting certain Policy Type, then Add the respective statements, and finally Generate Policy as per the requirement
  • These are in the policy container for certain permissions where customers can select anyone from respective policies such as IAM Policy, S3 bucket policies, and SNS topic policy, SQS queue policy, VPC endpoint policy etc.
    • Then adding statements is the respective policy to have a formal description for single access permission. The Final one, Generate Policy is a document that acts as a container for one or else massive statements.
  • The control provided by IAM is granular enough to limit a single user to the ability to perform a single action on a specific resource from a specific IP address during a specific time window.

Root User

When first create an Amazon Web Services (AWS) account, begin with a single sign-in identity that has complete access to all AWS services and resources in the account. This identity is called the AWS account root user. You can sign in as the root user using the email address and password that you used to create the account.

  • Root user can create, rotate, disable, or delete access keys, change root user password. (access key IDs and secret access keys) for the AWS account root user.
  • Anyone who has root user credentials for your AWS account has unrestricted access to all the resources in your account, including billing information.

When users create access keys, they create the access key ID and secret access key as a set. During access key creation, AWS gives one opportunity to view and download the secret access key part of the access key. Creating root user access keys can be done through the IAM console, AWS CLI, or AWS API.

A newly created access key has the status of active, which means that it can be used for CLI and API calls. Users are limited to two access keys for each IAM user, which is useful when to rotate the access keys.

  • You can assign up to two access keys to the root user.
  • When you disable an access key, you can’t use it for API calls, and inactive keys do count toward your limit.
  • You can create or delete an access key any time. However, when you delete an access key, it’s gone forever and can’t be retrieved.

You can change the email address and password on the Security Credentials page. You can also choose Forgot password? on the AWS sign-in page to reset your password.

  • User Policy:–These policies exist only in the context of the user to which they are attached. In the console, a user policy is entered into the user interface on the IAM user page. 
  • Managed Policies:–These policies are created in the Policies tab on the IAM page (or through the CLI, and so forth) and exist independently of any individual user. In this way, the same policy can be associated with many users or groups of users.

IAM Group

An IAM group is a collection of IAM users. Groups let you specify permissions for multiple users, which can make it easier to manage the permissions for those users. For example, you could have a group called Admins and give that group the types of permissions that administrators typically need. Any user in that group automatically has the permissions that are assigned to the group. If a new user joins your organization and needs administrator privileges, you can assign the appropriate permissions by adding the user to that group. Similarly, if a person changes jobs in your organization, instead of editing that user’s permissions, you can remove him or her from the old groups and add him or her to the appropriate new groups.

Note that a group is not truly an “identity” in IAM because it cannot be identified as a Principal in a permission policy. It is simply a way to attach policies to multiple users at one time.

Following are some important characteristics of groups:

  • A group can contain many users, and a user can belong to multiple groups.

  • Groups can’t be nested; they can contain only users, not other groups.

  • There’s no default group that automatically includes all users in the AWS account. If you want to have a group like that, you need to create it and assign each new user to it.

  • The number and size of IAM resources in an AWS account are limited. For more information, see IAM and STS quotas.

The following diagram shows a simple example of a small company. The company owner creates an Admins group for users to create and manage other users as the company grows. The Admins group creates a Developers group and a Test group. Each of these groups consists of users (humans and applications) that interact with AWS (Jim, Brad, DevApp1, and so on). Each user has an individual set of security credentials. In this example, each user belongs to a single group. However, users can belong to multiple groups.

  • Group Policy:– These policies exist only in the context of the group to which they are attached. In the AWS Management Console, a group policy is entered into the user interface on the IAM Group page. 
  • Managed Policies:– In the same way that managed policies (discussed in the “Authorization” section) can be associated with IAM users, they can also be associated with IAM groups.

Roles

An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM 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 standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

You can use roles to delegate access to users, applications, or services that don’t normally have access to your AWS resources. For example, you might want to grant users in your AWS account access to resources they don’t usually have, or grant users in one AWS account access to resources in another account. Or you might want to allow a mobile app to use AWS resources, but not want to embed AWS keys within the app (where they can be difficult to rotate and where users can potentially extract them). Sometimes you want to give AWS access to users who already have identities defined outside of AWS, such as in your corporate directory. 

For these scenarios, you can delegate access to AWS resources using an IAM role. This section introduces roles and the different ways you can use them, when and how to choose among approaches, and how to create, manage, switch to (or assume), and delete roles.

An IAM identity that you can create in your account that has specific permissions. An IAM role has some similarities to an IAM user. Roles and users are both AWS identities with permissions 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 standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

Roles can be used by the following:

  • An IAM user in the same AWS account as the role

  • An IAM user in a different AWS account than the role

  • A web service offered by AWS such as Amazon Elastic Compute Cloud (Amazon EC2)

  • An external user authenticated by an external identity provider (IdP) service that is compatible with SAML 2.0 or OpenID Connect, or a custom-built identity broker.

Security Hub

 

 

AWS Security Hub provides customers with a comprehensive view of their security state in AWS and helps them check their compliance with the security industry standards and best practices. Security Hub collects security data from across AWS accounts, services, and supported third-party partner products and helps customers analyze their security trends and identify the highest priority security issues.

  • Security Hub reduces the effort to collect and prioritize security findings across accounts from integrated AWS services and AWS partner products.
  • Security Hub automatically runs continuous, account-level configuration and compliance checks based on industry standards and best practices, such as the Center for Internet Security (CIS) AWS Foundations Benchmarks.
  • Security Hub consolidates customers security findings across accounts and provider products and displays results on the Security Hub console pages.
  • Security Hub supports integration with Amazon CloudWatch Events, which lets customers automate remediation of specific findings by defining custom actions to take when a finding is received. 

.

 web application firewall 
 

AWS WAF is a web application firewall that helps protect customers web applications or APIs against common web exploits that may affect availability, compromise security, or consume excessive resources. AWS WAF gives customers control over how traffic reaches your applications by enabling them to create security rules that block common attack patterns.

  • AWS WAF lets you create rules to filter web traffic based on conditions that include IP addresses, HTTP headers and body, or custom URIs. 
  • AWS WAF allows customers to create a centralized set of rules that they can deploy across multiple websites. 
  • AWS WAF provides real-time metrics and captures raw requests that include details about IP addresses, geo locations, URIs, User-Agent and Referers. AWS WAF is fully integrated with Amazon CloudWatch, making it easy to setup custom alarms when thresholds are exceeded or particular attacks occur.
  • AWS WAF provides organizations with the ability to create and maintain rules automatically and incorporate them into the development and design process via APIs.
AWS Shield
 

AWS Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. AWS Shield provides always-on detection and automatic inline mitigations that minimize application downtime and latency, so there is no need to engage

  • AWS Shield is closely related to both AWS WAF and also the AWS Firewall Manager.
  • All AWS customers benefit from the automatic protections of AWS Shield Standard, at no additional charge. AWS Shield Standard defends against most common, frequently occurring network and transport layer DDoS attacks that target customers web site or applications. 
  • Customers can use AWS Shield Standard with Amazon CloudFront and Amazon Route 53 to receive comprehensive availability protection against all known infrastructure (Layer 3 and 4) attacks.
  • AWS Shield Advanced is available globally on all Amazon CloudFront, AWS Global Accelerator, and Amazon Route 53 edge locations. Customers can protect their web applications hosted anywhere in the world by deploying Amazon CloudFront in front of their application.
  • AWS Shield Standard is always-on heuristics-based network flow monitoring and inline mitigation against common, most frequently occurring network and transport layer DDoS attacks.

SHARED RESPONSIBILITY

 

Customer responsibility “Security in the Cloud”: The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.

AWS responsibility “Security of the Cloud” – AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.

    • Cloud security at AWS is the highest priority.
      • As an AWS customer, users will benefit from a data center and network architecture built to meet the requirements of the most security-sensitive organizations.
      • An advantage of the AWS cloud is that it allows customers to scale and innovate, while maintaining a secure environment. 
      • Customers pay only for the services they use, meaning that users can have the security they need, but without the upfront expenses, and at a lower cost than in an on-premises environment.

INFRASTRUCTURE SECURITY

 

Network firewalls built into Amazon VPC.

  • In transit encryption using TLS across all services.
  • Private or dedicated connections into your data centre

Infrastructure Resilience

  • Technologies built from the ground up for resilience in the face of DDoS attacks.
  • Services can be used in combination to automatically scale for traffic load.
  • Autoscaling, CloudFront, Route 53 can be used to prevent DDoS.

Data Encryption

  • At rest encryption available in EBS, S3, Glacier, RDS (Oracle and SQL Server) and Redshift.
  • Key management through AWS KMS – you can choose whether to control the keys or let AWS.
  • Server side encryption of message queues in SQS.
  • Dedicated hardware-based cryptographic key storage using AWS CloudHSM, allowing you to satisfy compliance requirements.

APIs to integrate AWS security into any applications you create.

MONITORING AND LOGGING
 

Customer responsibility “Security in the Cloud”: The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.

AWS responsibility “Security of the Cloud” – AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. This infrastructure is composed of the hardware, software, networking, and facilities that run AWS Cloud services.

    • Cloud security at AWS is the highest priority.
      • As an AWS customer, users will benefit from a data center and network architecture built to meet the requirements of the most security-sensitive organizations.
      • An advantage of the AWS cloud is that it allows customers to scale and innovate, while maintaining a secure environment. 
      • Customers pay only for the services they use, meaning that users can have the security they need, but without the upfront expenses, and at a lower cost than in an on-premises environment.

SECURITY SUPPORT

 
  • Real-time insight through AWS Trusted Advisor
  • Proactive support and advocacy with a Technical Account Manager (TAM)

Compliance Assurance Programs:- From certifications, regulations to frameworks, AWS has you covered. Some of those included are 

  • DoD SRG, FIPS (US)
  • ISO 9001, CISPE, GLBA
  • UK Data Protection Act
  • EU Data Protection Directive
  • FFIEC
  • G-Cloud , NIST, UK Cloud Security Principles.

AWS SUPPORT

 

Network firewalls built into Amazon VPC.

  • In transit encryption using TLS across all services.
  • Private or dedicated connections into your data centre

Infrastructure Resilience

  • Technologies built from the ground up for resilience in the face of DDoS attacks.
  • Services can be used in combination to automatically scale for traffic load.
  • Autoscaling, CloudFront, Route 53 can be used to prevent DDoS.

Data Encryption

  • At rest encryption available in EBS, S3, Glacier, RDS (Oracle and SQL Server) and Redshift.
  • Key management through AWS KMS – you can choose whether to control the keys or let AWS.
  • Server side encryption of message queues in SQS.
  • Dedicated hardware-based cryptographic key storage using AWS CloudHSM, allowing you to satisfy compliance requirements.

APIs to integrate AWS security into any applications you create.

Lock away the AWS root user access keys

The access key for customers AWS account root user gives full access to all their resources for all AWS services, including customers’ billing information. Its important not to share AWS account root user password or access keys with anyone

Remove Unnecessary Credentials

Remove IAM user credentials (passwords and access keys) that are not needed. Passwords and access keys that have not been used recently might be good candidates for removal. Customers can find unused passwords or access keys using the console, using the CLI or API, or by downloading the credentials report.

Use Access Levels to Review IAM Permissions

To improve the security of your AWS account, you should regularly review and monitor each of your IAM policies. Make sure that your policies grant the least privilege that is needed to perform only the necessary actions.

  • When AWS customers review a policy, they can view the policy summary that includes a summary of the access level for each service within that policy. AWS categorizes each service action into one of five(List, Read, Write, Permissions management, or Tagging) access levels based on what each action does. 
Use Roles to Delegate Permissions

Don’t share security credentials between accounts to allow users from another AWS account to access resources in your AWS account. Instead, use IAM roles. Customers can define a role that specifies what permissions the IAM users in the other account are allowed. They can also designate which AWS accounts have the IAM users that are allowed to assume the role.

Rotate Credentials Regularly

It is important to change the root passwords and access keys regularly, and make sure that all IAM users in the account do as well. That way, if a password or access key is compromised without Principal knowledge, they can limit how long the credentials can be used to access their resources. They can apply a password policy to their account to require all their IAM users to rotate their passwords. Customers can also choose how often they must do so.

Monitor Activity the AWS Account

By using logging features in AWS customers can determine the actions users have taken in their account and the resources that were used. The log files show the time and date of actions, the source IP for an action, which actions failed due to inadequate permissions, and more.

Use groups to assign permissions to IAM users

Instead of defining permissions for individual IAM users, it’s usually more convenient to create groups that relate to job functions (administrators, developers, accounting, etc.). Next, define the relevant permissions for each group. Finally, assign IAM users to those groups. All the users in an IAM group inherit the permissions assigned to the group. That way, you can make changes for everyone in a group in just one place. As people move around in your company, you can simply change what IAM group their IAM user belongs to.

Do Not Share Access Keys

Access keys provide programmatic access to AWS. Do not embed access keys within unencrypted code or share these security credentials between users in your AWS account. For applications that need access to AWS, configure the program to retrieve temporary security credentials using an IAM role. To allow customers users for individual programmatic access, create an IAM user with personal access keys.

Enable MFA for privileged users

For extra security, we recommend that customers to require multi-factor authentication (MFA) for all users in your account. With MFA, users have a device that generates a response to an authentication challenge. Both the user’s credentials and the device-generated response are required to complete the sign-in process. If a user’s password or access keys are compromised, customers account resources are still secure because of the additional authentication requirement.

Configure a Strong Password Policy for the Users

When letting the users to change their own passwords, they should be required to create strong passwords and that they rotate their passwords periodically. On the Account Settings page of the IAM console, you can create a password policy for your account. You can use the password policy to define password requirements, such as minimum length, whether it requires non-alphabetic characters, how frequently it must be rotated, and so on.

Grant Least Privilege

When creating IAM policies, it is important to follow the standard security advice of granting least privilege, or granting only the permissions required to perform a task. Determine what users (and roles) need to do and then craft policies that allow them to perform only those tasks.

  • Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more
    secure than starting with permissions that are too lenient and then trying to tighten them later.
Create individual IAM users

Its important not to use AWS account root user credentials to access AWS. Instead, create individual users for anyone who needs access to the AWS account.

policy summary

The IAM console includes policy summary tables that describe the access level, resources, and conditions that are allowed or denied for each service in a policy. Policies are summarized in three tables: the policy summary, the service summary, and the action summary 

  1. The policy summary table is grouped into one or more Uncategorized services, Explicit deny, and Allow sections. If the policy includes a service that IAM does not recognize, then the service is included in the Uncategorized services section of the table. If IAM recognizes the service, then it is included under the Explicit deny or Allow sections of the table, depending on the effect of the policy (Deny or Allow).
  2. The service summary table includes a list of the actions and summaries of the permissions that are defined by the policy for the chosen service. You can view a service summary for each service listed in the policy summary that grants permissions. The table is grouped into Uncategorized actions, Uncategorized resource types, and access level sections. If the policy includes an action that IAM does not recognize, then the action is included in the Uncategorized actions section of the table. If IAM recognizes the action, then it is included under one of the access level (List, Read, Write and Permissions management) sections of the table.
  3. The action summary table includes a list of resources and the associated conditions that apply to the chosen action. To view an action summary for each action that grants permissions, choose the link in the service summary. The action summary table includes details about the resource, including its Region and Account. You can also view the conditions that apply to each resource. This shows you conditions that apply to some resources but not others.

Amazon Web Services (AWS)  offers high level data protection when compared to an on-premises environment, at a lower cost. Among various AWS security services, Identity and Access Management (IAM) is the most widely used one. It enables secure control access to AWS resources and services for the customers. Customers can create and manage AWS users as well as groups, and provides necessary permissions to allow or deny access to AWS resources. In a simple term IAM provides an infrastructure necessary to control authentication and authorization for its customers account.

AWS Identity access management capabilities 

  • AWS Identity and Access Management (IAM) enables customers to securely control access to AWS services and resources for their users. 
  • Using IAM, customers can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.
  •  IAM makes it easy to provide multiple users secure access to AWS resources.