Безопасная архитектура для SQL/веб-сервера

Цели

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

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

Архитектура первая встреча.

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

Откуда такой негативный подход? Это причина:

Забота о масштабируемости. Каждое увеличение нагрузки на SQL/WWW-сервер, будь то статические вещества или операции с базами данных (в обоих случаях упоминается нагрузка, возникающая в результате публикации веб-сайтов), влечет за собой необходимость обновить сервер или купить новый. Вы можете сказать: «Ну что ж, у нас больше трафика на наших сайтах, поэтому мы должны увеличить наши расходы». Конечно, больший трафик стоит больше, но зачем тратить деньги, не зная, какие части системы нуждаются в дополнительном финансировании? Модули памяти, которыми оснащен веб-сервер, могут быть дешевле, чем те, которые используются в SQL-сервере. А жесткие диски? Единственная разница заключается в том, что жесткий диск SQL-сервера намного дороже, чем диск веб-сервера. Между прочим, вы не можете ожидать большого трафика при использовании одного веб-сервера. Особенно, когда SQL-сервер дает ему дополнительную нагрузку. Это означает, что, потратив столько денег, вы поймете, что изначально выбрали неправильный подход.
Доступность — это еще один вариант, который не подходит при использовании сетевой архитектуры такого типа. Обратите внимание, что этот тип архитектуры означает, что вся система должна быть остановлена, если необходимо изменить одну из частей системы, например, если необходимо установить патч для сервера MS SQL. Если функции SQL-сервера и веб-сервера разделены, по крайней мере существует вероятность появления сообщения «Система проверяется. Он начнет работать примерно через десять минут». Кроме того, если один и тот же SQL-сервер используется и для бухгалтерского, и для складского ПО, патчить его по своему желанию невозможно. Однако это необходимо для стабильности веб-службы и службы SQL. Что можно сделать? Чем следует пожертвовать?
Безопасность будет полностью забыта, если вы построите сеть, подобную той, что представлена на Рисунке 1. Если один сервер заботится о публикации веб-сайтов, а также используется в качестве базы данных SQL, будет существовать исключительный набор опасностей, характерных для них обоих. У потенциального злоумышленника есть выбор: он сначала взломает SQL, а затем воспользуется функциями IIS, или он начнет с обнаружения новейшей ошибки IIS, которая позволит ему получить свободный доступ к SQL и интрасети? Только воображение хакера решит, что вы потеряете — репутацию вашей компании или ее финансы. Наконец, следует упомянуть еще об одном. Исследования показывают, что большинство попыток взлома исходят из корпоративных сетей. Это означает, что большинство злоумышленников также являются сотрудниками. Зачем облегчать им взлом? Доверие, конечно, хорошо, но наблюдение еще лучше. Кроме того, некоторые злоумышленники могут не осознавать, что они делают. Хорошим примером является ситуация, когда авторизованный пользователь выполняет операцию закрытия месяца на SQL компании. Сервер, загруженный этой операцией, а также нагрузкой SQL и веб-сервера (в результате размещения сайта компании), начинает тормозить. Это не только ухудшает качество бухгалтерских операций, но и еще больше замедляет работу публикации на сайте. Атака типа «отказ в обслуживании» имеет очень похожий эффект.
Управляемость. Последняя из целей, кажется, была достигнута. Легко управлять сетью с несколькими серверами. Однако, прежде чем вы подумаете, что этот вопрос решен, всплывает еще один факт. Этот тип архитектуры отговаривает вас от тестирования вашего нового сайта или изменения конфигурации SQL или веб-сервера, потому что оба они используют одну и ту же систему, и изменение, подходящее для MS SQL, не обязательно будет работать для веб-сервера. Это решение также не оставляет места для одного из процессов управления — укрепления системы, доступной через Интернет. Я могу заверить вас, что правильная защита такого сервера MS SQL фактически помешает ему работать.
Как видите, простая и предположительно дешевая архитектура не достигает ни одной из ожидаемых целей. Запуск тоже становится дорогим. Это должно быть изменено, и модификация должна быть чем-то большим, чем добавление брандмауэра в точке контакта корпоративной сети с Интернетом. В этом случае никакие межсетевые экраны не смогут повысить безопасность компании. Это правда, что установка брандмауэра означала бы достаточный контроль над входящим трафиком, так что потенциальному хакеру пришлось бы начинать свои попытки на веб-сервере. Однако эти шаги не будут отличаться от тех, которые, вероятно, были предприняты до установки брандмауэра. Упомянутый брандмауэр не отделит сервер от корпоративной сети и не достигнет ни одной из ранее упомянутых целей. Модификации должны быть более глубокими.

