dxdt.ru: занимательный интернет-журнал

Массовый централизованный сервис для обмена сообщениями должен обеспечить собственную надёжность и иметь возможности по восстановлению. Уже эти моменты гарантируют, что с пользовательскими сообщениями, сохраняемыми внутри сервиса, ситуация будет не самой прямолинейной, поэтому рассуждать об удалении переписки по команде пользователя – несколько странно. Посмотрим подробнее на разные особенности “хранения сообщений”.

Так, сообщения сохраняются в какой-то, условно, “базе данных”, потому что речь про централизованный сервис. База может быть распределённой или нет, это тут не особенно важно, потому что “распределение” всё равно происходит внутри единого сервиса (по условию задачи). Работа с базой данных может быть реализована при помощи той или иной распространённой СУБД, либо каким-то собственным решением; да, от хорошо спроектированного сервиса – можно было бы ожидать собственного специализированного решения. Однако тип решения для управления базой данных тут тоже не важен, поскольку так или иначе должны быть и “холодные” резервные копии, и реплики, работающие онлайн, последние, как минимум, необходимы для балансировки между дата-центрами и для обработки локальных отказов. И резервная копия, и реплика – содержат сообщения пользователей в некоторых файлах, выгружаемых на “диски” (то есть, в систему хранения данных). Если эти файлы куда-то утекают, то, понятно, из них можно восстановить сообщения. Кто-то сделал дамп дисков системы хранения данных (или, условно говоря, просто вынул пару дисков и унёс, потому что “так можно было”)? У этого “кого-то” теперь есть все сообщения.

Удаление сообщений ещё и в резервных копиях, – тем более, в упомянутых “побочных” дампах, – представляет собой очень большую технологическую проблему, что бы там ни публиковалось в маркетинговых материалах. Зашифрование резервной копии – не делает сообщения и данные удалёнными (см., впрочем, про ключи и связанные аспекты ниже), а дампы баз данных нередко делают в открытом виде, хоть бы и просто в SQL.

Дело не только в упомянутых файлах, которые содержат копии сообщений. Для того, чтобы сделать резервную копию или синхронизировать реплику – данные, в подавляющем большинстве случаев, должны быть переданы по сети внутри сервиса (заметьте, что это не эквивалентно даже понятию “внутри одного физического сегмента LAN”). Таким образом, резервирование данных в больших сервисах – тоже порождает сетевой трафик, который может ходить и внутри одного дата-центра, и между дата-центрами (более того – в случае резервных копий, в хорошей системе, трафик просто обязательно ходит между разными дата-центрами, так как делать резервное хранилище в том же дата-центре, где и основное, это архитектурная ошибка). Если этот трафик записывается, то из него можно восстановить данные. Трафик может быть защищён (VPN и пр.) от прослушивания, но может и не быть, а ключи от VPN – бывает, “утекают из-под коврика”.

Другой, менее очевидный, вариант: разнообразные логи – общие системные, а также логи конкретных программных сервисов. В лог-файлы записывается самая разнообразная информация. Там могут быть и пароли пользователей, в том числе, в открытом виде (известная история из практики Facebook); могут быть ключи/пароли, защищающие резервные копии; могут быть реквизиты доступа к базам данных и много всего другого, вплоть до самих текстов сообщений, передаваемых мессенджером. Логи (лог-файлы) передаются через вычислительную сеть – это самое обычное дело: в “операционной практике” принято логи собирать на центральных лог-коллекторах, которые являются отдельными физическими серверами. Более того, типовая практика подразумевает использование логов в системах обнаружения вторжений (или “обнаружения утечек/угроз”, SIEM и т.д., и т.п., там море аббревиатур и терминов, так что называть можно по-разному, но часто наличие такой системы – ни много ни мало, а строгое требование политики ИБ). А чтобы логи так использовать, их нужно скопировать в соответствующую систему. Понятно, что делаются и резервные копии логов, а сами лог-записи, – возможно, превращённые в какие-то типовые “сообщения о событиях”, – записываются в ту или иную дополнительную БД (“от SIEM в SOC”). У этой БД есть реплика, резервные копии, ну и так далее.

