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
Using Redshift with 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. Він переведе кластер у стан "обертання ключів" до завершення процесу, коли статус повернеться до "доступний".
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
Privesc
Persistence
Наступні дії дозволяють надати доступ до інших облікових записів AWS до кластера: