#019<< #020

DBA и безопасность

Создание гибкой системы безопасности MS SQL Server 7.0/2000
(По материалам статьи Моррис Льюис /Morris Lewis/ на sqlmag.com “Creating a Manageable Security”)

Ваша защита SQL Server должна быть простой для администрирования

В новых версиях SQL Server, появился целый набор гибких и мощных методов управления доступом пользователей к ресурсам SQL Server и базам данных. Эти нововведения вызвали некое замешательство администраторов серверов баз данных, поскольку они пробовали перенести на новую версию сервера модель защиты SQL Server 6.5. Не полное понимание отличий механизмов защиты SQL Server 7.0/2000 и SQL Server 6.5 привело к тому, что в бизнес приложениях появились «дыры» для не санкционированного доступа к данным. Прочитав эту статью, Вы сможете обеспечить такую систему безопасности SQL Server 7.0 (или SQL Server 2000) которая будет не только легко управляемой и гибкой, но и обеспечит Вам относительную безопасность доступа к данным.

Выбор схемы аутентификации

В этой статье, автор обращает внимание на принципиальное различие терминов «аутентификация» и «авторизация». Аутентификация – это подтверждение наличия прав у пользователя. Авторизация – это определение возможности допуска пользователя к операциям над объектами, к набору которых он прошёл аутентификацию. В нашем случае, аутентификация происходит тогда, когда пользователь подключается к SQL Server, а авторизация происходят всякий раз, когда пользователь пытается обращаться к данным или выполняет команды.
Первый шаг в формирование системы безопасности вы совершаете на этапе инсталляции сервера баз данных, когда выбираете механизм   аутентификации для доступа пользователей к SQL Server. Аутентификация SQL Server основана на проверке таких атрибут учётной записи пользователя, как account и password (пароль), которые хранятся в таблице Sysxlogins базы данных master. Механизм аутентификации Windows NT/2000 требует, чтобы санкционированность права доступы пользователя проверял контроллер домена. Вообще, автор рекомендует всегда использовать аутентификацию Windows NT /2000 для инсталляций, где сервер баз данных имеет сетевое подключение к контроллеру домена. Контроллер домена может быть, как Win2K, так и NT сервер, потому что в обоих случаях SQL Server анализирует специальный маркер доступа, который сопровождает список SID пользователя, сформированный в течение его аутентификации, и SID группы домена, в которую пользователь входит. Далее в статье автор показывает, как   SID используется при доступе к базе данных SQL Server и при назначении разрешений к объектам сервера. Особое внимание автор обращает на то, что совершенно не важно, как ОС формирует маркер доступа. SQL Server использует SID только в маркере доступа, не обращая внимание на то, какой сервер ему эту информацию предоставляет. Вы можете использовать любые сочетания SQL Server, 2000, SQL Server 7.0, Win2K и NT. Результат будет - тот же самый.
Единственная выгода использования механизма собственной аутентификации SQL Server, это – простота её настройки через Enterprise Manager. Главный недостаток такого механизма в том, что аутентификация SQL сервера локальна для каждого сервера баз данных, что создаёт трудности в случае нескольких обслуживаемых SQL серверов. Меньший, но все еще существенный недостаток последнего механизма аутентификации в том, что Вы должны управлять разрешениями для каждой базы данных индивидуально. Если пользователь нуждается в одинаковых разрешениях для двух базах данных, Вы должны назначать эти   разрешения вручную или формировать специальный сценарий, чтобы назначать их автоматически. Если у Вас не много пользователей (меньшее 25-ти), и изменения происходят не часто, собственная аутентификация SQL Server может быть приемлема. Во всех других случаях (исключаются только случаи применения специальных прикладных программ, которые управляют защитой самостоятельно), значительные трудности администрирования и управления логинами полностью перекрывают выгоды собственной аутентификации SQL сервера.

Web-аутентификация

