5.1. Méthodes de sécurité

Les SGBD modernes prennent en charge l'une des deux approches répandues de la sécurité des données, à savoir une approche sélective ou une approche obligatoire. Dans les deux approches, l'unité de données ou « objet de données » pour lequel le système de sécurité doit être créé peut être soit la base de données entière, soit un ensemble de relations, soit une valeur de données pour un attribut donné au sein d'un tuple dans une certaine relation. Ces approches diffèrent par les propriétés suivantes :

1. Dans le cas d'un contrôle sélectif, un certain utilisateur dispose de droits différents (privilèges ou pouvoirs) lorsqu'il travaille avec différents objets. De plus, différents utilisateurs ont généralement des droits d'accès différents au même objet. Par conséquent, les schémas électoraux se caractérisent par une flexibilité considérable.

2. Dans le cas du contrôle obligatoire, au contraire, chaque objet de données se voit attribuer un certain niveau de classification et chaque utilisateur dispose d'un certain niveau de sécurité. Par conséquent, avec cette approche, seuls les utilisateurs disposant du niveau de sécurité approprié ont accès à un objet de données spécifique. Par conséquent, les schémas requis sont assez rigides et statiques.

Quels que soient les schémas utilisés - sélectifs ou obligatoires, toutes les décisions concernant l'admission des utilisateurs à effectuer certaines opérations sont prises à un niveau stratégique et non technique. Par conséquent, ils sont hors de portée du SGBD lui-même, et tout ce que le SGBD peut faire dans une telle situation est seulement d'activer les décisions déjà prises plus tôt. Sur cette base, on peut noter ce qui suit :

D'abord. Les résultats des décisions stratégiques doivent être connus du système (c'est-à-dire exécutés sur la base d'assertions données dans un langage approprié) et y être stockés (en les stockant dans un répertoire en tant que règles de sécurité, également appelées autorisations).

En deuxième. De toute évidence, il devrait y avoir des moyens de réglementer les demandes d'accès en fonction des règles de sécurité pertinentes. (Ici, "demande, accès" signifie la combinaison de l'opération demandée, de la demande, de l'objet et de l'utilisateur demandeur.) Cette vérification est effectuée par le sous-système de sécurité du SGBD, également appelé sous-système d'autorisation.

Troisièmement. Afin de comprendre quelles règles de sécurité s'appliquent à quelles demandes d'accès, le système doit fournir des moyens d'identifier la source de cette demande, c'est-à-dire l'identification de l'utilisateur demandeur. Par conséquent, au moment de la connexion au système, l'utilisateur doit généralement saisir non seulement son identifiant (par exemple, son nom ou sa fonction), mais également un mot de passe (pour confirmer ses droits sur les données d'identification précédemment déclarées). On suppose généralement que le mot de passe n'est connu que du système et de certaines personnes disposant de droits spéciaux.

Concernant le dernier point, il convient de noter que différents utilisateurs peuvent avoir le même identifiant pour un certain groupe. Ainsi, le système peut prendre en charge des groupes d'utilisateurs et fournir les mêmes droits d'accès aux utilisateurs d'un même groupe, par exemple, pour toutes les personnes du service facturation. De plus, les opérations d'ajout ou de suppression d'utilisateurs individuels à un groupe peuvent être effectuées indépendamment de l'opération de définition de privilèges pour ce groupe. Notez, cependant, que les informations d'appartenance au groupe sont également stockées dans le répertoire système (ou éventuellement dans une base de données).

Les techniques de contrôle d'accès ci-dessus font en fait partie d'une classification plus générale des niveaux de sécurité. Tout d'abord, ces documents définissent quatre classes de sécurité - D, C, B et A. Parmi elles, la classe D est la moins sécurisée, la classe C est plus sécurisée que la classe D, et ainsi de suite. La classe D offre une protection minimale, la classe C est sélective, la classe B est obligatoire et la classe A est une protection éprouvée.

Protection sélective. La classe C est divisée en deux sous-classes, C1 et C2 (où la sous-classe C1 est moins sécurisée que la sous-classe C2), qui prennent en charge le contrôle d'accès sélectif dans le sens où le contrôle d'accès est à la discrétion du propriétaire des données.

La classe C1 requiert la séparation des données et de l'utilisateur, c'est-à-dire En plus de soutenir le concept d'accès mutuel aux données, il est également possible ici d'organiser l'utilisation séparée des données par les utilisateurs.

Selon les exigences de la classe C2, il est nécessaire d'organiser en plus la comptabilité sur la base de procédures de connexion au système, d'audit et d'isolement des ressources.

Protection obligatoire. La classe B contient des exigences pour les méthodes de contrôle d'accès obligatoires et est divisée en trois sous-classes - B1, B2 et B3 (où B1 est la moins sécurisée et B3 est la sous-classe la plus sécurisée).

La classe B1 requiert une « sécurité marquée » (ce qui signifie que chaque objet de données doit contenir une note sur son niveau de classification, par exemple : secret, à usage officiel, etc.), ainsi qu'un message informel sur la stratégie de sécurité actuelle.

Selon les exigences de la classe B2, il est en outre nécessaire de fournir une déclaration formelle sur la stratégie de sécurité actuelle, ainsi que de détecter et d'exclure les canaux de transmission d'informations mal protégés.

La classe B3 nécessite un support supplémentaire pour l'audit et la récupération des données, ainsi que la désignation d'un administrateur du mode de sécurité.

Protection éprouvée. La classe A est la plus sécurisée et, selon ses exigences, une preuve mathématique est requise que cette méthode d'assurance de la sécurité est compatible et adéquate à la stratégie de sécurité donnée.

Bien que certains SGBD commerciaux offrent une protection obligatoire au niveau B1, ils fournissent généralement un contrôle sélectif au niveau C2.

5.2. Contrôle d'accès sélectif

Le contrôle d'accès sélectif est pris en charge par de nombreux SGBD. Le contrôle d'accès sélectif est pris en charge dans SQL.

En général, le système de sécurité d'un tel SGBD repose sur trois composants :

1. Utilisateurs. Le SGBD effectue toute action avec la base de données au nom d'un utilisateur. Chaque utilisateur se voit attribuer un identifiant - un nom court qui identifie de manière unique l'utilisateur dans le SGBD. Un mot de passe est utilisé pour confirmer que l'utilisateur peut travailler avec l'identifiant saisi. Ainsi, l'identification et l'authentification de l'utilisateur s'effectuent à l'aide de l'identifiant et du mot de passe. La plupart des SGBD commerciaux vous permettent de regrouper les utilisateurs avec les mêmes privilèges en groupes - cela simplifie le processus d'administration.

2. Objets de base de données. Selon la norme SQL2, les objets sécurisables dans une base de données sont des tables, des vues, des domaines et des jeux de caractères définis par l'utilisateur. La plupart des SGBD commerciaux étendent la liste des objets en ajoutant des procédures stockées et d'autres objets.

3. Privilèges. Les privilèges montrent un ensemble d'actions pouvant être effectuées sur un objet. Par exemple, l'utilisateur a le privilège d'afficher la table.

5.3. Contrôle d'accès obligatoire

Des techniques de contrôle d'accès obligatoires sont appliquées aux bases de données dans lesquelles les données sont de structure assez statique ou rigide, comme dans les organisations gouvernementales ou militaires. Comme déjà noté, l'idée de base est que chaque objet de données a un certain niveau de classification, par exemple : secret, top secret, à usage officiel, etc., et chaque utilisateur a un niveau de sécurité avec les mêmes gradations que dans la classification de niveau. On suppose que ces niveaux forment un ordre hiérarchique strict, par exemple : top secret ® secret ® à usage officiel, etc. Ensuite, sur la base de ces informations, deux règles de sécurité très simples peuvent être formulées :

1.Un utilisateur n'a accès à un objet que si son niveau d'autorisation est supérieur ou égal au niveau de classification de l'objet.

2. Un utilisateur ne peut modifier un objet que si son niveau d'autorisation est égal au niveau de classification de l'objet.

La règle 1 est assez évidente, et la règle 2 nécessite des éclaircissements supplémentaires. Tout d'abord, il convient de noter que d'une autre manière la deuxième règle peut être formulée comme suit : toute information enregistrée par un utilisateur acquiert automatiquement un niveau égal au niveau de classification de cet utilisateur. Une telle règle est nécessaire, par exemple, pour éviter qu'une donnée secrète ne soit écrite par un utilisateur avec le niveau d'autorisation "secret" dans un fichier avec un niveau de classification inférieur, ce qui viole l'ensemble du système de secret.

Récemment, les méthodes de contrôle d'accès obligatoires se sont généralisées. Les exigences d'un tel contrôle d'accès sont énoncées dans deux documents, appelés officieusement le Livre Orange et le Livre Lavande. Le livre orange répertorie un ensemble d'exigences de sécurité pour une base informatique de confiance, et le livre rose fournit une interprétation de ces exigences pour les systèmes de gestion de bases de données.

5.4. Cryptage des données

Jusqu'à présent, il a été supposé dans ce chapitre que l'utilisateur malveillant présumé tentait de pénétrer illégalement dans la base de données en utilisant des informations d'identification système normales. Nous devons maintenant considérer le cas où un tel utilisateur essaie d'entrer dans la base de données en contournant le système, c'est-à-dire déplacer physiquement une partie de la base de données ou se connecter à un canal de communication. La méthode la plus efficace pour faire face à de telles menaces est le cryptage des données, c'est-à-dire stockage et transmission de données particulièrement importantes sous forme cryptée.

Certains nouveaux concepts devraient être introduits pour discuter des concepts de base de l'encodage des données. Les données d'origine (non codées) sont appelées texte brut. Le texte brut est crypté à l'aide d'un algorithme de cryptage spécial. Les données d'entrée d'un tel algorithme sont le texte en clair et la clé de cryptage, et la sortie est la forme cryptée du texte en clair, appelée texte chiffré. Si les détails de l'algorithme de chiffrement peuvent être rendus publics, ou du moins non gardés secrets, alors la clé de chiffrement est nécessairement tenue secrète. C'est le texte chiffré, incompréhensible pour ceux qui ne possèdent pas la clé de chiffrement, qui est stocké dans la base de données et transmis sur le canal de communication.

5.5. Piste d'audit des opérations effectuées

Il est important de comprendre qu'il n'y a pas de systèmes de sécurité invulnérables, car un intrus potentiel persistant peut toujours trouver un moyen de surmonter tous les systèmes de contrôle, surtout si une récompense suffisamment élevée est offerte pour cela. Par conséquent, lorsque vous travaillez avec des données très importantes ou lorsque vous effectuez des opérations critiques, il devient nécessaire d'enregistrer une piste d'audit des opérations effectuées. Si, par exemple, des données incohérentes conduisent à soupçonner qu'une falsification non autorisée de la base de données a été commise, la piste d'audit doit être utilisée pour clarifier la situation et confirmer que tous les processus sont sous contrôle. Si ce n'est pas le cas, alors la piste d'audit aidera au moins à identifier l'intrus.

Pour enregistrer la piste d'audit, un fichier spécial est généralement utilisé, dans lequel le système enregistre automatiquement toutes les opérations effectuées par les utilisateurs lorsqu'ils travaillent avec une base de données ordinaire. Une entrée de fichier de piste d'audit typique peut contenir des informations comme celle-ci :

2. le terminal à partir duquel l'opération a été appelée ;

3. l'utilisateur qui a spécifié l'opération ;

4. date et heure du début de l'opération ;

5. les relations de base, les tuples et les attributs impliqués dans le processus d'exécution de l'opération ;

6. anciennes valeurs ;

