AWS - 基本情報

Reading time: 36 minutes

組織階層

アカウント

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

Service Control Policy (SCP)

サービスコントロールポリシー (SCP) は、SCPが影響を与えるアカウント内でユーザーとロールが使用できるサービスとアクションを指定するポリシーです。SCPはIAM権限ポリシーに似ていますが、権限を付与することはありません。代わりに、SCPは組織、組織単位 (OU)、またはアカウントの最大権限を指定します。SCPを組織のルートまたはOUにアタッチすると、メンバーアカウント内のエンティティの権限が制限されます。

これはルートユーザーでさえ何かをするのを止める唯一の方法です。例えば、CloudTrailを無効にしたり、バックアップを削除したりするのを止めるために使用できます。
これを回避する唯一の方法は、SCPを設定するマスターアカウントも侵害することです（マスターアカウントはブロックできません）。

SCPの例：

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

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

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

• GuardDuty、CloudTrail、およびS3のパブリックブロックアクセスを無効にすることを拒否

• セキュリティ/インシデントレスポンスロールの削除または

変更を拒否。

• バックアップの削除を拒否。
• IAMユーザーとアクセスキーの作成を拒否。

JSONの例は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を変更することです。

RCPの例：

• S3バケットを制限し、あなたの組織内のプリンシパルのみがアクセスできるようにする
• KMSキーの使用を信頼された組織アカウントからの操作のみを許可するように制限
• SQSキューの権限を制限し、不正な変更を防ぐ
• Secrets Managerのシークレットにアクセス境界を強制し、機密データを保護する

例はAWS Organizations Resource Control Policies documentationで見つけてください。

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アカウントのルートユーザー

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

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

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

IAMユーザー

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

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

ユーザーは、コンソールを通じてMFAを有効にしてログインできます。MFAが有効なユーザーのAPIトークンはMFAによって保護されていません。ユーザーのAPIキーのアクセスをMFAを使用して制限したい場合は、特定のアクションを実行するために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>

以下の内容は、AWSにおける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"}
}
}
]
}

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

インラインポリシー

この種のポリシーは、ユーザー、グループ、またはロールに直接割り当てられます。そのため、他の誰も使用できるようにはポリシーリストには表示されません。
インラインポリシーは、ポリシーと適用されるアイデンティティとの間に厳密な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に外部のアイデンティティプロバイダーからのユーザーがAWSリソースに安全にアクセスできるようにし、AWSユーザー資格情報を有効なIAMユーザーアカウントから提供する必要がありません。
アイデンティティプロバイダーの例としては、独自の企業の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ユーザー
• 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プレフィックス

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

| 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を実行することによって構成できます。
そのファイルには、1つ以上のプロファイルを持つことができ、プロファイルが指定されていない場合、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をチェックできます。

一時的な資格情報の自動化

一時的な資格情報を生成するアプリケーションを悪用している場合、資格情報が期限切れになるたびにターミナルでそれらを更新するのは面倒です。これは、設定ファイルにcredential_processディレクティブを使用することで解決できます。たとえば、脆弱なウェブアプリがある場合、次のようにできます:

[victim]
credential_process = curl -d 'PAYLOAD' https://some-site.com

注意してください、資格情報は次の形式でSTDOUTに返されなければなりません:

{
"Version": 1,
"AccessKeyId": "an AWS access key",
"SecretAccessKey": "your AWS secret access key",
"SessionToken": "the AWS session token for temporary credentials",
"Expiration": "ISO8601 timestamp when the credentials expire"
}

参考文献

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html
• https://aws.amazon.com/iam/
• 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/