Информационная безопасность *

Коллеги-бумажные инфобезники, у меня к вам тема на поразмыслить. У каждого из нас есть мобильный телефон, в котором имеется телефонная книга и куда мы записываем телефон, фио и иные персональные данные конкретного человека. По сути, с момента нажатия на кнопку “Сохранить” мы начинаем обработку персональных данных (запись, систематизация, накопление, хранение) и должны руководствоваться 152-ФЗ. Но есть пару нюансов.

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

А что если я работаю, например, менеджером по продажам и у меня записаны сотни телефонов клиентов и подрядчиков? В данном случае может ли быть применен п. 5 ч. 1 ст. 6 ФЗ-152, в соответствии с которым обработка ПДн допускается для исполнения договора, стороной которого либо выгодоприобретателем или поручителем по которому является субъект персональных данных?

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

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

В общем, ситуация простая, а вопросов много. Предлагаю подискутировать по данному вопрос и уже наконец-то определиться, нужно ли брать согласие субъекта на обработку персональных данных перед добавлением контакта человека в свой телефон? ;)

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Защитили наш подход к мультирегиональности: новый патент на систему управления доступом в облаке

Команда безопасности Yandex Cloud запатентовала технологию объединения облаков, развёрнутых в разных регионах. В отличие от подхода, характерного для многих зарубежных облачных платформ, где используется глобальный сервис Identity and Access Management (IAM), в платформе Yandex Cloud применяется подход с изолированными облачными регионами. Это позволяет соблюдать региональные законы, требования к хранению пользовательских данных и минимизировать риски инцидентов. 

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

• будет ли сам IAM глобальным или региональным,

• как классифицировать ресурсы и пользователей,

• как будут работать процессы аутентификации и авторизации,

• должны ли токены и куки работать между регионами.

Это позволило создать технологию, в основе которой лежат ключевые архитектурные требования: 

1. Отсутствие общих точек отказа между регионами — если один регион испытывает трудности, другие регионы не должны страдать.

2. Объём ущерба инцидентов должен быть ограничен пределами одного региона.

3. Важно соответствовать требованиям комплаенса и локального законодательства.

4. Необходимо создать условия, при которых клиент чувствует, что пользуется единым сервисом, а не набором разнородных изолированных облаков.

Последнее условие соблюдается благодаря продуманному UX: регионы остаются независимыми, но пользователи могут «бесшовно» переключаться между ними. Это достигается через организацию — псевдоглобальный объект, выступающий административным доменом. Доступ к ресурсам могут получать только пользователи, входящие в организацию. 

Доверие между регионами реализовано через механизм Workload Identity Federation: аккаунт одного региона может имперсонироваться в аккаунт‑представитель в другом регионе. При этом права таких аккаунтов строго ограничены, а синхронизация выполняется односторонне — только из домашнего региона. Поэтому даже если в другом регионе произойдёт компрометация, это не затронет домашний регион.

Error Budget: сколько ошибок может позволить себе ваш сервис

Есть разговор, который рано или поздно случается в каждой команде. Бизнес приходит и говорит: «Нам нужна стопроцентная надёжность». И вот тут у хорошего инженера должен включиться внутренний голос, который вежливо, но твёрдо отвечает: «Нет».

Вместе с Кириллом Борисовым, TeamLead Incident Management из VK, разобрались, почему 100% uptime — это не цель, а симптом. Симптом того, что команда ещё не договорилась, сколько ошибок она на самом деле может себе позволить — и зачем вообще это считать.

Что на повестке

Error Budget — это не про то, сколько раз вам разрешили упасть. Это про то, как инженеры и бизнес наконец начинают говорить на одном языке: релизы, риски и стабильность в одной системе координат. В выпуске разбираем, как объяснить бюджет ошибок продакту, который слышит «бюджет» и думает о деньгах, почему идеально надёжная система — это не достижение, а тревожный сигнал, и как понять, что бюджет уже горит — до того, как это почувствуют пользователи.

Отдельно досталось теме «девяток»: сколько стоит каждая из них и в какой момент гнаться за следующей перестаёт иметь смысл.

Если вы хоть раз объясняли стейкхолдеру почему нельзя катить фичи и при этом держать SLA 99.99% — этот выпуск про вас.

Слушайте и смотрите на площадках

• 📺 YouTube

• 💻 Rutube

• 📱 VK

И подписывайтесь на телеграм-канал Avito SREда

Ещё больше экспертизы собрали для вас на сайте: смотрите наши лонгриды, новости, плейлисты видео. А узнать, как стать частью команды AvitoTech, можно вот здесь.

4 статьи для безопасного проектирования и разработки программ

Привет, Хабр! Подготовили для вас подборку полезных материалов по безопасной разработке ПО.

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

Что внутри:

• Процессы и основные риски безопасной разработки.

