웹 기반 앱을 위한 다중 계층 보안

이번 글에서는 AWS에 호스팅 된 웹 애플리케이션의 여러 계층에 걸쳐 보안을 적용하는 구체적인 방법을 살펴보려고 합니다.

 

모든 계층에 보안을 적용하는 것은 AWS Well-Architected Framework의 Security Pillar가 강조하는 핵심 설계 원칙입니다. 이 원칙은 다음과 같은 모든 지점에서 보안 통제를 구현할 것을 권장합니다.

• Network Edge
• VPC
• Load Balancer
• 컴퓨팅 인스턴스 또는 서비스
• 운영체제
• 애플리케이션 및 코드

 

다계층 보안의 예시

밑에서 제시될 아키텍처의 다양한 서비스가 다음과 같은 계층에서 보안을 제공하는 데 어떻게 도움이 되는지 요약을 하겠습니다. 

1. 네트워크 엣지

2. VPC 내부

3. 로드 밸런서

4. 컴퓨팅 인스턴스

5. 운영체제 내부

 

여러 계층에 보안을 적용하기 위한 논리적 흐름도

 

1. Network Edge Security

외부 접점에서 인프라 전체를 보호하는 첫 번째 방어선입니다.

• DDoS Protection: Amazon Route 53과 AWS Shield가 대규모 가용성 공격으로부터 서비스를 보호합니다.
• Web request filtering: AWS WAF를 통해 웹 공격 패턴을 사전에 차단합니다.
• TLS encryption and request routing: AWS Certificate Manager(ACM)와 Amazon CloudFront를 통해 데이터 전송 구간을 암호화(HTTPS)하고 검증된 요청만을 내부로 전달합니다.

2. VPC & Load Balancer

네트워크 내부로 진입한 트래픽에 대한 세부적인 제어가 이루어집니다.

• Firewalled load balancer & routing rules: Application Load Balancer(ALB)와 이에 적용된 보안 그룹(Security Group)이 허용된 포트와 프로토콜만 수용하며 사전에 정의된 라우팅 규칙에 따라 트래픽을 안전하게 분산합니다.

3. Compute Instance Security

실제 로직이 실행되는 서버 계층의 보호 단계입니다.

• Firewalled instances, behind NAT: Amazon EC2 인스턴스들은 외부에서 직접 접근할 수 없는 프라이빗 서브넷에 위치하며 보안 그룹을 통해 최소한의 통신만 허용됩니다. Auto Scaling은 가용성을 보장하는 동시에 일관된 보안 설정을 유지합니다.

4. OS & Filesystem Security

애플리케이션 내부 데이터와 자원에 대한 접근 제어입니다.

• IAM access restrictions on filesystem: Amazon EFS를 사용할 때 IAM 권한을 엄격히 적용하여 인가된 프로세스나 사용자만 파일 시스템에 접근할 수 있도록 제한합니다.

5. Data Layer Security

최종적인 데이터 저장소에 대한 격리 단계입니다.

• Managed service, firewalled, network isolated: Amazon RDS는 네트워크가 완전히 격리된 환경에서 운영되며 별도의 보안 그룹 설정을 통해 데이터베이스 계층으로의 접근을 원천적으로 차단하고 관리합니다.

 

다층 구조 아키텍처 심층 분석

해당 아키텍처는 서비스가 서로 다른 AWS 리전에 어떻게 배포되는지 애플리케이션 사용자의 요청이 다양한 서비스 계층을 거쳐 어떻게 흐르는지를 보여줍니다.

이제부터 아키텍처의 각 계층을 자세히 살펴보고 각 계층에서 보안이 어떻게 추가되는지 알아보겠습니다.

Multi-layered architecture

애플리케이션 사용자의 요청은 가장 먼저 전역 계층인 us-east-1 리전의 Route 53을 통해 도메인 이름이 해석되면 AWS Shield와 AWS WAF가 네트워크 및 웹 계층의 위협을 차단하며 AWS Certificate Manager의 인증서로 암호화된 보안 통신을 Amazon CloudFront가 수신하여 전 세계 엣지 로케이션에서 요청을 처리합니다. 이렇게 검증된 오리진 요청은 실제 서버가 위치한 시드니 리전의 VPC 내부로 진입하여 각 가용 영역의 퍼블릭 서브넷에 배치된 Application Load Balancer에 도달합니다. 로드 밸런서는 허용 목록 규칙을 기반으로 트래픽을 분산합니다. 일반적인 사용자 요청은 Private Subnet의 Auto Scaling Group 내 Fleet 인스턴스로 전달하고 관리 목적의 요청은 별도의 Admin 인스턴스로 라우팅 합니다.

