Oracle DBA Forum  

Вернуться   Oracle DBA Forum > Oracle University Official Study Notes (RUS) > База данных Oracle 10g Администрирование > База данных Oracle 10g Администрирование I

Ответ
 
Опции темы Опции просмотра
  #1  
Старый 24.09.2009, 15:38
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию 10 Обеспечение безопасности базы данных Oracle

__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #2  
Старый 24.09.2009, 15:39
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Рассматриваемые вопросы



Рассматриваемые вопросы

Этот урок - начальная точка изучения безопасности Oracle.

Дополнительна информация предоставляется в следующей документации:

Oracle Database Concepts 10g Release 2 (10.2)
Oracle Database Administrator's Guide 10g Release 2 (10.2)
Oracle Database Security Guide 10g Release 2 (10.2)

Кроме того, подготовку по вопросам безопасности можно получить на следующих курсах:

Oracle Database 10g: Администрирование II (10gDBA2)
Oracle Database 10g: Security (10gDBS)
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #3  
Старый 24.09.2009, 16:17
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Требования безопасности в отрасли информационных технологий



Требования безопасности в отрасли информационных технологий

Требования безопасности до недавнего времени были предметом индивидуального беспокойства. Если сведения не относились к государственной или военной информации, то к их защите предъявлялись незначительные юридические нормы. Однако такое положение быстро меняется. Приняты разнообразные законы, обязывающие обеспечивать конфиденциальность и аккуратное ведение личной информации. Среди этих законов есть также такие, которые предъявляют требования к аудиту проводимых мер безопасности.

Юридические акты. Каждый из приведенных здесь законов, предъявляет специфические требования. Данный перечень отражает законы, принятые по всему миру. Без сомнения, имеются отличия в законах безопасности, действующих в разных точках мира.

Закон Сарбэйнса - Оксли (Sarbanes-Oxley Act, SOX) требует укреплять публичные компании и контроль документов внутри них, чтобы не допустить со стороны отдельных личностей мошеннические действия, которые могут подорвать финансовое состояние организаций или скомпрометировать точность их финансовых отчетов. Президенты и финансовые директора компаний должны удостоверять соответствие внутреннего контроля предъявляемым требованиям, а также точность финансового отчета. Эти должностные лица могут быть оштрафованы и заключены в тюрьму за лживые отчеты. Отдельные положения SOX содержат требования по предоставлению данных, используемых для создания отчетов, а также требования к внутреннему контролю, обеспечивающему целостность финансовой информации.

Закон о преемственности страхования и отчетности в области здравоохранения (Health Information Portability and Accountability Act, HIPAA) действует с целью защиты персональной информации о здоровье и недопущения публичного разглашения или злоупотребления сведениями о здоровье отдельной личности. Держатели информации должны предоставлять журналы аудита доступа всех, кто обращался к этим данным.

Закон Великобритании о защите данных (UK Data Protection Act) действует с целью защиты персональной информации. Он включает восемь пунктов, один из которых требует, чтобы данные хранились защищено.

Другие законы:

Закон о правах семьи и конфиденциальности сведений, предоставляемых в учебные заведения (Family Educational Rights and Privacy Act, FERPA)
защищает данные о здоровье и персональные сведения, хранящиеся в школах.

Законодательство Калифорнии (California Breach Law) требует от организаций, хранящих различные персональные сведения (personal identity information, РП), защищать эти данные. К такой информации, например, относятся сведения о кредитных карточках, водительских удостоверениях и идентификационных государственных номерах (government identity numbers). В случае дискредитации такой информации организация обязана уведомить все вовлеченные лица.

Два закона, CA-SB-1386 и СА-АВ-1950, применимы к организациям, хранящим персональные сведения (РП).

Федеральный закон об управлении безопасностью информации (Federal Information Security Management Act, FISMA) предоставляет руководство и стандарты безопасности, основанные на федеральном стандарте обработки информации (Federal Information Processing Standard, FIPS), сопровождаемом национальным институтом стандартов (National Institute of Standards, NIST). Эти стандарты применяются в организациях, обрабатывающих информацию для правительства США.



