Shared Responsibility Model

Indicates which part of security AWS and the client are responsible for. The responsibilities are, basically:

AWS → Physical security of data centers, virtualization software, and infrastructure (regions, AZs, edge locations) → Security OF the cloud.
- Provide software security for clients to use.
Client → Security IN the cloud → Application and dataset security.
- Patching/maintenance of instances.
- Application passwords, role access, and AWS account management.
- Security group and network configuration.
- Firewalls in OSs.

Service Types

Types of services:

Infrastructure as a Service (IaaS) → Customer has control of the service and is in charge of security and maintenance.
Platform as a Service (PaaS) → Services that use infrastructure, but the underlying infrastructure is managed by the provider.
Software as a Service (SaaS) → Complete software solution, customer doesn’t manage anything.

Allows you to define users and the types of access they have → Free and global service.

You assign policies and credentials to each user.

Components:

IAM User → Person/application allowed to access the AWS account. By default NO permissions (Principle of Least Privilege).

IAM Group → Collection of IAM users granted the same access. Permissions granted by IAM Policies. Users can have multiple groups.

IAM Policy → Document that defines access to one/more services, independent of groups/users. Permissions defined here.

Written in JSON, and can be explicitly deny or allow (by default all deny), if explicitly deny, doesn’t matter if allowed in other places.
Types:
- Identity Based → Attached to IAM User, IAM Group, or IAM Role.
  - AWS Managed → Created and managed by AWS. They scale well.
  - Customer Managed → Created and managed by you. Customize policies to your needs.
  - Inline → You create and manage, and it’s embedded into the user/resource/group directly.
- Resource Based → Attached to a resource, define access and what actions can be performed (only inline).
  - WHO can access the resource.

IAM Role → Grant permissions to add multiple permissions, useful for TEMPORARY uses.

🌎 Global service.
Can be assumed by a person/application/service.
When the role is assumed, the user permissions are replaced by the role ones.
You have to get permissions to assume a role.
AWS Security Token Service (STS) to assume a role.
Types of access control:
- Role-Based Access Control (RBAC).
  - Grant permissions based on job function.
  - Grant role for specific combinations.
  - Fine grained access control, but can be time consuming.
- Attribute-Based Access Control (ABAC)
  - Permissions based on tags on resources.
  - Policies are easier to write and combine.
  - Tag the users and resource.
  - Scalable and no need to modify policy when resources are created.
Used to set up cross-account access to delegate access to resources and avoid creating users in other accounts.

Types of Access:

Programmatic → Useful for the AWS CLI or AWS SDK. Access key ID and secret key.
Management Console → Useful for the Web. Account ID (or alias), username, and password. Can use Multi Factor Auth (RECOMMENDED).

Authorization → Determine permissions user/service should be granted, after authentication.

Contents:

Version → Version of the policies (2012-10-17, old version is 2008-10-17).
Statement → Body of the policy, single or array.
Effect → Allow or deny (default DENY). Deny >> allow >> default.
Action → List of actions allowed/denied.
Resource → List of resources the actions apply to (identified by the ARN, Amazon Resource Name).
- NotResource → Inverse case, effect applies to all the NON-specified resources.
Condition → Conditions to be met for the policy to apply. If there are multiple conditions, IAM uses an OR to apply conditions.

Wildcards (*) can be used to be more general.

The user authentication is performed by an external system or Identity Provider.