Private Subnet 내의 인스턴스들은 구동에 필요한 정보를 AWS Secrets Manager에서 안전하게 가져오며 애플리케이션 실행에 필요한 공통 파일은 각 가용 영역의 EFS 타겟을 거쳐 Amazon EFS와 연결됩니다. 이때 일반 인스턴스는 읽기 전용으로 파일 시스템에 접근하여 코드 변조를 방지하고 관리자 인스턴스는 쓰기 권한을 통해 업데이트를 수행합니다. 인스턴스에 필요한 외부 통신은 Public Subnet의 NAT Gateway를 통해 안전하게 처리되며 최종적인 데이터 읽기 및 쓰기 작업은 격리 서브넷에 위치한 DB Primary와의 통신으로 완성됩니다. 처리된 모든 데이터는 비즈니스 연속성을 위해 다른 가용 영역의 DB Replica로 동기식 복제가 이루어지며 데이터 계층의 전반적인 보호와 복구는 AWS Backup이 전담하여 관리합니다.

 

경계 0 - People Layer

보안은 팀 구성원과 조직의 운영 방식에서 시작됩니다. '인적 요소'가 인프라를 구축하고 관리하는 방식은 보안 태세에 상당한 영향을 미칩니다.

 

1. Automate Security Best Practices

AWS Well-Architected Framework에서 강조하는 핵심 원칙 중 하나는 '보안 모범 사례의 자동화'입니다. 이는 두 가지 측면에서 결정적인 이점을 제공합니다.

• 수동으로 작업을 수행할 경우 Misconfiguration이나 단계 누락이 발생하기 쉽습니다. 자동화는 이를 원천 차단합니다.
• 반복적인 보안 작업을 자동화함으로써 보안 담당자가 더 고도화된 위협 분석에 집중할 수 있도록 돕습니다.

2. 관리형 서비스(Managed Services) 채택을 통한 책임 전가

인적 노력을 줄이면서 보안을 강화하는 가장 단순하고 확실한 방법은 AWS가 직접 관리하는 서비스를 채택하는 것입니다.

• Amazon RDS의 사례: 직접 DB를 구축할 경우 운영체제 및 DB 엔진의 패치 작업을 사람이 직접 챙겨야 하지만 Amazon RDS를 사용하면 AWS가 이를 전담합니다.
• 최신 보안 패치가 누락될 위험을 제거하고 자동 백업 및 복구 도구를 통해 데이터 가용성을 손쉽게 확보할 수 있습니다. 이는 '사람의 실수'가 개입할 여지를 최소화하는 전략입니다.

3. 자동화된 보안 모니터링 및 통합 관리

환경이 복잡해질수록 사람이 일일이 네트워크를 감시하는 것은 불가능에 가깝습니다. AWS의 전용 보안 서비스들을 통합하여 탐지 및 대응을 자동화해야 합니다.

• AWS CloudTrail: AWS 계정 내에서 발생하는 모든 API 호출을 기록합니다. 누가, 언제, 어떤 리소스에 어떤 작업을 수행했는지 완전한 감사 추적(Audit Trail)을 제공하며 보안 사고 발생 시 포렌식의 핵심 기반이 됩니다. 모든 리전에 대해 활성화하고 로그를 S3에 장기 보관하는 것을 권장합니다.
• Amazon GuardDuty: 지능형 위협 탐지 및 네트워크 모니터링
• AWS Config: 리소스의 설정 변경 사항 기록 및 규정 준수 여부 확인
• Amazon Inspector: 애플리케이션의 소프트웨어 취약점 및 의도치 않은 네트워크 노출 탐지
• AWS Security Hub: 위 보안 서비스들의 결과를 한 곳에서 통합 관리하고 우선순위 지정