Пожалуй самой большой опасностью не санкционированного доступа к данным является представление их в Web-страницах по запросу пользователей к SQL Server из интернет. Особую роль здесь приобретает организация правильной Web-аутентификации. К сожалению, типичным способом аутентификации из интернет состоит в том, чтобы внедрить логин к SQL Server и его пароль в Web-server-based программу, такую, как: Active Server Pages (ASP) или Common Gateway Interface сценарий (CGI). Сервер Web берет на себя   ответственность за аутентификацию пользователя, тогда, как программа использует ее собственный логин (часто это или systems administrator или логин в Sysadmin роли сервера) чтобы обратиться к данным сервера для предоставления отчёта пользователю в интернет.
Такой подход имеет несколько уязвимостей, наиболее значительными из которых являются: полная невозможность ревизовать действия на сервере; зависимость безопасности от Web-программы; недостаточная персонализация прав пользователей при определении разрешений в SQL Server.
Если вы используете Microsoft IIS 5.0 или IIS 4.0, у Вас имеется четыре «рычага» для подтверждения прав пользователей. Первый, должен представлять собой специальную учётную запись NT сервера для анонимных пользователей, причём   для каждого сайта и виртуального каталога. Все программы будут использовать этот контекст защиты при обращении к SQL серверу. Предоставляя учётной записи анонимного пользователя NT   соответствующие разрешения, Вы обеспечить ревизию действий этой учётной записи средствами ОС и получите имеющиеся у NT функциональные возможности управления учётными записями.
Второй «рычаг» - это наличие у каждого сайта механизма основной аутентификации, когда пользователи из интернет должны вводить в диалоговое окно действительные имена и пароли, прежде чем IIS предоставит им доступ на чтение страницы. IIS проверяет соответствие прав доступы каждого такого логина правам в базе данных защиты NT сервера, которая может размещаться локально или на контроллере домена. Когда пользователь выполняет программу или сценарий, который обращается к SQL серверу, IIS передаёт серверу баз данных права доступу этого пользователя, допущенного к просмотру страницы. Если Вы используете такой механизм, помните, что передача имени пользователя и пароля между IIS и браузером не зашифрована и может быть перехвачена обыкновенны снифером. Поэтому, Вы должны обеспечить Secure Sockets Layer (SSL) на любом Web сайте, который использует основную аутентификацию.
Если Ваши пользователи используют Microsoft Internet Explorer 5.0/4.0 или 3.0, Вы имеете третий «рычаг»: аутентификация NT совместно с   аутентификацией на Web-сайтах и виртуальных каталогах. IE передаёт IIS права доступу пользователя, зарегистрировавшегося на компьютере, а IIS использует эти права всякий раз, когда пользователь пробует обратиться к данным SQL сервера. Этим простым способом Вы можете аутентифицировать пользователей в домене удалённого сайта, если они зарегистрируются в домене, который имеет трастовые отношения с доменом Web сервера.
Наконец четвёртый «рычаг». Если ваши пользователи имеют персональные цифровые удостоверения, Вы можете отображать эти удостоверения на учётные записи NT в локальном домене. Базирующийся на той же самой технологии, что и сервер цифровых удостоверений, персональный сертификат проверяет достоверность прав пользователя и может заменить алгоритм аутентификации (Вызова/ответа) NT. В таком механизме, пользователь не должен обращаться к домену, который находится с ним в доверительных отношениях и даже может не знать ничего о домене, в котором находится IIS. Netscape navigator и IE автоматически посылают сертификаты к IIS с каждым запросом Web-страницы. В поставку IIS входит инструментарий, который позволяет администратору отображать на учётную запись NT цифровые сертификаты, заменяя обычный процесс регистрации с помощью имени и пароля.
Поскольку Вы имеете достаточно много возможностей подтверждения прав пользователей в NT, даже когда пользователи соединяются с SQL сервером из Internet и через IIS, лучше всего всегда планировать использование NT аутентификации, как основного средства подтверждения прав пользователей на доступ к серверу баз данных.

