При поиске пожарных дронов, как мне узнать о мерах поставщика в отношении безопасности данных и защиты конфиденциальности дронов?

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

Для обеспечения надежной безопасности данных вы должны явно запрашивать об использовании поставщиком шифрования AES-256 для всех каналов передачи и требовать документацию о возможностях "Локального режима данных", которые отключают интернет-соединения. Кроме того, проверьте, позволяет ли прошивка исключительно локальное хранение или маршрутизацию на серверы, расположенные в США, и запросите независимые аудиторские отчеты для подтверждения отсутствия несанкционированных бэкдоров или связи с иностранными серверами.

Обеспечение безопасности вашего парка дронов требует постановки правильных технических вопросов до подписания заказа на покупку.

Какие протоколы шифрования использует поставщик для передачи видео и управляющих данных?

При калибровке наших полетных контроллеров для экспорта в США и Европу мы ставим целостность сигнального канала выше почти всего остального. Мы знаем, что если злоумышленник перехватит видеопоток во время тактической операции, безопасность всей миссии будет поставлена под угрозу.

Вы должны потребовать от поставщика подтверждения использования шифрования AES-256 как для канала управления и контроля (C2), так и для видеосигнала, гарантируя, что перехваченные сигналы математически невозможно расшифровать в реальном времени. Кроме того, спросите, использует ли система протоколы TLS 1.3 для любой необходимой интернет-аутентификации, которая защищает рукопожатие между наземной станцией и дроном от атак типа "человек посередине".

Понимание уровней шифрования

При оценке потенциального поставщика недостаточно просто спросить: "Зашифровано ли это?". Вам нужно разобрать архитектуру связи. На наших инженерных совещаниях мы разделяем передачу данных на три отдельных потока, и вы должны требовать, чтобы ваш поставщик делал то же самое.

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

Золотой стандарт: AES-256

Вам следует искать Advanced Encryption Standard (AES) с 256-битным ключом. Некоторые производители более низкого уровня могут по-прежнему использовать AES-128 или проприетарные методы шифрования, которые "скрывают" данные, а не по-настоящему шифруют их. Проприетарное шифрование часто является тревожным сигналом; обычно это означает "безопасность через неясность", которую легко взломать решительные хакеры.

Ниже приведена сравнительная таблица, которая поможет вам оценить ответы поставщиков относительно их стандартов шифрования:

Таблица 1: Руководство по оценке протоколов шифрования

Архитектура нулевого доверия

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

Спросите поставщика: "Как дрон аутентифицирует наземную станцию управления перед принятием команд на полет?" Если они не могут четко ответить на этот вопрос, их меры безопасности могут быть поверхностными.

Может ли поставщик гарантировать, что никакие данные о полете не будут передаваться обратно на серверы в Китае?

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

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

Важность "Локального режима данных"

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

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

Проверка "воздушного зазора"

Чтобы по-настоящему гарантировать, что никакие данные не покинут США, система должна поддерживать рабочий процесс, при котором планшет или наземная станция управления (GCS) не нуждаются в подключении к Интернету для полета.

1. Кэширование карт: Можно ли предварительно загрузить карты в автономном режиме? Если дрону требуется подключение к Интернету в реальном времени для загрузки карт, он передает данные о местоположении.
2. Обновления прошивки: Можно ли обновлять через SD-карту (sideloading), а не через обновление "по воздуху" (OTA)? Обновления OTA требуют подключения к серверу, что открывает временный туннель к производителю.
3. Экспорт журналов: Как вы получаете данные? Это должно быть через физический кабель или передачу на SD-карту, а не через кнопку "Синхронизировать с облаком".

Таблица 2: Онлайн и офлайн режимы работы

Критический вопрос для поставщика

Вам следует спросить: "Требуется ли вашему дрону вход в систему или подключение к Интернету для активации двигателей?"

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

Как я могу протестировать программное обеспечение, чтобы убедиться в отсутствии несанкционированных бэкдоров?

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

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

Проведение анализа сетевого трафика

Вам не нужно быть экспертом в области кода, чтобы провести базовую проверку, но вам может потребоваться ИТ-поддержка. Самый эффективный способ проверить наличие бэкдоров — это "прослушать" трафик.

Когда мы тестируем устройства наших конкурентов для сравнения, мы создаем контролируемую среду:

1. Подключите контроллер дрона к Wi-Fi точке доступа, которую мы контролируем.
2. Запустите такое программное обеспечение, как Wireshark или Tcpdump на маршрутизаторе.
3. Включите дрон и запустите его.
4. Анализируйте пакеты данных.

Если дрон отправляет данные на IP-адрес, который вы не узнаете (особенно на серверы, расположенные в зарубежных юрисдикциях), в то время как он должен быть в автономном режиме или в режиме ожидания, это бэкдор.

Сторонние аудиты безопасности

Для менеджера по закупкам самым мощным инструментом является Отчет об аудите безопасности. Авторитетные поставщики промышленных дронов часто предоставляют свою прошивку сторонним фирмам по безопасности (например, Bishop Fox или Booz Allen Hamilton в контексте США) для тестирования на проникновение.

