Azure Key Vault를 사용하여 MSIX 및 CI/CD 파이프라인 서명MSIX and CI/CD Pipeline signing with Azure Key Vault

서명은 MSIX 패키지로 작업할 때 수행해야 하는 중요한 작업 중 하나입니다.Signing is one of the critical tasks to perform when you're working with MSIX packages. MSIX 패키지가 신뢰할 수 있는 인증서로 서명되지 않은 경우 사용자는 애플리케이션을 설치할 수 없습니다.If a MSIX package isn't signed with a trusted certificate, users won't be able to install the application. 동시에 서명은 보안과 관련하여 가장 중요한 작업 중 하나입니다.At the same time, signing is one of the most critical tasks also when it comes to security. 악의적인 행위자가 인증서를 다시 사용하여 우리의 ID로 애플리케이션에 서명하지 않도록 인증서를 안전하게 저장해야 합니다.Certificates must be safely stored, to avoid that malicious actors could reuse them to sign their applications with our identity. Azure Key Vault는 이 요구 사항을 지원하는 최상의 옵션입니다.Azure Key Vault is the best option to support this requirement.

이 문서에서는 프로세스의 일부로 MSIX 패키지에 자동으로 서명할 수 있도록 CI/CD 파이프라인에서 Azure Key Vault를 활용하는 방법을 살펴보겠습니다.In this article we're going to see how you can leverage Azure Key Vault in a CI/CD pipeline, so that we can automatically sign our MSIX package as part of the process.

중요

이 문서에서 설명하는 프로세스는 Azure Pipelines 및 GitHub Actions 모두에서 작동하는 Azure SignTool이라는 오픈 소스 도구를 기반으로 합니다.The process described in this article is based on an open source tool called Azure SignTool, which works both with Azure Pipelines and GitHub Actions. Azure Pipelines를 사용하는 경우 Azure Key Vault 작업과 함께 MSIX 확장도 활용할 수 있습니다.If you're using Azure Pipelines, you can leverage also the MSIX Extensions in combination with the Azure Key Vault task.

사전 요구 사항Prerequisites

  • Azure 계정.An Azure account. 아직 Azure 계정이 없는 경우 여기에서 시작하세요.If you do not already have an Azure account, start here.
  • Azure Key Vault.An Azure Key Vault. 자세한 내용은 Key Vault 만들기를 참조하세요.For more info, see Create a Key Vault.
  • Azure Key Vault로 가져온 유효한 패키지 서명 인증서입니다.A valid package signing certificate imported into Azure Key Vault. Azure Key Vault에서 생성된 기본 인증서는 코드 서명에 사용할 수 없습니다.The default certificate generated by Azure Key Vault will not work for code signing. 패키지 서명 인증서를 만드는 방법에 대한 자세한 내용은 패키지 서명에 대한 인증서 만들기를 참조하세요.For details on how to create a package signing certificate, see Create a certificate for package signing.
  • Azure Pipelines 또는 GitHub Actions에서 호스팅되는 MSIX 패키지를 생성하는 CI/CD 파이프라인입니다.A CI/CD pipeline which generates a MSIX package, hosted on Azure Pipelines or GitHub Actions. 자세한 내용은 YAML 파일을 사용하여 CI/CD 파이프라인 구성을 참조하세요.For more info, see Configure CI/CD pipeline with YAML file.

Azure에 애플리케이션 등록Register an application on Azure

CI/CD 파이프라인의 일부로 패키지에 서명하기 위해 Azure SignTool이라는 도구를 사용할 것입니다.To sign the package as part of the CI/CD pipeline, we're going to use a tool called Azure SignTool. Windows 10 SDK에 포함된 표준 SignTool 유틸리티처럼 작동하지만, 로컬 인증서를 사용하는 대신 Azure Key Vault에 연결하여 사용 가능한 인증서 중 하나를 사용합니다.It works like the standard SignTool utility included in the Windows 10 SDK but, instead of using a local certificate, it connects to Azure Key Vault to use one of the available certificates. 그러나 연결을 설정하려면 먼저 Azure에 애플리케이션을 등록해야 합니다. 그러면 Azure SignTool이 Azure Key Vault 서비스에 대해 인증하는 데 필요한 자격 증명이 제공됩니다.To establish the connection, however, we first need to register an application on Azure, which will give us the credentials we need to enable Azure SignTool to authenticate against our Azure Key Vault service.

