웹에서의 개인정보 보호

웹에서 사용할 수 있는 다양한 개인정보 보호 및 보안 기능을 살펴보기 전에 몇 가지 중요한 용어를 정의해 보겠습니다.

개인정보 보호에 대해 이야기할 때 보안에 대해서도 이야기하지 않을 수 없습니다. 이 둘은 밀접하게 관련되어 있으며, 좋은 보안 없이는 개인정보를 존중하는 웹사이트를 만들 수 없습니다. 따라서 우리는 두 가지를 모두 정의하겠습니다.

• 개인정보 보호는 사용자가 자신의 데이터가 어떻게 수집, 저장 및 사용되는지 제어할 수 있는 권리를 부여하고, 이를 무책임하게 사용하지 않는 것을 의미합니다. 예를 들어, 사용자가 어떤 데이터를 수집하고, 누구와 공유하며, 어떻게 사용할 것인지 명확하게 전달해야 합니다. 사용자는 데이터 사용 조건에 동의할 기회를 가져야 하며, 저장된 모든 데이터에 접근할 수 있어야 하고, 더 이상 데이터를 보유하지 않기를 원할 경우 삭제할 수 있어야 합니다. 또한 자신의 조건을 준수해야 합니다. 사용자가 동의하지 않은 방식으로 데이터를 사용하고 공유하는 것은 사용자 신뢰를 무너뜨리는 가장 큰 요인 중 하나입니다. 이는 단순히 윤리적으로 잘못된 것뿐만 아니라 법을 위반할 수도 있습니다. 세계 여러 지역에서는 소비자 개인정보 보호 권리를 보호하는 법률이 존재합니다(예: EU의 GDPR).

• 보안은 민감한 데이터와 시스템을 무단 접근으로부터 보호하는 행위를 의미합니다. 여기에는 회사(내부) 데이터와 사용자 및 파트너(외부) 데이터가 포함됩니다. 사용자가 신뢰할 수 있는 강력한 개인정보 보호 정책을 가지고 있어도 보안이 약하면 악의적인 당사자가 데이터를 훔칠 수 있습니다.

개인정보는 사용자를 설명하는 모든 정보를 의미합니다. 예시로는 다음과 같습니다.

• 우편 주소, 이메일 주소, 전화번호 등의 연락처 정보
• 여권 번호, 은행 계좌, 신용카드, 사회 보장 번호 등의 공식 식별자
• 키, 성별 표현, 체중, 머리 색깔, 나이 등의 신체적 속성
• 의료 기록, 알레르기, 지속적인 질환 등의 건강 정보
• 사용자 이름(개인과 연결될 수 있는 경우)
• 취미, 관심사 등의 개인적 선호
• 지문이나 얼굴 인식 데이터 등의 생체 데이터

민감정보는 사용자가 공개적으로 공유하기를 원하지 않는 정보로, 특정 그룹의 승인된 사용자만 접근할 수 있는 정보입니다. 일부 민감 데이터는 법적으로 보호되며(예: 의료 데이터), 일부는 개인의 선호에 따라 보호됩니다.

위 섹션에 이어서, 개인 식별 정보(PII)는 전체 또는 일부를 사용하여 특정 개인을 추적하거나 식별할 수 있는 정보를 의미합니다. 예를 들어, 사이트가 사용자 이름과 우편번호 목록을 온라인에 유출하면 악의적인 사용자가 이를 사용하여 전체 주소를 찾을 수 있습니다. 전체 유출이 발생하지 않더라도, 사용자가 사용하는 브라우저, 장치, 설치된 특정 글꼴 등을 통해 사용자를 식별할 수 있습니다.

추적은 여러 웹사이트에서 사용자의 활동을 추적하는 과정을 의미합니다. 이는 다양한 방법으로 수행될 수 있습니다. 예를 들어:

