Задачи
• Не допускать использования простых паролей.
• Принудительно блокировать учетные записи пользователей на 10 минут после четырех неудачных попыток установления соединения.
• Освободить соединение сервера приложения от принудительного изменения пароля.
• Проводить аудит неудачных попыток подсоединения к базе данных.
1. Не допускать использования простых паролей.
а) Какие профили есть в базе данных?
б) Как просмотреть с помощью Enterprise Manager парольные ограничения, накладываемые профилем DEFAULT?
в) Используя утилиту SQL*Plus, соединитесь с базой данных как sysdba и выполните командный файл utlpwdmg.sql из каталога $ORACLE_HOME/rdbms/admin
г) Используя Enterprise Manager, просмотрите изменения, сделанные в профиле default командным файлом utlpwdmg.sql:
- срок действия нового пароля истекает через 60 дней;
- если пользователь в течение 10 дней не меняет пароль, его учетная запись блокируется;
- пароль можно повторно использовать через 1800 дней;
- после трех последовательных неудачных попыток соединения с неверным паролем вход пользователя автоматически блокируется на одну минуту.
2. Отредактируйте профиль default так, чтобы после четырех последовательных неудачных попыток подсоединения на 10 минут блокировалась учетная запись пользователя.
3. Освободите пользователя HR от принудительного изменения пароля.
а) Используя default как шаблон, создайте новый профиль HREXEMPTPROFILE.
б) Сделайте неограниченным параметр истечения срока действия пароля в новом профиле.
в) Назначьте новый профиль пользователю HR.
г) Что случится с пользователем HR, когда будет удален профиль HREXEMPTPROFILE? [Выберите один ответ]
1) Ничего не произойдет с пользователем HR. Команда удаления завершится с ошибкой, так как профиль HREXEMPTPROFILE нельзя удалить, если он назначен пользователю.
2) Пользователь HR тоже будет удален.
3) Профиль HREXEMPTPROFILE будет удален и пользователь HR не сможет подсоединяться, пока администратор не назначит ему другой профиль.
4) Пользователю HR автоматически будет назначен профиль DEFAULT.
4. Проведите аудит неудачных попыток подсоединения к базе данных.
а) Включите сбор данных аудита. Сохраняйте их в базе данных.
б) Включите создание строк аудита о пользователях, которые пытались неудачно войти в базу данных.
в) Проверьте, были ли зафиксированы неудачные попытки соединения с БД.
г) Почему необходимо перезапускать экземпляр после изменения параметра инициализации AUDIT_TRAIL?
д) Что случится, если оставить для параметра AUDIT_TRAIL его значение по умолчанию NONE?
Описание ситуации. Вы подозреваете, что кто-то просматривает и возможно изменяет оклад (salary) без соответствующих полномочий. Сконфигурируйте базу данных так, чтобы регистрировать неавторизованный доступ к данным о заработной плате и фиксировать сделанные в ней изменения.
Задачи
• Проводить аудит запроса столбца SALARY таблицы EMPLOYEES
• Проводить аудит изменений столбца SALARY таблицы EMPLOYEES, регистрируя:
- старое и новое значения; пользователя, сделавшего изменения;
- с какого места было сделано изменение.
1. Необходимо регистрировать доступ пользователей только к столбцу SALARY таблицы employees. Поэтому следует использовать дифференцированный аудит, а не стандартный аудит базы данных.
Примечание:для продолжения команды SQL*Plus на следующей строчке используется символ "-" .
а) С помощью пакета DBMS_FGA добавьте политику дифференцированного аудита для таблицы employees пользователя HR. Регистрируйте только, что кто-то читал столбец SALARY.
б) Проверьте, что записи аудита создают только команды SELECT, содержащие столбец SALARY.
2. Необходимо регистрировать старое и новое значение столбца SALARY таблицы employees, а не только операцию изменения. Поэтому следует использовать аудит по значениям, а не стандартный аудит базы данных. Он производится с помощью триггеров базы данных.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.