Version imprimable
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
Pièce jointe 467686
Que proposez vous?
Merco
payer ou sortir les backups ?
rien de çaCitation:
Envoyé par 7gyY9w1ZY6ySRgPeaefZ
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 +
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égligenceCitation:
Envoyé par SQLpro
En psychologie on appelle ça des injonctions contradictoires !Citation:
Envoyé par erpWorld
Revenons aux sources :
1- Pourquoi ils en ont besoin ? (quelle fonctionnalité, quels process, ...)
2- Dans quel contexte de sécurité ? (séparation des comptes par process, notion de proxy, ...)
3- Pour quelles actions élémentaires ? lecture, lecture-écriture, full
Et, en accord avec les réponses, jouer avec les droits de partage ET ntfs (sans enlever les droits pour SQL ;) )
Perso je commencerais par couper l'accès et ouvrir un ticket pour chaque incident et en opposant la politique interne de sécurité.
Le premier à craquer (direction ou prestataire) définissant, de facto, l'équilibre des forces entre fonctionnalité et sécurité à appliquer dans votre entreprise.
Je sais c'est violent.
Mais en général personne ne fait l'effort de comprendre les enjeux avant d'être au pied du mur.
Et quand catastrophe il y a, alors, chacun va chercher en urgence un bouc émissaire.
Ce ne sera pas la direction.
Dès fois, les directions sont moins obtues ; On peut aussi commencer par discuter ;)
Bon courage.
