すのふら

すのふら

日々の備忘録

トップ > AWS > AWS Identify and Access Management(IAM)について勉強

AWS Identify and Access Management(IAM)について勉強

AWS

AWS 認定ソリューションアーキテクト ? アソシエイトを受けるため、改めてAmazon Web Service(AWS)の勉強をする。

今回もこの本を一読したうえで機能単位で勉強していく。

徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書

徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書


AWS Identify and Access Management(IAM)

AWSリソースをセキュアに操作するために、認証・認可の仕組みを提供するマネージドサービス。

  • EC2など各AWSリソースに対して別々のアクセス権限をユーザやリソースなどに付与できる
  • 多要素認証（MFA）によるセキュリティの強化
  • 一時的な認証トークンを用いた権限の委任
  • ほかのIDプロバイダーで認証されたユーザにAWSリソースへの一時的なアクセス
  • 世界中のAWSリソースで同じアイデンティティと権限を利用可能（高可用性）。リクエストが通らない場合は時間を置くと通るようになる
  • 無料サービス


ルートユーザ

AWSのアカウントを作ったときに払い出されるユーザのこと。
アカウントすべてのAWSサービスとAWSリソースすべてに完全なアクセス権限を持つ。
第三者に奪われたら自由にアカウントを使われてしまうので極力使用しない。
別途アドミニストレータ権限を持ったIAMユーザを作成する。

ルートユーザはパスワードポリシーが適用されない。

IAMユーザ

AWSで作成されるエンティティユーザ。
名前と認証情報（コンソール上に打ち込むパスワード、アクセスキー）

IAMユーザを作成するメリット


認証情報を個別に変更（キーやパスワードのローテーション）が可能
アクセス許可をいつでも変更無効化できる（乗っ取られてもすぐに無効化できる）
運用監視やガバナンス、コンプライアンスの観点からどのようなアクションを行ったのか、Amazon CloudTrailのログからIAMユーザを追跡することができる

IAMグループ

IAMユーザの集合をIAMグループという。

IAMロールや別のIAMグループをIAMグループに所属することはできない。
IAMユーザ：IAMグループ＝1：1～10
IAMグループに関連付けられたIAMポリシーは所属するIAMユーザに継承される。（ポリシーの許可拒否の仕組みは以下）


IAMロール

AWSサービスやアプリケーションなどのエンティティに対してAWSリソースの捜査権限を付与するための仕組み。
ユーザやアプリケーションがその権限のロール（役割）を一時的に担うというイメージ。
IAMグループやIAMユーザには紐づかない

複数のユーザがロールを引き受けることができる。

  • 別のAWSアカウントのIAMユーザやロールなど
  • Amazon EC2、AWS LambdaなどのAWSサービス
  • SAML2.0またはOpenID Connect(OIDC)と互換性があるIDプロバイダーによって認証された外部ユーザ（下記参照）

一時的なセキュリティ認証情報を利用して認証する。


一時的なセキュリティ認証情報

有効期限付きのアクセスキーIDとシークレットアクセスキー、セキュリティトークンで構成される認証情報。

特徴としては以下が挙げられる。

  • 短期的な有効期限（認証情報を取得する際に期限を設定）
  • 認証情報が不要になったときにローテーションしたり明示的に取り消す必要がない（ユーザ側に認証情報が保存されない）ので安全


認証情報はユーザのリクエストによって、AWS Security Token Service（STS）が動的に作成する。（以下を参照）


ポリシー

IAMアイデンティティやAWSリソース関連付けることでアクセス許可を定義することができるもの。
IAMユーザやIAMロールに対して、どのリソースのどんな権限を許可する/しないのかを設定できるもの。

アイデンティティベースのポリシーは主に以下

  1. 管理ポリシー
  2. インラインポリシー


管理ポリシー

複数のIAMユーザ、IAMグループ、IAMロールにセット可能（MAX10個）
ポリシーを作って、IAMユーザ（ロール）にセットするような形なので同じ権限が必要なユーザであれば再利用可能
バージョニングとして過去世代を5世代分持っているので、合わない場合はロールバックできる
変更管理もできる。

大きく二つの管理ポリシーが存在する。

  1. AWS管理ポリシー
  2. カスタマー管理ポリシー


AWS管理ポリシー

AWS側がある程度、想定される権限をまとめたおすすめセットな管理ポリシー
AWS側が管理・更新しているので、編集はできないが、知見がなくても簡単にすぐに利用することができる。
AWS側管理のため別のアカウントでも同じ権限を利用することができる。


カスタマー管理ポリシー

自分好みにカスタマイズできる管理ポリシー。
自分で作成するため別アカウントに引継ぎして仕様できず、使用するなら別アカウントで作り直しになる。

