Zenn
😊

イラストで理解するIAMロール

2023/06/21に公開
AWS
tech

はじめに

先日、AWSのアクセス制御についてのプレゼンを行いました。
その際、ポリシーが増える場合、どのように対応すれば良いですか？という質問を頂きました。

そこで、ポリシーを管理するためのIAMロールの説明がうまくできませんでした。
ポリシーやロールは普段から触ることも多いですが、そのメリットをちゃん理解できていなかったことを自覚しました。

そこで、AWSのIAMロール周りのことを聞かれて「ドキッ」とする、そんな私のような方は是非読んでみて下さい。

概要

この記事ではIAMロールの利点に焦点を当てているので、あまり細かい仕組みの説明はしておりませんので、あしからず。

ポリシー

ポリシーってなに？

そもそも、ポリシーってなんでしょう？
ポリシーがあって何がいいんでしょう？

では、まずポリシーがない状況を考えましょう。
ポリシー(権限)が無いと、誰でも、いつでも、なんでも、操作できるという状態です。

これでは困ります。
あなたの大事なパソコンも、データも全て他人が操作できる状態ということです。

では、これを回避するにはどうすればいいでしょう？
それがポリシーです。
ポリシーは「誰が」「どのような条件で」「何に対して」「どんな操作を」「許可 or 拒否」するかという設定です。

例えば、下の例では太郎君が9:00-17:00の間でEC2を起動、停止できるというポリシーです。

これを実際のポリシーに当てはめるとこんな感じになります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowStartAndStopEC2Instances",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "*",
            "Condition": {
                "DateGreaterThan": {"aws:CurrentTime": "2023-06-20T09:00:00Z"},
                "DateLessThan": {"aws:CurrentTime": "2023-06-20T17:00:00Z"}
            }
        }
    ]
}

このように、ポリシーを使うことでアクセスの制御ができるようになります。

ではここからポリシーを割り当て(アタッチ)していく例を見ていきます。

ポリシーとユーザー(1:1)

まずは一番簡単なパターンです。
学習用で使っているユーザーにフルアクセス権限を付与したものはこれが多いかもしれません。


特にアクセス管理は必要ありませんね。

ポリシーとユーザー(1:N or N:1)

では、ユーザー or ポリシーが少し増えました。
これはどうでしょう？

ユーザーやポリシーが増えると少し作業はありますが、片方が1なので
管理はそれほど面倒ではない気がしますね。

ポリシーとユーザー(N:N)

しかし、実際の運用ではこのパターンが多いでしょう。
ユーザーもポリシーも増えたり減ったりするパターンです。

さて、困りました。
みなさんならどうしたいですか？

ここで考えられるパターンは2つです

  • ポリシーをまとめる(IAMロール)
  • ユーザーをまとめる(ユーザーグループ)

この場合、AWSではポリシーをまとめるIAMロールを使うことが多いです。
(もちろんケースによります)

ポリシーはユーザーに直接アタッチできるのに、なぜIAMロールを使う必要があるのでしょうか？
確かにポリシーをまとめられるのは便利です。
しかし、それはユーザーグループも同じようにユーザーをまとめられます。

ではなぜIAMロールを使うのでしょうか？
それはIAMロールが他にもたくさん利点があるからです。

IAMロール

IAMロールは複数のポリシーを一つにまとめるられるサービスです。

しかし、IAMロールはそれだけではありません。
先にIAMロールの利点をまとめます。

  • リソースにもアタッチできる
  • 一時的に付与できる
  • アカウント間で使用できる

では一つずつ見ていきましょう。

リソースにアタッチできる

まず、リソース(資源)とはAWSのEC2やRDSのような各サービスのことを言います。
このリソースにはポリシーをアタッチできるものと、できないものがあります。

S3やLambdaはポリシーをアタッチできる代表的なサービスです。
EC2やRDSはポリシーを直接アタッチできないサービスです。

ではこのEC2やRDSはどのようにアクセス制御すればよいのでしょうか？
それがIAMロールです。

IAMロールはポリシーの入れ物のような働きをします。
その入れ物をEC2やRDSが使うといった感じです。

余談ですが、このように直接リソースにアタッチするポリシーを「リソースベースのポリシー」
IAMロールやIAMユーザーなどにアタッチするポリシーを「アイデンティティベースのポリシー」
と言います。

一時的な権限の付与

IAMロールを使うことで、ユーザーに対して一時的に特定の権限を割り当てることができます。
キーワードは「一時的」と「特定の」です。

例えば、あなたが管理者としてシステムを管理しています。
そこにエンジニアの方がやってきて、「データベースにデータ追加したいから権限ちょうだい」と言われました。

権限の発行、作業後の権限破棄、割り当てる権限の選定、etc...どれも面倒ですよね。
一回ならまだしも、これが複数回あると大変です。

そして、その人に悪気がなくても
もしかすると操作ミスでデータを削除する恐れもあります。
ということは特定の権限を割り当てる必要がありますね。

ここで活躍するのがIAMロールです！
IAMロールに特定のポリシーをアタッチして一時的にその権限を使うことができます。

これはAWS Security Token Service(STS)というサービスを使います。
STSは期限を持った認証情報を発行する役割を持っています。

では、 ユーザーがRDSにデータを追加する場合を考えてみましょう。
以下のような流れで認証情報を取得して、RDSの操作を行います。

  1. STSへ認証情報のリクエストを行なう
  2. STSがIAMロールへのアクセス権を持つ認証情報を返す
  3. 認証情報を元にIAMロールの権限を借りてRDSにデータを追加する
  4. 一定の時間が経つと認証情報が無効になる

このように、一時的に権限が必要になった！というケースはよくあると思います。
こんな時、IAMロールが使えると作成から削除までのライフサイクルが簡単に行えます。

アカウント間でのIAMロール

IAMロールを使うことでアカウント間の操作も楽になります。

まずは、IAMロールを活用しないパターンを見てみましょう。

あなたは複数のアカウントの管理者です。
「開発アカウント」と「運用アカウント」の各リソースを操作する必要が出ました。
では、どうすれば各リソースを操作できるでしょうか？

1つ考えられるのは、各アカウントにリソースを操作するためのユーザーを作る、です。

しかしこれは面倒ですね〜

ではIAMロールを活用するパターンを見てみましょう。

これは先ほどのSTSを使った一時的な認証の付与ですね。
各アカウント内のIAMロールへのアクセス認証情報を取得して、リソースを操作します。

矢印が多くなってややこしくなってしまいましたが、
こうすることで余計なユーザーを作る必要がなくなり楽になりました。

このようにIAMロールを使うことでアカウント間の操作も非常に楽になります。
子会社や顧客に一時的に特定の操作権限を渡すのもIAMロールを使えば安全にできますね。

IAMユーザーグループ

一応、IAMユーザーグループについても触れておきます。
こちらは「IAMユーザー」をまとめるために使われます。

ユースケースは、「開発チーム」や「運用チーム」などチームを分ける際に使うことが想定されます。
チームを分ける際に、あえて「開発チーム」という名前のIAMロールを作ることはないですね。

まとめ

どうでしょうか？IAMロールって思ってた以上にできることが多いですね。

IAMロールは調べてみるとかなり奥が深いです。
調べれば調べるほど分らないこということが分かりました。

STS周りが色々と気になったので、引き続き調べて別の記事として書こうと思います。

GitHubで編集を提案

Discussion