4. IaC를 통한 표준화와 가이드라인

인프라를 코드로 정의하는 IaC(Infrastructure as Code)는 인프라 구축을 자동화하는 데 사용할 수 있는 모범사례입니다.

• 인프라 정의를 AWS CodeCommit과 같은 소스 제어 시스템에 저장함으로써 누가, 언제, 왜 변경했는지에 대한 완벽한 감사 추적(Audit Trail)이 가능해집니다.
• 아키텍처가 진화함에 따라 변경 사항을 추적할 수 있으며 재해 발생 시 코드를 통해 전체 아키텍처를 신속하게 재배포할 수 있습니다.
• IaC 프로젝트에 보안 정책 검증 테스트를 통합하면 보안 가이드라인에 어긋나는 인프라가 배포되는 것을 사전에 차단할 수 있습니다.

5. Principle of Least Privilege

AWS IAM(Identity and Access Management)을 사용하여 사람과 시스템 모두에게 작업에 필요한 최소한의 권한만 부여해야 합니다.

• 특정 리소스에 대해 필요한 액션만 허용하는 세밀한 정책을 수립합니다.
• 장기 자격 증명(Access Key) 대신 임시 자격 증명을 사용합니다.
• 사용되지 않는 사용자, Role, 권한을 정기적으로 검토하여 제거합니다.
• AWS 루트 계정과 모든 IAM 사용자에게 MFA(다중 인증)를 반드시 활성화합니다. 루트 계정은 모든 AWS 리소스에 대한 무제한 접근 권한을 가지므로 MFA 없이 노출될 경우 치명적인 피해로 이어질 수 있습니다. 가능하다면 루트 계정은 초기 설정 이후 사용하지 않도록 Lock Down하는 것을 권장합니다.

 

경계 1 - Network Protections

인터넷은 공개되어 있으므로 신뢰할 수 없습니다. 따라서 위협 행위자와 네트워크 수준 공격으로 인한 위험에 적극적으로 대처해야 합니다.

 

1. AWS Shield

DDoS 공격은 서비스 가용성을 떨어뜨리는 가장 흔하고 강력한 위협입니다. AWS Shield를 네트워크 에지에 배치하여 관리형 보호 기능을 제공합니다.

• AWS Shield Standard: 모든 AWS 고객에게 추가 비용 없이 자동으로 활성화되는 기본 서비스입니다. 일반적인 네트워크 및 전송 계층에서의 DDoS 공격으로부터 인프라를 보호하도록 설계되었습니다.
• AWS Shield Advanced: 애플리케이션 계층을 노린 공격이나 더 높은 수준의 보호가 필요한 경우에 채택하는 유료 구독 서비스입니다. 공격 발생 시 전문가의 지원을 받을 수 있으며 공격으로 인한 비용 전이 방지 혜택도 제공됩니다.

2. Amazon Route 53

Amazon Route 53은 DNS 서비스로 가용성이 높은 글로벌 분산 구조를 통해 보안 기능을 수행합니다.

• 솔루션에서 사용하는 호스트 이름을 Amazon CloudFront 배포 지점에 별칭(Alias)으로 매핑합니다. 이를 통해 실제 서버의 IP 주소를 외부에 노출하지 않고도 안전하게 트래픽을 라우팅할 수 있습니다.
• DNS 공격 방어: Route 53은 유입되는 요청을 검사하여 DNS 증폭 공격(DNS Amplification Attack)과 같은 특정 유형의 DNS 공격으로부터 인프라를 보호합니다.

 

경계 2 - request processing

CloudFront는 AWS 네트워크 에지에서 작동하며 수신 요청을 캐싱, 변환하여 지연 시간이 짧은 AWS 글로벌 네트워크를 통해 관련 오리진 서비스로 전달합니다. CloudFront에 웹 요청을 캐싱함으로써 DDoS 공격으로 인한 애플리케이션 서버 과부하 위험을 더욱 줄일 수 있습니다.

이 아키텍처에서는 CloudFront를 구성하여 원본 요청에 Custom Header를 이용해 검증합니다.

