AWS Security Services Cheat Sheet

AWS Identity and Security Services

AWS Security Services Cheat Sheet

AWS Identity and Security Services

Key Management Service – KMS

  • is a managed encryption service that allows the creation and control of encryption keys to enable data encryption.
  • provides a highly available key storage, management, and auditing solution to encrypt the data across AWS services & within applications.
  • uses hardware security modules (HSMs) to protect and validate the KMS keys by the FIPS 140-2 Cryptographic Module Validation Program.
  • seamlessly integrates with several AWS services to make encrypting data in those services easy.
  • supports multi-region keys, which are AWS KMS keys in different AWS Regions. Multi-Region keys are not global and each multi-region key needs to be replicated and managed independently.

CloudHSM

  • provides secure cryptographic key storage to customers by making hardware security modules (HSMs) available in the AWS cloud
  • helps manage your own encryption keys using FIPS 140-2 Level 3 validated HSMs.
  • single tenant, dedicated physical device to securely generate, store, and manage cryptographic keys used for data encryption
  • are inside the VPC (not EC2-classic) & isolated from the rest of the network
  • can use VPC peering to connect to CloudHSM from multiple VPCs
  • integrated with Amazon Redshift and Amazon RDS for Oracle
  • EBS volume encryption, S3 object encryption and key management can be done with CloudHSM but requires custom application scripting
  • is NOT fault-tolerant and would need to build a cluster as if one fails all the keys are lost
  • enables quick scaling by adding and removing HSM capacity on-demand, with no up-front costs.
  • automatically load balance requests and securely duplicates keys stored in any HSM to all of the other HSMs in the cluster.
  • expensive, prefer AWS Key Management Service (KMS) if cost is a criteria.

AWS WAF

  • is a web application firewall that helps monitor the HTTP/HTTPS traffic and allows controlling access to the content.
  • helps protect web applications from attacks by allowing rules configuration that allow, block, or monitor (count) web requests based on defined conditions. These conditions include IP addresses, HTTP headers, HTTP body, URI strings, SQL injection and cross-site scripting.
  • helps define Web ACLs, which is a combination of Rules that is a combinations of Conditions and Action to block or allow
  • integrated with CloudFront, Application Load Balancer (ALB), API Gateway services commonly used to deliver content and applications
  • supports custom origins outside of AWS, when integrated with CloudFront

AWS Secrets Manager

  • helps protect secrets needed to access applications, services, and IT resources.
  • enables you to easily rotate, manage, and retrieve database credentials, API keys, and other secrets throughout their lifecycle.
  • secure secrets by encrypting them with encryption keys managed using AWS KMS.
  • offers native secret rotation with built-in integration for RDS, Redshift, and DocumentDB.
  • supports Lambda functions to extend secret rotation to other types of secrets, including API keys and OAuth tokens.
  • supports IAM and resource-based policies for fine-grained access control to secrets and centralized secret rotation audit for resources in the AWS Cloud, third-party services, and on-premises.
  • enables secret replication in multiple AWS regions to support multi-region applications and disaster recovery scenarios.
  • supports private access using VPC Interface endpoints

AWS Shield

  • is a managed service that provides protection against Distributed Denial of Service (DDoS) attacks for applications running on AWS
  • provides protection for all AWS customers against common and most frequently occurring infrastructure (layer 3 and 4) attacks like SYN/UDP floods, reflection attacks, and others to support high availability of applications on AWS.
  • provides AWS Shield Advanced with additional protections against more sophisticated and larger attacks for applications running on EC2, ELB, CloudFront, AWS Global Accelerator, and Route 53.

AWS GuardDuty

  • offers threat detection that enables continuous monitoring and protects the AWS accounts and workloads.
  • is a Regional service
  • analyzes continuous streams of meta-data generated from AWS accounts and network activity found in AWS CloudTrail Events, EKS audit logs, VPC Flow Logs, and DNS Logs.
  • integrated threat intelligence
  • combines machine learning, anomaly detection, network monitoring, and malicious file discovery, utilizing both AWS-developed and industry-leading third-party sources to help protect workloads and data on AWS
  • supports suppression rules, trusted IP lists, and thread lists.
  • provides Malware Protection to detect malicious files on EBS volumes
  • operates completely independently from the resources so there is no risk of performance or availability impacts on the workloads.

