Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/

src/pentesting-cloud/aws-security/aws-services/aws-redshift-enum.md

@@ -4,46 +4,43 @@
 
 ## Amazon Redshift
 
-Redshift is a fully managed service that can scale up to over a petabyte in size, which is used as a **data warehouse for big data solutions**. Using Redshift clusters, you are able to run analytics against your datasets using fast, SQL-based query tools and business intelligence applications to gather greater understanding of vision for your business.
+Redshiftは、**ビッグデータソリューションのためのデータウェアハウス**として使用される、ペタバイト以上のサイズにスケールアップできる完全管理型サービスです。Redshiftクラスターを使用すると、高速なSQLベースのクエリツールやビジネスインテリジェンスアプリケーションを使用してデータセットに対して分析を実行し、ビジネスのビジョンをより深く理解することができます。
 
-**Redshift offers encryption at rest using a four-tired hierarchy of encryption keys using either KMS or CloudHSM to manage the top tier of keys**. **When encryption is enabled for your cluster, it can't be disable and vice versa**. When you have an unencrypted cluster, it can't be encrypted.
+**Redshiftは、KMSまたはCloudHSMを使用して、最上位のキーを管理する4層の暗号化キーの階層を使用して、静止時の暗号化を提供します**。**クラスターの暗号化が有効になっている場合、それを無効にすることはできず、その逆も同様です**。暗号化されていないクラスターは、暗号化することができません。
 
-Encryption for your cluster can only happen during its creation, and once encrypted, the data, metadata, and any snapshots are also encrypted. The tiering level of encryption keys are as follows, **tier one is the master key, tier two is the cluster encryption key, the CEK, tier three, the database encryption key, the DEK, and finally tier four, the data encryption keys themselves**.
+クラスターの暗号化は、その作成中にのみ行うことができ、一度暗号化されると、データ、メタデータ、およびスナップショットも暗号化されます。暗号化キーの階層レベルは次のとおりです。**層1はマスターキー、層2はクラスター暗号化キー（CEK）、層3はデータベース暗号化キー（DEK）、最後に層4はデータ暗号化キー自体です**。
 
 ### KMS
 
-During the creation of your cluster, you can either select the **default KMS key** for Redshift or select your **own CMK**, which gives you more flexibility over the control of the key, specifically from an auditable perspective.
+クラスターの作成中に、Redshiftの**デフォルトKMSキー**を選択するか、**独自のCMK**を選択することができ、特に監査可能な観点からキーの制御に対してより柔軟性を持つことができます。
 
-The default KMS key for Redshift is automatically created by Redshift the first time the key option is selected and used, and it is fully managed by AWS.
+RedshiftのデフォルトKMSキーは、キーオプションが初めて選択され使用されるときに自動的に作成され、AWSによって完全に管理されます。
 
-This KMS key is then encrypted with the CMK master key, tier one. This encrypted KMS data key is then used as the cluster encryption key, the CEK, tier two. This CEK is then sent by KMS to Redshift where it is stored separately from the cluster. Redshift then sends this encrypted CEK to the cluster over a secure channel where it is stored in memory.
+このKMSキーは、CMKマスターキー（層1）で暗号化されます。この暗号化されたKMSデータキーは、クラスター暗号化キー（CEK、層2）として使用されます。このCEKはKMSによってRedshiftに送信され、クラスターとは別に保存されます。Redshiftはこの暗号化されたCEKを安全なチャネルを介してクラスターに送信し、メモリに保存します。
 
-Redshift then requests KMS to decrypt the CEK, tier two. This decrypted CEK is then also stored in memory. Redshift then creates a random database encryption key, the DEK, tier three, and loads that into the memory of the cluster. The decrypted CEK in memory then encrypts the DEK, which is also stored in memory.
+RedshiftはKMSにCEK（層2）の復号を要求します。この復号されたCEKもメモリに保存されます。Redshiftはランダムなデータベース暗号化キー（DEK、層3）を作成し、それをクラスターのメモリにロードします。メモリ内の復号されたCEKはDEKを暗号化し、これもメモリに保存されます。
 
-This encrypted DEK is then sent over a secure channel and stored in Redshift separately from the cluster. Both the CEK and the DEK are now stored in memory of the cluster both in an encrypted and decrypted form. The decrypted DEK is then used to encrypt data keys, tier four, that are randomly generated by Redshift for each data block in the database.
+この暗号化されたDEKは、安全なチャネルを介して送信され、Redshiftにクラスターとは別に保存されます。CEKとDEKは、暗号化された形式と復号された形式の両方で、クラスターのメモリに保存されています。復号されたDEKは、Redshiftによってデータベース内の各データブロックのためにランダムに生成されたデータキー（層4）を暗号化するために使用されます。
 
