現場の業務でKMSの設計を急に一任されたので、その時考えてたことです。

# そもそもKMSとは？
ストレージ上のデータや機密情報を暗号化するために便利なサービスです。セキュアに情報を扱うべきときには必ず使うサービスだと思います。主にはS3のデータを暗号化したり、Lambdaの環境変数 (従量課金されちゃうAPIのKEYとか)を暗号化するために使われることが多いです。


![KMS概要](https://kokosyna-post-bucket-prd.s3.ap-northeast-1.amazonaws.com/7b013673-65d7-406f-bcf5-52870702131e.webp)

# 現場での要件
- これから開発環境の環境構築を行う
- KMSについては何も決めてないので、いい感じに設計してほしい（半分投げやり）
- KMSを使うサービスはストレージ系、セキュリティ系含む複数
- KMSがないと設定できないサービスもあるので、なるはやで考えてほしい（設計〜実装まで3日以内くらい）

# 実際の設計
## AWS マネージド型か、カスタマーマネージド型か
AWS マネージド型とカスタマーマネージド型の比較は[公式ドキュメント](https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/concepts.html#symmetric-cmks)が最も信頼できるのでそちらに譲りますが、現場での視点では以下のメリデメがありました。


| キーの種類 | メリット | デメリット |
| :---: | :---: | :---: |
| AWS マネージド型 | 設定がかなり楽 | 個別にポリシーの設定ができない |
| カスタマーマネージド型 | 運用が柔軟にできる | 事前に設計する必要がある |

AWS マネージド型のメリットの「設定がかなり楽」の真の意味は、「他のサービスからKMSを設定するときに、KMSを事前に作成する必要がなく、勝手に作ってくれるので楽」という意味です。今回の開発環境構築では手動で複数人で同時に構築していくスタイルだったので、時間が限られている中このメリットは正直かなり大きかったです。

ですが、調査をしていくとデメリットにあるように運用の柔軟性がほぼ全て失われてしまうことが判明しました。今後想定外にポリシーの変更が必要になった場合、もう一度サービスとKMSを作り直す事態を避けたいと判断し、結局今回はカスタマーマネージド型を選択することとしました。
**※実際この後VPCフローログの設定の際に出力先S3をKMSで暗号化していた場合、追加のKMSのポリシー設定が必要になりました。**

## KMSを1つにするか、複数にするか
次に、複数サービスで使うKMSを1つにまとめるか、サービスごとに分ける形で複数にするかで迷いました。こちらもメリデメを。
  
| キー数 | メリット | デメリット |
| :---: | :---: | :---: |
| 1つ | コストが安い | キーポリシーの管理が煩雑化する |
| 複数 | 運用が柔軟にできる | キーの分コストがかさむ |

まずKMSのコストですが、カスタマーマネージド型の場合、置いとくだけで基本的に1個あたり$1/月です。今回の予算は万ドル~/月のスケールだったので、コストについてのメリデメは軽微だったので無視しました。となると数ドル節約して運用を煩雑化させるかどうかというレベル感の話になるので、サービスごとに複数に分ける形を採用しました。

複数サービスでKMSを使うのにキーを1つにまとめると将来的にキーポリシーがめちゃくちゃ長くなることと、キーのユーザーに対する権限の付与をサービスごとに分けることができなくなるため、運用がかなり窮屈になります。極限までコストを節約したいとか、ユーザーが自分しかいないとか、そういう特殊な状況下では逆に1つにまとめるでもいいと思います。

## KMS自体の設定はどうするか
これは基本的にデフォルトで作られる「対称暗号化 KMS キー」で問題ないと判断しました。
キーの原理などを軽く調査したりしましたが、詳細に検討する時間が取れなかったことと開発環境だしとりあえず暗号化されていれば問題ないと判断したためです。この辺りは本番環境の環境構築までに要検討としました。

# まとめ
- 基本的にKMSはサービスごとに分けたほうがいい
- 後で運用しないなら作るのが楽だしAWSマネージド型で！
- しっかり運用するならカスタマーマネージド型で！

# 最後に
KMSを設計したことない人、そもそもKMSを知らない人でもこんな感じで考えて設計すればいいんだなという参考になればと思います！	

AWS KMS