Une nouvelle approche : séparer
la sécurité du code de l’application
Visual Guard.Net stocke les données de sécurité
dans une base de données propriétaire: le Repository.
Les rôles, les comptes login/mots de passe, les permissions,
sont séparés du code source de votre application.
Les données de sécurité sont créées
et maintenues avec une interface graphique : la Console
Les règles de sécurité sont appliquées
dynamiquement lors de l’exécution de l’application.
Quels sont les avantages de cette approche
Visual Guard .Net modifie le comportement de l’application
sans la recompiler.
Visual Guard .Net applique les règles de sécurité
sur des applications en production
Les règles de sécurité sont créées
sans code : Rôles, permissions, etc…
Visual Guard permet de faire des économies significatives sur
:
le développement : on ne code plus les permissions,
les rôles, on les définit en quelques clics.
la maintenance : les mises à jour ne nécessitent
pas de recompilation.
Comment créer des permissions
avec Visual Guard .Net
Permissions sans code : Modifier les propriétés
des objets .Net
Visual Guard utilise la réflexion de .Net pour lister les objets
de votre application, et leurs propriétés.
La liste est affichée dans une fenêtre qui permet de
sélectionner les objets et de changer la valeur de chaque propriété.
La propriété modifiée est ensuite attribuée
à un rôle puis à un utilisateur.
On peut agir ainsi sur n’importe quel composant .NET : objets
visuels de l’interface graphique, objets non visuels contenant
les règles métier, objets qui gèrent l’accès
à la base de données.
Démo : Exemple de modification d’un contrôle.
Les permissions sont appliquées durant l’exécution
de votre application.
Visual Guard peut donc prendre en compte et appliquer immédiatement
toute nouvelle règle de sécurité (permission,
rôle…), même si votre application est en production.
D’un point de vue fonctionnel, Visual Guard .Net respecte les
principes généraux du contrôle d’accès
basé sur les rôles :
Un rôle
est attribué à un utilisateur.
Un rôle contient un set de permissions.
Un set de permissions contient des permissions.
Une permission est composée d’actions techniques.
Flexibilité Totale
Si besoin, Visual Guard .Net permet de tester des permissions dans
l’application.
Vous testez si une permission est attribuée à l’utilisateur
courant comme vous le feriez sans Visual Guard .Net.
Si le test est concluant, les permissions sont exécutées.
Il en est de même pour un rôle.
Une nouvelle approche : séparer
la sécurité du code de l’application
Visual Guard.Net stocke les données de sécurité
dans une base de données propriétaire: le Repository.
Les rôles, les comptes login/mots de passe, les permissions,
sont séparés du code source de votre application.
Les données de sécurité sont créées
et maintenues avec une interface graphique : la Console
Les règles de sécurité sont appliquées
dynamiquement lors de l’exécution de l’application.
Quels sont les avantages de cette approche
Visual Guard .Net modifie le comportement de l’application
sans la recompiler.
Visual Guard .Net applique les règles de sécurité
sur des applications en production
Les règles de sécurité sont créées
sans code : Rôles, permissions, etc…
Visual Guard permet de faire des économies significatives sur
:
le développement : on ne code plus les permissions,
les rôles, on les définit en quelques clics.
la maintenance : les mises à jour ne nécessitent
pas de recompilation.
Pourquoi ?
Réduire les coûts de maintenance : Un seul système
pour toutes vos applications .Net
Externaliser le support des technologies MS qui évoluent
sans cesse
Sécuriser simplement les applications N-tier (.Net ou
non .Net)
Visual Guard .Net supporte :
Toutes les Technologies :
Visual Guard .Net supporte déjà toutes les technologies
.Net : Winforms, ASP.Net, Web services, WCF, WPF. Le support de
Silverlight, et dans une certaine mesure, celui des applications
non .Net sera bientôt disponible.
Tous les composants .Net
Les objets visuels, les objets métiers non visuels sont
supportés ainsi que les objets gérant l’accès
à la base de données.
Les objets dynamiques sont également supportés (CAB,
Smartclient,…).
Dans tous les cas, vous pouvez choisir de tester les permissions
dans le code de l’application.
Toutes les architectures
Support des services web : le run time de Visual Guard
peut être intégré à des services web
pour sécuriser une architecture n-tier.
VG Server : Visual Guard .Net fournit un composant
qui permet de sécuriser des application .Net qui ne peuvent
pas accéder à la base de données.
Seul VG Server communique avec la base pour récupérer
les données de sécurité des utilisateurs.
VG serveur supporte toutes les applications .Net intégrant
le run-time de Visual Guard. La prochaine version présentera
des services web pour sécuriser les applications non
DotNet.
La console : Les données de sécurité
sont créées et maintenues avec une interface graphique
: la Console. Disponible en winform et en webform, elle permet
à des administrateurs de gérer la sécurité
même s’ils n’ont pas accès à
la base de données (un simple accès à Internet
suffit).
Pourquoi séparer la sécurité
du code de l’application?
La plus part du temps, le contrôle d’accès se
fait en codant les règles de sécurité dans
l’application.
Chaque mise à jour implique de recompiler l’application.
Parfois la mise en place de nouvelles règles est retardée,
ce qui peut créer une faille de sécurité.
L’approche de Visual Guard permet de:
Maximiser le niveau de sécurité
Les règles de sécurité sont mises à
jour à tout moment : pas besoin d’attendre le prochain
build.
Visual Guard offre une granularité très fine qui
permet de s’adapter aux besoins métiers complexes
(cf permissions avec conditions).
Réduire les coûts de maintenance
Modification de permissions existantes en quelques clics... voir
une démo
Toute nouvelle demande (rôle, permission…) est mise
en production immédiatement.
Permissions avec des conditions
Les permissions VG modifient les propriétés des
objets des applications .Net (ASP.Net, WCF, winform…).
Elles permettent de modifier les règles métier, une
requête SQL, masquer un bouton, désactiver un menu,
etc...
La valeur d’une propriété dépend donc
du rôle de l’utilisateur connecté.
Dans certains cas, la valeur d’une propriété
doit dépendre de deux critères : le rôle ET
une information de l’application.
Exemple: un utilisateur ayant le rôle “Agent commercial”
est autorisé à cliquer sur le bouton “OK”
d’une facture SI le client fait partie de son portefeuille.
La permission peut également dépendre d’une
autre propriété ou de la valeur d’un champ
de l’application …
Dans ce cas, Visual Guard .Net permet de modifier la valeur de
la propriété avec une expression
Sécurité maximum
ou minimum ?
Les recommandations de Microsoft incluent une politique visant
à ne rien autoriser par défaut dans les applications
.NET. Pour des raisons de sécurité, nous recommandons
vivement de respecter cette politique et de développer en
sécurité maximum :
- "Fermer toutes les portes" pendant le développement
et les ouvrir une par une avec des permissions.
- Plutôt que d’ "ouvrir toutes les portes"
pendant le développement et de les fermer une par une avec
des restrictions.
En effet, l’oubli d’une restriction peut entraîner
une faille de sécurité/confidentialité dans
le système : tous les utilisateurs pourront passer par cette
porte.
Au contraire, l’oubli d’une permission est moins critique:
il suffit d’ajouter une permission si/quand c’est nécessaire.
Avec les autorisations dynamiques de Visual Guard .Net, vous pouvez
ajouter des permissions à tout moment, y compris lorsque
l’application est en production (les permissions dynamiques
ne nécessitent pas d’accéder au code ou de le
modifier).
Testez Visual Guard !;)
Suivant : Log et audit des actions
;)
;)
Voir une démo... 