Apigee CMEK 권장사항

이 페이지에서는 Apigee를 사용한 CMEK 권장사항에 대해 설명합니다.

위험 방지

현재 Apigee는 제한된 고객 관리 암호화 키 기능을 지원합니다. CMEK 키 또는 키 버전이 실수로 폐기되는 것을 방지하려면 다음을 구현하는 것이 좋습니다.

• 액세스 제어 강화: roles/cloudkms.admin 역할 또는 키 폐기/업데이트 권한을 제한하세요. 신뢰할 수 있는 관리자 또는 상급 팀 구성원에 대해서만 권한을 부여하세요.
• 정기 권한 감사: 시간이 지남에 따라 권한이 의도치 않게 확장되지 않는지 확인하세요.
• 자동 키 폐기: 키를 자동으로 폐기/사용 중지하는 자동화 기능을 설정하지 마세요.

키 폐기 기간 및 순환 설정

• 기본 폐기 기간 확장 고려: 예정된 기본 폐기 기간은 30일입니다. 조직 정책을 통해 키를 생성하거나 더 긴 기간을 적용하여 커스텀 폐기를 설정하면 실수로 삭제했을 때 복구 시간을 더 많이 확보할 수 있습니다. 폐기 대기 기간이 길어지면 위험이 증가한다고 생각되는 경우, 폐기 기간이 길어지면 키가 실수로 삭제되는 것을 방지하는 데 도움이 된다는 점을 기억하세요. 이익과 위험을 모두 고려하여 필요에 가장 적합한 폐기 기간을 결정할 수 있습니다.
• 폐기 전 키 사용 중지 필요: 키 폐기를 예약하기 전에 키 버전을 사용 중지하는 것이 좋습니다. 이렇게 하면 키가 현재 사용되지 않는지 확인하는 데 도움이 되며, 키 버전을 폐기해도 안전한지 확인하는 데 중요한 단계입니다.
• 키 순환 구현: 키를 정기적으로 순환하면 잠재적으로 손상 영향을 줄일 수 있습니다. 키가 손상되더라도 정기적으로 키를 순환하면 손상에 취약한 실제 메시지 수가 제한됩니다.

Apigee의 키 순환

키 순환의 기본 목적은 오래된 키 버전을 완전히 대체하는 것이 아니라 하나의 키로 암호화되는 데이터 양을 줄이는 데 있습니다. 런타임 키와 컨트롤 플레인 키 모두 원래 키 버전은 처음 생성된 순간부터 리소스에 연결된 상태로 유지됩니다.

설명 예시

• Apigee 인스턴스는 키 순환 후에도 항상 생성 시점에 활성 상태였던 기본 CMEK 키 버전을 사용합니다.
• 프록시 번들은 처음 생성되었을 때 활성 상태였던 기본 CMEK 키 버전을 계속 사용합니다. 하지만 이 프록시 번들이 키 순환 이후 수정된 경우 그 안의 새로운 데이터는 새로운 기본 키 버전으로 암호화됩니다.

현재 제한사항: 자동 재암호화 없음

Apigee는 현재 키 순환 시 기존 데이터에 대한 자동 재암호화를 지원하지 않는다는 점에 유의해야 합니다. 신규 데이터 중 일부만 새로운 기본 키 버전으로 암호화됩니다. 분석, 런타임 디스크 데이터, 오래된 프록시 버전과 같은 데이터 대부분은 여전히 이전 키 버전으로 암호화됩니다.

키 사용 중지

키를 사용 중지하거나 폐기하면 Apigee 기능이 방해됩니다. 키를 먼저 사용 중지하면 나중에 거짓 경보로 판명된 경우 키를 다시 사용 설정할 수 있습니다.

키(또는 키 버전) 손상이 의심되는 경우 다음 안내를 따르세요.

• 고위험 시나리오: Apigee 데이터가 민감한 정보이고 공격자가 이를 악용할 가능성이 높으면 즉시 키를 사용 중지하고 키에 대한 액세스 권한을 취소하세요. apigee 인스턴스 및 apigee 조직을 다시 만들기 전에 키를 먼저 사용 중지해야 합니다.
• 저위험 시나리오: 잠재적인 위험보다 다운타임을 최소화하는 것이 더 중요하면 CMEK를 사용 중지/삭제하기 전에 먼저 apigee 인스턴스와 apigee 조직을 다시 만들어야 합니다. 백업/복원 투자로 다운타임을 사전에 방지하는 방법은 아래를 참조하세요.
• 지원팀 연락: 키가 손상되어 이를 사용 중지해야 할 경우에는 Google Cloud Customer Care에 연락하는 것이 좋습니다.

