Zenn
Closed7

「AWS IAMのマニアックな話」を読む

AWS
IAM
はるはる

1・2章

AWS アカウント

  • 全サービスにどこからでも操作できる
  • IPアドレス制限など設定できない
  • MFAの設定を推奨
  • なるべく使わない

IAM ユーザー

  • 認証の種類
    • ID・パスワード (マネジメントコンソールへのログイン)
    • アクセスキーID・シークレットアクセスキー (API)
      • なるべくアクセスキーの発行はしない
      • 必要なときは最小権限で発行する
  • 利用者ごとに作成する
    • 人ごと、プログラムごとに作成し共通ユーザーは作成しない
    • 誰が何をしたの追跡ができなくなるため

IAM グループ

  • 同一の役割を持つIAMユーザーをグループ化する
    • IAMユーザーは複数のグループに所属可能
    • 権限はIAMユーザーではなくグループに付与することを推奨
    • インラインポリシーはな

インラインポリシー

  • 特定のユーザー、特定のグループのみで利用できるポリシー
  • 再利用ができないので原則利用しない

IAM ポリシー

  • IAM ポリシーの種類
    • AWS 管理ポリシー： AWS がデフォルトで提供
    • カスタマー管理ポリシー：ユーザーが作成したもの
  • 使い分け
    • 管理ポリシーで基本的な権限を割り当て、カスタマー管理ポリシー機能を制限する
      eg. AWS 管理ポリシーの AdministratorAccess で権限と、 IP制限をするカスタマー管理ポリシーを付与する

IAM ロール

  • AWS サービスやアプリケーションに対して AWS の操作権限を与える
    • アクセスキーIDやシークレットアクセスキーの設定が不要
    • Lamda や ECS などの個々のタスクに対して IAM ユーザーを割り振れないようなサービスに対しても利用できる

パーミッション・バウンダリー

  • IAM ユーザー または IAM ロールに対してアクセス制限する
  • IAM ユーザー・IAM ロールとパーミッション・バウンダリーの両方に付与された権限のみ有効になる
はるはる

3章

IAM ポリシーの作成

Version

言語構文ルールを指定する。
記載しないとデフォルトが採用されるため最新のものを明示することを推奨

  • 2008-10-17(デフォルト)
  • 2012-10-17

Statement

この中にポリシーを書いていく

  • Effect

    • Allow / Deny

  • Action

    • 対象のサービス
    • ワイルドカードを使用可能

  • Resource

    • 特定のリソースに限定知る場合
      • IAM ユーザー名
      • 特定のバケットなど

  • Condition

    • ポリシーの対象となる条件式を記述する

IAM ポリシーの重ねがけ

明示的な Deny > 明示的な Allow > 暗黙的な Deny (デフォルト)

クロスアカウントロール

特定のユーザーからスイッチできるロール
スイッチできるユーザーを制限するためには Principal を設定する
グループでの指定はできない

{
  "Version": "2012-10-17",
  "Statement": [
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::[AWSアカウントID]:user/[ユーザーID]"
     },
    "Action": "sts.AssumeRole",
  ]
}
はるはる

4章 IAM ポリシーのデザインパターン

ホワイトリストパターン

許可する権限のみ付与するパターン
業務・運用設計が確立している本番環境などに適用

メリット

  • 必要最小限の権限のみ付与するのでセキュリティの信頼性が高い

デメリット

  • 事前に役割が決まっていないと権限が付与できない
  • 新しいアクションが増えた場合につど追加する必要がある

ブラックリストパターン

許可しない権限のみ剥奪するパターン
開発環境などやり方を模索していくような場合に適用
IAM のデフォルトは暗黙的な Deny なので厳密にはブラックリストパターンでの運用は不可で、ハイブリットパターンを使って明示的な権限付与が必要になる。

メリット

  • 禁止事項のみを定義するので事前に役割が決まっていなくてもある程度自由に操作でき利用を開始できる

