Last updated
AWSハッキングを学び、実践する：
HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：
HackTricks Training GCP Red Team Expert (GRTE)
AWSには、ルートアカウントがあり、これは組織のすべてのアカウントの親コンテナです。しかし、そのアカウントを使用してリソースをデプロイする必要はなく、異なるAWSインフラストラクチャを分離するために他のアカウントを作成することができます。
これはセキュリティの観点から非常に興味深いことであり、1つのアカウントは他のアカウントのリソースにアクセスできません（特別にブリッジが作成されていない限り）。このようにして、デプロイメント間に境界を作成できます。
したがって、組織内には2種類のアカウントがあります（AWSアカウントについて話しており、ユーザーアカウントではありません）：管理アカウントとして指定された単一のアカウントと、1つ以上のメンバーアカウントです。
**管理アカウント（ルートアカウント）**は、組織を作成するために使用するアカウントです。組織の管理アカウントから、次のことができます：
組織内にアカウントを作成する
他の既存のアカウントを組織に招待する
組織からアカウントを削除する
招待を管理する
組織内のエンティティ（ルート、OU、またはアカウント）にポリシーを適用する
組織内のすべてのアカウントにサービス機能を提供するために、サポートされているAWSサービスとの統合を有効にする。
このルートアカウント/組織を作成するために使用したメールアドレスとパスワードを使用して、ルートユーザーとしてログインすることが可能です。
管理アカウントは支払いアカウントの責任を持ち、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。
メンバーアカウントは、組織内の残りのすべてのアカウントを構成します。アカウントは、一度に1つの組織のメンバーであることができます。アカウントにポリシーを添付して、そのアカウントのみに制御を適用できます。
メンバーアカウントは有効なメールアドレスを使用する必要があり、名前を持つことができます。一般的に、請求を管理することはできませんが（アクセスが与えられる場合があります）。
アカウントは組織単位 (OU)にグループ化できます。この方法で、組織単位に対してポリシーを作成し、それがすべての子アカウントに適用されるようにできます。OUは他のOUを子として持つことができることに注意してください。
サービスコントロールポリシー (SCP) は、SCPが影響を与えるアカウント内でユーザーやロールが使用できるサービスとアクションを指定するポリシーです。SCPはIAMの権限ポリシーに似ていますが、権限を付与することはありません。代わりに、SCPは組織、組織単位 (OU)、またはアカウントの最大権限を指定します。SCPを組織のルートまたはOUにアタッチすると、メンバーアカウント内のエンティティの権限が制限されます。
これはルートユーザーでさえも何かを行うのを止める唯一の方法です。例えば、CloudTrailを無効にしたり、バックアップを削除したりするのをユーザーに止めるために使用できます。 これを回避する唯一の方法は、SCPを設定するマスターアカウントも侵害することです（マスターアカウントはブロックできません）。
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で見つけてください。
Amazonリソース名は、AWS内のすべてのリソースが持つユニークな名前で、次のように構成されています:
注意：AWSには4つのパーティションがありますが、それを呼び出す方法は3つだけです：
AWS Standard: aws
AWS China: aws-cn
AWS US public Internet (GovCloud): aws-us-gov
AWS Secret (US Classified): aws
IAMは、AWSアカウント内で認証、認可、およびアクセス制御を管理することを可能にするサービスです。
認証 - アイデンティティを定義し、そのアイデンティティを検証するプロセス。このプロセスは、識別と検証に分けることができます。
認可 - アイデンティティがシステム内で認証された後にアクセスできるものを決定します。
アクセス制御 - セキュアなリソースへのアクセスがどのように付与されるかの方法とプロセス
IAMは、AWSアカウント内のリソースに対するアイデンティティの認証、認可、およびアクセス制御メカニズムを管理、制御、統治する能力によって定義されます。
Amazon Web Services (AWS) アカウントを最初に作成すると、アカウント内のすべてのAWSサービスとリソースに完全にアクセスできる単一のサインインアイデンティティが与えられます。これがAWSアカウントの_ルートユーザー_であり、アカウントを作成する際に使用したメールアドレスとパスワードでサインインすることでアクセスします。
新しい管理者ユーザーはルートユーザーよりも権限が少ないことに注意してください。
セキュリティの観点からは、他のユーザーを作成し、このユーザーの使用を避けることが推奨されます。
IAM ユーザー は、AWS内で人またはアプリケーションを表すために作成するエンティティです。AWSのユーザーは、名前と資格情報（パスワードと最大2つのアクセスキー）で構成されます。
IAMユーザーを作成すると、適切な権限ポリシーが添付されたユーザーグループのメンバーにすることで権限を付与するか、ポリシーを直接ユーザーに添付することができます（推奨）。
ユーザーは、コンソールを通じてMFAを有効にしてログインできます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して制限したい場合は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（例 こちら）。
アクセスキーID: 20のランダムな大文字の英数字の文字列（例：AKHDNAPO86BSHKDIRYT）
シークレットアクセスキーID: 40のランダムな大文字と小文字の文字列（例：S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU）（失われたシークレットアクセスキーIDを取得することはできません）。
アクセスキーを変更する必要がある場合は、次のプロセスに従う必要があります： 新しいアクセスキーを作成 -> 新しいキーをシステム/アプリケーションに適用 -> 元のキーを非アクティブとしてマーク -> 新しいアクセスキーが機能していることをテストおよび確認 -> 古いアクセスキーを削除
これは、既存の方法（パスワードなど）に加えて認証のための追加の要素を作成するために使用され、したがって多要素の認証レベルを作成します。 無料の仮想アプリケーションまたは物理デバイスを使用できます。Google認証などのアプリを無料で使用してAWSでMFAを有効にできます。
MFA条件を持つポリシーは、以下に添付できます：
IAMユーザーまたはグループ
Amazon S3バケット、Amazon SQSキュー、またはAmazon SNSトピックなどのリソース
ユーザーによって引き受けられるIAMロールの信頼ポリシー
MFAをチェックするリソースにCLI経由でアクセスしたい場合は、**GetSessionToken**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。
AssumeRoleの資格情報にはこの情報が含まれていないことに注意してください。
As ここに記載されているように、MFAが使用できないさまざまなケースがあります。
IAM ユーザーグループは、複数のユーザーにポリシーを一度に適用する方法であり、これによりそれらのユーザーの権限を管理しやすくなります。ロールとグループはグループの一部にはなれません。
ユーザーグループにアイデンティティベースのポリシーを適用することができ、ユーザーグループ内のすべてのユーザーがポリシーの権限を受け取ります。ユーザーグループをポリシー（リソースベースのポリシーなど）内の**Principalとして特定することはできません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。
ユーザーグループのいくつかの重要な特徴は次のとおりです：
ユーザーグループは多くのユーザーを含むことができ、ユーザーは複数のグループに属することができます。
ユーザーグループはネストできません。ユーザーのみを含むことができ、他のユーザーグループは含められません。
AWSアカウント内のすべてのユーザーを自動的に含むデフォルトのユーザーグループはありません。そのようなユーザーグループを持ちたい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。
AWSアカウント内のIAMリソースの数とサイズ（グループの数や、ユーザーがメンバーになれるグループの数など）は制限されています。詳細については、IAMおよびAWS STSのクォータを参照してください。
IAM ロールは、ユーザーと非常に似ています。それは、AWSで何ができるか、できないかを決定する権限ポリシーを持つアイデンティティです。しかし、ロールには関連付けられた資格情報（パスワードやアクセスキー）がありません。特定の人に一意に関連付けられるのではなく、ロールは必要な人（十分な権限を持つ人）が引き受けることを意図しています。IAMユーザーはロールを引き受けて、一時的に特定のタスクのために異なる権限を持つことができます。ロールは、IAMの代わりに外部アイデンティティプロバイダーを使用してサインインするフェデレーテッドユーザーに割り当てることができます。
IAMロールは、2種類のポリシーで構成されています：信頼ポリシー（空であってはならず、誰がロールを引き受けることができるかを定義）と、権限ポリシー（空であってはならず、何にアクセスできるかを定義）。
AWSセキュリティトークンサービス（STS）は、一時的で制限された権限の資格情報を発行するためのウェブサービスです。これは特に次の目的に特化しています：
一時的な資格情報は主にIAMロールと共に使用されますが、他の用途もあります。標準のIAMユーザーよりも制限された権限セットを持つ一時的な資格情報をリクエストできます。これにより、より制限された資格情報によって許可されていないタスクを誤って実行することを防ぎます。一時的な資格情報の利点は、設定された期間の後に自動的に期限切れになることです。資格情報が有効な期間を制御できます。
権限を割り当てるために使用されます。2種類あります：
AWS管理ポリシー（AWSによって事前構成されたもの）
カスタマー管理ポリシー：あなたが構成したもの。AWS管理ポリシーに基づいてポリシーを作成できます（それらの1つを修正して独自のものを作成する）、ポリシージェネレーターを使用する（権限を付与および拒否するのを助けるGUIビュー）または独自に作成することができます。
デフォルトのアクセスは 拒否され、明示的なロールが指定された場合にのみアクセスが許可されます。 単一の「拒否」が存在する場合、それは「許可」を上書きします。AWSアカウントのルートセキュリティ資格情報を使用するリクエスト（デフォルトで許可されている）は除きます。
The グローバルフィールドは、任意のサービスの条件に使用できるものがここに文書化されています. サービスごとに条件に使用できる特定のフィールドはここに文書化されています.
この種のポリシーは、ユーザー、グループ、またはロールに直接割り当てられます。そのため、他の誰も使用できるポリシーリストには表示されません。 インラインポリシーは、ポリシーと適用されるアイデンティティとの間に厳密な1対1の関係を維持したい場合に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主エンティティの一部であるためです。
これらはリソースに定義できるポリシーです。すべてのAWSリソースがそれをサポートしているわけではありません。
もしプリンシパルがそれに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、彼らは許可されます。
IAMバウンダリーは、ユーザーまたはロールがアクセスできる権限を制限するために使用できます。このように、異なるポリシーによってユーザーに異なる権限が付与されても、彼がそれを使用しようとすると操作は失敗します。
バウンダリーは、ユーザーに添付されたポリシーであり、ユーザーまたはロールが持つことができる最大の権限レベルを示します。したがって、ユーザーが管理者アクセスを持っていても、バウンダリーが彼がS·バケットを読むことしかできないと示している場合、それが彼ができる最大のことです。
これ、SCP、および最小特権の原則に従うことは、ユーザーが必要な権限以上の権限を持たないように制御する方法です。
セッションポリシーは、ロールが引き受けられたときに設定されるポリシーです。これは、そのセッションのIAMバウンダリーのようなものです：これは、セッションポリシーが権限を付与するのではなく、ポリシーに示された権限に制限することを意味します（最大の権限はロールが持つものです）。
これはセキュリティ対策に役立ちます：管理者が非常に特権のあるロールを引き受ける場合、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。
注意してください、デフォルトではAWSはセッションにセッションポリシーを追加する可能性があります。これは第三者の理由によって生成されるセッションに対してです。例えば、認証されていないCognitoの仮定されたロールでは、デフォルトで（強化された認証を使用して）、AWSはセッションポリシーを持つセッション資格情報を生成し、そのセッションがアクセスできるサービスを次のリストに制限します。
したがって、ある時点で「...セッションポリシーが...を許可していないため」といったエラーに直面した場合、ロールがそのアクションを実行するアクセス権を持っていても、それを防ぐセッションポリシーが存在するためです。
アイデンティティフェデレーションは、AWSに外部のアイデンティティプロバイダーからのユーザーが、AWSのユーザー資格情報を提供することなく、AWSリソースに安全にアクセスできるようにします。 アイデンティティプロバイダーの例としては、独自の企業のMicrosoft Active Directory（SAML経由）やOpenIDサービス（Googleなど）があります。フェデレーテッドアクセスにより、その中のユーザーがAWSにアクセスできるようになります。
この信頼を構成するために、IAMアイデンティティプロバイダー（SAMLまたはOAuth）が生成され、他のプラットフォームを信頼します。次に、少なくとも1つのIAMロールがアイデンティティプロバイダーに（信頼される）割り当てられます。信頼されたプラットフォームのユーザーがAWSにアクセスすると、彼は前述のロールとしてアクセスします。
ただし、通常はサードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたいと思うでしょう。したがって、複数のIAMロールがサードパーティのアイデンティティプロバイダーを信頼し、サードパーティプラットフォームがユーザーにどちらのロールを引き受けるかを許可します。
AWS IAMアイデンティティセンター（AWSシングルサインオンの後継）は、AWSアイデンティティおよびアクセス管理（IAM）の機能を拡張し、ユーザーとそのAWSアカウントおよびクラウドアプリケーションへのアクセスの管理を統合するための中央の場所を提供します。
ログインドメインは、<user_input>.awsapps.comのようになります。
ユーザーをログインさせるために、使用できる3つのアイデンティティソースがあります：
アイデンティティセンターディレクトリ：通常のAWSユーザー
アクティブディレクトリ：異なるコネクタをサポート
外部アイデンティティプロバイダー：すべてのユーザーとグループは外部アイデンティティプロバイダー（IdP）から来ます
アイデンティティセンターディレクトリの最も単純なケースでは、アイデンティティセンターはユーザーとグループのリストを持ち、それらにポリシーを割り当てることができます。組織の任意のアカウントに対して。
アイデンティティセンターのユーザー/グループにアカウントへのアクセスを与えるために、アイデンティティセンターを信頼するSAMLアイデンティティプロバイダーが作成され、指定されたポリシーを持つアイデンティティプロバイダーを信頼するロールが宛先アカウントに作成されます。
IAMアイデンティティセンターを介して作成されたロールにインラインポリシーを介して権限を与えることが可能です。AWSアイデンティティセンターでインラインポリシーを持つアカウントで作成されたロールは、**AwsSSOInlinePolicy**というインラインポリシーでこれらの権限を持ちます。
したがって、**AwsSSOInlinePolicy**というインラインポリシーを持つ2つのロールが表示されても、同じ権限を持っているわけではありません。
ユーザー（信頼する側）は、いくつかのポリシーを持つクロスアカウントロールを作成し、別のユーザー（信頼される側）に自分のアカウントにアクセスさせることができますが、新しいロールポリシーで示されたアクセスのみを持つことができます。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールは2つのオプションを提供します。所有するAWSアカウント間でのアクセスを提供することと、所有するアカウントとサードパーティのAWSアカウント間でのアクセスを提供することです。 信頼されるユーザーを特定し、一般的なものを指定しないことをお勧めします**。そうしないと、フェデレーテッドユーザーなどの他の認証されたユーザーもこの信頼を悪用できる可能性があります。
サポートされていない：
信頼関係
AD管理センター
フルPS APIサポート
ADリサイクルビン
グループ管理サービスアカウント
スキーマ拡張
OSまたはインスタンスへの直接アクセスなし
アプリはAssumeRoleWithWebIdentityを使用して一時的な資格情報を作成します。ただし、これによりAWSコンソールへのアクセスは付与されず、AWS内のリソースへのアクセスのみが付与されます。
パスワードポリシー設定を設定することができ、最小長やパスワード要件などのオプションがあります。
「資格情報レポート」をダウンロードして、現在の資格情報に関する情報（ユーザー作成時間、パスワードが有効かどうかなど）を取得できます。資格情報レポートは、最長で4時間ごとに生成できます。
AWSアイデンティティおよびアクセス管理（IAM）は、AWS全体で細かいアクセス制御を提供します。IAMを使用すると、誰がどのサービスやリソースにアクセスできるか、どの条件下でアクセスできるかを指定できます。IAMポリシーを使用して、労働力やシステムへの権限を管理し、最小権限の権限を確保します。
このページでは、キーの性質に応じたIAM IDプレフィックスを見つけることができます：
以下の特権は、メタデータのさまざまな読み取りアクセスを付与します：
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を介してAWSに認証するためには、ローカル資格情報が必要です。デフォルトでは、~/.aws/credentialsに手動で設定するか、aws configureを実行することで構成できます。
そのファイルには、1つ以上のプロファイルを持つことができ、プロファイルが指定されていない場合、aws cliを使用すると、そのファイル内の**[default]**と呼ばれるものが使用されます。
複数のプロファイルを持つ資格情報ファイルの例：
もし異なるAWSアカウントにアクセスする必要があり、あなたのプロファイルがそれらのアカウント内でロールを引き受けるアクセスを与えられている場合、毎回手動でSTSを呼び出す必要はありません（aws sts assume-role --role-arn <role-arn> --role-session-name sessname）し、資格情報を設定する必要もありません。
~/.aws/configファイルを使用して引き受けるロールを指定することができ、その後は通常通り--profileパラメータを使用できます（assume-roleはユーザーにとって透過的に実行されます）。
設定ファイルの例:
この設定ファイルを使用すると、次のようにaws cliを使用できます:
もしあなたがブラウザ用の類似のものを探しているなら、拡張機能AWS Extend Switch Rolesをチェックしてください。
AWSハッキングを学び、練習する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、練習する：HackTricks Training GCP Red Team Expert (GRTE)
ABIA
ACCA
コンテキスト固有の資格情報
AGPA
ユーザーグループ
AIDA
IAMユーザー
AIPA
Amazon EC2インスタンスプロファイル
AKIA
アクセスキー
ANPA
管理ポリシー
ANVA
管理ポリシーのバージョン
APKA
公開鍵
AROA
ロール
ASCA
証明書
ASIA
一時的（AWS STS）アクセスキーIDはこのプレフィックスを使用しますが、秘密アクセスキーとセッショントークンと組み合わせた場合にのみ一意です。
