편집

다음을 통해 공유


AKS(Azure Kubernetes Service)의 DevSecOps

Azure Boards
Azure DevOps
Azure Monitor
Azure Pipelines
Azure Policy

보안 DevOps라고도 하는 DevSecOps는 기존 DevOps 수명 주기의 여러 단계에서 보안을 통합하여 DevOps의 사례를 기반으로 합니다. DevOps 사례에서 보안을 구축하는 이점 중 일부는 다음과 같습니다.

  • 보안 위협에 대한 가시성을 제공하고 취약성이 배포된 환경에 도달하지 못하도록 방지하여 애플리케이션 및 시스템을 더욱 안전하게 만듭니다.
  • 개발 및 운영 팀을 통해 보안 인식 향상
  • 소프트웨어 개발 수명 주기에 자동화된 보안 프로세스 통합
  • 개발 및 디자인 단계 초기에 보안 문제를 찾아서 수정 비용 절감

DevSecOps가 AKS(Azure Kubernetes Service)에 적용되는 경우 다양한 조직 역할이 보안 구현에 대해 서로 다른 고려 사항을 가질 수 있습니다. 이러한 다양한 조직 역할의 예는 다음과 같습니다.

  • AKS에서 실행되는 보안 애플리케이션을 빌드하는 개발자
  • 보안 AKS 인프라를 구축하는 클라우드 엔지니어
  • 클러스터를 제어하거나 보안 문제를 모니터링할 수 있는 다양한 운영 팀

이 문서는 보안 제어 및 보안 모범 사례를 포함하기 위한 고려 사항 및 권장 사항을 사용하여 다양한 DevOps 수명 주기 단계로 나뉩니다. 이 가이드에는 CI/CD(지속적인 통합 및 지속적인 업데이트) 파이프라인에 통합하는 일반적인 프로세스 및 도구가 포함되어 있으며, 사용 가능한 경우 사용하기 쉬운 기본 제공 도구를 선택합니다.

이 문서의 필수 구성 요소로 DevOps 및 GitOps를 사용하여 AKS에서 빌드 및 배포 앱을 검토하는 것이 좋습니다.

프로세스 흐름

아키텍처 다이어그램은 개발자에서 최종 사용자로의 흐름과 AKS의 DevSecOps를 사용할 수 있는 위치를 보여 줍니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

참고 항목

이 문서에서는 AKS 및 GitHub를 참조하지만 이러한 권장 사항은 컨테이너 오케스트레이션 또는 CI/CD 플랫폼에 적용됩니다. 구현 세부 정보는 다를 수 있지만 각 단계에서 멘션 대부분의 개념과 사례는 여전히 관련성이 있으며 적용 가능합니다.

  1. Microsoft Entra ID 는 GitHub의 ID 공급자로 구성됩니다. 추가 인증 보안을 제공하도록 MFA(다단계 인증)를 구성합니다.
  2. 개발자는 보안 확장이 활성화된 Visual Studio Code 또는 Visual Studio를 사용하여 보안 취약성에 대한 코드를 사전에 분석합니다.
  3. 개발자는 애플리케이션 코드를 회사 소유 및 관리되는 GitHub Enterprise 리포지토리에 커밋합니다.
  4. GitHub Enterprise는 GitHub Advanced Security를 통해 자동 보안 및 종속성 검사를 통합합니다.
  5. 끌어오기 요청은 GitHub Actions를 통해 CI(연속 통합) 빌드 및 자동화된 테스트를 트리거합니다.
  6. GitHub Actions를 통한 CI 빌드 워크플로는 Azure Container Registry에 저장된 Docker 컨테이너 이미지를 생성합니다.
  7. GitHub Actions의 CD(지속적인 업데이트) 워크플로의 일부로 프로덕션과 같은 특정 환경에 배포에 대한 수동 승인을 도입할 수 있습니다.
  8. GitHub Actions는 AKS에 CD를 사용하도록 설정합니다. GitHub Advanced Security를 사용하여 애플리케이션 원본 및 구성 파일에서 비밀, 자격 증명 및 기타 중요한 정보를 검색합니다.
  9. Microsoft Defender는 Azure Container Registry, AKS 클러스터 및 Azure Key Vault에서 보안 취약성을 검사하는 데 사용됩니다.
    1. 컨테이너용 Microsoft Defender는 컨테이너 이미지를 컨테이너 레지스트리에 업로드할 때 알려진 보안 취약성을 검사합니다.
    2. 컨테이너용 Defender를 사용하여 AKS 환경의 검사를 수행하고 AKS 클러스터에 대한 런타임 위협 방지 기능을 제공합니다.
    3. Key Vault 용 Microsoft Defender는 키 자격 증명 모음 계정에 액세스하려는 유해하고 비정상적이며 의심스러운 시도를 감지합니다.
  10. 정책 준수 및 적용을 위해 Azure Policy 를 Container Registry 및 AKS(Azure Kubernetes Service)에 적용할 수 있습니다. 컨테이너 레지스트리 및 AKS에 대한 일반적인 보안 정책은 빠른 사용을 위해 기본 제공됩니다.
  11. Azure Key Vault 는 런타임에 애플리케이션에 비밀 및 자격 증명을 안전하게 삽입하여 중요한 정보를 개발자와 분리하는 데 사용됩니다.
  12. AKS 네트워크 정책 엔진은 Kubernetes 네트워크 정책을 사용하여 애플리케이션 Pod 간의 트래픽을 보호하도록 구성됩니다.
  13. AKS 클러스터의 지속적인 모니터링은 Azure MonitorContainer Insights를 사용하여 성능 메트릭을 수집하고 애플리케이션 및 보안 로그를 분석하여 설정할 수 있습니다.
    1. 컨테이너 인사이트는 성능 메트릭과 애플리케이션 및 클러스터 로그를 검색합니다.
    2. 진단 및 애플리케이션 로그는 로그 쿼리를 실행하기 위해 Azure Log Analytics 작업 영역으로 가져옵니다.
  14. SIEM(보안 정보 및 이벤트 관리) 솔루션인 Microsoft Sentinel을 사용하여 정의된 패턴 및 규칙에 따라 보안 위협에 대한 AKS 클러스터 로그를 수집하고 추가로 분석할 수 있습니다.
  15. ZAP(Zed Attack Proxy)와 같은 오픈 소스 도구를 사용하여 웹 애플리케이션 및 서비스에 대한 침투 테스트를 수행할 수 있습니다.
  16. 클라우드용 Defender 사용할 수 있는 서비스인 DevOps용 Defender는 보안 팀이 GitHub 및 Azure DevOps를 비롯한 다중 파이프라인 환경에서 DevOps 보안을 관리할 수 있도록 합니다.

