Mot de passe de projet VBA
Verrou visuel rapide contre une ouverture accidentelle. De nombreux outils gratuits permettent de le retirer. Utile uniquement face à des utilisateurs honnêtes.
Protection du code VBA
Quatre couches autour de votre VBA.
Empilez ce dont votre modèle de menace a besoin.
La protection VBA n'est pas binaire. XLS Padlock propose quatre couches indépendantes : mot de passe de projet, masquage et verrouillage, compilation en bytecode et refus d'accès à la VBE. Empilez-en une ou empilez-les toutes les quatre. Le bon choix dépend de ceux à qui vous livrez et de l'agressivité avec laquelle vous vous attendez à ce qu'ils tentent la rétro-ingénierie.
Du code source lisible au bytecode compilé.
La couche 3 est la plus difficile à contourner. Vous déplacez les procédures que vous sélectionnez dans l'éditeur VBA de XLS Padlock, qui les compile en bytecode stocké dans l'application. La logique originale quitte le classeur : là où la macro s'exécutait, il ne reste qu'un appel au helper CallXLSPadlockVBA.
Chaque couche déjoue une classe d'attaque différente.
Masquage et verrouillage du VBA
Le gestionnaire XLS Padlock verrouille le projet VBA pour qu'il ne puisse être ni affiché, ni consulté, ni modifié. Toute ouverture affiche un message Project is unviewable, et comme le classeur est chiffré dans l'EXE, les outils de suppression de mot de passe ne peuvent pas atteindre la source.
VBA Compiler
Vous déplacez les parties critiques de vos macros dans l'éditeur VBA de XLS Padlock et les compilez en bytecode. Vous remplacez ensuite le code original par un appel au helper CallXLSPadlockVBA, de sorte que la logique source quitte le classeur et ne s'exécute qu'à l'intérieur de l'application sécurisée.
Accès à la VBE refusé
L'application compilée peut interdire l'ouverture du Visual Basic Editor (Alt+F11), de sorte que les utilisateurs finaux ne peuvent pas ouvrir la VBE pour inspecter le projet.
Trois modèles de menace, trois niveaux de protection.
Simplement masquer le code source aux utilisateurs honnêtes
Utilisez le mot de passe de projet VBA et le masquage et verrouillage. Configuration la plus rapide, aucune refonte de code. Suffisant si vos clients ne tenteront pas activement la rétro-ingénierie.
Compiler la propriété intellectuelle, garder le câblage
Déplacez vos procédures sensibles dans l'éditeur VBA de XLS Padlock et compilez-les, tout en laissant les gestionnaires d'événements et le code des UserForm en VBA simple. Meilleur équilibre entre sécurité et ergonomie pour le développeur.
Compiler agressivement, adapter le code si nécessaire
Déplacez le plus de logique métier possible dans l'éditeur VBA et compilez-la : bibliothèques mathématiques, moteurs de calcul, exporteurs, tout ce qui ne dépend pas des événements de l'interface Excel. Prévoyez d'adapter une partie du code (objet Application explicite, objets pris en charge uniquement), mais vous maximisez la surface protégée.
Verrouillez le projet, compilez la propriété intellectuelle, refusez l'éditeur.
Pour la plupart des classeurs commerciaux, la bonne base est constituée des couches 2, 3 et 4 : masquez le projet de l'interface Excel, déplacez le code sensible dans l'éditeur VBA de XLS Padlock pour le compiler, refusez l'accès à la VBE à l'exécution. Ignorez la couche 1 (le mot de passe de projet) puisqu'elle n'apporte rien dès lors que l'EXE refuse de toute façon d'ouvrir l'éditeur.