이 문서에서는 컨텍스트 인식 액세스를 사용하여 Google Cloud 리소스를 효과적으로 보호하기 위한 권장사항을 설명합니다. 컨텍스트 인식 액세스는 인증 강도, 기기 상태, 네트워크 위치, 지리적 위치 또는 기타 속성을 기반으로 사용자의 액세스를 제어하는 보안 접근 방식입니다. 이 접근 방식은 보안 액세스를 위해 기본 사용자 ID를 사용하는 것 이상이며, 제로 트러스트 보안 모델을 구현하여 전반적인 보안 상황을 개선하는 데 도움이 될 수 있습니다. 다양한 유형의 앱과 리소스에 컨텍스트 인식 액세스를 구현하는 방법에 관한 자세한 내용은 컨텍스트 인식 액세스를 사용하여 앱과 리소스 보호하기를 참고하세요.
앱과 Google Cloud 리소스를 보호하기 위해 다양한 컨텍스트 요소를 조합하여 세부적인 액세스 제어를 정의할 수 있습니다. Access Context Manager를 사용하여 액세스 수준과 서비스 매개변수가 포함된 액세스 정책을 정의할 수 있습니다.
이 문서는 Identity and Access Management (IAM)와 Google Cloud 리소스 및 앱의 보안을 담당하는 모든 보안 전문가를 대상으로 합니다. 이 문서에서는 사용자가 Access Context Manager,Google Cloud, IAM 관리에 이미 익숙하다고 가정합니다.
컨텍스트 인식 액세스 접근 방식
조직에서 컨텍스트 인식 액세스를 설정할 때 앱, 리소스 또는 둘 다에 컨텍스트 인식 액세스 제어를 적용할지 결정해야 합니다. 이 결정을 내리려면 다음과 같은 다양한 유형의 앱과 서비스를 구분하는 것이 좋습니다.
- 관리 앱: 이러한 앱을 사용하면 사용자가 VM 인스턴스, BigQuery 데이터 세트, Cloud Storage 버킷과 같은Google Cloud 리소스를 관리하거나 상호작용할 수 있습니다. 관리 앱의 예로는 Google Cloud 콘솔, Google Cloud CLI, Terraform, IAP Desktop이 있습니다.
- 비즈니스 앱: 이러한 앱에는Google Cloud 에서 실행되고 SAML 또는 IAP (Identity-Aware Proxy)를 사용하여 인증 및 승인을 받는 웹 앱이 포함됩니다. 이러한 앱을 내부 앱이라고도 합니다. 비즈니스 앱의 예로는 CRM 시스템, 대시보드, 기타 맞춤 앱이 있습니다.
- Google Workspace 및 기타 Google 서비스: 이러한 서비스는 Google에서 제공하지만 Google Cloud와는 관련이 없습니다.
인증 및 승인 처리 방식에 따라 LOB 앱을 추가로 구분할 수 있습니다.
- SAML: 인증에 Google Workspace SAML을 사용하는 앱입니다. SaaS 앱은 이 카테고리에 속하는 경우가 많습니다.
- IAP: IAP 뒤에 배포한 맞춤 웹 앱입니다.
- OAuth: OAuth 2.0을 사용하고 하나 이상의 Google Cloud OAuth 범위를 사용하는 맞춤 웹 또는 데스크톱 앱입니다.
다음 흐름 다이어그램은 각 앱 유형에 가장 적합한 상황 인식 액세스 방식을 보여줍니다.
다이어그램에는 다음 유형의 앱이 표시됩니다.
관리 앱: 일반적으로 관리 앱 자체보다는 관리 앱이 액세스를 지원하는Google Cloud 리소스를 보호하는 것이 더 중요합니다. 다음과 같은 시나리오를 가정합니다.
- 사용자가 리소스에 액세스할 수 없습니다. 이 시나리오에서는 관리 앱에 액세스하는 것이 사용자에게 그다지 가치가 없을 수 있습니다.
- 사용자가 리소스에 액세스할 수 있지만 관리 앱에는 액세스할 수 없습니다. 이 시나리오에서는 차단되지 않고 리소스에 액세스할 수 있는 다른 관리 앱을 찾을 수 있습니다.
따라서 관리 앱의 경우 리소스 중심 접근 방식을 취하세요. 리소스에 적절한 컨텍스트 인식 액세스 제어를 적용하는 가장 효과적인 방법은 적절한 인그레스 규칙과 함께 Virtual Private Cloud (VPC) 서비스 경계를 사용하는 것입니다. 액세스 바인딩으로 VPC 서비스 경계를 보완할 수 있습니다.
OAuth를 사용하는 기간 업무 앱: 이러한 앱의 경우 앱 자체에 대한 액세스와 앱에서 사용할 수 있는 리소스를 보호하는 것이 중요합니다. 컨텍스트 인식 액세스를 사용하여 앱을 보호하려면 액세스 바인딩을 사용하세요.
IAP를 사용하는 비즈니스 앱: IAP는 OAuth를 사용하지만 액세스 바인딩을 사용하여 IAP를 사용하여 사용자를 인증하는 앱을 보호할 수는 없습니다. 대신 IAM 조건을 사용하여 이러한 앱을 보호하세요.
SAML을 사용하는 비즈니스 라인 앱: OAuth를 사용하는 비즈니스 라인 앱과 마찬가지로 앱 자체에 대한 액세스와 앱에서 사용할 수 있는 리소스를 보호하는 것이 중요합니다. 이러한 앱을 보호하려면 Google Workspace 컨텍스트 인식 액세스를 사용하세요.
Google Workspace 및 기타 Google 서비스: 이러한 앱의 경우 앱 자체에 대한 액세스뿐만 아니라 앱에서 사용할 수 있는 리소스도 보호하는 것이 중요합니다. 이러한 앱을 보호하려면 Google Workspace 컨텍스트 인식 액세스를 사용하세요.
액세스 수준 관리
다음 섹션에서는 액세스 수준을 관리할 때 사용할 권장사항을 설명합니다.
재사용 가능한 액세스 수준 만들기
액세스 수준은 전역 리소스이며 Google Cloud 조직의 리소스 전반에서 사용하도록 설계되었습니다. 따라서 전체 액세스 수준 수를 제한하고 여러 리소스에 적용할 수 있는 의미 있는 액세스 수준을 만드는 것이 좋습니다. 다음 사항을 고려하세요.
- 액세스 수준의 이름에 특정 리소스 또는 앱의 이름을 삽입하지 마세요.
- 액세스 수준에 리소스별 또는 앱별 요구사항을 인코딩하지 마세요.
Fully Trusted Device와 같이 특정 사용자 또는 기기 자세를 주장하는 이름을 사용합니다.
복합 액세스 수준 사용
유지관리 오버헤드를 줄이고 서브네트워크 또는 리전이 변경될 때 일관성을 유지하려면 여러 액세스 수준에서 동일한 요구사항을 반복하지 마세요. 대신 액세스 수준이 서로 종속되도록 합니다.
예를 들어 여러 액세스 수준에 동일한 신뢰할 수 있는 리전 또는 IP 서브네트워크를 나열하지 말고 Trusted location라는 액세스 수준을 추가로 만드세요. 이 Trusted location 수준은 다른 액세스 수준의 종속 항목으로 사용할 수 있습니다.
액세스 수준에서 긴급 액세스 사용자 제외
실수로 잠기는 것을 방지하려면 하나 이상의 긴급 액세스 사용자를 모든 액세스 수준에서 제외하는 것이 좋습니다. 액세스 수준을 적용하는 모든 앱과 리소스에 예외가 적용되도록 하려면 액세스 수준 자체에서 예외를 구성하세요.
- 일반 요구사항을 정의하는 조건을 하나 추가합니다.
- 하나 이상의 긴급 액세스 사용자를 나열하는
members요구사항이 있는 조건을 하나 더 추가합니다. - 사용자가 두 조건 중 하나만 충족하면 되도록 결합 함수를
OR조건으로 설정합니다.
예를 들어 다음 액세스 수준은 세 지역에 대한 액세스를 제한하지만 사용자 emergencyaccess@example.net는 이 요구사항에서 제외됩니다.
{
"name": "accessPolicies/…",
"title": "Example access level",
"basic": {
"conditions": [
{
"members": [
"user:emergencyaccess@example.net"
]
},
{
"regions": [
"DE",
"AU",
"SG"
]
}
],
"combiningFunction": "OR"
}
}
해결 메시지 구성
조직의 사용자는 위치, 기기 및 기타 요인이 특정 앱에 대한 액세스 허용 여부에 영향을 미칠 수 있다는 사실을 알지 못할 수 있습니다. 사용자에게 정보를 제공하고 지원 요청을 줄이려면 사용자가 액세스 권한을 다시 얻기 위해 취해야 하는 단계를 안내하는 맞춤 해결 메시지를 구성하세요.
액세스 바인딩 관리
액세스 바인딩을 사용하면 하나 이상의 Google Cloud 범위를 사용하는 OAuth 앱에 컨텍스트 인식 액세스를 구성할 수 있습니다. 액세스 바인딩은 비즈니스 앱에 대한 컨텍스트 인식 액세스를 시행하는 효과적인 방법이기도 합니다.
다음 섹션에서는 액세스 바인딩을 사용할 때 권장되는 방법을 설명합니다.
범위가 지정된 설정으로 단일 액세스 바인딩 사용
액세스 바인딩을 사용할 때는 다음 제약 조건을 고려해야 합니다.
- 각 Cloud ID 그룹에는 액세스 바인딩이 최대 하나만 있을 수 있습니다.
- 사용자에게 두 개 이상의 액세스 바인딩이 적용되는 경우 제한이 적은 액세스 바인딩이 우선 적용됩니다.
이 두 가지 제약 조건을 수용하려면 모든 사용자에게 적용되는 단일 액세스 바인딩을 사용하세요.
- Cloud ID 또는 Google Workspace 계정의 모든 사용자가 자동으로 포함되는 그룹을 만듭니다.
- 기본 액세스 수준을 그룹과 연결하는 액세스 바인딩을 만들거나 사용합니다. 기본 액세스 수준은 대부분의 사용자, 기기, 앱에 적합해야 합니다.
- 필요한 경우 범위가 지정된 액세스 설정 (
scopedAccessSettings)을 사용하여 선택한 앱에 더 약한 액세스 수준을 할당합니다.
엄격한 기본 액세스 수준 사용
액세스 바인딩이 범위가 지정된 액세스 설정과 기본 액세스 수준을 모두 지정하는 경우 두 액세스 수준은 OR 시맨틱을 사용하여 결합됩니다.
이 동작은 다음과 같은 의미를 갖습니다.
- 사용자는 OAuth 앱에 액세스하기 위해 액세스 수준 중 하나만 충족하면 됩니다.
- OAuth 앱에 범위가 지정된 액세스 설정을 추가하면 유효한 액세스 요구사항을 낮출 수 있습니다.
- 범위가 지정된 액세스 설정이 액세스 바인딩의 기본 액세스 수준보다 더 엄격한 액세스 수준을 사용하는 경우 아무런 영향을 미치지 않습니다.
액세스 바인딩의 기본 액세스 수준을 선택할 때는 다음을 수행하는 것이 좋습니다.
- 엄격한 액세스 수준을 기본 액세스 수준으로 사용합니다.
- 범위가 지정된 액세스 설정을 사용하여 개별 OAuth 앱에 더 낮은 액세스 수준을 적용합니다.
기본 액세스 수준에 다음 제한사항 중 일부 또는 전부를 추가하는 것을 고려하세요.
- 브라우저 및 기기 제한: 사용자가 관리 Chrome 브라우저와 관리자가 승인한 기기를 사용하여 앱에 액세스하도록 요구합니다.
- 지리적 제한: 조직이 특정 지역에서만 운영되는 경우 지역 제한을 사용하여 해당 지역만 허용 목록에 포함합니다. 그렇지 않은 경우 지역 제한을 사용하여 제재가 가해진 지역이나 다른 이유로 관련성이 없는 지역에 대한 액세스를 제한할 수 있습니다.
- IP 네트워크 제한: 조직의 사용자가 특정 네트워크에서만Google Cloud 에 액세스하거나 조직에서 공통 이그레스 프록시를 사용하는 경우 IP 네트워크 제한을 포함할 수 있습니다.
인증서 기반 인증이 필요한 액세스 수준을 기본 액세스 수준으로 사용하지 마세요. 인증서 기반 인증은 VPC 서비스 경계 인그레스 규칙에 가장 적합합니다.
앱별 예외 관리
기본 액세스 수준의 예외를 관리하려면 사용자 또는 그룹의 예외가 아닌 개별 앱의 예외를 추가하세요.
엄격한 기본 액세스 수준은 대부분의 앱에 적합하지만 일부 앱에는 적합하지 않을 수 있습니다.
- 일부 앱은 민감도가 낮아 기본 액세스 수준을 충족하지 않는 사용자도 액세스할 수 있도록 해야 합니다. 파트너, 게스트 또는 졸업생이 액세스할 수 있어야 하는 앱이 그 예입니다.
- 일부 앱은 기본 액세스 수준에서 적용되는 제한사항과 기술적으로 호환되지 않을 수 있습니다.
개별 앱을 기본 액세스 수준에서 제외하려면 범위가 지정된 액세스 설정을 사용하세요. 영향을 받는 각 앱에 대해 범위가 지정된 설정을 추가하고 개별 앱에 더 적합한 액세스 수준을 할당합니다.
사용자 또는 그룹별 예외를 관리하기 위해 추가 액세스 바인딩을 만들지 마세요. 액세스 바인딩을 추가하면 다음과 같은 문제가 발생할 수 있습니다.
- 중복 액세스 바인딩이 실수로 생성될 수 있습니다.
- 개별 앱에 대해 어떤 컨텍스트 인식 액세스 요구사항이 효과적으로 적용되고 있는지 확인하기 어려워질 수 있습니다.
액세스 바인딩이 중복되지 않도록 방지
액세스 바인딩은 그룹과 연결됩니다. 사용자가 여러 그룹의 구성원인 경우 여러 액세스 바인딩이 적용될 수 있습니다. 이 경우 이러한 액세스 바인딩의 컨텍스트 인식 액세스 요구사항은 OR 시맨틱을 사용하여 결합됩니다.
이 동작으로 인해 의도하지 않은 결과가 발생할 수 있습니다. 예를 들어 사용자가 추가 그룹에 가입할 수 있는 경우 특정 앱의 보호가 약화될 수 있습니다.
이러한 상황을 방지하려면 액세스 바인딩이 중복되지 않도록 하는 것이 좋습니다.
- 액세스 바인딩 수를 최소화합니다(하나가 가장 좋음).
- 액세스 바인딩이 여러 개 필요한 경우 상호 배타적인 그룹에 할당하세요.
무단 수정으로부터 그룹 보호
기본적으로 Cloud ID에서는 그룹 구성원이 그룹을 탈퇴할 수 있습니다. 이 동작은 액세스 그룹에 적합하지만 연결된 액세스 바인딩이 있는 그룹에는 문제가 됩니다. 사용자가 연결된 액세스 바인딩이 있는 그룹을 나가면 액세스 바인딩으로 부과되는 컨텍스트 인식 액세스 요구사항이 더 이상 적용되지 않습니다. 따라서 사용자는 그룹을 나가 컨텍스트 인식 액세스 요구사항을 우회할 수 있습니다.
액세스 바인딩을 구성할 때는 항상 강제 적용 그룹을 사용하고 사용자가 강제 적용 그룹을 나가지 못하도록 합니다. 또는 Cloud ID 또는 Google Workspace 계정의 모든 사용자가 자동으로 포함되는 그룹을 만듭니다.
액세스 바인딩을 사용하는 경우 외부 사용자 액세스 허용 안함
액세스 바인딩은 Google Cloud 조직이 속한 Cloud ID 또는 Google Workspace 계정의 사용자에게만 영향을 미칩니다. 이러한 사용자는 다른 Google Cloud 조직의 리소스에 액세스하려고 하면 내 Google Cloud 조직의 액세스 바인딩이 적용됩니다. 사용자에 대한 액세스 바인딩의 이 적용은 Cloud ID를 사용하는 다른 컨텍스트의 동작과 다릅니다.
외부 Cloud ID 또는 Google Workspace 계정의 사용자가 Google Cloud 조직의 리소스에 액세스하도록 허용하는 경우 액세스 바인딩은 해당 사용자에게 영향을 미치지 않습니다.
액세스 바인딩이 효과적으로 적용되도록 하려면 Google Cloud 조직의 앱이나 리소스에 대한 액세스 권한을 외부 사용자에게 부여하지 마세요. 또한 Cloud ID 또는 Google Workspace 계정의 그룹에 외부 사용자를 추가하지 마세요.
세션 길이 제어를 위해 별도의 액세스 바인딩 사용
컨텍스트 인식 액세스 제어 외에도 액세스 바인딩을 사용하여 브라우저 세션 및 OAuth 토큰의 길이를 관리할 수 있습니다.
액세스 바인딩을 사용하여 컨텍스트 인식 액세스를 제어할 때는 액세스 바인딩이 중복되지 않도록 하는 것이 좋습니다.
액세스 바인딩을 사용하여 세션 길이를 제어할 때는 중복되는 액세스 바인딩을 만들지 마세요. 이러한 액세스 바인딩이 두 개 이상 사용자에게 적용되는 경우 마지막으로 업데이트된 액세스 바인딩만 적용되므로 의도하지 않은 결과가 발생할 수 있습니다.
이러한 의도하지 않은 결과를 방지하려면 별도의 액세스 바인딩을 사용하여 세션 길이를 제어하세요.
사용자가 서비스 계정으로 작업하도록 허용하지 않음
액세스 바인딩은 Cloud ID 및 Google Workspace 사용자에게 적용되지만 서비스 계정에는 영향을 미치지 않습니다. 사용자가 서비스 계정으로 인증하고 작업하도록 허용하면 사용자가 컨텍스트 인식 액세스 제어를 약화시킬 수 있습니다.
사용자가 서비스 계정으로 작업할 수 있는 경우 다른 위험이 발생합니다. 사용자가 일시적으로 권한을 상승하도록 허용하려면 Privileged Access Manager를 사용하는 것이 좋습니다. 개발 목적으로만 서비스 계정 가장을 사용하세요.
서비스 계정 및 서비스 계정 키를 보호하는 방법에 대한 자세한 내용은 서비스 계정 사용 권장사항 및 서비스 계정 키 관리 권장사항을 참고하세요.
VPC 서비스 경계의 인그레스 규칙
인그레스 규칙을 사용하면 서비스 경계 외부에서 경계 내부의 리소스에 대한 컨텍스트 인식 액세스를 부여할 수 있습니다. VPC 서비스 경계 및 인그레스 규칙은 개별 앱이 아닌 Google Cloud 리소스를 보호합니다. 따라서 인그레스 규칙이 있는 서비스 경계는 Google Cloud 콘솔 및 gcloud CLI와 같은 관리 도구에 컨텍스트 인식 액세스를 적용하는 데 적합합니다.
VPC 서비스 경계에 관한 자세한 내용과 권장사항은 VPC 서비스 제어 사용 설정 권장사항을 참고하세요.
다음 섹션에서는 인그레스 규칙을 사용하여 컨텍스트 인식 액세스를 적용할 때 권장되는 방법을 설명합니다.
IAP TCP 전달을 제한된 서비스로 포함
다음과 같은 이유로 사용자가 SSH 또는 RDP를 사용하여 서비스 경계의 VM 인스턴스에 연결하도록 허용하는 것은 위험할 수 있습니다.
- SSH 및 RDP 사용에는 Google API 액세스가 포함되지 않으므로 인그레스 규칙이 연결에 적용되지 않습니다.
- 사용자가 SSH 또는 RDP 세션을 설정한 후 해당 세션 내에서 시작된 모든 API 액세스는 서비스 경계 내에서 시작된 것으로 간주됩니다. 따라서 해당 세션 내에서 시작된 API 액세스에는 인그레스 규칙이 적용되지 않습니다.
이러한 위험을 완화하려면 IAP TCP 전달을 통해서만 VM에 대한 SSH 및 RDP 액세스를 허용하세요.
iaptunnel.googleapis.com서비스를 제한된 서비스로 포함합니다.- IAP TCP 전달을 통해 SSH 및 RDP 포트에 대한 액세스를 제한하는 방화벽 규칙을 구성합니다.
IAP TCP 전달을 사용하여 VPC 서비스 경계의 인그레스 규칙 구성이 모든 SSH 및 RDP 액세스 시도에 적용되도록 합니다.
민감한 서비스 경계에 인증서 기반 액세스 사용
기본적으로 Google 액세스 토큰과 갱신 토큰은 기기에 바인딩되지 않으며 도난이나 재전송 공격에 취약할 수 있습니다. 이러한 위험을 완화하기 위해 신뢰할 수 있는 X.509 인증서가 있는 기기로 액세스를 제한하는 인증서 기반 액세스 (CBA)를 사용할 수 있습니다.
CBA는 보안을 강화하는 데 도움이 되지만 이 접근 방식에는 다음과 같은 추가 인프라 요구사항도 있습니다.
- 사용자의 기기에는 내부 인증 기관에서 발급한 X.509 인증서가 있어야 합니다.
- 인증서와 연결된 키는 무단 내보내기를 방지하는 방식으로 저장해야 합니다.
- 클라이언트 앱은 상호 TLS (mTLS) 인증을 사용하여Google Cloud API에 연결해야 합니다.
CBA를 사용하여 가장 민감한 VPC 서비스 경계에 대한 액세스를 보호합니다. 이 접근 방식을 사용하면 최소한의 인프라 요구사항과 전반적인 영향으로 보안 강도를 균형 있게 유지할 수 있습니다.
참여자
작성자: 요하네스 패싱 | 클라우드 솔루션 설계자
기타 참여자: 아이도 플래토우 | 클라우드 솔루션 설계자