팀 구성원 개요 및 책임

Kubernetes 기반 솔루션 배포에서 DevSecOps의 복잡성을 문제 분리로 관리하는 것이 좋습니다. 배포의 각 측면에 관심을 가져야 하는 엔터프라이즈 환경의 팀은 무엇입니까? 팀이 목표를 가장 잘 달성하기 위해 사용해야 하는 도구와 프로세스는 무엇인가요? 이 섹션에서는 개발자, 애플리케이션 운영자(사이트 안정성 엔지니어), 클러스터 운영자 및 보안 팀의 일반적인 역할을 설명합니다.

개발자

개발자는 애플리케이션 코드를 작성할 책임이 있습니다. 또한 지정된 리포지토리에 코드를 커밋할 책임이 있습니다. 개발자의 중요한 책임 중 하나에는 코드가 의도한 대로 작동하고 나머지 애플리케이션과 원활하게 통합되도록 자동화된 테스트를 위한 스크립트 작성 및 실행이 포함됩니다. 또한 자동화 파이프라인의 일부로 컨테이너 이미지 빌드를 정의하고 스크립션합니다.

애플리케이션 운영자(사이트 안정성 엔지니어)

컨테이너 및 Kubernetes를 사용하여 클라우드에서 애플리케이션을 빌드하면 애플리케이션 개발, 배포 및 확장성을 간소화할 수 있습니다. 그러나 이러한 개발 접근 방식은 관리를 복잡하게 만드는 점점 더 분산된 환경을 만듭니다. 사이트 안정성 엔지니어는 대규모 소프트웨어 시스템의 감독을 자동화하는 솔루션을 빌드합니다. 개발 및 클러스터 운영자 팀 간의 브리지 역할을 하며 서비스 수준 목표와 오류 예산을 설정하고 모니터링하는 데 도움이 됩니다. 이러한 방식으로 애플리케이션 배포를 관리하고 YAML(Kubernetes 매니페스트) 파일을 작성하는 데 도움이 됩니다.

클러스터 연산자

클러스터 운영자는 클러스터 인프라를 구성하고 관리하는 역할을 담당합니다. 종종 GitOps와 같은 IaC(인프라를 코드) 모범 사례 및 프레임워크로 사용하여 클러스터를 프로비전하고 기본. Azure Monitor 컨테이너 인사이트 및 Prometheus/Grafana와 같은 다양한 모니터링 도구를 사용하여 전체 클러스터 상태를 모니터링합니다. 클러스터에 대한 패치, 클러스터 업그레이드, 권한 및 역할 기반 액세스 제어를 담당합니다. DevSecOps 팀에서는 클러스터가 팀의 보안 요구 사항을 충족하는지 확인하고 보안 팀과 협력하여 이러한 표준을 만듭니다.

