AWS Certified SysOps – Associate Notes
Mục lục
- 1. Security on AWS
- Shared Responsibility Model
- IAM: users and Groups
- Root user
- Best practices for the root user
- IAM User
- Best practices for users
- IAM Groups
- Rest practices for groups
- IAM policies
- Managed policies
- Custom policies
- IAM Roles
- Roles with AWS services
- Other uses of Roles
- IAM: Multi -Factor Authentication (MFA)
- What is Multi -Factor Authentication?
- AWS Scenario
- Amazon 53: Bucket Policies
- Elements of a Pucket Policies
- Effect
- Action
- Resource
- Principal
- Sid (Optional)
- Condition (Optional)
- S3 Data Integrity
- Versioning
- Replication
- Multi-Factor Authentication Delete (MFA Delete)
- Amazon VPC: Security Group and NACLS
- VPC (Virtual Private Clond)
- Security Groups
- NACLS (Network Access Control list)
- Host-based Fire walls: Os-level frewalls as needed
- AWS STS: Federation
- Secure Token Service (STS)
- Identity Federation
- Amazon Inspector
- VNTechies Dev Blog
1. Security on AWS
Shared Responsibility Model
Customer Responsible for security IN the cloud | AWS Responsible for security OF the cloud |
---|---|
Customer data | Regions, availability zones & edge locations |
Platform, application & IAM | Physical level and below |
OS patching on EC2 | Fire, power, climate management |
Antivirus | Storage device decommissioning according to industry standards |
Network and firewall configuration | Personnel security |
Multi-factor authentication | Network device security & ACLs |
Password and key rotation | API access points use SSL for secured communication |
Security groups | DDos protection |
Resource-based policy | EC2 instances and spoofing protection |
Access control list | Port scanning even if it's your environment |
VPC | EC2 instances hypervisor isolation |
OS level patches | Instances on the sane physical devices are separated at the hypervisor level they are independent of each other |
Data in transit & data at rest | Underlying OS patching for Lambda, RDS, Dynamo DB, and other managed services customers focus on security |
IAM: users and Groups
Root user
- The user created when the AWS account is created
- The credentials are the email & password used when signing up for the AWS account
- By default, the root user has full administrative rights & access to every part of the account
Best practices for the root user
- We should not use the root user for daily work & administration
- another account that has admin rights should be used
- The root user account should not access keys. Delete them if they exist
- The root user should use MFA
IAM User
- A new user has an implicit deny for all AWS services and requires a policy be added to grant them access
- Users receive unique credentials (username, password & access keys)
- Users can have IAM policies applied directly to them, or they can be a member of a group that has policies attached
- With policies, an explicit deny always overrides an explicit allow from attached policies
- for instance, AWS will ignore all policies attached to a user if a single deny-all policy is added
Best practices for users
- Never store or "pass" your credentials to EC2 instances - use SSH forwarding
- MFA can and should be used for users' accounts
- Access credentials are unique and should never be shared
IAM Groups
- Allow for policy assignments to multiple users at the same time
- We may assign permission to a group
- More organized and efficient way's to manage users and policies
- Cannot be nested
- Users may be the members of multiple groups
Rest practices for groups
- Organize users by functions
- Assign IAM policies to groups, not individual users
IAM policies
- A document that states one or more permissions (JSON formatted)
- An explicit deny always overrides an explicit allow.
- This allows for the users of a deny-all policy to quickly restricts all access a user may have
Managed policies
- AWS provides pre-built policy templates to assign to users & groups
- Examples include:
- Administrator access: Full access to all AWS resources
- Power-user access: Admin access, except it does not allow user/group management
- Read-only access: Only view AWS resources (e.g., user can only view what is in S3 buckets)
Custom policies
- You can create custom IAM policies using the policy generator or write them from scratch
- More than one policy can be attached to a user/group at the same time
- Policies can not be directly attached to AWS resources (such as an EC2 instance)
IAM Roles
- Temporary security credentials in AWS managed by Security Token Service (STS)
- Another entity can assume the specific permissions defined by the Roles
- These entities include:
- AWS resources (e.g., EC2 instance)
- A user outside of AWS needs temporary access
Roles with AWS services
- We must use role because policies cannot be attached directly to AWS resources
- Services can only have one role attached at a time
- You should never pass or store credentials to an EC2 instance - instead, use role
- You may change the role of running EC2 instances through the console or URI
Other uses of Roles
- Cross-account access (delegation)
- Provide access to another AWS account from another account
- Identity Federation
- Users ordside AWS can assume a role for temporary access to aws account and resources
- These users assume an identify provider access role
- Example identity providers:
- Active Directory
- Single sign on providers: like Facebook, Google, Amazon
IAM: Multi -Factor Authentication (MFA)
What is Multi -Factor Authentication?
- A security method that requires multiple seperate authentications
- One authentication option we nave with AWS uses time-based codes.
- Familiar examples of MFA: ATM to withdraw morey, both physical card & a PIN
AWS Scenario
- Enable MFA in order to access AWS console:
- Users type in their username and password as well as a time-based code
- The username and password are not enough to be authenticated
- The time-based code can be on the user's computer, smartphone or a device they carry around
- This should be turn on for users who have access to the console
- MFA Delete for S3 obrects can be used to mitigate acidental deletions
Amazon 53: Bucket Policies
- JSON statement used to allow or deny permission across obfects in a single bucket
Elements of a Pucket Policies
Effect
- Define whether to allow or deny the action
Action
- Actions we want to allow or deny
- Important An explicit deny always override an explicit allow
Resource
- Used to identity resources (like a bucket & object) with ARNs
Principal
- An account or users that this policy applies to
- Specific to S3 bucket policies, not user policies
Sid (Optional)
- Statement identifier that provides a way to indude information about an individual statement
Condition (Optional)
- Specify condition for when the policy is in effect
S3 Data Integrity
Versioning
- Enable to store new versions for every modification or deletion
- Help with accidental deletion by creating Dersions for deleted obrects
Replication
- Object are replicated across AZ automatically
- Standard and Infrequent Acces options at differents price options
Multi-Factor Authentication Delete (MFA Delete)
- MFA to prevent accidental deletion of objects
- Requires Versioning enable on a bucket
- We can enforce the use of MFA in order to permanently delete an object
- Only root account (the bucket owner) can access this feature
Amazon VPC: Security Group and NACLS
VPC (Virtual Private Clond)
- Isolate workloads into separented VPCs (based on applications , department, test, dev, etc)
Security Groups
- Group instances with similar functions
- Stateful = every allowed TCP or UDP ports will be allowed in both directions.
NACLS (Network Access Control list)
- Stateless = inbound and outbound rules are separate, no dependencies
- Granular control over IP protocols (allow and deny rules for inbound and outbound evaluated in order)
- Work with security groups (NACLs applies for the whole subnet, security groups app to members)
- Ephemeral ports: Client requests depending on OS(port 1024-65535)
Host-based Fire walls: Os-level frewalls as needed
AWS STS: Federation
Secure Token Service (STS)
An extensions of IAM that allows for management of temporary security credentials for IAM users or federated users
- It allows for granular control of how long the access remains active
- Fifteen minutes to one hour (default = 1 hour)
- Credentials are not stored with the user or service granted temporary access -A token is attached to the access request of API call
- Beneficial in a mumber of ways
- Low risk of credentials being exposed (not distributed)
- Do not have to create IAM identities for every user
- Because they are temporary in nature, there is no need to rotate keys
- STS uses a single endpoint
- This single endpoint resides in us-east-1
- Latency can be reduced by using STS API calls to regions that support them
- Temporary credentials have global scope, just like IAM
Identity Federation
- Federation: Providing a non-AWS user temporary AWS access by linking that user's indentity accross multiple identity systems
- Federation with Third-Party Providers:
- Most commonly used in web and mohile applications
- Amazon Cognito allows for creation of unique identities for users
- Uses identity providers to federate them: Facebook, Google, Amazon, etc
- Establishing Single-Sign-On (SSO) using SAML2.0
- Most commonly used in enterprise environment with an existing directory system
- Active Drectory,...
- Federated users can access AWS resources using their corporate domain account
- Federation also aids user management by allowing central management of accouts
- Most commonly used in enterprise environment with an existing directory system
Amazon Inspector
Inspector can
- Analyze the behavior of your AWS account
- Test network accessibility and security state
- Assesses for secunty vulnerabitaties and deviations from best pratices
- Target: A collection of Ecz instances
- Assessment template: Composed of security rules and produce a list of findings
- Assessment run: Applying the assegment tiplate to a tanget
- Findings: Security report, organized by severity level
- Features:
- Configuration scanning and activity monitoring engine:
- Determines what a target look like, its behavior, and any dependencies it may have
- Identifies security and compliances issues
- Configuration scanning and activity monitoring engine:
TO BE UPDATED
VNTechies Dev Blog
Kho tài nguyên mã nguồn mở với sứ mệnh đào tạo kiến thức, định hướng nghề nghiệp cho cộng đồng Cloud ☁️ DevOps 🚀
Tham gia group VNTechies - Cloud ☁️ / DevOps 🚀 nếu bạn muốn giao lưu với cộng đồng và cập nhật các thông tin mới nhất về Cloud và DevOps.
- Website: https://vntechies.dev
- Github repository: https://github.com/vntechies
- Facebook page: https://facebook.com/vntechies
Anh chị em hãy follow/ủng hộ VNTechies để cập nhật những thông tin mới nhất về Cloud và DevOps nhé!