다음을 통해 공유

사용자 프라이버시

  • 아티클

 

메리 커틀랜드

Microsoft Corporation

2001년 2월 14일

마지막 열에서 Web Services 지침 팀의 첫 번째 샘플 프로젝트인 즐겨찾기 서비스에 대한 비전을 정의하는 방법에 대해 설명했습니다. 열 사이의 긴 지연에 대해 사과드립니다. 나는 불쾌한 감기와 함께 한 달의 더 나은 부분을 위해 밖으로 왔다. 앞으로 몇 달 동안 정기적인 주간 칼럼을 위해 상황이 다시 정상궤도에 오를 수 있기를 바랍니다.

요약하자면, 즐겨찾기 서비스의 목표는 사용자가 어떤 컴퓨터를 사용하든 관계없이 사용자가 이러한 애플리케이션을 통해 즐겨찾기에 액세스할 수 있도록 애플리케이션이 웹 사이트에 대한 최종 사용자의 즐겨찾기 링크를 안전하고 안전한 중앙 위치에 저장하는 방법을 제공하는 것입니다. 기술적인 관점에서 이것은 구현하는 매우 간단한 서비스처럼 보입니다. 기본적으로 특수 데이터 저장소일 뿐입니다.

즐겨찾기 서비스를 살펴보기 시작한 거의 동시에 사용자 개인 정보 보호에 대한 뉴스 기사, 특히 제3자가 웹 페이지의 광고를 통해 수집할 수 있는 정보에 대한 뉴스 기사가 급증했습니다. 이렇게 생각하게 됨: 전체 웹 서비스 모델은 타사 서비스를 사용하는 웹 페이지를 기반으로 하며, 최종 사용자에 대한 지식이 없을 가능성이 높습니다. 걱정해야 할 개인 정보 보호 문제가 있었습니까?

사용자 개인 정보에 대한 좋은 정의가 없더라도 제안된 즐겨찾기 서비스가 의심스러운 것처럼 보이는 몇 가지 가능한 시나리오를 마련할 수 있었습니다. 문제에 대한 초기 연구를 바탕으로 즐겨찾기 서비스를 단계적으로 구현하여 의심스러운 시나리오를 이후 단계로 연기하기로 결정했습니다. 이 칼럼에서는 초기 연구 중에 발견한 내용, 지연된 어려운 문제, 프로젝트의 1단계에 남아 있는 개인 정보 보호 문제, 이러한 문제가 설계 및 구현에 미치는 영향에 대해 설명합니다.

정의된 개인 정보

먼저 사용자 개인 정보 보호의 의미를 살펴보겠습니다. 사용자 개인 정보 보호 및 웹에 대한 논의에 초점을 맞출 것입니다. 웹을 사용할 때마다 사용 중인 애플리케이션(예: 웹 브라우저)과 애플리케이션이 연결된 웹 사이트(예: 브라우저에 표시되는 페이지) 간에 교환될 수 있는 세 가지 종류의 정보가 있습니다.

  • 작성한 전자 메일, 휴가 사진, 재무 기록 등과 같은 애플리케이션의 일부 조합을 사용하여 만드는 정보입니다.
  • 사용자에게 서비스를 제공하기 위해 애플리케이션에서 수집한 이름, 주소, 개인 관심사 등과 같은 사용자에 대한 정보입니다.
  • 서비스를 제공하기 위해 애플리케이션에서 수집한 IP 주소와 같이 사용 중인 컴퓨터 및/또는 네트워크 연결에 대한 정보입니다.

사용자 개인 정보 보호 문제는 이 정보를 수집, 사용 및 배포하는 방법입니다. 온라인 서점에서 책을 구입하는 경우 물론 서점이 주문을 완료하려면 이름, 주소 및 신용 카드 번호를 제공해야 합니다. 그러나 서점이 구입한 특정 책의 기록과 함께 이 정보를 데이터베이스에 덤프하면 어떨까요? 한편으로는 이 정보를 사용하여 좋아하는 저자가 새 책을 출판할 때 알리는 것과 같은 유용한 서비스를 제공할 수 있습니다. 다른 한편으로는, 그것은 당신의 개인 정보를 판매 할 수 있습니다, 원치 않는 정크 메일의 홍수의 결과. 사용하는 애플리케이션을 제공하는 회사에서 이 정보를 공정하게 사용하는 것은 무엇인가요?

안타깝게도 이 질문에 대한 한 가지 대답이 없습니다. 옳은 일은 특히 대중의 인식과 정부 규정이 유동적이기 때문에 결정하기가 어렵습니다 (그리고 법적 관할권마다 다를 수 있음). 현재 웹 사이트에 대한 표준 사례는 수집되는 정보와 사용 및 배포 방법을 사용자에게 알리는 개인 정보 취급 방침을 게시하는 것입니다. 그러나 정보를 수집하기 전에 또는 사용자가 웹 사이트에 액세스하기 전에 사용자가 개인 정보 취급 방침을 읽어야 하는지 여부에 대한 표준은 없습니다.

Web Services에서는 상황이 더욱 불확실해집니다. 최종 사용자는 웹 서비스가 사용되고 있다는 사실을 알지 못할 수도 있습니다. 웹 서비스가 특정 최종 사용자(개인 식별 정보라고 함)에 연결할 수 있는 정보를 수집하는 경우 서비스 공급자는 수집되는 정보와 사용 또는 배포 방법에 대해 사용자에게 어떻게 알릴 수 있나요? 웹 서비스에 개인 정보를 배포하는 애플리케이션은 최종 사용자에게 이를 공개해야 합니까? 전통적으로 기업은 비즈니스 프로세스의 특정 측면을 아웃소싱한다고 공개하지 않았습니다. 예를 들어 주문 이행 회사와 고객 지원 organization 모두 고객에 대한 개인 정보에 액세스할 수 있지만 회사에서 주문 이행 또는 고객 지원이 아웃소싱되었다고 공개하지 않을 수 있습니다. 그러나 규칙은 온라인에서 다를 수 있습니다. 시간만 알 수 있습니다...

공정한 정보 관행

공정한 정보 관행은 고객에게 자신의 개인 정보를 알리고 제어할 수 있도록 합니다. 이러한 정보는 원치 않는 사용, 액세스 또는 배포로부터 보호되므로 고객은 회사의 제품을 사용할 때 확신하고 만족할 수 있습니다. 즐겨찾기 서비스에 대한 사용자 개인 정보 보호의 의미를 이해하는 첫 번째 단계는 Microsoft의 공정한 정보 관행을 읽는 것이었습니다. Microsoft의 회사 개인 정보 그룹은 공정한 정보 관행의 다섯 가지 요소를 정의합니다.

  • 알림. 회사는 개인 정보의 수집, 사용 및 배포에 대한 명확한 정책을 정의해야 합니다. 이 정책에는 데이터의 기본 및 보조 사용, 회사 내 사업부 간 데이터 배포, 계열사 및 비계열 기업과의 데이터 공유, 비즈니스 거래를 지원하는 공급업체와의 계약 의무 등이 포함되어야 합니다. 회사는 변경 전에 수집된 데이터에 대한 정책 변경 및 변경 내용의 영향에 대한 지침을 수립해야 합니다. 법률 고문과 협력하여 정책이 웹 사이트 및 웹 서비스에서 적용할 수 있는지 확인하려고 합니다. 온라인 및 오프라인을 비롯한 여러 배포 채널을 통해 고객과 사용자가 정책을 사용할 수 있도록 합니다.
  • 동의. 사용자가 데이터 수집, 사용 및 배포에 대한 기본 설정을 관리할 수 있는 유연하고 액세스 가능한 메커니즘을 제공해야 합니다. 사용자가 동의한 내용을 파악하고 사용자가 기본 설정을 하는 데 너무 오래 걸리지 않도록 정보를 합리적이고 의미 있는 그룹으로 분류해야 합니다. 사용자 기본 설정의 기본값을 고려해야 합니다. 사용자가 개인 정보의 특정 사용을 명시적으로 사용하도록 설정하거나(옵트인이라고 함) 사용을 명시적으로 사용하지 않도록 설정해야 합니까(옵트아웃이라고 함)?
  • 액세스. 사용자는 저장한 개인 정보를 보고/또는 편집하여 최신 상태로 유지하고 사용 기본 설정을 관리할 수 있어야 합니다. 사용자가 편집할 수 있는 정보와 볼 수 있는 정보만 파악해야 합니다. 예를 들어 사용자는 고유한 사용자 식별자를 편집할 수 없지만 암호를 편집할 수 있습니다. 이상적으로 개인 정보를 관리하는 도구는 온라인 및 오프라인 사용자가 모두 사용할 수 있습니다.
  • 보안. 사용자의 개인 정보를 보호하기 위해 적절한 보안 조치를 구현해야 합니다. 여기에는 저장된 데이터에 대한 액세스를 보호하는 인증 및 권한 부여 메커니즘이 포함됩니다. 또한 컴퓨터 간에 전송하는 동안 데이터를 보호하는 메커니즘이 포함될 수 있습니다. 보안 조치는 정보의 민감도에 비례해야 합니다. 예를 들어 사용자의 은행 계좌 또는 의료 기록으로 작업하는 경우 자신이 가장 좋아하는 저자 목록으로 작업하는 경우보다 보안에 대해 훨씬 더 걱정할 수 있습니다.
  • 적용. 당신이 그것을 따르지 않는 경우 개인 정보 보호 정책을 가지고 어떤 좋은 일을하지 않습니다. 회사는 개인 정보 보호 정책을 준수하기 위해 정보 시스템을 모니터링하기 위한 절차를 정의하고 따라야 합니다. 모든 고객 정보 서비스에 대한 분쟁 해결 프로세스를 정의하고 타사 인증 조직과의 안전한 항구 관계를 유지 관리합니다. 적용은 주로 웹 사이트 또는 웹 서비스 자체 외부에 있지만 적용 프로세스를 지원하기 위해 어떤 종류의 감사 정보를 유지해야 하는지 고려해야 합니다. 예를 들어 사용자가 개인 정보 취급 방침을 읽었는지 여부와 시기, 사용자가 사용자 기본 설정을 수정한 시기 및 방법을 추적할 수 있습니다.

