Encryption at rest for azimuth elevation ephemeris
Key policy requirements for azimuth elevation ephemeris
To use a customer managed key with azimuth elevation ephemeris data, your key policy must grant the following permissions to the AWS Ground Station service. Unlike TLE and OEM ephemeris data which uses grants, azimuth elevation ephemeris uses direct key policy permissions for encryption operations. This is a simpler method to manage the permissions of, and use your keys.
-
kms:GenerateDataKey- Generates data keys for encrypting your azimuth elevation ephemeris data. -
kms:Decrypt- Decrypts the encrypted data keys when accessing your azimuth elevation ephemeris data.
Example key policy granting AWS Ground Station access to a customer managed key
Note
With azimuth elevation ephemeris, you must configure these permissions directly in the key policy. The regional AWS Ground Station
service principal (e.g., groundstation.) must be granted these
permissions in your key policy statements. Without these statements added to the key policy AWS Ground Station will be unable to store or access your
custom azimuth elevation ephemeris.
region.amazonaws.com
IAM user permissions for creating azimuth elevation ephemeris with customer managed keys
When AWS Ground Station uses a customer managed key in cryptographic operations, it acts on behalf of the user who is creating the azimuth elevation ephemeris resource.
To create an azimuth elevation ephemeris resource using a customer managed key, a user must have permissions to call the following operations on the customer managed key:
-
kms:GenerateDataKey- Allows the user to generate data keys for encrypting the azimuth elevation ephemeris data. -
kms:Decrypt- Allows the user to decrypt data keys when accessing the azimuth elevation ephemeris data. -
kms:DescribeKey- Allows the user to view the customer managed key details to validate the key.
You can specify these required permissions in a key policy, or in an IAM policy if the key policy allows it. These permissions ensure that users can authorize AWS Ground Station to use the customer managed key for encryption operations on their behalf.
How AWS Ground Station uses key policies for azimuth elevation ephemeris
When you provide azimuth elevation ephemeris data with a customer managed key, AWS Ground Station uses key policies to access your encryption key. The permissions are granted directly to AWS Ground Station through key policy statements rather than through grants as with TLE or OEM ephemeris data.
If you remove AWS Ground Station's access to the customer managed key, AWS Ground Station won't be able to access any of the data encrypted by that key, which affects operations that are dependent on that data. For example, if you remove key policy permissions for azimuth elevation ephemeris currently in use for a contact, AWS Ground Station will be unable to use the provided azimuth elevation data for commanding the antenna during the contact. This will cause the contact to end in a FAILED state.
Azimuth elevation ephemeris encryption context
When AWS Ground Station uses your AWS KMS key to encrypt azimuth elevation ephemeris data, the service specifies an encryption context. The encryption context is additional authenticated data (AAD) that AWS KMS uses to ensure data integrity. When an encryption context is specified for an encryption operation, the service must specify the same encryption context for the decryption operation. Otherwise, decryption fails. The encryption context is also written to your CloudTrail logs to help you understand why a given AWS KMS key was used. Your CloudTrail logs might contain many entries describing the use of a AWS KMS key, but the encryption context in each log entry can help you determine the reason for that particular use.
AWS Ground Station specifies the following encryption context when it performs cryptographic operations with your customer managed key on an azimuth elevation ephemeris:
{ "encryptionContext": { "aws:groundstation:ground-station-id": "Ohio 1", "aws:groundstation:arn": "arn:aws:groundstation:us-east-2:111122223333:ephemeris/00a770b0-082d-45a4-80ed-SAMPLE", "aws:s3:arn": "arn:aws:s3:::customerephemerisbucket/00a770b0-082d-45a4-80ed-SAMPLE/raw" } }
The encryption context contains:
aws:groundstation:ground-station-id-
The name of the ground station associated with the azimuth elevation ephemeris.
- aws:groundstation:arn
-
The ARN of the ephemeris resource.
- aws:s3:arn
-
The ARN of the ephemeris stored in Amazon S3.
Using encryption context to control access to your customer managed key
You can use IAM condition statements to control AWS Ground Station access to your customer managed key. Adding a condition statement on the
kms:GenerateDataKey and kms:Decrypt actions restricts which ground stations a AWS KMS can be used for.
The following are example key policy statements to grant AWS Ground Station access to your customer managed key in a specific region for a specific ground station. The condition in this policy statement requires that all encrypt and decrypt access to the key that specify an encryption context that matches the condition in the key policy.
Example key policy granting AWS Ground Station access to a customer managed key for a specific ground station
Example key policy granting AWS Ground Station access to a customer managed key for multiple ground stations
Monitoring your encryption keys for azimuth elevation ephemeris
When you use an AWS KMS customer managed key with your azimuth elevation ephemeris resources, you can use CloudTrail or CloudWatch logs to track requests that AWS Ground Station sends to AWS KMS. The following examples are CloudTrail events for GenerateDataKey and Decrypt to monitor AWS KMS operations called by AWS Ground Station to access data encrypted by your customer managed key.
