# 전송 중 데이터 보호
*전송 중 데이터*는 시스템 간에 전송되는 모든 데이터를 의미합니다. 여기에는 워크로드 내 리소스 간의 통신과 다른 서비스 및 최종 사용자 간의 통신이 포함됩니다. 전송 중 데이터를 적절한 수준으로 보호하면 워크로드 데이터의 기밀성과 무결성을 보호할 수 있습니다.
**VPC 또는 온프레미스 위치 사이에서 데이터 보호:** Amazon Virtual Private Cloud(VPC) 또는 AWS에 호스팅된 서비스에 대한 온프레미스 연결 사이에서 안전한 프라이빗 네트워크 연결을 생성하는 데 [AWS PrivateLink](https://aws.amazon.com/privatelink/)를 사용할 수 있습니다. 프라이빗 네트워크에서와 같이 AWS 서비스, 서드파티 서비스 및 기타 AWS 계정의 서비스에 액세스할 수 있습니다. AWS PrivateLink를 사용하면 인터넷 게이트웨이 또는 NAT 없이도 IP CIDR이 중복되는 계정에서 서비스에 액세스할 수 있습니다. 또한 방화벽 규칙, 경로 정의 또는 라우팅 테이블을 구성하지 않아도 됩니다. 트래픽은 Amazon 백본에 머무르며 인터넷을 통과하지 않으므로 데이터가 보호됩니다. HIPAA 및 EU/US Privacy Shield와 같은 업계별 규정 준수 규제를 계속 준수할 수 있습니다. 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 보안 키 및 인증서 관리 구현
전송 계층 보안(TLS) 인증서는 인터넷과 프라이빗 네트워크에서 네트워크 통신을 보호하고 웹 사이트, 리소스 및 워크로드의 ID를 설정하는 데 사용됩니다.
**원하는 성과:** 퍼블릭 키 인프라(PKI)에서 인증서를 프로비저닝, 배포, 저장 및 갱신할 수 있는 보안 인증서 관리 시스템. 보안 키 및 인증서 관리 메커니즘은 인증서 개인 키 구성 요소가 공개되는 것을 방지하고 정기적으로 인증서를 자동 갱신합니다. 또한 다른 서비스와 통합하여 워크로드 내부의 머신 리소스에 대한 보안 네트워크 통신 및 ID를 제공합니다. 키 구성 요소는 인적 자격 증명이 절대 접근할 수 없어야 합니다.
**일반적인 안티 패턴:**
+ 인증서 배포 또는 갱신 프로세스 중에 수동 단계를 수행합니다.
+ 프라이빗 CA를 설계할 때 인증 기관(CA) 계층 구조에 충분히 주의를 기울이지 않습니다.
+ 퍼블릭 리소스에 자체 서명된 인증서를 사용합니다.
**이 모범 사례 확립의 이점: **
+ 자동 배포 및 갱신을 통해 인증서 관리 간소화
+ TLS 인증서를 사용하여 전송 중 데이터의 암호화 장려
+ 인증 기관이 취한 인증서 작업의 보안 및 감사 가능성 향상
+ CA 계층 구조의 여러 계층에서 관리 업무 구성
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 지침
최신 워크로드는 TLS와 같은 PKI 프로토콜을 사용하는 암호화된 네트워크 통신을 광범위하게 사용합니다. PKI 인증서 관리는 복잡할 수 있지만 자동화된 인증서 프로비저닝, 배포 및 갱신을 통해 인증서 관리와 관련된 마찰을 줄일 수 있습니다.
AWS에서는 범용 PKI 인증서를 관리하기 위해 [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관리형 서비스와 [통합](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를 사용하면 자체 루트의 CA 또는 하위 CA를 설정하고 API를 통해 TLS 인증서를 발급할 수 있습니다. 이러한 종류의 인증서는 TLS 연결의 클라이언트 측에서 신뢰 체인을 제어하고 관리하는 시나리오에서 사용할 수 있습니다. TLS 사용 사례 외에도 AWS Private CA를 사용하면 [사용자 지정 템플릿](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html)으로 Kubernetes 포드, Matter 디바이스 제품 증명, 코드 서명 및 기타 사용 사례에 인증서를 발급할 수 있습니다. [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 Management Console, CLI 또는 API를 사용하여 생성하고 내보내는 클라이언트 인증서를 사용하여 상호 TLS(mTLS)를 지원합니다.
**프라이빗 CA 계층 구조 설정 시 고려 사항**
프라이빗 CA를 설정해야 하는 경우 CA 계층 구조를 미리 적절하게 설계할 수 있도록 특별히 주의를 기울이는 것이 중요합니다. 프라이빗 CA 계층 구조를 만들 때는 CA 계층 구조의 각 수준을 별도의 AWS 계정에 배포하는 것이 좋습니다. 이 의도적인 단계는 CA 계층 구조의 각 수준에 대한 노출 영역을 줄여 CloudTrail 로그 데이터에서 이상 징후를 더 쉽게 발견하고 계정 중 하나에 대한 무단 액세스가 발생할 경우 액세스 또는 영향 범위를 줄일 수 있습니다. 루트 CA는 별도의 계정에 있어야 하며 하나 이상의 중간 CA 인증서를 발급하는 데만 사용해야 합니다.
그런 다음 루트 CA 계정과 분리된 계정에 하나 이상의 중간 CA를 생성하여 최종 사용자, 디바이스 또는 기타 워크로드에 대한 인증서를 발급합니다. 마지막으로 루트 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. 가능한 경우 자동 인증서 갱신 구현:
+ 통합된 AWS 관리형 서비스와 함께 ACM에서 발급한 인증서에 대해 [ACM 관리형 갱신](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html)을 사용합니다.
1. 로깅 및 감사 트레일 설정:
+ [CloudTrail 로그](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(워크숍)](https://www.youtube.com/watch?v=XrrdyplT3PE)
**관련 예제:**
+ [Private CA 워크숍](https://catalog.workshops.aws/certificatemanager/en-US/introduction)
+ [IOT Device Management 워크숍](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 전송 중 암호화 적용
조직, 법률 및 규정 준수 요구 사항을 충족할 수 있도록 조직의 정책, 규제 의무 및 표준에 따라 정의된 암호화 요구 사항을 적용합니다. 민감한 데이터를 Virtual Private Cloud(VPC) 외부로 전송할 때 암호화된 프로토콜만 사용합니다. 암호화는 데이터가 신뢰할 수 없는 네트워크로 전송되는 경우에도 데이터 기밀성을 유지하는 데 도움이 됩니다.
**원하는 성과:** 데이터에 대한 무단 액세스를 완화하기 위해 리소스와 인터넷 간의 네트워크 트래픽을 암호화합니다. 보안 요구 사항에 따라 내부 AWS 환경 내에서 네트워크 트래픽을 암호화합니다. 보안 TLS 프로토콜 및 암호 세트를 사용하여 전송 중 데이터를 암호화합니다.
**일반적인 안티 패턴:**
+ 사용 중단된 버전의 SSL, TLS 및 암호 그룹 구성 요소(예: SSL v3.0, 1024비트 RSA 키 및 RC4 암호)를 사용합니다.
+ 퍼블릭 리소스에서 암호화되지 않은(HTTP) 트래픽을 허용합니다.
+ 만료되기 전에 X.509 인증서를 모니터링하고 교체하지 않습니다.
+ TLS에 자체 서명된 X.509 인증서를 사용합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 높음
## 구현 가이드
AWS 서비스는 통신에 TLS를 사용하는 HTTPS 엔드포인트를 제공하여 AWS API와 통신할 때 전송 중 암호화 기능을 제공합니다. 안전하지 않은 HTTP 프로토콜은 보안 그룹을 사용하여 가상 프라이빗 클라우드(VPC)에서 감사 및 차단할 수 있습니다. HTTP 요청은 [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https-viewers-to-cloudfront.html)의 HTTPS로나 [Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions)에서 자동으로 리디렉션될 수도 있습니다. [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에서 보안 프로토콜 구성:** 클러스터가 [보안 소켓 계층(SSL) 또는 전송 계층 보안(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) 계층 구조를 생성하여 암호화된 TLS 채널을 생성하는 데 사용할 수 있는 최종 엔터티 X.509 인증서를 발급할 수 있습니다.
## 리소스
**관련 문서:**
+ [ 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 네트워크 통신 인증
전송 계층 보안(TLS) 또는 IPsec과 같은 인증을 지원하는 프로토콜을 사용하여 통신의 자격 증명을 확인합니다.
서비스, 애플리케이션 또는 사용자 간에 통신할 때마다 안전하고 인증된 네트워크 프로토콜을 사용하도록 워크로드를 설계합니다. 인증 및 권한 부여를 지원하는 네트워크 프로토콜을 사용하면 네트워크 흐름을 더 강력하게 제어할 수 있고 무단 액세스의 영향을 줄일 수 있습니다.
**원하는 성과:** 서비스 간 트래픽 흐름이 잘 정의된 데이터 영역 및 컨트롤 플레인 트래픽 흐름을 보유한 워크로드. 트래픽 흐름은 기술적으로 가능한 경우 인증되고 암호화된 네트워크 프로토콜을 사용합니다.
**일반적인 안티 패턴:**
+ 암호화되지 않았거나 인증되지 않은 트래픽이 워크로드 내에 흐릅니다.
+ 여러 사용자 또는 엔터티가 인증 자격 증명을 재사용합니다.
+ 액세스 제어 메커니즘으로 네트워크 제어에만 의존합니다.
+ 업계 표준 인증 메커니즘에 의존하지 않고 사용자 지정 인증 메커니즘을 구축합니다.
+ 서비스 구성 요소 또는 VPC의 다른 리소스 간에 지나치게 허용적인 트래픽이 흐릅니다.
**이 모범 사례 확립의 이점:**
+ 무단 액세스의 영향 범위를 워크로드의 한 부분으로 제한합니다.
+ 작업이 인증된 엔터티에 의해서만 수행되도록 더 높은 수준의 보장을 제공합니다.
+ 의도된 데이터 전송 인터페이스를 명확하게 정의하고 적용함으로써 서비스의 분리를 개선합니다.
+ 요청 어트리뷰션 및 잘 정의된 통신 인터페이스를 통해 모니터링, 로깅 및 인시던트 대응을 개선합니다.
+ 네트워크 제어와 인증 및 권한 제어를 결합하여 워크로드에 대한 심층 방어를 제공합니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 낮음
## 구현 가이드
워크로드의 네트워크 트래픽 패턴은 두 가지 범주로 분류할 수 있습니다.
+ *동서 트래픽*은 워크로드를 구성하는 서비스 간의 트래픽 흐름을 나타냅니다.
+ *남북 트래픽*은 워크로드와 소비자 간의 트래픽 흐름을 나타냅니다.
남북 트래픽을 암호화하는 것이 일반적이지만 인증된 프로토콜을 사용하여 동서 트래픽을 보호하는 것은 흔하지 않습니다. 최신 보안 관행에서는 네트워크 설계만으로는 두 엔터티 간에 신뢰할 수 있는 관계를 부여하지 않을 것을 권장합니다. 두 서비스가 공통 네트워크 경계 내에 있을 수 있는 경우에도 이러한 서비스 간의 통신을 암호화 및 인증하고 권한을 부여하는 것이 가장 좋습니다.
예를 들어, AWS 서비스 API는 요청이 시작된 네트워크와 상관없이 [AWS Signature Version 4(SigV4)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-signing.html) 서명 프로토콜을 사용하여 호출자를 인증합니다. 이 인증을 통해 AWS API는 작업을 요청한 자격 증명을 확인할 수 있으며, 그런 다음 해당 자격 증명을 정책과 결합하여 권한 부여 결정을 내려 작업의 허용 여부를 결정할 수 있습니다.
[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 서명 프로토콜을 사용하여 자체 워크로드의 동서 트래픽에 인증 및 권한 부여를 추가할 수 있습니다. AWS 환경 외부의 리소스가 SigV4 기반 인증 및 권한 부여가 필요한 서비스와 통신해야 하는 경우 AWS 이외 리소스에서 [AWS Identity and Access Management(IAM) Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 사용하여 임시 AWS 자격 증명을 얻을 수 있습니다. 이러한 자격 증명을 사용하여 액세스 권한 부여에 SigV4를 사용하는 서비스에 대한 요청에 서명할 수 있습니다.
동서 트래픽을 인증하는 또 다른 일반적인 메커니즘은 TLS 상호 인증(mTLS)입니다. 많은 사물 인터넷(IoT), B2B 애플리케이션 및 마이크로서비스는 mTLS를 사용하여 클라이언트 및 서버 측 X.509 인증서를 모두 사용하여 TLS 통신 양측의 자격 증명을 확인합니다. 이러한 인증서는 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 및 OIDC(OpenID Connect)는 일반적으로 사용자의 서비스 액세스를 제어하는 데 사용되는 프로토콜이지만 이제는 서비스 간 트래픽에서도 널리 사용되고 있습니다. 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 기능을 고려합니다. 네트워크 경계가 유일한 보안 제어가 되어서는 안 되지만, 네트워크 경계는 워크로드를 보호하기 위한 심층 방어 전략의 한 계층을 제공합니다.
+ [보안 그룹](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를 사용하여 서비스와 통합할 때는 [JWT 권한 부여자를 사용하여 API Gateway](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 Security Incident Response Guide](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 Security Incident Response Guide ](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 워크숍 ](https://catalog.us-east-1.prod.workshops.aws/workshops/9e543f60-e409-43d4-b37f-78ff3e1a07f5/en-US)
+ [ 제로 트러스트 에피소드 1 - The Phantom Service Perimeter 워크숍 ](https://catalog.us-east-1.prod.workshops.aws/workshops/dc413216-deab-4371-9e4a-879a4f14233d/en-US)