소개

완료됨

인프라를 코드로 배포할 때 배포를 자동화하고, 배포에 대한 신뢰도를 개선하고, 팀 작업의 효율성을 높일 수 있습니다. 그러나 이러한 이점은 사용자와 팀이 성실하고 환경을 수동으로 변경하지 않는 경우에만 적용됩니다.

이 모듈에서는 예기치 않거나 제어되지 않는 변경을 방지하기 위해 Azure 환경과 파이프라인에 구성과 거버넌스를 적용하는 방법을 알아봅니다.

참고

파이프라인에 대한 GitHub Actions 용어는 워크플로입니다. 간단히 말해, 이 모듈 전체에서 파이프라인을 사용하여 Azure Pipelines의 파이프라인과 GitHub Actions의 워크플로를 나타냅니다.

예제 시나리오

장난감 회사에서 Azure 관리자로 일한다고 가정합니다. 지난 몇 개월 동안 사용자와 팀은 Bicep을 사용하도록 Azure 배포를 변환했습니다. 파이프라인을 사용하여 배포 프로세스를 자동화했습니다. 하지만 팀에는 아직 모든 변경 내용을 코드로 배포하는 사고방식을 채택하지 않은 몇몇 멤버가 있습니다.

최근에 사용자가 다양한 프로세스를 사용하여 Azure에 배포한 여러 가지 상황이 있었습니다.

  1. 누군가가 Azure Portal을 사용하여 웹 사이트의 구성을 직접 변경했습니다.
  2. 누군가가 자신의 컴퓨터에서 직접 새 Bicep 파일을 배포했습니다.
  3. 누군가가 파이프라인의 서비스 주체 자격 증명을 복사하고 Azure CLI를 사용하여 프로덕션 환경에 액세스하는 데 사용했습니다.
  4. 누군가가 끌어오기 요청 검토를 우회하여 리포지토리의 기본 분기에 직접 Bicep 파일 변경을 커밋했습니다.
  5. 누군가가 끌어오기 요청을 사용하여 Bicep 파일을 업데이트했습니다. 변경 내용은 환경의 올바른 시퀀스 동안 유효성 검사, 테스트 및 배포되었습니다.

다음 다이어그램은 이러한 단계를 보여 줍니다.

Diagram that shows several approaches to making Azure configuration changes.

모든 변경 내용 중에서 채택한 자동화 도구와 팀이 동의한 프로세스를 통해 5번만 배포되었습니다. 다른 변경 내용은 어떤 손상도 초래하지 않았지만 너무 자만하지 않으려고 합니다. 팀은 자동화에 대한 투자를 최대한 활용할 수 있도록 프로세스를 적용하기로 결정했습니다. 승인된 프로세스를 제외하고 Azure 환경에 배포하는 기능을 종료하기로 팀과 합의했습니다.

Diagram that shows several approaches to making Azure configuration changes, which are all blocked except for the approved process.

무엇을 해야 할까요?

이 모듈에서는 Azure 인프라를 코드로 강제 배포하는 방법을 알아봅니다. 각 환경에 적용해야 하는 컨트롤을 고려하고 거버넌스 및 보안 정책을 적용하여 Azure 리소스를 보호합니다. 또한 Azure 구성의 모든 측면이 권장되고 강화된 프로세스를 따르도록 하여 파이프라인과 리포지토리를 보호하는 방법을 알아봅니다.

이 모듈에서는 다양한 보안 기능을 소개합니다. 요약 단원에는 각 기능에 대한 자세한 내용의 링크가 있습니다.

주요 목표는 무엇인가요?

이 모듈을 마치면 Azure 환경, 리포지토리, 파이프라인에 적용해야 하는 보안 컨트롤과 거버넌스를 식별하여 모든 인프라를 코드로 배포할 수 있습니다.

필수 구성 요소

다음을 사용하는 방법을 잘 알고 있어야 합니다.

  • 코드로서 인프라와 그 이점, Bicep 또는 Terraform과 같은 기술.
  • Azure(Azure Portal, 구독, 리소스 그룹 및 리소스 정의 포함)
  • 분기, 끌어오기 요청을 포함하여 코드를 관리하기 위한 Git.
  • GitHub Actions 또는 Azure Pipelines를 통해 자동화된 배포.