운영 권장사항

Last reviewed 2023-12-20 UTC

이 섹션에서는 Google Cloud 환경에 추가 워크로드를 배포하고 운영할 때 고려해야 하는 작업을 소개합니다. 이 섹션에서는 클라우드 환경의 모든 작업을 전부 다루지는 않지만 청사진에 의해 배포된 아키텍처 추천 및 리소스와 관련된 결정 사항을 소개합니다.

기반 리소스 업데이트

청사진은 기반 환경에 대한 독자적인 시작점을 제공하지만 시간이 지남에 따라 기반 요구사항이 증가할 수 있습니다. 초기 배포 후에는 구성 설정을 조정하거나 모든 워크로드에서 사용할 새로운 공유 서비스를 빌드할 수 있습니다.

기반 리소스를 수정하려면 기반 파이프라인을 통해 모든 변경을 수행하는 것이 좋습니다. 브랜칭 전략에서 코드 작성, 병합, 배포 파이프라인 트리거의 흐름에 대한 소개를 검토하세요.

새 워크로드 프로젝트의 속성 결정

자동화 파이프라인의 프로젝트 팩토리 모듈을 통해 새 프로젝트를 만들 경우 다양한 속성을 구성해야 합니다. 새 워크로드를 위한 프로젝트를 설계하고 만드는 프로세스에는 다음과 같은 결정이 포함되어야 합니다.

  • 사용 설정할 Google Cloud API
  • 사용할 공유 VPC 또는 새 VPC 네트워크 생성 여부
  • 파이프라인에서 생성된 초기 project-service-account에 만들 IAM 역할
  • 적용할 프로젝트 라벨
  • 프로젝트가 배포된 폴더
  • 사용할 결제 계정
  • VPC 서비스 제어 경계에 프로젝트를 추가할지 여부
  • 프로젝트의 예산 및 결제 알림 기준 구성 여부

각 프로젝트의 구성 가능 속성에 대한 자세한 내용은 자동화 파이프라인의 프로젝트 팩토리 입력 변수를 참조하세요.

대규모 권한 관리

기반을 토대로 워크로드 프로젝트를 배포하는 경우 해당 프로젝트에서 의도한 개발자 및 소비자에게 액세스 권한을 어떻게 부여할지 고려해야 합니다. 기존 ID 공급업체에서 관리하는 그룹에 사용자를 추가하고 그룹을 Cloud ID와 동기화한 다음 그룹에 IAM 역할을 적용하는 것이 좋습니다. 항상 최소 권한의 원칙을 염두에 두세요.

또한 IAM 추천자를 사용하여 과도한 권한을 가진 역할을 부여하는 허용 정책을 식별하는 것이 좋습니다. 주기적으로 추천을 검토하거나 추천을 배포 파이프라인에 자동으로 적용하는 프로세스를 설계합니다.

네트워킹팀과 애플리케이션팀 간의 변경 조정

청사진에서 배포된 네트워크 토폴로지에서는 네트워크 리소스 관리를 담당하는 팀과 워크로드 인프라 리소스를 배포하는 별도의 팀이 있다고 가정합니다. 워크로드팀이 인프라를 배포할 때 워크로드의 구성요소 간에 의도된 액세스 경로를 허용하도록 방화벽 규칙을 만들어야 하지만 이 팀에는 자체적으로 네트워크 방화벽 정책을 수정할 권한이 없습니다.

두 팀이 함께 애플리케이션을 배포하는 데 필요한 중앙 집중식 네트워킹 리소스에 대한 변경사항을 조정할 방법을 계획합니다. 예를 들어 워크로드팀에서 해당 애플리케이션의 태그를 요청하는 프로세스를 설계할 수 있습니다. 그런 다음 네트워킹팀에서 태그를 만들고 네트워크 방화벽 정책에 태그가 있는 리소스 간에 트래픽 흐름을 허용하는 규칙을 추가하고 워크로드팀에 태그를 사용하기 위한 IAM 역할을 위임합니다.

Active Assist 포트폴리오로 환경 최적화

IAM 추천자 외에도 Google Cloud는 환경을 최적화하는 방법을 추천하는 서비스의 Active Assist 포트폴리오를 제공합니다. 예를 들어 방화벽 통계 또는 미사용 프로젝트 추천자는 보안 상황을 강화하는 데 도움이 될 수 있는 실행 가능한 추천을 제공합니다.

