На страже безопасностиПароли и кредитные карты, часть 2
Йеспер М. Йоханссон (Jesper M. Johansson)
Содержание
Псевдо-многофакторный процесс входа
Проблема надстроек обозревателя
Проверка подлинности никогда не должна изменяться
Возврат к менее защищенным паролям
Обход псевдо-многофакторного входа
Проблемы скомпрометированных паролей
Некоторые преимущества
Введение пользователей в заблуждение при помощи внешней привлекательности
Открывать или не открывать
Предоставление безопасного подключения
Всё сводится к конфиденциальности
Представляем второй из трех выпусков о том, как отрасль ИТ вводит пользователей в замешательство, а не помогает им в плане безопасности. В выпуске журнала TechNet Magazine за июль 2008 г. я обсуждал невыполнимые и неверные рекомендации относительно безопасности и вводящие в заблуждение процессы входа в систему. (Если вы не читали первую часть, ее можно найти
по адресу technet.microsoft.com/magazine/cc626076.). Я показал, как распространенные, но неверные советы относительно безопасности и плохие потоки работ входа в систему вводят пользователей в замешательство и подрывают их усилия по защите личных данных.
В данном выпуске я продолжу обсуждение этой темы и приведу дополнительные реальные примеры из мира безопасности пользователей. Последний выпуск этой серии, в который будет включен «призыв к оружию» для специалистов в области безопасности всего мира, появится в следующем выпуске журнала TechNet Magazine.
Псевдо-многофакторный процесс входа
В октябре 2005 г. Федеральный совет по надзору за финансовыми учреждениями (FFIEC) опубликовал правила «Authentication in an Internet Banking Environment» (Проверка подлинности в банковском обслуживании через Интернет) (см. www.ffiec.gov/press/pr101205.htm). Эти правила должны были быть реализованы в течение 14 месяцев, и в скором времени финансовые учреждения США приступили к попыткам поиска путей соблюдения новых правил.
Большинству учреждений не удалось соблюсти эти временные рамки. Многие учреждения, которые, в конечном счете, привели свою деятельность в соответствие с правилами, сделали эти способами, цели которых отличались от целей правил. Другими словами, организации предприняли меры, никоим образом не улучшившие безопасность клиентов (они были просто « театром безопасности»). Одни из наиболее интересных примеров бесполезных решений заключались в попытке создания многофакторной проверки подлинности, в действительности не являющейся многофакторной.
Например, технология, осуществляющая анализ ритмичности ввода пароля пользователем. Это решение, используемое на веб-узле, отображает диалоговое окно входа в систему, полностью идентичное старому диалоговому окну входа. Однако теперь это диалоговое окно является объектом Adobe Flash.
Объект Flash записывает ритмичность ввода пользователем пароля с клавиатуры, включая длительность нажатия клавиш и время между нажатиями. Эти данные передаются веб-узлу вместе с паролем, где они сравниваются с сохраненными значениями. Если ритмичность ввода данных соответствует сохраненным данным с заданным уровнем отклонения, и если пароль является верным, подтверждается вход в систему. Основная идея заключается в том, что это позволяет использовать на узле псевдо-биометрический метод проверки подлинности без установки на клиенте оборудования стороннего производителя.
Я буду называть это псевдо-многофакторной проверкой подлинности. Это не подлинная многофакторная проверка подлинности, которая основана на измерении двух или нескольких следующих канонических факторов:
- чего-либо, принадлежащего пользователю (например, смарт-карты);
- чего-либо, что известно пользователю (например, пароля);
- чего-либо, относящегося к самому пользователю (например, отпечатка пальца).
Вместо действительного включения нескольких факторов в процесс проверки подлинности псевдо-многофакторная проверка подлинности считывает несколько параметров одного фактора – пароля. Затем эти дополнительные параметры используются для получения определенных выводов о пользователе.
Используемая для псевдо-многофакторной проверки подлинности технология имеет множество недостатков. Вместе все эти недостатки делают технологию в значительной мере неэффективной для разрешения проблем безопасности, для решения которых она предназначена.
Проблема надстроек обозревателя
Системы псевдо-многофакторной проверки подлинности основаны на использовании надстроек обозревателя для выполнения необходимой сложной обработки на стороне клиента. Конечно, все программное обеспечение имеет ошибки, а некоторые из них вызывают появление уязвимостей. Эти уязвимости становятся действительной проблемой в случае трудности обновления программного обеспечения, и если пользователь не уверен в том, было ли установлено обновление.
Надстройки обозревателя соответствуют обеим этим характеристикам — они трудны в обновлении и не предоставляют пользователю достаточную информацию об актуальности установленной версии надстройки. В результате пользователю необходимо предоставить определенному программному обеспечению доступ к Интернету, который в иных случаях не требуется.
В некоторых случаях для поддержания актуальности надстройки необходимо регулярное посещение веб-узла надстройки для проверки наличия обновления. Нет нужды говорить, что так поступают немногие пользователи. Любое программное обеспечение, требующее от конечных пользователей предоставления доступа к Интернету для дополнительного несвязанного программного обеспечения только для обеспечения безопасности, должно быть тщательно обдумано.
Проверка подлинности никогда не должна изменяться
Фактор «что-либо, относящееся к вам» имеют особенность, возможно, даже недостаток, не влияющий на два другие фактора. Хотя можно изменить пароли (что-то, что вы знаете) и создать новые маркеры безопасности (что-то, что у вас есть), количество биометрических проверок подлинности, которые можно использовать, достаточно ограничено. Например, что касается отпечатков пальцев, обычно их всегда десять. Если вы случайно лишитесь одного из пальцев, обычно его невозможно заменить.
Теперь рассмотрим, как это применяется к примеру псевдо-многофакторного входа в систему. Показатели, собранные как часть другого фактора, не могут быть просто заменены или изменены. Конечно, при изменении пароля изменится способ ввода пользователем нового пароля, но общий способ нажатия клавиш на клавиатуре не изменится. Именно на этом и основывается метод. При компрометации этих показателей может быть возможным их объединение. По крайней мере, злоумышленник может записать показатели и воспроизвести их.
Возврат к менее защищенным паролям
Неплохо использовать длинные пароли и часто менять их. И, как говорилось в первой части этой серии, также рекомендуется (вопреки некоторым советам) записывать пароли, обеспечив, конечно же, их безопасность. Однако эти методы не способствуют вводу пароля вручную. Длинные пароли труднее вводить, а сохраненные пароли гораздо более полезны, поскольку их можно скопировать и вставить. Одним из наилучших способов отслеживания сотни или более паролей является использование специального программного обеспечения, например, Password Safe (страница sourceforge.net/projects/passwordsafe). С помощью подобного средства можно создавать абсолютно случайные пароли, хранить их в зашифрованной форме и вставлять непосредственно в диалоговые окна входа в систему. Фактически, при использовании подобного средства не требуется даже знать сам пароль.
Но существует одно препятствие: ритмичность ввода пароля можно проверить только при его вводе с клавиатуры. И если необходимо вводить пароль в объект для измерения ритмичности ввода, этот способ управления паролями начинает испытывать проблемы. Правильный ввод 15-символьного абсолютно случайного пароля – непростая задача. И поэтому пользователи, сталкивающиеся с подобной системой, обычно стремятся упростить пароли. Хотя сам по себе 15-символьный абсолютно случайный пароль гораздо безопаснее короткого пароля в сочетании с псевдо-многофакторной системой проверки подлинности.
В действительности, реализованная исключительным образом псевдо-многофакторная проверка подлинности вынуждает пользователей использовать менее безопасные пароли. К сожалению, как вы скоро увидите, приспособление пользователей, использующих верные способы управления паролями, устраняет практически все значение систем псевдо-многофакторной проверки подлинности.
Обход псевдо-многофакторного процесса входа
Даже если на узле реализована псевдо-многофакторная проверка подлинности, она все равно должна поддерживать обход псевдо-многофакторной системы. Во-первых, на немногих веб-узлах от пользователей может требоваться установка «сторонней от сторонней» технологии для доступа к этому узлу. Некоторые пользователи (например, определенно авторы журнала TechNet Magazine) будут всегда отказываться устанавливать подобное программное обеспечение.
Во-вторых, ритмичность ввода может меняться по множеству причин, и поэтому это должно учитываться на узле. Например, предположим, что пользователь растянул запястье, и поэтому его ритмичность ввода временно изменилась. Как он получит доступ к узлу, если ритмичность уже проанализирована, и предполагается, что другое лицо пытается выполнить ввод с учетными данными пользователя? Если травма является неизлечимой, пользователь может сбросить сохраненное значение ритмичности. Однако в случае временного нарушения здоровья пользователь, скорей всего, не захочет восстанавливать сохраненное значение, предполагая, что ритмичность ввода в скором времени станет примерно такой же, как и ранее.
Наконец, использовать системы псевдо-многофакторной проверки подлинности могут не все пользователи. Например, лица с ограниченными возможностями, взаимодействующие с компьютерами с помощью интерфейса распознавания речи, могут быть не в состоянии заполнить поля диалогового окна в зависимости от того, допускается ли программный ввод. В этом случае, вероятно, должна быть законодательно необходима другая система, учитывающая пользователей с ограниченными возможностями.
Наиболее простым и прямолинейным способом учета всех этих случаев также является поддержка стандартной проверки подлинности, основанной на пароле.
Проблемы скомпрометированных паролей
Подразумевается, что системы псевдо-многофакторной проверки подлинности должны решать различные проблемы, связанные с проверкой подлинности на основе паролей. Однако эти системы не обеспечивают устранение всех существенных способов компрометации паролей. Существует пять основных способов компрометации систем, основанных на проверке подлинности на основе паролей, где «компрометация» означает, что злоумышленнику известен пароль другого пользователя, и он использует его:
- подбор пароля;
- средства регистрации нажатия клавиш;
- фишинг;
- запрос пользователя;
- взлом системы хранения пароля или его хэша.
Сейчас подбор паролей довольно редко используется злоумышленниками и значительно менее популярен, чем средства регистрации нажатия клавиш и фишинг. Кроме того, возможность подбора паролей устраняется псевдо-многофакторной проверкой подлинности только частично. Маловероятно, что обычный процесс подбора пароля будет работать в системах псевдо-многофакторной проверки подлинности, поскольку злоумышленник должен подобрать не только пароль, но и ритмичность печати. Хотя воспроизведение показателей печати теоретически возможно, это редко бывает необходимым, поскольку действительные данные могут быть собраны с помощью фишинга или средств регистрации нажатия клавиш. Кроме того, если система также предоставляет стандартный интерфейс входа в систему, использующий только пароль, злоумышленник может просто использовать эту систему для подбор пароля.
Помимо этого, атаки подбора паролей могут быть предотвращены путем использования надежных паролей. Если мы можем научить пользователей использовать надежные пароли, возможно, с помощью специальных средств, псевдо-многофакторная проверка подлинности не требуется. (В отличие от этого, более простые пароли, обычно используемые с системами псевдо-многофакторной проверки подлинности, в действительности делают подбор паролей более осуществимым подходом.) Таким образом, вся представленная ценность для устранения опасности подбора пароля значима только в случае, если реализация не поддерживает вход в систему только с паролем. И, как я указывал, это очень маловероятно, если вообще возможно. Другими словами, если в системах псевдо-многофакторной проверки подлинности пользователи используют менее надежные пароли, подбор пароля снова может стать возможным способом атаки; псевдо-многофакторная проверка подлинности ухудшает, а не улучшает безопасность. Этот вопрос нуждается в дополнительном исследовании.
Псевдо-многофакторная проверка подлинности также не разрешает проблему использования средств регистрации нажатия клавиш. Хотя мне неизвестны используемые в настоящее время средства регистрации нажатия клавиш, сохраняющие данные ритмичности ввода, нет никаких причин тому, чтобы кто-то разработал такие средства. Средство регистрации нажатия клавиш – это оборудование, располагающееся между клавиатурой и компьютером, или небольшая программа, регистрирующая нажатие клавиш. В любом случае средство регистрации получает полный доступ ко всем данным, используемым решением псевдо-многофакторной проверки подлинности.
Фактически, средству регистрации нажатия клавиш могут быть доступны не только данные, поскольку решение проверки подлинности работает в пользовательском режиме, а средство регистрации нажатия клавиш располагается далеко за его проделами. Без достоверного пути между клавиатурой и веб-объектом для регистрации пароля этот тип компрометации невозможно предотвратить. Если решения псевдо-многофакторной проверки подлинности станут достаточно распространены, вы, несомненно, может быть именно тем, кто создаст подобное средство регистрации нажатия клавиш.
Аналогично, псевдо-многофакторная проверка подлинности не защищает от фишинга. Вместо использования одного поддельного экрана входа в систему злоумышленник может использовать объект Flash для регистрации пароля и ритмичности ввода с клавиатуры.
Конечно, псевдо-многофакторная проверка подлинности может помочь в некоторых случаях, когда используемый злоумышленником способ предоставляет только пароль. Например, самый простой способ получить от пользователя пароль – спросить его. Невероятно, но этот метод доказал свою эффективность, запрашиваются ли пользователи лично, по телефону или путем фишинга.
Конечно, запрашивание у пользователя ритмичности ввода будет гораздо менее эффективным. Аналогично, при компрометации корпоративной базы данных злоумышленник скорей всего получит доступ только к паролям. Но опять же, эти атаки будут предотвращены, только если система не предоставляет стандартную проверку подлинности только с паролем.
Следует также отметить, что если сама база данных паролей на самом деле была скомпрометирована, скорей всего злоумышленник скомпрометировал систему гораздо больше, чем в случае одного или даже нескольких паролей обычных учетных записей пользователей. Поэтому в действительности бесполезно пытаться предотвратить действия злоумышленника, обладающего базой данных с паролями.
Некоторые преимущества
По совести говоря, псевдо-многофакторная проверка подлинности может разрешить несколько проблем (при условии, что система не предоставляет стандартную проверку подлинности только с паролем). Например, она может использоваться для предотвращения совместного использования паролей. Однако это может быть недостатком для систем, в которых учетные записи могут использоваться несколькими пользователями, например, учетные записи совместных банков.
Кроме того, правильно созданное интерактивное диалоговое окно входа (не вход на веб-узел) может требовать от пользователей выполнения дополнительных этапов проверки подлинности, если ритмичность ввода не совпадает с сохраненными показателями. Это может обеспечить для скомпрометированных учетных записей дополнительную защиту в средах с повышенной секретностью.
Введение пользователей в заблуждение при помощи внешней привлекательности
Один из самых лучших способов запутывания пользователей – предоставление неточных указаний относительно безопасности. Самым распространенным указанием, вероятно, является изображение замка на веб-странице, как показано на рис. 1. Эта страница идет еще дальше, рядом с замком отображается слово «Secure» (Безопасно).
Рис. 1. Пример злоупотребления значком с замком, тенденции, вызывающей беспокойство (щелкните изображение, чтобы увеличить его)
Как вы, конечно же, знаете, простое размещение на странице изображения замка и слова «Безопасно» не делает ее безопасной. Однако, что вызывает тревогу, такая практика является распространенной даже на самых зарекомендовавших себя и наиболее посещаемых веб-узлах. В результате множество пользователей привыкает к этим визуальных обозначениям безопасности на веб-странице вместо того, чтобы смотреть, что в действительности обозначают эти метки: в адресной строке. (На вики-странице W3C Web Security Context имеется статья, посвященная данной проблеме, доступная по адресу w3.org/2006/WSC/wiki/PadlockIconMisuse.)
К сожалению, по-прежнему существует множество примеров подобного неверного использования. Исследования показали, что пользователи не могут определить вредоносные веб-узлы даже при очевидности сертификатов (см. www.usablesecurity.org/papers/jackson.pdf). Все сводится к возможности просто отличать подделку, даже если ее не с чем сравнивать. Для этого необходимы навыки; визуальная привлекательность веб-страниц, вводящая в заблуждение относительно безопасности, препятствует выработке таких навыков, поскольку пользователям предоставляется неверная информация.
Особенно тревожный вариант этой проблемы показан на рис. 2. В этом случае страница, на которой отображаются сведения, в действительности не является безопасной. Если взглянуть на адресную строку, можно увидеть слово «http», обозначающее протокол. На этом узле используется очень распространенный метод оптимизации — вместо шифрования страницы с формой входа шифруется только отправка формы. Вход в систему является безопасным, что и указывается на странице, если словно «безопасно» означает «зашифровано». Однако, что очень важно, пользователь не может проверить отправку учетных данных до выполнения отправки! На узле не показан сертификат, подтверждающий подлинность веб-узла для пользователей до отправки формы. Это игра с доверием, также как упасть навзничь, предполагая, что сзади стоящий человек поймает вас. Ко времени отправки формы ущерб уже может быть нанесен.
Рис. 5. Безопасный внешний вид на небезопасной странице (щелкните изображение, чтобы увеличить его)
Протокол SSL, обеспечивающий безопасность протокола HTTPS, служит двум главным целям. Во-первых, он проверяет подлинность сервера для пользователя. Во-вторых, он предоставляет простой механизм согласования ключа шифрования сеанса, который может использоваться между клиентом и сервером.
При шифровании только самой отправки формы не достигается первая и самая главная цель. Узлы с применением подобной оптимизации используют SSL только для согласования ключей. По иронии это может осуществляться с помощью простого использования стандартного протокола согласования ключа, таким образом снижая затраты и перегрузку SSL.
Узел, показанный на рис. 2, не является чем-то редко встречающимся. Множество узлов обеспечивают защиту SSL только для отправки формы, но не для самой формы. Однако данный конкретный узел демонстрирует еще более тревожную черту. При вводе https://www.<site>.com (обратите внимание на указатель безопасности https) в адресную строку обозревателя узел перенаправит на версию узла без SSL! Даже при попытке просмотра сертификата перед отправкой узлу учетных данных сертификат не будет показан.
Не все узлы настолько плохие, но множество узлов подобны рассмотренному. И среди таких узлов узлы двух крупнейших учреждений США, выпускающих кредитные карты. Фактически, из трех крупных компаний, занимающихся обслуживанием кредитных карт, услугами которых я пользуюсь, только American Express предоставляет сертификат в форме входа в систему. American Express даже перенаправляет запросы HTTP на HTTPS. Отлично!
Последняя мысль о бессмысленной внешне привлекательной безопасности – это отсутствие сертификатов в форме входа в систему. Возможно, вам интересно узнать причины этого. Ответ заключается в простой экономии. Для представления сертификатов необходимо шифрование страницы, а это вызывает дополнительную обработку. Дополнительная обработка означает необходимость большего количества компьютеров для обслуживания нагрузки такого же объема. А большее количество компьютеров – это дополнительные затраты. К сожалению, при выборе между обеспечением конфиденциальности пользователей и увеличением прибыли множество организаций выберут последнее.
Открывать или не открывать
Недавно я получил по электронной почте удивительное сообщение от моей компании страхования здоровья. Все, кто пользуется компьютерами последние 10 лет, знают, что не нужно открывать незапрашиваемые вложения электронной почты. Поэтому представьте мое удивление, когда я получил сообщение, показанное на рис. 3.
Рис. 5. Сообщение электронной почты с «безопасным вложением» (щелкните изображение, чтобы увеличить его)
Вероятно, я задал вопрос на веб-узле компании страхования здоровья (и забыл это ко времени получения подозрительного сообщения). Так ответила компания. Сначала я подумал, что это ловкая схема фишинга. Но как выяснилось, это было подлинное сообщение, волосы на моем затылке начали вставать дыбом.
Первое указание заключается в необходимости двойного щелчка вложения для начала расшифровки сообщения. Сообщества безопасности и администраторы ИТ целых 10 лет пытались научить пользователей НЕ открывать вложения. И после этого компания (учреждение медицинского обслуживания, чьими услугами я пользуюсь, и, кстати, не единственная организация, использующая подобный подход) заявляет, что в целях моей безопасности я должен открыть вложение. Как должен действовать пользователь в такой ситуации? Какие действиям он знает или уже забыл?
Далее, я воспользовался функцией предварительного просмотра Microsoft® Office Outlook® 2007, чтобы просмотреть сообщение. Как показано на рис. 4, программа Outlook решила, что это сообщение может представлять опасность и рекомендовала мне не открывать его!
Рис. 4. Программа Outlook 2007 посчитала надежный документ небезопасным (щелкните изображение, чтобы увеличить его)
Одновременно смешно и грустно, что компания медицинского страхования может нарушить простейшие проверки безопасности, используемые в самой популярной почтовой программе в мире. Предполагая, что эта компания даже не проверила новое решение безопасности в программе Outlook, мне приходится догадываться, что еще компания осуществляет в интересах защиты моей частной информации. Или, говоря более откровенно, какие еще решения реализованы компанией исключительно для того, чтобы избежать обвинений в недостаточности защиты конфиденциальности клиентов? Это напоминает театр безопасности финансовых учреждений. Я думаю, что в этом случае основной причиной решения является избежание обвинения, а не защита клиентов.
Мне захотелось увидеть, что же собой представляет вложение. Оказалось, что это объект элемента управления ActiveX®. Чтобы просмотреть вложение, мне пришлось открыть его в обозревателе Internet Explorer® и установить объект. Я увидел успокаивающее окно, показанное на рис. 5. Как можно видеть, создатели пошли на все, чтобы это сообщение выглядело как обычный почтовый конверт, на нем даже есть штамп с уверением о надежности.
Рис. 5. Безопасный документ с изображением конверта со штампом «Trusted» (Надежно)(щелкните изображение, чтобы увеличить его)
Этот тип технологии вызывает тревогу по множеству причин. Во-первых, он поощряет выполнение пользователем недопустимых действий: открытие незапрашиваемых вложений. Во-вторых, само сообщение содержало в корне неверное указание на настройку системы на открытие вложений без выдачи запроса. В-третьих, несмотря на противоречащие сообщения компьютера (в сообщении электронной почты уверяется, что оно надежное, а программа Outlook заявляет обратное), сообщение выглядит очень подозрительным. Наконец, вложение содержит бесполезное визуально привлекательное обозначение безопасности, убеждающее пользователя в действительной надежности сообщения. Если пользователь привыкнет доверять подобным сообщениям, это быстро приведет к появлению доверия к сходным вредоносным сообщениям.
Предоставление безопасной связи
По общему признанию, проблема, для решения которой предназначена эта технология, является очень важной. Обеспечение доверенной связи с клиентами – очень трудная задача. Однако данное конкретное решение отличается излишней разработанностью. Скорее всего, оно вызовет путаницу у клиента и, возможно, приведет к противоположному результату, отличному от предполагавшегося: компрометации системы клиента.
Правильно созданные веб-узлы теперь используют «центр сообщений». В таком случае если компании необходимо связаться с клиентом, она отправляет сообщение электронной почты с текстом, подобным следующему: «В центре сообщений имеется непрочитанное сообщение. Посетите наш веб-узел, войдите в систему и щелкните ссылку центра сообщений, чтобы прочитать сообщение.» Компания получает премиальные баллы, если использует S/MIME для подписывания всех отправляемых клиентам сообщений электронной почты, чтобы пользователи могли проверить подлинности источника. Дополнительные премиальные баллы компания получает в случае, если в сообщении электронной почты отсутствуют фразы «щелкните данную ссылку». Пользователь должен ввести URL-адрес компании от руки, чтобы открыть именно нужный узел.
Центр сообщений и подписанные сообщения позволяют компании обеспечить надежный канал связи с клиентом. Проверена подлинность всего, что видит клиент во время рабочего процесса обмена сообщения, а компания не предоставляет неверных рекомендаций относительно безопасности.
Все сводится к конфиденциальности.
Пока я посвятил два из трех выпусков этой серии описанию того, как специалисты в области безопасности в действительности вредят пользователям. Обеспечение безопасности является нашей работой. Но множество принятых решений и реализованных систем вводят пользователей в заблуждение, рекомендуя им принимать неправильные решения и создавая у них неверное представление о безопасности. Нам не следует заваливать пользователей этими противоречивыми идеями.
Как указывалось ранее, для обычных пользователей безопасность означает простую защиту паролей и номеров кредитных карт. Им необходимо, чтобы технологии работали и были надежными. К сожалению, им приходится принимать решения, и наша работа состоит в том, чтобы их решения были компетентными.
В последнем выпуске этой серии я рассмотрю, как некоторые из наиболее важных доступных для пользователей технологий не оправдывают ожиданий. Я также представлю мою программу действий. Поэтому ознакомьтесь с рубрикой «На страже безопасности» в номере за сентябрь 2008 г.
Йеспер М. Йоханссон является архитектором программного обеспечения, который работает над программами безопасности, и пишущим редактором журнала TechNet Magazine. Он имеет докторскую степень по информационным системам управления, обладает более чем 20-летним опытом в области безопасности и званием наиболее ценного специалиста (MVP) Майкрософт по безопасности предприятий. Его последняя книга – Windows Server 2008 Security Resource Kit.
© 2005 Корпорация Майкрософт и CMP Media LLC. Все права защищены; запрещено частичное или полное воспроизведение без специального разрешения.