Please enable JavaScript.
Coggle requires JavaScript to display documents.
Security - Coggle Diagram
Security
AWS Services
Security for Kinesis:
- Kinesis Data Streams:
- Has SSL endpoints using the HTTPS protocol to do encryption in flight
- AWS KMS provides server side encryption [Encryption at rest]
- For client side encryption, I must use my own encryption libraries
- Supported Interface VPC Endpoints / Private Link access privately (can access the Kinesis service within our private EC2 instances privately
- KCL must get read / write access to DynamoDB table to do check pointing and sharing the work between different KCL instances
- Kinesis Data Firehose:
- Attach IAM roles so it can deliver to S3 / ElasticSearch / Redshift / Splunk
- Can encrypt the delivery stream with KMS [Server side encryption]
- Supported Interface VPC Endpoints / Private Link access privately
- Kinesis Data Analytics:
- Attach IAM role so it can read from Kinesis Data Streams and reference sources and write to an output destination (example Kinesis Data Firehose)
Security for SQS:
- Encryption in flight using the HTTPS endpoint
- Server Side Encryption using KMS
- IAM policy must allow usage of SQS
- SQS queue access policy
- Client side encryption must be implemented manually and I must do it myself
- VPC Endpoint is provided through an Interface to access the SQS service securely
Security for IoT:
- AWS IoT policies:
- Attached to X.509 certificates or Cognito Identities into devices
- Able to revoke any device at any time
- IoT Policies are JSON documents
- Can be attached to groups instead of individual Things
- IAM Policies:
- Attached to users, group or roles
- Used for controlling IoT AWS APIs
- Attach roles to Rules Engine so they can perform their actions
- e.g. if my Rules Engine action is sending data to Kinesis, I need to attach an IAM role to that rule
Security for Quicksight:
- Standard edition:
- IAM users
- Email based accounts
- Enterprise edition:
- Active Directory
- Federated Login
- Supports MFA (Multi Factor Authentication)
- Encryption at rest and in SPICE
- Row Level Security to control which users can see which rows
Security for Athena:
- IAM policies to control access to the service
- Data is in S3: IAM policies, bucket policies & ACLs
- Encryption of data according to S3 standards: SSE-S3, SSE-KMS, CSE-KMS
- Encryption in transit using TLS between Athena and S3 and JDBC enable by SSL
- Fine grained access using the AWS Glue Catalog
Security for S3:
- IAM policies
- S3 bucket policies
- Access Control Lists (ACLs)
- Encryption in flight using HTTPS
- Encryption at rest
- Server-side encryption: SSE-S3, SSE-KMS, SSE-C
- Client-side encryption such as Amazon S3 Encryption Client
- Versioning + MFA Delete
- CORS for protecting websites
- VPC Endpoint is provided through a Gateway
- Glacier vault lock policies to prevent deletes (WORM)
Security for DynamoDB:
- Data is encrypted in transit using TLS (HTTPS)
- DynamoDB can be encrypted at rest
- KMS encryption for base tables and secondary indexes
- Only for new tables
- To migrate un-encrypted table, create new table and copy the data
- Encryption cannot be disabled once enabled
- Access to tables / API / DAX using IAM policy
- DynamoDB Streams do not support encryption
- VPC Endpoint is provided through a Gateway
Security for RDS:
- VPC provides network isolation
- Security Groups control network access to DB Instances
- KMS provides encryption at rest
- SSL provides encryption in-flight
- IAM policies provide protection for the RDS API
- IAM authentication is supported by PostgreSQL and MySQL
- Must manage user permissions within the database itself
- MSSQL Server and Oracle support TDE (Transparent Data Encryption)
Security for Aurora:
- Very similar to RDS
- VPC provides network isolation
- Security Groups control network access to DB Instances
- KMS provides encryption at rest
- SSL provides encryption in-flight
- IAM authentication is supported by PostgreSQL and MySQL
- Must manage user permissions within the database itself
Security for Lambda:
- IAM roles attached to each Lambda function
- Pull data from Sources
- Send data to Targets
- KMS encryption for secrets
- Pass secrets to Lambda function, I could use KMS to encrypt the variable, run decrypt function with the Lambda function provide it has the right IAM roles
- SSM parameter store for configurations in the Lambda function
- Encrypt the secret within SSM with KMS
- CloudWatch Logs
- Deploy Lambda function in VPC to access private resources
Security for Glue:
- IAM policies for the Glue service
- Configure Glue to only access JDBC through SSL (Glue to database; data in-flight is encrypted)
- Data Catalog:
- Encrypted by KMS
- Resource policies to protect Data Catalog resources (similar to S3 bucket policy)
- Connection passwords: Encrypted by KMS
- Data written by AWS Glue - Security Configurations:
- S3 encryption mode: SSE-S3 or SSE-KMS
- CloudWatch encryption mode
- Job bookmark encryption mode
Security for EMR:
- Using Amazon EC2 key pair for SSH credentials
- Attach IAM roles to EC2 instances for:
- proper S3 access
- for EMRFS requests to S3
- DynamoDB scans through Hive
- EC2 Security Groups for node to node communication
- One for master node
- Another one for cluster node (core node or task node)
- At-rest data encryption for EMRFS on S3: (image)
- Encryption in S3 (SSE-S3, SSE-KMS, CSE-KMS)
- At-rest data encryption for local disks:
- Open-source HDFS Encryption
- EC2 Instance Store encryption: NVMe encryption or LUKS encryption
- EBS volumes:
- EBS encryption (KMS): works with root volume
- LUKS encryption: does not work with root volume
- In-transit encryption:
- Node to node communication using SSL
- For EMRFS traffic between S3 and cluster nodes using TLS encryption
- Data is encrypted before uploading to S3
- Kerberos authentication (provide authentication from Active Directory)
- Apache Ranger: Centralized Authorization (RBAC Role Based Access) setup on external EC2 and then connecting to the EMR cluster
- https://aws.amazon.com/blogs/big-data/best-practices-for-securing-amazon-emr/
Security for Redshift:
- VPC provides network isolation
- Cluster security groups
- Encryption in flight using the JDBC driver enabled with SSL
- Encryption at rest using KMS or an HSM device (establish a trusted connection between HSM and Redshift)
- Supports S3-SSE using default managed key
- Use IAM Roles for Redshift
- To access other AWS Resources (example S3 or KMS)
- Must be referenced in the COPY or UNLOAD command (alternatively paste access key and secret key credentials)
Security for ElasticSearch Service:
- VPC provides network isolation
- ElasticSearch policy to manage security further
- Data security by encrypting data at-rest using KMS
- Encryption in-transit using SSL
- IAM or Cognito based authentication
- Cognito allow end users to log in to Kibana through enterprise identity providers such as Microsoft Active Directory using SAML
Why encryption?
- Encryption in flight => SSL/TLS (image)
- Data is encrypted before sending and Server will be decrypting it after receiving
- TLS certificates help with encryption (HTTPS)
- Encryption in flight ensures no MITM (man in the middle attack) can happen
- Amazon S3 exposes:
- HTTP endpoint: non encrypted
- HTTPS endpoint: encryption in flight
- Free to use the endpoint I want, but HTTPS is recommended
- Most clients would use the HTTPS endpoint by default
- Server-side encryption at rest (image)
- Data is encrypted after being received by the server
- Data is decrypted before being sent
- It is stored in an encrypted form thanks to a key (usually a data key)
- The encryption / decryption keys must be managed somewhere (usually in KMS), and the server must have access to it
- Client-side encryption (image)
- Data is encrypted by the client and never decrypted by the server
- Data will be decrypted by a receiving client
- The server should not be able to decrypt the data
- Could leverage Envelope Encryption
- Envelope encryption is the practice of encrypting plaintext data with a data key, and then encrypting the data key under another key. Use CMKs to generate, encrypt, and decrypt the data keys that you use outside of AWS KMS to encrypt your data. CMKs are created in AWS KMS and never leave AWS KMS unencrypted
S3 Encryption for Objects:
- There are 4 methods of encrypting objects in S3
- SSE-S3 (image)
- Encrypts S3 objects using keys handled & managed by S3
- Object is encrypted server side
- AES-256 encryption type
- Must set header: “x-amz-server-side-encryption": "AES256"
- SSE-KMS
- Leverage AWS Key Management Service to manage encryption keys
- Encryption using keys handled & managed by KMS
- KMS Advantages: user control + audit trail
- Object is encrypted server side
- Must set header: “x-amz-server-side-encryption": ”aws:kms"
- SSE-C
- When you want to manage your own encryption keys
- Server-side encryption using data keys fully managed by the customer outside of AWS
- S3 does not store the encryption key you provide
- HTTPS must be used
- Encryption key must provided in HTTP headers, for every HTTP request made
- Client-Side Encryption
- Client library such as the Amazon S3 Encryption Client
- Clients must encrypt data themselves before sending to S3
- Clients must decrypt data themselves when retrieving from S3
- Customer fully manages the keys and encryption cycle
Encryption in AWS Services:
- Requires migration (through Snapshot / Backup):
- EBS Volumes
- RDS databases
- ElastiCache
- EFS network file system
- In-place encryption:
AWS Security Token Service (STS):
- Allows to grant limited and temporary access to AWS resources
- Token is valid for up to one hour (must be refreshed)
- Cross Account Access
- Allows users from one AWS account access resources in another
- Federation (Active Directory)
- Provides a non AWS user with temporary AWS access by linking users Active Directory credentials
- Uses SAML (Security Assertion markup language)
- Allows Single Sign On (SSO) which enables users to log in to AWS console without assigning IAM credentials
- Federation with third party providers / Cognito
- Used mainly in web and mobile applications
- Makes use of Facebook/Google/Amazon etc to federate them
Cross Account Access: (image)
- Define an IAM Role for another account to access
- Define which accounts can access this IAM Role
- Use AWS STS (Security Token Service) to retrieve credentials and impersonate the IAM Role I have access to AssumeRole API
- Temporary credentials can be valid between 15 minutes to 1 hour
What’s Identity Federation? (image)
- Federation lets users outside of AWS to assume temporary role for accessing AWS resources (user do not need to have an IAM user in AWS to access AWS)
- These users assume identity provided access role
- Federation assumes a form of 3rd party authentication
- LDAP
- Microsoft Active Directory (~= SAML). SAML is the standard and Microsoft Active Directory is the implementation of it
- Single Sign On
- Open ID
- Cognito
- Using federation, you do not need to create IAM users (user management is done outside of AWS)
-
-
AWS Cognito Federated Identity Pools For Public Applications: (image)
- Goal:
- Provide direct access to AWS Resources from the Client Side
- How:
- Log in to federated identity provider or remain anonymous
- Get temporary AWS credentials back from the Federated Identity Pool
- These credentials come with a pre defined IAM policy stating their permissions
- Example:
- provide (temporary) access to write to S3 bucket using Facebook Login
- Note:
- Web Identity Federation is an alternative to using Cognito but AWS recommends against it
AWS Key Management Service (KMS):
- Easy way to control access to my data, AWS manages keys for us
- Fully integrated with IAM for authorization and with CloudTrail if I want to track the API calls on to KMS
- Seamlessly integrated into, for example:
- EBS: encrypt volumes
- S3: Server side encryption of objects
- Redshift: encryption of data
- RDS: encryption of data
- SSM: encrypt secrets in parameter store
- Can also use the CLI / SDK to leverage KMS functionality
- Able to fully manage the keys & policies:
- Create
- Rotation policies
- Disable
- Enable
- Able to audit key usage (using CloudTrail)
- Three types of Customer Master Keys (CMK):
- AWS Managed Service Default CMK: free
- User Keys created in KMS: $1 / month
- User Keys imported (must be 256 bit symmetric key): $1 / month
- Plus pay for Encrypt/ Decrypt API call to KMS ($0.03 / 10000)
- How does KMS work? API – Encrypt and Decrypt (image)
AWS KMS 101:
- Anytime you need to share sensitive information… use KMS
- Database passwords
- Credentials to external service
- Private Key of SSL certificates
- The value in KMS is that the CMK used to encrypt data can never be retrieved by the user, and the CMK can be rotated for extra security
- Never ever store your secrets in plaintext, especially in my code
- Encrypted secrets can be stored in the code / environment variables
- KMS can only help in encrypting up to 4KB of data per call
- If data > 4 KB, use envelope encryption
- To give access to KMS to someone:
- Make sure the Key Policy allows the user
- Make sure the IAM Policy allows the Encrypt/ Decrypt API calls
KMS Automatic Key Rotation:
- For Customer-managed CMK (not AWS managed CMK)
- If enabled: automatic key rotation happens every 1 year
- Previous key is kept active so you can decrypt old data
- New Key has the same CMK ID => only the backing key is changed (image)
KMS Manual Key Rotation:
- When you want to rotate key every 90 days, 180 days, etc…
- New Key has a different CMK ID
- Keep the previous key active so you can decrypt old data
- Better to use aliases in this case (to hide the change of key for the application)
- Good solution to rotate CMK that are not eligible for automatic rotation (like asymmetric CMK)
KMS Alias Updating:
- Better to use aliases in this case => to hide the change of key for the application (image)
-
CloudHSM:
- KMS => AWS manages the software for encryption
- CloudHSM => AWS provisions encryption hardware
- Dedicated Hardware (HSM = Hardware Security Module)
- I manage my own encryption keys entirely (not AWS)
- HSM device is tamper resistant, FIPS 140-2 Level 3 compliance
- CloudHSM clusters are spread across Multi AZ (HA) must setup
- Supports both symmetric and asymmetric encryption (SSL/TLS keys)
- No free tier available
- Must use the CloudHSM Client Software
- Redshift supports CloudHSM for database encryption and key management
- Good option to use with SSE-C encryption
- CloudHSM Diagram (image)
AWS CloudTrail:
- Provides governance, compliance and audit for my AWS Account
- CloudTrail is enabled by default!
- Get an history of events / API calls made within my AWS Account by:
- Console
- SDK
- CLI
- AWS Services
- Can put logs from CloudTrail into CloudWatch Logs
- If a resource is deleted in AWS, look into CloudTrail first
- CloudTrail shows the past 90 days of activity
- Default UI only shows “Create”, “Modify” or “Delete” events
- CloudTrail Trail:
- Get a detailed list of all the events you choose
- Ability to store these events in S3 for further analysis
- Can be Region specific or Global
- CloudTrail Logs have SSE-S3 encryption when placed into S3
- Control access to S3 using IAM, Bucket Policy, etc.
VPC Endpoints:
- Endpoints allow me to connect to AWS Services using a private network instead of the public www network
- They scale horizontally and are redundant
- They remove the need of IGW, NAT, etc. to access AWS Services
- Gateway: provisions a target and must be used in a route table ONLY S3 and DynamoDB
- Interface: provisions an ENI (private IP address) as an entry point (must attach security group) – most AWS services. Also called VPC PrivateLink
- VPC Endpoint PrivateLink to SQS (image)