웹 애플리케이션에 인증서 기반 액세스 사용 설정

이 페이지에서는 웹 애플리케이션에 대해 인증서 기반 액세스(CBA)를 사용 설정하는 방법을 설명합니다. CBA를 사용하면 신뢰할 수 있는 기기로부터 Google Cloud에서 실행되는 엔터프라이즈 웹 애플리케이션까지 액세스를 보호할 수 있습니다.

개요

웹 애플리케이션을 위한 CBA는 BeyondCorp Enterprise 컨텍스트 인식 액세스 기능과 Google Cloud 네트워킹을 사용해서 상호 TLS(mTLS)를 통해 액세스를 보호합니다 다음은 웹 애플리케이션에서 CBA를 사용 설정하기 위해 사용되는 기본 구성요소에 대한 설명입니다.

• Access Context Manager: 웹 애플리케이션에 대해 액세스를 확인할 때 인증서가 필요한 액세스 수준을 만들 수 있습니다.
• IAP(Identity-Aware Proxy): 사용자의 웹 애플리케이션 액세스를 인증합니다.
• Google Cloud HTTPS 부하 분산기: 사용자와 웹 애플리케이션 간의 상호 인증(mTLS)을 제공합니다.
• Chrome Enterprise 정책: Chrome 브라우저를 사용할 때 사용자와 웹 애플리케이션 간에 상호 인증(mTLS)을 제공합니다.

시작하기 전에

다음 명령어를 실행해서 Google Cloud CLI의 현재 버전을 확인합니다.

gcloud components update

외부 HTTPS 부하 분산기의 mTLS 설정

안내에 따라 HTTPS 외부 부하 분산기를 설정합니다. 이후 단계에 필요하므로 생성된 대상 HTTPS 프록시 이름을 기록해 둡니다.

트러스트 구성 만들기

공개 키 인프라(PKI) 유형을 나타내는 트러스트 구성을 만듭니다.

이 태스크를 완료하려면 대상 Google Cloud 프로젝트에 대해 certificatemanager.trustconfigs.create 권한이 있어야 합니다.

트러스트 구성은 Google에서 발급한 인증서(방법 1)를 사용하거나 자체 인증서를 사용하거나(방법 2) 엔드포인트 확인으로 자체 서명된 인증서를 사용(방법 3)하여 만들 수 있습니다.

방법 1

Google에서 발급한 인증서를 사용하여 트러스트 구성을 만듭니다.

1. 루트 CA 만들기 단계를 완료합니다.

2. PEM 파일 콘텐츠를 가져옵니다.

   gcloud privateca roots describe ROOT_CA_ID \
       --pool=POOL_ID \
       --location=CA_LOCATION \
       --format='value(pemCaCertificates)'
   

   다음을 바꿉니다.

   • ROOT_CA_ID: 루트 인증서 ID입니다.
   • POOL_ID: 루트 인증서 풀 ID입니다.
   • CA_LOCATION: CA 위치입니다.

3. pemCaCertificates 필드에 반환된 루트 인증서를 검색합니다. 인증서는 BEGIN CERTIFICATE 및 END CERTIFICATE 마커 사이의 문자열이며 두 마커를 모두 포함합니다.

4. PEM 형식의 루트 인증서를 파일에 저장합니다.

5. 트러스트 구성을 만듭니다.

   1. 다음 환경 변수를 설정합니다.

      ROOT_PEM_FILE=TRUST_ANCHOR_PATH
      INT_PEM_FILE1=IM_CERT_PATH
      INT_PEM_FILE2=SECOND_IM_CERT_PATH
      

      다음을 바꿉니다.

      • TRUST_ANCHOR_PATH: PEM으로 인코딩된 신뢰 앵커의 경로입니다.
      • IM_CERT_PATH: PEM으로 인코딩된 중간 인증서의 경로입니다.
      • SECOND_IM_CERT_PATH: 두 번째 PEM으로 인코딩된 중간 인증서의 경로입니다.

   2. 트러스트 구성 YAML 파일의 콘텐츠를 준비합니다.

      ROOT=$(cat ROOT_PEM_FILE | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
      INT_1=$(cat INT_PEM_FILE1 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
      INT_2=$(cat INT_PEM_FILE2 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
      

   3. 트러스트 구성 YAML 파일을 만듭니다.

      cat << EOF > trust_config.yaml
      name: "${TRUST_CONFIG_NAME?}"
      trustStores:
      - trustAnchors:
        - pemCertificate: "${ROOT?}"
        intermediateCas:
        - pemCertificate: "${INT_1?}"
        - pemCertificate: "${INT_2?}"
       EOF
      

      이 YAML 파일은 TRUST_CONFIG_NAME이라는 트러스트 구성을 정의합니다. 트러스트 구성에는 루트 인증서와 2개의 중간 인증서가 포함된 하나의 트러스트 저장소가 있습니다.

   4. 트러스트 구성을 Google Cloud 인증서 관리자로 가져옵니다.

      gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \
        --project=GCP_PROJECT \
        --source=${PWD?}/trust_config.yaml
      

      다음을 바꿉니다.

      • TRUST_CONFIG_NAME: 트러스트 구성의 이름입니다.
      • GCP_PROJECT: Google Cloud 프로젝트 ID입니다.

중간 CA가 루트로 서명된 보다 복잡한 구조를 배포하는 경우 중간 CA를 intermediateCAs로 추가합니다.

방법 2

기존 인증서와 함께 자체 PKI 배포를 사용하여 트러스트 구성을 만듭니다.

이 유형의 트러스트 구성에서는 루트 인증서를 나타내는 단일 신뢰 앵커가 포함된 기본 트러스트 저장소를 가정합니다. 중간 인증서는 지정되지 않습니다.

트러스트 구성을 만듭니다.

1. 다음 환경 변수를 설정합니다.

   ROOT_PEM_FILE=TRUST_ANCHOR_PATH
   INT_PEM_FILE1=IM_CERT_PATH
   INT_PEM_FILE2=SECOND_IM_CERT_PATH
   

   다음을 바꿉니다.

   • TRUST_ANCHOR_PATH: PEM으로 인코딩된 신뢰 앵커의 경로입니다.
   • IM_CERT_PATH: PEM으로 인코딩된 중간 인증서의 경로입니다.
   • SECOND_IM_CERT_PATH: 두 번째 PEM으로 인코딩된 중간 인증서의 경로입니다.

2. 트러스트 구성 YAML 파일의 콘텐츠를 준비합니다.

   ROOT=$(cat ROOT_PEM_FILE | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
   INT_1=$(cat INT_PEM_FILE1 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
   INT_2=$(cat INT_PEM_FILE2 | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
   

3. 트러스트 구성 YAML 파일을 만듭니다.

   cat << EOF > trust_config.yaml
   name: "${TRUST_CONFIG_NAME?}"
   trustStores:
   - trustAnchors:
     - pemCertificate: "${ROOT?}"
     intermediateCas:
     - pemCertificate: "${INT_1?}"
     - pemCertificate: "${INT_2?}"
   EOF
   

   이 YAML 파일은 TRUST_CONFIG_NAME이라는 트러스트 구성을 정의합니다. 트러스트 구성에는 루트 인증서와 2개의 중간 인증서가 포함된 하나의 트러스트 저장소가 있습니다.

4. 트러스트 구성을 Google Cloud 인증서 관리자로 가져옵니다.

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \
     --project=GCP_PROJECT \
     --source=${PWD?}/trust_config.yaml
   

   다음을 바꿉니다.

   • TRUST_CONFIG_NAME: 트러스트 구성의 이름입니다.
   • GCP_PROJECT: Google Cloud 프로젝트 ID입니다.

방법 3

Chrome 브라우저를 사용 중이고 엔드포인트 확인으로 자체 서명 인증서를 사용하려면 이 섹션의 안내를 따르세요.

안내에 따라 조직의 엔드포인트 확인을 배포합니다. 엔드포인트 확인은 Google에서 발급된 자체 서명된 인증서를 기기에 자동으로 배포하며, 사용자가 트러스트 구성을 만들 필요가 없습니다.

외부 부하 분산기에서 mTLS를 사용 설정하도록 TLS 정책 만들기

방법 3을 사용한 경우 이 단계를 건너뛸 수 있습니다.

이 태스크를 수행하려면 다음 권한이 있어야 합니다.

• 이 ServerTlsPolicy에 대해 만든 트러스트 구성에 대한 certificatemanager.trustconfigs.use
• 대상 Google Cloud 프로젝트에 대한 networksecurity.serverTlsPolicies.create

1. 서버 TLS 정책 YAML 파일을 만듭니다.

   cat << EOF > server_tls_policy.yaml
   name: "SERVER_TLS_POLICY_NAME"
   mtlsPolicy:
     clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
     clientValidationTrustConfig: projects/GCP_PROJECT/locations/global/trustConfigs/TRUST_CONFIG_NAME
   EOF
   

   다음을 바꿉니다.

   • SERVER_TLS_POLICY_NAME: 서버 TLS 정책의 이름입니다.
   • GCP_PROJECT: Google Cloud 프로젝트 ID입니다.
   • TRUST_CONFIG_NAME: 이전 단계에서 만든 트러스트 구성입니다.

   clientValidationMode의 클라이언트 검증 옵션에 대한 자세한 내용은 MTLS 클라이언트 검증 모드를 참조하세요.

2. 서버 TLS 정책 YAML을 Google Cloud 프로젝트로 가져옵니다.

   gcloud network-security server-tls-policies import ${SERVER_TLS_POLICY_NAME?} \
     --project=GCP_PROJECT \
     --source=${PWD?}/server_tls_policy.yaml \
     --location=global
   

   GCP_PROJECT를 Google Cloud 프로젝트 ID로 바꿉니다.

TLS 정책을 만든 후에는 수정할 수 없습니다. 기존 TLS 정책을 변경하려면 기존 TLS 정책을 삭제하고 새로 만들어야 합니다.

대상 HTTPS 정책에 TLS 정책 연결

이 태스크를 완료하려면 대상 Google Cloud 프로젝트에 대해 compute.targetHttpsProxies.get 권한이 있어야 합니다.

1. 기존 대상 HTTPS 프록시를 로컬 파일로 내보냅니다.

   gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
       --project=GCP_PROJECT \
       --global \
       --destination=${PWD?}/xlb-mtls-target-proxy.yaml
   

   다음을 바꿉니다.

   • TARGET_HTTPS_PROXY_NAME: 대상 HTTPS 프록시입니다.
   • GCP_PROJECT: Google Cloud 프로젝트 ID입니다.

2. 대상 HTTPS 프록시 구성에 ServerTlsPolicy를 추가합니다.

   이 태스크를 수행하려면 다음 권한이 있어야 합니다.

   • 대상 HTTPS 프록시에 만든 ServerTlsPolicy에 대한 networksecurity.serverTlsPolicies.use
   • 대상 Google Cloud 프로젝트에 대한 compute.targetHttpsProxies.update

   echo "serverTlsPolicy:
   //networksecurity.googleapis.com/projects/GCP_PROJECT/locations/global/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> xlb-mtls-target-proxy.yaml
   

   다음을 바꿉니다.

   • GCP_PROJECT: Google Cloud 프로젝트 ID입니다.
   • SERVER_TLS_POLICY_NAME: 서버 TLS 정책입니다.

3. 로컬 파일에서 새 구성을 가져와서 대상 HTTPS 프록시를 업데이트합니다.

   gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
       --project=GCP_PROJECT \
       --global \
       --source=${PWD?}/xlb-mtls-target-proxy.yaml
   

   다음을 바꿉니다.

   • TARGET_HTTPS_PROXY_NAME: 대상 HTTPS 프록시입니다.
   • GCP_PROJECT: Google Cloud 프로젝트 ID입니다.

인증서가 필요한 액세스 수준 만들기

콘솔

1. 안내에 따라 커스텀 액세스 수준을 만듭니다.

2. 커스텀 액세스 수준에 다음 표현식을 추가합니다.

   트러스트 구성을 만든 경우(방법 1 또는 방법 2) 인증 시 PKI 증명 바인딩을 사용하도록 커스텀 액세스 수준의 조건 필드에 다음 표현식을 추가합니다.

   certIsPkiAttested(origin, ["TLS_POLICY_FULL_RESOURCE_PATH1", "TLS_POLICY_FULL_RESOURCE_PATH2", …]) == true
   

   여기서 TLS_POLICY_FULL_RESOURCE_PATH1 및 TLS_POLICY_FULL_RESOURCE_PATH2 는 여러 트러스트 구성을 나타내는 경로(certificatemanager.googleapis.com/projects/GCP_PROJECT/locations/global/trustConfigs/TRUST_CONFIG_NAME)입니다.

   트러스트 구성 경로를 1개 이상 제공해야 합니다.

   다음을 바꿉니다.

   • GCP_PROJECT: Google Cloud 프로젝트 ID입니다.
   • TRUST_CONFIG_NAME: 트러스트 구성의 이름입니다.

   Google에서 발급된 자체 서명된 인증서를 사용한 경우(방법 3) 인증 시 인증서 바인딩을 사용하도록 커스텀 액세스 수준의 조건 필드에 다음 표현식을 추가합니다.

   certificateBindingState(origin, device) == CertificateBindingState.CERT_MATCHES_EXISTING_DEVICE
   

gcloud

트러스트 구성을 만든 경우(방법 1 또는 방법 2) 다음 명령어를 실행해서 인증 시 PKI 증명 바인딩을 사용하는 커스텀 액세스 수준을 만듭니다.

gcloud access-context-manager levels create ACCESS_LEVEL_NAME \
    --title=TITLE \
    --custom-level-spec=FILE \
    --description=DESCRIPTION \
    --policy=POLICY_NAME

다음을 바꿉니다.

• ACCESS_LEVEL_NAME: 액세스 수준의 고유한 이름입니다.
• TITLE: 사람이 읽을 수 있는 제목입니다.

• FILE: 다음 표현식이 포함된 YAML 파일입니다.

  certIsPkiAttested(origin, ["TLS_POLICY_FULL_RESOURCE_PATH1", "TLS_POLICY_FULL_RESOURCE_PATH2", …]) == true

  여기서 TLS_POLICY_FULL_RESOURCE_PATH1 및 TLS_POLICY_FULL_RESOURCE_PATH2 는 여러 트러스트 구성을 나타내는 경로(certificatemanager.googleapis.com/projects/GCP_PROJECT/locations/global/trustConfigs/TRUST_CONFIG_NAME)입니다.

  트러스트 구성 경로를 1개 이상 제공해야 합니다.

  다음을 바꿉니다.

  • GCP_PROJECT: Google Cloud 프로젝트 ID입니다.
  • TRUST_CONFIG_NAME: 트러스트 구성의 이름입니다.

• DESCRIPTION: 긴 형식으로 된 액세스 수준의 설명입니다.

• POLICY_NAME: 조직의 액세스 정책입니다.

트러스트 구성이 없으면 엔드포인트 확인을 사용하여 자체 서명된 인증서를 사용(방법 3) 중이므로 커스텀 액세스 수준에 다음 표현식을 추가합니다.

certificateBindingState(origin, device) == CertificateBindingState.CERT_MATCHES_EXISTING_DEVICE

IAP(Identity-Aware Proxy)를 사용하는 인증서 기반 액세스 적용

웹 애플리케이션 아키텍처의 CBA에서 IAP는 신뢰할 수 없는 기기로부터 웹 애플리케이션을 보호하기 위해 주 구성원 기반 정책 적용을 제공합니다.

다음 단계에 따라 IAP를 사용 설정하고 CBA 정책을 구성합니다.

1. IAP가 설정되지 않았으면 안내에 따라 IAP를 설정합니다.
2. IAP로 이동해서 앞에서 만든 액세스 수준을 연결합니다.
   IAP로 이동
3. CBA로 보호하려는 리소스를 선택한 후 설정을 클릭합니다.
4. 액세스 수준 필드에 생성된 액세스 수준의 이름을 입력합니다.

Google Cloud CLI를 사용해서 IAP에서 CBA 정책을 구성하려면 Google Cloud CLI 문서를 참조하세요.

인증서 자동 선택을 위해 브라우저 구성

액세스를 확인할 때 브라우저가 인증서를 자동으로 선택하도록 하려면 해당 브라우저의 단계를 완료합니다.

Chrome

Chrome이 mTLS 핸드셰이크 중 올바른 인증서를 사용하도록 AutoSelectCertificateForURLs Chrome 정책을 구성합니다.

1. Chrome 브라우저가 Chrome 브라우저 클라우드 관리 또는 Windows 그룹 정책에 따라 관리되는지 확인합니다.

   • Windows, macOS, Linux: 관리되는 Chrome 프로필 설정 단계를 수행합니다.
   • Chrome: 엔터프라이즈에 기기를 등록합니다.

2. AutoSelectCertificateForUrls 정책을 추가합니다.

   1. 관리 콘솔에서 기기 > Chrome > 설정 > 사용자 및 브라우저 설정 > 클라이언트 인증서로 이동합니다.
   2. 조직을 선택합니다.
   3. 웹 애플리케이션 URL에 대한 AutoSelectCertificateForUrls 정책 및 루트 인증서 정보를 추가합니다.

자세한 내용은 정책 스키마 문서를 참조하세요. 다음은 엔드포인트 확인의 인증서를 사용하는 정책 구성 예시입니다.

{
  "pattern":"https://[*.].mysite.com",
  "Filter":{
    "ISSUER":{
      "CN":"Google Endpoint Verification"
    }
  }
}

Safari

ID 환경설정을 구성합니다.

1. 키체인 액세스 앱을 연 후 모든 항목을 선택합니다.
2. 구성할 인증서를 선택합니다.
3. 파일 > 새 ID 환경설정을 클릭합니다.
4. URL을 입력하고 추가를 클릭합니다.

그러면 키체인에 업데이트할 수 있는 새 ID 환경설정 항목이 생성됩니다.

Edge

Edge 문서의 안내에 따라 AutoSelectCertificateForUrls Edge 정책을 설정합니다.