Google Chrome samesite 쿠키 정책

Google은 2020년 초에 출시될 예정인 Chrome 80부터 시작하는 사용자에게 기본적으로 새로운 쿠키 정책을 부과하기 시작합니다. 이 문서에서는 새로운 SameSite 쿠키 정책, Adobe Target이 이러한 정책을 지원하는 방법 및 Target을 사용하여 Google Chrome의 새로운 SameSite 쿠키 정책을 준수하는 방법에 대해 자세히 설명합니다.

Chrome 80부터 웹 개발자는 웹 사이트에서 사용할 수 있는 쿠키를 명시적으로 지정해야 합니다. 이것은 구글이 웹에서의 개인정보 보호와 보안을 개선하기 위해 계획하고 있는 많은 공지 중 첫 번째이다.

개인정보 및 보안과 관련하여 Facebook이 주목을 받고 있다는 사실을 고려하면, Apple과 현재 Google과 같은 다른 주요 플레이어는 개인정보 보호 및 보안 챔피언으로서 새로운 신분을 만들 수 있는 기회를 재빨리 이용해 왔다. 애플은 올해 초 ITP 2.1과 최근 ITP 2.2를 통해 쿠키 정책 변경 사항을 발표함으로써 이 팩을 선도했다. ITP 2.1에서는 애플은 완전히 타사 쿠키를 차단하며 브라우저에서 만든 쿠키를 7일간 보관한다. ITP 2.2에서는 쿠키가 하루만 보관됩니다. 구글의 이번 발표는 애플처럼 공격적이지는 않지만, 같은 최종 목표를 향한 첫 번째 단계이다. Apple의 정책에 대한 자세한 내용은 ITP(Apple Intelligent Tracking Prevention) 2.x을 참조하십시오.

쿠키란 무엇이며 어떻게 사용됩니까?

쿠키 정책에 대한 Google의 변경 사항을 살펴보기 전에 쿠키가 무엇이고 어떻게 사용되는지 살펴보겠습니다. 간단히 말해 쿠키는 사용자 속성을 기억하는 데 사용되는 웹 브라우저에 저장되는 작은 텍스트 파일입니다.

쿠키는 웹을 탐색할 때 사용자의 경험을 향상시키므로 중요합니다. 예를 들어 eCommerce 웹 사이트에서 쇼핑을 하고 장바구니에 어떤 것을 추가하지만 해당 방문에서 로그인 또는 구매하지 않는 경우, 쿠키는 항목을 기억하고 다음 방문 동안 장바구니에 보관합니다. 또는 자주 사용하는 소셜 미디어 웹 사이트를 방문할 때마다 사용자 이름과 암호를 다시 입력해야 한다고 생각해 보십시오. 쿠키는 귀하의 신원을 식별하는 데 도움이 되는 정보를 저장하므로 또한 이 문제를 해결합니다. 이러한 종류의 쿠키는 귀하가 방문한 웹 사이트에서 만들고 사용하기 때문에 퍼스트 파티 쿠키라고 합니다.

타사 쿠키도 있습니다. 이러한 사례를 더 잘 이해하려면 다음 예제를 고려해 보십시오.

"친구"라는 가상 소셜 미디어 회사가 친구 사용자가 친구 피드에서 사이트의 컨텐츠를 공유할 수 있도록 다른 사이트에서 구현하는 공유 단추를 제공한다고 가정해 봅시다. 이제 사용자는 공유 버튼을 사용하는 뉴스 웹 사이트의 뉴스 기사를 읽고 이를 클릭하여 친구 계정에 자동으로 게시합니다.

이렇게 하려면 뉴스 아티클이 로드되면 브라우저가 platform.friends.com에서 친구 공유 단추를 가져옵니다. 이 프로세스 내에서 브라우저는 사용자의 로그인 자격 증명을 포함하는 친구 쿠키를 친구 서버에 요청에 첨부합니다. 이렇게 하면 사용자가 로그인하지 않아도 친구가 사용자를 대신하여 피드에 뉴스 아티클을 게시할 수 있습니다.

이는 모두 제3자 쿠키를 사용하여 가능합니다. 이 경우 제3자 쿠키는 platform.friends.com에 대해 브라우저에 저장되므로 platform.friends.com은 사용자를 대신하여 친구 앱의 게시물을 만들 수 있습니다.

