Excel 워크북의 코드 보호?

Excel 워크북의 코드 보호?

저는 독점 공식과 기타 지적 재산권이 포함된 Excel 워크북을 제작하고 싶습니다.이 워크북은 Visual Studio 2010에서 C#으로 제작할 예정입니다.

이러한 프로젝트 내에서 코드는 얼마나 보호됩니까?C# 반영과 관련된 동일한 문제가 이 워크북 프로젝트에도 적용됩니까?그렇다면 이러한 유형의 워크북에 대한 난독화 도구가 있습니까?

이 질문에 추가하기 위해 - 좋은 '올레 VBA'는 어떻습니까?만약 우리가 VBA 경로로 간다면 그 코드도 보호할 방법이 있습니까?

다른 답변에서 알 수 있듯이 Excel 2003(.xls)의 VBA 보안에는 결함이 있습니다. 암호는 대부분 개발자 자신이 사용하지 않는 것보다 약간 번거로울 뿐입니다.IMHO Excel 2007+(.xlsx)의 VBA 보안이 훨씬 우수하더라도 VSTO를 사용하는 것이 훨씬 좋습니다. 몇 세기 동안 개선되지 않은 VBA IDE는 말할 것도 없습니다(적절한 VBE 추가 기능을 사용하면 그렇지 않습니다...).

해결책은 VSTO 프로젝트에서 호출하는 별도의 라이브러리에 적절한 코드를 작성하는 것일 수 있습니다. 복잡한 수식 대신 "블랙박스"(즉, 수식 기능의 추상화)로 나타나는 함수를 노출할 수 있습니다. 소스 코드가 없으면 구현 방법을 사용할 수 없습니다.그리고 DLL이 없으면 워크북을 계산할 수 없습니다.#NAME?도처에)

를 들어, 예들어에 에 신대를.=some proprietary formula returning a Smurf사용자는 볼 수 있습니다.=Smurf(SomeTableColumnName, SomeRangeName, SomeRangeReference, SomeCellReference)물론 성능 비용이 많이 들기 때문에 보호해야 할 중요한 사항에 대해서만 이 작업을 수행할 것입니다.

이러한 온사이드 라이브러리에서 독점 공식을 추출하는 사용자는 Alt+F11과 사이에는 상당한 단계가 있습니다. 독점 코드는 다른 .net 어셈블리와 마찬가지로 "보호"됩니다.

갱신하다

타사 라이브러리를 사용하지 않더라도 독점 코드에 Excel 상호 운용성이 필요하지 않은 경우 VBA에서 함수를 생성하고(즉, Excel 인터op 부분을 Excel 내에 남김) 원시 유형만 통과하는 것이 더 나은 솔루션일 수 있습니다(VBA).Integer=> => .netInt16 VBALong=> => .netInt32문자열 등)은 Excel interop을 사용할 필요도 없는 COM 가시성 라이브러리에 대한 것으로, Excel interop 대신 COM interop이 될 것이며 성능 히트는 상당히 감소할 것입니다(관리되지 않는 COM에 .net 관리 코드 "대화 중"으로 남아 있음).

VBA 코드의 역할은 워크시트에서 읽고 쓰는 것이고, COM 가시 라이브러리의 역할은 VBA 코드가 전달하는 값으로 계산할 수 있는 것입니다. 물론 VBA 코드는 사용자가 쉽게 액세스할 수 있지만(Alt+F11) 실제 계산 구현에는 액세스할 수 없습니다.보호될 수 , 는 "VBA" "VBA" "DLL" "DLC" 중 가 될 입니다.0의 또는#VALUE!VBA 코드가 구현되는 방식에 따라 달라집니다.

핵심은 Excel에 Excel 사양을 남겨 두고 .net 라이브러리가 Excel 인터op 어셈블리를 참조하지 않고 선택할 수 있는 곳에서 .net 라이브러리를 선택하도록 하는 것입니다. 예를 들어, VBA 함수는 셀 참조를 가져와서 값을 가져와서 .net 어셈블리로 전달합니다(아마도 유효성 검사). 이 경우 VBA가 Excel에 반환할 다른 원시 유형을 반환합니다.

또 다른 장점은 Excel 워크북을 웹 애플리케이션으로 "변환"할 경우 전용 계산이 포함된 라이브러리 코드를 재사용할 수 있다는 것입니다.

향후 참조를 위해 정확한 문제를 해결하는 데 도움이 되는 새로운 혁신적인 제품 2개를 소개합니다.