키 사용 중지/취소/폐기에 대한 영향은 아래를 참조하세요. 키를 사용 중지한 후에는 apigee 조직/인스턴스를 다시 만들어야 합니다. 권장사항을 참조하세요.

• 런타임 CMEK 손상: 새 CMEK로 새 인스턴스를 만든 후 트래픽이 마이그레이션 후 이전 런타임 CMEK는 물론 원래 인스턴스도 삭제합니다.
• 모든 CMEK 손상: 새 CMEK로 새 apigee 조직을 만들고, 구성을 복제하고, 트래픽을 전환한 후 이전 조직을 종료하고 원래 CMEK를 사용 중지/삭제합니다.
• Google Cloud Customer Care 연락: 인스턴스 또는 apigee 조직 삭제/재생성을 위한 API가 너무 오래 걸리면 Google Cloud Customer Care에 연락하세요.

키 사용 중지/권한 취소/폐기 영향

키를 사용 중지, 권한 취소, 폐기하면 Apigee가 올바르게 작동하지 않을 수 있습니다. 영향은 다음과 같습니다.

• 전체 키 사용 중지/권한 취소/폐기: Apigee의 고객용 API 작동이 즉시 멈춥니다. 몇 분 내에 내부 시스템 오류가 발생하여 프록시 배포, 런타임 트래픽, 분석, API 보안에 영향을 줍니다. 몇 주 후 디스크 재마운트 문제로 인해 인스턴스를 완전히 시작할 수 없게 됩니다.
• 키 버전 사용 중지/권한 취소/폐기(기본 키 버전 또는 이전 키 버전 모두 포함): 해당 키 버전을 사용하는 Apigee의 고객용 API 작동이 즉시 멈춥니다. 일부 내부 시스템과 런타임 트래픽이 영향을 받습니다. 키 버전이 디스크 암호화에 사용된 경우 인스턴스를 시작할 수 없게 될 수 있습니다.

키 다시 사용 설정

손상이 거짓 경보이거나 키 사용 중지가 의도한 것이 아니라면 키가 사용 중지되었을 때 키를 다시 사용 설정할 수 있습니다. 키를 다시 사용 설정하면 고객용 API 기능이 복원됩니다. 내부 시스템은 몇 분 내에 복구됩니다. 하지만 키를 사용할 수 없는 기간 동안 API 보안 및 분석에 대한 데이터 손실이 발생할 수 있습니다.

• 키 사용 중지 기간이 짧은 경우: API 보안 및 분석의 일부 데이터 손실을 제외하고 시스템이 복구됩니다.
• 키 사용 중지 기간이 긴 경우: 트래픽 서빙을 수행하도록 시스템이 복구되지만 특정 리전이 반환하는 값과 이전에 작동 중지된 리전이 반환하는 값이 달라지는 데이터 불일치로 이어질 수 있습니다. Google Cloud Customer Care에 문의하여 Apigee 클러스터를 수정하세요.

키 삭제

키를 삭제하기 전 다음을 고려하세요.

• 정리 목적인 경우: 키 삭제 전 Apigee에서 키 사용을 파악하기 위해 키 추적 기능을 제공할 때까지 이전 키를 삭제하지 마세요.
• 삭제가 필요한 경우: 키를 먼저 사용 중지하고 폐기를 예약하세요. 조직 정책을 사용해서 키 우선 사용 중지 및 최소 폐기 기간을 적용할 수 있습니다.

CI/CD 백업으로 Apigee 조직 보호

고객 관리 암호화 키(CMEK) 손상의 경우 손상된 키를 사용 중지, 권한 취소, 폐기하는 조치를 즉시 취하는 것이 중요합니다. 하지만 이러한 필수 보안 조치에 따라 Apigee 시스템이 작동하지 않고, 잠재적으로 다운타임 및 서비스 중단으로 이어질 수 있습니다.

Apigee 서비스 다운타임을 최소화하거나 없애기 위해서는 조직 구성에 대한 지속적인 백업(지속적 통합/지속적 배포(CI/CD) 백업)이라는 사전적인 방법을 구현해야 합니다. 사용 가능한 도구 및 Apigee 조직 복원 권장사항을 참조하세요.

