Посвящается нашим семьям

Предисловие

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

Свою вторую работу в качестве программиста я получил в рекламной фирме. Там активно обменивались документами Microsoft Word, защищенными паролями, зачастую с конфиденциальной коммерческой информацией внутри. Я указал на то, насколько слабым было шифрование этих файлов и как их можно было легко прочитать, используя инструмент, находящийся в свободном доступе в Usenet (древнем аналоге Google Groups). Никто меня не слушал, пока я не начал возвращать эти файлы отправителям, предварительно убрав шифрование.

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

По прошествии более чем десяти лет, когда я занимался разработкой крупномасштабной платформы энерготрейдинга в ThoughtWorks, мне попался отчет об ошибке, который по сей день остается моим любимым. Одна из наших тестировщиц заметила, что поле ввода пароля не предусматривало проверку длины, хотя сам пароль должен был быть не длиннее 30 символов. Но вместо того, чтобы оформить это как «не проверяется 30-символьный лимит на пароль», она написала: «Интересно, сколько текста я могла бы всунуть в поле ввода пароля?» Путем проб и ошибок в заключительном отчете был сделан следующий вывод: «Если в поле пароля ввести больше 32 000 символов, приложение падает». Она превратила простую ошибку проверки корректности в эксплойт для DoS-атаки, который позволял вывести из строя все приложение путем ввода пароля, сформированного подходящим образом. (Спустя несколько лет я посетил конференцию по тестированию программного обес­печения, на которой для регистрации было решено использовать планшеты iPad с самописным приложением. Когда моя подруга попыталась зарегистрироваться под именем Julie undefined и сломала тем самым систему, я понял, что с тестировщиками ПО лучше не шутить.)

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

