AWSガイダンスレポート

1. 使用率の低いEC2インスタンス(優先度：中)

ベースライン：

過去48時間でCPU使用率が2％未満であったEC2インスタンスが存在するかを確認します。

推奨：

Amazon EC2ではインスタンスタイプと使用時間に応じて請求が発生します。使用率の低いインスタンスを停止してコストを下げてください。ダウングレード先に推奨するインスタンスタイプも表示されるので、こちらもコスト削減に役立てられます。

必要な権限：

"ec2:DescribeInstances"、"cloudwatch:GetMetricData"、"cloudwatch:GetMetricStatistics"、"cloudwatch:ListMetrics"

2. EC2セキュリティグループ：特定ポートへの 無制限アクセス（優先度：高）

ベースライン：

監視しているEC2インスタンスのセキュリティグループを確認し、ポート「20、21、22、1433、1434、3306、3389、4333、5432、5500」で、無制限アクセスを許可しテイルポートがないか調べてください。

説明：

無制限アクセスはDDoS攻撃やアプリケーションへの悪意のトラフィックにつながる可能性があります。

推奨：

TCPポート80と443をインターネットに公開し、攻撃機会を最小限にします。

必要な権限：

"ec2:DescribeInstances"、"ec2:DescribeSecurityGroups"

3. EC2インスタンスの終了を抑制（優先度：高）

ベースライン：

EC2インスタンスの設定を確認し、終了制御が有効となっているかを確認してください。

説明：

終了抑制によって、インスタンスが誤って削除されるのを防止できます。また、Auto ScalingポリシーによってEC2インスタンスがスケールインする際に、削除されるのも防止します。

推奨：

EC2インスタンスの終了抑制はデフォルトでは無効となっています。予期しないインスタンスの終了を防ぐためにこれを有効化してください。

必要な権限：

"ec2:DescribeInstances"、"ec2:DescribeInstanceAttribute

4. Amazon EC2 VPCインスタンス：膨大なルールをもつセキュリティグループ（優先度：中）

ベースライン：

50を超えるインバウンドおよびアウトバウンドルールをもつセキュリティグループがあるAmazon EC2 VPCインスタンスを確認します。

説明：

インスタンスをVPCで起動している場合、インスタンスに関連付けられているセキュリティグループを5つまで特定します。各セキュリティグループで、入力および出力トラフィックを制御するルールを追加します。セキュリティグループの数がルールよりも大きい場合、インスタンスのパフォーマンスに影響を及ぼします。

推奨：

VPCセキュリティグループに関連付けられているルールに数を減らしてください。

必要な権限：

"ec2:DescribeInstances"、"ec2:DescribeSecurityGroups"

5. タグ付けされていないEC2インスタンス（優先度：情報)

ベースライン：

ユーザー定義のタグ（キー・バリューペア）のElastic Compute Cloud (EC2)インスタンスを確認します。

説明：

AWSはユーザーにタグ（キー・バリューペア）のフォームでメタデータを割り当て、インスタンスやイメージ、Auto Scalingグループなどに対してよりよい追跡と管理を提供しています。組織はこれら関連するタグや実践的なタグの戦略を実行し、EC2リソースファームを効果的に管理することができます。

推奨：

タグ戦略とAWSのベストプラクティス

必要な権限：

"ec2:DescribeInstances"

6. Amazon EC2：高いインスタンス使用率（優先度：高）

ベースライン：

Amazon EC2のパフォーマンスカウンターを確認し、使用率が高いインスタンスを識別します。

説明：

次の条件を満たした場合に、EC2インスタンスは利用過剰と判断します。

• 日ごとのEC2インスタンス平均CPU使用率が、最新7日間連続で90％を超えた場合
• 日ごとのEC2インスタンス平均メモリー使用率が、最新7日間連続で90％を超えた場合（EC2インスタンスにSite24x7のエージェントが展開されている場合のみ適用）

推奨：

インスタンスサイズを変更したり、インスタンスをAuto Scalingグループによって追加するかを検討してください。

7. Amazon EC2のIAM権限 （優先度：高）

ベースライン：

監視されているEC2インスタンスの設定を確認し、IAM権限の無いリソースを識別します。

説明：

マイクロサービスアーキテクチャ内で、EC2インスタンス上で稼働しているアプリケーションは、その他AWSサービス（S3バケット、Lambda、DynamoDBなど）上で稼働しているリソースにアクセスする必要があります。これを有効化するには、AWS認証情報を作成してインスタンスに分配するか（将来的にはそれらを変更したり更新する必要があります）、IAM権限を用いたAPI要求によって権限を与える必要があります。

推奨：

EC2インスタンスのIAM権限を作成し、その権限を与えるアクションを行います。

必要な権限：

"ec2:DescribeInstances"

8. Auto Scalingグループに所属していないEC2インスタンス（優先度：情報)

ベースライン：

Auto Scalingグループに関連付けられていないElastic Compute Cloud (EC2)インスタンスを確認します。

説明：

Auto Scalingは需要によってコンピューターリソースを拡大・縮小するのに役立ちます。Auto ScalingグループというEC2インスタンスのグループを作成して、希望する容量の入力し、条件を割り当てます。そうすることで、アプリケーションの要求を処理するのに最適なEC2インスタンスの数が確保されます。

推奨：

Auto ScalingグループとしてEC2インスタンスを構成してください。

必要な権限：

"ec2:DescribeInstances" "autoscaling:DescribeAutoScalingGroups"

9. VPC内で起動していないEC2インスタンス（優先度：中）

ベースライン：

EC2クラシックプラットフォームで起動しているElastic Compute Cloud (EC2)インスタンスを確認します。

説明：

Amazon EC2ネットワークはEC2クラシックとEC2 VPCという2つのプラットフォームに分類されています。クラシックプラットフォーム内のインスタンスを起動すると、そのインスタンスは他のAWSテナントが共有するネットワークで起動されます。一方、VPCでインスタンスを起動すると、リソースは他のネットワークからロジカルに隔離されます。

推奨：

インスタンスをVPCに移行してください。

必要な権限：

"ec2:DescribeInstances"

10. EC2システムステータスチェックの失敗（優先度：高）

ベースライン：

システム到達チェックの失敗

説明：

システムステータスチェックはAmazon EC2で提供されていて自動的に行われます。これはEC2インスタンスをホストしているAWS物理インフラで行われている運用の信頼性を確認します。

推奨：

自動アクションを設定し、インスタンスを再起動してください。定期的にシステムチェックが失敗するインスタンスある場合は、そのインスタンスを置き換えるか、インスタンスタイプを変更してください。

必要な権限：

"ec2:DescribeInstances"、"ec2:DescribeInstanceStatus"

11. EC2インスタンスのステータスチェックの失敗（優先度：高）

ベースライン：

インスタンス到達チェックの失敗

説明：

Amazon EC2自体にインスタンスステータスチェックという自動チェック機能がサポートされています。このチェックはアドレス解決プロトコル（ARP）を送信することで、インスタンスの死活確認を行います。

推奨：

OSやネットワーク設定をチェックすることでシステムログを取得し、インスタンス再起動といったトラブルシューティングや自動アクションを設定します。

必要な権限：

"ec2:DescribeInstances"、"ec2:DescribeInstanceStatus"

12. EC2インスタンスのメンテナンススケジュール（優先度：中）

ベースライン：

Elastic Compute Cloud（EC2）インスタンスのメンテナンススケジュールイベントを確認します。

説明：

使用しているインスタンスでAWSがシステムメンテンナンスイベントをスケジューリングし、その物理ホストの定期的なメンテナンスタスクを実行する場合があります。

推奨：

監視しているEC2インスタンスをSite24x7のメンテナンスウィンドウに関連付けることで、アラートを抑制し、その間も監視を続けるように設定します。

必要な権限：

"ec2:DescribeInstances"、"ec2:DescribeInstanceStatus"

13.使用していないAmazon EC2セキュリティグループ（優先度：低）

リソースレベルの説明：

使用していないEC2セキュリティグループでも追加課金が発生します。

ベースライン：

使用していないEC2セキュリティグループが存在するかを確認します。

説明：

使用していないAmazon EC2セキュリティグループをアカウントから削除し、追加課金の発生を防ぎます。

推奨：

インスタンスにアタッチされていないセキュリティグループを削除します。使用率の低いセキュリティグループを誤ってEC2インスタンスにアタッチしないようにし、外部からの攻撃から保護します。

14. EC2インスタンスがインスタンスメタデータサービスを使用していない。

ベースライン：

インスタンスがインスタンスメタデータサービスのv2を使用していないかどうかを確認します。

説明：

EC2 IMDSはインスタンスメタデータの値をクエリするのに使用されます。IMDSはローカルで全てのインスタンスにアタッチされていて、特有の"link local"のIPアドレスで稼働します。デフォルトではIMDSv1とIMDSv2の両方をインスタンスで使用できます。IMDSがv2にのみ制限されている場合、セキュリティがより強化されるため、IMDSv2を使用することが重要です。