Это далеко не всё. Сейчас повсеместно используется виртуализация вычислительных ресурсов. Наличие виртуальных машин автоматически подразумевает, что есть и гипервизор с системой управления им, а это, в свою очередь, означает, что имеется и популярнейший механизм под названием “снапшоты”. Полноценный снапшот записывает в файл полную копию состояния виртуальной машины, включая дамп оперативной памяти. То есть, в такой снапшот попадают и данные, которые программное обеспечение, работающее в виртуальной машине, не записывало на диск (например, те самые “сансовые ключи” от чего угодно, которые “под ковриком”).

Снапшоты снимаются администраторами и DevOps, специалистами ИБ и SecOps, и даже другим инженерным персоналом (с более экзотическими обязанностями). Снапшоты, без всяких сомнений, нужны. Они нужны: для резервирования; для обнаружения угроз; для исследования условий потребления ресурсов; для экспериментов; для изучения “всяких странностей” (постоянно используются, не шутка). Снапшоты могут содержать образы баз данных, файлы с ключами, файлы логов и много всего ещё. Снапшоты рутинно передаются через сетевые соединения. В снапшотах сохраняются сообщения пользователей сервиса. Отследить, чтобы сообщения удалялись из снапшотов, чтобы удалялись сами снапшоты, как и то, чтобы в снапшот не попала чувствительная информация, – задачи слишком сложные. Обратите внимание, что при это доступ на уровне гипервизора подразумевает, что нужны и резервные копии “данных гипервизора”.

А ещё есть контейнеризация (читай – разные воплощения Docker). Контейнеры – это программно-обособленные копии системного и прикладного окружения. Контейнеры, как и снапшоты виртуальных машин, могут попадать в резервные копии, передаваться между серверами, и так далее, и тому подобное. Естественно, внутри контейнера легко могут оказаться (и оказываются) самые критически важные данные и ключи доступа.

Общее “зашифрование бэкапов” (это сейчас уже звучит скорее как описание успешной разрушительной атаки на инфраструктуру), да ещё и с ключами, имеющими срок действия, после которого они уничтожаются, означает, что в нужный момент доступа к данным в резервных копиях не окажется, потому что необходимые ключи будут “максимально безопасно” сохранены в самих зашифрованных бэкапах.

Вернёмся к обсуждению сервисов, реализующих “мессенджеры”. Архитектурной особенностью центрального (централизованного) сервиса обмена сообщениями является то, что все точки “копирования сообщений” будут сосредоточены в небольшом количестве “сетевых локаций”. Для действительно распределённой P2P-системы это было бы не так. В теории, даже в центрально сервисе, если пользовательские сообщения, передаваемые сервисом, зашифрованы на стороне клиента без доступа сервера к ключу, то во всех упомянутых выше случаях внутри копий на стороне сервиса окажутся только зашифрованные “блобы”. Проблема в том, что такой идеальный подход на практике реализован далеко не всегда, даже если заявлен и предусмотрен. Это происходит из-за наличия ошибок и административных “особенностей” (как минимум, тут всегда остаются открытыми метаданные, а ключи – могут и утечь). Если же ключи как-то на сторону сервиса передаются, то эти ключи там могут быть сохранены, в том числе, в результате “побочных процессов”, например, в момент миграции конкретного экземпляра ПО сервиса на другую аппаратуру.

В быту 3D-принтер полезен тем, что можно напечатать разные уникальные изделия, “оптимизированные” для решения конкретной задачи. Например, я напечатал ремонтную деталь для блока кнопок управления автомобильным креслом: можно было бы заменить весь блок целиком (хорошо, что не кресло), но это потребовало бы снятия кресла – достаточно много работы. Это далеко не единственный пример. Так, из недавнего, я спроектировал и распечатал несколько установочных кронштейнов для крепления небольших солнечных батарей (для питания уличных светильников), кронштейн для установки самого светильника под скатом крыши, несколько элементов крепления видеокамер, немало коробок-корпусов для разных самодельных устройств вроде цифровых термометров и часов с GPS-коррекцией, несколько защитных кожухов для различных простых механизмов (вроде замка уличной калитки) и другие подобные изделия. Модели я готовлю в OpenSCAD, это очень удобно. Сейчас я в основном использую FDM-принтер Anycubic Mega X – о чём рассказано в отдельной заметке (с картинками). Этот принтер работает методом последовательного наплавления слоёв пластика, то есть, он состоит из нагреваемого столика, над которым перемещается печатающий узел с горячим соплом (“хотэндом”) экструдера.

