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

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

## はじめに

「こんな時どうする」数が増えていくにつれ、弱い部分も見えてきました、
公式資料を読み返し、問題点をクリアにしていく過程が楽しくなりました。

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

- アクセスキーを悪用した不正アクセスが報告された、IAMアクセス許可が変更されていないか確認したい
    - AWS Configサービスを使用、AWSリソースの設定を評価、監査、審査できる
    - AWSリソースの設定が継続的にモニタリングおよび記録され、設定の評価が自動的に実行される

- DDoS攻撃によりネットワークやシステムに遅延が発生した
    - 攻撃対象領域を削減する
        - 目標
            - 必要なインターネットエントリポイントの数を減らす
            - インターネットエントリポイントを分離し攻撃の効果を最小化
                - 管理トラフィックからエンドユーザートラフィックを分離
            - 必要なインターネットエントリポイントを難読化し、信頼できないエンドユーザーがアクセスできなくする
        - 対策
            - VPCを使用し、AWS内に独自の論理的に分離された仮想ネットワーク領域を定義
            - 使用しないポート、プロトコルを無効にする
    - スケールして攻撃を吸収できるようにする
        - 目標
            - 攻撃をより広い領域に分散させ、影響範囲を最小化
            - 攻撃者が攻撃をスケールアップするためさらにリソースを消費
            - DDoS攻撃を分析し、対策するまで時間を稼ぐ
            - その他障害シナリオに対し、冗長性のセキュリティレイヤーが追加される
        - 対策
            - アプリケーションに対して適切なEC2インスタンスタイプを選択
            - Elastic Load BalancingやAuto Scaling といったサービスで自動スケール
            - Amazon CloudFrontやAmazon Route 53などに組み込まれた固有のスケールを使用
            - Application Load BalancerとAuto Scalingグループで自動スケールし、アプリケーション層のトラフィック増を吸収
    - 公開されたリソースを保護する
        - 目標
            - サービズ中断できないエントリポイントへのアクセスを制限し、保護
            - 悪意のあるトラフィックがアプリケーションに到達しないようにする
        - 対策
            - Amazon CloudFront
            - Amazon Route 53
            - AWS WAF(ウェブアプリケーションファイアウォール)
            - AWS Well-Architectedフレームワークを使用
    - 通常時の動作について学習する
        - 目標
            - アプリケーションやインフラストラクチャが攻撃を受けたときに検知できる
            - アプリケーションの正常なトラフィックレベルやパターンを理解し、異常検知のベンチマークとして使用
        - 対策
            - Amazon CloudWatchを使用し、AWSで実行中のインフラストラクチャとアプリケーションをモニタリング
            - Amazon CloudFrontレポートを使用
            - Amazon Route 53のヘルスチェック
    - 攻撃に対する計画を作成する
        - 目標
            - 攻撃される前に対応を計画することで、インシデント発生時に素早く対応できる
        - 対策
            - アーキテクチャを検証し、インフラストラクチャにおいて有効な手法を選択
            - 弾力性を高めるためのコストを評価、防御の目標を理解
            - 攻撃が発生したときの連絡先を明確にする
            - 必要なAWSサポートレベルを考慮

