애플리케이션 보호를 위한 상위 5가지 Docker 보안 모범 사례

Docker 보안은 컨테이너가 실행되기 전부터 시작됩니다. 이미지에 취약한 패키지가 포함되어 있거나, 컨테이너가 필요한 것보다 더 많은 권한으로 실행되거나, Docker 소켓이 공격자에게 호스트로의 직접적인 경로를 제공할 수 있습니다.

이 다섯 가지 Docker 보안 모범 사례는 일상적으로 가장 큰 차이를 만드는 제어에 초점을 맞춥니다: 신뢰할 수 있는 이미지, 작은 런타임 표면, 비루트 프로세스, 제한된 네트워크 액세스, 보호된 데몬.

1. Docker 이미지에서 취약점 정기적으로 스캔

Docker 보안에서 가장 중요한 단계 중 하나는 배포하는 컨테이너 이미지에 알려진 취약점이 없는지 확인하는 것입니다. 이미지는 컨테이너의 구성 요소이며, 이미지에 악성 코드나 오래되고 취약한 소프트웨어가 포함되어 있으면 애플리케이션이 이러한 위험을 상속받습니다.

이미지 스캔이 중요한 이유

알려진 익스플로잇 식별: 이미지 스캐너는 이미지 내 운영 체제 패키지 및 애플리케이션 종속성에서 공개적으로 알려진 취약점(CVE)을 감지할 수 있습니다.
공급망 공격 방지: 사용하는 기본 이미지가 변조되지 않았거나 악성 페이로드를 포함하지 않았는지 확인합니다.
규정 준수 유지: 많은 규제 프레임워크에서 소프트웨어 구성 요소에 대한 정기적인 취약점 스캔을 요구합니다.

도구 및 기술

Docker 이미지를 스캔하는 데 도움이 되는 여러 도구가 있습니다:

Docker Scout: 설정에 따라 Docker 제품 및 CLI 워크플로를 통해 사용할 수 있는 Docker의 이미지 분석 도구입니다.
Trivy: 컨테이너 이미지, Git 리포지토리 등에서 취약점을 찾는 오픈 소스의 사용하기 쉬운 스캐너입니다.
Clair: 컨테이너를 위한 또 다른 오픈 소스 취약점 정적 분석 도구입니다.
Trivy CLI:
```
trivy image your-docker-image:tag
```

모범 사례: 이미지 스캔을 CI/CD(지속적 통합/지속적 배포) 파이프라인에 통합합니다. 이렇게 하면 이미지가 프로덕션에 배포되기 전에 스캔되어 취약한 이미지가 라이브 환경에 도달하는 것을 방지할 수 있습니다.

2. 최소 기본 이미지를 사용하여 컨테이너 공격 표면 최소화

최소 권한 원칙은 컨테이너 이미지에도 적용됩니다. 기본 이미지가 작고 집중적일수록 포함할 수 있는 잠재적 취약점이 줄어들고 공격자가 이를 악용하기가 더 어려워집니다.

최소 이미지가 중요한 이유

취약점 수 감소: 패키지가 적을수록 공격자의 잠재적 진입점이 줄어듭니다.
더 작은 공간: 최소 이미지는 더 빠른 풀 및 배포로 이어지고 저장 공간을 덜 소비합니다.
더 쉬운 유지 관리: 패치 및 관리할 소프트웨어가 줄어듭니다.

최소 기본 이미지 선택

alpine Linux: 작고 인기가 있지만 musl libc를 사용하므로 호환성을 테스트하세요.
Distroless 이미지: 이러한 이미지는 셸이나 패키지 관리자 없이 애플리케이션과 런타임 종속성을 포함합니다. 손상 후 공격자가 사용할 수 있는 것을 줄이지만 디버깅을 더 어렵게 만들 수 있습니다.

예: Alpine을 기본 이미지로 사용

대신:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y --no-install-recommends your-app

다음을 고려하세요:

FROM alpine:latest
RUN apk add --no-cache your-app

팁: 애플리케이션에 절대적으로 필요한 패키지와 종속성만 설치하세요. 프로덕션 이미지에 개발 도구, 셸 또는 불필요한 유틸리티를 설치하지 마세요.

3. 비루트 사용자로 컨테이너 실행

이미지가 다른 사용자를 지정하지 않는 한 Docker 컨테이너 내부의 프로세스는 root로 실행됩니다. 공격자가 해당 컨테이너에서 코드 실행을 얻으면 컨테이너 내부의 루트는 파일 수정, 마운트된 볼륨 남용, Docker 또는 커널 잘못된 구성과 결합된 손상 등 더 많은 여지를 제공합니다.

루트로 실행할 때의 위험

권한 상승: 컨테이너가 손상되면 공격자는 컨테이너 내에서 완전한 루트 액세스 권한을 갖습니다. 컨테이너가 호스트에서 과도한 권한을 가지고 있으면 호스트 손상으로 이어질 수 있습니다.
데이터 변조: 루트 사용자는 컨테이너 파일 시스템 내의 모든 파일을 수정할 수 있습니다.

비루트 실행 구현

전용 사용자 생성: Dockerfile에서 비루트 사용자와 그룹을 만든 다음 애플리케이션을 실행하기 전에 해당 사용자로 전환합니다.
파일 권한 설정: 애플리케이션 파일과 디렉터리가 비루트 사용자가 소유하도록 합니다.

예제 Dockerfile 스니펫:

# 비루트 사용자 및 그룹 생성
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# 애플리케이션 파일 복사 및 소유권 설정
COPY --chown=appuser:appgroup /app /app

