Japanese - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

HackTricksをサポートする

組織階層

アカウント

AWSにはルートアカウントがあり、これは組織内のすべてのアカウントの親コンテナです。しかし、そのアカウントを使用してリソースをデプロイする必要はなく、異なるAWSインフラストラクチャを分離するために他のアカウントを作成することができます。

これはセキュリティの観点から非常に興味深いことであり、1つのアカウントは他のアカウントのリソースにアクセスできません（特別にブリッジが作成されていない限り）。このようにして、デプロイメント間に境界を作成できます。

したがって、組織内には2種類のアカウントがあります（AWSアカウントについて話しており、ユーザーアカウントではありません）：管理アカウントとして指定された単一のアカウントと、1つ以上のメンバーアカウントです。

  • **管理アカウント（ルートアカウント）**は、組織を作成するために使用するアカウントです。組織の管理アカウントから、次のことができます：

  • 組織内にアカウントを作成する

  • 他の既存のアカウントを組織に招待する

  • 組織からアカウントを削除する

  • 招待を管理する

  • 組織内のエンティティ（ルート、OU、またはアカウント）にポリシーを適用する

  • 組織内のすべてのアカウントにサービス機能を提供するために、サポートされているAWSサービスとの統合を有効にする。

  • このルートアカウント/組織を作成するために使用したメールアドレスとパスワードを使用して、ルートユーザーとしてログインすることが可能です。

管理アカウントは支払いアカウントの責任を持ち、メンバーアカウントによって発生したすべての料金を支払う責任があります。組織の管理アカウントを変更することはできません。

  • メンバーアカウントは、組織内の残りのすべてのアカウントを構成します。アカウントは、一度に1つの組織のメンバーであることができます。アカウントにポリシーを添付して、そのアカウントのみに制御を適用できます。

  • メンバーアカウントは有効なメールアドレスを使用する必要があり、名前を持つことができます。一般的に、請求を管理することはできませんが（アクセスが与えられる場合があります）。

aws organizations create-account --account-name testingaccount --email testingaccount@lalala1233fr.com

組織単位

アカウントは組織単位 (OU)にグループ化できます。この方法で、組織単位に対してポリシーを作成し、それがすべての子アカウントに適用されるようにできます。OUは他のOUを子として持つことができることに注意してください。

# You can get the root id from aws organizations list-roots
aws organizations create-organizational-unit --parent-id r-lalala --name TestOU

サービスコントロールポリシー (SCP)