Пользователей собирайте в группы

Следующий шаг в формировании системы безопасности состоит в выделении групп, в которые будут помещены учётные записи пользователей, схожих по типу доступа к данным или объединённых использованием одного приложения. Обычно, прикладная программа имеет таких пользователей, как: операторы ввода данных, администраторы ввода данных, составители отчётов, бухгалтера, ревизоры, и администраторы доступа. Каждая группа нуждается в различных правах доступа к базе данных.
Самый простой путь администрирования разрешений доступа групп пользователей, это   создание глобальной группы домена, в которую входят все группы пользователей. Вы можете создавать отдельные группы для каждой прикладной программы или создавать группы, охватывающие более широкие категории, которые у вас присутствуют. Автор предпочитает создавать группы, которые относятся к прикладным программам так, чтобы можно было точно знать, что могут делать их пользователи. Используя пример обычной бухгалтерии, Вы могли бы создать группы по именам: Accounting Data Entry Operators, Accounting Data Entry Managers, и так далее. Помните, что для простоты администрирования, длинные имена групп - это плата за понятность их назначения.
Помимо групп приложений, Вам понадобятся несколько основных, первичных групп, члены которых управляют вашими серверами. Как правило, рекомендуются следующие группы: SQL Server Administrators, SQL Server Users, SQL Server Denied Users, SQL Server DB Creators, SQL Server Security Operators, SQL Server Database Security Operators, SQL Server Developers, и DB_Name Users (где DB_Name - имя базы данных на сервере). Также, Вы можете создавать и любые другие группы, если Вы в них нуждаетесь.
После того, как Вы создали глобальные группы, Вы можете предоставлять им доступ к SQL серверу. Сначала, создайте NT логин для аутентификации группы SQL Server Users, и предоставьте необходимый минимум прав этому логину. Сделайте базой данных по умолчанию master, и не предоставляйте доступ к другим базам, или к добавлению нового логина членам других ролей сервера. Затем, повторите процесс с SQL Server Denied Users, но этой группе доступ к серверу должен быть запрещён. После того, как вы создали эти две группы, Вы получите простой способ разрешения и запрета доступа пользователей к серверу. SQL Server предоставляет доступ пользователям на уровне групп и при условии, что маркер доступа пользователя имеет соответствующее разрешение. Иначе, логину будет отказано в доступе, а также, если его лишили доступа через SQL Server Denied Users. В таком случае пользователь не сможет получить никакого доступа к серверу баз данных и к его NTFS.
Для предоставления права группам, которые не имеют явных логинов в системной таблице Sysxlogins, Вы не можете использовать Enterprise Manager, потому что он позволяет осуществлять выбор только из списка существующих логинов, а не из полного списка групп домена. Чтобы обращаться ко всем группам, используйте для предоставления необходимых привилегий Query Analyzer и хранимые процедуры sp_addsrvrolemember и sp_addrolemember. (подробности см. в SQL Server Books Online — BOL)
Для групп, объединяющих операторов серверов баз данных, используя sp_addsrvrolemember, добавьте каждый их логин соответствующей роли сервера. Логин группы SQL Server Administrators становится членом роли Sysadmins, SQL Server DB Creators становится членом роли Dbcreator, и SQL Server Security Operators становится членом роли Securityadmin. Помните, что второй параметр sp_addsrvrolemember требует полного наименования учётной записи. Например, JoeS в домене BigCo должен быть назван bigco\joes. (Если Вы используете локальные учётные записи, имя выглядело бы так: server_name\joes.).
Чтобы создавать пользователей, которые автоматически будут заводиться во всех новых базах данных, используйте базу Model. SQL Server автоматически копирует всё, что Вы создаёте для Model в новые базы данных. Это значительно упрощает работу администратора. Если Вы правильно используете Model, Вам не нужно будет настраивать каждую новую базу данных после ее создания. Далее, используя sp_addrolemember, добавьте SQL Server Security Operators к db_securityadmin, а SQL Server Developers к db_owner роли (ну, здесь можно с автором и поспорить…).
Обратите внимание, что Вы все еще не предоставили доступ ни одной группе или учётной записи к базам данных. Фактически, Вы не можете предоставить доступ к базе данных с помощью Enterprise Manager, поскольку он позволяет предоставить доступ к базам только действующим логинам. SQL Server не требует, чтобы учётная запись NT имела доступ к базе данных до включения её в одну из ролей этой базы или назначения ей объектных разрешений. К сожалению, Enterprise Manager таким ограничением обладает. В то же время, Вы можете назначать разрешения любой учётной записи в домене NT без предоставления непосредственного доступа к базе данных, используя sp_addrolemember, что не возможно с помощью Enterprise Manager.
Все описанные выше действия можно выполнить для базы Model, если ваши пользователи не относятся к общим категориям сотрудников организации в целом, которым в базе делать нечего. В таком случае, Вы можете обобщить основные задачи системы безопасности в базе Model, вместо того, что бы определять их заново для каждой новой базы данных.