보안 팀

보안 팀은 보안 표준을 개발하고 적용할 책임이 있습니다. 일부 팀은 클러스터를 보유한 구독 및 리소스 그룹에 적용되는 Azure Policy를 만들고 선택할 책임이 있을 수 있습니다. 보안 문제를 모니터링하고 다른 팀과 함께 보안이 DevSecOps 프로세스의 모든 단계의 최전선에 있는지 확인합니다.

DevSecOps 수명 주기 단계

보안 제어는 SDLC(소프트웨어 개발 수명 주기)의 각 단계에서 구현됩니다. 이 구현은 DevSecOps 전략과 왼쪽 이동 방식의 핵심 요소입니다.

아키텍처 다이어그램은 개발자에서 최종 사용자로의 흐름과 AKS의 DevSecOps를 사용할 수 있는 위치를 보여 줍니다.

이 아키텍처의 Visio 파일을 다운로드합니다.

계획 단계

계획 단계는 일반적으로 자동화의 양이 적지만 나중에 DevOps 수명 주기 단계에 큰 영향을 주는 중요한 보안 영향을 줍니다. 이 단계에는 보안, 개발 및 운영 팀 간의 협업이 포함됩니다. 이 디자인 및 계획 단계에서 보안 관련자를 포함하면 보안 요구 사항 및 보안 문제를 적절하게 고려하거나 완화할 수 있습니다.

모범 사례 – 보다 안전한 애플리케이션 플랫폼 설계

보다 안전한 AKS 호스팅 플랫폼을 구축하는 것은 플랫폼 자체부터 시작하여 모든 계층에서 보안이 시스템에 기본 제공되도록 하는 중요한 단계입니다. 플랫폼에는 클러스터 내부 구성 요소(예: 런타임 보안 및 정책 에이전트) 및 AKS 외부에 있는 구성 요소(예: 네트워크 방화벽 및 컨테이너 레지스트리)가 포함될 수 있습니다. 자세한 내용은 보안, ID 및 네트워크 토폴로지와 같은 중요한 디자인 영역을 포함하는 AKS 랜딩 존 가속기를 참조하세요.

모범 사례 – 프로세스에 위협 모델링 빌드

  • 위협 모델링은 일반적으로 보안 및 개발 팀을 포함하는 수동 작업입니다. 시스템 내에서 위협을 모델링하고 찾는 데 사용되므로 코드를 개발하거나 시스템을 변경하기 전에 취약성을 해결할 수 있습니다. 위협 모델링은 중요한 소프트웨어 변경, 솔루션 아키텍처 변경 또는 보안 인시던트 등의 이벤트에 의해 트리거되는 다른 시간에 발생할 수 있습니다.
  • STRIDE 위협 모델을 사용하는 것이 좋습니다. 이 방법론은 데이터 흐름 다이어그램으로 시작하고 STRIDE 니모닉(스푸핑, 변조, 정보 공개, 거부, 서비스 거부 및 권한 상승) 위협 범주를 사용하여 팀이 위험을 식별, 완화 및 유효성을 검사할 수 있도록 합니다. 또한 시스템 구성 요소, 데이터 흐름 및 보안 경계를 표시하고 시각화하는 모델링 도구도 포함되어 있습니다. SDLC 프로세스에 위협 모델링을 구축하면 업데이트된 위협 모델을 기본 위해 새로운 프로세스와 더 많은 작업이 도입됩니다. 그러나 보안이 조기에 배치되도록 보장하여 이후 SDLC 단계에서 발견된 보안 문제를 처리하는 잠재적 비용을 줄이는 데 도움이 됩니다.

모범 사례 – WAF(Azure Well Architect Framework) 적용

  • 클라우드 네이티브 환경에 적용되는 ID 관리, 애플리케이션 보안, 인프라 보호, 날짜 보안 및 DevOps와 같은 사항에 대한 지침을 제공하는 WAF 보안 핵심 모범 사례를 적용합니다.
  • DEVSecOps 및 프로덕션 환경 모니터링에 적용되는 WAF 운영 모범 사례를 적용합니다.

개발 단계

"왼쪽으로 이동"은 DevSecOps 사고 방식의 핵심 테넌트입니다. 이 프로세스는 코드가 리포지토리에 커밋되고 파이프라인을 통해 배포되기 전에 시작됩니다. 개발 단계에서 보안 코딩 모범 사례를 채택하고 코드 분석에 IDE 도구 및 플러그 인을 사용하면 더 쉽게 해결할 수 있는 개발 수명 주기의 앞부분에서 보안 문제를 해결하는 데 도움이 될 수 있습니다.