공정한 정보 관행 및 즐겨찾기

이 모든 것이 이론적으로 합리적으로 들렸지만, 이것이 웹 서비스에 어떻게 적용되었는지, 또는 웹 서비스에 대해 이러한 모든 요소를 일반적으로 구현하는 방법은 아직 완전히 명확하지 않았습니다. 그래서 저는 몇 시간 동안 기업 정책 그룹의 구성원과 문제를 논의했습니다. 즐겨찾기 서비스가 잠재적으로 사용하도록 설정할 수 있는 시나리오 목록(초기 비전 설명에 따라)으로 시작했습니다.

  1. 사용자가 인터넷 Explorer 즐겨찾기 등의 메뉴 옵션 집합을 제공하는 인터넷 Explorer 일부 추가 기능을 설치합니다. 단, 즐겨찾기에는 실제로 coldrooster.com 저장됩니다. (마지막 열을 읽는 경우 컨설팅 회사를 중심으로 비즈니스 시나리오를 정의했음을 알 수 있습니다. 우리는 이제이 가상의 컨설팅 회사의 이름이 콜드 수탉 컨설팅임을 알 수 있습니다, 마이크로 소프트 캠퍼스에 우리의 건물 주위에 매달려있다 수탉의 명예. 따라서 coldrooster.com.)
  2. Coldrooster.com 사용자가 즐겨찾기를 관리할 수 있는 웹 애플리케이션을 제공합니다.
  3. 웹 사이트(예: msdn.microsoft.com)는 사용자가 클릭하여 coldrooster.com 저장된 사용자의 즐겨찾기에 해당 페이지를 추가할 수 있는 각 페이지에 단추를 제공합니다.
  4. Msdn.microsoft.com 사용자 대신 msdn.microsoft.com 원래 저장한 사용자의 즐겨찾기를 표시하는 웹 페이지를 제공합니다.
  5. Msdn.microsoft.com 사용자가 사용자를 대신하여 msdn.microsoft.com 원래 저장한 즐겨찾기를 관리할 수 있는 웹 애플리케이션을 제공합니다.
  6. 콜드 수탉 컨설팅은 저장된 모든 즐겨찾기를 주기적으로 가져와서 특정 사용자에게 다시 연결하는 모든 정보를 제거하고 분석을 위해 별도의 데이터베이스에 덤프합니다.
  7. Msdn.microsoft.com 원래 사용자를 대신하여 즐겨찾기를 저장한 웹 사이트에 관계없이 사용자가 저장한 모든 즐겨찾기를 표시하는 웹 페이지를 제공합니다.
  8. Msdn.microsoft.com 사용자가 즐겨찾기를 모두 관리할 수 있는 웹 애플리케이션을 제공합니다.
  9. 콜드 수탉 컨설팅은 msdn.microsoft.com 라이선스를 부여할 수 있는 별도의 웹 서비스를 제공합니다. 이 서비스를 통해 라이선스 사용자는 "즐겨찾기 즐겨찾기" 또는 "이 페이지를 저장한 사용자도 이 페이지를 저장했습니다"와 같은 정보를 검색할 수 있지만 msdn.microsoft.com 도메인에 대해서만 검색할 수 있습니다.
  10. 콜드 수탉 컨설팅은 시나리오 9에 설명된 웹 서비스를 제공합니다. 단, msdn.microsoft.com 반환되는 권장 사항에는 다른 도메인의 즐겨찾기를 포함할 수 있습니다.