Предоставление доступа к базам данных

Для баз данных процедура предоставления доступа отличается от аутентификации учётных записей. Разрешения предоставляются через роли, а не путём назначения прав непосредственно к глобальным группам. Это позволяет Вам добавлять логины для аутентификации на SQL сервере, в рамках планируемой системы безопасности, без особых усилий.
После того, как Вы создали базу данных, используйте хранимую процедуру sp_grantdbaccess для предоставления доступа группе DB_Name Users. Обратите внимание, что не существует обратной по смыслу процедуры sp_denydbaccess, так что Вы не можете запретить доступ к базе таким же образом, как это делалось по отношению к серверу. Если Вам необходимо запретить доступ к базе данных, создайте другую глобальную группу по имени DB_Name Denied Users, предоставьте ей доступ к базе данных, и сделайте её членом ролей db_denydatareader и db_denydatawriter. Будьте осторожны при назначении операторных разрешений, ввиду того, что эти роли ограничивают только доступ к объектам, а не к инструкциям Data Definition Language (DDL).
Как и в случае с логинами, SQL Server предоставляет пользователю доступ к базе данных, если его SID в маркере совпадает с записью в системной таблицы Sysusers. Таким образом, Вы можете предоставлять пользователям доступ к базе данных через их персональную учётную запись NT, имеющую свой SID, или через SID любой группы NT, членом которой он является. Для простоты управления, создайте одну глобальную группу по имени DB_Name Users, которая будет иметь доступ к базе данных, и не предоставляйте доступ к этой базе другим группам. Так Вы сможете очень просто добавлять и удалять пользователей базы данных, определяя их принадлежность к одной глобальной группе.

Назначение разрешений