https://HiveLink.io : - HiveLink를 사용하여 사용자에게 제공하는 스프레드시트의 "경량" 버전을 만들 수 있지만 중요한 VBA 또는 계산 공식은 포함되어 있지 않습니다.경량 스프레드시트에서 지적 재산을 제거하고 사용자가 이 스프레드시트를 다운로드하도록 초대합니다.사용자가 입력 데이터를 입력하면 HiveLink는 데이터를 원래 스프레드시트로 전달하여 데이터를 처리한 다음 결과를 사용자에게 자동으로 반환합니다.

이 접근 방식의 좋은 점은 사용자가 컴퓨터에서 코드를 완전히 제거하기 때문에 .NET 반사 또는 어셈블리 코드를 사용하여 리버스 엔지니어링할 수 없다는 것입니다.이것은 가장 안전한 옵션이며, 모델이 입력/출력 왕복 설계에 적합한 경우에는 좋습니다. 즉시 발생하는 클라이언트 측 대화형 코드가 필요한 경우에는 그렇게 좋지 않습니다.빠른 클라이언트 측 대화형 코드가 필요한 경우 일반적으로 이것은 덜 민감하며 워크북 보호를 사용하거나 DoneEx Excel 컴파일러와 같은 것을 사용하여 기본 코드를 컴파일할 수 있으며 Excel 컴파일러와 HiveLink의 조합을 사용하여 보호할 수 있습니다.

http://FCell.io :이렇게 하면 .NET 코드를 스프레드시트에 직접 빌드할 수 있습니다.또한 스프레드시트에 코드 편집기 창이 있습니다. 기존 VBA 코드 편집기를 .NET 코드 편집기로 대체하는 것과 같습니다.코드 편집기의 개체 모델은 일반 모델보다 포괄적이지 않지만 작업 창을 만들어 배포용 워크북에 포함시켜 사용자가 아무것도 설치할 필요가 없도록 할 수도 있습니다!사용자 코드가 워크북에 얼마나 안전하게 포함되어 있는지는 모르겠지만, 사용자에게 충분히 중요한 코드라면 사용자 코드에 액세스할 수 있다고 100% 확신합니다.

추가 의견 ReMat's Mug 유용한 답변:

Re: 성능 비용 - 특히 UDF나 매크로에서 Excel이 전혀 하지 않는 멀티스레딩을 사용하는 경우 .NET에서 구현하면 성능이 크게 향상될 수 있습니다..NET 라이브러리에서 클라이언트 코드 중 일부를 100배 더 다시 작성하는 이점을 보았습니다(처리량이 많은 계산을 위해)또한 VBA보다 .NET 코드를 유지 관리하고 개선하는 것이 훨씬 쉬울 수 있습니다.저는 VBA 코드와 기능을 .NET 코드로 변환한 적이 많았으며 제대로 수행되었을 때 성능 문제가 발생한 적은 없었습니다.

Re: .NET 라이브러리를 반영하여 액세스할 자격이 있는 사용자?저는 이것에 전적으로 동의하지 않습니다.반사를 사용하여 .NET 코드에 접근하는 것은 매우 쉬우며, 아마도 엑셀의 약한 암호를 해독하는 것보다 더 쉬울 것입니다.만약 당신이 정말로 보호하고 싶은 민감한 계산이 있다면, 하이브링크와 같은 것을 사용하여 역엔지니어링의 가능성을 완전히 제거하거나 난독화를 사용하여 훨씬 더 어렵거나 매우 성가시게 만드는 것이 가장 좋습니다.난독화를 위해 CryptoObfulcator($)와 Dotfulcator($$)를 사용합니다.이것 없이는 클라이언트의 민감한 모델 VBA 코드를 .NET 라이브러리에서 엑셀로 공유하지 않을 것입니다.또한 CryptoLicensing을 사용하여 각 사용자에 대한 라이센스를 생성하여 DLL 기능에 액세스할 수 있는 사용자를 제어할 수 있습니다.

Re: 워크시트에서 쓰기/읽기를 VBA 코드에 맡깁니다. 저도 이에 매우 반대합니다.가능한 한 VBA에 코드를 적게 남기고 .NET 플러그인에 읽기/쓰기를 맡기고 .NET에 고급 호출을 하는 것이 좋습니다.워크시트에서 명명된 범위를 사용하여 입력/출력 및 데이터 위치를 식별한 다음 이러한 명명된 범위를 .NET 라이브러리의 상수로 정의합니다.라이브러리에서 범위를 매우 쉽게 읽고 범위에 쓸 수 있습니다.이런 식으로 유지하는 것이 훨씬 깨끗하고 쉽습니다.

