# AWS - 基本情報 {{#include ../../../banners/hacktricks-training.md}} ## 組織階層 ![](<../../../images/image (151).png>) ### アカウント AWSには**ルートアカウント**があり、これは**組織内のすべてのアカウントの親コンテナ**です。しかし、そのアカウントを使用してリソースをデプロイする必要はなく、**異なるAWS**インフラストラクチャを分離するために**他のアカウントを作成することができます**。 これは**セキュリティ**の観点から非常に興味深いことであり、**1つのアカウントは他のアカウントのリソースにアクセスできません**（特別にブリッジが作成されていない限り）。このようにして、デプロイメント間に境界を作成できます。 したがって、**組織内には2種類のアカウントがあります**（AWSアカウントについて話しており、ユーザーアカウントではありません）：管理アカウントとして指定された単一のアカウントと、1つ以上のメンバーアカウントです。 - **管理アカウント（ルートアカウント）**は、組織を作成するために使用するアカウントです。組織の管理アカウントから、次のことができます： - 組織内にアカウントを作成する - 他の既存のアカウントを組織に招待する - 組織からアカウントを削除する - 招待状を管理する - 組織内のエンティティ（ルート、OU、またはアカウント）にポリシーを適用する - 組織内のすべてのアカウントにサービス機能を提供するために、サポートされているAWSサービスとの統合を有効にする。 - このルートアカウント/組織を作成するために使用されたメールアドレスとパスワードを使用して、ルートユーザーとしてログインすることが可能です。 管理アカウントは**支払いアカウントの責任**を持ち、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。 - **メンバーアカウント**は、組織内の残りのすべてのアカウントを構成します。アカウントは、一度に1つの組織のメンバーであることができます。アカウントにポリシーを添付して、そのアカウントのみに制御を適用することができます。 - メンバーアカウントは**有効なメールアドレスを使用する必要があり**、**名前**を持つことができます。一般的に、請求を管理することはできませんが、アクセスが与えられることがあります。 ``` aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com ``` ### **組織単位** アカウントは**組織単位 (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 ``` ### Service Control Policy (SCP) **サービスコントロールポリシー (SCP)** は、SCPが影響を与えるアカウント内でユーザーとロールが使用できるサービスとアクションを指定するポリシーです。SCPは**IAM**権限ポリシーに似ていますが、**権限を付与することはありません**。代わりに、SCPは組織、組織単位 (OU)、またはアカウントの**最大権限**を指定します。SCPを組織のルートまたはOUにアタッチすると、**メンバーアカウント内のエンティティの権限が制限されます**。 これは**ルートユーザーでさえ何かを行うのを止める唯一の方法**です。例えば、CloudTrailを無効にしたり、バックアップを削除したりするのを防ぐために使用できます。\ これを回避する唯一の方法は、SCPを設定する**マスターアカウント**も侵害することです（マスターアカウントはブロックできません）。 > [!WARNING] > **SCPはアカウント内のプリンシパルのみを制限**するため、他のアカウントには影響しません。これは、SCPが`s3:GetObject`を拒否しても、あなたのアカウント内の**公開S3バケットにアクセスする人を止めることはない**ことを意味します。 SCPの例： - ルートアカウントを完全に拒否 - 特定のリージョンのみを許可 - ホワイトリストに登録されたサービスのみを許可 - GuardDuty、CloudTrail、およびS3のパブリックブロックアクセスを無効にすることを拒否 - セキュリティ/インシデントレスポンスロールの削除または 変更を拒否。 - バックアップの削除を拒否。 - IAMユーザーとアクセスキーの作成を拒否 **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)で見つけてください。 ### Resource Control Policy (RCP) **リソースコントロールポリシー (RCP)** は、**AWS組織内のリソースに対する最大権限を定義するポリシー**です。RCPは構文においてIAMポリシーに似ていますが、**権限を付与しません**—他のポリシーによってリソースに適用できる権限を制限するだけです。RCPを組織のルート、組織単位 (OU)、またはアカウントにアタッチすると、RCPは影響を受ける範囲内のすべてのリソースに対するリソース権限を制限します。 これは**リソースが事前定義されたアクセスレベルを超えないことを保証する唯一の方法**です—たとえアイデンティティベースまたはリソースベースのポリシーが過剰に許可されていても。これらの制限を回避する唯一の方法は、組織の管理アカウントによって設定されたRCPを変更することです。 > [!WARNING] > RCPはリソースが持つことができる権限のみを制限します。プリンシパルが何をできるかを直接制御するわけではありません。例えば、RCPがS3バケットへの外部アクセスを拒否する場合、それはバケットの権限が設定された制限を超えるアクションを許可しないことを保証します—たとえリソースベースのポリシーが誤って設定されていても。 RCPの例： - S3バケットを制限し、あなたの組織内のプリンシパルのみがアクセスできるようにする - KMSキーの使用を信頼された組織アカウントからの操作のみを許可するように制限 - SQSキューの権限を制限し、不正な変更を防ぐ - Secrets Managerのシークレットにアクセス境界を強制し、機密データを保護する 例は[AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)で見つけてください。 ### ARN **Amazon Resource Name**は、AWS内のすべてのリソースが持つ**ユニークな名前**で、次のように構成されています： ``` arn:partition:service:region:account-id:resource-type/resource-id arn:aws:elasticbeanstalk:us-west-1:123456789098:environment/App/Env ``` 注意：AWSには4つのパーティションがありますが、それを呼び出す方法は3つだけです： - AWS Standard: `aws` - AWS China: `aws-cn` - AWS US public Internet (GovCloud): `aws-us-gov` - AWS Secret (US Classified): `aws` ## IAM - アイデンティティとアクセス管理 IAMは、AWSアカウント内での**認証**、**承認**、および**アクセス制御**を管理することを可能にするサービスです。 - **認証** - アイデンティティを定義し、そのアイデンティティを検証するプロセス。このプロセスは、識別と検証に細分化できます。 - **承認** - アイデンティティがシステム内でアクセスできるものを決定します。 - **アクセス制御** - セキュアなリソースへのアクセスがどのように付与されるかの方法とプロセス IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、承認、およびアクセス制御メカニズムを管理、制御、統治する能力によって定義されます。 ### [AWSアカウントのルートユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html) Amazon Web Services (AWS) アカウントを最初に作成すると、アカウント内のすべてのAWSサービスとリソースに**完全にアクセスできる**単一のサインインアイデンティティが与えられます。これがAWSアカウントの_**ルートユーザー**_であり、**アカウントを作成する際に使用したメールアドレスとパスワードでサインインすることでアクセスします**。 新しい**管理者ユーザー**は**ルートユーザーよりも権限が少ない**ことに注意してください。 セキュリティの観点からは、他のユーザーを作成し、このユーザーの使用を避けることが推奨されます。 ### [IAMユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) IAM _ユーザー_ は、AWS内で**人またはアプリケーション**を**AWSと対話させるために使用する**エンティティです。AWSのユーザーは、名前と資格情報（パスワードと最大2つのアクセスキー）で構成されます。 IAMユーザーを作成すると、適切な権限ポリシーが添付された**ユーザーグループのメンバー**にすることで**権限**を付与するか、**ポリシーを直接ユーザーに添付**することができます（推奨）。 ユーザーは、コンソールを通じて**MFAを有効にしてログイン**できます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して**制限したい場合**は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（例 [**こちら**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)）。 #### CLI - **アクセスキーID**: 20のランダムな大文字の英数字の文字列（例：AKHDNAPO86BSHKDIRYT） - **シークレットアクセスキーID**: 40のランダムな大文字と小文字の文字列（例：S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU）（失われたシークレットアクセスキーIDを取得することはできません）。 アクセスキーを**変更する必要がある場合**は、次のプロセスに従う必要があります：\ _新しいアクセスキーを作成 -> 新しいキーをシステム/アプリケーションに適用 -> 元のキーを非アクティブとしてマーク -> 新しいアクセスキーが機能していることをテストおよび確認 -> 古いアクセスキーを削除_ ### MFA - 多要素認証 これは、既存の方法（パスワードなど）に加えて**認証のための追加の要素を作成する**ために使用され、マルチファクターレベルの認証を作成します。\ 無料の仮想アプリケーションや物理デバイスを使用できます。AWSでMFAを有効にするために、Google認証などのアプリを無料で使用できます。 MFA条件を持つポリシーは、以下に添付できます： - IAMユーザーまたはグループ - Amazon S3バケット、Amazon SQSキュー、またはAmazon SNSトピックなどのリソース - ユーザーによって引き受けられるIAMロールの信頼ポリシー MFAを**チェックする**リソースに**CLI経由でアクセスしたい場合**は、**`GetSessionToken`**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。\ 注意：**`AssumeRole`の資格情報にはこの情報は含まれていません**。 ```bash aws sts get-session-token --serial-number --token-code ``` 以下の内容は、AWSに関する基本情報を提供します。 As [**stated here**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)、**MFAが使用できない**さまざまなケースがあります。 ### [IAMユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) IAM [ユーザーグループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、**複数のユーザーにポリシーを一度にアタッチする**方法であり、これによりそれらのユーザーの権限を管理しやすくなります。**ロールとグループはグループの一部にはなれません**。 **ユーザーグループにアイデンティティベースのポリシーをアタッチ**することで、ユーザーグループ内のすべての**ユーザー**が**ポリシーの権限を受け取ります**。**ユーザーグループ**を**ポリシー**（リソースベースのポリシーなど）内の**`Principal`**として特定することは**できません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。 ユーザーグループの重要な特徴は以下の通りです： - ユーザー**グループ**は**多くのユーザーを含むことができ**、**ユーザー**は**複数のグループに属することができます**。 - **ユーザーグループはネストできません**。ユーザーのみを含むことができ、他のユーザーグループは含められません。 - **AWSアカウント内のすべてのユーザーを自動的に含むデフォルトのユーザーグループはありません**。そのようなユーザーグループを持ちたい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。 - AWSアカウント内のIAMリソースの数とサイズ（グループの数や、ユーザーがメンバーになれるグループの数など）は制限されています。詳細については、[IAMおよびAWS STSのクォータ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html)を参照してください。 ### [IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) IAM **ロール**は、**ユーザー**と非常に**似ています**。それは、AWSで何ができるかを決定する**権限ポリシーを持つアイデンティティ**です。しかし、ロールには**関連付けられた資格情報**（パスワードやアクセスキー）が**ありません**。特定の人に一意に関連付けられるのではなく、ロールは**必要な人（十分な権限を持つ人）が引き受けることを意図しています**。**IAMユーザーはロールを引き受けて、一時的に**特定のタスクのために異なる権限を持つことができます。ロールは、IAMではなく外部アイデンティティプロバイダーを使用してサインインする[**フェデレーテッドユーザー**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)に**割り当てることができます**。 IAMロールは、**2種類のポリシー**で構成されています：**信頼ポリシー**（空であってはならず、**誰がロールを引き受けることができるかを定義**）と、**権限ポリシー**（空であってはならず、**何にアクセスできるかを定義**）。 #### AWSセキュリティトークンサービス（STS） AWSセキュリティトークンサービス（STS）は、**一時的で制限された権限の資格情報を発行する**ためのウェブサービスです。これは特に以下の目的に特化しています： ### [IAMにおける一時的な資格情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) **一時的な資格情報は主にIAMロールと共に使用されます**が、他の用途もあります。標準のIAMユーザーよりも制限された権限セットを持つ一時的な資格情報をリクエストできます。これにより、**より制限された資格情報によって許可されていないタスクを誤って実行することを防ぎます**。一時的な資格情報の利点は、設定された期間の後に自動的に期限切れになることです。資格情報が有効な期間を制御できます。 ### ポリシー #### ポリシー権限 権限を割り当てるために使用されます。2種類あります： - 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"} } } ] } ``` [グローバルフィールドは、任意のサービスで条件に使用できることが文書化されています](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)。 #### インラインポリシー この種のポリシーは、**ユーザー、グループ、またはロールに直接割り当てられます**。そのため、他の誰も使用できるポリシーリストには表示されません。\ インラインポリシーは、**ポリシーと適用されるアイデンティティの間に厳密な1対1の関係を維持したい場合**に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。 #### リソースバケットポリシー これらは**リソース**に定義できる**ポリシー**です。**すべてのAWSリソースがそれをサポートしているわけではありません**。 もしプリンシパルがそれに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、彼らは許可されます。 ### IAMバウンダリー IAMバウンダリーは、**ユーザーまたはロールがアクセスすべき権限を制限するために使用できます**。このように、異なるポリシーによってユーザーに異なる権限が付与されても、操作は**失敗**します。 バウンダリーは、ユーザーに添付されたポリシーであり、**ユーザーまたはロールが持つことができる最大の権限レベルを示します**。したがって、**ユーザーが管理者アクセスを持っていても**、バウンダリーが彼にS·バケットのみを読み取ることを示している場合、それが彼ができる最大のことです。 **これ**、**SCP**および**最小特権の原則に従うこと**は、ユーザーが必要以上の権限を持たないように制御する方法です。 ### セッションポリシー セッションポリシーは、**ロールが引き受けられたときに設定されるポリシー**です。これは、そのセッションの**IAMバウンダリーのようなもの**になります：これは、セッションポリシーが権限を付与するのではなく、**ポリシーに示された権限に制限することを意味します**（最大の権限はロールが持つものです）。 これは**セキュリティ対策**に役立ちます：管理者が非常に特権のあるロールを引き受ける場合、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。 ```bash aws sts assume-role \ --role-arn \ --role-session-name \ [--policy-arns ] [--policy ] ``` 注意すべきは、デフォルトで**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)。 したがって、ある時点で「...セッションポリシーが...を許可していないため」といったエラーに直面した場合、ロールがそのアクションを実行するアクセス権を持っていても、**それを妨げるセッションポリシーが存在する**ということです。 ### アイデンティティフェデレーション アイデンティティフェデレーションは、**AWSに外部のアイデンティティプロバイダーからのユーザーが**AWSリソースに安全にアクセスできるようにし、AWSユーザー資格情報を有効なIAMユーザーアカウントから提供する必要がありません。\ アイデンティティプロバイダーの例としては、独自の企業の**Microsoft Active Directory**（**SAML**経由）や**OpenID**サービス（**Google**など）があります。フェデレーテッドアクセスにより、その中のユーザーがAWSにアクセスできるようになります。 この信頼を構成するために、**IAMアイデンティティプロバイダー（SAMLまたはOAuth）が生成され**、**他のプラットフォームを信頼する**ことになります。そして、少なくとも1つの**IAMロールがアイデンティティプロバイダーに（信頼される）割り当てられます**。信頼されたプラットフォームのユーザーがAWSにアクセスすると、前述のロールとしてアクセスします。 ただし、通常は**サードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたい**と思うでしょう。そのため、複数の**IAMロールがサードパーティのアイデンティティプロバイダーを信頼し**、サードパーティプラットフォームがユーザーにどのロールを引き受けるかを許可します。
### IAMアイデンティティセンター AWS IAMアイデンティティセンター（AWSシングルサインオンの後継）は、AWSアイデンティティおよびアクセス管理（IAM）の機能を拡張し、**ユーザーとそのAWSアカウントおよびクラウドアプリケーションへのアクセスの管理を統合する**ための**中央の場所**を提供します。 ログインドメインは、`.awsapps.com`のようになります。 ユーザーをログインさせるために、使用できる3つのアイデンティティソースがあります： - アイデンティティセンターディレクトリ：通常のAWSユーザー - Active Directory：異なるコネクタをサポート - 外部アイデンティティプロバイダー：すべてのユーザーとグループは外部アイデンティティプロバイダー（IdP）から来ます
アイデンティティセンターディレクトリの最も単純なケースでは、**アイデンティティセンターはユーザーとグループのリストを持ち**、それらに**ポリシーを割り当てる**ことができ、**組織の任意のアカウント**に対して行います。 アイデンティティセンターのユーザー/グループにアカウントへのアクセスを与えるために、**アイデンティティセンターを信頼するSAMLアイデンティティプロバイダーが作成され**、**指定されたポリシーを持つアイデンティティプロバイダーを信頼するロールが宛先アカウントに作成されます**。 #### AwsSSOInlinePolicy **IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを通じて権限を与えることが可能です**。AWSアイデンティティセンターでインラインポリシーを持つアカウントで作成されたロールは、**`AwsSSOInlinePolicy`**というインラインポリシーにこれらの権限を持ちます。 したがって、**`AwsSSOInlinePolicy`**というインラインポリシーを持つ2つのロールがあっても、**同じ権限を持っているわけではありません**。 ### クロスアカウントの信頼とロール **ユーザー**（信頼する側）は、いくつかのポリシーを持つクロスアカウントロールを作成し、**別のユーザー**（信頼される側）に**自分のアカウントにアクセスを許可する**が、**新しいロールポリシーで示されたアクセスのみを持つ**ことができます。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。\ 信頼されるユーザーを**特定し、一般的なものを指定しないことをお勧めします**。そうしないと、フェデレーテッドユーザーのような他の認証されたユーザーもこの信頼を悪用できる可能性があります。 ### AWS Simple AD サポートされていない： - 信頼関係 - AD管理センター - フルPS APIサポート - ADリサイクルビン - グループ管理サービスアカウント - スキーマ拡張 - OSまたはインスタンスへの直接アクセスなし #### WebフェデレーションまたはOpenID認証 アプリはAssumeRoleWithWebIdentityを使用して一時的な資格情報を作成します。ただし、これによりAWSコンソールへのアクセスは付与されず、AWS内のリソースへのアクセスのみが許可されます。 ### その他のIAMオプション - **パスワードポリシー設定**を設定することができ、最小長やパスワード要件などのオプションがあります。 - **「資格情報レポート」をダウンロード**することができ、現在の資格情報に関する情報（ユーザー作成時間、パスワードが有効かどうかなど）を取得できます。資格情報レポートは、最長で**4時間ごと**に生成できます。 AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体での**きめ細かいアクセス制御**を提供します。IAMを使用すると、**誰がどのサービスやリソースにアクセスできるか、どの条件下でアクセスできるかを指定できます**。IAMポリシーを使用して、労働力やシステムへの権限を管理し、**最小権限の権限を確保**します。 ### IAM IDプレフィックス [**このページ**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-unique-ids)では、キーの性質に応じた**IAM IDプレフィックス**を見つけることができます： | Identifier Code | Description | | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ABIA | [AWS STSサービスベアラートークン](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_bearer.html) | | 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)はこのプレフィックスを使用しますが、秘密アクセスキーとセッショントークンと組み合わせた場合にのみ一意です。 | ### アカウントを監査するための推奨権限 以下の特権は、メタデータのさまざまな読み取りアクセスを付与します： - `arn:aws:iam::aws:policy/SecurityAudit` - `arn:aws:iam::aws:policy/job-function/ViewOnlyAccess` - `codebuild:ListProjects` - `config:Describe*` - `cloudformation:ListStacks` - `logs:DescribeMetricFilters` - `directconnect:DescribeConnections` - `dynamodb:ListTables` ## その他 ### CLI認証 通常のユーザーがCLIを介してAWSに認証するためには、**ローカル資格情報**が必要です。デフォルトでは、`~/.aws/credentials`に**手動で**設定するか、**`aws configure`を実行することで**構成できます。\ そのファイルには、1つ以上のプロファイルを持つことができ、**プロファイル**が指定されていない場合、**そのファイルの`[default]`**と呼ばれるものが使用されます。\ 複数のプロファイルを持つ資格情報ファイルの例： ``` [default] aws_access_key_id = AKIA5ZDCUJHF83HDTYUT aws_secret_access_key = uOcdhof683fbOUGFYEQug8fUGIf68greoihef [Admin] aws_access_key_id = AKIA8YDCu7TGTR356SHYT aws_secret_access_key = uOcdhof683fbOUGFYEQuR2EIHG34UY987g6ff7 region = eu-west-2 ``` 異なる **AWS アカウント** にアクセスする必要があり、あなたのプロファイルが **それらのアカウント内でロールを引き受ける** アクセスを与えられている場合、毎回手動で STS を呼び出す必要はありません (`aws sts assume-role --role-arn --role-session-name sessname`) と資格情報を設定する必要はありません。 `~/.aws/config` ファイルを使用して[ **引き受けるロールを指定**](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)し、その後は通常通り `--profile` パラメータを使用できます（`assume-role` はユーザーにとって透過的に実行されます）。\ 設定ファイルの例: ``` [profile acc2] region=eu-west-2 role_arn=arn:aws:iam:::role/ role_session_name = source_profile = sts_regional_endpoints = regional ``` この設定ファイルを使用すると、次のようにaws cliを使用できます: ``` aws --profile acc2 ... ``` もしこれに**似た**ものを**ブラウザ**用に探しているなら、**拡張機能** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en)をチェックできます。 ## 参考文献 - [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) - [https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/](https://aws.amazon.com/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/) {{#include ../../../banners/hacktricks-training.md}}