# 비루트 사용자로 전환
USER appuser

# 작업 디렉터리 설정
WORKDIR /app

# 애플리케이션 실행 명령
CMD ["your-app-executable"]

경고: 애플리케이션이 실행되는 사용자에게 필요한 디렉터리나 파일에 액세스하고 쓸 수 있는 필요한 파일 권한이 있는지 확인하세요. 그렇지 않으면 애플리케이션이 시작되지 않거나 제대로 작동하지 않을 수 있습니다.

4. 컨테이너 통신을 위한 네트워크 분할 및 최소 권한 구현

네트워킹은 컨테이너 보안의 중요한 측면입니다. 컨테이너는 Docker 네트워크를 공유하고 대상 서비스가 수신 대기 중일 때 통신할 수 있습니다. 각 Docker 네트워크를 신뢰 경계로 취급하세요. 손상된 웹 컨테이너가 데이터베이스, 캐시, 관리 UI 또는 내부 작업에 자동으로 도달해서는 안 됩니다.

네트워크 분할의 이점

폭발 반경 제한: 하나의 컨테이너가 손상되면 네트워크 분할로 인해 다른 민감한 컨테이너나 서비스에 액세스하지 못하도록 방지할 수 있습니다.
트래픽 흐름 제어: 어떤 컨테이너가 서로 통신할 수 있는지와 어떤 포트에서 통신할 수 있는지 정확히 정의합니다.
보안 태세 개선: 네트워크 액세스에 대한 최소 권한 원칙을 적용합니다.

Docker 네트워크 모범 사례

사용자 정의 네트워크 사용: 기본 bridge 네트워크에 의존하는 대신 각 애플리케이션 또는 계층에 대한 사용자 정의 네트워크를 만듭니다. 사용자 정의 브리지 네트워크는 또한 컨테이너 이름으로 기본 제공 DNS 기반 서비스 검색을 제공합니다.
```
docker network create my-app-network
docker run --network my-app-network ...
```
컨테이너 액세스 제한: 프론트엔드가 API만 호출해야 하는 경우 두 서비스를 하나의 네트워크에 배치하고 데이터베이스는 API와만 공유되는 별도의 백엔드 네트워크에 유지합니다.
방화벽 규칙 사용(호스트 수준): 호스트 수준 방화벽 규칙(예: iptables)을 구현하여 컨테이너와의 네트워크 트래픽을 추가로 제한합니다.
네트워크 플러그인 고려: 고급 네트워크 정책 및 분할을 위해 Docker 네트워크 플러그인 또는 정교한 네트워크 정책을 제공하는 Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼을 살펴보세요.

팁: 컨테이너 네트워크 구성 및 액세스 제어 목록을 정기적으로 검토하여 보안 요구 사항 및 최소 권한 원칙과 일치하는지 확인하세요.

5. Docker 데몬 및 호스트 보안

Docker 데몬 자체는 호스트 운영 체제와 직접 상호 작용하는 강력한 구성 요소입니다. Docker 데몬이 손상되면 공격자는 전체 Docker 환경(호스트 시스템 포함)에 대한 상당한 제어권을 얻을 수 있습니다.

Docker 데몬 보안

데몬 액세스 제한: Docker 데몬의 소켓(/var/run/docker.sock)이 신뢰할 수 없는 사용자나 애플리케이션에 노출되지 않도록 합니다. 권한이 있는 사용자에게만 액세스 권한을 부여합니다.
원격 데몬 액세스에 TLS 사용: TCP를 통해 Docker API를 노출하는 경우 TLS 및 클라이언트 인증으로 보호하세요. 명확한 운영상의 필요가 없는 한 노출을 피하세요.
적합한 경우 루트리스 모드 선호: 루트리스 Docker는 일부 워크로드에 대한 호스트 수준 위험을 줄일 수 있지만 네트워킹 및 기능상의 장단점이 있으므로 테스트해야 합니다.

Docker 호스트 보안

호스트 OS 업데이트 유지: Docker 호스트의 기본 운영 체제를 정기적으로 패치하고 업데이트하여 보안 취약점을 수정합니다.
호스트 강화: 불필요한 서비스 비활성화, 방화벽 구성, 강력한 액세스 제어 적용 등 호스트 시스템에 보안 강화 구성을 적용합니다.
호스트 활동 모니터링: 의심스러운 활동을 감지하기 위해 Docker 호스트에 대한 강력한 로깅 및 모니터링을 구현합니다.
보안 도구 사용: 환경에 적합한 호스트 기반 침입 탐지, 감사 로깅 및 런타임 모니터링을 사용합니다.
불필요한 권한 제거: --privileged를 피하고 필요하지 않은 Linux 기능을 삭제하며 애플리케이션이 지원하는 경우 읽기 전용 파일 시스템을 사용합니다.

모범 사례: Docker 데몬의 구성과 Docker 호스트의 보안 태세를 정기적으로 감사합니다. CIS Docker Benchmark와 같은 보안 벤치마킹 도구를 사용하여 보안 설정을 평가하고 개선하는 것을 고려하세요.

핵심 요점

Docker 보안을 일반적인 전달 경로의 일부로 만드세요. CI에서 이미지를 스캔하고, 프로덕션 이미지를 작게 유지하고, 비루트 사용자로 실행하고, 네트워크별로 서비스를 격리하고, Docker 호스트를 고가치 시스템으로 보호하세요. 하나의 서비스로 시작하여 이러한 제어를 적용한 다음 패턴을 기본 템플릿으로 전환하세요.