推奨：

すべてのEC2インスタンスにIMDSv2を使用してネットワークの脆弱性を守ります。

15. 停止したEC2インスタンスの特定期間経過後の削除

ベースライン：

許可した日にち以上に停止されているEC2インスタンスがあるかを確認します。

説明：

EC2インスタンスを停止した時、ストレージの課金は引き続き発生します。しかしインスタンスを削除した場合には課金は停止します。加えて、EC2インスタンスが一定期間稼働していない場合、インスタンスがアクティブに維持されていない可能性があるため、リスクが高くなる可能性があります。

推奨：

一定期間停止しているEC2インスタンスがないかを確認します。

16. Amazon EC2 - 複数ENIのアタッチ（優先度：低）

ベースライン：

Amazon EC2インスタンスに複数Elastic Network Interfaces (ENI)がアタッチされているか確認します。

説明：

複数のENIデュアルホストインスタンスを引き起こし、複数のサブネットがインスタンスに割り当てられます。これにより、ネットワークセキュリティ問題が発生し、意図しないネットワークパスやアクセスを引き起こします。

推奨：

必要のないENIをインスタンスから取り除きます。

必要な権限：

• "ec2:DescribeInstances"

17. Amazon EC2 - Para-virtual仮想化タイプインスタンス（優先度：中）

ベースライン：

Para-virtual仮想化タイプのEC2インスタンスが存在するか確認します。

説明：

Linux Amazon Machine Image (AMI)は、Para-virtual (PV)またはハードウェア仮想マシン (HVM)の2タイプのいずれかを使用します。PVとHVM AMIでは起動の方法が異なります。HVMタイプベースのインスタンスでは、PVベースと比べより高いパフォーマンスを持ちます。

推奨：

HVM仮想化タイプのインスタンスに変更します。

必要な権限：

• "ec2:DescribeInstances"

18. Amazon EC2 - 詳細なインスタンス監視（優先度：低）

ベースライン：

EC2インスタンスの詳細な監視が有効化されているか確認します。

説明：

デフォルトでEC2インスタンスには基本的な監視が有効化されています。詳細監視を有効にすることができ、より多くのメトリックを取得できます。
これらメトリックごとに課金が発生します。

推奨：

EC2インスタンスの詳細監視が有効となっているかを確認します。

必要な権限：

• "ec2:DescribeInstances"

1. スナップショットのないEBSボリューム （優先度：高）

ベースライン：

スナップショットIDと関連付けられているAmazon Elastic Block Store (EBS)ボリューム設定を確認します。

説明：

EBSはEC2インスタンスの永続的なブロックレベルのストレージを提供します。スナップショットはEBSボリューム内に保存されているデータのある時点での追加バックアップです。冗長化において、これらスナップショットは複数のアベイラビリティゾーンにわたったS3バケットに保存されます。また障害時には、スナップショットは新規ボリュームに作成されたり、アベイラビリティゾーンまたは領域のような領域に移動します。

推奨：

EBSボリュームの週ごとのスナップショットの作成するようにします。

必要な権限：

"ec2:DescribeVolumes"、"ec2:DescribeSnapshots"

2. 最近のスナップショットのないEBSボリューム（優先度：中）

ベースライン：

過去30日の間に取得されているEBSスナップショットがない。

説明：

スナップショットはEBSボリュームのその時の状態を記録します。障害時、元のボリュームを複製したものがこれらスナップショットを用いて作成されます。

推奨：

EBSボリュームが変更される頻度に基づき、スナップショットを撮影するスケジュールを自動的に設定し、EBSデータの保護と回復を向上させます。

必要な権限：

"ec2:DescribeVolumes"、"ec2:DescribeSnapshots"

3. 停止しているEC2インスタンスに接続しているEBSボリューム（優先度：中）

ベースライン：

EBSが接続しているEC2インスタンスの状態を確認します。

説明：

インスタンスがどのような移行を行っても、それに伴ってEBSボリュームは永続的に持続し続けます。EBSは提供されたストレージ容量に基づいて支払いが発生します。IOPS(Only for Provisioned IOPS SSD (io1) Volumes)はストレージが解放されるまでです。

推奨：

EBSボリュームのスナップショットを作成し、ストレージを解放してください。

必要な権限：

"ec2:DescribeInstances"、"ec2:DescribeVolumes"

4. 接続されていないEBSボリューム（優先度：中）

ベースライン：

関連付けられているインスタンスIDのEBSボリューム設定を確認します。

説明：

EBSボリュームはインスタンス終了したり、インスタンスからボリュームをアンマウントや解除したりしても、ボリュームは独立して保持できます。よく知られていることですが、接続されていないボリュームは提供されたストレージに基づいて、IOPSに対して課金が発生します。

推奨：

EBSボリュームをアクティブなインスタンスを関連付けて、ストレージボリュームを解放してください。

必要な権限：

"ec2:DescribeVolumes"

5. Amazon EBS：暗号化（優先度：高）

ベースライン：

EBSボリュームの設定を確認し、暗号化されていないボリュームがある場合は警告します。

説明：

EBSボリュームが暗号化されていて、それがEC2インスタンスに接続されている場合、ボリューム内の全てのデータが暗号化されます。また、ボリュームとインスタンス間で移行したデータは全て暗号化されます。

推奨：

重要なデータが保存されている場合、そのボリュームを暗号化してください。

6. Amazon EBS：AWS管理のCMKを用いた暗号化（優先度：高）

ベースライン：

EBSボリュームの設定を確認し、AWS管理のCMKを用いた暗号化が有効化されているボリュームを識別してください。

説明：

Amazon EBSの暗号化にはAWSキー管理サービスであるCMKを用います。CMKには、顧客管理のCMK、AWS管理のCMK、AWSが所有するCMKも3つのタイプがあります。顧客管理のCMKが一番柔軟に利用することができ、キー条件やIAM条件などの設定と維持を行うことができます。

推奨：

顧客管理のCMKを作成し、ボリュームを暗号化します。

1. 使われていないELB（優先度：高）

ベースライン：

監視しているクラシックロードバランサーの設定を確認し、バックエンドのインスタンスに登録されていないELBノードを特定します。

説明：

設定されているロードバランサーは削除しない限り課金が発生します。ロードバランサーに登録されていないバックエンドのインスタンスがある場合、それを効果的に利用できているとは言えません。

推奨：

インスタンスをロードバランサーに追加・登録するべきか、またはそれを削除するべきかを検討してください。

必要な権限：

"elasticloadbalancing:DescribeLoadBalancers"、"elasticloadbalancing:DescribeInstanceHealth"

2. アイドルなELB（優先度：高）

ベースライン：

監視しているクラシックなロードバランサーの使用率状況で、入力/出力要求数や目的インスタンスへのTCP接続数が過去48時間に100より低くアイドルとしてみなされているかを確認します。

説明：

ロードバランサーの稼働時間に応じてAWSで課金が発生します。ロードバランサーのルーティングでその要求数が100に満たない場合は、適切に使用できているとは言えません。

推奨：

ロードバランサーを使用していないアプリケーションを継続的に使用するか、削除するかを検討します。

必要な権限

"elasticloadbalancing:DescribeLoadBalancers"、"cloudwatch:GetMetricData"、"cloudwatch:GetMetricStatistics"、"cloudwatch:ListMetrics"

3. ロードバランサーの正常に機能しているインスタンス数の把握（優先度：中）

ベースライン：

ロードバランサーの"正常なホスト数"を確認し、しきい値を下回った際にそれを警告します。

説明：

ロードバランサーは全ての登録されているインスタンスの死活確認を行い、インスタンスが正常に機能しているかを確認します。しかし、この死活確認の設定が制限されている場合があり、正常なインスタンスでも異常とみなされることがあります。

推奨：

死活確認の設定を行い、そのしきい値やタイムアウトの最適化を行います。

必要な権限：

"elasticloadbalancing:DescribeLoadBalancers"、"elasticloadbalancing:DescribeInstanceHealth"

4. 複数のアベイラビリティゾーンで使用されていないELB（優先度：高）

ベースライン：

単一のアベイラビリティゾーンでのみ稼働しているロードバランサーを確認します。

説明：

単一のアベイラビリティゾーンで起動しているEC2インスタンスがある場合、そのデータセンターで障害が発生すると、その中の全てのインスタンスが利用できなくなる可能性があります。同じ領域の異なるアベイラビリティゾーンに、複数EC2インスタンスを配置することで、その障害発生部分を取り除くことができます。

推奨：

復旧力と障害耐性を高めるには、異なるアベイラビリティゾーンに接続されているロードバランサーにEC2インスタンスを接続してください。

必要な権限：

"elasticloadbalancing:DescribeLoadBalancers"