• 여러 사이트에 포함된 제3자 콘텐츠에서 설정된 제3자 쿠키를 통해 사용자의 다양한 정보 포인트를 찾습니다.
• Referer 헤더를 통해 사용자가 어디에서 왔는지 확인합니다.
• 인바운드 링크의 URL에 매개변수를 포함시켜(예: 제품 페이지로 연결되는 광고나 마케팅 이메일) 링크된 사이트에 링크가 어디에서 왔는지, 어떤 마케팅 캠페인의 일부인지, 클릭한 사용자의 이메일 주소나 다른 식별자를 알 수 있습니다. 이 과정을 링크 장식이라고 하며, 링크 URL은 다음과 같이 보입니다. https://example.com/article/?id=62yhgt1a&campaign=902.
• 리디렉션 추적은 추적기가 사용자를 잠시(그리고 감지할 수 없을 정도로) 자신의 웹사이트로 리디렉션하여 퍼스트 파티(first-party) 저장소를 사용하여 사용자를 추적하는 것을 의미합니다. 이는 제3자 쿠키가 차단되는 것을 우회할 수 있게 합니다. 예를 들어, 제품 리뷰를 읽고 구매하려고 클릭하면, 리디렉션 추적기에게 먼저 이동한 후 소매업체로 이동할 수 있습니다. 이는 추적기가 첫 번째로 로드되어 퍼스트 파티(first-party) 쿠키에 저장된 식별자와 추적 데이터를 연결한 후 소매업체로 전달할 수 있음을 의미합니다.

추적 데이터는 사용자의 관심사와 선호도를 프로파일링하는 데 사용될 수 있으며, 이는 일반적으로 나쁘고 다양한 정도로 성가실 수 있습니다. 예를 들면 다음과 같습니다.

• 타겟 광고: 누구나 한 번쯤 구매하려고 한 물품을 한 기기에서 검색해 본 뒤, 다른 모든 기기에서 같은 상품에 대한 광고가 갑자기 쏟아지는 불편한 경험을 해본 적이 있을 것입니다.
• 데이터 판매 또는 공유: 일부 제3자는 추적 데이터를 수집하여 다른 사람에게 판매하거나 공유하여 타겟 광고와 같은 다양한 목적으로 사용할 수 있습니다. 이는 매우 비윤리적이며, 세계 어느 지역에서 발생하느냐에 따라 불법일 수도 있습니다.
• 데이터를 통한 편견: 최악의 경우, 데이터 공유로 인해 사용자가 부당하게 불이익을 받을 수 있습니다. 예를 들어, 보험 회사가 잠재 고객에 대한 데이터를 찾아내고 이를 보험료 인상의 근거로 사용하는 경우를 상상해 보십시오.

추적과 매우 밀접한 관련이 있는 과정은 핑거프린팅입니다. 이는 사용자를 식별하기 위해 다른 사용자와 구별되는 데이터 포인트를 축적하는 것을 의미합니다. 이는 쿠키 내용에서 사용자가 사용하는 브라우저와 로컬에 설치된 글꼴에 이르기까지 무엇이든 될 수 있습니다.

최신 브라우저는 정보에 대한 액세스를 허용하지 않거나, 정보가 제공되어야 하는 경우 식별 목적으로 사용되지 못하도록 변형이나 "노이즈"를 도입하여 핑거프린팅 기반 공격을 방지하기 위한 조치를 취합니다.

예를 들어, 웹사이트가 사용자의 브라우저에서 경과 시간을 쿼리하면, 해당 시간을 서버에서 보고한 시간과 비교하면 지문 분석의 요소로 유용할 수 있습니다. 이로 인해 브라우저는 타이머에 약간의 변동을 도입하여 사용자의 시스템을 식별하는 데 덜 유용하게 만듭니다.

브라우저 공급업체는 사용자 개인정보 보호의 필요성과 추적, 핑거프린팅 등이 사용자 경험에 미치는 부정적인 영향을 인식하고 있습니다. 이를 위해 개인정보 보호를 강화하거나 위협을 완화하는 다양한 기능을 구현했습니다. 이 섹션에서는 브라우저가 자동으로 적용하는 다양한 개인정보 보호 범주를 살펴봅니다.

전송 계층 보안(TLS)은 네트워크를 통한 데이터 전송 중에 데이터를 암호화하여 보안과 개인정보 보호를 제공합니다. 이는 HTTPS 프로토콜의 기술입니다. TLS는 전송된 데이터를 제3자가 가로채어 악의적으로 사용하는 것을 방지하므로 개인정보 보호에 유리합니다.