• Требования безопасности

• Принципы безопасного проектирования

• Безопасное использование сторонних компонентов.

Читайте и сохраняйте в закладки →

Подключайтесь к вебинару про Enterprise-grade ЦОД в Selectel

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

В центре внимания — услуга Enterprise-grade ЦОД от Selectel. Поговорим о том, как она устроена и почему ее выбирают крупные IT-компании.

Подключайтесь к трансляции в VK и на YouTube.

РБПО по ГОСТ Р 56939—2024: вебинар №09 из 30 – Экспертиза исходного кода

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.9. – "Экспертиза исходного кода". На YouTube. Слайды.

Цели девятого процесса по ГОСТ Р 56939—2024:

Обеспечение соответствия исходного кода ПО предъявляемым к нему требованиям.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

DevSecOps без имитации: что учесть, чтобы безопасность не стала тормозом для разработки

DevSecOps часто начинают с инструментов: добавить сканер в CI/CD, включить проверки зависимостей, собрать отчёты по уязвимостям. Но на практике быстро выясняется, что проблема глубже: непонятно, кто отвечает за найденные риски, какие проверки действительно нужны, как не утопить команду в ложных срабатываниях и где проходит граница ответственности между разработкой, эксплуатацией и ИБ.

30 апреля в 20:00 пройдёт бесплатный демо-урок «Планируем внедрение DevSecOps — что следует учесть?».

Обсудим, с чего начинать внедрение: как оценить зрелость процессов разработки и ИБ, встроить практики безопасной разработки в текущий конвейер, определить роли и точки взаимодействия, а также выбрать метрики, по которым видно реальное движение. Приходите, чтобы разобраться в теме и задать вопросы эксперту.

Записаться на урок можно на странице курса «Внедрение и работа в DevSecOps».

Если хочется шире посмотреть на инфраструктуру, Kubernetes, DevSecOps, observability, Ansible, Nginx и не только — в дайджесте собрали больше бесплатных уроков и гайдов по этим темам.

Бюджет на защиту ПДн формируется в логике постройки дома

Алексей Колпаков, начальник управления развития процессов кибербезопасности ОТП Банка, выступил на сессии «Персональные данные» в рамках Ciso Forum 2026. Обсудил новые тренды в защите персданных.

На какие направления защиты ПДн компании реально выделяют основной бюджет в 2026 году? Алексей предложил рассматривать как бюджет на строительство дома. Есть три главных «стрима»: фундамент, стены и крыша.

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

Стены — это доступы, обезличивание, работа с подрядчиками. Алексей отметил, что взлом периметра в 2026 году — резонансный, но редкий кейс. Куда более реальный сценарий — разработчик с доступом к продуктивной среде, аналитик, сохраняющий таблицы с ПДн в Excel, или подрядчик, риск взлома которого значительно выше.

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

Алексей также привел статистику, собранную в общении с коллегами: все три инструмента — DLP, DCAP и обезличивание — одновременно используют только 15% компаний, работающих с ПДн. Он отметил, что это прогресс, ведь еще пять лет назад таких компаний было в три раза меньше. В банках и финтехе этот процент выше, на уровне 75%, благодаря высокой зарегулированности отрасли и ответственности перед клиентами.

Что покупают сначала: процессы, архитектурные изменения или инструменты? Сначала всегда идут процессы, затем архитектурные изменения, потом инструменты, иначе деньги будут потрачены впустую, система просто не будет работать. В качестве примера он привел контакт-центр: «Правильный процесс — когда оператор работает в CRM, видит на экране только имя и отчество клиента и его продукты, нажимает кнопку звонка, и система сама соединяет его с клиентом. Провал — когда операторам выгружают в Excel списки с ФИО и другими ПДн, и эти файлы начинают перемещаться по рабочим местам и пересылаться по почте. В таком случае процесс становится неконтролируемым, и никакие системы безопасности не помогут», - пояснил Колпаков.

Если процессы настроены, но у сотрудников остались избыточные права, многие будут действовать по-старому. Поэтому нужно разделение контуров на обычный, защищенный и RnD. Работа с чувствительными данными должна идти в защищенном контуре без возможности копирования. RnD, напротив, должен быть максимально удобным — с административными правами, доступом в интернет и инструментами, но без продовых данных. Когда бизнес-процессы требуют передачи данных между контурами, вступают в дело инструменты: почту проверяет DLP, обмен файлами через общие папки контролирует DCAP, для переноса баз данных работает система обезличивания. Если начать в обратном порядке — компания получит сотни алертов и тысячи ложных срабатываний, с обработкой которых физически справиться будет просто невозможно. Лучше посмотреть в первую очередь на процессы в массовых функциях, потому что там чаще всего отмечаются самые высокие риски нарушения контура информационной безопасности.

