Comment éviter le piratage accidentel avec une base de données de production?

31

Tout récemment, un développeur a accidentellement tenté de restaurer une base de données en production, alors qu'il aurait dû restaurer sur une copie intermédiaire. C'est facile à faire, étant donné que les noms de base de données sont similaires, c'est-à-dire CustomerName_Staging contre CustomerName_Production.

Idéalement, je les aurais sur des boîtiers entièrement séparés, mais cela est prohibitif et, à strictement parler, cela n'empêche pas la même chose de se produire si l'utilisateur se connecte au mauvais boîtier.

Ce n'est pas un problème de sécurité en soi - c'était le bon utilisateur qui travaillait avec la base de données intermédiaire, et s'il y avait du travail à faire sur la base de données de production, ce serait lui aussi. J'adorerais avoir un officier de déploiement pour séparer ces préoccupations, mais l'équipe n'est pas assez grande pour cela.

Je serais ravi d'entendre quelques conseils en termes de pratique, de configuration et de contrôles sur la façon d'éviter cela.

sql-server best-practices

— Chris B. Behrens
source

25

Les développeurs ne doivent pas avoir accès en écriture aux bases de données de production, ou de préférence, aucun accès.

— Michael Hampton

12

@MichaelHampton - C'est moi et lui. Je suis également développeur. Que suggérez-vous?

— Chris B. Behrens

10

Comptes d'utilisateurs distincts pour chaque rôle (dev vs ops / DBA). Et une abondance de prudence.

— Michael Hampton

2

Je vous conseille fortement d'avoir votre environnement de production sur une boîte séparée. Sinon, le transfert et la production doivent partager des ressources - disque, processeur, etc. - et si le transfert monopolise une ressource, votre environnement de production peut en souffrir.

— Thorbjørn Ravn Andersen

1

Il suffit d'avoir des utilisateurs / mots de passe séparés pour ces bases de données.

— neutrinus

32

Si c'est quelque chose que vous vous voyez souvent faire, automatisez-le. Et puisque vous êtes tous deux développeurs, l'écriture de code devrait se faire dans votre timonerie. :) Sérieusement cependant ... en l'automatisant, vous pouvez faire des choses comme:

Vérifiez que vous restaurez sur le bon serveur (c.-à-d. Pas de dev -> restaurations prod)
Vérifiez que c'est le bon "type" de base de données (dans votre cas, "staging" et "production")
Déterminez la ou les sauvegardes à restaurer automatiquement en consultant les tables de sauvegarde dans msdb

Etc. Vous n'êtes limité que par votre imagination.

— Ben Thul
source

1

C'est une idée intéressante ... nous avons déjà du code qui gère les restaurations db (pour les tests automatisés). Nous pourrions mettre une couche d'abstraction entre les deux qui ne vise que la mise en scène afin que la restauration de la production soit un processus entièrement différent ...

— Chris B. Behrens

11

Vous pensez maintenant aux portails. :)

— Ben Thul

4

Pour les travaux automatisés qui affectent la production, j'aime ajouter une étape manuelle qui oblige l'utilisateur à taper le mot "production" pour réduire la possibilité qu'il pense qu'il regarde par exemple l'équivalent de la mise en scène.

— Joe Lee-Moyet

2

J'ai rétrogradé car personne ne devrait avoir accès à la production par défaut. Vous devez avoir un processus spécial pour récupérer un mot de passe prod. C'est gênant mais vraiment le minimum.

— OliverS

1

@BenThul Ajouter un compte différent pour l'accès prod et le rendre une étape de plus incommode est toujours la bonne solution pour moi. Le besoin commercial n'est pas de faire gagner 2 minutes au DEV mais de restaurer la base de données qui peut être parfaitement déplacée vers un compte prod.

— OliverS

32

Je ne suis pas d'accord avec l'hypothèse de la question - c'est la sécurité - mais je suis également en désaccord avec le fait que l'automatisation va sauver la situation toute seule. Je vais commencer par le problème:

Vous ne devriez pas pouvoir accidentellement faire quoi que ce soit à la production!

Cela inclut de faire des choses automatisées accidentellement.

Vous confondez la sécurité du système avec des concepts comme «qui est autorisé à faire quoi». Vos comptes de développement ne devraient pouvoir écrire que sur leurs copies, le serveur de contrôle de version et la base de données de développement. S'ils peuvent lire / écrire la production, ils peuvent être piratés et exploités pour voler des données client ou (comme vous l'avez démontré) peuvent être maltraités pour perdre des données client.

Vous devez commencer par trier votre flux de travail.