Архитектура вторая встреча

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

• Внешняя сеть, внешняя зона, которая напрямую связана с Интернетом. Адреса будут переведены сюда, и эта зона отсекает любое неожиданное проникновение в сеть.
  
• Демилитаризованная зона (DMZ), где вы можете найти отфильтрованный трафик как из внутренней, так и из внешней сети. Эта зона не допускает никаких подключений напрямую во внутреннюю сеть.
  
• Внутренняя сеть, которая пропускает обычный трафик, возникающий для нужд компании, например, трафик, вызванный подготовкой данных для серверов, установленных в демилитаризованной зоне. В DMZ пропускают только необходимый трафик. Например, обновление данных сервера или чтение файлов журнала или данных, вставленных гостями на сайт.

Собрав эти выводы, в конечном итоге вы получите рис. 2.

Схема готова. Теперь пришло время решить, какие серверы должны стоять в доверенной зоне, а какие в зоне ограниченного доверия. После разделения серверов на эти группы придется решать еще одну проблему — управлять ими? Внутренняя сеть — это пространство, в котором целостность хранимых данных надежно защищена, поэтому она кажется естественным местом для базового сервера базы данных. Это вызовет еще одно сомнение. Если бы сервер SQL был установлен во внутренней сети, то для барьера между внутренней сетью и демилитаризованной зоной необходимо было бы запрограммировать специальное правило. Это правило необходимо для того, чтобы веб-сервер мог обновлять свои данные каждый раз, когда это необходимо. Правило ослабило бы барьер, разрешив соединения, инициализированные DMZ. Можно согласиться на это и ослабить барьер (который отрезал бы любой трафик, инициализированный в DMZ, от внутренней зоны), а можно согласиться на затраты на репликацию SQL-сервера в DMZ. Эксперты по безопасности отмечают, что второе решение лучше. Серверы, которые должны найти свое место в доверенной зоне, называются промежуточными серверами. Они хранят актуальную и правильную информацию, которая используется для обновления информации, хранящейся на серверах в демилитаризованной зоне, всякий раз, когда такое обновление необходимо. Очевидно, сервер из внутренней сети инициирует обновление. Это может быть вызвано необходимостью установки новой версии сайта или уничтожением содержимого одного из серверов в демилитаризованной зоне, например, из-за сбоя. Аналогичный процесс следует использовать при обновлении баз данных. В этом случае, однако, вам следует загрузить обновленные базы данных через взаимодействие с пользователями веб-сайта. Внутренняя сеть также должна иметь собственный контроллер домена, чтобы внутри нее можно было эффективно управлять авторизацией. Демилитаризованная зона – это территория, на которой должна быть установлена обработка данных, т.е. веб-серверы и вспомогательные серверы. Вспомогательные серверы: DNS-сервер, контроллер домена для веб-сервера и SQL-сервер (или несколько). Далее в этой статье я объясню, как подключить веб и SQL-серверы. Я также должен подчеркнуть тот факт, что размещение контроллера домена в DMZ не является ошибкой. В моем безумии есть метод.
Во внешней сети вообще не должно быть серверов. Он должен состоять только из незаменимых сетевых устройств и (в зависимости от выбранной вами политики безопасности) сенсоров системы IDS.
Эти объяснения могут быть определены дальнейшим развитием эскиза на рисунке 2.