Amazon Inspector

  • is a vulnerability management service that continuously scans the AWS workloads for vulnerabilities
  • automatically discovers and scans EC2 instances and container images residing in Elastic Container Registry (ECR) for software vulnerabilities and unintended network exposure.
  • creates a finding, when a software vulnerability or network issue is discovered, that describes the vulnerability, rates its severity, identifies the affected resource,  and provides remediation guidance.
  • is a Regional service.
  • requires Systems Manager (SSM) agent to be installed and enabled.

Amazon Detective

  • helps analyze, investigate, and quickly identify the root cause of potential security issues or suspicious activities.
  • automatically collects log data from the AWS resources and uses machine learning, statistical analysis, and graph theory to build a linked set of data to easily conduct faster and more efficient security investigations.
  • enables customers to view summaries and analytical data associated with CloudTrail logs, EKS audit logs, VPC Flow Logs.
  • provides detailed summaries, analysis, and visualizations of the behaviors and interactions amongst your AWS accounts, EC2 instances, AWS users, roles, and IP addresses.
  • maintains up to a year of aggregated data
  • is a Regional service and needs to be enabled on a region-by-region basis.
  • is a multi-account service that aggregates data from monitored member accounts under a single administrative account within the same region.
  • has no impact on the performance or availability of the AWS infrastructure since it retrieves the log data and findings directly from the AWS services.

AWS Security Hub

  • a cloud security posture management service that performs security best practice checks, aggregates alerts, and enables automated remediation.
  • collects security data from across AWS accounts, services, and supported third-party partner products and helps you analyze your security trends and identify the highest priority security issues.
  • is Regional abut supports cross-region aggregation of findings.
  • automatically runs continuous, account-level configuration and security checks based on AWS best practices and industry standards which include CIS Foundations, PCI DSS.
  • consolidates the security findings across accounts and provider products and displays results on the Security Hub console.
  • supports integration with Amazon EventBridge. Custom actions can be defined when a finding is received.
  • has multi-account management through AWS Organizations integration, which allows delegating an administrator account for the organization.
  • works with AWS Config to perform most of its security checks for controls

AWS Macie

  • Macie is a data security service that discovers sensitive data by using machine learning and pattern matching, provides visibility into data security risks, and enables automated protection against those risks.
  • provides an inventory of the S3 buckets and automatically evaluates and monitors the buckets for security and access control.
  • automates the discovery, classification, and reporting of sensitive data.
  • generates a finding for you to review and remediate as necessary if it detects a potential issue with the security or privacy of the data, such as a bucket that becomes publicly accessible.
  • provides multi-account support using AWS Organizations to enable Macie across all of the accounts.
  • is a regional service and must be enabled on a region-by-region basis and helps view findings across all the accounts within each Region.
  • supports VPC Interface Endpoints to access Macie privately from a VPC without an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.

AWS Artifact

  • is a self-service audit artifact retrieval portal that provides customers with on-demand access to AWS’ compliance documentation and agreements
  • can use AWS Artifact Reports to download AWS security and compliance documents, such as AWS ISO certifications, Payment Card Industry (PCI), and System and Organization Control (SOC) reports.

References

AWS_Security_Products

AWS Key Management Service – KMS

AWS KMS - Owned vs Managed vs Customer Managed Keys