デメリット

  • サービスの追加、拡張によって予期せぬ機能が突然使えるようになる可能性がある

ハイブリットパターン

ホワイトリストパターンとブラックリストパターンの組み合わせ。
あらゆる環境で適用可能。

メリット

  • AWS 管理ポリシーによる権限の許可とカスタマー管理ポリシーによる権限の拒否を組み合わせることで最小限の労力でセキュリティを向上させることができる

デメリット

  • 特になし
はるはる

5章 IAMグループのデザインパターン

どちらもそれほど優劣はないので好みや組織形態に応じて

複数グループに所属するパターン

ユーザーが複数のグループに所属することを前提に権限を設定する

例
開発者
- 全ユーザー向けグループ
  - IPアドレス制限
  - パスワード変更権限
- 開発者向けグループ
  - EC操作権限

ネットワーク担当
- 全ユーザー向けグループ(IPアドレス制限、パスワード変更権限)
- ネットワーク担当者者向けグループ(VPC操作権限)

メリット

  • ポリシーが複数のグループから利用されることが少ないので、ポリシー変更の際の影響範囲がわかりやすい。
  • 必須の権限・制約を是ニューザー向けのグループに付与して、抜け漏れを防ぎやすくできる。

グループ内に複数ポリシー

ユーザーが1つのグループに所属することを前提に権限を設定する

例

開発者
- 開発者向けグループ
  - IPアドレス制限
  - パスワード変更権限
  - EC操作権限

ネットワーク担当
- ネットワーク担当者者向けグループ
  - IPアドレス制限
  - パスワード変更権限
  - VPC操作権限

メリット

  • ユーザーから見るとシンプルな構造になる。
  • ポリシーも多数のグループから利用されることが前提になるため、シンプルな設計につながる。
はるはる

6章 IAM とセキュリティ

  • IAM のベストプラクティスを遵守する。
    https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html
  • ルートユーザーは使わない
  • IAM に関する権限
    • 原則アカウント管理者以外には権限を与えない
    • パスワード変更とMFAの設定は許可する
  • Lamda のリソースベースの権限
    • AWSリソースのアクセス権を自由にコントロールできるので FullAccess ではなく必要最低限を付与する
  • インターネット公開系の権限
    • 多岐にわたるのでホワイトリストで管理するのが難しいので明示的な拒否を活用
  • VPC 内からのアクセス
    • パブリックIPしか使えない
    • VPC Endpoint などプライベートIPでアクセスする場合は VPC の ID を使う
  • アクセスキーを使わない
    • IAMロールを活用する
    • CLI についても作業用のEC2などを使う
はるはる

7章 IAM の運用

運用の目的

目的

  • AWS を安全な状態に保つ

考えるべきこと

  • 維持するための手間がかからない
  • 利用者によってセキュリティレベルのさいが出ないようにする

役割と責任範囲

  • 登場人物の洗い出し
    • 人
    • ツール
  • 役割の洗い出し
    • AWS アカウント管理者
    • 開発者
    • 運用担当者

AWS アカウントの管理

  • 原則使わない

IAM ユーザーの管理

  • 最小限の権限を付与
  • CloudTrail で利用ログを取得
  • Config を利用し、IAMの設定を監視
  • Config Rules で設定値を関し
  • 定期的な棚卸し
  • プログラム用の IAM ユーザは担当者を明確化する
  • 最終利用日から一定期間が過ぎた IAM ユーザーは継続を確認する
    • 使われていなければ 無効化 → 削除

アクセスキーの管理とCLI

  • 必要な IAM ユーザーのみ発行
  • 管理者権限付きのアクセスキーは特に注意
    • スイッチロールで IPアドレス制限を施す

MFA 未使用時に権限を制限する

  • MFA なしの場合は殆どの権限を剥奪する

マルチ AWS アカウントでの運用

  • IAM ユーザーを管理する踏み台 AWS アカウントを作成し、他のアカウントはロールとポリシーのみ作成
このスクラップは2023/11/18にクローズされました