TIL

3-5 보안 설계

• AWS에서도 클라우드 보안은 최우선 사항으로 취급된다.
• AWS가 제시하는 공동 책임 모델을 기반으로 ECS/Fargate를 취급하는 데 있어 중요한 설계 포인트를 정리한다.

공동 책임 모델의 이해

• AWS가 제공하는 공동 책임 모델을 따르는 보안 설계를 해야 한다.
  • AWS는 ‘보안과 규정 준수는 AWS와 고객의 공동 책임이다’라 명시하고 있음
  • 설비와 하드웨어 기반 시설은 AWS가, 애플리케이션이나 데이터 등의 암호화는 이용자가 그 책임을 진다.
• ECS/Fargate 구성을 사용하는 경우
  • AWS의 책임 - 워커 노드와 관련된 보안 대책 (OS 설정 및 취약점 등)
  • 이용자의 책임 - 애플리케이션과 데이터, 네트워크 설정, ECS 태스크, 컨테이너 등
• 이와 같이 이용할 AWS 공동 책임 모델을 파악하면 어디까지 보안을 해야 할지 알 수 있다.

컨테이너 개발 보안 모범 사례

• 컨테이너의 보안 수준을 높이기 위한 모범 사례 및 지침으로 NIST SP800-190이 있다.

NIST SP800-190

• 컨테이너 워크플로의 구성 요소에 대해 보안상 주의점과 대책을 제공
  • 이미지
  • 레지스트리
  • 오케스트레이터
  • 컨테이너
  • 호스트
• 이 책에서는 이용자가 책임져야 하는 부분을 설명한다.

이미지에 대한 보안 대책

‘이미지 취약점’에 대한 대책

• 컨테이너를 안전하게 이용하려면 이미지에 어떤 취약점이 있는지 주기적으로 확인/제거하는 것이 중요
  • 이미지에는 애플리케이션 뿐 아니라 라이브러리 등이 포함되어 있다.
  • 라이브러리는 시간이 지남에 따라 버전 취약점이 드러날 수도 있다.
• ECR을 이용한 취약점 스캔
  • ECR에서 푸시된 이미지의 취약점을 스캔하는 기능을 활성화할 수 있다.
  • 이미지 스캔은 추가 비용 없이 이용할 수 있다.
  • ‘푸시 시 스캔’과 ‘수동 스캔’이 존재하는데 ‘푸시 시 스캔’ 활성화를 추천
• Trivy를 이용한 취약점 스캔
  • Teppei Fukuda가 개인적으로 개발했고 AquaSecurity가 이어서 개발하고 있는 OSS
  • 컨테이너 보안 수준을 높이기 위해 반드시 이용해야 하는 도구로 자리매김하고 있다.
  • 기본 이미지에 포함된 OS 패키지 뿐 아니라 애플리케이션 종속성도 스캔 대상이 된다.
  • 실행 방법이 매우 간단하며 CI/CD 파이프라인과도 쉽게 통합 가능하다.
• 지속적인 스캔을 위한 설계
  • 이미지 취약점 대책에서 중요한 것은 자동으로 정기적인 스캔을 실행해야 한다는 것이다.
  • CI/CD에서 취약점을 스캔하는 것도 좋은 방법이지만 CI/CD 파이프라인이 실행되지 않으면 취약점을 확인할 수 없다.
  • CloudWatch Event에서 정기적으로 Lambda를 실행해 수동 스캔을 실행하는 방법도 있다.

이미지 설정 문제에 대한 대책

• Dockerfile은 작성 방법이나 개발자 수준에 따라 바람직하지 않은 보안 구성이 될 수도 있다.
  • ex) 애플리케이션이 root 권한으로 실행된다면 시스템 영역에 쓰기나 조작이 가능하게 되어 침해 사고가 발생하면 영향이 더 커진다.
• Dockle
  • 컨테이너 설정 내용을 확인해주는 오픈 소스 소프트웨어
  • 컨테이너 이미지에 대해 CIS(The Center for Internet Security)가 제공하는 모범 사례를 바탕으로 이미지를 확인한다.
  • Dockle을 통해 전체적인 컨테이너 이미지 확인이 가능하고 CI/CD 프로세스에 포함시킬 수도 있다.

‘악성 코드 포함’ 대책

• 컨테이너 이미지를 패키징할 때 악성 코드가 포함되면 시스템에 피해를 줄 수 있다.
• 신뢰할 수 있는 제공자가 제공한 기본 이미지 사용
  • 기본 이미지는 일반적으로 도커 허브나 ECR Public Gallery에서 취득한다.
  • 공개된 곳에 있다는 특성상 주의해야하기에 알 수 없는 제공자의 이미지는 피하는 것이 좋다.
  • ECR Public Gallery에서 Verified account 배지가 부여된 이미지는 AWS에서 확인을 완료한 이미지이다.
