AWS IAMのアカウント管理の仕組みを理解しよう！

AWS IAM

概要

AWS Identity and Access Management (IAM) は、AWSリソースへのアクセスを管理するためのサービスです。IAMを使用することで、ユーザーやグループの認証と認可を行いAWSリソースへのアクセスを制御できます。これにより適切なセキュリティが確保され、リソースへの不正アクセスを防ぐことができます。また複数のAWSアカウントを一元管理するために、AWS OrganizationsとIAMを連携させることでクロスアカウントのアクセス管理や一貫したセキュリティポリシーの適用が可能になります。

認証と認可

ここで認証と認可という言葉が出てきたので簡単に解説をします。認証はユーザーが誰か？を確認する行為であり、認可はそのユーザーが特定の動作を許可されているか？を確認する行為です。運転免許証に例えると、認証とは顔写真で本人かどうかを確認すること、認可とはどのような車種を運転できるか（普通自動車、バイク、大型車など）を確認することに相当します。つまりIAMは誰にどのような行為を許可/禁止するかを設定する機能と言えます。

基本的な用語

次のセクションで具体的な仕組みを説明する前にIAMに関する基本的な用語を押さえておきましょう。以下の用語を理解することでIAMの仕組みが分かりやすくなると思います。

• プリンシパル
  • AWSリソースに対しアクションや操作のリクエストを行うことができる人、アプリケーション、フェデレーテッドユーザー（IAMで管理されていない外部ユーザー）、ロールのことを指します。
• ユーザー
  • AWSリソースにアクセスする個別の人やアプリケーションを表します。各ユーザーには固有の認証情報（パスワード、アクセスキーなど）が割り当てられます。
• グループ
  • 複数のユーザーをまとめて管理するためのコンテナです。グループに付与されたアクセス許可は、そのグループに属するすべてのユーザーに適用されます。例えば、開発者用グループ、管理者用グループ、監査用グループなどを作成してユーザーを割り当てます。
• ロール
  • 一時的に特定のアクセス許可を付与するためのIAMエンティティです。ロールは特定のAWSリソースにアクセスするための権限を持ち、ユーザーやAWSサービスがロールを引き受けることで、その権限を一時的に利用できます。
• 信頼されたエンティティ
  • 帽子を被ることができる対象を制限する機能、ロールを信頼されたエンティティ⇒帽子を被ることができる対象を制限する機能
• ロールを引き受ける（Assume Role）
  • IAMロールを特定の対象（ユーザーやAWSサービス）にアタッチすることを指します。
• ポリシー
  • アクセス許可のルールを定義するドキュメントです。ポリシーにはどのアクションがどのリソースに対して許可されるかまたは禁止されるかが記述されており、これをユーザー、グループ、ロールにアタッチすることでアクセス制御を行います。

IAMの仕組み

IAMグループとIAMロール

IAMグループとIAMロールはAWSリソースへのアクセス制御を効率的に行うための異なる方法を提供します。IAMグループは、ユーザー管理とアクセス許可の簡素化のために使用し特定の職務やチームに基づいた一貫したアクセス制御を提供します。一方でIAMロールは一時的なアクセス権の付与、クロスアカウントアクセスの管理、AWSサービス間のアクセス権管理に使用します。

上記の文章だと違いがイメージしにくいかと思いますので、例え話で役割の違いを説明します。あるアーティストのファンクラブ会員制度とチケット購入を想像してみましょう。ファンクラブ会員は入会も退会も手続きがあるので面倒ではありますが、限定ライブや限定グッズの購入などの特典を得ることができます。一方で、一般の方はライブチケットを購入してライブに参加することになりますが、チケットではライブに参加する以外に特典はなく限定的なサービスが提供されます。

このときのファンクラブ会員がIAMグループ、ライブチケットがIAMロールになります。つまり、特定の集団に対する権限を長期的な管理をする場合はIAMグループを使用し、特定の役割に対する短期的な管理をする場合はIAMロールを使用することになります。

ポリシーの分類

ポリシーを考える観点として、①アクセス許可を付与、②アクセス許可の上限を設定の２点があります。

アクセス許可を付与

まず1点目の観点についてです。IAMで扱うポリシーはJSON形式で表現されてますが、アイデンティティベースポリシー（アクセスする側につけるポリシー）とリソースベースポリシー（アクセスされる側につけるポリシー）の２つがあります。一見するとアクセスする側、アクセスされる側の両方に権限をつけることは煩雑な印象を持つかもしれませんが、これは多層防御を実現するためであり2つのポリシーを組み合わせることでより強固なアクセス管理を実現しています。（引用元はこちら）（これについてはAWS トレーニングの講師の方が仰っていました）

AWS, ポリシーの評価論理

アクセス許可の上限を設定

続いて2点目の観点についてです。ここで重要な用語はアクセス許可の境界（permissions boundary）とAWS Organizations サービスコントロールポリシー（SCP）になります。

まずアクセス許可の境界ですが、これはIAMユーザーまたはロールにアタッチされた特別なポリシーで、許可されるアクションの「最大限の範囲」を定義します。アクセス許可の境界は、IAMユーザーやロールが実際に持つことができるアクセス許可の範囲を制約する「上限」を設定するものです。これは、通常のIAMポリシーと組み合わせて使用されます。イメージは下記のようになります。

AWS, ポリシーの評価論理

続いて2つ目のSCPについてです。これはアカウントを組織単位(OU)でグループ化して、階層を作成するサービスコントロールポリシー(SCP)を適用して、OU配下の各アカウントのアクセス許可の上限をコントロールすることができます。（引用元はこちら）

AWS, ポリシーの評価論理

このように図で見てみると、権限の範囲はアイデンティティベースポリシーとリソースベースポリシーはORの関係、アイデンティティベースポリシーとアクセス許可の境界、アイデンティティベースポリシーとSCPはANDの関係にあることがわかります。

評価プロセス

では最後にこれまで出てきたポリシー（アイデンティティベースポリシー、リソースベースポリシー、アクセス許可の境界、SCP）がどのような順番で評価されるかを見ていきます。結論を申し上げると下図を理解しておくとよいでしょう。簡単に説明をすると明示的なDeny＜ 明示的なAllow ＜暗黙的なDenyで評価され、明示的なAllowについては下図の順番となります。 もっと詳しく知りたい方はこちらのブログや公式ドキュメントをご参考ください。

Academaid, 【AWS初学者向け】IAMポリシーの評価ロジックを逃げずに理解する

まとめ

本記事ではIAMに関する基本的な概念を説明しました。初めて触れる方にとっては取っつきにくい概念が多いかと思いますが、しっかりとしたAWS運用を行っている環境ではIAMの理解は避けて通れないと思います。少しずつでもIAMの理解を進めて権限管理を意識してAWSを活用できるようになりましょう！