주기적으로 추천을 검토하거나 추천을 배포 파이프라인에 자동으로 적용하는 프로세스를 설계합니다. 중앙팀이 관리해야 할 추천과 워크로드 소유자가 담당해야 할 추천을 결정하고 그에 따라 IAM 역할을 적용하여 추천에 액세스합니다.

조직 정책에 예외 부여

청사진은 대부분의 시나리오에서 대다수 고객에게 권장되는 조직 정책 제약조건 집합을 적용하지만 광범위하게 시행하는 조직 정책에 대한 제한적인 예외가 필요한 적법한 사용 사례가 있을 수 있습니다.

예를 들어 청사진은 iam.disableServiceAccountKeyCreation 제약조건을 적용합니다. 유출된 서비스 계정 키는 상당히 부정적인 영향을 미칠 수 있으며 대부분의 시나리오에서는 인증을 위해 서비스 계정 키에 보다 안전한 대안을 사용해야 하므로 이 제약조건은 중요한 보안 제어입니다. 그러나 Google Cloud 서비스에 액세스해야 하고 워크로드 아이덴티티 제휴를 사용할 수 없는 온프레미스 서버와 같이 서비스 계정 키로만 인증할 수 있는 사용 사례가 있을 수 있습니다. 이 시나리오에서는 서비스 계정 키 관리 권장사항과 같은 추가 보완 제어 기능이 시행되는 한 정책에 대한 예외를 허용하도록 결정할 수 있습니다.

따라서 워크로드에서 정책에 대한 예외를 요청할 수 있도록 프로세스를 설계하고, 예외 부여를 담당하는 의사 결정자가 사용 사례를 검증할 수 있는 기술적 지식을 갖추고 있는지 확인하고 추가적인 제어를 통해 보완해야 하는지 여부를 상담해야 합니다. 워크로드에 예외를 부여할 때는 조직 정책 제약조건을 가능한 제한적으로 수정합니다. 정책 예외 또는 적용을 부여하는 태그를 정의한 다음 프로젝트 및 폴더에 태그를 적용하여 조직 정책에 제약조건을 조건부로 추가할 수도 있습니다.

VPC 서비스 제어로 리소스 보호

청사진을 사용하면 기본 네트워크와 제한된 네트워크를 분리하여 VPC 서비스 제어를 위한 환경을 준비할 수 있습니다. 그러나 VPC 서비스 제어를 사용 설정할 경우 프로세스가 중단될 수 있으므로 기본적으로 Terraform 코드는 VPC 서비스 제어를 사용 설정하지 않습니다.

경계는 콘솔, 개발자 워크스테이션, 리소스 배포에 사용되는 기반 파이프라인을 포함하는 경계 외부에서 시작되는 제한적인 Google Cloud 서비스 액세스를 거부합니다. VPC 서비스 제어를 사용하는 경우 의도한 액세스 경로를 허용하는 경계에 대한 예외를 설계해야 합니다.

VPC 서비스 제어 경계는 Google Cloud 조직과 외부 소스 사이의 유출 제어를 위한 것입니다. 경계는 개별 프로젝트 또는 리소스에 대한 세분화된 액세스 제어를 위해 허용 정책을 대체하거나 복제하기 위한 것이 아닙니다. 경계를 설계할 때는 관리 오버헤드를 낮추기 위해 공통 통합 경계를 사용하는 것이 좋습니다.

Google Cloud 조직 내에서 서비스 트래픽을 세밀하게 제어하도록 여러 경계를 설계해야 하는 경우 보다 복잡한 경계 구조로 해결되는 위협과 의도된 작업에 필요한 경계 간 액세스 경로를 명확하게 정의하는 것이 좋습니다.

VPC 서비스 제어를 채택하려면 다음을 평가합니다.

경계가 사용 설정된 후 새 프로젝트를 올바른 경계에 일관적으로 추가하는 프로세스와 개발자에게 현재 경계 구성에서 거부하는 새 사용 사례가 있을 때 예외를 설계하는 프로세스를 설계하는 것이 좋습니다.

별도의 조직에서 조직 전체 변경사항 테스트

테스트 없이 변경사항을 프로덕션에 배포하지 않는 것이 좋습니다. 워크로드 리소스의 경우 이 접근 방식은 개발, 비프로덕션, 프로덕션을 위한 별도의 환경에서 원활하게 수행됩니다. 그러나 조직의 일부 리소스에는 원활한 테스트를 위한 별도의 환경이 없습니다.

