인프라스트럭처 애즈 코드(IaC)는 현대 기술 환경의 판도를 바꾸는 혁신으로 급부상했습니다. 인프라 프로비저닝 및 관리 프로세스를 코드로 전환함으로써 개발자는 버전 관리와 재현성을 확보하고 잠재적 취약점을 줄일 수 있지만, 그 확산과 함께 잠재적 취약점 문제도 발생합니다.
GitLab IaC 스캐닝은 IaC 설정 내 잘못된 구성과 보안 취약점을 발견하고 이를 방지하는 효과적이고 효율적인 수단으로 두각을 나타냅니다. 본 가이드는 IaC 구성을 강화하기 위한 그 가치, 설정 과정 및 모범 사례를 심층적으로 살펴볼 것입니다.
인프라스트럭처 애즈 코드(IaC)란 무엇인가?
인프라스트럭처 애즈 코드(IaC)는 인프라 프로비저닝, 관리 및 구성 작업을 수동 프로세스나 맞춤형 스크립트가 아닌 코드로 명시하는 접근 방식입니다. 서버, 데이터베이스 또는 네트워킹 인프라 구성 요소를 프로비저닝하기 위해 수동 프로세스에 의존하는 대신, IaC는 표준 코드 템플릿을 활용합니다.
IaC의 인기는 애플리케이션 배포 및 확장에 있어 민첩성에 대한 요구가 지속적으로 증가하고 있기 때문이라고 설명할 수 있습니다. 기존 인프라 관리는 시간이 많이 소요되는 설정이 필요했고, 종종 인적 오류에 의존했습니다. IaC는 소프트웨어 코드처럼 인프라에 버전 관리를 적용하여 일관성, 반복성 및 신속한 업데이트 프로세스를 제공합니다. 이를 통해 버전 관리된 반복 가능한 인프라 구축이 인간의 감독이나 오류 없이 지속적으로 실행될 수 있습니다.
DevOps 관행은 또한 IaC 관행과 시너지를 발휘하여 조직이 개발과 운영 간의 격차를 해소하는 데 도움을 줍니다. IaC를 통해 인프라 변경을 애플리케이션 개발과 동시에 구현할 수 있어 배포 시간을 단축하고 파이프라인 관리를 원활하게 할 수 있습니다. 이들의 결합된 노력은 배포 프로세스 중 조직의 효율성과 신뢰성 향상을 촉진합니다.
IaC 스캐닝이 필수적인 이유는 무엇인가?
인프라스트럭처 애즈 코드(IaC)는 잠재적 취약성의 새로운 경로를 열어놓았습니다. 인프라 배포를 자동화하기 위해 스크립트를 작성하는 개발자들은 의도치 않게 인프라 배포 프로세스에 중대한 보안 허점을 도입할 수 있습니다; IaC 스캐닝은 이러한 보안 취약점이 프로덕션 환경에 도달하기 전에 탐지하는 데 필수적입니다.
현대적인 클라우드 네이티브 인프라스트럭처는 매우 동적이고 복잡한 환경일 수 있습니다. IaC 스캐닝 도구가 코드 정의를 분석하여 보안 모범 사례를 위반하고 데이터 유출 및 인프라 취약점으로 인한 시스템 침해를 유발할 수 있습니다. IaC 스캔 도구는 AI-as-a-Consumption(AIC) 기술을 활용합니다. (AIC) 기술을 활용합니다. 이를 통해 데이터 유출이나 시스템 침해를 유발하는 인프라 취약점 관련 위험을 획기적으로 낮춥니다.
규정 준수 및 데이터 보호 기준이 강화됨에 따라 기업은 법적 또는 평판상의 영향을 피하기 위해 초기부터 안전한 인프라를 구축해야 합니다. IaC 스캔은 인프라가 업계 규정을 준수하도록 보장함으로써 기업이 이러한 기준을 따르도록 지원하여 법적 후과로부터 보호합니다.
GitLab IaC 스캐닝 이해하기
GitLab의 인프라스트럭처 코드(IaC) 스캐닝 기능은 잠재적 취약점에 대해 IaC 구성 파일을 체계적으로 검증하는 접근 방식을 제공합니다. 이를 통해 인프라를 프로비저닝하고 관리하는 구성이 견고하고 안전하며 규정을 준수하도록 보장합니다. 이 지원은 Terraform, Ansible, AWS CloudFormation, Kubernetes 등 널리 사용되는 파일을 포함한 다양한 IaC 구성 파일로 확장됩니다.
- 요구 사항 및 호환성
- 지원되는 파일 및 사용자 정의
- 구성 및 규칙 맞춤 설정
- 자동 취약점 해결
1. 요구 사항 및 호환성
효과적인 IaC 스캐닝은 테스트 단계 내에서 작동해야 하며, 이 단계의 .gitlab-ci.yml 파일에 포함되어야 합니다.
- 최적의 성능을 위해 최소 RAM 요구 사항은 4GB 이상이어야 합니다.
- 기본적으로 Docker 또는 Kubernetes 실행기를 사용하는 GitLab Runner가 필수입니다(GitLab.com 사용자에게는 자동으로 활성화됨). 그러나 IaC 스캐닝 분석기는 amd64가 아닌 CPU 아키텍처와 호환되지 않을 수 있으며, 이러한 작업에는 Docker 버전 19.03.0 사용을 피하는 것이 가장 좋습니다.
2. 지원되는 파일 및 사용자 정의
GitLab IaC 스캔은 KICS 도구를 통해 포괄적인 지원을 제공합니다. Ansible, AWS CloudFormation, Azure Resource Manager Dockerfile, Google Deployment Manager, Kubernetes OpenAPI, Terraform 등의 구성 파일이 지원됩니다. 결과 검토 시 JSON 형식의 Azure Resource Manager 템플릿이 필요하거나 사용자 정의 레지스트리 Terraform 모듈을 지원하지 않는 등 특정 요구 사항도 고려해야 합니다.
GitLab은 이 기능을 통해 모든 오픈 소스 (OSS) 분석기를 GitLab Free 티어를 통해 사용할 수 있도록 함으로써 개방성에 대한 헌신을 계속하고 있습니다. SAST_IMAGE_SUFFIX 변수를 조작하여 표준 버전과 FIPS 버전의 이미지 간에 전환할 수 있습니다.
3. 구성 및 규칙 사용자 지정
프로젝트에서 IaC 스캔을 설정하는 것은 비교적 간단합니다. SAST-IaC.gitlab-ci.yml 템플릿을 포함하여 수동으로 설정하거나, 병합 요청을 통해 자동으로 설정할 수 있습니다. 스캔 완료 후 IaC 스캔 작업 결과가 SAST 보고서 아티팩트로 저장됩니다.
스캔 프로세스를 개선하려는 팀은 기본 규칙을 사용자 정의할 수 있습니다. 이 기능에는 다음이 포함됩니다:
- 사전 정의된 규칙 비활성화.
- 중요도 수준 조정이나 개인 문서 직접 연결 등 특정 측면에 영향을 미치는 사용자 정의 규칙으로 기존 규칙 재정의.
또한 스캔 프로세스를 특정 분석기 버전과 연결하여 업데이트로 인한 회귀 현상이나 원치 않는 변경 사항으로부터 보호할 수도 있습니다.
4. 자동 취약점 해결
GitLab IaC 스캐닝은 보고서의 불필요한 노이즈를 제거하는 데 중점을 둡니다. 관련성을 유지하고 현재 취약점에 집중하기 위해 시스템은 다음과 같은 자동 조치를 취합니다.
1. 규칙 비활성화: 하나 이상의 규칙이 더 이상 프로젝트와 관련이 없다고 판단하여 명시적으로 비활성화하면, 해당 규칙이 이전에 보고한 취약점은 자동으로 해결됩니다.
2. 규칙 제거: GitLab이 하나 이상의 기본 규칙이 더 이상 필요하지 않거나 너무 많은 오탐을 발생시킨다고 판단할 경우, 해당 규칙은 제거될 가능성이 높으며, 그러한 규칙에 의해 표시된 모든 취약점은 자동으로 해결됩니다.
3. 기록 보관: 감사 추적 기록 유지가 중요합니다. GitLab 취약점 관리 시스템은 주석을 추가하여 자동 처리 및 해결된 과거 취약점을 계속 파악할 수 있도록 합니다.
4. 규칙 재활성화: 이전에 비활성화된 규칙을 다시 활성화하면 자동 해결된 발견 사항이 다시 분류 검토를 위해 열려 과거 취약점이 누락되지 않도록 합니다.
보고: JSON 형식 이해&
GitLab의 IaC 스캐닝 도구는 SAST 보고서 형식에 부합하도록 발견 사항을 구조화된 JSON 보고서로 출력하여 사용자에게 포괄적인 결과를 제공합니다.
1. 표준화: 이 형식은 다양한 프로젝트 또는 스캔 간에 쉽게 통합하고 비교할 수 있게 합니다.
2. 접근성: 사용자는 CI 파이프라인 페이지나 머지 요청 파이프라인에서 아티팩트: 경로 지시어를 사용하여 "gl-sast-report.json"을 직접 빠르고 쉽게 다운로드할 수 있습니다. 이를 위해 아티팩트: 경로 지시어를 "gl-sast-report.json"으로 설정하세요.
3. 스키마 참조: GitLab은 이 보고서를 더 깊이 탐구하거나 다른 시스템과 통합하려는 사용자가 모든 부분을 쉽고 포괄적으로 접근할 수 있도록 상세한 스키마 문서를 제공합니다.
GitLab IaC 스캐닝 설정하기
프로젝트에 GitLab IaC 스캐닝을 설정하는 방법을 살펴보겠습니다.
GitLab IaC 스캐닝 설정 단계는 다음과 같습니다.–
- 필수 조건
- GitLab CI/CD 통합
- 사용자 정의 구성 (선택 사항)
- 스캔 실행
- 결과 검토
1. 필수 조건
- GitLab 버전: GitLab 버전 12.10 이상을 사용 중인지 확인해야 합니다.
- 저장소 설정: 인프라스트럭처 코드 파일(예: Terraform, CloudFormation, Kubernetes 구성 파일)은 저장소의 일부를 구성해야 합니다.
2. GitLab CI/CD 통합
IaC 스캔을 설정하려면 GitLab CI/CD 파이프라인과 통합해야 합니다.
저장소 루트에 .gitlab-ci.yml 파일을 생성하거나 업데이트하세요.
다음 구성을 추가하세요:
Include:
template: Security/Infrastructure-Scanning.gitlab-ci.yml
이 포함을 통해 CI/CD 파이프라인 내에서 IaC 스캐닝 작업이 활성화됩니다.
3. 사용자 정의 구성 (선택 사항)
특정 요구사항이 있는 프로젝트의 경우 스캔 프로세스를 맞춤 설정할 수 있습니다:
- 사용자 정의 규칙: GitLab IaC 스캔은 사용자가 사용자 정의 규칙을 정의하거나 기존 규칙을 수정할 수 있도록 합니다. 이러한 규칙은 저장소 루트 디렉터리에 .iac-custom-rules 디렉터리를 생성하여 추가할 수 있습니다.
- 디렉터리 무시: 스캐너가 특정 디렉터리를 건너뛰도록 하려면 CI/CD 구성의 변수 아래에서 해당 디렉터리를 정의할 수 있습니다:
변수:
IAC_PATHS: “infrastructure/*,!infrastructure/legacy/”
위 예시에서 스캐너는 infrastructure 디렉토리 내 파일만 분석하고 legacy 하위 디렉토리는 제외합니다.
4. 스캔 실행
설정이 완료되면 CI/CD 파이프라인 실행을 시작하세요. IaC 스캔 작업이 인프라스트럭처 코드 파일을 분석하여 잠재적 취약점에 대한 인사이트를 제공합니다.
5. 결과 검토
분석 후 발견된 취약점(있는 경우)은 다음과 같이 표시됩니다:
- 머지 요청 내(스캔이 머지 요청에 의해 트리거된 경우).
- 프로젝트의 보안 및 규정 준수 섹션.
여기서 다음을 수행할 수 있습니다:
- 취약점 세부 정보를 확인합니다.
- 해결됨으로 표시하거나 추적할 이슈를 생성합니다.
- 선택적으로 취약점 심각도나 유형에 기반한 자동화된 조치를 설정합니다.
안전한 IaC(Infrastructure as Code) 구성을 위한 모범 사례
안전한 IaC (Infrastructure as Code) 구성 모범 사례는 다음과 같습니다.–
- 최소 권한 원칙(PoLP Principle)
- 버전 관리 및 변경 추적 유지
- 의존성 정기 스캔 및 업데이트
- 비밀 정보 보호
- 구성 효율적 검증 및 평가
1. PoLP 원칙 (최소 권한 원칙)
최소 권한 원칙(Principle of Least Privilege) 은 사용자, 시스템, 프로세스 등 모든 주체가 수행해야 할 작업에 필요한 최소한의 권한만을 부여받도록 보장하기 위해 고안된 핵심 보안 개념입니다. 이 원칙은 프로그래밍 방식으로 권한을 할당할 수 있는 IaC 환경에서 더욱 중요해집니다. 권한이 잘못 부여되거나 지나치게 광범위하게 부여될 경우, 자원을 불필요한 위험에 노출시킬 수 있기 때문입니다.
IaC 내에서 PoLP 요구사항을 준수하려면 각 서비스나 기능이 필요한 자원만 접근하도록 권한을 신중하게 스크립팅해야 합니다. AWS와 같은 클라우드 인프라의 경우, 이는 모든 스토리지 리소스에 대한 포괄적 권한 부여 대신 S3 버킷에 대한 읽기 전용 권한 부여를 포함할 수 있습니다. 인프라가 진화함에 따라 권한이 계속 엄격하게 유지되도록 IaC 스크립트를 지속적으로 검토해야 합니다.
2. 버전 관리 및 변경 추적 유지
버전 관리는 전통적인 소프트웨어 개발뿐만 아니라 IaC 환경의 인프라 관리에서도 필수적인 역할을 합니다. 변경 사항 추적, 구성 롤백, 인프라 조정 이해는 IaC 인프라 관리를 위한 안전하고 안정적인 환경 유지에 필수적입니다.
IaC 구성을 위한 GitLab 및 GitHub 플랫폼은 변경 추적 도구뿐만 아니라, 프로덕션 환경에 배포되기 전에 팀원과 함께 제안된 수정 사항을 검토할 수 있는 협업 기능도 제공합니다. 이러한 동료 검토 프로세스는 중요한 변경 사항이 IaC 환경에 도입되기 전에 보안 문제가 고려되고 모범 사례를 준수하도록 보장합니다.
3. 종속성 정기 스캔 및 업데이트
소프트웨어 개발과 마찬가지로, 인프라스트럭처 애즈 코드(IaC) 구성은 인프라스트럭처 배포를 간소화하기 위해 종종 타사 템플릿 및 모듈에 의존합니다. 이러한 종속성은 배포를 단순화할 수 있지만, 오래되었거나 손상된 경우 잠재적 취약점을 초래할 수도 있습니다.
의존성을 지속적으로 스캔하면 인프라에 알려진 보안 취약점이 유입되는 것을 방지할 수 있습니다. 이를 위해 특별히 설계된 도구는 오래되거나 취약한 모듈을 자동으로 표시하고 팀이 필요에 따라 업데이트하도록 안내합니다. 이는 소프트웨어 패치 관리와 유사하지만, 인프라 모듈에 특별히 적용되어 최대의 보호와 복원력을 달성합니다.
4. 비밀 정보 보호
디지털 환경에는 비밀 정보가 노출되어 심각한 침해 사고로 이어진 경고 사례가 넘쳐납니다. IaC의 프로그래밍적 특성으로 인해 프로그래머들은 민감한 정보를 스크립트에 직접 하드코딩하고 싶은 유혹을 받게 됩니다. 이는 항상 피해야 할 무책임한 관행입니다.
조직은 HashiCorp Vault나 AWS Secrets Manager 같은 전용 비밀 관리 솔루션을 활용하여 비밀을 암호화된 상태로 안전하게 보호함으로써, IaC 스크립트 내에 비밀을 직접 내장하는 것을 피해야 합니다. 이렇게 하면 구성 파일이 공개적으로 노출되더라도 비밀이 보호될 수 있습니다.
5. 구성 효율적 검증 및 평가
IaC 스크립트의 기능성과 보안성을 동시에 보장하는 것은 지속적인 노력이 필요하며 정기적인 평가를 요구합니다. 구성 변경이나 IT 환경 변화에 따라 새로운 취약점이 발생하여 기존에 정상 작동하던 스크립트가 비정상적으로 작동하거나 완전히 중단될 수 있습니다.
조직은 이러한 상황을 방지하기 위해 IaC 구성이 업계 벤치마크 및 모범 사례를 정기적으로 준수하도록 해야 하며, 수동 개입 없이 자동화된 테스트 도구를 사용하여 정기적으로 점검해야 합니다. 프로덕션 환경에 변경 사항을 적용하기 전에 스테이징 또는 테스트 환경은 예상치 못한 문제에 대한 조기 경고를 제공하는 데 매우 중요하며, 프로덕션 환경에서 안전하면서도 운영 가능한 인프라를 보장하는 데 도움이 됩니다.
IaC의 일반적인 함정과 회피 방법
GitLab IaC 스캐닝의 일반적인 함정과 회피 방법?
- 인프라 코드를 일회성 스크립트로 취급하기
- 테스트 소홀히 하기
- 비밀 정보 및 인증 정보 하드코딩하기
- IaC 스크립트를 지나치게 복잡하게 만들기
- 사용 중단된 도구 또는 라이브러리 우회
1. 인프라 코드를 일회성 스크립트로 취급하기
인프라 코드(IaC)에 대한 흔한 오해 중 하나는 이를 한 번 작성한 후 거의 다시 살펴보지 않는 일회성 스크립트처럼 취급하는 것입니다. 그러나 일회성 스크립트와 달리 IaC는 다른 소프트웨어 코드와 마찬가지로 주기적인 유지 관리 업데이트, 수정 및 개정이 필요합니다.
예방 방법: GitLab IaC Scanning과 같은 도구를 사용하여 정기적인 코드 검토 및 업데이트를 수행하고 IaC 구성을 지속적으로 스캔하세요. 이렇게 하면 코드가 최신 상태를 유지하고 관련성을 확보하며 잠재적 취약점이 없도록 할 수 있습니다.&
2. 테스트 소홀
신속한 배포를 위해 서두르는 일부 팀은 철저한 IaC 스크립트 테스트를 생략하는 경우가 있습니다. 실행되면 모든 것이 정상이라고 생각하기 때문입니다. 이는 프로비저닝된 인프라에서 예상치 못한 동작이나 보안 취약점으로 이어질 수 있습니다. 이러한 소홀함은 예상치 못한 동작을 간과하게 하거나 배포 시 즉각적인 패치가 필요한 보안 구멍을 만들 수 있습니다.
예방 방법: 애플리케이션 코드와 마찬가지로 스테이징과 같은 비프로덕션 환경에서 IaC 구성을 테스트하는 것은 프로덕션 환경의 잘못된 구성과 잠재적 위험을 피하는 데 필수적입니다. GitLab IaC 스캐닝은 팀이 프로덕션 환경에 직접 영향을 미치기 전에 잘못된 구성을 식별할 수 있도록 하는 핵심 서비스를 제공합니다.&
3. 비밀 정보 및 인증 정보의 하드코딩
하드코딩은 IaC 스크립트에서 명백한 함정이 될 수 있으며, 데이터 보안을 위해 항상 피해야 합니다. 코드에 비밀 정보나 인증 정보를 직접 포함시키는 하드코딩은 간과해서는 안 될 중대한 보안 위협을 초래할 수 있습니다.
방지 방법: 스크립트에 비밀 정보를 직접 포함하는 대신 전용 비밀 관리 도구를 사용하십시오. GitLab IaC 스캐닝 도구는 스캐닝 프로세스의 일환으로 이러한 관행을 탐지할 수 있으며, 예를 들어 구성 파일 내 하드코딩된 자격 증명에 대해 개발자에게 경고할 수 있습니다.
4. IaC 스크립트 과도한 복잡화
모든 가능한 시나리오를 아우르는 단일 솔루션을 만들려는 과정에서 일부 엔지니어들은 IaC 스크립트 작성 시 지나치게 복잡하게 만드는 경향이 있습니다. 이는 다양한 상황을 더 효율적으로 처리할 수 있지만, 동시에 IaC 솔루션에 불필요한 복잡성과 잠재적 실패 지점을 생성합니다.
예방 방법: GitLab IaC 스캐닝을 활용해 복잡한 구성을 관리 가능한 모듈로 분할함으로써 단순성과 명확성을 우선시하십시오. GitLab IaC 스캐닝을 통해 이러한 모듈을 정기적으로 점검하여 효과적이고 안전하며 기능적으로 유지하십시오.
5. 사용 중단된 도구 또는 라이브러리 우회
IaC는 종종 타사 도구 또는 라이브러리에 의존합니다. 그러나 이러한 외부 리소스가 발전함에 따라 특정 기능이나 기능이 사용 중단될 수 있습니다. 오래된 방법을 사용하면 기능적 취약점과 보안 취약점 모두 발생할 수 있습니다.&
방지 방법: IaC 구성이 의존하는 모든 타사 도구 또는 라이브러리를 적극적으로 모니터링하고, 업데이트된 버전과 권장 사항을 반영하도록 스크립트를 정기적으로 업데이트하며, 구식 기능이나 종속성을 강조 표시하는 GitLab IaC Scanning과 같은 스캐닝 도구를 사용하십시오.
결론
GitLab IaC 스캔은 보안 취약점을 탐지하고 종속성을 처리할 수 있습니다. 오탐을 제거하고, 사용자 정의 규칙을 설정하며, 감사 추적을 유지할 수 있습니다. 보고 작업도 훨씬 편리해지며, 최상의 결과를 위해 GitLab IaC 스캐닝을 CI/CD 파이프라인에 쉽게 통합할 수 있습니다. GitLab IaC 스캐너로 비밀을 보호하고, 버전 관리 및 변경 추적을 유지하며, 최소 권한 원칙을 적용하세요. 원활한 인프라 관리를 위해 구성을 효율적으로 평가하고 관리하는 데 도움이 될 것입니다.
"GitLab IaC 스캐닝 FAQ
GitLab IaC 스캐닝은 Terraform, CloudFormation, Ansible, Dockerfile, Kubernetes 매니페스트와 같은 인프라스트럭처 코드(IaC) 파일을 검사하여 잘못된 구성 및 알려진 취약점을 확인하는 내장 CI/CD 기능입니다. 파이프라인의 테스트 단계에서 실행되며, JSON 형식의 SAST 보고서를 생성하고 머지 요청에서 문제를 강조 표시하여 배포 전에 위험한 설정을 수정할 수 있도록 합니다.
"IaC 스캔은 2021년 6월 출시된 GitLab 14.5에서 처음 도입되었습니다. 해당 버전부터는 프로젝트에 지원되는 IaC 구성 파일이 CI 파이프라인 중에 적절한 KICS 기반 분석기를 자동으로 트리거합니다. 단, .gitlab-ci.yml 에 IaC 템플릿을 포함해야 합니다.
GitLab의 IaC 스캐닝은 KICS로 구동되는 다양한 구성 파일을 지원합니다:
- Ansible 플레이북
- AWS CloudFormation (YAML/JSON)
- Azure Resource Manager (JSON)
- Dockerfiles
- Google Deployment Manager
- Kubernetes 매니페스트
- OpenAPI 정의
Terraform HCLBicep을 사용하는 경우 스캔 전에 JSON으로 컴파일해야 하며, 사용자 정의 레지스트리 Terraform 모듈은 아직 스캔되지 않음을 유의하십시오.
"GitLab의 모든 IaC 스캐닝 분석기는 KICS(Keep It Configuration Scanner)를 기반으로 합니다. KICS는 풍부한 규칙 세트를 사용하여 IaC 파일을 검사하는 오픈 소스 엔진입니다. KICS는 지원되는 형식을 자동으로 감지하고 적절한 검사를 적용하며, CI 변수 또는 사용자 정의 규칙 디렉터리를 통해 규칙 버전을 사용자 정의하거나 비활성화하거나 고정할 수 있습니다.
"IaC 스캔을 활성화하려면 프로젝트의 .gitlab-ci.yml 상단에 공식 템플릿을 추가하세요:
다음 줄을 추가하세요:
- template: Jobs/SAST-IaC.gitlab-ci.yml
이렇게 하면 테스트 단계에 iacs 작업이 삽입됩니다. GitLab.com 또는 공유 러너를 사용하는 자체 관리 환경에서는 추가 러너 설정이 필요하지 않습니다. 파이프라인 실행 후 스캔 결과는 작업 아티팩트, 병합 요청, 보안 및 규정 준수 아래에 표시됩니다.
"