Спросите поставщика: "Проходили ли вы статический анализ кода или тестирование на проникновение аккредитованным сторонним агентством за последние 12 месяцев?"

Если мы, как производитель, не хотим делиться этими отчетами (или их отредактированным резюме), это означает, что мы не проделали работу или скрываем уязвимости.

Таблица 3: Чек-лист аудита безопасности для закупок

Анализ "Цепочки хранения" для ремонта

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

Вы должны спросить о Цепочке передачи данных при ремонте. Стирает ли поставщик данные с устройства немедленно после получения? Есть ли у них политика, запрещающая техническим специалистам доступ к внутренней памяти? Мы рекомендуем извлечь все SD-карты и отформатировать внутренние накопители (если возможно) перед отправкой устройства на обслуживание.

Возможно ли настроить прошивку для хранения данных исключительно на локальных серверах в США?

Мы предлагаем услуги OEM, потому что знаем, что универсального решения не существует, особенно когда речь идет об управлении данными. Многие из наших клиентов требуют, чтобы их экосистема данных оставалась полностью в пределах национальных границ.
AWS GovCloud ³

Да, компетентные OEM-производители могут настроить прошивку для маршрутизации данных исключительно на указанные клиентом серверы в США, такие как AWS GovCloud или частная локальная инфраструктура. Это включает в себя изменение конечных точек API в стеке связи дрона, чтобы гарантировать, что телеметрия, журналы или метаданные никогда не будут отправляться на стандартные глобальные серверы производителя, эффективно создавая замкнутую систему.

тестирование на проникновение ⁴

Подход "Gov Edition"

Стандартные коммерческие дроны обычно подключаются к глобальному кластеру серверов (часто псевдонимизированному через AWS или Azure, но управляемому производителем). Для клиентов с высокими требованиями безопасности мы можем создать пользовательскую сборку прошивки, часто называемую "Government Edition" или "Enterprise Build"."
такие инструменты, как Wireshark ⁵

В этой сборке мы меняем Конечные точки API. Вместо того чтобы дрон подключался к api.manufacturer.com, мы перенастраиваем его для подключения к drone-data.your-fire-department.gov или безопасный экземпляр частного облака, который вы контролируете.

Развертывание в частном облаке

Кастомизация выходит за рамки простого указания другого URL. Она включает в себя Развертывание в частном облаке.

1. Контейнеризация: Мы можем предоставить серверное программное обеспечение в виде Docker-контейнера.
2. Локальный хостинг: Ваш ИТ-отдел устанавливает этот контейнер на ваших собственных физических серверах или в вашей собственной учетной записи AWS/Azure.
3. Полный контроль: Вы владеете ключами, базой данных и логами. Мы, производитель, не имеем никакого доступа.

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

Таблица 4: Уровни кастомизации для хранения данных

Обсуждение сборов за НРЭ (единовременные инженерные затраты)

Когда вы запрашиваете эту настройку, будьте готовы к сборам за НРЭ. Настройка прошивки требует, чтобы наша команда разработчиков программного обеспечения создала ответвление кода, протестировала его и поддерживала отдельную версию для вас.
безопасность через неясность ⁷

Однако для крупной закупки (например, оснащения пожарной службы целого штата) эта стоимость незначительна по сравнению с риском утечки данных. Вам следует сформулировать запрос следующим образом: "Нам требуется сборка пользовательской прошивки с жестко закодированными конечными точками для нашего частного сервера. Какова стоимость НРЭ для этой разработки?"
атаки «человек посередине» ⁸

Задавая этот вопрос, вы сигнализируете о своем понимании производственного процесса и серьезном отношении к архитектуре безопасности. Это переводит разговор из стадии продажи в стадию инженерного сотрудничества.
протоколы TLS 1.3 ⁹

Заключение

Чтобы обезопасить свой парк устройств, требуйте шифрование AES-256, проверяйте возможности работы в автономном режиме, проводите аудит на наличие бэкдоров и договаривайтесь о пользовательской прошивке, которая сохраняет данные на ваших собственных серверах.
Шифрование AES-256 ¹⁰

Сноски

1. Ссылки на официальную публикацию правительства США, устанавливающую стандарты Zero Trust. ↩︎
   

2. Определяет концепцию подчинения данных законам страны, в которой они находятся. ↩︎
   

3. Официальная документация для конкретной облачной службы, соответствующей требованиям правительства, на которую ссылается. ↩︎
   

4. Официальное определение методологии тестирования безопасности, рекомендованной в статье. ↩︎
   

5. Прямая ссылка на официальный веб-сайт рекомендованного инструмента сетевого анализа. ↩︎
   

6. Объясняет механизм конкретного вектора атаки, упомянутого в тексте. ↩︎
   

7. Предоставляет контекст, почему полагаться на секретность для обеспечения безопасности считается уязвимостью. ↩︎
   

8. Авторитетное определение этой конкретной киберугрозы от NIST. ↩︎
   

9. Официальный технический стандарт IETF для протокола Transport Layer Security. ↩︎
   

10. Официальное определение NIST упомянутого стандарта шифрования. ↩︎