AWS公式資料で挑むSCS認定(10)-KMS(続き)

[前回] [AWS公式資料で挑むSCS認定(9)-KMS](https://qiita.com/mingchun_zhao/items/67b44c02b5d78218702e)

## はじめに

前回の続きとしてKMSの勉強です。
KMSの暗号化/復号のフロー、暗号キーの認可/監査など重要事項を確認してから、
KMSが実際運用でどのように使われているか、ベストプラクティスを見てみます。

## KMSの暗号化/復号のフロー

### 暗号キーの作成と受け渡し

引用元: [[AWS Black Belt Online Seminar] AWS Key Management Service](https://d1.awsstatic.com/webinars/jp/pdf/services/20181121_AWS-BlackBelt-KMS.pdf)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523098/6a26b2a6-18a0-c50e-3934-a0da44f6cc66.png)

1. クライアントは AWSアカウント内のKMSキーIDを渡してkms:GenerateDataKey を呼び出す
    - このリクエストは呼び出したユーザーの権限と鍵のアクセス権限の両方に基づき認証される
2. KMSがユニークなデータキーを生成
3. 暗号化されたKMSキーを高耐久ストレージから取り出し、HSMの中でKMSを復号
4. 複合化されたKMSキーを使用しデータキーを暗号化し、平文のデータキーと暗号化されたデータキーをクライアントに返す
    - 利用後は平文のKMSキーは消える
5. クライアントは、平文のデータキーを使ってデータを暗号化し、データとともに暗号化されたデータキーを保存する
6. 復号の際は、クライアントがデータに含まれる暗号化されたデータキーをKMSに渡す
    - 暗号化されたデータキーは復号のために必要

## KMSの認可/監査

### 認可(セクセス制御)

暗号キーを安全に使用するための権限設定(アクセス許可)です。
設定方法は2種類存在します。

引用元: [[AWS Black Belt Online Seminar] AWS Key Management Service](https://d1.awsstatic.com/webinars/jp/pdf/services/20181121_AWS-BlackBelt-KMS.pdf)

- キーポリシーによるリソースベースアクセス制御
    - 暗号鍵作成時にキーポリシーが定義される
    - AWS管理コンソール、CLI/SDKにより変更可能
        - GetKeyPolicy：ポリシーの取得
        - PutKeyPolicy：ポリシーの設定
    - デフォルトポリシーの例

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523098/71baa599-05aa-c8ed-98ce-707d54826bdd.png)

- IDベースアクセス制御
    - IAMユーザーやIAM ロールで設定されたポリシーによるアクセス制御
    - デフォルトポリシーの例

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523098/85eb9f93-3a2b-93bf-7cf3-74ed1203d3ea.png)


- ポリシーの評価
    - 暗号キーに付与されたリソースベース権限と、IAM ユーザー/ロールに付与したユーザーベースの権限両方を評価
    - 暗号キーに付与されるデフォルトポリシーはrootアカウントに対して全ての権限を持つ
    - KMSのアクセス権の評価は通常のIAMのポリシー評価と同じロジック
        - アクセス権限に"Allow"の条件があった場合、アクセス許可
        - ただしアクセス権限に１つでも"Deny"の条件があった場合、アクセス拒否(明示的なDeny)
        - デフォルトDeny < Allow < 明示的なDeny

- 許可(Grants)
    - KMSではキーポリシーの他に、許可(Grants)というリソースベースのアクセス制御機能をサポート
    - 許可を利用すると、KMSキーの使用をクライアントによって他のAWSプリンシパルに委任することができる
    - より細かいアクセス権の設定が可能
    - 利用される5つの要素
        - キー: KMSキーのID
        - GranteePrincipal: パーミッションを受ける対象
        - Operations: 許可されるオペレーション
        - Constraints: Grantsが有効になるConditionを定義
        - RetiringPrincipal: Grantsをretireさせることができる対象
    - 許可(Grants)の使用例

```
# Create a grant

key_id = 'arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef1234567890ab'
grantee_principal = 'arn:aws:iam::111122223333:user/Alice'
operation = 'Encrypt'
response = kms_client.create_grant(
  KeyId=key_id,
  GranteePrincipal=grantee_principal,
  Operations=operation
)
```

[引用元: 許可の使用]( https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/programming-grants.html)

### 監査

CloudTrailによりKMSのログ集約されるので、監査に使用できる。

- CloudTrailによりKMSの管理コンソールでの操作やSDKでの操作で利用したAPIのログを取得
- CloudTrailにより取得できるログ
    - 誰が
    - いつ
    - どのAPIを
    - どのAWSリソースから
    - どのAWSリソースに対して


## KMSのユースケース

### データ保護(機密性を保護)

暗号化を用いて守るべきデータは、ストレージの保存データのみならず、
ネットワーク通信路で転送されるデータも含まれています。

- ネットワーク通信の暗号化
    - 目的
        - 通信路のデータが盗聴されないように
    - 暗号化方法
        - SSL/TLSを使用
        - IPSecを使用
        - 無線LANの暗号化
- 保管データの暗号化
    - 目的
        - 攻撃者の不正アクセスや改竄を防止
    - 暗号化方法
        - ファイルの暗号化
        - ファイルシステムの暗号化
        - データベースの暗号化
        - ブロックデバイスの暗号化

### デジタル署名(完全性を保護)

デジタル署名は、本人認証の手段として使われ、なりすましを防止。

- 暗号化の方式は盗聴に対して非常に有効だが、他人になりすまして偽りのメールを送るケースに対してはその発見が困難
- そこで、重要情報をメールで送る場合や、ECサイトなどで本人認証の手段として使われるのがデジタル署名

### AWSの各種サービスでKMSによる暗号化が使用される

- EBS
- RDS

など 。。。

## AWS KMSのベストプラクティス

引用元: [[AWS Black Belt Online Seminar] AWS Key Management Service](https://d1.awsstatic.com/webinars/jp/pdf/services/20181121_AWS-BlackBelt-KMS.pdf)

- 認証と認可
    - IAMポリシーとキーポリシーのデザイン
    - 最小権限と権限の分離(Least Privilege / Separation of Duties)
        - クロスアカウントのアクセス、ルーツアカウントの考慮
        - PutKeyPolicyに対する権限
        - Encryption Context
    - MFAの利用の検討
- 発見的統制
    - CloudTrailの利用
- パフォーマンスとサービス制限
    - [1秒あたりのAPIオペレーションのリクエスト数](https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/limits.html)に要注意

- インフラストラクチャのセキュリティ
    - カスタマーマネージド型鍵の利用
    - 鍵をどの単位で分割するかの検討（AWSアカウントの体系、データクラス、インシデント対応から考える）
- インシデント対応の明確化と自動化
    - AWS KMSセキュリティの自動化
    - KMSキーの無効化と削除、特に削除は慎重に

## クイズでリラックス

KMS関連リソースのクォータについてクイズです。

|リソース|クォータ|
|:--:|:--:|
|KMS キー|?|
|KMS キーごとのエイリアス|?|
|KMS キーごとの権限|?|
|キーポリシードキュメントのサイズ	|?|
|直接暗号化できるデータサイズ|4KB|

正解は[リソースクォータ](https://docs.aws.amazon.com/ja_jp/kms/latest/developerguide/resource-limits.html)に載っています(最後の項目は自作です)。

## おわりに

SCS試験対象の超重要なサービス(IAM、VPC、KMS)を一通り勉強しました。
残りのサービスも同じ要領で勉強を進めようと思います(スピードアップしなくちゃ)。
実環境でも手を動かして確認することで理解を深めたいところです。
お楽しみに。

[次回] [AWS公式資料で挑むSCS認定(11)-Aritifact](https://qiita.com/mingchun_zhao/items/23e0fb58313badec62a8)