모범 사례 – 보안 코딩 표준 적용

  • 설정된 보안 코딩 모범 사례 및 검사 목록을 사용하면 삽입 및 안전하지 않은 디자인과 같은 일반적인 취약성으로부터 코드를 보호할 수 있습니다. OWASP 재단은 코드를 작성할 때 채택해야 하는 업계 표준 보안 코딩 권장 사항을 게시합니다. 이러한 지침은 공용 웹 애플리케이션 또는 서비스를 개발할 때 특히 중요합니다.
  • 일반적인 보안 모범 사례 외에도 Java 및 .NET과 같은 특정 프로그래밍 언어 런타임에 대한 보안 코딩 방법도 살펴봐야 합니다.
  • 로깅 표준을 적용하여 중요한 정보가 애플리케이션 로그로 유출되지 않도록 보호할 수 있습니다. log4j 및 log4net과 같은 가장 인기 있는 로깅 프레임워크는 계정 번호 또는 개인 데이터와 같은 중요한 정보를 마스킹하는 필터 및 플러그 인을 제공합니다.

모범 사례 – IDE 도구 및 플러그 인을 사용하여 보안 검사 자동화

Visual Studio, Visual Studio Code, IntelliJ IDEA 및 Eclipse와 같은 가장 인기 있는 IDE는 애플리케이션 코드를 작성하는 동안 발생할 수 있는 잠재적 보안 문제에 대한 즉각적인 피드백과 권장 사항을 가져오는 데 사용할 수 있는 확장을 지원합니다.

  • SonarLint 는 가장 인기 있는 언어 및 개발자 환경에서 사용할 수 있는 IDE 플러그 인입니다. SonarLint는 중요한 피드백을 제공하고 코드를 자동으로 검사하여 일반적인 프로그래밍 오류 및 잠재적인 보안 문제를 확인합니다.
  • 기타 무료 및 상업용 플러그 인은 OWASP 상위 10개 일반적인 취약성과 같은 보안 특정 항목에 중점을 둡니다. 예를 들어 Synk 플러그 인은 애플리케이션 원본 및 타사 종속성을 검사하고 취약성이 발견되면 경고합니다.
  • Visual Studio 및 Visual Studio Code용 SARIF(정적 분석 결과 교환 형식) 플러그 인을 사용하면 원시 JSON 출력 파일의 결과를 해석하는 것과 비교하여 직관적이고 읽기 쉬운 방식으로 인기 있는 SAST(정적 애플리케이션 보안 테스트) 도구의 취약성을 쉽게 볼 수 있습니다.

모범 사례 – 소스 코드 리포지토리에 대한 컨트롤 설정

  • 엔터프라이즈 전체에서 분기를 일관되게 사용할 수 있도록 분기 방법론을 설정합니다. 릴리스 흐름 및 GitHub 흐름같은 방법론에는 분기를 사용하여 팀 및 병렬 개발을 지원하는 방법에 대한 구조적 지침이 있습니다. 이러한 방법론을 통해 팀은 코드 커밋 및 CI/CD 워크플로에 병합하기 위한 표준 및 제어를 설정할 수 있습니다.
  • 기본 같은 특정 분기는 애플리케이션 소스 코드의 무결성을 유지하는 오래 지속되는 분기입니다. 이러한 분기는 변경 내용을 병합하거나 커밋하기 전에 병합 정책을 설정해야 합니다. 몇 가지 모범 사례는 다음과 같습니다.
    • 다른 개발자가 코드를 기본 분기에 직접 커밋하지 못하도록 합니다.
    • 피어 검토 프로세스를 설정하고 변경 내용을 기본 분기에 병합하기 전에 최소 승인 수가 필요합니다. GitHub를 사용하여 이러한 컨트롤을 쉽게 구성하고 적용할 수 있습니다. 또한 GitHub를 사용하면 제어된 환경에 필요한 경우 승인된 승인자 그룹을 지정할 수 있습니다.
  • 사전 커밋 후크를 사용하여 애플리케이션 소스 코드 내에서 중요한 정보를 검사 보안 문제가 발견되면 커밋이 발생하지 않도록 방지합니다.
    • 특정 프로젝트에 대해 쉽게 구성할 수 있는 GitHub 제공 기본 제공 사전 커밋 후크를 사용합니다. 예를 들어 비밀, 프라이빗 키 및 자격 증명을 검색하고 이러한 문제가 발견되면 커밋을 방지하기 위해 미리 빌드된 후크가 있습니다.
  • 버전 제어 시스템 내에서 역할 기반 액세스 제어를 설정합니다.
    • 최소 권한 원칙을 사용하여 잘 정의된 역할을 만듭니다. CI/CD 파이프라인은 프로덕션 배포를 위한 공급망입니다.
    • 조직 내에서 설정된 사용자 또는 그룹 역할을 적용합니다. CI/CD 워크플로와 관련된 특정 역할 및 기능에 따라 개인을 그룹화하려면 관리, 개발자, 보안 관리자 및 운영자와 같은 역할을 만들어야 합니다.
  • CI/CD 파이프라인과 관련하여 구성 및 기타 변경 내용에 대한 투명성과 추적 가능성이 있도록 워크플로 감사를 사용하도록 설정합니다.

