Wasabi ポリシージェネレーターの使用方法

Wasabi ポリシージェネレーターは、ユーザーがビジュアルエディター形式でポリシーを作成できるツールで、Wasabi のリソースへのアクセスに関わる JSON ポリシーを自動作成します。

このツールは AWS ポリシージェネレーター と使用方法が似ているため、複雑なポリシーを作成する前に、IMAポリシーとアクセス許可についてこちらのKBを読んでおくことを強くおすすめします。

Wasabi ポリシージェネレーターの使用前に以下の注意点を確認しておきましょう。

  • 現時点では、以下の4つのタイプのサービスに対するポリシーを作成することができます。
  1. iam
  2. s3
  3. sts
  4. aws-portal
  • 1つのポリシーに複数のルールを追加することができます。
  • 1つのステートメントで複数の条件を追加することができます。
  • 現在、このツールを使用して追加できるのは1つのステートメントのみで、複数のステートメントを追加する機能は今後リリース予定です。複数のステートメントが必要な場合は、ポリシージェネレーターを使用してポリシーを作成した後、エディターボックスでポリシーを編集できます。

 

このポリシージェネレーターを使用するには、Wasabi コンソールにログインし、メニューから [ポリシー] を選択し、[ポリシーを作成] をクリックします。

以下のスクリーンショットのように、[ポリシージェネレーター] をクリックしてポリシーの作成を開始します。

mceclip0.png

 

ここでは、このツールを使い始めるのに役立ついくつかの基本的な例を紹介していますが、必要に応じて複雑なポリシーを作成することも可能です。

1. サブユーザーのすべての IAM アクションを許可するポリシー

2. サブユーザーのすべてのポリシーの作成、更新、削除、一覧表示、取得、デフォルトバージョンの設定を許可するポリシー

3. サブユーザーのバケット内のすべての s3 アクションを許可するポリシー (図のように複数のステートメントが必要です)

4. s3 バケットポリシーを作成し、パブリックへの読み出しアクセスを許可する (リソースベースのポリシー)

5. API コールを発信するクライアント IP を制限するポリシー

6. STS 経由でサブユーザーにロールを引き受ける許可を与えるポリシー

7. MFA にあらゆる種類の削除を強制的に許可するポリシー

8. 請求ページの表示を許可するが、s3 のすべてのアクションを拒否するポリシー

------------------------------------------------------------------------------------------------------

1. サブユーザーのすべての IAM アクションを許可するポリシー

ポリシー名と説明を入力し、[ルール] をクリックし、[許可] を選択します。

ここでは、スクリーンショットにあるように「iam」サービスを選択しています。

mceclip1.png

この例では、すべての iam ポリシーに対してすべての iam アクションを許可するポリシーを作成しています。スクリーンショットのとおり、[リソース名] に「All Actions」と「*」を選択しています。

mceclip2.png

[適用する] をクリックすると、JSON のポリシー文書が自動作成されます。ここで、[ポリシーを作成] をクリックして、このポリシーを iam のすべてのアクションを許可したいサブユーザーに添付することができます。

mceclip3.png

 

2. サブユーザーのすべてのポリシーの作成、更新、削除、一覧表示、取得、デフォルトバージョンの設定を許可するポリシー

まず、ポリシーに名前と説明を追加します。[ルール] をクリックし、[許可] を選択し、「iam」サービスを選択します。

この例では、すべての iam アクションではなく、このポリシーを作成するために必要なアクションのみを個別に選択して許可します。スクリーンショットのとおり、ドロップダウンメニューをクリックしてアクションを一つずつ選択していきます。

アクションを1つ選択したら、下部の [ルールを追加] ボタンをクリックしてアクションを追加し、同じ作業を繰り返して以下のアクションをすべて追加します。

 "iam:CreatePolicy", "iam:CreatePolicyVersion", "iam:DeletePolicy", "iam:DeletePolicyVersion", "iam:GetPolicy", "iam:GetPolicyVersion", "iam:ListPolicies", "iam:ListPolicyVersions", "iam:SetDefaultPolicyVersion"