7. nouvelles valeurs.

Comme mentionné précédemment, même une déclaration du fait qu'un système donné prend en charge le suivi de surveillance est dans certains cas très essentiel pour empêcher l'entrée non autorisée dans le système.

5.6. Prise en charge de la sécurité SQL

La norme SQL actuelle ne prend en charge que le contrôle d'accès sélectif. Il est basé sur deux parties plus ou moins indépendantes de SQL. L'un s'appelle un moteur de présentation, qui (comme indiqué ci-dessus) peut être utilisé pour masquer des données hautement sensibles aux utilisateurs non autorisés. Un autre est appelé sous-système de pouvoirs et donne à certains utilisateurs le droit d'attribuer de manière sélective et dynamique différents pouvoirs à d'autres utilisateurs, et également de retirer ces pouvoirs si nécessaire.

5.7. Directives GRANT et REVOKE

Le mécanisme de représentation du langage SQL vous permet de diviser la base de données en plusieurs parties de différentes manières afin que certaines informations soient cachées aux utilisateurs qui n'ont pas les droits d'accès. Cependant, ce mode n'est pas paramétré à partir des paramètres des opérations, à partir desquels des utilisateurs autorisés effectuent certaines actions avec une donnée donnée. Cette fonction (comme indiqué ci-dessus) est exécutée à l'aide de la directive GRANT.

Notez que le créateur de tout objet se voit automatiquement accorder tous les privilèges sur cet objet.

La norme SQL1 définit les privilèges suivants pour les tables :

1. SELECT - vous permet de lire les données d'une table ou d'une vue ;

INSERT - vous permet d'insérer de nouveaux enregistrements dans une table ou une vue ;

MISE À JOUR - vous permet de modifier les enregistrements d'une table ou d'une vue ;

SUPPRIMER - vous permet de supprimer des enregistrements d'une table ou d'une vue.

La norme SQL2 a étendu la liste des privilèges pour les tables et les vues :

1. INSERT pour les colonnes individuelles, comme le privilège UPDATE ;

2. RÉFÉRENCES - pour la prise en charge des clés étrangères.

En plus de ce qui précède, a ajouté le privilège USAGE pour d'autres objets de base de données.

De plus, la plupart des SGBD commerciaux prennent en charge des privilèges supplémentaires, par exemple :

1. ALTER - permet de modifier la structure des tables (DB2, Oracle);

2. EXECUTER - vous permet d'exécuter des procédures stockées.

Le créateur de l'objet obtient également le droit d'accorder des privilèges d'accès à un autre utilisateur à l'aide de l'instruction GRANT. Voici la syntaxe d'une instruction GRANT :

GRANT (SELECT | INSERT | DELETE | (colonne UPDATE, ...)), ...

ON TO table (utilisateur | PUBLIC)

Les privilèges INSERT et UPDATE (mais pas les privilèges SELECT, ce qui est plutôt étrange) peuvent être définis sur des colonnes spécialement définies.

Si la directive WITH GRANT OPTION est spécifiée, cela signifie que les utilisateurs spécifiés ont des autorisations spéciales pour l'objet spécifié - le droit d'accorder des autorisations. Ceci, à son tour, signifie qu'ils peuvent autoriser d'autres utilisateurs à travailler avec cet objet.

Par exemple : accordez à l'utilisateur Ivanov le droit de sélectionner et de modifier les noms de famille dans la table Étudiants avec le droit d'accorder le droit.

GRANT SELECT, UPDATE StName

SUR Étudiants À Ivanov AVEC OPTION DE SUBVENTION

Si l'utilisateur A accorde certains privilèges à un autre utilisateur B, il peut ensuite révoquer ces privilèges pour l'utilisateur B. La révocation des privilèges est effectuée à l'aide de la directive REVOKE avec la syntaxe suivante.

RÉVOQUER ((SÉLECTIONNER | INSÉRER | SUPPRIMER | MISE À JOUR),… | TOUS LES PRIVILÈGES)

ON table,… FROM (utilisateur | PUBLIC),… (CASCADE | RESTRICT)

Étant donné que l'utilisateur dont le privilège est révoqué aurait pu l'accorder à un autre utilisateur (s'il avait le droit d'accorder des privilèges), une situation de privilèges abandonnés peut survenir. L'objectif principal des paramètres RESTRICT et CASCADE est d'empêcher l'abandon de privilèges. En définissant le paramètre RESTRICT, une opération de révocation de privilège est empêchée si elle aboutit à un privilège déprécié. Le paramètre CASCADE indique la révocation séquentielle de tous les privilèges dérivés de celui-ci.

Par exemple : retirez à l'utilisateur Ivanov le droit de modifier les noms de famille dans la table Etudiants. Supprimez également ce privilège de tous les utilisateurs auxquels il a été accordé par Ivanov.

SUR Étudiants D'Ivanov CASCADE

Lorsque vous supprimez un domaine, une table, une colonne ou une vue, tous les privilèges sur ces objets de tous les utilisateurs seront également automatiquement supprimés.

5.8. Vues et sécurité

En créant des vues et en accordant aux utilisateurs l'autorisation d'y accéder plutôt que la table d'origine, vous pouvez restreindre l'accès des utilisateurs aux colonnes ou enregistrements spécifiés uniquement. Ainsi, les vues vous permettent d'exercer un contrôle complet sur les données disponibles pour un utilisateur particulier.

Conclusion

Pour minimiser les risques de pertes, il est nécessaire de mettre en œuvre un ensemble de mesures de protection réglementaires, organisationnelles et techniques, tout d'abord : la mise en place d'un contrôle d'accès basé sur les rôles, l'organisation des accès des utilisateurs sur présentation d'un certificat numérique, et dans le avenir proche - une solution industrielle pour le cryptage sélectif et l'utilisation d'algorithmes GOST pour crypter la base de segments sélectionnés.

Pour résoudre complètement le problème de la protection des données, l'administrateur de sécurité doit être capable de surveiller les actions des utilisateurs, y compris ceux avec des droits d'administrateur. Étant donné que le système d'audit régulier ne dispose pas de mesures de sécurité suffisantes, un système indépendant est nécessaire pour protéger le réseau de l'entreprise non seulement de l'extérieur, mais aussi de l'intérieur. À l'avenir, des techniques standard devraient également apparaître pour une solution globale au problème de la protection des bases de données pour les entreprises de différentes tailles - des plus petites aux plus réparties géographiquement.

La première partie de l'article est consacrée aux innovations en matière de contrôle d'accès aux données et aux services. La suite de l'article est consacrée à la minimisation des privilèges pour le code exécutable, au chiffrement du trafic et des données dans SQL Server 2005, ainsi qu'à certains autres aspects de la sécurité de ce SGBD. La troisième partie de l'article fournit des conseils pour les administrateurs réseau et les développeurs d'applications, ainsi que les outils de sécurité des différentes éditions de SQL Server par rapport à d'autres SGBD. Le but de cet article est d'attirer l'attention des administrateurs de bases de données et des spécialistes de la sécurité de l'information sur ce problème et de montrer l'une des options pour mettre en œuvre une attaque contre le SGBD MS SQL, à la suite de laquelle un intrus potentiel aura accès non seulement à les informations stockées dans la base de données, mais aussi un contrôle total sur le serveur SGBD. La sécurisation des bases de données d'entreprise est l'un des sujets les plus brûlants aujourd'hui. Et cela est compréhensible. Cependant, le paradoxe est qu'avec une grande attention à la protection des bases de données de l'extérieur, beaucoup oublient de les protéger de l'intérieur. Après la tragédie du 11 septembre, le gouvernement américain a commencé à mettre en œuvre un large éventail de mesures pour prévenir les attaques terroristes. L'une de ces mesures consiste à soutenir le développement et la mise en œuvre de l'informatique pour identifier et appréhender les individus suspects, et pour réduire le risque de menaces à la sécurité et prévenir les situations qui pourraient conduire à de telles attaques. L'un des éléments technologiques requis, en particulier pour prévenir les manifestations de terrorisme, est la technologie des bases de données. Typiquement, cette tâche est confiée à des administrateurs de bases de données qui n'ont ni le temps ni la formation nécessaire pour cela. En quoi consiste la journée de travail d'un DBA ? Bien sûr, tout dépend du type de réponse que vous souhaitez obtenir - courte ou détaillée. La réponse longue s'étendra sur des kilomètres : installation, mise à niveau, planification des performances, réglage, garantie de la santé des applications et restauration des données à partir des sauvegardes. Ce ne sont que les premiers points de la liste, elle n'inclut pas les mesures urgentes qui doivent être prises au quotidien. Dans les conditions modernes, toute activité est associée à l'exploitation de grandes quantités d'informations, qui sont effectuées par un large éventail de personnes. La protection des données contre les accès non autorisés est l'une des tâches prioritaires dans la conception de tout système d'information. L'augmentation récente de l'importance de l'information a entraîné des exigences élevées en matière de confidentialité des données. Les systèmes de gestion de bases de données, en particulier les SGBD relationnels, sont devenus l'outil dominant dans ce domaine. Assurer la sécurité de l'information d'un SGBD devient crucial lors du choix d'un moyen spécifique d'assurer le niveau de sécurité requis pour une organisation dans son ensemble. SI UNE ENTREPRISE EST CHER POUR SA PROPRIÉTÉ INTELLECTUELLE, ET CHAQUE EMPLOYÉ PEUT OBTENIR FACILEMENT L'INFORMATION NÉCESSAIRE (ET PAS PLUS), L'ENTREPRISE PEUT ESPÉRER UNE AUGMENTATION DE LA PRODUCTIVITÉ. MAIS SI LES DONNÉES NE SONT PAS COMMANDÉES, ALORS, MALGRÉ L'ENTHOUSIASME DES EMPLOYÉS, DANS LA PLUPART DES CAS, L'ENTREPRISE S'ATTEND À L'ÉCHEC. Presque aucune entreprise moderne ne peut se passer de l'utilisation de bases de données. Dans le cas le plus simple, pour stocker de petites quantités de données, Microsoft Access peut être utilisé comme système de gestion de base de données (SGBD).

