Zenn
🎄

Who am I? ~what is IAM?~

2022/12/04に公開
AWS
IAM
tech

こんにちは。最近AWS Certified Security - Specialtyの取得に向けて勉強をしている@ten_takanoです。

ACCESS Advent Calender 2022 4日目のこの記事は、AWS Certified Security - SpecialtyにちなんでIAMについて勉強したことをまとめていこうと思います。

IAMってなんだ？

一度でもAWSを利用したことがある方であればIAMという文字列は見たことがあるのではないでしょうか。IAMはAWSにおいてアカウントを認証する大切な仕組みのことで、これを理解することでどのようにAWSの操作が行われるのか、どうすれば行動を制限することができるのかを把握することができます。ちなみに読み方はアイアムのようです。(公式の解説動画で講師の方がアイアムと言っていたのできっと間違いありません。)

イメージとしては、他のWebサービスで言うところのアカウントに相当するような概念です。しかし、AWSではアカウントというとIAMをまとめたテナントと呼ばれるようなものを指すことになっていて、他のWebサービスとは異なる命名がされています。

AWSでアカウントを作成すると、このテナントとrootユーザーが生成されます。rootユーザーは支払いを含むすべての操作が可能なアカウントのため、万が一にもログイン情報が流出してしまうと大変なことになってしまいます。そこで、手動またはプログラムによって何かしらのAWSのサービスに対する操作を行うためにIAMユーザーを作成していくのです。

なんだ簡単じゃないか。記事にするほどでもないな？

そんなことはありません。「IAM = 普段遣いのユーザー」という関係ではないからです。 前の章では意図的に「IAM」と「IAMユーザー」という言葉を明確に使い分けています。それはIAMユーザーはIAMの一種だからなのです。実際にはIAMユーザー・IAMグループ・IAMポリシー・IAMロールという単語が登場します。

よくこれらは並べて解説されているのですが、実はIAMポリシーだけが異質な存在です。無理やり分類すると下記のような関係になります。

  • 権限(ルール)適用の単位
    • IAMユーザー
    • IAMグループ
    • IAMロール
  • 適用するルール
    • IAMポリシー

では、それぞれどのようなものなのか見ていきましょう。

IAMポリシー

いきなりですが、IAMポリシーについてまずは理解しましょう。名前だけ見ると他のものと混ざってしまいますが、IAMポリシーの実態は、「誰になんの権限を与えるか」をまとめたものになっています。実体はJSONになっていて、例えば以下のような形です。

{
    "Version": "2022-12-01",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::123456789012:user/someone"},
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": "*"
        }
    ]
}

いきなりJSONだけ見るとびっくりしてしまうかもしれませんが、内容はとても簡単です。"Principal"で指定したIAMユーザーに "Action" (ここではS3のオブジェクト、そしてそれらの一覧取得)を "Allow" しています。そしてこのルールは "Resource" が対象となっています。(ここでは全てが対象となっています。)

これをIAMポリシーとよび、IAMユーザーやIAMグループ、IAMロールといった操作をする主、あるいは操作を受けるリソースに対してアタッチします。(操作をする主にアタッチをする場合には、"Principal"で指定する対象が自明になるので省略されます)

ちなみに、Principalに記載されているarnから始まる文字列はARN(Amazon Resource Name)と呼ばれるもので、あらゆるリソースに割り振られている一意な名前です。

IAMユーザーやIAMグループ、IAMロールと言った、操作をする主にアタッチするIAMポリシーのことをユーザーベースのポリシーとよび、対してリソースに対して適用するIAMポリシーのことをリソースベースのポリシーと呼ぶようです。

また、"Effect"については、Denyを指定することも可能なようですが、基本的に拒否されているものを許可する形を取っているので、明示的に指定することはほぼないと公式ドキュメントに書いてありました。曰く、「あらゆる手段を取ってなお実現できない最終手段として利用すべき」だそうです。

IAMユーザー

IAMユーザーは前述の通り、AWSのサービスを利用するユーザーにあたります。ちなみに、rootユーザーはどうやらIAMユーザーとは言わない(IAMユーザーに含まれない)ようです。

IAMグループ

