# AWS - Redshift Enum

{{#include ../../../banners/hacktricks-training.md}}

## Amazon Redshift

Redshift est un service entièrement géré qui peut évoluer jusqu'à plus d'un pétaoctet, utilisé comme un **entrepôt de données pour des solutions de big data**. En utilisant des clusters Redshift, vous pouvez exécuter des analyses sur vos ensembles de données à l'aide d'outils de requête rapides basés sur SQL et d'applications d'intelligence d'affaires pour mieux comprendre la vision de votre entreprise.

**Redshift offre un chiffrement au repos utilisant une hiérarchie de clés de chiffrement à quatre niveaux en utilisant soit KMS soit CloudHSM pour gérer le niveau supérieur des clés**. **Lorsque le chiffrement est activé pour votre cluster, il ne peut pas être désactivé et vice versa**. Lorsque vous avez un cluster non chiffré, il ne peut pas être chiffré.

Le chiffrement pour votre cluster ne peut se faire qu'au moment de sa création, et une fois chiffré, les données, les métadonnées et tous les instantanés sont également chiffrés. Les niveaux de hiérarchie des clés de chiffrement sont les suivants : **le niveau un est la clé maître, le niveau deux est la clé de chiffrement du cluster, la CEK, le niveau trois, la clé de chiffrement de la base de données, la DEK, et enfin le niveau quatre, les clés de chiffrement des données elles-mêmes**.

### KMS

Lors de la création de votre cluster, vous pouvez soit sélectionner la **clé KMS par défaut** pour Redshift soit sélectionner votre **propre CMK**, ce qui vous donne plus de flexibilité sur le contrôle de la clé, spécifiquement d'un point de vue auditable.

La clé KMS par défaut pour Redshift est automatiquement créée par Redshift la première fois que l'option de clé est sélectionnée et utilisée, et elle est entièrement gérée par AWS.

Cette clé KMS est ensuite chiffrée avec la clé maître CMK, niveau un. Cette clé de données KMS chiffrée est ensuite utilisée comme clé de chiffrement du cluster, la CEK, niveau deux. Cette CEK est ensuite envoyée par KMS à Redshift où elle est stockée séparément du cluster. Redshift envoie ensuite cette CEK chiffrée au cluster via un canal sécurisé où elle est stockée en mémoire.

Redshift demande ensuite à KMS de déchiffrer la CEK, niveau deux. Cette CEK déchiffrée est ensuite également stockée en mémoire. Redshift crée ensuite une clé de chiffrement de base de données aléatoire, la DEK, niveau trois, et la charge dans la mémoire du cluster. La CEK déchiffrée en mémoire chiffre ensuite la DEK, qui est également stockée en mémoire.

Cette DEK chiffrée est ensuite envoyée via un canal sécurisé et stockée dans Redshift séparément du cluster. La CEK et la DEK sont maintenant stockées en mémoire du cluster à la fois sous forme chiffrée et déchiffrée. La DEK déchiffrée est ensuite utilisée pour chiffrer les clés de données, niveau quatre, qui sont générées aléatoirement par Redshift pour chaque bloc de données dans la base de données.

Vous pouvez utiliser AWS Trusted Advisor pour surveiller la configuration de vos buckets Amazon S3 et vous assurer que la journalisation des buckets est activée, ce qui peut être utile pour effectuer des audits de sécurité et suivre les modèles d'utilisation dans S3.

### CloudHSM

<details>

<summary>Utiliser Redshift avec CloudHSM</summary>

Lorsque vous travaillez avec CloudHSM pour effectuer votre chiffrement, vous devez d'abord établir une connexion de confiance entre votre client HSM et Redshift tout en utilisant des certificats client et serveur.

Cette connexion est nécessaire pour fournir des communications sécurisées, permettant aux clés de chiffrement d'être envoyées entre votre client HSM et vos clusters Redshift. En utilisant une paire de clés privées et publiques générées aléatoirement, Redshift crée un certificat client public, qui est chiffré et stocké par Redshift. Cela doit être téléchargé et enregistré sur votre client HSM, et attribué à la bonne partition HSM.

Vous devez ensuite configurer Redshift avec les détails suivants de votre client HSM : l'adresse IP HSM, le nom de la partition HSM, le mot de passe de la partition HSM, et le certificat de serveur HSM public, qui est chiffré par CloudHSM en utilisant une clé maître interne. Une fois ces informations fournies, Redshift confirmera et vérifiera qu'il peut se connecter et accéder à la partition de développement.

Si vos politiques de sécurité internes ou vos contrôles de gouvernance dictent que vous devez appliquer une rotation des clés, cela est possible avec Redshift vous permettant de faire pivoter les clés de chiffrement pour les clusters chiffrés, cependant, vous devez être conscient que pendant le processus de rotation des clés, cela rendra un cluster indisponible pendant une très courte période, il est donc préférable de ne faire pivoter les clés que lorsque vous en avez besoin, ou si vous pensez qu'elles ont pu être compromises.

Pendant la rotation, Redshift fera pivoter la CEK pour votre cluster et pour toutes les sauvegardes de ce cluster. Il fera pivoter une DEK pour le cluster mais il n'est pas possible de faire pivoter une DEK pour les instantanés stockés dans S3 qui ont été chiffrés en utilisant la DEK. Il mettra le cluster dans un état de 'rotation des clés' jusqu'à ce que le processus soit terminé lorsque le statut reviendra à 'disponible'.

</details>

### Énumération
```bash
# Get clusters
aws redshift describe-clusters
## Get if publicly accessible
aws redshift describe-clusters | jq -r ".Clusters[].PubliclyAccessible"
## Get DB username to login
aws redshift describe-clusters | jq -r ".Clusters[].MasterUsername"
## Get endpoint
aws redshift describe-clusters | jq -r ".Clusters[].Endpoint"
## Public addresses of the nodes
aws redshift describe-clusters | jq -r ".Clusters[].ClusterNodes[].PublicIPAddress"
## Get IAM roles of the clusters
aws redshift describe-clusters | jq -r ".Clusters[].IamRoles"

# Endpoint access & authorization
aws redshift describe-endpoint-access
aws redshift describe-endpoint-authorization

# Get credentials
aws redshift get-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).
aws redshift get-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 profiles
aws redshift describe-authentication-profiles

# Snapshots
aws redshift describe-cluster-snapshots

# Scheduled actions
aws redshift describe-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 -h redshift-cluster-1.sdflju3jdfkfg.us-east-1.redshift.amazonaws.com -U admin -d dev -p 5439
```
## Privesc

{{#ref}}
../aws-privilege-escalation/aws-redshift-privesc.md
{{#endref}}

## Persistence

Les actions suivantes permettent d'accorder l'accès à d'autres comptes AWS au cluster :

- [authorize-endpoint-access](https://docs.aws.amazon.com/cli/latest/reference/redshift/authorize-endpoint-access.html)
- [authorize-snapshot-access](https://docs.aws.amazon.com/cli/latest/reference/redshift/authorize-snapshot-access.html)

{{#include ../../../banners/hacktricks-training.md}}
