IAM アクセス管理

  • IAM アクセス管理は、アクセス許可とポリシーに関するすべてです。
  • 権限により、アクセス権を持つ人と、実行できるアクションを定義できます。
  • IAM ポリシーは、ポリシー所有者に付与されたアクセス許可を微調整するのに役立ちます。
  • IAM ポリシーは、1つ以上の権限を正式に示すドキュメントです。
  • 最も制限的なポリシーが常に勝つ
  • IAM ポリシーは JSON (JavaScript オブジェクト表記) 形式で定義されています。
  • IAM ポリシーは基本的に “条件 D が満たされると、リソース C に対してアクション B を実行するために、プリンシパル A の許可または拒否（効果）”

{
    “Version”: “2012-10-17”,
    “Statement”: {
       “Principal“: {“AWS”: [“arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root”]},
       “Action“: “s3:ListBucket”,
       “Effect“: “Allow”,
       “Resource“: “arn:aws:s3:::example_bucket”,
       “Condition“: {“StringLike”: {
           “s3:prefix”: [ “home/${aws:username}/” ]
              }
          }
    }
}
  • エンティティは複数のポリシーに関連付けることができ、ポリシーは複数のステートメントを持つことができ、ポリシー内の各ステートメントは単一のアクセス権を参照します。 ポリシーに複数のステートメントが含まれている場合、評価時に論理ステートメントがステートメント全体に適用されます。 同様に、要求に複数のポリシーが適用可能であれば、評価時に論理ORがポリシー全体に適用されます。
  • プリンシパルは、リソースベースのポリシーに対してポリシー内で指定することができますが、ユーザーベースポリシーの場合、プリンシパルはポリシーが関連付けられているユーザー、グループ、またはロールです。

ID ベース 対 リソースベース のアクセス許可

  • ID ベースまたは IAM のアクセス許可
    • IAM ユーザー、グループ、またはロールに ID ベースまたは IAM 権限がアタッチされ、ユーザー、グループ、またはロールが実行できる内容を指定します。
    • ユーザー、グループ、またはロール自体がプリンシパルとして機能する。
    • IAM アクセス許可は、ほとんどすべての AWS サービスに適用できます。
    • IAM ポリシーはインラインでも管理でもかまいません。
    • IAM ポリシーのバージョンは 2012-10-17 でなければなりません
  • リソースベースのアクセス許可
    • リソースベースのアクセス許可は、S3、SNS などのリソースに関連付けられています。
    • リソースベースのアクセス許可は、リソース (プリンシパル) へのアクセス権を持つ人と、それに対して実行できるアクション (アクション) の両方を指定します。
    • リソースベースのポリシーはインラインのみで、管理されません。
    • リソースベースのアクセス許可は、一部の AWS サービスでのみサポートされます。
    • リソースベースのポリシーは常にインラインポリシーにアタッチされ、管理されません。
    • リソースベースのポリシーは、バージョン2012-10-17 または 2008-10-17 で定義できます。

管理ポリシーとインラインポリシー

  • 管理ポリシー
    • 管理ポリシーは、AWS アカウントの複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンポリシーです。
    • 管理ポリシーは、ID (ユーザー、グループ、およびロール) にのみ適用されますが、リソースは対象になりません。
    • 管理ポリシーにより再利用が可能。
    • 管理ポリシーの変更はバージョン (5 に制限) として実装されており、既存のポリシーに新しい変更を加えると、必要に応じて変更を比較して元に戻すのに役立つ新しいバージョンを作成できます。
    • 管理ポリシーに独自の ARN がある。
    • 2種類の管理ポリシー:
      • AWS 管理ポリシー
        • AWS によって作成および管理される管理ポリシー。
        • AWS はこれらのポリシーを維持し、アップグレードすることができます。たとえば、新しいサービスが導入された場合、変更はポリシーに関連付けられている既存のすべてのプリンシパルに自動的に影響します。
        • AWS は、ポリシーを破らないように注意を払います。権限の削除の制限を追加する。
        • 管理ポリシーは変更できません。
      • 顧客管理ポリシー
        • 管理ポリシーはスタンドアロンであり、ユーザーが作成および管理するカスタムポリシーです。
        • カスタマー管理ポリシーでは、AWS 管理ポリシーを使用する場合よりも、ポリシーをより正確に制御できます。
  • インラインポリシー
    • インラインポリシーはユーザーによって作成および管理され、単一のユーザ、グループ、またはロールに直接埋め込まれます。
    • エンティティ (ユーザー、グループ、またはロール) またはリソースを削除すると、インラインポリシーも削除されます。

