This is the next part of my AWS security notes to help you to cover the main highlight of AWS security specialty preparations. Please take into account that this is not only the learning material that you should use.
HSM users are a big topic to understand when you initialize the cluster. HSM full HA mode is done via spinning up multiple clusters, it’s not done by default.
- Precrypto Officer (PRECO) – Temporary user available after init of HSM
- Crypto Officer (CO) – User management role.
- Crypto User (CU) – Key and cryptographic operations.
- Appliance User (AU) -This user can perform cloning and synchronization operations
User permissions table for Hardware security module.
You need to know basic management utils for HSM:
cloudhsm_mgmt_util – utility for managing he users.
key_mgmt_util – It includes multiple commands that generate, delete, import, and export keys, get and set attributes, find keys, and perform cryptographic operations
KMS grants and policies
- Grants are an alternative access control mechanism, using key policies.
- Delegate temporary access to keys and key operations to other AWS principals.
- Grants allow access, not deny.
Grantee vs Grant user :
There are two entitities in the game of granting access to the KMS keys.
Grantee – the user who gets the access
Grant user – user who generated the access for Grantee (generated the grant)
Output of the opration: GrantId and GRantToken
Flow with KMS Grants
aws kms create-key (Here is how you create the key)
Test encrypting plain text using my new key:
aws kms encrypt --plaintext "mykeymaterial" --key-id
Create a grant for user Marek :
aws iam get-user –user-name Marek
aws kms create-grant –key-id –grantee-principal –operations “Encrypt”
Encrypt plain text as user Marek:
aws kms encrypt --plaintext "mytext" --key-id --grant-tokens --profile Marek
Revoke the grant:
aws kms revoke-grant --key-id --grant-id
Link for learning how to crate a grant:
The Delegation is done programaticly via CLI.
CLI reference: How to Create KMS GRant
Most important to know :
- create-grant, list-grants, revoke-grant.
- Grant token is generated and is can be passed as arguments to Key management system API.
- Provides temporary (CMK) aand granular perrmissions (encrypt, decrypt, re-encrypt, describe-key)
KMS policy conditions :
Conditions in policies for KMS are very important part of the exam and I recommend to every to test in their home labs multi-account key access policies. Contain conditions Keys. The allowed access must be in Key policy or IAM policy. The condition must be true to policy take effect.
Key condition: ViaService – limits the key us of CMK from specific service. Can be integrated with – allow or deny to CMK.
Cross account access to the KMS CMK:
It’s about giving access to another Account to your CMK. Combination of Key Policy – key user and key administrator + IAM – grant permission to users, groups or roles.
You need to enable cross-account access:
1) Enable the key policy in the account of the CMK. Add the root users. (not individual user)
2) Enable access to KMS in IAM policy of external account.
Cross region replicion of with specific keys:
- The snapshot of the encrypted volume is also encrypted.
- When we copy the EBS snapshot to another region we need to choose the key in that specific region.
- RDS snapshots in same regions can be encrypted with the same key or a new key.
- RDS snapshots in different regions must use different keys.
- The default encryption is not allowed when you migrate an RDS snapshot from one to another region.
- When using data keys >Decrypt and then you can migrate.
Good to read:
KMS delete period – when the key is in delete period (7-30 days) it cant be used for cryptographic operations.
IF you delete your CMK – EBs is still ok until it’s attached. The plaintext data key is stored in Hypervisor memory.
Unmanagable CMK – it better to assign the key to root. If the IAM used is deleted, the key is unmanageable.
The secret manager is services which help you easily rotate, manage, and retrieve database credentials, API keys, and other secrets through their lifecycle.
- rotation, encryption and Access control to your credentials.
- using KMS by default.
- Integration with RDS, Aurora, MySQL, etc.
- Additional charges apply.
- Storing the database credentials mainly, its not parameter store.
- Immediate rotation of the secrets.
- Other secrets are supported also – for example, API keys, SSH keys, passwords
- The secret deletion period is 7 – 30 days.
- The application must be configured to use the secrets manager to retrieve the secrets from it. (referencing the ARN of the secret.)
VPC security: Infrastructure security
The interesting part comes with Infrastructure security. Which you need to understand in every aspect. You need to understand different models of DNS architecture, Hosted zones, Security groups, logging, VPN and much more. The topic is covering pretty much a lot of services from AWS candy box.
Basic filtering mechanisms:
- ACL (Access control list) – stateless
- Security group – stateful
- 1subnet = 1AZ ( Aval ability zone radnomly assigned)
VPC security notes from the lab (Refresh):
- When you create new VPC you get default security groups, NACL and route table. No subnets.
- 1 Internet gateway 1 vpc.
- Route our in custom rout table – 0.0.0.0/0 – destination, IGW – target
- Auto assign public IP is by default disabled.
New feature VPC sharing:
VPC sharing allows customers to share subnets with other AWS accounts within the same AWS Organization. This is a very powerful concept that allows for a number of benefits:
Separation of duties: centrally controlled VPC structure, routing, IP address allocation.
Application owners continue to own resources, accounts, and security groups.
VPC sharing participants can reference security group IDs of each other.
Efficiencies: higher density in subnets, efficient use of VPNs and AWS Direct Connect.
Hard limits can be avoided, for example, 50 VIFs per AWS Direct Connect connection through simplified network architecture.
Costs can be optimized through reuse of NAT gateways, VPC interface endpoints, and intra-Availability Zone traffic.
A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. Instances in either VPC can communicate with each other as if they are within the same network. You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account. The VPCs can be in different regions (also known as an inter-region VPC peering connection). VPC peering is not possible in overlapping IP addresses. VPC peering is not transitive.
To establish a VPC peering connection, you do the following:
- The owner of the requester VPC sends a request to the owner of the accepter VPC to create the VPC peering connection.
- The accepter VPC can be owned by you, or another AWS account, and cannot have a CIDR block that overlaps with the requester VPC’s CIDR block.
- The owner of the accepter VPC accepts the VPC peering connection request to activate the VPC peering connection.
If required, update the security group rules. You must update your route tables!
NAT gateway / instance
- Nat instances can get from community AMI. Can be bottle net dua to instance dependency and network limits.
- Nat instances must have disabled the source/destination check – basically that the instance is source or destination of the traffic.
- Nat instance must be in a public subnet.
- There must be a route out via NAT instance.
- Recommended using autoscaling with HA.
NAT GW :
- Scale up to 10 GB.
- You need to update your rote tables.
- Enterprise preffered solution (out of box AWS service)
- Automaticaly assigned public IP address.
- No need to disable S/D checks.
Egress only GW – is gw for IPv6 only.
Nat GW – is gw for IPv4 only.
NACLS and Security groups extra notes:
- 1 subnet can be assigned to ACL, 1 subnet cannot be associated to multiple ACLs. 1 ACL can have multiple subnets assigned.
- Private ACLs contain by defulat DENY.
- Default ACLs contain default Allow.
- Outbound random port is often configured on ephemeral ports 1024 – 65535
- Rules are evalutaed in numerical order. Its rocommended to use the iteration of 100.
- NACLS are evaluated before security groups.
- Nacls are statelsss.
- Security groups are statefull.
- Load Balances and custom VPC.
- 2 subnets must be specified and ever subnet must be from different AZ.
- Elastic load balances can take care of TLS termination.
- To terminate the traffic on EC2 instance we need to use classic or network load balancer. (due to TCP usage)
SNI : Can be done with TCP listerner with more certificates from ACS.
SSL policies for Load balancing are making a lot for understanding SSL / TLS layer and end2end encryption: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html
Main actors in VPN setup from on-premise to AWS:
VPN connectivity is initiated from the customer gateway, not from AWS services. Virtual private Gateway always has 2 tunnels and It is recommended to have HA solution on Customer gateways side.
- You can select your routing method based on your VPN device. (Static and dynamic routing.
- You can use pre-shared keys, or certificates to authenticate your Site-to-Site VPN tunnel endpoints.
- Main recommended architectures are:
- Multiple Site-to-Site VPN connections with a transit gateway
- Multiple Site-to-Site VPN connections
- Single Site-to-Site VPN connection
- You can download great static-routing-examples.zip to view example configuration files for the following customer gateway devices. Configuration file for your device to establish Site to Site tunnel is provided by AWS.
Process according AWS is following:
- Step 1: Create a customer gateway
- Step 2: Create a target gateway
- Step 3: Configure routing
- Step 4: Update your security group
- Step 5: Create a Site-to-Site VPN connection
- Step 6: Download the configuration file
- Step 7: Configure the customer gateway device