• GuardDuty 활용
  • GuardDuty란 VPC 플로 로그나 CloudTail의 이벤트 로그 등에서 악성 통신을 식별/탐지하는 관리형 서비스다.
  • 컨테이너 내에 악성 코드가 삽입되어 악성 IP와 통신이 발생하면 침해 내용을 알려준다.
  • GuardDuty는 ECS/Fargate 컨테이너 워크로드에 한정되어 사용되지만 악성 코드 탐지 대책으로 좋다.

‘평문 기밀 정보 포함’ 대책

• 애플리케이션 개발 시 기밀 정보를 취급하는 경우가 종종 발생한다.
  • DB 접속 정보, 서드파티 API 호출에 필요한 키 등
  • 이러한 기밀 정보를 소스 코드나 이미지 내에 평문으로 저장하면 안 된다.
• ECS/Fargate에서 기밀 정보를 관리할 수 있는 장소
  • Secrets Manager
  • System Manager(구 SSM) Parameter Store
  • 기밀 정보가 저장된 곳의 ARN과 환경 변수명을 태스크 정의 안에서 매핑해 환경 변수로 인식시킬 수 있다.
• System Manager Parameter Store 사용 시 주의점
  • 평문을 저장하는 string 정의와 암호화 매개변수를 취급하는 secure string 정의가 존재한다.
  • 기밀 정보는 secure string을 사용해 암호화할 필요가 있다.

‘신뢰할 수 없는 이미지 사용’ 대책

• 검증이 불충분한 외부 컨테이너 이미지를 사용해야 한다면 충분한 테스트 후 위험성을 없애야 한다.
• 기본적인 대책은 환경에 맞는 신뢰 가능한 이미지 및 리포지토리를 한 곳에서 관리하는 것
  • ECR을 사용
• DCT (Docker Content Trust)
  • Docker가 제공하는 이미지의 서명을 검증하여 변조를 탐지하는 기능
  • CodeBuild와 통합해 CI/CD와 연계해 이미지 정합성 확인을 자동화할 수 있다.

레지스트리에 대한 보안 대책

• 이미지 레지스트리로 ECR을 사용한다면 개발자는 아래 측면만 고려하면 된다.
  • 저장된 이미지 관리
  • 레지스트리 자체의 인증 및 인가 보안

‘레지스트리 내의 오래된 이미지’ 대책

• 컨테이너 이미지는 태그를 이용해 여러 버전을 관리하는 것이 일반적이다.
  • 이전 버전을 관리하는 것은 배포 후 롤백을 위해 필요할 수 있다.
  • 그러나 너무 오래된 이미지는 취약점을 다수 포함하는 버전으로 변경될 수도 있다.
• ECR 수명 주기 정책을 적절히 설정하여 버전 관리를 자동화할 수 있다.
• ECR에는 이미지 태그 덮어쓰기를 금지하는 IMMUTABLE 설정이 가능하다.
  • 동일 태그를 푸시하면 기존 이미지는 삭제되어 버린다.
  • 컨테이너 이미지 일관성을 유지하고 잘못된 이미지가 푸시되는 것을 막기 위해 활성화를 추천

‘불충분한 인증, 인가 제한’ 대책

• 예상하지 못한 곳에서 접속을 허용하면 이미지 변조나 정보 유출의 원인이 된다.
• IAM 정책 설계를 잘 하는 것만으로도 어느 정도의 보안 레벨은 달성할 수 있다.
• 프라이빗 리포지토리 선택
  • ECR은 반드시 프라이빗 리포지토리를 생성해 특정 IAM 권한의 사용자만 접근 가능하게 해야 한다.
• 리포지토리 정책 활용
  • 프로덕션용 ECR에 수동 푸시를 허용하면 규칙에서 벗어난 이미지가 배포될 가능성이 있다.
  • 수동 푸시를 막고 CI/CD를 이용한 배포 자동화에서만 이미지를 푸시하도록 정책을 설계하는 것이 효과적이다.
  • CodeBuild를 통해서만 푸시 가능, 이미지 pull은 IAM 이용자 및 ECS만 허가, 그 밖에는 모두 거부

오케스트레이터에 대한 보안 대책

• ECS를 사용하기에 호스트 OS 레이어는 개발자가 보안을 고려하지 않아도 된다.

‘제한 없는 관리 접속’ 대책

• ECS 관리 접속을 모두에게 허용하는 것은 바람직하지 않다.
  • ECS 뿐 아니라 AWS 자원 이용에 있어서 IAM을 이용한 최소 권한 부여를 추천한다.
