Redshift - це повністю керована служба, яка може масштабуватися до понад петабайта, що використовується як сховище даних для рішень великих даних. Використовуючи кластери Redshift, ви можете виконувати аналітику над своїми наборами даних, використовуючи швидкі інструменти запитів на основі SQL та додатки бізнес-аналітики для отримання більшого розуміння бачення вашого бізнесу.
Redshift пропонує шифрування даних у стані спокою, використовуючи чотирирівневу ієрархію ключів шифрування, використовуючи або KMS, або CloudHSM для управління верхнім рівнем ключів. Коли шифрування увімкнено для вашого кластера, його не можна вимкнути і навпаки. Коли у вас є незашифрований кластер, його не можна зашифрувати.
Шифрування для вашого кластера може відбуватися лише під час його створення, і після шифрування дані, метадані та будь-які знімки також шифруються. Рівні ієрархії ключів шифрування наступні: перший рівень - це головний ключ, другий рівень - ключ шифрування кластера, CEK, третій рівень - ключ шифрування бази даних, DEK, і нарешті четвертий рівень - самі ключі шифрування даних.
KMS
Під час створення вашого кластера ви можете вибрати або стандартний KMS ключ для Redshift, або вибрати свій власний CMK, що дає вам більше гнучкості в управлінні ключем, особливо з точки зору аудиту.
Стандартний KMS ключ для Redshift автоматично створюється Redshift при першому виборі та використанні опції ключа, і він повністю керується AWS.
Цей KMS ключ потім шифрується головним ключем CMK, перший рівень. Цей зашифрований KMS ключ даних потім використовується як ключ шифрування кластера, CEK, другий рівень. Цей CEK потім надсилається KMS до Redshift, де він зберігається окремо від кластера. Redshift потім надсилає цей зашифрований CEK до кластера через захищений канал, де він зберігається в пам'яті.
Redshift потім запитує KMS для розшифрування CEK, другий рівень. Цей розшифрований CEK також зберігається в пам'яті. Redshift потім створює випадковий ключ шифрування бази даних, DEK, третій рівень, і завантажує його в пам'ять кластера. Розшифрований CEK в пам'яті потім шифрує DEK, який також зберігається в пам'яті.
Цей зашифрований DEK потім надсилається через захищений канал і зберігається в Redshift окремо від кластера. І CEK, і DEK тепер зберігаються в пам'яті кластера як у зашифрованій, так і в розшифрованій формі. Розшифрований DEK потім використовується для шифрування ключів даних, четвертий рівень, які випадково генеруються Redshift для кожного блоку даних у базі даних.
Ви можете використовувати AWS Trusted Advisor для моніторингу конфігурації ваших Amazon S3 бакетів і забезпечення увімкнення журналювання бакетів, що може бути корисним для проведення аудиту безпеки та відстеження шаблонів використання в S3.
CloudHSM
Використання Redshift з CloudHSM
Працюючи з CloudHSM для виконання вашого шифрування, спочатку ви повинні налаштувати довірений зв'язок між вашим HSM клієнтом і Redshift, використовуючи клієнтські та серверні сертифікати.
Цей зв'язок необхідний для забезпечення безпечного зв'язку, що дозволяє передавати ключі шифрування між вашим HSM клієнтом і вашими кластерами Redshift. Використовуючи випадково згенеровану пару приватного та публічного ключів, Redshift створює публічний клієнтський сертифікат, який шифрується та зберігається Redshift. Це потрібно завантажити та зареєструвати на вашому HSM клієнті та призначити правильному розділу HSM.
Ви повинні налаштувати Redshift з наступними деталями вашого HSM клієнта: IP-адреса HSM, ім'я розділу HSM, пароль розділу HSM та публічний серверний сертифікат HSM, який шифрується CloudHSM за допомогою внутрішнього головного ключа. Після надання цієї інформації Redshift підтвердить і перевірить, що він може підключитися та отримати доступ до розділу розробки.
Якщо ваші внутрішні політики безпеки або контроль управління вимагають застосування ротації ключів, це можливо з Redshift, що дозволяє вам обертати ключі шифрування для зашифрованих кластерів, однак, ви повинні знати, що під час процесу ротації кластер буде недоступний протягом дуже короткого періоду часу, тому краще обертати ключі лише тоді, коли це необхідно, або якщо ви вважаєте, що вони могли бути скомпрометовані.
Під час ротації Redshift обертатиме CEK для вашого кластера та для будь-яких резервних копій цього кластера. Він обертатиме DEK для кластера, але неможливо обертати DEK для знімків, збережених у S3, які були зашифровані за допомогою DEK. Він переведе кластер у стан 'rotating keys' до завершення процесу, після чого статус повернеться до 'available'.
Enumeration
# Get clustersawsredshiftdescribe-clusters## Get if publicly accessibleawsredshiftdescribe-clusters|jq-r".Clusters[].PubliclyAccessible"## Get DB username to loginawsredshiftdescribe-clusters|jq-r".Clusters[].MasterUsername"## Get endpointawsredshiftdescribe-clusters|jq-r".Clusters[].Endpoint"## Public addresses of the nodesawsredshiftdescribe-clusters|jq-r".Clusters[].ClusterNodes[].PublicIPAddress"## Get IAM roles of the clustersawsredshiftdescribe-clusters|jq-r".Clusters[].IamRoles"# Endpoint access & authorizationawsredshiftdescribe-endpoint-accessawsredshiftdescribe-endpoint-authorization# Get credentialsawsredshiftget-cluster-credentials--db-user<username>--cluster-identifier<cluster-id>## By default, the temporary credentials expire in 900 seconds. You can optionally specify a duration between 900 seconds (15 minutes) and 3600 seconds (60 minutes).
awsredshiftget-cluster-credentials-with-iam--cluster-identifier<cluster-id>## Gives creds to access redshift with the IAM redshift permissions given to the current AWS account## More in https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-access-control-identity-based.html# Authentication profilesawsredshiftdescribe-authentication-profiles# Snapshotsawsredshiftdescribe-cluster-snapshots# Scheduled actionsawsredshiftdescribe-scheduled-actions# Connect# The redshift instance must be publicly available (not by default), the sg need to allow inbounds connections to the port and you need creds
psql-hredshift-cluster-1.sdflju3jdfkfg.us-east-1.redshift.amazonaws.com-Uadmin-ddev-p5439
