KMSの設定と運用を簡単にする方法を考えてみた

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

こんにちは、臼田です。

皆さん、KMSを使っていますか?

しっかり利用しようと思って使い始めるとどうしてもアレが大変で苦しめられると思います…

そう、キーポリシーです。

今回はそのキーポリシーをなるべく簡単に設定・運用するための方法を考えてみました。

KMSとは

KMSについては下記ブログが参考になるので、KMS自体を知りたい方はご参照下さい。

10分でわかる!Key Management Serviceの仕組み #cmdevio

「実践 Amazon KMS」 #cmdevio2015 #cmdevio2015H

キーポリシーの簡単な利用方法

まずは下記画面を御覧ください。

こちらは、KMSの鍵詳細画面ですが、キーポリシーに直接ポリシーのドキュメントが表示されずに「キー管理者」と「キーユーザー」の2つの項目が表示されています。

CLIからKMSを利用している人は馴染みがないかもしれませんが、キーポリシーはポリシーを直接管理する方法の他に、マネジメントコンソールのデフォルトビューを利用することにより簡単に管理することができます。

デフォルトビューは、マネジメントコンソールから鍵を作成することにより利用が可能です。

このデフォルトビューでは、キーポリシーを管理者とユーザーの2種類用意し、それぞれにIAMユーザーやIAM Roleを割り当てることが可能です。一般的にユーザーやRoleを割り当てる際には、この2種類の権限に分割することがIAMベストプラクティスでも謳われているのでベーシックな使い方にはデフォルトビューを利用するといいでしょう。

デフォルトビューの利用についての公式ドキュメントはこちら。

キーポリシーの変更 - AWS Key Management Service

デフォルトビューのメリット

デフォルトビューのメリットは何と言ってもその可視性と操作性です。

キーポリシーのjson表記を眺めただけでは直感的に誰にどのような権限が割り当てられているかや、ポリシーの設定漏れ等を確認することが出来ません。

ちなみに、デフォルトビューを利用して設定されている先程の画面右上の「ポリシービューへの切り替え」でjson表記を確認することができ、キーポリシーは下記のようになっています。

{
  "Version": "2012-10-17",
  "Id": "importkey-consolepolicy-2",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::000000000000:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow access for Key Administrators",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::000000000000:user/iam_user_name"
      },
      "Action": [
        "kms:Create*",
        "kms:Describe*",
        "kms:Enable*",
        "kms:List*",
        "kms:Put*",
        "kms:Update*",
        "kms:Revoke*",
        "kms:Disable*",
        "kms:Get*",
        "kms:Delete*",
        "kms:ImportKeyMaterial",
        "kms:TagResource",
        "kms:UntagResource",
        "kms:ScheduleKeyDeletion",
        "kms:CancelKeyDeletion"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::000000000000:user/iam_user_name"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow attachment of persistent resources",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::000000000000:user/iam_user_name"
      },
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

比較的わかりやすく分割されていますが、それでもデフォルトビューと比べるとわかりづらいと思います。

キーポリシーにユーザーやRoleを追加することを考えると、これを直接操作するより、コンソールでポチポチやりたくなります。

デフォルトビューの場合の追加は、キー管理者・キーユーザーごとの「追加」ボタンを押して、一覧からIAMユーザー/Roleを選択してアタッチするだけです。

デフォルトビューが向かないケース

非常に使いやすいデフォルトビューですが、もちろん万能ではありません。デフォルトビューが向かないケースは以下の通りです。

  • 鍵毎に利用できるリソースを制限する場合
  • 鍵をサービスが利用する場合

これはどちらも、デフォルトビューでは設定できないことに由来します。

しかし、デフォルトビューは非常に強力なので、上記に当たる場合には鍵を分割しデフォルトビューが利用できる範囲で最大限利用するといいでしょう。

まとめ

デフォルトビューの良さについてご理解いただけたかと思います。

鍵の作成・運用時に、タイポやミスでキーポリシーが正しく設定できなくて困ることは発生しがちです。

少しでも運用負荷を軽減するために、なるべく鍵はマネジメントコンソールから作成してデフォルトビューを利用するようにしてみてはいかがでしょうか?