Обеспечение надежности и работоспособности базы данных

 

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

Cуществуют следующие типы защиты данных:

• Авторизация пользователей.

• Представления.

• Резервное копирование и восстановление.

• Поддержка целостности.

• Шифрование.

• Вспомогательные процедуры.

1) Авторизация – предоставление прав (или привилегий), позволяющих их вла­дельцу иметь законный доступ к системе или к ее объектам.

Средства авторизации пользователей могут быть встроены непосредственно в про­граммное обеспечение и управлять не только предоставленными пользователям пра­вами доступа к системе или объектам, но и набором операций, которые пользователи могут выполнять с каждым доступным ему объектом. По этой причине механизм ав­торизации часто иначе называют подсистемой управления доступом. Термин “владелец” в определении может представлять пользователя-человека или програм­му. Термин “объект” может представлять таблицу данных, представление, приложе­ние, процедуру или любой другой объект, который может быть создан в рамках сис­темы. В некоторых системах все предоставляемые субъекту права должны быть явно указаны для каждого из объектов, к которым этот субъект должен обращаться. Ав­торизация пользователей с помощью средств языка SQL будет обсуждаться в юните 2. Процесс авторизации включает аутентификацию субъектов, требующих полу­чения доступа к объектам.

Аутентификация – механизм определения того, является ли пользователь тем, за кого себя выдает.

За предоставление пользователям доступа к компьютерной системе обычно отве­чает системный администратор, в обязанности которого входит создание учетных за­писей пользователей. Каждому пользователю присваивается уникальный идентифи­катор, который используется операционной системой для определения того, кто есть кто. С каждым идентификатором связывается определенный пароль, выбираемый пользователем и известный операционной системе. При регистрации пользователь должен предоставлять системе свой пароль для выполнения проверки (аутентификации) того, является ли он тем, за кого себя выдает.

 

Рис. 15. Общая схема типичной многопользовательской компьютерной системы

 

Подобная процедура позволяет организовать контролируемый доступ к компьютерной системе, но не обязательно предоставляет право доступа к СУБД или иной прикладной программе. Для получения пользователем права доступа к СУБД может использоваться отдельная подобная процедура. Ответственность за предоставление прав доступа к СУБД обычно несет администратор базы данных, в обязанности которого входит создание индивидуальных идентификаторов пользователей, но на этот раз уже в среде самой СУБД. Каждый из идентификаторов пользователей СУБД также связывается с паролем, который должен быть известен только данному пользователю. Этот пароль будет использоваться подпрограммами СУБД для идентификации данного пользователя.

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

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

Привилегии. Как только пользователь получит право доступа к СУБД, ему могут автоматически предоставляться различные другие привилегии, связанные с его идентификато­ром. В частности, эти привилегии могут включать разрешение на доступ к опреде­ленным базам данных, таблицам, представлениям и индексам или же право запуска различных утилит СУБД. Некоторые типы СУБД функционируют какзакрытые сис­темы, поэтому пользователям помимо разрешения на доступ к самой СУБД потребу­ется иметь отдельные разрешения и на доступ к конкретным ее объектам. Эти раз­решения выдаются либо АБД, либо владельцами определенных объектов системы. В противоположность этому,открытые системы по умолчанию предоставляют авторизированным пользователям полный доступ ко всем объектам базы данных. В этом случае привилегии устанавливаются посредством явной отмены тех или иных прав конкретных пользователей. Типы привилегий, которые могут быть предоставлены авторизированным субъектам, включают, например, право доступа к указанным ба­зам данных, право выборки данных, право создания таблиц и других объектов.