모범 사례 – 컨테이너 이미지 보호

  • OS 공간을 최소화한 경량 이미지를 사용하여 전체 표면 공격 영역을 줄입니다. Alpine과 같은 최소한의 이미지 또는 애플리케이션 및 관련 런타임만 포함하는 배포판이 없는 이미지를 고려합니다. Microsoft 오픈 소스 Linux 배포판인 Mariner는 AKS가 컨테이너화된 워크로드를 호스트하도록 설계된 가볍고 강화된 배포판입니다.
  • 컨테이너를 빌드할 때 신뢰할 수 있는 기본 이미지만 사용합니다. 이러한 기본 이미지는 취약성을 자주 검색하는 프라이빗 레지스트리에서 검색해야 합니다.
  • 개발자 도구를 사용하여 이미지 취약성을 로컬로 평가합니다.
    • Trivy 는 컨테이너 이미지 내의 보안 취약성을 분석하는 데 사용할 수 있는 오픈 소스 도구의 예입니다.
  • 이미지에 대한 루트 사용자 액세스/컨텍스트를 방지합니다. 기본적으로 컨테이너는 루트로 실행됩니다.
    • 보안 강화가 필요한 컨테이너의 경우 Kubernetes 클러스터 내에서 AppArmor 프로필을 사용하여 실행 중인 컨테이너에 대한 보안을 추가로 적용하는 것이 좋습니다.

빌드 단계

빌드 단계에서 개발자는 사이트 안정성 엔지니어 및 보안 팀과 협력하여 CI 빌드 파이프라인 내에서 애플리케이션 원본의 자동화된 검사를 통합합니다. 파이프라인은 CI/CD 플랫폼의 보안 도구 및 확장을 사용하여 SAST, SCA 및 비밀 검색과 같은 보안 사례를 사용하도록 구성됩니다.

모범 사례 – SAST(정적 코드 분석)를 수행하여 애플리케이션 소스 코드에서 잠재적 취약성 찾기

  • 코드 검색 및 CodeQL에 GitHub 고급 보안 검색 기능을 사용합니다.
    • 코드 검색 은 GitHub 리포지토리의 코드를 분석하여 보안 취약성 및 코딩 오류를 찾는 데 사용하는 기능입니다. 분석으로 식별되는 모든 문제는 GitHub Enterprise Cloud에 표시됩니다.
    • 코드 검색에서 코드에서 잠재적 취약성 또는 오류를 발견하면 GitHub는 리포지토리에 경고를 표시합니다.
    • 상태 확인 필요 대한 분기 규칙을 구성하여 새 코드를 병합하기 전에 기능 분기 베이스 분기 최신 상태로 유지되도록 할 수도 있습니다. 이렇게 하면 분기가 항상 최신 코드로 테스트됩니다.
  • kube 점수와 같은 도구를 사용하여 Kubernetes 배포 개체를 분석합니다.
    • kube 점수는 Kubernetes 개체 정의의 정적 코드 분석을 수행하는 도구입니다.
    • 출력은 애플리케이션을 보다 안전하고 복원력 있게 만들기 위해 개선할 수 있는 권장 사항의 목록입니다.

모범 사례 – 실수로 리포지토리에 커밋된 비밀의 사기성 사용을 방지하기 위해 비밀 검사를 수행합니다.

  • 리포지토리에 대해 비밀 검사를 사용하도록 설정하면 GitHub는 코드에서 많은 서비스 공급자가 사용하는 비밀과 일치하는 패턴을 검색합니다.
  • 또한 GitHub는 리포지토리의 기존 콘텐츠에 대한 전체 git 기록 검사를 주기적으로 실행하고 경고 알림을 보냅니다.
    • Azure DevOps의 경우 클라우드용 Defender 비밀 검색을 사용하여 소스 코드 및 빌드 출력에서 자격 증명, 비밀, 인증서 및 기타 중요한 콘텐츠를 검색합니다.
    • 비밀 검사는 Azure DevOps용 Microsoft Security DevOps 확장의 일부로 실행할 수 있습니다.