Естественно, возможности принтера ограничены, но если вы самостоятельно проектируете изделие, то его конструкцию можно оптимизировать с учётом этих ограничений. Например, многие удивляются, что этот конкретный принтер позволяет распечатать работающие резьбовые соединения. Действительно, резьбу печатать не так просто, но вполне возможно. Единственная хитрость состоит в том, что при печати изделие на столике нужно расположить так, чтобы резьба шла строго вертикально. Это касается и внешней, и внутренней резьбы. Печать “под наклоном” или в горизонтальном положении – даёт плохой результат. Естественно, это связано с кинематикой принтера: в данном случае, столик двигается только по одной горизонтальной оси, а второе горизонтальное перемещение и вертикальное – обеспечиваются перемещением печатающего узла.

Основные проблемы всегда доставляют участки модели, которые нависают над столиком. Очевидно, что FDM-принтер не может печатать “в воздухе” – пластик будет просто вытекать вниз. Обычно, для того, чтобы печатать “нависающие” поверхности, используются подпорки. Подпорки здесь – это достаточно лёгкие структуры, которые принтер печатает, начиная от столика, и которые потом можно удалить, отломив или отрезав от изделия. Подпорки добавляются в описание модели для печати. Слои основного изделия, соответственно, накладываются на подпорки. Убирать подпорки, например, у резьбы – весьма сложно: смысл теряется. (Бывает ещё вариант с печатью подпорок другим типом пластика, например, водорастворимым, но для этого принтер должен иметь два печатающих узла.)

Так вот, у всякого FDM-принтера, тем не менее, есть некоторая “степень нависания” слоя, которую принтер может распечатать без подпорок, если только соответствующая часть изделия “вырастает” из другой части, а не висит уж совсем отдельно. Это объясняется достаточно просто: если очередной слой лишь немного “свешивается” за край предыдущего, то свежий пластик успешно приклеивается к этому краю и не провисает, так как застывает достаточно быстро (тут главное не использовать ни слишком высокую скорость движения печатающего узла, ни слишком низкую). Это отлично работает как для резьбы, печатаемой вертикально, так и для других моделей (в принципе, можно даже печатать небольшие горизонтальные “прогоны”, на небольшой скорости). Что, собственно, и составляет один из методов оптимизации: углы “нависания” нужно проектировать так, чтобы принтер справился без подпорок. Да, это вводит ограничения на конструкцию изделия, поэтому может составить проблему, если использовать готовую модель. Однако если модель проектируется под конкретную задачу с нуля, этот момент можно учесть, что, в общем-то, является обычным технологическим аспектом разработки (не только в случае 3D-печати).

Построение изделия “от столика” приводит к ещё одному методу оптимизации: отверстия лучше всего печатаются в положении, когда плоскость отверстия параллельна столику. Идеальный вариант – это когда поверхность, в которой сделано отверстие, лежит при печати прямо на столике.

Это же применимо и к разнообразным опорным поверхностям и рёбрам жёсткости: для оптимизации печати нужно стараться большинство углов сводить к прямым, учитывая, что модель лучше всего разместить так, чтобы наибольший по площади сегмент поверхности непосредственно лежал на столике. Например, если нужно распечатать плоскую деталь, то её нужно повернуть так, чтобы при печати она лежала, а не стояла на столике (тут, кстати, хорошо заметны некоторые известные особенности русского языка: плоская тарелка стоит на столе, а вилка – лежит рядом; если тарелку перевернуть, то она тоже будет лежать, как ни странно).