Право владения и привилегии. Некоторыми объектами в среде СУБД владеет сама СУБД. Обычно это владение ор­ганизуется посредством использования специального идентификатора особого супер­пользователя, например с именем Database Administrator. Как правило, владение не­которым объектом предоставляет его владельцу весь возможный набор привилегий в отношении этого объекта. Это правило применяется ко всем авторизированным пользо­вателям, получающим права владения определенными объектами. Любой вновь соз­данный объект автоматически передается во владение его создателю, который и полу­чает весь возможный набор привилегий для данного объекта. Тем не менее, хотя поль­зователь может быть владельцем некоторого представления, единственной привилегией, которая будет предоставлена ему в отношении этого объекта, может ока­заться право выборки данных из этого представления. Причина подобных ограничений состоит в том, чтобы данный пользователь имеет столь ограниченный набор прав в отно­шении базовых таблиц созданного им представления. Принадлежащие владельцу привилегии могут быть переданы им другим авторизированным пользователям. Например, владелец нескольких таблиц базы данных может предоставить другим пользователям право выборки информации из этих таблиц, но не позволить им вносить в эти таблицы какие-либо изменения. В некоторых типах СУБД всякий раз, когда пользователю предоставляется определенная привилегия, дополнительно может указываться, передается ли ему право предоставлять эту привилегию другим пользователям (уже от имени этого пользователя). Естественно, что в этом случае СУБД должна контролировать всю це­почку предоставления привилегий пользователям с указанием того, кто именно ее предоставил, что позволит поддерживать корректность всего набора установленных в системе привилегий. В частности, эта информация будет необходима в случае отмены предоставленных ранее привилегий для организации каскадного распространения вно­симых изменений среди цепочки пользователей.

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

2) Представления (подсхемы) – это динамический результат одной или нескольких реляцион­ных операций с базовыми отношениями с целью создания неко­торого иного отношения.

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

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

3) Резервное копирование и восстановление – периодически выполняемая процедура получения копии базы данных и ее файла журнала (а также, возможно, программ) на но­сителе, сохраняемом отдельно от системы.

Любая современная СУБД должна предоставлять средства резервного копирова­ния, позволяющие восстанавливать базу данных в случае ее разрушения. Кроме того, рекомендуется создавать резервные копии базы данных и ее файла журнала с неко­торой установленной периодичностью, а также организовывать хранение созданных копий в местах, обеспеченных необходимой защитой. В случае отказа, в результате которого база данных становится непригодной для дальнейшей эксплуатации, ре­зервная копия и зафиксированная в файле журнала оперативная информация ис­пользуются для восстановления базы данных до последнего согласованного состоя­ния.

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

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

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

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

– алгоритм шифрования, который описывает, как с помощью ключа шифрования преобразовать обычный текст в шифротекст;

– ключ дешифрования, предназначенный для дешифрования шифротекста;

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

Некоторые системы шифрования, называемыесимметричными, использующие один и тот же ключ как для шифрования, так и для дешифрования, при это предполагается наличие защищенных линий связи, предназначенных для обмена ключами. Однако большинство пользователей не имеют доступа к защищенны линиям связи, поэтому для получения надежной защиты длина ключа должна быть не меньше длины самого сообщения. Тем не менее большинство эксплуатируемых систем построено на использовании ключей, которые короче самих сообщений. Одна из распространенных систем шифрования называется DES (Data Encryption Standard) – в ней используется стандартный алгоритм шифрования, разработанный фирмой IBM. В этой схеме для шифрования и дешифрования используется один и тот же ключ, который должен храниться в секрете, хотя сам алгоритм шифрования не является секретным. Этот алгоритм предусматривает преобразование каждого 64-битового блока обычного текста с использованием 51-битового ключа шифрования. Система шифрования DES расценивается как достаточно надежная далеко не всеми – некоторые разработчики полагают, что следовало бы использовать более длинное значение ключа. Так, в системе шифрования PGP (Pretty Good Privacy) используется 128-битовый симметричный алгоритм, применяемый для шифрования блоков отсылаемых данных.

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

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