Последний шаг в настройке системы безопасности вашего сервера баз данных состоит в создании пользовательских ролей баз данных и назначении им разрешений. Самый простой способ, это создать роли с названиями, которые соответствуют именам глобальных групп. Используя пример бухгалтерии, Вы создали бы роли по именам: Accounting Data Entry Operators, Accounting Data Entry Managers, и так далее. Здесь можно использовать сокращённые названия, потому что роли в бухгалтерской базе данных, вероятно, касаются только бухгалтерии. Однако если эти имена полностью соответствуют именам глобальных группы, у вас будет возникать меньше путаницы, и можно будет более легко определять принадлежность группы роли базы данных.
После того, как Вы создали роли, Вы можете назначать разрешения. На этом шаге допустимо использование только стандартных разрешений GRANT, REVOKE, и DENY. Будьте осторожны с DENY, потому что оно имеет наивысший приоритет перед всеми другими разрешениям. SQL Server запретит доступ пользователю к объектам базы, если он является членом любой роли или группы с установленным разрешением DENY. Также, если вы модернизируете используемую в SQL Server 6.5 систему безопасности, помните, что механизмы назначения и применения разрешений у SQL Server 7.0, и SQL Server 6.5 имеют существенные различия.
Теперь Вы можете добавлять логины для аутентификации ваших пользователей в SQL Server. Одна из наиболее ценных особенностей пользовательских ролей базы данных в том, что они могут содержать, как обычные логины SQL сервера, так и глобальные или локальные группы NT, а также индивидуальные учётные записи. Поскольку пользовательские роли являются универсальным контейнером для всех типов логинов, это является главной причиной использовать их вместо назначения разрешений глобальным группам.
Обратите внимание, что предлагается использовать только две встроенных роли базы данных (db_securityadmin и db_owner). Причина в том, что встроенные роли обращаются к базе данных в целом, а не к её объектам. Например, db_datareader предоставляет разрешение SELECT для каждого объекта базы данных. Вы могли использовать db_datareader для выборочно запрещения SELECT конкретным пользователям или группам, но этот метод чреват тем, что можете просто забыть установить необходимые разрешения для некоторых пользователей или объектов. Проще говоря, менее подверженным ошибкам методом является создание пользовательских ролей для определенных категорий пользователей и назначение им разрешений, через которые они получат доступ к тем объектам, в которых эти категории нуждается.

Простая система безопасности

Использование собственного механизма аутентификации SQL сервера проще чем аутентификация NT, особенно если она предоставляется через прикладную программу. Но ситуация резко ухудшается, если число пользователей превысит 25 или когда Вы имеете несколько сервера баз данных и каждый пользователь должен иметь доступ к нескольким база на разных серверах, администрируемых разными людьми. Даже в не больших организациях, в которых администратор базы данных выполняет и другие обязанности, простая схема безопасности позволяет легко запомнить систему предоставления разрешений каждому пользователю и то, как он их получил. Такой подход позволяет сгладить проблемы, вызванные отсутствием у SQL сервера инструментов, позволяющих определить действующие, эффективные разрешения пользователей. Лучшее решение должно использовать механизм аутентификации NT и предоставлять доступом к базе данных через тщательно продуманный набор ролей базы данных и глобальных групп.

Основные правила системы безопасности

1. Пользователи получают доступ сервера через группу SQL Server Users, а доступ к базе данных через группу DB_Name Users.

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

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

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

СОВЕТ

Глобальные переменные
(По материалам pinnaclepublishing.com)

Какая разница между @@identity, @@servername, и @@servicename?

SQL сервер, во время соей работы, следит за десятками значений глобальных переменных, которые   Microsoft называет специальными функциями, характеризующимися префиксом "@@". Некоторые из названий этих функций могут ввести в заблуждение. @@IDENTITY, например, не возвращает имя сервера, а скорее значения последнего инсёрта, которое было добавлено после INSERT, SELECT INTO, или bulk copy. @@SERVERNAME, однако, возвращает имя локального сервера, на котором запущен сервер баз данных. @@SERVICENAME возвращает ключ реестра, определяющий сервис SQL сервера (например, MSSQLServer).

ГОТОВИМСЯ К ТЕСТУ ПО 1139А

ШПАРГАЛКА №5 Продолжение (обзор официального курса Microsoft)
Архив шпаргалок Вы найдёте на следующих сайтах:
http://pilgrim.rostov-na-donu.ru/sql/default.htm
http://mssqlhelp.com.ru
http://subscribe.ru/archive/comp.soft.winsoft.sqlhelpyouself

Резервное копирование

