AWS公式資料で挑むSCS認定(23)-こんな時どうする(分野5:データ保護)

##### [前回] [AWS公式資料で挑むSCS認定(22)-こんな時どうする(分野4:ID及びアクセス管理)](https://qiita.com/mingchun_zhao/items/2c9d60dc58a58749f807)

## はじめに

最後の分野「分野5: データ保護」となります。

## 「分野5: データ保護」基本知識のおさらい

### データ保護に使用されるサービス

- AWS KMS
- AWS CloudHSM
- AWS Certificate Manager
- AWS Secrets Manager
- Amazon S3 Glacier
- Amazon S3 Glacier Vault
- Amazon RDS
- Amazon DynamoDB
- Amazon Elastic File System(EFS)

### 暗号化

#### 暗号キー

- データキー
    - データの暗号化/復号を行う対称キー
    - 暗号化対象のオブジェクト毎にユニーク
    - KMSキー(マスターキー)により暗号化される
- KMSキー(マスターキー)
    - データキーの暗号化/復号を行う暗号キー
    - KMSキーのメタデータとは、キーID、作成日、説明、キーステータスなど

##### KMSキーの種類
|キー種類|メタデータ|管理者|AWSアカウント依存|ローテーション|
|--|--|--|--|--|
|AWS管理キー|表示可|AWS|はい(アカウント内で使用)|必須(3年毎)|
|カスタマー管理キー(CMK)|表示可|ユーザ|はい(アカウント内で使用)|オプション(1年毎)|
|AWS所有キー|表示不可|AWS|いいえ|可変|

##### KMSキーの保護

###### KMSキー保護に使用されるサービス

- AWS KMS
    - マネージド暗号化サービス、エンベロープ暗号化を使用した2層のキー階層を持つ
        - エンベロープ暗号化とは、暗号化されたデータ暗号キーとルートキーを使用して機密データを保護するプロセス
    - KMSキーにエリアスを付与することで、KMSキーを変えず、KMSキーマテリアルだけローテーションできる
        - キーマテリアルとは、暗号化キーの生成に必要な材料(キーの長さ、乱数など)
    - KMSキーを削除するより、再利用に備え無効化する、削除したら取り戻せない
    - KMSキーをインポート可、エクスポート不可
    - AWS CloudTrailを使って、キー使用を監査
- AWS CloudHSM
    - クラウドベースのハードウェアセキュリティモジュール(HSM)
        - HSMとは、暗号化や電子署名に用いる暗号キーを安全に保管し暗号処理を行うICチップ
    - AWSクラウドで暗号化キーを簡単に生成/使用できる

###### KMSキーポリシー

- リソースベースのポリシー
- キー管理と暗号化/復号を行えるユーザのアクセス権を指定
- 必要に応じてAWSアカウントにカスタマー管理キー(CMS)を付与

#### データの暗号化方法

- クライアント側の暗号化(CSE)
    - データ送信前にユーザがアプリケーションレベルで暗号化
    - 長所は、転送中と保管中の両方のデータに対応
    - 短所は、キーとアルゴリズムをアプリケーションで管理するため、AWSで復号不能

- サーバー側の暗号化(SSE)
    - AWSですべての暗号化とそのプロセスを管理
    - 長所は、KMSキーの管理はAWS/ユーザどちらでも管理可能
    - 長所は、KMSキーのローテーション可能
    - エンドユーザに対して透過的、透過的とは「存在を意識することなく使える」という意味

### データの保護

#### 転送中データの保護

- トラフィックの暗号化(機密性)
    - HTTPS通信を使用
        - クライアントとサービスエンドポイント間でTLSセッションを確立
- データ整合性の認証(完全性)
    - 証明書による署名認証を使用
        - PKI(公開キー基盤)のX.509証明書を使って、サーバーのID検証を行い、改ざん/偽造防止
            - 公開キー基盤とは、公開キーとその公開キーの持ち主の対応関係を保証するための仕組みで、公開キー暗号化と電子署名で用いられる
    - 証明書の保護
        - AWS Certificate Managerを使用
            - パブリック/プライベート証明書を作成/管理/デプロイ
            - ユーザのプライベート証明書の保存/保護も可能
            - 証明書自動更新によるダウンタイムを最小限に抑える

#### 保管中データの保護

- 保管データの暗号化(機密性)
- バックアップ/スナップショット
- バージョニング(S3)
- レプリケーション

### S3によるデータ保護

- アクセス制御方法
    - オブジェクトACL
        - 個々のオブジェクトへのアクセス権限を付与
        - 別のアカウントが所有するオブジェクトへのアクセス制御
    - バケットACL
        - ログ配信グループにバケットへの書き込みアクセスを付与
    - バケットポリシー
        - バケットACLよりも幅広いアクセス権限を付与する
        - バケットへのクロスアカウントアクセスを許可する
    - IAMポリシー
        - ユーザーとグループを作成し、ポリシーをアタッチすることでアクセス権限を管理
    - CORS(Cross−Origin Resource Sharing)
        - 特定のドメインにロードされたクライアントウェブアプリケーションが、異なるドメイン内のリソースと通信する方法を定義
        - リッチなクライアント側ウェブアプリケーションから、S3リソースへのクロスオリジンアクセスを選択的に許可