Azure Portal을 열고 사용 가능한 서비스 중 Azure Active Directory 를 선택합니다.Open the Azure Portal and choose Azure Active Directory among the available services. 앱 등록 을 클릭하고 새 등록 을 선택하여 프로세스를 시작합니다.Click on App Registrations and choose New registration to start the process. 애플리케이션에 이름을 지정한 다음(예: 아래 이미지의 SignToolForContoso), 기본 설정을 그대로 둡니다.Give a name to the application (for example, it's SignToolForContoso in the image below) and then leave the default settings.

Azure에 애플리케이션 등록

다음 단계는 리디렉션 URI가 필요하지 않은 시나리오이므로 애플리케이션을 퍼블릭 클라이언트로 처리하는 것입니다.The next step is to treat the application as a public client, since we are in a scenario where a redirect URI is not needed. 인증 섹션 으로 이동하고 고급 설정 에서 애플리케이션을 퍼블릭 클라이언트로 처리 로 변경합니다.Move to the Authentication section and, under Advanced settings, change the switch Treat application as a public client to Yes.

고급 설정 지정

마지막 단계는 Azure SignTool에서 인증해야 하는 암호에 해당하는 클라이언트 암호를 만드는 것입니다.The last step is to create a client secret, which is the password we'll need to authenticate from the Azure SignTool. 인증서 및 비밀 섹션 으로 이동한 다음, 새 클라이언트 암호 를 클릭합니다.Move to the Certificates & secrets section, then click on New client secret. 이름을 지정하고 만료를 선택한 다음, 추가 단추를 누릅니다.Give it a name, choose an expiration and then press the Add button. 비밀이 값과 함께 나열되는 기본 페이지로 다시 리디렉션됩니다.You will be redirected back to the main page, where the secret will be listed together with its value. 이를 복사하여 안전한 곳에 보관해야 합니다.Make sure to copy it and to store it somewhere safe. 다시 검색할 수 없습니다.You won't be able to retrieve it again. 페이지를 새로 고치자마자, 비밀은 가려지고 공개할 방법이 없습니다.As soon as you refresh the page, the secret will be masked and there won't be any way to reveal it. 따라서 새 비밀을 생성하는 방법밖에 없습니다.Your only option will be to generate a new secret.

클라이언트 암호와 함께 저장해야 하는 마지막 정보는 애플리케이션 식별자입니다.There's one last information you need to save together with the client secret: the application identifier. 개요 를 클릭하여 애플리케이션의 홈으로 돌아가서 상단 섹션에서 애플리케이션(클라이언트) ID 값을 찾습니다.Go back to the home of the application (by clicking on Overview) and, in the upper section, look for the value Application (client) ID:

애플리케이션 ID

Azure Key Vault에 대한 액세스 사용Enable access to Azure Key Vault

다음 단계는 Azure Key Vault 서비스에 액세스하기 위해 방금 만든 Azure 애플리케이션을 구성하는 것입니다.The next step is to configure the Azure application we have just created to access to our Azure Key Vault service. Azure Portal에서 MSIX 패키지에 서명하는 데 사용할 인증서가 있는 Azure Key Vault 인스턴스로 이동합니다.From the Azure portal, move to the Azure Key Vault instance which holds the certificate you want to use to sign your MSIX package. 액세스 정책 섹션으로 이동하여 액세스 정책 추가 를 클릭합니다.Go to the Access policies section and click on Add Access Policy. 이 도구는 사용 가능한 템플릿 중 하나를 선택하여 부여할 권한을 정의하는 것을 지원하지만 이 시나리오에서는 어느 템플릿도 적합하지 않습니다.The tool supports choosing one of the available templates to define the permissions we want to grant but, in our scenario, no one of them is the right fit. 따라서 드롭다운을 사용하여 다음 옵션을 수동으로 설정해야 합니다.As such, we'll need to manually set, using the dropdowns, the following options:

  • 키 권한 에서 서명 옵션을 사용합니다.Under Key permissions, enable the Sign option.
  • 인증서 권한 에서 가져오기 옵션을 사용합니다.Under Certificate permissions, enable the Get option.

마지막으로 중요한 단계는 이 정책에 액세스할 애플리케이션을 지정하는 것입니다.The last important step is to specify which application is going to access to this policy. 보안 주체 선택 을 클릭하고 이전 단계에서 만든 Azure 애플리케이션의 이름을 사용하여 검색합니다.Click on Select principal and search for the Azure application you have created in the previous step by using its name. 이 예에서는 SignToolForContoso 입니다.In the example, it's called SignToolForContoso.

보안 주체 선택

찾았으면 선택 을 누릅니다.Once you have found it, press Select. 정책은 이렇게 보여야 합니다.This is how the policy should look like.

액세스 정책 추가

프로세스를 완료하면 추가 를 클릭하여 정책을 만듭니다.When you have completed the process, click Add to create the policy.

Azure SignTool을 사용하여 로컬로 패키지 서명Use Azure SignTool to sign the package locally

이제 Azure 구성이 완료되었으므로 Azure SignTool을 사용하여 패키지에 서명할 수 있습니다.Now that the Azure configuration is completed, we can use Azure SignTool to sign the package. 이 섹션에서는 도구를 로컬에서 사용하여 숙지하겠습니다.In this section, we'll use the tool locally to familiarize with it. 다음 섹션에서는 CI/CD 파이프라인의 일부로 사용하겠습니다.In the next sections, we're going to use it as part of a CI/CD pipeline.

이 도구는 .NET 전역 도구로 사용할 수 있습니다.The tool is available as a .NET global tool. 최신 .NET SDK가 설치되어 있는지 확인한 후 명령 프롬프트를 열고 다음 명령을 실행합니다.Make sure to have the latest .NET SDK installed, then open a command prompt and launch the following command:

dotnet tool install --global AzureSignTool 

이제 AzureSignTool 명령을 사용하여 패키지에 서명할 수 있으며, 다음 매개 변수가 필요합니다.Now you can sign your package using the AzureSignTool command, which requires the following parameters:

  • kvu는 Azure Key Vault의 URL입니다.kvu is the URL of your Azure Key Vault. Azure Portal의 DNS 이름 아래에 있는 서비스의 기본 페이지에서 찾을 수 있습니다.You can find it in the main page of the service in the Azure portal, under DNS Name.
  • kvi는 등록하고 이전에 기록한 Azure 앱의 애플리케이션 ID입니다.kvi is the application id of the Azure app you have registered and that you have previously noted.
  • kvs는 이전에 생성하고 이전에 기록한 클라이언트 암호입니다.kvs is the client secret you have previously generated and that you have previously noted.
  • kvc는 사용하려는 인증서의 식별 이름입니다.kvc is the friendly name of the certificate you want to use.
  • tr은 타임스탬프 서버의 URL입니다.tr is the URL of a timestamp server. 이 옵션을 사용하면 인증서가 만료될 때에도 패키지가 작동하도록 할 수 있습니다.By using this option, we can enable our package to work also when the certificate will expire.
  • v는 서명하려는 MSIX 패키지의 경로입니다.v is the path of the MSIX package we want to sign.

이는 샘플 명령입니다.This is a sample command:

AzureSignTool sign -kvu "https://contosoexpenses-blog.vault.azure.net/" -kvi "64fae35e-cb84-4b9f-86eb-5170d169316d" -kvs "this-is-the-secret" -kvc "MyCertificate" -tr http://timestamp.digicert.com -v .\MyContosoApp.msix

Azure Pipelines와 함께 Azure SignTool 사용Using Azure SignTool with Azure Pipelines

이 섹션에서는 여기에 설명된 대로 Azure Pipelines에서 YAML 파일로 구성된 Windows 애플리케이션용 CI/CD 파이프라인이 이미 있다고 가정합니다.This section assumes you already have a CI/CD pipeline for a Windows application configured with a YAML file on Azure Pipelines, as explained here.

처음에는 Azure SignTool에서 Azure Key Vault에 연결하는 데 필요한 정보를 저장할 몇 가지 변수를 만들어야 합니다.At first, you will need to create a few variables to store the information required by Azure SignTool to connect to Azure Key Vault. Azure DevOps에서 파이프라인을 선택하고 맨 위에 있는 편집 단추를 누릅니다.In Azure DevOps select your pipeline and press the Edit button at the top. YAML 편집기에 있으면 위쪽의 변수 단추를 클릭하여 패널을 엽니다.Once you are in the YAML editor, click on the Variables button at the top to open the panel. + 단추를 클릭하여 다음 변수를 추가하겠습니다.You're going to click on the + button to add the following variables:

  • AzureKeyVaultName(자격 증명 모음의 식별 이름 포함).AzureKeyVaultName, with the friendly name of your vault.
  • AzureKeyVaultUrl(자격 증명 모음의 URL 포함).AzureKeyVaultUrl, with the URL of your vault.
  • AzureKeyVaultClientId(Azure 애플리케이션의 애플리케이션 ID 포함)AzureKeyVaultClientId, with the application id of your Azure application.
  • AzureKeyVaultClientSecret(Azure 애플리케이션의 클라이언트 암호 포함)AzureKeyVaultClientSecret, with the client secret of your Azure application.

각 변수를 만들 때 이 값 유지 비밀 옵션을 사용해야 합니다.When you create each variable, make sure to enable the Keep this value secret option. 이렇게 하면 파이프라인에 액세스할 수 있는 다른 사용자가 자신의 값을 볼 수 없게 됩니다.It will make sure that other people who have access to the pipeline won't be able to see their values.

변수 추가

이제 에이전트에서 Azure SignTool을 설치하는 .NET Core 작업을 추가하여 기존 YAML 파이프라인을 사용자 지정할 수 있습니다.Now you can customize your existing YAML pipeline by adding a .NET Core task to install Azure SignTool on the agent. 이는 추가할 YAML입니다.This is the YAML to add:

- task: DotNetCoreCLI@2
  displayName: 'Install Azure SignTool'
  inputs:
    command: custom
    custom: tool
    arguments: 'install --global AzureSignTool'

다음 단계는 패키지에 서명하는 명령을 실행하는 PowerShell 작업을 추가하는 것입니다.The next step is to add a PowerShell task to execute the command that will sign the package. MSIX 패키지를 만든 후에는 빌드 프로세스가 끝날 때만 이 작업을 수행해야 합니다.You must perform this task only at the end of the build process, once the MSIX package has been created.

- powershell: '& AzureSignTool sign -kvu $(AzureKeyVaultUrl) -kvi $(AzureKeyVaultClientId) -kvs $(AzureKeyVaultClientSecret) -kvc $(AzureKeyVaultName) -tr http://timestamp.digicert.com -v "$(System.DefaultWorkingDirectory)\MyPipeline\MyContosoApp\MyContosoApp.msix"'
  displayName: 'Sign the package'

명령은 로컬에서 패키지에 서명할 때 사용한 명령과 비슷합니다.The command is similar to the one we have used to sign the package locally. 차이점은 다음과 같습니다.The only differences are:

  • 다양한 매개 변수에 고정 값을 사용하는 대신 $(Variable-Name) 구문을 사용하여 만든 변수를 사용합니다.Instead of using fixed values for the various parameters, we're using the variables we have created with the syntax $(Variable-Name)
  • MSIX 패키지의 경로는 빌드 끝에 MSIX 패키지가 생성되는 에이전트의 폴더를 가리킵니다.The path of the MSIX package points to the folder on the agent where the MSIX package is created at the end of the build.

GitHub Actions와 함께 Azure SignTool 사용Using Azure SignTool with GitHub Actions

이 섹션에서는 여기에 설명된 대로 GitHub Actions에서 YAML 파일로 구성된 Windows 애플리케이션용 CI/CD 파이프라인이 이미 있다고 가정합니다.This section assumes you already have a CI/CD pipeline for a Windows application configured with a YAML file on GitHub Actions, as explained here.

Azure Pipelines에서와 같이 첫 번째 단계로 자격 증명을 안전하게 저장해야 합니다.As first step, like we did on Azure Pipeline, we need to safely store the credentials. GitHub는 비밀 을 사용하며 리포지토리의 설정에 추가할 수 있습니다.GitHub uses secrets and they can be added in the settings of your repository. Windows 애플리케이션을 호스팅하는 GitHub 리포지토리에 있는 경우 설정 을 클릭한 다음, 비밀 로 이동합니다.Once you're on the GitHub repository which hosts your Windows application, click on Settings then move to Secrets.

Azure Pipelines와 마찬가지로, 새 비밀 을 클릭하여 4개의 비밀을 만듭니다.Similarly to what you did with Azure Pipelines, you're going to click on New secret to create four secrets:

  • AzureKeyVaultName(자격 증명 모음의 식별 이름 포함).AzureKeyVaultName, with the friendly name of your vault.
  • AzureKeyVaultUrl(자격 증명 모음의 URL 포함).AzureKeyVaultUrl, with the URL of your vault.
  • AzureKeyVaultClientId(Azure 애플리케이션의 애플리케이션 ID 포함)AzureKeyVaultClientId, with the application id of your Azure application.
  • AzureKeyVaultClientSecret(Azure 애플리케이션의 클라이언트 암호 포함)AzureKeyVaultClientSecret, with the client secret of your Azure application.

Azure Pipelines와의 차이점은 비밀이 암시적으로 숨겨져 있기 때문에 비밀을 보호하기 위한 어떤 옵션도 실행할 필요가 없다는 것입니다.The difference with Azure Pipeline is that secrets are implicitly hidden, so you won't have to enable any option to protect them.

이제 리포지토리의 작업 탭을 통해 기존 워크플로를 열고 서명을 수행하는 데 필요한 작업을 추가할 수 있습니다.Now, through the Actions tab of your repository, you can open your existing workflow and add the tasks you need to perform the signing. 첫 번째 것은 에이전트에 AzureSign 도구를 설치합니다.The first one will install AzureSign Tool on the agent:

- name: Install AzureSignTool
  run: dotnet tool install --global AzureSignTool

두 번째 것은 패키지에 서명하므로, Visual Studio 빌드가 완료되고 MSIX 패키지가 생성된 후에 실행해야 합니다.The second one will sign the package and, as such, it must be executed after the Visual Studio build has been completed and the MSIX package has been generated.

 - name: Sign package
   run: |
        Get-ChildItem -recurse -Include **.msix | ForEach-Object {
        $msixPath = $_.FullName
        & AzureSignTool sign -kvu "${{ secrets.AzureKeyVaultUrl }}" -kvi "${{ secrets.AzureKeyVaultClientId }}" -kvs "${{ secrets.AzureKeyVaultClientSecret }}" -kvc ${{ secrets.AzureKeyVaultName }} -tr http://timestamp.digicert.com -v $msixPath
        }

Azure Pipelines에서 사용한 것과 비교하여 이 작업에는 몇 가지 차이점이 있습니다.There are a few differences in this task compared to the one we used in Azure Pipelines. 첫 번째는 GitHub가 ${{secrets.SECRET_NAME }}라는 다른 구문을 사용하여 비밀에 액세스한다는 것입니다.The first one is that GitHub uses a different syntax to access to the secrets, which is ${{ secrets.SECRET_NAME }}. 따라서 다양한 매개 변수는 이전에 비밀 섹션에서 만든 값으로 채워집니다.As such, the various parameters are filled with the values we have previously created in the Secrets section. 또 하나는 서명할 MSIX 패키지를 찾기 위해 다른 방법을 사용해야 한다는 것입니다.The other one is that you need to use a different approach to find the MSIX packages to sign. 이 작업은 특정 MSIX 패키지를 가리키는 대신 빌드 출력에 저장된 모든 파일을 반복하는 PowerShell 스크립트를 사용합니다.The task, instead of pointing to a specific MSIX package, uses a PowerShell script which iterates through all the files stored in the build output. 파일에 MSIX 확장자가 있는 경우 AzureSignTool 명령을 사용하여 서명합니다.If the file has the MSIX extension, then it will use the AzureSignTool command to sign it.

패키지 배포Deploy the package

선택한 CI/CD 플랫폼과 관계없이 흐름의 끝에서 Azure Key Vault에 저장된 인증서로 MSIX 패키지가 서명됩니다.Regardless of the CI/CD platform of your choice, at the end of the flow you will have a MSIX package signed with your certificate stored on Azure Key Vault. 이제 Microsoft Store, 웹 사이트, Microsoft Intune 등 원하는 배포 방식을 통해 다른 사용 가능한 작업을 사용하여 패키지를 배포할 수 있습니다.Now you can use any other available task to deploy the package using your preferred choice of distribution: the Microsoft Store, a website, Microsoft Intune, etc.