Другой тип систем шифрования предусматривает использование для шифровки и дешифровки сообщений различных ключей – подобные системы принято называть несимметричными. Примером такой системы является система с открытым ключом, предусматривающая использование двух ключей, один из которых является открытым, а другой хранится в секрете. Алгоритм шифрования также может быть открытым, поэтому любой пользователь, желающий направить владельцу ключей зашифрованное сообщение, может использовать его открытый ключ и соответствующий алгоритм шифрования. Однако дешифровать данное сообщение сможет только тот, кто знает закрытый ключ шифрования. Системы шифрования с открытым ключом могут также использоваться для отправки вместе с сообщением “цифровой подписи”, подтверждающей, что данное сообщение было действительно отправлено владельцем открытого ключа. Наиболее популярной несимметричной системой шифрования является RSA. Как правило, симметричные алгоритмы являются более быстродействующими, чем несимметричные, однако на практике обе схемы часто применяются совместно, когда алгоритм с открытым ключом используется для шифрования случайным образом сгенерированного ключа шифрования, а уже этот случайный ключ – для шифровки самого сообщения с применением некоторого симметричного алгоритма.

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

Копирование. Процедуры, регламентирующие процессы создания резервных копий, определя­ются типом и размерами эксплуатируемой базы данных, а также тем набором соот­ветствующих инструментов, который предоставляется используемой СУБД. Эти процедуры должны включать необходимые этапы, на которых будет непосредственно выполняться создание резервной копии. Крупные базы данных могут полностью копироваться раз в неделю или даже раз в месяц, но при этом следует организовать обязательное инкрементное копирование, выполняемое с более высокой частотой. День и час выполнения резервного копирования должен ус­танавливаться ответственными лицами.

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

Восстановление. Как и процедуры копирования, процедуры восстановления также должны быть тщательно продуманы и проработаны. То, какие именно процедуры восстановления будут выполняться, должно определяться типом имевшего место отказа (разрушение носителя, отказ программного обеспечения или отказ оборудования системы). Кроме того, процедурами восстановления должны учитываться особенности методов восста­новления, принятых в используемой СУБД. В любом случае разработанные процеду­ры восстановления должны быть тщательно протестированы, поскольку необходимо получить полную гарантию, что они работают правильно, еще до того, как произой­дет реальный отказ системы. В идеале, процедуры восстановления должны регуляр­но тестироваться с некоторым установленным интервалом.

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

Установка или модернизация системного программного обеспечения. В обязанности АБД входит выполнение модернизации программного обеспечения СУБД при поступлении от разработчика очередных пакетов изменений. В некоторых случаях вносимые изменения оказываются совсем незначительными и касаются только небольшой части модулей системы. Однако возможны ситуации, когда потребуется полная ревизия всей установленной системы. Как правило, каждый поступающий па­кет изменений сопровождается печатной или интерактивной документацией, содержа­щей подробные сведения о сути изменений и их назначении. Многие склонны пола­гать, что после установки любого из пакетов модернизации продолжение нормального функционирования существующих баз данных и прикладного программного обеспече­ния автоматически гарантируется. С ростом интенсивности использования базы дан­ных и увеличением объема сопроводительной документации к пакету эта убежденность укрепляется. Однако обеспечение защиты данных и приложений имеет превалирую­щую важность, и это следует учитывать. Никакие изменения и модернизации ни в ко­ем случае не должны вноситься в систему без предварительной оценки их возможного влияния на имеющиеся данные и программное обеспечение.

Результатом ознакомления с сопроводительной документацией пакета должен стать план действий по его установке. В этом плане должны быть отражены любые измене­ния, которые могут повлиять на базу данных и приложения, а также предложены ре­шения по их реализации. В некоторых случаях может потребоваться, чтобы програм­мисты выполнили поиск в тексте программ определенных конструкций или осущест­вили какие-либо иные подготовительные действия. Иногда требуемые изменения могут оказаться минимальными – после модернизации системы достаточно будет просто пе­рекомпилировать некоторые из программ. В других случаях могут потребоваться более существенные подготовительные действия, например изменение типа используемых данных. Однако какие бы изменения ни потребовались, все они должны быть учтены и для каждого из них должна быть дана оценка времени выполнения с учетом объема всего имеющегося программного обеспечения. Главная задача АБД – обеспечить плав­ный и безболезненный переход от старой версии системы к новой.

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