Screen_Shot_2020-07-12_at_9.52.52_PM.png

[ルールを追加] ですべてのアクションを追加すると、次のようなポリシーが生成されます。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreatePolicy",
"Resource": [
"*"
],
"Condition": {}
},
{
"Effect": "Allow",
"Action": "iam:CreatePolicyVersion",
"Resource": [
"*"
],
"Condition": {}
},
{
"Effect": "Allow",
"Action": "iam:DeletePolicy",
"Resource": [
"*"
],
"Condition": {}
},
{
"Effect": "Allow",
"Action": "iam:GetPolicy",
"Resource": [
"*"
],
"Condition": {}
},
{
"Effect": "Allow",
"Action": "iam:GetPolicyVersion",
"Resource": [
"*"
],
"Condition": {}
},
{
"Effect": "Allow",
"Action": "iam:ListPolicies",
"Resource": [
"*"
],
"Condition": {}
},
{
"Effect": "Allow",
"Action": "iam:ListPolicyVersions",
"Resource": [
"*"
],
"Condition": {}
},
{
"Effect": "Allow",
"Action": "iam:SetDefaultPolicyVersion",
"Resource": [
"*"
],
"Condition": {}
}
]
}

ここで、[ポリシーを作成] をクリックして、このポリシーを選択したサブユーザーに添付します。

3. サブユーザーのバケット内のすべての s3 アクションを許可するポリシー (図のように複数のステートメントが必要です)

今回は、「s3」サービスを選択し、すべてのアクションを許可しています。

[リソース名(Resource Name)] セクションに、アクセスを許可したいサブユーザーの s3 バケットの ARN を追加し、ARN を以下のように編集してそのバケット内のすべてを許可する別のルールを追加します。