모든 응용 프로그램 및 컴퓨터를 통해 사용자의 즐겨찾기를 사용할 수 있도록 하려면 사용자의 즐겨찾기를 전자 메일 주소 또는 Microsoft Passport 식별자와 같은 개인 식별자에 연결해야 하므로 사용자 즐겨찾기 데이터는 개인 식별 정보의 범주에 속합니다. 즐겨찾기 서비스의 이 정의를 고수하는 경우 정책, 절차 및 코드의 조합을 통해 공정한 정보 관행을 구현해야 합니다.

논의 당시에는 사용자를 대신하여 정보를 저장하기 전에 사용자에게 알려야 하는 법률이 없었습니다. 따라서 coldrooster.com 개인 정보 취급 방침을 게시하여 알림 요소를 구현할 수 있습니다. 사용자가 정책을 읽어야 한다는 것을 어떻게 알 수 있나요? 두 가지 옵션을 마련했습니다. 즉, 사용자가 서비스를 통해 즐겨찾기를 저장하기 전에 coldrooster.com 등록해야 하거나, 클라이언트 애플리케이션에서 콜드 수탉 컨설팅 즐겨찾기 서비스가 사용되고 있음을 사용자에게 알리고 개인 정보 보호 정책에 대한 포인터를 제공해야 합니다.

보안 관점에서 사용자 즐겨찾기 는 의료 기록과 동일한 범주에 속하지 않지만 사용자는 여전히 액세스할 수 있는 사용자를 제어하려고 합니다. 예를 들어 홈 머신에 저장한 즐겨찾기를 살펴보면 지원되는 스포츠 팀, 읽고 싶은 책의 종류, 듣고 싶은 음악 종류, 은행 계좌가 있는 곳, 전 세계 모든 사람이 액세스하기를 원하는 정보가 아닌 내 은행 계좌를 찾을 수 있습니다. 그리고 누군가가 내 즐겨 찾기를 수정 할 수 있다면, 그들은 내가 선택한 링크를 다른 사이트 (기밀 정보 가로채기와 같은 사악한 목적을 위해)로 바꾸거나 즐겨 찾기에 새로운 링크를 추가 할 수 있습니다. 따라서 사용자 즐겨찾기에 대한 액세스를 안전하게 보호하려고 합니다. 사용자가 즐겨찾기를 읽거나 쓸 수 있는 애플리케이션을 지정하도록 할 수 있습니다. 예를 들어 MSDN이 msdn.microsoft.com 도메인에 대한 즐겨찾기를 수정하도록 할 수 있지만 MSDN에서 즐겨찾기 스포츠 팀의 링크도 표시하지 않도록 할 수 있습니다. MSDN이 이러한 항목에 관심을 가져야 하는 이유는 무엇인가요?

사용자가 즐겨찾기를 읽거나 쓸 수 있는 애플리케이션을 제어할 수 있도록 하려면 공정한 정보 관행의 동의 및 액세스 요소를 구현해야 합니다. 또한 적용 요소를 지원하기 위해 감사 코드를 구현하려고 할 것입니다.