5. ELB：クロスゾーンロードバランス（優先度：高）

ベースライン：

ELBのクロスゾーンロードバランスが無効となっているかを確認します。

説明：

クラシックタイプのELBではデフォルトで、クロスゾーンロードバランスが有効化されていません。一般的に、ロードバランサーは設定しているアベイラビリティゾーンへの流入トラフィックを均等に分配しています。しかし、各ゾーンで稼働しているEC2インスタンスの数が均等でない場合、ロードの不一致が引き起こされる可能性があります。このような状況はヘルスチェックの失敗やメンテナンスの除去があった際の、手動での登録解除やデタッチによって簡単に引き起こされてしまいます。クロスゾーンロードバランスを有効化すれば、ELBがアプリケーションのトラフィックを登録されているインスタンスでのみ均等に分配します。

推奨：

クラシックタイプのELBのクロスゾーンバランスを有効にします。

必要な権限：

"elasticloadbalancing:DescribeLoadBalancers"

6. ELB：アクセスログ（優先度：中）

ベースライン：

ロードバランサーの設定で、ELBのアクセスログが有効となっているかを確認します。

説明：

アクセスログはロードバランサーが受け取った各要求の詳細な情報を取得して保存します。IPアドレス、レイテンシー、要求パス、バックエンドのサーバー応答といった情報が設定したAmazon S3バケットに保存されます。AWSアカウントのユーザーはこれらをトラフィックパターンの解析やアドバンス型ELBにあった障害のトラブルシュートに用いることができます。

推奨：

デフォルトで、アクセスログ機能は無効となっているため、使用しているELBでこの機能を有効化してください。

必要な権限：

"elasticloadbalancing:DescribeLoadBalancers"

7. ELB：接続ドレイン（優先度：高）

ベースライン：

監視しているELBを確認し、接続ドレインが無効となっているELBノードを特定します。

説明：

死活確認の失敗によって削除または登録解除されたEC2インスタンスがある場合、ELBは新規要求のルーティングを停止し、インスタンスへの接続を閉鎖します。接続ドレインを有効にすると、ELBはセッションが完了するまでその接続を試行し続けます。

推奨：

ロードバランサーの接続ドレインを有効化してください。

必要な権限：

"elasticloadbalancing:DescribeLoadBalancers"

8. ELB：リスナーセキュリティ（優先度：高）

ベースライン：

クラシックまたはアプリケーションタイプのELBの設定を確認し、安全なプロトコル（HTTPSまたはSSL）を用いているリスナーではない場合に警告します。

説明：

リスナーは接続要求を確認するプロセスです。ELBにHTTPSの設定されていないリスナーがいる場合に、そのような許可されていない関係者はクライアントとロードバランサー間のネットワークで送信されたデータのみ閲覧することができます。

推奨：

ロードバランサーにSSL証明書を配置し、HTTPリスナーのSSL/TLSサポートを有効にしてください。

1. IAMユーザーのアクセスキー（優先度：中）

ベースライン：

アクセスキーの作成日時を確認し、90日より古いキーのIAMユーザーを特定します。

説明：

アクセスキーはアクセスキーIDとシークレットアクセスキーで構成されていて、AWS APIエンドポイントへの要求にプログラムで署名することに用いられます。

推奨：

セキュリティのベストプラクティスとして、定期的にアクセスキーを変更を行うことでアクセスキーが有効である期間を短くするようにします。

必要な権限：

"iam:ListUsers"、"iam:ListAccessKeys"

2. IAMグループ：インラインポリシー（優先度：情報)

ベースライン：

インラインポリシーのIAMグループを確認します。

説明：

IAMポリシーはIAMのユーザー、権限、グループに割り当てることができるJSONポリシーのドキュメントです。管理ポリシーを用いる利点として、それらの維持や新規AWSサービスの更新、APIの導入が更新できることです。

推奨：

AWS管理ポリシーを用いて、IAMグループへの許可を付与します。

必要な権限：

"iam:ListGroupPolicies"

3. 管理者権限をもつIAMユーザー（優先度：高）

ベースライン：

アカウント内の各IAMユーザーを確認し、管理者アクセスが割り当てられている管理ポリシーのあるユーザーを特定します。

説明：

管理者のアクセスポリシーは表示、読み込み、書き込み、許可管理といった全ての4つのアクセスレベルの許可が付与されています。管理者のアクセスを制限しないと、リソースの孤立やセキュリティの問題、AWS請求書の予期しない急増に簡単につながってしまいます。

推奨：

IAMユーザーにアクセス権限を付与する場合は最小限の権限を付与するようにしてください。例としては、タスクを行うのに必要な権限のみを付与するなどが考えられます。

必要な権限：

"iam:ListEntitiesForPolicy"

4. 全ての管理者権限をもつIAMロール（優先度：高）

ベースライン：

アカウントの各IAMロールを確認し、管理者アクセス権限が割り当てられているロールを特定します。

説明：

管理者のアクセスポリシーによって、ユーザーがコンテンツの読み込み、作成、削除、修正、許可権限の修正を行うことができます。

推奨：

このポリシーはアカウントの管理者にだけ割り当ててください。そして、リソースを安全に保つために、IAMポリシーに他のロールが割り当てられていないかを定期的に確認してください。

必要な権限：

"iam:ListAttachedRolePolicies"

5. 必要のないアクセスキー（優先度：高）

ベースライン：

2つのアクセスキーをもつIAMユーザーを確認します。

説明：

IAMユーザーはアクセスキーを用いて、AWSサービスAPIへの安全なRESTやHTTP要求を行います。

推奨：

ベストプラクティスとして、アクティブなキーを1つのみにするようにしてください。

必要な権限：

"iam:ListUsers"、"iam:ListAccessKeys"

6. 使われていないIAMユーザー（優先度：中）

ベースライン：

プログラムアクセスのないIAMユーザーのコンソールパスワードの使用期間を確認し、それが使われていない場合に警告します。

説明：

コンソールパスワードはIAMユーザーがAWS管理コンソールにサインインするために使うものです。使われていないIAMユーザーを削除するかパスワードを無効化することで、AWSアカウントのセキュリティをより高めることができます。

推奨：

使われていないIAMユーザーを削除してください。

必要な権限：

"iam:ListUsers"、"iam:GetLoginProfile"

7. 無効なIAMユーザー（優先度：中）

ベースライン：

プログラムアクセスの無いIAMユーザーのコンソールパスワードの使用期間を確認し、過去90日間でそれが使用されていない場合に警告します。

説明：

コンソールパスワードはIAMユーザーがAWS管理コンソールにサインインするために使うものです。使われていないIAMユーザーを削除するかパスワードを無効化することで、AWSアカウントのセキュリティをより高めることができます。

推奨：

無効なIAMユーザーを削除するか、サインインの認証情報を無効化してください。

必要な権限：

"iam:ListUsers"、"iam:GetLoginProfile"

8. MFA：AWS rootアカウント（優先度：高）

ベースライン：

多要素認証がルートアカウントで有効化となっているかどうかを確認します。

説明：

すでに知っている方も多いと思いますが、ルートアカウントを持っている人は、そのアカウント内の全てのAWSサービスやリソースにアクセスすることができます。2段階あるいは多要素認証を追加し、パスワードや時間で同期されるワンタイムパスワードを用いることで、重要なAWSリソースを保護することができます。

推奨：

トークンベースの多要素認証を用いて、AWSアカウントを保護します。

9. IAMグループ（優先度：高）

ベースライン：

AWSアカウントにIAMグループが作成されているかどうかを確認します。

説明：

IAMユーザーを作成することで、チームメンバーがAWSコンソールへサインインできたり、AWSサービスへのプログラムを用いた要求を行えるようになります。ポリシーをユーザーに直接追加したり、手動で権限を編集する代わりに、IAMグループ（複数のIAMユーザー）を作成して簡単に管理を行うことができます。

推奨：

異なる権限を持った複数のIAMグループを作成してください。

必要な権限：

iam:ListGroups"

10. IAMパスワードポリシー（優先度：高）

ベースライン：

パスワードポリシーがAWSアカウントに設定されているかを確認します。

説明：

複雑なパスワード要求（長さや文字のタイプ）や定期的にIAMユーザーのパスワードを変更するといったパスワードポリシーを作成します。

推奨：

パスワードポリシーを設定し、より複雑なパスワードを作成するようにします。

必要な権限：

"iam:GetAccountPasswordPolicy"

11. IAMユーザー：サポートアクセス（優先度：中）

ベースライン：

"AWSSupportAccess"というIAMポリシーが各IAMロールに追加されたIAMポリシーのリストを確認します。

説明：

管理ポリシーの"AWSSupportAccess"はIAMユーザーにアクセス権を付与し、AWSサポートセンターを管理します。

推奨：