IAM ポリシーシミュレータ

  • IAM ポリシーシミュレーターは、IAM およびリソースベースのポリシーのテストとトラブルシューティングに役立ちます。
  • IAM ポリシーシミュレータは、次の方法をテストするのに役立ちます。
    • IAM ベースのポリシーをテストします。複数のポリシーがアタッチされている場合は、すべてのポリシーをテストしたり、テストする個別のポリシーを選択したりできます。特定のリソースに対して選択したポリシーによって許可または拒否されるアクションをテストできます。
    • リソースベースのポリシーをテストします。ただし、リソースベースのポリシーはスタンドアロンでテストできず、リソースにアタッチする必要があります。
    • ユーザー、グループ、またはロールにまだアタッチされていない新しい IAM ポリシーを、シミュレーターに入力またはコピーしてテストします。これらはシミュレーションでのみ使用され、保存されません。
    • 選択したサービス、アクション、およびリソースを使用してポリシーをテストする。
    • テスト対象のポリシーの条件要素に含まれる、IP アドレスや日付などのコンテキストキーを提供することにより、実際のシナリオをシミュレートします。
    • 特定のリソースまたはアクションへのアクセスを許可または拒否するポリシーの結果の特定のステートメントを識別します。
  • IAM ポリシーシミュレーターは実際の AWS サービス要求を行わないため、AWS ライブ環境に望ましくない変更を加えません。
  • IAM ポリシーシミュレーターは、許可または拒否された結果を報告するだけです。
  • IAM ポリシーシミュレーターを使用すると、ポリシーとテストを変更できます。これらの変更は、エンティティに関連付けられた実際のポリシーにさされません
  • ポリシーシミュレータ紹介ビデオ

IAM ポリシーの評価

許可が許可されているかどうかを判断するときは、フローに従います。

IAMポリシーの評価

  1. 評価は、リクエストが拒否されるという前提からスタートします。
  2. エンフォースメントコードは、リクエストに適用可能なユーザーベースおよびリソースベースのポリシーすべてを、リソース、プリンシパル、アクション、および条件に基づいて評価します。
    エンフォースメントコードによるポリシー評価の順序は重要ではありません。
  3. 前述のすべてのポリシーにおいて、リクエストに適応する明示的な拒否のインストラクションがエンフォースメントコードによって検索されます。
    適用される明示的な拒否が 1 つでも見つかると、コードは「Deny」の結果を返してプロセスが終了します。
  4. 明示的な拒否が見つからなかった場合、リクエストに適用され得る「Allow」のインストラクションがないか、エンフォースメントコードによって検索されます。
    明示的な許可が 1 つでも見つかると、コードは「Allow」の結果を返し、サービスはリクエストの処理を続けます。
  5. 許可が見つからない場合、最終結果は「Deny」となります。
    評価中にコードにエラーが発生すると、例外を生成して終了します。

IAM ポリシー変数

  • ポリシー変数は、ポリシー内のプレースホルダを指定する機能を提供します。
  • ポリシーが評価されると、ポリシー変数は要求自体からの値に置き換えられます。
  • ポリシー変数を使用すると、ユーザーのグループに1つのポリシーを適用して、たとえば、S3 バケットフォルダへのアクセス権を持つすべてのユーザーの名前のみを制御できます。
  • ポリシー変数は、$ プレフィックスの後に中かっこ ({}) を付けてマークします。${} 文字の中に、ポリシーで使用する要求の値の名前を入力します。
  • ポリシー変数は、バージョン2012-10-17 で定義されたポリシーでのみ機能します。
  • ポリシー変数は、Resource 要素でのみ使用でき、条件要素の文字列比較。
  • ポリシー変数は大文字小文字を区別し、aws:username、aws: userid、aws: SourceIp、aws: CurrentTime などのような変数を含みます。