• CloudFront는 오리진(로드 밸런서)으로 요청을 보낼 때 헤더 내에 Shared Secret를 추가합니다.
• 로드 밸런서는 요청을 받을 때 이 헤더가 있는지 확인합니다. 이 Shared Secret는 반드시 AWS Secrets Manager에 저장하여 관리해야 하며 정기적인 자동 교체(Rotation) 정책을 설정해 노출 위험을 최소화하는 것이 중요합니다. Secret을 코드나 환경 변수에 하드코딩하는 방식은 보안 위협이 될 수 있습니다.

트래픽이 CloudFront를 거치면 로드 밸런서 입장에서는 접속자 IP가 CloudFront의 IP로 보이게 됩니다. 이를 해결하기 위해 CloudFront Function을 활용합니다.

• CloudFront Function이 원래 사용자의 실제 IP 주소를 또 다른 맞춤형 헤더에 복사하여 전달합니다. 이를 통해 보안 로그 분석이나 이후 IP 차단 시 실제 공격자를 정확히 식별할 수 있습니다.

AWS WAF(Web Application Firewall)는 SQL 인젝션, XSS과 같이 잘 알려진 웹 취약점 공격을 CloudFront 단계에서 즉시 차단합니다.

• AWS Managed Rules: 최신 위협에 맞춰 미리 구성해둔 관리형 규칙을 적용합니다. 이를 통해 별도의 복잡한 설정 없이도 수준 높은 보안 수준을 유지할 수 있으며 필요에 따라 사용자 정의 규칙(Custom Rules)을 추가할 수도 있습니다.
• IP CIDR 제한: 특정 IP 대역에서만 프론트엔드에 접근할 수 있도록 IP 제한 규칙을 설정하여 인가되지 않은 네트워크로부터의 접근을 원천적으로 차단합니다.

 

경계 3 - VPC

CloudFront와 AWS WAF가 요청을 확인한 후 CloudFront는 해당 요청을 VPC내의 컴퓨팅 서비스로 전달합니다. VPC는 ​​AWS 계정 내에서 논리적으로 격리된 네트워크로 출입이 허용되는 네트워크 트래픽을 제어하는 ​​데 사용할 수 있습니다. 인터넷으로 직접 연결되거나 인터넷에서 직접 연결될 수 없는 Private IPv4 CIDR 블록을 사용하도록 함으로써 AWS 리소스 주변에 네트워크 경계를 생성합니다.

Amazon EC2 인스턴스들은 VPC 내의 Private Subnet에 호스팅 되고 인터넷에서 들어오는 트래픽이 차단됩니다. 소프트웨어 업데이트 등 필요한 경우에만 NAT 게이트웨이를 경유하여 외부로 나가는 아웃바운드 요청만 허용합니다.

Amazon RDS 데이터베이스 인스턴스는 인바운드뿐만 아니라 아웃바운드 인터넷 접속까지도 격리된 서브넷에 호스팅합니다. RDS는 관리형 서비스이므로 이러한 고립된 환경에서도 AWS가 보안 패치와 소프트웨어 업데이트를 대신 관리해 줍니다.

프라이빗 서브넷의 자원이 AWS의 다른 서비스와 통신하려면 인터넷 망을 거쳐야 하지만 이 아키텍처에서는 Interface VPC Endpoint(AWS PrivateLink)를 활용합니다.

• AWS Secrets Manager를 마치 VPC 내부의 리소스인 것처럼 연결합니다.
• 데이터가 인터넷을 통과하지 않고 AWS 내부 네트워크망으로만 흐릅니다.

추가되면 좋을 보안 요소

1. VPC Flow Logs를 구성하여 IP 트래픽에 대한 로그를 AWS GuardDuty를 통해 예기치 못한 활동, 무단 접근 시도, 악성 활동 등을 자동으로 식별하여 관리자에게 알립니다. -> 모니터링 강화

 

애플리케이션의 구성 요소를 분할하는 다른 방법

VPC Peering으로 데이터베이스 전용 VPC를 별도로 구축하고 앱 VPC와 피어링으로 연결하여 물리적 분리 수준을 높일 수 있습니다.

 

애플리케이션의 규모와 복잡도가 커진다면?

Multi-account Strategy: 서비스별, 환경별(Dev/Prod)로 AWS 계정을 분리하여 논리적 경계를 만듭니다. 이때 AWS Transit Gateway로 네트워크를 통합 관리하고 AWS Network Firewall로 트래픽 제어를 수행할 수 있습니다.

 