AWS管理ポリシーに基づく要件を満たさない場合に使用する。


インラインポリシー

単一のIAMユーザ、IAMグループ、IAMロールに直接書き込むもののため、再利用ができない。
複数のIAMユーザを同じ権限でのインラインポリシーで管理する場合、2重メンテナンスになるので推奨されない。
基本的には管理ポリシーを利用する


ポリシーのアクセス要否の決定ロジック

すべてのアクセスはデフォルトで拒否されている（暗黙的なDeny）ため、ポリシーで明示的に許可（明示的なAllow）や明示的に拒否（明示的なDeny）をしてあげる必要性がある。
（特に書いてなければ基本的に拒否されているとみなしていい）

強さ：明示的なDeny＞明示的なAllow＞暗黙的なDeny

明示的なDenyをあえて書いているのは、IAMグループ上では明示的なDenyにしていて、IAMユーザでは明示的なAllowのことを指している。この場合は拒否される。


アクセス権の決定ロジック

単一アカウントの場合

AWS OrganizationのSCP（サービス管理ポリシー）とIAMポリシーは両方が許可されないとNG（AND条件）
リソースベースポリシー（S3バケットポリシーなど）とIAMポリシーは片方許可されていればOK（OR条件）

複数アカウントの場合

AWS OrganizationのSCP（サービス管理ポリシー）とIAMポリシーは両方が許可されないとNG（AND条件）
リソースベースポリシー（S3バケットポリシーなど）とIAMポリシーは両方が許可されないとNG（AND条件）


認証


MFA（Multi-Factor Authentication 多要素認証）

ルートユーザーやIAMユーザの各IDに個別のMFA設定が可能

IAMポリシーにMFAがされているかどうかを判断することも可能。機密性の高い場合には付けておくとよい。
主な対象は以下


AWS Security Token Service（STS）

IAMロールを使用した際に一時的なセキュリティ認証情報を生成するサービス。
有効期限付きのアクセスキーIDとシークレットアクセスキー、セキュリティトークンで、トークンの種類によって有効期限が様々。

発行してしまった認証情報の期限変更は不可能。

グローバルサービスのためSTSエンドポイントは全リージョンに使用可能。


監視

AWS CloudTrail

コンプライアンスチェックやガバナンスチェック、運用中の管理などでAWSのリソースに対して誰がいつどこでなにをしたということが確認できる。
また管理コンソール画面でのログインの成功や失敗も取得できる。

誰が：APIを呼び出した身元（IAMユーザなど）
いつ：APIを呼び出した時間
どこで：API呼び出し元のSource IP
なにを：呼び出し先のAPI・APIの対象となるAWSリソース

AWS Config

IAMユーザ、グループ、ロール、ポリシーなどのAWSリソースの設定の履歴情報を持つ。
（ユーザが何かをしたかというログ記録情報ではなく、あくまでリソースの変更履歴の情報となる）


ロールを使用したアクセス許可の委任

別アカウントのユーザが自分のアカウントリソースにアクセスしたい場合がある。

ユースケースは、

  1. IAMロールによるクロスアカウントアクセス
  2. クロスアカウントアクセスによる権限管理の効率化
  3. SAML2.0のIDフェデレーション
  4. SAML2.0ベースのAWSマネジメントコンソールへのシングルサインオン（SSO認証）
  5. Amazon Cognitoを用いたモバイルアプリの Web IDフェデレーション


IAMロールによるクロスアカウントアクセス

例えば開発アカウントのユーザーに対して本番環境のS3権限を与えたい場合、本番環境側にIAMロールを設定し開発アカウントのユーザに紐づけることで一時的に接続が可能になる。


クロスアカウントアクセスによる権限管理の効率化


SAML2.0のIDフェデレーション

Active DirectoryなどのIdentity Provider(IdP)情報を使用してAWSにアクセスする方法。

組織内の全員をIAMユーザを作成しなくても、ユーザはオンプレミス上のIdP認証情報を経由して利用することができる。

メリットはアカウント管理が統合されてリスクが低減するという点になる。

  • 既存のユーザ情報をそのまま利用できる
  • 既存の権限ベースで管理できる（権限のはく奪など）
  • 既存と同様のアカウントロックポリシーや、パスワード管理ポリシーを利用した状態でのAWS利用が可能
  • 入退社などの一元管理が可能
  • イントラネットなどからのみアクセス可能なログイン画面を用意できる


Amazon Cognitoを用いたモバイルアプリの Web IDフェデレーション

モバイルアプリから一時的なAWSセキュリティ認証情報を必要に応じて動的にリクエスト。
GoogleやFacebookやTwitter、Amazon Cognito及びOpenID Connect(OIDC)準拠のIdPに対応

snofra 読者になる

広告を非表示にする
コメントを書く