갑자기 우리의 간단한 작은 웹 서비스는 그렇게 간단 소리하지 않습니다! 사용자에게 어떤 수준의 제어를 제공해야 하나요? 각 도메인에서 즐겨찾기를 읽거나 쓸 수 있는 애플리케이션을 정확히 지정하도록 해야 하나요? 또는 구성을 간소화하기 위해 애플리케이션 및 도메인을 영역으로 그룹화해야 하나요? 그리고 위에 나열된 시나리오 중 기본적으로 사용하도록 설정해야 하는 시나리오는 무엇인가요?

개인 정보 보호 전문가는 시나리오 1 - 5에 대한 우려가 없었습니다. 일반적인 개인 정보 보호 정책은 이러한 시나리오를 다룹니다. 그러나 시나리오 2의 경우 사용자의 즐겨찾기를 저장한 애플리케이션 또는 Cold Rooster Consulting의 애플리케이션이 추가한 즐겨찾기에 관계없이 coldrooster.com 사용자의 모든 즐겨찾기를 관리할 수 있는지 여부를 고려해야 합니다. 사용자가 사용자를 대신하여 저장된 모든 즐겨찾기를 보거나 편집하는 데 앱을 사용할 수 있음을 명시적으로 지정하지 않는 한 콜드 수탉 컨설팅의 애플리케이션은 해당 앱을 통해 추가된 사용자 즐겨찾기만 관리할 수 있다고 말할 수 있습니다.

개인 정보 취급 방침이 추가 분석을 위해 저장된 사용자 즐겨찾기를 사용할 수 있음을 나타내는 한 시나리오 6조차도 너무 많은 문제가 되지 않습니다. 다시 말하지만, 데이터를 분석하기 전에 도메인 또는 원래 데이터를 제공한 애플리케이션에 의해 데이터를 분할해야 하는지 여부를 고려해야 합니다. 그리고 많은 사람들이 데이터 프로파일링을 경계하기 때문에 사용자가 분석에 사용되는 풀링된 데이터에 즐겨찾기를 포함하는 것을 옵트아웃할 수 있는 기능을 제공할 수 있습니다.

나머지 시나리오는 개인 정보 관점에서 점점 더 받아쓰기됩니다. 즉, 구현해서는 안 된다는 것을 말하는 것이 아니라 정확하면서도 이해할 수 있는 정책 문을 작성하는 것이 더 어렵고 사용자가 시나리오에 익숙하지 않을 수 있으므로 기본적으로 사용하지 않도록 설정해야 합니다(사용자가 옵트인해야 함).

시나리오 7은 처음에는 무해한 것처럼 들리지만 웹 서비스 관점에서 실제로 의미하는 바는 애플리케이션이 즐겨찾기 서비스에서 사용자의 모든 즐겨찾기 복사본을 가져올 수 있다는 것입니다. 애플리케이션에 데이터 복사본이 있으면 원하는 대로 수행할 수 있습니다. 이 시나리오를 지원하는 웹 서비스를 제공하는 경우 최소한의 기준을 충족하는 개인 정보 보호 정책을 사용하여 알려진 클라이언트로 웹 서비스에 대한 액세스를 제한하려고 할 것입니다.

시나리오 8은 훨씬 더 문제가 됩니다. 애플리케이션에서 사용자의 즐겨찾기를 수정할 수 있게 되면 애플리케이션이 사용자의 목록에 임의의 페이지를 추가하거나 경쟁사의 사이트를 가리키는 즐겨찾기를 삭제하지 못하도록 하는 것은 무엇인가요? 즉, 웹 서비스는 최종 사용자를 대신하여 애플리케이션에서 수행한 유효한 서비스 요청을 최종 사용자가 인식하지 못하는 애플리케이션의 서비스 요청과 어떻게 구별할 수 있나요? HTTP 및 XML에서 작동하는 사용 가능한 보안 메커니즘은 이러한 종류의 클라이언트/서버/서비스 시나리오를 직접 지원하지 않습니다. 일부 사용자 지정 보안 솔루션을 구현해야 합니다. 사용자 지정 보안 메커니즘을 사용하더라도 사용자가 즐겨찾기를 편집할 수 있는 애플리케이션을 지정할 수 있는 방법을 제공하는 데 추가 작업이 필요할 수 있습니다.