모범 사례 – SCA(소프트웨어 컴퍼지션 분석) 도구를 사용하여 코드베이스에서 오픈 소스 구성 요소를 추적하고 종속성 취약성을 검색합니다.

  • 종속성 검토를 사용하면 환경에 적용하기 전에 안전하지 않은 종속성을 파악하고 라이선스, 종속성 및 종속성에 대한 정보를 제공합니다. 끌어오기 요청의 “변경된 파일” 탭에서 서식 있는 Diff로 종속성 변경 내용을 쉽게 이해할 수 있습니다.
  • Dependabot은 검색을 수행하여 안전하지 않은 종속성을 검색하고 GitHub 권고 데이터베이스에 새 권고가 추가되거나 리포지토리 변경에 대한 종속성 그래프 때 Dependabot 경고를 보냅니다.

모범 사례 – IaC(Infrastructure as Code) 템플릿의 보안 검색을 사용하도록 설정하여 프로덕션 환경에 도달하는 클라우드 구성 오류를 최소화합니다.

  • 개발 수명 주기 동안 클라우드 리소스 구성을 사전에 모니터링합니다.
  • DevOps용 Microsoft Defender 는 GitHub 및 Azure DevOps 리포지토리를 모두 지원합니다.

모범 사례 – 컨테이너 레지스트리의 워크로드 이미지를 검사하여 알려진 취약성 식별

  • Defender for Containers 는 Container Registry 및 Amazon AWS ECR(Elastic Container Registry)의 컨테이너를 검사하여 이미지에 알려진 취약성이 있는지 알립니다.
  • Azure Policy 를 사용하여 Container Registry에 저장된 모든 이미지에 대한 취약성 평가를 수행하고 각 검색에 대한 자세한 정보를 제공할 수 있습니다.

모범 사례 – 기본 이미지 업데이트에 새 이미지 자동 빌드

  • Azure Container Registry 작업은 컨테이너 이미지를 빌드할 때 기본 이미지 종속성을 동적으로 검색합니다. 따라서 애플리케이션 이미지의 기본 이미지가 업데이트되는 시기를 감지할 수 있습니다. 미리 구성된 빌드 작업 하나를 사용하여 Container Registry 작업은 기본 이미지를 참조하는 모든 애플리케이션 이미지를 자동으로 다시 빌드할 수 있습니다.

모범 사례 – Container Registry, Azure Key Vault 및 표기법을 사용하여 컨테이너 이미지에 디지털 서명하고 AKS 클러스터를 구성하여 유효성이 검사된 이미지만 허용

  • Azure Key Vault는 표기법 키 자격 증명 모음 플러그 인(azure-kv)과 함께 표기법으로 사용할 수 있는 서명 키를 저장하여 컨테이너 이미지 및 기타 아티팩트를 서명하고 확인합니다. Container Registry를 사용하면 Azure CLI 명령을 사용하여 이러한 서명을 연결할 수 있습니다.
  • 서명된 컨테이너를 사용하면 사용자가 신뢰할 수 있는 엔터티에서 배포가 빌드되었는지 확인하고 아티팩트가 생성된 이후로 변조되지 않았는지 확인할 수 있습니다. 서명된 아티팩트를 사용하면 사용자가 아티팩트를 모든 환경으로 끌어오기 전에 무결성과 신뢰성이 보장되어 공격을 방지할 수 있습니다.
    • Ratify 를 사용하면 Kubernetes 클러스터가 배포 전에 아티팩트 보안 메타데이터를 확인하고 사용자가 만든 허용 정책을 준수하는 클러스터만 배포를 허용할 수 있습니다.

배포 단계

배포 단계에서 개발자, 애플리케이션 운영자 및 클러스터 운영자 팀은 보다 안전하고 자동화된 방식으로 프로덕션 환경에 코드를 배포하기 위해 CD(지속적인 배포) 파이프라인에 적합한 보안 제어를 설정하기 위해 함께 작업합니다.

모범 사례 – 배포 파이프라인의 액세스 및 워크플로 제어

  • 분기 보호 규칙을 설정하여 중요한 분기를 보호할 수 있습니다. 이러한 규칙은 공동 작업자가 분기를 삭제하거나 강제 푸시 수 있는지 여부를 정의합니다. 또한 상태 확인 통과 또는 선형 커밋 기록과 같은 분기 푸시에 대한 요구 사항을 설정합니다.
  • 배포에 환경을 사용하면 보호 규칙 및 비밀로 환경을 구성할 수 있습니다.
  • 승인Gates 기능을 활용하여 배포 파이프라인의 워크플로를 제어할 수 있습니다. 예를 들어 프로덕션 환경에 배포하기 전에 보안 또는 운영 팀의 수동 승인을 요구할 수 있습니다.