AWS Key Management Service – KMS

  • AWS Key Management Service – KMS is a managed encryption service that allows the creation and control of encryption keys to enable data encryption.
  • provides a highly available key storage, management, and auditing solution to encrypt the data across AWS services & within applications.
  • uses hardware security modules (HSMs) to protect and validate the keys by the FIPS 140-2 Cryptographic Module Validation Program.
  • seamlessly integrates with several AWS services to make encrypting data in those services easy.
  • is integrated with AWS CloudTrail to provide encryption key usage logs to help meet auditing, regulatory, and compliance needs.
  • is regional and keys are only stored and used in the region in which they are created. They cannot be transferred to another region.
  • enforces usage and management policies, to control which IAM user, role from the account, or other accounts can manage and use keys.
  • can create and manage keys by
    • Create, edit, and view symmetric and asymmetric keys, including HMAC keys.
    • Control access to the keys by using key policies, IAM policies, and grants. Policies can be further refined using condition keys.
    • Supports attribute-based access control (ABAC).
    • Create, delete, list, and update aliases for the keys.
    • Tag the keys for identification, automation, and cost tracking.
    • Enable and disable keys.
    • Enable and disable automatic rotation of the cryptographic material in keys.
    • Delete keys to complete the key lifecycle.
  • supports the following cryptographic operations
    • Encrypt, decrypt, and re-encrypt data with symmetric or asymmetric keys.
    • Sign and verify messages with asymmetric keys.
    • Generate exportable symmetric data keys and asymmetric data key pairs.
    • Generate and verify HMAC codes. 
    • Generate random numbers suitable for cryptographic applications
  • supports multi-region keys, which act like copies of the same KMS key in different AWS Regions that can be used interchangeably – as though you had the same key in multiple Regions.
  • supports VPC private endpoint to connect KMS privately from a VPC.
  • supports keys in a CloudHSM key store backed by the CloudHSM cluster.

Envelope encryption

  • AWS cloud services integrated with AWS KMS use a method called envelope encryption to protect the data.
  • Envelope encryption is an optimized method for encrypting data that uses two different keys (Master key and Data key)
  • With Envelop encryption
    • A data key is generated and used by the AWS service to encrypt each piece of data or resource.
    • Data key is encrypted under a defined master key.
    • Encrypted data key is then stored by the AWS service.
    • For data decryption by the AWS service, the encrypted data key is passed to KMS and decrypted under the master key that was originally encrypted so the service can then decrypt the data.
  • When the data is encrypted directly with KMS it must be transferred over the network.
  • Envelope encryption can offer significant performance benefits as KMS only supports sending data less than 4 KB to be encrypted.
  • Envelope encryption reduces the network load for the application or AWS cloud service as only the request and fulfillment of the data key must go over the network.

KMS Service Concepts

KMS Usage

KMS Keys OR Customer Master Keys (CMKs)

  • AWS KMS key is a logical representation of a cryptographic key.
  • KMS Keys can be used to create symmetric or asymmetric keys for encryption or signing OR HMAC keys to generate and verify HMAC tags.
  • Symmetric keys and the private keys of asymmetric keys never leave AWS KMS unencrypted.
  • A KMS key contains metadata, such as the key ID, key spec, key usage, creation date, description, key state, and a reference to the key material that is used to run cryptographic operations with the KMS key.
  • Symmetric keys are 256-bit AES keys that are not exportable.
  • KMS keys can be used to generate, encrypt, and decrypt the data keys, used outside of AWS KMS to encrypt the data [Envelope Encryption]
  • Key material for symmetric keys and the private keys of asymmetric key never leaves AWS KMS unencrypted.

Customer Keys and AWS Keys

AWS KMS - Owned vs Managed vs Customer Managed Keys

AWS Managed Keys

  • AWS Managed keys are created, managed, and used on your behalf by AWS services in your AWS account.
  • keys are automatically rotated every year (~365 days) and the rotation schedule cannot be changed.
  • have permission to view the AWS managed keys in your account, view their key policies, and audit their use in CloudTrail logs.
  • cannot manage or rotate these keys, change their key policies, or use them in cryptographic operations directly; the service that creates them uses them on your behalf.

Customer managed keys

  • Customer managed keys are created by you to encrypt your service resources in your account.
  • Automatic rotation is Optional and if enabled, keys are automatically rotated every year.
  • provides full control over these keys, including establishing and maintaining their key policies, IAM policies, and grants, enabling and disabling them, rotating their cryptographic material, adding tags, creating aliases refering the KMS keys, and scheduling the KMS keys for deletion.

AWS Owned Keys

  • AWS owned keys are a collection of KMS keys that an AWS service owns and manages for use in multiple AWS accounts.
  • AWS owned keys are not in your AWS account, however, an AWS service can use the associated AWS owned keys to protect the resources in your account.
  • cannot view, use, track, or audit them

