이 간단한 소프트웨어 보호 스키마에 대해 의견을주십시오.

Question

Google 제품에 대한 라이선스 스키마를 구현하도록 요청 받았습니다. 그것들은 매우 비싼 제품으로 전세계에 희소하게 분포 된 고객이 거의 없으며 기본적으로 이들 모두는 디자인 환경 (단일 Windows 시스템에 설치된 Windows 애플리케이션, 고객 당 1 ~ 150 대의 클라이언트 시스템)과 프로덕션 환경을 호스팅하는 웹 서버 (고객 당 1 ~ 8 대의 기계). 당사의 제품은 서버 사용에 대한 라이센스를 보유하고 있으므로 고객은 여러 클라이언트를 사용할 수 있습니다. 우리는 SLA 계약의 적용을 받기 때문에 서버 부분을 라이센스하지 않기로 결정했지만 클라이언트 만 사용할 수없는 시간이 지나면 기본적으로 시스템이 쓸모 없게되기 때문에 클라이언트 만 라이센스하기로 결정했습니다.

우리의 기본 가정은 고객이 "정직하게"충분하고 시간 만료 라이센스로 적절하게 라이센스되지 않은 경우 클라이언트 설계 환경을 중지하는 것입니다. ,

• 이 라이센스는 간단한 서명 XML 파일이어야합니다

  나는 다른 라이선스 제품을 평가 한 그들은 너무 비싸거나 관리하기가 너무 어렵거나, 그래서 나는이 간단한 해결책을 마련했습니다 w3c의 표준 XML 서명 기능을 사용하여 서명하고, USB 키로 관리 부서에 전달할 개인 키를 사용합니다. 그들이 사본의 잃으면 그 다음 라이센스 스키마는 실패하지만 자신의 잘못이 될 것입니다

• 시작시 라이센스 파일을 열고 라이센스 XML이 유효하면 바이너리
• 에 포함 된 공개 키를 사용하여 유효성을 확인합니다 클라이언트 그 안에있는 데이터 (유효 기간 및 제품명)는 설계자의 작업보다 정확합니다. 그렇지 않은 경우 적절한 메시지가 표시됩니다.

시나리오에 대한 아이디어가 있습니까?

Answer 1

나는 충분한 관심이 있었다면 몇 주 안에 부러지지 않은 라이센스 체계를 아직 보지 못했다. 당신의 계획은 아주 좋아 보인다. (누군가가 정말로 원한다면, 그것을 깨뜨릴 것이다.

무슨 일이 있어도, 당신은 따라야 에릭 싱크의 advice :

목표는 단순히 "정직 정직한 사람을 유지"하기위한 것이어야한다. 우리는 이보다 더 갈 경우, 두 가지 일이 :

1. 우리는 우리가 이길 수없는 싸움을. 속임수를 쓰고 자하는 사람들은 성공할 것입니다.
2. 사용하기가 더 어려워서 정직한 사용자를 다치게합니다. 당신이 회사의 사용을 위해 설계된 프로그램에 대한 라이센스 방식을 구현하고 있기 때문에

, 당신도 간단 가서 바로 클라이언트에 간단한 서명과 함께 ID와 유효 기간 어떤 종류의 유지에 거부 할 수 있습니다 라이센스가 만료되었거나 서명이 실패하면 시작하십시오. 라이센스를 없애기가 그렇게 어렵지는 않지만 라이센스 체계가 없기 때문에 고객을 정직하게 생각하면 충분합니다.

Answer 2

당신의 계획이 어떻게 작동하는지 궁금하지 않습니다. 클라이언트 소프트웨어의 모든 인스턴스마다 다른 키가 있습니까? 면허는 얼마 동안 지속됩니까? 고객마다 다른 키가 있습니까? 라이선스 비용은 어떻게 지불됩니까? 면허증은 어떻게 갱신됩니까?

클라이언트 코드의 사용 횟수를 제어하려는 경우 위의 첫 번째 코드 만 사용하면됩니다.

세상에서 당신이 살고있는 것처럼 보입니다. 나는 당신이 당신의 면허증에 뻔뻔스러운 침해가 없다는 것을 신뢰해야한다고 생각합니다. 대부분의 알맞은 규모의 조직 (고객처럼 보일 것입니다)은 라이센스 계약을 위반할 경우 심각한 결과를 초래할 수있는 침해하지 않는 책임이 있습니다. 그들은 주기적으로 감사를 받게되며 사용권을 확인하고 사용권을 확인하는 법적 권리가있을 수 있습니다 (사용권 동의서에 기재하지 않을 경우).

USB 키의 내용이 웹에있는 경우 매우 위험합니다. 이와 관련하여 게시 된 키를 사용하는 모든 구성표는 기밀 정보의 고의적 공개에 취약합니다.

나는이 주제에 관한 많은 문헌이 있으므로, 연구를 계속 해보는 것이 가치가 있다고 생각합니다.

BTW 서버 라이센스에 관한 중간 부분의 SLA에 대한 귀하의 참조가 확실하지 않습니다. 라이센스 및 SLA는 매우 다릅니다. 라이센스는 SLA가 귀하의 의무 인 클라이언트의 의무입니다.

Answer 3

개인 키를 부여하면 추가 라이센스를 구매하는 대신 서명 된 XML 파일을 더 이상 만들지 못하게하려면 어떻게해야합니까? 또는 사이트 라이센스입니까? 후자의 경우 다른 사람/사이트에 대한 라이선스를 만들지 못하게하려면 어떻게해야합니까? 일반

개발 라이센스 방식이

(보통 하드웨어 정보 단지 해쉬이다) 단지 활성화 키 종종 MAC 주소 및/또는 하드 드라이브의 일련 번호를 사용하거나 특정 시스템에 라이센스를 묶어

그리고 일반적으로 인코딩은 비밀로 유지하는 개인 키로 이루어지며 라이센스는 공개 키로 확인됩니다. 클라이언트는 결코 개인 키를 갖지 않을 것입니다. 그렇지 않으면 자신이 라이센스를 생성 할 수 있습니다.

Answer 4

나는 Steven A. Lowe (나는 15 명의 평판이 없어서 투표 할 수 없었습니다)에 동의합니다.

이것은 또한 너무 복잡해 보입니다. 당신은 그것이 깨지지 않기를 바랍니까? 당신은 할 수 없습니다. 충분히 동기를 부여받은 전문가라면 누구나 그 길을 찾을 수 있습니다.

때때로 간단한 라이선스 방식은 가장 잘 작동합니다

나는 관리자가 어딘가 클라이언트가 액세스 할 수있는 두는 간단한 암호화 된 파일을 제안 - 그것은 클라이언트의 이름과 유효 기간을 포함 할 것이다. 모든 인쇄 된 보고서 (대부분 PHBs에 관심이있는 사람, 다른 사람의 이름을 인쇄하는 라이센스를 사용하지 않는 것)에서 파일의 클라이언트 이름을 사용합니다.