Vos comptes de développeur doivent pouvoir écrire sur leurs propres copies, contrôler la version et peut-être passer du contrôle de version dans un environnement de test.
Les utilisateurs de sauvegarde ne doivent pouvoir lire qu'à partir de la production et écrire dans votre magasin de sauvegarde (qui doit être correctement protégé).
Faire toute autre lecture / écriture sur la production devrait nécessiter une authentification spéciale et peu pratique . Vous ne devriez pas pouvoir y glisser ou oublier que vous êtes connecté. Le contrôle d'accès physique est utile ici. Cartes à puce, interrupteurs à bascule pour "armer" le compte, accès à double clé à tour simultané.

L'accès à la production ne devrait pas être quelque chose que vous devez faire tous les jours. La plupart du travail doit être effectué sur votre plate-forme de test et les déploiements en dehors des heures d'ouverture doivent être effectués en production après un examen minutieux. Un petit inconvénient ne vous tuera pas.

L'automatisation fait partie de la solution.

Je ne suis pas aveugle au fait que le retournement complet (téléchargement vers VCS, vérification de la couverture, traction vers le serveur de test, exécution de tests automatisés, réauthentification, création d'une sauvegarde, extraction depuis VCS) est un long processus.

C'est là que l'automatisation peut aider, selon la réponse de Ben. Il existe de nombreux langages de script différents qui rendent l'exécution de certaines tâches beaucoup plus facile. Assurez-vous simplement que vous ne faites pas trop facilement des choses stupides. Vos étapes de réauthentification doivent toujours être prononcées (et si elles sont dangereuses), elles doivent être incommodes et difficiles à faire sans réfléchir.

Mais seule , l'automatisation est pire qu'inutile. Cela vous aidera simplement à faire de plus grosses erreurs avec moins de réflexion.

Convient aux équipes de toutes tailles.

J'ai remarqué que vous montriez la taille de votre équipe. Je suis un gars et je me suis mis à travers ça car il n'y a qu'une seule personne pour avoir un accident. Il y a des frais généraux mais ça vaut le coup. Vous vous retrouvez avec un environnement de développement et de production beaucoup plus sûr et beaucoup plus sécurisé.

— Oli
source

2

De plus, une chose que j'aime faire est d'utiliser deux comptes nommés par utilisateur. L'un est pour la connexion utilisateur normale, le fonctionnement, le travail quotidien, etc., tandis que le deuxième compte (généralement avec une sorte de suffixe comme un + ou un trait de soulignement) a tous les droits de production et de développement dont l'utilisateur a besoin. De cette façon, l'utilisateur doit prendre une décision active pour pousser à prod plutôt qu'à dev. Ceci est similaire à la puce 3 décrite ci-dessus, mais ne nécessite pas d'infrastructure ou de dépenses supplémentaires importantes pour démontrer la valeur.

— user24313

3

Il est également important d'éviter de prendre l'habitude de faire autre chose que la maintenance de prod dans votre compte prod. À cette fin, assurez-vous que le prod ne peut pas voir le code source, ne peut pas démarrer un IDE, etc.

— Eric Lloyd

Où puis-je me procurer une de ces machines à double clé à tour simultané et est-il livré avec USB?

— Lilienthal

Une autre chose qui pourrait aider est l'automatisation complète (un ou deux clics) des procédures de transfert et de développement, mais pas l' automatisation complète des déploiements de production. Le fait de devoir se déplacer manuellement dans la boîte pour faire quoi que ce soit à la production mais pas à d'autres environnements est une différence de commodité importante, comme vous le suggérez. (Vous pouvez toujours créer des scripts pour toutes les étapes impliquées et utiliser ce script dans tous les environnements; ce que je veux dire, c'est que vous devrez déclencher manuellement l'exécution desdits scripts pour la production.) Cela peut bien sûr être fait en plus du type d'authentification procédures que vous recommandez.

— jpmc26

1

@Lilienthal C'était une métaphore pour le théâtre de haute sécurité, mais vous pouvez imiter cette clé USB d'attaque à bas prix pour chaque développeur, puis demander à votre automatisation de vérifier au moins deux de leurs numéros de série lors de l'exécution de choses dangereuses. Dans de plus grandes équipes, vous pouvez ensuite vous connecter pour voir qui interfère avec la production et tenir les bonnes personnes responsables lorsque tout va mal.

— Oli

12

Un de mes collègues a une approche intéressante à ce sujet. Son schéma de couleurs terminal pour la production est à la mode . Gris et rose et difficile à lire, ce qui est théoriquement censé garantir que quoi qu'il écrive, il avait vraiment l'intention d'écrire.

Votre kilométrage peut varier ... et je n'ai probablement pas à dire qu'il n'est guère à lui seul. :)

— robhol
source

2

J'utilise également une grande couleur de fond rouge sur les connexions terminaux / db aux serveurs de production, ainsi que des fonds d'écran rouge vif pour les administrateurs sur PC ...

— Falco

Ouais, je pensais ça. Rendre la pompe à feu de production rouge ...

— Chris B. Behrens

Le codage couleur aide. Tout comme dans un IDE.

— Thorbjørn Ravn Andersen

1

Les développeurs ne doivent pas connaître le mot de passe de la base de données de production. Le mot de passe prod doit être aléatoire et non mémorisable - quelque chose comme le résultat de l'écrasement du clavier ( Z^kC83N*(#$Hx). Votre mot de passe dev peut être $YourDog'sNameou correct horse battery stapleou autre.

Bien sûr, vous pouvez découvrir le mot de passe, surtout si vous êtes une petite équipe, en consultant le fichier de configuration de l'application cliente. C'est le seul endroit où le mot de passe prod doit exister. Cela garantit que vous devrez faire un effort délibéré pour obtenir le mot de passe prod.

(Comme toujours, vous devriez avoir des sauvegardes ponctuelles pour votre base de données de production. Par exemple, avec MySQL, archivez les journaux binaires en tant que sauvegardes incrémentielles. Pour PostgreSQL, archivez les journaux d'écriture anticipée. C'est votre protection de dernier recours pour tout type de catastrophe, auto-infligée ou non.)

— 200_success
source

Je ne suis pas entièrement d'accord avec cela, car dans tout grand environnement réaliste, il y a des cas assez réguliers où les développeurs / administrateurs doivent accéder à la base de données de production. Bien sûr, dans un monde parfait avec un système sans faille, cela ne devrait jamais se produire, mais dans la plupart des systèmes, je sais que vous devez corriger manuellement certaines données critiques de production ... Je suis donc avec Oli, la connexion de production devrait être gênante, mais faisable

— Falco

1

@Falco C'est exactement ce que je suggère cependant. Inconvénient mais faisable.

— 200_success

Le problème avec votre approche n'est que s'il y a une émergence et une production en baisse, le temps compte. Vos développeurs devraient donc savoir où trouver le mot de passe et l'obtenir rapidement. S'ils doivent se renseigner, recherchez dans le référentiel et les fichiers de configuration et essayez de perdre du temps précieux = de l'argent. Je préfère donc avoir le mot de passe dans un endroit où tout le monde sait où chercher, mais c'est toujours gênant, mais rapide si besoin est

— Falco

2

@Falco Étant donné que les environnements de production doivent refléter de près les environnements de développement, le fichier de configuration se trouverait à la même place sur le serveur de production que sur les machines de développement. Tout développeur compétent doit savoir où chercher, et s'il ne sait pas où chercher, alors vous voulez ce délai - précisément pour éviter les dommages du type indiqué dans la question.

— 200_success

Ne pas connaître les mots de passe n'empêche pas les accidents. Au contraire, cela crée la motivation de ne faire la recherche de mot de passe qu'une seule fois, et après cela, le développeur peut commencer à utiliser l'historique bash ou même créer un alias pour se connecter à la base de données. Et puis, les accidents sont plus susceptibles de se produire.

— k0pernikus

0

La réponse courte est RBAC - contrôle d'accès basé sur les rôles.

Vos autorisations pour tous les environnements doivent être différentes - et aussi ennuyeux que soient des choses comme des choses comme l'UAC, vous en avez besoin: en particulier pour les environnements PROD.

Il n'y a JAMAIS de raison pour que les développeurs aient un accès direct à Prod - quelle que soit la taille de l'organisation / de l'équipe. Votre "Dev" peut également porter les chapeaux "Stage" et "Prod", mais il doit avoir des informations d'identification et des processus différents pour atteindre différents environnements.

C'est ennuyeux? Absolument. Mais cela [aide-t-il] à empêcher le borking de vos environnements? Absolument.

— garenne
source

0

Une solution simple et rapide: utilisez deux comptes utilisateurs différents, un pour votre travail de développement normal qui n'a accès qu'à la base de données de développement, et un autre pour réellement opérer sur la base de données de production, avec un accès complet à celle-ci. De cette façon, vous devrez modifier activement le compte que vous utilisez avant de pouvoir apporter des modifications à la production, ce qui devrait être suffisant pour éviter les erreurs accidentelles.

La même approche peut être utilisée si vous avez deux sites Web, ou deux serveurs, ou deux environnements entiers: un compte utilisateur pour le développement sans accès (ou au moins aucun accès en écriture ) à la production, un autre compte utilisateur pour travailler sur le système de production ( s).

Il s'agit de la même approche qu'un administrateur système disposant d'un compte non administrateur standard pour le travail de routine (lecture d'e-mails, navigation sur le Web, suivi des tickets, classement des feuilles de temps, rédaction de documentation, etc.) et d'un compte administrateur complet distinct à utiliser lors de l'exploitation sur les serveurs et / ou Active Directory.

— Massimo
source