-You can use AWS Trusted Advisor to monitor the configuration of your Amazon S3 buckets and ensure that bucket logging is enabled, which can be useful for performing security audits and tracking usage patterns in S3.
+AWS Trusted Advisorを使用して、Amazon S3バケットの構成を監視し、バケットロギングが有効になっていることを確認できます。これは、セキュリティ監査を実施し、S3の使用パターンを追跡するのに役立ちます。
 
 ### CloudHSM
 
 <details>
 
-<summary>Using Redshift with CloudHSM</summary>
+<summary>CloudHSMを使用したRedshift</summary>
 
-When working with CloudHSM to perform your encryption, firstly you must set up a trusted connection between your HSM client and Redshift while using client and server certificates.
+CloudHSMを使用して暗号化を行う場合、まずHSMクライアントとRedshiftの間に信頼できる接続を設定する必要があります。この接続は、HSMクライアントとRedshiftクラスター間で暗号化キーを送信するための安全な通信を提供するために必要です。ランダムに生成されたプライベートおよびパブリックキーのペアを使用して、Redshiftは公開クライアント証明書を作成し、これを暗号化してRedshiftに保存します。これをダウンロードしてHSMクライアントに登録し、正しいHSMパーティションに割り当てる必要があります。
 
-This connection is required to provide secure communications, allowing encryption keys to be sent between your HSM client and your Redshift clusters. Using a randomly generated private and public key pair, Redshift creates a public client certificate, which is encrypted and stored by Redshift. This must be downloaded and registered to your HSM client, and assigned to the correct HSM partition.
+次に、HSMクライアントの次の詳細を使用してRedshiftを構成する必要があります：HSMのIPアドレス、HSMパーティション名、HSMパーティションパスワード、およびCloudHSMによって内部マスターキーを使用して暗号化された公開HSMサーバー証明書。この情報が提供されると、Redshiftは接続して開発パーティションにアクセスできることを確認し、検証します。
 
-You must then configure Redshift with the following details of your HSM client: the HSM IP address, the HSM partition name, the HSM partition password, and the public HSM server certificate, which is encrypted by CloudHSM using an internal master key. Once this information has been provided, Redshift will confirm and verify that it can connect and access development partition.
+内部のセキュリティポリシーやガバナンスコントロールがキーのローテーションを適用する必要があると規定している場合、Redshiftを使用して暗号化されたクラスターの暗号化キーをローテーションすることが可能ですが、キーのローテーションプロセス中はクラスターが非常に短い時間利用できなくなることに注意する必要があります。そのため、必要なときや、キーが侵害された可能性があると感じたときにのみキーをローテーションするのが最善です。
 
-If your internal security policies or governance controls dictate that you must apply key rotation, then this is possible with Redshift enabling you to rotate encryption keys for encrypted clusters, however, you do need to be aware that during the key rotation process, it will make a cluster unavailable for a very short period of time, and so it's best to only rotate keys as and when you need to, or if you feel they may have been compromised.
-
-During the rotation, Redshift will rotate the CEK for your cluster and for any backups of that cluster. It will rotate a DEK for the cluster but it's not possible to rotate a DEK for the snapshots stored in S3 that have been encrypted using the DEK. It will put the cluster into a state of 'rotating keys' until the process is completed when the status will return to 'available'.
+ローテーション中、RedshiftはクラスターのCEKとそのバックアップのCEKをローテーションします。クラスターのDEKはローテーションされますが、DEKを使用して暗号化されたS3に保存されたスナップショットのDEKをローテーションすることはできません。プロセスが完了するまで、クラスターは「キーをローテーション中」の状態になり、その後ステータスは「利用可能」に戻ります。
 
 </details>
 
 ### Enumeration
-
 ```bash
 # Get clusters
 aws redshift describe-clusters
@@ -82,7 +79,6 @@ aws redshift describe-scheduled-actions
 # 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}}
@@ -91,13 +87,9 @@ psql -h redshift-cluster-1.sdflju3jdfkfg.us-east-1.redshift.amazonaws.com -U adm
 
 ## Persistence
 
-The following actions allow to grant access to other AWS accounts to the cluster:
+次のアクションにより、クラスタへの他のAWSアカウントへのアクセスを付与できます：
 
 - [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}}
-
-
-
-