許可のあるAWSアカウントのIAMユーザーが1つ以上作成されていてサポートケースを管理していることを確認します。

必要な権限：

"iam:ListEntitiesForPolicy"

12. AWSルートアカウントユーザー：アクセスキー（優先度：高）

ベースライン：

有効なアクセスキーのAWSアカウントルートユーザーを確認します。

説明：

アクセスキーはREST APIやHTTP要求を安全に行うために用いられています。このキーを用いることで、AWSルートアカウントのユーザーは請求に関するデータなどといった全てのリソースに制限なくアクセスできます。

推奨：

ルートユーザーのアクセスキーを削除するか、無効にしてください。

13. IAMパスワードポリシーに少なくとも1つの大文字、小文字、記号、数字が必須であるかを確認 (優先度：中)

ベースライン：

IAMパスワードポリシーに少なくとも1つの大文字、小文字、記号、数字が必須であるかを確認します。

説明：

管理者がカスタムパスワードポリシーを設定していない場合、IAMユーザーパスワードに少なくとも1つの大文字、小文字、記号、数字を含ませる必要があります。

推奨：

強固なIAMパスワードの作成と頻繁にそれを変更することでセキュリティを維持します。

14. グループやロールにのみIAMポリシーがアタッチされていることを確認 (優先度：低)

ベースライン：

IAMポリシーがグループやロールにのみアタッチされているかを確認します。

説明：

IAMユーザーレベルではなくIAMグループレベルの権限を定義することでAWSリソースへのユーザーベースアクセスを効率的に管理します。各ユーザーでポリシーを定義したりグループ間で既存ユーザーで切り替える必要がなくなるため、情報の重複を防ぎ、労力を削減できます。

推奨：

既存のIAMポリシーがグループやロールにのみアタッチされていて全ユーザーに効率的に権限を割り当てているかを確認します。

15. IAMパスワードポリシーに少なくとも1つの大文字、小文字、記号、数字が必須であるかを確認 (優先度：中)

リソースレベルの説明：

IAMパスワードポリシーに少なくとも1つの大文字、小文字、記号、数字が必須であるかを確認します。

ベースライン：

IAMパスワードポリシーに少なくとも1つの大文字、小文字、記号、数字が必須であるかを確認します。

説明：

管理者がカスタムパスワードポリシーを設定していない場合、IAMユーザーパスワードに少なくとも1つの大文字、小文字、記号、数字を含ませる必要があります。

推奨：

強固なIAMパスワードの作成と頻繁にそれを変更することでセキュリティを維持します。

16. グループやロールにのみIAMポリシーがアタッチされていることを確認 (優先度：低)

リソースレベルの説明：

AMポリシーがグループやロールにのみアタッチされているかを確認します。

ベースライン：

AMポリシーがグループやロールにのみアタッチされているかを確認します。

説明：

IAMユーザーレベルではなくIAMグループレベルの権限を定義することでAWSリソースへのユーザーベースアクセスを効率的に管理します。各ユーザーでポリシーを定義したりグループ間で既存ユーザーで切り替える必要がなくなるため、情報の重複を防ぎ、労力を削減できます。

推奨：

既存のIAMポリシーがグループやロールにのみアタッチされていて全ユーザーに効率的に権限を割り当てているかを確認します。

1. パブリックS3バケット（優先度：中）

ベースライン：

監視しているS3バケットのバケットやユーザーポリシー（アクセスコントロールリストではありません）を確認し、パブリックにアクセスできるバケットを特定します。

説明：

パブリックにアクセスできるとは、保存、アップロード、削除されたリソースをリストにし、それを世界中の人が読み込めることを意味します。S3の場合、要求タイプや要求量、取得されたデータ量に応じて課金が発生します。

推奨：

特定のバケットに本当にパブリックアクセスが必要かを検討します。もし必要でなければ、アクセスを制限してリソースをプライベートにしてください。

必要な権限：

"s3:ListBucket"、"s3:GetBucketPolicyStatus"

2. Amazon S3：デフォルトの暗号化（優先度：中）

ベースライン：

Amazon S3バケットでデフォルトのS3暗号化が無効化されていることを確認します。

説明：

サーバー側の暗号化または保管時の暗号化において、リソースレベルでデータをAmazon S3が暗号化します。

推奨：

Amazon S3管理キー（SSE-S3）かAWS KMS管理キー（SSE-KMS）を用いて、サーバー側の暗号化を行ってください。

必要な権限：

s3:GetEncryptionConfiguration"、"s3:ListBucket"

3. Amazon S3：アクセスログ（優先度：中）

ベースライン：

Amazon S3バケットでサーバアクセスログが無効となっているかを確認します。

説明：

デフォルトでAmazon S3はサーバーアクセスログを収集しません。ログを有効化することで、アクセス者、バケット名、要求時間、応答ステータスなどといった選択された目的バケットのアクセス要求についての情報を保存できます。サーバーアクセスログの課金は発生しません。ただし、通常の保存課金は発生します。

推奨：

S3バケットのサーバーアクセスログを有効にし、セキュリティとアクセスの管理を行いやすくします。

必要な権限：

s3:GetBucketLogging"、"s3:ListBucket"

4. Amazon S3：MFA削除（優先度：中）

ベースライン：

Amazon S3バケットの設定を確認し、MFA削除が無効となっているバケットを特定します。

説明：

MFA削除はバージョンの変更や削除操作をバケットに行う際に、追加で認証を行うようにします。

推奨：

MFA削除を有効化することで、セキュリティ層をS3バケットに追加します。

必要な権限

"s3:ListBucket"、"s3:GetBucketVersioning"

5. Amazon S3：バケットポリシーでSSLを用いるリクエストのみを許可（優先度：中）

ベースライン：

S3バケットポリシーでSSLでのリクエストのみを許可しているかどうかを確認します。

説明：

S3バケットでSSL接続を行うように設定する必要があります。行っていない場合、ユーザー、アプリケーション、バケット間の接続が、盗聴や中間者（MITM）攻撃に脆弱になります。

推奨：

機密データを処理するときは、SSLを利用していないHTTPリクエストはすべて拒否し、SSL限定アクセスを実施してください。

6. Amazon S3：S3バケットでクロスリージョンレプリケーションを有効にする（優先度：中）

ベースライン：

S3バケットでクロスリージョンレプリケーションが有効となっているかどうかを確認します。

説明：

クロスリージョンレプリケーションを有効化すると、異なるAWSリージョンのS3バケットでデータの複製やオブジェクトのコピーを自動で行えます。障害時の復旧計画やパフォーマンスの最適化などにより、アプリケーションの可用性や信頼性を向上させます。

推奨：

すべてのS3バケットでクロスリージョンレプリケーションを有効化します。

7. S3バケット CloudTrailログがパブリックにアクセスできないことを確認 (優先度：高)

ベースライン：

S3バケットCloudTrailログがパブリックにアクセス可能かどうかを確認します。

説明：

Amazon S3バケットとオブジェクトはデフォルトでプライベート設定となっており、バケットを作成し、それが含むオブジェクトを作成したユーザーのみがアクセスできます。CloudTrailログにはアカウントのAPIアクティビティの詳細イベントが含まれているかもしれません。S3バケットのCloudTrailログに付与されている権限が安全でない場合、ログデータに悪意のあるユーザーがアクセスしてしまう可能性があり、未認証のアクセスのリスクが増加します。

推奨：

CloudTrailログに関連付けられているS3バケットがパブリックにアクセスできないことを確認し、ログデータを保護します。

8. バケットポリシー内のその他アカウントに付与されているS3権限が制限されているかを確認 (優先度：高)

ベースライン：

バケットポリシーで他のアカウントに付与されているAmazon S3権限が制限されているかどうかを確認します。

説明：

共有バケットを使用している場合は、他のアカウントの最小限の認証アクセスを付与します。他アカウントでの主要な拒否アクションは次のとおりです。

• s3:DeleteBucketPolicy
• s3:PutBucketAcl
• s3:PutBucketPolicy
• s3:PutEncryptionConfiguration
• s3:PutObjectAcl

推奨：

エラーや悪意のある攻撃の影響を減らすために、共有Amazon S3バケットを使用している間は、他のAWSアカウントのプリンシパルがS3のリソースに対して拒否されたアクションを実行しないでください。

9. バケットポリシー内のその他アカウントに付与されているS3権限が制限されているかを確認 (優先度：高)

リソースレベルの説明：

バケットポリシーで他のアカウントに付与されているAmazon S3権限が制限されているかどうかを確認します。

ベースライン：

バケットポリシーで他のアカウントに付与されているAmazon S3権限が制限されているかどうかを確認します。

説明：

共有バケットを使用している場合は、他のアカウントの最小限の認証アクセスを付与します。他アカウントでの主要な拒否アクションは次のとおりです。

• s3:DeleteBucketPolicy
• s3:PutBucketAcl
• s3:PutBucketPolicy
• s3:PutEncryptionConfiguration
• s3:PutObjectAcl