Key Material

  • KMS keys contain a reference to the key material used to encrypt and decrypt data.
  • By default, AWS KMS generates the key material for a newly created key.
  • KMS key can be created without key material and then your own key material can be imported or created in the AWS CloudHSM cluster associated with an AWS KMS custom key store.
  • Key material cannot be extracted, exported, viewed, or managed.
  • Key material cannot be deleted; you must delete the KMS key.

Key Material Origin

  • Key material origin is a KMS key property that identifies the source of the key material in the KMS key.
  • Symmetric encryption KMS keys can have one of the following key material origin values.
    • AWS_KMS
      • AWS KMS creates and manages the key material for the KMS key in AWS KMS.
    • EXTERNAL
      • Key has imported key material. 
      • Management and security of the key are the customer’s responsibility.
      • Only symmetric keys are supported.
      • Automatic rotation is not supported and needs to be manually rotated.
    • AWS_CLOUDHSM
      • AWS KMS created the key material for the KMS key in the AWS CloudHSM cluster associated with the custom key store.
    • EXTERNAL_KEY_STORE
      • Key material is a cryptographic key in an external key manager outside of AWS.
      • This origin is supported only for KMS keys in an external key store.

Data Keys

  • Data keys are encryption keys that you can use to encrypt data, including large amounts of data and other data encryption keys.
  • KMS does not store, manage, or track your data keys.
  • Data keys must be used by services outside of KMS.

Encryption Context

  • Encryption context provides an optional set of key–value pairs that can contain additional contextual information about the data.
  • AWS KMS uses the encryption context as additional authenticated data (AAD) to support authenticated encryption.
  • Encryption context is not secret and not encrypted and appears in plaintext in CloudTrail Logs so you can use it to identify and categorize your cryptographic operations.
  • Encryption context should not include sensitive information.
  • Encryption context usage
    • When an encryption context is included in an encryption request, it is cryptographically bound to the ciphertext such that the same encryption context is required to decrypt the data.
    • If the encryption context provided in the decryption request is not an exact, case-sensitive match, the decrypt request fails.
  • Only the order of the key-value pairs in the encryption context can vary.

Key Policies

  • help determine who can use and manage those keys.
  • can add, remove, or change permissions at any time for a customer-managed key.
  • cannot edit the key policy for AWS owned or managed keys.

Grants

  • provides permissions, an alternative to the key policy and IAM policy, that allows AWS principals to use the KMS keys.
  • are often used for temporary permissions because you can create one, use its permissions, and delete it without changing the key policies or IAM policies.
  • permissions specified in the grant might not take effect immediately due to eventual consistency.

Grant Tokens

  • help mitigate the potential delay with grants.
  • use the grant token received in the response to CreateGrant API request to make the permissions in the grant take effect immediately.

Alias

  • Alias helps provide a friendly name for a KMS key.
  • can be used to refer to different KMS keys in each AWS Region.
  • can be used to point to different keys without changing the code.
  • can allow and deny access to KMS keys based on their aliases without editing policies or managing grants.
  • aliases are independent resources, not properties of a KMS key, and can be added, changed, and deleted without affecting the associated KMS key.

Encryption & Decryption Process

  • Use KMS to get encrypted and plaintext data keys using CMK.
  • Use the plaintext data key to encrypt the data and store the encrypted data key with the data.
  • Use KMS decrypt to get the plaintext data key and decrypt the data.
  • Remove the plaintext data key from memory, once the operation is completed.

KMS Working

  • KMS centrally manages and securely stores the keys.
  • Keys can be generated or imported from the key management infrastructure (KMI).
  • Keys can be used from within the applications and supported AWS services to protect the data, but the key never leaves KMS.
  • Data is submitted to KMS to be encrypted, or decrypted, under keys that you control.
  • Usage policies on these keys can be set that determines which users can use them to encrypt and decrypt data.