마지막으로 시나리오 9와 10은 시나리오 6보다 온라인 프로파일링 영역으로 더 많이 이동합니다. 기술적인 문제는 이미 언급된 것과 다르지 않지만 사용자 불편 수준은 더 높을 것입니다.

이 시나리오 분석을 바탕으로 즐겨찾기 서비스의 초기 제공에 대한 비전을 다시 생각해 보기로 결정했습니다. 1단계에 대한 새로운 비전은 위의 시나리오 3-5에 중점을 둡니다. 기본적으로 각 애플리케이션에는 사용자 즐겨찾기를 위한 자체 프라이빗 저장소가 있습니다. msdn.microsoft.com 이동하여 이 열에 대한 링크를 저장하는 경우 msdn.microsoft.com 제공하는 사용자 인터페이스를 통해서만 해당 링크를 보거나 편집할 수 있습니다.

이 방법은 몇 가지 어려운 문제를 제거합니다. 실제로 사용자 즐겨찾기에 관련된 전체 사용자 개인 정보 보호 문제가 제거됩니다. 즐겨찾기 서비스를 사용하는 각 애플리케이션에는 별도의 사용자 즐겨찾기 저장소가 있으므로 즐겨찾기 서비스에서 이해하는 전역 사용자 식별 체계가 필요하지 않습니다. 각 애플리케이션은 원하는 식별자를 사용할 수 있습니다. 즐겨찾기 서비스는 이러한 식별자를 해석하거나 다른 애플리케이션에 의해 저장된 정보의 상관 관계를 지정하는 방법이 없습니다. 데이터는 단일 애플리케이션(또는 더 정확하게는 Favorites Service의 단일 라이선스 사용자)에서만 액세스할 수 있으므로 사용자가 다양한 시나리오를 옵트인하거나 옵트아웃할 수 있는 방법을 제공하는 것에 대해 걱정할 필요가 없습니다. 사용자 개인 정보 보호 문제를 호출 애플리케이션에 효과적으로 위임했습니다.

이는 위의 시나리오 분석에서 제기된 기술적 과제를 해결하는 데 관심이 없다는 것을 말하는 것이 아닙니다. 즐겨찾기 서비스의 향후 단계에서 이러한 문제를 해결하려고 합니다. 좀 더 시간을 내어 개발자 커뮤니티에 추천할 수 있는 솔루션을 마련하려고 합니다.

그렇다면 오늘 문제를 해결해야 한다면 어떨까요? 사용자와 애플리케이션 모두에 대한 라이선스 메커니즘을 구현하는 방법을 볼 수 없습니다. 사용자는 서비스에 계정에 등록해야 합니다. 즉, 사용자가 개인 정보 취급 방침을 읽고, 계정에 등록하고, 기본 설정을 관리할 수 있는 웹 사이트가 있습니다. 애플리케이션을 개발하는 회사도 웹 서비스를 사용하기 위해 라이선스에 등록해야 합니다. 사용권 계약은 라이선스 사용자가 웹 서비스 사용에 대해 사용자에게 알리는 방법을 지정해야 합니다. 라이선스를 신뢰하여 웹 서비스만 적절하게 사용할 수 있는지 여부를 파악해야 합니다. 그렇다면 웹 사이트에서 사용자 자격 증명을 수집하고 웹 서비스에 전달할 수 있습니다. 그렇지 않은 경우 라이선스 사용자가 사용자 자격 증명을 검색하고 웹 서비스에 전달하는 보안 메커니즘을 제공하는 데 사용할 수 있는 몇 가지 코드를 제공해야 합니다. 어느 쪽이든, 상당한 양의 작업이 관련될 것입니다.

나머지 개인 정보 문제

1단계의 사용자 즐겨찾기에 대해 사용자 개인 정보에 대해 걱정할 필요는 없지만 여전히 고려해야 할 몇 가지 개인 정보 보호 문제가 있습니다. 즐겨찾기 서비스에 대한 액세스 권한을 부여하기로 결정했습니다. 즉, 라이선스 사용자에 대한 일부 연락처 정보를 유지 관리해야 합니다. 해당 정보는 개인 식별 정보의 범주에 속합니다. 따라서 계정 정보를 유지하는 모든 애플리케이션이 직면하는 표준 개인 정보 보호 문제가 있습니다.

