Japanese - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Basic Information

htARTE（HackTricks AWS Red Team Expert） を通じて、ゼロからヒーローまでAWSハッキングを学びましょう！

HackTricks をサポートする他の方法:

組織階層

アカウント

AWSには、組織のすべてのアカウントの親コンテナであるルートアカウントがあります。ただし、リソースを展開するためにそのアカウントを使用する必要はありません。異なるAWSインフラストラクチャを区別するために他のアカウントを作成できます。

これはセキュリティの観点から非常に興味深いです。1つのアカウントは他のアカウントのリソースにアクセスできない（特定のブリッジが作成されていない限り）、そのため、展開間に境界を作成できます。

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

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

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

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

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

  • 招待を管理する

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

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

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

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

  • メンバーアカウント は、組織内のすべての残りのアカウントを構成します。アカウントは1度に1つの組織のメンバーになることができます。アカウントにポリシーを添付して、その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にアタッチすると、SCPはメンバーアカウント内のエンティティの権限を制限します。

これはルートユーザーですら停止される唯一の方法です。例えば、CloudTrailの無効化やバックアップの削除をユーザーが停止するのを防ぐために使用できます。 これをバイパスする唯一の方法は、SCPを構成するマスターアカウントも侵害することです（マスターアカウントはブロックできません）。

SCPはアカウント内の主体にのみ制限を設けるため、他のアカウントには影響しません。これはSCPがs3:GetObjectを拒否しても、アカウント内のパブリックS3バケットへのアクセスを停止しないことを意味します。

SCPの例：

  • ルートアカウントを完全に拒否

  • 特定のリージョンのみ許可

  • ホワイトリストされたサービスのみ許可

  • GuardDuty、CloudTrail、およびS3 Public Block Accessの無効化を拒否

  • セキュリティ/インシデント対応ロールの削除や変更を拒否

  • バックアップの削除を拒否

  • IAMユーザーとアクセスキーの作成を拒否

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.htmlでJSONの例を見つけることができます。

ARN

Amazon Resource Name（ARN）は、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標準：aws

  • AWS中国：aws-cn

  • AWS米国公共インターネット（GovCloud）：aws-us-gov

  • AWSシークレット（米国機密）：aws

IAM - Identity and Access Management

IAMは、AWSアカウント内での認証、認可、およびアクセス制御を管理するためのサービスです。

  • 認証 - アイデンティティの定義とそのアイデンティティの検証のプロセス。このプロセスは、識別と検証に分割できます。

  • 認可 - 認証された後のシステム内でアイデンティティがアクセスできる内容を決定します。

  • アクセス制御 - 安全なリソースへのアクセスがどのように許可されるかの方法とプロセス

IAMは、AWSアカウント内のリソースへのアイデンティティの認証、認可、およびアクセス制御メカニズムを管理、制御、および統治する能力によって定義できます。

AWSアカウントルートユーザー

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

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

セキュリティの観点から、他のユーザーを作成し、このユーザーを使用しないようにすることが推奨されています。

IAMユーザー

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

IAMユーザーを作成すると、それを適切な権限ポリシーがアタッチされたユーザーグループのメンバーにすることによって権限を付与するか、ユーザーに直接ポリシーをアタッチすることによって権限を付与します。

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

CLI

  • アクセスキーID：AKHDNAPO86BSHKDIRYTのような20個のランダムな大文字英数字文字

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

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

MFA - マルチファクタ認証

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

MFA条件付きポリシーは、次のものにアタッチできます：

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

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

  • ユーザーが仮定できるIAMロールの信頼ポリシー

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

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

ここで述べられているように、MFAを使用できないさまざまなケースがあります。

IAMユーザーグループ

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

ユーザーグループにアイデンティティベースのポリシーをアタッチして、ユーザーグループ内のすべてのユーザーがポリシーの権限を受け取ることができます。グループは認証ではなく権限に関連しているため、リソースベースのポリシーなどのポリシーでユーザーグループをPrincipalとして識別することはできません。

以下は、ユーザーグループの重要な特性です：

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

  • ユーザーグループはネストできません。ユーザーグループには他のユーザーグループではなくユーザーのみが含まれることができます。

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

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

IAMロール

IAM ロールは、AWSで何ができるかできないかを決定する権限ポリシーを持つアイデンティティであるユーザーと非常に似ています。ただし、ロールには（パスワードやアクセスキーなどの）資格情報が関連付けられていません。1人の人物に固有に関連付けられるのではなく、ロールはそれを必要とする誰でも（十分な権限を持っている場合）仮定できるように意図されています。IAMユーザーは、特定のタスクのために異なる権限を一時的に持つためにロールを仮定することができます。ロールは、IAMではなく外部のアイデンティティプロバイダーを使用してサインインする**連携ユーザー**に割り当てることができます。

IAMロールには2種類のポリシーが含まれています：空にできない信頼ポリシー（誰がロールを仮定できるかを定義）と空にできない権限ポリシー（アクセスできるものを定義）。

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

AWSセキュリティトークンサービス（STS）は、一時的で限られた特権の資格情報の発行を容易にするWebサービスです。これは特に以下に適しています：

IAMでの一時的な資格情報

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

ポリシー

