Security Introduction

Published on
Reading time
5 min read

Overview

This one will be less focused on cloud-security and more about specific things important to know in the AWS ecosystem such as their shared responsibility model (although this model is quite similar to other cloud providers too).

The AWS Shared Responsibility Model

The purpose of this model is to articulate which parts of security are handled by AWS and others that are handled by the AWS users/developers. AWS secures things like the physical hardware, data centers, the infrastructure of the AWS network, and their virtualization environments. This is often stated as "AWS handles the security of the cloud. On the other side, users of AWS handle "the security in the cloud" meaning they are responsible for user account permissions, resource permissions, software running in servers or containers, and generally anything that is configurable / deployable by a user.

Identity and Access Management (IAM)

IAM is all about configuring access of user accounts (or roles) to provide varying levels of access to resources. There are a ton of different roles and concepts to go over within IAM, but I'll only introduce the basics. To start, there are important security priorities to deal with when first making an AWS account.

Top IAM priorities

Upon creating an account, users are initially logged into what is called the root user account. Its best practice to not use this account often and lock it down by doing the following:

  1. Enable Multi-factor Authentication
    • Do not do SMS-based MFA, use a time-based one-time password (TOTP) or a Yubikey for the most security (this should also be on all user accounts)
  2. Provision a Separate User Account
    • Give whatever permissions are necessary while aiming for least privilege
  3. Switch to that account as your regular user account
    • Log out of the root and into the new (ideally more restricted) user account

IAM Users and Groups

An IAM user is one of the fundamentals entities that permissions will be set on. They default to having no permissions, but what they have access to can be configured in a very granular level using policies. IAM groups can be defined to manage assigning multiple policies to multiple users. By assigning a policy to a group of users, all of the users assigned to that group will get the policy.

IAM Policies

An IAM policy is what provides these granular rules for users and groups. They can vary in kind and scope. For example, a rule could apply to all instances of a service or a single instance such as a rule for a single S3 bucket vs. all buckets.

IAM Roles and Service Roles

IAM roles can be temporarily allocated to a user performing a specific task. The aren't permanently set and must be approved to be added. Another use-case is a service role which gives a service access to another service. For instance, if a Lambda function wanted to save something to an S3 bucket, it would need to be assigned the necessary permissions just like a user.

AWS Organizations

This service allows an organization to efficiently manage multiple AWS accounts. These are grouped and can be managed with central policies called service control policies (SCPs) which are set on an account and will be applied to all users in that account. Additionally, billing will be consolidated into one from each of the separate accounts.

Organizational Unit (OU)

This is kind of like an IAM Group, but applies policies to groups of AWS accounts. Permissions (SCPs) set against an organizational unit will apply to all accounts in that OU.

Denial-of-Service Attacks (DOS)

DOS attacks aim to down your services by either overwhelming them with a large workload or bogging them down using a variety of creative techniques. AWS offers several strategies and services that can mitigate these threats significantly. For example, using ELB prevents bad attackers miming a slow connection from blocking other user's request from being handled. Similarly, AWS WAF (Web Application Firewall) can review traffic to block any suspected bad actors from getting through. It is configurable and has some ML capabilities to be smarter about who gets in and who gets blocked. In this case, configuring VPC access correctly is also important ot stop unwanted traffic from getting in and overwhelming resources. Lastly, AWS Shield can be used and integrated with many AWS services to help mitigate DOS or DDOS attacks (distributed denial-of-service). Shield works by triggering alert in CloudWatch when traffic suddenly shows a significant change in kind and quantity.

AWS GuardDuty and Amazon Inspector

Inspector and GuardDuty provide automated security analysis and threat detection across an AWS environment and VPC network. GuardDuty will analyze and detect threats to provide actions to take to improve security by monitoring traffic and different service configurations. Inspector tracks where applications are lacking when it comes to best practices and security compliance and provides ways to fix these issues. Altogether, it provides an automated security assessment to generate a report of security findings.

Security Compliance (of AWS)

AWS Artifact provides security compliance documentation for AWS that has been completed by third-party auditors.

Discuss on Twitter