推奨：

エラーや悪意のある攻撃の影響を減らすために、共有Amazon S3バケットを使用している間は、他のAWSアカウントのプリンシパルがS3のリソースに対して拒否されたアクションを実行しないでください。

1. RDSセキュリティグループ：制限されていないインバウンドアクセス（優先度：中）

ベースライン：

CIDR表記0.0.0.0/0のIPをアドレスを持つインバウンドルールのRDS VPCセキュリティグループを確認します。

説明：

VPCセキュリティグループはDBインスタンスへのトラフィックアクセスを制御します。特定のIPレンジ、ポート、EC2セキュリティグループからのアクセスを許可するセキュリティグループのルールを追加します。

推奨：

特定のIPアドレスのアクセスを制限し、悪意のあるアクセスを防止します。

必要な権限

"rds:DescribeDBInstances"、"rds:DescribeDBSecurityGroups"

2. パブリックRDSインスタンス（優先度：高）

ベースライン：

アクセス可能な機能を確認し、パブリックにアクセスできるDBインスタンスを特定します。

説明：

パブリックに解決可能なDNSを持つインターネットに接続されたDBインスタンスは予期しないデータ転送などの恐れが発生しやすくなります。

推奨：

パブリックにアクセス可能のフラッグを無効にします。

必要な権限：

"rds:DescribeDBInstances"

3. RDSの自動バックアップ（優先度：高）

ベースライン：

設定を確認し、自動バックアップが無効となっているRDS DBインスタンスを特定します。

説明：

Amazonは一定期間で全てのDBインスタンスのストレージのバックアップを行い、ある日数の間、そのバックアップを保存してその時点での復旧に役立てます。

推奨：

スムーズなデータ復元のためにRDSインスタンスの自動バックアップを有効にします。

必要な権限：

"rds:DescribeDBInstances"

4. Amazon RDS：暗号化（優先度：高）

ベースライン：

暗号化が有効になっていないAmazon RDS DBインスタンスを確認します。

説明：

ストレージ、自動バックアップ、リードレプリカ、スナップショットといったRDSの保存データを暗号化し、保護のレイヤーを強化します。

推奨：

RDS DBインスタンス作成時に暗号化を有効化にするか、DBスナップショットのコピーを暗号化して、暗号化したスナップショットからインスタンスを復元してください。

必要な権限：

"rds:DescribeDBInstances"

5. RDS：複数のアベイラビリティゾーン（優先度：中）

ベースライン：

単一のアベイラビリティゾーンにDBインスタンスが配置されているかを確認します。

説明：

複数のアベイラビリティゾーンの配置で、Amazonは異なるアベイラビリティゾーンを提供し、データを同期して複製します。障害やメンテナンスの際は、Amazon RDSは手動作業不要で、自動的にフェイルオーバーを行います。

推奨：

複数のアベイラビリティゾーンにDBインスタンスを配置するか、既存のDBインスタンスを複数のアベイラビリティゾーンに配置します。

必要な権限：

"rds:DescribeDBInstances"

6. Amazon RDS：使用率上昇（優先度：高）

ベースライン：

Amazon RDSのCloudWatchのパフォーマンスカウンターを確認し、使用率の高くなっているDBインスタンスを特定します。

説明：

RDSインスタンスが次の条件に該当すると、使用率上昇と判定します。

• 最新7日間のうちの最低4日で、1日の平均CPU使用率が90％を超えている場合。
• 最新7日間のうちの最低4日で、ディスク消費量が85％を超えている場合。

推奨：

マスターデータベースをスケールアップするか、リードレプリカを使用してアプリケーションの要求に対応します。

7. Amazon RDS：アイドルDBインスタンス（優先度：高）

ベースライン：

Amazon RDSインスタンスのCloudWatchパフォーマンスカウンターを確認し、十分に利用されていないように見えるDBインスタンスを特定します。

説明：

RDSインスタンスは次の条件に該当するとアイドルとみなされます。

• 最新7日間のうちの最低4日で、1日の平均CPU使用率が20％に満たない場合。
• 最新7日間のうちの最低4日で、1日の平均データベース接続数が100回に満たない場合。

推奨：

Amazon RDSの場合、DBインスタンス稼働していた時間に応じて、コンピューター容量を支払います。DBインスタンスが少ない接続数受け取っていたり、少ないCPU量を消費している場合、スナップショットを作成して、インスタンスを削除してコストを削減します。

8. Amazon RDS：RDSスナップショットのパブリックアクセスを禁止（優先度：高）

ベースライン：

AWS RDSスナップショットがパブリックにアクセスできるかどうかを確認します。

説明：

RDSクラスタースナップショットは、単一のデータベースだけではなく、データベースクラスター全体のバックアップを取得します。機密データの漏洩や不正使用を防ぐために、スナップショットを非公開にして他のAWSユーザーが新しいボリュームにアクセス、コピー、作成できないようにしてください。

推奨：

データ漏洩を防ぐために、AWS RDSスナップショットが全てのAWSアカウントとユーザーに共有されているなど、パブリックアクセスができる状態にはなっていないことを確認してください。

9. Amazon RDS： RDSクラスターの削除保護を有効化（優先度：中）

ベースライン：

Amazon RDSクラスターで削除保護が有効となっているかを確認します。

説明：

Amazon RDSクラスターの削除保護が有効化されていると、クラスターが突然削除されることがなくなり、データ喪失を防止できます。Amazon Auroraデータベースを含めた全てのRDSデータベースエンジンでこの設定を有効にできます。

推奨：

全てのデータベースエンジンでRDSクラスター削除保護設定を有効にしてください。

1. SNS：トピック（全員）へのパブリックメッセージ（優先度：中）

ベースライン：

全員がパブリックに許可されているトピックで、Amazon SNSトピックのアクセスポリシーを確認します。

説明：

全てのAWSユーザーやリソースにパブリックメッセージを許可することは、予期しないSNSの課金額増加につながります。

推奨：

トピックオーナーや特定のユーザーのみにパブリックメッセージを許可します。

必要な権限：

sns:GetTopicAttributes"、"sns:ListTopics"

2. SNS：トピックへのサブスクリプション（全員）（優先度：中）

ベースライン：

匿名のサブスクリプションが許可されているトピックで、Amazon SNSトピックのアクセスポリシーを確認します。

説明：

全員にサブスクライブを許可することは、メッセージの機密性を損なうことにつながります。例えば、権限のないのエンティティがトピックにサブスクライブし、公開されているメッセージを受け取ることができます。

推奨：

トピックオーナーや特定のエンドポイントへのサブスクリプションを制限し、トピックのセキュリティを保ちます。

必要な権限：

sns:GetTopicAttributes"、"sns:ListTopics"

3. Amazon SNS：サブスクライバーとしてのHTTPエンドポイント（優先度：中）

ベースライン：

サブスクライバーとしてのHTTPエンドポイントのSNSトピックを確認します。

説明：

Amazon Simple Notification Service (SNS)は公開者とサブスクライバーの観点から働く非同期なメッセージ配信サービスです。HTTP/HTTPSエンドポイントをトピックにサブスクライブし、メッセージを公開する場合、SNSはメッセージのコンテンツを選択したエンドポイントへPOST要求を送信します。しかし、HTTP経由のメッセージ送信は盗聴に対して脆弱である可能性があります。

推奨：

URLを購読する場合は、HTTPSやHTTPを選択します。

1. DynamoDB：オートスケール（優先度：高）

ベースライン：

手動で管理されているテーブルスループットのあるAmazon DynamoDBテーブルを確認します。

説明：

Amazon DynamoDBにテーブルを作成する場合、読み込みと書き込みの容量条件を入力します。適切な容量を推定する、またはプロビジョニングされた容量を手動で設定することは、周期的または予測不可能なDBワークロードを処理する場合に長期的には運用負担になる可能性があります。

推奨：

Dynamo DBのオートスケーリングを用いてトラフィックパターンを自動化することで、応答のテーブルスループットの容量を動的に調整します。

2. DynamoDB：オンデマンドのバックアップや保存（優先度：高）

ベースライン：

過去30日間でAmazon DynamoDBテーブルのバックアップがないことを確認します。

説明：

データのアーカイブは長期的なデータの保持と規制コンプライアンス要件に重要です。Amazon DynamoDBは秒単位でテーブルの全バックアップを作成し、アプリケーションパフォーマンスや可用性への衝撃なくデータを保存できます。

推奨：

バックアップを実行し、AWS管理コンソールやDynamo APIで用いられているDymanoDBテーブルの操作を保存します。

3. DynamoDB：サーバー側の暗号化（優先度：高）

ベースライン：

リセット時の暗号化が無効となっているAmazon DynamoDBテーブルを確認します。

説明：

