Journal SQL Server sous Linux : enjeux de sécurité

Posté par  (site Web personnel) . Licence CC By‑SA.
42
16
mar.
2021

Sommaire

TL;DR: Avec Microsoft SQL Server, la sécurité est une option. Et une option payante.

Microsoft aime Linux, nous dit-il, et il nous permet maintenant d'installer nativement son serveur de base de données SQL Server (cf. cette vidéo technique pour comprendre comment ils on fait le portage). Seulement, la configuration par défaut n'est pas sécurisée du tout. Petite revue de quelques éléments à rectifier quand vous installez et utilisez SQL Server. La plupart de ces conseils sont aussi valables si vous utilisez le cloud de Microsoft.

remarque : ce journal ne prétend pas à l'exhaustivité. Je n'ai qu'une toute petite expérience de SQL Server.

Version testée : SQL server 2019 sur Ubuntu 18.04 (en l'occurrence installée sur Debian Buster). Les recommandations valent aussi pour d'autres distributions Linux.

Configuration de SQL server

Voici le manuel d'installation. Ce qu'il ne précise pas, c'est que par défaut :

  1. SQL server écoute sur toutes les adresses réseau (et pas uniquement localhost)
  2. Le chiffrement n'est pas activé

Selon votre cas d'usage, vous devrez nécessairement corriger l'un de ces deux points.

Désactiver l'écoute sur le réseau

Si vous prévoyez d'interroger SQL Server uniquement depuis localhost, alors il faut limiter son écoute au réseau local seulement. Pour ça, il faut ajouter les lignes suivantes au fichier de configuration, qui est par défaut /var/opt/mssql/mssql.conf :

[network]
ipaddress = 127.0.0.1

Il faut ensuite redémarrer mssql-server :

$ sudo systemctl restart mssql-server

Activer TLS (1.2)

Si le serveur doit écouter sur le réseau, il est indispensable d'activer TLS. Pour cela, après avoir créé une paire clé privée / clé publique et un certificat correspondant à cette paire, il faut ajouter les options suivantes au fichier de configuration :

[network]
privatekey=/chemin/de/votre/clé/privée
cert=/chemin/de/la/chaine/de/certification/de/votre/clé
forceencryption=1
min-tls-version=1.2
cipherlist=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

Signification des options :
- privatekey/cert : fichiers de clé et certificats utilisés pour chiffrer et authentifier la connexion
- forceencryption : refuser les connexions non chiffrées. Ça protège d'un équipement réseau indiscret (écoute passive). Ça ne protège d'une attaque active type homme-du-milieu que si le client vérifie le certificat présenté (voir ci-dessous).
- min-tls-version : par défaut, SQL Server 2019 fonctionne avec TLS 1.0 (1999), TLS 1.1 (2006) et TLS 1.2 (2008). Il ne fonctionne pas avec TLS 1.3 (2018), qui apporte des garanties de sécurité supplémentaires. TLS 1.0 et 1.1 sont considérés comme "non sûrs" aujourd'hui : à moins que vous n'ayez de très vieux équipements qui doivent communiquer avec votre serveur, il vaut mieux désactiver complètement ces versions.
- cipherlist : si TLS 1.2 est encore considéré comme raisonnablement sûr, toutes les suites de chiffrement n'ont pas les mêmes qualités. En particulier, certaines n'offrent pas la confidentialité persistante, la protection contre un attaquant qui enregistrerait les flux réseau chiffrés dans un premier temps puis, dans un second temps, mettrait la main sur la clé privée du serveur. Dans un cas (sans confidentialité persistante), cette clé permet de déchiffrer les échanges passés, dans l'autre cas (avec) cela ne le permet pas. La liste indiquée ici reprend celle de la configuration "intermédiaire" proposée par Mozilla.

Désactiver TLS 1.0 et 1.1 sur le cloud Azure SQL Database

Si vous avez une base de données Azure, la situation est à peine meilleure : un certificat vous est fourni et le chiffrement est activé. Ils utilisent un certificat par datacenter, valable pour tous leurs clients (cf. la liste des "Subject Alternative Name" de ce certificat, par exemple).

Seulement, là encore TLS 1.0 et 1.1 sont proposés par défaut, vous exposant à une attaque type "downgrade". Depuis mai 2020, vous pouvez désactiver ces protocoles à l'aide de la commande suivante :

az sql server update -n sql-server-name -g sql-server-group --set minimalTlsVersion="1.2"

Les remontées d'informations vers Microsoft

Données d'utilisation : Par défaut, Microsoft collecte des données sur l'utilisation du produit. Il n'est possible de désactiver cette remontée d'informations que sur la version payante, avec les options suivantes dans le fichier de configuration :

[telemetry]
customerfeedback = false

Crash dumps : Microsoft collecte aussi les images mémoires lors des plantages de l'application (crash dump) et les conservent jusqu'à un mois. Ils préviennent que ces images sont susceptibles de contenir les identifiants d'accès à la base et des données personnelles contenus dans la base. Il ne semble pas possible de désactiver cette remontée d'informations, mais vous pouvez toujours restreindre l'accès de SQL server au réseau en créant le fichier /etc/systemd/system/mssql-server.conf.d/blocage-reseau.conf :

[Service]
IPAddressDeny=all
# Adaptez la ligne suivante : quelles IP auront besoin d'accéder à votre serveur ?
IPAddressAllow=localhost 192.168.0.0/16

Puis, pour prendre en compte cette modification et redémarrer SQL Server :

$ sudo systemctl daemon-reload
$ sudo systemctl restart mssql-server.service

sqlcmd : --insecure par défaut

Vous connaissez l'option "--insecure" de curl, celle qui signifie que "oui, je me connecte en httpS, mais je me fiche de la validité du certificat, vas-y quand même" ?

Sqlcmd, l'outil en ligne de commande pour se connecter à SQL server proposé par Microsoft, active ce comportement par défaut. Si vous voulez la sécurité apportée par TLS, il faut l'expliciter avec le drapeau "-N". La documentation explique sobrement "This switch is used by the client to request an encrypted connection".

Sans cette indication, vous êtes vulnérable à une attaque type homme du milieu qui peut soit retirer le chiffrement (s'il est partageur) soit vous présenter un certificat autosigné pour espionner la transaction et récupérer les identifiants d'accès.

L'option "-C (trust the server certificate)" n'a d'effet que si l'option -N est présente et a pour effet de forcer l'utilisation de TLS mais sans vérification du certificat du serveur. On est donc protégé d'un attaquant se contentant d'observer la connexion, mais pas d'un équipement trafiquant les données (homme-du-milieu).

Résumé

Synthèse des attaques possibles selon la configuration

Serveur :

[network]
privatekey=/chemin/de/votre/clé/privée
cert=/chemin/de/la/chaine/de/certification/de/votre/clé
forceencryption=1
min-tls-version=1.2
cipherlist=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

Client : sqlcmd -N

Si vous hébergez des données très sensibles ou que votre serveur est accessible depuis internet, il vaut mieux payer une licence SQL Server et désactiver la remontée d'informations.

  • # Dans quel cas ?

    Posté par  (site Web personnel) . Évalué à 9.

    Bonjour,

    J'aurais juste une question basique qui ne concerne pas SQL SERVER directement mais …

    votre serveur est accessible depuis internet

    Dans quel cas de figure un serveur de base de données serait exposé depuis internet ?

    • [^] # Re: Dans quel cas ?

      Posté par  . Évalué à 2.

      Dans quel cas de figure un serveur de base de données serait exposé depuis internet ?

      Dans l'optique de participer à l'attaque de SQL Slammer peut-être ? Je reconnais, dans ce cas, que c'est un peu contradictoire à la sécurisation de SQL Server…

    • [^] # Re: Dans quel cas ?

      Posté par  . Évalué à 8.

      J'ai déjà vu des applications clientes qui devaient se connecter à un serveur SQL central à déployer «soi-même».
      Dans certaines entreprises, si des gens pas assez formés font ce genre de déploiement, cela va aboutir à un serveur SQL directement exposé pour que l'application marche pour tout le monde… Hé oui, tout le monde n'a pas encore compris le VPN. De plus, là c'est SQL Server qui écoute sur toutes les interfaces. Tu peux très bien avoir ton serveur avec eno0 (internet) et un tun0 (vpn), si on n'y prend garde le SQL server qui écoute sur les deux par méprise…

    • [^] # Re: Dans quel cas ?

      Posté par  . Évalué à 8.

      Dans quel cas de figure un serveur de base de données serait exposé depuis internet ?

      Dans le cas où on a besoin de s'y connecter depuis internet ?

      Il y a des applications dites "métier" écrites sous la forme d'un client lourd qui se connectent à un serveur SQL distant. Ce n'est probablement pas l'architecture qui serait choisie si le développement des applications concernés avait démarré cette année, mais toutes les applications ne datent pas de cette année.

      • [^] # Re: Dans quel cas ?

        Posté par  (site Web personnel) . Évalué à 3.

        mais toutes les applications ne datent pas de cette année

        Du bon code, ça dure au moins 20 ans !

      • [^] # Re: Dans quel cas ?

        Posté par  . Évalué à 1.

        Une architecture ça se change

        • [^] # Re: Dans quel cas ?

          Posté par  . Évalué à 2.

          Tout est possible, mais pour quel gain ?

          • [^] # Re: Dans quel cas ?

            Posté par  . Évalué à -1.

            Ne pas exposer sa BDD en direct sur internet

            • [^] # Re: Dans quel cas ?

              Posté par  . Évalué à 10.

              Ne pas exposer sa BDD en direct sur internet

              Quelle est la différence fondamentale entre exposer la BDD et exposer une API type REST qui donne accès à tout le contenu de la BDD ?
              Le pilote pour ta BDD sera probablement dispo dans tous les environnements de développement que tu pourras imaginer, sans même avoir besoin d'un générateur de code pour traduire ton API dans le langage ciblé, voire avec des composants avancés déjà disponibles (traduire une requête en modèle directement exploitable avec tes composants graphiques, par exemple).
              La BDD peut faire la gestion de l'authentification, en allant jusqu'au niveau de la ligne dans les tables (Row Level Security dans PostgreSQL, je suppose que SQL Server a un équivalent)
              La BDD peut faire abstraction des différents changements (vues, procédures stockées et fonctions, schémas séparés…)
              Qu'est-ce-qui ferait donc que fondamentalement, exposer une BDD avec un code lu, relu et rerelu, audité moultes fois, soit moins bien qu'exposer un service HTTP maison par dessus un serveur Web (lui aussi lu, relu etc) ?

              • [^] # Re: Dans quel cas ?

                Posté par  . Évalué à 2.

                je suppose qu'il souhaiterait que la bdd n'écoute que sur l'interface VPN.

                Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: Dans quel cas ?

                  Posté par  . Évalué à 6.

                  Si tu conçois une application distribuée au delà du réseau d'une entreprise, le VPN n'est pas nécessairement une option… À moins d'assimiler, par exemple, du TLS avec authentification du client par certificat à l'équivalent en sécurité du VPN…
                  Je pointais simplement que l'argument «la base de données doit être planquée sur un réseau privé» est plus proche du dogme que de l'argument étayé.

                  • [^] # Re: Dans quel cas ?

                    Posté par  . Évalué à 2. Dernière modification le 18/03/21 à 20:47.

                    Je pointais simplement que l'argument «la base de données doit être planquée sur un réseau privé» est plus proche du dogme que de l'argument étayé.

                    Ça dépend de ce que tu compares. Est-ce que tu compares une base de données + 1 service par dessus (type serveur web), tous les 2 exposés sur internet, à l'équivalent avec uniquement le service web exposé et la base en back-end privé ?
                    Dans ce cas, la solution avec la base planquée est clairement meilleure, elle diminue la surface d'attaque.

                    Par contre, si tu compares 1 base de données exposée directement par rapport à 1 base de donnés "planquée" avec 1 service par dessus qui l'expose, effectivement là les arguments sont moins évidents.

    • [^] # Re: Dans quel cas ?

      Posté par  (site Web personnel) . Évalué à 6.

      Dans quel cas de figure un serveur de base de données serait exposé depuis internet ?

      Dans le cloud Azure proposé par Microsoft, c'est l'option par défaut :

      • la base de données sur le cloud Azure SQL Database, exposé sur tout internet
      • l'application sur le cloud "web apps"

      L'authentification entre les 2 se fait soit via mot de passe, soit via authentification Azure Active Directory (exemple en .net). Dans cette dernière situation, la gestion des droits d'accès se fait dans l'Active Directory du cloud.

      • [^] # Re: Dans quel cas ?

        Posté par  (site Web personnel) . Évalué à 2.

        C'est marrant mais cela ne m'étonne pas de M$ :)

        mais laissons de coté les sarcasmes, trop facile, envers petitmou et soyons objectif …

        IMHO je prefere que l'éditeur se concentre sur les performances et les fonctionnalités de sa base de données que sur l'aspect sécuritaire.

        Et pour moi une base de données devrait être a l'abri derrière des parefeux et ne pas être accessible depuis le net.

        Tout comme n'importe quelle application, même codé correctement en prenant en compte l'aspect sécuritaire …

        En gros, si une faille de sécurité est découverte dans une base de données ou une application cela peut arriver … l'éditeur doit la corriger, mais la sécurité n'est pas forcément son activité principale et cela peut se comprendre. Difficile d'être bon partout

        C'est pour cette raison que l'accès a l'application et/ou à la base de données, pour moi, doit se faire via un VPN, au minimum, dont la raison d'être est la sécurité … cela me paraît logique.

        Je ne validerais jamais un accès direct depuis le net a une application ou une base de données dont le but premier n'est pas la sécurité.

        Il est possible de scier avec une lime et de limer avec une scie … tout dépend du niveau de résultat attendu :)

    • [^] # Re: Dans quel cas ?

      Posté par  . Évalué à 1.

      …Dans le cas d'applications claoudisées où les compétences disponibles ne permettent pas de faire/envisager du vpn par exemple.

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # pourquoi SQL server

    Posté par  . Évalué à 5.

    Peut-être une question naïve, mais dans quel cas voudrait-on préférer SQL server à ses concurrents (Oracle, Postgres). SQL server a t-il un quelconque avantage?

    • [^] # Re: pourquoi SQL server

      Posté par  . Évalué à 3.

      Si tu es maqué avec les technologies Microsoft, c'est un choix très intéressant : intégration avec un active directory, procédures stockées en C#, intégration avec visual studio… Cf. https://en.wikipedia.org/wiki/SQL_CLR pour la partie procédures stockées (et autres joyeusetés) en .net.

    • [^] # Re: pourquoi SQL server

      Posté par  . Évalué à 3.

      Par rapport à Oracle : principalement le prix. Pour une grosse installation, le prix des licences Oracle est ridiculement élevé, typiquement un ordre de grandeur au-dessus de l'équivalent en SQL Server.

      Par rapport à PostgreSQL : comme déjà mentionné, c'est le choix "naturel" quand on a déjà un environnement Microsoft ou qu'on développe en .Net, tous les outils sont conçus pour fonctionner ensemble et s'intègrent facilement. On a aussi un ensemble de fonctionnalités avancées disponibles en standard qui n'existent que sous forme d'outils externes pour PostgreSQL (au niveau de la réplication et haute disponibilité, par exemple, ou pour les données géographiques). Et pour les installations plus petites, il y a une version "Express", gratuite. Elle est évidemment très limitée (en particulier, il y a une limite sur la taille maximale de la db), mais ça reste suffisant dans beaucoup de cas.

      Pour avoir travaillé sur SQL Server, je dois dire que c'est un plutôt bon produit, que ça soit niveau fonctionnalités, stabilité, performance ou facilité d'utilisation.

      • [^] # Re: pourquoi SQL server

        Posté par  . Évalué à 2.

        Si tu es maqué avec les technologies Microsoft, c'est un choix très intéressant

        Si tu es maqué il faut essayer de te libérer plutôt que de t'enfermer encore plus non ?

        • [^] # Re: pourquoi SQL server

          Posté par  . Évalué à 2.

          Si tu es maqué il faut essayer de te libérer plutôt que de t'enfermer encore plus non ?

          Évidemment, mais la questions était bien «SQL server a-t-il un quelconque avantage ?», pas «produire un comparatif détaillé des avantages et inconvénients de SQL server» :)

          Globalement, si tu veux vraiment exploiter toutes les performances de ta base de données, tu seras très liée à elle. Dans le cas de SQL Server tu utiliseras les fonctionnalités comme .Net intégré, pour PostgreSQL ce sera le système de typage avancé type hstore/jsonb/ltree, les index gin/gist ou encore les trigrammes… (je suis DBA PostgreSQL, pas SQL Server, donc dur pour moi de faire une comparaison).

          • [^] # Re: pourquoi SQL server

            Posté par  . Évalué à 1.

            Oui mais moi je rebondissais sur "maqué aux technologies Microsoft" , celles qui te font choisir Sql Server…on est bien d'accord que une fois que tu as choisi une base tu peux être lié à elle.
            Mon propos était de dire que si tu n'es pas maqué avec les technologies Microsoft tu peux choisir une autre base , libre de préférence.

    • [^] # Re: pourquoi SQL server

      Posté par  (site Web personnel) . Évalué à 3.

      Je connais les 2 bases Oracle SQL SERVER dans des environnements de Production

      La question est plutôt pourquoi un éditeur ne choisi pas PostGRESQL et MySQL ?

      ORACLE est une excellente base de données, certainement une des plus avancèes techniquement parlant, mais cela se paye et très très cher.
      De plus la politique commerciale est une des pires que j'ai connues avec un mépris manifeste de certain de leur client.
      Oracle ou comment flinguer un bijou technologique par une politique commerciale absurde.

      SQLSERVER est une bonne base de données pour peu qu'elle soit gérée par des gens formés. (Oui malgré tout DBA est encore un métier …) son coté facile yakacliké est un leurre mais avec les ressources en adéquations des besoins et bien géré cela fonctionne.
      dernièrement elle a bénéficiée, en tout cas dans mon microcosme, de la politique commerciale d'oracle. Mais récemment je trouve qu'elle coute chere quand même sans pour autant offrir des fonctionnalités exceptionnelles.

      • [^] # Re: pourquoi SQL server

        Posté par  (site Web personnel) . Évalué à 1.

        Mon avis à 2 centimes comme simple utilisateur d'Oracle: la base de données est bien, mais les outils périphériques sont épouvantables!! Je l'utilise (enfin cela fait un moment que je n'ai pas fait de mise à jour, voir ci-dessous) depuis c++ via occi, en gros il est illusoire de vouloir déployer Oracle occi chez un utilisateur de base. Il faut choisir le bon package qui contienne occi (ce qui n'est pas toujours facile), puis installer un package à moitié cassé (liens symboliques cassés, fichiers pas toujours à un emplacement logique) et enfin espérer retrouver les éléments dont on à besoin car à chaque nouvelle version, l'arborescence change (par example la bibliothèque n'est plus au même endroit donc rien ne fonctionne). Et évidement, reconfigurer PATH et LDLIBRARY_PATH à chaque installation (du fait des points ci-dessus). Pendant quelques années j'ai refait un package propre du client Oracle pour Linux pour les utilisateurs de mon soft sans jamais avoir le courage de faire de même pour Mac et Windows et maintenant, j'ai même arrêté pour Linux…

        Si on ajoute les interactions avec le support… en gros, il faut installer d'autres outils Oracle (que l'on doit acheter) avant de renvoyer les résultats et diagnostiques demandés par le support pour enfin se voir répondre qu'ils ne savent pas et ils nous recontacterons (je l'ai vécu plusieurs fois, maintenant je ne prends même pas la peine de contacter le support).

        • [^] # Re: pourquoi SQL server

          Posté par  (site Web personnel) . Évalué à 2.

          IL faut que tu utilises l'instant client
          c'est fait pour ça …
          si tes besoins son juste de se connecter cela suffit amplement

          bien choisir la version car depuis qq années un instant_client ne peu servir que pour 2 versions

          en gros tu decompresse dans un répertoire puis tu cree un oracle.sh dans /etc/profile.d
          ou tu modifie ton .profile

          Ex:

          # Oracle
          ORACLE_BASE=/u/oracle/app
          ORACLE_HOME=$ORACLE_BASE/product/12.2.0/client_1   <= repertoire de l'instant_client
          LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib
          PATH=$PATH:$HOME/bin:$ORACLE_HOME/bin
          export PATH ORACLE_BASE ORACLE_HOME LD_LIBRARY_PATH
          
          # Si besoin
          ORACLE_SID=ORCL
          export ORACLE_SID
          

          apres c'est tout sqlplus system/manager@SERVEUR:1521/ORACLE_SID

          mais de toute facon change … la politique commerciale d'Oracle est a vomir

  • # Et c'est quoi la pratique en général ?

    Posté par  . Évalué à 3.

    J'ai un peu honte de le dire, mais je suis pas vraiment surpris.

    Et je me pose la question : c'est comment avec les autres SGBDR ? Oracle ? PostgreSQL ? MySQL/MariaDB ?

    J'installe pratiquement jamais de SGBDR from scratch, et je l'ai pas fait depuis très longtemps, mais de mémoire à chaque fois que j'ai installé un PostgreSQL, que ce soit sur Windows ou Linux, j'ai pas l'impression d'avoir eu à faire des trucs compliqués pour que le serveur soit accessible depuis une autre machine.

    Et comme dit par ailleurs, à part de rares cas d'architecture obsolète (client/serveur), on n'expose pas un serveur SQL sur internet. Ou même en dehors d'une DMZ à laquelle seule la couche applicative a accès.

    En grande entreprise, pour ce que j'en sais, c'est souvent :

    • Une DMZ data, avec les ports SQL standards ouverts par défaut pour tout ce qui vient de la DMZ métier
    • Une DMZ métier, accessible uniquement via des VIPs et par la couche présentation qui va bien
    • Une DMZ présentation, accessible uniquement via des VIPs et qui elle est ouverte vers le monde extérieur
    • [^] # Re: Et c'est quoi la pratique en général ?

      Posté par  . Évalué à 8.

      Et je me pose la question : c'est comment avec les autres SGBDR ? Oracle ? PostgreSQL ? MySQL/MariaDB ?

      Casquette de DBA PostgreSQL !

      Par défaut, les paramètres suivants sont appliqués dans PostgreSQL

      1) L'écoute par PG pour les connexions

      Il s'agit du paramètre listen_addresses, valorisé par défaut à localhost.
      Donc quand tu installes un PostgreSQL, sans opération volontaire ou altération par ton distributeur, il est impossible de s'y connecter depuis un autre endroit que la machine elle-même.
      https://www.postgresql.org/docs/current/runtime-config-connection.html

      2) L'authentification

      L'authentification est gérée par le fichier pg_hba.conf de PostgreSQL.
      https://www.postgresql.org/docs/13/auth-pg-hba-conf.html
      Le fichier par défaut est comme suit:

      # TYPE  DATABASE        USER            ADDRESS                 METHOD
      local   all             all                                     peer
      host    all             all             127.0.0.1/32            md5
      host    all             all             ::1/128                 md5
      
      local   replication     all                                     peer
      host    replication     all             127.0.0.1/32            md5
      host    replication     all             ::1/128                 md5
      

      En français :
      - les connexions classiques sont autorisées sur la socket UNIX pour les utilisateurs dont le login correspond à un utilisateur dans la base de données
      - les connexions classiques sont autorisées sur la loopback pour les utilisateurs identifiés par login/mot de passe dans la base de données
      - les connexions pour réplication sont autorisées de la même manière que les connexions classiques.

      Je ne répondrai pas pour les autres SGBDR, je laisse des spécialistes de ces derniers s'en charger.

      • [^] # Re: Et c'est quoi la pratique en général ?

        Posté par  . Évalué à 0. Dernière modification le 19/03/21 à 07:48.

        Tu serais pas en train de comparer un SGBD de qualité professionnel à un jouet quand même ?

        (j'ai le droit c'est vendredi!)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: Et c'est quoi la pratique en général ?

          Posté par  (site Web personnel) . Évalué à 3.

          C’est pas super honnête de qualifier le SQL Server de Microsoft de jouet, il y a des gens qui se reposent très sérieusement dessus dans leur activité professionnelle.

          • [^] # Re: Et c'est quoi la pratique en général ?

            Posté par  . Évalué à 3.

            Au vu de ma note, au moins trois personnes sont d'accord avec toi :D

            Mais blague à part, au vu de la conf par défaut, c'est à se demander si l'éditeur lui même ne le considère pas comme tel.

            Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Et c'est quoi la pratique en général ?

            Posté par  . Évalué à 2. Dernière modification le 21/03/21 à 17:43.

            L'un n'a jamais empêché l'autre ; il y a eu plein d'entreprise qui ont utilisé les ordinateurs domestiques à des fins professionnelles. (je ne parle pas que de l'époque Atari, puisqu'on a vu plus tard en entreprise plein de fenêtre xp puis vista qui n'étaient pas estampillées pro s'utiliser comme poste de travail pro… et récemment dans un grand groupe j'ai vu utiliser la version express de sql-server en production)

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Et c'est quoi la pratique en général ?

      Posté par  (site Web personnel) . Évalué à 4.

      Sur ma Debian, mariadb écoute en local par défaut. Dans le fichier /etc/mysql/mariadb.conf.d/50-server.conf, j'ai :

      # Instead of skip-networking the default is now to listen only on
      # localhost which is more compatible and is not less secure.
      bind-address            = 127.0.0.1
      
      [...]
      # * Security Features
      [...]
      # For generating SSL certificates you can use for example the GUI tool "tinyca".
      #
      #ssl-ca = /etc/mysql/cacert.pem
      #ssl-cert = /etc/mysql/server-cert.pem
      #ssl-key = /etc/mysql/server-key.pem
      #
      # Accept only connections using the latest and most secure TLS protocol version.
      # ..when MariaDB is compiled with OpenSSL:
      #ssl-cipher = TLSv1.2
      # ..when MariaDB is compiled with YaSSL (default in Debian):
      #ssl = on
      
      

      Par contre, avec YaSSL on est limité à TLSv1.1 et Debian utilise YaSSL depuis 2014, suite à des embrouilles de licence autour d'OpenSSL 😐 .

      • [^] # Re: Et c'est quoi la pratique en général ?

        Posté par  (site Web personnel) . Évalué à 4.

        Par contre, avec YaSSL on est limité à TLSv1.1 et Debian utilise YaSSL depuis 2014, suite à des embrouilles de licence autour d'OpenSSL 😐 .

        Sur Debian, mariadb-10.5 dépend bien de libssl-dev pour la construction des paquets binaires depuis les sources. Ça devrait être la version fournie avec la prochaine stable, Debian 11 Bullseye.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.