- S3のアンチパターン
    - 特別な理由がない限り(静的コンテンツなど) 、パブリックアクセスを許可しない
    - アカウントレベルでブロックパブリックアクセスを用いて、バケットを完全保護
        - ACLにより許可されたバケットとオブジェクトへのパブリックアクセスをブロック
        - バケットポリシーにより許可されたバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロック
    - 既存のバケット設定を監査するまたはソフトウェアのトラブルシューティングを行う手段として、バケットをパブリックアクセスに開かない
    - アカウント管理を必要とするユーザーに、管理者権限を付与しない

- Amazon S3 Glacier
    - ライフサイクル設定により、データをS3からS3 Glacierへ自動転送し、アーカイブ/長期保存
    - データを一括またはセグメント単位で取得可能

- Amazon S3 Glacier Vault
    - S3 Glacierボールトロック
        - ボールトは、アーカイブを格納するコンテナ
        - ボールトロックポリシーを使用し、各ボールトに対するコンプライアンス管理を簡単にデプロイして適用
        - WORM(Write once Read Many)制御を用いて、コンプライアンスに必須なポリシー設定をロックし編集不可に
        - ロック時間を設定可
        - MFA認証を強制できる

### Amazon RDSによるデータ保護

- 転送中データの保護
    - TLSとネイティブ暗号化クライアントを使用
    - RDSのアクセス認証機能を使用

- 保管中データの保護
    - AES-256暗号化アルゴリズムを使用
    - 暗号化を有効化し、表や表領域のデータを暗号化保存
        - DB作成時に有効化、DB作成後は機能しない
    - 特定のDBエンジンでTDEを使用可
        - TDEとは、透過的データベース暗号化で、ユーザーが暗号化や復号を意識することなく、暗号化データを扱える

### Amazon DynamoDBによるデータ保護

- 転送中データの保護
    - TLSで暗号化されたエンドポイントを使用
    - HMAC-SHA256署名付きのリクエストのみを許可

- 保管中データの保護
    - CSE、SSE暗号化オプションをサポート
    - AES-256暗号化アルゴリズムを使用
    - テーブルとインデックスを暗号化

### AWS Secrets Managerによるデータ保護

- シークレット(データベースの認証情報、APIキーなど)をライフサイクル全体で保護
- キーのローテーションを自動的に実行
- ユーザ/グループ/ロールの一元的なセキュリティと監査ポリシーを実現

## 「分野5: データ保護」の「こんな時どうする」

- 保管中データの情報漏洩を防止したい(機密性)
    - ポリシーによるアクセス制限
    - 暗号化
    - S3 Glacierボールトロック

- 保管中データの改ざん・誤った削除を防止したい(完全性、整合性)
    - ポリシーによるアクセス制限
        - ベストは、ポリシーが異なる複数アカウントを用いてアクセス権を完全分離させる
    - 暗号化
    - デジタル署名
    - バックアップ/スナップショット
    - バージョニング(S3)
    - レプリケーション
    - S3 Glacierボールトロック

- 保管中データをシステム障害や天災発生時も使用可能にしたい(可用性)
    - レプリケーション
    - バックアップ/スナップショット

- ELB経由の転送中データを保護するため暗号化を強制したい
    - ELBのHTTPSリスナーを有効に
    - ELBのセキュリティグループで、保護されていないポートを許可しない
    - ※ CloudWatchではデータが暗号化されたか監視できない(特定要素の内容を確認するメトリクスは存在しない)

- 暗号化されたファイルシステムを使用して保管中データを保護したい
    - 方法1: AWS KMSキー暗号化を使用し、Amazon Elastic File System(Amazon EFS)を作成
    - 方法2: CloudWatchアラームを作成し、暗号化されていないファイルシステムを検出する
    - ※ 既存のEFSに対し、KMSを使用するように変更することは不可

- 機密データをS3バケットへ転送及び保管中に暗号化を強制したい、かつバケットへのアクセス権限を持つすべてのユーザが保管データを利用可能にしたい
    - 下記バケットポリシーが必要
        - AES-256 SSE-S3で管理される暗号化キーを使用する場合のみ、put/getアクセスを許可

- S3 Glacierのボールトへのアクセスに対し、コンプライアンス制御を適用したい
    - S3 Glacierボールトロックを使用
    - S3 Glacierボールトロックの2つのステップ
        - ロック開始
            - ボールトロックポリシーをボールトに関連付けると、ロックがInProgress状態になり、ロックIDが返される
            - InProgress状態で、ロックIDの有効期限が切れるまでの24時間にボールトロックポリシーを検証可能
        - ロックIDを使用しロック処理を完了

## おわりに

最後の分野「分野5: データ保護」の「こんな時どうする」集でした。
一通り終わりましたが、全分野における「こんな時どうする」を追記していこうと思います。
お楽しみに。

##### [次回] [AWS公式資料で挑むSCS認定(24)-こんな時どうする(全分野追記)](https://qiita.com/mingchun_zhao/items/d4e6cf1651d52523fe65)