이 페이지에서는 Google Cloud 글로벌 서비스인 IAP(Identity-Aware Proxy)의 기본 개념을 설명합니다.
IAP를 사용하면 HTTPS로 액세스한 애플리케이션에 대한 중앙 승인 레이어를 설정할 수 있으므로 네트워크 수준 방화벽을 사용하지 않고 애플리케이션 수준 액세스 제어 모델을 사용할 수 있습니다.
IAP 정책은 조직 전체에서 확장됩니다. 중앙에서 액세스 정책을 정의하고 이를 모든 애플리케이션 및 리소스에 적용할 수 있습니다. 정책 생성 및 적용을 위해 전용 팀을 할당할 경우, 모든 애플리케이션에서의 잘못된 정책 정의 또는 구현으로부터 프로젝트를 보호할 수 있습니다.
IAP 사용 시기
애플리케이션 및 리소스에 대한 액세스 제어 정책을 시행하려는 경우 IAP를 사용합니다. IAP는 서명된 헤더 또는 App Engine 표준 환경 Users API와 함께 작동하여 앱을 보호합니다.IAP를 사용하면 그룹 기반의 애플리케이션 액세스를 설정할 수 있습니다. 계약업체가 아닌 직원만 리소스에 액세스하거나 특정 부서만 액세스하도록 설정할 수 있습니다.
IAP 작동 방식
Cloud IAP로 애플리케이션 또는 리소스가 보호되는 경우, 올바른 Identity and Access Management(IAM) 역할이 있는 주 구성원, 일명 사용자가 이 프록시를 통해서만 액세스할 수 있습니다.
IAP를 통해 애플리케이션 또는 리소스에 대한 액세스 권한을 사용자에게 부여할 경우, VPN 없이 사용 중인 제품으로 구현된 미세 조정된 액세스 제어가 적용됩니다. 사용자가 IAP 보안 리소스에 액세스하려고 시도하면 IAP는 인증 및 승인 검사를 수행합니다.
App EngineCloud RunCompute EngineGKE온프레미스
인증
리소스에 대한 요청은 Google Cloud Cloud Run, App Engine, Cloud Load Balancing (외부 및 내부 HTTP(S) 부하 분산)을 통해 이루어집니다. 이러한 제품의 서비스 제공 인프라 코드는 앱 또는 백엔드 서비스에 대해 IAP가 사용 설정되었는지 확인합니다. IAP가 사용 설정된 경우 보호되는 리소스 정보가 IAP 인증 서버로 전송됩니다. 여기에는 Google Cloud 프로젝트 번호, 요청 URL, 요청 헤더 또는 쿠키의 모든 IAP 사용자 인증 정보와 같은 정보가 포함됩니다.
그런 후 IAP가 사용자의 브라우저 사용자 인증 정보를 확인합니다. 아무 것도 존재하지 않으면, 이후 로그인을 위해 브라우저 쿠키에 토큰을 저장하는 OAuth 2.0 Google 계정 로그인 과정으로 사용자가 리디렉션됩니다. 기존 사용자에 대해 Google 계정을 만들어야 할 경우, Google 클라우드 디렉토리 동기화를 사용하여 Active Directory 또는 LDAP 서버와 동기화할 수 있습니다.
요청 사용자 인증 정보가 유효하면, 인증 서버가 해당 사용자 인증 정보를 사용하여 사용자의 ID(이메일 주소 및 사용자 ID)를 가져옵니다. 그런 다음 인증 서버가 ID를 사용하여 사용자의 IAM 역할을 확인하고 사용자에게 리소스에 액세스할 권한이 있는지 확인합니다.
Compute Engine 또는 Google Kubernetes Engine을 사용하는 경우 VM(가상 머신)의 애플리케이션 제공 포트에 액세스할 수 있는 사용자가 IAP 인증을 우회할 수 있습니다. Compute Engine 및 GKE 방화벽 규칙은 IAP 보안 애플리케이션과 동일한 VM에서 실행되는 코드 액세스에 대한 보호를 제공할 수 없습니다. 방화벽 규칙은 다른 VM의 액세스에 대한 보호를 제공할 수 있지만, 올바르게 구성되어 있어야 합니다. 보안을 위한 개발자 책임을 알아보세요.
Cloud Run을 사용하는 경우 다음과 같은 방법으로 IAP를 사용 설정할 수 있습니다.
Cloud Run 서비스에서 직접 이렇게 하면 IAP가 자동 할당된 URL 및 구성된 모든 부하 분산기 URL을 포함하여 Cloud Run의 모든 인그레스 경로를 보호할 수 있습니다. 이 구성은 IAP를 사용 설정할 단일 Cloud Run 서비스가 있는 경우에 유용합니다.
Cloud Run 백엔드가 있는 부하 분산기를 통해 이 구성은 단일 글로벌 부하 분산기 뒤에 여러 리전에 Cloud Run 서비스가 있는 경우에 유용합니다. 이 구성에서는 자동 할당된 URL이 IAP로 보호되지 않으며 직접 액세스할 수 있습니다. 보안을 위한 개발자 책임에 대해 자세히 알아보세요.
Cloud Run 서비스가 부하 분산기 뒤에 있는 경우 부하 분산기와 Cloud Run 서비스 모두에서 IAP를 사용 설정하지 마세요.
승인
인증 후에는 IAP가 관련 IAM 정책을 적용하여 사용자가 요청된 리소스에 액세스하도록 승인되었는지 여부를 확인합니다. 리소스가 있는Google Cloud 콘솔 프로젝트에 대해 IAP 보안 웹 앱 사용자 역할이 사용자에게 있으면, 애플리케이션 액세스가 승인됩니다. IAP 보안 웹 앱 사용자 역할 목록을 관리하려면 콘솔의 IAP 패널 Google Cloud 을 사용하세요.
리소스에 대해 IAP를 사용하면 OAuth 2.0 클라이언트 ID 및 보안 비밀이 자동으로 생성됩니다. 자동으로 생성된 OAuth 2.0 사용자 인증 정보를 삭제하면 IAP가 올바르게 작동하지 않습니다. OAuth 2.0 사용자 인증 정보는 Google Cloud 콘솔 API 및 서비스에서 보고 관리할 수 있습니다.
컨텍스트 인식 액세스
승인 단계의 일부로 컨텍스트 인식 액세스를 사용하여 다음 유형의 리소스에 대한 안전한 액세스를 제공할 수 있습니다.
Google Cloud 콘솔 및 API
Google Cloud에 대한 인프라 액세스를 보호하는 첫 번째 방어선입니다.
사용자에 대한 고급 컨텍스트 인식 Google Cloud 액세스
가상 머신 (VM)
Google Cloud 및 기타 클라우드의 VM에 대한 관리 SSH/RDP 액세스를 사용 설정합니다.
강력한 컨텍스트 인식 제어를 구현하여 지정된 관리자만 액세스하도록 제한할 수 있습니다.
웹 애플리케이션
Google Cloud 및 기타 클라우드에 호스팅된 웹 애플리케이션에 대한 승인 및 인증을 제공합니다.
무단 액세스 및 데이터 손실을 방지하기 위해 지속적인 승인을 제공합니다.
개발자 책임
IAP는 Cloud Run, App Engine, Cloud Load Balancing (HTTPS) 및 내부 HTTP 부하 분산에 대한 모든 요청의 인증 및 승인을 보호합니다.
보안을 위해서는 다음과 같은 예방 조치를 취해야 합니다.
부하 분산기에서 IAP를 사용 설정하는 경우 백엔드 리소스에 직접 액세스할 수 있는지 확인합니다.
백엔드 리소스가 VM인 경우 부하 분산기를 통과하지 않는 트래픽으로부터 보호하도록 방화벽 규칙을 구성합니다.
IAP는 프로젝트 내의 다른 VM과 같이 프로젝트 내의 활동에 대한 보호를 제공하지 않습니다.
백엔드 리소스가 Cloud Run 서비스인 경우 run.app URL을 사용 중지하여 모든 인그레스가 부하 분산기를 통해 들어오도록 할 수 있습니다. run.app URL을 사용 설정 상태로 두려면 인그레스 제어를 사용하여 네트워크 외부의 트래픽을 차단해야 합니다.
서명된 헤더를 사용하도록 앱을 업데이트하거나 App Engine 표준 환경 사용자 API를 사용합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eIdentity-Aware Proxy (IAP) is a Google Cloud service that establishes a centralized authorization layer for HTTPS applications, enabling application-level access control instead of relying on network firewalls.\u003c/p\u003e\n"],["\u003cp\u003eIAP enforces access control policies for applications and resources by authenticating users and verifying their Identity and Access Management (IAM) roles before allowing access, utilizing signed headers or the App Engine Users API for securing applications.\u003c/p\u003e\n"],["\u003cp\u003eWhen enabled, IAP performs authentication and authorization checks on user requests, first by checking user credentials and then the user's IAM role, automatically creating OAuth 2.0 client credentials for this purpose.\u003c/p\u003e\n"],["\u003cp\u003eIAP allows for context-aware access, extending secure access to Google Cloud console, APIs, virtual machines, and web applications, providing enhanced control over resource access.\u003c/p\u003e\n"],["\u003cp\u003eWhile IAP manages external access, users must configure firewalls, load balancers, or Cloud Run ingress controls to prevent internal traffic within the project from bypassing IAP authentication, and to use signed headers or the App Engine Users API.\u003c/p\u003e\n"]]],[],null,["# Identity-Aware Proxy overview\n\nThis page describes the basic concepts of Identity-Aware Proxy\n(IAP), a Google Cloud global service.\n\nIAP lets you establish a central authorization\nlayer for applications accessed by HTTPS, so you can use an application-level\naccess control model instead of relying on network-level firewalls.\n\nIAP policies scale across your organization. You can define\naccess policies centrally and apply them to all of your applications and\nresources. When you assign a dedicated team to create and enforce policies, you\nprotect your project from incorrect policy definition or implementation in any\napplication.\n\nWhen to use IAP\n---------------\n\nUse IAP when you want to enforce access control policies\nfor applications and resources. IAP works with\n[signed headers](/iap/docs/signed-headers-howto) or the App Engine\nstandard environment [Users API](/appengine/docs/standard/services/users)\nto secure your app. With IAP, you can set up group-based\napplication access: a resource could be accessible for employees and\ninaccessible for contractors, or only accessible to a specific department.\n\nHow IAP works\n-------------\n\nWhen an application or resource is protected by IAP, it can\nonly be accessed through the proxy by\n[principals](/iam/docs/overview#concepts_related_identity), also known as users,\nwho have the correct\n[Identity and Access Management (IAM) role](/iam/docs/understanding-roles).\nWhen you grant a user access to an application or resource by\nIAP, they're subject to the fine-grained access controls\nimplemented by the product in use without requiring a VPN. When a user tries\nto access an IAP-secured resource, IAP\nperforms authentication and authorization checks.\nApp Engine Cloud Run Compute Engine GKE On-premises\n\n### Authentication\n\nRequests to your Google Cloud resources come through Cloud Run,\nApp Engine, and Cloud Load Balancing (External and Internal HTTP(S)\nLoad Balancing). The serving infrastructure code for these products checks if\nIAP is enabled for the app or backend service. If\nIAP is enabled, information about the protected resource is\nsent to the IAP authentication server. This includes\ninformation like the Google Cloud project number, the request URL, and any\nIAP credentials in the request headers or cookies.\n\nNext, IAP checks the user's browser credentials. If none\nexist, the user is redirected to an OAuth 2.0 Google Account sign-in flow that\nstores a token in a browser cookie for future sign-ins. If you need to create\nGoogle Accounts for your existing users, you can use\n[Google Cloud Directory Sync](https://support.google.com/a/answer/106368)\nto synchronize with your Active Directory or LDAP server.\n\nIf the request credentials are valid, the authentication server uses those\ncredentials to get the user's identity (email address and user ID). The\nauthentication server then uses the identity to check the user's\nIAM role and check if the user is authorized to access the\nresource.\n\nIf you're using Compute Engine or Google Kubernetes Engine,\nusers who can access the application-serving port of the Virtual Machine (VM)\ncan bypass IAP authentication. Compute Engine and GKE\nfirewall rules can't protect against access from code running on the same VM as\nthe IAP-secured application. Firewall rules can protect\nagainst access from another VM, but only if properly configured. Learn\nabout [your responsibilities](#your_responsibilities) to ensure security.\n\nIf you're using Cloud Run, you can [enable\nIAP](/run/docs/securing/identity-aware-proxy-cloud-run) in the\nfollowing ways:\n\n- Directly on your Cloud Run services. This enables IAP to protect all ingress paths to Cloud Run, including the [auto-assigned URL](/run/docs/triggering/https-request) and any configured load balancer URL. This configuration is useful when you have a single Cloud Run service to enable IAP for.\n- Through a load balancer with a Cloud Run backend. This configuration is useful when you have multiple Cloud Run services in different regions behind a single global load balancer. In this configuration, the auto-assigned URL is unprotected by IAP and might be directly accessible. Learn more about [your\n responsibilities](#your_responsibilities) to ensure security.\n\nIf a Cloud Run service is behind a load balancer, don't enable\nIAP on both the load balancer and the Cloud Run\nservice.\n\n### Authorization\n\nAfter authentication, IAP applies the relevant\nIAM policy to check if the user is authorized to access the\nrequested resource. If the user has the **IAP-secured Web App User** role on the\nGoogle Cloud console project where the resource exists, they're authorized to\naccess the application. To manage the **IAP-secured Web App User** role list,\nuse the\n[IAP panel on the Google Cloud console](https://console.cloud.google.com/security/iap/).\n\nWhen you turn on IAP for a resource, it automatically\ncreates an OAuth 2.0 client ID and secret. If you delete the automatically\ngenerated OAuth 2.0 credentials, IAP won't function\ncorrectly. You can view and manage OAuth 2.0 credentials in the\n[Google Cloud console APIs \\& services](https://console.cloud.google.com/apis/dashboard).\n\n#### Context-aware access\n\nAs part of the [authorization](#iap-auth) step, you can use context-aware access to provide\nsecure access to the following types of resources:\n\n##### Google Cloud console and APIs\n\n- First layer of defense in protecting infrastructure access to Google Cloud.\n- Advanced context-aware Google Cloud access to users.\n\n##### Virtual Machines (VMs)\n\n- Enables administrative SSH/RDP access to VMs in Google Cloud and in other clouds.\n- Lets you implement robust context-aware controls to restrict access to only designated administrators.\n\n##### Web applications\n\n- Provides authorization and authentication for web applications hosted in Google Cloud and other clouds.\n- Provides continuous authorization to prevent unauthorized access and data loss.\n\nYour responsibilities\n---------------------\n\nIAP secures authentication and authorization of all requests\nto Cloud Run, App Engine, Cloud Load Balancing (HTTPS),\nand internal HTTP load balancing.\n\nTo ensure security, you must take the following precautions:\n\n- If you're enabling IAP on a load balancer, verify whether the backend resources can be accessed directly.\n - If the backend resource is a VM, configure your firewall rules to protect against traffic that doesn't come through the load balancer. IAP doesn't protect against activity within a project, such as another VM inside the project.\n - If the backend resource is a Cloud Run service, you can disable the run.app URL to ensure that all ingress comes in through the load balancer. If you choose to leave the run.app URL enabled, you should use [ingress controls](/run/docs/securing/ingress) to block traffic from outside your network.\n- Update your app to use [signed headers](/iap/docs/signed-headers-howto) or use the App Engine standard environment [Users API](/appengine/docs/standard/services/users).\n\nWhat's next\n-----------\n\n- Get started with IAP by completing one of the following tasks:\n - Enable IAP [directly on your\n Cloud Run](/run/docs/securing/identity-aware-proxy-cloud-run) services or on a [load balancer with a\n Cloud Run backend](/iap/docs/enabling-cloud-run).\n - Complete the App Engine quickstart to [Manage Access with Google\n Accounts](/iap/docs/app-engine-quickstart).\n - Enable [IAP for Compute Engine](/iap/docs/enabling-compute-howto).\n - Enable [IAP for GKE](/iap/docs/enabling-kubernetes-howto).\n - Enable [IAP for on-premises apps](/iap/docs/enabling-on-prem-howto).\n- Learn more:\n - [Authenticating to Compute Engine](/compute/docs/authentication)\n - [App Engine user authentication options](/appengine/docs/python/oauth)\n - [Using OAuth 2.0 to access Google APIs](https://developers.google.com/identity/protocols/OAuth2)\n - [Google Cloud auth guide](/docs/authentication)\n - [Setting up a load balancer](/iap/docs/load-balancer-howto)\n - [Setting up a load balancer with Cloud Run (fully managed)](/load-balancing/docs/https/setting-up-https-serverless)\n - [Restricting ingress for Cloud Run](/run/docs/securing/ingress)"]]
