Before we can build the new Web Phonebook Application, you need to have a free AWS account and you need some background information about how AWS IAM works and how it applies to our Web Phonebook Application.
In this lesson, I ask you to setup your AWS free account if you don’t already have an account and I share key information about IAM and how it relates to our Web Phonebook Application before I walk you through the steps to implement AWS IAM for out application and AWS environment.
Since this is a beginners series of lessons, we will be accessing AWS and building our application via the AWS Web Management Console as opposed to using one of the more advanced methods such as the AWS Command Line Interface or AWS Software Development Kits.
AWS Free Account Setup
In order to build the Web Phonebook Application, you will need a free AWS account. You will need a trustworthy email account, password, and credit card in the event you go over your free limits. I strongly encourage you to stay away from free accounts from Yahoo, Google, and similar email providers if possible. You can always get a free Protonmail account at no charge and be confident your important account information is not being read.
The email address that you sign up with becomes the root user to the account. This root user has unrestricted access to EVERYTHING in this account. You need to take steps to protect your account.
Since your personal credit card is on file with AWS, you absolutely do not want an attacker compromising your account and running up a huge bill on your behalf or committing a crime from your environment.
In a future lesson, I will walk you through how to enable Multi-Factor Authentication to help make it more difficult for this account to be compromised. I will show you how to setup a virtual MFA device (Google Authenticator).
I also show you how to not use your root user account for anything other than billing and very few other legitimate use cases by setting up a new IAM user with administrative permissions.
Using AWS IAM, I will show you how to setup an admin account that will allow you to develop the new application and not expose your root account. We will also enable MFA on the admin account as well. I strongly recommend MFA to be required for any admin level accounts. If you are really awesome, you will require MFA across the board.
For now, go setup your free account and review the best practices in the two sections below. You don’t need to take any actions beyond setting up the free account just yet. In this lesson, I wanted to expose you to this information and then I will walk you through how to properly secure your root account and then setup a new IAM account with admin privileges to build out the application.
Best Practices For The AWS Root User
As mentioned above, the root user has complete access to all AWS services and resources in your account, in addition to your billing and personal information. Due to this, you should securely lock away the credentials associated with the root user and do not use the root user for everyday tasks.
To ensure the safety of the root user, you need to be aware of these best practices:
- Choose a strong random unique password for the root user. Do not use this password and preferably email anywhere else.
- Never share your root user password or access keys with anyone
- Disable or delete the access keys associated with the root user
- Do not use the root user for administrative tasks or everyday tasks
Delete Your Root Keys
If you don’t have an access key for your AWS account root user, don’t create one unless you absolutely need to. If you have an access key for your AWS account root user and want to delete the keys, follow these steps:
- In the AWS Management Console, go to the My Security Credentials page, and sign in with the root user’s email address and password.
- Open the Access keys section.
- Under Actions, choose Delete.
- Choose Yes.
IAM Basics For Web Phonebook Application
For our application, we need to use AWS Identity & Access Management Services (IAM) to establish a new admin account and setup access control and credential management. I want to expose you to some basic information that you need to be aware of before we build the application and setup the authentication and authorization.
Refer to Point A in the diagram above. IAM will allow us to setup access controls handing the authentication portion to AWS services. In other words, you need a valid account and password in order to be able to access the AWS environment. This is separate from authenticating to the web-based application, so don’t get these confused.
Refer to Point B in the diagram above. Our WPA application is technically running on a virtual server in the AWS cloud within our VPC (Virtual Private Cloud) on an EC2 instance. Our application code will need to make API calls to the S3 buckets (Simple Storage Service) in order for the application to allow the user to add, edit, modify, and delete records in the phonebook application. I will walk you through the steps of how to do this in a later lesson. For now, just be aware of the information and if you are a security professional, take note of this.
One of the benefits of AWS is the code running on your EC2 instance is not automatically allowed to authenticate and make changes to your S3 object storage buckets. This is a good thing and from a security perspective, we will take small wins like this anytime we can get them.
In fact, all API calls in AWS must be signed and authenticated in order to be allowed which means IAM will need to be involved in this process.
In order to make our application work correctly, the application code on the EC2 instance needs access to credentials to make the signed API calls to S3. We need to use IAM Roles to handle the signed and authenticated API calls from our application to S3. I will walk you through how to do this in a future lesson.
IAM TIPS & CONSIDERATIONS
After you setup your root account, you should not use it again unless you need to change your billing information or delete your account. I will walk you through how to setup a new admin-type user account in AWS IAM and assign it to a group that is managed by a policy to control authorization to the application environment.
In reality, there are typically many developers and administrators in an organization that would need access to various aspects of the system and application. We don’t want to assign access management at the individual user level. This is where IAM Groups and IAM Roles come into play and I will walk you through this is a future lesson.
Each user mush have unique credentials to access assets needed to perform their jobs. Never share credentials under any circumstance. IAM is used to create the credentials for each user and also responsible for the creation and management of groups for these users as well as the signed API calls to AWS Services that we will be setting up later.
IAM is not designed to handle access management at the application level for our WPA application, so be clear if we want authentication to the actual application, we will need to handle that in our application code.
After users are authenticated, they need to be authorized to perform specific tasks. By using IAM Policies, we can control the authorization discussed here and at a very granular level. More on this later in future lessons.
The best practice is to assign individual users to groups using the admin account (not root account) and create policies for the groups because any user that is part of the group would inherit the permissions created in the IAM policy.
Also, it is impossible to apply a policy to a root user, which makes sense and you should not be using the root account anyway.
- AWS Management Console
- AWS Command Line Interface
- AWS Software Development Kits
- Free AWS Account Signup
- Multi-Factor Authentication (MFA)
- AWS IAM
- AWS IAM Policies
- IAM Groups
- IAM Roles
- VPC (Virtual Private Cloud)
- EC2 (Elastic Cloud Computing)
- S3 (Simple Storage Service)
Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management for business stakeholders across the enterprise. Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier.
Stay Connected With Tim Layton
Get My Free Cloud Security Journal
COMMON CYBERSECURITY RISK TERMS DEFINED
Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. (NIST 800–30)
Threat: potential cause of an unwanted incident, which can result in harm to a system or organization. (ISO 27001)
Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. (NIST 800–30)
Vulnerability: weakness of an asset or control that can be exploited by one or more threats. (ISO 27001)
Likelihood: A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities. (NIST 800–30)
Likelihood: chance of something happening. (ISO 27001)
Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NIST 800–30)
Risk: effect of uncertainty on objectives. (ISO 27001)
Security Controls: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NIST 800–30)
Compensating Security Control: A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NIST 800–30)
Impact Level: The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. (NIST 800–30)
Residual Risk: Portion of risk remaining after security measures have been applied. (NIST 800–30)
Security Posture: The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST 800–30)
Get My Free Cloud Security Journal