경계 4 - Load Balancer

VPC로 요청이 전송되면 Application Load Balancer(ALB)가 이를 처리합니다. ALB는 요청을 하위 EC2 인스턴스로 분산합니다. ALB는 AWS Certificate Manager(ACM) 인증서를 사용하여 HTTPS 통신을 암호화합니다. 이때 적용되는 TLS 버전은 ALB에 설정된 Security Policy에 따라 결정되며 보안 강화를 위해 TLS 1.2 이상만 허용하는 정책(예: ELBSecurityPolicy-TLS13-1-2-2021-06)을 명시적으로 선택하는 것을 권장합니다. AWS는 현재 TLS 1.3도 지원하며 가능하다면 TLS 1.3을 우선 허용하도록 구성하는 것이 더 강력한 보안을 제공합니다.

ALB는 Security Group을 통해 인바운드 규칙을 적용합니다. 443(HTTPS) 포트만 개방하고 오직 CloudFront IP 대역에서 오는 트래픽만 허용합니다. CloudFront의 IP 범위는 수시로 변할 수 있습니다. 이를 일일이 수동으로 업데이트하는 대신 AWS가 직접 관리하는 CloudFront Prefix List를 Source로 지정함으로써 Human Error를 방지하고 보안 누수를 막습니다.

ALB는 Rules를 사용해서 요청을 대상 인스턴스로 전달할지 또는 거부할지 결정합니다.

아까 위에서 말했던 Custom Headers에 CloudFront가 삽입한 Shared Secret 헤더를 여기서 검사합니다. 만약 이 헤더가 없거나 일치하지 않는다면 CloudFront를 우회하여 로드 밸런서에 직접 접근하려는 시도로 간주하고 요청을 즉시 거부합니다.

그리고 CloudFront Function이 헤더에 담아준 사용자의 원본 IP를 분석합니다. 일반 사용자라면 표준 앱 기능을 담당하는 Fleet instance 타겟 그룹으로 전달됩니다. 관리자 권한을 가진 특정 IP 대역의 요청은 Admin instance 타겟 그룹으로 라우팅됩니다.

만약 유입된 요청이 사전에 정의된 어떤 보안 규칙이나 라우팅 규칙에도 부합하지 않는다면 ALB는 해당 요청에 대해 404(Not Found) 응답을 반환하여 내부 인프라의 존재 자체를 숨기고 무단 접근을 방어합니다.

 

경계 5 - Compute Instance Network Security

보안 그룹은 EC2 인스턴스 주변에 경계를 생성합니다. 인스턴스에 도달하는 트래픽은 보안 그룹 규칙에서 허용하는 트래픽뿐입니다. ALB만 EC2 인스턴스로의 인바운드 연결을 허용합니다.

과거에는 프라이빗 서브넷에 있는 서버를 관리하기 위해 외부로 포트를 개방하거나 별도의 관리용 서버인 Bastion Host를 운영하는 것이 일반적이었습니다. 하지만 여기에는 치명적인 리스크가 따릅니다.

원격 접속용 포트(SSH/RDP)를 인터넷에 개방해 둘 경우 원격 액세스 프로토콜의 취약점에 인스턴스가 노출될 수 있습니다.

원격 근무가 늘어남에 따라 편의를 위해 인바운드 규칙을 일시적으로 과도하게 허용했다가 이를 닫지 않고 방치하는 인적 오류가 빈번하게 발생합니다.

이러한 위험을 제거하기 위해 AWS Systems Manager Session Manager를 채택합니다. 이는 배스천 호스트나 열린 포트 없이도 서버에 안전하게 접속할 수 있는 방법입니다. 인스턴스에 설치된 SSM Agent를 통해 연결합니다.

이를 통해 SSH(22번)나 RDP(3389번) 포트를 열 필요가 없고 IAM을 통해 누가 어떤 서버에 접속할 수 있는지 통제하며 모든 접속 기록과 명령어 입력 내역을 로그로 남길 수 있습니다. 그리고 모든 연결은 일회성 암호화 세션으로 이루어지므로 보안성이 높습니다.

