Cloud CDN 및 Cloud Load Balancing은 Compute Engine 인스턴스, Cloud Storage 버킷 또는 Google Cloud외부의 외부 원본에서 콘텐츠를 제공하는지 여부에 관계없이 웹 보안 권장사항을 충족합니다.
보안 헤더 설정
HTTP 사양에는 다음을 제어하는 여러 헤더가 있습니다.
클라이언트 동작
콘텐츠 삽입 방법
도메인 간 콘텐츠 제공 방법
해당 도메인 연결 시 항상 TLS(HTTPS)를 사용할지 여부
이러한 제어는 일반적으로 각 백엔드(CDN 용어로 원본)에 외부 애플리케이션 부하 분산기 및 Cloud CDN 배포의 커스텀 응답 헤더로 설정할 수 있는 HTTP 응답 헤더로 표시됩니다.
Cloud Storage를 사용하고 버킷에서 웹 콘텐츠를 제공하는 경우 스토리지 버킷 앞에 Cloud CDN을 사용하여 웹 보안 헤더를 설정하고 인기 콘텐츠를 캐시할 수 있습니다.
가장 유용한 웹 보안 헤더는 다음 표에 정의되어 있습니다.
헤더 이름
설명
사용 예
Strict-Transport-Security(HSTS)
이 헤더를 설정하기 전에 도메인에 유효한 SSL(TLS) 인증서가 있는지 확인하세요.
클라이언트가 HTTPS(SSL/TLS)를 통해 도메인에 직접 연결해야 해서 HTTP에서 HTTPS로 리디렉션할 필요가 없으므로 속도가 느려지고 중간자 공격이 발생할 위험이 있습니다.
이 헤더를 설정하면 되돌릴 수 없습니다. 이 헤더를 캐시한 후 최신 브라우저 클라이언트는 HTTPS가 아닌 연결을 시도하지 않으며, SSL이 작동 중단되더라도 사용자는 이 헤더를 수신한 도메인에 액세스할 수 없습니다. 이 동작은 공격자가 보안 프로토콜을 보호되지 않는 HTTP로 다운그레이드하는 것을 방지합니다(다운그레이드 공격이라고 함).
Strict-Transport-Security 헤더를 제공할 때는 includeSubdomains 또는 preload 지시문을 추가할 때 주의하세요. 이 지시문을 사용하려면 동일한 도메인의 내부 사이트를 포함한 모든 하위 도메인이 HTTPS를 사용해야 합니다.
예를 들어 example.com에서 제공되는 경우 support.example.com입니다.
클라이언트가 이후 모든 연결에 대해 HTTPS를 통해 직접 연결하도록 요구하고 최대 2년 동안 이 지시문을 캐싱합니다.
Strict-Transport-Security: max-age=3104000
X-Frame-Options
브라우저가 <frame>, <frame>, <embed> 또는 <object>에서 페이지를 렌더링할 수 있는지 여부를 나타냅니다. 이렇게 하면 콘텐츠를 다른 사이트에 삽입할 수 없도록 하여 클릭재킹 공격을 방지하는 데 도움이 됩니다.
사이트의 모든 iframe 거부: X-Frame-Options: DENY
사이트 자체 iFrame(삽입)하도록 허용: X-Frame-Options:
SAMEORIGIN
Content-Security-Policy
사이트의 콘텐츠 보안 정책(CSP)을 평가하려면 Google의 CSP 평가자 도구를 사용하면 됩니다.
기존 웹사이트에 새 보안 헤더를 도입할 때는 타사 스크립트, 삽입된 콘텐츠(예: iFrame) 또는 사이트의 다른 측면이 손상될 수 있으므로 주의해야 합니다. 프로덕션 트래픽을 변경하기 전에 백엔드 버킷 또는 백엔드 서비스의 두 번째 인스턴스를 만들고 테스트하는 것이 좋습니다.
TLS는 데이터가 전송 중에 수정되지 않았는지 확인하여 신뢰성을 제공합니다. TLS 인증서는 도청자가 사용자와 서버 간에 교환되는 내용을 확인할 수 없게 하여 기밀을 유지합니다.
이는 사용자 개인 정보 보호와 보안에 중요합니다.
SSL 인증서를 사용하면 HTTP/2 및 Google의 QUIC 프로토콜과 같은 최신 전송 프로토콜을 활용할 수 있습니다. 두 프로토콜 모두 SSL(TLS)이 필요합니다. 이러한 프로토콜은 웹 콘텐츠의 성능, 미디어 전달(예: 스트리밍 동영상) 및 혼잡한 네트워크의 안정성을 직접적으로 향상시킵니다.
Google Cloud 는 Cloud Load Balancing 및 Cloud CDN 서비스 전반에서 최신 TLS 프로토콜(예: TLS 1.3)을 지원합니다.
SSL 정책을 사용하여 최소 버전의 TLS를 높일 수 있습니다. 내장형 기기 또는 10년 이상 된 이전 비브라우저 클라이언트와 같은 이전 클라이언트를 지원할 필요가 없는 경우 버전을 TLS v1.2로 높이는 것이 좋습니다. 전역적으로 TLS v1.0 및 TLS v1.1은 Google Cloud간 0.5% 미만의 연결을 나타냅니다.
특정 클라이언트를 오래된 버전의 TLS로 식별하거나 연결해야 하는 경우 요청 헤더에 변수({tls_version})를 사용할 수 있습니다. 그런 다음 이 정보를 로깅할 수 있습니다.
[[["이해하기 쉬움","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-05(UTC)"],[[["\u003cp\u003eCloud CDN and Cloud Load Balancing can enhance web security when serving content from various sources, including Compute Engine, Cloud Storage, or external origins.\u003c/p\u003e\n"],["\u003cp\u003eSecurity headers, like \u003ccode\u003eStrict-Transport-Security\u003c/code\u003e, \u003ccode\u003eX-Frame-Options\u003c/code\u003e, and \u003ccode\u003eContent-Security-Policy\u003c/code\u003e, control client behavior, content embedding, cross-domain content, and TLS usage, and can be implemented using custom response headers.\u003c/p\u003e\n"],["\u003cp\u003eSetting the \u003ccode\u003eStrict-Transport-Security\u003c/code\u003e (HSTS) header forces clients to connect over HTTPS, which is irreversible, and care must be taken with the \u003ccode\u003eincludeSubdomains\u003c/code\u003e or \u003ccode\u003epreload\u003c/code\u003e directives.\u003c/p\u003e\n"],["\u003cp\u003eManaged TLS certificates are provided at no cost, are easily deployable to load balancers, automatically renew, and are globally distributed, offering data authenticity and confidentiality.\u003c/p\u003e\n"],["\u003cp\u003eUtilizing modern TLS protocols, such as TLS 1.3, and setting minimum TLS versions through SSL policies, enhances security and allows for improved performance with protocols like HTTP/2 and QUIC.\u003c/p\u003e\n"]]],[],null,["# Web security best practices\n\nBest practices for web security\n-------------------------------\n\nCloud CDN and Cloud Load Balancing can help you meet web\nsecurity best practices, whether you're serving content from\nCompute Engine instances, a Cloud Storage bucket, or an\nexternal origin located outside of Google Cloud.\n\n### Set security headers\n\nThe HTTP specification has a number of headers that control the following:\n\n- Client behavior\n- How content is embedded\n- How content is served across domains\n- Whether to always use TLS (HTTPS) when connecting to that domain\n\nThese controls are typically represented as HTTP response headers, which you can\nset for each backend (*origin* , in CDN terms) as [custom response\nheaders](/load-balancing/docs/custom-headers) for your\nexternal Application Load Balancer and Cloud CDN deployment.\n\nIf you are using Cloud Storage and serving web content from your\nbucket, you can use Cloud CDN [in front of your storage\nbucket](/cdn/docs/setting-up-cdn-with-bucket) to set web security headers and\ncache popular content.\n\nThe most useful web security headers are defined in the following table.\n\nUse caution when introducing new security headers to existing websites,\nbecause they can break third-party scripts, embedded content (for example, in\niframes), or other aspects of your sites. Before making changes to your\nproduction traffic, we recommend creating a second instance of your backend\nbucket or backend service and testing.\n\nYou can read more about web security headers and best practices on\n[web.dev](https://web.dev/secure/) as well on Mozilla's\n[infosec site](https://infosec.mozilla.org/guidelines/web_security).\n\n### TLS and certificate management\n\n[Managed certificates](/load-balancing/docs/ssl-certificates/google-managed-certs)\nhave the following characteristics:\n\n- Are provided at no cost\n- Can be easily deployed to your load balancers\n- Automatically renew\n- Are globally distributed to all of Google's edge locations\n\nTLS provides authenticity by validating that data has not been modified in\ntransit. TLS certificates provide confidentiality by making sure that an\neavesdropper cannot determine what is being exchanged between users and servers.\nThis is important for user privacy and security.\n\nWith SSL certificates, you can benefit from modern transport protocols, such as\n[HTTP/2](https://developers.google.com/web/fundamentals/performance/http2) and\nGoogle's [QUIC protocol](https://cloud.google.com/blog/products/gcp/introducing-quic-support-https-load-balancing), both of which require SSL (TLS). These\nprotocols directly improve the performance of web content, media delivery\n(such as streaming video), and reliability over congested networks.\n\nGoogle Cloud supports modern TLS protocols (such as TLS 1.3) across\nCloud Load Balancing and Cloud CDN services.\n\nYou can use [SSL policies](/load-balancing/docs/use-ssl-policies) to raise the\nminimum version of TLS. We recommend raising the version to TLS v1.2, if you\ndon't need to support older clients, such as embedded devices\nor older (more than 10 years old) non-browser clients. Globally, TLS v1.0 and\nTLS v1.1 represent less than 0.5% of connections across Google Cloud.\nIf you need to identify or associate specific clients with outdated versions of\nTLS, you can use the `{tls_version}` [variable in a request\nheader](/load-balancing/docs/user-defined-request-headers#variables). You can\nthen log this information.\n\nWhat's next\n-----------\n\n- To check whether Cloud CDN is serving responses from cache, see [Viewing logs](/cdn/docs/logging).\n- To learn about which content is cacheable or non-cacheable, see [Caching overview](/cdn/docs/caching).\n- To see Cloud CDN's points of presence, see [Cache locations](/cdn/docs/locations)."]]