조직 수준의 변경사항이거나 ID 공급업체와 Cloud ID 간의 구성과 같이 프로덕션 환경에 영향을 줄 수 있는 기타 변경사항은 테스트 목적으로 별도의 조직을 만드는 것이 좋습니다.

가상 머신에 대한 원격 액세스 제어

기반 파이프라인, 인프라 파이프라인, 애플리케이션 파이프라인을 통해 변경할 수 없는 인프라를 배포하는 것이 좋습니다. 따라서 제한적이거나 예외적인 사용 사례에서는 SSH 또는 RDP를 통해 개발자에게 가상 머신에 대한 직접 액세스 권한만 부여하는 것이 좋습니다.

원격 액세스가 필요한 시나리오에서는 가능하면 OS 로그인을 사용하여 사용자 액세스를 관리하는 것이 좋습니다. 이 접근 방식은 관리형 Google Cloud 서비스를 사용하여 액세스 제어, 계정 수명 주기 관리, 2단계 인증, 감사 로깅을 사용합니다. 또는 메타데이터의 SSH 키 또는 RDP 사용자 인증 정보를 통해 액세스를 허용해야 할 경우 사용자 인증 정보 수명 주기를 관리하고 사용자 인증 정보를 Google Cloud 외부에 안전하게 및 저장할 책임이 사용자에게 있습니다.

어떤 경우든 VM에 대한 SSH 또는 RDP 액세스 권한이 있는 사용자는 권한 에스컬레이션 위험이 있을 수 있으므로 이를 염두에 두고 액세스 모델을 설계해야 합니다. 이러한 사용자는 연결된 서비스 계정의 권한으로 해당 VM에서 코드를 실행하거나 메타데이터 서버를 쿼리하여 API 요청을 인증하는 데 사용되는 액세스 토큰을 볼 수 있습니다. 사용자가 서비스 계정의 권한으로 작업하도록 의도한 것이 아니라면 이러한 액세스는 권한 에스컬레이션이 될 수 있습니다.

예산 알림 계획을 통한 과다 지출 완화

청사진은 비용 관리를 위해 다음을 포함하여 Google Cloud 아키텍처 프레임워크: 비용 최적화에 소개된 권장사항을 구현합니다.

  • 기업 기반의 모든 프로젝트에서 단일 결제 계정을 사용합니다.

  • 각 프로젝트에 비용 센터 간 비용 할당에 사용되는 billingcode 메타데이터 라벨을 할당합니다.

  • 예산 및 알림 기준을 설정합니다.

예산을 계획하고 결제 알림을 구성하는 것은 사용자의 책임입니다. 이 청사진은 예상 지출이 예산의 120%에 도달하는 추세를 보일 때 워크로드 프로젝트의 예산 알림을 만듭니다. 이 접근 방식을 사용하면 중앙팀에서 상당한 과다 지출 이슈를 식별하고 완화할 수 있습니다. 명확한 원인 없이 예기치 않게 지출이 크게 증가할 경우 보안 사고의 징후일 수 있으므로 비용 관리 및 보안 관점에서 이를 조사해야 합니다.

사용 사례에 따라 프로젝트마다 세분화된 예산을 설정하는 대신 전체 환경 폴더 또는 특정 비용 센터와 관련된 모든 프로젝트의 비용을 기준으로 예산을 설정할 수 있습니다. 또한 일상적인 모니터링을 위해 보다 세분화된 알림 기준을 설정할 수 있는 워크로드 소유자에게 예산 및 알림 설정을 위임하는 것이 좋습니다.

워크로드의 예산 예측 등 FinOps 기능 빌드에 대한 안내는 Google Cloud에서 FinOps 시작하기를 참조하세요.

내부 비용 센터 간 비용 할당

콘솔에서 결제 보고서를 확인하여 여러 측정기준에서 비용을 보고 예측할 수 있습니다. 사전 제작된 보고서 외에도 prj-c-billing-logs 프로젝트의 BigQuery 데이터 세트로 결제 데이터를 내보내는 것이 좋습니다. 내보낸 결제 레코드를 사용하면 billingcode와 같은 프로젝트 라벨 메타데이터를 기준으로 내부 비용 센터와 같은 커스텀 측정기준에 비용을 할당할 수 있습니다.