テーブル、ローカルセカンダリインデックス、グローバルセカンダリインデックスといったデータのリセット時の暗号化をAES-256やAWSキー管理サービス（KMS）を用いて有効にし、重要な情報を保護し、コンプライアンス要件をアーカイブします。

推奨：

既存のテーブルではリセット時の暗号化を有効にできません。AWS管理コンソールやAPIを用いて新しく暗号化テーブルを作成します。

4. DynamoDB：使われていないテーブル（優先度：中）

ベースライン：

Amazon DynamoDBテーブルが稼働しているかを確認し、総アイテム数がない場合に警告します。

説明：

DynamoDBの場合、手動でプロビジョニングされるスループット、またはAmazonが目的の読み込みおよび書き込み容量を維持するためにプロビジョニングするリソースに対して支払いが発生します。そのため、設定されている全てのテーブルに課金が発生し続けます。データのないテーブルのある場合、それは効率的に用いられているとは言えません。

推奨：

使われていないテーブルを削除することを検討します。

5. Amazon DynamoDB - ポイントインタイムリカバリー（優先度：中）

Baseline:

Amazon DynamoDBテーブルでポイントインタイムリカバリー（PITR）が有効化されているか確認します。

説明：

バックアップはセキュリティインシデントの早期回復に役立ち、システムの回復を強化します。DynamoDB PITRはテーブルのバックアップを自動化し、意図しない削除や書き込み操作からの回復を早めます。PITRが有効化されているDynamoDBテーブルは、直近35日までリストア可能です。

推奨：

DynamoDBテーブルのPITRを有効化します。

必要な権限：

• "dynamodb:DescribeContinuousBackups"

1. SQS：サーバー側暗号化 (SSE)（優先度：中）

ベースライン：

SQSのクエリー設定を確認し、サーバー側の暗号化が無効となっている場合に警告します。

説明：

サーバー側の暗号化はメッセージ本体を暗号化し、分配されたアプリケーションコンポーネントやマイクロサービス間の重要なデータのやり取りに信頼性を持たせます。

推奨：

既存のキューのサーバー側の暗号化を有効化するか、キュー作成の際にこの機能を有効化してください。

2. SQS - AWS管理CMKを用いたSSE（優先度：中）

ベースライン：

サーバー側の暗号化に用いたデフォルトのAWS管理CMKにあるSQSキューを確認します。

説明：

サーバー側の暗号化を有効にする場合、AWSキー管理サービス（KMS）より提供されているキーを選択し、標準およびFIF0キューに保存されているメッセージを暗号化します。デフォルトのAWS管理顧客マスターキー（CMK）を用いるか、アクセス制御、変更、削除をより柔軟に行える自身のキーを作成し管理してください。

推奨：

自身の顧客マスターキー（CMK）を作成します。（メモ：顧客管理のCMKは月額料金がかかります。）

3. SQSキューアクセスポリシー：ワイルドカード使用率（優先度：高）

ベースライン：

SQSキューアクセスポリシーの主要要素内のワイルドカード（＊）使用率を確認します。

説明：

ポリシーの主要要素で、どのAWSアカウント、サービス、ユーザーがキューへのアクセス権を持つかを入力します。主要要素のワイルドカード（＊）バリューはキューが全てのAWSアカウントを開くことを意味します。SQSへのオープンアクセスは認証されていないメッセージの配信を引き起こす可能性があります。

推奨：

AWSアカウントIDに基づいたAmazonSQSアクセスを許可します。

4. SQS：デッドレターキューなし（優先度：中）

ベースライン：

設定したデッドレターキューのない標準またはFIF0キューを確認します。

説明：

デッドレターキューは顧客がメッセージの送信に失敗した際に送られる未配信のメッセージです。ユーザーはこの保留キューを使用して、問題のあるメッセージの切り分けてトラブルシューティングをし、失敗した原因を把握できます。

推奨：

デッドレターキューは既存のキューに設定することができません。新しくSQSキューを設定し、第2のキューとしてデッドレターキューを作成してください。

5. SQS：停止したキュー （優先度：中）

ベースライン：

SQS CloudWatchメトリクスを確認し、表示されたメッセージの概数が3回連続のポーリングで100を超えた場合に警告します。

説明：

Amazon SQSはホストキュー全体をを管理するサービスを提供していて、分配されたアプリケーションコンポーネントを連携させるのに役立ちます。"表示されたメッセージの概数"はアクティブなキューのサイズやバックログについての分析に利用できます。メトリクスが増加し続けている場合、それはキューのスタックや低下を表しています。

推奨：

ユーザーのEC2インスタンス、Lambda関数、ECSインスタンスの使用率を確認し、問題の特定とトラブルシューティングを行います。

1. Amazon SES：ステータス確認（優先度：情報)

ベースライン：

保留中の確認ステータスでメールアドレスやドメインの両方のAmazon SES情報を確認します。

説明：

Amazon SESでは、メールを送信に使用するメールアドレスやドメインを用います。開始前に、送信元、送信者、リターンパスアドレスといった各情報を入力する必要があります。Amazon SES sandboxを使用する場合は、受信者のアドレスも入力する必要があります。

推奨：

確認過程の問題を直ちに解決します。

2. Amazon SES - DKIM署名（優先度：情報)

ベースライン：

SES情報（ドメインとメールアドレス）の設定でDKIM署名が使用されていないことを確認します。

説明：

Domain Keys Identified Mail (DKIM)はメールの認証プロトコルで、送信者はメールメッセージの特定の表現に暗号で署名できます。受信メールサーバーはメッセージ転送の際に第三者から修正を受けていないかを確認するのにこの署名を使用します。

推奨：

Amazon SESの簡単なDKIMを使用して送信されたメール全てに自動的にDKIMが追加されるようにするか、手動で自身のDKIM署名を追加してください。

1. Amazon Kinesis Streams - AWS管理CMKを用いたSSE（優先度：高）

ベースライン：

AWS管理のCMKによってサーバー側の暗号化（SSE）が有効化されているAmazon Kinesis Data Streamsを確認します。

説明：

CMK （顧客マスターキー）はデータの暗号化や複合化に用いられる主要なリソースです。顧客管理のCMK、AWS管理のCMK、AWS自身のCMKの3タイプがあり、AWS管理のCMKを用いてAmazon Kinesis Streamsでデータの暗号化を行うか、あるいは自身の顧客管理のCMKを作成します。顧客管理のCMKはより制御しやすく柔軟に使用することができます。

推奨：

顧客管理のCMKを用いて、Kinesis Data Streamサービス内にあるデータを暗号化します。

2. Amazon Kinesis Streams：サーバー側の暗号化（SSE）（優先度：高）

ベースライン：

サーバー側の暗号化（SSE）が無効となっているAmazon Kinesis Data Streamsを確認します。

説明：

保管時の暗号化はデータ管理において重要な役割を果たし、アプリケーションが厳格なコンプライアンスや規制要件を満たすのに役立てられます。サーバー側の暗号化を有効にすることで、データの入力によって自動的に暗号化され、ストリームサービスを出ると複合化されます。

推奨：

Amazon Key Management（KMS）のキーを使用して、ライブストリームのサーバー側の暗号化を有効にします。

1. AWS WAF：割り当てられていないWeb ACL（優先度：高）

ベースライン：

WAFの設定を確認し、割り当てられていないWeb ACLを特定します。

説明：

AWS WAFの場合、CloudFrontディストリビューションやアプリケーションロードバランサーといったリソースに関連付けられているかに関係なく、Webアクセスコントロールリストの数やWeb ACLごとに追加されているルールの数に基づいて計測されます。

推奨：

使われていないWeb ACLを削除することを検討します。（メモ：削除の前に、ルールの削除し、ACLと全てのCloudFrontディストリビューションやアプリケーションロードバランサーとの関連付けをやめる必要があります。）

1. Amazon Redshift：十分に使用されていないクラスター（優先度：高）

ベースライン：

Amazon Redshiftのパフォーマンスカウンターを確認し、十分に活用されていないクラスターを特定してください。

説明：

稼働しているAmazon Redshiftクラスターのパフォーマンスカウンターを確認して、次の条件が適用されている場合はアイドルとマークされます。

• データベースの平均接続数が過去7日間で10より低い場合。
• クラスター全体のCPU使用率が過去7日間で5％より低い場合。
• クラスターにわたった読み込みと書き込み操作数の平均が過去7日間である値より低い場合。

メモ：デフォルトのアラート条件はアドバンス設定から変更できます。

推奨：

Amazon Redshiftの場合、クラスター内のノードの種類と数に基づいて時間料金が発生します。クラスターの接続数が少ない場合やCPIの消費量が少ない場合、サイズを低くしたり削除することを検討します。（メモ：クラスターをシャットダウンする前に最新のスナップショットを取得してください。）

2. Amazon Redshift clusters：高いディスク使用率（優先度：高）

ベースライン：