Для чего нужно резервное копирование, думаю объяснять не нужно. Каждый пользователь ПК имеет горький опыт потери информации по той или иной причине… Что бы эти потери свести к минимуму используют резервное копирование. Главное, что бы копии хранились отдельно от оригиналов. Относительно SQL сервера, к необходимости восстановления из резервной копии могут привести, как глобальные катаклизмы, так и тривиальные ошибки пользователей/разработчиков/администраторов.   Например, кто-то может случайно или не случайно выполнить DELETE или UPDATE , забыв указать WHERE ; а кто-то подцепит вирус, который окажется деструктивным, а кто-то решит позариться на вашу базу данных, или кто-то подожжет вашу серверную комнату. Впрочем, случаются ещё и войны, наводнения и пожары. В общем, как в песне поётся: «…следи за собой, будь осторожен…».
Поэтому, после завершения создания баз данных, лучше ещё до   закачки информации в базы, разработайте и внедрите систему резервирования информации ваших серверов баз данных. Здесь, кроме непосредственно MS SQL Server , нужно не забыть и другие компоненты программно – аппаратного окружения ваших информационных систем и приложений. Например, будет очень обидно, если сервер баз данных выживет после того, как террорист кинет гранату в окно ВЦ, а единственный контроллер домена умрёт, вместе с его списком пользователей из 1500 человек. Затраты на систему резервирования рассчитываются, как правило таким образом, что бы они не превысили цифру возможных потерь, в случае потери данных. Иначе, сама система резервирования может стать причиной не явных убытков.
Резервные копии надо делать регулярно (как это банально…)! Другой вопрос, как часто? Для OLTP баз данных или таблиц это может быть очень часто, а для данных OLAP , возможно и не очень часто. Если данные обновляются не очень часто и не очень критичны к их потере, можно составить расписание резервного копирования и делать копии, когда удобно. Исходите из того, сколько ваши сервера могут безболезненно простоять и какой временной период не критичен для восстановления данных из альтернативных резервной копии источников (например, ручной ввод или подкачка из файла).
Сама процедура резервного копирования не должна, при правильном конфигурировании аппаратных средств, существенно повлиять на работу сервера бах данных. Во время резервирования данных, работу с сервером прекращать не нужно, кроме того, в копию попадут и все изменения данных, которые произошли за время резервного копирования. Это становится возможным потому, что на резервную копию копируются не только данные, но их схема и структура файлов. Также в копию попадут фрагменты журнала транзакций, содержащие изменения за время резервного копирования. Механизм включения текущих изменений в резервную копию заключается в том, что перед началом копирования инициализируется процесс контрольной точки, который закрепляет все исполненные транзакции. Далее, сервер запоминает Log Sequence Number (LSN) – номер самой старой транзакции. Копируются все новые транзакции, начиная с этого LSN . Кроме того, в резервную копию помещаются все страницы, которые читаются непосредственно с диска, в обход кэша.
Выполнять резервное копирование дозволено только трём фиксированным серверным ролям: sysadmin, db_owner и db_backupoperator . Для этого можно написать запрос на T-SQL или просто воспользоваться MS SQL SEM . Можно создать и специальную пользовательскую роль, предоставив ей право на резервное копирование.
Для хранения резервных копий Вы можете воспользоваться ленточным накопителем, подключённым непосредственно к серверу баз данных или копировать на диск локального или удалённого компьютера. Для обеспечения возможности использования сторонних программ резервного копирования, таких, как сервер резервного копирования ARCserve производства Computer Associates International, есть возможность копирования в именованный канал.

Продолжение следует

РАБОТА ДЛЯ DBA (Только пошлите английское резюме)

POSITION ID: Tommy_654NT EMAIL: recruiter-tommy@unitek.com
WEB: http://www.unitek.com

POSITION ID: Tommy_123NT EMAIL: recruiter-tommy@unitek.com
WEB: http://www.unitek.com

POSITION ID: Tommy_234NT EMAIL: recruiter-tommy@unitek.com
WEB: http://www.unitek.com

POSITION ID: JL5613 EMAIL: jenny77@s2tech.com
WEB: http://www.s2tech.com

POSITION ID: soliqwa.di8321 EMAIL: recruiting@solutionsiq.com
WEB: http://www.solutionsiq.com