VBA에서 외부 기능을 호출하려는 Excel용 확장 라이브러리를 구축할 때는 라이브러리 COM을 표시해야 합니다.몇 가지 방법이 있습니다.regsvr32를 사용하여 라이브러리를 Windows COM 목록에 등록해야 하는 것을 피하는 것이 좋습니다. 어떤 대가를 치르더라도 피해야 합니다!

라이브러리를 등록하는 가장 좋은 방법은 ExcelDna를 사용하여 라이브러리를 로드하는 것입니다. 이를 통해 레지스트리에서 COM 인터페이스로 각 클래스를 영구적으로 정의할 필요 없이 Excel을 시작할 때마다 DLL을 동적으로 로드할 수 있습니다(버전 업데이트 시 악몽).결국 DLL이 내부에 포함될 수 있는 XLL 파일을 만들고 레지스트리에 키를 넣어 시작할 때마다 XLL을 로드하도록 Excel에 지시할 수 있습니다.이렇게 하면 전체 COM 인터페이스를 레지스트리에 저장할 필요가 없으므로 새 버전을 관리하기가 매우 쉽습니다.

따라서 VBA 코드는 다음과 같습니다.

Sub Button_Click()
    Call ThisWorkbook.EnsureLibraryInitialized
    Call ThisWorkbook.MyLibrary.ReadRangesAndWriteResults(someInputParam)
End Sub

VBA는 실행 시 ReadRangesAndWriteResults 방법을 찾습니다.만약 당신이 VBA에서 컴파일 시간에 대한 방법을 노출한다면, 당신은 레지스트리에 COM 인터페이스 서명을 등록해야 할 것입니다. - 어떤 대가를 치르더라도 피할 가치가 있습니다!

이 워크북 모듈:

Public MyLibrary as Object

public sub Workbook_Open()
    EnsureLibraryInitialized
End Sub

public Sub EnsureLibraryInitialized()
    Dim addin As COMAddIn
    If MyLibrary is Nothing Then
        For Each addin In Application.COMAddIns
            If InStr(addin.Description, "MyLibrary.COMHelper") Then
                If addin.object Is Nothing Then
                    'complain it can't connect to library, tell user to reinstall it
                Else
                    Set MyLibrary = addin.object
                Exit For
            End If
        Next
    End if
End Sub

Re: Excel Interop 및 .NET 라이브러리 - 좋은 점 매트 머그컵, 이것은 일반 마이크로소프트를 사용할 때 악몽이 될 수 있습니다.사무실. 인터럽트.Excel. 관리되는 .NET 환경에서 네이티브 코드에 액세스하기 때문에 .NET COM 래퍼 개체가 제대로 정리되었는지 확인해야 합니다. 그렇지 않으면 Excel을 닫은 후에도 Excel이 사라지거나 닫힌 것처럼 보일 수 있습니다(작업 관리자에서 해당 개체가 여전히 있을 수 있습니다!).

이 문제를 해결하는 가장 좋은 방법은 NetOffice를 사용하는 것입니다. NetOffice는 기본적으로 Excel 인터op 모델의 복제본이지만 이러한 모든 문제를 안전하게 관리하기 위해 만들어졌습니다.또한 COM 개체를 안전하게 취급하는 것이 좋습니다(예: 여기와 여기).

행운을 빕니다.

XLSB로 열기 위해 암호로 워크북을 저장하는 경우(참고: 이 워크북 보호 안 함 구조 등) 적절한 보안 암호화로 워크북이 암호화됩니다(Excel 2013에서는 더 강력함).
그러나 사용자가 암호를 입력해야 열기 때문에 일부 사용 시나리오에는 적합하지 않습니다.

다른 모든 형태의 Excel 보호는 상대적으로 취약합니다.

Excel에서 코드를 보호하는 것은 C++ XLL을 사용하는 것이 가장 좋습니다.
VB6 DLL입니다. (엑셀에서는 하지 않을 것입니다.) VB6 DLL입니다.
그 다음으로는 난독화된 .NET이지만, .NET Interop 및 VSTO의 성능 특성이 저하되지 않도록 하려면 Addin Express 또는 XL DNA에서 제공하는 종류의 .NET XLL 인터페이스를 사용해야 합니다.

언급URL : https://stackoverflow.com/questions/16363621/protecting-code-in-an-excel-workbook