アイデンティティ、リソース、境界

開発者のための AWS セキュリティ活用

Rahul Singh

Technical Product Manager

どのポリシーが優先されるのか？

何も変わらない編集

  • 第1章: 明示的な拒否、または許可の欠如
  • ここでは: 第3の原因

3つのポリシーチェックが重なり、判断すべき箇所に疑問符が付いたリクエスト。

開発者のための AWS セキュリティ活用

どのポリシーが優先されるのか？

最大3つの層

  1. 呼び出し元のアイデンティティポリシー
  2. リソース側のリソースポリシー
  3. 上位の境界、減算のみ

自分のアカウント内では、どちらか一方の許可で十分

いずれかの層で拒否されれば拒否

リクエストが上から下へ、アイデンティティポリシー、リソースポリシー、権限の境界の順に3つのチェックを通過し、許可という結果に至る様子。

開発者のための AWS セキュリティ活用

ポリシーが存在しうる2つの場所

アイデンティティベースポリシー

  • 呼び出し元にアタッチ
  • そのアイデンティティが実行できること
  • 身に着ける通行証

上部のロールがアイデンティティベースポリシーを持ち、下部には同じリクエストのリソース側のためのスペースがある図。

開発者のための AWS セキュリティ活用

ポリシーが存在しうる2つの場所

アイデンティティベースポリシー

  • 呼び出し元にアタッチ
  • そのアイデンティティが実行できること
  • 身に着ける通行証

リソースベースポリシー

  • リソースにアタッチ
  • 誰が操作できるか
  • クロスアカウントの呼び出し元に必要

上部のロールがアイデンティティベースポリシーを持ち、下部の S3 バケットがリソースベースポリシーを持ち、その間をリクエストが通過する図。

開発者のための AWS セキュリティ活用

あなたのために管理するか、あなたが管理するか

アイデンティティベースポリシーの2種類

  • AWS 管理: AWS が所有
  • カスタマー管理: 自分が所有

AWS が所有しデフォルトで広範な AWS 管理ポリシーと、自分が所有しタスクに応じて絞り込んだカスタマー管理ポリシーを比較する2枚のカード。

開発者のための AWS セキュリティ活用

あなたのために管理するか、あなたが管理するか

アイデンティティベースポリシーの2種類

  • AWS 管理: AWS が所有
  • カスタマー管理: 自分が所有

 

利便性か、精密さか

  • AWS 管理: 素早く進める
  • カスタマー管理: 最小権限

AWS が所有しデフォルトで広範な AWS 管理ポリシーと、自分が所有しタスクに応じて絞り込んだカスタマー管理ポリシーを比較する2枚のカード。

開発者のための AWS セキュリティ活用

境界がポリシーの付与範囲に上限を設ける

アカウントがこれをアタッチする理由

  • 開発者がロールを作成しても、権限昇格は起きない

権限の境界

  • ポリシーが付与できる範囲の上限
  • 実効権限: 両方で許可された範囲

アイデンティティポリシーが付与する3つの権限が、S3 操作のみを許可する権限の境界へと渡り、iam:CreateUser 権限は阻止され、残り2つは下部の実効権限へと続く図。

開発者のための AWS セキュリティ活用

境界がポリシーの付与範囲に上限を設ける

アカウントがこれをアタッチする理由

  • 開発者がロールを作成しても、権限昇格は起きない

権限の境界

  • ポリシーが付与できる範囲の上限
  • 実効権限: 両方で許可された範囲

iam:CreateUser が何も起こさなかった理由

  • 減算のみで、付与はしない

アイデンティティポリシーが付与する3つの権限が、S3 操作のみを許可する権限の境界へと渡り、iam:CreateUser 権限は阻止され、残り2つは下部の実効権限へと続く図。

開発者のための AWS セキュリティ活用

境界がポリシーの付与範囲に上限を設ける

アカウントがこれをアタッチする理由

  • 開発者がロールを作成しても、権限昇格は起きない

権限の境界

  • ポリシーが付与できる範囲の上限
  • 実効権限: 両方で許可された範囲

iam:CreateUser が何も起こさなかった理由

  • 減算のみで、付与はしない

セッションポリシー: 1回の AssumeRole セッション

アイデンティティポリシーが付与する3つの権限が、S3 操作のみを許可する権限の境界へと渡り、iam:CreateUser 権限は阻止され、残り2つは下部の実効権限へと続く図。

開発者のための AWS セキュリティ活用

条件が許可を絞り込む

条件キー

  • 許可をリクエストの文脈に絞り込む

  • aws:SourceIp: リクエスト元のネットワーク

S3 オブジェクトの読み取りを許可する1件が、送信元ネットワークキーと呼び出し元タグキーを列挙した条件帯を通過し、文脈が一致すれば許可、一致しなければ拒否へと分岐する図。

開発者のための AWS セキュリティ活用

条件が許可を絞り込む

条件キー

  • 許可をリクエストの文脈に絞り込む

  • aws:SourceIp: リクエスト元のネットワーク

  • aws:PrincipalTag: 呼び出し元のタグ

ABAC: 属性ベースアクセス制御

  • 1つのポリシーで複数のプリンシパルに対応

S3 オブジェクトの読み取りを許可する1件が、送信元ネットワークキーと呼び出し元タグキーを列挙した条件帯を通過し、文脈が一致すれば許可、一致しなければ拒否へと分岐する図。

開発者のための AWS セキュリティ活用

1つのテーブル、一度に1テナントずつ

1つの共有テーブル

  • DynamoDB、テナントごとに1つのパーティションキー
  • それ自体では分離にならない

テナント A の呼び出し元が leading keys 条件を通過して共有 DynamoDB テーブルに到達し、テナント A の行が返され、テナント B とテナント C の行はブロックされる図。

開発者のための AWS セキュリティ活用

1つのテーブル、一度に1テナントずつ

"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

1つの共有テーブル

  • DynamoDB、テナントごとに1つのパーティションキー
  • それ自体では分離にならない

1つの条件が絞り込む

  • ForAllValues: 指定されたすべてのキーが一致する必要がある
開発者のための AWS セキュリティ活用

1つのテーブル、一度に1テナントずつ

"Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:Scan"],
"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

1つの共有テーブル

  • DynamoDB、テナントごとに1つのパーティションキー
  • それ自体では分離にならない

1つの条件が絞り込む

  • ForAllValues: 指定されたすべてのキーが一致する必要がある
残る抜け穴: すべてのリクエストがパーティションを指定するわけではない
  • dynamodb:Scan は何も指定しないため、失敗しようがない
開発者のための AWS セキュリティ活用

練習しましょう！

開発者のための AWS セキュリティ活用

Preparing Video For Download...