다음 SQL 쿼리는 billingcode 프로젝트 라벨별로 그룹화된 모든 프로젝트의 비용을 이해하기 위한 샘플 쿼리입니다.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

이 내보내기를 설정하려면 Cloud Billing 데이터를 BigQuery로 내보내기를 참조하세요.

비용 센터 간에 내부 회계 또는 지불 거절이 필요한 경우 이 쿼리에서 얻은 데이터를 내부 프로세스에 통합할 책임은 사용자에게 있습니다.

탐지 통제에서 기존 SIEM으로 발견 항목 수집

기반 리소스는 감사 로그 및 보안 발견 항목에 대한 집계된 대상을 구성하는 데 도움이 되지만, 이러한 신호를 소비하고 사용하는 방법을 결정할 책임은 사용자에게 있습니다.

모든 클라우드 및 온프레미스 환경의 로그를 기존 SIEM으로 집계해야 하는 경우 prj-c-logging 프로젝트의 로그와 Security Command Center의 발견 항목을 기존 도구 및 프로세스로 수집할 방법을 결정합니다. 단일 팀이 전체 환경의 보안을 모니터링해야 하는 경우 모든 로그 및 발견 항목에 대한 단일 내보내기를 만들거나, 서로 책임이 다른 여러 팀에 필요한 로그 및 발견 항목 집합으로 필터링된 여러 개의 내보내기를 만들 수 있습니다.

또는 로그 볼륨과 비용이 너무 큰 경우 Google Cloud 로그와 발견 항목만 Google Cloud에 보관하여 중복을 방지할 수 있습니다. 이 시나리오에서는 기존 팀이 Google Cloud에서 직접 로그 및 발견 항목을 사용할 수 있는 적절한 액세스 권한과 교육을 제공받아야 합니다.

  • 감사 로그의 경우 로그를 여러 버킷에 복제하여 로그 스토리지 비용을 늘리는 대신 로그 뷰를 설계하여 중앙 집중식 로그 버킷의 로그 하위 집합에 대한 액세스를 개별 팀에 부여합니다.
  • 보안 발견 항목의 경우 Security Command Center의 폴더 수준 및 프로젝트 수준 역할을 부여하면 팀이 콘솔에서 직접 담당하는 프로젝트의 보안 발견 항목만 보고 관리할 수 있습니다.

제어 라이브러리의 지속적인 개발

청사진은 위협을 감지하고 방지하기 위한 제어 기준으로 시작됩니다. 이러한 제어를 검토하고 요구사항에 따라 제어를 추가하는 것이 좋습니다. 다음 표에는 거버넌스 정책을 적용하는 메커니즘과 추가 요구사항을 위한 확장 방법이 요약되어 있습니다.

청사진에 의해 적용되는 정책 제어 제어 확장 안내

Security Command Center는 여러 보안 소스에서 취약점과 위협을 감지합니다.

Security Health Analytics용 커스텀 모듈 및 Event Threat Detection용 커스텀 모듈을 정의합니다.

조직 정책 서비스는 Google Cloud 서비스에서 권장 조직 정책 제약조건 집합을 적용합니다.

사용 가능한 제약조건의 사전 제작된 목록에서 추가 제약조건을 적용하거나 커스텀 제약조건을 만듭니다.

Open Policy Agent(OPA) 정책은 배포 전에 허용 가능한 구성에 대해 기반 파이프라인의 코드를 검증합니다.

GoogleCloudPlatform/policy-library의 안내에 따라 추가 제약조건을 개발합니다.

로그 기반 측정항목 및 성능 측정항목 알림은 일부 민감한 리소스의 IAM 정책 및 구성에 대한 변경사항을 알리도록 로그 기반 측정항목을 구성합니다.

환경에서 발생하면 안 되는 로그 이벤트에 대한 추가적인 로그 기반 측정항목과 알림 정책을 설계합니다.

자동화된 로그 분석을 위한 커스텀 솔루션은 의심스러운 활동이 있는지 정기적으로 로그를 쿼리하고 Security Command Center 발견 항목을 만듭니다.

보안 로그 분석을 참조로 사용하여 모니터링하려는 보안 이벤트에 대한 발견 항목을 만드는 추가 쿼리를 작성합니다.

애셋 변경사항에 대응하는 커스텀 솔루션은 Security Command Center 발견 항목을 만들고 해결 작업을 자동화할 수 있습니다.