모든 브라우저는 기본적으로 HTTPS를 요구하는 방향으로 나아가고 있습니다. 이는 이미 사실상 웹에서 이 프로토콜 없이는 할 수 있는 일이 거의 없기 때문입니다.

관련 주제는 다음과 같습니다:

인증서 투명성

인증서를 모니터링하고 감사하기 위한 공개 표준으로, 잘못된 인증서를 식별하는 데 사용할 수 있는 공개 로그 데이터베이스를 만듭니다.

HTTP 엄격 전송 보안(HSTS)

HSTS는 서버가 프로토콜 다운그레이드 및 쿠키 하이재킹 공격으로부터 자신을 보호할 수 있도록 클라이언트에게 HTTPS만을 사용하여 서버와 통신할 수 있음을 알리는 데 사용됩니다.

HTTP/2

HTTP/2는 기술적으로 암호화를 사용하지 않아도 되지만, 대부분의 브라우저 개발자는 HTTPS와 함께 사용할 때만 지원하므로 보안/개인정보 보호를 강화하는 기능으로 생각할 수 있습니다.

잠재적으로 민감한 데이터와 작업에 대한 액세스를 제공하는 "강력한" 웹 API 기능은 보안 컨텍스트에서만 사용할 수 있습니다. 이는 기본적으로 HTTPS 전용을 의미합니다. 뿐만 아니라 이러한 웹 기능은 사용자 권한 시스템 뒤에 숨겨져 있습니다. 사용자는 알림 허용, 위치 데이터 액세스, 전체 화면 모드로 전환, 웹캠에서 미디어 스트림 액세스, 웹 결제 사용 등의 기능을 명시적으로 옵트인해야 합니다.

브라우저는 사용자의 개인정보 보호를 자동으로 강화하는 여러 추적 방지 기능을 구현했습니다. 이들 중 다수는 최상위 도메인에서 설정된 쿠키에 접근하거나 추적 스크립트를 실행하는 등의 제3자 사이트의 능력을 차단하거나 제한합니다.

• Set-Cookie 헤더의 SameSite 속성의 기본값이 Lax로 업데이트되어 추적 및 CSRF 공격에 대한 보호를 제공합니다. 자세한 내용은 SameSite로 제3자 쿠키 제어를 참조하십시오.
• 모든 브라우저는 기본적으로 제3자 쿠키를 차단하기 시작했습니다. 자세한 내용은 브라우저는 제3자 쿠키를 어떻게 처리합니까?를 참조하십시오.
• 브라우저는 특정 상황에서만 제3자 쿠키를 허용하거나 현재 제3자 쿠키가 필요한 일반적인 사용 사례를 대체하는 기술을 구현하고 있습니다. 자세한 내용은 제3자 쿠키에서 전환 및 제3자 쿠키 대체를 참조하십시오.
• 여러 브라우저는 URL에서 알려진 추적 매개변수를 제거합니다. 여기에는 Firefox, Safari, Brave가 포함됩니다. 브라우저 확장 프로그램도 이를 도와줍니다. 예를 들어 ClearURLs을 참조하십시오.
• 브라우저는 리디렉션 추적 보호를 구현했습니다.

웹 개발자는 사용자의 개인정보를 개선하기 위해 여러 가지 조치를 취할 수 있으며 취해야 합니다. 아래 섹션에서는 가장 중요한 것들을 논의합니다. 일부 범주는 순수한 기술 작업이 아니며 다른 팀원과의 협업이 필요할 수 있습니다.

회사는 다양한 이유로 사용자로부터 다양한 데이터를 수집합니다.

• 인증 목적으로 사용자 이름, 비밀번호, 이메일 등을 수집합니다.
• 의사소통을 위해 이메일, 우편 주소, 전화번호를 수집합니다.
• 사이트 개인화부터 고객 만족도 조사에 이르기까지 다양한 PII를 수집합니다.
• 사이트 및 다른 사이트에서의 브라우징 습관을 측정하여 페이지 및 기능 성공 지표를 측정합니다.
• 그 외에도 많은 데이터를 수집합니다.

고객으로부터 데이터를 수집할 때, 무결성을 유지하고 신뢰할 수 있음을 보여주며, 고객과의 훌륭한 관계를 구축할 기회를 가집니다. 이는 브랜드를 개선하고 성공 가능성을 높이는 데 도움이 됩니다.

