Quel est le niveau de risque de sécurité du schéma conceptuel publié?

Je demandais les schémas conceptuels au système d'information d'un organisme gouvernemental pour mes recherches. Ma demande a été refusée au motif qu'elle constituait un risque pour la sécurité.

Je n'ai pas vraiment d'expérience approfondie dans les bases de données, je ne peux donc pas vérifier cette affirmation. La divulgation de votre schéma représente-t-elle vraiment un risque de sécurité? Je veux dire, ceux-ci sont assez abstraits et séparés des implémentations matérielles et logicielles. Une explication de la façon dont un attaquant pourrait exploiter des schémas conceptuels serait appréciée. Merci.

D'accord avec gbn (donc +1), mais je pense qu'il y a deux autres possibilités en jeu:

1. Il est fort possible que leur schéma conceptuel se chevauche beaucoup avec leur schéma physique. La connaissance des noms de table vous donne une longueur d'avance décente dans la planification de vos attaques par injection SQL.

2. Il est très probable que leur schéma conceptuel ne soit pas documenté. Les organisations qui permettent aux programmeurs de concevoir leurs propres bases de données n'ont souvent aucune rigueur dans leur processus de conception de base de données, allant directement à l'implémentation physique sans aucune conception initiale. Il se peut qu'ils ne veuillent pas l'admettre, ou qu'ils ne veuillent pas passer le temps et les ennuis de recréer un document conceptuel qui n'a jamais existé.

Edit: OP a commenté que l'organisation demandée pour son schéma conceptuel est une agence gouvernementale. À mon avis, cela ajoute une autre possibilité probable:

Les fonctionnaires ne sont pas connus pour leur amour de la prise de risques et il est donc peu probable qu'un fonctionnaire de niveau intermédiaire dans un service gouvernemental leur tienne le cou et divulgue des informations au cas où cela pourrait attirer l'attention ou la colère de quelqu'un plus haut dans la hiérarchie. .

Je pense toujours que # 2 est le plus probable.

Je dirais que c'est un risque de propriété intellectuelle mais ils ne voulaient pas le dire

Je suis tout à fait d'accord pour dire que le schéma conceptuel derrière les informations secrètes doit également rester secret.

Si les espions collectent de petites informations qui glissent d'une manière ou d'une autre à travers les mailles du filet, il reste le problème de mettre ces informations en contexte. Le schéma conceptuel fournit le contexte. La forme et le contenu des friandises collectées peuvent être sensiblement différents de la forme et du contenu des données dans la base de données, mais le schéma simultané fournit un excellent guide pour décoder le contenu.

En travaillant sur la récupération de données pour les entreprises, j'ai toujours considéré un schéma conceptuel fiable comme une mine d'or. Certes, ces projets n'impliquaient pas d'espionnage. Mais peut facilement voir comment la même analyse se poursuit.

De nombreux fournisseurs essaient de garder leurs schémas de base de données près de leur poitrine. Le plus souvent, il s'agit de garder un couvercle sur leurs sales petits secrets comme le manque abject d'intégrité des données ou la mauvaise conception de la base de données. D'autres raisons incluent:

• De nombreux produits logiciels ont des schémas de base de données mal conçus.

• Désir de ne pas encourir de charge de travail de support.

• Tente de forcer les clients à acheter des services de conseil pour les travaux d'intégration de systèmes.

• Une volonté de maximiser les coûts de sortie pour décourager les clients de migrer vers les produits concurrents.

Malheureusement, vous ne travaillez pas pour le client, mais si vous l'étiez, vous pourriez utiliser un argument dans le sens de rechercher les défauts architecturaux du logiciel, de sorte que l'exposition du schéma de la base de données pourrait constituer un risque pour la sécurité.