기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
워크로드 OU — 애플리케이션 계정
| 간단한 설문조사를 |
다음 다이어그램은 애플리케이션 계정에 구성된 AWS 보안 서비스 (애플리케이션 자체 포함) 를 보여줍니다.
애플리케이션 계정은 엔터프라이즈 애플리케이션을 실행하고 유지 관리하기 위한 기본 인프라 및 서비스를 호스팅합니다. 애플리케이션 계정과 워크로드 OU는 몇 가지 기본 보안 목표를 제공합니다. 먼저 각 애플리케이션에 대해 별도의 계정을 만들어 워크로드 간의 경계와 제어를 제공하여 역할, 권한, 데이터 및 암호화 키가 뒤섞이는 문제를 방지할 수 있습니다. 다른 사람에게 영향을 주지 않으면서 애플리케이션 팀에 자체 인프라를 관리할 수 있는 광범위한 권한을 부여할 수 있는 별도의 계정 컨테이너를 제공하고자 합니다. 다음으로 보안 운영 팀이 보안 데이터를 모니터링하고 수집할 수 있는 메커니즘을 제공하여 보호 계층을 추가합니다. 보안 팀이 구성하고 모니터링하는 계정 보안 서비스 (Amazon, AWS GuardDuty Config, AWS Security Hub, Amazon, EventBridge AWS IAM 액세스 분석기) 의 조직 추적 및 로컬 배포를 활용하십시오. 마지막으로, 기업이 중앙에서 제어를 설정할 수 있도록 합니다. 애플리케이션 계정을 적절한 서비스 권한, 제약 조건 및 가드레일을 상속하는 Workloads OU의 구성원으로 만들어 애플리케이션 계정을 보다 광범위한 보안 구조에 맞춥니다.
설계 고려 사항
-
조직에 비즈니스 애플리케이션이 두 개 이상 있을 가능성이 높습니다. 워크로드 OU는 프로덕션 및 비프로덕션 환경을 포함하여 대부분의 비즈니스별 워크로드를 수용하기 위한 것입니다. 이러한 워크로드는 상용 off-the-shelf (COTS) 애플리케이션과 자체 개발한 사용자 지정 애플리케이션 및 데이터 서비스를 혼합한 것일 수 있습니다. 다양한 비즈니스 애플리케이션을 개발 환경과 함께 구성하는 패턴은 거의 없습니다. 한 가지 패턴은 프로덕션, 스테이징, 테스트 및 개발과 같은 개발 환경을 기반으로 여러 하위 OU를 두고 서로 다른 애플리케이션과 관련된 OU 아래에 별도의 하위 AWS 계정을 사용하는 것입니다. 또 다른 일반적인 패턴은 애플리케이션당 별도의 하위 OU를 만든 다음 개별 개발 환경에 대해 별도의 하위 AWS 계정을 사용하는 것입니다. 정확한 OU 및 계정 구조는 애플리케이션 설계와 해당 애플리케이션을 관리하는 팀에 따라 달라집니다. OU에서 SCP로 구현하는 것이 더 쉽기 때문에 환경별 제어이든 응용 프로그램별 제어이든 적용하려는 보안 제어를 고려하십시오. 워크로드 지향 OU 구성에 대한 추가 고려 사항은 AWS 백서 “여러 계정을 사용한 AWS 환경 구성” 중 “워크로드 지향 OU 구성” 섹션을 참조하십시오.
애플리케이션 VPC
애플리케이션 계정의 가상 사설 클라우드 (VPC) 에는 인바운드 액세스 (모델링 중인 단순 웹 서비스용) 와 아웃바운드 액세스 (애플리케이션 요구 사항 또는 AWS 서비스 요구 사항) 가 모두 필요합니다. 기본적으로 VPC 내부의 리소스는 서로 라우팅할 수 있습니다. 프라이빗 서브넷은 두 개가 있습니다. 하나는 EC2 인스턴스 (애플리케이션 계층) 를 호스팅하기 위한 것이고 다른 하나는 Amazon Aurora (데이터베이스 계층) 를 호스팅하기 위한 것입니다. 애플리케이션 계층 및 데이터베이스 계층과 같은 서로 다른 계층 간의 네트워크 분할은 VPC 보안 그룹을 통해 이루어지며, VPC 보안 그룹은 인스턴스 수준에서 트래픽을 제한합니다. 복원력을 위해 워크로드는 2개 이상의 가용 영역에 걸쳐 있으며 영역당 2개의 서브넷을 사용합니다.
설계 고려 사항
-
트래픽 미러링을 사용하여 EC2 인스턴스의 Elastic network 인터페이스에서 네트워크 트래픽을 복사할 수 있습니다. 그런 다음 콘텐츠 검사, 위협 모니터링 또는 문제 out-of-band 해결을 위해 트래픽을 보안 및 모니터링 어플라이언스로 보낼 수 있습니다. 예를 들어 VPC에서 나가는 트래픽 또는 소스가 VPC 외부에 있는 트래픽을 모니터링할 수 있습니다. 이 경우 VPC 내에서 전달되는 트래픽을 제외한 모든 트래픽을 미러링하여 단일 모니터링 어플라이언스로 전송합니다. Amazon VPC 흐름 로그는 미러링된 트래픽을 캡처하지 않으며, 일반적으로 패킷 헤더의 정보만 캡처합니다. 트래픽 미러링을 사용하면 페이로드를 포함한 실제 트래픽 콘텐츠를 분석할 수 있어 네트워크 트래픽에 대한 심층적인 통찰력을 얻을 수 있습니다. 민감한 워크로드의 일부로 작동하거나 문제 발생 시 자세한 진단이 필요할 것으로 예상되는 EC2 인스턴스의 Elastic network 인터페이스에만 트래픽 미러링을 활성화하십시오.
VPC 엔드포인트
VPC 엔드포인트는 확장성 및 안정성뿐만 아니라 또 다른 보안 제어 계층을 제공합니다. 이를 사용하여 애플리케이션 VPC를 다른 AWS 서비스에 연결할 수 있습니다. (애플리케이션 계정에서 AWS SRA는 AWS KMS, AWS Systems Manager 및 Amazon S3용 VPC 엔드포인트를 사용합니다.) 엔드포인트는 가상 디바이스입니다. 수평으로 확장된 고가용성 중복 VPC 구성 요소입니다. 네트워크 트래픽에 가용성 위험이나 대역폭 제약을 발생시키지 않고 VPC의 인스턴스와 서비스 간에 통신할 수 있습니다. VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결 없이 VPC를 지원되는 AWS 서비스 및 PrivateLink AWS에서 제공하는 VPC 엔드포인트 서비스에 비공개로 연결할 수 있습니다. VPC의 인스턴스는 다른 AWS 서비스와 통신하는 데 퍼블릭 IP 주소가 필요하지 않습니다. VPC와 다른 AWS 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다.
VPC 엔드포인트를 사용할 때 얻을 수 있는 또 다른 이점은 엔드포인트 정책을 구성할 수 있다는 것입니다. VPC 엔드포인트 정책은 엔드포인트를 만들거나 수정 시 엔드포인트에 연결하는 IAM 리소스 정책입니다. 엔드포인트를 생성할 때 IAM 정책을 연결하지 않으면 AWS는 서비스에 대한 전체 액세스를 허용하는 기본 IAM 정책을 자동으로 연결합니다. 엔드포인트 정책은 IAM 정책 또는 서비스별 정책 (예: S3 버킷 정책) 을 재정의하거나 대체하지 않습니다. 이는 엔드포인트에서 지정된 서비스로의 액세스를 제어하기 위한 별도의 IAM 정책입니다. 이러한 방식으로 어떤 AWS 보안 주체가 리소스 또는 서비스와 통신할 수 있는지에 대한 또 다른 제어 계층을 추가합니다.
Amazon EC2
애플리케이션을 구성하는 Amazon EC2
별도의 VPC (계정 경계의 하위 집합) 를 사용하여 워크로드 세그먼트별로 인프라를 분리하십시오. 서브넷을 사용하여 단일 VPC 내의 애플리케이션 티어(예: 웹, 애플리케이션 및 데이터베이스)를 격리합니다. 인터넷에서 직접 액세스하면 안 되는 경우 프라이빗 서브넷을 인스턴스에 사용합니다. 인터넷 게이트웨이를 사용하지 않고 프라이빗 서브넷에서 Amazon EC2 API를 호출하려면 AWS를 사용하십시오. PrivateLink 보안 그룹을 사용하여 인스턴스에 대한 액세스를 제한하십시오. VPC 흐름 로그를 사용하여 인스턴스에 도달하는 트래픽을 모니터링합니다. AWS Systems Manager의 기능인 세션 관리자를 사용하면 인바운드 SSH 포트를 열고 SSH 키를 관리하는 대신 원격으로 인스턴스에 액세스할 수 있습니다. 운영 체제와 데이터에 대해 별도의 Amazon Elastic Block Store (Amazon EBS) 볼륨을 사용하십시오. 생성한 새 EBS 볼륨 및 스냅샷 사본의 암호화를 적용하도록 AWS 계정을 구성할 수 있습니다.
구현 예제
AWS SRA 코드 라이브러리는
Application Load Balancers
애플리케이션 로드 밸런서는
AWS Certificate Manager (ACM) 는 기본적으로 애플리케이션 로드 밸런서와 통합되며, AWS SRA는 ACM을 사용하여 필요한 X.509 (TLS 서버) 공인 인증서를 생성하고 관리합니다. Application Load Balancer 보안 정책을 통해 프런트 엔드 연결에 TLS 1.2 및 강력한 암호를 적용할 수 있습니다. 자세한 내용은 Elastic Load Balancing 설명서를 참조하세요.
설계 고려 사항
-
Application Load Balancer의 사설 TLS 인증서가 필요한 내부 애플리케이션과 같은 일반적인 시나리오의 경우 이 계정 내에서 ACM을 사용하여 사설 인증서를 생성할 수 있습니다. AWS Private CA AWS SRA에서 ACM 루트 사설 CA는 보안 도구 계정에서 호스팅되며, 보안 도구 계정 섹션의 앞부분에 설명된 대로 전체 AWS 조직 또는 특정 AWS 계정과 공유하여 최종 엔티티 인증서를 발급할 수 있습니다.
-
공인 인증서의 경우 ACM을 사용하여 해당 인증서를 생성하고 관리할 수 있습니다 (자동 교체 포함). 또는 SSL/TLS 도구를 사용하여 인증서 서명 요청 (CSR) 을 생성하고, 인증 기관 (CA) 의 CSR 서명을 받아 인증서를 생성한 다음, 인증서를 ACM으로 가져오거나 Application Load Balancer와 함께 사용할 수 있도록 IAM에 인증서를 업로드하여 자체 인증서를 생성할 수 있습니다. 인증서를 ACM으로 가져오는 경우 인증서의 만료 날짜를 모니터링하고 만료되기 전에 갱신해야 합니다.
-
추가 방어 계층을 위해 AWS WAF 정책을 배포하여 Application Load Balancer를 보호할 수 있습니다. 엣지 정책, 애플리케이션 정책, 심지어 프라이빗 또는 내부 정책 적용 계층까지 갖추면 통신 요청의 가시성이 향상되고 통합된 정책 시행이 가능합니다. 자세한 내용은 AWS WAF용 AWS 관리형 규칙을 사용한 심층 방어 배포라는
블로그 게시물을 참조하십시오.
AWS Private CA
AWS Private Certificate Authority(AWS Private CA) 는 애플리케이션 계정에서 Application Load Balancer와 함께 사용할 사설 인증서를 생성하는 데 사용됩니다. 애플리케이션 로드 밸런서가 TLS를 통해 보안 콘텐츠를 제공하는 것은 일반적인 시나리오입니다. 이를 위해서는 애플리케이션 로드 밸런서에 TLS 인증서를 설치해야 합니다. 내부용으로만 구성된 애플리케이션의 경우 사설 TLS 인증서가 보안 채널을 제공할 수 있습니다.
AWS SRA에서는 보안 도구 계정에서 AWS Private CA 호스팅되며 AWS RAM을 사용하여 애플리케이션 계정과 공유됩니다. 이를 통해 애플리케이션 계정의 개발자는 공유 사설 CA에 인증서를 요청할 수 있습니다. 조직 전체 또는 AWS 계정 간에 CA를 공유하면 모든 AWS 계정에서 중복 CA를 생성하고 관리하는 데 드는 비용과 복잡성을 줄이는 데 도움이 됩니다. ACM을 사용하여 공유 CA에서 사설 인증서를 발급하는 경우 인증서는 요청 계정에서 로컬로 생성되며 ACM은 전체 수명 주기 관리 및 갱신을 제공합니다.
Amazon Inspector
AWS SRA는 Amazon Inspector를 사용하여 Amazon
Amazon Inspector는 이 계정의 EC2 인스턴스에 취약성 관리 서비스를 제공하기 때문에 애플리케이션 계정에 배치됩니다. 또한 Amazon Inspector는 EC2 인스턴스로 들어오고 나가는 원치 않는 네트워크 경로를 보고합니다.
멤버 계정의 Amazon Inspector는 위임된 관리자 계정을 통해 중앙에서 관리됩니다. AWS SRA에서 보안 도구 계정은 위임된 관리자 계정입니다. 위임된 관리자 계정은 조사 결과 데이터 및 조직 구성원의 특정 설정을 관리할 수 있습니다. 여기에는 모든 회원 계정에 대한 집계된 결과 세부 정보 보기, 회원 계정 스캔 활성화 또는 비활성화, AWS 조직 내 스캔한 리소스 검토 등이 포함됩니다.
설계 고려 사항
-
AWS Systems Manager의 기능인 패치 관리자를 사용하여 온디맨드 패치를 트리거하여 Amazon Inspector 제로데이 또는 기타 중요한 보안 취약성을 해결할 수 있습니다. Patch Manager를 사용하면 일반적인 패치 일정을 기다릴 필요 없이 이러한 취약성을 패치할 수 있습니다. 문제 해결은 Systems Manager 자동화 런북을 사용하여 수행됩니다. 자세한 내용은 두 부분으로 구성된 블로그 시리즈 Amazon Inspector와 AWS Systems Manager를 사용하여 AWS에서 취약성 관리 및 해결을 자동화하십시오
.
아마존 시스템 관리자
AWS Systems Manager는
이러한 일반 자동화 기능 외에도 Systems Manager는 다양한 예방, 탐지 및 대응 보안 기능을 지원합니다. AWS Systems Manager 에이전트 (SSM 에이전트) 는 EC2 인스턴스, 온 프레미스 서버 또는 가상 머신 (VM) 에 설치 및 구성할 수 있는 Amazon 소프트웨어입니다. SSM Agent를 사용하면 Systems Manager가 이러한 리소스를 업데이트, 관리 및 구성할 수 있습니다. Systems Manager를 사용하면 이러한 관리형 인스턴스를 검사하여 패치, 구성 및 사용자 지정 정책에서 탐지된 위반 사항을 보고 (또는 수정 조치) 함으로써 보안 및 규정 준수를 유지할 수 있습니다.
AWS SRA는 Systems Manager의 기능인 세션 관리자를 사용하여 대화형 브라우저 기반 셸 및 CLI 환경을 제공합니다. 이를 통해 인바운드 포트를 열거나 배스천 호스트를 유지 관리하거나 SSH 키를 관리할 필요 없이 안전하고 감사 가능한 인스턴스 관리가 가능합니다. AWS SRA는 Systems Manager의 기능인 패치 관리자를 사용하여 운영 체제와 애플리케이션 모두의 EC2 인스턴스에 패치를 적용합니다.
또한 AWS SRA는 Systems Manager의 기능인 자동화를 사용하여 Amazon EC2 인스턴스 및 기타 AWS 리소스의 일반적인 유지 관리 및 배포 작업을 간소화합니다. 자동화를 통해 노드 한 개 이상에 대한 상태 변경(승인 자동화 사용), 일정에 따른 노드 상태 관리와 같은 일반 IT 태스크를 간소화할 수 있습니다. Systems Manager에는 태그를 사용해 대규모 인스턴스 그룹을 대상으로 설정하는 기능과 사용자가 정의한 한계에 따라 변경 사항을 롤아웃하는 작업을 지원하는 속도 제어 기능이 있습니다. 자동화는 골든 Amazon 머신 이미지 (AMI) 생성 및 연결할 수 없는 EC2 인스턴스 복구와 같은 복잡한 작업을 간소화하는 원클릭 자동화를 제공합니다. 또한 IAM 역할에 권한을 직접 부여하지 않고도 특정 기능을 수행할 수 있는 특정 런북에 대한 액세스 권한을 부여하여 운영 보안을 강화할 수 있습니다. 예를 들어, 패치 업데이트 후 IAM 역할에 특정 EC2 인스턴스를 다시 시작할 수 있는 권한을 부여하고 싶지만 해당 역할에 권한을 직접 부여하고 싶지 않은 경우, 대신 자동화 런북을 생성하고 해당 역할에 런북을 실행만 할 수 있는 권한을 부여하면 됩니다.
설계 고려 사항
-
Systems Manager는 올바르게 작동하기 위해 EC2 인스턴스 메타데이터를 사용합니다. Systems Manager는 인스턴스 메타데이터 서비스 (IMDSv1 및 IMDSv2) 의 버전 1 또는 버전 2를 사용하여 인스턴스 메타데이터에 액세스할 수 있습니다.
-
SSM 에이전트는 Amazon EC2 메시지, Systems Manager, Amazon S3와 같은 다양한 AWS 서비스 및 리소스와 통신해야 합니다. 이러한 통신을 위해서는 서브넷에 아웃바운드 인터넷 연결 또는 적절한 VPC 엔드포인트의 프로비저닝이 필요합니다. AWS SRA는 SSM 에이전트의 VPC 엔드포인트를 사용하여 다양한 AWS 서비스에 대한 프라이빗 네트워크 경로를 설정합니다.
-
Automation을 사용하여 조직의 나머지 부서와 모범 사례를 공유할 수 있습니다. Runbook에서 리소스 관리에 대한 모범 사례를 생성하고 AWS 리전 및 그룹 간에 런북을 공유할 수 있습니다. 또한 런북 파라미터의 허용 값을 제한할 수 있습니다. 이러한 사용 사례의 경우 보안 도구 또는 공유 서비스와 같은 중앙 계정에서 자동화 런북을 생성하여 다른 AWS 조직과 공유해야 할 수 있습니다. 일반적인 사용 사례에는 패치 및 보안 업데이트를 중앙에서 구현하고, VPC 구성 또는 S3 버킷 정책의 편차를 해결하고, 대규모 EC2 인스턴스를 관리하는 기능이 포함됩니다. 구현 세부 정보는 Systems Manager 설명서를 참조하십시오.
Amazon Aurora
AWS SRA에서는 Amazon Aurora와 Amazon
설계 고려 사항
-
많은 데이터베이스 서비스에서와 마찬가지로 Aurora의 보안은 세 가지 수준에서 관리됩니다. Aurora DB 클러스터 및 DB 인스턴스에서 Amazon RDS (Amazon 관계형 데이터베이스 서비스) 관리 작업을 수행할 수 있는 사용자를 제어하려면 IAM을 사용합니다. VPC에 있는 Aurora DB 클러스터용 DB 인스턴스의 클러스터 엔드포인트 및 포트에 대한 연결을 열 수 있는 디바이스와 EC2 인스턴스를 제어하려면 VPC 보안 그룹을 사용합니다. Aurora DB 클러스터의 로그인 및 권한을 인증하려면 MySQL 또는 PostgreSQL의 독립 실행형 DB 인스턴스와 동일한 접근 방식을 사용하거나 Aurora MySQL 호환 에디션용 IAM 데이터베이스 인증을 사용할 수 있습니다. 후자의 접근 방식에서는 IAM 역할과 인증 토큰을 사용하여 Aurora MySQL 호환 DB 클러스터를 인증합니다.
Amazon S3
Amazon S3는
AWS KMS
AWS SRA는 KMS 키가 암호화할 리소스와 동일한 AWS 계정 내에 있는 키 관리를 위한 권장 배포 모델을 보여줍니다. 이러한 이유로 AWS KMS는 보안 도구 계정에 포함되는 것 외에도 애플리케이션 계정에서도 사용됩니다. 애플리케이션 계정에서 AWS KMS는 애플리케이션 리소스별 키를 관리하는 데 사용됩니다. 키 정책을 사용하여 로컬 애플리케이션 역할에 키 사용 권한을 부여하고 관리 및 모니터링 권한을 키 관리자로 제한함으로써 업무 분리를 구현할 수 있습니다.
설계 고려 사항
-
분산 모델에서 AWS KMS 키 관리 책임은 애플리케이션 팀에 있습니다. 하지만 중앙 보안 팀이 다음과 같은 중요한 암호화 이벤트의 거버넌스 및 모니터링을 담당할 수 있습니다.
-
KMS 키의 가져온 키 구성 요소의 만료 날짜가 가까워졌습니다.
-
KMS 키의 키 구성 요소가 자동으로 교체되었습니다.
-
KMS 키가 삭제되었습니다.
-
복호화 실패율이 높습니다.
-
AWS CloudHSM
AWS CloudHSM은 AWS 클라우드에서
설계 고려 사항
-
FIPS 140-2 레벨 3에 대한 엄격한 요구 사항이 있는 경우, 네이티브 KMS 키 스토어를 사용하는 대신 CloudHSM 클러스터를 사용자 지정 키 스토어로 사용하도록 AWS KMS를 구성할 수도 있습니다. 이렇게 하면 KMS 키를 보호하는 HSM에 대한 책임을 지는 동시에 데이터를 암호화하는 AWS 서비스와 AWS KMS의 통합 혜택을 누릴 수 있습니다. 이를 통해 제어할 수 있는 단일 테넌트 HSM과 AWS KMS의 사용 편의성 및 통합이 결합됩니다. CloudHSM 인프라를 관리하려면 공개 키 인프라 (PKI) 를 사용하고 HSM 관리 경험이 있는 팀이 있어야 합니다.
AWS Secrets Manager
AWS Secrets Manager를
Secrets Manager를 사용하면 세분화된 IAM 정책 및 리소스 기반 정책을 사용하여 비밀에 대한 액세스를 관리할 수 있습니다. AWS KMS를 사용하여 관리하는 암호화 키로 암호를 암호화하여 보안을 강화할 수 있습니다. 또한 Secrets Manager는 중앙 집중식 감사를 위해 AWS 로깅 및 모니터링 서비스와 통합됩니다.
Secrets Manager는 AWS KMS 키 및 데이터 키를 사용한 봉투 암호화를 사용하여 각 비밀 값을 보호합니다. 시크릿을 생성할 때 AWS 계정 및 리전에서 원하는 대칭 고객 관리 키를 선택하거나 Secrets Manager용 AWS 관리 키를 사용할 수 있습니다.
가장 좋은 방법은 암호를 모니터링하여 변경 내용을 기록하는 것입니다. 이렇게 하면 예상치 못한 사용 또는 변경 사항을 조사할 수 있습니다. 원하지 않는 변경 사항은 롤백할 수 있습니다. Secrets Manager는 현재 조직과 활동을 모니터링할 수 있는 두 가지 AWS 서비스, 즉 CloudTrail AWS와 AWS Config를 지원합니다. CloudTrail Secrets Manager 콘솔에서의 호출 및 Secrets Manager API에 대한 코드 호출을 포함하여 Secrets Manager에 대한 모든 API 호출을 이벤트로 캡처합니다. 또한 AWS 계정에 보안 또는 규정 준수에 영향을 미치거나 운영 문제를 해결하는 데 도움이 될 수 있는 기타 관련 (비 API) 이벤트를 CloudTrail 캡처합니다. 여기에는 특정 시크릿 로테이션 이벤트 및 시크릿 버전 삭제가 포함됩니다. AWS Config는 Secrets Manager에서 비밀에 대한 변경 사항을 추적 및 모니터링하여 탐지 제어 기능을 제공할 수 있습니다. 이러한 변경에는 시크릿 설명, 로테이션 구성, 태그, 기타 AWS 소스와의 관계 (예: KMS 암호화 키 또는 시크릿 로테이션에 사용되는 AWS Lambda 함수) 가 포함됩니다. 또한 AWS Config로부터 구성 및 규정 준수 변경 알림을 수신하는 EventBridge Amazon이 알림 또는 수정 조치를 위해 특정 비밀 이벤트를 라우팅하도록 구성할 수 있습니다.
AWS SRA에서 Secrets Manager는 애플리케이션 계정에 위치하여 로컬 애플리케이션 사용 사례를 지원하고 사용과 비슷한 보안 정보를 관리합니다. 여기서 인스턴스 프로파일은 애플리케이션 계정의 EC2 인스턴스에 연결됩니다. 그런 다음 해당 인스턴스 프로필이 암호를 검색할 수 있도록 Secrets Manager에서 별도의 암호를 구성할 수 있습니다. 예를 들어 적절한 Active Directory 또는 LDAP 도메인에 가입하고 Aurora 데이터베이스에 액세스할 수 있습니다. Secrets Manager는 Amazon RDS와 통합되어 Amazon RDS DB 인스턴스 또는 다중 AZ DB 클러스터를 생성, 수정 또는 복원할 때 사용자 자격 증명을 관리합니다. 이렇게 하면 키 생성 및 회전을 관리할 수 있으며 코드의 하드코딩된 자격 증명을 Secrets Manager에 대한 프로그래밍 방식의 API 호출로 대체합니다.
설계 고려 사항
-
일반적으로 암호가 사용될 위치와 가장 가까운 계정에서 Secrets Manager를 구성하고 관리하십시오. 이 접근 방식은 사용 사례에 대한 현지 지식을 활용하고 애플리케이션 개발 팀에 속도와 유연성을 제공합니다. 추가 제어 계층이 적절할 수 있는 엄격하게 통제되는 정보의 경우 보안 도구 계정의 Secrets Manager를 통해 비밀을 중앙에서 관리할 수 있습니다.
Amazon Cognito
Amazon Cognito를
Amazon Cognito는 사용자 가입 및 로그인을 위한 사용자 지정 가능한 내장 UI를 제공합니다. Android, iOS 및 Amazon Cognito용 JavaScript SDK를 사용하여 앱에 사용자 가입 및 로그인 페이지를 추가할 수 있습니다. Amazon Cognito Sync는 애플리케이션 관련 사용자 데이터의 디바이스 간 동기화를 지원하는 AWS 서비스 및 클라이언트 라이브러리입니다.
Amazon Cognito는 저장 데이터와 전송 중인 데이터에 대한 다단계 인증 및 암호화를 지원합니다. Amazon Cognito 사용자 풀은 애플리케이션 내 계정에 대한 액세스를 보호하는 데 도움이 되는 고급 보안 기능을 제공합니다. 이러한 고급 보안 기능은 위험 기반 적응형 인증을 제공하고 손상된 자격 증명 사용으로부터 보호합니다.
설계 고려 사항
-
AWS Lambda 함수를 생성한 다음, 사용자 가입, 확인, AWS Lambda 트리거로 로그인 (인증) 과 같은 사용자 풀 작업 중에 해당 함수를 트리거할 수 있습니다. 인증 문제 추가, 사용자 마이그레이션 및 확인 메시지 사용자 지정을 수행할 수 있습니다. 일반적인 작업 및 사용자 흐름에 대해서는 Amazon Cognito 설명서를 참조하십시오. Amazon Cognito는 Lambda 함수를 동기적으로 호출합니다.
-
Amazon Cognito 사용자 풀을 사용하여 소규모 멀티테넌트 애플리케이션을 보호할 수 있습니다. 멀티테넌트 설계의 일반적인 사용 사례는 애플리케이션의 여러 버전 테스트를 지원하는 워크로드를 실행하는 것입니다. 멀티 테넌트 설계는 여러 데이터 집합으로 단일 애플리케이션을 테스트하는 데에도 클러스터 리소스를 완전하게 사용할 수 있도록 해준다는 점에서 유용합니다. 하지만 테넌트 수와 예상 볼륨이 관련 Amazon Cognito 서비스 할당량과 일치하는지 확인하십시오. 이러한 할당량은 애플리케이션의 모든 테넌트 간에 공유됩니다.
Amazon Verified Permissions
Amazon 검증 권한은 사용자가
API를 통해 애플리케이션을 서비스에 연결하여 사용자 액세스 요청을 승인할 수 있습니다. 각 권한 부여 요청에 대해 서비스는 관련 정책을 검색하고 해당 정책을 평가하여 사용자, 역할, 그룹 구성원 및 속성과 같은 컨텍스트 입력을 기반으로 사용자가 리소스에 대한 작업을 수행할 수 있는지 여부를 결정합니다. 검증된 권한을 구성하고 연결하여 정책 관리 및 권한 부여 로그를 AWS로 보낼 수 CloudTrail 있습니다. Amazon Cognito를 자격 증명 저장소로 사용하는 경우 검증된 권한과 통합하여 Amazon Cognito가 반환하는 ID 및 액세스 토큰을 애플리케이션의 권한 부여 결정 시 사용할 수 있습니다. 검증된 권한에 Amazon Cognito 토큰을 제공합니다. 그러면 토큰에 포함된 속성을 사용하여 보안 주체를 나타내고 보안 주체의 권한을 식별합니다. 이 통합에 대한 자세한 내용은 Amazon 검증 권한 및 Amazon Cognito를 사용하여 세분화된 권한 부여를 간소화하는
검증된 권한은 정책 기반 액세스 제어 (PBAC) 를 정의하는 데 도움이 됩니다. PBAC는 정책으로 표현된 권한을 사용하여 누가 애플리케이션의 어떤 리소스에 액세스할 수 있는지 결정하는 액세스 제어 모델입니다. PBAC는 RBAC (역할 기반 액세스 제어) 와 ABAC (속성 기반 액세스 제어) 를 통합하여 더욱 강력하고 유연한 액세스 제어 모델을 제공합니다. PBAC에 대한 자세한 내용과 검증된 권한을 사용하여 권한 부여 모델을 설계하는 방법에 대한 자세한 내용은 AWS 블로그 게시물 Amazon 검증 권한을 사용한 애플리케이션 개발 시 정책 기반 액세스 제어를
AWS SRA에서 검증된 권한은 Amazon Cognito와의 통합을 통해 애플리케이션에 대한 권한 관리를 지원하는 애플리케이션 계정에 있습니다.
계층형 방어
애플리케이션 계정은 AWS가 지원하는 계층적 방어 원칙을 설명할 기회를 제공합니다. AWS SRA에 표시된 간단한 예제 애플리케이션의 핵심을 구성하는 EC2 인스턴스의 보안을 고려해 보면 AWS 서비스가 계층형 방어를 통해 함께 작동하는 방식을 확인할 수 있습니다. 이 접근 방식은 이 안내서 앞부분의 AWS 조직 전체에 보안 서비스 적용 섹션에서 설명한 것처럼 AWS 보안 서비스의 구조적 관점과 일치합니다.
-
가장 안쪽 계층은 EC2 인스턴스입니다. 앞서 언급한 것처럼 EC2 인스턴스에는 기본적으로 또는 옵션으로 다양한 기본 보안 기능이 포함되어 있습니다. 예로는 IMDSv2, 니트로 시스템, Amazon EBS 스토리지
암호화 등이 있습니다. -
두 번째 보호 계층은 EC2 인스턴스에서 실행되는 운영 체제와 소프트웨어에 중점을 둡니다. Amazon Inspector
및 AWS Systems Manager와 같은 서비스를 사용하면 이러한 구성을 모니터링하고 보고하고 수정 조치를 취할 수 있습니다. Inspector는 소프트웨어의 취약성을 모니터링하고 Systems Manager는 관리형 인스턴스의 패치 및 구성 상태를 검사한 다음 지정한 수정 조치를 보고하고 취함으로써 보안 및 규정 준수를 유지할 수 있도록 지원합니다. -
인스턴스와 이러한 인스턴스에서 실행되는 소프트웨어는 AWS 네트워킹 인프라와 함께 제공됩니다. Amazon VPC의 보안 기능을 사용하는 것 외에도 AWS SRA는 VPC 엔드포인트를 사용하여 VPC와 지원되는 AWS 서비스 간에 프라이빗 연결을 제공하고 네트워크 경계에 액세스 정책을 적용하는 메커니즘을 제공합니다.
-
EC2 인스턴스, 소프트웨어, 네트워크, IAM 역할 및 리소스의 활동 및 구성은 AWS Security Hub, Amazon, AWS, AWS CloudTrail Config, AWS IAM 액세스 분석기, GuardDuty Amazon Macie와 같은 AWS 계정 중심 서비스를 통해 추가로 모니터링됩니다.
-
마지막으로, AWS RAM은 애플리케이션 계정 외에도 어떤 리소스가 다른 계정과 공유되는지를 제어하는 데 도움이 되며, IAM 서비스 제어 정책은 AWS 조직 전체에 일관된 권한을 적용하는 데 도움이 됩니다.