Lors de la conception de systèmes d'information à des fins diverses pour stocker de grandes et très grandes quantités d'informations, les concepteurs font généralement un choix en faveur d'un SGBD relationnel. C'est la pratique établie. Aux stades ultérieurs de la conception et du développement, assurer la sécurité de la base de données (le noyau de l'ensemble du système) revient généralement à identifier les catégories d'utilisateurs, leurs besoins en informations et leurs privilèges (ces étapes et plusieurs autres sont incluses dans la formation d'un politique de sécurité) et la conception d'un système de contrôle d'accès.

De plus, pour attribuer / révoquer des privilèges, le langage SQL est utilisé, qui inclut les instructions GRANT, REVOKE, etc.. La plupart des SGBD relationnels modernes prennent en charge les modèles de contrôle d'accès discrétionnaire (DAC) et obligatoire (MAC), ainsi que des outils de sécurité supplémentaires.

A toutes les étapes du cycle de vie d'un système d'information construit sur la base d'un SGBD relationnel, un grand nombre de menaces de différentes classes sont possibles. Ces capacités découlent à la fois des propriétés du modèle de données relationnelles lui-même et des caractéristiques de la mise en œuvre du SGBD par divers fabricants et du modèle de contrôle d'accès utilisé. La protection des informations dans les bases de données relationnelles est spécifique en ce que la sémantique des données traitées offre de plus grandes possibilités de mise en œuvre de diverses menaces par rapport à la base de données. disons au système de fichiers.

Une menace est généralement comprise comme un événement, une action (impact), un processus ou un phénomène potentiellement possible qui peut nuire aux intérêts de quelqu'un.

Menace de sécurité de l'information pour le système d'information automatisé (AIS) appelons la possibilité d'influencer les informations traitées dans le système, conduisant à la distorsion, la destruction, la copie, le blocage d'accès

à l'information, ainsi que la possibilité d'influencer les composants du système d'information, entraînant la perte, la destruction ou la défaillance du fonctionnement du support d'information ou des moyens de contrôler l'ensemble logiciel et matériel du système.

La menace de violation de la confidentialité des données comprend toute divulgation volontaire ou accidentelle d'informations stockées dans un système informatique ou transférées d'un système à un autre. La violation de la confidentialité est causée à la fois par une action délibérée visant à mettre en œuvre un accès non autorisé aux données et par une erreur accidentelle de l'action d'un opérateur programmatique ou non qualifié, qui a conduit à la transmission d'informations confidentielles non protégées par des canaux de communication ouverts.

La menace d'atteinte à l'intégrité comprend toute modification délibérée ou accidentelle des informations traitées dans le système d'information ou saisies à partir de la source de données primaire. La violation de l'intégrité des données peut être causée soit par une action destructrice délibérée d'une personne qui modifie les données pour atteindre ses propres objectifs, soit par une erreur logicielle ou matérielle accidentelle ayant entraîné une destruction irréversible des données.

La première étape de l'analyse des menaces consiste à les identifier. Les types de menaces envisagées doivent être sélectionnés sur la base de considérations de bon sens (à l'exclusion, par exemple, des tremblements de terre, mais sans oublier la possibilité de saisie de l'organisation par des terroristes), mais au sein des types sélectionnés, effectuer l'analyse la plus détaillée.

A noter qu'il faut non seulement effectuer des travaux d'identification et d'analyse des menaces elles-mêmes, mais aussi étudier et décrire les sources des menaces identifiées. Cette approche aidera à choisir un ensemble d'équipements de protection. Par exemple, des connexions illégales peuvent résulter de la lecture d'un dialogue initial, de la devinette d'un mot de passe ou de la connexion d'équipements non autorisés au réseau. Évidemment, pour contrer chacune des méthodes d'entrée illégales répertoriées, vous avez besoin de ses propres mécanismes de sécurité.

2.1. Sources de menaces pour les informations de la base de données

Le développement d'un système de sécurité de l'information devrait être basé sur une certaine liste de menaces potentielles pour la sécurité et l'établissement de sources possibles de leur apparition. La conception d'un système de sécurité spécifique pour toute installation, y compris pour les systèmes de bases de données, implique l'identification et la classification scientifique de la liste des sources de menaces pour la sécurité.

Formulons une liste des menaces externes et internes à la sécurité de l'information des bases de données.

Les facteurs de déstabilisation externes qui créent des menaces de sécurité pour le fonctionnement des systèmes de bases de données et des SGBD sont :

Actions intentionnelles et destructrices de personnes dans le but de déformer, détruire ou voler des programmes, des données et des documents du système, qui sont causées par des violations de la sécurité de l'information de l'objet protégé ;

Des distorsions dans les canaux de transmission des informations provenant de sources externes circulant dans le système et transmises aux consommateurs, ainsi que des valeurs inadmissibles et des changements dans les caractéristiques des flux d'informations provenant de l'environnement externe et au sein du système ;

Défaillances et défaillances des équipements informatiques ;

Virus et autres éléments logiciels destructeurs distribués à l'aide de systèmes de télécommunication qui assurent la communication avec l'environnement externe ou les communications internes d'un système de base de données distribué ;

Les changements dans la composition et la configuration du complexe d'équipements en interaction du système dépassent les limites vérifiées lors des tests ou de la certification du système.

Les sources internes de menaces pour la sécurité des bases de données et des SGBD sont :

Erreurs du système dans la définition des buts et objectifs de la conception des systèmes d'information automatisés et de leurs composants, commises lors de la formulation des exigences pour les fonctions et les caractéristiques des moyens de sécurité du système ;

Erreurs dans la détermination des conditions et paramètres de fonctionnement de l'environnement externe dans lequel le système d'information doit être utilisé et, en particulier, les logiciels et matériels de protection des données ;

Erreurs de conception dans le développement et la mise en œuvre d'algorithmes de sécurité pour le matériel, les logiciels et les bases de données ;

Erreurs et actions non autorisées des utilisateurs, du personnel administratif et de maintenance pendant le fonctionnement du système ;

Efficacité insuffisante des méthodes et moyens utilisés pour assurer la sécurité de l'information dans des conditions de fonctionnement normales ou particulières du système.

L'élimination complète de toutes les menaces potentielles à la sécurité de l'information des bases de données est fondamentalement impossible. La vraie tâche est de réduire la probabilité que des menaces potentielles se réalisent à un niveau acceptable pour un système particulier. L'acceptabilité du niveau de menace approprié peut être déterminée par la portée, le budget alloué ou la loi applicable. En règle générale, il n'est pas possible de construire un arbre des menaces avec une hiérarchie stricte. Par conséquent, le risque cumulé est une fonction assez complexe de la vulnérabilité des composants du système. Diverses influences négatives affectent également les caractéristiques de base de la qualité et de la sécurité des systèmes de bases de données d'une manière assez complexe.

Le principe directeur principal pour la conception des systèmes de protection est le principe de résistance égale. Les ressources disponibles qui assurent la sécurité de l'information du système doivent être allouées de manière à minimiser certains indicateurs de risque généralisés pour tout impact externe et interne négatif sur le système. La présence de menaces dans le système, pour une protection contre laquelle le système ne prévoit aucune contre-mesure, conduit au fait que tous les efforts déployés pour ériger des barrières efficaces contre d'autres méthodes d'impact destructeur sur le système ne conduiront pas au résultat attendu. Une conclusion pratique importante en découle : la comptabilisation des menaces doit être complète et pour chacune des menaces possibles, une méthode de menace correspondante doit être mise en œuvre.

2.2. Classification des menaces à la sécurité de l'information des bases de données

Afin d'assurer un certain niveau de sécurité des systèmes d'information, il est nécessaire de comprendre la nature des menaces émergentes, les principales méthodes qui assurent la réduction du niveau de vulnérabilité d'un système ou d'une technologie, et le coût des solutions correspondantes, en corrélation avec le niveau de sécurité fourni par la solution.

Le manque de sensibilisation des décideurs à la nature des menaces, ainsi qu'à l'objectif et aux caractéristiques des méthodes de sécurité conduit à des idées fausses largement répandues.

La mise en œuvre d'une analyse complète des menaces à la sécurité de l'information de tout objet, y compris les systèmes de bases de données, nécessite une classification. La classification scientifique est basée sur l'analyse de l'expérience antérieure, réunit des cas dont le contenu est similaire aux sections mises en évidence du classificateur. Quelle que soit l'approche adoptée pour définir la sécurité, la classification des menaces et de leurs sources est d'un intérêt indépendant. La présence de diverses classifications permet au chercheur de ne pas rater une menace importante pour un système spécifique parmi une riche liste de menaces pour la sécurité de l'information des bases de données.

Le problème d'assurer la sécurité de l'information des bases de données est multiforme. Les bases de données elles-mêmes sont un modèle du monde réel, qui est infiniment diversifié. La conception et la maintenance des systèmes de bases de données nécessitent un traitement des données logiciel et matériel moderne et des schémas et structures de gestion organisationnelle plutôt complexes. Par conséquent, vous pouvez choisir de nombreux motifs pour classer les menaces de sécurité de l'information dans les bases de données. Étant donné le taux élevé de changement dans les industries de l'informatique et des télécommunications, il faut bien comprendre que la classification présentée n'est probablement pas exhaustive.

L'analyse de la littérature scientifique moderne a permis d'identifier les options de classification suivantes pour les menaces possibles aux violations de la sécurité de l'information des bases de données.

Classement par objectifs de la mise en œuvre des menaces :

1. Violation de la confidentialité des informations, c'est-à-dire l'utilisation des informations stockées dans le système par des personnes ou des processus qui n'ont pas été identifiés par les propriétaires des informations.

2. Violation de l'intégrité de l'information, c'est-à-dire modification ou destruction de l'information pour la dévaloriser en perdant la conformité avec l'état des entités modélisées du monde réel.

3 Perturbation totale ou partielle des performances du système en raison de la défaillance ou du changement incorrect des modes de fonctionnement des composants du système, y compris leur modification ou leur remplacement.

Classement par nature de l'événement des menaces:

1. Menaces naturelles - menaces causées par l'impact sur le système de base de données et ses composants de processus physiques objectifs ou de phénomènes naturels se développant spontanément.

2. Menaces artificielles - menaces à la sécurité de l'information des systèmes de bases de données associées aux activités humaines.

Classement par localisation des sources la menace se présente comme suit :

1. Menaces dont la source directe est une personne :

Divulgation, transfert ou perte d'attributs de contrôle d'accès (mots de passe, clés de cryptage, serrures électroniques, etc.) par les utilisateurs légaux du système ;

Corruption ou chantage du personnel de service ou des utilisateurs ayant l'autorité nécessaire afin d'obtenir leurs paramètres pour les procédures d'authentification ;

Copie de données confidentielles par un utilisateur légal du système à des fins d'utilisation illégale (vente, chantage, etc.) ;

Piratage du système de sécurité afin d'effectuer des actions destructrices par une personne qui n'est pas un utilisateur légitime du système ;

L'introduction d'agents d'entreprises concurrentes ou d'organisations criminelles dans le personnel de service du système d'information attaqué (dont le groupe administratif, le groupe de sécurité de l'information).

2. Menaces dont la source directe sont les logiciels et matériels standards du système d'information :

Utilisation non qualifiée ou saisie erronée des paramètres du programme pouvant entraîner une perte totale ou partielle des performances du système (arrêt anormal des processus du système, gaspillage inapproprié de ressources informatiques, etc.) ;

Utilisation non qualifiée ou saisie erronée des paramètres du programme pouvant entraîner des modifications irréversibles du système (initialisation des bases de données, formatage ou restructuration des supports de stockage, suppression des données, etc.) ;

Défaillances et dysfonctionnements du système d'exploitation, du SGBD et des programmes d'application.

3. Menaces dont la source directe sont des logiciels et du matériel non autorisés :

Introduction et utilisation illégales de programmes qui ne sont pas nécessaires au contrevenant pour exercer ses fonctions officielles ;

Introduction illégale (en raison de la négligence d'un utilisateur légal) et utilisation de chevaux de Troie conçus pour enquêter sur les paramètres d'un système d'information automatisé, collecter des données, zombifier un ordinateur avec une mauvaise utilisation ultérieure des ressources, etc. ;

Infection d'un ordinateur par des virus aux fonctions destructrices ;

Fonctionnement de générateurs de bruit et de sources similaires de rayonnement électromagnétique.

4. Menaces dont la source directe est l'habitat :

Arrêt soudain et prolongé des systèmes d'alimentation électrique ;

Catastrophes technologiques et naturelles;

Explosions de rayonnement électromagnétique naturel.

Classement par l'emplacement de la source des menaces.

1. Menaces dont la source est située en dehors de la zone contrôlée de l'emplacement du système d'information automatisé :

Perturbation du fonctionnement normal ou destruction des systèmes de survie des bâtiments dans lesquels se trouvent les moyens techniques et le personnel de service du système ;

Blocage de l'accès physique au site du système automatisé pour le personnel de service ou les utilisateurs ;

Perturbation du fonctionnement normal ou destruction des canaux de communication externes (lignes filaires, canaux radio, fibre optique).

2. Menaces dont la source se situe dans la zone contrôlée de l'emplacement du système d'information automatisé, à l'exclusion des emplacements des terminaux clients et des salles serveurs :

Perturbation du fonctionnement normal ou destruction des systèmes d'alimentation électrique et d'alimentation en eau dans les locaux où se trouvent les moyens techniques, assurant le fonctionnement du système automatisé ;

Destruction physique des lignes de communication ou des équipements assurant le fonctionnement du système d'information ;

Lecture d'informations confidentielles à partir de matériel informatique ou de télécommunications utilisant l'interception de rayonnement électromagnétique;

Sortir le personnel de service de l'état de travail (organisation de sabotage, utilisation de substances toxiques, psychotropes, etc.).

3. Menaces dont la source a accès aux terminaux du système d'information automatisé :

Obtention des paramètres de connexion et des informations d'authentification à l'aide de la vidéosurveillance, des onglets du clavier et des technologies de devinette de mot de passe ;

Obtention de paramètres de connexion et d'informations d'authentification à l'aide de techniques frauduleuses, de violence ou de menaces de violence ;

Obtenir la possibilité d'une entrée non autorisée dans le système pendant la période où l'utilisateur légal a quitté le lieu de travail sans mettre fin à la session d'interaction avec le système ;

Obtention d'informations confidentielles à partir des impressions des résultats de l'exécution des requêtes et d'autres données sorties par le système.

4. Menaces dont la source a accès aux locaux où se trouvent les serveurs du système d'information automatisé :

Destruction physique des éléments du serveur et des équipements de commutation ;

Couper l'alimentation des serveurs et des équipements de commutation ;

Arrêt du serveur et d'autres processus critiques pour le fonctionnement du système automatisé ;

Destruction ou modification de fichiers du système d'exploitation critiques pour le fonctionnement du système automatisé ;

Perturbation du fonctionnement normal du système d'exploitation de base, par exemple, en raison du lancement de processus qui consomment activement des ressources système, des fichiers critiques pour le fonctionnement du système d'exploitation, etc.

Classement par méthode impact sur les méthodes et moyens de stockage des données Système d'Information.

1. Menaces de violation de la sécurité des informations des données stockées sur des périphériques de stockage externes :

Violation de la confidentialité, destruction ou modification des données enregistrées au moyen de la création de copies de sauvegarde sur support magnétique, en restaurant illégalement des bases de données avec remplacement ultérieur d'une copie réelle ou sans elle ;

Violation de la confidentialité, destruction ou modification des données créées par des moyens réguliers de tenue d'un journal des modifications de la base de données ;

Discréditer les systèmes de protection des informations cryptographiques en créant des copies de supports d'informations clés ;

Création de copies non autorisées de fichiers du système d'exploitation contenant des informations de base de données pour une analyse ultérieure afin d'accéder à des informations confidentielles.

2. Menaces de violation de la sécurité de l'information des données stockées dans la RAM des serveurs et des ordinateurs clients :

Modification des informations dans la RAM utilisée par le SGBD pour la mise en cache des données, organisation du stockage des résultats intermédiaires d'exécution des requêtes, des constantes et des variables de traitement des données ;

Modification des informations dans la RAM utilisées par le système d'exploitation pour la mise en cache des données, organisation d'un mode de fonctionnement multi-utilisateurs, constantes et variables de traitement des données ;

Modification des informations en RAM utilisées par les programmes applicatifs dans le processus d'organisation et d'exécution d'une session d'interaction avec le serveur de base de données et le processus d'écoute.

3. Menaces de violation de la sécurité des informations des données affichées sur le terminal utilisateur ou l'imprimante :

Organisation d'imitation du processus d'établissement d'interaction avec le serveur (fausse session) afin d'obtenir des identifiants et des informations d'authentification des utilisateurs ;

Modification des données affichées sur le terminal de l'utilisateur en interceptant le flux de sortie ;

Modification des éléments de données sortis vers l'imprimante en interceptant le flux de sortie.

Classification par la nature de l'impact au système d'information (il convient de distinguer deux options) :

Influence active, c'est-à-dire l'exécution par l'utilisateur du système de base de données de toutes actions qui dépassent le cadre de ses fonctions, impliquant une interaction avec le système, ou les actions d'un utilisateur ou d'un processus externe au SI, visant à atteindre un ou plusieurs des objectifs ci-dessus ;

Influence passive, c'est-à-dire observation par l'utilisateur des valeurs de tous les paramètres du SGBD ou du système de base de données, ainsi que divers effets secondaires et signes indirects afin d'obtenir des informations confidentielles sur la base de l'analyse des données collectées.

Le problème de la sécurité des bases de données est complexe. Par conséquent, en tant que modèle mathématique de première approximation, le niveau de sécurité de l'information d'un certain système d'information peut être considéré comme un vecteur multidimensionnel, comprenant les caractéristiques de plusieurs mesures indépendantes :

Physique;

technologique;

Logique (procédural);

Humain.

Caractéristique physique la mesure montre l'efficacité de la protection physique des éléments qui constituent la base technique de l'environnement informatique du commerce électronique. Les ordinateurs, les routeurs, les lignes de communication doivent être physiquement inaccessibles aux porteurs potentiels d'influences destructrices. Surveiller les écrans, le rayonnement électromagnétique des équipements ne doit pas être une source d'informations confidentielles.

Caractéristique technologique la mesure montre l'efficacité de la mise en œuvre logicielle et matérielle des procédures assurant le niveau de sécurité requis : authentification des utilisateurs, contrôle d'accès, garantie de l'intégrité de l'infrastructure d'information, etc. guide d'étude.

Caractéristique logique (procédural) la mesure montre à quel point les fondements logiques des mécanismes de sécurité mis en place dans le système sont adéquats. Si les blocs d'informations critiques sont mal identifiés, ils deviennent vulnérables non pas à cause des lacunes du complexe logiciel et matériel, mais à cause d'erreurs de conception du système.

Caractéristique Humain la mesure montre à quel point le comportement des personnes responsables de la sécurité du système est adéquat. Les méthodes de mesure de cette caractéristique devraient être choisies dans l'arsenal des sciences humaines. Dans tout système d'information automatisé, il y a des personnes qui ont des informations critiques et sont responsables de la sécurité du système. Divers motifs (cupidité, insatisfaction, vanité, etc.) peuvent conduire au transfert volontaire de ces informations à l'attaquant ou à l'incapacité de prendre les mesures nécessaires pour contrer efficacement l'impact destructeur sur le système.

Les quatre dimensions présentées sont en quelque sorte orthogonales les unes aux autres. Les mesures qui améliorent les performances d'une certaine dimension ne conduisent pas toujours à une augmentation de la sécurité du système dans son ensemble. Les caractéristiques des différentes dimensions doivent être équilibrées.

2.3. Menaces spécifiques aux systèmes de gestion de bases de données

Il existe plusieurs bases de classification des menaces spécifiques aux systèmes de gestion de bases de données. Nous utiliserons une classification simplifiée des menaces pour les motifs suivants : menaces à la confidentialité des informations, menaces à l'intégrité des informations et menaces à la disponibilité.

Menaces de confidentialité des informations.

Les menaces de ce type incluent :

1. Injection SQL. De nombreuses applications utilisent la génération SQL dynamique d'instructions SQL par code de programme en concaténant des chaînes et des valeurs de paramètres. Connaissant la structure de la base de données, un attaquant peut soit exécuter le programme stocké dans la requête, soit commenter des fragments "légaux" du code SQL en injectant par exemple la construction UNION dont la requête retourne des données confidentielles. II, des programmes spéciaux sont même apparus récemment pour automatiser le processus de mise en œuvre de telles menaces.

2. Inférence basée sur les dépendances fonctionnelles.

3. Inférence basée sur des contraintes d'intégrité.

Pour les tuples de relations dans un modèle de données relationnel (RDM), vous pouvez spécifier des contraintes d'intégrité - des conditions logiques qui doivent être satisfaites par les attributs des tuples.

4. Utilisation de l'instruction UPDATE pour obtenir des informations confidentielles. Dans certaines normes SQL, un utilisateur sans le privilège d'exécuter une instruction SELECT pourrait exécuter une instruction UPDATE avec une condition logique arbitrairement complexe. Puisqu'après avoir exécuté l'instruction UPDATE, elle vous indique le nombre de lignes traitées, en fait, l'utilisateur peut savoir s'il existe des données qui satisfont à cette condition.

Tenir compte des menaces à l'intégrité des informations spécifiques aux systèmes de gestion de bases de données. La modification des données dans les SGBD relationnels est possible à l'aide des instructions SQL UPDATE, INSERT et DELETE. Un danger potentiel provient du fait qu'un utilisateur disposant des privilèges appropriés peut modifier tous les enregistrements de la table. Il est possible de limiter l'ensemble des enregistrements disponibles pour modification en créant des vues avec l'opérateur CHECK, mais celle-ci (comme toutes les autres) nécessite une compréhension préalable de l'essence du problème et de la conception correspondante du circuit.

Les menaces de disponibilité spécifiques aux systèmes de gestion de bases de données sont :

1. Utilisation des propriétés des clés primaires et étrangères. Tout d'abord, cela inclut la propriété d'unicité des clés primaires et la présence d'intégrité référentielle. Dans le cas où des valeurs de clé primaire naturelles, plutôt que générées par le système, sont utilisées, vous pouvez créer une situation où il sera impossible d'insérer de nouveaux enregistrements dans la table, car il y aura déjà des enregistrements avec les mêmes valeurs de clé primaire . Si la base de données maintient l'intégrité référentielle, vous pouvez rendre impossible la suppression des enregistrements parents en créant délibérément des enregistrements subordonnés. Une caractéristique importante de la mise en œuvre de l'intégrité référentielle est la question de l'indexation des clés étrangères.

2. Verrouillage des enregistrements en cas de modification. En verrouillant les enregistrements ou la table entière, un attaquant peut la rendre indisponible pour la mise à jour pendant un temps considérable.

3. Chargement du système avec un travail insensé. Le plus simple
un exemple est l'exécution d'une requête contenant le produit cartésien de deux grandes relations. D'autres menaces classiques peuvent être implémentées dans les SGBD relationnels, par exemple les attaques de chevaux de Troie - les utilisateurs lançant des programmes contenant du code qui effectue certaines actions et y est injecté par un intrus.

Presque tous les SGBD modernes ont un langage de programmation procédural intégré (PL / SQL, Transact SQL, etc.) Les programmes dans ce langage sont stockés dans la base de données et exécutés par le sous-système d'exécution du serveur de base de données. la présence et l'utilisation généralisée du mécanisme de masquage du code source des programmes stockés par les fabricants de logiciels d'application rend sa détection difficile. De nombreux canaux secrets sont également possibles, du fait de la sémantique des données et de la nécessité d'assurer le travail dans des conditions d'accès multi-utilisateurs.

Sur la base de l'analyse effectuée, nous pouvons conclure que dans les implémentations modernes des SGBD relationnels, il existe un nombre important de vulnérabilités qui peuvent être utilisées pour diverses attaques contre les systèmes d'information construits sur leur base. Ce problème peut être partiellement résolu en utilisant un logiciel spécialisé pour analyser les vulnérabilités et se protéger contre les menaces de divers types.

Envoyez votre bon travail dans la base de connaissances est simple. Utilisez le formulaire ci-dessous

Les étudiants, les étudiants diplômés, les jeunes scientifiques qui utilisent la base de connaissances dans leurs études et leur travail vous seront très reconnaissants.

Posté sur http://www.allbest.ru/

Ministère de l'Éducation et des Sciences de la Fédération de Russie

Établissement privé établissement d'enseignement supérieur

"Académie humanitaire d'Omsk"

Département d'informatique, de mathématiques et de sciences naturelles

TRAVAIL DE COURS

sur le thème : Sécurité des bases de données

par discipline : Bases de données

Complété par : Nurgalieva Shynar Altaybekovna

introduction

1. Voler des informations dans la base de données

1.1 Contrôle d'accès à la base de données

1.2 Gestion de l'intégrité des données

1.3 Contrôle de la concurrence

1.4 Récupération de données

1.5 Transaction et récupération

1.6 Annulation et dénouement d'une transaction

2. Sécurité de la base de données

2.1 Bases de données de planification

2.2 Connexion à la base de données

2.3 Stockage de données cryptées

2.4 Injection SQL

2.5 Technique de défense

Conclusion

Liste des sources utilisées

Applications

introduction

Les offres constantes d'achat de diverses bases de données (principalement départementales) indiquent que la vente d'informations confidentielles sur les citoyens et les personnes morales est devenue un type d'entreprise distinct. Si l'apparition de la prochaine base de données publiée pour les citoyens n'est qu'un autre fait désagréable de la divulgation d'informations sur leur vie privée, alors dans certaines entreprises, cela peut affecter négativement les affaires. Par exemple, pour un opérateur mobile, l'étalement de la base de facturation peut entraîner une sortie importante d'abonnés vers un opérateur concurrent plus « fiable ». Ainsi, il est parfois plus rentable économiquement pour un opérateur de trouver un « fabricant » qui a préparé la base volée à la vente et de racheter l'intégralité du tirage. Mais le problème du chevauchement d'éventuelles fuites reste très urgent.

La protection des bases de données est l'une des tâches les plus difficiles auxquelles sont confrontés les services de sécurité de l'information. D'une part, pour travailler avec la base de données, il est nécessaire de donner accès aux données à tous les employés qui, en service, doivent collecter, traiter, stocker et transférer des données confidentielles. D'autre part, la consolidation des bases de données n'a pas toujours une architecture centralisée, et donc les actions des contrevenants sont de plus en plus sophistiquées. Dans le même temps, il n'existe pas de méthodologie claire et claire pour une solution globale au problème de la protection des bases de données, qui pourrait être appliquée dans tous les cas, dans chaque situation spécifique, il est nécessaire de trouver une approche individuelle.

La vision classique de la solution de ce problème comprend une étude de l'entreprise afin d'identifier des menaces telles que le vol, la perte, la destruction, la modification, le déni d'authenticité. La deuxième étape est suivie par la compilation de modèles mathématiques des principaux flux d'informations et des violations possibles, la modélisation des actions typiques des intrus ; sur le troisième - le développement de mesures globales pour supprimer et prévenir les menaces possibles à l'aide de mesures de protection juridiques, organisationnelles, administratives et techniques. Cependant, la variété des activités des entreprises, la structure de l'entreprise, les réseaux d'information et les flux d'information, les systèmes d'application et les méthodes d'organisation de l'accès à ceux-ci, etc., ne permettent pas de créer une méthodologie universelle de résolution.

Pendant longtemps, la protection des bases de données a été associée à la protection du réseau local d'une entreprise contre les attaques externes de pirates informatiques, la lutte contre les virus, etc. Des rapports d'analyse récents de sociétés de conseil ont identifié d'autres domaines plus importants de la protection des ressources d'information des entreprises. La recherche a montré de manière convaincante que les pare-feu, les VPN et même les systèmes sophistiqués de détection d'intrusion et d'analyse de la sécurité ne peuvent pas protéger contre les fuites d'informations du personnel et les actions malveillantes des administrateurs de bases de données « omnipotents ». L'accès non autorisé aux données et le vol d'informations confidentielles sont les principaux contributeurs à la perte d'entreprises après les dommages causés par un virus.

L'une des principales conclusions du rapport CSI / FBI est l'augmentation significative des dommages causés par une menace telle que le vol de données confidentielles. Chaque entreprise américaine a perdu en moyenne 355 500 $ en raison de fuites de données confidentielles au cours des 12 derniers mois. Le montant moyen des pertes résultant des actions d'initiés était de 300 000 $ (maximum - 1,5 million de dollars). Résoudre les problèmes d'accès personnalisé aux données confidentielles permet d'identifier un attaquant à l'aide d'informations qui prouvent de manière irréfutable sa culpabilité. Ceci, à son tour, est impossible sans l'utilisation de méthodes d'authentification et de contrôle d'accès de pointe.

L'objectif de ce cours est d'aborder la question de la sécurité des bases de données.

Pour résoudre cet objectif, il est nécessaire de résoudre les tâches suivantes :

1. Possibilité d'éviter l'accès non autorisé à la base de données.

2. Stockage de données cryptées.

3. Technique de protection de la base de données.

sécurité de la gestion des bases d'informations

1 . Voler des informations dans des bases de données

1.1 Contrôle d'accès à la base de données

Formuler les principales raisons de l'accès non autorisé aux données et, dans certains cas, aux bases de données commercialisées contenant des données personnelles d'abonnés, de partenaires ou d'employés et des secrets commerciaux d'entreprises.

On a donc les données initiales suivantes :

Beaucoup ne savent pas que leurs bases de données sont volées ;

Le vol et les dommages causés sont latents ;

Si le fait du vol de données est établi, la plupart des entreprises sont muettes sur les dommages causés. L'une des raisons à cela est l'absence de véritables mécanismes de collecte de la base de preuves sur le vol de ressources par un utilisateur spécifique ;

Les technologies permettant de personnaliser strictement les actions des utilisateurs et de différencier leurs droits sont méconnues de la plupart des gestionnaires ;

La capacité à protéger les données des administrateurs système est également peu connue, les managers préfèrent les considérer comme les employés les plus fidèles ;

Les budgets de sécurité de l'information sont généralement faibles. Cela ne permet pas de résoudre le problème de manière globale (la mise en place d'unités de personnel chargées de la sécurité de l'information.

Les principales exigences de sécurité des données pour les bases de données et les SGBD coïncident largement avec les exigences de sécurité des données dans les systèmes informatiques - contrôle d'accès, protection cryptographique, contrôle d'intégrité, journalisation, etc.

La gestion de l'intégrité dans une base de données fait référence à la protection des données dans une base de données contre les modifications et la destruction incorrectes (par opposition à non autorisées). Maintenir l'intégrité de la base de données consiste à assurer à chaque instant l'exactitude (correction) à la fois des valeurs de tous les éléments de données eux-mêmes et des relations entre les éléments de données dans la base de données. Les exigences de base suivantes sont associées au maintien de l'intégrité.

Garantir la fiabilité. Chaque élément de données est enregistré exactement comme décrit pour cet élément. Des mécanismes doivent être fournis pour garantir que les éléments de données et leurs relations logiques résistent aux erreurs ou aux actions des utilisateurs non qualifiés.

Contrôle d'accès concurrentiel. Des violations d'intégrité de la base de données peuvent se produire lorsque des opérations sont effectuées sur des données simultanément, chacune d'entre elles ne violant pas individuellement l'intégrité de la base de données. Par conséquent, des mécanismes de gestion des données doivent être fournis pour garantir que l'intégrité de la base de données est maintenue pendant que plusieurs opérations sont effectuées simultanément.

Récupération. Les données stockées dans la base de données doivent être résistantes aux influences physiques défavorables (erreurs matérielles, pannes de courant, etc.) et aux erreurs logicielles. Par conséquent, des mécanismes doivent être prévus pour restaurer dans un temps extrêmement court l'état de l'OBD qui était avant l'apparition du dysfonctionnement.

Les problèmes de contrôle d'accès et de maintien de l'intégrité de la base de données sont étroitement liés et, dans de nombreux cas, les mêmes mécanismes sont utilisés pour les résoudre. La différence entre ces aspects de la sécurisation des données dans une base de données est que le contrôle d'accès vise à empêcher la destruction intentionnelle de la base de données, et la gestion de l'intégrité vise à empêcher l'introduction par inadvertance d'une erreur.

La plupart des systèmes de bases de données sont un moyen de stockage de données unique et centralisé. Cela réduit considérablement la redondance des données, simplifie l'accès aux données et aide à protéger les données plus efficacement. Cependant, un certain nombre de problèmes se posent dans la technologie des bases de données, liés, par exemple, au fait que différents utilisateurs doivent avoir accès à certaines données et ne pas avoir accès à d'autres. Par conséquent, sans utiliser de moyens et de méthodes spéciaux, il est pratiquement impossible de fournir une séparation fiable des accès à la base de données.

La plupart des SGBD modernes ont des outils intégrés qui permettent à l'administrateur système de définir les droits des utilisateurs pour accéder à diverses parties de la base de données, jusqu'à un élément spécifique. Dans ce cas, il est possible non seulement de donner accès à un utilisateur particulier, mais également de spécifier le type d'accès autorisé : que peut exactement un utilisateur particulier avec des données spécifiques (lire, modifier, supprimer, etc.), jusqu'à réorganisation de l'ensemble de la base de données Le contrôle d'accès aux tables (listes) est largement utilisé dans les systèmes informatiques, par exemple, dans le système d'exploitation pour contrôler l'accès aux fichiers. La particularité d'utiliser cet outil pour protéger une base de données est que non seulement les fichiers individuels (zones dans les bases de données réseau , relations dans les bases de données relationnelles ), mais aussi d'autres éléments structurels de la base de données : élément, champ, enregistrement, jeu de données.

1.2 Gestion de l'intégrité des données

Les atteintes à l'intégrité des données peuvent être causées par un certain nombre de raisons :

Pannes d'équipement, impacts physiques ou catastrophes naturelles ;

Erreurs d'utilisateurs autorisés ou actions délibérées d'utilisateurs non autorisés ;

Erreurs logicielles du SGBD ou du système d'exploitation ;

Erreurs dans les programmes d'application ;

Exécution conjointe de demandes d'utilisateurs conflictuelles, etc.

Les violations de données sont également possibles dans les systèmes bien débogués. Par conséquent, il est important non seulement d'empêcher la violation de l'intégrité, mais également de détecter à temps le fait de la violation de l'intégrité et de restaurer rapidement l'intégrité après la violation.

1.3 Contrôle de la concurrence

Le maintien de l'intégrité sur la base des contraintes d'intégrité ci-dessus est un problème assez difficile dans un système de base de données, même avec un seul utilisateur. Dans les systèmes orientés vers le mode de fonctionnement multi-utilisateurs, un certain nombre de nouveaux problèmes se posent liés à l'exécution parallèle de demandes d'utilisateurs conflictuelles. Avant d'aborder les mécanismes de protection de la base de données contre les erreurs qui surviennent en cas de conflit de demandes d'utilisateurs, nous dévoilerons un certain nombre de concepts liés au contrôle de la concurrence.

Le moyen le plus important du mécanisme de protection de l'intégrité de la base de données est la combinaison d'un ensemble d'opérations, à la suite desquelles la base de données d'un état intégral passe à un autre état intégral, en un élément logique de travail, appelé transaction . L'essence du mécanisme de transaction est qu'avant l'achèvement de la transaction, toutes les manipulations de données sont effectuées en dehors de la base de données et les modifications réelles ne sont apportées à la base de données qu'après l'achèvement normal de la transaction.

Du point de vue de la sécurité des données, un tel mécanisme d'affichage des modifications dans la base de données est très important. Si la transaction a été interrompue, des outils SGBD spéciaux intégrés effectuent ce qu'on appelle la restauration - la base de données revient à l'état avant le début de la transaction (en fait, la restauration consiste généralement simplement à ne pas apporter de modifications en raison du cours de la transaction dans la base de données physique). Si l'exécution d'une transaction ne viole pas l'intégrité de la base de données, alors en raison de l'exécution simultanée de plusieurs transactions, l'intégrité de la base de données peut être violée. Pour éviter de telles erreurs, le SGBD doit prendre en charge des mécanismes qui garantissent que les transactions capturent les éléments de données modifiés jusqu'à la fin de la modification, appelés verrous. Cela garantit que personne ne peut accéder à l'élément en cours de modification jusqu'à ce que la transaction le libère. L'utilisation du mécanisme de verrouillage conduit à de nouveaux problèmes de contrôle de la concurrence, en particulier, à l'apparition de situations de clinchage à deux transactions. De plus, si une transaction essaie de verrouiller un objet déjà verrouillé par une autre transaction, elle devra alors attendre que le verrou de l'objet soit libéré par la transaction qui a établi ce verrou. En d'autres termes, une seule transaction peut verrouiller un objet.

1.4 Récupération de données

La récupération de données est le processus d'accès aux fichiers enregistrés sur un support de stockage particulier qui sont devenus inaccessibles en raison d'une défaillance logicielle, d'une défaillance du support de stockage ou d'actions erronées de l'utilisateur. La possibilité de récupérer des données à l'aide de programmes spéciaux existe si elles n'ont pas été écrasées par d'autres informations. De plus, le succès dépend en grande partie de la sécurité de la structure du système de fichiers et des performances du support en général.

Comme vous le savez, les données sur tout support de stockage moderne au niveau le plus bas sont stockées sous la forme d'une séquence de bits de zéros et de uns. C'est-à-dire sous forme de secteurs aimantés/chargés (1) ou de leur absence (0).

Cependant, Windows et d'autres systèmes d'exploitation fonctionnent à des niveaux supérieurs en utilisant différents systèmes de fichiers pour accélérer et simplifier l'accès aux données. Le système de fichiers est une couche logicielle permettant une interaction efficace du système d'exploitation avec des informations sur un support physique. Il se compose de deux parties : la zone système et la zone de données. La zone système stocke le secteur de démarrage (responsable de la possibilité de démarrer à partir du support et de sa reconnaissance correcte), ainsi qu'un certain nombre de secteurs qui stockent des tables d'index de fichiers et d'autres informations de service.

Toutes les informations sont physiquement stockées dans la zone de données, cependant, les listes de fichiers se trouvent dans la zone système. Le mécanisme d'une telle organisation du travail est le suivant: lorsqu'un support est connecté à un ordinateur, le système ne scanne pas l'intégralité du disque pour détecter la présence de fichiers, mais lit rapidement les données les concernant à partir de la zone système. L'OS interagit également avec le support, par exemple lors de la suppression de données : les fichiers ne sont pas physiquement détruits, mais seules les références à ceux-ci dans la table des fichiers sont supprimées. Cela donne au système une raison de considérer les clusters de médias « libérés » comme étant vides et adaptés à une réécriture ultérieure. Ainsi, le premier cas où la récupération de données est possible est la disparition d'un lien vers un fichier dans la table des fichiers, à condition que le fichier n'ait pas été écrasé par d'autres données. Le deuxième cas courant est le formatage des médias. Il existe trois types de formatage :

Formatage rapide - seule la table des fichiers est effacée, mais la zone de données n'est pas affectée. Avec ce formatage, les chances de récupération sont très élevées (à condition que rien d'autre n'ait été écrit sur le lecteur flash formaté).

Formatage complet - la zone système et la zone de données sont effacées. Ce type de formatage prévoit un effacement complet du support, cependant, pour accélérer le processus, la zone de données n'est pas totalement effacée, mais par fragments. Cela donne (bien que petite) une chance de récupérer les fichiers dont vous avez besoin.

Formatage de bas niveau - tous les secteurs du support de données sont remplis de zéros. Après un tel formatage, il est presque impossible de récupérer quoi que ce soit, car toutes les données sont complètement détruites. Sous Windows, il n'y a aucune possibilité de formatage de bas niveau, donc même après avoir complètement nettoyé le disque avec ses moyens, la récupération des données est théoriquement possible ! De même, vous pouvez essayer de récupérer des informations en cas de défaillance du système de fichiers, avec lesquelles les lecteurs flash « pèchent » souvent. Avec de telles défaillances, la zone système est généralement partiellement ou complètement détruite et le lecteur flash nécessite un formatage :

Comme déjà noté, l'apparition de pannes matérielles ou logicielles peut entraîner la nécessité de récupérer et de revenir rapidement à un état aussi proche que possible de l'état avant que la panne (erreur) ne se produise. L'impasse est souvent l'une des raisons du besoin de récupération.

Il existe trois niveaux principaux de récupération :

La récupération en ligne, qui se caractérise par la capacité de récupérer au niveau des transactions individuelles lorsque la situation de manipulation de données se termine de manière anormale (par exemple, lorsqu'une erreur de programme se produit).

Récupération intermédiaire. Si des anomalies surviennent dans le système (erreurs système et logicielles, pannes logicielles non liées à la destruction de la base de données), il est alors nécessaire de restaurer l'état de toutes les transactions en cours au moment de la panne.

Récupération à long terme. Si la base de données est détruite à la suite d'un défaut sur le disque, la récupération est effectuée à l'aide d'une copie de la base de données. Ensuite, ils reproduisent les résultats des transactions exécutées depuis la prise de copie et remettent le système dans l'état au moment de la destruction.

1.5 Transaction et récupération

L'abandon d'une transaction en raison d'un échec viole l'intégrité de la base de données. Si les résultats d'une telle exécution de la transaction sont perdus, il est alors possible de les reproduire au moment de l'échec. Ainsi, le concept de transaction joue un rôle important dans le recouvrement. Pour restaurer l'intégrité de la base de données, les transactions doivent répondre aux exigences suivantes :

Il est nécessaire que la transaction soit exécutée complètement ou pas du tout ;

Il faut que la transaction laisse la possibilité de revenir à l'état initial, et, afin d'assurer un retour indépendant de la transaction à l'état initial, le verrouillage exclusif doit être effectué jusqu'à l'achèvement du changement de tous les objets ;

Il est nécessaire de pouvoir reproduire le processus d'exécution d'une transaction et, pour répondre à cette exigence, un verrouillage conjoint doit être effectué jusqu'au moment où toutes les transactions ont fini de visualiser les données.

Dans le processus d'exécution de toute transaction, vient le moment de son achèvement. Dans ce cas, tous les calculs effectués par une transaction dans sa zone de travail doivent être terminés, une copie des résultats de son exécution doit être écrite dans le journal système. C'est ce qu'on appelle une opération de validation. Lorsqu'un échec se produit, il est plus opportun de revenir non pas au début de la transaction, mais à une position intermédiaire. Le point où un tel retour se produit est appelé le point de fixation (point de contrôle). L'utilisateur peut définir un nombre arbitraire de tels points lors de l'exécution d'une transaction. Si un point de validation est atteint lors de l'exécution d'une transaction, le SGBD effectue automatiquement l'opération ci-dessus.

1.6 Annulation et dénouement d'une transaction

Le principal outil utilisé lors de la récupération est le journal système, qui enregistre toutes les modifications apportées à la base de données par chaque transaction. Remettre une transaction à son état initial consiste à annuler toutes les modifications qui ont été apportées lors de l'exécution de la transaction. Cette opération est appelée restauration. Pour reproduire les résultats d'une transaction, vous pouvez, à l'aide du journal système, restaurer les valeurs des modifications apportées dans l'ordre de leur apparition, ou ré-exécuter la transaction. La relecture des résultats d'une transaction à l'aide du syslog est appelée roll-up. La promotion est une opération assez compliquée mais nécessaire des mécanismes modernes de récupération de base de données.

2 . Sécurité de baseLes données

2.1 Bases de données de planification

Aujourd'hui, les bases de données sont l'épine dorsale de pratiquement toutes les applications Web, permettant la fourniture d'une variété de contenus dynamiques. Étant donné que de telles bases de données peuvent stocker des informations très importantes et secrètes, vous devez veiller à leur protection. L'architecture utilisée pour créer des pages Web à l'aide de PL/SQL WebToolkit est étonnamment simple, comme le montre la figure 1 (voir l'annexe A).

Pour recevoir ou enregistrer des informations dans la base de données, vous devez vous y connecter, envoyer une demande, traiter la réponse et fermer la connexion. Aujourd'hui, tout cela se fait généralement à l'aide d'un langage de requête structuré (SQL). Voyons comment un attaquant peut gérer une requête SQL.

Comme vous le savez, PHP ne peut pas protéger la base de données elle-même. Les sections suivantes sont une introduction aux bases de l'accès et de l'utilisation des bases de données dans les scripts PHP.

Souvenez-vous d'une règle simple : la défense se construit en profondeur. Plus vous protégez d'emplacements et plus vous entreprenez d'actions pour protéger la base de données, moins un attaquant réussira à extraire et à utiliser les informations classifiées qui y sont stockées. Tous les points dangereux sont éliminés par la conception correcte de la structure de la base de données et de l'application qui l'utilise.

La première étape est toujours la création proprement dite de la base de données, sauf lors de l'utilisation des bases de données de quelqu'un d'autre. Lorsqu'une base de données est créée, un propriétaire lui est affecté, qui a invoqué la commande de création. Habituellement, un seul propriétaire ("superutilisateur") peut faire quoi que ce soit avec les objets de cette base de données, et afin de permettre à d'autres utilisateurs de l'utiliser, des autorisations doivent leur être attribuées.

Les applications ne doivent jamais se connecter à la base de données en tant que propriétaire ou "superutilisateur", car cela permettrait aux utilisateurs d'effectuer toute action telle que modifier le schéma (par exemple, supprimer des tables) ou supprimer tout son contenu.

Vous pouvez créer différents utilisateurs de base de données pour chaque action d'application requise, ce qui limite fortement l'accès de ces derniers aux objets de la base de données. Les droits requis doivent être attribués une seule fois et doivent être évités ailleurs dans la demande. Cela signifie que si un attaquant obtient l'accès en utilisant un compte particulier, il ne pourra obtenir que l'accès dont disposait la partie utilisée du programme.

Il vaut mieux ne pas introduire toute la logique du travail avec les bases de données dans les applications. Cela peut être fait dans la base de données elle-même à l'aide d'indicateurs, de vues, de règles et de procédures intégrées. Au fur et à mesure que le système évolue et se développe, les procédures intégrées peuvent être modifiées pour traiter automatiquement de nouveaux champs, et les indicateurs fourniront des options supplémentaires pour le débogage des transactions.

2.2 Connexion à la base de données

Les connexions peuvent être établies à l'aide de SSL pour crypter les connexions client-serveur, ce qui offre une sécurité accrue. Vous pouvez également utiliser ssh pour chiffrer les connexions réseau entre les clients et le serveur de base de données. Dans tous les cas, il est très difficile de suivre et de récupérer les informations du trafic réseau.

2.3 Stockage des données cryptées

SSL/SSH ne protège que les données du client au serveur, mais pas les données stockées dans la base de données. SSL n'est qu'un protocole réseau.

Lorsqu'un attaquant accède à votre base de données en contournant le serveur Web, les données sensibles stockées peuvent être récupérées et exploitées, à moins que les informations ne soient protégées dans la base de données elle-même. Le chiffrement est une très bonne astuce dans ce cas, mais très peu de systèmes de gestion de bases de données le prennent actuellement en charge.

Le moyen le plus simple dans ce cas est de créer votre propre système de cryptage, puis de l'utiliser dans des scripts PHP. PHP facilite cette approche en fournissant des extensions spécifiques telles que Mcrypt et Mhash qui couvrent un large éventail d'algorithmes de cryptage. Le programme crypte les données stockées et décrypte les données reçues. Pour une description détaillée des schémas de cryptage, voir les liens.

Dans le cas de données masquées, où leur apparence d'origine n'est pas requise (par exemple, pour l'affichage), vous pouvez utiliser le hachage. Un exemple célèbre de hachage consiste à stocker le hachage MD5 du mot de passe dans la base de données au lieu du mot de passe lui-même. Voir crypt () et md5 () pour une description détaillée.

Exemple : Utilisation de mots de passe hachés

// enregistre le hachage du mot de passe

$ query = sprintf ("INSERT INTO users (name, pwd) VALUES ("% s ","% s ");",

// vérifier l'exactitude du mot de passe saisi par l'utilisateur

$ query = sprintf ("SELECT 1 FROM utilisateurs WHERE nom ="% s "AND pwd ="% s ";",

addlashes ($ nom d'utilisateur), md5 ($ mot de passe));

$ result = pg_exec (connexion $, requête $);

if (pg_numrows ($ résultat)> 0) (

echo "Bienvenue, $ nom d'utilisateur !";

echo "Mot de passe entré pour $ nom d'utilisateur non valide.";

2.4 Injection SQL

De nombreux développeurs d'applications Web considèrent que les requêtes SQL sont sans valeur, ignorant le potentiel d'un attaquant pour les exploiter. Cela signifie que les requêtes SQL peuvent être utilisées pour contourner les systèmes de sécurité, d'authentification et d'autorisation, et peuvent parfois être utilisées pour accéder aux commandes au niveau du système d'exploitation.

L'injection de commandes SQL est une technique dans laquelle un attaquant crée ou modifie des commandes SQL pour accéder à des données cachées, pour modifier des données existantes et même pour exécuter des commandes au niveau du système d'exploitation. Ceci est réalisé si le programme utilise les données d'entrée en combinaison avec des paramètres statiques pour créer une requête SQL. Les exemples suivants, malheureusement, sont basés sur des cas réels :

Un attaquant pourrait créer un nouveau superutilisateur dans la base de données en cas de validation insuffisante des données d'entrée et de connexion à la base de données en tant que superutilisateur.

Exemple : fractionnement du résultat de la requête sur plusieurs pages et... création de super-utilisateurs (PostgreSQL et MySQL)

$ décalage = argv; // Attention! pas de validation des données !

// dans PostgreSQL

$ result = pg_exec ($ conn, $ query);

$ result = mysql_query (requête $);

En règle générale, les utilisateurs utilisent les boutons « suivant » et « précédent », où le décalage $ est intégré dans l'URL. Le programme suppose que $ offset est un nombre. Cependant, n'importe qui peut essayer d'injecter en ajoutant urlencode () - des données encodées à l'url

// dans le cas de PostgreSQL

insérer dans pg_shadow (username, usesysid, usesuper, usecatupd, passwd)

sélectionnez "crack", useysid, "t", "t", "crack"

de pg_shadow où username = "postgres" ;

// dans le cas de MySQL

UPDATE user SET Password = PASSWORD ("crack") WHERE user = "root";

PRIVILÈGES DE FLASH ;

Si cela se produit, le programme lui accordera un accès superutilisateur. Notez que 0; sert à définir le décalage correct pour la demande d'origine et à la compléter.

Une pratique courante consiste à forcer le traducteur SQL à ignorer le reste de la requête du développeur en utilisant la notation de début de commentaire SQL -.

Il existe un moyen d'obtenir des mots de passe via vos pages de recherche. Tout ce dont un attaquant a besoin, c'est d'une variable qui n'est pas correctement traitée et utilisée dans la requête SQL. Les commandes WHERE, ORDER BY, LIMIT et OFFSET de la requête SELECT peuvent être utilisées. Si votre base de données supporte la construction UNION, un attaquant peut en ajouter une autre à la requête originale pour récupérer les mots de passe. Dans ce cas, le stockage de mots de passe cryptés vous aidera.

Exemple : Affichage des articles... et des mots de passe (n'importe quel serveur de base de données)

$ query = "SELECT id, nom, inséré, taille FROM produits

WHERE taille = "$ taille"

ORDER BY $ order LIMIT $ limit, $ offset; ";

$ result = odbc_exec ($ conn, $ query);

La partie statique de la requête peut être combinée avec une autre requête SELECT qui affichera tous les mots de passe :

union select "1", concat (uname || "-" || passwd) comme nom, "1971-01-01", "0" de usertable ;

Si une requête similaire (utilisant "et -) est spécifiée dans l'une des variables utilisées par $ query, alors l'attaque sera réussie.

Les requêtes SQL UPDATE peuvent également être utilisées pour attaquer la base de données. Ces requêtes sont également sujettes au danger d'être tronquées et de nouvelles requêtes ajoutées. Mais ici, l'attaquant travaille avec la commande SET. Dans ce cas, il est nécessaire de connaître quelques informations sur la structure de la base de données pour réussir la modification de la requête. Ces informations peuvent être obtenues en étudiant les noms de formes variables ou simplement par sélection. Après tout, peu de noms sont inventés pour les champs d'utilisateur et de mot de passe.

Exemple : De la réinitialisation d'un mot de passe à l'obtention de privilèges... (n'importe quel serveur de base de données)

$ query = "UPDATE usertable SET pwd =" $ pwd "WHERE uid =" $ uid ";";

L'attaquant envoie la valeur "or uid like"% admin% "; -, à la variable $ uid pour changer le mot de passe administrateur, ou définit simplement $ pwd sur" hehehe ", admin =" yes ",trusted = 100" (avec un espace de fin) pour l'obtention des droits. La demande sera brouillée comme ceci :

// $ uid == "ou uid like"% admin% "; -

$ query = "UPDATE usertable SET pwd =" ... "WHERE uid =" "ou uid like"% admin% "; -";

// $ pwd == "hehehe", admin = "yes", trusté = 100 "

$ query = "UPDATE usertable SET pwd =" hehehe ", admin =" yes ", trusté = 100 WHERE ...;"

Et voici un exemple de la façon dont les commandes au niveau du système d'exploitation peuvent être exécutées sur certains serveurs de base de données :

Exemple : Attaque sur le système d'exploitation d'un serveur de base de données (serveur MSSQL)

$ query = "SELECT * FROM produits WHERE id LIKE"% $ prod% "";

Si un attaquant envoie la valeur a% "exec master..xp_cmdshell" net user test testpass / ADD "à $ prod, alors $ query ressemblera à ceci :

$ query = "SELECT * FROM produits

WHERE id LIKE "% a%"

exec master..xp_cmdshell "net user test testpass / ADD" - ";

$ result = mssql_query (requête $);

Le serveur MSSQL exécute toutes les commandes SQL, y compris la commande pour ajouter un nouvel utilisateur à la base de données d'utilisateurs locale. Si cette application a été lancée en tant que sa et que le service MSSQLSERVER dispose des droits suffisants, l'attaquant disposera d'un compte pour accéder à cette machine.

Certains des exemples ci-dessus sont spécifiques à un serveur de base de données spécifique. Mais cela ne signifie pas qu'une telle attaque est impossible contre d'autres logiciels. Votre serveur de base de données sera vulnérable aux attaques imprévues d'une manière ou d'une autre.

2.5 Technique de défense

La plupart des exemples montrent que l'attaquant doit disposer d'informations pour attaquer. Tout est correct, mais on ne sait jamais à l'avance dans quel sens ira cette information. Si cela se produit, la base de données n'est plus sécurisée. Si vous utilisez un package de gestion de base de données librement redistribuable qui appartient à un système de gestion de contenu ou à un forum, un attaquant peut facilement obtenir une copie de cette partie de votre programme. Il peut également présenter une faille de sécurité.

La plupart des attaques sont basées sur l'utilisation de code qui n'a pas été écrit avec des considérations de sécurité à l'esprit. Ne faites jamais confiance aux données saisies, surtout si elles proviennent du côté client, même si elles proviennent d'une case à cocher, d'un champ masqué ou d'un enregistrement de cookie. Le premier exemple montre à quoi peut conduire la substitution de ces données.

Ne vous connectez jamais à une base de données en tant que superutilisateur ou propriétaire. Utilisez toujours des utilisateurs spéciaux avec un minimum de droits.

Vérifiez l'entrée pour voir si le type de données correspond à celui requis. PHP inclut un grand nombre de fonctions de vérification, de la plus simple des sections "Fonctions pour travailler avec des variables" et "Fonctions pour gérer le type de caractère" (par exemple is_numeric() et ctype_digit(), respectivement) aux expressions régulières Perl ("Regular expressions, compatibles Perl").

Si le programme attend un nombre, vérifiez les données avec is_numeric (), ou changez simplement le type avec settype (), ou même utilisez la représentation numérique fournie par sprintf ().

Exemple : Pagination plus sûre

settype ($ offset, "integer");

$ query = "SELECT id, nom FROM produits ORDER BY nom LIMIT 20 OFFSET $ offset;";

// marquer% d dans la chaîne de format, utiliser % s est inutile

$ query = sprintf ("SELECT id, nom FROM produits ORDER BY nom LIMIT 20 OFFSET% d;",

Toute entrée non numérique transmise à la base de données doit être précédée de addlashes () ou d'addcslashes (). Le premier exemple montre que les guillemets ne suffisent pas dans la partie statique de la requête.

Vous ne pouvez en aucun cas afficher des informations sur la structure de la base de données.

Des procédures stockées et des emplacements prédéfinis peuvent être utilisés pour découpler l'accès aux données du programme afin que les utilisateurs n'aient pas un accès direct aux tables et aux vues, mais cette option a ses propres problèmes.

De plus, il est nécessaire de conserver un journal des opérations dans le programme ou dans la base de données elle-même, si elle est prise en charge. La journalisation n'empêchera pas les infiltrations, mais elle aidera à déterminer quelle partie du programme a été compromise. Le journal lui-même est inutile - les informations qu'il contient sont utiles. Le plus, le mieux.

Conclusion

Les bases de données sont les composants clés de la plupart des applications Web aujourd'hui, permettant la diffusion de contenu dynamique sur les sites. Étant donné que de telles bases de données peuvent stocker des informations très précises ou confidentielles, vous devez vous assurer que vos données sont bien protégées.

Pour récupérer ou enregistrer des données, vous devez ouvrir une connexion à la base de données, envoyer la requête correcte, récupérer le résultat et fermer la connexion. Actuellement, la norme de communication la plus courante est le langage de requête structuré (SQL). Vous devez toujours vous souvenir de la possibilité d'une attaque via une requête SQL.

Évidemment, PHP seul ne peut pas protéger votre base de données. Cette section de la documentation couvre les bases de l'accès sécurisé et de la gestion des données dans les scripts PHP.

Rappelez-vous une règle simple : une protection maximale. Plus vous travaillez dans des zones potentiellement dangereuses du système, plus il sera difficile pour un attaquant potentiel d'accéder à la base de données ou de l'endommager. Une bonne conception de base de données et des applications logicielles peuvent vous aider à gérer vos peurs.

La première étape consiste toujours à créer une base de données, sauf lorsque vous souhaitez utiliser une base de données toute faite fournie par un tiers. Une fois la base de données créée, elle est attribuée à l'utilisateur qui a exécuté la requête qui a créé la base de données. En règle générale, seul le propriétaire (ou superutilisateur) peut effectuer différentes actions sur différents objets stockés dans la base de données. Pour que d'autres utilisateurs y aient accès, ils doivent être dotés des privilèges appropriés.

Les applications ne doivent pas se connecter à la base de données en utilisant le compte propriétaire ou superutilisateur, sinon elles peuvent modifier la structure des tables (par exemple, supprimer certaines tables) ou même supprimer tout le contenu de la base de données.

Vous pouvez créer différents comptes d'utilisateur de base de données pour chaque besoin d'application individuel avec les restrictions fonctionnelles correspondantes. Il est recommandé de n'attribuer que les privilèges les plus nécessaires, et vous devez également éviter les situations où le même utilisateur peut interagir avec la base de données dans plusieurs modes. Vous devez comprendre que si un attaquant peut utiliser n'importe quel compte de votre base de données, il pourra apporter toutes les modifications à la base de données en tant que programme qui utilise le compte actuel.

Il n'est pas nécessaire d'implémenter toute la logique métier dans une application web (c'est-à-dire dans des scripts), pour cela vous pouvez également utiliser les capacités fournies par la base de données : déclencheurs, vues, règles. Si le système grandit, vous aurez besoin de nouvelles connexions à la base de données et la logique de travail devra être dupliquée pour chaque nouvelle interface d'accès. Sur la base de ce qui précède, les déclencheurs peuvent être utilisés pour traiter de manière transparente et automatique les enregistrements, ce qui est souvent nécessaire lors du débogage des applications ou lors du suivi d'une annulation de transactions.

Selon le système d'exploitation que vous utilisez, vous devez envisager d'attaquer une variété de fichiers, y compris les fichiers de périphérique système (/dev/ou COM1), les fichiers de configuration (par exemple /etc/ou les fichiers avec l'extension .ini), bien- zones de stockage connues (/home/, Mes Documents), etc. Par conséquent, il est généralement plus facile de mettre en œuvre une politique de sécurité qui interdit tout sauf ce qui est explicitement autorisé.

Étant donné que les administrateurs de bases de données d'entreprise ne peuvent pas toujours consacrer le temps dont ils ont besoin à la sécurité, certaines entreprises prennent des mesures plus proactives. Ils libèrent ces employés de leurs fonctions normales et les incluent dans l'équipe de sécurité informatique.

La création d'un tel poste résout deux problèmes à la fois : les spécialistes de la sécurité informatique qui n'ont pas beaucoup de connaissances dans le domaine des bases de données peuvent utiliser l'aide de professionnels, et les administrateurs de bases de données ont la possibilité de concentrer leurs activités sur les questions de sécurité de l'information et de recevoir les formation nécessaire pour assurer la sécurité des bases de données de l'entreprise. ...

Liste des sources utilisées

1. Boychenko I. A. Concevoir des composants d'un environnement de confiance d'un SGBD relationnel basé sur les technologies CASE [Texte] / I. A. Boychenko - Voronej, 2014. - 251p.

2.Borrie H. Firebird : Manuel de l'utilisateur de la base de données [Texte] : par. de l'anglais / H.Bori. - SPb. : BHV - Pétersbourg, 2012 .-- 1104s.

3.Système de gestion de base de données Bronevshchuk E.S. [Texte] / E.S. Bronevshchuk, V.I. Burdakov, L.I. Gukov. - M. : Finances et statistiques, 2013 .-- 634p.

4. Goncharov A. Yu. Access 2007. Ouvrage de référence avec exemples [Texte] / A. Yu. Goncharov. - M. : KUDITS - PRESSE, 2011 .-- 296s.

5.Date K. Introduction aux systèmes de bases de données [Texte] / K. Date 7e éd. - M. : SPb. : Williams, 2013 .-- 325s.

6. Kalenik A. Utilisation des nouvelles fonctionnalités de MS SQL Server 2005 [Texte] / A. Kalenik. - SPb. : Pierre, 2013 .-- 334s.

7. Connolly T. Bases de données. Conception, réalisation et maintenance. Théorie et pratique [Texte] / T. Connolly, L. Begg, A. Stragan 2e éd. - M. : Williams, 2012.-- 476s.

8. Motev, A. A. Leçons de My SQL. Guide d'auto-apprentissage [Texte] / A. A. Motev. - SPb. : BHV - Pétersbourg, 2013 .-- 208s.

9. Oppel E. Divulgation des secrets de SQL [Texte] : par. de l'anglais / E. Opel, Jim Kiu, D.A. Terentyeva. - M. : NT Press, 2012 .-- 320s.

10. Promakhina I. M. Network DBMS (PC) interfaces avec des langages de haut niveau [Texte] / I. M. Promakhina - Moscou : Centre de calcul de l'Académie des sciences de Russie, 2011.- 874p.

11. Fufaev E.V., Bases de données ; [Texte] / E. V. Fufaev, D. E. Fufaev - Académie - Moscou, 2013. - 320 p.

12. Frost, R. Bases de données. Conception et développement [Texte] : par. de l'anglais / R. Frost, D. Day, K. Van Slike, A. Yu. Kukharenko. - M. : NT Press, 2007 .-- 592s.

Annexe A

Figure A.1 - Architecture utilisée pour créer des pages Web

Appendice B

Figure B.1 - Système de protection des informations

Publié sur Allbest.ru

...

Documents similaires

Fondamentaux de la sécurité des données personnelles. Classification des menaces à la sécurité de l'information des données personnelles, caractéristiques de leurs sources. Bases de données de données personnelles. Contrôle et gestion des accès. Développement de mesures pour la protection des données personnelles dans la banque.

thèse, ajoutée le 23/03/2018


Prise en compte de la problématique d'assurer l'autorisation d'utilisation des informations dans les bases de données (protection des données contre les modifications non désirées, la destruction, l'infection par des virus) et réglementation légale de la sécurité sur l'exemple du SGBD Ms SQL.

dissertation, ajouté le 30/03/2010


Qu'est-ce qu'une base de données, visualisation des informations de la base de données. La structure et les propriétés de la base de données la plus simple. Caractéristiques des définitions, types de données, sécurité, spécificités de la constitution des bases de données. Approches de la conception des spécifications techniques. Travailler avec des tableaux.

présentation ajoutée le 11/12/2010


Formes d'information présentées. Les principaux types du modèle de données utilisé. Niveaux des processus d'information. Rechercher des informations et rechercher des données. Stockage de données en réseau. Problèmes de développement et de maintenance des entrepôts de données. Technologies de traitement des données.

conférence ajoutée le 19/08/2013


Entités et dépendances fonctionnelles de la base de données. Attributs et liens. Tableaux de la base de données. Construire un diagramme ER. Organisation de la saisie et de la correction des données. Schéma de base de données relationnelle. Exécution des demandes, réception des rapports. Protection de la base de données.

dissertation ajoutée le 02/06/2016


Les principaux types de bases de données. Système de gestion de base de données. Analyse des activités et des informations traitées dans la clinique. La composition des tables de la base de données et leur relation. La méthode de remplissage de la base de données avec des informations. Algorithme de création d'une base de données.

dissertation, ajouté le 17/12/2014


Évolution des concepts de bases de données. Exigences à remplir par une organisation de base de données. Modèles de présentation des données. Langage SQL comme langage de base de données standard. Architectures de bases de données. Environnement Delphi comme outil de développement de SGBD.

thèse, ajoutée le 26/11/2004


Concept de base de données, modèle de données. Classement de la base de données. Systèmes de gestion de bases de données. Étapes, approches de la conception de bases de données. Développement d'une base de données qui automatisera la maintenance de la documentation requise pour les activités de la CYSS.

dissertation, ajouté le 04/06/2015


Processus de traitement de l'information. L'efficacité d'un système d'information automatisé. Système de gestion de base de données. Système local et distribué de banques et de bases de données. Étapes de conception de la base de données. Différence dans les niveaux de présentation des données.

test, ajouté le 07/07/2015


Conception d'une base de données Access. Système de gestion de base de données. Création et maintenance d'une base de données, donnant accès aux données et à leur traitement. Définition des tâches et des objectifs, les principales fonctions exécutées par la base de données. Les principaux types de bases de données.

Avec l'utilisation croissante des bases de données, la fréquence des attaques de bases de données a également augmenté. Les attaques de bases de données sont une tendance croissante de nos jours. Quelle est la raison de l'attaque sur la base de données ? L'une des raisons est l'accès accru aux données stockées dans la base de données. Lorsque les données ont été utilisées par de nombreuses personnes, les risques de vol de données augmentent. Il s'ensuit que la sécurité des bases de données est l'ensemble des techniques utilisées pour protéger les informations stockées dans une base de données. Étant donné que les tentatives de piratage des bases de données sont les plus courantes, vous devrez penser à la sécurité de l'infobase, car il existe de nombreux autres dangers.

Les dommages physiques à votre ordinateur, un encodage incorrect ou une corruption et les redémarrages de données sont presque tous des menaces potentielles pour votre base de données. Cela signifie qu'il existe de nombreuses mesures de sécurité - des pare-feu à l'audit et aux sauvegardes de disque - pour minimiser tout dommage potentiel et empêcher la perte de l'intégralité de la base de données. La plupart des entreprises ont leurs propres protocoles de sécurité des données pour se protéger contre certaines attaques et dommages potentiels.

Installation d'un pare-feu pour la base de données, une sorte de barrière de sécurité qui interdit toutes les connexions inconnues, est la forme la plus basique de sécurité des bases de données. Les pare-feu sont installés sur la plupart des ordinateurs et sont conçus de manière à ce que les pirates informatiques aient des difficultés à se connecter à l'ordinateur de la victime. Les pare-feu fonctionnent en filtrant les connexions réseau et seuls les ordinateurs ou utilisateurs de confiance peuvent accéder à la base de données. Alors que les pirates informatiques expérimentés peuvent contourner cela, un pare-feu offre un niveau de sécurité élevé.

Chiffrement Est une autre mesure de sécurité pour une base de données dans laquelle les données sont cryptées ou rendues illisibles pour toute personne accédant à la base de données. Lors de l'utilisation du cryptage, l'algorithme encode les caractères en charabia, il ne peut donc pas être lu. Cela signifie que si le pirate a une certaine connaissance des clés de cryptage, les informations dont vous avez besoin pour changer les données cryptées des caractères illisibles en une forme intelligible, il n'y a aucun moyen pour lui de lire la base de données.

Audit- c'est à ce moment qu'un superviseur ou un manager vérifie la base de données pour s'assurer que rien n'y a changé. Ce type de protection de base de données est généralement effectué physiquement, par quelqu'un qui peut lire la base de données, ou pour les bases de données volumineuses à l'aide d'un programme pour voir que l'intégrité de la base de données reste la même. De plus, l'audit peut inclure la vérification de l'accès à la base de données et l'observation de ce que la personne a fait lorsqu'elle a accédé à la base de données. Cela empêche le vol de données ou au moins permet aux administrateurs de découvrir qui a perpétré le vol de données.

Sauvegardes régulières de la base de données Est une mesure de sécurité de base de données qui peut protéger la base de données contre diverses menaces. Lorsque la base de données est sauvegardée régulièrement, cela signifie que les données seront stockées sur un autre disque dur ou serveur. Si la base de données perd tout ou partie des informations, elle peut être redémarrée rapidement avec une perte minimale à l'aide d'une sauvegarde. En sauvegardant la base de données, les administrateurs peuvent éviter des dommages physiques à l'ordinateur, tels qu'un incendie, des dommages à la base de données ou une corruption de la base de données, par surcharge.