제3자 쿠키 없이 이 사용 사례를 달성하려면 사용자가 많은 수동 단계를 수행해야 합니다. 먼저 사용자는 뉴스 기사 링크를 복사해야 합니다. 둘째, 사용자는 친구 앱에 별도로 로그인해야 합니다. 그런 다음 사용자가 게시물 만들기 단추를 클릭합니다. 그런 다음 사용자가 텍스트 필드에 링크를 복사하여 붙여 넣은 다음 마지막으로 게시물을 클릭합니다. 보시다시피, 제3자 쿠키는 수작업 단계를 대폭 줄일 수 있으므로 사용자 경험을 대폭 향상시키는 데 도움이 됩니다.

일반적으로 타사 쿠키는 사용자가 웹 사이트를 명시적으로 방문하지 않고도 데이터를 사용자의 브라우저에 저장할 수 있도록 합니다.

보안 문제

쿠키는 사용자 경험과 강력한 광고를 향상시키지만, CSRF(Cross-Site Request 위조) 공격과 같은 보안 취약점도 유발할 수 있습니다. 예를 들어 사용자가 은행 사이트에 로그인하여 신용 카드 대금을 내고 로그아웃하지 않고 사이트를 나간 다음 동일한 세션에서 악성 사이트로 이동하면 CSRF 공격이 발생할 수 있습니다. 악성 사이트에는 페이지가 로드될 때 실행하는 은행 사이트로 요청하는 코드가 포함될 수 있습니다. 사용자가 여전히 은행 사이트로 인증되므로 세션 쿠키를 사용하여 CSRF 공격을 실행하여 사용자의 은행 계좌에서 자금 전송 이벤트를 시작할 수 있습니다. 이는 사이트를 방문할 때마다 모든 쿠키가 HTTP 요청에 첨부되기 때문입니다. 그리고 이러한 보안 문제 때문에 Google은 이제 이러한 문제를 완화하려고 시도하고 있습니다.

Target은 쿠키를 어떻게 사용합니까?

이러한 모든 의미와 함께 Target이 쿠키를 사용하는 방법을 살펴보겠습니다. 먼저 Target을(를) 사용하려면 사이트에 Target JavaScript 라이브러리를 설치해야 합니다. 이렇게 하면 사이트를 방문하는 사용자의 브라우저에 퍼스트 파티 쿠키를 배치할 수 있습니다. 사용자가 웹 사이트와 상호 작용할 때 JavaScript 라이브러리를 통해 사용자의 행동 및 관심 데이터를 Target에 전달할 수 있습니다. Target JavaScript 라이브러리는 자사 쿠키를 사용하여 사용자의 행동 및 관심 데이터에 매핑할 사용자에 대한 식별 정보를 추출합니다. 그런 다음 이 데이터를 Target에서 사용하여 개인화 활동을 강화합니다.

또한 Target은 (경우에 따라) 제3자 쿠키를 사용합니다. 다른 도메인에 존재하는 여러 웹 사이트를 소유하고 있고 해당 웹 사이트에서 사용자 여정을 추적하려는 경우 도메인 간 추적을 활용하여 타사 쿠키를 사용할 수 있습니다. Target JavaScript 라이브러리에서 도메인 간 추적을 활성화하면 계정이 타사 쿠키를 사용하기 시작합니다. 사용자가 한 도메인에서 다른 도메인으로 이동할 때 브라우저는 Target의 백엔드 서버와 통신하며 이 프로세스에서는 타사 쿠키가 만들어져 사용자의 브라우저에 배치됩니다. 사용자의 브라우저에 상주하는 제3자 쿠키를 통해 Target은 단일 사용자에 대해 다른 도메인에 일관된 경험을 제공할 수 있습니다.

Google의 새로운 쿠키 레서피

사용자가 보호될 수 있도록 쿠키를 사이트 간에 보내는 경우에 대한 보호 조치를 제공하기 위해 Google은 웹 개발자가 Set-Cookie 헤더에서 SameSite 속성 구성 요소의 쿠키를 관리하도록 요구하는 SameSite라는 IETF 표준에 대한 지원을 추가할 계획입니다.

SameSite 속성으로 전달할 수 있는 Strict, Lax 또는 None값이 있습니다.