AWS認定試験の練習問題

  • 質問はインターネットから収集され、答えは自分の知識と理解に基づいてマークされます（これはあなたと異なる場合があります）。
  • AWSサービスは毎日更新され、回答と質問はすぐに時代遅れになる可能性がありますので、それに応じて調査してください。
  • AWSのアップデートのペースを追うためにAWS試験の質問は更新されないため、基礎となる機能が変更されても質問が更新されないことがあります。
  • さらなるフィードバック、ディスカッション、修正を可能にします。
  1. IAM のポリシー評価ロジックは、常に、AWS アカウントのルートセキュリティ資格情報を使用するものを除き、すべての要求に対してデフォルトの ____________ で開始されます
    1. 許可
    2. 否定
    3. キャンセル
  2. 組織は、10 の IAM ユーザーを作成しました。組織は、それぞれの IAM ユーザーが別々の DynamoDB テーブルにアクセスできるようにしたいと考えています。すべてのユーザーが同じグループに追加され、組織はこのためにグループレベルのポリシーを設定したいと考えています。どのように組織はこれを達成することができますか?
    1. グループポリシーを定義し、IAM 名に基づくアクセスを許可する条件を追加します。
    2. IAM ユーザー名と同じ名前の DynamoDB テーブルを作成し、変数を使用して DynamoDB ARN に基づいてアクセスを許可するポリシールールを定義します。
    3. ユーザーごとに別個の DynamoDB データベースを作成し、DB 変数に基づいてグループ内のポリシーを構成する
    4. 異なる IAM ユーザーに異なる DynamoDB テーブルを許可するグループレベルのポリシーを設定することはできません。
  3. 組織は複数の IAM ユーザーをセットアップしています。組織は、各 IAM ユーザーが、外部からではなく、組織内でのみ IAM コンソールにアクセスすることを望んでいます。どのようにこれを達成することができますか?
    1. セキュリティグループで IAM ポリシーを作成し、そのセキュリティグループを使用して AWS コンソールログイン
    2. IP アドレス範囲が組織から外れた場合にアクセスを拒否する条件を持つ IAM ポリシーを作成する
    3. 組織の IP 範囲からのトラフィックのみを許可する EC2 インスタンスセキュリティグループを構成する
    4. VPC を使用して IAM ポリシーを作成し、組織と AWS コンソールの間でセキュアなゲートウェイを許可する
  4. 特定のエンティティに複数のポリシーをアタッチすることはできますか。
    1. はい、常に
    2. GovCloud 内の場合のみ
    3. いいえ
    4. VPC 内でのみ
  5. __________ は、1つ以上の権限の正式なステートメントを提供するドキュメントです。
    1. ポリシー
    2. 許可
    3. 役割
    4. リソース
  6. __________ は、ユーザー、グループ、またはロールなどのエンティティを1つ以上のリソースにアクセスできるようにする (または禁止する) という概念です。
    1. ユーザー
    2. AWS アカウント
    3. リソース
    4. 許可
  7. True または False: IAM を使用して RDS リソースへのアクセスを制御する場合、使用できるキー名は大文字小文字を区別します。たとえば、aws:CurrentTime は AWS:CurrentTime と同等ではありません。
    1. TRUE
    2. FALSE (参照リンク)
  8. ユーザーは、IP 10.10.10.1/32 からの要求があれば、すべての要求を許可する IAM ポリシーを設定しました。別のポリシーでは、午後5時から午後7時までのすべてのリクエストが可能です。ユーザーが午後6時に IP 10.10.10.1/32 からアクセスを要求している場合はどうなりますか?
    1. IAM はポリシーの競合に対してエラーをスローします
    2. 時間または IP に基づいてポリシーを設定することはできません。
    3. これは、アクセスを拒否する
    4. それはアクセスを許可する
  9. AWS ID およびアクセス管理のポリシー評価ロジックを使用した正しいステートメントは、次のうちどれですか。2つの回答を選択します。
    1. 既定では、すべての要求は拒否されます
    2. 明示的な許可は、明示的な拒否をオーバーライドします
    3. 明示的な許可は既定の拒否をオーバーライドします
    4. 明示的な拒否は明示的な許可をオーバーライドしません。
    5. 既定では、すべての要求が許可されます。
  10. Web デザイン会社は現在、250の顧客がアップロードし、大きなグラフィックファイルをダウンロードするために使用するいくつかの FTP サーバーを実行します。彼らは、このシステムをAWSに移行して拡張性を高めたいと考えていますが、顧客のプライバシーを維持し、コストを最小限に抑えたいと考えています。 どのようなAWSアーキテクチャをお勧めしますか？ [PROFESSIONAL]
    1. 顧客に FTP クライアントの代わりに S3 クライアントを使用するように依頼します。1つの S3 バケットを作成します。顧客ごとに IAM ユーザーを作成します。IAM ユーザーを、「ユーザー名」ポリシー変数を使用してバケット内のサブディレクトリへのアクセスを許可する IAM ポリシーを持つグループに配置します。
    2. 冗長ストレージが有効になっている単一の S3 バケットを作成し、顧客に FTP クライアントの代わりに S3 クライアントを使用するように依頼します。1人の顧客にのみアクセスを許可するバケットポリシーを使用して、顧客ごとにバケットを作成します。(各ユーザのバケットを作成すると、スケーラブルなモデルではない、また100バケットは、リンクを変更して以来、拡張することなく、以前の制限があります)
    3. Auto スケーリンググループの最小ネットワークトラフィックが指定されたしきい値を下回った場合に、スケーリングポリシーを使用して自動的にスケールインする FTP サーバーの自動スケーリンググループを作成します。各インスタンスのユーザーデータのスタートアップスクリプトの一部として、S3 から FTP ユーザーの中央リストをロードします (高額)
    4. リクエスタがオンになっている1つの S3 バケットを作成し、顧客に FTP クライアントの代わりに S3 クライアントを使用するように依頼します。バケットを作成する各顧客は、その1つの顧客にのみアクセスを許可するバケットポリシーを使用します。(各ユーザのバケットを作成すると、スケーラブルなモデルではない、また100バケットは、リンクを変更して以来、拡張することなく、以前の制限があります)

Jayendra’s Blog

この記事は自己学習用に「AWS IAM Access Management（Jayendra’s Blogより）」を日本語に訳した記事です。