배경
이 문서에서는 Google과 공급업체 (또는 사용자의 계정 발급기관) 간의 통합에 사용되는 공유 식별자의 필수 속성을 설명합니다. 공유 식별자는 Google 계정과 발급기관 계정 사이의 가장자리를 가리키는 불투명 포인터라는 것입니다.
따라서 공유 식별자는 Google 계정 (또는 Google 스토리지의 사용자 또는 기타 법인)이나 공급업체/발급기관 계정 (또는 기타 법인)을 참조하지 않는다는 점을 기억해야 합니다. 이 둘 사이의 관계를 나타냅니다.
공유 식별자 속성
공유 식별자에 필요한 속성은 공유 식별자에 이러한 속성이 없기 때문에 발생한 과거 경험과 기술적 문제로부터 비롯됩니다.
Google과 외부 파트너 간의 통합에서는 사용되는 공유 식별자에 다음과 같은 속성이 있어야 합니다.
- 전역적으로 고유해야 합니다. 이 공유 식별자는 Google 사용자와 발급기관 계정 간의 정확히 하나의 연결을 가리켜야 합니다. 동일한 발급기관에 대해 동일한 값을 가진 또 다른 공유된 식별자가 있어서는 안 됩니다.
- 추측 불가능: 이러한 공유 식별자에는 사용자를 대신하여 조치를 취할 수 있는 권한이 있으므로 서드 파티가 공유 식별자 값을 추측할 수 없어야 합니다.
- 해지 가능: 사용자가 공유 식별자를 취소할 수 있어야 하며, 취소 과정에서 공유 식별자 값의 향후 사용을 금지해야 합니다.
이 속성에는 다음과 같은 몇 가지 결과 속성이 있습니다.
- 두 계정의 변경할 수 없는 속성을 기반으로 하지 않음: 공유 식별자 값이 발급기관 계정 또는 Google 계정의 변경할 수 없는 속성을 기반으로 하는 경우 취소된 공유 식별자를 다시 생성하면 해당 공유 식별자와 동일한 값이 생겨(취소가 실행취소됨) 공유 식별자의 값이 전화번호나 해시가 아니어야 합니다.
- <Google 계정, 파트너 계정>만 아님: 취소를 허용하는 다른 값 (예: 시간)이 있어야 합니다.
- 양쪽에서 계정에 다중 연결 허용: 공유 식별자 값 생성으로 인해 단일 Google 사용자가 여러 은행 계좌에 연결하거나, 2개 이상의 Google 계정을 단일 은행 계좌 (예: 상위 계좌와 상위 계좌의 은행 계좌에 모두 연결된 하위 계좌)에 연결할 수 있어서는 안 됩니다. 취소 가능성과 마찬가지로 몇 가지 결과가 있습니다.
- 마찬가지로 한 계정의 변경 불가능한 속성을 기반으로 하지 않습니다. 그렇지 않으면 단일 Google 사용자가 여러 은행 계좌를 연결했을 때 (공유 식별자 값이 Google 계정을 기반으로 하는 경우) 또는 여러 Google 계정이 단일 은행 계좌에 연결된 경우 (공유 식별자 값이 은행 계좌의 속성을 기반으로 하는 경우)에 따라 공유 식별자 값이 동일합니다.
- 장기 유지: 공유 식별자는 보안 컨텍스트 (연결 수준 및 애플리케이션 수준 보호 (예: PGP, 상호 SSL 등)를 모두 사용하는 Google과 공급업체 간의 통합)에서만 유효하므로 보안을 유지하기 위해 짧은 수명 주기가 필요하지 않습니다. Google에서는 공유 식별자가 만료되지 않는 것을 선호하지만 공급업체가 만료를 요구하는 경우 장기간 (예: 1년 초과)이어야 합니다.
권장되는 다른 공유 식별자 속성은 다음과 같습니다.
- Base64: 이 속성을 사용하면 https를 통해 통합에서 값을 쉽게 전송하고 통신할 수 있습니다.
- 최소 길이: 충돌을 방지하기 위한 주소 공간이 충분한지 확인하려면 최소 27자리 (Base64 인코딩 전)를 사용하는 것이 좋습니다.
문제점
필요한 속성을 이해하는 데 도움이 되도록 이러한 속성을 준수하지 않을 때 발생하는 문제를 보여주는 몇 가지 우수사례를 소개합니다.
공유 식별자 우수사례
우수사례 #1: 전화번호 재활용
사용자의 전화번호를 공유 식별자로 사용한 발급기관입니다. 사용자 A는 휴대전화 요금제를 변경했을 때 전화번호를 포기하고 새 전화번호를 받았습니다. 한 달 후, 통신사가 오래된 전화번호를 재활용하자 갑자기 이 전화번호의 새 소유자인 사용자 B가 계정에 구매하지 않은 제품에 대한 비용이 청구되기 시작했습니다.
발급기관이 다수의 공유 식별자 속성(주로 속성 1)을 위반했습니다. 전화번호와 같은 항목은 사용자 간에 이전할 수 있으므로 특정 스냅샷 기간에만 고유합니다.
우수사례 #2: 붙여넣기
Google/파트너 직원이 실수로 내부 도구 대신 공유 식별자를 채팅에 붙여넣습니다. 추가 보호 계층을 통해 아무도 공유 식별자를 악의적으로 사용하는 것을 방지하지만, 보안을 위해 Google에서는 공유 식별자를 취소하고 새 식별자로 대체하려고 했습니다. Google/파트너가 공유 식별자를 취소하려고 하면 공유 식별자가 발급기관 시스템에 있는 사용자의 계정 ID일 뿐이며 사용자의 계정을 직접 조회하는 데 공유 식별자가 사용된다는 사실을 알게 됩니다. 따라서 공유 식별자를 취소하려면 사용자의 계정을 삭제하고 새 계정을 만들어야 합니다.
우수사례 #3: 나쁜 직원
위의 '붙여넣기' 사고 후 Google/파트너의 악의적인 행위자는 공유 식별자가 사용자의 계정 ID일 뿐이므로 다른 사람의 계정 ID를 자체 공유 식별자 값에 넣을 수 있다면 다른 사람의 계정을 대상으로 구매를 할 수 있다는 사실을 깨달았습니다. 속성 2의 위반으로 인해 이러한 의도치 않게 붙여넣기가 단일 사용자를 위한 보안 허점을 넘어 모든 사용자의 보안에 구멍이 되었습니다.
우수사례 #4: The Rotation
위의 '붙여넣기' 이슈가 발생하면 발급기관은 공유 식별자 형식으로 UUID로 전환합니다. 이번에는 발급기관 직원이 일부 공유 식별자를 디버깅 이메일 스레드의 일부로 일반 텍스트로 잘못 전송합니다. Google은 걱정하지 마세요. 사용자의 공유 식별자를 취소하고 교체하기만 하면 됩니다.
순환 과정의 일환으로, Google은 데이터베이스 정리가 진행되는 동안 보안 침해된 각 사용자 계정에 짧은 시간 동안 2개의 공유 식별자가 활성화된다고 발급기관에 알립니다. 하지만 발급기관이 속성 #4를 허용하지 않았고 특정 사용자 계정에 하나의 공유 식별자만 활성화할 수 있다는 제약 조건이 있다고 Google에 알립니다. 이렇게 하면 경합 상태가 포함된 매우 복잡한 회전이 발생합니다.