Вчера проводила эксперимент с 5 нейронками об отключении мобильного интернета и об ограничении вообще интернета в стране Х. Были задействованы DeepSeek, Yandex, Kimi, Gemini и GPT. То есть, разные нейронки, обученные на разных культурных корпусах, США, Китай, Россия. Язык русский.

Так вот, все 5 нейронок согласились что интернет можно отключать только в кратковременных случаях, если есть угроза жизни. Ограничивать также можно, но если это пропорционально соответствует угрозе, что пока не доказано. Самый сок!

Во всех опросах Алиса/Яндекс рассказывала как это плохо ограничивать интернет в целях безопасности, но ставила 8/10 «ЗА». Все остальные ставили 2-3/10.

Вы понимаете парадокс? Алиса говорит, что ограничения ужасны для безопасности, образования, медиа, науки, права, экономики, медицины (особенно она отметила что нельзя ограничивать доступ к глобальной медицине), но голосовала ЗА!

Подумайте, какой приоритет встроен в итоговую оценку.А теперь главное: ИИ встраивается сейчас везде, в бизнес, в банки, в госуправление, в места, где принимаются критические решения.
Что посоветует Алиса, если она подробно описывает медленную деградацию системы, но в итоговой оценке всё равно поддерживает ограничения? Какие критические решения могут приниматься с таким "технологическим суверенитетом”?

Друзья, есть необычная просьба 🙂 Как вы знаете, я активно занимаюсь программно-аппаратными исследованиями и реверсом всякой электроники.

Если у вас завалялась:

• нерабочая IoT техника

• старые роутеры / камеры / умные устройства

• любая сломанная или просто устаревшая электроника, которую жалко выбросить

  -с радостью приму в дар на исследование.

Мне это интересно именно с точки зрения “поковыряться”: посмотреть, как устроено, что сломалось, как можно восстановить или обойти. Иногда из этого получаются довольно неожиданные находки. По результатам, само-собой, с меня детально описанное исследование!

Если что-то есть - напишите в личку. Дам устройствам вторую жизнь (или хотя бы красивую смерть в процессе анализа😅).

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

РБПО по ГОСТ Р 56939—2024: вебинар №08 из 30 – Формирование и поддержание в актуальном состоянии правил кодирования

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.8. – "Формирование и поддержание в актуальном состоянии правил кодирования". На YouTube. Слайды.

Цели восьмого процесса по ГОСТ Р 56939—2024:

Обеспечение эффективной и единообразной организации оформления и использования исходного кода в соответствии с предъявляемыми к ПО требованиями.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Что проверять перед любым крипто-переводом: короткий anti-fail чеклист

Большая часть проблем с крипто-переводами возникает не из-за “сложности блокчейна”, а из-за слишком бытовых ошибок.

Не ту сеть выбрали. Скопировали адрес, но не сверили хвост. Забыли про memo/tag. Отправили “впритык”, а после комиссии сумма стала ниже минимального порога. Итог всегда один: деньги вроде бы отправлены, но дальше начинается нервный квест. Парадокс в том, что большинство таких ошибок можно поймать за 30–60 секунд до отправки.

Ниже короткий anti-fail чеклист, который реально стоит прогонять перед любым крипто-переводом, особенно если сервис новый, сумма чувствительная или вы работаете в спешке.

Первое: сеть.

USDT в ERC-20, TRC-20, BEP-20 и других сетях визуально выглядит как “тот же USDT”, но на практике это разные маршруты. Ошибка здесь одна из самых дорогих и самых частых.

Второе: адрес.

Недостаточно просто вставить адрес в поле. Стоит хотя бы сверить первые и последние символы. Ошибки буфера, подмена адреса вредоносным ПО и банальная спешка - классика.

Третье: связка “актив + сеть”.

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

Четвёртое: комиссия и итоговая сумма.

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

Пятое: минимальная сумма зачисления.

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

Шестое: memo, tag или дополнительный идентификатор.

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

Седьмое: тестовый перевод.

Самый скучный совет, но самый дешёвый. Если сервис новый, сеть непривычная или сумма ощутимая, то сначала лучше отправить небольшую часть, а уже потом основную сумму.

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

Представлен открытый проект FMHY Filterlist — это список вредоносных ресурсов и другого сомнительного ПО в сети, где есть фейковые сайты популярных репакеров, торрентов и софта, пиратские сайты, где хоть раз нашли вирусы, а также «серые» ресурсы, сервисы с сомнительной репутацией вроде Avast, McAfee, Tlauncher, 360 Total Security и других. Разработчики проекта постоянно обновляют список угроз. Фильтр уберёт большинство вредоносных сайтов из доступной сети и не даст пользователям перейти на них.

Базовая версия: https://github.com/fmhy/FMHYFilterlist#howtouse-basic.

Продвинутый вариант: https://github.com/fmhy/FMHYFilterlist#howtouse-plus.

