이 문서에서는 컨텍스트 인식 액세스를 사용하여 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와 관련이 없습니다.
비즈니스 라인 앱은 인증 및 승인 방식을 기준으로 다음과 같이 추가로 구분할 수 있습니다.
- SAML: Google Workspace SAML을 사용하여 인증하는 앱입니다. SaaS 앱들이 이 카테고리에 속하는 경우가 많습니다.
- IAP: IAP 뒤에 배포한 커스텀 웹 앱입니다.
- OAuth: OAuth 2.0을 사용하고 하나 이상의 Google Cloud OAuth 범위를 사용하는 커스텀 웹 또는 데스크톱 앱입니다.
다음 흐름도는 각 앱 유형에 가장 적합한 컨텍스트 인식 액세스 방식을 보여줍니다.
이 다이어그램은 다음과 같은 앱 유형을 보여줍니다.
관리 앱: 일반적으로 관리 앱 자체를 보호하는 것보다, 관리 앱이 액세스를 가능하게 하는Google 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 액세스에는 인그레스 규칙이 적용되지 않습니다.
이러한 위험을 완화하려면 VM에 대한 SSH 및 RDP 액세스는 반드시 IAP TCP 전달을 통해서만 허용해야 합니다.
iaptunnel.googleapis.com서비스를 제한된 서비스로 포함합니다.- 방화벽 규칙을 구성하여 SSH 및 RDP 포트에 대한 액세스를 IAP TCP 전달을 통해서만 허용하도록 합니다.
IAP TCP 전달을 사용하면 VPC 서비스 경계의 인그레스 규칙 구성이 모든 SSH 및 RDP 액세스 시도에 일관되게 적용되도록 보장할 수 있습니다.
민감한 서비스 경계를 위해 인증서 기반 액세스 사용
기본적으로 Google 액세스 토큰과 갱신 토큰은 특정 기기에 묶여 있지 않으며, 도난이나 재사용 공격에 취약할 수 있습니다. 이러한 위험을 완화하기 위해 인증서 기반 액세스 (CBA)를 사용할 수 있습니다. CBA는 신뢰할 수 있는 X.509 인증서를 보유한 기기로만 액세스를 제한합니다.
CBA는 보안을 강화할 수 있지만, 다음과 같은 추가 인프라 요구사항이 발생합니다.
- 사용자의 기기에는 내부 인증 기관이 발급한 X.509 인증서가 있어야 합니다.
- 인증서와 연결된 키는 무단 내보내기를 방지할 수 있는 방식으로 저장되어야 합니다.
- 클라이언트 앱은Google Cloud API에 연결할 때 상호 TLS(mTLS) 인증을 사용해야 합니다.
CBA는 가장 민감한 VPC 서비스 경계에 대한 액세스를 보호하는 데 사용합니다. 이 접근 방식은 보안 강도, 인프라 요구사항, 전체적 영향도 간의 균형을 맞출 수 있습니다.
참여자
작성자: 요하네스 파싱 | 클라우드 솔루션 설계자
기타 참여자: 이도 플라토브 | 클라우드 솔루션 설계자