Эдвард Сноуден. Личное дело - Эдвард Сноуден Страница 45

Официально моя должность называлась «системный аналитик» и в обязанности входило администрировать локальные системы АНБ, хотя поначалу я помогал и как сисадмин, когда нужно было совместить архитектуру систем АНБ и ЦРУ. Оттого что я был единственным в регионе, кто знал архитектуру ЦРУ, я к тому же ездил по разным американским посольствам, вроде женевского, устанавливая и поддерживая инфраструктуру, посредством которой агентства могли бы обмениваться информацией способами, доныне невозможными. В первый раз в жизни я по-настоящему осознал то чувство, когда сидишь перед терминалом, видя, как работает не одна изолированная система, а как она взаимодействует вместе со многими другими – или же нет. Позже, когда шефы Тихоокеанского технического центра оценили мою «хакерскую» хватку, мне дали вовсю разгуляться, и тогда я мог предлагать свои собственные проекты.

Два момента в АНБ поразили меня с самого начала: насколько технологически более продвинутым оно было в сравнении с ЦРУ и насколько мало внимания в нем уделялось вопросам безопасности каждой итерации – от разделения информации на безопасные и обособленные части до шифрования данных. В Женеве нам приходилось каждый вечер вытаскивать жесткие диски из компьютеров и запирать их в сейф, более того, сами диски были зашифрованы. В АНБ, наоборот, едва давали себе труд шифровать хоть что-то.

По правде говоря, меня слегка сбивало с толку то, насколько АНБ сильно по части киберразведки и как сильно отстает в самых простых методах компьютерной безопасности, таких как восстановление данных после сбоя и резервное копирование. Каждый из тихоокеанских сайтов агентства хранил данные на собственных локальных серверах и ввиду ограничений пропускной способности – лимита на высокоскоростную передачу данных – часто не отсылал копии на серверы штаб-квартиры АНБ. Это означало, что если что-то будет повреждено на каком-то конкретном сайте, то разведданные, с таким трудом собранные агентством, будут утрачены. Мои начальники в Тихоокеанском техническом центре понимали риск, которому подвергалось агентство, не делая резервные копии, поэтому уполномочило меня найти инженерное решение и передать его в штаб-квартиру. Результатом стала система резервного копирования: всеохватывающая, автоматизированная и постоянно обновляющаяся копия всех наиболее важных файлов агентства, которая бы позволила агентству работать, даже если бы штаб-квартира в Форт-Мид была стерта в пыль.

Насущная проблема при создании глобальной системы восстановления после сбоя – и в принципе при создании любой системы резервного копирования – это ее работа с дублированными данными. Говоря простыми словами, у вас есть тысяча компьютеров, и все имеют копии одного-единственного файла. Вам нужно убедиться, что при создании резервной копии вы не дублируете этот файл тысячу раз, так как это потребует в тысячу раз больше пропускной способности соединения и места для хранения. Это ненужное дублирование, которое помешает сайтам агентства передавать ежедневные копии отчетов в Форт-Мид: соединение будет буквально забито тысячами копий одного и того же файла, содержащими перехваченный звонок, остальные 999 копий которого агентству совсем не нужны.

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

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

В АНБ существует целый протокол, которому вам приходится следовать, давая программе кодовое имя. Эта стохастическая процедура случайного подбора слов из двух столбиков, как в И цзин ^[51]: внутренний веб-сайт как бы бросает игральные кости, получая одно слово из колонки «А», а другое, тем же способом, из колонки «Б». Именно так, а не иначе получаются имена, которые вообще ничего не значат, вроде FOXACID («лиса-кислота») или EGOTISTICALGIRAFFE («эгоистичный жираф»). Главное, чтобы в названии не было никаких указаний на то, чем занимается программа. (Как мне известно, FOXACID – это кодовое имя серверов АНБ, на которых размещены вредоносные «копии» известных веб-сайтов; EGOTISTICALGIRAFFE – программа АНБ, эксплуатирующая уязвимость определенных браузеров, работающих по технологии Tor – раз уж не удалось вывести из строя сам Tor.) Но агенты АНБ были так уверены в абсолютной неуязвимости агентства, что редко считались с этими предписаниями. В двух словах: они хитрили и повторяли попытки до тех пор, пока не получалась легко запоминаемая комбинация слов на их вкус: например, TRAFFICTHIEF («похититель трафика»), организатор атак на VPN-сервисы.

Клянусь, я не стал так делать, когда настала пора подобрать название для моей системы резервного копирования. Я кинул кости и получил EPICSHELTER – «эпическое пристанище».

Позже, после того как агентство приняло эту систему на вооружение, ее переименовали во что-то вроде Storage Modernization Plan или Storage Modernization Program – «программу модернизации хранения данных». Не прошло двух лет после изобретения EPICSHELTER, как этот вариант был внедрен и принят к стандартному использованию, но уже под другим именем.

Материалы, которые я распространил в прессе в 2013 году, документально подтверждают такое количество разнообразных злоупотреблений со стороны АНБ, посредством такого набора технологических возможностей, что ни один агент в ходе выполнения своих повседневных обязанностей не мог знать обо всех – даже ни один системный администратор. Чтобы найти хотя бы малую толику должностных преступлений, надо заняться поиском. Но, чтобы начать поиск, нужно знать, что эти злоупотребления есть.

В разгар моей работы над EPICSHELTER, Тихоокеанский технический центр принимал конференцию о Китае, спонсируемую JCITA ^[52], или Объединенной учебной академией контрразведки, для Разведывательного управления Министерства обороны США – подразделения Минобороны, которое специализируется на шпионаже в войсках иностранных государств. На конференции экспертами из всех разведструктур (АНБ, ЦРУ, ФБР и армейских разведок) проводились брифинги о том, как китайские разведслужбы нацеливаются на американское разведывательное сообщество и что можно в связи с этим предпринять. Хоть Китай и интересовал меня, к моей работе это никак не относилось, поэтому конференцию я слушал в пол-уха – до того момента, как объявили, что единственный технический эксперт, чье выступление на брифинге ждали, не сможет прийти. Не помню, в чем была причина его отсутствия, однако председатель секции навел справки, мог ли кто-нибудь из Тихоокеанского центра его подменить, поскольку переносить выступление было поздно. Кто-то упомянул мое имя, и, когда меня спросили, не хочу ли я попробовать, я согласился. Я любил своего начальника и хотел ему помочь. К тому же я был любопытен и пользовался любой возможностью заняться чем-то, кроме дедупликации файлов.