설명
Strict 이 설정을 사용하는 쿠키는 처음에 설정된 도메인을 방문할 때만 액세스할 수 있습니다. 즉, Strict는 쿠키를 사이트 간에 사용할 수 없게 차단합니다. 이 옵션은 은행과 같이 보안이 높은 애플리케이션에 가장 적합합니다.
Lax 이 설정을 사용하는 쿠키는 HTTP GET과 같은 비강력한 HTTP 요청이 있는 동일한 사이트 요청이나 최상위 탐색에서만 전송됩니다. 따라서 이 옵션은 쿠키를 제3자가 사용할 수 있지만 사용자가 CSRF 공격의 피해를 입지 않도록 보호하는 보안 혜택이 추가된 경우에 사용됩니다.
없음 이 설정을 사용하는 쿠키는 쿠키가 작동하는 방식과 동일하게 작동합니다.

상기에 유의하면서 Chrome 80은 사용자에게 다음과 같은 2개의 독립 설정을 제공합니다."기본 쿠키로 SameSite" 및 "SameSite가 없는 쿠키는 안전해야 합니다." 이러한 설정은 Chrome 80에서 기본적으로 활성화됩니다.

SameSite 대화 상자

  • 기본 쿠키로 동일한 사이트:설정되면 SameSite 특성을 지정하지 않은 모든 쿠키는 자동으로 사용해야 합니다 SameSite = Lax.
  • SameSite가 없는 쿠키는 안전해야 합니다.설정할 때 SameSite 속성이 없거나 쿠키를 SameSite = None 보안해야 합니다. 이 컨텍스트에서 보호란 모든 브라우저 요청이 HTTPS 프로토콜을 따라야 한다는 것을 의미합니다. 이 요구 사항을 준수하지 않는 쿠키는 거부됩니다. 모든 웹 사이트는 이러한 요구 사항을 충족하기 위해 HTTPS를 사용해야 합니다.

Google의 보안 모범 사례를 따르는 Target

Adobe은 보안 및 개인 정보 보호에 대한 업계 최신 모범 사례를 항상 지원하고 싶습니다. Target이(가) Google에서 도입한 새로운 보안 및 개인 정보 설정을 지원함을 알려드립니다.

"SameSite by default cookies" 설정의 경우 Target은(는) 영향을 주지 않고 사용자의 개입도 없이 개인화를 계속 제공합니다. Target 퍼스트 파티 쿠키를 사용하고 플래그를 Google Chrome에서 SameSite = Lax 적용할 때 계속 제대로 작동합니다.

"SameSite가 없는 쿠키는 안전해야 함" 옵션의 경우 Target에서 도메인 간 추적 기능에 대해 옵트인하지 않으면 Target의 퍼스트 파티 쿠키가 계속 작동합니다.

그러나 도메인 간 추적을 사용하여 여러 도메인에서 Target을 활용하도록 옵트인하는 경우 Chrome에는 SameSite = None 및 보안 플래그가 제3자 쿠키에 사용되어야 합니다. 즉, 사이트에서 HTTPS 프로토콜을 사용해야 합니다. Target의 클라이언트측 라이브러리는 자동으로 HTTPS 프로토콜을 사용하고 SameSite = None 및 보안 플래그를 Target의 제3자 쿠키에 연결하여 모든 활동이 계속 제공될 수 있도록 합니다.

필요한 작업

Target이(가) Google Chrome 80+ 사용자를 위해 계속 작업하도록 하려면 아래 표를 참조하십시오. 이 표에서 다음 열이 표시됩니다.

  • Target JavaScript 라이브러리:mbox.js를 사용하는 경우 at.js 1.x 또는 at.js 2 사이트 를 병합합니다.
  • 기본 쿠키로 SameSite = Enabled:사용자에게 "기본 쿠키로 SameSite"가 활성화되어 있는 경우, 쿠키가 사용자에게 어떤 영향을 미치며 작업을 계속 진행하기 위해 필요한 모든 Target 것이 있습니까?
  • SameSite가 없는 쿠키는 보안되어야 함 = 활성화됨:사용자에게 "SameSite가 없는 쿠키는 반드시 보안 대상이어야 함"이 활성화되어 있는 경우, 쿠키가 어떤 영향을 미치며 Target 계속 작업해야 하는 데 필요한 사항이 있습니까?
