I did and I used this summary with some bullets and some parts of text extracted from AWS papers and from come online courses like cloud guru, linux academy, udemy. To study concepts about AWS Security.
I hope it could be useful to someone.
Responsibility for security in cloud:
- Customer data
- Platform, application, identity, access management
- Operation system, network, firewall configuration
- Client-Side Data Encryption
- Data Integrity Authentication
- Server Side Encryption (File System and/or Data)
- Networking traffic protection (Encryption, Integrity, Identity)
- Computer, Storage, Database, Networking
- Hardware/ AWS Global Infrastructure
- Regions, Availability Zones, Edge Locations
AWS offers shared responsibility models for each of the different type of service that we offer:
- Infrastructure services
- Container services
- Abstracted services
The customer are responsible for the security of the following assets:
- Amazon Machine Images (AMIs)
- Operating systems
- Data in transit
- Data at rest
- Data stores
- Policies and configuration
Shared Responsibility Model for Infrastructure Services
Principle of Least Privileges
- Give users (or services) nothing more than those privilegies required to perform their intended function. (and only when they need them)
- Who are you?
- AWS Ex: Root Account User, IAM User, Temporary Security credentials
- Prove that you’re who you say.
- AWS Ex: Multi-factor Authentication, Client-Side SSL Certification
- Are you allowed to of this?
- AWS Ex: IAM Policies
- Do other entities that I trust say they trust you?
- AWS Ex: Cross-Account Access. SAML-base federation, Web Identity federation
Typical Components of Security:
- Identity Providers: Facebook, Google, Cognito
- Identity Store
- Identity Broker
- Servide Provider
- Can handle both authorization and authentication
- XML- Based protocol
- Can contain user, group membership and other useful information
- Assertion in the XML for authentication, attributes to authorization
- Best suited for Single sign-on for enterprise users.
- Allow sharing of protected assets without having to send login credentials
- Handles authorization only, not authentication
- Issues token to client
- Application validate token with Authorization Server
- Delegate Access, allowing the client application to access information on behalf of user
- Best suited for API authorization between apps
- Identity layer built on top of OAuth 2.0, adding authentication
- Uses REST/JSON message flows
- Best suite for Single Sign-on for consumers
- Most large organization will have multiples AWS Account
- Segregation of duties, cost allocation, and increased agility
- Need methods to properly manage and maintain them
When Should you use Multiple Accounts?
- Do you require administrative isolation between workloads?
- Do you require limited visibility and discoverability of workloads?
- Do you require isolation to minimize “blast radius” ?
- Do you require strong isolation of recovery and/or auditing data?
AWS Tools for Account Management:
- AWS Organizations
- Service Control Policies
- Resources Groups
- Consolidate Billing
Identity Account Structure:
- Manage all user accounts in one location
- Users trust relationship from IAM roles in sub-account to grant temporary access
- Variations included by Business Unit, Deployment Environment, Geography
Logging Account Structure:
- Centralized logging repository
- Can be secured so as to be immutable
- Can use Service Control Policies (SCP) to prevent sub-account from changing logging settings
Publishing Account Structure:
- Common repository for AMI’s, Containers, Code
- Permits sub-account to use pre-approved standardised service or assets
AWS Organization Account:
Service Control Policies:
- Virtual firewalls for individual assets (Ec2,RDS,AWS Workspaces, etc)
- Controls Inbound and outbound traffic for TCP,UPD,ICMP, or custom protocol
- Port or Port ranges
- Inbound rules are by Source Ip, Subnet, or other Security Group
- Outbound rules are by destination IP, Subnet, or other Security Group
Network Access Control List (NACL)
- Additional Layer of security for VPC that acts as a firewall
- Apply to entire subnets rather than individual assets
- Default NACL allow all inbound and outbound traffic
- NACLs are stateless, its meaning outbound traffic simply obeys outbound rules, no connection is maintained.
- Can duplicate or further restrict access along with Security Groups
Why use SG’s and NACL’s ?
- NACLs provide a backup method of security if you accidentally change your SG to be too permissive.
- Covers the entire subnets so users to create new instances and fail to assign a proper SG are still protected.
- Part of a multi-layer Least Privilege concept to explicitly allow and deny.
Types of Directory Service Offered:
- AWS Cloud Directory:
- Cloud native directory to share and control access to hierarchical data between application
- Best for cloud applications that need hierarchical data with complex relationship.
- Amazon Cognito:
- Sign-up and Sign-in functionality that scales to millions of users and federated to public social media services
- Best for Develop consumer apps or Saas
- AWS Directory Service for Microsoft Active Directory:
- AWS-managed full Microsoft AD (Standard or enterprise) running on Windows Server 2012 R2
- Best for Enterprises that want hosted Microsoft AD or you need LDAP for Linux apps
- AD Connector:
- Allows on-premisses user to log into AWS service with there existing AD credentials. Also allows Ec2 instances to join AD domain.
- Best for single sign-on for on-premisses employees and for adding Ec2 instances to the domain.
- Simple AD:
- Low scale, low cost AD implementation based on Samba
- Best for simple user directory, or you need LDAP compatibility
AD Connector vs Simple AD:
- AD Connector
- must have existing AD
- Existing AD user can access AWS assets via IAM roles
- Supports MFA via exiting RADIUS-based MFA infrastructure
- Simple AD
- Stand-alone AD based on Samba
- Supports user accounts, groups, groups policies and domains
- Kerberos- based SSO
- MFA not supported
- No trust Relationship
Token Vending Machine Concepts:
- Common way to issue temporary credential for mobile app development
- Anonymous TVM - Used as way to provide access to AWS services only, does not store user identity
- Identity TVM, used for registration and login, and authorizations
- Mobile developers can use Congnito and the related SDK
AWS Secret Manager
- Store passwords, encryption keys, API keys, SSH keys,PGP keys, etc.
- Alternative to storing passwords or key in a “valut”
- Can access secrets via API with fine-grained access control provided by IAM
- Automatically rotate RDS database credentials for Mysql , PostgreSQL and Aurora
- Better than hard coding credentials in scripts or application
- Encryption at Rest
- Data is encrypted were it is stored such as on EBS, on S3, in a RDS database, or in a SQS queue waiting to be processed
- Encryption in Transit
- Data is encrypted as it flows through a network to process, such as SSL/TLS for HTTP, or with IPSec for VPN Connections.
Key Management Service (KMS)
- Key storage, management and auditing
- Tightly integrated into MANY AWS services like lambda, S3,EBS,EFS,DynamoDB,SQS, etc.
- You can import you own keys or have KMS generates them
- Control who manages and accesses keys via IAM users and roles
- Audit use of keys via CloudTrail
- Differs from Secrets Manager as its propouse-build for encryption key management
- Validated by many compliance schemes (PCI DSS Level1, FIPS 104-2 Level 2)
- Dedicated hardware devices, Single Tenated
- Must be within VPC and can access via VPC Peering
- Does not natively integrate with many AWS services like KMS, but rather requires custom application scripts
- Offload SSL from web servers, act as an issuing CA, enable TDE for Oracle databases
CloudHSM vs KMS
|Tenancy||Single Tenant HSM||Multi-Tenant AWS Service|
|Availability||Customer-Managed durability and availability||Highly availability and durable key storage and management|
|Root od Trust||Customer managed root of trust||AWS managed root of trust|
|FIPS 104-2||Level 3||Level 2/Level 3 in some areas|
|3rd Party Support||Board 3rd Party Support||Board AWS Service Support|
AWS Certificate Manager
- Managed service that lets you provision, managed and deploy public or private SSL/TLS certificates
- Directly integrated into many AWS Service like CloudFront, ELB and API Gateway
- Free public certificates to use with AWS services; no need to register via a 3rd party certificate authority
- Possible import 3rd party certificate for use on AWS
- Supports wildcards domain (*.domain.com) to cover all you subdomains.
- Managed certificated renewal (no embarrassing “certificates expired” messages for customer)
- Can create a managed Private Certificate Authority as well for internal or proprietary apps, services or devices
|Best Practice||AWS Service|
|Minimize attack surface||NACLs, SGs, VPC Design|
|Scale to absorve attack||Auto-Scaling Groups, AWS Cloud Front Static web content via S3|
|Safeguard exposed resources||Route 53, AWS WAF, AWS Shield|
|Learn normal Behaviour||AWS GuradDuty, CloudWatch|
Intruder Prevention and Detection
- IDS (Intruder Detection System) : watches the network and system for suspicious activity that might indicate someone trying to compromise a system.
- IPS (Intruder Prevention System) : tries to prevent exploits by sitting behind firewalls and scanning and analysing suspicious content for threats. Ex: IPD in that it can automatically take action on intrusion, like blacklist an offending IP address.
- Normally comprised of a Collection/ Monitoring System and monitoring agents on each system
- Logs collected or analysed in CloudWatch, S3 or third-party tools (Splunk, SumoLogic, etc) sometimes, called a Security information and Event Management system (SIEM).
CloudWatch vs CloudTrail
|Log events across AWS Service||Log API activity across services|
|Higher level comprehensive Monitoring and Eventing||Lower lever granular|
|Logs from multiple accounts||Logs from multiple accounts|
|Logs stored indefinitely||Logs stored to S3 or CloudWatch indefinitely|
|Alarms history for 14 days||No native alarming; Can use CloudWatch alarms|
AWS Service Catalog
- Framework allowing administrator to create pre-defined products and landscape for their users.
- Granular control over which user have access to which offering.
- Makes use adopted IAM roles so user don’t need underlying services access
- Allow end users to be self-sufficient while upholding enterprise standards for deployment.
- Based on CloudFormation templates
- Administrator can version and remove products. Existing running products version will not be shutdown.
AWS Service Catalog Constraints
|Launch Constraint||IAM role that Service Catalog assumes when and end-user launch a product||Without a launch constraint, the end-user must have all permission needed within their own IAM credentials.|
|Notification Constraint||Specific the AWS SNS topic to receive notification s about stack events.||Can get notifications when products are launched or have a problem.|
|Template Constraint||Ore or more rules the narrow allowed values and end-user can select.||
Adjust product attributes based on choices a user makes.
Example: Only allow certain instances types for DEV environment.
- The challenge with layer 7 detection is telling an attack from normal user traffic. CloudFront in conjunction with AWS WAF can be an effective way to create DDoS resilience at Layer 7.
- OAuth 2.0 provides authorization only and issues tokens to clients. It is best suited to API authorization between apps rather than SSO
- NACLs are stateless and support DENY rules while SGs are stateful and have no DENY rules.
- Simple AD is a scaled-down version of AD with limited feature support. It does not support trust relationships with other domains
- Principle of Lease Privilege says to only grant just enough access as required and nothing more--preferably only when its needed
Using the Trusted Advisor Tool
The Trusted Advisor tool offers a one-view snapshot of your service and helps identify common security misconfigurations, suggestions for improving system performance, and underutilized resources.
Trusted Advisor checks for compliance with the following security recommendations:
- Limited access to common administrative ports to only a small subset of addresses.This includes ports 22(SSH), 23(Telnet) 3389(RDP),and 5500 (VNC).
- Limited access to common database ports. This includes ports 1433 (MSSQL Server), 1434 (MSSQL Monitor), 3306 (MySQL), Oracle (1521) and 5432 (PostgreSQL).
- IAM is configured to help ensure secure access control of AWS resources.
- Multi-factor authentication (MFA) token is enabled to provide two-factor
- Authentication for the root AWS account.
Amazon S3 Features for Protecting Data at Rest
Protecting Data at Rest on Amazon EMR
Protecting Data in Transit to Amazon EMR
Your Operating Systems and Applications
- Disable root API access keys and secret key
- Restrict access to instances from limited IP ranges using Security Groups
- Password protect the .pem file on user machines
- Delete keys from the authorized_keys file on your instances when someone leaves your organization or no longer requires access
- Rotate credentials (DB, Access Keys)
- Regularly run least privilege checks using IAM user Access Advisor and
- IAM user Last Used Access Keys
- Use bastion hosts to enforce control and visibility
Clean-up Tasks before Publishing an AMI
Securing Linux/UNIX AMIs
Securing Windows AMIs
Using Additional Application Security Practices
- Always change vendor-supplied defaults before creating new AMIs or prior todeployingnewapplications, including but not limited to passwords, simple network management protocol (SNMP) community strings, and security configuration.
- Remove or disable unnecessary user accounts.
- Implement a single primary function per Amazon EC2 instance to keep functions that require different security levels from co-existing on the same server. For example, implement web servers, database servers, and DNSon separateservers.
- Enable only necessary and secure services, protocols, daemons, etc., as required for the functioning of the system.Disableallnon-essential services, because they increase the security risk exposure for the instance, as well as theen tire system.
- Disable or remove all unnecessary functionality, such as scripts, drivers, features, subsystems, EBS volumes, and unnecessary web servers.
Using Amazon Virtual Private Cloud (VPC)
|Concern||Recommended Protection Approach|
Encrypt application and administrative traffic using SSL/TLS, or build custom user VPN solutions.
Carefully plan routing and server placement in public and private subnets.
Use security groups and NACLs.
|IPSec over the Internet|
Establish a private IPSec connection using IKEv1 and IPSec using standard AWS VPN facilities (Amazon VPC VPN gateways, customer gateways, and VPN connections).
Alternatively, establish customer- specific VPN software infrastructure in the cloud, and on-premises.
|AWS Direct Connect without IPSec||Depending on your data protection requirements, you might not need additional protection over private peering.|
|AWS Direct Connect with IPSec||See IPSec over the Internet above.|
Using Security Zoning and Network Segmentation
On AWS, you can build network segments using the following access control methods:
- Using Amazon VPC to define an isolated network for each workload or organizational entity.
- Using security groups to manage access to instances that have similar functions and security requirements
- Using Network Access Control Lists (NACLs) that allow stateless management of IP traffic
- Using host-based firewalls to control access to each instance.
- Creating a threat protection layer in traffic flow and enforcing all traffic to traverse the zone.
- Applying access control at other layers.
Controls for Periphery Systems
Techniques for Mitigation and Protection from DoS/DDoS Attacks
Security monitoring starts with answering the following questions:
- What parameters should we measure?
- How should we measure them?
- What are the thresholds for these parameters?
- How will escalation processes work?
- Where will data be kept?
Perhaps the most important question you must answer is “What do I need to log?” We recommend configuring the following areas for logging and analysis:
- Actions taken by any individual with root or administrative privileges
- Access to all audit trails
- Invalid logical access attempts
- Use of identification and authentication mechanisms
- Initialization of audit logs
- Creation and deletion of system level objects
Log File Considerations