배포 파이프라인을 사용하면 코드 또는 사전 빌드된 아티팩트를 가져와 Google Cloud 환경에 배포하는 프로세스를 자동화할 수 있습니다. 또한 Google Cloud 콘솔 또는 Google Cloud CLI와 같은 대화형 도구 사용의 대안이 될 수 있습니다.
배포 파이프라인은 Identity and Access Management와 상호작용하는 방식이 Google Cloud 콘솔 또는 gcloud CLI와 같은 대화형 도구와 다르며 Google Cloud 리소스를 보호할 때 이러한 차이점을 고려해야 합니다.
Google Cloud는 사용자의 리소스 액세스를 허용하기 전에 액세스 검사를 수행합니다. 일반적으로 이 검사를 수행하기 위해 IAM에서 다음을 고려합니다.
- 본인 확인
- 액세스하려는 리소스와 IAM 허용 및 거부 정책
- 요청의 컨텍스트(시간 및 위치 포함)
배포 파이프라인에서 Google Cloud API를 직접 호출하는 경우는 거의 없습니다. 대신 도구를 사용하여 Google Cloud 리소스에 액세스합니다. Google Cloud 콘솔 또는 gcloud CLI와 같은 도구를 사용하려면 먼저 사용자를 대신하여 리소스에 액세스할 수 있도록 도구를 승인해야 합니다. 이 승인을 제공하면 API를 호출할 때 사용자 ID를 사용할 수 있는 권한이 도구에 부여됩니다.
Google Cloud 콘솔 또는 gcloud CLI와 마찬가지로 배포 파이프라인은 사용자를 대신하여 역할을 수행합니다. 즉, 소스 코드로 표시된 변경사항을 적용하고 Google Cloud에 배포합니다. 하지만 Google Cloud 콘솔 또는 gcloud CLI와 달리 배포 파이프라인은 일반적으로 사용자의 ID를 사용하여 배포를 수행하지 않습니다.
사용자는 일반적으로 배포 파이프라인과 직접 상호작용하지 않습니다. 대신 소스 저장소에 코드 변경사항을 푸시하거나 코드 검토를 승인하여 소스 제어 시스템(SCM)과 상호작용합니다.
배포 파이프라인이 SCM 시스템에서 제출된 코드 변경사항을 읽고 이를 Google Cloud에 배포합니다.
배포를 수행하기 위해 배포 파이프라인은 일반적으로 다음과 같은 이유로 사용자의 ID를 사용할 수 없습니다.
- 소스 코드 및 메타데이터에 사용자가 작성자라고 표시되지 않거나 작성자 정보가 위조 방지되지 않음(서명되지 않은 Git 커밋의 경우).
- 소스 코드를 제출하는 데 사용한 ID가 Google ID와 다를 수 있으며 두 ID를 매핑할 수 없음
따라서 대부분의 배포 파이프라인은 서비스 계정을 사용하여 자체 ID로 배포를 수행합니다.
배포 파이프라인이 Google Cloud에 액세스하면 IAM이 사용자 계정의 ID가 아니라 파이프라인에서 사용하는 서비스 계정의 ID만을 기준으로 액세스를 허용하거나 거부합니다.
배포 파이프라인에서 서비스 계정을 사용하여 Google Cloud에 액세스하도록 허용하는 경우 몇 가지 이점이 있습니다.
- 서비스 계정의 수명 주기는 사용자 계정의 수명 주기와 연결이 끊어집니다. 서비스 계정을 사용하도록 파이프라인을 구성하면 더 이상 조직에 코드 작성자가 없는 경우에도 코드를 배포할 수 있습니다.
- 배포 파이프라인을 사용하여 리소스를 관리할 때는 사용자에게 리소스에 대한 액세스 권한을 부여할 필요가 없으며 읽기 전용 액세스로 권한을 제한할 수 있습니다. 이 접근 방식을 사용하면 IAM 정책을 보다 쉽게 관리하고 사용자가 배포 파이프라인을 사용하여 모든 수정을 수행하도록 강제할 수 있습니다.
하지만 서비스 계정을 사용하면 새로운 위협이 발생합니다. 예를 들면 다음과 같습니다.
- 스푸핑: 악의적인 행위자가 배포 파이프라인의 ID를 스푸핑하거나 사용자 인증 정보를 도용하여 리소스에 대한 액세스 권한을 얻으려고 할 수 있습니다.
- 권한 에스컬레이션: 파이프라인이 수행해서는 안 되는 작업을 수행하도록 만들어 혼동된 대리인이 될 수 있습니다.
- 부인 방지: 파이프라인에서 작업을 수행한 후 작업이 완료된 이유와 작업을 변경하는 개발자 또는 코드 변경에 의해 트리거되었는지 재구성하기가 어려울 수 있습니다.
- 조작: 파이프라인을 악용하여 클라우드 환경의 무결성 또는 보안 제어를 훼손할 수 있습니다.
- 정보 공개: 악의적인 행위자가 배포 파이프라인을 사용하여 기밀 데이터를 유출하려고 할 수 있습니다.
스푸핑 위협으로부터 보호
배포 파이프라인에 Google Cloud에 대한 액세스 권한을 부여하려면 일반적으로 다음 조치를 수행합니다.
- 서비스 계정 만들기
- 필수 리소스에 대한 액세스 권한을 서비스 계정에 부여
- 서비스 계정을 사용하도록 배포 파이프라인을 구성
IAM 관점에서 서비스 계정은 배포 파이프라인을 대표하지만, 배포 파이프라인과 서비스 계정은 서로 다른 두 항목입니다. 제대로 보호하지 않으면 악의적인 행위자가 동일한 서비스 계정을 사용하여 배포 파이프라인의 ID를 '스푸핑'할 수 있습니다.
다음 섹션에서는 이러한 위협을 줄이는 데 도움이 되는 권장사항에 대해 설명합니다.
권장사항:
CI/CD 시스템에서 사용하는 VM 인스턴스에 서비스 계정을 연결하지 않음배포 파이프라인별 전용 서비스 계정 사용
가능하면 언제나 워크로드 아이덴티티 제휴 사용
VPC 서비스 제어를 사용하여 유출된 사용자 인증 정보의 영향 줄이기
CI/CD 시스템에서 사용하는 VM 인스턴스에 서비스 계정을 연결하지 않음
Google Cloud 리소스에 액세스해야 하는 Compute Engine에 배포된 애플리케이션의 경우 일반적으로 기본 VM 인스턴스에 서비스 계정을 연결하는 것이 가장 좋습니다. Compute Engine VM을 사용하여 다양한 배포 파이프라인을 실행하는 CI/CD 시스템의 경우, 동일한 VM 인스턴스를 사용하여 각각 다른 리소스에 액세스해야 하는 여러 배포 파이프라인을 실행하면 문제가 발생할 수 있습니다.
연결된 서비스 계정을 사용하여 배포 파이프라인이 리소스에 액세스하도록 허용하는 대신 각 배포 파이프라인이 별도의 서비스 계정을 사용하도록 허용하세요. CI/CD 시스템에서 사용하는 VM 인스턴스에는 서비스 계정을 연결하지 않거나 Cloud Logging과 같은 필수 서비스에만 액세스하도록 제한된 서비스 계정을 연결하는 것이 좋습니다.
배포 파이프라인별 전용 서비스 계정 사용
여러 배포 파이프라인이 동일한 서비스 계정을 사용하도록 허용하면 IAM은 파이프라인을 구분할 수 없습니다. 파이프라인은 동일한 리소스에 액세스할 수 있으며 감사 로그에는 리소스에 액세스하거나 리소스를 변경할 수 있도록 트리거한 배포 파이프라인을 확인하는 데 필요한 정보가 충분하지 않을 수 있습니다.
이러한 모호성을 막기 위해 배포 파이프라인과 서비스 계정 간에 1:1 관계를 유지합니다. 배포 파이프라인마다 전용 서비스 계정을 만들고 다음과 같이 수행합니다.
- 배포 파이프라인의 이름 또는 ID를 서비스 계정의 이메일 주소에 포함합니다. 일관된 이름 지정 스키마를 따르면 서비스 계정 이름에서 배포 파이프라인을 파악하는 것은 물론 그 반대의 경우에도 도움이 됩니다.
- 특정 배포 파이프라인에 필요한 리소스에 대한 액세스 권한만 서비스 계정에 부여합니다.
가능하면 언제나 워크로드 아이덴티티 제휴 사용
GitHub Actions 또는 GitLab과 같은 일부 CI/CD 시스템을 사용하면 배포 파이프라인에서 배포 파이프라인의 ID를 알리는 OpenID Connect 준수 토큰을 얻을 수 있습니다. 워크로드 아이덴티티 제휴를 사용하여 배포 파이프라인에서 서비스 계정을 가장하도록 이 토큰을 사용할 수 있습니다.
워크로드 아이덴티티 제휴를 사용하면 서비스 계정 키 사용과 관련된 위험을 방지할 수 있습니다.
VPC 서비스 제어를 사용하여 유출된 사용자 인증 정보의 영향 줄이기
악의적인 행위자가 어떤 경위로든 배포 파이프라인 중 하나에서 액세스 토큰 또는 서비스 계정 키를 얻게 되는 경우, 이 사용자 인증 정보를 사용하여 제어하는 다른 머신에서 리소스에 액세스하려고 할 수 있습니다.
기본적으로 IAM은 액세스 결정을 내릴 때 위치정보, 소스 IP 주소 또는 원본 Google Cloud 프로젝트를 고려하지 않습니다. 따라서 도용된 사용자 인증 정보가 어디서나 사용될 수 있습니다.
프로젝트를 VPC 서비스 경계에 배치하고 인그레스 규칙을 사용하여 Google Cloud 리소스에 액세스할 수 있는 소스에 제한사항을 적용하세요.
- 배포 파이프라인이 Google Cloud에서 실행되는 경우 CI/CD 시스템이 포함된 프로젝트에서만 액세스를 허용하도록 인그레스 규칙을 구성할 수 있습니다.
- 배포 파이프라인이 Google Cloud 외부에서 실행되는 경우 특정 위치정보 또는 IP 범위에서의 액세스만 허용하는 액세스 수준을 만들 수 있습니다. 그런 다음 이 액세스 수준을 충족하는 클라이언트의 액세스를 허용하는 인그레스 규칙을 만듭니다.
조작 위험으로부터 보호
Google Cloud에 저장하는 일부 데이터에서는 승인되지 않은 수정 또는 삭제를 막는 것이 특히 중요할 수 있습니다. 승인되지 않은 수정 또는 삭제가 특히 걱정된다면 데이터 특성을 무결성이 높은 데이터로 규정할 수 있습니다.
데이터 무결성을 유지하려면 데이터를 저장하고 관리하는 데 사용하는 Google Cloud 리소스가 안전하게 구성되었는지 확인하고 무결성을 유지해야 합니다.
배포 파이프라인은 데이터와 리소스의 무결성을 유지하는 데 도움이 될 수 있지만 위험을 일으킬 수도 있습니다. 해당 구성요소 중 하나의 파이프라인이 관리하는 리소스의 무결성 요구사항을 충족하지 않으면 배포 파이프라인이 악의적인 행위자가 데이터 또는 리소스를 변조할 수 있는 취약한 지점으로 전환됩니다.
다음 섹션에서는 조작 위협의 위험을 줄이는 데 도움이 되는 권장사항을 설명합니다.
보안 제어에 대한 액세스 제한
Google Cloud 데이터와 리소스의 보안 및 무결성을 보장하기 위해 다음과 같은 보안 제어를 사용합니다.
- 허용 정책 및 거부 정책
- 조직 정책 제약조건
- VPC 서비스 제어 경계, 액세스 수준, 인그레스 정책
이러한 보안 제어는 그 자체로 리소스입니다. 보안 제어를 조작하면 보안 제어가 적용되는 리소스의 무결성이 훼손됩니다. 따라서 보안 제어의 무결성을 적어도 보안 제어가 적용되는 리소스의 무결성만큼 중요하게 고려해야 합니다.
배포 파이프라인이 보안 제어를 관리하도록 허용하면 보안 제어의 무결성을 유지하는 것은 배포 파이프라인의 책임입니다. 따라서 배포 파이프라인 자체의 무결성을 적어도 배포 파이프라인에서 관리하는 보안 제어 및 보안 제어가 적용되는 리소스의 무결성만큼 중요하게 고려해야 합니다.
배포 파이프라인이 리소스의 무결성에 미치는 영향을 제한하는 조치로는 다음과 같은 방법이 있습니다.
- 배포 파이프라인에 허용 정책, 거부 정책, 기타 보안 제어에 대한 액세스 권한을 부여하지 않고 다른 리소스에 대한 액세스를 제한
- 특정 리소스 또는 프로젝트의 허용 정책 및 거부 정책과 같이 선택한 보안 제어에만 액세스 권한을 부여하고 여러 리소스 또는 프로젝트에 영향을 미치는 광범위한 제어에 대한 액세스 권한은 부여하지 않음
배포 파이프라인, 구성요소, 기본 인프라가 특정 보안 제어의 무결성 요구사항을 충족하지 못하는 경우 배포 파이프라인이 이러한 보안 제어를 관리하지 않도록 하는 것이 좋습니다.
부인 방지 위협으로부터 보호
특정 시점에서 Google Cloud의 리소스 중 하나에 영향을 미치는 의심스러운 활동을 발견할 수도 있습니다. 이런 경우에는 활동에 대한 자세한 정보를 확인할 수 있어야 하며, 이상적으로는 이벤트를 초래한 체인을 재구성할 수 있어야 합니다.
Cloud 감사 로그를 사용하면 리소스에 액세스 또는 수정된 시기, 관련된 사용자를 확인할 수 있습니다. Cloud 감사 로그는 의심스러운 활동 분석을 위한 시작점을 제공하지만 이러한 로그에서 제공하는 정보가 충분하지 않을 수 있습니다. 배포 파이프라인을 사용하는 경우 Cloud 감사 로그와 배포 파이프라인에서 생성된 로그를 연관시킬 수도 있어야 합니다.
이 섹션에는 Google Cloud와 배포 파이프라인에서 감사 추적을 유지하는 데 도움이 되는 권장사항이 포함되어 있습니다.
배포 파이프라인 로그와 Cloud 감사 로그를 연관시킬 수 있는지 확인
Cloud 감사 로그에는 활동을 시작한 사용자에 대한 타임스탬프 및 정보가 포함됩니다. 배포 파이프라인별 전용 서비스 계정을 사용하는 경우 이 정보를 사용하여 활동을 시작한 배포 파이프라인을 식별하고 활동의 원인이 될 수 있는 코드 변경 및 파이프라인 실행의 범위를 좁힐 수 있습니다. 하지만 Cloud 감사 로그와 배포 파이프라인의 로그의 상관관계를 파악할 수 있는 추가 정보 없이는 활동으로 이어지는 정확한 파이프라인 실행과 코드 변경을 식별하기 어려울 수 있습니다.
다음과 같은 여러 가지 방법으로 추가 정보를 포함하도록 Cloud 감사 로그를 보강해 보세요.
- Terraform을 사용할 때는 CI/CD 파이프라인 실행을 나타내는 요청 이유를 지정합니다.
X-Goog-Request-ReasonHTTP 헤더를 API 요청에 추가하고 배포 파이프라인 실행 ID를 전달합니다.- 배포 파이프라인 실행 ID를 삽입하는 커스텀
User-Agent를 사용합니다.
배포 파이프라인에서 내보낸 로그를 보강할 수도 있습니다.
- 각 CI/CD 파이프라인에서 실행된 API를 로깅합니다.
- API가 작업 ID를 반환할 때마다 CI/CD 시스템 로그에 ID를 기록합니다.
배포 파이프라인 로그 및 Cloud 감사 로그의 보관 기간 정렬
배포 파이프라인과 관련된 의심스러운 활동을 분석하려면 일반적으로 관리자 활동 감사 로그, 데이터 액세스 감사 로그, 배포 파이프라인의 로그 등 여러 유형의 로그가 필요합니다.
Cloud Logging은 특정 기간 동안만 로그를 보관합니다. 기본적으로 관리자 활동 감사 로그보다 데이터 액세스 감사 로그의 보관 기간이 더 짧습니다. 배포 파이프라인을 실행하는 시스템에서 특정 기간이 지난 후 로그를 삭제할 수도 있습니다. 배포 파이프라인의 특성과 배포 파이프라인이 관리하는 리소스의 중요도에 따라 이러한 기본 보관 기간이 충분하지 않거나 잘못 정렬될 수 있습니다.
필요할 때 로그를 사용할 수 있게 하려면 여러 시스템에서 사용하는 로그 보관 기간이 정렬되어 있고 길이는 충분한지 확인하세요.
필요한 경우 데이터 액세스 감사 로그의 보관 기간을 맞춤설정하거나 커스텀 싱크를 설정하여 로그를 커스텀 스토리지 위치로 라우팅하세요.
정보 공개 위협으로부터 보호
배포 파이프라인의 서비스 계정에 기밀 데이터에 대한 액세스 권한이 있는 경우 악의적인 행위자가 배포 파이프라인을 사용하여 해당 데이터를 유출하려고 시도할 가능성이 있습니다. 배포 파이프라인의 데이터 액세스는 직접적일 수도 있고 간접적일 수도 있습니다.
직접: 배포 파이프라인의 서비스 계정에 Cloud Storage, BigQuery 또는 다른 위치에서 기밀 데이터를 읽을 수 있는 권한이 있을 수 있습니다. 의도적으로 이러한 액세스 권한을 부여했을 수 있지만 우발적으로 과도한 액세스 권한을 부여한 결과일 수도 있습니다.
악의적인 행위자가 기밀 데이터에 직접 액세스할 수 있는 배포 파이프라인에 액세스하게 되면 서비스 계정의 액세스 토큰을 사용하여 데이터에 액세스하고 추출할 수 있게 됩니다.
간접: 구성 또는 새 소프트웨어 버전을 배포하기 위해 배포 파이프라인의 서비스 계정에 VM 인스턴스, Cloud Run 애플리케이션 또는 기타 컴퓨팅 리소스를 만들거나 다시 배포할 수 있는 권한이 있을 수 있습니다. 이러한 컴퓨팅 리소스 중 일부에 기밀 데이터에 대한 액세스 권한을 부여하는 연결된 서비스 계정이 있을 수 있습니다.
이 경우 악의적인 행위자가 배포 파이프라인을 손상시켜서 악성 코드를 컴퓨팅 리소스 중 하나에 배포하고 이 코드가 기밀 데이터를 유출하도록 할 수 있습니다.
이 섹션에서는 기밀 데이터의 공개 위험을 제한하는 데 도움이 되는 권장사항을 제공합니다.
기밀 데이터에 대한 직접 액세스 권한을 부여하지 않음
인프라, 구성 또는 새 소프트웨어 버전을 배포할 때는 주로 배포 파이프라인에 기존 데이터에 대한 액세스 권한이 필요 없습니다. 대신 데이터가 전혀 없거나 최소한 기밀 데이터가 포함되어 있지 않은 리소스에 대한 액세스를 제한하는 것만으로도 충분한 경우가 많습니다.
기밀일 가능성이 있는 기존 데이터에 대한 액세스를 최소화하는 방법은 다음과 같습니다.
- 배포 파이프라인의 서비스 계정에 전체 프로젝트에 대한 액세스 권한을 부여하는 대신 특정 리소스에 대한 액세스 권한만 부여하세요.
- 읽기 액세스를 허용하지 않고 만들기 액세스 권한을 부여하세요. 예를 들어 스토리지 객체 생성자 역할(
roles/storage.objectCreator)을 부여하면 기존 데이터를 읽을 수 있는 권한을 부여하지 않으면서도 서비스 계정이 새 객체를 Cloud Storage 버킷에 업로드하도록 허용할 수 있습니다. - 코드형 인프라(IaC)를 기밀 수준이 낮은 리소스로 제한합니다. 예를 들어 VM 인스턴스 또는 네트워크 관리에는 IaC를 사용하지만 기밀 BigQuery 데이터 세트 관리에는 사용하지 않습니다.
VPC 서비스 제어를 사용하여 데이터 무단 반출 방지
VPC 서비스 제어 경계에 Google Cloud 리소스를 배포하면 간접 데이터 무단 반출의 위험을 줄일 수 있습니다.
배포 파이프라인이 Google Cloud 외부에서 실행되거나 다른 경계에 속하는 경우 인그레스 규칙을 구성하여 파이프라인의 서비스 계정에 경계에 대한 액세스 권한을 부여할 수 있습니다. 가능한 경우 배포 파이프라인에서 사용하는 IP 주소에서만 액세스를 허용하고 배포 파이프라인에 실제로 필요한 서비스에만 액세스를 허용하도록 인그레스 규칙을 구성합니다.
권한 에스컬레이션 위협으로부터 보호
배포 파이프라인은 서비스 계정을 사용하여 Google Cloud 리소스에 액세스할 때 코드 또는 구성 변경을 작성한 개발자 또는 사용자와 관계없이 이 작업을 수행합니다. 파이프라인의 서비스 계정과 개발자 ID 간의 연결 해제로 인해 배포 파이프라인은 혼동된 대리인 공격에 취약해져 악의적인 행위자가 스스로 수행할 수 없고 파이프라인도 수행할 수 없는 작업을 파이프라인이 수행하도록 만듭니다.
이 섹션에는 권한 에스컬레이션에 배포 파이프라인이 악용될 위험을 줄이는 데 도움이 되는 권장사항이 포함되어 있습니다.
배포 파이프라인 및 모든 입력에 대한 액세스 제한
대부분의 배포 파이프라인은 소스 코드 저장소를 기본 입력 소스로 사용하며, 특정 브랜치(예: main 브랜치)에서 코드 변경을 감지하는 즉시 자동으로 트리거될 수 있습니다. 일반적으로 배포 파이프라인은 소스 코드 저장소에서 찾은 코드와 구성이 신뢰할 수 있는지 확인할 수 없습니다. 따라서 이 아키텍처의 보안은 다음에 의존합니다.
- 배포 파이프라인에서 사용하는 저장소 및 브랜치에 코드 및 구성을 제출할 수 있는 사용자 제어
- 변경사항을 커밋하기 전에 충족해야 하는 기준 시행(예: 코드 검토 성공, 정적 분석, 자동 테스트)
이러한 제어가 효과가 있으려면 악의적인 행위자가 다음과 같은 방법으로 이러한 제어를 무력화시킬 수 없게 해야 합니다.
- 소스 코드 저장소 또는 배포 파이프라인의 구성을 수정
- 배포 파이프라인의 기반이 되는 인프라(예: VM 및 스토리지) 변조
- 패키지, 컨테이너 이미지, 라이브러리 등 소스 코드 저장소 외부의 입력을 수정 또는 교체
배포 파이프라인에서 관리되는 경우 Google Cloud의 리소스는 배포 파이프라인, 구성, 인프라, 입력만큼만 안전할 수 있습니다. 따라서 Google Cloud 리소스를 보호하려는 경우와 마찬가지로 이러한 구성 요소를 보호해야 합니다.
배포 파이프라인이 정책을 수정하도록 허용하지 않음
대부분의 리소스 유형에서는 IAM이 RESOURCE_TYPE.setIamPolicy 권한을 정의합니다. 이 권한이 있으면 사용자가 리소스의 IAM 허용 정책을 수정하여 다른 사용자에게 액세스 권한을 부여하거나 자신의 액세스 권한을 수정하고 확장할 수 있습니다. 거부 정책에 따른 제약이 없는 한, 사용자 또는 서비스 계정에 *.setIamPolicy 권한을 부여하면 리소스에 대한 전체 액세스 권한이 부여됩니다.
가능한 경우 배포 파이프라인이 리소스에 대한 액세스 권한을 수정하지 않도록 합니다.
파이프라인의 서비스 계정에 Google Cloud 리소스에 대한 액세스 권한을 부여할 때 *.setIamPolicy 권한이 포함되지 않은 역할을 사용하고 기본 역할 편집자 및 소유자를 사용하지 않습니다.
일부 배포 파이프라인의 경우 허용 정책 또는 거부 정책을 수정할 수 있는 권한을 부여하는 것을 피할 수 없습니다. 배포 파이프라인의 목적이 새 리소스를 만들거나 기존 리소스에 대한 액세스를 관리하는 것인 경우가 그 예에 해당합니다. 이런 경우에도 배포에서 다음을 수정할 수 있는 액세스 범위를 제한할 수 있습니다.
- 전체 프로젝트 대신 특정 리소스에 대한
*.setIamPolicy권한만 부여 - IAM 거부 정책을 사용하여 부여할 수 있는 권한 집합을 제한하거나 부여 가능한 주 구성원을 제한
- IAM 조건을 사용하여 파이프라인에서 부여할 수 있는 역할을 제한하고
*.setIamPolicy권한을 포함하지 않는 역할만 허용
로그에 서비스 계정 사용자 인증 정보를 표시하지 않음
배포 파이프라인에서 생성된 로그에 파이프라인의 구성을 수정할 권한이 없는 사용자를 포함한 대규모 사용자 그룹이 액세스할 수 있는 경우가 많습니다. 이러한 로그에는 에코를 통해 사용자 인증 정보가 우발적으로 표시될 수 있습니다.
- 환경 변수의 콘텐츠
- 명령줄 인수
- 진단 출력
로그에 실수로 액세스 토큰과 같은 사용자 인증 정보가 표시되는 경우 악의적인 사용자가 이러한 사용자 인증 정보를 악용하여 권한을 에스컬레이션할 수 있습니다. 로그가 사용자 인증 정보를 공개하지 못하게 하는 방법은 다음과 같습니다.
- 액세스 토큰 또는 기타 사용자 인증 정보를 명령줄 인수로 전달하지 않음
- 환경 변수에 사용자 인증 정보를 저장하지 않음
- 가능한 경우 토큰 및 기타 사용자 인증 정보를 자동으로 감지하고 마스킹하도록 CI/CD 시스템 구성
다음 단계
- 워크로드 아이덴티티 제휴 및 워크로드 아이덴티티 제휴 사용 권장사항에 대해 자세히 알아보기
- 엔터프라이즈 기반 청사진 및 인증 및 승인에 대한 안내 검토
- 서비스 계정 작업 권장사항 자세히 알아보기