KMS Access Control

  • Primary way to manage access to AWS KMS keys is with policies.
  • KMS keys access can be controlled using
    • Key Policies
      • are resource-based policies
      • every KMS key has a key policy
      • is a primary mechanism for controlling access to a key.
      • can be used alone to control access to the keys.
    • IAM policies
      • use IAM policies in combination with the key policy to control access to keys.
      • helps manage all of the permissions for your IAM identities in IAM.
    • Grants
      • Use grants in combination with the key policy and IAM policies to allow access to keys.
      • helps allow access to the keys in the key policy, and to allow users to delegate their access to others.
  • To allow access to a KMS CMK, a key policy MUST be used, either alone or in combination with IAM policies or grants.
  • IAM policies by themselves are not sufficient to allow access to keys, though they can be used in combination with a key policy.
  • IAM user who creates a KMS key is not considered to be the key owner and they don’t automatically have permission to use or manage the KMS key that they created.

Rotating KMS or Customer Master Keys

  • Key rotation changes only the key material, which is the cryptographic secret that is used in encryption operations. 
  • KMS keys can be enabled for automatic key rotation, where KMS generates new cryptographic material for the key every year.
  • KMS saves all previous versions of the cryptographic material in perpetuity so it can decrypt any data encrypted with that key.
  • KMS does not delete any rotated key material until you delete the KMS key.
  • All new encryption requests against a key are encrypted under the newest version of the key.
  • Rotation can be tracked in CloudWatch and CloudTrail.

Automatic Key Rotation

  • Automatic key rotation has the following benefits
    • properties of the KMS key like ID, ARN, region, policies, and permissions do not change.
    • applications or aliases refering the key do not need to change
    • Rotating key material does not affect the use of the KMS key in any AWS service.
  • Automatic key rotation is supported only on symmetric encryption KMS keys with key material that KMS generates i.e. Origin = AWS_KMS.
  • Automatic key rotation is not supported for
    • asymmetric keys, 
    • HMAC keys,
    • keys in custom key stores, and
    • keys with imported key material.
  • AWS managed keys
    • automatically rotated every 1 year (updated from 3 years before)
    • rotation cannot be enabled or disabled
  • Customer Managed keys
    • automatic key rotation is supported but is optional.
    • automatic key rotation is disabled, by default, and needs to be enabled.
    • keys can be rotated every year.
  • CMKs with imported key material or keys generated in a CloudHSM cluster using the KMS custom key store feature
    • do not support automatic key rotation.
    • provide flexibility to manually rotate keys as required.

Manual Key Rotation

  • Manual key rotation can be performed by creating a KMS key and updating the applications or aliases to point to the new key.
  • does not retain the ID, ARN, and policies of the key.
  • can help control the rotation frequency esp. if the frequency required is less than a year.
  • is also a good solution for KMS keys that are not eligible for automatic key rotation, such as asymmetric keys, HMAC keys, keys in custom key stores, and keys with imported key material.
  • For manually rotated keys, data has to be re-encrypted depending on the application’s configuration.

KMS Deletion

  • KMS key deletion deletes the key material and all metadata associated with the key and is irreversible.
  • Data encrypted by the deleted key cannot be recovered, once the key is deleted.
  • AWS recommends disabling the key before deleting it.
  • AWS Managed and Owned keys cannot be deleted. Only Customer managed keys can be scheduled for deletion.
  • KMS never deletes the keys unless you explicitly schedule them for deletion and the mandatory waiting period expires.
  • KMS requires setting a waiting period of 7-30 days for key deletion. During the waiting period, the KMS key status and key state is Pending deletion.
    • Key pending deletion cannot be used in any cryptographic operations.
    • Key material of keys that are pending deletion is not rotated.

KMS Multi-Region Keys

  • AWS KMS supports multi-region keys, which are AWS KMS keys in different AWS Regions that can be used interchangeably – as though you had the same key in multiple Regions.
  • Multi-Region keys have the same key material and key ID, so data can be encrypted in one AWS Region and decrypted in a different AWS Region without re-encrypting or making a cross-Region call to AWS KMS.
  • Multi-Region keys never leave AWS KMS unencrypted.
  • Multi-Region keys are not global and each multi-region key needs to be replicated and managed independently.

KMS Features

  • Create keys with a unique alias and description
  • Import your own keys
  • Control which IAM users and roles can manage keys
  • Control which IAM users and roles can use keys to encrypt & decrypt data
  • Choose to have AWS KMS automatically rotate keys on an annual basis
  • Temporarily disable keys so they cannot be used by anyone
  • Re-enable disabled keys
  • Delete keys that you no longer use
  • Audit use of keys by inspecting logs in AWS CloudTrail