Аудит. Многие из этих законов включают положения, требующие проверку планов безопасности (внутренних планов) путем периодического аудита. SOX требует, чтобы неясности и вопросы были проинтерпретированы должностными лицами организации. Реализация закона может значительно различаться в зависимости от уровня детализации, который необходим должностным лицам Поскольку положения SOX сформулированы нечетко, а санкции за их нарушение серьезные, важно защитить свою компанию. Стоимость осуществления мер безопасности должна быть сбалансирована с рисками ее нарушения. Никто не может уверить вас в 100% безопасности. Хорошее решение -достижение консенсуса в отрасли. Если достигнуто согласие о минимальных действиях по безопасности, производимых с надлежащей аккуратностью, тогда можно обезопасить себя от наихудших санкций закона. Среди организаций, в которых на хорошем уровне осуществляется деятельность по разработки стандартов отрасли, можно назвать следующие: SysAdmin, Audit, Network, Security (SANS) Institute, CERT/CC (для министерство обороны деятельность этой организации осуществляет Carnegie Mellon University), а также необходимо упомянуть стандарт 1SO-17799. Сведения см. на сайтах:

http://www.sans.org/index.php
http://www.cert.org/nav/index.html
http://www.isol7799software.com/


ISO-17799 certification Standard - это международный стандарт по применению лучших практических приемов обеспечения безопасности, сертификации и оценки рисков. Он охватывает широкий диапазон проблем и включает предварительно созданные политики.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 24.09.2009 в 16:21.
Ответить с цитированием
  #4  
Старый 24.09.2009, 16:23
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Разделение ответственности



Разделение ответственности

Ниже приведены главные требования разделения служебных обязанностей.

Администраторами баз данных (АБД) должны быть доверенные люди. АБД трудно ограничить. Для выполнения своей работы ему (ей) необходимы привилегии высокого уровня. АБД занимает ответственный пост и должен быть тщательно проверен. Даже АБД, которому доверяют, должен быть подотчетен.

Принимайте во внимание следующее:

Злоупотребление доверием. АБД может потенциально с умыслом использовать зашифрованные пароли из представления DBA_USERS.
Использование журналов аудита для защиты от злоупотреблений ответственного должностного лица. Когда аудит тщательно реализован с учетом рекомендаций, тогда журнал аудита может показать, что конкретное лицо не выполняло нарушающих чего-либо действий, а также не совершало дискредитирующих поступков. Хорошо спроектированный аудит может перехватить попытку злоумышленника перевести подозрение на доверенного пользователя.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #5  
Старый 24.09.2009, 16:24
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Безопасность базы данных




Безопасность базы данных

Oracle База данных Oracle 10g предоставляет лучшие в отрасли возможности системы безопасности. Однако администратор базы данных должен их правильно настроить, чтобы система безопасности стала эффективной. Кроме того, необходимо проводить постоянное наблюдение за операциями, выполняемыми в базе данных.


Ограничение доступа к данным и службам

Всем пользователям нельзя предоставлять доступ ко всем данным. Ограничения зависят от хранимой в базе данных информации и могут быть вызваны бизнес-требованиями, потребительскими ожиданиями и в большей степени правовыми нормами. Необходимо защитить от несанкционированного доступа информацию о кредитной карточке, сведения о состоянии здоровья и многое другое. Oracle предоставляет дифференцированный авторизированный контроль для ограничения доступа к БД. Ограничение доступа должно основываться на применении принципа выделения наименьших привилегий.


Аутентификация пользователей

Чтобы ограничить доступ к секретной информации, система, прежде всего, должна знать, кто пытается получить доступ к данным. Компромиссный подход к аутентификации может сделать бесполезными все остальные меры предосторожности, предпринимаемые в целях безопасности. Наиболее общая форма пользовательской аутентификации заключается в запросе у пользователя чего-то такого, что он знает, например, пароля. Безопасность системы значительно повышается, когда вводятся простые правила проверки сложности пароля. Более строгие методы аутентификации основываются на запросе у пользователя чего-то такого, что у пользователя есть, например, маркера доступа (token) или сертификата доступа с использованием открытого ключа (Public Key Infrastructure certificate - РКI certificate). Наиболее строгая форма аутентификации состоит в идентификации пользователя по биометрическим характеристикам: отпечаткам пальцев, сканированию радужной оболочке глаза, по образцу костной структуры и т.д. Опция Oracle Advanced Security поддерживает такие усовершенствованные методы аутентификации, как идентификация с использованием маркера доступа, биометрических данных и сертификатов доступа. Неиспользуемые учетные записи пользователей следует заблокировать, чтобы предотвратить попытки несанкционированного доступа.


Наблюдение за подозрительными операциями

Даже пользователь, прошедший процедуру аутентификации и авторизации, может иногда попытаться выполнить несанкционированные действия. Выявление необычных операций в базе данных, например, внезапных больших запросов информации о кредитных карточках, результатах исследований или другой секретной информации, может быть первым шагом при обнаружении воровства информации. Oracle предоставляет богатый набор инструментов аудита для отслеживания действий пользователей и выявления подозрительных тенденций.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #6  
Старый 24.09.2009, 16:32
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Принцип предоставления наименьших привилегий