서버에 설치되는 모든 소프트웨어는 보안 검토의 대상이 되어야 합니다. AWS는 투명성을 위해 SSM Agent의 소스 코드를 공개하고 있습니다. 보안 및 컴플라이언스 요구 사항에 부합하는지 amazon-ssm-agent GitHub repo에서 직접 코드를 확인할 수 있습니다.

이 아키텍처의 컴퓨팅 계층은 두 개의 독립적인 Amazon EC2 Auto Scaling 그룹으로 구성되어 있습니다.

한 그룹은 관리자 요청을 처리하고, 다른 그룹은 일반 사용자 요청을 처리합니다.

두 기능을 분리함으로써 한쪽 컴포넌트에서 발생한 결함이나 보안 사고가 시스템 전체로 확산되는 것을 방지합니다. 예를 들어 일반 사용자용 서버가 과부하로 다운되더라도 관리자용 서버는 영향을 받지 않고 정상 가동되어 후속 조치를 취할 수 있습니다.

각 Auto Scaling 그룹은 Multiple Availability Zones에 걸쳐 배치됩니다.

특정 가용 영역(AZ)에 데이터 센터 화재나 정전 같은 장애가 발생하더라도 다른 AZ에 있는 인스턴스들이 즉시 서비스를 이어받아 비즈니스 연속성을 보장합니다.

데이터베이스 계층에서 Amazon RDS와 같은 관리형 서비스를 사용하면 데이터베이스 서버 인스턴스에 보안 업데이트가 사전에 적용되지 않아 발생하는 보안 문제를 예방할 수 있습니다.

직접 DB 서버를 운영할 경우 OS나 DB 엔진의 보안 패치를 놓칠 위험이 큽니다. 관리형 서비스는 AWS가 보안 업데이트를 제때 적용하도록 보장하여 패치 미비로 인한 취약점 노출 위험을 줄여줍니다.

하드웨어 장애로 인한 가동 중단이나 기반 운영체제의 관리 부실로 발생하는 보안 이슈를 최소화합니다.

 

경계 6 - Compute Instance Operating System

인스턴스를 처음 시작할 때는 운영 체제가 안전해야 하고 새로운 보안 패치가 출시되면 필요에 따라 인스턴스를 업데이트해야 합니다. EC2 Image Builder를 사용해서 서버 OS를 미리 강화하고 필요한 설정을 마친 골든 이미지를 자동 생성합니다.

실행 중인 인스턴스에 패치를 적용하는 대신 최신 보안 패치가 적용된 새로운 Amazon Machine Image(AMI)를 생성하고 기존 인스턴스를 새것으로 완전히 교체합니다.

이 방식이 가능한 이유는 애플리케이션 코드와 데이터가 인스턴스 내부가 아닌 Amazon EFS에 저장되어 있기 때문입니다. 서버를 새로 갈아 끼워도 EFS만 다시 마운트하면 데이터 유실 없이 즉시 서비스를 이어갈 수 있습니다.

서버 내부에서 다른 AWS 리소스(S3, Secrets Manager 등)에 접근해야 할 때 가장 위험한 행동은 Access Key를 서버 파일 시스템에 직접 저장(Hardcoding)하는 것입니다.

EC2 Instance profiles를 통해 인스턴스가 특정 IAM role을 Assume 설정합니다. 이 방식은 고정된 키 대신 주기적으로 갱신되는 임시 보안 토큰을 사용하여 자격 증명이 유출되더라도 피해를 최소화합니다.

서버 내부의 애플리케이션은 별도의 설정 없이도 AWS SDK를 통해 안전하게 권한을 획득하고 다른 리소스와 통신할 수 있습니다.

인스턴스에 부여되는 IAM 역할에는 오직 해당 서버가 작동하는 데 꼭 필요한 최소한의 권한만 연결합니다.

• EFS 마운트 권한: 공유 파일 시스템에 접근하기 위한 권한
• AWS Systems Manager 권한: 앞서 언급한 포트 없는 접속을 위한 권한
• Secrets Manager 접근 권한: 데이터베이스 비밀번호가 필요한 경우에만 해당 비밀에 접근할 수 있는 특정 권한을 부여합니다.

 

경계 7 - File System