Чтобы упростить задачу, на этом рисунке не показаны двойные элементы сети (коммутаторы и межсетевые экраны с защитой от перегорания). Контроллер домена защищенной внутренней сети намеренно опущен, как и соединение с корпоративной сетью, которое должно быть связано с коммутатором безопасных внутренних сетей. Трафик должен фильтроваться брандмауэром и проходить через зашифрованный канал VPN, если только это не подключение по локальной сети. Правила сетевого фильтра корпорации должны определять, какие пользователи в сети компании имеют право доступа к определенным серверам (если возможно, постарайтесь иметь дополнительный сервер доступа для веб-мастеров). Трафик с рабочих станций сети корпорации должен быть отрезан от прямого доступа к безопасному SQL-серверу или промежуточному серверу (это должно быть правилом!). Следует также сказать, что эти серверы принимают трафик только от других серверов, в данном случае отфильтрованный трафик от выбранных серверов в сети корпорации. Еще одной гарантией может быть необходимость инициализации соединения через серверы из безопасной внутренней сети и отказ от трафика, инициализируемого каждым сервером из сети корпорации.
Выполняет ли такая сеть все задачи, описанные в начале этого текста?
Давайте проверим это:

Задача масштабируемости. Это было выполнено, и вы можете относительно дешево увеличить мощность системы, связанную с функциями более высокой вычислительной мощности (только за цену задействованного оборудования). Обновление веб-серверов позволит запускать новые, более требовательные к памяти приложения. Добавление новых веб-серверов в кластер NLB позволит вам справиться с растущим трафиком. Более высокие требования к SQL-серверу можно удовлетворить, удвоив его (с использованием отказоустойчивого кластера, т.е. Microsoft Cluster Service). Вы также можете разбить его данные, разделив их между множеством баз данных или SQL-серверов.
Доступность. Эта задача выполнена. При использовании этой архитектуры каждый элемент сети может быть продублирован таким образом, что сбой не окажет заметного влияния на пользователей веб-сайта. При таком удвоении можно легко выполнять ремонтные работы даже в прайм-тайм. Чтобы начать установку обновлений или патчей, вам нужно всего лишь переключить трафик с одного сервера на другой. Системы, поддерживаемые таким образом, имеют шанс быть максимально безопасными на этом конкретном уровне знаний.
Безопасность. При использовании возможности определения строгих правил общения внутри сети необходимо достичь удовлетворительного уровня безопасности. Это включает в себя подходящее распределение ролей между системами. В этом случае взлом одного из барьеров не скомпрометирует всю сеть; такой взлом будет ограничен несколькими устройствами или системами. Например, взлом первого брандмауэра не приведет к катастрофе. Хакер будет иметь доступ только к сетевым картам веб-серверов, которые размещены снаружи и максимально защищены. В этом случае защита серверов может быть доведена до предела, поскольку они хранят только данные URL; поэтому процесс будет эффективным. По сути, единственная угроза для всей системы — это затопление нефильтрованными TCP/UDP/ICMP-пакетами опубликованных сетевых карт веб-серверов. Конечно, несмотря на наличие барьера брандмауэра, атака может быть направлена непосредственно на веб-серверы, с использованием новейшей (или самой модной) бреши в замках безопасности IIS. Этот случай немного более опасен, но захват одного сервера не является победой для хакера, потому что все соединения сервер-база данных работают в доверенном режиме. Это означает, что нет сайта APS, который мог бы дать злоумышленнику пароль или учетную запись, позволяющую ему проникнуть в систему дальше. С другой стороны, есть большая вероятность, что другой сервер из NLB-кластера ответит на запрос злоумышленника, что вызовет легкое замешательство. Злоумышленник даже не мечтает пойти дальше, на любой из серверов DMZ, которые работают только во внутренней сети (SQL, DC и т.д.). Правильный процесс защиты внешних систем делает невозможным отправку их пакетов в сеть. Обратите внимание, насколько далек агрессор от доверенной внутренней сети, истинного сердца системы. Попытки атак из корпоративной сети не обязательно успешны, потому что хороший набор правил не позволяет напрямую связываться с серверами. Более того, даже если брандмауэр будет взломан со стороны корпоративной сети, все коммуникации должны быть немедленно остановлены, поскольку серверы потребуют соответствующие пакеты IPSEC. Они будут недоступны, потому что злоумышленник только что выключил свой источник. Что ж, кажется, мы только что разработали идеальную систему. Это может быть правдой, но вы никогда не должны впадать в рутину и становиться слишком самоуверенными. История успешных попыток взлома показывает, что любую систему можно взломать при наличии необходимого опыта и средств.
Управляемость. Похоже, что система на рис. 3 также выполняет эту задачу. Каждый элемент системы доступен и может быть проанализирован. Использование этого типа архитектуры позволяет относительно легко указать обновленные и будущие нагрузки, а также определить их источники и, следовательно, определить расходы, необходимые для состояния равновесия. Итак, архитектурная схема безопасного сосуществования SQL и веб-серверов вроде бы выработана. В том, что все? К сожалению нет. Теперь следует сказать кое-что о вещах, на которые средний администратор не может повлиять, но которые могут свести на нет всю его работу по защите сервера.

