Please enable JavaScript.

Coggle requires JavaScript to display documents.

Security - Coggle Diagram

- - - - Log file integrity validation
        
        You can enable it - this makes it computationally infeasible to modify, delete or forge CloudTrail log files without detection
        
        Allows you to detect if a log file was changed or deleted
        
        CloudTrail creates a SHA-256 hash for each log file
        
        Digest files contain referencies to all log files created in the past hour and a hash of each file
        
        Digest files are digitally signed using a private key (SHA-256 with RSA) owned by AWS
        
        You can use the AWS CLI to validate the files in the location where CloudTrail delivered them
      - Secure the S3 bucket used to store your logs
        
        Dedicated - use a dedicated S3 bucket for CloudTrail
        
        Control Access - use a bucket policy to control access. CloudTrail will need permission to write to the bucket
        
        *User Read Access *- restrict read access permission to only those who need it (e.g. security team, SysOps team)
        
        Enable S3 versioning
        
        Enable S3 Object Lock
        
        MFA Delete Protection
        
        S3 Lifecycle Policy (S3 IA, Glacier...)
      - Server-side Encryption SSE
        
        SSE-KMS enabled by default
        
        SSE-KMS you control who can use the key for encrypting/decrypting files
        
        You control access, only users with permission to use the key will be able to decrypt
        
        The key policy must allow CloudTrail to use the key, and let the users you specify read log files
        
        The KMS key and S3 must be in the same AWS Region
        
        CloudTrail also supports AWS KMS multi-Region keys
- - - - KMS
        
        Shared tenancy of underlying hardware
        
        Automatic key rotation
        
        Automatic key generation
      - CloudHSM
        
        Dedicated HSM to you
        
        Full control of underlying hardware
        
        Full control of users, groups, keys, etc.
        
        No automatic key rotation
    - - Create a CloudHSM Cluster that can contain multiple HSMs, spread across multiple AZ in a region
        
        HSM appears as a network resource in your VPC
        
        HSMs in a cluster are automatically synchronized and load-balanced
        
        You receive dedicated, single-tenant access to each HSM in your cluster
        
        Add/Remove HSMs from your Cluster with AWS CloudHSM API or AWS CLI
        
        You configure a client on your EC2 instance that allows your applications to use the cluster over a secure, authenticated network connection
        
        AWS just provides you the hardware and the CloudHM software client, then it is up to you to manage it. If you loose keys AWS cannot help you
        
        AWS API and thus IAM permissions only to CRUD an HSM Cluster
        
        CloudHSM software allows you to manage users and keys
    - - KMS is integrated with AWS CloudHSM through the KMS custom key store feature
        
        AWS services integrate with AWS Key Management Service
        
        To use the server-side encryption offered by AWS services (e.g. EBS, S3, RDS), you can do so by configuring a custom key store in AWS KMS
        
        Redshift supports CloudHSM for database encryption and key management
        
        Good option for S3 SSE-C
    - - SSL/TLS Acceleration (NGINX, Apache HTTPD, MS IIS)
        
        Oracle TDE Acceleration
        
        Redshift supports CloudHSM for database encryption and key management