Вернёмся к принтерам. Размещение и поворот моделей приводит к следующему аспекту оптимизации – к оптимизации затрат времени. Так, плоские детали, лежащие на столике, могут печататься дольше, чем те же детали, но стоящие вертикально. Вообще, время, требующееся для печати детали, складывается из затрат на перемещение печатающего узла. По каким-то направлениям и осям этот узел может двигаться быстрее, а по каким-то – медленнее. Больше всего этот аспект проявляется тогда, когда печатается простая, но “протяжённая” модель: затраты на движение оказываются неожиданно большими, при этом в вертикальном направлении слой перемещается целиком. Совсем уж очевидный пример: размещение нескольких моделей на столике для одновременной печати. Заметьте, что тут, опять же, многое определяется кинематической схемой (и другая история – фотополимерные принтеры).

В заметке про практику 3D-печати я писал, что иногда использую Blender для того, чтобы реализовать “виртуальный предпросмотр” модели. Blender – это полнофункциональный и очень богатый по возможностям пакет для 3D-графики, собственно, один из немногих существующих. Естественно, применительно к 3D-печати – используется только малая часть возможностей. (Да, Blender применяют и в качестве инструментария для проектирования, но мне на этом направлении больше подходит OpenSCAD.) Вот, ниже, пример визуализации (Blender), использующий эффект прозрачности.

Это корпус для небольшого устройства на базе Arduino UNO (модель этого микроконтроллера видна внутри) с LCD, тремя кнопками на передней панели и местом установки динамика. Корпус состоит из двух частей, которые печатаются отдельно: основная коробка и лицевая панель – к ней крепятся блок кнопок и LCD (не показаны), а сама панель прикручивается шурупами к коробке.

Дополнение: версия “в стекле”, менее (а может – более) наглядная; распечатать такую, конечно, не выйдет.

В мае 2021 года опубликована заметка (с картинками, что важно) про 3d-печать “в домашних условиях” – там я рассказываю о своём опыте использования трёх различных принтеров. За прошедшие почти два года появились некоторые дополнения. Так, принтер Anycubic 4Max Pro 2.0 некоторе время назад неожиданно вышел из строя. Сломался подающий механизм экструдера: возможно, сам электродвигатель, а возможно – сгорело что-то в соответствующем драйвере, в деталях я пока что не проверял. Принтер вряд ли отработал больше килограмма пластика к моменту поломки. Отмечу, что данный принтер больше не выпускается. Как и другой из упомянутых в исходной заметке – Anycubic Mega X.

Второй принтер, Mega X, между тем, продолжает проявлять себя с лучшей стороны. Каких-то существенных проблем с ним пока не наблюдалось. Да, пришлось один раз заменить “хотенд” (это горячая часть экструдера – нагревательный элемент и сопло) на новый, поскольку сопло старого перестало хорошо пропускать пластик, а прочистить его не удавалось. Но это пока что единственный сбой. Конечно, нагрузка на принтер небольшая. Сложно сказать, какой именно объём пластика за это время Mega X превратил в распечатки, но соответствующая масса точно превышает семь килограмм. Так что, для бюджетного устройства с большим доступным объёмом печати, надежность уже неплохая, на мой взгляд. Более того, используемая кинематическая схема, похоже, не только отличается надёжностью реализации, но и уверенно обеспечивает вполне достаточную точность печати во всём диапазоне перемещений печатающего узла. Недостатков у Mega X отмечу два: первый (как и в исходной заметке) – невозможно печатать “гибкими пластиками” (Flex); второй – иногда, в процессе замены пластиковой нити, внутри подающего механизма сдвигается втулка, нить застревает, а механизм приходится разбирать, чтобы поправить подачу.

Из пластиков – ничего не поменялось: PLA, как и раньше, остаётся основным, а PETG – редко, для изделий с повышенными требованиям к “износостойкости” (условно) и прочности.

(А вот принтер Wanhao, который упоминается в исходной заметке, так и не используется.)

Поделюсь некоторым практическим опытом любительской 3D-печати. Я пока поработал с тремя разными принтерами. Это бюджетные устройства, все они относятся к типу FDM (FFF), то есть, строят изделие методом последовательного наплавления слоёв пластика: пластиковая нить поступает в подвижную печатающую головку, где пластик расплавляется при помощи нагревательного элемента и выдавливается, формируя очередной слой изделия, – впрочем, думаю, что принцип печати многим хорошо знаком.