Полный список угроз и базовый репозиторий: https://github.com/fmhy/FMHYFilterlist.

Открытый проект Viseron улучшает поток от обычных видеокамер с помощью нейросетей:

• запись включается только в момент происшествия. Например, в кадре прошёл человек или животное;

• умеет распознавать лица и объекты;

• может собрать в одну сеть камеры от разных брендов;

• все данные сохраняются локально;

• поддерживает все популярные бренды: Hikvision, Dahua, Reolink и другие;

Скрипт отработал без ошибок. Каталог – нет

Скрипт массового обновления атрибутов отработал идеально: лог чистый, ошибок нет.

Через час выясняется – у 400 пользователей сломалась связка UPN‑sAMAccountName.

Причина – логическая ошибка в условии.
Тест на 10 объектах её просто не поймал.

Дальше обычно три сценария.

Первый – откат из резервной копии.
Но копию сделали 18 часов назад. За это время уже:

– создали новые аккаунты;
– поменяли пароли;
– выдали права.

Откат чинит одно и ломает другое.

Второй – писать обратный скрипт.
Работает, если ты точно помнишь, что именно перезаписалось, и уверен, что обратная логика не добьёт оставшееся.

Обычно это уже режим «админской археологии».

Третий – взять снимок состояния до запуска и вернуть только нужные атрибуты у нужных объектов.

Проблема в том, что третий путь работает только если снимок был сделан заранее.

Не «когда всё поехало», а до того, как нажали Enter.

Массовое изменение без снимка перед изменением – это не автоматизация.

Это ставка на то, что скрипт идеален.

Обычно – нет.

РБПО по ГОСТ Р 56939—2024: вебинар №07 из 30 – Моделирование угроз и разработка описания поверхности атаки

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.7. – "Моделирование угроз и разработка описания поверхности атаки". На YouTube.  Слайды.

Цели седьмого процесса по ГОСТ Р 56939—2024:

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

5.7.1.2 Уточнение модели угроз и описания поверхности атаки по результатам разработки кода и его изменений.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

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

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

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

В итоге сервис вроде живой, а дальше начинается админская археология.

Поэтому для каталога мало просто уметь подняться из копии. Нужно ещё уметь нормально разруливать логические потери без отката всего подряд.

Потому что «всё поднялось» и «всё починилось» – это, как известно, две разные стадии одного и того же инцидента.

Бесплатный проект email-fake позволяет генерировать одноразовую электронную почту за один клик. Сервис создаёт почтовые ящики, чтобы пользователи могли зарегаться в различных сервисах и получать любые коды доступа без регистрации и получения спама на личную почту.

РБПО по ГОСТ Р 56939—2024: вебинар №06 из 30 – Разработка, уточнение и анализ архитектуры программного обеспечения

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

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.6. – "Разработка, уточнение и анализ архитектуры программного обеспечения". Слайды.

Цели шестого процесса по ГОСТ Р 56939—2024:

5.6.1.1 Создание условий для снижения количества возможных недостатков при разработке архитектуры ПО.

5.6.1.2 Уточнение архитектуры ПО в процессе разработки кода.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

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

С момента покупки нового мультиметра UNI-T UT61B+ я горю желанием поменять родные щупы. Несмотря на китайское происхождение, у них минимальное сопротивление, а замеры они делают достаточно точно и быстро. Единственный существенный минус - их наконечники очень короткие и толстые, что накладывает определенные ограничения на их использование и измерения. Во-первых, когда мы имеем дело с плотной SMD-пайкой в ограниченном пространстве, в том числе с многоножечными чипами, производить измерения не только невозможно, но и опасно, так как можно “закоротить” плату. Во-вторых, на щуп нельзя прикрепить “крокодила”, например, для подачи точечного питания или имитации джампера.

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

Хорошо, идем в синий маркетплейс и выбираем щупы с 36 тысячами отзывов и средней оценкой 4.8 (ну столько-то не накрутят же, верно?). “Оказалось, что показалась”, и замеры как прыгали, так и прыгают. При попытке вернуть товар даже продавец отказался их забирать обратно и предложил их оставить себе с выплатой небольшой компенсации. Я пару раз отказывался, но в итоге просто “забил”: теперь они лежат мертвым грузом и я не представляю, что с ними делать. Если посмотреть отзывы, очень много людей говорят, что провода работают отлично. Мне вот интересно: это мне так повезло или это “нелицензионные” провода и юни-т не хочет с ними работать ;)

В связи с этим я нуждаюсь в помощи и у меня к вам вопрос: посоветуйте, пожалуйста, хорошие провода для тестера, чтобы контакты были тонкими и длинными, с низким (желательно околонулевым) сопротивлением и подходящими под гнезда UNI-T. Заранее благодарю :)

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте