mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-31 15:05:44 -08:00
Translated ['src/README.md', 'src/banners/hacktricks-training.md', 'src/
This commit is contained in:
@@ -1,331 +1,317 @@
|
||||
# AWS - Basic Information
|
||||
# AWS - 基本情報
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Organization Hierarchy
|
||||
## 組織階層
|
||||
|
||||
.png>)
|
||||
|
||||
### Accounts
|
||||
### アカウント
|
||||
|
||||
In AWS there is a **root account,** which is the **parent container for all the accounts** for your **organization**. However, you don't need to use that account to deploy resources, you can create **other accounts to separate different AWS** infrastructures between them.
|
||||
AWSには**ルートアカウント**があり、これは**組織内のすべてのアカウントの親コンテナ**です。しかし、そのアカウントを使用してリソースをデプロイする必要はなく、**異なるAWS**インフラストラクチャを分離するために**他のアカウントを作成することができます**。
|
||||
|
||||
This is very interesting from a **security** point of view, as **one account won't be able to access resources from other account** (except bridges are specifically created), so this way you can create boundaries between deployments.
|
||||
これは**セキュリティ**の観点から非常に興味深いことであり、**1つのアカウントは他のアカウントのリソースにアクセスできません**(特別にブリッジが作成されない限り)。このようにして、デプロイメント間に境界を作成できます。
|
||||
|
||||
Therefore, there are **two types of accounts in an organization** (we are talking about AWS accounts and not User accounts): a single account that is designated as the management account, and one or more member accounts.
|
||||
したがって、**組織内には2種類のアカウントがあります**(AWSアカウントについて話しており、ユーザーアカウントではありません):管理アカウントとして指定された単一のアカウントと、1つ以上のメンバーアカウントです。
|
||||
|
||||
- The **management account (the root account)** is the account that you use to create the organization. From the organization's management account, you can do the following:
|
||||
- **管理アカウント(ルートアカウント)**は、組織を作成するために使用するアカウントです。組織の管理アカウントから、次のことができます:
|
||||
|
||||
- Create accounts in the organization
|
||||
- Invite other existing accounts to the organization
|
||||
- Remove accounts from the organization
|
||||
- Manage invitations
|
||||
- Apply policies to entities (roots, OUs, or accounts) within the organization
|
||||
- Enable integration with supported AWS services to provide service functionality across all of the accounts in the organization.
|
||||
- It's possible to login as the root user using the email and password used to create this root account/organization.
|
||||
- 組織内にアカウントを作成する
|
||||
- 他の既存のアカウントを組織に招待する
|
||||
- 組織からアカウントを削除する
|
||||
- 招待を管理する
|
||||
- 組織内のエンティティ(ルート、OU、またはアカウント)にポリシーを適用する
|
||||
- 組織内のすべてのアカウントにサービス機能を提供するために、サポートされているAWSサービスとの統合を有効にする。
|
||||
- このルートアカウント/組織を作成するために使用されたメールアドレスとパスワードを使用して、ルートユーザーとしてログインすることが可能です。
|
||||
|
||||
The management account has the **responsibilities of a payer account** and is responsible for paying all charges that are accrued by the member accounts. You can't change an organization's management account.
|
||||
|
||||
- **Member accounts** make up all of the rest of the accounts in an organization. An account can be a member of only one organization at a time. You can attach a policy to an account to apply controls to only that one account.
|
||||
- Member accounts **must use a valid email address** and can have a **name**, in general they wont be able to manage the billing (but they might be given access to it).
|
||||
管理アカウントは**支払いアカウントの責任**を持ち、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。
|
||||
|
||||
- **メンバーアカウント**は、組織内の残りのすべてのアカウントを構成します。アカウントは、一度に1つの組織のメンバーであることができます。アカウントにポリシーを添付して、そのアカウントのみに制御を適用することができます。
|
||||
- メンバーアカウントは**有効なメールアドレスを使用する必要があります**。一般的に、**名前**を持つことができ、請求を管理することはできません(ただし、アクセスが与えられる場合があります)。
|
||||
```
|
||||
aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com
|
||||
```
|
||||
### **組織単位**
|
||||
|
||||
### **Organization Units**
|
||||
|
||||
Accounts can be grouped in **Organization Units (OU)**. This way, you can create **policies** for the Organization Unit that are going to be **applied to all the children accounts**. Note that an OU can have other OUs as children.
|
||||
|
||||
アカウントは**組織単位 (OU)**にグループ化できます。この方法で、組織単位に対して**ポリシー**を作成し、それが**すべての子アカウントに適用される**ようにできます。OUは他のOUを子として持つことができることに注意してください。
|
||||
```bash
|
||||
# You can get the root id from aws organizations list-roots
|
||||
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
|
||||
```
|
||||
### サービス制御ポリシー (SCP)
|
||||
|
||||
### Service Control Policy (SCP)
|
||||
**サービス制御ポリシー (SCP)** は、SCPが影響を与えるアカウント内でユーザーとロールが使用できるサービスとアクションを指定するポリシーです。SCPは**IAM** 権限ポリシーに**似ていますが、**権限を付与することはありません**。代わりに、SCPは組織、組織単位 (OU)、またはアカウントの**最大権限**を指定します。SCPを組織のルートまたはOUにアタッチすると、**SCPはメンバーアカウント内のエンティティの権限を制限します**。
|
||||
|
||||
A **service control policy (SCP)** is a policy that specifies the services and actions that users and roles can use in the accounts that the SCP affects. SCPs are **similar to IAM** permissions policies except that they **don't grant any permissions**. Instead, SCPs specify the **maximum permissions** for an organization, organizational unit (OU), or account. When you attach a SCP to your organization root or an OU, the **SCP limits permissions for entities in member accounts**.
|
||||
|
||||
This is the ONLY way that **even the root user can be stopped** from doing something. For example, it could be used to stop users from disabling CloudTrail or deleting backups.\
|
||||
The only way to bypass this is to compromise also the **master account** that configures the SCPs (master account cannot be blocked).
|
||||
これは**ルートユーザーでさえも何かを行うのを止める唯一の方法**です。例えば、CloudTrailを無効にしたり、バックアップを削除したりするのをユーザーに止めるために使用できます。\
|
||||
これを回避する唯一の方法は、SCPを設定する**マスターアカウント**も侵害することです(マスターアカウントはブロックできません)。
|
||||
|
||||
> [!WARNING]
|
||||
> Note that **SCPs only restrict the principals in the account**, so other accounts are not affected. This means having an SCP deny `s3:GetObject` will not stop people from **accessing a public S3 bucket** in your account.
|
||||
> **SCPはアカウント内のプリンシパルのみを制限する**ため、他のアカウントには影響しません。これは、SCPが` s3:GetObject`を拒否しても、あなたのアカウント内の**公開S3バケットにアクセスすることを止めることはない**ことを意味します。
|
||||
|
||||
SCP examples:
|
||||
SCPの例:
|
||||
|
||||
- Deny the root account entirely
|
||||
- Only allow specific regions
|
||||
- Only allow white-listed services
|
||||
- Deny GuardDuty, CloudTrail, and S3 Public Block Access from
|
||||
- ルートアカウントを完全に拒否
|
||||
- 特定のリージョンのみを許可
|
||||
- ホワイトリストに登録されたサービスのみを許可
|
||||
- GuardDuty、CloudTrail、およびS3のパブリックブロックアクセスを無効にすることを拒否
|
||||
|
||||
being disabled
|
||||
- セキュリティ/インシデントレスポンスロールの削除または
|
||||
|
||||
- Deny security/incident response roles from being deleted or
|
||||
変更を拒否。
|
||||
|
||||
modified.
|
||||
- バックアップの削除を拒否。
|
||||
- IAMユーザーとアクセスキーの作成を拒否。
|
||||
|
||||
- Deny backups from being deleted.
|
||||
- Deny creating IAM users and access keys
|
||||
|
||||
Find **JSON examples** in [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
|
||||
**JSONの例**は[https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)で見つけてください。
|
||||
|
||||
### ARN
|
||||
|
||||
**Amazon Resource Name** is the **unique name** every resource inside AWS has, its composed like this:
|
||||
|
||||
**Amazonリソース名**は、AWS内のすべてのリソースが持つ**一意の名前**で、次のように構成されています:
|
||||
```
|
||||
arn:partition:service:region:account-id:resource-type/resource-id
|
||||
arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env
|
||||
```
|
||||
|
||||
Note that there are 4 partitions in AWS but only 3 ways to call them:
|
||||
注意:AWSには4つのパーティションがありますが、それを呼び出す方法は3つだけです:
|
||||
|
||||
- AWS Standard: `aws`
|
||||
- AWS China: `aws-cn`
|
||||
- AWS US public Internet (GovCloud): `aws-us-gov`
|
||||
- AWS Secret (US Classified): `aws`
|
||||
|
||||
## IAM - Identity and Access Management
|
||||
## IAM - アイデンティティとアクセス管理
|
||||
|
||||
IAM is the service that will allow you to manage **Authentication**, **Authorization** and **Access Control** inside your AWS account.
|
||||
IAMは、AWSアカウント内で**認証**、**認可**、および**アクセス制御**を管理することを可能にするサービスです。
|
||||
|
||||
- **Authentication** - Process of defining an identity and the verification of that identity. This process can be subdivided in: Identification and verification.
|
||||
- **Authorization** - Determines what an identity can access within a system once it's been authenticated to it.
|
||||
- **Access Control** - The method and process of how access is granted to a secure resource
|
||||
- **認証** - アイデンティティを定義し、そのアイデンティティを検証するプロセス。このプロセスは、識別と検証に分けることができます。
|
||||
- **認可** - アイデンティティがシステム内でアクセスできるものを決定します。
|
||||
- **アクセス制御** - セキュアなリソースへのアクセスがどのように付与されるかの方法とプロセス
|
||||
|
||||
IAM can be defined by its ability to manage, control and govern authentication, authorization and access control mechanisms of identities to your resources within your AWS account.
|
||||
IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、認可、アクセス制御メカニズムを管理、制御、統治する能力によって定義されます。
|
||||
|
||||
### [AWS account root user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
|
||||
### [AWSアカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) <a href="#id_root" id="id_root"></a>
|
||||
|
||||
When you first create an Amazon Web Services (AWS) account, you begin with a single sign-in identity that has **complete access to all** AWS services and resources in the account. This is the AWS account _**root user**_ and is accessed by signing in with the **email address and password that you used to create the account**.
|
||||
Amazon Web Services (AWS) アカウントを最初に作成すると、アカウント内のすべてのAWSサービスとリソースに**完全にアクセスできる**単一のサインインアイデンティティが作成されます。これがAWSアカウントの_**ルートユーザー**_であり、**アカウントを作成する際に使用したメールアドレスとパスワードでサインインすることでアクセスします**。
|
||||
|
||||
Note that a new **admin user** will have **less permissions that the root user**.
|
||||
新しい**管理者ユーザー**は**ルートユーザーよりも権限が少ない**ことに注意してください。
|
||||
|
||||
From a security point of view, it's recommended to create other users and avoid using this one.
|
||||
セキュリティの観点からは、他のユーザーを作成し、このユーザーの使用を避けることが推奨されます。
|
||||
|
||||
### [IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
|
||||
### [IAMユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) <a href="#id_iam-users" id="id_iam-users"></a>
|
||||
|
||||
An IAM _user_ is an entity that you create in AWS to **represent the person or application** that uses it to **interact with AWS**. A user in AWS consists of a name and credentials (password and up to two access keys).
|
||||
IAM _ユーザー_ は、AWS内で**人またはアプリケーションを表す**ために作成するエンティティです。AWSのユーザーは、名前と資格情報(パスワードと最大2つのアクセスキー)で構成されます。
|
||||
|
||||
When you create an IAM user, you grant it **permissions** by making it a **member of a user group** that has appropriate permission policies attached (recommended), or by **directly attaching policies** to the user.
|
||||
IAMユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーをユーザーに直接添付**することができます(推奨)。
|
||||
|
||||
Users can have **MFA enabled to login** through the console. API tokens of MFA enabled users aren't protected by MFA. If you want to **restrict the access of a users API keys using MFA** you need to indicate in the policy that in order to perform certain actions MFA needs to be present (example [**here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
|
||||
ユーザーは、コンソールを通じて**MFAを有効にしてログイン**できます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して**制限したい場合**は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります(例:[**こちら**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html))。
|
||||
|
||||
#### CLI
|
||||
|
||||
- **Access Key ID**: 20 random uppercase alphanumeric characters like AKHDNAPO86BSHKDIRYT
|
||||
- **Secret access key ID**: 40 random upper and lowercase characters: S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (It's not possible to retrieve lost secret access key IDs).
|
||||
- **アクセスキーID**: 20のランダムな大文字の英数字の文字列(例:AKHDNAPO86BSHKDIRYT)
|
||||
- **シークレットアクセスキーID**: 40のランダムな大文字と小文字の文字列(例:S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU)(失われたシークレットアクセスキーIDを取得することはできません)。
|
||||
|
||||
Whenever you need to **change the Access Key** this is the process you should follow:\
|
||||
アクセスキーを**変更する必要がある場合**は、次のプロセスに従う必要があります:\
|
||||
&#xNAN;_Create a new access key -> Apply the new key to system/application -> mark original one as inactive -> Test and verify new access key is working -> Delete old access key_
|
||||
|
||||
### MFA - Multi Factor Authentication
|
||||
### MFA - 多要素認証
|
||||
|
||||
It's used to **create an additional factor for authentication** in addition to your existing methods, such as password, therefore, creating a multi-factor level of authentication.\
|
||||
You can use a **free virtual application or a physical device**. You can use apps like google authentication for free to activate a MFA in AWS.
|
||||
これは、既存の方法(パスワードなど)に加えて**認証のための追加の要素を作成する**ために使用され、マルチファクターレベルの認証を作成します。\
|
||||
無料の仮想アプリケーションや物理デバイスを使用できます。Google認証などのアプリを無料で使用してAWSでMFAを有効にできます。
|
||||
|
||||
Policies with MFA conditions can be attached to the following:
|
||||
MFA条件を持つポリシーは、以下に添付できます:
|
||||
|
||||
- An IAM user or group
|
||||
- A resource such as an Amazon S3 bucket, Amazon SQS queue, or Amazon SNS topic
|
||||
- The trust policy of an IAM role that can be assumed by a user
|
||||
|
||||
If you want to **access via CLI** a resource that **checks for MFA** you need to call **`GetSessionToken`**. That will give you a token with info about MFA.\
|
||||
Note that **`AssumeRole` credentials don't contain this information**.
|
||||
- IAMユーザーまたはグループ
|
||||
- Amazon S3バケット、Amazon SQSキュー、またはAmazon SNSトピックなどのリソース
|
||||
- ユーザーによって引き受けられるIAMロールの信頼ポリシー
|
||||
|
||||
MFAを**チェックする**リソースに**CLI経由でアクセスしたい場合**は、**`GetSessionToken`**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。\
|
||||
**`AssumeRole`の資格情報にはこの情報が含まれていない**ことに注意してください。
|
||||
```bash
|
||||
aws sts get-session-token --serial-number <arn_device> --token-code <code>
|
||||
```
|
||||
As [**ここに記載されているように**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)、**MFAを使用できない**さまざまなケースがあります。
|
||||
|
||||
As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), there are a lot of different cases where **MFA cannot be used**.
|
||||
### [IAMユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
|
||||
### [IAM user groups](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
IAM [ユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、**複数のユーザーにポリシーを一度に適用する**方法であり、これによりそれらのユーザーの権限を管理しやすくなります。**ロールとグループはグループの一部にはなれません**。
|
||||
|
||||
An IAM [user group](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) is a way to **attach policies to multiple users** at one time, which can make it easier to manage the permissions for those users. **Roles and groups cannot be part of a group**.
|
||||
**ユーザーグループにアイデンティティベースのポリシーを適用する**ことで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取る**ことができます。**ユーザーグループ**を**ポリシー**(リソースベースのポリシーなど)内の**`Principal`**として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。
|
||||
|
||||
You can attach an **identity-based policy to a user group** so that all of the **users** in the user group **receive the policy's permissions**. You **cannot** identify a **user group** as a **`Principal`** in a **policy** (such as a resource-based policy) because groups relate to permissions, not authentication, and principals are authenticated IAM entities.
|
||||
ユーザーグループのいくつかの重要な特徴は次のとおりです:
|
||||
|
||||
Here are some important characteristics of user groups:
|
||||
- ユーザー**グループ**は**多くのユーザーを含むことができ**、**ユーザー**は**複数のグループに属することができ**ます。
|
||||
- **ユーザーグループはネストできません**。ユーザーのみを含むことができ、他のユーザーグループは含められません。
|
||||
- **すべてのユーザーを自動的に含むデフォルトのユーザーグループはAWSアカウントには存在しません**。そのようなユーザーグループを持ちたい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。
|
||||
- AWSアカウント内のIAMリソースの数とサイズ(グループの数や、ユーザーがメンバーになれるグループの数など)は制限されています。詳細については、[IAMおよびAWS STSのクォータ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)を参照してください。
|
||||
|
||||
- A user **group** can **contain many users**, and a **user** can **belong to multiple groups**.
|
||||
- **User groups can't be nested**; they can contain only users, not other user groups.
|
||||
- There is **no default user group that automatically includes all users in the AWS account**. If you want to have a user group like that, you must create it and assign each new user to it.
|
||||
- The number and size of IAM resources in an AWS account, such as the number of groups, and the number of groups that a user can be a member of, are limited. For more information, see [IAM and AWS STS quotas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
|
||||
### [IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
|
||||
### [IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
IAM **ロール**は**ユーザー**に非常に**似ており**、AWS内で**何ができるかを決定する権限ポリシーを持つアイデンティティ**です。しかし、ロールには**関連付けられた資格情報**(パスワードやアクセスキー)が**ありません**。特定の人に一意に関連付けられるのではなく、ロールは**必要な人(十分な権限を持つ人)が引き受けることを意図しています**。IAMユーザーは、特定のタスクのために一時的に異なる権限を取得するためにロールを**引き受けることができます**。ロールは、IAMの代わりに外部アイデンティティプロバイダーを使用してサインインする[**フェデレーテッドユーザー**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)に**割り当てることができます**。
|
||||
|
||||
An IAM **role** is very **similar** to a **user**, in that it is an **identity with permission policies that determine what** it can and cannot do in AWS. However, a role **does not have any credentials** (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be **assumable by anyone who needs it (and have enough perms)**. An **IAM user can assume a role to temporarily** take on different permissions for a specific task. A role can be **assigned to a** [**federated user**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html) who signs in by using an external identity provider instead of IAM.
|
||||
IAMロールは**2種類のポリシー**で構成されています:**信頼ポリシー**(空であってはならず、**誰がロールを引き受けることができるかを定義**)と、**権限ポリシー**(空であってはならず、**何にアクセスできるかを定義**)。
|
||||
|
||||
An IAM role consists of **two types of policies**: A **trust policy**, which cannot be empty, defining **who can assume** the role, and a **permissions policy**, which cannot be empty, defining **what it can access**.
|
||||
#### AWSセキュリティトークンサービス(STS)
|
||||
|
||||
#### AWS Security Token Service (STS)
|
||||
AWSセキュリティトークンサービス(STS)は、**一時的で制限された権限の資格情報を発行する**ためのウェブサービスです。これは特に次の目的に特化しています:
|
||||
|
||||
AWS Security Token Service (STS) is a web service that facilitates the **issuance of temporary, limited-privilege credentials**. It is specifically tailored for:
|
||||
### [IAMにおける一時的な資格情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
|
||||
### [Temporary credentials in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
|
||||
**一時的な資格情報は主にIAMロールと共に使用されます**が、他の用途もあります。標準のIAMユーザーよりも制限された権限セットを持つ一時的な資格情報を要求できます。これにより、**より制限された資格情報によって許可されていないタスクを誤って実行することを防ぎます**。一時的な資格情報の利点は、設定された期間の後に自動的に期限切れになることです。資格情報が有効な期間を制御できます。
|
||||
|
||||
**Temporary credentials are primarily used with IAM roles**, but there are also other uses. You can request temporary credentials that have a more restricted set of permissions than your standard IAM user. This **prevents** you from **accidentally performing tasks that are not permitted** by the more restricted credentials. A benefit of temporary credentials is that they expire automatically after a set period of time. You have control over the duration that the credentials are valid.
|
||||
### ポリシー
|
||||
|
||||
### Policies
|
||||
#### ポリシー権限
|
||||
|
||||
#### Policy Permissions
|
||||
権限を割り当てるために使用されます。2種類あります:
|
||||
|
||||
Are used to assign permissions. There are 2 types:
|
||||
|
||||
- AWS managed policies (preconfigured by AWS)
|
||||
- Customer Managed Policies: Configured by you. You can create policies based on AWS managed policies (modifying one of them and creating your own), using the policy generator (a GUI view that helps you granting and denying permissions) or writing your own..
|
||||
|
||||
By **default access** is **denied**, access will be granted if an explicit role has been specified.\
|
||||
If **single "Deny" exist, it will override the "Allow"**, except for requests that use the AWS account's root security credentials (which are allowed by default).
|
||||
- AWS管理ポリシー(AWSによって事前構成されたもの)
|
||||
- カスタマー管理ポリシー:あなたが構成したもの。AWS管理ポリシーに基づいてポリシーを作成できます(そのうちの1つを修正して独自のものを作成する)、ポリシージェネレーターを使用する(権限を付与および拒否するのを助けるGUIビュー)または独自に作成することができます。
|
||||
|
||||
**デフォルトのアクセスは** **拒否されます**。明示的なロールが指定された場合にのみアクセスが許可されます。\
|
||||
**単一の「拒否」が存在する場合、それは「許可」を上書きします**。AWSアカウントのルートセキュリティ資格情報を使用するリクエスト(デフォルトで許可されている)は除きます。
|
||||
```javascript
|
||||
{
|
||||
"Version": "2012-10-17", //Version of the policy
|
||||
"Statement": [ //Main element, there can be more than 1 entry in this array
|
||||
{
|
||||
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
|
||||
"Effect": "Allow", //Allow or deny
|
||||
"Action": [ //Actions that will be allowed or denied
|
||||
"ec2:AttachVolume",
|
||||
"ec2:DetachVolume"
|
||||
],
|
||||
"Resource": [ //Resource the action and effect will be applied to
|
||||
"arn:aws:ec2:*:*:volume/*",
|
||||
"arn:aws:ec2:*:*:instance/*"
|
||||
],
|
||||
"Condition": { //Optional element that allow to control when the permission will be effective
|
||||
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
|
||||
}
|
||||
}
|
||||
]
|
||||
"Version": "2012-10-17", //Version of the policy
|
||||
"Statement": [ //Main element, there can be more than 1 entry in this array
|
||||
{
|
||||
"Sid": "Stmt32894y234276923" //Unique identifier (optional)
|
||||
"Effect": "Allow", //Allow or deny
|
||||
"Action": [ //Actions that will be allowed or denied
|
||||
"ec2:AttachVolume",
|
||||
"ec2:DetachVolume"
|
||||
],
|
||||
"Resource": [ //Resource the action and effect will be applied to
|
||||
"arn:aws:ec2:*:*:volume/*",
|
||||
"arn:aws:ec2:*:*:instance/*"
|
||||
],
|
||||
"Condition": { //Optional element that allow to control when the permission will be effective
|
||||
"ArnEquals": {"ec2:SourceInstanceARN": "arn:aws:ec2:*:*:instance/instance-id"}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
The [グローバルフィールドは、任意のサービスで条件に使用できるものがここに文書化されています](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount)。\
|
||||
[特定のフィールドは、サービスごとに条件に使用できるものがここに文書化されています](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html)。
|
||||
|
||||
The [global fields that can be used for conditions in any service are documented here](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceaccount).\
|
||||
The [specific fields that can be used for conditions per service are documented here](https://docs.aws.amazon.com/service-authorization/latest/reference/reference_policies_actions-resources-contextkeys.html).
|
||||
#### インラインポリシー
|
||||
|
||||
#### Inline Policies
|
||||
この種のポリシーは、**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰かが使用できるようにポリシーリストには表示されません。\
|
||||
インラインポリシーは、ポリシーとそれが適用されるアイデンティティとの間に**厳密な1対1の関係を維持したい場合**に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。
|
||||
|
||||
This kind of policies are **directly assigned** to a user, group or role. Then, they do not appear in the Policies list as any other one can use them.\
|
||||
Inline policies are useful if you want to **maintain a strict one-to-one relationship between a policy and the identity** that it's applied to. For example, you want to be sure that the permissions in a policy are not inadvertently assigned to an identity other than the one they're intended for. When you use an inline policy, the permissions in the policy cannot be inadvertently attached to the wrong identity. In addition, when you use the AWS Management Console to delete that identity, the policies embedded in the identity are deleted as well. That's because they are part of the principal entity.
|
||||
#### リソースバケットポリシー
|
||||
|
||||
#### Resource Bucket Policies
|
||||
これらは**リソース**に定義できる**ポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。
|
||||
|
||||
These are **policies** that can be defined in **resources**. **Not all resources of AWS supports them**.
|
||||
もし主がそれらに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、彼らは許可されます。
|
||||
|
||||
If a principal does not have an explicit deny on them, and a resource policy grants them access, then they are allowed.
|
||||
### IAMバウンダリー
|
||||
|
||||
### IAM Boundaries
|
||||
IAMバウンダリーは、**ユーザーまたはロールがアクセスできる権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、彼がそれらを使用しようとすると操作は**失敗**します。
|
||||
|
||||
IAM boundaries can be used to **limit the permissions a user or role should have access to**. This way, even if a different set of permissions are granted to the user by a **different policy** the operation will **fail** if he tries to use them.
|
||||
バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼がS·バケットを読むことしかできないと示している場合、それが彼ができる最大のことです。
|
||||
|
||||
A boundary is just a policy attached to a user which **indicates the maximum level of permissions the user or role can have**. So, **even if the user has Administrator access**, if the boundary indicates he can only read S· buckets, that's the maximum he can do.
|
||||
**これ**、**SCP**、および**最小特権の原則に従うこと**は、ユーザーが必要な権限以上の権限を持たないように制御する方法です。
|
||||
|
||||
**This**, **SCPs** and **following the least privilege** principle are the ways to control that users doesn't have more permissions than the ones he needs.
|
||||
### セッションポリシー
|
||||
|
||||
### Session Policies
|
||||
|
||||
A session policy is a **policy set when a role is assumed** somehow. This will be like an **IAM boundary for that session**: This means that the session policy doesn't grant permissions but **restrict them to the ones indicated in the policy** (being the max permissions the ones the role has).
|
||||
|
||||
This is useful for **security meassures**: When an admin is going to assume a very privileged role he could restrict the permission to only the ones indicated in the session policy in case the session gets compromised.
|
||||
セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションの**IAMバウンダリーのようなもの**になります:これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**(最大の権限はロールが持つものです)。
|
||||
|
||||
これは**セキュリティ対策**に役立ちます:管理者が非常に特権のあるロールを引き受ける場合、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。
|
||||
```bash
|
||||
aws sts assume-role \
|
||||
--role-arn <value> \
|
||||
--role-session-name <value> \
|
||||
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
|
||||
[--policy <file://policy.json>]
|
||||
--role-arn <value> \
|
||||
--role-session-name <value> \
|
||||
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
|
||||
[--policy <file://policy.json>]
|
||||
```
|
||||
注意してください、デフォルトでは**AWSはセッションにセッションポリシーを追加する可能性があります**。これは第三者の理由によって生成されるセッションに対してです。例えば、[認証されていないCognitoの仮定されたロール](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles)では、デフォルト(強化された認証を使用)で、AWSは**セッションポリシーを持つセッション資格情報**を生成し、そのセッションがアクセスできるサービスを[**次のリストに制限します**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services)。
|
||||
|
||||
Note that by default **AWS might add session policies to sessions** that are going to be generated because of third reasons. For example, in [unauthenticated cognito assumed roles](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles) by default (using enhanced authentication), AWS will generate **session credentials with a session policy** that limits the services that session can access [**to the following list**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
|
||||
したがって、ある時点で「...セッションポリシーが許可していないため...」というエラーに直面した場合、ロールがアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在する**ためです。
|
||||
|
||||
Therefore, if at some point you face the error "... because no session policy allows the ...", and the role has access to perform the action, it's because **there is a session policy preventing it**.
|
||||
### アイデンティティフェデレーション
|
||||
|
||||
### Identity Federation
|
||||
アイデンティティフェデレーションは、**AWSに外部のアイデンティティプロバイダーからのユーザー**がAWSリソースに安全にアクセスできるようにし、正当なIAMユーザーアカウントのAWSユーザー資格情報を提供する必要がありません。\
|
||||
アイデンティティプロバイダーの例としては、独自の企業の**Microsoft Active Directory**(**SAML**経由)や**OpenID**サービス(**Google**など)があります。フェデレーテッドアクセスにより、その中のユーザーがAWSにアクセスできるようになります。
|
||||
|
||||
Identity federation **allows users from identity providers which are external** to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account.\
|
||||
An example of an identity provider can be your own corporate **Microsoft Active Directory** (via **SAML**) or **OpenID** services (like **Google**). Federated access will then allow the users within it to access AWS.
|
||||
この信頼を構成するために、**IAMアイデンティティプロバイダー(SAMLまたはOAuth)が生成され**、**他のプラットフォームを信頼する**ことになります。次に、少なくとも1つの**IAMロールがアイデンティティプロバイダーに(信頼される)割り当てられます**。信頼されたプラットフォームのユーザーがAWSにアクセスすると、彼は前述のロールとしてアクセスします。
|
||||
|
||||
To configure this trust, an **IAM Identity Provider is generated (SAML or OAuth)** that will **trust** the **other platform**. Then, at least one **IAM role is assigned (trusting) to the Identity Provider**. If a user from the trusted platform access AWS, he will be accessing as the mentioned role.
|
||||
|
||||
However, you will usually want to give a **different role depending on the group of the user** in the third party platform. Then, several **IAM roles can trust** the third party Identity Provider and the third party platform will be the one allowing users to assume one role or the other.
|
||||
ただし、通常は**サードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたい**と思うでしょう。したがって、複数の**IAMロールがサードパーティのアイデンティティプロバイダーを信頼し**、サードパーティプラットフォームがユーザーにどのロールを引き受けるかを許可します。
|
||||
|
||||
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### IAM Identity Center
|
||||
### IAMアイデンティティセンター
|
||||
|
||||
AWS IAM Identity Center (successor to AWS Single Sign-On) expands the capabilities of AWS Identity and Access Management (IAM) to provide a **central plac**e that brings together **administration of users and their access to AWS** accounts and cloud applications.
|
||||
AWS IAMアイデンティティセンター(AWSシングルサインオンの後継)は、AWSアイデンティティおよびアクセス管理(IAM)の機能を拡張し、**ユーザーとそのAWSアカウントおよびクラウドアプリケーションへのアクセスの管理を統合する**ための**中央の場所**を提供します。
|
||||
|
||||
The login domain is going to be something like `<user_input>.awsapps.com`.
|
||||
ログインドメインは`<user_input>.awsapps.com`のようになります。
|
||||
|
||||
To login users, there are 3 identity sources that can be used:
|
||||
ユーザーをログインさせるために、使用できる3つのアイデンティティソースがあります:
|
||||
|
||||
- Identity Center Directory: Regular AWS users
|
||||
- Active Directory: Supports different connectors
|
||||
- External Identity Provider: All users and groups come from an external Identity Provider (IdP)
|
||||
- アイデンティティセンターディレクトリ:通常のAWSユーザー
|
||||
- アクティブディレクトリ:異なるコネクタをサポート
|
||||
- 外部アイデンティティプロバイダー:すべてのユーザーとグループは外部アイデンティティプロバイダー(IdP)から来ます
|
||||
|
||||
<figure><img src="../../../images/image (279).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
In the simplest case of Identity Center directory, the **Identity Center will have a list of users & groups** and will be able to **assign policies** to them to **any of the accounts** of the organization.
|
||||
アイデンティティセンターディレクトリの最も単純なケースでは、**アイデンティティセンターはユーザーとグループのリストを持ち**、それらに**ポリシーを割り当てる**ことができ、**組織の任意のアカウント**に対して行います。
|
||||
|
||||
In order to give access to a Identity Center user/group to an account a **SAML Identity Provider trusting the Identity Center will be created**, and a **role trusting the Identity Provider with the indicated policies will be created** in the destination account.
|
||||
アイデンティティセンターのユーザー/グループにアカウントへのアクセスを与えるために、**アイデンティティセンターを信頼するSAMLアイデンティティプロバイダーが作成され**、**指定されたポリシーを持つアイデンティティプロバイダーを信頼するロールが宛先アカウントに作成されます**。
|
||||
|
||||
#### AwsSSOInlinePolicy
|
||||
|
||||
It's possible to **give permissions via inline policies to roles created via IAM Identity Center**. The roles created in the accounts being given **inline policies in AWS Identity Center** will have these permissions in an inline policy called **`AwsSSOInlinePolicy`**.
|
||||
**IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを介して権限を与えることが可能です**。AWSアイデンティティセンターでインラインポリシーを持つアカウントで作成されたロールは、**`AwsSSOInlinePolicy`**というインラインポリシーでこれらの権限を持ちます。
|
||||
|
||||
Therefore, even if you see 2 roles with an inline policy called **`AwsSSOInlinePolicy`**, it **doesn't mean it has the same permissions**.
|
||||
したがって、**`AwsSSOInlinePolicy`**というインラインポリシーを持つ2つのロールが表示されても、**同じ権限を持っているわけではありません**。
|
||||
|
||||
### Cross Account Trusts and Roles
|
||||
### クロスアカウントの信頼とロール
|
||||
|
||||
**A user** (trusting) can create a Cross Account Role with some policies and then, **allow another user** (trusted) to **access his account** but only **having the access indicated in the new role policies**. To create this, just create a new Role and select Cross Account Role. Roles for Cross-Account Access offers two options. Providing access between AWS accounts that you own, and providing access between an account that you own and a third party AWS account.\
|
||||
It's recommended to **specify the user who is trusted and not put some generic thing** because if not, other authenticated users like federated users will be able to also abuse this trust.
|
||||
**ユーザー**(信頼する側)は、いくつかのポリシーを持つクロスアカウントロールを作成し、**別のユーザー**(信頼される側)に**自分のアカウントにアクセスすることを許可できますが、**新しいロールポリシーで示されたアクセスのみを持つことになります**。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。\
|
||||
信頼されるユーザーを**特定し、一般的なものを指定しないことをお勧めします**。そうしないと、フェデレーテッドユーザーのような他の認証されたユーザーもこの信頼を悪用できる可能性があります。
|
||||
|
||||
### AWS Simple AD
|
||||
|
||||
Not supported:
|
||||
サポートされていない:
|
||||
|
||||
- Trust Relations
|
||||
- AD Admin Center
|
||||
- Full PS API support
|
||||
- AD Recycle Bin
|
||||
- Group Managed Service Accounts
|
||||
- Schema Extensions
|
||||
- No Direct access to OS or Instances
|
||||
- 信頼関係
|
||||
- AD管理センター
|
||||
- 完全なPS APIサポート
|
||||
- ADリサイクルビン
|
||||
- グループ管理サービスアカウント
|
||||
- スキーマ拡張
|
||||
- OSまたはインスタンスへの直接アクセスなし
|
||||
|
||||
#### Web Federation or OpenID Authentication
|
||||
#### WebフェデレーションまたはOpenID認証
|
||||
|
||||
The app uses the AssumeRoleWithWebIdentity to create temporary credentials. However, this doesn't grant access to the AWS console, just access to resources within AWS.
|
||||
アプリはAssumeRoleWithWebIdentityを使用して一時的な資格情報を作成します。ただし、これによりAWSコンソールへのアクセスは付与されず、AWS内のリソースへのアクセスのみが許可されます。
|
||||
|
||||
### Other IAM options
|
||||
### その他のIAMオプション
|
||||
|
||||
- You can **set a password policy setting** options like minimum length and password requirements.
|
||||
- You can **download "Credential Report"** with information about current credentials (like user creation time, is password enabled...). You can generate a credential report as often as once every **four hours**.
|
||||
- **パスワードポリシー設定**を設定することができ、最小長やパスワード要件などのオプションがあります。
|
||||
- **「資格情報レポート」をダウンロード**して、現在の資格情報に関する情報(ユーザー作成時間、パスワードが有効かどうかなど)を取得できます。資格情報レポートは、最長で**4時間ごと**に生成できます。
|
||||
|
||||
AWS Identity and Access Management (IAM) provides **fine-grained access control** across all of AWS. With IAM, you can specify **who can access which services and resources**, and under which conditions. With IAM policies, you manage permissions to your workforce and systems to **ensure least-privilege permissions**.
|
||||
AWSアイデンティティおよびアクセス管理(IAM)は、AWS全体で**細かいアクセス制御**を提供します。IAMを使用すると、**誰がどのサービスやリソースにアクセスできるか、どの条件下でアクセスできるかを指定できます**。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保します**。
|
||||
|
||||
### IAM ID Prefixes
|
||||
### IAM IDプレフィックス
|
||||
|
||||
In [**this page**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids) you can find the **IAM ID prefixe**d of keys depending on their nature:
|
||||
[**このページ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids)では、キーの性質に応じた**IAM IDプレフィックス**を見つけることができます:
|
||||
|
||||
| ABIA | [AWS STS service bearer token](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
| ABIA | [AWS STSサービスベアラートークン](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) |
|
||||
| ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| ACCA | Context-specific credential |
|
||||
| AGPA | User group |
|
||||
| AIDA | IAM user |
|
||||
| AIPA | Amazon EC2 instance profile |
|
||||
| AKIA | Access key |
|
||||
| ANPA | Managed policy |
|
||||
| ANVA | Version in a managed policy |
|
||||
| APKA | Public key |
|
||||
| AROA | Role |
|
||||
| ASCA | Certificate |
|
||||
| ASIA | [Temporary (AWS STS) access key IDs](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) use this prefix, but are unique only in combination with the secret access key and the session token. |
|
||||
| ACCA | コンテキスト固有の資格情報 |
|
||||
| AGPA | ユーザーグループ |
|
||||
| AIDA | IAMユーザー |
|
||||
| AIPA | Amazon EC2インスタンスプロファイル |
|
||||
| AKIA | アクセスキー |
|
||||
| ANPA | 管理ポリシー |
|
||||
| ANVA | 管理ポリシーのバージョン |
|
||||
| APKA | 公開鍵 |
|
||||
| AROA | ロール |
|
||||
| ASCA | 証明書 |
|
||||
| ASIA | [一時的(AWS STS)アクセスキーID](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)はこのプレフィックスを使用しますが、秘密アクセスキーとセッショントークンと組み合わせた場合にのみ一意です。 |
|
||||
|
||||
### Recommended permissions to audit accounts
|
||||
### アカウントを監査するための推奨権限
|
||||
|
||||
The following privileges grant various read access of metadata:
|
||||
以下の特権は、メタデータのさまざまな読み取りアクセスを付与します:
|
||||
|
||||
- `arn:aws:iam::aws:policy/SecurityAudit`
|
||||
- `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess`
|
||||
@@ -336,14 +322,13 @@ The following privileges grant various read access of metadata:
|
||||
- `directconnect:DescribeConnections`
|
||||
- `dynamodb:ListTables`
|
||||
|
||||
## Misc
|
||||
## その他
|
||||
|
||||
### CLI Authentication
|
||||
|
||||
In order for a regular user authenticate to AWS via CLI you need to have **local credentials**. By default you can configure them **manually** in `~/.aws/credentials` or by **running** `aws configure`.\
|
||||
In that file you can have more than one profile, if **no profile** is specified using the **aws cli**, the one called **`[default]`** in that file will be used.\
|
||||
Example of credentials file with more than 1 profile:
|
||||
### CLI認証
|
||||
|
||||
通常のユーザーがCLIを介してAWSに認証するためには、**ローカル資格情報**が必要です。デフォルトでは、`~/.aws/credentials`に**手動で**設定するか、**`aws configure`を実行することで**構成できます。\
|
||||
そのファイルには複数のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**そのファイルの`[default]`**と呼ばれるものが使用されます。\
|
||||
複数のプロファイルを持つ資格情報ファイルの例:
|
||||
```
|
||||
[default]
|
||||
aws_access_key_id = AKIA5ZDCUJHF83HDTYUT
|
||||
@@ -354,12 +339,10 @@ aws_access_key_id = AKIA8YDCu7TGTR356SHYT
|
||||
aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7
|
||||
region = eu-west-2
|
||||
```
|
||||
もし**異なるAWSアカウント**にアクセスする必要があり、あなたのプロファイルが**それらのアカウント内でロールを引き受ける**アクセスを与えられている場合、毎回手動でSTSを呼び出す必要はありません(`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`)し、資格情報を設定する必要もありません。
|
||||
|
||||
If you need to access **different AWS accounts** and your profile was given access to **assume a role inside those accounts**, you don't need to call manually STS every time (`aws sts assume-role --role-arn <role-arn> --role-session-name sessname`) and configure the credentials.
|
||||
|
||||
You can use the `~/.aws/config` file to[ **indicate which roles to assume**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html), and then use the `--profile` param as usual (the `assume-role` will be performed in a transparent way for the user).\
|
||||
A config file example:
|
||||
|
||||
`~/.aws/config`ファイルを使用して[ **引き受けるロールを指定する**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)ことができ、その後は通常通り`--profile`パラメータを使用できます(`assume-role`はユーザーにとって透過的に実行されます)。\
|
||||
設定ファイルの例:
|
||||
```
|
||||
[profile acc2]
|
||||
region=eu-west-2
|
||||
@@ -368,23 +351,16 @@ role_session_name = <session_name>
|
||||
source_profile = <profile_with_assume_role>
|
||||
sts_regional_endpoints = regional
|
||||
```
|
||||
|
||||
With this config file you can then use aws cli like:
|
||||
|
||||
この設定ファイルを使用すると、aws cliを次のように使用できます:
|
||||
```
|
||||
aws --profile acc2 ...
|
||||
```
|
||||
もしあなたが**ブラウザ**用の**類似**のものを探しているなら、**拡張機能**[**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en)をチェックできます。
|
||||
|
||||
If you are looking for something **similar** to this but for the **browser** you can check the **extension** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en).
|
||||
|
||||
## References
|
||||
## 参考文献
|
||||
|
||||
- [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
|
||||
- [https://aws.amazon.com/iam/](https://aws.amazon.com/iam/)
|
||||
- [https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user