CI/CD 및 IaC의 강력한 기능

코드형 인프라(IaC) 솔루션인 Terraform과 같은 도구에 대한 투자로 백업된 구성으로부터 새로운 Apigee 조직을 원활하게 만들 수 있습니다. 이러한 효율적인 프로세스를 통해 Apigee 조직을 빠르게 효율적으로 다시 만들어서 다운타임을 최소화하고 비즈니스 연속성을 보장할 수 있습니다.

사용 가능한 도구

다음 도구를 모두 조합하여 apigee 조직을 주기적으로 백업하고 복구 프로세스를 테스트할 수 있습니다.

• Apigee 인스턴스만 다시 만들려면 다운타임 없이 Apigee 인스턴스 다시 만들기를 참조하세요.
• Terraform을 사용하려면 오픈소스 apigee/terraform modules의 아이디어를 차용할 수 있습니다.
• Apigee 조직을 다시 만들려면 백업 기초로 apigeecli, apigeecli organizations export, apigeecli organizations import를 사용할 수 있습니다. 조직 내보내기/다시 만들기를 참조하세요.
• 위 목록 이외의 리소스를 추가로 백업 및 복원하려면 API를 직접 사용하거나 다른 apigeecli 명령어를 사용해야 합니다.

권장사항

• 정기 백업: 최신 구성을 사용할 수 있도록 정기적으로 백업을 예약하세요. 조직 내보내기/다시 만들기를 참조하세요.
• 보안 스토리지: 암호화된 저장소와 같은 안전한 위치에 백업을 저장하세요.
• 복원 테스트: Apigee 조직을 효과적으로 복구할 수 있도록 복원 프로세스를 정기적으로 테스트하세요. 새로 생성된 Apigee 조직으로 트래픽을 쉽게 전환할 수 있도록 복원 프로세스를 정기적으로 테스트하세요.

조직 내보내기/다시 만들기

apigeecli 도구는 Apigee 리소스를 관리할 수 있는 명령줄 도구입니다. 이를 사용하면 gcloud 명령어와 비슷하게, Apigee API와 동일한 작업을 사용이 간편한 명령줄 인터페이스로 수행할 수 있습니다.
Apigee 조직을 다시 만들거나 다른 Apigee 조직으로 마이그레이션하려면 apigeecli organizations export 및 apigeecli organizations import를 사용하면 됩니다. 또한 진행 중인 백업의 기초로 사용될 수도 있습니다. 다음과 같이 리소스를 내보내고 가져올 수 있습니다.

• API 포털 문서
• API 포털 카테고리
• API 프록시
• API 보안 구성 및 보안 프로필
• 공유 흐름
• API 제품
• 개발자
• 사용자 인증 정보를 포함하는 개발자 앱
• 사용자 인증 정보를 포함하는 AppGroup 및 앱
• 환경 세부정보
• 환경 그룹
• 데이터 수집기 구성
• 환경 수준 키 저장소 및 별칭 인증서
• 환경 수준 대상 서버
• 환경 수준 참조
• 조직, 환경, 프록시 수준의 키-값 맵(KVM) 및 항목
• 비공개 키를 제외한 키 저장소 및 별칭 인증서

이 도구는 다른 모든 Apigee 리소스를 관리할 수 있습니다. 전체 명령어 목록은 apigeecli tree를 사용하여 확인할 수 있습니다.

이 도구에는 몇 가지 제한사항이 있습니다.

• 키 저장소를 만들 때 비공개 키를 저장하고 이를 로컬 백업 파일에 포함해야 합니다.
• OAuth 토큰은 백업 및 복원이 불가능합니다. 즉, 새로 생성된 Apigee 인스턴스의 경우 고객이 다시 로그인해야 합니다.
• 조직 정책 및 IAM 규칙과 같은 액세스 제어는 마이그레이션되지 않습니다. 이러한 규칙을 마이그레이션하려면 Google Cloud API를 사용해야 합니다.
• 애널리틱스 보고서 내보내기는 지원되지 않으며 분석 측정항목이 새 apigee 조직으로 복사되지 않습니다.
• 이 import 명령어는 인스턴스, 환경 그룹, 환경 첨부 파일, 엔드포인트 첨부 파일을 자동으로 만들거나 프록시를 배포하지 않습니다. 이러한 리소스는 관리할 수 있지만 import 명령어를 사용하여 직접 관리할 수 없습니다.
• 이 import 명령어는 포털 사이트를 자동으로 만들지 않습니다. 포털 사이트 만들기는 UI를 통해 수동으로 수행해야 합니다.
• 키 삭제를 위한 재해 복원에 투자하고 새로 생성된 Apigee 조직으로 빠르게 트래픽을 전환할 수 있도록 복원 프로세스를 주기적으로 테스트하는 것이 좋습니다.