Amazon Redshiftのパフォーマンスカウンターを確認し、ディスク使用率の高いデータウェアハウスクラスターを特定します。

説明：

クラスターのディスク使用領域のパーセンテージを確認し、過去7日間のうちの少なくとの4日で90％より高い値を示した場合は警告します。

推奨：

AWSコンソールやModifyCluster API経由でデータウェアハウスクラスター内のノード数を増やし、十分なデータストレージを確保します。

3. Amazon Redshiftパブリックなアクセス（優先度：高）

ベースライン：

Amazon Redshiftのネットワーク設定を確認し、バブリックにアクセスできるデータウェアハウスクラスターを特定します。

説明：

パブリックにアクセスできるクラスター（パブリックIP）は、インターネットから全てのマシンでアクセスすることができ、セキュリティリスクを高めます。

推奨：

VPC内からのクラスター接続に限定して制限します。

4. Amazon Redshift：データベース監査ログ（優先度：中）

ベースライン：

データウェアハウスクラスターにおけるAmazon Redshiftの設定を確認して、データベース監査ログが無効になっている場合は警告します。

説明：

監査ログが有効化されている場合、認証属性、接続、未接続、ユーザーアクティビティー、DBユーザー定義の変更などといった詳細な情報を取得しS3バケットにアップロードします。

推奨：

セキュリティの監査ログを有効にし、目的の問題をトラブルシューティングします。

5. Amazon Redshift - SSLを用いた接続（優先度：中）

ベースライン：

Amazon Redshiftのパラメーターグループを確認し、要求SSLパラメーターがfalseと設定されているクラスターを特定します。

説明：

デフォルトでクラスターデータベースはSSLを使用するかどうかにかかわらず、クライアント接続が可能です。しかし、クライアント間で暗号化されていない接続が行われ、データウェアハウスクラスターにセキュリティの脆弱性を及ぼします。

推奨：

カスタムパラメーターグループを作成し、要求SSLパラメーターをtrueと設定してクラスターに関連付けます。

1. Lambda関数：パブリックなアクセス（優先度：高）

ベースライン：

AWS Lambdaの設定を確認し、関数にパブリックにアクセスできる場合は警告します。

説明：

Lambdaの場合、要求数に応じて課金が発生します。AWSはイベントの通知または呼び出しに応じて関数が実行されるたびに要求をカウントします。認証されていない実行を許可することはAWSの請求に対して予期しない課金を発生させるかもしれません。

推奨：

呼び出し許可を管理するためにLambda関数ポリシーを用います。

2. AWS Lambda；X-Rayトレースが無効（優先度：中）

ベースライン：

Lambda関数の設定を確認し、トレースが無効となっている場合には警告します。

説明：

CloudWatchはLambada関数の全ての実行に対してパフォーマンスカウンターを自動で提供します。しかし、これらのメトリクスではイベントソースからダウンストリームまでの各呼び出しの要求を全て表示するには不十分の可能性があります。

推奨：

Lambda関数のアクティブトレースを有効にします。

3. AWS Lambda関数のVPC設定（優先度：中）

ベースライン：

AWSリソースにプライベートアクセスができるよう、Lambda関数でVPC接続が有効になっているかを確認します。

説明：

Lamdaではデフォルトで、関数の実行をAWSサービスへのセキュアVPC接続やインターネットで行います。ただし、Lambda関数はカスタムVPCでリソースにアクセスするようにも設定可能です。カスタムVPCは、データベース、キャッシュインスタンス、内部サービスなどのリソースで、プライベートネットワークを定義します。これにより、インターネットにアクセスせずにVPC内でLambda関数に接続できます。この方法で、インターネットへの不正なアウトバウンドトラフィックをブロック可能です。AWSサービスには、VPCエンドポイントを低挙うしているものがあります。このVPCエンドポイントを使用して、インターネットにアクセスすることなくVPC内からAWSサービスに接続できます。

推奨：

Lambda関数でVPC設定を行い、AWSリソースにプライベートアクセスを実現してください。

4. Lambda関数の最近のランタイムの使用 (優先度：中)

ベースライン：

Lambda関数で使用されているランタイムが非推奨かどうかを確認します。

説明：

AWS Lambdaランタイム実行環境はLambda関数作成時に選択した設定に基づいてたてられるコンテナです。セキュリティアップデートでコンポーネントのサポートが無効となっている場合、ランタイムを非推奨としています。最近のランタイムを用いて新機能や機能強化を利用できることに加えて、セキュリティ、パフォーマンス、信頼性の向上も行えます。

推奨：

最近のランタイムを使用して、最良のセキュリティ強化を行い、Lambda関数のバグや脆弱性のリスクを削減します。

5. Lambda関数の最近のランタイムの使用 (優先度：中)

リソースレベルの説明：

Lambda関数をアップグレードして最近のランタイムの使用し、過去のランタイム環境を使用しないようにします。過去のものの仕様によりセキュリティアップデートの可用性低下を引き起こします。

ベースライン：

Lambda関数で使用しているランタイムが非推奨かどうかを確認します。

説明：

AWS Lambdaランタイム実行環境はLambda関数作成時に選択した設定に基づいてたてられるコンテナです。セキュリティアップデートでコンポーネントのサポートが無効となっている場合、ランタイムを非推奨としています。最近のランタイムを用いて新機能や機能強化を利用できることに加えて、セキュリティ、パフォーマンス、信頼性の向上も行えます。

推奨：

最近のランタイムを使用して、最良のセキュリティ強化を行い、Lambda関数のバグや脆弱性のリスクを削減します。

1. Amazon ElastiCache：十分に活用されていないノード（優先度：高）

ベースライン：

Amazon ElastiCacheのホストレベルでのメトリクスを確認し、十分に活用されていないように見えるノードを特定します。

説明：

次の条件に適用される場合はキャッシュノードは十分に活用されていないとみなされます。

• 過去7日間のうちの最低4日、1日のCPU使用率のパーセンテージが10％を下回った場合。
• 過去7日間のうちの最低4日、1日のエンジンCPU使用率のパーセンテージが10％を下回った場合。

推奨：

クラスターからノードを削除するか、より小さいノードタイプに変更します。

2. Amazon ElastiCache for Redis：複数のアベイラビリティゾーン（優先度：中）

ベースライン：

ElastiCache Redisの設定を確認し、複数のアベイラビリティゾーンが有効となっていないクラスターを特定します。

説明：

計画されたメンテナンス中、あるいはノードやアベイラビリティゾーンで障害が発生した場合には新しい主要ノードを手動で作成しなおす必要があります。その代わり複数のアベイラビリティゾーンを有効にし、ElastiCasheが自動的にリードレプリカをプライマリとして昇格させ、直ちにフェイルオーバーを完了できるようにします。

推奨：

ElastiCashe管理コンソールまたはAPIを使用して、自動フェイルオーバーで複数のアベイラビリティゾーンを有効化します。

3. あまり使用していないElastiCache Memcachedインスタンス (優先度：高)

リソースレベルの説明：

ElastiCache Memcacheインスタンスがあまり使用していないと表示されているかを確認します。

ベースライン：

Memcached cache環境のAmazon ElastiCacheのリソース使用率を確認して、CPU使用率が過去48時間で2%未満であった場合にあまり使用していないとみなされます。

推奨：

Amazon ElastiCacheの場合、インスタンスタイプと利用時間を基に請求が発生します。あまり使用していないインスタンスを特定し停止することでこの請求を削減できます。

4. ElastiCache Memcached - 高いインスタンス使用率 (優先度：高)

ベースライン：

Memcached ElastiCacheのパフォーマンスカウンターを確認し、使用率が高いインスタンスがあるかを確認します。

説明：

Memcached ElastiCacheはCPU使用率が過去7日間で日次平均して90%をを超えている場合に過剰に使用されているとみなされます。

推奨：

インスタンスサイズの変更を検討します。

5. あまり使用していないElastiCache Redisインスタンス (優先度：高)

リソースレベルの説明：

ElastiCache Redisインスタンスがあまり使用されていないかを確認します。

ベースライン：

Amazon ElastiCache Redisのリソース使用率を確認して、CPU使用率が過去48時間で2%未満であった場合にあまり使用していないとみなされます。

推奨：

Amazon ElastiCacheの場合、インスタンスタイプと利用時間を基に請求が発生します。あまり使用していないインスタンスを特定し停止することでこの請求を削減できます。

6. ElastiCache Redis - 高いインスタンス使用率 (優先度：高)

ベースライン：

Redis ElastiCacheのパフォーマンスカウンターを確認し、使用率が高いインスタンスがあるかを確認します。

説明：

Redis ElastiCacheはCPU使用率が過去7日間で日次平均して90%をを超えている場合に過剰に使用されているとみなされます。

推奨：

インスタンスサイズの変更を検討します。

1. Amazon CloudFront – WAF連携（優先度：中）