Target JavaScript 라이브러리 SameSite를 기본 쿠키로 지정 = 활성화됨 SameSite가 없는 쿠키를 보호해야 함 = 활성화됨
퍼스트 파티 쿠키만 있는 mbox.js입니다. 효과 없음. 도메인 간 추적을 사용하지 않는 경우에는 영향을 주지 않습니다.
크로스 도메인 추적이 활성화된 mbox.js를 반환합니다. 효과 없음. 사이트에 대해 HTTPS 프로토콜을 활성화해야 합니다.
Target 를 사용하여 사용자를 추적하고 Google을 사용하려면 제3자 쿠키가 SameSite = None 있어야 하며 보안 플래그가 있어야 합니다. 보안 플래그를 사용하려면 사이트가 HTTPS 프로토콜을 사용해야 합니다.
at.js 1.x (퍼스트 파티 쿠키 포함). 효과 없음. 도메인 간 추적을 사용하지 않는 경우에는 영향을 주지 않습니다.
at.js 1.x 크로스 도메인 추적이 활성화되어 있는지 확인하십시오. 효과 없음. 사이트에 대해 HTTPS 프로토콜을 활성화해야 합니다.
Target 를 사용하여 사용자를 추적하고 Google을 사용하려면 제3자 쿠키가 SameSite = None 있어야 하며 보안 플래그가 있어야 합니다. 보안 플래그를 사용하려면 사이트가 HTTPS 프로토콜을 사용해야 합니다.
at.js 2.x 효과 없음. 효과 없음.

Target은(는) 무엇을 해야 합니까?

그렇다면 새로운 Google Chrome 80+ SameSite 쿠키 정책을 준수하는 데 Adobe 플랫폼에서 어떻게 해야 합니까?

Target JavaScript 라이브러리 SameSite를 기본 쿠키로 지정 = 활성화됨 SameSite가 없는 쿠키를 보호해야 함 = 활성화됨
퍼스트 파티 쿠키만 있는 mbox.js입니다. 효과 없음. 도메인 간 추적을 사용하지 않는 경우에는 영향을 주지 않습니다.
크로스 도메인 추적이 활성화된 mbox.js를 반환합니다. 효과 없음. Target 서버 SameSite = None 가 호출될 때 타사 쿠키에 Target 및 보안 플래그를 추가합니다.
at.js 1.x (퍼스트 파티 쿠키 포함). 효과 없음. 도메인 간 추적을 사용하지 않는 경우에는 영향을 주지 않습니다.
at.js 1.x 크로스 도메인 추적이 활성화되어 있는지 확인하십시오. 효과 없음. at.js 1.x 크로스 도메인 추적이 활성화되어 있는지 확인하십시오.
at.js 2.x 효과 없음. 효과 없음.

HTTPS 프로토콜을 사용하지 않으면 어떤 영향을 미칩니까?

영향을 줄 유일한 사용 사례는 Target에서 mbox.js 또는 at.js 1을 통해 크로스 도메인 추적 기능을 사용하는 경우입니다.x​에서 지원되지 않습니다. Google의 요구 사항인 HTTPS로 전환하지 않으면 Google에서 사용하는 제3자 쿠키가 Google에 의해 삭제되기 때문에 도메인에서 고유 방문자 수가 급등하게 됩니다. 또한 타사 쿠키가 삭제되기 때문에 사용자가 한 도메인에서 다른 도메인으로 이동할 때 Target은(는) 해당 사용자에 대해 일관되고 개인화된 경험을 제공할 수 없습니다. 제3자 쿠키는 주로 소유한 도메인 간을 이동하는 단일 사용자를 식별하는 데 사용됩니다.

결론

업계가 소비자를 위한 보다 안전한 웹 제작을 위해 진일보하고 있기 때문에, Adobe은 고객이 최종 사용자의 보안과 개인 정보를 보장하는 방식으로 개인화된 경험을 전달할 수 있도록 지원하기 위해 절대적으로 노력하고 있습니다. 전술한 모범 사례를 따르고 Target을 활용하여 Google Chrome의 새로운 SameSite 쿠키 정책을 준수하는 것하기만 하면 됩니다.

이 페이지에서는

Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now
Adobe Maker Awards Banner

Time to shine!

Apply now for the 2021 Adobe Experience Maker Awards.

Apply now