Auto Scaling 그룹의 EC2 인스턴스들은 동일한 EFS를 공유하지만 각 인스턴스가 수행할 수 있는 작업은 IAM 파일 시스템 정책에 의해 통제됩니다.

IAM 정책을 통해 일반 사용자용 인스턴스가 애플리케이션의 핵심 파일을 수정하거나 삭제하는 것을 차단합니다.

이 아키텍처에서는 Mount Mode가 적용됩니다.

• 관리자 그룹 -> Read-Write 모드: 애플리케이션 자체 업데이트, 애드온 설치, 콘텐츠 업로드, 구성 변경 등 시스템의 상태를 변경해야 하는 작업을 위해 쓰기 권한을 부여합니다.
• 일반 사용자 그룹 -> Read-Only 모드: 일반 사용자에 대응되는 인스턴스들은 오직 파일을 읽기만 할 수 있습니다. 서버 내부의 보안이 뚫리더라도 해커는 읽기 전용으로 마운트된 소스 코드를 수정할 수 없습니다.

EFS를 사용하면 성능 저하가 우려될 수 있습니다. 이를 해결하기 위해 로컬 파일 캐싱 전략을 사용합니다.

일반 사용자용 인스턴스는 EFS의 파일을 로컬 Amazon EBS(Elastic Block Store) 볼륨에 캐싱합니다.

빈번하게 액세스하는 파일을 로컬에서 빠르게 불러옴으로써 성능과 확장성을 동시에 확보합니다.

 

경계 8 - Web Server Configuration

각 Amazon EC2 Auto Scaling 그룹에서 실행되는 인스턴스에 서로 다른 웹 서버 구성을 적용합니다. 이를 통해 웹 서버 계층에서 추가적인 격리 경계를 생성합니다.

관리자 인스턴스는 애플리케이션의 기본 설정을 그대로 유지하여 관리자 인터페이스에 대한 접근을 허용합니다.

이 인스턴스들은 이미 이전 단계에서 특정 관리자 IP로만 접근할 수 있도록 네트워크 수준에서 격리되어 있으므로 내부적으로는 관리 기능을 안전하게 수행할 수 있습니다.

관리자 권한이 없는 일반 사용자용 인스턴스는 관리자 관련 경로(예: WordPress의 wp-login.php 등)를 웹 서버 설정 차원에서 명시적으로 차단합니다. 외부 사용자가 관리자 페이지에 접근하려고 시도할 경우 웹 서버는 즉시 403 Forbidden 응답을 반환합니다.

 

왜 이렇게 까지 할까?

• ALB에서 이미 경로 기반 라우팅을 수행하고 있지만 웹 서버 자체에서도 한 번 더 경로를 차단함으로써 설정 실수나 제로데이 취약점으로 인한 우회 공격을 아예 막음.
• 일반 트래픽을 처리하는 수많은 서버에는 관리 기능이 비활성화된 상태가 아니라 물리적으로 도달 불가능한 상태가 되어 전체 시스템의 위협 노출 면적을 줄입니다.

 

경계 9 - Database Security

데이터베이스 계층은 두 개의 추가적인 격리 경계 내에 있습니다. Amazon RDS를 사용하며 데이터베이스 인스턴스는 격리된 서브넷에 배포됩니다. 외부 인터넷으로 나가는 아웃바운드 경로나 들어오는 인바운드 경로가 전혀 존재하지 않습니다.

오직 VPC 내부의 다른 네트워크 인터페이스(예: EC2 인스턴스)를 통해서만 접근이 가능하므로 인터넷을 통한 직접적인 공격 시도가 물리적으로 불가능한 환경입니다.

서브넷 수준의 격리에 더해 RDS Security Group이 한 번 더 트래픽을 필터링합니다.

오직 애플리케이션이 실행되는 EC2 인스턴스 그룹으로부터 오는 트래픽만 허용합니다.

데이터베이스 서비스 포트(예: MySQL의 경우 3306 등) 외의 모든 포트는 차단하여 인프라 내부에서 발생할 수 있는 잠재적인 위협 확산을 방지합니다.

IAM Database Authentication을 도입하여 보안 수준을 한 단계 더 높입니다.

