IAM User / Roleとアクセス許可の設定

IAM
76件のシェア(ちょっぴり話題の記事)

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

渡辺です。

AWSの各サービスを最小限のリスクで運用するには、IAM(Identity and Access Management)の利用は必要不可欠です。IAMには様々な機能がありますが、基本となるUser, Group, Role, Policyを押さえることで、通常の運用についてはほとんどフォローすることができます。今回は、マネジメントコンソールを使ってIAM User / Group / Roleについての確認と、アクセス許可の与え方について解説します。

IAMを構成する基本要素

IAMでは大きく、User(ユーザ)とRole(ロール)の2種類のリソースを作成することができます。UserもRoleもAWSのリソースに対するアクセス許可を持つリソースですが、用途が異なります。また、Groupを作ることで複数のUserを同じアクセス許可を与えることができます。 はじめに、これらのIAMを構成する基本要素の概要を確認していきましょう。

User

User(ユーザ)は、AWSのマネジメントコンソールでの操作など、AWSを利用する人がAWSを操作する時に利用するIAMリソースです。

Userにはいくつかの認証情報が設定することができます。代表的な認証情報としては、マネジメントコンソールにログインするためのパスワードやMFA情報です。これらの認証情報があることで、はじめてマネジメントコンソールにログインすることができます。 また、Userには認証情報にはアクセスキーを設定することができます。アクセスキーとペアとなるシークレットキーを利用することで、ローカルPCなどマネジメントコンソールを使わずにAWSのリソースを操作することができます。

Userの権限には、マネジメントコンソールにログインしすべての操作を行えるように、管理者権限を与えることが多いかと思います。しかしながら、そのUserのアクセスキーとシークレットキーが漏洩した場合には、どんな環境からもAWSの全リソースを操作することができてしまうので注意して運用しなければなりません。

Group

Group(グループ)は、複数のUserに同一のアクセス許可を与えるIAMリソースです。 例えば、Adminグループを作成し、Management Policyで「AdministratorAccess」を与えておけば、各ユーザのアクセス許可を設定する代わりにAdminグループに追加するだけで、アクセス許可を与えることができます。

Role

Role(ロール)は、EC2インスタンスがAWSを操作する時に利用するIAMリソースです。

EC2インスタンスには、Userのアクセスキーを設定する事で、Userのアクセス許可の範囲で、AWSリソースを操作できるようになります。しかし、EC2インスタンスが増えた場合などアクセスキーとシークレットキーの管理が煩雑になり、ファイルに保存することなどから漏洩のリスクも出てきます。一方、Roleを利用することで、EC2インスタンス自体にアクセス許可を持たせることができます。このため、アクセスキーとシークレットキーの管理から解放されます。

Roleを設定できるのは、EC2をLaunchするタイミングだけです。既に起動しているEC2インスタンスのRoleを変更することや、新しく与えることはできません。Roleを変更(追加)したい場合は、EC2インスタンスをAMIから再構築する必要があります。

なお、Roleは主にEC2インスタンスにアクセス許可を与える時に利用しますが、EC2インスタンス以外にも適用することもあります。

アクセス許可を構成するPolicy

Policy(ポリシー)は、User,Group, Roleに与えるAWSリソースへのアクセス許可(Permission)です。 Policyには、Management Policy(管理ポリシー)とInline Policy(インラインポリシー)のふたつがあり、これらを設定することでアクセス許可を与えます。

Management Policy

Management Policy(管理ポリシー)は、AWSが提供する代表的なPolicy(管理者権限、EC2フルアクセスなど)と利用者が作成するカスタムポリシーがあります。どちらの場合も、Management PolicyはUserやRoleに与えることができるため、なんらかのPolicyを幾つかのUserやRoleで再利用する場合に便利です。 よく使われるManagement Policyとしては、次のようなものがあります。

  • AdministratorAccess (管理者権限)
  • ReadOnlyAccess (読み込み権限)
  • AmazonEC2FullAccess (EC2に関する全権限)
  • AmazonS3FullAccess (S3に関する全権限)
  • AmazonS3ReadOnlyAccess (S3に関する読み込み権限)

特定の範囲での権限をざっくりと与えたいのであれば簡単に利用できて便利です。

Inline Policy

Inline Policy(インラインポリシー)は、細かくアクセス許可を設定できますが、各Userや各Roleに直接設定するため、再利用はできません(Groupに設定した場合は、属するUser全体に適用できます)。

Inline PolicyはPolicy DocumentにJSON形式で記述します。 Policy Documentでは、どんなリソースに対し、どんなアクションを許可(不許可)とするかを細かく設定できます。細かすぎるところもありますが、awscliの各コマンドに対応していると考えれば概ね間違っていません。Policy DocumentはPolicy Generatorを利用して作ることができます。

Policy Documentの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*",
                "s3:PutObject"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

IAM User, Roleへのアクセス許可を設定する

User や Roleを作成したならば、アクセス許可から、Management Policy(管理ポリシー)とInline Policy(インラインポリシー)を設定します。

IAM_User
IAM_Role

Management Policyは「ポリシーのアタッチ」ボタンをクリックし、メニューからManagement Policyを選択します。ただし、Management Policyは2つまでしかアタッチできないので注意してください。

Management_policy

Inline Policyは、インラインポリシーから作成します。Policy Generatorを利用し、Policy Documentを作成すれば、必要最低限のアクセス許可を与えることができます。どのアクションを許可すれば良いか解らない場合は、必要になってからawscliを叩きながら許可を与えると良いでしょう。

Inline_Policy
Inline_Policy_2

まとめ

用途に合わせてIAM User, Role を作成し、必要最低限のアクセス許可を与えましょう。

AWS Cloud Roadshow 2017 福岡

  • Kazuaki Urayama

    上記文中の「Roleを設定できるのは、EC2をLaunchするタイミングだけです。」・・・ここは書き直しされたほうがいいのではないでしょうか。というのも2017年初にEC2のIAMロールが変更可能になったから(https://dev.classmethod.jp/cloud/aws/attach-iam-role-to-existing-ec2/ )