Два принтера, которые я использую и сейчас, это Anycubic Mega X и Anycubic 4Max Pro 2.0 (далее – просто 4Max). Третий – Wanhao Duplicator 4S (как я понимаю – больше не выпускается), его я некоторое время назад всё же разобрал с прицелом на модификацию, поскольку и качество печати оставляло желать лучшего, и принтер требовал постоянной настройки и мелкой возни с механической частью. Единственное преимущество этого принтера состоит в том, что там двойной печатающий узел, который, в теории, позволяет печатать двумя типами пластика одновременно. Упомянутый принтер Wanhao вполне можно использовать, но, к сожалению, добиться устойчивого и приемлемого результата с этим устройством весьма непросто, кроме того, сам принтер на настоящий момент сильно устарел. Так что в этой записке речь, в основном, только об упомянутых принтерах Anycubic, которыми я пользуюсь. Эти принтеры, кроме кинематической схемы, отличаются тем, что первый – полностью открытый, а второй имеет закрываемый корпус, с прозрачной крышкой и дверкой.

(Продолжение с картинками.)

Занятный, с точки зрения, так сказать, искусства, проект: Phantom Terrains. С помощью специального наушника превращаются в слышимый звук сигналы сетей WiFi, находящихся неподалёку от носителя наушника. Точнее, звук, формируемый наушником, отражает характеристики сетей WiFi – имя, тип протокола, параметры шифрования, скорость. На страничке проекта есть звукозапись, иллюстрирующая работу устройства.

В СМИ пишут, что данная технология позволяет “слышать Интернет”, но понятно, что это не так. Чтобы человек “услышал” Интернет, в акустические колебания нужно было бы преобразовывать поток IP-пакетов: сами пакеты могли бы “щёлкать”, адреса узлов гудеть чистыми нотами, а, например, какой-нибудь SYN-флуд – стрекотать, подобно кузнечику. Почему именно IP? Потому что это главная особенность, которая делает некий набор сетей Интернетом – так исторически сложилось.

Особого смысла в акустическом прослушивании параметров сетей WiFi нет. Разве что эти сигналы могут послужить дополнительным ориентиром, если человек плохо видит и заплутал. Тем более, что ничего фундаментально нового в таком инструменте нет – преобразовать электромагнитные колебания в звук может всякий радиоприёмник, которые используются людьми многие десятки лет. Что было бы интересно получить – так это трансляцию невидимого в видимое, прямо в глаза, как минимум, через ретинальный монитор, а то и напрямую в зрительный канал мозга. Те же точки доступа WiFi отображались бы уже в виде ландшафта, построить который можно при помощи чувствительного приёмника и данных о положении человека, последний должен идти, чтобы обеспечить базис для измерений. Отличная картинка получится, если показывать отражения волн от зданий и прочих конструкций, раскрашивая сигналы согласно их кодированию. Пользы, впрочем, не сильно больше, чем от звука. А главная проблема в том, что для решения такой задачи потребуется огромная вычислительная мощность. Она, пока что, не помещается в карман.

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

Кроме полезных приложений, очки дополненной реальности должны быть хорошо оснащены аппаратурой. И вовсе не только вычислительной. Камера с добротным и мощным объективом – очень пригодилась бы. То есть, объектив должен позволять смотреть на мир с большим оптическим увеличением, при этом детали увеличенной картинки показываются поверх реального изображения, в дополнение. Например, надписи на отдалённом уличном указателе – очки сами обнаруживают их на “мелкой” картинке, увеличивают и демонстрируют пользователю. То же самое с другими объектами, вызывающими дополнительный интерес. Самое главное, что приложения для очков должны бы уметь сами выделять эти объекты, без дополнительных команд, а, скажем, на основании анализа движений глаз и каких-нибудь пользовательских настроек.

В различных киберпанковских (и не только) литературных произведениях окружающая реальность плотно интегрирована с виртуальной глобальной сетью. Настолько плотно, что через размытую границу проникает программный код – и в направлении реальность->виртуальность, и, что более занятно, в обратном направлении. Если посмотреть на текущее состояние дел, то окажется, что мы находимся не так уж и далеко от подобного устройства окружающего мира.

