Mise à niveau et mise en œuvre de la sécurité (accès 2000-2003 et versions ultérieures)

Question

J'ai travaillé sur quelques projets d'accès à petite échelle qui ont rapidement évolué à grande échelle. Le concepteur original a mis en place une sécurité quasi nulle et tout le monde peut y entrer avec un simple changement de vitesse, bien au-delà d'un trou de sécurité pour les sous-marins nucléaires à plonger et qui m'a toujours conduit. Cela dit, les utilisateurs sont actuellement sur Office 2000, migrant lentement en 2003. J'ai saisi cette opportunité pour convaincre les parties plus élevées d'implémenter cette sécurité en utilisant des outils d'accès intégrés.

Ensuite, je passe à travers des centaines de fonctions et de formulaires pour afficher l'option explicit pour définir tous les types de données restreignant la compilation à MDE et nettoyer la mémoire qui n'a pas été faite pour une raison quelconque. Il y a des chaînes de connexion sensibles dans le code qui sont simples comme jour qui doivent être compilées pour réduire le facteur de risque. Mes questions impliquent à la fois la mise à niveau vers 2003+ et la sécurité intégrée. Et oui, c'est ce que je suis coincé avec l'utilisation à moins que je veux vraiment tout refaire dans Visual FoxPro, mais la construction d'une porsche avec des roches ... pas mon idée d'un bon moment.

• Lors d'un déplacement dans le bureau 2007, sont il des trous majeurs que je travailler autour de l'avance? Dans la prochaine année et demie toute l'affaire est censé être mise à niveau vers et j'ai seulement entendu histoires d'horreur au sujet changé/ obsolètes fonctions

• Y a-t-il des bugs majeurs qui peut/va se passer parce que de l'utilisation de le fichier de groupe de travail et les autorisations? Trucs Je devrais savoir à l'avance si quelque chose de fou arrive à verrouiller tout le monde?

• Dans le bac à sable, je n'ai pas implémenté la fonctionnalité Chiffrement. Avantages/inconvénients, risques?

D'autres bons conseils? Je me rends compte de l'ampleur de cette question et j'ai ici quelques bons livres (Programmation Access Professional 2000, Access Developers 2002, Developing Solutions avec Office 2000 Components et VBA) mais évidemment ceux-ci sont avant la technologie Access et Jet actuelle. Si quelque chose, une bonne recommandation de livre serait un booster pour moi, n'importe quoi pour me donner une longueur d'avance. À l'heure actuelle, j'ai vraiment besoin de dévorer cette question de sécurité, c'est au-delà du simple examen de la sensibilité de l'information à portée de main.

Merci d'avoir lu mon mur redoutée du texte o.o

Answer 1

sécurité au niveau utilisateur n'existe pas pour les fichiers Access 2007 (http://office.microsoft.com/en-us/access/HA101662271033.aspx). Si les données sont très sensibles, vous pouvez envisager un back-end différent.

Answer 2

J'attendrais que A2010 soit terminé avant de prendre une décision concernant les mises à niveau au-delà de A2003. A2003 va bien pour le moment, me semble-t-il. Je ne voudrais certainement pas me lancer dans le développement d'A2007 avec A2010 qui sortira si tôt et qui présentera de très nombreuses nouvelles fonctionnalités (macros de données au niveau de la table, ajouts très utiles à l'intégration de Sharepoint qui rendent possibles beaucoup de choses énormes, pour n'en nommer que deux). Mon plan est de sauter A2007 avec les clients (bien que je l'ai installé maintenant et joue avec lui afin que je sois mieux préparé quand 2010 sortira).Une chose qui n'est pas souvent mentionnée à propos de A2007 est que l'objet Office FileSearch a été supprimé dans Office 2007. Si votre application l'utilise, vous pouvez utiliser mon File Search class module pour le remplacer. Je l'ai utilisé en production depuis Juin (quand je l'ai créé), mais je viens de le publier plus largement et je suis en train de résoudre certains problèmes qui semblent être liés à des noms de fichiers avec des caractères étranges.

Answer 3

Si les données sont vraiment sensibles, elles ne doivent pas être stockées dans un fichier de base de données Access. N'importe qui peut copier l'ensemble des données MDB/ACCDB et les ramener à la maison avec eux pour les analyser à leur guise. Au lieu de cela, les données doivent être migrées vers un moteur de base de données tel que SQL Server. Conserver les requêtes, les formulaires et les rapports Access actuels, mais obtenir les données dans un format qui n'est pas si facile à voler. Ensuite, pensez à limiter leurs vues, en consignant les requêtes qu'ils exécutent et ainsi de suite.