ACG - AWS Certified Security Specialty Flashcards
S3 policy precedents
- when an AWS principal issues a request to S3, the authorization decision depends on the union of all IAM policies, S3 bucket polices and S3 ACLs that apply
- an S3 bucket policy will take precedence over an IAM policy, unless the IAM policy contains a deny statement.
- deny statements always take precedence over allow statements whether with-in an S3 policy, an IAM policy or an S3 ACL
S3 ACLs
- ACLs have been around since the inception of S3
- AWS recommends using IAM or S3 bucket policies over ACLS
- if you need to specify permissions on a specific object, you will have to use ACLs
- ACLs can only be used to grant access to your AWS account or another AWS account using their canonical ID. You can’t use ACLs to grant access to a specific user
S3 bucket policies
- used to allow or deny actions on an S3 bucket
- applied to the S3 bucket
- limited to 20kb in size
IAM policies
- applied at the IAM user, group or role level
- limited to 2kb for users, 5kb for groups and 10 kb for roles.
AWS principal
- term that designates an AWS user, group or role
S3 policy conflict flow
- access always starts with deny (least privilege)
- all applicable polices are evaluated
- if there is an explicit deny, the action is denied
- if there is no explicit deny and there is an allow, the action is allowed
- if there is neither an allow or deny, the action is denied
S3 Replication
- the source and destination buckets must have versioning enabled and can be located in the same or different regions
- Amazon S3 must have permissions to replicate objects on your behalf
- If the source bucket owner is not the object owner, then the bucket owner needs Read and Read_ACP permissions via the object ACL
- the IAM role must have permissions to replicate objects in the destination bucket
- during replication you can change the ownership of the object replica to the AWS account that owns the destination bucket
- any new objects created after you enable replication on the bucket are replicated
- S3 replicates objects encrypted using S3 managed keys by default and AWS KMS if you enable it
- S3 does not replicate objects encrypted with server side customer provided encryption keys
- S3 replicates the object metadata, ACL updates and tags
- delete markers are replicated, but the version history still remains on the source and destination buckets
- S3 does not replicate deletes to a particular version of an object
- S3 always replicates buckets over SSL
CloudFront - SSL certs
- you can use a default CloudFront SSL cert that has a *.cloudfront.net domain name
- if you want to use your own cert with your own domain name, you can register a cert in AWS ACM, but the cert must be registered in the us-east-1 region
- you can also use a cert stored in IAM, but you must use the IAM CLI
S3 pre-signed URLs
- you can access objects using a pre-signed URLs instead of IAM or S3 bucket policies or S3 ACLs.
- pre-signed URLs are typically generated by the SDK, but can be generated by the CLI
- you can change the default time-out for the token by using the –expires-in option
Security Token Service (STS)
- grants users limited and temporary access to AWS resources by federating with another identity store.
- users can be federated with Active Directory
- users can be federated with Mobile Apps (Facebook, Amazon, Google or other OpenID providers)
- users can be from other AWS accounts (Cross account access)
Security Token Service (STS) Identity Broker
- a service that brokers the authentication and authorization between the identity store (like AD) and the AWS service (like S3)
- an application sends the user’s credentials to the identity broker, who validates with the identity store (like AD)
- the identity broker calls the GetFederationToken function using IAM credentials that have permissions to create new tokens. The call must include an IAM policy, a duration (1 to 36 hours) and a policy that specifies the permissions to be granted to the temporary security credentials
- the STS returns to the identity broker an access key, a secret access key, a token and a duration
- the identity broker returns the temporary credentials to the application
- the application uses the temporary credentials to make the call to S3
- S3 uses IAM to verify that the credentials allow the requested operation
- IAM approves the operation
Amazon Cognito
- provides Web Identity Federation with providers like Amazon, Facebook or Google
- provides sign-up and sign-in to your apps
- grants access for guest users
- acts as an identity broker between your app and Web ID providers
- synchronizes user data for multiple devices
- recommended for all mobile apps using AWS services
Cognito User Pools
- user directories used to manage sign-up and sign-in functionality for mobile and web apps
- users can sign-in directly to a User Pool or indirectly via an identity provider like Facebook, Amazon, Google
- successful authentication generates a number of JSON Web tokens (JWTs)
Cognito Identity Pools
- enable you to create unique identities for your users and assign them access to AWS resources
- the identity pool exchanges the JWT tokens for temporary AWS credentials which grant access other AWS services
Glacier Vault Lock
- allows configuring and enforcing compliance controls for individual Glacier Vaults
- you can enforce WORM archives and data retention
- you must initiate the lock by attaching a vault lock policy
- there is a 24 hour waiting period before you can validate the lock policy and the vault lock takes effect and becomes immutable
Amazon Glacier
- extremely low cost cloud storage for data archiving
- costs as little as $0.004 GB/month
- data is stored in Archives as .tar or .zip
Glacier Vault
- a container in Glacier storage that contains one or more archives
AWS Organizations
- an account management service which allows consolidation of multiple AWS accounts for centralize management
- allows centralized billing
- allows organizing accounts into OUs for access control
- allows attaching Service Control Policies (SCPs) for restricting AWS services
Service Control Polices
- used by AWS Organizations to restrict the AWS services allowed by accounts
- can be attached to accounts directly or to OUs
- SCPs attached to OUs higher up the Organization hierarchy will apply to all OUs and accounts beneath it
- can be used to create a Permissions Boundary, restricting the actions users, groups and roles (including root) can do
- SCPs can deny access only, they cannot allow
IAM Credential Report
- exports list of users with credential information like, account creation time, password enabled, last used\last rotated, access keys enabled, last used\last rotated, certs enabled\last used, MFA enabled
- can be generated in the AWS console or CLI
CloudTrail
- logs API calls to resources in your AWS account
- does not log SSH or RDP sessions
- does log the ID of the caller, the time of the call, the source IP, the request parameters and the response from the service
- delivered with digest file that can be used to validate the integrity of the log file
- CloudTrail log file validation uses SHA-256 hashing and SHA-256 with RSA for digital signing
CloudTrail logs security
- CloudTrail logs contain personally identifiable information like usernames, team membership, DynamoDB table and key names
- it is best practice to secure your CloudTrail logs by using IAM or S3 bucket polices and SSE-S3 or SSE-KMS to encrypt the logs
- you can also enable Object lock on the S3 bucket that contains your CloudTrail logs, but only when the bucket is created
- you can enable S3 MFA Delete (via the CLI only)
CloudTrail log retention
- logs are kept indefinitely in their S3 bucket
- you can setup S3 Object Lifecycle Management to automatically remove the files after a certain period
- you can move the files to AWS Glacier for cost effective long term storage
CloudWatch
- real time monitoring (detailed monitoring = every 1 min, standard monitoring = every 5 mins)
- gathers metrics including items like CPU and network utilization
- you can configure alarms based on metrics
- Alarms can trigger notifications like SNS
- can create custom metrics
- can can also monitor on-premises servers
CloudWatch logs
- logs from other AWS services, like CloudTrail, can be pushed to CloudWatch
- you can also setup your applications and systems to send their logs to CloudWatch via the CloudWatch Agent
- you can setup log groups to filter the metrics from your application logs
- the logs sent to CloudWatch will be logged indefinitely (not in an S3 bucket that we have access to)
CloudWatch events
- near real-time stream of system events
- events are AWS resources state changes
- can create custom & scheduled events
- allows you to create actions based off rules that trigger when certain metrics are detected in the CloudWatch logs
- for example a CloudWatch event could trigger a Lambda function to delete any EC2 instances provisioned by a certain user. CloudWatch would be aware of this event if CloudTrail logs were ingested into CloudWatch
CloudWatch security
- can restrict access to CloudWatch via IAM policies
- note that data is decoupled from its source, so you can’t restrict access to originating sources with-in CloudWatch, you can only restrict access to CloudWatch itself
AWS Config
- enables compliance auditing, security analysis and resource tracking
- provides configuration snapshots, logs changes of AWS resources and automates compliance checking
- provides AWS resource inventory
- you can aggregate AWS resource inventory or Config rule compliance status from other AWS accounts and regions
AWS Config permissions
- AWS config requires an IAM role with read only access to record resources
- AWS config needs write access to an S3 bucket to record its results
- AWS config needs access to publish to an SNS topic if you want it to send notifications
- you should restrict user access to AWS Config using IAM roles
AWS CloudHSM
- dedicated hardware security module
- not shared by other tenants
- enables control of data, evidence of control, meets tough compliance controls
- provides secure key storage, cryptographic operations, and tamper resistant HSM
- CloudHSM has FIPS 140-2 & EAL-4 compliance
- AWS only administers the HSM appliance, they have no access to your keys (although they could probably destroy your keys by destroying the HSM partition)
- the HSM can detect physical attempts at tampering and auto destroy the keys
- if the HSM detects five unsuccessful attempts as Crypto Officer (CO), the HSM erases itself
- if the HSM detects five unsuccessful attempts as Crypto User (CU), the user will be locked and must be unlocked by a CO
AWS CloudHSM roles
- Crypto Officer - can create Crypto Users, but can’t access keys
- Crypto User - can create, import, export and delete keys, but can’t create users
AWS Inspector
- automated security assessment service that assesses applications for vulnerabilities or deviations from best practices
- provides a detailed list of security findings prioritized by level of severity
- requires an agent installed on your EC2 instances
- available rules packages are CVE, Network Reachability, CIS OS Security Configuration Benchmarks, Security Best Practices
AWS Trusted Advisor
- online resource to help you reduce cost, increase performance and improve security though optimization
- the Trusted Advisor will make suggestions on Cost Optimization, Performance, Security, Fault Tolerance and Service Limits
- consists of two sets of checks Core Changes and Recommendations and Full Trusted Advisor
- Core is available on all support levels
- Full is available only on Business and Enterprise level support agreements
Logging in AWS
- AWS Cloud Trail - logs changes to system components, should have file validation and encryption turned on
- AWS Config - logs changes to system components
- VPC Flow logs - logs all network traffic
- AWS CloudWatch logs - provides performance monitoring and metrics
AWS KMS
- managed service that makes it easy to create and control encryption keys
- uses multi-tenant HSMs to protect the keys
- keys are regional, they can only be used in the region the were created, they can not be copied to another region
- KMS keys are used by various AWS services, like S3 for object encryption or EBS to encrypt an EC2 volume
- KMS keys are not used to SSH into EC2 instances
AWS KMS CMK
- customer master key
- consists of an alias, creation date, description, key state (enabled, disabled, scheduled for deletion), key material
- key material can be either customer provided or AWS provided
- CMKs can never be exported
- Key Administrators are IAM users/roles that can administer the key, but not use it
- Key Users are IAM users/roles that can use the key to encrypt\decrypt data
AWS KMS reasons to import your own key material
- prove that randomness meets your requirements
- extend your existing processes to AWS
- to delete key material without the 7 - 30 days wait, then be able to import them again.
- to provide resilience against AWS failure by storing keys outside AWS
AWS KMS customer provide key material process
- create a CMK with no key material
- download the wrapping key and import token
- encrypt the key material using something like Open SSL
- import the key material into the CMK
AWS KMS key rotation - AWS managed keys
- AWS managed keys are rotated every 3 years and you have no control over this
- when a CMK is due for rotation, a new backing key is created and marked as the active key for all new requests
- the old backing key remains available to decrypt any existing files
- AWS managed keys cannot be deleted
AWS KMS key rotation - customer managed keys with AWS provided key material
- automatically rotated once a year if enabled
- AWS KMS generates new key material for the CMK every year and the old backing key is saved for decrypting old data
- can delete the keys, requires a minimum wait period of 7 days
- be very careful, once deleted no files encrypted with that key can be decrypted
AWS KMS key rotation - customer managed keys with customer provided key material
- you can rotate on demand manually.
- you will need to create a new CMK, then change your applications to use the new CMK
- you can delete customer managed keys without waiting 7 - 30 days, but be very careful, once deleted no files encrypted with that key can be decrypted
AWS KMS - EBS volume encryption
- you can use a KMS key to encrypt an EBS volume when you create it or when creating an EC2 instance
- to encrypt an existing EBS volume, you need to first snapshot the volume, then copy the snapshot and choose to encrypt it, then deploy a new EC2 instance from the copied\encrypted snapshot
EC2 key pairs
- you can add a key pair to an EC2 instance when you build it for ssh access
- you can also add additional key pairs under /home/ec2-user/.ssh/authorized_keys
- if you delete the key from EC2 -> Key Pairs, in the AWS console, this will not remove the key from the metadata of the EC2 instance or from the authorized_keys file with-in the EC2 instance
- if you clone an EC2 instance to am AMI, all the old keys in the authorized_keys file will be left and any new keys you attach when powering on the new copy of the instance, will be appended