Например, очки дополненной реальности осуществляют обработку данных в “облачном сервисе” (пусть это будет сервис Google), это означает, что изображение того или иного объекта реальности, построенное видеокамерой очков, воздействует на информационную систему сервиса. Другими словами, показав носителю очков определённое изображение, можно внедрить программный код во вполне себе виртуальный сервис Google, хоть это и похоже на фантастику. Внедрённый код сможет распространиться по другим узлам, образующим “виртуальность”, а также проникнуть в другие очки, например. Или в смартфоны. Сервис-носитель, конечно, должен содержать подходящую уязвимость, но кого сейчас удивишь очередным “переполнением буфера”?

Так что условия для миграции “программного кода” в одном из направлений уже сложились. Остаётся дождаться реализации встречного движения – из виртуальности в реальность. Наверное, тут помогут 3D-принтеры.

(На правах технократического юмора.) Если кто не знает, то “циска” – это собирательное название маршрутизаторов, произошедшее от Cisco и почти ставшее нарицательным. Известно, что если отключить достаточное число маршрутизаторов, то национальный сегмент Интернета потеряет внутреннюю связность (а не только связность с глобальной Сетью). То есть внешняя атака, отключающая “циски”, приводит к пропаданию Интернета в выбранной стране. Естественно, маршрутизаторы содержат уязвимости-закладки, некоторые из них позволяют маршрутизатор не просто отключить, а убить совсем. Идеальным решением задачи активации закладки является передача в составе трафика специального ключа.

Маршрутизаторы копируют все пакеты и обязательно анализируют часть их заголовков, а факультативно – содержимое самих пакетов. Так что обнаружив ключ активации в составе полученного пакета данных, маршрутизатор отключается. Ключ может представлять собой строку из 256 бит, соответственно подобрать его не представляется возможным. Понятно, что программная реализация проверки валидности полученного кода должна быть устроена так, что сам код на основании анализа алгоритма вычислить не удастся. Это очень важный аспект: иначе кто-то сможет получить ключ уничтожения в своё распоряжение, прикупив одну уязвимую “циску”.

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

Предположим, что пакет, содержащий “смертельный код”, отправляется внешним узлом в направлении ближайшего пограничного маршрутизатора атакуемого сегмента сети. Если маршрутизатор, получив пакет, умирает немедленно, то гарантировать можно лишь уничтожение этого самого маршрутизатора – остальные узлы-маршрутизаторы останутся работоспособными, а вот связь их с внешним сетевым миром прервётся, поэтому вырубить их извне уже не получится. Проблема.

Допустим, маршрутизатор сперва отправляет пакет далее по маршруту, и лишь потом – умирает. При такой схеме возможно вывести из строя один из маршрутов, в который входит начальный маршрутизатор, да и то – гарантировать ничего нельзя: пакет может потеряться в пути, а переслать его повторно будет уже некому. Так как маршрутов доставки пакетов обычно несколько, получаем проблему с покрытием: после того, как откажет несколько “цисок”, эпидемия затихнет, а связность сохранится.

Естественно, можно продолжать бомбардировать все доступные узлы пакетом, содержащим смертельный код, но есть и другое решение. Для качественного уничтожения связности пакеты должны пройти через каждый маршрутизатор, обеспечивающий работу национального сегмента Сети. При этом желательно, чтобы вредоносные пакеты вообще не покидали пределов сегмента. Это означает, что источником пакетов должны быть пользовательские компьютеры – тогда они заведомо охватят большое число маршрутизаторов, а распространяться эпидемия отключений начнёт с самого подходящего уровня: ведь без конечных пользователей Интернет не имеет особого смысла.

Как получить нужный эффект? Например, использовать механизм, встроенный в распространённую операционную систему. Пусть в определённый момент центральные серверы, куда эта операционная система обращается за обновлениями, отправят некий “праймер” – сигнал к атаке. После этого операционная система в любой пакет исходящего трафика встраивает убивающий маршрутизаторы код и – вуаля, сегмент посыпался, причём падают маршрутизаторы во всех возможных путях доставки пакетов к пользователям, покрытие идеальное. Естественно, операционная система пользовательских компьютеров не содержит секретного кода: он передаётся центральными серверами, в зашифрованном виде, чтобы не вызвать преждевременного срабатывания. От конечного компьютера требуется только расшифровать код и вернуть его обратно в Сеть – самая обычная операция, кстати, не вызывает подозрений, встречается во многих протоколах, так как может являться чем-то вроде проверки электронной подписи или служить частью системы аутентификации.

