Защита информации в базах данных

SELECT pay.salary      

FROM  payroll pay      

WHERE  id = p_erap_id;

BEGIN 

IF NOT checkdept (p_emp_id) THEN  

raise applicatiori_error (-20001, 'Insufficient Privilege'); 

END IF; 

IF NOT mgr THEN  

OPEN c_old_salary;  

FETCH c__old_s alary INTO l__salary;   

CLOSE c_old_salary, 

ELSE  

l_salary := p_salary; 

END IF; 

UPDATE payroll 

SET    name = p_name      

,payment_period = p_payment_period       

,salary = l_salary 

WHERE  id = p_emp_id;

END upd;

-Код инициализации  пакета

BEGIN 

OPEN  c_me; 

FETCH c_me 

INTO ray_dept    

,mgr_flag; 

CLOSE c_me; 

IF mgr_flag = 'Y' THEN   

mgr := TRUE; 

ELSE   

mgr := FALSE; 

END IF;

END k_payroll;

/

Восстановление базы данных

 
В том случае, если нельзя восстановить БД после сбоя автоматически, восстановление БД выполняется в два этапа:

1.  
   перенос на рабочий диск резервной копии базы данных (или той её части, которая была повреждена);
2.  
   перезапуск сервера БД с повторным проведением всех транзакций, зафиксированных после создания резервной копии и до момента возникновения сбоя.

 
Если в системе есть архив транзакций, то повторное проведение транзакций может проходить автоматически или под управлением пользователя. 
 
Если произошёл сбой процесса сервера, то требуется перезагрузка сервера для восстановления БД. При перезагрузке СУБД может по содержимому системных файлов узнать, что произошёл сбой, и выполнить восстановление автоматически (если это возможно). Восстановление БД в этой ситуации означает приведение всех данных в БД в согласованное состояние, т.е. откат незавершённых транзакций и проверку того, что все изменения, внесённые завершёнными транзакциями, попали на диск. 
 
Для оптимизации регистрации изменений некоторые СУБД могут записывать в журнал информацию о незавершённых транзакциях, предвидя их завершение. Более того, не дожидаясь подтверждения транзакции, СУБД переписывает на диск модифицированные блоки (при формировании контрольной точки). Поэтому в каждый момент времени в журнале транзакций и в БД может находиться небольшое число записей, модифицированных незавершёнными транзакциями. Эти записи помечаются соответствующим образом. С другой стороны, т.к. изменения сначала попадают в журнал транзакций и только потом в файл базы данных, в любой момент времени БД может не содержать блоков данных, модифицированных подтверждёнными транзакциями. Поэтому в результате сбоя могут возникнуть две потенциальные ситуации:

•  
  Блоки, содержащие подтверждённые модификации, не были записаны в файлы данных, так что эти изменения отражены лишь в журнале транзакций. Следовательно, журнал транзакций содержит подтверждённые данные, которые должны быть переписаны в файлы данных.
•  
  Журнал транзакций и блоки данных содержат изменения, которые не были подтверждены. Изменения, внесенные неподтверждёнными транзакциями, во время восстановления БД должны быть удалены из файлов данных.

 
Для того чтобы разрешить эти ситуации, СУБД автоматически выполняет два этапа при восстановлении после сбоев: прокрутку вперед и прокрутку назад.

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

 
После выполнения этих этапов восстановления БД находится в согласованном состоянии и с ней можно работать.

 

 

 

Заключение

 

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

К сожалению, подобная динамичность объективно затрудняет обеспечение надежной защиты. Причин тому несколько:

•  повышение быстродействия микросхем, развитие архитектур с высокой степенью параллелизма позволяет методом грубой силы (перебором вариантов) преодолевать барьеры (прежде всего криптографические), ранее казавшиеся неприступными;

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

• появление новых информационных сервисов ведет и к появлению новых угроз как «внутри» сервисов, так и на их стыках;

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

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

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

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