Изменения, вносимые в программы СУБД в результате модернизации, могут ока­зать влияние на любые используемые прикладные программы, созданные различны­ми программистами. Поэтому список необходимых изменений должен быть либо ра­зослан всем заинтересованным лицам, либо открыт для всеобщего доступа. Некото­рые из вносимых изменений могут представлять особый интерес, если они связаны, например, с исправлением замеченных ранее ошибок и позволяют удалить использо­вавшиеся до этого искусственные способы их обхода. Кроме того, желательно, чтобы сопроводительная документация включала список известных ошибок с указанием использовавшихся путей их обхода (“заплат”). Эти сведения также должны быть ра­зосланы всем заинтересованным лицам или сделаны общедоступными.

Контрмеры. Некомпьютерные средства контроля включают такие методы, как выработку ог­раничений, соглашений и других административных мер, не связанных с компью­терной поддержкой:

– меры обеспечения безопасности и планирование защиты от непредвиден­ных обстоятельств;

– контроль за персоналом;

– защита помещений и хранилищ;

– гарантийные соглашения;

– договоры о сопровождении;

– контроль за физическим доступом.

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

В документе по мерам обеспечения безопасности должно быть определено сле­дующее:

– область деловых процессов организации, для которой они устанавливаются;

– ответственность и обязанности отдельных работников;

– дисциплинарные меры, принимаемые в случае обнаружения нарушения установленных ограничений;

– процедуры, которые должны обязательно выполняться.

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

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

– сведения о том, кто является главным ответственным лицом и как можно установить с ним контакт;

– информацию о том, кто и на каком основании принимает решение о воз­никновении необычной ситуации;

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

• сведения о расположении альтернативных сайтов;

• сведения о необходимом дополнительном оборудовании;

• сведения о необходимости дополнительных линий связи;

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

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

• сведения о наличии страховки на случай конкретной ситуации.

Любой разработанный план защиты от непредвиденных обстоятельств должен пе­риодически пересматриваться и тестироваться на предмет его осуществимости.

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

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

Контроль за физическим доступом. Внутренний контроль. Этот метод контроля используется внутри отдельных зданий и предназначен для управления тем, кто будет иметь доступ в определенные помещения этих зданий. Например, наиболее “ответственные” помещения (в которых установле­ны основные компьютеры) могут быть оборудованы системами входного контроля. В подобных системах могут использоваться самые различные принципы, например специальные ключи, карточки, кодовые замки или средства указания пароля. Наи­более сложные комплексы предполагают использование отпечатков пальцев, снимков радужной оболочки глаз, фиксацию особенностей голоса или почерка. Однако в на­стоящее время очень немногие коммерческие организации применяют столь изощренные методы контроля – в основном из-за их высокой стоимости.

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

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

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

Защита от компьютерных вирусов. Важнейшей проблемой, особенно актуальной для среды ПК, является риск занесе­ния в систему нежелательных и зачастую просто опасных программ, называемых ком­пьютерными вирусами. Беспечное и небрежное отношение к методам использования оборудования часто приводит к поражению систем различными вирусами – например, в тех случаях, когда персонал приносит на рабочие места и запускает на своих компь­ютерах различные игровые программы. Распространению вирусов в системе способст­вует бесконтрольный обмен дискетами, хотя некоторые вирусы способны самостоя­тельно распространяться в сетевой среде.

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

СУБД и защита в Web. К мерам защиты, связанным с использованием СУБД в среде Web, относятся следующие:

– прокси-серверы;

– брандмауэры;

– использование цифровой подписи;

– алгоритмы создания дайджеста сообщений и цифровой подписи;

– цифровые сертификаты;

– использование церберов;

– использование технологий SSL и SHTTP.