Написание безопасного кода

Как обсуждалось ранее, есть один элемент, способный свести на нет все затраты на безопасную архитектуру. ASP-сайт и код генерируемых ASP-элементов, которые выполняются во время обработки веб-сайта, являются магическими аннигиляторами. Кажется, что лучший способ создания активных веб-сайтов — это разделение всего веб-приложения на уровни: уровень представления, уровень бизнес-логики и уровень данных. С одной стороны, такой тип разделения позволяет быстро вносить изменения в любой из слоев без необходимости перестраивать все приложение. С другой стороны, это хорошая основа для построения безопасных веб-систем и их адаптации к различным нагрузкам данных. Уровень представления размещается на самих веб-серверах. Этот уровень состоит из элементов кода ASP, отвечающих за представление данных. Очевидно, что они зависят от потребностей веб-мастера и его требований относительно внешнего вида веб-сайта. В то же время они безопасны для администратора. Этот слой также отвечает за получение данных из формы. Дальнейшая обработка данных происходит на другом уровне, называемом уровнем бизнес-логики. Обычно элементы этого уровня работают как отдельные компоненты (зарегистрированные в Component Services). Они вызываются с веб-сайта так же, как и любой другой компонент, например FilesystemObject. Как я уже упоминал, компоненты уровня бизнес-логики регистрируются как отдельные элементы. Каждый из них может работать под учетной записью, определенной администратором (в домене или локально). Каждый из них может использовать свои собственные права, связанные с учетной записью, но не более того. Обратите внимание на наличие ASP-сайта, работающего как IWAM_machine или IUSER_machine (в зависимости от исполняемого фрагмента кода сайта) со стандартными, низкими правами для этих учетных записей в системе. Взлом сервера даст злоумышленнику гостевые права. Однако система хорошо защищена, поэтому гость не сможет сильно навредить и будет искать более гостеприимного хозяина. Как же тогда можно при таком низком уровне авторизации вызывать соединение с базой для загрузки данных для презентации? Код ASP не обязательно должен содержать учетную запись SQL и пароль. Нужно только вызвать нужный компонент, который также не знает своего пароля или учетной записи. Однако при использовании доверенного соединения в базе данных, а также при работе в контексте учетной записи, определенной службами компонентов, он будет получать (т. е. уровень данных) необходимую информацию из базы данных. Это чистый и понятный поток данных, полностью управляемый администратором, оставляющий недвусмысленный отпечаток в системе. Эти отпечатки пальцев однозначны, потому что они исходят от одной учетной записи по всему пути данных. Важно следить за режимом работы SQL-сервера. Он может принимать только доверенные соединения. Данные следует тщательно проверять и искать элементы, опасные для SQL-сервера. Это должно произойти до того, как данные попадут на уровень данных. К сожалению, очень легко внедрить свои собственные команды на защищенный SQL-сервер со всеми сопутствующими рисками. Даже самая сложная и самая дорогая архитектура систем и приложений не защитит вас от таких ошибок. Все, что приходит из сети, должно быть проверено, и нельзя считать, что чего-то еще никогда не было. В конце концов кто-то появится с определенной комбинацией символов, которая позволит ему войти. Кто-то, наконец, получит то, чего не должен был иметь.
Тем из вас, кто заинтересован в более глубоком изучении вопроса создания безопасных веб-серверных приложений, следует прочитать следующие книги: «Проектирование безопасных веб-приложений для Microsoft Windows» Майкла Ховарда и «Написание безопасного кода» Майкла Ховарда и Дэвида ЛеБланка.