• 직무에 따른 권한 부여는 적절하게 수행해야 하지만 ECS 클러스터별로 접근을 분리해야 하는지 여부는 요건에 따라 달라진다.
  • 너무 제한하면 개발 민첩성이 낮아질 수도 있다.

‘컨테이너 간 네트워크 트래픽 분리 미흡’ 대책

• ECS/Fargate에서 실행하는 ECS 태스크는 모두 VPC 위에 배치된다.
• Fargate에서 호스팅되는 태스크는 ‘awsvpc’ 네트워크 모드가 선택된다.
  • 네트워크 모드 : ECS 태스크에 대한 네트워크 연결 방법
  • 태스크 별로 고유한 ENI(Elastic Network Interface)가 할당
  • ENI에 프라이빗 IPv4 주소가 할당
• ECS/Fargate 네트워크 보안은 VPC 전체 모습을 생각하며 설정하는 것이 좋다.
  • IPv4 주소가 ECS 태스크에 할당되면 그 자체가 네트워크 노드가 되기 때문
• 컨테이너 간 네트워크 트래픽에 대한 보안은 ‘컨테이너로부터의 네트워크 접근 제한 대책’과 함께 정리할 예정이다.

컨테이너에 대한 보안 대책

‘컨테이너로부터의 네트워크 접근 제한’ 대책

• ECS 태스크에 구성된 VPC 네트워크에는 다음 3가지 설계 사항이 반영된다.
  • 퍼블릭 네트워크 → VPC 통신
  • ECS 태스크 간 통신
  • VPC → 퍼블릭 네트워크 통신
• 퍼블릭 네트워크 → VPC 통신
  • AWS에서 ECS 태스크에 직접 퍼블릭 IP를 할당하면 외부에서 들어오는 통신을 태스크의 보안 그룹 또는 애플리케이션 내부에서 제어해야 한다.
  • AWS에선 관리형 WAF(Web Application Firewall)를 제공하지만 WAF는 다음 3가지와만 연계가 가능하다.
    • CloudFront, ALB, API Gateway
    • 대표적인 구성은 ALB와 연계하는 것
  • AWS 서비스는 추가 요금 없이 AWS Shield Standard를 이용할 수 있기에 알아둘 것을 권장한다.
• ECS 태스크 간 통신
  • 태스크와 ALB에 연결된 보안 그룹 규칙을 적절히 설정해 간단히 통신을 제어할 수 있다.
• VPC → 퍼블릭 네트워크 통신
  • VPC 내에서 리전 서비스에 접속하려면 퍼블릭 네트워크까지의 경로가 필요하다.
    • S3에 파일을 업르도, CloudWatch로 로그 전달 등
  • AWS는 프라이빗 서브넷에 컨테이너를 배치하는 것을 추천하고 있다.
  • NAT 게이트웨이를 이용해 퍼블릭 네트워크와 통신이 가능하도록 할 수 있다.
  • 컴플라이언스 요건 등에 따라 퍼블릭 네트워크로 나가도록 하고 싶지 않다면 ‘VPC 엔드 포인트’ 서비스를 이용하는 방법이 있다.
  • VPC 내/외부의 AWS 서비스와 프라이빗으로 통신하려면 연계할 AWS 서비스별로 VPC 엔드포인트를 만들어야 한다.
    • 비용이 우려된다면 우선 NAT 게이트웨이에 통신을 집중시키는 편이 좋다.

‘애플리케이션 취약점’ 대책

• 애플리케이션 자체 취약점 대칙은 보안 대책의 기본이다.
  • 시큐어 코딩
  • WAF 설치 등
• ECS 태스크 정의에서 컨테이너의 루트 파일 시스템을 읽기 전용으로 변경할 것을 추천한다.

‘승인되지 않은 컨테이너’ 대책

• IAM 정책과 리포지터리 정책을 사용해 승인되지 않은 컨테이너 배포를 차단할 수 있다.
• 승인되지 않은 컨테이너 대책
  • 개발환경: CI/CD를 통해 빌드된 이미지 배포를 기본으로 하지만, 수동 빌드 및 푸시 이미지의 배포도 허용
  • 스테이징 환경: CI/CD를 통해 빌드된 이미지만 배포 가능
  • 프로덕션 환경: 스테이징 환경용 CI/CD에서 빌드/배포된 이미지로부터의 배포만 가능
• 다중 계정 구성
  • 스테이징/프로덕션용 ECR 정책에 CI/CD에서만 이미지 푸시가 가능하도록 설정 (IAM)
  • IAM 사용자에게 할당된 IAM 정책에는 ECS 태스크 정의를 변경할 수 없게 설정