추가 Cloud 애셋 인벤토리 피드를 만들어 특정 애셋 유형의 변경사항을 모니터링하고 커스텀 로직으로 Cloud Functions를 추가로 작성하여 정책 위반에 대응합니다.

이러한 제어는 Google Cloud 변경사항에 대한 요구사항 및 성숙도에 따라 발전할 수 있습니다.

Cloud Key Management Service로 암호화 키 관리

Google Cloud는 모든 고객 콘텐츠의 기본 저장 데이터 암호화를 제공하지만 저장 데이터의 암호화 키에 대한 추가적인 제어를 위해 Cloud Key Management Service(Cloud KMS)도 제공합니다. 기본 암호화로 충분한지 또는 Cloud KMS를 사용하여 키를 직접 관리해야 하는 규정 준수 요구사항이 있는지 평가하는 것이 좋습니다. 자세한 내용은 저장 데이터 암호화에 대한 규정 준수 요건을 충족하는 방법 결정을 참조하세요.

청사진에서는 공통 폴더에 prj-c-kms 프로젝트를 제공하고 암호화 키를 중앙에서 관리할 수 있도록 각 환경 폴더에 prj-{env}-kms 프로젝트를 제공합니다. 이 접근 방식을 사용하면 중앙팀이 워크로드 프로젝트의 리소스에서 사용하는 암호화 키를 감사하고 관리하여 규제 및 규정 준수 요구사항을 충족할 수 있습니다.

운영 모델에 따라서는 하나의 팀이 통제하는 Cloud KMS의 단일 중앙 집중식 프로젝트 인스턴스를 선호할 수도 있고, 각 환경에서 암호화 키를 개별적으로 관리하는 방식을 선호할 수도 있고, 암호화 키에 대한 책임을 적절한 팀에 위임할 수 있도록 분산된 여러 인스턴스를 선호할 수도 있습니다. Terraform 코드 샘플을 운영 모델에 맞게 적절히 수정하세요.

고객 관리 암호화 키(CMEK) 조직 정책을 적용하여 특정 리소스 유형에서 CMEK 키를 필수화하고 신뢰할 수 있는 프로젝트의 허용 목록에 있는 CMEK 키만 사용 가능하도록 할 수도 있습니다.

Secret Manager로 애플리케이션 사용자 인증 정보 저장 및 감사

API 키, 비밀번호, 비공개 인증서와 같은 민감한 보안 비밀은 어떠한 경우에도 소스 코드 저장소에 커밋하지 않는 것이 좋습니다. 대신 보안 비밀을 Secret Manager에 커밋하고 보안 비밀에 액세스해야 하는 사용자 또는 서비스 계정에 Secret Manager 보안 비밀 접근자 IAM 역할을 부여하세요. 프로젝트의 모든 보안 비밀이 아닌 개별 보안 비밀에 IAM 역할을 부여하는 것이 좋습니다.

가능한 경우 CI/CD 파이프라인 내에서 프로덕션 보안 비밀을 자동으로 생성하고 breakglass 상황이 아니라면 실제 사용자가 액세스할 수 없도록 유지해야 합니다. 이 시나리오에서는 사용자 또는 그룹에 이러한 보안 비밀을 조회할 수 있는 IAM 역할을 부여하지 않아야 합니다.

청사진에서는 공통 폴더에 단일 prj-c-secrets 프로젝트를 제공하고 보안 비밀을 중앙에서 관리할 수 있도록 각 환경 폴더에 prj-{env}-secrets 프로젝트를 제공합니다. 이렇게 하면 중앙팀에서 규제 및 규정 준수 요구사항을 충족하기 위해 애플리케이션에서 사용하는 보안 비밀을 감사하고 관리할 수 있습니다.

운영 모델에 따라서는 하나의 팀이 통제하는 Secret Manager의 단일 중앙 집중식 인스턴스를 선호할 수도 있고, 각 환경에서 보안 비밀을 개별적으로 관리하는 방식을 선호할 수도 있고, 각 워크로드 팀이 자체 보안 비밀을 관리할 수 있도록 Secret Manager의 분산된 여러 인스턴스를 선호할 수도 있습니다. Terraform 코드 샘플을 운영 모델에 맞게 적절히 수정하세요.

권한이 높은 계정에 대한 breakglass 액세스 계획