IAMユーザーがどういうものか理解したところで、IAMユーザーを作成して、権限を割り当てることを想像してみましょう。AWSはかなり細かく権限の制御ができるため、特定のリソースへの読み込み、書き込みといった単位での制御が可能です。IAMユーザーやリソースがたかだか数個程度であれば特に問題はないでしょう。

では、何百何千とIAMユーザーを発行した場合にはどうでしょうか？それも、一回作れば終わりではなく、定期的にユーザーの追加や削除を行わなければならないような場合。とてもではないですが、手動でIAMユーザーそれぞれに権限を手作業で割り当てていくのは現実的ではありません。

大抵の場合、ユーザーはグループ化することができると思います。例えばサービスの管理者のグループやサービスを利用するユーザーのグループです。こういったグループを作るための機能がIAMグループなのです。権限の割当はIAMグループに対して行うことができるので、同じ作業を繰り返すことで特定のIAMユーザーだけ権限をつけ忘れたorつけすぎたと言った事故を防ぐことができます。また、IAMグループを設定するだけで、権限の割当が行えるので、煩雑な設定を1ステップで済ませることができるようになります。

IAMロール

IAMロールは独特な機能で、直感的に理解できないかもしれません。(僕も最初理解できませんでした)

IAMロールとは、特定の権限をもった役割をユーザーやサービス自体に与える機能です。AWSのドキュメントでは帽子のマークで図に登場します。マークの通り、特定のユーザーやサービス自体に帽子を被せて操作が許可されていることを主張するようなイメージです。(個人的には帽子よりもオフィスなどで入退室を行うためのセキュリティカードのイメージのほうがしっくり来ています。)

このIAMロールの特徴は、IAMユーザーだけでなく、AWSサービス自体に付与することができるという点です。例えば、あるEC2インスタンスにIAMロールを付与してしまえば、そのEC2インスタンスがどのIAMユーザーを利用したとしても、IAMロールで設定された権限を持つことができます。(たとえ利用しているIAMユーザーがそのIAMロールを利用できなかったとしても)

また、このIAMロールはアカウントを越えて付与することもできます。 隣の会社に入ることができるセキュリティカードを貸与されているようなイメージですね。

IAM完全に理解した

以上が僕がこれまでに勉強したIAMの知識をまとめたものです。これで権限管理はバッチリと思いきや、実は権限管理を行うためにはIAMだけでなくSCP(Service Control Policy)なるものや、OU(Organization Unit)といった概念も登場し、問題は複雑になっています。

SCPはIAMポリシーと同じく権限の管理を行うためのものです。そしてSCPはIAMポリシーを置き換えるものではなく、共存するものなのです。つまり、IAMポリシーとSCP両方で制限を行うため、IAMポリシーだけを見ていると、予期しない動きとなることがあります。実際に許可される操作は、IAMポリシー・SCP両方で許可されている必要があるのです。

最後にもう少しだけ、SCPとOUについて補足します。

OUとSCP

OUはIAMユーザー(AWSアカウントの間違いでした)をまとめて階層構造を作ることができるもの、SCPはOUまたはOUのメンバに適用するルールです。OUはその名前の通り、組織単位で、階層構造を作ることができます。会社組織がまさにそのままのイメージです。

階層構造を作ることができるということにももちろん意味があります。OUに適用されたSCPは下位組織にも引き継がれます。そして、SCPがIAMポリシーと異なる点として、rootユーザーさえもSCPのルールが適用されるのです。

まとめ

  • IAMにはIAMユーザー・IAMグループ・IAMロール・IAMポリシーがある。
  • 用途の数だけIAMユーザーとIAMポリシーを作らなくても、IAMグループやIAMロールを使えばもっと単純に権限を付与できる。
  • 権限はIAMポリシーとSCPで管理する
  • SCPはOUに適用する。OUは階層構造をもつことができて、上位組織のSCPは下位組織にも適用される。

以上で今回の内容は以上です。この内容で権限周りは網羅できたかというと、実はそうではなくて、IDフェデレーションやActiveDirectory、OAuth周りの外部のユーザー管理との協調関係もあるのですが、AWS内で完結するものについては網羅できているかなと思っています。(そうじゃなかったら泣きたい)
また勉強が進んで内容が整理する機会があればまとめようかなと思っています。

明日は @kiito1000 さんの記事です。お楽しみに！

参考にさせていただいたページ・書籍

Discussion