Bonjour,
Depuis la nouvelle version de Sage L100, FileTable (avec accès Full) est indispensable pour le fonctionnement de la solution.
Le problème est que chez un client le dossier partagé a été attaqué par un ransomware
Que proposez vous?
Merco
Bonjour,
Depuis la nouvelle version de Sage L100, FileTable (avec accès Full) est indispensable pour le fonctionnement de la solution.
Le problème est que chez un client le dossier partagé a été attaqué par un ransomware
Que proposez vous?
Merco
payer ou sortir les backups ?
Si on est encore capable de lire la donnée (période de "grâce") un export logique peut être envisagé.
Faire en dehors de la zone de portée du ransomware (hôte distant, attention à, la contamination)
Clic droit sur la base > tâche > exporter une application de la couche de donnée (fichier bakpac= fichier compressé)
ou
Clic droit sur la base > tâche > générer des scripts (bien valider chaque option sinon pas de données dedans)
Good luck.
Ps :
On peut aussi envisager de péter la gueule à ces putains de développeurs qui demandent les droits admin pour leur développement.
Je ne citerais pas le noms de deux éditeurs auquel je fais actuellement la guerre, mais qui sont dans le domaine du TMS (Transport Management System) et l'autre dans le WMS (Warehouse Management System) qui veulent absolument un compte de connexion sysadmin pour pouvoir tuer les sessions, parc que c'est pour eux (dixit) le seul moyen de débloquer les blocages dans SQL Server….
À côté de ça on trouve pour le premier (WMS) :
- 171 tables sans clef
- aucune clef étrangères
- aucune contrainte de validation (CHECK)
- 15 colonnes ayant des types obsolètes (text, ntext, image)
- 46 tables avec plus de 100 colonnes, allant jusqu'à 291 colonnes
- 0 vues, 20 procédures, 0 fonctions table, 7 udf scalaires
- 90 tables ayant des clefs avec 10 colonnes et jusqu'à 16
- 53 tables ayant des clefs de plus de 200 octets et jusqu'à 1384 octets
- 4 tables ayant des clefs dont la longueur potentielle dépasse la taille maximale allant de 903 à 1384 octets...
Et pour l'autre (TMS) c'est aussi triste
- 146 tables sans clef
- aucune clef étrangères
- aucune contrainte de validation (CHECK)
- 3 colonnes ayant des types obsolètes (text, ntext, image)
- 2681 colonnes avec des types de données déconseillé
- 81 tables avec plus de 100 colonnes, allant jusqu'à 664 colonnes
- 0 vues, 52 procédures, 1 fonctions table, 4 udf scalaires
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Aucune perte de données pour le moment, les fichiers pdf n'ont aucune importance (c'est l'exigence de la LAF française qui n'est pas applicable en Tunisie)
Mais je cherche plutôt comment sécurisé l'accès a ce dossier partagé sans perturbé le fonctionnement de l'applicatif.
Comme j'ai mentionné l'éditeur exige un accès full au niveau du filestream.
Même si je manque encore de l'expertise et je fait encore des bêtises (contrainte de budget temps de mise en place principalement) j'essaie de remonter toutes les défaillances que vous avez cité a notre équipe de dev.. Mais toujours une énormes négligence
Partager