사용자의 위험을 완화하는 좋은 방법은 사용자의 개인 정보 보호에 영향을 미치고 필요하지 않은 민감한 정보를 보유하지 않는 것입니다. 비즈니스 목표를 달성하면서 이를 실행하는 방법은 생각보다 많으며, 각각의 방법을 고려해 볼 만합니다. 다음과 같은 방법을 사용할 수 있습니다.
- 데이터가 필요한 대상을 설명합니다.
- 데이터를 더 낮은 수준으로 수집합니다.
- 사용한 후에는 데이터를 삭제합니다.
- 애초에 수집하지 않습니다.
이러한 각 접근 방식은 개발자가 수행하는 작업과 이유에 대해 사용자가 더 편안하게 느끼도록 할 수 있으며 도움이 될 수 있습니다 투명성은 신뢰를 구축하며, 중요한 점은 신뢰가 차별화된 판매 포인트가 될 수 있다는 것입니다. 여러 사람 사용자와 고객이 기본적으로 자신을 신뢰한다고 가정하지만 소비자는 지속적으로 제품과 서비스를 평가하고 있으므로 그렇지 않습니다. 사용자의 데이터 및 상호작용을 신뢰할 수 있다고 사용자가 신뢰하는 상태에서 사용자와 관계를 구축하면 기업으로서 프로젝트 또는 비즈니스로서 경쟁 우위를 점할 수 있습니다. 진정한 차별화 요소라고 할 수 있습니다.
위의 접근 방식을 가장 효과적(비즈니스에 가장 큰 영향)에서 가장 효과적이지 않지만 구현 시 가장 간섭이 적은 순서로 살펴보겠습니다.
처음부터 수집하지 마세요.
사용자의 보안 침해를 방지하는 가장 확실한 방법은 데이터를 수집하지 않는 것입니다. 서비스를 제공하기 위해서는 일부 데이터 수집이 필요하며, 생각보다 데이터 수집을 피할 수 있는 곳이 더 많이 있습니다. 예를 들어 비회원 결제를 생각해 보세요. 사용자가 웹 앱을 사용하여 무언가를 구매할 때 계정에 가입하라고 요구할 수 있습니다. 나중에 처리를 위해 개인 정보를 캡처한 경우: 메일링 리스트에 추가할 수 있으며 이미 자격이 있음을 확인합니다. 관심을 보이는 고객이라고 말할 수 있습니다. 하지만 고객은 이를 인식하고 이를 싫어합니다. 2021년 한 연구에 따르면 사이트에서 사용자에게 계정 생성을 요구하여 판매가 중단된 사례가 4건 중 1건에 달했습니다. 계정이 필요하지 않으면 고객을 유지할 가능성이 높습니다. 가입하지 않고 구매를 완료할 수 있는 기능은 다음과 같습니다. 사용자에게 더 나은 옵션을 제공할 수 있으며, 보호 및 보안을 위해 데이터가 충분하지 않다는 의미이기도 합니다.
데이터 '퍼징'
물론 데이터 수집을 완전히 피하는 것은 불가능할 수 있습니다. 서비스를 제공하고 현명한 비즈니스 결정을 내리기 위해서는 데이터를 수집하는 것이 중요합니다. 또한 신뢰 관계의 맥락에서 마케팅 커뮤니케이션을 구축하는 것도 도움이 될 수 있습니다. 하지만 종합적으로 내린 결정 (즉, 많은 사용자에게 한 번에 영향을 미치는 결정)이 내려지고 집계한 데이터에 대한 정보 (즉, 데이터의 집합적 속성에 관한 정보)를 제공합니다.
예를 들어 시청자의 인구통계, 즉 시청자가 어떤 연령대에 속하는지, 지정할 수 있습니다. 따라서 메시지 또는 접근 방식이 달라질 수 있습니다. 하지만 서비스의 모든 사용자에 대해 정확한 연령을 수집해야 한다는 의미는 아닙니다. 동향 및 전반적인 숙박 시설을 주로 확인합니다. 내리고자 하는 결정이 대부분의 잠재고객이 '18~34세 주요 인구통계'에 속하는지에 영향을 받는다면 실제로 물어봐야 할 유일한 질문은 내 사용자가 해당 인구통계에 속하는지 여부입니다. 이렇게 하면 해당 버킷이 아닌 해당 그룹에 있는 두 개의 '버킷'으로 수집됩니다. 그보다 더 상세한 데이터가 필요한 경우가 있을 수 있지만, 인구통계 목록을 사용하는 것이 매우 합리적입니다. 사용자를 이 목록으로 분류하도록 요청하는 데 사용됩니다.
예
따라서 사용자층이 '18~34세', '35~49세', '49~64세', '65세 이상' 연령 카테고리 중 어느 곳에 속하는지 아는 것이 유용하다면 사용자에게 해당 카테고리 중 어느 곳에 속하는지 선택해 달라고 요청할 수 있습니다. 매우 상세하고 개인화된 개인 정보를 요청한 후 나중에 동일한 질문을 더 자세히 다시 할 필요가 없으므로 사용자를 직접 분류하고 싶은 유혹이 들 수 있습니다. 예를 들어 정확한 연령과 생년월일을 요청한 후 이를 사용하여 '35~49세' 카테고리에 속하는 사용자 수를 직접 나열할 수 있습니다. 그러나 이 과정이 어떻게 진행되는지 깨닫는 것이 중요합니다. 이미 과정에서 자세한 수준의 데이터를 요청하면 사람들이 불편해질 수 있으므로 조직에 대한 사용자의 신뢰가 낮아질 수 있습니다. 위험 부담을 줄일 수 있습니다
데이터 요구사항을 고려하는 것도 중요합니다. 더 상세한 데이터에 대한 '필요'가 추측에 기반한 '만약의 경우' 요구사항인 경우가 있습니다. 지금은 사용자를 네 가지 연령대만으로 분류하면 되지만 향후 범위를 좁히고 싶을 수 있으므로 나중에 이 옵션을 계속 사용할 수 있도록 지금 매우 상세한 데이터를 수집해야 합니다. 과거에 더 세부적인 데이터가 실제로 얼마나 자주 의사결정에 사용되었는지 고려해 볼 만합니다. 데이터에 대해 악영향을 끼치는 것으로 인식될 경우 사용자의 신뢰도가 낮아지게 됩니다. 되었습니다. '만약에'라는 이유로 데이터를 수집하는 경우, 비즈니스 결정을 개선하기 위한 사용자 신뢰를 잃을 뿐만 아니라 존재하지 않을 수도 있는 미래의 이론적 결정 가능성만을 위해 사용자 신뢰를 잃고 해당 정보에 대한 보안 요구사항을 부담하게 될 수 있습니다.
수집된 데이터의 세부사항을 줄이는 더 자세한 알고리즘 방식도 있습니다. 무작위 응답 방법은 데이터가 조정 가능한 정도의 부정확성으로 수집된다는 것을 의미하며, 이러한 방법은 응답자의 비밀을 유지하면서 잠재적으로 침습적이거나 민감한 데이터를 수집할 때 수십 년 동안 사회과학에서 사용되어 왔습니다. 이 보다 광범위한 데이터 수집이 포함됩니다. '다음 중 어느 연령대에 속하는가'), 여기서 무작위 응답은 특정 비율을 포함합니다. 의 사용자가 자신의 답변에 대해 거짓말을 합니다. 잘못 응답하는 사용자의 비율을 알고 있다면 수집된 데이터에서 의미 있는 결론을 도출할 수 있지만, 수집된 데이터가 잘못되었을 수 있으므로 개별 사용자의 개인 정보는 침해되지 않습니다. 이 경우 시청자의 80% 가 여전히 18~34세에 해당한다고 언급한다면 10% 가 의도적으로 잘못된 답변을 제공하더라도 이 비율이 여전히 가장 큰 비중이라고 상대적으로 확신하고 있습니다. 부정확한 정도는 프로그래밍 방식으로 변경할 수도 있습니다. 즉, 정답은 항상 요구되지만 소프트웨어는 전송하기 전에 답변의 특정 비율을 변경합니다. 이 프로세스와 그 결과는 데이터가 수집될 때 사용자에게 설명할 수도 있습니다. 즉, 개별 데이터는 신뢰할 수 없으므로 수집된 데이터를 악용하지 않을 것이라고 사용자는 신뢰할 필요가 없습니다.
비슷하지만 더 기술적으로 더 복잡한 프로세스가 개인 정보 차등 보호입니다. 이는 수학적 기법을 사용하여 데이터의 집계 속성이 여전히 존재하도록 데이터 스토리지를 변경하지만 특정 개인이 데이터를 제공했는지 또는 그들이 제공한 데이터가 있었는지조차 알 수 없습니다. 이는 무작위 응답과 마찬가지로 명확한 의도를 보여줍니다. 사용자의 액세스 권한을 데이터를 찾을 수 있습니다.
이러한 접근 방식은 수집된 데이터가 광고주를 포함한 사용자의 개인 정보 침해를 줄이고 데이터가 유출되는 경우 침해 수준을 줄여주므로 데이터 침해 및 유출에 대한 보안도 강화됩니다. 하지만 서버에서 개인 정보 차등 보호 기술을 적용하면 기법을 사용하여 집계하는 경우) 여전히 원시 사용자 데이터를 보호하고 처리 후 삭제합니다. 또한 명확한 정책을 마련하여 준수해야 하며 데이터를 집계하거나 용도를 명확히 알 수 있어야 합니다.
보관: 데이터를 수집한 다음 사용한 후에는 삭제
수집된 데이터에는 수집, 비즈니스 결정을 내리는 데 사용, 삭제라는 수명 주기가 있음을 기억하는 것이 좋습니다. 이는 다시 한번 절충입니다. 사용자에게 질문하거나 사용자가 방문한 다른 웹사이트에 관한 정보를 저장하거나 사용자가 어떤 항목을 얼마나 오래 살펴봤는지 추적하여 사용자의 선호도를 예측하는 경우, 개발자가 적절하다고 판단되는 대로 사용할 수 있는 무제한 부여가 아닌 특정 목적으로 부여된 데이터입니다. 데이터가 더 이상 필요하지 않은 경우 몇 년이 지난 후에 삭제되기도 합니다.
사용자에 관한 정보를 수집할 때마다 해당 데이터를 어떤 용도로 사용할지(아래 참고) 알고 있어야 하며, 언제, 왜 해당 데이터를 보유하지 않게 될지도 알아야 합니다. 이는 사용자가 삭제하도록 선택했을 때, 로그아웃할 때, 특정 기간이 지난 후 또는 특정 이벤트가 발생한 후에 발생할 수 있습니다. 이는 고객과의 관계에서 신뢰를 쌓을 수 있는 좋은 방법입니다. 가능한 경우 일방적 수신 거부 등 데이터 관리 방식을 사용자에게 명확히 알리는 것입니다. 데이터를 삭제하려면 어떻게 해야 하나요? 계정을 삭제하려면 어떻게 해야 하나요? 이러한 관계를 구축하는 데 도움이 되는 것 외에도 데이터를 처리하는 데 필요한 기간 동안만 데이터를 저장하고 그 이상은 저장하지 않는 것이 좋습니다. 또한 사용자가 개발자가 수집하거나 사용자를 대신하여 수집한 데이터를 확인하고 삭제할 수 있는 방법이 있어야 합니다. 자치령에서 이 사안에 대한 법률이 Google Cloud 서비스입니다
이 영역에서는 사용자가 셀프서비스에 도움이 되는 명확한 기술적 목표를 정의할 수 있습니다. 사용자가 권한을 요청하지 않고도 데이터 웨어하우스를 선택 해제할 수 있다면 선택하는 데 훨씬 더 편안함을 느낄 수 있으며, 이를 위해 지원 리소스가 필요하지 않습니다.
간편하고 기본적으로 선택 해제할 수 있는 기능의 중요성을 인식하는 것이 중요합니다. IAPP는 '신뢰와 인식을 구축하기 위해 기업은 모든 터치 포인트에서 시청자를 존중하고, 시청자의 니즈에 귀 기울이며, 그에 따라 대응하겠다는 사회적 계약에 동의하는 것으로 시작할 수 있습니다.'라고 말합니다. Nielsen Norman Group은 사용자가 '확장된 절차를 거치지 않고 원치 않는 작업을 종료할 수 있도록 명확하게 표시된 '긴급 탈출구'가 필요하다고 말합니다.' 모두가 알고 있으며, 구독하는 것이 구독 취소보다 간편합니다 그러나 Nielsen Norman에 따르면 사용자가 '자유감과 자신감을 키웁니다'. 학계 연구에서는 이를 뒷받침하며 취소 가능성'은 물론 '인터페이스를 통해 사용자가 어느 위치에서나 부여된 권한을 쉽게 취소할 수 있어야 합니다. 해지가 가능합니다. 사용자는 이러한 동의를 취소할 수 있어야 하며 이에 따라 리소스에 액세스할 수 있는 권한을 축소할 수 있어야 합니다. 할 수 있습니다." 예를 보려면 Yee 및 Iacono를 참고하세요.
데이터를 보관하는 기간과 보관해야 할 데이터는 조직마다 크게 다른 주제입니다. 몇 가지 공통적인 가이드라인이 있습니다
권장사항
여기서는 사용자가 계정(및 가능한 경우 관련 데이터)을 삭제하고 Clear-Site-Data 헤더를 사용하여 로그아웃 시 일시적이고 로컬에 저장된 데이터를 정기적으로(예: 로그아웃 시) 삭제할 수 있도록 허용하는 것이 좋습니다.
Clear-Site-Data 헤더를 제공하여 클라이언트 측 (쿠키에 관계없이)에 저장된 일부 또는 모든 사용자 데이터를 삭제합니다.
또는 브라우저 캐시에 저장된 위치(해당되는 경우)에 저장됩니다. Clear-Site-Data의 명백한 사용 사례는 사용자가 로그아웃할 때이지만 보안 사고 후에도 사용될 수 있습니다. 이를 통해 잠재적으로 손상된 계정에 클라이언트에 저장된 손상된 데이터의 잔여 트레이스가 없음을 확인할 수 있습니다.
Clear-Site-Data 지원을 추가하려면 사용자가 로그아웃할 때 (또는 다른 위치에서 로그아웃할 때) HTTP 헤더 Clear-Site-Data를 전송해야 합니다.
클라이언트 측 저장용량을 비우려는 횟수) 로그아웃 상태를 확인하는 페이지 (https://your-site/logout)
또는 이와 유사한 유형). 이 헤더는 다음 값 중 일부 또는 전부를 포함할 수 있으며, 모두 포함하는 경우 "*"입니다.
Clear-Site-Data: "cache", "cookies", "storage"
이러한 값은 각각 캐시된 페이지(및 기타 HTTP 캐시된 리소스), 저장된 쿠키, localStorage 및 IndexedDB 등을 삭제합니다.
다른 옵션인 executionContexts에 대한 참조가 표시될 수도 있지만 이 옵션은 대부분의 브라우저에서 지원되지 않습니다.
Clear-Site-Data 헤더를 사용하면 생성된 모든 리소스를 직접 개별적으로 삭제하는 것보다 쉽습니다. JavaScript 코드를 사용할 필요가 없기 때문입니다.
클라이언트에서 실행되지만 (브라우저 캐시를 지우는 유일한 공식 방법임) 모든 브라우저에서 지원되지는 않습니다.
사용 참고사항: Clear-Site-Data: cache를 전송하여 캐시를 삭제하는 경우 Clear-Site-Data 헤더는 실제 로그아웃 페이지가 아닌 페이지가 로드되는 다른 리소스에 전송되어야 합니다. 캐시가 크고 느린 컴퓨터에서는 캐시를 지우는 동안 페이지가 차단되어 탐색이 방해되기 때문입니다. 이 작업은 몇 분 정도 걸릴 수 있으며 사용자에게 불편을 줄 수 있습니다. 발생할 가능성은 낮지만 테스트하기 어렵기 때문에 이 점을 염두에 두는 것이 좋습니다.
데이터가 필요한 이유 설명
사용자와 서비스 간의 신뢰는 사용자의 장기적인 이용을 유도하므로 그 중요성이 여러 번 강조되었습니다. 또한 경쟁 우위를 제공합니다. 이러한 신뢰도를 높이는 한 가지 방법은 절차에 투명성을 적용하는 것입니다. 투명성을 높이는 좋은 방법은 데이터를 원하는 이유를 설명하는 것입니다. 이전에 배웠듯이 수집하는 각 항목에 대해 언제 해당 항목이 삭제되는지 생각해 보세요 이를 알기 위해서는 이 데이터가 필요한 이유, 답변을 찾기 위해 필요한 구체적인 질문, 데이터를 수집하여 내릴 결정을 알아야 합니다. 이 데이터가 필요한 이유를 알았다면 해당 사용자에게 설명하여 신뢰를 구축하는 데 도움이 됩니다. 개인정보처리방침에서 또는 계정에 관해 질문하는 경우 이 특정 질문에 대한 답변이 필요한 이유, 해당 데이터로 수행할 작업, 삭제할 수 있는 경우와 방법을 설명합니다.
이러한 설명은 인라인으로 제공할 때 훨씬 더 잘 볼 수 있습니다. 웹사이트의 다른 곳에서 밀집된 정책 문서에 설명을 묻음 숨기려는 시도처럼 보일 수 있습니다. 가입, 결제 또는 요청 양식에 수집과 함께 데이터를 수집하는 이유를 표시할 수 있습니다. 있습니다. 양식 필드에 필수 입력란임을 나타내는 별표(*)가 표시되는 경우가 많습니다. 복잡한 양식에는 필드의 의미를 설명하는 정보 링크(i)가 있는 경우가 많습니다. 데이터를 수집하는 이유에 관한 설명을 이러한 설명에 추가해 보세요. 자주 '이것이 왜 필요한가요?'라는 클릭하면 팝업 설명이 표시되는 양식 입력란 옆을 클릭합니다.
HTML 예시는 다음과 같을 수 있으며 CSS와 JavaScript는 <aside>를 숨기고 링크가 클릭될 때 팝업으로 표시합니다. 이때 사이트에서 만든 양식의 접근성을 확인하세요.
이를 배치하는 정확한 방법은 스타일과 접근 방식에 따라 다르지만, 여기서 요점은 데이터 수집을 직접 연관 짓는 것입니다.
해당 데이터가 수집되는 이유에 대한 설명 모든 필드에 이 속성이 필요한 것은 아닙니다. 가입 시 비밀번호를 선택해야 하는 이유를 설명할 필요는 없습니다. 그러나 개인 및 연락처 정보에 대한 각 요청을 어떻게 사용하고 보관할 것인지 다듬는 것이 도움이 될 수 있습니다.
여러분의 데이터를 보호하는 데 투자하고 있다는 사실을 사용자에게 분명히 밝히세요.
<div>
<label for="email">Email address*</label>
<input id="email" type="email" name="email" required aria-describedby="whyemail">
<a href="#whyemail">Why do we need this?</a>
<aside id="whyemail">We need this information as a unique identifier for you, and if you forget your password we can send you a reminder. We will use your email address to send you regular updates on the service if you choose, and will delete your email address from any mailing lists if you delete your account.</aside>
</div>
사용자에 대해 수집한 모든 정보를 가지고 이 프로세스를 거치는 것도 내부 프로세스와 논의에 도움이 될 수 있습니다. 앞서 '만약을 대비하여' 데이터를 수집하려는 유혹이 어떻게 나타나는지 살펴봤습니다. 이유를 투명하게 공개하는 경우 이런 일이 일어나고 있다는 것은 분명합니다. 원하는 것을 공개적으로 작성하기 어려우다면 사용자 데이터와 관련된 질문입니다 있습니다. 불쾌감을 주는 설명이 너무 침입적이거나('이 정보를 사용하여 방문한 위치를 시간별로 추적할 예정입니다'), 너무 광범위하거나('아직 이 정보를 어떻게 사용할지 모르지만 나중에 사용할 수 있도록 확보하고 싶습니다'), 너무 회피적이거나('이 정보를 내부 비공개 목적으로 사용할 예정입니다') 하는 경우에도 적용됩니다. 이는 단순히 도덕성의 문제가 아닙니다. 사람들은 이미 설명한 것처럼 이를 인식하고 있어야 하며, 사용자는 무언가를 실험하는 것이 시작이 아닐 것이라고 기대하고 있습니다. 장기적 약정이 있습니다 사용자 경험 설계의 일반적인 관행은 가입을 최대한 원활하고 쉽게 만드는 것입니다. 초기 단계에서는 사용자가 정의상 서비스에 많은 투자를 하지 않으므로 아직 투자 의향이 없는 상태에서 쉽게 더 많은 투자를 할 수 있도록 허용하는 것이 중요합니다. 다시 나가기가 쉽다면 서비스를 실험하는 것이 강제된 장기적인 노력의 시작이 아닌 실험이 됩니다. 앞서 언급했듯이 신뢰를 쌓는 가장 좋은 방법은 사용자가 원하지 않는 경우 사용자에게 신뢰를 강요하지 않는 것입니다. 모순적이지만 사실입니다.
사람들은 데이터를 공유하지 않거나 최소한의 데이터를 공유해야 할 합당한 이유가 있습니다. 고객과의 관계를 처음 시작할 때는 고객이 광고주를 신뢰할 이유가 없을 수 있으며, 신뢰할 필요도 없습니다. 여러분의 목표는 이들이 왜 효과적이어야 하는지를 보여주는 것입니다.
권장사항
- 수집하려는 모든 데이터에 대해 데이터가 필요한 이유와 보관 기간을 결정합니다.
- 해당 데이터를 요청할 때는 사용자에게 데이터를 수집하는 이유를 설명하세요.
- 사용한 후에는 서버 데이터베이스에서 삭제합니다.
- 사용자가
Clear-Site-Data헤더를 사용하여 자신이 만든 계정을 삭제하고 스토리지에서 저장된 데이터를 삭제하도록 허용합니다.
이유
사용자와의 관계 구축은 신뢰에 관한 것이며 신뢰는 개방성에 관한 것입니다. 당신이 할 수 없는 일을 보여줄 수 있다면 단지 사용자에 대해 가능한 한 많은 데이터를 수집하고 데이터의 용도를 숨기는 것이 신뢰를 쌓는 데 도움이 되며, 덜 양심적인 경쟁자에 비해 경쟁 우위를 점할 수 있습니다.