AWS公式資料で挑むSCS認定(26)-こんな時どうする(全分野その3)

##### [前回] [AWS公式資料で挑むSCS認定(25)-こんな時どうする(全分野その2)](https://qiita.com/mingchun_zhao/items/58d4ad73ddd1631b9b87)

## はじめに

早速、今回も「こんな時どうする」の追記です。
精査はしていますが、過去と似たような項目を取り上げる可能性あります、悪しからず。

## 分野1: インシデント対応

- EC2インスタンスで使用されていないポートが攻撃された、稼働中システムを止めずにすぐ対処したい
    - セキュリティグループのインバウンドルールから問題のポート番号を削除

## 分野2: ログとモニタリング(監視)

- S3バケットのアクセスログに「認証失敗」「HTTP Referer情報」を含め記録したい
    - S3サーバーアクセスログを使用し、S3リクエストをログ記録

- S3バケットのアクセスログに「IAM/ユーザー特定情報」「クロスアカウントログ」を含め記録したい、かつログファイルを暗号化したい
    - AWS CloudTrailを使用し、S3のAPIコールをログ記録

- Amazon GuardDutyによる監視で、特定EC2インスタンスから頻繁に誤検知(false positive)の通知発生するため、監視対象から除外したい
    - 信頼できるIPリストに、問題EC2インスタンスのIPアドレスを追加し、Amazon GuardDutyに適用
    - ※ 信頼できるIPリストのアップロード数は各リージョンのAWSアカウントにつき1つのみ
    - ※ Amazon GuardDutyとは
        - セキュリティの観点から脅威リスクを検知するマネージドサービス
        - 分析のソースに下記を利用、メタデータの連続ストリームを分析
            - VPC Flow Logs
            - AWS CloudTrail Event Logs
            - DNS Logs
        - 統合脅威インテリジェンスを使用し脅威を認識

## 分野3: インフラストラクチャのセキュリティ

- VPC内複数コンテナ間で相互TLS認証による通信を行いたい
    - ACMプライベートCA(証明機関)を使用し、下位CAを作成
    - ACM(AWS Certificate Manager)を使ってプライベート証明書を作成、すべてのコンテナに適用する
    - ※ ACMプライベートCAとは、プライベート証明書のライフサイクルを簡単かつ安全に管理するマネージドサービス
        - 自社プライベートCAを先行投資やメンテナンスコストをかけず運用でき、可用性の高いプライベートCAを得られる

## 分野4: アイデンティティ(ID)及びアクセス管理

- AWSアカウントを保護したい
    - AWSアカウントのルートユーザーまたはIAMユーザーに対しMFA(多要素認証)を有効に

- EC2 Linuxインスタンスにログインしたい
    - キーペアによる認証でログイン
    - キーペアには、プライベートキーとパブリックキーが含まれる
        - パブリックキーは、EC2インスタンス内に保管
        - プライベートキーは、ユーザー自身が保管 

- セキュリティ監査の実施タイミングが不明
    - 定期的監査
    - 従業員が退職するなど組織変更があった場合
    - 1つ以上のAWSサービスを使用しなくなった場合(不要になったアクセス許可を削除するため重要)
    - AWSアカウントでソフトウェアの追加/削除があった場合(EC2インスタンスのアプリケーション、AWS OpsWorksスタック、AWS CloudFormationテンプレートなど)
    - 権限のない人がアカウントにアクセスした疑いがある場合

## 分野5: データ保護

- S3バケットのオブジェクトに対し、KMSキーを用いたサーバー側暗号化(SSE-KMS)を強制するポリシーを作成したい
    - ポリシーで下記Statementを定義
```
    {
      ... ...
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Condition": {
        "StringNotEquals":{
           "s3:x-amz-server-side-encryption":"aws:kms"
        }
      }
    }
```

- S3バケットのオブジェクトに対し、S3バケットキーを用いたサーバー側暗号化(SSE-S3)を強制するポリシーを作成したい
    - ポリシーで下記2つのStatementを定義
```
    {
      ... ...
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    },
    {
      ... ...
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption": "true"
        }
      }
    }
```

- 独自のキーマテリアルをインポートしているKMSキー(カスタマー管理キー)を毎年更新したい
    - 新しいKMSキーを作成し
    - 新しいキーマテリアルをインポート
    - 既存のKMSキーのエイリアスを新しいKMSキーにマッピング
    - ※ KMSキー(カスタマー管理キー)の種類とローテーション
        - カスタマー管理の対称KMSキー
            - キーマテリアルをAWS KMSで生成
                - 1年ごとの自動更新を設定可
            - キーマテリアルをAWS CloudHSMクラスターで生成(KMSカスタムキーストア機能を使用)
                - 自動更新不可、要手動更新
            - 独自のキーマテリアルをインポート
                - 自動更新不可、要手動更新
        - カスタマー管理の非対称KMSキー
            - キーマテリアルはAWS KMS HSMでのみ生成可能
                - 自動更新不可

## おわりに

「こんな時どうする」の追記でした。
次回も続きます、お楽しみに。

##### [次回] [AWS公式資料で挑むSCS認定(27)-こんな時どうする(全分野その4)](https://qiita.com/mingchun_zhao/items/6e46410c6e6a9f230c6c)