ポリシーの権限

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

  • AWS管理ポリシー（AWSによって事前に構成された）

  • カスタマー管理ポリシー：ユーザーによって構成されます。AWS管理ポリシーを基にポリシーを作成できます（それらの1つを変更して独自のポリシーを作成する）、ポリシージェネレーター（許可と拒否の権限を助けるGUIビュー）を使用するか、独自のポリシーを作成するかを選択できます。

デフォルトではアクセスが拒否され、明示的なロールが指定されている場合にのみアクセスが許可されます。 単一の"Deny"が存在する場合、"Allow"がオーバーライドされますが、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"}
}
}
]
}

ここ には、任意のサービスで使用できる条件に使用できるグローバルフィールドが文書化されています。 ここ には、サービスごとに使用できる条件に使用できる特定のフィールドが文書化されています。

インラインポリシー

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

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

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

主体に明示的な拒否がない場合、かつリソースポリシーがアクセスを許可している場合、アクセスが許可されます。

IAM 境界

IAM 境界を使用して、ユーザーやロールがアクセスできる権限を制限できます。これにより、異なるポリシーによってユーザーに異なる権限セットが付与されても、その操作は失敗します。

境界は、ユーザーにアタッチされたポリシーであり、ユーザーやロールが持つことができる最大レベルの権限を示すものです。したがって、ユーザーが管理者アクセス権を持っていても、境界が彼が S3 バケットを読むだけと示している場合、それができることの最大限度です。

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

セッションポリシー

セッションポリシーは、ロールが仮定されるときに設定されるポリシーです。これはそのセッションのための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 に外部のアイデンティティプロバイダーからのユーザーが AWS リソースにアクセスできるようにするためのもので、有効な IAM ユーザーアカウントから AWS ユーザー資格情報を提供する必要がないようにします。 アイデンティティプロバイダーの例としては、独自の企業のMicrosoft Active Directory（SAML 経由）やOpenID サービス（Google のような）が挙げられます。連携アクセスにより、それに含まれるユーザーが AWS にアクセスできるようになります。

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

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

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

AWS IAM Identity Center（AWS Single Sign-On の後継）は、AWS Identity and Access Management（IAM）の機能を拡張し、AWS アカウントとクラウドアプリケーションへのユーザーの管理とアクセスを一元化する中心的な場所を提供します。

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

ユーザーをログインさせるために使用できる 3 つのアイデンティティソースは次のとおりです：

  • Identity Center Directory: 通常の AWS ユーザー

  • Active Directory: 異なるコネクタをサポート

  • External Identity Provider: すべてのユーザーとグループが外部アイデンティティプロバイダー（IdP）から来る

Identity Center ディレクトリの最も単純なケースでは、Identity Center にはユーザーとグループのリストがあり、それらに組み込まれたポリシーを組織のアカウントのいずれかに割り当てることができます。

Identity Center ユーザー/グループにアカウントへのアクセス権を与えるためには、Identity Center を信頼する SAML アイデンティティプロバイダーが作成され、宛先アカウントには指定されたポリシーを持つアイデンティティプロバイダーを信頼するロールが作成されます。

AwsSSOInlinePolicy

IAM Identity Center で作成されたロールにインラインポリシーを通じて権限を与えることが可能です。AWS Identity Center でインラインポリシーを持つアカウント内のロールは、**AwsSSOInlinePolicy**というインラインポリシーでこれらの権限を持ちます。

したがって、AwsSSOInlinePolicy というインラインポリシーを持つ 2 つのロールを見たとしても、同じ権限を持っているわけではないことに注意してください。

クロスアカウントの信頼とロール

ユーザー（信頼する側）は、一部のポリシーを持つクロスアカウントロールを作成し、別のユーザー（信頼される側）に新しいロールポリシーで指定されたアクセス権を持つアカウントにアクセスを許可することができます。これを作成するには、新しいロールを作成し、クロスアカウントロールを選択します。クロスアカウントアクセス用のロールには、所有する AWS アカウント間のアクセスを提供するオプションと、所有するアカウントとサードパーティ AWS アカウントとの間のアクセスを提供するオプションがあります。 信頼されるユーザーを明示的に指定し、一般的なものを指定しないようにすることが推奨されます。そうしないと、他の認証済みユーザー（フェデレーテッドユーザーなど）もこの信頼を悪用できる可能性があります。

AWS Simple AD

サポートされていない機能：

  • 信頼関係

  • AD 管理センター

  • 完全な PS API サポート

  • AD リサイクル ビン

  • グループ管理サービス アカウント

  • スキーマ拡張

  • OS やインスタンスへの直接アクセスはできません

Web Federation または OpenID 認証

アプリケーションは、一時的な資格情報を作成するために AssumeRoleWithWebIdentity を使用します。ただし、これにより AWS コンソールへのアクセスは許可されず、AWS 内のリソースにのみアクセスできます。

その他の IAM オプション

  • 最小長やパスワード要件などのパスワードポリシー設定オプションを設定できます。

  • 現在の資格情報に関する情報（ユーザー作成時刻、パスワードが有効かどうかなど）を含む**「資格情報レポート」をダウンロードできます。クレデンシャル レポートは最大で 4 時間ごと**に生成できます。

AWS Identity and Access Management（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 ...

参照

htARTE（HackTricks AWS Red Team Expert）で**ゼロからヒーローまでAWSハッキングを学ぶ**

HackTricksをサポートする他の方法:

前へAWS Pentesting次へAWS - Federation Abuse

最終更新