Почему все так плохо? В мире бесплатной многофакторной аутентификации, биометрической безопасности, физических токенов, пакетов управления паролями вроде 1Password (https://1password.com/) и LastPass (https://www.lastpass.com/) и таких сервисов уведомлений, как Have I Been Pwned (https://haveibeenpwned.com), легко поверить в то, что проблемы безопасности уже решены. Но, как отмечают во введении Дэн, Дэниел и Дэниел (я был просто обязан написать предисловие к этой книге, так как над ней работало слишком мало людей по имени Дэниел), надежные замки и крепкие двери не помогут, если злоумышленник может просто снять их с метафорических петель и уйти с добычей.

Такого явления, как безопасная система, не существует, по крайней мере в абсолютном выражении. Любая безопасность оценивается относительно модели предполагаемой угрозы, и по отношению к этой модели все системы являются более или менее безопасными. Цель этой книги и причина, по которой описанные в ней проблемы еще никогда не были настолько насущными, состоят в демонстрации того, что безопасность — это в первую очередь вопрос проектирования. Ее нельзя прилепить в конце, какими бы хорошими ни были ваши намерения.

Безопасность — это и типы данных, которые вы выбираете, и то, как вы их представляете в коде. Это и понятия предметной области, которые вы используете, и старательное моделирование доменных концепций и бизнес-правил. Это и уменьшение когнитивного расстояния между бизнес-областью и инструментами, которые вы создаете для удовлетворения потребностей клиентов в этой области.

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

Эта книга — одна из моих любимых. Во-первых, она объединяет два моих любимых направления: программную и информационную безопасность (которым я увлекаюсь как любитель) и предметно-ориентированное проектирование (в котором я имею кое-какую квалификацию). Во-вторых, это действенное практическое руководство. Это не просто призыв воспринимать безопасность как часть проектирования (что уже само по себе достойная цель), но и целый ряд примеров, охватывающих как архитектурные вопросы, так и листинги с реальным кодом, что придает книге конкретику.

Хотел бы отметить несколько примеров, которые мне больше всего запомнились. Один был посвящен поверхностному проектированию и иллюстрировал использование стандартных типов вроде целых чисел и строк для представления сложных бизнес-концепций. Это создает такие угрозы безопасности, как взлом пароля (тип Password, в отличие от строки, сам может проверить свою длину) или заказ отрицательного количества книг (тип BookCount не допустил бы ввода отрицательных значений, как это произошло с int). Я занимаюсь профессиональной разработкой программного обеспечения больше 30 лет, но во время чтения этого раздела хотел вернуться в прошлое и треснуть себя молодого по голове этой книгой или по крайней мере оставить ее на своем столе с загадочной пометкой: «Прочти меня» в стиле «Алисы в Стране чудес».

Еще одним примером была тема о плохой обработке ошибок, что является источником огромного числа потенциальных нарушений безопасности. У большинства современных языков есть два пути выполнения кода: один, где все идет хорошо, и другой, на котором случаются разные неприятности. Второй в основном существует в «серой» зоне из блоков catch и обработчиков исключений или робких инструкций-ограничителей. Программистам свойственно искажение восприятия, которое убеждает нас в том, что мы обо всем позаботились. У нас даже иногда хватает наглости оставлять комментарии вроде //этогоникогданеслучится. И мы оказываемся не правы снова и снова.

Покойный Джо Армстронг, потрясающий системный инженер и создатель языка Erlang, приговаривал, что единственный надежный способ обработать ошибку — «позволить ей (системе. — Примеч. авт.) упасть!». Ухищрения, на которые мы идем, лишь бы этого не допустить, включают нулевые указатели (известные как «ошибка на миллиард») и их хитрые исключения, вложенные инструкции if-else, логику блоков switch вида «повезет — не повезет» и привычку доверять нашей IDE работу по генерации загадочного шаблонного кода для интерполяции строк и проверки равенства.

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

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

Не все мы специалисты по безопасности. Но все можем помнить о хорошем предметно-ориентированном проектировании и его воздействии на защищенность систем.

Дэниел Терхорст-Норт, начинающий специалист в сфере безопасности, июль 2019 года

Введение

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

За прошедшие годы мы встретились и поработали со многими людьми. Мы обсуждали код, проектирование в целом и безопасность в частности. Мысль о том, что высококачественные методы программирования могут уменьшить число ошибок, связанных с безопасностью, постепенно укреплялась в нашем сознании. Если бы программисты имели в своем распоряжении такую надежную опору, это могло бы иметь огромный эффект и сделать наш мир чуточку стабильней. Позже эта идея была воплощена в принципе «безопасность на уровне проектирования» и в данной книге. Мы проверяли эту идею на работоспособность независимо друг от друга в различных формах, большинство из которых остались безымянными, встречались и обменивались мыслями со многими людьми. Некоторые из этих встреч оставили заметный след и заслуживают упоминания, хотя при этом мы рискуем не упомянуть о некоторых других важных беседах.

Среди людей, которые оказали на нас самое большое влияние, был Эрик Эванс. Его идеи о предметно-ориентированном проектировании (Domain-Driven De­sign, DDD) сформировали терминологию для обсуждения того, как код должен наполняться смыслом. В 2008 году исследователь в области безопасности Джон Уиландер и энтузиаст DDD Дэн Берг Джонсон начали работать вместе. Принципы DDD послужили основой для их дискуссий о безопасности и коде. В 2009 году они предложили выражение «предметно-ориентированная безопасность», которое стало одним из первых предвестников безопасности на уровне проектирования. Во время своего выступления на конференции OWASP European в 2010 году они обнаружили, что Эрленд Офтедаль из Осло тоже экспериментировал с похожими идеями, что позволило расширить дискуссию. Это, в свою очередь, привело к более глубокому пониманию способов минимизировать такие риски, как атаки внедрения и межсайтовый скриптинг (XSS). В 2011 году к команде присоединились Дэниел Деоган и Дэниел Савано, что положило начало активному применению этих идей на практике. Мы развивали свои методики, используя проектирование для улучшения безопасности, и испытывали их в реальных крупномасштабных системах. К нашему восторгу, они работали на удивление хорошо. Например, наш клиент тайно заказал аудит безопасности для проверки одного из наших проектов, результатом стало одно-единственное замечание, тогда как другой сопоставимый проект получил список из 3000 замечаний!

Популяризируя свои мысли с помощью проектов, статей в блогах и выступлений на конференциях, мы продолжали распространять идею о том, что со слабыми местами в безопасности можно бороться на уровне проектирования. Так продолжалось до тех пор, пока в 2015 году с Дэниелом Деоганом не связались представители издательства Manning и не предложили оформить все это в виде книги. На момент написания данных строк в 2019 году мы рассмотрели довольно много тем, и книга стала толще и полнее, чем мы ожидали. Но мы старались включить в нее только тот материал, который, по нашему мнению, важен для безопасности. А также позаботились о том, чтобы написанное здесь не было привязано к каким-то конкретным языкам или фреймворкам. Надеемся, что наши идеи окажутся универсальными и не устареют в ближайшее время. Мы рады, что вы приобрели экземпляр этой книги, и хотим, чтобы она помогла вам сделать этот чудесный цифровой мир чуточку лучше, стабильнее и безопаснее.

Благодарности

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

Мы бы также хотели поблагодарить тех, кто сделал эту книгу реальностью. Спасибо нашим терпеливым редакторам, Синтии Кейн, Тони Арртиоле и Дженнифер Стаут, которые сделали отличные замечания по содержимому и стилю. Спасибо замечательному редактору текста, Рейчел Хед, которая отшлифовала наш грубый неродной английский. И спасибо производственному отделу Manning, который помог превратить нашу рукопись в готовое издание. Глубоко признательны Дэниелу Терхорст-Норту за предисловие и отзывы, которые он оставил в процессе его написания. Спасибо Гойко Аджичу, Эрленду Офтедалю, Питеру Магнуссону, Джимми Нилсону, Луи Атенцио и Джону Гатри за техническую экспертизу и отзывы. Всем рецензентам: Адриану Ситу, Александру Зенгеру, Андреа Барисоне, Арналдо Габриелю Мейеру, Кристоферу Финку, Доту Морине, Дэвиду Рэймонду, Дагу Спарлингу, Эросу Педрини, Генрику Герингу, Яну Гойвертсу, Джереми Ланжу, Джиму Амрхейну, Джону Касевичу, Джонатану Шерли, Джозефу Престону, Пьетро Маффи, Ричарду Вогану, Роберту Кильти, Стиву Экманну и Зороджаю Макайе — ваши советы помогли сделать эту книгу лучше. Спасибо издательству, которое поверило в нас и в тему, которая здесь освещается. Мы также хотели бы выразить признательность всем, кто участвовал в создании этой книги, но с кем мы не общались напрямую. Поразительно, сколько всего требуется для появления на свет такого издания, как это.

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

Дэн Берг Джонсон

Я бы хотел поблагодарить свою прекрасную жену Айду и любимых детей Лукаса и Айзека. Спасибо за ваши поддержку, любовь и понимание в подчас напряженные времена написания этой книги. Без вас у меня бы ничего не получилось — спасибо вам. Я также благодарен всем, кто за прошедшие годы испытывал мои идеи на прочность: ваши вопросы, комментарии и интересные дискуссии были по-настоящему полезны во время работы над этой книгой.

Дэниел Деоган

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

Дэниел Савано

О книге

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

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

Для кого эта книга

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

Структура книги

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

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

• Глава 1. Здесь демонстрируется, как проектирование может способствовать безопасности ПО и как оно позволяет с легкостью создавать защищенные системы. На закуску приводится пример того, как обеспечение безопасности на уровне проектирования дает возможность предотвратить угрозы безопасности.

• Глава 2. Это отступление о том, как плохая архитектура ПО привела к существенным финансовым потерям. В этом примере безопасности ничто бы не угрожало, если бы использовались концепции, представленные в части II.

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

• Глава 3. Здесь вы познакомитесь с одними из важнейших концепций предметно-ориентированного проектирования (DDD), необходимыми для понимания многих идей, связанных с безопасным проектированием. Мысли и понятия, которые вы усвоите, прочитав ее, активно используются по всей книге, поэтому, если вы плохо ориентируетесь в DDD, советуем начать с этой главы.

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

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

• Глава 6. Здесь мы обсудим основы создания безопасных сущностей: как обеспечить их согласованность в момент создания и поддерживать в целостном состоянии на протяжении жизненного цикла.

• Глава 7. Продолжение темы сущностей. Вы познакомитесь с разными подходами к минимизации их сложности.

• Глава 8. Здесь вы увидите, как с помощью конвейера доставки можно улучшить и проверить безопасность программного обеспечения. Мы также обсудим некоторые трудности, возникающие при автоматизации тестирования безопасности.

• Глава 9. В этой главе вы научитесь справляться со сбоями и ошибками, не нарушая безопасность. Кроме того, мы исследуем некоторые пути борьбы с неполадками на уровне архитектуры.

• Глава 10. Глава описывает, как принципы проектирования, распространенные в облачных окружениях, можно использовать для повышения безопасности даже тех систем, на которые они не были изначально рассчитаны.

• Глава 11. Еще одно отступление, посвященное тому, как система с сервис-ориентированной архитектурой вышла из строя, хотя каждый отдельный ее сервис был исправен. Это реальный пример уникальных проблем с безопасностью, возникающих при создании системы, состоящей из других систем. Обсуждение этих проблем продолжается в части III.

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

• Глава 12. Здесь рассматриваются шаблоны проектирования и конструкции в коде, которые часто встречаются в старых проектах и оказываются проблематичными с точки зрения безопасности. Вы узнаете, как их находить и исправлять.

• Глава 13. В этой главе мы рассмотрим трудности (иногда неочевидные), присущие микросервисным архитектурам, и покажем, как с ними справляться с использованием безопасных архитектурных решений.

• Глава 14. Здесь мы обсудим, почему время от времени безопасности нужно уделять особое внимание. Мы также подскажем, о каких направлениях следует позаботиться при создании безопасных программных систем.

О коде

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

В этой книге принято использовать так называемый змеиный регистр (snake case) в именах тестовых методов (как в методах с аннотациями @Test из JUnit). Это сделано для удобства чтения. Когда для создания тестов применяется стиль BDD (behavior-driven development — разработка через поведение), как мы любим делать, имена тестовых методов зачастую превращаются в длинные грамматически корректные предложения, которые смогут прочитать не только разработчики. При использовании верблюжьего регистра (camel case) слишком длинные имена методов становятся практически неразборчивыми. Змеиный регистр решает эту проблему. Верблюжий регистр является стандартным стилем именования в Java и применяется в именах всех остальных методов и классов.

Эта книга содержит множество примеров исходного кода как в виде пронумерованных листингов, так и посреди обычного текста. В обоих случаях код выделяется такиммоношириннымшрифтом, чтобы его было легче заметить.

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

Код представленных здесь примеров доступен для загрузки на веб-сайте Manning по адресу https://www.manning.com/books/secure-by-design.

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

Об авторах

Дэн Берг Джонсон		Дэниел Деоган		Дэниел Савано

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

Об иллюстрации на обложке

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

На обложке изображена Sultana, or Kaddin, что в переводе с турецкого означает «жена». Эта иллюстрация позаимствована из коллекции костюмов Османской империи, опубликованной 1 января 1802 года Уильямом Миллером с Бонд-стрит, Лондон. Заглавная страница издания утеряна, и найти ее не удается до сих пор. В оглавлении книги рисунки подписаны как на английском, так и на французском, возле каждого из них указаны имена двух художников, которые над ним работали. Они, несомненно, были бы удивлены, обнаружив свою работу на обложке книги по программированию… 200 лет спустя.

Коллекция была куплена редактором издательства Manning на антикварном блошином рынке в «Гараже» на 26-й Западной улице на Манхэттене. Продавец был американцем, проживавшим в Анкаре, столице Турции, и покупка произошла, когда он уже собирал товары в конце рабочего дня. У редактора Manning не было при себе достаточной суммы наличными, а на предложение заплатить кредитной картой или чеком он получил вежливый отказ. Продавец возвращался в Анкару тем же вечером, и ситуация казалась безнадежной. Как же все получилось? Сделку удалось утрясти с помощью старого доброго устного соглашения, скрепленного рукопожатием. Продавец просто предложил оплатить покупку с помощью банковского перевода, и вдобавок к коллекции иллюстраций редактор получил банковские реквизиты. Мы, конечно же, на следующий день перевели нужную сумму и по сей день остаемся благодарны и потрясены оказанным нам доверием. Это в духе давно прошедших времен.

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

Мы в издательстве Manning превозносим изобретательность и инициативу компьютерного бизнеса. И чтобы это подчеркнуть, размещаем на обложках наших книг рисунки из этой коллекции, которые напоминают о богатом многообразии жизни, царившей 200 лет назад в разных концах света.