Ни для кого не станет новостью, что правит современным миром информация. Предприятие, защита баз данных которого находится на высоком уровне, при условии, что каждый сотрудник имеет возможность в любой момент воспользоваться необходимой информацией, может вполне надеяться на дальнейшее развитие. Если же данные организации находятся в беспорядке, даже при энтузиазме работников предприятие, скорее всего, ожидает крах.
Достаточно часто можно услышать, что на том или ином рынке появилась база данных какой-либо организации или государственной структуры. Порой можно увидеть, как на улице предлагают приобрести базы данных всевозможных компаний, от сотовых операторов до налоговых. Это говорит в первую очередь о том, что организации, целью которых должно быть обеспечение защиты данных, халатно относятся к своим обязанностям. Так каким же образом защитить информацию?
Права доступа к информации
Практически во всех организациях администраторы с программистами обладают беспрепятственным доступом к имеющимся базам данных. Сотрудников же, работающих в отделе информационных технологий, и вовсе можно считать главными в сети, поскольку они способны сделать практически все что угодно. Такая ситуация, как правило, возникает по следующим причинам.
Все сотрудники работают в одном месте и общаются друг с другом ежедневно как минимум по 8 часов. Со временем между ними начинают завязываться дружеские отношения. И здесь очень часто сотрудники начинают путать работу с дружбой, думая, как не дать другу необходимую ему информацию. Для распределения прав доступа к информации баз данных или изменения какой-либо конфигурации необходимы определенные привилегии. Очень часто администраторы перекладывают свои обязанности на программистов, предоставляя им тем самым право доступа, думая, что они справятся с работой лучше. Однако у программистов не может быть прав заниматься административной работой.
Так же рекомендуем это видео с форума Cisco:
Очень часто на практике встречается именно второй вариант, поэтому на нем стоит остановиться подробнее. Поскольку базы данных создают именно программисты, то чаще всего они обладают информацией о пароле, что не совсем безопасно. Правами должен обладать исключительно администратор баз данных и никто иной. В данном случае даже директор или начальник отдела могут не иметь таких привилегий.
Если в компании штат сотрудников не предусматривает наличия администратора баз данных, это плохо, поскольку в каждой организации должен быть человек, который бы занимался производительностью, оптимизацией и защитой данных. В некоторых случаях это может быть программист, однако он должен обладать для исполнения этой роли определенными правами.
Как правило, потеря данных происходит внутри организации, то есть причиной этого являются сами сотрудники. Однако, даже несмотря на это, некоторые продолжают не замечать угрозы, в результате чего базы данных по-прежнему продолжают свободно распространяться на дисковых носителях.
Роли, пользователи и аудит безопасности
При распределении права доступа применяются пользователи и роли. Последними являются определенные группы, предназначенные для объединения пользователей со схожими правами. К примеру, для всех сотрудников, работающих в бухгалтерском отделе, требуется обеспечить доступ к данным финансового характера. Для того чтобы не производить выдачу прав каждому работнику бухгалтерского отдела, их объединяют в роль с выдачей требуемого доступа.
Вполне возможна реализация в базе сразу трех объектов: пользователей, ролей и групп, однако чаще всего из них применяются только две – первый и последний. Каждый объект нуждается в управлении и отслеживании. Это необходимо для того, чтобы получающий права от ролей пользователь обладал доступом только к необходимым для решения конкретных поставленных задач данным.
Роли позволяют осуществлять контроль за управлением доступа и выдачей запретов и разрешений группам и пользователям. Роль также может содержать другую, иначе говоря, наследовать у нее права доступа. Это позволяет создавать иерархическую структуру прав.
К примеру, те сотрудники, имеющие доступ к базе данных компании, как правило, включаются в одну и ту же роль с предоставлением минимальных прав. В случае если участнику роли потребуется дополнительная привилегия для доступа к таблицам, его необходимо будет добавить в другую роль или выделить права определенной учетной записи.
Если каждый пользователь, работающий в базе, обладает учетной записью, чтобы определить текущего, существует переменная user, а запрос выглядит так: SELECT user from dual. Данный запрос позволяет вернуть имя пользователя, в настоящий момент осуществляющего соединение с сервером. При условии, что несколько пользователей входит через одно имя, запрос возвращает только одно общее для всех имя, что абсолютно не дает никаких результатов в аудите.
Далее, уже исходя из полученных данных, можно однозначно идентифицировать пользователя. Можно также определить и роли, в которые он входит.
Видео про основы баз данных:
Учетные записи и их безопасность
Ошибкой многих баз данных является то, что устанавливается, во-первых, достаточно простой пароль в системе, а во-вторых, он всем известен. Конечно, не стоит говорить о таких простых вещах, что пароль следует устанавливать, об этом должны знать все. Кроме того, данное правило относится абсолютно ко всем ИТ-областям.
Практика показывает, что при разработке нескольких корпоративных программ используется одна учетная запись для всех пользователей, которые используют базу данных. Кроме того, параметры ее прописываются в самой программе, а доступ к отдельным модулям, например, бухгалтерии или складу, реализуется программно. Если посмотреть с одной стороны, стоит заметить, что это достаточно удобно, поскольку есть возможность подключаться к базе на администраторских правах, что избавляет от хлопот с распределением прав и ролей. Однако если взглянуть с другой стороны, то это совсем не безопасно, так как большинство пользователей становятся все более «продвинутыми» в области интернета, да и родственники с друзьями вполне могут неплохо разбираться в безопасности. Достаточно узнать такую информацию, как пароль и имя, чтобы соединиться с базой данных для получения всей необходимой информации, а это далеко не всегда безопасно.
Стоит заметить, что SQL нельзя назвать слишком сложным языком и он не является секретом. Сегодня существует огромное количество программ, используя которые можно получить любую информацию из базы данных. Узнав имя и пароль, можно украсть информацию, и уже на следующий день важные для компании данные могут оказаться на прилавке какого-нибудь ларька, занимающегося продажей дисков.
Главное условие, которое необходимо соблюдать, ни в коем случае нельзя сохранять имя и пароль в самой программе. Кроме того, к программе должен быть ограниченный доступ без возможности открыть ее посторонним человеком. Для большей безопасности нужно выделить для каждого сотрудника компании свою учетную запись в базе данных с минимальными правами, в которой он мог бы вводить только собственные имя с паролем. Логика достаточно проста: если после введения пароля и имени программа авторизовалась, значит, доступ разрешен, в противном случае следует прервать процесс. Все достаточно просто в силу того, что была задействована авторизация базы данных.
Представления и защита данных
Достаточно удобным методом улучшения защиты и абстрагирования от структуры базы данных являются представления. Нельзя отрицать, что представления достаточно негативно влияют на производительность, однако в это же время положительны для защиты. Появляется возможность выдачи собственных прав доступа, но таблицы, содержащие данные, при этом остаются недоступными.
В каких случаях стоит использовать представления? Первое, с чем необходимо определиться, это в чем именно заключается недостаток. Представление является запросом на выборку, причем обращение может происходить сразу к нескольким таблицам. При простой выборке данных производительность не уменьшится. Можно использовать представления и в иных запросах для выборки данных, причем обращение происходит как к таблице.
При отсутствии особой необходимости давать доступ к системным данным категорически нельзя. В таком случае, чтобы не получилось так, что были предоставлены лишние права, необходимо начинать с разрешений исключительно на выборку данных при помощи запроса SELECT. Только при необходимости получить вставку дополнительных записей для выполнения поставленной перед пользователем задачи можно добавить на отдельную таблицу разрешение INSERT.
Особенно опасными действиями для баз данных считаются изменение информации и ее удаление, поэтому к распределению таких прав стоит подходить с особой внимательностью. Нужно убедиться в возможности удаления и изменения данных и уже только после этого выделять права, ведь отдельные таблицы могут или скорее должны исключительно пополняться.
Кроме того, нужно убедиться в том, что данные будут как можно чаще подвергаться воздействию. К примеру, таблица, содержащая данные о работниках компании, может лишь изменяться либо пополняться, однако удаляться информация не должна, поскольку это может повлиять, во-первых, на историю компании по работникам, а во-вторых, на целостность имеющихся данных. Бывают, конечно, случаи, когда сотрудник организации случайно создал лишнюю запись, в этом случае удалить ее может исключительно администратор базы данных.
О защите персональных данных:
Внешние ключи и резервное копирование
Как правило, наличие внешних ключей при внешнем соединении запрещает удаление информации, поэтому их многие боятся. Однако проблему достаточно просто решить установкой каскадного удаления, хотя стоит заметить, что специалисты обычно относятся к такой возможности отрицательно, поскольку при одном нелепом действии вся информация может быть уничтожена без подтверждающих действия запросов. Информация должна быть удалена только в том случае, если пользователь это подтвердил.
Внешних ключей пугаться вовсе не нужно, поскольку это лишь способ дополнительного контроля над целостностью информации баз данных. Проблемы с удалением, конечно, могут возникнуть, однако это скорее плюс, нежели минус, поскольку гораздо лучше информацию не суметь удалить, чем безвозвратно ее потерять. Кроме того, использование ключа при использовании его с индексом абсолютно никак не влияет на производительность системы.
Большинство пренебрегает резервным копированием до тех пор, пока не столкнется с проблемой потери данных. Этот фактор защиты можно даже отнести к основным, поскольку потеря информации часто происходит не только из-за хакеров и самих пользователей, неисправность самой системы может стать причиной. Сбои, происходящие в работе оборудования, вполне могут стать причиной потери данных, восстанавливать которые придется достаточно много времени – от нескольких часов до дней.
Лучшим выходом будет резервное копирование, которое заключается в минимальном количестве времени между моментом, когда произошла потеря системной информации, и восстановлением работы системы. Резервирование ни в коем случае не должно мешать действиям пользователя, а потеря информации должна быть как можно меньше.
Таким образом, политика безопасности баз данных должна быть максимально четкой и содержать несколько уровней. Нелишним будет реализация в сети, на серверах, а также на ПК антишпионов, антивирусов и других программ. Чем больше защита информации в базах данных имеет уровней, тем труднее ее будет преодолеть.
Защита информации баз данных должна осуществляться как от деятельности хакеров, так и пользователей-новичков, способных удалить или изменить данные просто по неопытности. Главное – помнить, что лучше всего предусмотреть возможность защитить данные от неопытных пользователей, чем терять огромное количество времени для того, чтобы их восстановить, создавая простои в работе компании.
Загрузка...