Принцип предоставления наименьших привилегий

Применяйте принцип наименьших привилегий, начиная с самых низких уровней, а затем продолжайте использовать такой подход на каждом последующем уровне. Всегда присутствует новый вредоносный код , эксплуатирующий уязвимости программных компонентов компьютера, появление которого невозможно предвидеть. Применение принципа наименьших привилегий снижает вероятность такого компьютерного вторжения и останавливает угрозу.

Установка на машине только необходимого программного обеспечения. Уменьшение количества пакетов программного обеспечения снижает затраты на сопровождение и обновление (upgrades), вероятность появления "дыр безопасности" и конфликтов в программном обеспечении.

Запуск на машине только требуемых служб. При меньшем количестве служб меньше открытых портов и меньше направлений атак для злоумышленников.

Предоставление доступа к операционной системе (ОС) и базе данных только тем пользователям, которым доступ необходим. Меньше пользователей - меньше паролей и учетных записей. Снижается вероятность наличия учетных записей в открытом или просроченном состояниях. При меньшем количестве учетных записей администратору проще поддерживать их текущее состояние.

Ограничение доступа к учетной записи root или администратора. Необходимо тщательно защищать, вести аудит и никогда не использовать совместно учетную запись администратора.

Ограничение доступа к учетным записям с привилегиями SYSDBA и SYSOPER. Пользователи, которым необходимы эти роли, должны иметь собственные учетные записи и для них должен производиться аудит.

Предоставление доступа пользователям только к таким объектам базы данных, которые необходимы для выполнения их заданий. Пользователи, которым предоставлен доступ к большему числу объектов, чем это необходимо, имеют возможность причинить вред.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #7  
Старый 24.09.2009, 16:40
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Применение принципа наименьших привилегий



Применение принципа наименьших привилегий

Пользователю следует предоставлять только такие привилегии, которые ему необходимы для эффективного решения задачи. Применение этого принципа уменьшает риск того, что пользователи смогут случайно или умышленно изменить или просмотреть данные, к которым им не должны были быть предоставлены привилегии доступа, позволяющие это сделать.

Защита словаря данных. По умолчанию параметр 07_DICTIONARY_ACCESSIBILITY имеет значение FALSE. Не следует изменять этот параметр, если это не обосновано очень вескими причинами. Значение FALSE препятствует доступу пользователей с системными привилегиями ANY TABLE к базовым таблицам словаря. Кроме того, значение FALSE не допускает подсоединения пользователя SYS без привилегии SYSDBA.

Лишние привилегии, выданные всем (PUBLIC), должны быть отобраны.
Приведенные ниже пакеты чрезвычайно полезны приложениям, которые в них нуждаются, но требуют надлежащего конфигурирования для безопасного использования. Отберите право их выполнения у PUBLIC и предоставьте его отдельным ролям, которым они необходимы.


В число пакетов с большими возможностями, которыми можно злонамеренно воспользоваться, входят:

UTL_SMTP; позволяет послать произвольное почтовое сообщение с помощью базы, используемой в качестве почтового сервера, работающего по протоколу SMTP (Simple Mail Transfer Protocol). Предоставление всем (PUBLIC) права применения этого пакета может привести к несанкционированному обмену почтовыми сообщениями.
UTL_TCP; разрешает устанавливать серверу базы данных исходящие сетевые соединения с любыми принимающими и находящимися в ожидании сетевыми службами. Таким образом, произвольно выбранные данные могут быть посланы между сервером базы данных и ожидающей сетевой службой.
UTL_HTTP; разрешает серверу базы данных запрашивать и принимать данные, передаваемые по протоколу HTTP. Выделение привилегии на этот пакет всем (PUBLIC) может позволить передать данные с помощью форм HTML на Web-сайт злоумышленников.
UTL_FILE; если этот пакет неправильно сконфигурирован, отрывается доступ на текстовом уровне к любому файлу в операционной системе хоста. Даже при правильном конфигурировании пакет не различает вызывающие его приложения. В результате приложение, имеющее доступ к пакету UTL_FILE может писать произвольные данные в то же самое место, в которое пишет другое приложение.


Ограничение доступа пользователей к каталогам ОС.

Объект DIRECTORY, хранимый внутри базы данных, позволяет АБД отображать директорию БД в путь ОС и предоставлять привилегии на такие директории отдельным пользователям.