サービスコントロールポリシー (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で見つけることができます。

ARN

Amazonリソース名は、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アカウントのルートユーザー

Amazon Web Services (AWS) アカウントを最初に作成すると、アカウント内のすべてのAWSサービスとリソースに完全にアクセスできる単一のサインインアイデンティティが与えられます。これがAWSアカウントの_ルートユーザー_であり、アカウントを作成する際に使用したメールアドレスとパスワードでサインインすることでアクセスします。

新しい管理者ユーザーはルートユーザーよりも権限が少ないことに注意してください。

セキュリティの観点からは、他のユーザーを作成し、このユーザーの使用を避けることが推奨されます。

IAMユーザー

IAM ユーザー は、AWS内で人またはアプリケーションを表すために作成するエンティティです。AWSのユーザーは、名前と資格情報（パスワードと最大2つのアクセスキー）で構成されます。

IAMユーザーを作成すると、適切な権限ポリシーが添付されたユーザーグループのメンバーにすることで権限を付与するか、ポリシーを直接ユーザーに添付することができます（推奨）。

ユーザーは、コンソールを通じてMFAを有効にしてログインできます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。MFAを使用してユーザーのAPIキーのアクセスを制限したい場合は、特定のアクションを実行するためにMFAが必要であることをポリシーに示す必要があります（例：こちら）。

CLI

  • アクセスキーID: 20のランダムな大文字の英数字の文字列（例：AKHDNAPO86BSHKDIRYT）

  • シークレットアクセスキーID: 40のランダムな大文字と小文字の文字列（例：S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU）（失われたシークレットアクセスキーIDを取得することはできません）。

アクセスキーを変更する必要がある場合は、次のプロセスに従う必要があります： 新しいアクセスキーを作成 -> 新しいキーをシステム/アプリケーションに適用 -> 元のキーを非アクティブとしてマーク -> 新しいアクセスキーが機能していることをテストおよび確認 -> 古いアクセスキーを削除

MFA - 多要素認証

これは、既存の方法（パスワードなど）に加えて認証のための追加の要素を作成するために使用され、したがって多要素の認証レベルを作成します。 無料の仮想アプリケーションまたは物理デバイスを使用できます。Google認証などのアプリを無料で使用してAWSでMFAを有効にできます。

MFA条件を持つポリシーは、以下に添付できます：

  • IAMユーザーまたはグループ

  • Amazon S3バケット、Amazon SQSキュー、またはAmazon SNSトピックなどのリソース

  • ユーザーによって引き受けられるIAMロールの信頼ポリシー

CLIを介してMFAをチェックするリソースにアクセスしたい場合は、**GetSessionToken**を呼び出す必要があります。これにより、MFAに関する情報を含むトークンが得られます。 AssumeRoleの資格情報にはこの情報が含まれていないことに注意してください。

aws sts get-session-token --serial-number <arn_device> --token-code <code>

As ここに記載されているように、MFAが使用できないさまざまなケースがあります。

IAMユーザーグループ

IAM ユーザーグループは、複数のユーザーにポリシーを一度に適用する方法であり、これによりそれらのユーザーの権限を管理しやすくなります。ロールとグループはグループの一部にはなれません。

ユーザーグループにアイデンティティベースのポリシーを適用することができ、これによりユーザーグループ内のすべてのユーザーがポリシーの権限を受け取ります。ユーザーグループをポリシー（リソースベースのポリシーなど）内の**Principalとして特定することはできません**。なぜなら、グループは権限に関連し、認証には関連しないため、プリンシパルは認証されたIAMエンティティだからです。

ユーザーグループのいくつかの重要な特徴は次のとおりです：

  • ユーザーグループは多くのユーザーを含むことができ、ユーザーは複数のグループに属することができます。

  • ユーザーグループはネストできません。ユーザーのみを含むことができ、他のユーザーグループを含むことはできません。

  • AWSアカウント内のすべてのユーザーを自動的に含むデフォルトのユーザーグループはありません。そのようなユーザーグループを持ちたい場合は、自分で作成し、新しいユーザーをそれに割り当てる必要があります。

  • AWSアカウント内のIAMリソースの数とサイズ（グループの数や、ユーザーがメンバーになれるグループの数など）は制限されています。詳細については、IAMおよびAWS STSのクォータを参照してください。

IAMロール

IAM ロールは、ユーザーと非常に似ています。それは、AWSで何ができるか、何ができないかを決定する権限ポリシーを持つアイデンティティです。しかし、ロールには関連付けられた資格情報（パスワードやアクセスキー）がありません。特定の人に一意に関連付けられるのではなく、ロールは必要な人（十分な権限を持つ人）が引き受けることを意図しています。IAMユーザーは、特定のタスクのために一時的に異なる権限を取得するためにロールを引き受けることができます。ロールは、IAMではなく外部アイデンティティプロバイダーを使用してサインインするフェデレーテッドユーザーに割り当てることができます。

IAMロールは、2種類のポリシーで構成されています：信頼ポリシー（空であってはならず、誰がロールを引き受けることができるかを定義）と、権限ポリシー（空であってはならず、何にアクセスできるかを定義）。

AWSセキュリティトークンサービス（STS）

AWSセキュリティトークンサービス（STS）は、一時的で制限された権限の資格情報を発行するためのウェブサービスです。これは特に次の目的に特化しています：

IAMにおける一時的な資格情報

一時的な資格情報は主にIAMロールと共に使用されますが、他の用途もあります。標準のIAMユーザーよりも制限された権限セットを持つ一時的な資格情報を要求できます。これにより、より制限された資格情報によって許可されていないタスクを誤って実行することを防ぎます。一時的な資格情報の利点は、設定された期間の後に自動的に期限切れになることです。資格情報が有効な期間を制御できます。

ポリシー

ポリシー権限

権限を割り当てるために使用されます。2種類あります：

  • AWS管理ポリシー（AWSによって事前設定されたもの）

  • カスタマー管理ポリシー：あなたが設定したもの。AWS管理ポリシーに基づいてポリシーを作成できます（そのうちの1つを修正して自分のものを作成する）、ポリシージェネレーターを使用する（権限を付与および拒否するのを助けるGUIビュー）または自分で作成することができます。

デフォルトのアクセスは 拒否されます。明示的なロールが指定された場合にのみアクセスが許可されます。 単一の「拒否」が存在する場合、それは「許可」を上書きします。AWSアカウントのルートセキュリティ資格情報を使用するリクエスト（デフォルトで許可されている）は除きます。

{
"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 グローバルフィールドは、任意のサービスの条件に使用できるものがここに文書化されています. 特定のフィールドは、サービスごとの条件に使用できるものがここに文書化されています.

インラインポリシー

この種のポリシーは、ユーザー、グループ、またはロールに直接割り当てられます。そのため、他の誰かが使用できるようにポリシーリストには表示されません。 インラインポリシーは、ポリシーとそれが適用されるアイデンティティとの間に厳密な1対1の関係を維持したい場合に便利です。たとえば、ポリシー内の権限が意図されたアイデンティティ以外に誤って割り当てられないことを確認したい場合です。インラインポリシーを使用すると、ポリシー内の権限が誤って間違ったアイデンティティに添付されることはありません。さらに、AWS Management Consoleを使用してそのアイデンティティを削除すると、アイデンティティに埋め込まれたポリシーも削除されます。これは、それらが主なエンティティの一部であるためです。

リソースバケットポリシー

これらはリソースに定義できるポリシーです。すべてのAWSリソースがそれをサポートしているわけではありません。

もしプリンシパルがそれに対して明示的な拒否を持っておらず、リソースポリシーがアクセスを許可している場合、彼らは許可されます。

IAMバウンダリー

IAMバウンダリーは、ユーザーまたはロールがアクセスできる権限を制限するために使用できます。このように、異なるポリシーによってユーザーに異なる権限が付与されても、彼がそれを使用しようとすると操作は失敗します。

バウンダリーは、ユーザーに添付されたポリシーであり、ユーザーまたはロールが持つことができる最大の権限レベルを示します。したがって、ユーザーが管理者アクセスを持っていても、バウンダリーが彼がS·バケットを読むことしかできないと示している場合、それが彼ができる最大のことです。

これ、SCP、および最小権限の原則に従うことは、ユーザーが必要以上の権限を持たないように制御する方法です。

セッションポリシー

セッションポリシーは、ロールが引き受けられたときに設定されるポリシーです。これは、そのセッションのIAMバウンダリーのようなものになります：これは、セッションポリシーが権限を付与するのではなく、ポリシーに示された権限に制限することを意味します（最大の権限はロールが持つものです）。

これはセキュリティ対策に役立ちます：管理者が非常に特権のあるロールを引き受ける場合、セッションが侵害された場合に備えて、セッションポリシーに示された権限のみを制限することができます。

aws sts assume-role \
--role-arn <value> \
--role-session-name <value> \
[--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
[--policy <file://policy.json>]

注意すべきは、デフォルトでAWSはセッションにセッションポリシーを追加する可能性があるということです。例えば、認証されていないCognitoの仮定されたロールでは、デフォルト（強化された認証を使用）で、AWSはセッションポリシーを持つセッション資格情報を生成し、そのセッションがアクセスできるサービスを次のリストに制限します。

したがって、ある時点で「...セッションポリシーが許可していないため...」というエラーに直面した場合、ロールがアクションを実行するアクセス権を持っていても、それを防ぐセッションポリシーが存在するためです。

アイデンティティフェデレーション

アイデンティティフェデレーションは、AWSに外部のアイデンティティプロバイダーからのユーザーが、正当なIAMユーザーアカウントのAWSユーザー資格情報を提供することなく、AWSリソースに安全にアクセスできるようにします。 アイデンティティプロバイダーの例としては、独自の企業のMicrosoft Active Directory（SAML経由）やOpenIDサービス（Googleなど）があります。フェデレーテッドアクセスにより、その中のユーザーがAWSにアクセスできるようになります。

この信頼を構成するために、IAMアイデンティティプロバイダー（SAMLまたはOAuth）が生成され、他のプラットフォームを信頼することになります。そして、少なくとも1つのIAMロールがアイデンティティプロバイダーに（信頼される）割り当てられます。信頼されたプラットフォームのユーザーがAWSにアクセスすると、彼は前述のロールとしてアクセスします。

ただし、通常はサードパーティプラットフォームのユーザーのグループに応じて異なるロールを与えたいと思うでしょう。そのため、複数のIAMロールがサードパーティのアイデンティティプロバイダーを信頼し、サードパーティプラットフォームがユーザーにどのロールを引き受けるかを許可します。

IAMアイデンティティセンター

AWS IAMアイデンティティセンター（AWSシングルサインオンの後継）は、AWSアイデンティティおよびアクセス管理（IAM）の機能を拡張し、ユーザーとそのAWSアカウントおよびクラウドアプリケーションへのアクセスの管理を統合するための中央の場所を提供します。

ログインドメインは、<user_input>.awsapps.comのようになります。

ユーザーをログインさせるために、使用できる3つのアイデンティティソースがあります：

  • アイデンティティセンターディレクトリ：通常のAWSユーザー

  • アクティブディレクトリ：異なるコネクタをサポート

  • 外部アイデンティティプロバイダー：すべてのユーザーとグループは外部アイデンティティプロバイダー（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プレフィックス

このページでは、キーの性質に応じたIAM IDプレフィックスを見つけることができます：

ABIA

AWS STSサービスベアラートークン

ACCA

コンテキスト固有の資格情報

AGPA

ユーザーグループ

AIDA

IAMユーザー

AIPA

Amazon EC2インスタンスプロファイル

AKIA

アクセスキー

ANPA

管理ポリシー

ANVA

管理ポリシーのバージョン

APKA

公開鍵

AROA

ロール

ASCA

証明書

ASIA

一時的（AWS STS）アクセスキー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認証

通常のユーザーがCLIを介してAWSに認証するためには、ローカル資格情報が必要です。デフォルトでは、~/.aws/credentialsに手動で設定するか、aws configureを実行することで構成できます。 そのファイルには複数のプロファイルを持つことができ、プロファイルが指定されていない場合、aws cliを使用すると、そのファイル内の**[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-arn> --role-session-name sessname）し、資格情報を設定する必要もありません。

~/.aws/configファイルを使用して引き受けるロールを指定することができ、その後は通常通り--profileパラメータを使用できます（assume-roleはユーザーにとって透過的に実行されます）。 設定ファイルの例:

[profile acc2]
region=eu-west-2
role_arn=arn:aws:iam::<account-id>:role/<role-path>
role_session_name = <session_name>
source_profile = <profile_with_assume_role>
sts_regional_endpoints = regional

この設定ファイルを使用して、次のようにaws cliを使用できます:

aws --profile acc2 ...

もしあなたがブラウザ用の類似のものを探しているなら、拡張機能AWS Extend Switch Rolesをチェックしてください。

参考文献

HackTricksをサポートする
PreviousAWS PentestingNextAWS - Federation Abuse

Last updated