고정된 데이터베이스 비밀번호를 사용하는 대신 IAM을 통해 발급받은 수명이 짧은 인증 토큰으로 접속합니다. 이는 비밀번호 유출 위험을 낮춥니다. IAM 정책을 통해 어떤 인스턴스가 어떤 데이터베이스 사용자 권한을 가질지 제어할 수 있습니다.

관리자용 인스턴스는 데이터베이스 구조를 변경하거나 민감한 작업을 수행할 수 있는 높은 수준의 DB 사용자 권한을 가집니다.

일반 사용자용 인스턴스는 웹 서비스 운영에 필요한 최소한의 읽기/쓰기 권한만 가진 낮은 DB 사용자 자격 증명을 사용하여 혹시 모를 침해 사고 시 피해 범위를 최소화합니다.

전송 중 데이터를 TLS로 보호하는 것만큼 저장된 데이터를 암호화하는 것도 필수적입니다. 이 아키텍처에서 적용해야 할 항목은 다음과 같습니다.

• Amazon RDS: 인스턴스 생성 시 AWS KMS 키를 사용한 스토리지 암호화를 활성화합니다. 생성 이후에는 암호화를 적용할 수 없으므로 초기 설계 단계에서 반드시 설정해야 합니다.
• Amazon EFS: 파일 시스템 생성 시 KMS 기반 암호화를 적용합니다.
• Amazon EBS: EC2 인스턴스에 연결되는 EBS 볼륨도 AWS KMS로 암호화하여 스냅샷 등 파생 데이터까지 보호합니다.

AWS KMS는 키 생성, 저장, 교체를 중앙에서 관리하며 CloudTrail과 통합되어 키 사용 이력도 감사할 수 있습니다.

 

경계 10 - Security at the application code layer

애플리케이션 코드 수준에서 보안을 적용하려면 업데이트가 제공될 때 이를 설치하는 좋은 관행을 확립해야 합니다. 대부분의 애플리케이션은 업데이트가 있을 때 알림을 받을 수 있는 이메일 목록을 제공합니다.

새로운 애플리케이션을 도입하기 전에 품질을 평가해야 합니다. 고려해야 할 몇 가지 지표는 다음과 같습니다.

• 얼마나 많은 개발자가 프로젝트에 기여하고 있는가? 
• 마지막 업데이트가 언제였는가?
• 버그나 보안 결함이 보고되었을 때 패치가 얼마나 신속하게 릴리스되는가?

 

추가되면 좋을 보안 요소

1. AWS Verified Access

더 안전한 사용자 인증 단계를 추가하고 싶다면 AWS Verified Access를 도입해야 합니다.

사용자가 애플리케이션의 관리 기능에 접근하기 전 기업의 보안 정책에 부합하는지 실시간으로 검증합니다.

오직 검증된 사용자만이 검증된 기기를 통해서만 관리자 기능을 사용할 수 있도록 강제함으로써 신원 도용으로 인한 내부 침입 리스크를 낮춥니다.

 

2. Amazon GuardDuty

Amazon GuardDuty는 AWS 계정과 워크로드를 지속적으로 모니터링하여 악의적인 활동을 찾아내는 위협 탐지 서비스입니다.

알려진 악성 도메인이나 IP 주소와의 통신을 감지하고 평소와 다른 비정상적인 동작을 머신러닝으로 식별합니다.

특히 GuardDuty Malware Protection 기능은 EC2 인스턴스에 연결된 EBS 볼륨을 스캔하여 멀웨어의 존재 여부를 감지합니다.

 

3. Amazon Inspector & AWS Systems Manager Patch Manager

인프라가 운영되는 동안 새롭게 발견되는 취약점에 대응하기 위해서는 자동화된 관리 도구가 필수적입니다.

• Amazon Inspector: 실행 중인 EC2 인스턴스를 자동으로 검색하여 소프트웨어 취약점과 의도치 않은 네트워크 노출을 스캔합니다.
• AWS Systems Manager Patch Manager: 웹 서버 인스턴스가 보안 패치가 제공될 때 Patch Manager를 통해 보안 패치를 자동으로 적용할 수 있습니다.

 

참고 자료: https://aws.amazon.com/ko/blogs/security/security-at-multiple-layers-for-web-administered-apps/