ベースライン：

Amazon CloudFront WebディストリビューションがWebアプリケーションファイアウォール（AWS WAF）と連携されているか確認します。

説明：

AWS Cloudfront—WAF連携によって、WAF Webアクセス制御リスト（ACL）で定義された基準に基づいて、Cloudfrontコンテンツ配信ネットワークに対して行われた悪意のあるリクエストをブロックできます。これは、Webアプリケーションのセキュリティが危険にさらされたり、不必要な負荷をかけたりする可能性のあるセキュリティ層の攻撃から保護します。

推奨：

WAF ACLを作成してそれをWebディストリビューションと関連付け、CloudFrontとAWS WAFを連携させてください。

必要な権限：

"cloudfront:ListDistributions"

2. Amazon CloudFront – アクセスログ（優先度：中）

ベースライン：

Amazon Cloudfrontディストリビューションのアクセスログ機能が有効になっているかを確認してください。

説明：

CloudfrontアクセスログはWebコンテンツのに対して行われた各要求について、要求されたオブジェクト名、アクセス日時、クライアントIP、アクセスポイント、エラーコードなどといった詳細な情報を保持しています。その他にもセキュリティ―監査に役立つ情報、解析やレポートツールのデータが含まれます。

推奨：

CloudFront CDN ディストリビューションのアクセスログを有効にします。

必要な権限：

"cloudfront:ListDistributions"、"cloudfront:GetDistribution"

3. Amazon CloudFront – 暗号化の適用（優先度：中）

ベースライン：

Amazon CloudFront CDNディストリビューションとそのユーザー間の通信がHTTPを使って暗号化されているかどうかを確認します。

説明：

Establishing communication with HTTPS (SSL encryption) for your CloudFront CDNディストリビューションのHTTPS（SSL暗号化）を用いた通信を行うことは、エッジ（キャッシュ）サーバー間の暗号化トラフィックを保証することができ、また、また、悪意のあるユーザーがCDN配信ネットワークを介して送信されたパケットを傍受できる場合、アプリケーションビューアーを解読することはできません。

推奨：

Configure CloudFrontディストリビューションプロトコルポリシーを設定し、転送暗号化でデータにHTTPを適用します。してください。

必要な権限：

"cloudfront:ListDistributions"

4. Amazon CloudFront – フィールドレベルの暗号化（優先度：中）

ベースライン：

フィールドレベルの暗号化がAmazon CloudFront Webディストリビューションで有効となっているかを確認します。

説明：

CloudFrontのフィールドレベルの暗号化によって、SSLの暗号化（HTTPS）とともにセキュリティ層を追加します。システム処理全体で特定の機密データを保護し、環境内の特定のアプリケーションのみがそのデータを表示できるようにします。

推奨：

Amazon CloudFront Webディストリビューションのフィールドレベルの暗号化を有効にします。

必要な権限：

"cloudfront:ListDistributions"

5. Amazon CloudFront – 安全でないSSLプロトコル（優先度：中）

ベースライン：

AWS CloudFrontディストリビューションの設定で、安全でないSSLプロトコルが使われていないことを確認します。

説明：

Cloudfrontディストリビューションに安全でなく非推奨のSSLプロトコルを使用すると、CloudFront CDNとオリジンサーバーの間の接続がPOODLE（ダウングレードされたレガシー暗号化のパディングOracle）などのエクスプロイトに対して脆弱性が発生します。TLSv1.0より新しいバージョンを用いるか（オリジンがサポートしている場合はTLSv1.2のみを使うことを推奨します）、SSLv3プロトコルを使うのを避けてください。

推奨：

CloudFrontディストリビューションオリジンから非推奨であるSSLv3プロトコルを削除してください。

必要な権限：

"cloudfront:ListDistributions"

6. Amazon CloudFront – 暗号化されていないトラフィック（優先度：中）

ベースライン：

AWS CloudFrontディストリビューションとそれらカスタムオリジン間の通信でHTTPSを用いた暗号化が行われているかを確認します。

説明：

AWS CloudfrontディストリビューションにHTTPSにより、エッジサーバー間の暗号化トラフィックを保証することができます。そして、悪意のあるユーザーがCDNを介して送られたパケットを取得できるような場合、カスタムオリジンは暗号を解除することができません。これはWebコンテンツの安全な配信に役立てられ、転送の暗号化におけるデータのコンプライアンス要件を満たすことができます。

推奨：

CloudFrontディストリビューションのエッジロケーションとそれらオリジン間のトラフィック暗号化のためにHTTPSを有効にしてください。

必要な権限：

"cloudfront:ListDistributions"

1. API Gateway - SSLクライアント証明書の有効化（優先度：中）

ベースライン：

Amazon API GatewayのAPIにSSL証明書が使われていて、バックエンドのシステムに行われたHTTP要求がAPI Gatewayサービスからのものであるということを確認します。

説明：

バックエンドサービスへのHTTP要求がAmazon API GatewayのAPIからのものであることを確認し、その要求の認証のためにクライアント側のSSL証明書を使用することを強く勧めています。

推奨：

SSL証明書を作成し、それをAmazon API GatewayのAPIに関連付けてください。

必要な権限：

"apigateway:RestApis"、"apigateway:GetStages"

2. API Gateway - APIのCloudWatchログ（優先度：中）

ベースライン：

AWS CloudWatchのログがAmazon API Gatewayで作成されたAPIに有効であるかどうか確認します。

説明：

Amazon CloudWatchログはステージレベルでのAPI実行についての記録情報を収集します。この情報はAPIに関するあらゆる問題のトラブルシューティングにきわめて役立てられます。

推奨：

Amazon API GatewayのAPIでAWS CloudWatchログを有効化します。.

必要な権限：

"apigateway:RestApis"、"apigateway:GetStages"

3. API Gateway：コンテンツエンコード（優先度：中）

ベースライン：

コンテンツエンコード機能がAmazon API GatewayのAPIで有効となっているか確認します。

説明：

Amazon API Gatewayでクライアントはサポートされている圧縮タイプのいずれかを使用して圧縮されたペイロードでAPIを呼び出すことができます。コンテンツエンコードが有効となると、API Gatewayサービスで、クライアントのアクセプトエンコーディングヘッダーに基づいて、応答本文の圧縮を行うことができます。APIペイロードの圧縮を有効化すると、APIパフォーマンスの向上や領域の使用率を削減することに役立てられます。

推奨：

コンテンツエンコード機能を用いて、Amazon API GatewayのAPIペイロード圧縮を有効にします。

必要な権限：

"apigateway:RestApis"

4. API Gateway - APIのCloudWatchメトリクス（優先度：中）

ベースライン：

詳細なCloudWatchメトリクスがAWS API Gatewayで作成された全てのAPIで有効になっているか確認します。

説明：

APIステージのAWS CloudWatchメトリクスを使用すると、より詳細なデータを取得することができるため、これらメトリクスのアラートを通じて受け取れる情報に基づいて、迅速に対応し即座にアクションを実行できます。

推奨：

Amazon API GatewayのAPIステージで、詳細なCloudWatchメトリクスを有効にします。

必要な権限：

"apigateway:RestApis"、"apigateway:GetStages"

1. AWS EFS：管理KMSキー（優先度：高)

ベースライン：

Amazon EFSファイルシステムがAWS管理キー（顧客キーが設定されていないときのEFSサービスによるデフォルトのキー）ではなくKMS顧客キーによって暗号化されているか確認します。

説明：

自身のKMS CMK顧客管理キーを設定し用いると、EFSファイルシステムのデータやメタデータを保護して、誰がこのキーを用いてデータ（システムメタデータも含む）にアクセスしているかといった情報を広く得ることができます。AWS KMSサービスでファイルシステムのCMK暗号化キーを作成、変更、無効化、監査することができ、保存データの暗号化または複合化プロセスをより詳細に制御できます。

推奨：

自身のAWS KMS CMK顧客管理キーを用いて既存のAWS EFSファイルシステムを暗号化してください。

必要な権限：

"elasticfilesystem:DescribeFileSystems"

2. AWS EFS：暗号化（優先度：高)

ベースライン：

Amazon EFSファイルシステムが暗号化されて保存データを保護しているかを確認します。

説明：

AWS KMSサービスで管理されている暗号化キーによって、安全なキー管理インフラストラクチャーの構築と維持が必要なくなります。暗号化はデータが書き込まれている間、複合化はファイルシステムから読み取られる間に起こるため、ユーザーやアプリケーションで何かアクションを起こす必要はありません。認証されていないアクセスからのデータやメタデータの保護や、組織内の保存データを暗号化でコンプライアンス要件を高めることができるため、EFSファイルシステムを暗号化することを強くお勧めします。

推奨：

AWS EFSファイルシステムの暗号化を有効にします。

必要な権限：

"elasticfilesystem:DescribeFileSystems"