# 転送中のデータの保護
転送中のデータとは、システム間で送信されるすべてのデータを指します。これには、ワークロード内のリソース間での通信や他のサービスとエンドユーザーとの通信が含まれます。転送中のデータに適切なレベルの保護を提供することにより、ワークロードのデータの機密性と整合性を守ることができます。
**VPC またはオンプレミスの場所間のデータを保護する:** [AWS PrivateLink](https://aws.amazon.com/privatelink/) を使用して、Amazon Virtual Private Cloud (Amazon VPC) 間、またはオンプレミスから AWS にホストされているサービスへの保護されたプライベートネットワーク接続を構築できます。AWS サービス、サードパーティーサービス、および他の AWS アカウントのサービスを、あたかも自分のプライベートネットワークにあるかのように利用することができます。AWS PrivateLink を使うと、インターネットゲートウェイまたは NAT を使わずに、IP CIDR が重複するアカウント間のサービスにアクセスすることができます。また、ファイアウォールルール、パス定義、またはルートテーブルを設定する必要もありません。トラフィックは Amazon のバックボーンにとどまり、インターネットを横断しないため、お客様のデータは保護されます。HIPAA および EU/US プライバシーシールドなどの業界特有のコンプライアンス規制に対する準拠を維持できます。AWS PrivateLink はサードパーティーソリューションとシームレスに連携し、簡素化されたグローバルネットワークを作成するため、クラウドへの移行を加速させて利用可能な AWS のサービスを活用できます。
**Topics**
+ [SEC09-BP01 安全な鍵および証明書管理を実装する](sec_protect_data_transit_key_cert_mgmt.md)
+ [SEC09-BP02 伝送中に暗号化を適用する](sec_protect_data_transit_encrypt.md)
+ [SEC09-BP03 ネットワーク通信を認証する](sec_protect_data_transit_authentication.md)
# SEC09-BP01 安全な鍵および証明書管理を実装する
Transport Layer Security (TLS) 証明書は、ネットワーク通信を保護し、インターネットやプライベートネットワーク上のウェブサイト、リソース、ワークロードの ID を確立するために使用されます。
**期待される成果:** 公開鍵基盤 (PKI) で証明書をプロビジョニング、デプロイ、保存、更新できる、安全な証明書管理システム。安全な鍵と証明書の管理メカニズムは、証明書のプライベートキーの内容が漏洩するのを防ぎ、自動的に証明書の定期更新を行います。また、他のサービスと統合して、ワークロード内のマシンリソースに安全なネットワーク通信と ID を提供します。キーの内容は、決して人的 ID にアクセス可能なものであってはなりません。
**一般的なアンチパターン:**
+ 証明書のデプロイまたは更新プロセス中に手動で手順を実行する。
+ プライベート認証機関 (CA) を設計する際、CA 階層に十分な注意を払わない。
+ 公共リソースに自己署名証明書を使用する。
**このベストプラクティスを活用するメリット:**
+ 自動デプロイと自動更新により証明書管理を簡素化する
+ TLS 証明書を使用して転送中のデータの暗号化を奨励する
+ 認証機関による証明書アクションのセキュリティと可監査性を向上させる
+ CA 階層のさまざまなレイヤーにおける管理業務を整理する
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
最新のワークロードでは、TLS などの PKI プロトコルを使用して暗号化されたネットワーク通信が広く利用されています。PKI 証明書の管理は複雑になる場合がありますが、証明書のプロビジョニング、デプロイ、更新を自動化することで、証明書管理に伴う手間を軽減できます。
AWS には、汎用 PKI 証明書を管理するための 2 つのサービス、[AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) と [AWS Private Certificate Authority (AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) があります。ACM は、証明書をプロビジョニング、管理、デプロイして、パブリックとプライベート両方の AWS ワークロードで使用できるようにするための主要なサービスです。ACM は AWS Private CA を使用してプライベート証明書を発行し、他の多くの AWS Managed Services と[連携](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html)してワークロード用の安全な TLS 証明書を提供します。ACM は、[Amazon Trust Services](https://www.amazontrust.com/repository/) からパブリックに信頼された証明書を発行することもできます。ACM のパブリック証明書は、最新のブラウザとオペレーティングシステムがデフォルトでこれらの証明書を信頼しているため、パブリック側ワークロードで使用できます。
AWS Private CA では、独自のルート認証機関または下位認証機関を確立し、API を通じて TLS 証明書を発行できます。こうした種類の証明書は、TLS 接続のクライアント側で信頼チェーンを制御し管理するシナリオで使用できます。TLS ユースケースに加えて、AWS Private CA は、Kubernetes ポッドへの証明書の発行、Matter デバイス製品認証、コード署名、[カスタムテンプレート](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html)を使用したその他のユースケースにも使用できます。また、[IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) を使用することで、プライベート CA によって署名された X.509 証明書が発行されたオンプレミスのワークロードに、一時的な IAM 認証情報を提供することもできます。
ACM と AWS Private CA に加えて、[AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/what-is-aws-iot.html) は、PKI 証明書のプロビジョニング、管理、IoT デバイスへのデプロイに特化したサポートを提供しています。AWS IoT Core は、公開鍵のインフラストラクチャに [IoT デバイスを大規模にオンボーディングする](https://docs.aws.amazon.com/whitepapers/latest/device-manufacturing-provisioning/device-manufacturing-provisioning.html)ための特殊な仕組みを備えています。
[Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) や [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) などの一部のAWSサービスは、証明書を使用してアプリケーション接続を保護する独自の機能を提供します。例えば、API Gateway と Application Load Balancer (ALB) はどちらも AWS マネジメントコンソール、CLI、または API を使用して作成およびエクスポートするクライアント証明書を使用した相互 TLS (mTLS) をサポートしています。
**プライベート CA 階層を確立する際の考慮事項**
プライベート CA を確立する必要がある場合、特別な注意を払って事前に CA 階層を適切に設計しておくことが重要です。プライベート CA 階層を作成する場合は、CA 階層の各レベルを個別の AWS アカウントにデプロイすることがベストプラクティスです。この意図的な手順により、CA 階層内の各レベルへの外部からのアクセスが減り、CloudTrail ログデータ内の異常をより簡単に発見できるようになります。また、いずれかのアカウントに不正アクセスがあった場合、アクセス範囲と影響が小さくなります。ルート CA はそれぞれ別のアカウントに保存し、1 件以上の中間 CA 証明書の発行にのみ使用すべきです。
次に、ルート CA のアカウントとは別のアカウントに 1 つ以上の中間 CA を作成し、エンドユーザー、デバイス、または他のワークロードに証明書を発行します。最後に、ルート CA から中間 CA に証明書を発行します。これにより、エンドユーザーまたはデバイスに証明書が発行されます。回復力の計画、クロスリージョンレプリケーション、組織全体での CA の共有など、CA デプロイの計画と CA 階層の設計の詳細については、「[Planning your AWS Private CA deployment](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html)」を参照してください。
### 実装手順
1. ユースケースに必要となる適切な AWS サービスを判断します。
+ 多くのユースケースでは、[AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) を使用して既存の AWS パブリックキーインフラストラクチャを活用することができます。ACM は、ウェブサーバー、ロードバランサー、一般的に信頼されている証明書のその他の用途向けに TLS 証明書をデプロイする際に使用できます。
+ 独自のプライベート認証機関の階層を設定する必要がある場合や、エクスポート可能な証明書へのアクセスが必要な場合は、[AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) の使用を検討します。それにより、ACM を使用して、AWS Private CA を使った[さまざまな種類のエンドエンティティ証明書](https://docs.aws.amazon.com/privateca/latest/userguide/PcaIssueCert.html)を発行できます。
+ 組み込み型のモノのインターネット (IoT) デバイス向けに証明書を大規模にプロビジョニングする必要があるユースケースについては、[AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/x509-client-certs.html) の使用を検討します。
+ [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) や [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) などのサービスでネイティブ mTLS 機能を使用することを検討してください。
1. 可能な限り、証明書の自動更新を実装してください。
+ ACM が発行した証明書に、[ACM マネージド型更新](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html)を、統合された AWS のマネージドサービスと併せて使用します。
1. 認証機関を保有するアカウントへの
+ [CloudTrail logs](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html) を有効にして、認証機関を持つアカウントへのアクセスを追跡します。CloudTrail でログファイルの整合性検証を設定し、ログデータの信頼性を検証することを検討します。
+ プライベート CA が発行または取り消しした証明書を一覧表示する[監査レポート](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html)を、定期的に生成し、レビューします。これらのレポートは S3 バケットにエクスポートできます。
+ プライベート CA をデプロイするときは、証明書失効リスト (CRL) を保存する S3 バケットも確立する必要があります。ワークロードの要件に基づいてこの S3 バケットを設定する方法については、「[Planning a certificate revocation list (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html)」を参照してください。
## リソース
**関連するベストプラクティス:**
+ [SEC02-BP02 一時的な認証情報を使用する](sec_identities_unique.md)
+ [SEC08-BP01 安全なキー管理を実装する](sec_protect_data_rest_key_mgmt.md)
+ [SEC09-BP03 ネットワーク通信を認証する](sec_protect_data_transit_authentication.md)
**関連ドキュメント:**
+ [How to host and manage an entire private certificate infrastructure in AWS](https://aws.amazon.com/blogs/security/how-to-host-and-manage-an-entire-private-certificate-infrastructure-in-aws/)
+ [How to secure an enterprise scale ACM Private CA hierarchy for automotive and manufacturing](https://aws.amazon.com/blogs/security/how-to-secure-an-enterprise-scale-acm-private-ca-hierarchy-for-automotive-and-manufacturing/)
+ [Private CA best practices](https://docs.aws.amazon.com/privateca/latest/userguide/ca-best-practices.html)
+ [How to use AWS RAM to share your ACM Private CA cross-account](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/)
**関連動画:**
+ [Activating AWS Certificate Manager Private CA (workshop)](https://www.youtube.com/watch?v=XrrdyplT3PE)
**関連する例:**
+ [Private CA workshop](https://catalog.workshops.aws/certificatemanager/en-US/introduction)
+ [IOT Device Management Workshop](https://iot-device-management.workshop.aws/en/) (デバイスプロビジョニングを含む)
**関連ツール:**
+ [Plugin to Kubernetes cert-manager to use AWS Private CA](https://github.com/cert-manager/aws-privateca-issuer)
# SEC09-BP02 伝送中に暗号化を適用する
組織的、法的、コンプライアンス要件を満たすための組織のポリシー、法的義務と標準に基づいて、定義された暗号化要件を適用します。機密データを仮想プライベートクラウド (VPC) の外部に送信する場合は、暗号化されたプロトコルのみを使用します。暗号化を行うと、データが信頼できないネットワークを転送中も、データの機密性を保持できます。
**期待される成果:** リソースとインターネット間のネットワークトラフィックを暗号化して、データへの不正アクセスを軽減します。セキュリティ要件に従って、内部 AWS 環境内のネットワークトラフィックを暗号化します。転送中のデータはすべて、安全な TLS プロトコルと暗号スイートを使用して暗号化します。
**一般的なアンチパターン:**
+ 廃止されたバージョンの SSL、TLS、および暗号スイートコンポーネント (SSL v3.0、1024-bit RSA キー、および RC4 暗号) を使用する。
+ パブリック向けリソースとの間で暗号化されていない (HTTP) トラフィックを許可する。
+ X.509 証明書をモニタリングし、期限が切れる前に交換しない。
+ TLS に自己署名 X.509 証明書を使用する。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS のサービスには、通信に TLS を使用し、AWS API との通信の際に伝送中データの暗号化を利用できる、HTTPS エンドポイントが用意されています。安全でない HTTP プロトコルは、セキュリティグループを使用して仮想プライベートクラウド (VPC) で監査およびブロックできます。HTTP リクエストは [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html) 内または [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions) の HTTPS に自動的にリダイレクトすることもできます。[Amazon Simple Storage Service (Amazon S3) バケットポリシー](https://aws.amazon.com/blogs/storage/enforcing-encryption-in-transit-with-tls1-2-or-higher-with-amazon-s3/)を使用すると、HTTP 経由でオブジェクトをアップロードする機能を制限し、バケットへのオブジェクトのアップロードに HTTPS の使用を効果的に強制できます。コンピューティングリソースを完全に制御して、サービス全体に伝送中データの暗号化を実装できます。また、外部ネットワークまたは [AWS Direct Connect](https://aws.amazon.com/directconnect/) から VPC に VPN で接続することで、トラフィックの暗号化を円滑にすることができます。[AWS では 2024 年 2 月で以前のバージョンの TLS の使用が廃止](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/)されたため、クライアントが少なくとも TLS 1.2 を使用して AWS API を呼び出すことを確認してください。TLS 1.3 を使用することをお勧めします。転送中の暗号化に特別な要件がある場合は、AWS Marketplace で利用可能なサードパーティーのソリューションを見つけることができます。
### 実装手順
+ **伝送中に暗号化を適用する:** 暗号化の要件は、最新の標準とベストプラクティスに基づき、安全なプロトコルのみを許可する必要があります。例えば、Application Load Balancer または Amazon EC2 インスタンスに対してのみ HTTPS プロトコルを許可するよう、セキュリティグループを設定します。
+ **エッジサービスで安全なプロトコルを設定する:** [Amazon CloudFront を使用して HTTPS を設定](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)し、[自社のセキュリティ体制やユースケースに適したセキュリティプロファイル](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers)を使用します。
+ **[外部接続に VPN](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html) を使用する:** ポイントツーポイント接続やネットワーク間接続を IPsec VPN で保護し、データのプライバシーと整合性の両方を提供することを検討します。
+ **ロードバランサーで安全なプロトコルを設定する:** リスナーに接続するクライアントがサポートしている暗号スイートのなかで、もっとも堅牢な暗号スイートを提供しているセキュリティポリシーを選びます。[Application Load Balancer 用の HTTPS リスナーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)
+ **Amazon Redshift で安全なプロトコルを設定する:** [Secure Socket Layer (SSL) または Transport Layer Security (TLS) 接続](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)を必須とするように、クラスターを設定します。
+ **安全なプロトコルを設定する:** AWS サービスのドキュメントをレビューして、転送時の暗号化機能を決定します。
+ **Amazon S3 バケットへのアップロード時の安全なアクセスを設定する:** Amazon S3 バケットポリシーコントロールを使用して、データへの[安全なアクセスを適用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)します。
+ **[AWS Certificate Manager](https://aws.amazon.com/certificate-manager/) の使用を検討する:** ACM を使用すると、AWS サービスで使用するパブリック TLS 証明書のプロビジョニング、管理、デプロイが行えます。
+ **プライベート PKI のニーズには [AWS Private Certificate Authority](https://aws.amazon.com/private-ca/) の使用を検討する:** AWS Private CA を使用すると、プライベート認証局 (CA) 階層を作成してエンドエンティティ X.509 証明書を発行することができます。こちらは暗号化された TLS チャネルの作成に使用できます。
## リソース
**関連ドキュメント:**
+ [CloudFront で HTTPS を使用する](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html)
+ [AWS Virtual Private Network を使用して VPC をリモートネットワークに接続する](https://docs.aws.amazon.com/vpc/latest/userguide/vpn-connections.html)
+ [Create an HTTPS listener for your Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html)
+ [Tutorial: Configure SSL/TLS on Amazon Linux 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/SSL-on-amazon-linux-2.html)
+ [SSL/TLS を使用した DB インスタンスへの接続の暗号化](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html)
+ [接続のセキュリティオプションを設定する](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)
# SEC09-BP03 ネットワーク通信を認証する
Transport Layer Security (TLS) や IPsec など、認証をサポートするプロトコルを使用して、通信の ID を検証します。
サービス間、アプリケーション間、またはユーザーへの通信には常に、安全で認証済みのネットワークプロトコルを使用するようにワークロードを設計してください。認証と認可をサポートするネットワークプロトコルを使用すると、ネットワークフローをより強力に制御し、不正アクセスの影響を軽減できます。
**期待される成果:** ワークロードで、サービス間のデータプレーンとコントロールプレーンのトラフィックフローが明確に定義されます。技術上可能な場合は必ず、認証および暗号化されたネットワークプロトコルをトラフィックフローが使用する。
**一般的なアンチパターン:**
+ ワークロード内のトラフィックフローが暗号化されていない、または認証されていない。
+ 複数のユーザーやエンティティで認証情報を再利用している。
+ アクセス制御のメカニズムとしてネットワーク統制にばかり依存している。
+ 業界標準の認証メカニズムに頼る代わりに、カスタムの認証メカニズムを作成する。
+ VPC 内のサービスコンポーネントや他のリソース間のトラフィックフローが必要以上に許可されている。
**このベストプラクティスを活用するメリット:**
+ 不正アクセスによる影響が及ぶ範囲をワークロードの一部に制限します。
+ アシュアランスのレベルを上げ、認証済みのエンティティだけがアクションを実行するように徹底します。
+ 導入予定のデータ転送インターフェイスを明確に定義し、実際に導入して、サービスの分離を強化します。
+ リクエストのアトリビューションと、明確に定義された通信インターフェイスにより、モニタリング、ログ記録、インシデント対応を強化します。
+ ネットワーク統制に認証と認可の制御を組み合わせることで、ワークロードに多層防御を提供します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
ワークロードのネットワークトラフィックのパターンは、次の 2 つのカテゴリに分類できます。
+ East-West トラフィックは、特定のワークロードを構成しているサービス間のトラフィックフローを表します。
+ North-South トラフィックはワークロードとコンシューマー間のトラフィックフローを表します。
一般的には North-South トラフィックを暗号化し、認証済みプロトコルを用いて East-West トラフィックを保護する例はあまり見られません。最近のセキュリティ対策では、ネットワークの設計だけで、2 つのエンティティ間に信頼関係があるとは想定しないというのが通例となっています。2 つのサービスが共通のネットワーク境界内に存在する場合でも、それらのサービス間の通信を暗号化し、認証と認可を行うことがベストプラクティスです。
例えば、AWS サービス API は、リクエストの発信側のネットワークに関係なく、[AWS Signature Version 4 (SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) 署名プロトコルを使用して発信者を認証します。この認証により、AWS API はアクションをリクエストした ID を検証し、その ID をポリシーと組み合わせて、アクションを許可するかどうかを判断する認可決定を行うことができます。
[Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/access-management-overview.html) や [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) などのサービスでは、同じ SigV4 署名プロトコルを使用して、独自のワークロードの East-West トラフィックに認証と認可を追加できます。SigV4 ベースの認証と認可が要求されるサービスに AWS 環境外のリソースから通信する必要がある場合は、非 AWS リソースに [AWS Identity and Access Management (IAM) Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html) を使用することで、一時的な AWS 認証情報を取得できます。これらの認証情報は、SigV4 を使用してサービスへのリクエストに署名して、アクセスの認可を受けるために使用できます。
East-West トラフィックを認証するメカニズムとしては、TLS 相互認証 (mTLS) も一般的です。モノのインターネット (IoT)、ビジネス間アプリケーション、マイクロサービスの多くは、mTLS を採用しています。TLS 通信のクライアント側とサーバー側の両方が X.509 証明書を使用して、双方のアイデンティティを認証し合います。これらの証明書は AWS Private Certificate Authority (AWS Private CA) で発行できます。[Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) などのサービスを使用して、ワークロード間またはワークロード内の通信で mTLS 認証を行うことができます。[Application Load Balancer は、内部または外部向けワークロードの mTLS もサポート](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html)しています。mTLS は TLS 通信の両側に認証情報を提供しますが、認証のメカニズムは提供しません。
最後に、OAuth 2.0 と OpenID Connect (OIDC) の 2 つのプロトコルは、ユーザーがサービスへのアクセスを制御する際によく利用されていますが、最近はサービス間のトラフィックにもよく利用されています。API Gateway の [JSON ウェブトークン (JWT) オーソライザー](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html)を使用すると、OIDC または OAuth 2.0 の ID プロバイダーが発行した JWT を使用して、API ルートへのアクセスをワークロードで制限することができます。OAuth2 のスコープを基本的な承認決定のソースとして使用できますが、依然として承認チェックをアプリケーション層に実装する必要があります。OAuth2 スコープ単体で複雑な承認ニーズに対応することはできません。
### 実装手順
+ **ワークロードのネットワークフローを定義し文書化する:** 多層防御戦略を実装するには、まずワークロードのトラフィックフローを定義します。
+ ワークロードを構成するさまざまなサービス間でデータがどのように転送されるかを明確に定義したデータフロー図を作成します。これらのフローを認証済みのネットワークチャネルに実際に流していく前に、まずこの図を用意します。
+ 開発段階とテスト段階でワークロードを計測して、ランタイム時のワークロードの動作がデータフロー図に正確に反映されていることを確認してください。
+ データフロー図は、脅威モデリングを行う (「[SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)」を参照) ときにも役立ちます。
+ **ネットワーク統制を確立する:** データフローに応じたネットワーク統制を確立するときは AWS の機能を使用することを検討します。ネットワーク境界は、それだけでは十分なセキュリティ統制にはなりませんが、ワークロードを保護する多層防御戦略の 1 層にはなります。
+ リソース間のデータフローの確立、定義、制限には、[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/security-groups.html)を使用します。
+ AWS サービスと、AWS PrivateLink をサポートしているサードパーティーのサービスの両方と通信するときは、[AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) の使用を検討します。AWS PrivateLink インターフェイスエンドポイントを介して送信されるデータは、AWS ネットワークバックボーン内にとどまり、公開インターネットを経由しません。
+ **ワークロード内のサービス間に認証と認可を実装する:** ワークロード内のトラフィックフローの認証と暗号化を実現するために最も適した AWS サービスのセットを選択します。
+ サービス間通信のセキュリティを保護するときは、[Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html) の使用を検討します。VPC Lattice では、[SigV4 認証を認証ポリシーと組み合わせて](https://docs.aws.amazon.com/vpc-lattice/latest/ug/auth-policies.html)使用することで、サービス間のアクセスを制御できます。
+ mTLS を使用するサービス間通信では、[API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html) または [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html) の使用を検討します。[AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) を使用すると、mTLS で使用する証明書を発行できる、プライベート CA 階層を作成できます。
+ OAuth 2.0 または OIDC を使用したサービスを統合するときは、[API Gateway で JWT オーソライザーを使用する](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html)ことを検討します。
+ ワークロードと IoT デバイスとの通信には、[AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/client-authentication.html) の使用を検討します。これには、ネットワークトラフィックの暗号化と認証の方法が複数用意されています。
+ **不正アクセスを監視する:** 意図しない通信チャネル、不正なプリンシパルによる保護済みリソースへのアクセス、その他不適切なアクセスパターンを継続的にモニタリングします。
+ VPC Lattice を使用してサービスへのアクセスの管理するときは、[VPC Lattice アクセスログ](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html)を有効にしてモニタリングすることを検討します。これらのアクセスログには、リクエスト元のエンティティに関する情報、ソースとターゲットの VPC などのネットワーク情報、リクエストのメタデータが記録されています。
+ ネットワークフローのメタデータをキャプチャし、異常がないか定期的に点検するときは、[VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)を有効にすることを検討します。
+ セキュリティインシデントのプランニング、シミュレーション、対応に関する解説は、「[AWS セキュリティインシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)」および「セキュリティの柱 - AWS Well-Architected Framework」内の「[インシデント対応](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/incident-response.html)」のセクションを参照してください。
## リソース
**関連するベストプラクティス:**
+ [SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_analyze_cross_account.html)
+ [SEC02-BP02 一時的な認証情報を使用する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html)
+ [SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)
**関連ドキュメント:**
+ [Evaluating access control methods to secure Amazon API Gateway APIs](https://aws.amazon.com/blogs/compute/evaluating-access-control-methods-to-secure-amazon-api-gateway-apis/)
+ [REST API の相互 TLS 認証の設定](https://docs.aws.amazon.com/apigateway/latest/developerguide/rest-api-mutual-tls.html)
+ [How to secure API Gateway HTTP endpoints with JWT authorizer](https://aws.amazon.com/blogs/security/how-to-secure-api-gateway-http-endpoints-with-jwt-authorizer/)
+ [Authorizing direct calls to AWS services using AWS IoT Core credential provider](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html)
+ [AWS セキュリティインシデント対応ガイド](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
**関連動画:**
+ [AWS re:invent 2022: Introducing VPC Lattice ](https://www.youtube.com/watch?v=fRjD1JI0H5w)
+ [AWS re:invent 2020: Serverless API authentication for HTTP APIs on AWS](https://www.youtube.com/watch?v=AW4kvUkUKZ0)
**関連する例:**
+ [Amazon VPC Lattice Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [Zero-Trust Episode 1 – The Phantom Service Perimeter workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)