arn:aws:s3:::bucket-name/*

Screen_Shot_2020-07-12_at_10.40.31_PM.png

このように、複数のステートメントが必要になる場合があります。その場合は、Wasabi ポリシージェネレーターでポリシーを自動生成したら、ポリシーを保存する前に、エディターを使って以下のように別のステートメントを追加します。

 :  コンソールでバケットやオブジェクトの操作を行うには、サブユーザーに「ListAllMyBuckets」許可が 必要 となるため、以下のとおり別のステートメントを追加しています。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::bucket-name"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::bucket-name/*"
}
]
}

 

4. s3 バケットポリシーを作成し、パブリックへの読み出しアクセスを許可する (リソースベースのポリシー)

: これらはリソースベースのポリシーと呼ばれる特殊なポリシーで、IAM ユーザーではなくリソースに直接適用されます。このため、ステートメントの「Principal」に含める必要があります。

リソースベースのポリシーを作成する場合は、アクセスを許可または拒否したいアカウント、ユーザー、ロールもしくは外部連携ユーザーを示す必要があります。ユーザーやロールに添付する IAM 許可ポリシーを作成する場合には、この要素を含めることができません。Principal はそのユーザーまたはロールとして暗示されます。

Screen_Shot_2020-07-12_at_11.08.43_PM.png

このポリシーを作成する前に、以下のようにポリシーエディターに Principal 要素を追加し、ここでの説明に従い、このポリシーを公開したいバケットにコピーします。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::public-bucket-name"
],
"Condition": {}
}
]
}

 

5. API コールを発信するクライアント IP を制限するポリシー

この例では、条件ステートメントで指定された発信元 IP からのものでない場合、Wasabi アカウントへのすべての API コールを拒否するという条件のポリシーを作成します。

例として 203.0.113.0/24 IP を使用しています。ご利用の IP アドレスに基づいて任意の値を追加できます。

Screen_Shot_2020-07-12_at_11.24.14_PM.png

ポリシーは以下のようになります。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
}
]
}

 

6. STS 経由でサブユーザーにロールを引き受ける許可を与えるポリシー

このポリシーをサブユーザーに添付することで、アカウントで作成済みのロールに対して sts 経由で AssumeRole を呼び出す許可を付与することができます。

リソース名には、正しい ARN、適切な Wasabi アカウント番号、自分のロール名を必ず使用してください。

Screen_Shot_2020-07-13_at_12.10.25_AM.png

 

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::1234567890:role/already-present-role-name"
],
"Condition": {}
}
]
}

 

7. MFA にあらゆる種類の削除を強制的に許可するポリシー

このポリシーは基本的にすべてのリソースに対する s3 アクションを許可しますが、MFA 認証で承認されない限り、アカウントで行われるあらゆる種類の削除を拒否します。

 :  コンソールでバケットやオブジェクトの操作を行うには、サブユーザーに「ListAllMyBuckets」許可が 必要 となるため、上記のとおり別のステートメントを追加しています。

 

まず、上記のとおり、必要に応じて s3 の完全な許可またはバケットごとのドリルダウンアクセスを許可します。

 

Screen_Shot_2020-07-13_at_6.24.24_AM.png

 

続いて、以下のような s3 アクションを拒否するルールを追加していきます。

s3:DeleteBucket,

s3:DeleteBucketPolicy,

s3:DeleteObject,

s3:DeleteObjectVersion

これらのルールには、MultiFactorAuthPresent が存在しない場合 (ブール値が False である場合) 基盤となる s3 アクションを拒否する条件を必ず追加してください。

Screen_Shot_2020-07-13_at_6.26.05_AM.png

 

最後に、このポリシーを作成する前に、前述の例のように、ポリシーエディターで ListAllMyBuckets (バケットに関するコンソール操作) を許可する別のステートメントを追加します。ポリシーは以下のようになります。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "s3:DeleteBucket",
"Resource": "*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "false"
}
}
},
{
"Effect": "Deny",
"Action": "s3:DeleteBucketPolicy",
"Resource": "*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "false"
}
}
},
{
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "false"
}
}
},
{
"Effect": "Deny",
"Action": "s3:DeleteObjectVersion",
"Resource": "*",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}

 

8.  請求ページの表示を許可するが、s3 のすべてのアクションを拒否するポリシー 

このポリシーでは、サブユーザーに監査目的でアカウントの請求情報を閲覧 (財務部門の場合など) することを許可しますが、請求内容の変更に関するアクセスの付与を選択しない限り、請求の変更はできません。また、このサブユーザーがあなたのアカウントで s3 バケットを閲覧したり、s3 関連のアクションを実行したりすることはできません。

 

まず「aws-portal」サービスの ViewBilling 許可から始めます。

Screen_Shot_2020-07-13_at_7.00.22_AM.png

 

次に、以下のように s3 サービスからのすべての s3 アクションを拒否するルールを追加します。

Screen_Shot_2020-07-13_at_7.00.50_AM.png

 

ここでは以下の点に注意します。

  • ここでは、コンソール操作であるにもかかわらず、「ListAllMyBuckets」許可を付与する別のステートメントを追加していません。これは、このポリシーがバケット/オブジェクト操作の領域外であり、請求にのみ関係するからです。
  • このポリシーでは、以下の2つの異なるサービスを使用しています。
  1. aws-portal
  2. s3
  • この許可を実行するには、こちらで示すように、設定ページでルートユーザーが [IAM ユーザーとロールに請求ポータルへのアクセスを許可] を切り替える必要があります。
  • サブユーザーがコンソールにログインすると、最初に「アクセス拒否」の画面が点滅し (バケットのリストアップ処理)、その後自動的に請求ページにリダイレクトされます。

ポリシーは以下のようになります。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "aws-portal:ViewBilling",
"Resource": [
"*"
],
"Condition": {}
},
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"*"
],
"Condition": {}
}
]
}

 

他にご質問がございましたら、リクエストを送信してください