정책 및 코드 조합을 사용하여 이러한 문제를 해결했습니다. 다음 다이어그램은 시스템 아키텍처를 개략적으로 볼 수 있습니다.

그림 1. 1단계의 즐겨찾기 서비스 아키텍처

이 서비스는 계층화된 아키텍처로 구현되며 웹 팜과 데이터 클러스터의 두 물리적 계층에 배포됩니다. 라이선스 계정 정보는 데이터 클러스터의 데이터베이스에 저장됩니다. 라이선스가 계정 정보를 관리하는 웹 서비스 및 웹 사이트는 웹 팜에 배포됩니다. 사용이 허가된 정보에 대한 몇 가지 보호 계층이 있습니다.

  • 콜드 수탉 컨설팅 외부의 컴퓨터에서는 데이터 클러스터에 액세스할 수 없습니다.
  • 즐겨찾기 서비스는 사용이 허가된 연락처 정보에 액세스할 필요가 없으므로 로그온 구성 요소를 사용하여 라이선스를 인증합니다. 로그온 구성 요소는 필요한 정보만 검색합니다.
  • 반면에 라이선스 관리 웹 사이트는 사용이 허가된 연락처 정보에 액세스해야 합니다. 라이선스 사용자가 데이터를 편집할 수 있는 다른 방법은 무엇입니까? 웹 사이트는 라이선스 구성 요소를 통해 모든 데이터 액세스를 수행합니다. 라이선스 구성 요소의 액세스 제어는 라이선스 관리 웹 사이트 이외의 다른 항목이 구성 요소를 호출하지 못하도록 합니다.
  • 라이선스 데이터베이스의 액세스 제어는 로그온 구성 요소 및 라이선스 구성 요소 이외의 다른 항목이 데이터베이스에 액세스하는 것을 방지합니다.
  • 연락처 정보가 수정될 때마다 연락처 정보에 지정된 주소로 확인 전자 메일이 전송됩니다.

순 효과: 라이선스 사용자의 식별자와 암호가 손상되지 않는 한 권한이 없는 사용자가 라이선스 사용자 연락처 정보에 액세스하거나 수정하기가 매우 어려워야 합니다. 이러한 상황에서도 누군가가 연락처 정보를 변경하려고 하면 현재 연락처에 알릴 수 있습니다.

또한 웹 사이트에 개인 정보 취급 방침을 게시합니다. 즐겨찾기 서비스를 사용하는 애플리케이션을 작성하는 방법에 대한 설명서와 같이 새 라이선스 사용자에게 제공하는 다른 설명서와 함께 개인 정보 취급 방침을 제공할 수도 있습니다.

결론

사용자 개인 정보 보호는 웹 서비스 개발자와 이를 사용하는 애플리케이션에 대한 가시적인 문제입니다. 즐겨찾기 서비스에 대한 문제를 분석한 후 서비스에 대한 전체 목표를 재고하게 되었습니다. scope 줄었음에도 불구하고 사용자 정보가 부적절한 사용으로부터 보호되도록 하기 위해 상당한 수의 요구 사항이 추가되었습니다. 가장 중요한 요구 사항은 사용이 허가된 애플리케이션에 대한 액세스를 제한해야 한다는 것이었습니다. 다음 주에는 우리가 고려한 비즈니스 모델, 선택한 모델, 모델이 디자인 및 구현에 미치는 영향 등 라이선스에 대해 자세히 살펴보겠습니다.

웹 서비스에서 개인 식별 정보를 유지 관리해야 하는 경우 서비스의 핵심 기능을 구현하는 것 외에 많은 작업을 수행해야 합니다. 공지, 동의, 액세스, 보안, 적용 등 공정한 정보 관행의 다섯 가지 요소를 모두 해결해야 합니다. 사용자와 직접 해결해야 하는 시기와 웹 서비스를 사용하여 애플리케이션에 대한 개인 정보 문제를 연기할 수 있는 시기를 결정해야 합니다. 사용자가 어디에 있든지 사용자 개인 정보 보호법과 관련하여 최신 상태인지 확인하기 위해 이러한 문제에 대한 토론에 법률 고문과 참여하는 것이 좋습니다. 다음 리소스는 사용자 개인 정보에 대한 추가 정보를 제공합니다.