기반 리소스에 대한 변경사항은 기반 파이프라인에서 배포하는 버전 제어 IaC를 통해 관리하는 것이 좋지만, 환경을 직접 수정하기 위해 높은 액세스 권한이 필요한 예외 또는 긴급 시나리오가 있을 수 있습니다. 긴급 상황이나 자동화 프로세스가 중단되는 상황에 대비하여 높은 권한으로 환경에 액세스할 수 있는 breakglass 계정(파이어콜 또는 긴급 계정이라고도 함)을 마련해 두는 것이 좋습니다.

다음 표에서는 breakglass 계정의 몇 가지 용도를 제시합니다.

breakglass 용도 설명

최고 관리자

예를 들어 ID 제휴 또는 다중 인증(MFA)과 관련된 문제를 해결하려는 경우 Cloud ID와 함께 사용되는 최고 관리자 역할에 대한 긴급 액세스 권한입니다.

조직 관리자

조직 관리자 역할에 대한 긴급 액세스 권한입니다. 그런 다음 조직의 다른 IAM 역할에 대한 액세스 권한을 부여할 수 있습니다.

기반 파이프라인 관리자

기반 파이프라인 자동화가 손상된 경우 Google Cloud의 CICD 프로젝트와 외부 Git 저장소에 있는 리소스를 수정하는 긴급 액세스 권한입니다.

작업 또는 SRE

운영팀 또는 SRE팀이 서비스 중단 또는 이슈에 대응하려면 높은 액세스 권한이 필요합니다. VM 재시작 또는 데이터 복원과 같은 작업이 여기에 포함될 수 있습니다.

breakglass 액세스를 허용하는 메커니즘은 기존 도구 및 절차에 따라 다르지만 다음과 같은 몇 가지 메커니즘을 예로 들 수 있습니다.

  • 높은 액세스 권한을 관리하는 기존 도구를 사용하여 권한이 높은 IAM 역할로 사전 정의된 그룹에 사용자를 임시로 추가하거나 권한이 높은 계정의 사용자 인증 정보를 사용합니다.
  • 관리자 전용 계정을 사전 프로비저닝합니다. 예를 들어 개발자 Dana에게 평상시 용도의 ID인 dana@example.com과 breakglass 액세스용 ID인 admin-dana@example.com이 있을 수 있습니다.
  • 적시 권한 부여된 액세스와 같이 권한이 더 높은 역할을 개발자가 자신에게 부여할 수 있는 애플리케이션을 사용합니다.

사용하는 메커니즘에 관계없이, 다음과 같은 질문을 운영상으로 어떻게 해결할지를 고려하세요.

  • breakglass 액세스의 범위와 세부사항을 어떻게 설계하나요? 예를 들어 여러 사업부가 서로 영향을 주지 않도록 각기 다른 breakglass 메커니즘을 설계할 수 있습니다.
  • 메커니즘에서 악용을 어떻게 방지하나요? 승인이 필요한가요? 예를 들어 한 사람이 사용자 인증 정보를 보유하고 다른 사람이 MFA 토큰을 보유하도록 운영을 분할할 수 있습니다.
  • breakglass 액세스를 어떻게 감사하고 알림을 보내나요? 예를 들어 사전 정의된 breakglass 계정이 사용될 때 보안 발견 항목을 만들도록 커스텀 Event Threat Detection 모듈을 구성할 수 있습니다.
  • 이슈가 종료된 후 breakglass 액세스를 삭제하고 정상 운영을 재개하는 방법은 무엇인가요?

일반적인 권한 에스컬레이션 작업 및 변경사항 롤백의 경우 사용자 ID에 대한 권한 에스컬레이션 없이 사용자가 작업을 수행할 수 있도록 자동화된 워크플로를 설계하는 것이 좋습니다. 이 접근 방식은 사용자의 실수를 줄이고 보안을 강화하는 데 도움이 될 수 있습니다.

시스템에 정기적으로 개입해야 하는 경우 수정 자동화가 가장 좋은 해법일 수 있습니다. Google은 고객이 제로터치 프로덕션 방식을 채택하여 자동화, 안전 프록시 또는 감사되는 breakglass를 사용하여 모든 프로덕션 변경을 수행하도록 권장합니다. Google은 Google의 SRE 방식을 채택하려는 고객을 위해 SRE 도서를 제공합니다.

다음 단계