모범 사례 – 배포 자격 증명 보호

  • OIDC(OpenID 커넥트)를 사용하면 GitHub Action 워크플로가 Azure 자격 증명을 수명이 긴 GitHub 비밀로 저장할 필요 없이 Azure의 리소스에 액세스할 수 있습니다.
  • 배포에 환경을 사용하면 보호 규칙 및 비밀로 환경을 구성할 수 있습니다.
    • GitOps를 사용하는 CI/CD에 대한 풀 기반 접근 방식을 사용하면 보안 자격 증명을 Kubernetes 클러스터로 전환할 수 있으므로 외부 CI 도구에 자격 증명이 저장되지 않도록 제거하여 보안 및 위험 노출 영역을 줄일 수 있습니다. 허용된 인바운드 연결을 줄이고 Kubernetes 클러스터에 대한 관리자 수준 액세스를 제한할 수도 있습니다.

모범 사례 – DAST(동적 애플리케이션 보안 테스트)를 실행하여 실행 중인 애플리케이션에서 취약성 찾기

  • 배포 워크플로에서 GitHub Actions 를 사용하여 DAST(동적 애플리케이션 보안 테스트) 테스트를 실행합니다.
  • ZAP와 같은 오픈 소스 도구를 사용하여 일반적인 웹 애플리케이션 취약성에 대한 침투 테스트를 수행합니다.

모범 사례 – 신뢰할 수 있는 레지스트리에서만 컨테이너 이미지 배포

  • Defender for Containers를 사용하여 Kubernetes에 대한 Azure Policy 추가 기능을 사용하도록 설정합니다.
  • 컨테이너 이미지를 신뢰할 수 있는 레지스트리에서만 배포할 수 있도록 Azure Policy를 사용하도록 설정합니다.

작동 단계

이 단계에서는 잠재적인 보안 인시던트에 대해 사전에 모니터링, 분석 및 경고하기 위해 작업 모니터링 및 보안 모니터링 작업을 수행합니다. Azure Monitor 및 Microsoft Sentinel과 같은 프로덕션 관찰 도구는 엔터프라이즈 보안 표준을 모니터링하고 준수하는 데 사용됩니다.

모범 사례 – 클라우드용 Microsoft Defender를 사용하여 프로덕션 구성의 자동 검사 및 모니터링 사용

  • 지속적인 검사를 실행하여 애플리케이션의 취약성 상태에서 드리프트를 감지하고 취약한 이미지를 패치하고 대체하는 프로세스를 구현합니다.
  • 운영 체제에 대한 자동화된 구성 모니터링을 구현합니다.
    • 클라우드용 Microsoft Defender 컨테이너 권장 사항(컴퓨팅 및 앱 섹션 아래)을 사용하여 AKS 클러스터에 대한 기준 검색을 수행합니다. 구성 문제 또는 취약성이 발견되면 클라우드용 Microsoft Defender 대시보드에서 알림을 받습니다.
    • 클라우드용 Microsoft Defender 사용하고 네트워크 보호 권장 사항을 따라 AKS 클러스터에서 사용하는 네트워크 리소스를 보호합니다.
  • Container Registry에 저장된 이미지에 대한 취약성 평가를 수행합니다.

모범 사례 – Kubernetes 클러스터를 업데이트된 상태로 유지

  • Kubernetes 릴리스는 자주 롤아웃됩니다. 지원에서 뒤처지지 않도록 수명 주기 관리 전략을 마련하는 것이 중요합니다. AKS는 이 업그레이드 프로세스를 관리할 수 있는 도구와 유연성을 제공하는 관리되는 제품입니다. AKS 플랫폼의 계획된 기본 테넌트 기능을 사용하여 기본 테넌트 창 및 업그레이드를 더 자세히 제어할 수 있습니다.
  • AKS 작업자 노드를 더 자주 업그레이드해야 합니다. 더 많은 제어 및 포괄적인 업데이트를 위해 무인 모드 또는 Azure CLI를 통해 자동으로 적용할 수 있는 주간 OS 및 런타임 업데이트를 제공합니다.