Сокращение числа пользователей с административными привилегиями.

Никогда не предоставляйте больших привилегий пользователям, чем это необходимо. Пользователям, не являющимся администраторами, не следует предоставлять роль DBA. Чтобы применить принцип наименьших привилегий, ограниченно предоставляйте следующие виды привилегий:

позволяющие предоставлять системные и объектные привилегии;
позволяющие соединяться с правами пользователя SYS (SYSDBA и SYSOPER);
привилегии роли DBA, например, DROP ANY TABLE.


Ограничение на удаленную аутентификацию БД.

Параметр REMOTE_OS_AUTHENT по умолчанию имеет значение FALSE. Это значение не следует изменять, за исключением ситуации, когда всем клиентам можно доверить аутентификацию соответствующих пользователей.


В процессе удаленной аутентификации:

производится внешняя (externally) аутентификация пользователя БД;
аутентификация пользователя выполняется на удаленной системе;
пользователь подсоединятся к БД без дальнейшей аутентификации.
__________________
Чат форума (требуется аккаунт на github или twitter)

Последний раз редактировалось Marley; 02.11.2009 в 01:07.
Ответить с цитированием
  #8  
Старый 24.09.2009, 16:57
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Наблюдение за подозрительными действиями



Наблюдение за подозрительными действиями

Аудит означает сбор и хранение информации о том, что происходит в системе. Его выполнение увеличивает нагрузку на систему. Поэтому аудит должен быть целенаправленным и отслеживать только такие события, сведения о которых необходимо собирать. Соответствующим образом сфокусированный аудит оказывает минимальное влияние на производительность. Чрезмерно обширный аудит может существенно повлиять на производительность.

Обязательный аудит. Все базы данных Oracle выполняют аудит определенных действий, независимо от других опций и параметров аудита. Обязательный аудит фиксирует в журнальных файлах некоторые операции, например startup и shutdown.
Стандартный аудит базы данных. Задается на уровне системы с помощью параметра инициализации AUDIT_TRAIL. После включения аудита необходимо выбрать объекты и привилегии, за которыми необходимо вести наблюдение.
Аудит по значениям (value-based auditing). Такой аудит расширяет стандартный аудит БД, фиксируя не только произошедшее событие, но и фактические значения, которые были вставлены, изменены или удалены. Он реализуется с помощью триггеров базы данных.
Дифференцированный аудит (fine-grained auditing - FGA) расширяет стандартный аудит БД, регистрируя выполняемые команды SQL, а не только происходящие события.
Аудит АБД. Разделяйте аудит, который обязан выполнять АБД, и аудит, производимый аудитором или системным администратором, ведущим мониторинг действий АБД с использованием журнала аудита операционной системы.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #9  
Старый 24.09.2009, 16:58
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Стандартный аудит базы данных



Стандартный аудит базы данных

БД начинает собирать данные аудита после включения аудита базы данных и задания его опций, определяющих регистрацию событий входа в систему, использования системных и объектных привилегий, выполнения команд SQL.

Если значение AUDIT_TRAIL равно OS, тогда записи проводимого аудита сохраняются в журнале аудита, находящемся в операционной системе. В среде Windows это журнал событий (event log), в UNIX или Linux записи сохраняются в файле. Месторасположение этого файла задается в параметре AUDIT_FILE_DEST.

В случае, когда параметр AUDIT_TRAIL равен DB, записи аудита можно просмотреть в представлении DBA_AUDIT_TRAIL, принадлежащем схеме SYS.

Когда значение AUDIT_TRAIL равно XML или XML, EXTENDED, записи аудита записываются в XML-файлы в каталоге, на который указывает параметр AUDIT_FILE_DEST. Представление V$XML_AUDIT_TRAIL позволяет просмотреть все XML-файлы из этой директории.

Сопровождение журнала аудита - важная административная задача. В зависимости от фокусировки аудита, определяемого задаваемыми опциями, журнал с его результатами может расти очень сильно и чрезвычайно быстро. При отсутствии соответствующего сопровождения журнал может занять такое большое пространство, что это окажет влияние на производительность системы.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
  #10  
Старый 24.09.2009, 16:58
Marley Marley вне форума
Senior Member
 
Регистрация: 19.09.2009
Сообщений: 7,385
По умолчанию Включение аудита



Включение аудита

Необходимо включить аудит базы данных перед тем, как задавать установки аудита.
__________________
Чат форума (требуется аккаунт на github или twitter)
Ответить с цитированием
Ответ
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход


Текущее время: 19:19. Часовой пояс GMT +3.


Powered by vBulletin®