데이터 수집의 윤리는 세 가지 간단한 원칙으로 나눌 수 있습니다.

• 필요한 데이터만 수집
• 수집한 데이터를 어떻게 사용할 것인지 명확하게 전달
• 데이터를 사용한 후 삭제

미래에 유용할 것이라고 생각하여 사용자로부터 많은 데이터를 요청하는 것은 유혹적입니다. 그러나 수집하는 모든 추가 데이터는 사용자의 개인정보에 대한 위험을 증가시키고, 설문조사 작성이나 서비스 가입 등 사용자가 수행하는 단계를 포기할 가능성을 높입니다.

데이터를 익명화하는 것이 좋습니다. 또한 데이터 요청을 덜 세분화하여 필요한 것을 얻을 수 있는지 고려해야 합니다. 예를 들어, 사용자의 좋아하는 제품을 묻는 대신 더 일반적인 카테고리 중에서 선택하도록 요청할 수 있습니다.

그러나 사용자 개인정보를 보호하는 가장 좋은 방법은 수집하는 데이터를 최소화하는 것입니다. 이전 예를 참조하면, 사용자 구매 내역을 살펴보면 동일한 데이터를 추론할 수 있습니다. 또 다른 예로, 사용자는 익명으로 제품을 구매할 수 있는 것을 선호합니다. 서비스 운영에 필요하지 않다면 계정 가입을 강요하지 말아야 합니다. 이는 사용자의 선택이어야 합니다.

수집할 데이터를 결정한 후, 사이트에 개인정보 보호 정책을 게시하여 다음을 명확하게 명시해야 합니다.

• 수집하는 데이터
• 데이터를 사용하는 방법
• 데이터를 공유할 의도가 있는 경우, 공유할 당사자와 사용자 동의를 요청할 것임을 명시
• 데이터를 삭제하기 전까지 보관하는 기간
• 사용자가 수집한 데이터를 보고 삭제할 수 있는 방법

사용자가 데이터를 제공할 때, 개인정보 보호 정책을 읽고 동의할 기회를 제공해야 합니다. 사용자는 이에 동의하고 귀하의 조건에 동의할 수 있어야 합니다. 위에서 언급한 것처럼, 수집한 데이터를 보고 삭제할 수 있어야 합니다.

개인정보 보호 정책을 게시한 후에는 이를 준수해야 합니다. 말한 대로 행동하는 것은 사용자 신뢰를 구축하는 데 매우 중요합니다. 수집한다고 말한 데이터만 수집하고, 말한 목적에만 사용해야 합니다. 회사의 누군가가 기존 데이터를 사용하는 새로운 방법을 생각해냈더라도, 정책에 명시되지 않은 목적이라면 여전히 허용되지 않습니다. 사용자가 특정 목적으로 데이터 사용에 동의했으며 그 목적이 확장되면 새로운 동의를 얻어야 할 수도 있습니다.

앞서 언급한 것처럼, 사용자가 수집한 데이터를 보고 삭제할 수 있는 방법을 제공해야 합니다. 이는 계정 삭제 경험의 일부로 수행할 수 있으며(데이터가 함께 삭제됨), 두 가지 별도의 옵션으로 만들 수도 있습니다. 어느 쪽이든 옵션은 쉽게 찾을 수 있어야 합니다.

사용자가 데이터의 상당 부분을 삭제할 수 있도록 선택할 수 있게 하는 것은 매우 강력하며 신뢰를 구축하지만, 일부 데이터는 직접 삭제하는 것이 좋습니다. 예를 들어, 일부 데이터는 몇 시간 또는 몇 분 동안만 사용되고 삭제될 수 있습니다. 예를 들어, 사용자가 로그인한 동안 세션을 관리하는 동안 사용되는 데이터와 같은 데이터입니다.

앞서 추적과 비윤리적인 목적으로 사용되는 예를 논의했습니다. 이러한 사용이 사용자 신뢰를 어떻게 훼손할 수 있는지 설명할 필요는 없습니다. 가능한 한 제3자 쿠키와 같은 잠재적 추적 메커니즘을 윤리적인 용도로만 사용해야 합니다. 예를 들어, 사이트 간 로그인 상태나 다른 개인화 상태를 전송하는 데 사용할 수 있습니다.