А после того как в национальном сегменте умерли хотя бы две трети “цисок”, на восстановление связности потребуются многие месяцы (не исключено, что и годы).

“Плащ-невидимка” – это такое теоретическое снаряжение, позволяющее человеку или предмету стать практически невидимым, хотя бы в некотором диапазоне электромагнитных волн. Лучше всего, конечно, подходит видимый диапазон. Возможность создания подобного снаряжения показана в теоретических работах физиков уже несколько лет назад. Сейчас достижения в области невидимости демонстрируют в лабораторных условиях, для весьма ограниченных ситуаций. Но кто знает – возможно, некоторым сильным спецслужбам уже доступно практическое решение, представляющее собой готовый элемент снаряжения, изготовленный в секретных высокотехнологичных мастерских. Интересно представить, какая от такого плаща может быть реальная польза.

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

Если невидимые агенты проникают в какой-то хорошо охраняемый бункер, то такие бункеры ограждены разнообразными заборами. Пройти сквозь забор – плащ не помогает. Даже в случае с часовыми и сотрудниками охраны всё не так просто: хорошо защищённые периметры содержат в составе пропускных пунктов “шлюзы”; войти в такой шлюз невидимке не удастся уже потому, что шлюз активируется оператором, который должен видеть входящего (или выходящего). Если же невидимка забежал внутрь шлюза вместе с кем-то из сотрудников охраняемого объекта, то он будет тут же обнаружен дополнительными сенсорами, которыми оборудован шлюз: а там, как минимум, имеется какой-нибудь рентгеновский или терагерцевый сканер. Запертый внутри кабинки невидимый агент, естественно, произведёт фурор. Но не более того.

Невидимость удобна для предварительной разведки местности, проводимой с некоторого расстояния. Но и тут есть проблема: объективы средств наблюдения придётся выставлять наружу, а тогда их сможет обнаружить автоматический детектор оптики, которым оборудован защищённый сверхсекретный объект. Очевидно, что всякий объект, заслуживающий внимания агента, оснащённого секретным плащём-невидимкой, оборудован детектором оптических приборов. Или даже несколькими такими детекторами. Что уж говорить о радарах, в том числе, длинноволновых, от которых плащ не защищает (по условиям задачи).

Можно было бы сказать, что служба безопасности нашего защищённого объекта даже не догадывается о существовании плаща-невидимки. Но в реальности это вряд ли так – ведь всякая теоретическая возможность должна учитываться при разработке модели угроз для сверхзащищённого суперсекретного объекта. Тем более, что обнаружение невидимок реализуется уже имеющимися средствами.

Конечно, невидимость окажется полезной для роботов-разведчиков: такой робот может иметь небольшой размер и проникать в помещения сквозь системы вентиляции или проползая под двери. Беда в том, что от подобных роботов охраняемые помещения уже защищают, и системы защиты далеко не всегда подразумевают визуальный контакт (хотя разные “лазерные заборы” никто не отменял).

Так что выгод от использования секретного плаща-невидимки не так много. Но область применения у них, тем не менее, есть: плащ нужно использовать не для проникновения куда-то, а для выхода с территории тех или иных объектов, или для того, чтобы скрытно вынести что-то. Защита охраняемого лица от взгляда снайпера – вот другое эффективное применение.

В продолжение истории “отпечатанного” 3D-принтером металлического пистолета. Оборудование, которое использовали для изготовления этого пистолета – весьма дорогое. Точнее, из оборудования там один станок, сам принтер. То есть, по сравнению с другими схемами организации производства данного пистолета, получаем существенное упрощение: вместо нескольких специализированных станков – один, пусть сложный, но самодостаточный.

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

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

Вариант же с 3D-печатью позволяет качественно пересмотреть организацию производства: станок один, работает автономно, делает сразу весь комплект, а модели загружаются из Сети. Удобно. Новый уровень. В этом и преимущество. Хотя, в жилой комнате пока не разместить.