# インフラストラクチャの保護
**Topics**
+ [
# SEC 5. ネットワークリソースはどのように保護するのですか。
](sec-05.md)
+ [
# SEC 6. コンピューティングリソースはどのように保護するのですか。
](sec-06.md)
# SEC 5. ネットワークリソースはどのように保護するのですか。
何らかの形式のネットワーク接続があるワークロードは、インターネットでもプライベートネットワークでも、外部および内部ネットワークベースの脅威から保護するために、複数の防御レイヤーが必要です。
**Topics**
+ [
# SEC05-BP01 ネットワークレイヤーを作成する
](sec_network_protection_create_layers.md)
+ [
# SEC05-BP02 ネットワークレイヤー内のトラフィックフローを制御する
](sec_network_protection_layered.md)
+ [
# SEC05-BP03 検査に基づく保護を実装する
](sec_network_protection_inspection.md)
+ [
# SEC05-BP04 ネットワーク保護を自動化する
](sec_network_auto_protect.md)
# SEC05-BP01 ネットワークレイヤーを作成する
ワークロードコンポーネントをそのデータの機密度とアクセス要件に応じて論理的にグループ化し、そのグループに基づいてネットワークトポロジをさまざまなレイヤーに分割します。インターネットからのインバウンドアクセスを必要とするコンポーネント (公開ウェブエンドポイントなど) と、内部アクセスのみを必要とするコンポーネント (データベースなど) は区別します。
**期待される成果:** ネットワークのレイヤーが多層防御のセキュリティ対策全体の一翼を担い、ワークロードのアイデンティティ認証や承認戦略を補完しています。データの機密度とアクセス要件に応じてレイヤーが配置され、トラフィックフローと統制のメカニズムが適切に機能しています。
**一般的なアンチパターン:**
+ 単一の VPC またはサブネットですべてのリソースを作成する。
+ データの機密度の要件、コンポーネントの動作、機能を考慮せずにネットワークレイヤーを構築する。
+ ネットワークレイヤーのすべての考慮事項について、デフォルトとして VPC とサブネットを使用し、AWS マネージドサービスがトポロジに与える影響を考慮していない。
**このベストプラクティスを活用するメリット:** ネットワークレイヤーを確立することは、ネットワーク内の不要な経路、特に重要なシステムやデータにつながる経路を制限するための第一歩です。これにより、権限のない攻撃者がネットワークにアクセスしたり、ネットワーク内の他のリソースを操作したりしづらくなります。ネットワークレイヤーが分離されていると、侵入検知やマルウェア防止などの検査システムの分析範囲が狭くなるという利点があります。そのおかげで、誤検出や不要な処理に伴うオーバーヘッドの発生確率が下がります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードのアーキテクチャを設計する場合、一般的には、コンポーネントをそれぞれの役割に応じて異なるレイヤーに分けます。例えば、ウェブアプリケーションは、プレゼンテーションレイヤー、アプリケーションレイヤー、データレイヤーで構成できます。ネットワークトポロジを設計する際も似たようなアプローチを採用できます。基盤にあるネットワーク統制が、ワークロードのデータアクセス要件を適用するのに役立つことがあります。例えば、3 層のウェブアプリケーションのアーキテクチャでは、プレゼンテーションレイヤーの静的ファイルを [Amazon S3](https://aws.amazon.com/s3/) に保存し、それらのファイルを [Amazon CloudFront](https://aws.amazon.com/cloudfront/) などのコンテンツ配信ネットワーク (CDN) から提供できます。アプリケーションレイヤーには、[Application Load Balancer (ALB)](https://aws.amazon.com/elasticloadbalancing/application-load-balancer/) が [Amazon VPC](https://aws.amazon.com/vpc/) のパブリックサブネット (非武装地帯 (DMZ) と類似) で提供するパブリックエンドポイントを設け、バックエンドのサービスをプライベートサブネットにデプロイできます。データレイヤーは、データベースや共有ファイルシステムなどのリソースをホストします。アプリケーションレイヤーのリソースとは異なるプライベートサブネットに配置できます。これらのレイヤー境界 (CDN、パブリックサブネット、プライベートサブネット) のそれぞれで統制を効かせて、承認されたトラフィックしかそれらの境界を超えられないようにすることができます。
ワークロードのコンポーネントの機能面の目的に基づいてネットワークレイヤーをモデル化するのと同様に、処理対象のデータの機密度も考慮してください。ウェブアプリケーションの例で考えてみると、ワークロードサービスはすべてアプリケーションレイヤー内にある一方で、それぞれのサービスが処理するデータの機密度は異なる場合があります。この場合、統制の要件によっては、複数のプライベートサブネット、同じ AWS アカウントの異なる VPC、または異なる AWS アカウントの異なる VPC を使用して、データの機密度ごとにアプリケーションレイヤーを分割した方が適切なこともあります。
ネットワークレイヤーについてさらに考慮すべき点は、ワークロードのコンポーネントの動作の一貫性です。引き続き同じ例で言えば、アプリケーションレイヤーにエンドユーザーや統合先の外部システムからの入力を受け入れるサービスがあり、その入力のリスクが他のサービスへの入力と比べて本質的に高いという場合が考えられます。例えば、ファイルのアップロード、実行するコードスクリプト、メールのスキャンなどが該当します。こうしたサービスを独自のネットワークレイヤーに配置すれば、より強固な分離境界を張り巡らせることができ、それらの固有の動作のせいで検査システムで誤検知アラートが発生するのを防止できます。
設計の過程で、AWS マネージドサービスを使用することで、ネットワークトポロジにどのような影響があるかを検討してください。[Amazon VPC Lattice](https://aws.amazon.com/vpc/lattice/) などのサービスが、ネットワークレイヤー間のワークロードコンポーネントの相互運用性の向上にいかに役立つかをご確認ください。[AWS Lambda](https://aws.amazon.com/lambda/) を使用する場合は、特に理由がない限り、VPC サブネットにデプロイしてください。インターネットゲートウェイへのアクセスを制限するセキュリティポリシーの遵守を VPC エンドポイントや [AWS PrivateLink](https://aws.amazon.com/privatelink/) で簡素化できるのはどこか、判断してください。
### 実装手順
1. ワークロードのアーキテクチャを見直します。コンポーネントやサービスを、それらが提供する機能、処理対象のデータの機密度、動作に基づいて論理的にグループ化します。
1. インターネットからのリクエストに応答するコンポーネントについては、ロードバランサーやその他のプロキシを使用してパブリックエンドポイントを設けることを検討します。CloudFront、[Amazon API Gateway](https://aws.amazon.com/api-gateway/)、Elastic Load Balancing、[AWS Amplify](https://aws.amazon.com/amplify/) などのマネージドサービスを利用してパブリックエンドポイントをホストすることで、セキュリティ統制を移行することを検討してください。
1. Amazon EC2 インスタンス、[AWS Fargate](https://aws.amazon.com/fargate/) コンテナ、Lambda 関数など、コンピューティング環境で実行されるコンポーネントの場合、手順 1 で決めたグループに基づいて、これらをプライベートサブネットにデプロイします。
1. [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、[Amazon Kinesis](https://aws.amazon.com/kinesis/)、[Amazon SQS](https://aws.amazon.com/sqs/) などのフルマネージド型の AWS サービスについては、プライベート IP アドレス経由のアクセスにはデフォルトで VPC エンドポイントを使用することを検討します。
## リソース
**関連するベストプラクティス:**
+ [REL02 ネットワークトポロジを計画する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)
+ [PERF04-BP01 ネットワークがパフォーマンスに与える影響を理解する](https://docs.aws.amazon.com/wellarchitected/latest/framework/perf_networking_understand_how_networking_impacts_performance.html)
**関連動画:**
+ [AWS re:Invent 2023 - AWS networking foundations](https://www.youtube.com/watch?v=8nNurTFy-h4)
**関連する例:**
+ [VPC の例](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-examples-intro.html)
+ [Access container applications privately on Amazon ECS by using AWS Fargate, AWS PrivateLink, and a Network Load Balancer](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/access-container-applications-privately-on-amazon-ecs-by-using-aws-fargate-aws-privatelink-and-a-network-load-balancer.html)
+ [Serve static content in an Amazon S3 bucket through a VPC by using Amazon CloudFront](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/serve-static-content-in-an-amazon-s3-bucket-through-a-vpc-by-using-amazon-cloudfront.html)
# SEC05-BP02 ネットワークレイヤー内のトラフィックフローを制御する
ネットワークのレイヤー内でさらにセグメンテーションを行い、各ワークロードに必要なフローのみにトラフィックを制限します。まず、インターネットや他の外部システムからワークロードや環境へのトラフィック (North-South トラフィック) の制御に着目します。その後、さまざまなコンポーネントとシステム間のフロー (East-West トラフィック) を確認します。
**期待される成果:** ワークロードのコンポーネントが相互通信や、クライアントや依存先のその他のサービスとの通信に必要とするネットワークフローのみを許可します。設計では、パブリックとプライベートの送受信、データ分類、地域の規制、プロトコル要件などが考慮されます。可能な限り、最小特権の原則に基づく設計の一環として、ネットワークピアリングよりもポイントツーポイントフローを優先します。
**一般的なアンチパターン:**
+ ネットワークセキュリティに境界ベースのアプローチを採用し、ネットワークレイヤーの境界でのみトラフィックフローを制御する。
+ ネットワークレイヤー内のすべてのトラフィックが認証済み、承認済みだと仮定している。
+ 受信トラフィックと送信トラフィックのいずれかに制御を適用し、両方には適用していない。
+ トラフィックの認証と承認をワークロードコンポーネントとネットワーク統制のみに頼っている。
**このベストプラクティスを活用するメリット:** このプラクティスを実践することで、ネットワーク内の不正な移動のリスクを軽減し、ワークロードに承認のレイヤーを追加できます。トラフィックフロー制御を行うことで、セキュリティインシデントによる影響の範囲を制限し、検出と対応をスピードアップできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ネットワークレイヤーによって、機能、データの機密レベル、動作が似ているワークロードのコンポーネント群の周りに境界を確立できますが、最小特権の原則に従ってこれらのレイヤー内のコンポーネントをさらにセグメント化する手法を用いて、よりきめ細かくトラフィックを制御できます。AWS 内では、ネットワークレイヤーは主に、Amazon VPC 内の IP アドレス範囲に応じたサブネットを使用して定義されます。また、マイクロサービス環境をビジネスドメインごとにグループ化するなど、さまざまな VPC を使用してレイヤーを定義することもできます。複数の VPC を使用する場合は、[AWS Transit Gateway](https://aws.amazon.com/transit-gateway/) を使用してルーティングを行います。この場合、セキュリティグループとルートテーブルを使用してレイヤー 4 レベル (IP アドレスとポートの範囲) でトラフィックを制御できますが、[AWS PrivateLink](https://aws.amazon.com/privatelink/)、[Amazon Route 53 Resolver DNS Firewall](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html)、[AWS Network Firewall](https://aws.amazon.com/network-firewall/)、[AWS WAF](https://aws.amazon.com/waf/) などの追加サービスを使用して制御を強化することもできます。
ワークロードのデータフローと通信の要件を接続の開始側、ポート、プロトコル、ネットワークレイヤーの観点から把握し、インベントリを作成します。接続の確立とデータ転送に使用できるプロトコルを評価して、保護要件を満たすプロトコル (例えば、HTTP ではなく HTTPS) を選択します。ネットワークの境界と各レイヤー内の両方で、これらの要件を把握してください。これらの要件を特定できたら、オプションを検討し、必要なトラフィックのみが各接続ポイントを流れるようにします。まず、VPC 内でセキュリティグループを使用することをお勧めします。セキュリティグループは、Amazon EC2 インスタンス、Amazon ECS タスク、Amazon EKS ポッド、Amazon RDS データベースなど、Elastic Network Interface (ENI) を使用するリソースにアタッチできます。レイヤー 4 のファイアウォールとは異なり、セキュリティグループには別のセキュリティグループからのトラフィックを識別子ごとに許可するルールを設定できるため、グループ内のリソースが時間の経過とともに変化しても更新を最小限に抑えることができます。セキュリティグループを使用し、インバウンドルールとアウトバウンドルールの両方を用いて、トラフィックをフィルタリングすることもできます。
トラフィックが VPC 間を移動する場合、シンプルルーティングには VPC ピアリングを使用し、複雑なルーティングには AWS Transit Gateway を使用するのが一般的です。これらのアプローチにより、送信元ネットワークと宛先ネットワークの両方の IP アドレス範囲間のトラフィックフローが円滑になります。ただし、異なる VPC にある特定のコンポーネント間のトラフィックフローのみをワークロードが必要とする場合は、[AWS PrivateLink](https://aws.amazon.com/privatelink/) を使用してポイントツーポイント接続を確立することを検討してください。その場合は、プロデューサーとして機能するサービスと、コンシューマーとして機能するサービスを特定します。プロデューサーには互換性のあるロードバランサーをデプロイし、PrivateLink を適宜有効にしてから、コンシューマーからの接続リクエストを受け入れます。その後、プロデューサーサービスには、コンシューマーの VPC からプライベート IP アドレスが割り当てられます。コンシューマーはこれを使用して以降のリクエストを行うことができます。この方法だと、ネットワークのピアリングはほとんど必要なくなります。PrivateLink の評価の中で、データ処理と負荷分散のコストも考慮してください。
セキュリティグループや PrivateLink は、ワークロードのコンポーネント間のフロー制御に役立ちますが、もう 1 つの重要な考慮事項は、リソースがアクセスできる DNS ドメイン (存在する場合) を制御する方法です。VPC の DHCP 構成に応じて、この目的で 2 つの異なる AWS サービスを検討できます。大半のお客様は、VPC で CIDR 範囲 \$12 のアドレスを利用できるデフォルトの Route 53 Resolver DNS サービス (別称 Amazon DNS サーバーまたは AmazonProvidedDNS) を使用します。この方法では、DNS ファイアウォールルールを作成して VPC に関連付け、指定したドメインリストに対して実行するアクションを決定できます。
Route 53 Resolver を使用していない場合や、ドメインフィルタリング以外の詳細な検査やフロー制御の機能で Resolver を補完したい場合は、AWS Network Firewall の デプロイを検討してください。このサービスは、ステートレスルールまたはステートフルルールを使用して個々のパケットを検査し、トラフィックを拒否するか許可するかを決定します。AWS WAF を使用してパブリックエンドポイントへのインバウンドウェブトラフィックをフィルタリングする場合も、同様のアプローチを採用できます。これらのサービスの詳細については、「[SEC05-BP03 検査に基づく保護を実装する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html)」を参照してください。
### 実装手順
1. ワークロードのコンポーネント間で必要なデータフローを特定します。
1. セキュリティグループやルートテーブルの使用など、インバウンドトラフィックとアウトバウンドトラフィックの両方に、多層防御のアプローチで複数の統制を適用します。
1. Route 53 Resolver DNS Firewall、AWS Network Firewall、AWS WAF など、ファイアウォールを使用して、VPC に出入りするネットワークトラフィックに対する制御をきめ細かく定義します。組織全体でファイアウォールルールを一元的に設定および管理するには、[AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) の使用を検討してください。
## リソース
**関連するベストプラクティス:**
+ [REL03-BP01 ワークロードをセグメント化する方法を選択する](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_service_architecture_monolith_soa_microservice.html)
+ [SEC09-BP02 伝送中に暗号化を適用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_data_transit_encrypt.html)
**関連ドキュメント:**
+ [VPC のセキュリティのベストプラクティス](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html)
+ [AWS Network Optimization Tips](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [Guidance for Network Security on AWS](https://aws.amazon.com/solutions/guidance/network-security-on-aws/)
+ [Secure your VPC's outbound network traffic in the AWS クラウド](https://docs.aws.amazon.com/prescriptive-guidance/latest/secure-outbound-network-traffic/welcome.html)
**関連ツール**:
+ [AWS Firewall Manager](https://aws.amazon.com/firewall-manager/)
**関連動画:**
+ [AWS Transit Gateway reference architectures for many VPCs](https://youtu.be/9Nikqn_02Oc)
+ [Application Acceleration and Protection with Amazon CloudFront, AWS WAF, and AWS Shield](https://youtu.be/0xlwLEccRe0)
+ [AWS re:Inforce 2023: Firewalls and where to put them](https://www.youtube.com/watch?v=lTJxWAiQrHM)
# SEC05-BP03 検査に基づく保護を実装する
ネットワークレイヤー間にトラフィックの検査ポイントを設定して、転送中のデータが、予想されるカテゴリやパターンと一致していることを確認します。 トラフィックフロー、メタデータ、パターンを分析して、イベントの識別、検出、対応をより効果的に行えるようにします。
**期待される成果:** ネットワークレイヤー間を通過するトラフィックが検査され、承認されます。 許可と拒否の決定は、明示的なルールや脅威インテリジェンス、ベースラインの動作から逸脱しているかどうかに基づいて行われます。 トラフィックが機密データに近づくにつれて、保護は厳格化されます。
**一般的なアンチパターン:**
+ ポートとプロトコルに基づくファイアウォールルールのみに依存している。インテリジェントシステムを利用していない。
+ 特定の最新の脅威パターンに基づいてファイアウォールルールを作成しているが、このパターンは変更される可能性がある。
+ トラフィックがプライベートサブネットからパブリックサブネットに、またはパブリックサブネットからインターネットに転送される箇所のみを検査している。
+ 動作の異常の比較基準となるネットワークトラフィックのベースラインビューがない。
**このベストプラクティスを活用するメリット:** 検査システムでは、トラフィックデータが特定の条件に該当する場合にのみトラフィックを許可または拒否するなど、インテリジェントなルールを作成できます。脅威の状況は時間とともに変化するので、AWS やパートナーが最新の脅威インテリジェンスに基づいて提供するマネージドルールセットが役立ちます。 これにより、ルールの維持や侵害の兆候の調査にかかるオーバーヘッドが減り、誤検出率が下がります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS Network Firewall や、[Gateway Load Balancer (GWLB)](https://aws.amazon.com/elasticloadbalancing/gateway-load-balancer/) の背後にデプロイできる AWS Marketplace の他の[ファイアウォール](https://aws.amazon.com/marketplace/search/results?searchTerms=firewalls)および[侵入防止システム](https://aws.amazon.com/marketplace/search/results?searchTerms=Intrusion+Prevention+Systems) (IPS) を使用して、ステートフルネットワークトラフィックとステートレスネットワークトラフィックの両方をきめ細かく制御します。AWS Network Firewall は、[Suricata 互換](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-ips.html)のオープンソースの IPS 仕様に対応し、ワークロードの保護に役立ちます。
AWS Network Firewall と、GWLB を使用するベンダーソリューションはどちらも、さまざまなインライン検査デプロイモデルをサポートしています。 例えば、VPC 単位で検査を実行することや、検査用 VPC に一元化することができます。また、ハイブリッドモデルでデプロイし、East-West トラフィックは検査用 VPC に流し、インターネットの受信トラフィックは VPC 単位で検査することもできます。 もう 1 つ考慮すべき点は、そのソリューションが Transport Layer Security (TLS) のラップ解除に対応しているかどうかです。これにより、どちらの方向から開始されたトラフィックフローでもディープパケット検査が可能になります。これらの構成の詳細については、[AWS Network Firewall のベストプラクティスガイド](https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/)を参照してください。
プロミスキャスモードで動作しているネットワークインターフェイスからのパケットデータの pcap 分析など、アウトオブバンド検査を実行するソリューションを使用している場合は、[VPC トラフィックミラーリング](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)を設定できます。ミラーリングされたトラフィックは、インターフェイスで使用可能な帯域幅にカウントされ、ミラーリングされていないトラフィックと同じデータ転送料金が課されます。これらのアプライアンスの仮想バージョンが [AWS Marketplace](https://aws.amazon.com/marketplace/solutions/infrastructure-software/cloud-networking) で提供されているかどうかを確認できます。GWLB の背後のインラインデプロイに対応している場合があります。
HTTP ベースのプロトコルを介してトランザクションを行うコンポーネントの場合は、ウェブアプリケーションファイアウォール (WAF) で一般的な脅威からアプリケーションを保護します。[AWS WAF](https://aws.amazon.com/waf) は、HTTP(S) リクエストを監視し、設定可能なルールに一致するものを Amazon API Gateway、Amazon CloudFront、AWS AppSync、または Application Load Balancer に送信する前にブロックできるウェブアプリケーションファイアウォールです。ウェブアプリケーションファイアウォールのデプロイを評価するときは、ディープパケット検査を検討してください。一部、トラフィック検査の前に TLS を終了しなければならないものがあるためです。AWS WAF の使用を開始するには、[AWS マネージドルール](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html#getting-started-wizard-add-rule-group)を独自のルールと組み合わせて使用するか、既存の[パートナー統合](https://aws.amazon.com/waf/partners/)を使用できます。
[AWS Firewall Manager](https://aws.amazon.com/firewall-manager/) を使用して、AWS Organization 全体で AWS WAF、AWS Shield Advanced、AWS Network Firewall、Amazon VPC セキュリティグループを一元管理できます。
## 実装手順
1. 検査ルールの範囲を広く設定できるか (検査用 VPC を使用するなど)、または VPC 単位のよりきめ細かいアプローチが必要かどうかを判断します。
1. インライン検査ソリューションの場合:
1. AWS Network Firewall を使用する場合は、ルール、ファイアウォールポリシー、ファイアウォール自体を作成します。これらを設定したら、[トラフィックをファイアウォールエンドポイントにルーティング](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)して検査を有効にすることができます。
1. Gateway Load Balancer (GWLB) とサードパーティー製アプライアンスを使用する場合は、アプライアンスを 1 つ以上のアベイラビリティーゾーンにデプロイして構成します。次に、GWLB、エンドポイントサービス、エンドポイントを作成し、トラフィックのルーティングを設定します。
1. アウトオブバンド検査ソリューションの場合:
1. インバウンドトラフィックとアウトバウンドトラフィックをミラーリングする必要があるインターフェイスで VPC トラフィックミラーリングを有効にします。Amazon EventBridge ルールを使用して、新しいリソースが作成されたときに AWS Lambda 関数を呼び出してインターフェイスでトラフィックミラーリングを有効にすることができます。トラフィックミラーリングセッションを、トラフィックを処理するアプライアンスの前にある Network Load Balancer に送ります。
1. インバウンドのウェブトラフィックソリューションの場合:
1. AWS WAF を設定するには、まずウェブアクセスコントロールリスト (ウェブ ACL) を設定します。ウェブ ACL は、WAF がトラフィックを処理する方法を定義する、逐次処理されるデフォルトアクション (ALLOW または DENY) を指定したルールのコレクションです。独自のルールとグループを作成することも、ウェブ ACL で AWS マネージドルールグループを使用することもできます。
1. ウェブ ACL を設定したら、ウェブ ACL を AWS リソース (Application Load Balancer、API Gateway REST API、CloudFront ディストリビューションなど) に関連付けて、ウェブトラフィックの保護を開始します。
## リソース
**関連ドキュメント:**
+ [What is Traffic Mirroring?](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)
+ [Implementing inline traffic inspection using third-party security appliances](https://docs.aws.amazon.com/prescriptive-guidance/latest/inline-traffic-inspection-third-party-appliances/welcome.html)
+ [AWS Network Firewall example architectures with routing](https://docs.aws.amazon.com/network-firewall/latest/developerguide/architectures.html)
+ [Centralized inspection architecture with AWS Gateway Load Balancer and AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/)
**関連する例:**
+ [ゲートウェイロードバランサーをデプロイするためのベストプラクティス](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/)
+ [TLS inspection configuration for encrypted egress traffic and AWS Network Firewall](https://aws.amazon.com/blogs/security/tls-inspection-configuration-for-encrypted-egress-traffic-and-aws-network-firewall/)
**関連ツール**:
+ [AWS Marketplace IDS/IPS](https://aws.amazon.com/marketplace/search/results?prevFilters=%257B%2522id%2522%3A%25220ed48363-5064-4d47-b41b-a53f7c937314%2522%257D&searchTerms=ids%2Fips)
# SEC05-BP04 ネットワーク保護を自動化する
Infrastructure as Code (IaC) や CI/CD パイプラインなどの DevOps のプラクティスを活用して、ネットワーク保護のデプロイを自動化します。 これらのプラクティスに則って、ネットワーク保護の変更をバージョン管理システムを通じて追跡し、変更のデプロイにかかる時間を短縮できます。また、ネットワーク保護が目的の設定から逸脱していないかどうかを検知できます。
**期待される成果:** ネットワーク保護をテンプレートに定義して、バージョン管理システムにコミットします。 新しい変更が加えられると、自動パイプラインが開始して、そのテストとデプロイを調整します。 変更をデプロイ前に検証するための、ポリシーチェックやその他の静的テストが整備されています。 変更をステージング環境にデプロイして、統制が予期したとおりに機能していることを検証します。 統制が承認されると、本番環境へのデプロイも自動的に実行されます。
**一般的なアンチパターン:**
+ 個々のワークロードチームに、ネットワークスタック、保護、自動化の完全な定義を任せている。 ネットワークスタックと保護の標準的な側面が、ワークロードチームが利用できるように中央で公開されていない。
+ ネットワーク、保護、自動化のあらゆる側面の定義を中央のネットワークチームに一任している。 ネットワークスタックと保護のワークロード固有の側面を、そのワークロードのチームに委任していない。
+ ネットワークチームとワークロードチームの間で一元管理と委任の適切なバランスを取っているが、一貫したテストとデプロイの標準がすべての IaC テンプレートと CI/CD パイプラインにわたっては適用されていない。 テンプレートの準拠状況をチェックするために必要な設定が、ツールに取り込まれていない。
**このベストプラクティスを活用するメリット:** テンプレートにネットワーク保護を定義しておくと、経時的な変更をバージョン管理システムで追跡し、比較できます。 変更のテストとデプロイを自動化することで、プロセスが標準化されて予測可能性が高まり、デプロイの成功率が上がり、繰り返しの手動設定を省くことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
「[SEC05-BP02 ネットワークレイヤー内のトラフィックフローを制御する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_layered.html)」や「[SEC05-BP03 検査に基づく保護を実装する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_inspection.html)」で説明されている多くのネットワーク保護統制では、最新の脅威インテリジェンスを反映して自動更新できるマネージドルールシステムを採用します。 ウェブエンドポイントを保護する例としては、[AWS WAF マネージドルール](https://docs.aws.amazon.com/waf/latest/developerguide/aws-managed-rule-groups.html)や [AWS Shield Advanced アプリケーションレイヤー DDoS の自動緩和](https://docs.aws.amazon.com/waf/latest/developerguide/ddos-automatic-app-layer-response.html)などがあります。[AWS Network Firewall マネージドルールグループ](https://docs.aws.amazon.com/network-firewall/latest/developerguide/nwfw-managed-rule-groups.html)を使用すれば、レピュテーションの低いドメインリストや脅威シグネチャの最新情報が随時反映されます。
マネージドルール以外にも、DevOps のプラクティスを使用して、指定したネットワークリソース、保護、ルールのデプロイを自動化することをお勧めします。 これらを [AWS CloudFormation](https://aws.amazon.com/cloudformation/) や任意の Infrastructure as Code (IaC) ツールに定義してバージョン管理システムにコミットし、CI/CD パイプラインを使用してデプロイできます。 この方法なら、リリースの予測可能性の向上、[AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) などのツールを使用した自動テスト、デプロイした環境が目的の構成とずれている場合の検知など、ネットワーク統制管理に関する DevOps の従来のメリットが得られます。
「[SEC05-BP01 ネットワークレイヤーを作成する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_network_protection_create_layers.html)」の過程で行った決断に伴い、一元管理のアプローチで受信フロー、送信フロー、検査フロー専用の VPC を作成する場合があります。 「[AWS Security Reference Architecture (AWS SRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture)」で説明されているとおり、これらの VPC は専用の[ネットワークインフラストラクチャアカウント](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)で定義できます。 同様の手法を用いて、他のアカウントのワークロード、そのセキュリティグループ、AWS Network Firewall デプロイ、Route 53 Resolver ルールと DNS ファイアウォール構成、その他のネットワークリソースが使用する VPC を一元的に定義できます。 これらのリソースは、[AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) を使用して他のアカウントと共有できます。 このアプローチなら、管理先が 1 つになり、ネットワーク統制の自動テストとネットワークアカウントへの自動デプロイを簡素化できます。 これは、ハイブリッドモデルで実現できます。つまり、特定の統制を一元的にデプロイして共有し、他の統制を個々のワークロードチームとそれぞれ該当するアカウントに委任します。
## 実装手順
1. ネットワークと保護のどの側面を一元的に定義し、どの側面をワークロードチームで管理できるのか、所有権を明確にします。
1. ネットワークとその保護に対する変更をテストし、デプロイする環境を作成します。 例えば、ネットワークテストアカウントとネットワーク本稼働アカウントを用意します。
1. テンプレートをバージョン管理システムに保存し、管理する方法を決定します。 中央テンプレートはワークロードリポジトリとは別のリポジトリに保存し、ワークロードテンプレートはそのワークロード固有のリポジトリに保存できます。
1. テンプレートをテストしてデプロイするための CI/CD パイプラインを作成します。 設定ミスがないかチェックし、テンプレートが会社の標準に準拠していることを確認するテストを定義します。
## リソース
**関連するベストプラクティス:**
+ [SEC01-BP06 標準的なセキュリティ統制のデプロイを自動化する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls)
**関連ドキュメント:**
+ [AWS セキュリティリファレンスアーキテクチャ - Network account](https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/network.html)
**関連する例:**
+ [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/)
+ [NetDevSecOps to modernize AWS networking deployments](https://aws.amazon.com/blogs/networking-and-content-delivery/netdevsecops-to-modernize-aws-networking-deployments/)
+ [Integrating AWS CloudFormation security tests with AWS Security Hub CSPM and AWS CodeBuild reports](https://aws.amazon.com/blogs/security/integrating-aws-cloudformation-security-tests-with-aws-security-hub-and-aws-codebuild-reports/)
**関連ツール**:
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)
+ [cfn\$1nag](https://github.com/stelligent/cfn_nag)
# SEC 6. コンピューティングリソースはどのように保護するのですか。
ワークロード内のコンピューティングリソースは、外部や内部のネットワークベースの脅威から保護するための複数の防御層を必要とします。コンピューティングリソースには、EC2 インスタンス、コンテナ、AWS Lambda 関数、データベースサービス、IoT デバイスなどがあります。
**Topics**
+ [
# SEC06-BP01 脆弱性管理を実行する
](sec_protect_compute_vulnerability_management.md)
+ [
# SEC06-BP02 強化されたイメージからコンピューティングをプロビジョニングする
](sec_protect_compute_hardened_images.md)
+ [
# SEC06-BP03 手動管理とインタラクティブアクセスを削減する
](sec_protect_compute_reduce_manual_management.md)
+ [
# SEC06-BP04 ソフトウェアの整合性を検証する
](sec_protect_compute_validate_software_integrity.md)
+ [
# SEC06-BP05 コンピューティング保護を自動化する
](sec_protect_compute_auto_protection.md)
# SEC06-BP01 脆弱性管理を実行する
コード、依存関係、インフラストラクチャ内の脆弱性のスキャンとパッチ適用を頻繁に実施し、新しい脅威から保護します。
**期待される成果:** ソフトウェアの脆弱性、潜在的な欠陥、意図しないネットワークへの露出がないかワークロードを継続的にスキャンするソリューションがあります。リスク評価基準に基づいて、これらの脆弱性を特定、優先順位付け、および修正するためのプロセスと手順を確立しました。さらに、コンピューティングインスタンスに自動パッチ管理を実装しました。脆弱性管理プログラムは、CI/CD パイプライン中にソースコードをスキャンするソリューションを使用して、ソフトウェア開発ライフサイクルに統合されています。
**一般的なアンチパターン:**
+ 脆弱性管理プログラムがない。
+ 重大度またはリスク回避を考慮せずに、システムパッチ適用を実施する。
+ ベンダーが提供する耐用年数 (EOL) を過ぎたソフトウェアを使用する。
+ セキュリティの問題を分析する前に、本番環境にコードをデプロイする。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
脆弱性管理は、安全で堅牢なクラウド環境を維持するうえで重要な要素です。これには、セキュリティスキャン、問題の特定と優先順位付け、特定された脆弱性を解決するためのパッチの適用など、包括的なプロセスが含まれます。このプロセスでは、潜在的な問題や意図しないネットワークへの露出、および修復作業に対するワークロードの継続的なスキャンを容易にするため、自動化はこのプロセスで重要な役割を果たします。
[AWS 責任共有モデル](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/shared-responsibility.html)は、脆弱性管理を支える基本的な概念です。このモデルによると、AWS は、AWS のサービスを実行するハードウェア、ソフトウェア、ネットワーク、施設など、基盤となるインフラストラクチャを保護する責任があります。一方で、ユーザーは Amazon EC2 インスタンスや Amazon S3 オブジェクトなどのサービスに関連するデータ、セキュリティ設定、管理タスクを保護する責任があります。
AWS は、脆弱性管理プログラムをサポートするさまざまなサービスを提供します。[Amazon Inspector](https://aws.amazon.com/inspector/) は、ソフトウェアの脆弱性や意図しないネットワークアクセスがないか、AWS ワークロードを継続的にスキャンし、[AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html) は Amazon EC2 インスタンス間のパッチ適用の管理に役立ちます。これらのサービスは、AWS セキュリティチェックの自動化、セキュリティアラートの一元化、組織のセキュリティ体制の包括的なビューを提供するクラウドセキュリティ体制管理サービスである [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) と統合できます。さらに、[Amazon CodeGuru Security](https://aws.amazon.com/codeguru/) は静的コード分析を使用して、開発フェーズ中の Java および Python アプリケーションの潜在的な問題を特定します。
ソフトウェア開発ライフサイクルに脆弱性管理プラクティスを組み込むことにより、本番環境に導入される前に、脆弱性をプロアクティブに解決できるため、セキュリティイベントのリスクが軽減され、脆弱性の潜在的な影響を最小限に抑えることができます。
### 実装手順
1. **責任共有モデルを理解する:** AWS 責任共有モデルを確認して、クラウド内のワークロードとデータを保護する責任を理解します。AWS は基盤となるクラウドインフラストラクチャを保護する責任があり、ユーザーは使用するアプリケーション、データ、サービスを保護する責任があります。
1. **脆弱性スキャンの実装**: Amazon Inspector などの脆弱性スキャンサービスを設定すると、ソフトウェアの脆弱性、潜在的な欠陥、意図しないネットワークへの流出がないか、コンピューティングインスタンス (仮想マシン、コンテナ、サーバーレス関数など) を自動的にスキャンします。
1. **脆弱性管理プロセスを確立する:** 脆弱性の特定、優先順位付け、修正のためのプロセスと手順を定義します。これには、定期的な脆弱性スキャンスケジュールの設定、リスク評価基準の確立、脆弱性の重大度に基づく修復スケジュールの定義などが含まれます。
1. **パッチ管理の設定:** パッチ管理サービスを使用して、オペレーティングシステムとアプリケーションの両方でコンピューティングインスタンスへのパッチ適用プロセスを自動化します。サービスを設定して、パッチが適用されていないインスタンスをスキャンし、スケジュールに従って自動的にインストールできます。この機能を導入するため、AWS Systems Manager Patch Manager を検討してください。
1. **マルウェア保護の設定:** 環境内の悪意のあるソフトウェアを検出するメカニズムを実装します。例えば、[Amazon GuardDuty](https://aws.amazon.com/guardduty/) などのツールを使用して、EC2 ボリュームや EBS ボリューム内のマルウェアを分析、検出、アラートを行うことができます。また、GuardDuty は、Amazon S3 に新たにアップロードされたオブジェクトをスキャンし、潜在的なマルウェアやウイルスを検出できます。また、それらがダウンストリームプロセスに取り込まれる前に分離するアクションを実行できます。
1. **CI/CD パイプラインに脆弱性スキャンを統合する:** アプリケーションのデプロイに CI/CD パイプラインを使用している場合は、脆弱性スキャンツールをパイプラインに統合します。Amazon CodeGuru Security やオープンソースオプションなどのツールは、ソースコード、依存関係、アーティファクトをスキャンして、潜在的なセキュリティ上の問題を検出できます。
1. **セキュリティモニタリングサービスの設定:** AWS Security Hub CSPM などのセキュリティモニタリングサービスを設定して、複数のクラウドサービスのセキュリティ体制を包括的に把握します。このサービスは、さまざまなソースからセキュリティ検出結果を収集し、優先順位付けや修復を容易にするために標準化された形式で提示する必要があります。
1. **ウェブアプリケーションのペネトレーションテストの実装**: アプリケーションがウェブアプリケーションであり、組織に必要なスキルがあるか、外部からの支援を利用できる場合は、ウェブアプリケーションのペネトレーションテストの実装を検討して、アプリケーションの潜在的な脆弱性を特定してください。
1. **Infrastructure as Code で自動化する**: [AWS CloudFormation](https://aws.amazon.com/cloudformation/) などの Infrastructure as Code (IaC) ツールを使用して、前述のセキュリティサービスを含むリソースのデプロイと設定を自動化します。この手法は、複数のアカウントや環境にわたって、より一貫性があり標準化されたリソースアーキテクチャを作成するのに役立ちます。
1. **モニタリングと継続的な改善**: 脆弱性管理プログラムの有効性を継続的にモニタリングし、必要に応じて改善してください。セキュリティの検出結果を検討し、是正措置の有効性を評価し、それに応じてプロセスとツールを調整します。
## リソース
**関連ドキュメント:**
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Lambda のセキュリティの概要](https://pages.awscloud.com/rs/112-TZM-766/images/Overview-AWS-Lambda-Security.pdf)
+ [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Improved, Automated Vulnerability Management for Cloud Workloads with a New Amazon Inspector ](https://aws.amazon.com/blogs/aws/improved-automated-vulnerability-management-for-cloud-workloads-with-a-new-amazon-inspector/)
+ [ Automate vulnerability management and remediation in AWS using Amazon Inspector and AWS Systems Manager – Part 1 ](https://aws.amazon.com/blogs/mt/automate-vulnerability-management-and-remediation-in-aws-using-amazon-inspector-and-aws-systems-manager-part-1/)
**関連動画:**
+ [サーバーレスおよびコンテナサービスを保護する](https://youtu.be/kmSdyN9qiXY)
+ [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI)
# SEC06-BP02 強化されたイメージからコンピューティングをプロビジョニングする
強化されたイメージからランタイム環境をデプロイすることで、ランタイム環境への意図しないアクセスの機会を減らします。コンテナイメージやアプリケーションライブラリなどのランタイム依存関係は、信頼できるレジストリからのみ取得し、その署名を検証します。独自のプライベートレジストリを作成して、ビルドおよびデプロイのプロセスで使用する、信頼できるイメージとライブラリを保存します。
**期待される成果:** コンピューティングリソースは、強化されたベースラインイメージからプロビジョニングされます。コンテナイメージやアプリケーションライブラリなどの外部依存関係は、信頼できるレジストリからのみ取得し、その署名を検証します。これらはプライベートレジストリに保存され、ビルドおよびデプロイのプロセスで参照できます。新たに発見された脆弱性に対応できるように、イメージと依存関係を定期的にスキャンして更新します。
**一般的なアンチパターン:**
+ 信頼できるレジストリからイメージとライブラリを取得しているが、使用前に署名の検証や脆弱性スキャンを行っていない。
+ イメージを強化しているが、新たな脆弱性がないか定期的にテストしたり、最新バージョンに更新したりしていない。
+ イメージの想定されるライフサイクル中に、不要なソフトウェアパッケージをインストールしている、または削除していない。
+ 本番環境のコンピューティングリソースを最新の状態に保つために、パッチの適用しか行っていない。パッチを適用するだけでは、経時的に、コンピューティングリソースが強化された標準に準拠しなくなる可能性があります。また、パッチを適用しても、セキュリティイベントの発生時に脅威アクターによってインストールされた可能性のあるマルウェアを削除できない場合があります。
**このベストプラクティスを活用するメリット:** イメージを強化すると、権限のないユーザーやサービスへの意図しないアクセスを許可する可能性がある、ランタイム環境で利用可能なパスの数を減らすことができます。また、万一、不正アクセスが発生した場合でも、影響の範囲を低減することができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
システムを強化するには、まず、オペレーティングシステム、コンテナイメージ、アプリケーションライブラリを最新バージョンにします。既知の問題にはパッチを適用します。不要なアプリケーション、サービス、デバイスドライバー、デフォルトユーザー、その他の認証情報を削除し、システムを最小限に抑えます。ポートを無効にしてワークロードに必要なリソースと機能のみを備えた環境を作成するなど、その他の必要な対策を行ってください。その状態をベースラインとして、ワークロードの監視や脆弱性管理などの目的に必要なソフトウェア、エージェント、その他のプロセスをインストールします。
[Center for Internet Security](https://www.cisecurity.org/) (CIS) や Defense Information Systems Agency (DISA) の [Security Technical Implementation Guide (STIG)](https://public.cyber.mil/stigs/) など、信頼できるソースが提供するガイダンスを利用することで、システム強化の負担を軽減できます。AWS または APN パートナーによって公開された [Amazon マシンイメージ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) (AMI) から開始して、AWS [EC2 Image Builder](https://aws.amazon.com/image-builder/) を使用し、CIS コントロールと STIG コントロールの適切な組み合わせに従って構成を自動化することをお勧めします。
CIS または DISA STIG のレコメンデーションを適用する強化済みのイメージや EC2 Image Builder レシピが用意されていますが、それらの構成によって、ご利用のソフトウェアの正常な実行が妨げられる場合があります。このような状況では、まず、強化されていないベースイメージを用意してソフトウェアをインストールし、CIS の統制を段階的に適用してその影響をテストします。ソフトウェアの実行を妨げている CIS 統制がある場合は、代わりに DISA でよりきめ細かな強化のレコメンデーションを実装できるかをテストしてください。正常に適用できる各種の CIS 統制とDISA STIG 構成を記録しておきましょう。これらを使用して、イメージ強化のレシピを EC2 Image Builder で適宜、定義します。
コンテナ化されたワークロードの場合、Docker の強化されたイメージは、[Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) [パブリックリポジトリ](https://gallery.ecr.aws/docker)で利用できます。EC2 Image Builder を使用して、AMI と共にコンテナイメージを強化できます。
オペレーティングシステムやコンテナイメージと同様に、pip、npm、Maven、NuGet などのツールを通じて、パブリックリポジトリからコードパッケージ (またはライブラリ) を取得できます。[AWS CodeArtifact](https://aws.amazon.com/codeartifact/) 内などのプライベートリポジトリを信頼できるパブリックリポジトリと統合して、コードパッケージを管理することをお勧めします。この統合により、パッケージを取得、保存し、最新の状態に保つことができます。その後、アプリケーションビルドプロセスで、Software Composition Analysis (SCA)、Static Application Security Testing (SAST)、および Dynamic Application Security Testing (DAST) などの手法を使用して、これらのパッケージの最新バージョンをアプリケーションと一緒に取得し,テストできます。
AWS Lambda を使用するサーバーレスワークロードの場合、[Lambda レイヤー](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)を使用してパッケージの依存関係を簡単に管理できます。Lambda レイヤーを使用して、さまざまな関数間で共有される一連の標準依存関係をスタンドアロンアーカイブに構成します。独自のビルドプロセスでレイヤーを作成して管理できるため、関数を一元的に最新の状態に保つことができます。
## 実装手順
+ オペレーティングシステムを強化する。信頼できるソースから取得したベースイメージを、強化した AMI を構築するための基盤として使用します。[EC2 Image Builder](https://aws.amazon.com/image-builder/) を使用すると、イメージにインストールされたソフトウェアをカスタマイズできます。
+ コンテナ化されたリソースを強化する。セキュリティのベストプラクティスを満たすように、コンテナ化されたリソースを設定します。コンテナを使用する場合は、ビルドパイプラインに [ECR イメージスキャン](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html)を実装し、イメージリポジトリに対して定期的にコンテナ内の CVE を探します。
+ AWS Lambda でサーバーレス実装を使用する場合は、[Lambda レイヤー](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)を使用して、アプリケーション関数コードと共有依存ライブラリを分離します。Lambda で[コード署名](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html)を設定すると、信頼できるコードのみを Lambda 関数で実行することができます。
## リソース
**関連するベストプラクティス:**
+ [OPS05-BP05 パッチ管理を実行する](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_dev_integ_patch_mgmt.html)
**関連動画:**
+ [Deep dive into AWS Lambda security](https://www.youtube.com/watch?v=FTwsMYXWGB0)
**関連する例:**
+ [Quickly build STIG-compliant AMI using EC2 Image Builder](https://aws.amazon.com/blogs/security/quickly-build-stig-compliant-amazon-machine-images-using-amazon-ec2-image-builder/)
+ [Building better container images](https://aws.amazon.com/blogs/containers/building-better-container-images/)
+ [Using Lambda layers to simplify your development process](https://aws.amazon.com/blogs/compute/using-lambda-layers-to-simplify-your-development-process/)
+ [Develop & Deploy AWS Lambda Layers using Serverless Framework](https://github.com/aws-samples/aws-serverless-lambda-layers)
+ [オープンソースの SCA、SAST、DAST ツールを使用してエンドツーエンドの AWS DevSecOps CI/CD パイプラインを構築する](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
# SEC06-BP03 手動管理とインタラクティブアクセスを削減する
デプロイ、構成、保守、調査のタスクは、可能な限り自動化します。自動化を利用できない場合は、緊急対応が必要な事態や安全な (サンドボックス) 環境でのコンピューティングリソースへの手動アクセスを検討してください。
**期待される成果:** プログラムスクリプトと自動化ドキュメント (ランブック) は、コンピューティングリソースに対する承認されたアクションをキャプチャします。これらのランブックは、変更検出システムによって自動的に開始されるか、人間による判断が必要な場合は手動で開始されます。コンピューティングリソースへの直接アクセスは、自動化を利用できない緊急時にのみ可能です。手動のアクティビティはすべてログに記録され、自動化機能を継続的に改善していくため、レビュープロセスに組み込まれます。
**一般的なアンチパターン:**
+ SSH や RDP などのプロトコルを使用して、Amazon EC2 インスタンスにインタラクティブにアクセスする。
+ `/etc/passwd` や Windows ローカルユーザーなどの個々のユーザーログインを維持する。
+ インスタンスにアクセスするためのパスワードまたはプライベートキーを複数のユーザー間で共有している。
+ 手動でソフトウェアをインストールし、構成ファイルを作成または更新している。
+ 手動でソフトウェアを更新するかパッチを適用する。
+ インスタンスにログインして問題をトラブルシューティングする。
**このベストプラクティスを活用するメリット:** 自動化を使用してアクションを実行すると、意図しない変更や設定ミスの運用リスクを軽減できます。インタラクティブアクセスに Secure Shell (SSH) や Remote Desktop Protocol (RDP) を使用しなくなれば、コンピューティングリソースへのアクセスの範囲が限定されます。これにより、不正行為に対して一般的な経路を遮断できます。コンピューティングリソースの管理タスクを自動化ドキュメントやプログラムスクリプトに定義しておくことで、承認されるアクティビティの全範囲をきめ細かく定義および監査するメカニズムを確立できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
インスタンスへのログインは、システム管理における従来のアプローチです。サーバーのオペレーティングシステムをインストールした後、ユーザーは通常手動でログインしてシステムを設定し、必要なソフトウェアをインストールします。サーバーの存続期間中、ユーザーはログインしてソフトウェアの更新、パッチの適用、構成の変更、問題のトラブルシューティングを行うことができます。
ただし、手動アクセスは多くのリスクを伴います。サーバーは SSH や RDP サービスなどのリクエストをリスニング (待ち受け) しなければならず、それが不正アクセスに対して経路を開くことになりかねません。また、手作業による人為的ミスのリスクも高まります。その結果、ワークロードインシデント、データの破損や破壊、その他のセキュリティ問題が発生するおそれがあります。また、人為的アクセスには認証情報の共有に対する保護も必須となり、管理オーバーヘッドが増えます。
これらのリスクを軽減するために、[AWS Systems Manager](https://aws.amazon.com/systems-manager/) などのエージェントベースのリモートアクセスソリューションを実装できます。AWS Systems Managerエージェント (SSM エージェント) は、暗号化されたチャネルを自ら確立するため、外部発信のリクエストをリッスンする必要がありません。[VPC エンドポイントを介してこのチャネルを確立するように、](https://docs.aws.amazon.com/systems-manager/latest/userguide/setup-create-vpc.html)SSM エージェントを設定することを検討してください。
Systems Manager では、マネージドインスタンスとの対話方法をきめ細かく制御できます。実行する自動化、実行できるユーザー、実行できるタイミングを定義します。Systems Manager は、インスタンスへのインタラクティブなアクセスなしで、パッチの適用、ソフトウェアのインストール、および設定変更を行うことができます。Systems Manager は、リモートシェルへのアクセスを提供し、セッション中に呼び出されたすべてのコマンドとその出力を、ログと [Amazon S3](https://aws.amazon.com/s3/)に記録することもできます。[AWS CloudTrail](https://aws.amazon.com/cloudtrail/) は、検査のために Systems Manager API の呼び出しを記録します。
### 実装手順
1. Amazon EC2 インスタンスに、[AWS Systems Manager Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html) (SSM エージェント) をインストールします。SSM Agent が基本の AMI 構成に組み込まれていて、自動的に起動されるかどうかを確認してください。
1. EC2 インスタンスプロファイルに関連付けられた IAM ロールに、`AmazonSSMManagedInstanceCore` [マネージド IAM ポリシー](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html)が含まれていることを確認します。
1. インスタンスで実行されている SSH、RDP、その他のリモートアクセスサービスを無効にします。このためには、起動テンプレートのユーザーデータセクションで設定したスクリプトを実行するか、EC2 Image Builder などのツールを使用してカスタムの AMI を構築します。
1. EC2 インスタンスに適用されるセキュリティグループの受信 (イングレス) ルールで、ポート 22/tcp (SSH) またはポート 3389/tcp (RDP) へのアクセスが許可されていないことを確認します。AWS Config などのサービスを使用して、セキュリティグループの構成ミスに対する検出とアラートを実装します。
1. Systems Manager で適切な自動化、ランブックを定義し、コマンドを実行します。IAM ポリシーを使用して、これらのアクションを実行できるユーザーと、アクションが許可される条件を定義します。これらの自動化を本稼働環境以外で徹底的にテストしてください。インスタンスにインタラクティブにアクセスする代わりに、必要に応じてこれらの自動化を呼び出します。
1. [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) を使用し、必要に応じてインスタンスへのインタラクティブなアクセスを提供します。セッションアクティビティのログ記録を有効にして、[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) または [Amazon S3](https://aws.amazon.com/s3/) で監査証跡を維持します。
## リソース
**関連するベストプラクティス:**
+ [REL08-BP04 イミュータブルなインフラストラクチャを使用してデプロイする](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_tracking_change_management_immutable_infrastructure.html)
**関連する例:**
+ [Replacing SSH access to reduce management and security overhead with AWS Systems Manager](https://aws.amazon.com/blogs/mt/vr-beneficios-session-manager/)
**関連ツール**:
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
**関連動画:**
+ [Controlling User Session Access to Instances in AWS Systems Manager Session Manager](https://www.youtube.com/watch?v=nzjTIjFLiow)
# SEC06-BP04 ソフトウェアの整合性を検証する
暗号化技術による検証を使用して、ワークロードが使用するソフトウェアアーティファクト (イメージを含む) の整合性を検証します。 コンピューティング環境内で行われる不正変更への対策として、暗号化技術によりソフトウェアに署名します。
**期待される成果:** すべてのアーティファクトが信頼できるソースから取得されます。ベンダーのウェブサイトの証明書が検証されます。 ダウンロードしたアーティファクトは、署名により暗号化技術を使用して検証されます。独自のソフトウェアは暗号化技術を使用して署名され、コンピューティング環境によって検証されます。
**一般的なアンチパターン:**
+ 定評あるベンダーのウェブサイトを信頼してソフトウェアアーティファクトを入手しているが、証明書の有効期限の通知を無視している。 証明書が有効であることを確認せずにダウンロードを続行する。
+ ベンダーウェブサイトの証明書を検証するが、これらのウェブサイトからダウンロードしたアーティファクトについては、暗号化技術による検証を行わない。
+ ソフトウェアの整合性の検証をダイジェストまたはハッシュのみに頼っている。 ハッシュでは、アーティファクトが元のバージョンから変更されていないことは確認できますが、ソースは検証されません。
+ 独自のソフトウェア、コード、またはライブラリに署名しない (独自のデプロイでしか使用しない場でも、署名は必要です)。
**このベストプラクティスを活用するメリット:** ワークロードが依存するアーティファクトの整合性を検証すると、マルウェアがコンピューティング環境に侵入するのを防ぐことができます。 ソフトウェアに署名することで、コンピューティング環境での不正実行を防ぐことができます。 コードに署名して検証することで、ソフトウェアサプライチェーンが保護されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
オペレーティングシステムイメージ、コンテナイメージ、コードアーティファクトは、多くの場合、ダイジェストやハッシュなどによる整合性チェックが可能な状態で配布されます。 その場合、クライアントはペイロードのハッシュを独自に計算し、それが公開されたものと同じであることを検証することで、整合性を検証できます。 これらのチェックはペイロードが改ざんされていないことを確認するのに役立ちますが、ペイロードが元のソース (データの来歴) から送信されたかどうかは検証しません。 データの来歴を確認するには、信頼できる機関がアーティファクトにデジタル署名するために発行した証明書が必要です。
ダウンロードしたソフトウェアまたはアーティファクトをワークロードで使用している場合は、プロバイダーがデジタル署名検証用のパブリックキーを提供しているかどうかを確認してください。 AWS では、公開しているソフトウェアのパブリックキーと検証手順を提供しています。以下に例を示します。
+ [EC2 Image Builder: AWS TOE インストールダウンロードの署名を検証します](https://docs.aws.amazon.com/imagebuilder/latest/userguide/awstoe-verify-sig.html)
+ [AWS Systems Manager: SSM エージェントの署名を検証します](https://docs.aws.amazon.com/systems-manager/latest/userguide/verify-agent-signature.html)
+ [Amazon CloudWatch: CloudWatch エージェントパッケージの署名を検証します](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/verify-CloudWatch-Agent-Package-Signature.html)
「[SEC06-BP02 強化されたイメージからコンピューティングをプロビジョニングする](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html)」で説明しているように、イメージの取得と強化に使用するプロセスにデジタル署名検証を組み込みます。
[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) を使用して、署名の検証と、独自のソフトウェアとアーティファクトの独自のコード署名ライフサイクルを管理できます。 [AWS Lambda](https://aws.amazon.com/lambda/) と [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) はどちらも Signer との統合が可能で、コードとイメージの署名を検証します。 「リソース」セクションの例を参考にして、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに Signer を組み込み、署名の検証と独自のコードやイメージへの署名を自動化できます。
## リソース
**関連ドキュメント:**
+ [Cryptographic Signing for Containers](https://aws.amazon.com/blogs/containers/cryptographic-signing-for-containers/)
+ [Best Practices to help secure your container image build pipeline by using AWS Signer](https://aws.amazon.com/blogs/security/best-practices-to-help-secure-your-container-image-build-pipeline-by-using-aws-signer/)
+ [Announcing Container Image Signing with AWS Signer and Amazon EKS](https://aws.amazon.com/blogs/containers/announcing-container-image-signing-with-aws-signer-and-amazon-eks/)
+ [AWS Lambda でのコード署名の設定](https://docs.aws.amazon.com/lambda/latest/dg/configuration-codesigning.html)
+ [Best practices and advanced patterns for Lambda code signing](https://aws.amazon.com/blogs/security/best-practices-and-advanced-patterns-for-lambda-code-signing/)
+ [Code signing using AWS Certificate Manager Private CA and AWS Key Management Service asymmetric keys](https://aws.amazon.com/blogs/security/code-signing-aws-certificate-manager-private-ca-aws-key-management-service-asymmetric-keys/)
**関連する例:**
+ [Automate Lambda code signing with Amazon CodeCatalyst and AWS Signer](https://aws.amazon.com/blogs/devops/automate-lambda-code-signing-with-amazon-codecatalyst-and-aws-signer/)
+ [Signing and Validating OCI Artifacts with AWS Signer](https://aws.amazon.com/blogs/containers/signing-and-validating-oci-artifacts-with-aws-signer/)
**関連ツール:**
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html)
+ [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/)
+ [AWS Key Management Service](https://aws.amazon.com/kms/)
+ [AWS CodeArtifact](https://aws.amazon.com/codeartifact/)
# SEC06-BP05 コンピューティング保護を自動化する
コンピューティング保護操作を自動化して、人的介入の必要性を減らします。自動スキャンを使用してコンピューティングリソース内の潜在的な問題を検知し、プログラムによる自動応答またはフリート管理操作で修正します。 CI/CD プロセスに自動化を組み込むことで、最新の依存関係を反映した信頼できるワークロードをデプロイできます。
**期待される成果:** 自動化システムは、コンピューティングリソースのすべてのスキャンとパッチ適用を実行します。自動検証を使用して、ソフトウェアイメージと依存関係が信頼できるソースから取得され、改ざんされていないことを確認します。ワークロードは自動的に最新の依存関係をチェックし、AWS コンピューティング環境での信頼度を確立するために署名されます。 非準拠リソースが検出されると、自動修復が開始します。
**一般的なアンチパターン:**
+ イミュータブルインフラストラクチャの慣習に従っているが、本稼働システムの緊急時のパッチ適用や交換に備えたソリューションが不在である。
+ 誤った構成のリソースを自動修正しているが、手動によるオーバーライドメカニズムが導入されていない。 要件の調整が必要となる事態が発生し、そうした変更を行うまで自動化を中断しなければならない場合が考えられます。
**このベストプラクティスを活用するメリット:** 自動化は、コンピューティングリソースへの不正アクセスと不正使用のリスクを軽減します。 本番環境に構成ミスが波及しないよう防ぎ、構成ミスが生じた場合は検知して修正できます。 コンピューティングリソースへの不正アクセスや不正使用を検知し、対応にかかる時間を短縮するうえでも、自動化が役に立ちます。 その結果、問題による全体的な影響範囲を縮小できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
コンピューティングリソースを保護するために、セキュリティの柱のプラクティスで説明されている自動化を適用できます。「[SEC06-BP01 脆弱性管理を実行する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_vulnerability_management.html)」では、CI/CD パイプラインの両方で [Amazon Inspector](https://aws.amazon.com/inspector/) を使用し、ランタイム環境を継続的にスキャンして既知の共通脆弱性識別子 (CVE) を見つける方法を説明しています。 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) を使用してパッチを適用したり、自動ランブックを通じて新しいイメージから再デプロイしたりして、コンピューティングフリートを最新のソフトウェアやライブラリで更新できます。 これらの手法を使用すれば、手作業によるプロセスやコンピューティングリソースへのインタラクティブアクセスの必要性を低減できます。 詳細については、「[SEC06-BP03 手動管理とインタラクティブアクセスを削減する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_reduce_manual_management.html)」を参照してください。
自動化は、「[SEC06-BP02 強化されたイメージからコンピューティングをプロビジョニングする](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_hardened_images.html)」と「[SEC06-BP04 ソフトウェアの整合性を検証する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_protect_compute_validate_software_integrity.html)」で説明している、信頼できるワークロードのデプロイでも役割を果たします。 [EC2 Image Builder](https://aws.amazon.com/image-builder/)、[AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html)、[AWS CodeArtifact](https://aws.amazon.com/codeartifact/)、[Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) などのサービスを使用することで、強化され、承認されたイメージとコードの依存関係をダウンロード、検証、コンストラクト、保存できます。 Inspector と同様、これらのサービスがそれぞれ CI/CD プロセスで役割を果たし、依存関係が最新であり、出所が信頼できるソースであることが確認された場合にのみ、ワークロードが本番環境に投入されるようにします。 ワークロードも署名されるため、[AWS Lambda](https://aws.amazon.com/lambda/) や [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) などの AWS コンピューティング環境は、実行を許可する前に改ざんされていないことを確認できます。
このような予防的統制のほかに、コンピューティングリソースの発見的統制でも自動化を活用できます。 一例として、[AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) は、[[EC2.8] EC2 インスタンスはインスタンスメタデータサービスバージョン 2 (IMDSv2) を使用する必要があるか](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-8)、などのチェックを含む、[NIST 800-53 Rev.5](https://docs.aws.amazon.com/securityhub/latest/userguide/nist-standard.html)標準を提供しています IMDSv2 はセッション認証の手法を使用して、X-Forwarded-For HTTP ヘッダーを含むリクエストをブロックし、ネットワーク TTL を 1 に設定して、EC2 インスタンスに関する情報を取得する外部ソース発信のトラフィックを停止します。Security Hub CSPM のこのチェックでは、EC2 インスタンスが IMDSv1 を使用しているタイミングを検出し、自動修復を開始できます。自動検出と修復の詳細については、「[SEC04-BP04 非準拠リソースの修復を開始する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_detect_investigate_events_noncompliant_resources.html)」を参照してください。
### 実装手順
1. [EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/integ-compliance-products.html) を使用して、安全で規制に準拠し、強化された AMI の作成を自動化します。 基本の AWS イメージや APN パートナーイメージから、Center for Internet Security (CIS) ベンチマークまたは Security Technical Implementation Guide (STIG) 標準の統制を組み込んだイメージを作成できます。
1. 構成管理を自動化します。構成管理のサービスやツールを使うことで、コンピューティングリソースで安全性の高い構成を自動的に適用および検証します。
1. [AWS Config](https://aws.amazon.com/config/) を使用した自動構成管理
1. [AWS Security Hub CSPM](https://aws.amazon.com/security-hub/) を使用したセキュリティとコンプライアンス体制の自動管理
1. Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのパッチ適用または置き換えを自動化する。AWSSystems Manager Patch Manager は、セキュリティ関連および他の種類の更新の両方を使用して、マネージドインスタンスにパッチを適用するプロセスを自動化します。Patch Manager を使用して、オペレーティングシステムとアプリケーションの両方にパッチを適用することができます。
1. [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
1. 共通脆弱性識別子 (CVE) を検知するためのコンピューティングリソースのスキャンを自動化し、セキュリティスキャンソリューションをビルドパイプラインに埋め込みます。
1. [Amazon Inspector](https://aws.amazon.com/inspector/) –
1. [ECR イメージスキャン](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html)
1. コンピューティングリソースを保護するために、マルウェアと脅威を自動検出する Amazon GuardDuty を検討してください。GuardDuty は、AWS 環境で [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 関数が呼び出されたときに発生する可能性のある問題を特定することもできます。
1. [Amazon GuardDuty](https://aws.amazon.com/guardduty/)
1. AWS パートナーソリューションを検討する。AWSパートナーは、オンプレミス環境の既存の統制に匹敵するか同等の、またはそれらと統合できる、業界をリードする製品を提供しています。これらの製品で AWS の既存のサービスを補完して、包括的なセキュリティアーキテクチャをデプロイし、クラウド環境とオンプレミス環境の全体でよりシームレスなエクスペリエンスを実現できます。
1. [インフラストラクチャセキュリティ](https://aws.amazon.com/security/partner-solutions/#infrastructure_security)
## リソース
**関連するベストプラクティス:**
+ [SEC01-BP06 標準的なセキュリティ統制のデプロイを自動化する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_automate_security_controls.html)
**関連ドキュメント:**
+ [Get the full benefits of IMDSv2 and disable IMDSv1 across your AWS infrastructure](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure/)
**関連動画:**
+ [Security best practices for the Amazon EC2 instance metadata service](https://youtu.be/2B5bhZzayjI)