KMS with VPC Interface Endpoint

  • AWS KMS can be connected through a private interface endpoint in the Virtual Private Cloud (VPC).
  • Interface VPC endpoint ensures the communication between the VPC and AWS KMS is conducted entirely within the AWS network.
  • Interface VPC endpoint connects the VPC directly to KMS without an internet gateway, NAT device, VPN, or Direct Connect connection.
  • Instances in the VPC do not need public IP addresses to communicate with AWS KMS.

KMS vs CloudHSM

AWS KMS vs CloudHSM

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You are designing a personal document-archiving solution for your global enterprise with thousands of employee. Each employee has potentially gigabytes of data to be backed up in this archiving solution. The solution will be exposed to he employees as an application, where they can just drag and drop their files to the archiving system. Employees can retrieve their archives through a web interface. The corporate network has high bandwidth AWS DirectConnect connectivity to AWS. You have regulatory requirements that all data needs to be encrypted before being uploaded to the cloud. How do you implement this in a highly available and cost efficient way?
    1. Manage encryption keys on-premise in an encrypted relational database. Set up an on-premises server with sufficient storage to temporarily store files and then upload them to Amazon S3, providing a client-side master key. (Storing temporary increases cost and not a high availability option)
    2. Manage encryption keys in a Hardware Security Module (HSM) appliance on-premise server with sufficient storage to temporarily store, encrypt, and upload files directly into amazon Glacier. (Not cost effective)
    3. Manage encryption keys in amazon Key Management Service (KMS), upload to amazon simple storage service (s3) with client-side encryption using a KMS customer master key ID and configure Amazon S3 lifecycle policies to store each object using the amazon glacier storage tier. (With CSE-KMS the encryption happens at client side before the object is upload to S3 and KMS is cost effective as well)
    4. Manage encryption keys in an AWS CloudHSM appliance. Encrypt files prior to uploading on the employee desktop and then upload directly into amazon glacier (Not cost effective)
  2. An AWS customer is deploying an application that is composed of an Auto Scaling group of EC2 Instances. The customers security policy requires that every outbound connection from these instances to any other service within the customers Virtual Private Cloud must be authenticated using a unique x 509 certificate that contains the specific instance-id. In addition an x 509 certificates must be designed by the customer’s Key management service in order to be trusted for authentication.
    Which of the following configurations will support these requirements?
    1. Configure an IAM Role that grants access to an Amazon S3 object containing a signed certificate and configure the Auto Scaling group to launch instances with this role. Have the instances bootstrap get the certificate from Amazon S3 upon first boot.
    2. Embed a certificate into the Amazon Machine Image that is used by the Auto Scaling group Have the launched instances generate a certificate signature request with the instance’s assigned instance-id to the Key management service for signature.
    3. Configure the Auto Scaling group to send an SNS notification of the launch of a new instance to the trusted key management service. Have the Key management service generate a signed certificate and send it directly to the newly launched instance.
    4. Configure the launched instances to generate a new certificate upon first boot. Have the Key management service poll the AutoScaling group for associated instances and send new instances a certificate signature that contains the specific instance-id.
  3. A company has a customer master key (CMK) with imported key materials. Company policy requires that all encryption keys must be rotated every year. What can be done to implement the above policy?
    1. Enable automatic key rotation annually for the CMK.
    2. Use AWS Command Line interface to create an AWS Lambda function to rotate the existing CMK annually.
    3. Import new key material to the existing CMK and manually rotate the CMK.
    4. Create a new CMK, import new key material to it, and point the key alias to the new CMK.
  4. An organization policy states that all encryption keys must be automatically rotated every 12 months. Which AWS Key Management Service (KMS) key type should be used to meet this requirement? (Select TWO)
    1. AWS managed Customer Master Key (CMK) (Now supports every year. It was every 3 years before.)
    2. Customer managed CMK with AWS generated key material
    3. Customer managed CMK with imported key material
    4. AWS managed data key

References

AWS_Key_Management_Service