9 votes

La sagesse d'exposer un serveur de base de données sur Internet ?

La direction de la petite entreprise pour laquelle je travaille s'est enthousiasmée pour le SaaS et pousse notre produit vers un déploiement SaaS. Cela me préoccupe car une partie de la fonctionnalité du produit repose sur la possibilité pour les utilisateurs d'utiliser des outils de veille stratégique pour rédiger des rapports sur la base de données sous-jacente de l'application.

Lorsque je demande comment nous prévoyons de fournir cette fonctionnalité dans le modèle SaaS, je suis accueilli par des regards vides et la réponse est simplement que nous allons exposer le serveur de base de données sur Internet et permettre aux gens d'interroger la base de données comme si elle fonctionnait dans leur réseau d'entreprise.

Cela me fait très peur, mais je ne sais pas si je suis simplement paranoïaque ou s'il y a de bonnes raisons de s'inquiéter.

Ma question est donc la suivante : est-il possible de renforcer de manière appropriée la sécurité d'un serveur de base de données Oracle afin de ne pas avoir à se préoccuper du fait qu'il sera exposé sur Internet ? Et si oui, quelles ressources dois-je rechercher pour apprendre à le faire ? La base de données stockera des informations exclusives que nos clients ne voudraient pas exposer au monde entier, et pourtant une proposition visant à placer cette fonctionnalité derrière un VPN a été carrément rejetée.

Mes recherches sur le durcissement d'une base de données Oracle ont presque toutes abouti à des affirmations du type "Ne faites jamais de trou dans votre pare-feu". Il se peut donc que la bonne réponse soit "Mettez votre CV à jour aussi vite que possible", mais j'apprécierais tout conseil que vous pourriez me donner.

8voto

RP. Points 191

Exposer une base de données n'est pas vraiment géant Ce n'est pas un problème par rapport à certains autres services qui sont souvent exposés à world+dog... sauf que c'est un système compliqué avec beaucoup de vulnérabilités potentielles, y compris l'escalade des permissions. Je m'assurerais que vous n'exposez pas la base de données aux requêtes publiques et que vous l'exécutez avec le SSL requis, etc. Je dirais que c'est possible, mais oui, vous devez être paranoïaque et vous devez maintenir une installation de base de données distincte de celle qui est destinée au public. Si votre entreprise n'est pas prête à payer les coûts de licence pour cela, oui, allez-y.

Du côté du client/de l'assistance, la connexion directe à la base de données peut poser problème si le fournisseur d'accès Internet du client bloque certains types de ports ou de trafic.

Dans un modèle SaaS, ce que vous attendez généralement de vos programmeurs, c'est qu'ils écrivent une API qui peut être interrogée à partir de l'application. Les API de cette nature fonctionnent généralement sur https et renvoient des données à l'application dans la réponse HTTP. Bonus supplémentaire : elle fonctionne partout où le Web fonctionne, il est TRÈS facile de mettre en cache les ensembles de résultats à l'aide de memcached ou d'autres technologies de mise en cache pour réduire la charge sur le serveur de base de données, et l'authentification http est très bien prise en charge et testée.

3voto

Kyle Brandt Points 81077

Je mettrais en place un second serveur de base de données dans la DMZ, j'importerais les vidages dans cette base de données et je rendrais cette publicité de base de données disponible.

2voto

Dominic D Points 1366

Vous en conviendrez, l'accès et la sécurité sont, par définition, un compromis. Et vous avez pour mission de rendre les données sensibles accessibles.

En bref, vous pouvez atténuer une grande partie du risque en utilisant des pare-feu, une architecture réseau solide, des correctifs actualisés, des audits d'accès et des sauvegardes abondantes.

La gestion des mots de passe vient également à l'esprit comme une chose délicate à accomplir, souvent les comptes d'application ont des mots de passe qui n'expirent jamais, et des contrôles d'accès physiques/réseau sont mis en place pour s'assurer que les ex-employés connaissant les mots de passe ne peuvent pas accéder aux données. Si votre serveur de base de données est exposé à l'ensemble de l'Internet, cela semble difficile à réaliser.

Vous voudrez probablement aussi définir une stratégie du type "nous avons été compromis, que faisons-nous maintenant ?", afin de définir les attentes de toutes les personnes concernées et d'avoir un plan d'action pour le cas où votre chance tournerait.

1voto

smokris Points 634

Je dirais qu'il faut utiliser soit les API, soit les services web, les services web étant préférables car ils offrent plus de flexibilité quant à la manière dont les utilisateurs finaux (clients) s'y connectent.

Dans la deuxième partie, la direction dira "c'est dingue, il nous faut un marché MAINTENANT" et ne voudra pas dépenser de l'argent pour le développer.

Dans la troisième partie, il faut convaincre la direction que l'exposition directe de la base de données n'est pas une bonne chose, puis proposer un grand nombre de livres blancs, de rapports de sécurité, etc. De plus, si j'envisageais d'utiliser votre logiciel et qu'il est SaaS je veux tout savoir sur votre sécurité, et dès que je découvre que vous exposez la base de données, le marché est rompu.

0voto

Martin Points 3552

Le SaaS est un bien.

Exposer un serveur de base de données à l'Internet - pas si bien.

Pourquoi ont-ils besoin de l'exposer ? Est-ce à cause de RPC et ils ne veulent pas utiliser les ports RPC statiques ?

Mais il existe d'excellents pare-feu d'application et si vous verrouillez le port de l'endmapper de la BD et que vous le pare-feu, vous pouvez faire de bonnes choses avec des ACL, des restrictions IP, etc.

Et vous devrez auditer les journaux d'événements, l'analyse de vulnérabilité, etc.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X