기본 요건

시작하기 전에 다음 기본 요건을 충족하는지 확인하세요.

• Apigee CLI 설치됨: 설치 가이드의 단계에 따라 apigeecli를 설치합니다.
• 인증: Apigee 조직과 상호작용하는 데 필요한 권한 및 인증 사용자 인증 정보가 있어야 합니다. 다음이 설정되었는지 확인하세요.
  • Google Cloud SDK(gcloud): 설치되고 인증되었는지 확인합니다.
  • 액세스 토큰: gcloud auth print-access-token을 사용하여 액세스 토큰을 가져옵니다.
• 네트워크 액세스: 네트워크에서 Apigee API에 대한 액세스가 허용되는지 확인합니다.
• 조직 만들기: 이전할 새 apigee 조직을 만듭니다. 다양한 유형의 apigee 조직을 만들 수 있습니다. 하지만 동일한 유형의 조직(사용한 만큼만 지불 또는 구독) 및 원래 조직에 사용한 것과 동일한 유형의 네트워크 라우팅을 사용해야 합니다.

Apigee 조직 내보내기

다음은 샘플 명령어를 보여줍니다. 다양한 플래그에 대한 자세한 내용은 apigeecli 조직 내보내기를 참조하세요.

# Sample command
mkdir apigee_backup
cd apigee_backup

# gcloud auth application-default login
export ORG_FROM=REPLACE
apigeecli organizations export -o $ORG_FROM --default-token

Apigee 조직 가져오기

다음은 샘플 명령어를 보여줍니다. 다양한 플래그에 관한 자세한 내용은 apigeecli 조직 가져오기를 참조하세요.

# Sample command
# gcloud auth application-default login
export ORG_TO=REPLACE
apigeecli organizations import -o $ORG_TO -f . --default-token

가져오기 이후 단계

인스턴스 만들기 및 네트워크 설정

다음을 수행하여 인스턴스를 만들고 네트워크를 설정합니다.

1. 새 인스턴스 만들기의 단계에 따라 새 인스턴스를 만듭니다.
2. Northbound 트래픽 구성: Northbound는 부하 분산기를 통해 외부 또는 내부 클라이언트에서 Apigee로의 API 트래픽을 나타냅니다. 인스턴스에 연결할 수 있도록 PSC 또는 VPC를 올바르게 구성해야 합니다. 새 조직에서 환경 그룹 호스트 이름을 설정해야 합니다.
3. Southbound 트래픽 구성: Southbound는 Apigee에서 API 프록시 대상 서비스로의 API 트래픽을 나타냅니다. 따라서 NAT에 대해 새 IP 주소를 예약 및 활성화하고 대상 엔드포인트에서 방화벽/허용 목록을 다시 구성해야 합니다.

자세한 내용은 Apigee 네트워킹 옵션을 참조하세요.

기타 구성 백업/복원

다음 중 하나를 사용하여 다른 구성을 백업/복원합니다.

• IAM 규칙: gcloud projects get-iam-policy 및 gcloud projects set-iam-policy를 사용하여 자체 IAM 정책을 복사하고, 프로젝트 및 apigee 조직 이름을 조정하고, 새 Google Cloud 프로젝트 및 apigee 조직에 적용할 수 있습니다.
• 기타 Apigee 구성: Apigee 관리 API를 사용할 수 있습니다.

프록시 배포

다음 중 하나를 사용하여 프록시를 배포합니다.

• apigeecli 사용
• Apigee 커뮤니티 스크립트를 참조로 사용
• Apigee 관리 API 사용

트래픽 전환

트래픽을 전환하려면 다음 안내를 따르세요.

1. 새 인스턴스에 대한 자동 통합 테스트를 준비합니다.
2. 성능을 모니터링하면서 새 인스턴스로 점차적으로 트래픽을 전환하도록 부하 분산기를 구성합니다.