또한 앞서 언급한 것처럼, 모든 브라우저는 기본적으로 제3자 쿠키를 차단하기 시작했으며, 대체 기술을 구현하여 일반적인 사용 사례를 달성하고 있습니다. 이를 준비하는 것이 좋습니다. 추적 활동을 제한하거나 다른 방법으로 원하는 정보 지속성을 구현하십시오. 자세한 내용은 제3자 쿠키에서 전환을 참조하십시오.

물론, 자신이 만든 리소스(코드, 쿠키, 사이트 등)만 신경 쓴다면 개인정보 보호를 관리하기 쉬울 것입니다. 실제 도전 과제는 사이트에서 제3자 리소스를 사용할 가능성이 있다는 것입니다. 여기에는 <iframe>에 포함된 제3자 콘텐츠, 라이브러리, 프레임워크, API, 외부 호스팅 리소스(예: 이미지 및 비디오) 등이 포함됩니다.

제3자 리소스는 최신 웹 개발의 필수 요소로 많은 기능을 제공합니다. 그러나 사이트에 허용하는 모든 제3자 리소스는 포함 방법에 따라 동일한 권한을 가질 수 있습니다.

• <iframe>을 통해 사이트에 포함된 제3자 콘텐츠 내에서 실행되는 JavaScript는 동일 출처 정책에 의해 분리되어 최상위 브라우징 컨텍스트에 포함된 다른 스크립트 및 데이터에 접근할 수 없습니다.
• 그러나 <script> 요소를 통해 페이지에 직접 포함된 제3자 스크립트는 사이트나 다른 사이트에 호스팅된 스크립트 및 데이터에 접근할 수 있습니다. 이는 사실상 퍼스트 파티(first-party) 코드로 간주됩니다. 이 방식으로 포함된 악성 스크립트는 사용자의 데이터를 비밀리에 훔쳐 제3자 서버로 전송할 수 있습니다.

사이트에서 사용하는 모든 제3자 리소스를 감사하는 것이 중요합니다. 그들이 수집하는 데이터, 요청하는 대상 및 개인정보 보호 정책을 파악하십시오. 신중하게 설계된 개인정보 보호 정책은 이를 위반하는 제3자 스크립트를 사용하면 무용지물이 됩니다.

제3자 리소스를 감사하고 그들이 무엇을 하는지 이해한 후에는 그들의 부정적인 측면을 그들이 가져오는 가치에 대한 절충안(trade-off)으로 고려해야 합니다. 제3자 스크립트가 무료이고 매우 유용하지만 많은 사용자 데이터를 수집하는 경우 다음을 수행할 수 있습니다.

1. 그 타협을 받아들이고, 개인정보 보호 정책을 업데이트하여 세부 정보를 포함하고, 사용자 신뢰에 큰 영향을 미치지 않기를 바랍니다.
2. 덜 데이터 수집하는 제3의 대안적 도구를 찾습니다.
3. 자체 도구를 만듭니다.

다음 목록은 제3자 리소스를 사용할 때 내재된 개인정보 보호 위험을 완화하는 방법에 대한 몇 가지 팁을 제공합니다.

• 제3자 리소스를 포함할 때, 개인정보 보호에 미치는 영향을 줄이면서 동일하거나 유사한 효과를 달성할 수 있는 방법이 있는지 고려하십시오. 예를 들어, 사이트에 소셜 미디어 게시물 뷰어를 포함하는 것이 재미있을 수 있지만, 정말 필요한가요? 소셜 미디어 페이지로의 링크가 충분하지 않나요? 또한 일부 제3자 서비스는 개인정보 보호 옵션을 제공합니다. 예를 들어 YouTube의 비디오 및 재생목록 포함 > 개인정보 보호 모드 켜기를 참조하십시오.

• 가능한 경우, 제3자에게 요청할 때 Referer 헤더를 받지 않도록 차단하십시오. 이는 예를 들어 외부 링크에 rel="noreferrer"를 포함하여 매우 세분화된 방식으로 수행할 수 있습니다. 또는 Referrer-Policy 헤더를 사용하여 페이지나 사이트에 대해 더 전역적으로 설정할 수 있습니다.

  참고 :>Referer 헤더: 개인정보 보호 및 보안 문제도 참조하십시오.