모범 사례 – Azure Policy를 사용하여 AKS 클러스터 보호 및 관리

  • AKS용 Azure Policy 추가 기능을 설치한 후 개별 정책 정의 또는 이니셔티브(정책 집합이라고도 함)라는 정책 정의 그룹을 클러스터에 적용할 수 있습니다.
  • 권한 있는 컨테이너가 실행되지 않도록 방지하거나 허용 목록에 있는 외부 IP만 승인하는 것과 같은 일반적인 시나리오에는 기본 제공 Azure 정책을 사용합니다. 특정 사용 사례에 대한 사용자 지정 정책을 만들 수도 있습니다.
  • 클러스터에 정책 정의를 적용하고 해당 할당이 적용되고 있는지 확인합니다.
  • Gatekeeper를 사용하여 지정된 규칙에 따라 배포를 허용하거나 거부하는 허용 컨트롤러를 구성합니다. Azure Policy는 Gatekeeper를 확장합니다.
  • AKS에서 네트워크 정책을 사용하여 워크로드 Pod 간의 트래픽을 보호합니다.
    • 네트워크 정책 엔진을 설치하고 Kubernetes 네트워크 정책을 만들어 AKS의 Pod 간 트래픽 흐름을 제어합니다. 네트워크 정책은 AKS의 Linux 기반 또는 Windows 기반 노드 및 Pod에 사용할 수 있습니다.

모범 사례 – 지속적인 모니터링 및 경고를 위해 Azure Monitor 사용

  • Azure Monitor를 사용하여 AKS에서 로그 및 메트릭을 수집합니다. 애플리케이션 및 인프라의 가용성 및 성능에 대한 인사이트를 얻습니다. 또한 신호에 대한 액세스를 제공하여 솔루션의 상태를 모니터링하고 비정상적인 작업을 조기에 발견합니다.
    • Azure Monitor를 사용하는 지속적인 모니터링은 모니터링 데이터를 기반으로 릴리스 파이프라인을 게이트 또는 롤백 릴리스로 확장합니다. 또한 Azure Monitor는 보안 로그를 수집하고 의심스러운 활동에 대해 경고할 수 있습니다.
    • AKS 인스턴스를 Azure Monitor에 온보딩하고 클러스터에 대한 진단 설정을 구성합니다.
      • Azure Kubernetes Service에 대한 Azure 보안 기준을 참조하세요.

모범 사례 – 활성 위협 모니터링에 클라우드용 Microsoft Defender 사용

  • 클라우드용 Microsoft Defender 노드 수준(VM 위협)과 내부에서 AKS에 대한 활성 위협 모니터링을 제공합니다.
  • Defender for DevOps는 포괄적인 가시성을 위해 사용해야 하며 보안 및 운영자 팀에게 모든 CI/CD 파이프라인에 대한 중앙 집중식 대시보드를 제공해야 합니다. 이 기능은 Azure DevOps 및 GitHub와 같은 다중 파이프라인 플랫폼을 사용하거나 퍼블릭 클라우드에서 파이프라인을 실행하는 경우에 특히 유용합니다.
  • Key Vault용 Defender를 사용하여 키 자격 증명 모음 계정에 액세스하려는 비정상적이고 의심스러운 시도를 감지하고 구성에 따라 관리자에게 경고할 수 있습니다.
  • Defender for Containers는 Container Registry에 저장된 컨테이너 이미지 내에서 발견된 취약성에 대해 경고할 수 있습니다.

모범 사례 – 중앙 집중식 로그 모니터링을 사용하도록 설정하고 SIEM 제품을 사용하여 실시간 보안 위협 모니터링

  • AKS 진단 로그를 커넥트 패턴 및 규칙에 따라 중앙 집중식 보안 모니터링을 위해 Microsoft Sentinel에 로그를 보냅니다. Sentinel을 사용하면 데이터 커넥터를 통해 원활하게 액세스할 수 있습니다.

모범 사례 – 감사 로깅을 사용하도록 설정하여 프로덕션 클러스터에서 작업 모니터링

  • 활동 로그를 사용하여 AKS 리소스에 대한 작업을 모니터링하여 모든 활동 및 해당 상태 봅니다. 리소스에 대해 수행된 작업과 해당 리소스에 의해 수행된 작업을 결정합니다.
  • CoreDNS 사용자 지정 ConfigMap에서 문서화된 구성을 적용하여 DNS 쿼리 로깅을 사용하도록 설정합니다.
  • 비활성화된 자격 증명에 대한 액세스 시도를 모니터링합니다.

모범 사례 – Azure 리소스에서 진단 사용

  • 모든 워크로드의 리소스에서 Azure 진단 사용하도록 설정하면 Azure 리소스에 대한 자세한 진단 및 감사 정보를 제공하는 플랫폼 로그에 액세스할 수 있습니다. 이러한 로그는 보안 모니터링 및 경고를 위해 Log Analytics 또는 Microsoft Sentinel과 같은 SIEM 솔루션으로 수집할 수 있습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

기타 기여자:

다음 단계