Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

15分で教えるAWSのユーザー管理と権限管理

More than 1 year has passed since last update.

AWS初めての方にAWSアカウントとIAMを説明する用の記事です。

短い時間で全体像を把握してもらうことを目的としているため、これを読んだところでAWSの設定ができるようにはなりません。自分が使っている環境をベースに書いているので、人によっては足りない部分があると思います。

初めから詳しく知りたい場合はBlackBeltを見ることをおすすめします。
AWS Black Belt Techシリーズ AWS IAM

この記事の目的

  • AWSコンソールへの認証、ログイン方法になにがあるか知ってもらう
  • AWSサービスの認可、権限をどう管理しているのか知ってもらう
  • AWSアカウントの分け方と関係性はどうなっているか知ってもらう
  • AWS管理者が不安に思いそうなところを先んじて抑える

AWSコンソールへのログイン方法

コンソールへのログインに用いるユーザーは主に3種類あります。

  • AWSルートユーザー(ID/Password)
  • IAMユーザー(ID/Password)
  • フェデレーションユーザー(SAML等)

参考:ID 管理の概要: ユーザー - AWS Identity and Access Management
参考:ID(ユーザー、グループ、ロール) - AWS Identity and Access Management

AWSルートユーザー

AWSアカウント作成時に登録したメールアドレスでログインするとルートユーザーになります。
ルートユーザーはすべての操作をすることができます。

ルートユーザーはその特性上、アカウントの設定で挙動を縛ることはほぼ不可能なため(OrganizationのService Control Policyなら可能)、組織で使う場合ルートユーザーを利用者に使わせることはほぼありません。
管理者でも使うことはめったになく、MFA登録して塩漬けすることが多いです。

rootuser_mfa.png

ただしルートユーザーでしかできないこともあるため、MFA登録しておいて登録端末を破棄するなどといった自爆技で完全に使えないようにしてはいけません。

参考:AWS アカウントのルートユーザー が必要な AWS タスク - アマゾン ウェブ サービス

IAMユーザー

IAM(Identity and Access Management)というAWSのサービスを用いると、2種類のユーザーが作成できます。

  • コンソール利用可能IAMユーザー(人によるGUI操作向け)
  • コンソール利用不可IAMユーザー(プログラムからの操作向け)

AWSアカウント数が少なければコンソール利用可能なIAMユーザーを使うのが一般的です。

iam-user.png

AWSアカウント数が多いときは、IAMユーザーをアカウントごとに作り管理する手間を削減するため、フェデレーションユーザーを使う場合が多いと思います。

フェデレーションユーザー

自組織内の認証基盤などを用いてSAML認証でAWSにログインすることができます。
フェデレーションログインの場合は事前に定めた権限(IAMロール)の一時的セキュリティ認証情報を発行してログインします。

これだとひとりひとりにIAMユーザーを作る必要がありません。
AWSからは IAMロール名/Idp認証時のユーザーID といったユーザーとして認識されます。
ex. S3ReadOnlyRole/hogehoge@example.com

federation-user.png

Idpを含めた認証フローは公式がわかりやすいので割愛。

saml-based-sso-to-console.diagram.png

参考:SAML 2.0 フェデレーションユーザーが AWS マネジメントコンソールにアクセス可能にする - AWS Identity and Access Management

AWS APIの利用方法

APIの利用方法は主に2種類あります。

  • IAMユーザーのアクセスキー
  • IAMロールの一時的セキュリティ認証情報

IAMユーザーのアクセスキー

IAMユーザーはAPIを利用できるアクセスキーを発行できます。
AWS外からAWSのAPIを利用したい時は、このアクセスキーを使います。

iam-user.png

AWS内のリソースからAPIを利用したい場合はアクセスキーを使わずに、IAMロールを使うことが推奨されています。

IAMロールの一時的セキュリティ認証情報

IAMロールは権限の塊としての役割以外に、一時的セキュリティ認証情報を発行してサービスやフェデレーションユーザーやEC2などに権限を与えることができます。

sts_assumerole.png

一時的セキュリティ認証情報といっていますが、これもアクセスキーです。
IAMユーザーのアクセスキーとは違い、有効期限ありのアクセスキーになります。
DurationSeconds パラメータで認証情報の有効期限を設定できます。
デフォルト1時間で最大12時間まで延ばすことができます。

アクセスキーを都度発行するため、サービスにアクセスキーを埋め込む必要がなくセキュアに使えます。

# 割り当てRoleの確認
$ aws sts get-caller-identity
# インスタンスプロファイルの確認
$ curl http://169.254.169.254/latest/meta-data/iam/info
# Default region / output は初期値として未設定なので必要なら設定する、アクセスキー部分は空白でOK
$ aws configure
AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: ap-northeast-1
Default output format [None]: json

参考:ロールの一般的なシナリオ: ユーザー、アプリケーション、およびサービス - AWS Identity and Access Management
参考:一時的セキュリティ認証情報 - AWS Identity and Access Management

AWSサービスの認可、権限管理方法

すでに用語としては何度も出してしまっていますが、権限管理で使っている機能についてちゃんと説明します。

IAMポリシー

AWSの権限管理の最小単位はIAMポリシーと呼ばれていて、権限をjsonで管理しています。
IAMポリシーはIAMユーザー・グループ・ロールにアタッチできます。

policy_attach.jpg

参考:AWSome Day 2016 - Module 3: Security, Identity, and Access Management

IAMポリシーは以下のような構造となっており、Condition:どういう条件のとき Action:どのサービスのどのアクションResource:どのリソース に対して Effect:許可・拒否 するかを設定することができます。

  • Effect – ポリシーがアクセスを許可または拒否するかどうか
  • Action – ポリシーによって許可または拒否されるアクションのリスト
  • Resource – アクションを起こすことができるリソースのリスト
  • Condition (オプション) – ポリシーがアクセス許可を付与する状況
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dynamodb:DeleteItem",
                "dynamodb:GetItem",
                "dynamodb:PutItem",
                "dynamodb:UpdateItem"
            ],
            "Resource": [
                "arn:aws:dynamodb:us-west-1:123456789012:table/myDynamoTable"
            ],
            "Condition": {
                "ForAllValues:StringEquals": {
                    "dynamodb:LeadingKeys": [
                        "${cognito-identity.amazonaws.com:sub}"
                    ]
                }
            }
        }
    ]
}

参考:IAM ポリシー - AWS Identity and Access Management

IAMロール

IAMユーザーが使う場合、IAMポシリーはIAMロールにまとめてIAMグループにアタッチするのが一般的です。
IAMユーザーはIAMグループに所属させることで権限を得るような管理になります。
サービスで使う場合、同じくIAMロールにまとめて、それをそのまま使います。

iam-group

この図のようにIAMロールは権限の塊として認識しておけばいいのですが、ほかにもIAMロールは役割があります。
それが先に何度も出てきた一時的セキュリティ認証情報の付与になります。

すべてのIAMロールで一時的セキュリティ認証情報を発行できるわけではなく、Principal:どのサービスorアカウントから であれば Action:一時的セキュリティ認証情報の発行Effect:可能 かもポリシーで制御可能です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": [ "123456789012" ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away