• Permissions-Policy HTTP 헤더를 사용하여 API "강력한 기능"(예: 알림, 위치 데이터, 웹캠에서 미디어 스트림 액세스 등)에 대한 액세스를 제어하십시오. 이는 제3자 사이트가 이러한 기능으로 예상치 못한 작업을 수행하는 것을 방지하고, 사용자가 이해하지 못할 수 있는 권한 프롬프트로 불필요하게 폭격당하지 않도록 하기 때문에 개인정보 보호에 유용합니다. 또한 <iframe> 요소 내에 포함된 제3자 사이트 내에서 "강력한 기능" 사용을 제어할 수 있습니다.

  참고 : 자세한 내용과 예는 Permissions-Policy 가이드를 참조하고, 유용한 도구를 포함한 permissionspolicy.com을 참조하십시오.

• <iframe> sandbox 속성을 사용하여 <iframe>에 포함된 콘텐츠 내에서 특정 기능 사용을 허용하거나 허용하지 않습니다. 여기에는 다운로드, 양식 제출, 모달 및 스크립팅 등이 포함됩니다.

사용자 데이터를 수집한 후에는 안전하게 전송하고 저장해야 합니다. 이는 보안 주제와 더 비슷하지만 여기서 언급할 가치가 있습니다. 보안이 느슨하고 공격자가 데이터를 훔칠 수 있다면 좋은 개인정보 보호 정책은 무용지물입니다.

다음 팁은 사용자의 데이터를 보호하는 데 도움이 됩니다.

• 보안을 올바르게 구현하는 것은 어렵습니다. 특히 민감한 데이터(예: 로그인 자격 증명)를 포함한 보안 솔루션을 구현할 때는 신뢰할 수 있는 공급업체의 평판 좋은 솔루션을 사용하는 것이 좋습니다. 예를 들어, 모든 평판 있는 서버 측 프레임워크는 일반적인 취약성을 보호하는 내장 기능을 제공합니다. 또한 용도에 맞는 특수 제품(예: ID 공급업체 솔루션 또는 보안 온라인 설문 조사 공급업체)을 사용하는 것도 고려할 수 있습니다.
• 사용자 데이터를 수집하기 위한 자체 솔루션을 구현하려면 무엇을 하는지 이해해야 합니다. 경험이 풍부한 서버 측 개발자 및/또는 보안 엔지니어를 고용하여 시스템을 구현하고 철저히 테스트하십시오. 더 나은 보호를 위해 다중 요소 인증(MFA)을 사용하십시오. 클라이언트 측 앱을 간소화하기 위해 웹 인증 또는 연합 자격 증명 관리와 같은 전용 API를 사용하는 것을 고려하십시오.
• 사용자 가입 정보를 수집할 때, 사용자의 계정 세부 정보를 쉽게 추측할 수 없도록 강력한 비밀번호를 적용하십시오. 약한 비밀번호는 보안 침해의 주요 원인 중 하나입니다. 사용자가 비밀번호 관리자를 사용하여 복잡한 비밀번호를 생성하고 저장하도록 권장하십시오. 이렇게 하면 비밀번호를 기억하는 것에 대해 걱정하지 않거나 적어두어 보안 위험을 초래하지 않습니다.
• URL에 민감한 데이터를 포함하지 마십시오. 제3자가 URL을 가로채면(예: Referer 헤더를 통해) 해당 정보를 훔칠 수 있습니다. 이를 피하기 위해 GET 요청 대신 POST 요청을 사용하십시오.
• 콘텐츠 보안 정책 및 권한 정책과 같은 도구를 사용하여 사이트에서 기능 사용 집합을 강제하여 취약성을 도입하기 어렵게 만드십시오. 이를 수행할 때 주의하십시오. 제3자 스크립트가 작동하는 데 의존하는 기능 사용을 차단하면 사이트 기능이 중단될 수 있습니다. 이는 제3자 리소스를 감사할 때 조사할 수 있는 사항입니다(참조: 제3자 리소스 신중하게 관리).

• 웹 보안
• web.dev의 Learn Privacy
• developers.google.com의 The Privacy Sandbox
• mozilla.org의 Lean Data Practices