※ [DDoSに対するAWSのベストプラクティス](https://media.amazonwebservices.com/jp/DDoS%20White%20Paper_Revised.pdf)を参考

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

- EC2インスタンスのシステムログをCloudWatch Logsに配信したい
    - CloudWatchエージェントを使用
    - CloudWatchエージェントのインストール手順(IAMロール使用例、IAMユーザーも使用可)
        - IAMロールを作成し、以下アクションを許可するポリシーをアタッチ
            - "logs:CreateLogGroup"
            - "logs:CreateLogStream"
            - "logs:PutLogEvents"
            - "logs:DescribeLogStreams"
        - EC2インスタンスに上記IAMロールをアタッチ
        - EC2インスタンスにCloudWatchエージェントをインストール
        - CloudWatchエージェント設定ファイルで、収集するメトリクスを指定

- 機密レベルが異なる複数アプリケーションログに対し、それぞれアクセス制御したい
    - Amazon CloudWatch Logsを使用し、機密レベルに応じてロググループを作成
    - IAMポリシーを使用し、ロググループ別アクセス制御を行う
    - ロググループを各アプリケーションに適用

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

- VPCプライベートサブネット内のアプリケーションサーバーとMySQLサーバー間でHTTPS通信のみ許可したい
    - MySQLセキュリティグループのインバウンドルールに、アプリケーションサーバーセキュリティグループからMySQLポートへのアクセスのみ許可
    - ※ セキュリティグループはステートフルのため、インバウンドルールのみでOK

- VPCとAWS KMS間の通信をAWSネットワーク内に制限したい(インターネットを介さず)
    - VPCプライベートエンドポイントをAWS KMS用に作成し、AWS KMSに直接接続
    - VPCエンドポイントのプライベートDNS名を有効にし、下記標準KMS DNSホスト名がVPCエンドポイントに名前解決できるように
        - `https://kms.<region>.amazonaws.com`
    - KMSへのリクエストをVPCエンドポイントに制限するため、KMSキーポリシーで`aws:sourceVpce`または `aws:sourceVpc`条件キーを使用
        - ※ リクエストがVPCエンドポイントから送信される場合、`aws:sourceIP`条件キーは無効        

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

- 特定IPアドレスからS3バケット及びすべてのオブジェクトへアクセス制限したい
    - バケットポリシーのResourceセクションに、バケットとバケット両方指定
```
            ... ...
            "Effect": "Deny",
            "Resource": [
                "arn:aws:s3:::MY-TEST-BUCKET",
                "arn:aws:s3:::MY-TEST-BUCKET/*"
            ],
            "Condition": {
                "NotIpAddress": {
                    "aws:SourceIp": "xxx.xxx.xxx.xxx/xx"
                }
            }
```

- SAML2.0互換IDプロバイダー(IdP)を使用し、Amazon API Gateway経由でAPIにアクセスしたい
    - Amazon Cognitoで、ユーザープールにSAML2.0互換IDプロバイダーを設定
    - Amazon CognitoがSAMLアサーションを受信時、SAML属性をユーザープール属性にマッピングできるように
        - `属性マッピング`タブでSAML2.0互換IdPの属性をAmazon Cognitoユーザープール属性にマッピング
    - SAML2.0互換IdPをセットアップし、SAML2.0互換IdPからSAMLアサーションを受信できるように
        - Amazon Cognitoユーザープールを証明書利用者として追加
        - 署名証明書を追加
    - Amazon API GatewayがAmazon Cognitoから渡される認証情報を認識できるように
        - Amazon API Gatewayで、Amazon Cognitoユーザープールをオーソライザーとして指定
    - ※ [デベロッパーガイド](https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/user-pool-accessing-resources-api-gateway-and-lambda.html)から引用:
            - Amazon API Gatewayは、ユーザープール認証からのトークンを検証し、これらのトークンを Lambda 関数などのリソースに付与できる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523098/d07ab4f7-5b9d-fcd1-82de-257ee5c056f8.png)



## 分野5: データ保護

- 使用しなくなったKMSキーをコスト削減のため30日後に削除したい
    - キーの削除をスケジュールするためのアクセス許可`kms:ScheduleKeyDeletion`を追加
    - `Schedule key deletion`で、キーの削除をスケジュールする
    - `Waiting period(in days)`で、待機期間(日数)を30日に指定
    - `Schedule deletion`を選択
    - KMSキーのステータスが`Pending deletion`(削除保留中)に変わる
    - ※ 注意: KMSキーを削除すると復元できない、そのKMSキーで暗号化されたデータも復号できなくなる
        - 不明な場合は削除ではなく、KMSキーを無効化

## おわりに

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

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