POSITION ID: PAC-624 EMAIL: pdoherty@appliedconceptsinc.com
WEB: http://www.appliedconceptsinc.com

ИНФОРМАЦИЯ АВТОРА РАССЫЛКИ

Милые Дамы и уважаемые Господа!

Спешу сообщить Вам о появлении Питерского зеркала домашней страницы рассылки http://mssqlhelp.com.ru
Хостинг для неё предоставил majordomo.ru, за что им огромное спасибо.
Не смотря на мою бесконечную занятость, удалось «слегка» улучшить дизайн. Из нововведений появились только новости рассылки, которые призваны информировать посетителей сайта о выходе очередных выпусков рассылки и их содержании.

Другой приятной новостью можно считать существенное оживление конференции по SQL Server на SQL.RU http://www.sql.ru/cgi-bin/UltraBoard/UltraBoard.pl за счёт подписчиков рассылки, после упоминания этого замечательного сервера в одном из выпусков. Хотя это оживление, возможно, стало причиной снижения интереса к форуму рассылки, ревности я не испытываю. Сам с удовольствием посещаю эту конференцию и отвечаю на вопросы, которые мне по силам. Главное, что теперь есть где поделиться своими проблемами.
Мало того, я собираюсь открыть в ближайшем будущем ещё один форум, в котором у Вас появится возможность в оперативном режиме подыскать себе необходимого специалиста в разработке приложений с использованием SQL или хорошего DBA. С другой стороны, если Вы наоборот желаете подыскать новый проект или просто другую работу, также связанную с MS SQL Server, форум сможет помочь Вам и в этом. Идея эта возникла не с проста. Кроме заметного оживления рынка труда высококвалифицированных IT специалистов (большую долю подписчиков составляют молодые люди, которые ещё только собираются начать свой трудовой путь и достичь этого уровня) наблюдается бурное внедрение информационных технологий во все сферы бизнеса. Появляются новые ниши во всех сферах применения систем управления базами данных, которые требуют своего заполнения. В общем, я решил, что информация, позволяющая облегчить не лёгкий процесс трудоустройства DBD и SQL – программистов будет востребована. Кроме того, к моему великому сожалению, заканчивается мой очередной глобальный проект, который тянулся около шести лет, и новый форум, возможно, поможет расширить горизонты поиска нового проекта.

ПОЛЕЗНОСТИ

Совершенно забыл про старожила рунета, на котором за много лет скопилось море разнообразной документации сервер CITFOFUM.RU. Там есть много интересных материалов по нашей тематике:
http://www.citforum.ru/database/index.shtml#sql

Недавно появился новый сайт, правда за «бугром», который собирается облегчить жизнь разработчикам программ разного плана. Сайт новый и поэтому там пока почти ничего нет: http://www.developersites.com/.
Зато есть все типичные для современного оформления «навороты».

Вышла в свет новая версия сервера резервного копирования ARCserve 2000 производства Computer Associates International (CA) http://www.ca.com/arcserve, которая поддерживает Microsoft SQL Server 2000.


ДОСТУПНЫЕ РЕСУРСЫ РАССЫЛКИ:

СТРАНИЦА КАТАЛОГА
http://subscribe.ru/catalog/comp.soft.winsoft.sqlhelpyouself
Зеркало в Ростове-на-Дону и АРХИВ №1
http://pilgrim.rostov-na-donu.ru/sql/default.htm
Зеркало в Cанкт-Петербурге и АРХИВ №2
http://mssqlhelp.com.ru
АРХИВ на SUBSCRIBE.RU
http://subscribe.ru/archive/comp.soft.winsoft.sqlhelpyouself
СТАТИСТИКА
http://subscribe.ru/stat/comp.soft.winsoft.sqlhelpyouself
ФОРУМ
http://book.by.ru/cgi-bin/book.cgi?book=SQLServer-Forum