기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon Inspector Dockerfile 검사 이 단원에서는 Amazon Inspector SBOM 생성기를 사용하여 보안 취약성을 유발하는 잘못된 구성이 있는지 Dockerfiles 및 Docker 컨테이너 이미지를 스캔하는 방법에 대해 설명합니다. **Topics** + [Sbomgen Dockerfile 검사 사용](#w2aac39c13b7) + [지원되는 Dockerfile 검사](#w2aac39c13b9) ## Sbomgen Dockerfile 검사 사용 Dockerfile 검사는 `Dockerfile` 또는 `*.Dockerfile`이라는 파일이 검색되고 Docker 이미지가 스캔될 때 자동으로 수행됩니다. `--skip-scanners dockerfile` 인수를 사용하여 Dockerfile 검사를 비활성화할 수 있습니다. 또한 Dockerfile 검사를 OS 또는 타사 패키지 등 사용 가능한 모든 스캐너와 결합할 수도 있습니다. **Docker 검사 명령 예제** 다음 예제 명령은 Dockerfile과 Docker 컨테이너 이미지, OS 및 타사 패키지에 대한 SBOM을 생성하는 방법을 보여줍니다. ``` # generate SBOM only containing Docker checks for Dockerfiles in a local directory ./inspector-sbomgen directory --path ./project/ --scanners dockerfile # generate SBOM for container image will by default include Dockerfile checks ./inspector-sbomgen container --image image:tag # generate SBOM only containing Docker checks for specific Dockerfiles and Alpine, Debian, and Rhel OS packages in a local directory /inspector-sbomgen directory --path ./project/ --scanners dockerfile,dpkg,alpine-apk,rhel-rpm # generate SBOM only containing Docker checks for specific Dockerfiles in a local directory ./inspector-sbomgen directory --path ./project/ --skip-scanners dockerfile ``` **예제 파일 구성 요소** 다음은 파일 구성 요소에 대한 Dockerfile 조사 결과의 예입니다. ``` { "bom-ref": "comp-2", "name": "dockerfile:data/docker/Dockerfile", "properties": [ { "name": "amazon:inspector:sbom_scanner:dockerfile_finding:IN-DOCKER-001", "value": "affected_lines:27-27" } ], "type": "file" }, ``` **취약성 대응 구성 요소의 예** 다음은 취약성 대응 구성 요소에 대한 Dockerfile 조사 결과의 예입니다. ``` { "advisories": [ { "url": "https://docs.docker.com/develop/develop-images/instructions/" } ], "affects": [ { "ref": "comp-2" } ], "analysis": { "state": "in_triage" }, "bom-ref": "vuln-13", "created": "2024-03-27T14:36:39Z", "description": "apt-get layer caching: Using apt-get update alone in a RUN statement causes caching issues and subsequent apt-get install instructions to fail.", "id": "IN-DOCKER-001", "ratings": [ { "method": "other", "severity": "info", "source": { "name": "AMAZON_INSPECTOR", "url": "https://aws.amazon.com/inspector/" } } ], "source": { "name": "AMAZON_INSPECTOR", "url": "https://aws.amazon.com/inspector/" }, "updated": "2024-03-27T14:36:39Z" }, ``` **참고** Sbomgen을 `--scan-sbom` 플래그 없이 간접적으로 호출하는 경우 원시 Dockerfile 조사 결과만 볼 수 있습니다. ## 지원되는 Dockerfile 검사 Sbomgen Dockerfile 검사는 다음 항목에 대해 지원됩니다. + Sudo 바이너리 패키지 + Debian APT 유틸리티 + 하드코딩된 보안 암호 + 루트 컨테이너 + 런타임 약화 명령 플래그 + 런타임 약화 환경 변수 이러한 각 Dockerfile 검사의 심각도 등급은 다음 주제의 상단에 나와 있습니다. **참고** 다음 주제에 설명된 권장 사항은 업계 모범 사례를 기반으로 합니다. ### Sudo 바이너리 패키지 **참고** 이 검사의 심각도 등급은 **정보**입니다. Sudo 바이너리 패키지는 예측할 수 없는 TTY 및 신호 전달 동작이 발생할 수 있으므로 설치하거나 사용하지 않는 것이 좋습니다. 자세한 내용은 Docker Docs 웹 사이트에서 [User](https://docs.docker.com/build/building/best-practices/#user)를 참조하세요. 사용 사례에 Sudo 바이너리 패키지와 유사한 기능이 필요한 경우 [Gosu](https://github.com/tianon/gosu)를 사용하는 것이 좋습니다. ### Debian APT 유틸리티 **참고** 이 검사의 심각도 등급은 **높음**입니다. 다음은 Debian APT 유틸리티 사용에 대한 모범 사례입니다. **캐싱 문제 방지를 위해 단일 `Run` 문에 `apt-get` 명령 결합** Docker 컨테이너 내부의 단일 RUN 문에 `apt-get` 명령을 결합하는 것이 좋습니다. `apt-get update`만 단독으로 사용하면 캐싱 문제가 발생하고 후속 `apt-get install` 명령이 실패할 수 있습니다. 자세한 내용은 Docker Docs 웹 사이트에서 [apt-get](https://docs.docker.com/build/building/best-practices/#apt-get)을 참조하세요. **참고** 설명한 캐싱 동작은 Docker 컨테이너 소프트웨어가 최신 버전이 아닌 경우에도 Docker 컨테이너 내부에서 발생할 수 있습니다. **비대화형 방식으로 APT 명령줄 유틸리티 사용** APT 명령줄 유틸리티는 대화형으로 사용하는 것이 좋습니다. APT 명령줄 유틸리티는 최종 사용자 도구로 설계되었으며 버전에 따라 동작이 달라집니다. 자세한 내용은 Debian 웹 사이트에서 [Script Usage and differences from other APT Tools](https://manpages.debian.org/stretch/apt/apt.8.en.html#SCRIPT_USAGE_AND_DIFFERENCES_FROM_OTHER_APT_TOOLS)를 참조하세요. ### 하드 코딩된 보안 암호 **참고** 이 검사의 심각도 등급은 **중요**입니다. Dockerfile의 기밀 정보는 하드 코딩된 보안 암호로 간주됩니다. Sbomgen Docker 파일 검사를 통해 다음과 같은 하드 코딩된 보안 암호를 식별할 수 있습니다. + AWS 액세스 키 IDs- `AKIAIOSFODNN7EXAMPLE` + AWS 보안 키 - `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` + DockerHub 개인 액세스 토큰 - `dckr_pat_thisisa27charexample1234567` + GitHub 개인 액세스 토큰 - `ghp_examplev61wY7Pj1YnotrealUoY123456789` + GitLab 개인 액세스 토큰 - `glpat-12345example12345678` ### 루트 컨테이너 **참고** 이 검사의 심각도 마커는 **정보**입니다. Docker 컨테이너는 루트 권한 없이 실행하는 것이 좋습니다. 루트 권한 없이 실행할 수 없는 컨테이너화된 워크로드의 경우 최소 권한 원칙을 기반으로 애플리케이션을 구축하는 것이 좋습니다. 자세한 내용은 Docker Docs 웹 사이트에서 [User](https://docs.docker.com/build/building/best-practices/#user)를 참조하세요. ### 런타임 약화 환경 변수 **참고** 이 검사의 심각도 등급은 **높음**입니다. 여러 명령줄 유틸리티 또는 프로그래밍 언어 런타임은 보안 기본값 우회를 지원하므로 안전하지 않은 방법을 통해 실행될 수 있습니다. **NODE\_TLS\_REJECT\_UNAUTHORIZED=0** Node.js 프로세스가 `NODE_TLS_REJECT_UNAUTHORIZED`를 `0`으로 설정하여 실행되면 TLS 인증서 검증이 비활성화됩니다. 자세한 내용은 Node.js 웹 사이트에서 [NODE\_TLS\_REJECT\_UNAUTHORIZED=0](https://nodejs.org/api/cli.html#node_tls_reject_unauthorizedvalue)을 참조하세요. **GIT\_SSL\_NO\_VERIFY=\*** `GIT_SSL_NO_VERIFY`를 설정한 상태에서 git 명령줄 프로세스를 실행하면 Git은 TLS 인증서 확인을 건너뜁니다. 자세한 내용은 Git 웹 사이트에서 [Environment variables](https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables)를 참조하세요. **PIP\_TRUSTED\_HOST=\*** `PIP_TRUSTED_HOST`를 설정한 상태에서 Python pip 명령을 실행하면 Pip은 지정된 도메인에서 TLS 인증서 확인을 건너뜁니다. 자세한 내용은 Pip 웹 사이트에서 [--trusted-host](https://pip.pypa.io/en/stable/cli/pip/#cmdoption-trusted-host)를 참조하세요. **NPM\_CONFIG\_STRICT\_SSL=false** Node.js npm 명령줄 프로세스가 `NPM_CONFIG_STRICT_SSL`을 false로 설정하여 실행되면 Node Package Manager(npm) 유틸리티는 TLS 인증서를 검증하지 않고 NPM 레지스트리에 연결합니다. 자세한 내용은 npm Docs 웹 사이트에서 [strict-ssl](https://docs.npmjs.com/cli/v10/using-npm/config#strict-ssl)을 참조하세요. ### 런타임 약화 명령 플래그 **참고** 이 검사의 심각도 등급은 **높음**입니다. 런타임 약화 환경 변수와 마찬가지로, 여러 명령줄 유틸리티 또는 프로그래밍 언어 런타임은 보안 기본값 우회를 지원하므로 안전하지 않은 방법을 통해 실행될 수 있습니다. **`npm ––strict-ssl=false`** Node.js npm 명령줄 프로세스가 `--strict-ssl=false` 플래그와 함께 실행되면 Node Package Manager(npm) 유틸리티는 TLS 인증서를 검증하지 않고 NPM 레지스트리에 연결됩니다. 자세한 내용은 npm Docs 웹 사이트에서 [strict-ssl](https://docs.npmjs.com/cli/v10/using-npm/config#strict-ssl)을 참조하세요. **`apk ––allow-untrusted`** Alpine Package Keeper 유틸리티가 `--allow-untrusted` 플래그와 함께 실행되면 `apk`는 서명이 없거나 신뢰할 수 없는 패키지를 설치합니다. 자세한 내용은 Apline 웹 사이트에서 [다음 리포지토리](https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/f9eaeb6429325eeb5a17ed771fd477be9227fe15/doc/apk.8.scd#L114-115)를 참조하세요. **`apt-get ––allow-unauthenticated`** Debian `apt-get` 패키지 유틸리티를 `--allow-unauthenticated` 플래그와 함께 실행하면 `apt-get`은 패키지의 유효성을 검사하지 않습니다. 자세한 내용은 Debian 웹 사이트에서 [APT-Get(8)](https://manpages.debian.org/stretch/apt/apt-get.8.en.html)을 참조하세요. **`pip ––trusted-host`** Python pip 유틸리티를 `--trusted-host` 플래그와 함께 실행하면 지정된 호스트 이름이 TLS 인증서 검증을 건너뜁니다. 자세한 내용은 Pip 웹 사이트에서 [--trusted-host](https://pip.pypa.io/en/stable/cli/pip/#cmdoption-trusted-host)를 참조하세요. **`rpm ––nodigest, ––nosignature, ––noverify, ––nofiledigest`** RPM 기반 패키지 관리자 `rpm`이 `--nodigest`, `--nosignature`, `--noverify`, `--nofiledigest` 플래그와 함께 실행되면 RPM 패키지 관리자는 패키지를 설치할 때 패키지 헤더, 서명 또는 파일의 유효성을 검사하지 않습니다. 자세한 내용은 RPM 웹 사이트에서 다음 [RPM 매뉴얼 페이지](https://rpm-software-management.github.io/rpm/man/)를 참조하세요. **`yum-config-manager ––setopt=sslverify false`** RPM 기반 패키지 관리자 `yum-config-manager`가 `--setopt=sslverify` 플래그를 false로 설정하여 실행되면 YUM 패키지 관리자는 TLS 인증서를 검증하지 않습니다. 자세한 내용은 Man7 웹 사이트에서 다음 [YUM 매뉴얼 페이지](https://man7.org/linux/man-pages/man5/yum.conf.5.html)를 참조하세요. **`yum ––nogpgcheck`** RPM 기반 패키지 관리자 `yum`이 `--nogpgcheck` 플래그와 함께 실행되면 YUM 패키지 관리자는 패키지의 GPG 서명 검사를 건너뜁니다. 자세한 내용은 Man7 웹 사이트에서 [yum(8)](https://man7.org/linux/man-pages/man8/yum.8.html)을 참조하세요. **`curl ––insecure, curl –k`** `curl`이 `--insecure` 또는 `-k` 플래그와 함께 실행되면 TLS 인증서 검증이 비활성화됩니다. 기본적으로 `curl`에서 설정하는 모든 보안 연결은 전송이 발생하기 전에 보안 상태인지 확인을 거칩니다. 이 옵션을 사용하면 `curl`은 확인 단계를 건너뛰고 검사 없이 진행합니다. 자세한 내용은 Curl 웹 사이트에서 다음 [Curl 매뉴얼 페이지](https://curl.se/docs/manpage.html#-k)를 참조하세요. **`wget ––no-check-certificate`** `wget`이 `--no-check-certificate` 플래그와 함께 실행되면 TLS 인증서 검증이 비활성화됩니다. 자세한 내용은 GNU 웹 사이트에서 다음 [Wget 매뉴얼 페이지](https://www.gnu.org/software/wget/manual/wget.html#index-SSL-certificate_002c-check)를 참조하세요. ### 컨테이너 내 OS 패키지 데이터베이스 제거 확인 **참고** 이 검사의 심각도 등급은 **정보**입니다. 운영 체제 패키지 데이터베이스를 제거하면 컨테이너 이미지 소프트웨어의 전체 인벤토리를 스캔하는 기능이 줄어듭니다. 이러한 데이터베이스는 컨테이너 빌드 단계에서 그대로 두어야 합니다. OS 패키지 데이터베이스에 대한 제거 검사는 다음 패키지 관리자에 대해 지원됩니다. **Alpine 패키지 키퍼(APK)** 설치된 소프트웨어에 대해 APK 패키지 관리자를 사용하는 컨테이너 이미지는 빌드 중에 APK 시스템 파일이 제거되지 않도록 해야 합니다. 자세한 내용은 Arch Linux 웹 사이트의 [APK 관리](https://man.archlinux.org/man/apk.8.en#System_files) 시스템 파일 설명서를 참조하세요. **Debian Package Manager(DPKG)** Debian, Ubuntu 또는 Distroless 기반 이미지와 같이 DPKG 패키지 관리자를 사용하는 컨테이너는 컨테이너 빌드 중에 DPKG 데이터베이스가 제거되지 않았는지 확인해야 합니다. 자세한 내용은 Ubuntu 웹 사이트의 [DPKG 관리](https://manpages.ubuntu.com/manpages/trusty/man1/dpkg.1.html#files) 시스템 파일 설명서를 참조하세요. **RPM 패키지 관리자(RPM)** Amazon Linux 또는 Red Hat Enterprise Linux와 같이 RPM 패키지 관리자(yum/dnf)를 사용하는 컨테이너는 컨테이너 빌드 중에 RPM 데이터베이스가 제거되지 않았는지 확인해야 합니다. 자세한 내용은 RPM 웹 사이트의 [RPM 관리](https://rpm-software-management.github.io/rpm/man/rpm-common.8#FILES) 시스템 파일 설명서를 참조하세요.