서비스 계정은 리소스이자 주 구성원이라는 점에서 사용자 계정과 다릅니다. Show
서비스 계정을 보호하려면 이중적인 특성을 고려하세요.
서비스 계정은 여러 가지 방법으로 악용될 수 있습니다.
이 가이드에서는 서비스 계정의 권한을 제한하고 이러한 위험 요소를 줄이기 위한 권장사항을 제공합니다. 서비스 계정 권한 제한서비스 계정은 주 구성원이며 일반 사용자 계정과 마찬가지로 리소스에 대한 액세스 권한을 부여받을 수 있습니다. 기본 서비스 계정에 자동 역할 부여를 사용하지 않음일부 Google Cloud 서비스는 Google Cloud 프로젝트에서 API를 처음으로 사용 설정할 때 기본
서비스 계정을 만듭니다. 기본적으로 이러한 서비스 계정에는 Cloud 프로젝트의 편집자 역할( 기본 서비스 계정에 편집자 역할이 자동으로 부여되지 않도록 하려면 조직에
기본 서비스 계정에 대한 자동 IAM 부여 사용 중지( 이 제약조건을 적용하면 새 프로젝트의 기본 서비스 계정이 Google Cloud 리소스에 액세스할 수 없습니다. 기본 서비스 계정이 리소스에 액세스할 수 있도록 적절한 역할을 부여해야 합니다. VM 인스턴스에 서비스 계정을 연결할 때는 액세스 범위를 사용하지 않음VM 인스턴스에 서비스 계정을 연결할 때 하나 이상의 액세스 범위를 지정할 수 있습니다. 액세스 범위를 사용하면 VM에서 액세스할 수 있는 서비스를 제한할 수 있습니다. 이러한 제한은 허용 정책에 추가로 적용됩니다. 액세스 범위는 대략적입니다. 예를 들어 액세스 범위를 사용하는 대신 전용 서비스 계정을 만들고 세분화된 허용 정책을 사용하여 서비스 계정에서 액세스할 수 있는 리소스를 제한합니다. 서비스 계정에 리소스에 대한 액세스 권한을 부여하기 위해 그룹을 사용하지 않음조직에서는 여러 직원이 유사하거나 중복된 직무를 수행하는 경우가 많기 때문에 리소스에 대한 비슷한 액세스가 요구됩니다. 그룹을 사용하면 이러한 유사성을 활용하여 관리 오버헤드를 줄일 수 있습니다. 서비스 계정은 애플리케이션에 의해 사용됩니다. 여러 애플리케이션이 동일한 기능을 수행하기 때문에 액세스 요구사항이 비슷하거나 동일한 경우는 거의 없습니다. 애플리케이션은 고유한 경우가 많으며 액세스가 필요한 리소스는 일반적으로 애플리케이션마다 다릅니다. 그룹을 사용하여 서비스 계정에 리소스에 대한 액세스 권한을 부여하면 몇 가지 잘못된 결과가 발생할 수 있습니다.
그룹의 목적이 좁게 정의되지 않는 한 그룹을 사용하지 않는 것이 좋습니다. 대신 서비스 계정에 필요한 리소스에 대한 액세스 권한을 직접 부여합니다. 도메인 전체 위임 사용하지 않음도메인 전체 위임은 서비스 계정이 Cloud ID 또는 Google Workspace 계정의 모든 사용자를 가장할 수 있도록 합니다. 도메인 전체 위임을 사용하면 서비스 계정이 Google Workspace 및 Cloud ID에서 특정 관리 작업을 수행하거나 Google Cloud 외부에서 서비스 계정을 지원하지 않는 Google API에 액세스할 수 있습니다. 도메인 전체 위임은 특정 사용자를 가장하기 위해 서비스 계정을 제한하지 않지만 최고 관리자를 포함한 Cloud ID 또는 Google Workspace 계정의 모든 사용자를 가장할 수 있도록 허용합니다. 따라서 서비스 계정이 도메인 전체 위임을 사용하도록 허용하면 서비스 계정이 권한 에스컬레이션 공격의 목표가 되기 쉽습니다. 서비스 계정으로 직접 또는 OAuth 동의 흐름을 통해 작업을 처리할 수 있는 경우 도메인 전체 위임을 사용하지 마세요. 도메인 전체 위임을 사용할 수밖에 없는 경우 서비스 계정이 사용할 수 있는 OAuth 범위 집합을 제한하세요. OAuth 범위는 서비스 계정이 가장할 수 있는 사용자를 제한하지 않지만 서비스 계정에서 액세스할 수 있는 사용자 데이터 유형을 제한합니다. 사용자 인증 정보 액세스 경계를 사용하여 액세스 토큰 권한 축소Google 액세스 토큰은 Bearer 토큰이며 특정 애플리케이션에 한정되지 않고 사용할 수 있습니다. 내 애플리케이션이 액세스 토큰을 다른 애플리케이션에 전달하면 다른 애플리케이션 또한 내 애플리케이션과 같은 방식으로 토큰을 사용할 수 있습니다. 마찬가지로, 액세스 토큰이 악의적인 사용자에게 유출되는 경우 이러한 사용자 역시 토큰을 사용하여 액세스 권한을 얻을 수 있습니다. 액세스 토큰은 Bearer 토큰이므로 승인되지 않은 당사자에게 유출되거나 표시되지 않도록 보호해야 합니다. 액세스 권한이 부여되는 리소스를 제한하여 유출된 액세스 토큰에 의해 발생할 수 있는 잠재적인 피해를 제한할 수 있습니다. 이 과정을 줄이기(downscoping)라고 합니다. 사용자 인증 정보 경계를 사용하여 다른 애플리케이션이나 애플리케이션의 다른 구성요소로 액세스 토큰을 전달할 때마다 액세스 토큰을 축소할 수 있습니다. 토큰이 필요한 리소스에 대해 적당한 범위를 벗어나지 않는 액세스 권한을 부여하도록 필요한 액세스 경계를 설정합니다. 역할 권장사항을 사용하여 사용하지 않는 권한 식별애플리케이션을 처음 배포할 때 애플리케이션에 실제로 어떤 역할과 권한이 필요한지 확실하지 않을 수 있습니다. 따라서 애플리케이션 서비스 계정에 필요한 추가 권한을 부여할 수 있습니다. 마찬가지로 애플리케이션의 액세스 요구사항이 시간이 지남에 따라 증가할 수 있으며, 처음에 부여한 역할과 권한의 일부는 필요 없어질 수 있습니다. 역할 권장사항을 사용하여 애플리케이션에서 실제로 사용 중인 권한과 사용하지 않을 수 있는 권한을 식별합니다. 애플리케이션이 실제로 필요한 것보다 많은 액세스 권한을 부여받지 않도록 영향을 받는 리소스의 허용 정책을 조정합니다. 측면 이동 통계를 사용하여 측면 이동 제한측면 이동은 한 프로젝트의 서비스 계정에 다른 프로젝트의 서비스 계정을 가장할 수 있는 권한이 있는 경우입니다. 예를 들어 프로젝트 A에서 만든 서비스 계정이 프로젝트 B의 서비스 계정을 가장할 수 있는 권한을 보유할 수 있습니다. 이러한 권한은 주 구성원에 의도하지 않은 리소스 액세스 권한을 부여하는 프로젝트 간의 일련의 가장을 일으킬 수 있습니다. 예를 들어 주 구성원은 프로젝트 A에서 서비스 계정을 가장한 후 이 서비스 계정을 사용해서 프로젝트 B의 서비스 계정을 가장할 수 있습니다. 프로젝트 B의 서비스 계정에 조직 내 다른 프로젝트의 다른 서비스 계정을 가장할 수 있는 권한이 있으면 주 구성원이 계속해서 서비스 계정 가장을 사용하여 프로젝트 간에 이동하며 권한을 계속 얻을 수 있습니다. 추천자는 이 문제의 해결을 돕기 위해 측면 이동 통계를 제공합니다. 측면 이동 통계는 한 프로젝트의 서비스 계정이 다른 프로젝트의 서비스 계정을 가장하도록 허용하는 역할을 식별합니다. 측면 이동 통계를 직접 보고 관리하는 방법을 알아보려면 측면 이동 통계 관리를 참조하세요. 일부 측면 이동 통계는 역할 권장사항과 관련됩니다. 이러한 권장사항을 적용하여 프로젝트 간 측면 이동을 줄일 수 있습니다. 자세한 내용은 권장사항 검토 및 적용을 참조하세요. 권한 에스컬레이션 위협으로부터 보호아무런 역할도 부여되지 않았고 어떤 리소스에도 액세스할 수 없으며 방화벽 규칙과 연결되지 않은 서비스 계정은 일반적으로 값이 제한되어 있습니다. 서비스 계정에 리소스에 대한 액세스 권한을 부여하면 서비스 계정의 값이 증가합니다. 서비스 계정은 사용자에게 더 유용한 역할을 하지만 쉽게 권한 에스컬레이션 공격의 대상이 되기도 합니다. 예를 들어 민감한 정보가 포함된 Cloud Storage 버킷에 대한 전체 액세스 권한이 있는 서비스 계정을 가정해 보겠습니다. 이 경우 서비스 계정은 Cloud Storage 버킷 자체만큼 유용합니다. 악의적인 사용자는 버킷에 직접 액세스하는 대신 서비스 계정을 제어하려고 시도할 수 있습니다. 이러한 시도가 성공하면 악의적인 사용자가 서비스 계정을 가장하여 해당 권한을 에스컬레이션할 수 있으며, 이를 통해 버킷의 민감한 정보에 액세스할 수 있습니다. 서비스 계정과 관련된 권한 에스컬레이션 기술은 일반적으로 다음과 같은 카테고리로 분류됩니다.
다음 섹션에서는 권한 에스컬레이션 위협으로부터 서비스 계정을 보호하기 위한 권장사항을 제공합니다. 사용자가 사용자 자신보다 권한이 더 높은 서비스 계정을 가장하는 것을 허용하지 않음서비스 계정을 가장하면 사용자는 서비스 계정에서 액세스할 수 있는 일부 또는 모든 리소스에 액세스할 수 있습니다. 서비스 계정이 사용자보다 더 광범위한 액세스를 가진 경우 사실상 사용자보다 더 많은 권한을 갖게 됩니다. 사용자에게 권한이 더 많은 서비스 계정으로 가장할 수 있는 권한이 부여되면 Linux에서 사용자가 서비스 계정을 가장할 수 있는 권한은 다음과 같습니다.
이러한 권한 중 일부를 포함하는 역할은 다음과 같습니다(이에 국한되지 않음).
사용자에게 역할을 할당하기 전에 먼저 다음과 같이 자문해 보세요.
모든 질문에 확실히 답할 수 없는 경우 역할을 할당하지 마세요. 대신 사용자에게 권한이 낮은 다른 서비스 계정을 부여하는 것이 좋습니다. 사용자가 권한이 더 높은 서비스 계정의 허용 정책을 변경하는 것을 허용하지 않음서비스 계정을 사용하거나 가장할 수 있는 사용자는 서비스 계정의 허용 정책에 의해 캡처됩니다. 허용 정책은 특정 서비스 계정에서
이러한 역할을 사용자에게 할당하려면 먼저 사용자가 서비스 계정을 가장하여 현재 Cloud 프로젝트 내부 및 외부에서 어떤 리소스에 액세스할 수 있는지 확인하세요. 서비스 계정이 사용자보다 더 많은 권한을 가진 경우 사용자가 서비스 계정의 허용 정책을 변경하도록 허용하지 마세요. 사용자가 서비스 계정 키를 만들거나 업로드하도록 허용하지 않음애플리케이션 또는 사용자가 서비스 계정 키를 사용하여 서비스 계정으로 인증할 수 있습니다. 다른 형태의 서비스 계정 가장과는 달리 서비스 계정 키를 사용할 때는 이전과 같은 인증이 필요하지 않습니다. 즉, 서비스 계정 키를 소유한 사람이 이를 사용할 수 있습니다. 따라서 서비스 계정 키를 사용하여 인증하는 것은 다른 형태의 가장과 유사합니다. 사용자에게 서비스 계정 키에 대한 액세스 권한을 부여하거나 새 서비스 계정 키를 만들 수 있는 권한을 부여하면 사용자는 서비스 계정을 가장하고 서비스 계정에서 액세스할 수 있는 모든 리소스에 액세스할 수 있습니다. 서비스 계정 키를 생성 또는
업로드하기 위해서는
Cloud 프로젝트에 서비스 계정 키가 전혀 필요하지 않은 경우 Cloud 프로젝트 또는 바깥쪽 폴더에
서비스 계정 키 생성 사용 중지 및 서비스 계정 키 업로드 사용 중지 조직 정책 제약조건을 적용합니다. 이러한 제약조건을 통해 모든 사용자가 서비스 계정에 대한 Cloud 프로젝트 또는 폴더 수준에서 서비스 계정에 액세스 권한을 부여하지 않음서비스 계정은 리소스이자 리소스 계층 구조의 일부입니다. 따라서 다음 수준으로 서비스 계정에 대한 액세스 권한을 관리할 수 있습니다.
Cloud 프로젝트 수준 또는 리소스 계층 구조의 더 높은 수준에서 액세스 권한을 관리하면 관리 오버헤드를 줄이는 데 도움이 될 수 있지만, 권한이 과도하게 부여될 수 있습니다. 예를 들어 사용자에게 Cloud 프로젝트의 서비스 계정 토큰 생성자 역할을 부여하면 사용자는 Cloud 프로젝트의 모든 서비스 계정을 가장할 수 있습니다. 서비스 계정을 가장할 수 있는 경우 사용자가 Cloud 프로젝트 외부의 리소스를 포함해 해당 서비스 계정으로 액세스할 수 있는 모든 리소스에 액세스할 수 있습니다. 이러한 과도한 권한 부여를 방지하려면 Cloud 프로젝트 또는 폴더 수준에서 서비스 계정에 대한 액세스를 관리하지 마세요. 대신 각 서비스 계정의 액세스 권한을 개별적으로 관리하세요. 권한이 있는 서비스 계정이 연결된 컴퓨팅 리소스에서 보안 수준이 낮은 소스의 코드를 실행하지 않음VM 인스턴스나 Cloud Run 애플리케이션과 같은 컴퓨팅 리소스에 서비스 계정을 연결하면 해당 리소스에서 실행 중인 프로세스가 메타데이터 서버를 사용하여 액세스 토큰 및 ID 토큰을 요청할 수 있습니다. 이러한 토큰을 사용하면 프로세스가 서비스 계정을 가장하고 서비스 계정을 대신하여 리소스에 액세스할 수 있습니다. 기본적으로 메타데이터 서버에 대한 액세스는 특정 프로세스 또는 사용자로 제한되지 않습니다. 대신 컴퓨팅 리소스에서 실행되는 모든 코드는 메타데이터 서버에 액세스하여 액세스 토큰을 얻을 수 있습니다. 이러한 코드에는 다음이 포함될 수 있습니다.
사용자가 코드를 제출하거나 원격 스토리지 위치에서 코드를 읽는 경우, 코드가 신뢰할 수 있고 원격 스토리지 위치의 보안이 연결된 서비스 계정만큼 철저한지 확인해야 합니다. 원격 스토리지 위치가 서비스 계정보다 덜 안전한 경우 악의적인 사용자가 자신의 권한을 에스컬레이션할 수 있습니다. 서비스 계정의 권한을 사용하는 악성 코드를 해당 위치에 삽입하여 이를 수행합니다. 권한이 있는 서비스 계정이 연결된 VM에 대한 셸 액세스 제한일부 컴퓨팅 리소스는 대화형 액세스를 지원하며 사용자가 시스템에 대한 셸 액세스 권한을 얻을 수 있도록 합니다. 예를 들면 다음과 같습니다.
VM 인스턴스에 권한이 있는 서비스 계정이 연결된 경우 시스템에 대한 셸 액세스 권한이 있는 모든 사용자가 서비스 계정을 가장하고 서비스 계정을 대신해 리소스에 액세스할 수 있습니다. 사용자가 이러한 기능을 남용해 권한을 에스컬레이션하지 못하게 하려면 셸 액세스 권한의 보안이 연결된 서비스 계정만큼 철저한지 확인해야 합니다. Linux 인스턴스의 경우 OS 로그인을 사용하여 연결된 서비스 계정에 대한 액세스보다 SSH 액세스를 더
제한적으로 적용할 수 있습니다. OS 로그인이 사용 설정된 VM 인스턴스에 연결하려면 사용자는 OS 로그인을 사용하도록 허용되어야 할 뿐만 아니라 연결된 서비스 계정에 대한 메타데이터 기반 키를 사용하는 VM 인스턴스나 Windows 인스턴스에는 동일한 수준의 액세스 제어가 적용되지 않습니다. 메타데이터에 SSH 키를 게시하거나
Windows 사용자 인증 정보를 요청하려면 VM 인스턴스의 메타데이터에 대한 액세스 권한과 연결된 서비스 계정에 대한 마찬가지로 VM 인스턴스가 인증을 위해 커스텀 Linux 플러그인 가능한 인증 모듈을 사용하거나 Active Directory 도메인의 구성원인 경우 서비스 계정을 가장할 권한이 없는 사용자가 로그인할 수 있습니다. 특히 OS 로그인을 사용하지 않는 VM 인스턴스의 경우 IAP(Identity-Aware Proxy)를 통해 셸 액세스를 제한하는 것이 좋습니다. VM 인스턴스에 연결된 서비스 계정을 가장하도록 허용되어야 하는 사용자에게 IAP 보안 터널 사용자 역할만 부여합니다. 선택된 사용자 및 프로세스에 대한 메타데이터 서버 액세스 제한VM 인스턴스에 서비스 계정을 연결하면 VM에 배포된 워크로드가 메타데이터 서버에 액세스하여 서비스 계정의 토큰을 요청할 수 있습니다. 기본적으로 메타데이터 서버에 대한 액세스는 VM의 특정 프로세스 또는 사용자로 제한되지 않습니다. Linux의 메타데이터 서버 액세스를 특정 사용자로 제한하려면 게스트 운영체제의 호스트 방화벽을 구성하여 이러한 사용자만 메타데이터 서버에 대한 아웃바운드 연결을 열 수 있도록 해야 합니다. Linux에서는 스푸핑 위협으로부터 보호워크로드 아이덴티티 제휴를 사용하면 Cloud 프로젝트와 외부 ID 공급업체 간에 단방향 트러스트 관계를 만들 수 있습니다. 이 트러스트 관계를 설정한 후 외부 ID 공급업체로부터 얻은 사용자 인증 정보를 보안 토큰 서비스(STS) 토큰과 교환할 수 있습니다. 그러면 해당 STS 토큰을 사용하여 서비스 계정에 액세스하거나 가장할 수 있습니다. STS 토큰은 특정 Google ID와 대응하지 않는다는 점에서 액세스 토큰과 다릅니다. 또한 STS 토큰은 외부 ID 공급업체의 특정 ID와 대응하지 않을 수도 있습니다. 대신 STS 토큰은 속성 집합을 나타냅니다. 이러한 속성이 무엇인지에 따라 외부 ID 공급업체의 단일 또는 여러 ID에 대응할 수 있습니다. STS 토큰으로 표현된 속성이 모호하거나 부적절하게 사용되는 경우 악의적인 사용자가 자신의 신원을 스푸핑할 수 있습니다. 다음 섹션에서는 이러한 위장 위협으로부터 보호하는 데 도움이 되는 권장사항을 설명합니다. 속성 매핑 수정 허용하지 않음워크로드 아이덴티티 제휴는 속성 매핑을 사용하여 외부 ID 공급업체에서 제공하는 속성 중 STS 토큰에 삽입할 속성 및 속성 이름을 변환하는 방법을 선택합니다. 속성 매핑 구성은 외부 ID 공급업체와 Google Cloud 간의 트러스트 관계를 설정하는 중요한 단계입니다. 속성 매핑은 워크로드 아이덴티티 제휴를 이용하는 보안에도 중요합니다. 서비스 계정을 가장하고 속성 매핑을 변경할 수 있는 제휴된 주 구성원 또는 주 구성원 집합 권한을 부여한 경우 서비스 계정에 액세스할 수 있는 사용자를 변경할 수 있습니다. 속성 매핑을 수정하려면
악의적인 행위자가 속성 매핑을 수정할 권한이 있으면 ID를 스푸핑하여 서비스 계정에 대한 액세스 권한을 갖도록 매핑 규칙을 변경할 수 있습니다. 이러한 악성 수정을 방지하려면 소수의 관리 사용자만 속성 매핑을 수정할 수 있는 권한을 갖고 있어야 합니다. 리소스 계층 구조의 상위 수준에서 사용자에게 실수로 이러한 역할 중 하나가 할당되는 위험을 제한하기 위해 워크로드 아이덴티티 풀을 관리하기 위한 전용 Cloud 프로젝트를 만드는 것이 좋습니다. 워크로드 아이덴티티 제휴를 사용하면 외부 ID 공급업체 통해 사용자를 인증하고 인증된 사용자에 대한 정확한 정보를 Google Cloud에 보고합니다. ID 공급업체는 속성을 사용하여 인증된 사용자에 대한 정보를 전달합니다. 이러한 속성 중 일부는 일반적으로 권한이 보장되지만 다른 속성은 그렇지 않을 수 있습니다. 예를 들어 외부 ID 공급업체가 OpenID Connect ID 토큰에 사용자 이름과 사용자 ID를 모두 삽입할 수 있습니다. 두 속성 모두 사용자를 고유하게 식별하며 서로 상호 호환될 수 있는 것처럼 보일 수 있습니다. 하지만 외부 ID 공급업체는 사용자 ID가 안정적이고 신뢰할 수 있도록 보장하면서 사용자 이름을 변경하도록 허용할 수 있습니다. 속성 매핑이 안정적이지 않거나 신뢰할 수 없는 속성에 의존하는 경우 악의적인 행위자가 외부 ID 공급업체의 사용자 프로필을 수정하여 ID를 스푸핑할 수 있습니다. 예를 들어 외부 ID 공급업체에서 사용자 이름을 최근에 삭제되었지만 Google Cloud에서 서비스 계정에 계속 액세스할 수 있는 사용자의 이름으로 변경할 수 있습니다. 이러한 스푸핑 공격을 방지하려면 속성 매핑에서 외부 ID 공급업체가 안정적이고 신뢰할 수 있는 것으로 확인된 속성만 사용하도록 합니다. 정보 공개 위협으로부터 보호서비스 계정 이메일 주소에 기밀 정보를 공개하지 않음서비스 계정에 다른 Cloud 프로젝트의 리소스에 대한 액세스 권한을 부여하려면 리소스의 허용 정책에 역할 결합을 추가하면 됩니다. 허용 정책은 리소스 자체와 마찬가지로 다른 Cloud 프로젝트의 일부이며 다른 Cloud 프로젝트에서 공개 상태가 제어됩니다. 허용 정책 보기는 일반적으로 권한 작업으로 간주되지 않습니다. 대부분의 역할에는 기본 뷰어 역할을 비롯해 필요한 허용 정책을 볼 수 있는 사용자는 리소스 액세스가 부여된 주 구성원의 이메일 주소도 볼 수 있습니다. 서비스 계정의 경우 이메일 주소는 악의적인 사용자에게 힌트를 제공할 수 있습니다. 예를 들어 허용 정책에는 이메일 주소 샌드박스 또는 개발 Cloud 프로젝트 등 액세스 권한이 덜 엄격하게 제어되는 Cloud 프로젝트의 리소스에 대한 액세스 권한을 서비스 계정에 부여할 경우 서비스 계정의 이메일 주소가 모든 정보를 공개하지 않도록 해야 합니다. 특히 기밀이거나 공격자에게 힌트를 제공할 수 있는 정보를 공개하면 안 됩니다. 부인 방지 위협으로부터 보호Google Cloud의 리소스 중 하나에 영향을 미치는 의심스러운 활동이 감지되었을 때, Cloud 감사 로그는 활동이 언제 발생했는지, 어떤 사용자가 관련되었는지를 확인하는 데 중요한 정보 소스입니다. Cloud 감사 로그에서 서비스 계정에 의해 활동이 발생했음을 나타내는 경우 이 정보만으로는 이벤트의 전체 체인을 재구성하는 데 충분하지 않을 수 있습니다. 서비스 계정에서 활동을 수행하게 만든 사용자 또는 애플리케이션을 찾을 수 있어야합니다. 이 섹션에는 거부할 수 없는 감사 추적을 유지하는 데 도움이 되는 권장사항을 제공합니다. IAM API의 데이터 액세스 로그 사용 설정서비스 계정 가장 시나리오를 식별하고 이해할 수 있도록 Compute Engine과 같은 서비스에는 Cloud 감사 로그에 일부 서비스는 Cloud 감사 로그에서 가장에 대한 세부정보를 포함하지 않습니다. 가장 이벤트를 기록하려면 다음 API에 대한 데이터 액세스 로그도 사용 설정해야 합니다.
이러한 로그를 사용 설정하면 사용자가 액세스 토큰 또는 서비스 계정의 ID 토큰을 요청할 때마다 Cloud 감사 로그에 항목이 추가됩니다. CI/CD 기록이 Cloud 감사 로그와 상호 연결될 수 있는지 확인서비스 계정은 일반적으로 코드 변경이 성공적으로 확인되고 배포가 승인된 후 CI/CD 시스템에서 배포를 수행하는 데 사용됩니다. 일반적으로 CI/CD 시스템은 배포로 이어지는 이벤트 기록을 유지합니다. 이 기록에는 해당 코드 검토, 커밋, 파이프라인 실행 ID 및 배포를 승인한 사람에 대한 정보가 포함될 수 있습니다. 배포에 의해 Google Cloud의 리소스가 수정되면 이러한 변경사항은 각 리소스의 Cloud 감사 로그에서 추적됩니다. Cloud 감사 로그에는 변경을 시작한 사용자 또는 서비스 계정에 대한 정보가 포함됩니다. 하지만 CI/CD 시스템에 의해 트리거된 배포에서는 서비스 계정 자체만으로 변경에 기여한 전체 체인을 재구성할 수 없는 경우가 많습니다. CI/CD 시스템과 Google Cloud 전체에 일관된 감사 추적을 설정하려면 Cloud 감사 로그 기록이 CI/CD 시스템 기록의 이벤트와 상호 연관될 수 있는지 확인해야 합니다. Cloud 감사 로그에서 예기치 않은 이벤트가 발생하면 이 상관관계를 사용하여 변경사항이 CI/CD 시스템에서 실제로 수행되었는지 여부, 수행된 이유 및 승인한 사람을 확인할 수 있습니다. Cloud 감사 로그 레코드와 CI/CD 시스템 기록 간의 상관관계를 설정하는 방법은 다음과 같습니다.
거부되지 않도록 하려면 로그 파일을 구성하고 기록을 커밋하여 악의적인 행위자가 추적을 소급하여 숨길 수 없도록 합니다. 다음 단계
|