Промежуточные звенья все относятся к отправителю или получателю. УКЭП есть у достаточно большго количества народу. Если нужно гарантированно безопасно получить документы из банка и банк готов зашифровать на нее, можно даже ради этого получить.
Правильно настроенная электронная почта использует TLS соединения. Точно такие же, как онлайн банк. Кроме того, письмо / вложение может быть дополнительно зашифровано локально перед отправкой.
Вопрос был как передать по недоверенному каналу. Если приложение считаете доверенным каналом, то можно передать через него в открытом виде. Причем доверие не только к самой передаче, но и к тому, что получатель не сможет удалить факт отправки документов из приложения.
сведения, составляющие банковскую тайну требовать по незащищённому каналу Так и объясните, что не согласны раскрывать банковскую тайну третьим лицам (оператору почтового сервиса). Попросите банк предоставить сертификат УКЭП, зашифруйте на локальном компьютере этим сертификатом и в таком виде отправьте.
Федеральный закон от 02.12.1990 N 395-1 (ред. от 23.07.2025) "О банках и банковской деятельности" Статья 30.1. Рассмотрение кредитной организацией обращений ... Кредитная организация обязана обеспечить прием обращений, направленных посредством почтовой связи или нарочным на бумажном носителе, в местах обслуживания потребителей банковских услуг по адресу в пределах места нахождения кредитной организации, адресу места нахождения филиала, представительства кредитной организации, указанным в едином государственном реестре юридических лиц, а также направленных на адрес электронной почты кредитной организации. Наличие подписи заявителя в обращении не требуется. ...
Можно проверить DKIM подпись и IP адреса откуда было отправлено. Основные почтовые сервисы проверяют автоматически.
Если по п.1 письмо действительно из банка, но вызывает сомнения (типа злоумышленники получили доступ к почтовому серверу банка, или просто было направлено по ошибке). То: согласно действующему законодательству можно обращаться в банк по электронной почте. Именно так. ЕМНИП обязаны в течение суток подтвержить получение обращения и в течение 2х недель ответить (по большинству вопросов). Можно написать запрос типа: я от Вас получил письмо о предоставлении документов, прошу уточнить о каких именно 3х лицах идет речь и т.п. То есть Вы не отказываетесь предоставить документы, просто их запрос непонятный. Дальше уже исходя от ответа будет понятно, реально от банка запрос или мошенничество. По сравнению с другими формами обращений (телефон, всякие чаты и проч), отправитель не сможет сказать, что такого не было. В почте нет функций удаления сообщения отправителем и т.п. Это документ, который можно использовать при необходимости обжалования действий банка
Во втором абзаце написано, что отправляются на емейл, в четвертом - что в "Личный кабинет". Куда отправляются то в итоге и где находится этот "Личный кабинет" ?
А почему "закупка железа" в категории "не смотрим" ? Сейчас большинство "железа" (если это, конечно, не стойки для стеллажей) имеет собственное ПО. С теми же проблемами, что ПО, закупаемое непосредствено.
По ссылке написано: "Злоумышленники проникли в корпоративную систему 1С: для входа не требовалась двухфакторная аутентификация".
Но там не написано что проникли через уязвимость в 1С. И не написано, для входа куда требовалась 2FA . Если получили доступ к SQL серверу с базой или к бекапам, вообще без разницы, какая в 1С аутентификация.
В любом случае отсутствие двухфакторной аутентификации - это уязвимость конкретной инсталляции. А никак не "уязвимость в 1С".
В Яндекс-почте отображение шифрования непонятное. Принудительно выключил шифрование на исходящих письмах в Postfix (smtp_tls_security_level = none), отправил себе письмо на Яндекс-почту. Письмо пришло с ESMTP в заголовке, но в пользовательском интерфейсе зеленый замок и Шифрование:Да. Хотя в Gmail при таких настройках замок перечеркнутый красный и написано шифрования нет. Час потратил на чат с техподдержкой, в итоге пообещали ответить уже по почте в течение 2х недель.
Которые сидят в терминале отменили, например, потому что терминал привык что данные на пассажиров должны к ним из базы поступить, и не способен за короткое время полностью перестроиться на ввод вручную. Там же все по времени расписано - прилеты, вылеты, погрузка выгрузка багажа, рабочее время экипажей, работа наземного транспорта и служб обслуживания самолетов. Плюс еще вообще полеты из за БПЛА приостанавливают. 1-2 рейса как-то можно задержать и в ручном режиме обработать, но не 10-20.
Важно знать число свободных мест на рейсе, чтобы их можно было продавать. Т.е. в самолете 200 мест, но неизвестно, сколько продано, значит непонятно, сколько можно продавать еще. Не продавать на уже объявленные к продаже рейсы вообще - явно не вариант, т.к. продавали их как минимум на несколько месяцев вперед.
А где писали что закрытый ключ утащили ? По нормальному такие вещи находятся на аппаратном носителе или отдельном компьютере, который имеет только функцию "выполнить действие с ключом", но не имеет функции "выдать ключ".
Не нужен тут никакой архив, достаточно открытого ключа DKIM подписи. Пассажир представляет письмо с билетом и DKIM подписью. Подпись проверяется открытым ключом и если она валида, значит билет достоверен и данные из него можно загрузить в систему. Билеты же по типовому шаблону оформлены, значит не должно быть проблемой из него все реквизиты извлечь.
Попробуйте попросить их. Мотивируйте тем, что Вы не имеете необходимых знаний, чтобы настроить собственный почтовый сервер, поэтому вынуждены пользоватся общедоступными. В тоже время вправе рассчитывать на защиту ПДн от доступа третьих лиц (в т.ч. операторов почтовых сервисов), тем более что медицинские данные это особая категория. А получить их в офисе на бумаге Вам не удобно. Обосновать можно например тем что по работа связана с командировками в труднодоступные места, где нет их офисов. А получить результаты анализов важно оперативно, в т.ч. могут выявиться заболевания которые требуют немедленного реагирования: назначения / отмены препаратов, изменения условий труда и т.п.
Чтобы полагаться на почтовый сервер, он должен быть свой собственный. И почтовые клиенты должны быть настроены своими руками. Тогда Вы можете быть уверенными в письмах внутри него. Также Вы можете написать письмо наружу и быть уверенными что Ваш почтовый сервер проверит сертификат сервера получателя и доставит до него. Все остальное под вопросом. Здесь уже надо использовать внешнее шифрование. То есть Вы создаете ключевую пару. Например это может быть личная УКЭП, передаете сертификат Гемотесту. ПО Гемотеста шифрует результат анализов Вашим сертификатом и в зашифрованном виде передает на свой почтовый сервер (ПС), откуда уходит на ПС GMail. Здесь все зашифровано и оператор сервиса не может прочитать письмо. Дальше Вы скачиваете письмо к себе на компьютер и здесь уже локально расшифровываете с помощью закрытого ключа УКЭП. Это так в теории, возможно ли на практике, я не уверен. Хотя если они снабжают анализы своей УКЭП, возможно готовы и шифровать на сертификат пациента.
Сначала ПО Гемотеста где хранятся результаты анализов подключается к почтовому серверу (далее - ПС) Гемотеста. Это подключение скорее всего идет по внутреннему маршруту без выхода в Интернет или VPN соединению и шифрование тут роли не играет.
После этого ПС Гемотеста подключается к ПС Gmail. Я не пользуюсь GMail, но насколько мне известно, все крупные почтовые сервисы уже лет 10 как разрешают только шифрованные соединения. И здесь соединение скорее всего шифрованное. Шифрование в TLS соединении устроено так, что нельзя "записать трафик", а потом расшифровать его, даже если удастся получить закрытый ключ сервера. Для того, чтобы расшифровать данные, нужна MITM атака - пропуск атакующим соединения через свой сервер в реальном времени.
Для защиты от MITM атаки используются сертификаты. Так как соединение устанавливает почтовый сервер Гемотеста, то он будет проверять сертификат у почтового сервера Gmail. Сертификат самого ПС Гемотеста при этом никак не используется. Но может и не проверить (тогда будет возможна MITM атака). Со стороны GMail узнать, выполняет ли ПС Гемотеста проверку сертификата при подключении к ПС Gmail невозможно. Только администраторы ПС Гемотеста знают это. То есть возможна ситуация, когда у ПС отправителя быть валидный сертификат и GMail будет показывать зеленую отметку, а реально проверки на входящем письме нет.
Что именно означает пометка в интерфейсе Gmail я не знаю. Могут предположить что Gmail осуществляет отдельную (не связанную с приемом почты) проверку сертификата ПС Гемотеста на случай если Вы захотите написать им письмо.
Для меня странно, что Вас беспокоит MITM атака. которую еще надо организовать. Для этого понадобится либо наличие уязвимости на оборудовании / софте интернет-провайдера либо сообщник у них. При этом не беспокоит что на GMail Ваши данные лежат в открытом для оператора сервиса виде.
Если Вас беспокоит тема безопасности, то Вы можете проверить наличие в письме валидной DKIM подписи. Она гарантирует что письмо пришло непосредственно от ПС Гемотеста. А не было такого что письмо из Гемотеста ушло мошенникам, те прочитали его и потом отправили Вам, подставив адрес ПС Гемотеста. Например я получаю анализы по емейл от Инвитро и у них этой подписи нет. Пробовал писать им, причем даже комментарий писал для первой линии - вопрос технический по настройке почтового сервера - бесполезно. Прикладывал скриншоты заголовков, где виден ИНЗ (уникальный номер моего анализа в их системе) - бесполезно, даже не понимают о чем речь. Начинают запрашивать ФИО пациента, дату рождения и прочее что не имеет отношения к делу. Если у них есть DKIM подпись, но это именно мне так приходит без нее, ИНЗ достаточно, чтобы найти мой анализ, письмо с ним и разобраться с проблемой.
УКЭП это закрытый ключ + сертификат. Сертификат получателя документа можно использовать для шифрования данных.
Промежуточные звенья все относятся к отправителю или получателю. УКЭП есть у достаточно большго количества народу. Если нужно гарантированно безопасно получить документы из банка и банк готов зашифровать на нее, можно даже ради этого получить.
Правильно настроенная электронная почта использует TLS соединения. Точно такие же, как онлайн банк. Кроме того, письмо / вложение может быть дополнительно зашифровано локально перед отправкой.
Вопрос был как передать по недоверенному каналу. Если приложение считаете доверенным каналом, то можно передать через него в открытом виде. Причем доверие не только к самой передаче, но и к тому, что получатель не сможет удалить факт отправки документов из приложения.
Чтобы нельзя было подделать домен отправителя должна быть настроена DKIM подпись. А она настроена не у всех.
Федеральный закон от 02.12.1990 N 395-1 (ред. от 23.07.2025) "О банках и банковской деятельности"
Статья 30.1. Рассмотрение кредитной организацией обращений
...
Кредитная организация обязана обеспечить прием обращений, направленных посредством почтовой связи или нарочным на бумажном носителе, в местах обслуживания потребителей банковских услуг по адресу в пределах места нахождения кредитной организации, адресу места нахождения филиала, представительства кредитной организации, указанным в едином государственном реестре юридических лиц, а также направленных на адрес электронной почты кредитной организации. Наличие подписи заявителя в обращении не требуется.
...
Можно проверить DKIM подпись и IP адреса откуда было отправлено. Основные почтовые сервисы проверяют автоматически.
Если по п.1 письмо действительно из банка, но вызывает сомнения (типа злоумышленники получили доступ к почтовому серверу банка, или просто было направлено по ошибке). То: согласно действующему законодательству можно обращаться в банк по электронной почте. Именно так. ЕМНИП обязаны в течение суток подтвержить получение обращения и в течение 2х недель ответить (по большинству вопросов). Можно написать запрос типа: я от Вас получил письмо о предоставлении документов, прошу уточнить о каких именно 3х лицах идет речь и т.п. То есть Вы не отказываетесь предоставить документы, просто их запрос непонятный. Дальше уже исходя от ответа будет понятно, реально от банка запрос или мошенничество. По сравнению с другими формами обращений (телефон, всякие чаты и проч), отправитель не сможет сказать, что такого не было. В почте нет функций удаления сообщения отправителем и т.п. Это документ, который можно использовать при необходимости обжалования действий банка
Во втором абзаце написано, что отправляются на емейл, в четвертом - что в "Личный кабинет". Куда отправляются то в итоге и где находится этот "Личный кабинет" ?
А почему "закупка железа" в категории "не смотрим" ? Сейчас большинство "железа" (если это, конечно, не стойки для стеллажей) имеет собственное ПО. С теми же проблемами, что ПО, закупаемое непосредствено.
По ссылке написано: "Злоумышленники проникли в корпоративную систему 1С: для входа не требовалась двухфакторная аутентификация".
Но там не написано что проникли через уязвимость в 1С. И не написано, для входа куда требовалась 2FA . Если получили доступ к SQL серверу с базой или к бекапам, вообще без разницы, какая в 1С аутентификация.
В любом случае отсутствие двухфакторной аутентификации - это уязвимость конкретной инсталляции. А никак не "уязвимость в 1С".
В Яндекс-почте отображение шифрования непонятное. Принудительно выключил шифрование на исходящих письмах в Postfix (smtp_tls_security_level = none), отправил себе письмо на Яндекс-почту. Письмо пришло с ESMTP в заголовке, но в пользовательском интерфейсе зеленый замок и Шифрование:Да. Хотя в Gmail при таких настройках замок перечеркнутый красный и написано шифрования нет. Час потратил на чат с техподдержкой, в итоге пообещали ответить уже по почте в течение 2х недель.
Которые сидят в терминале отменили, например, потому что терминал привык что данные на пассажиров должны к ним из базы поступить, и не способен за короткое время полностью перестроиться на ввод вручную.
Там же все по времени расписано - прилеты, вылеты, погрузка выгрузка багажа, рабочее время экипажей, работа наземного транспорта и служб обслуживания самолетов. Плюс еще вообще полеты из за БПЛА приостанавливают. 1-2 рейса как-то можно задержать и в ручном режиме обработать, но не 10-20.
Важно знать число свободных мест на рейсе, чтобы их можно было продавать. Т.е. в самолете 200 мест, но неизвестно, сколько продано, значит непонятно, сколько можно продавать еще. Не продавать на уже объявленные к продаже рейсы вообще - явно не вариант, т.к. продавали их как минимум на несколько месяцев вперед.
А где писали что закрытый ключ утащили ? По нормальному такие вещи находятся на аппаратном носителе или отдельном компьютере, который имеет только функцию "выполнить действие с ключом", но не имеет функции "выдать ключ".
Не нужен тут никакой архив, достаточно открытого ключа DKIM подписи. Пассажир представляет письмо с билетом и DKIM подписью. Подпись проверяется открытым ключом и если она валида, значит билет достоверен и данные из него можно загрузить в систему. Билеты же по типовому шаблону оформлены, значит не должно быть проблемой из него все реквизиты извлечь.
Билет же на почту присылается, у письма должна быть DKIM подпись. Попросить пассажиров прислать письма с билетами, по ним можно восстановить.
Попробуйте попросить их. Мотивируйте тем, что Вы не имеете необходимых знаний, чтобы настроить собственный почтовый сервер, поэтому вынуждены пользоватся общедоступными. В тоже время вправе рассчитывать на защиту ПДн от доступа третьих лиц (в т.ч. операторов почтовых сервисов), тем более что медицинские данные это особая категория. А получить их в офисе на бумаге Вам не удобно. Обосновать можно например тем что по работа связана с командировками в труднодоступные места, где нет их офисов. А получить результаты анализов важно оперативно, в т.ч. могут выявиться заболевания которые требуют немедленного реагирования: назначения / отмены препаратов, изменения условий труда и т.п.
Чтобы полагаться на почтовый сервер, он должен быть свой собственный. И почтовые клиенты должны быть настроены своими руками. Тогда Вы можете быть уверенными в письмах внутри него. Также Вы можете написать письмо наружу и быть уверенными что Ваш почтовый сервер проверит сертификат сервера получателя и доставит до него. Все остальное под вопросом.
Здесь уже надо использовать внешнее шифрование. То есть Вы создаете ключевую пару. Например это может быть личная УКЭП, передаете сертификат Гемотесту. ПО Гемотеста шифрует результат анализов Вашим сертификатом и в зашифрованном виде передает на свой почтовый сервер (ПС), откуда уходит на ПС GMail. Здесь все зашифровано и оператор сервиса не может прочитать письмо. Дальше Вы скачиваете письмо к себе на компьютер и здесь уже локально расшифровываете с помощью закрытого ключа УКЭП.
Это так в теории, возможно ли на практике, я не уверен. Хотя если они снабжают анализы своей УКЭП, возможно готовы и шифровать на сертификат пациента.
При отправке письма Гемотестом на GMail:
Сначала ПО Гемотеста где хранятся результаты анализов подключается к почтовому серверу (далее - ПС) Гемотеста. Это подключение скорее всего идет по внутреннему маршруту без выхода в Интернет или VPN соединению и шифрование тут роли не играет.
После этого ПС Гемотеста подключается к ПС Gmail. Я не пользуюсь GMail, но насколько мне известно, все крупные почтовые сервисы уже лет 10 как разрешают только шифрованные соединения. И здесь соединение скорее всего шифрованное. Шифрование в TLS соединении устроено так, что нельзя "записать трафик", а потом расшифровать его, даже если удастся получить закрытый ключ сервера. Для того, чтобы расшифровать данные, нужна MITM атака - пропуск атакующим соединения через свой сервер в реальном времени.
Для защиты от MITM атаки используются сертификаты. Так как соединение устанавливает почтовый сервер Гемотеста, то он будет проверять сертификат у почтового сервера Gmail. Сертификат самого ПС Гемотеста при этом никак не используется. Но может и не проверить (тогда будет возможна MITM атака). Со стороны GMail узнать, выполняет ли ПС Гемотеста проверку сертификата при подключении к ПС Gmail невозможно. Только администраторы ПС Гемотеста знают это. То есть возможна ситуация, когда у ПС отправителя быть валидный сертификат и GMail будет показывать зеленую отметку, а реально проверки на входящем письме нет.
Что именно означает пометка в интерфейсе Gmail я не знаю. Могут предположить что Gmail осуществляет отдельную (не связанную с приемом почты) проверку сертификата ПС Гемотеста на случай если Вы захотите написать им письмо.
Для меня странно, что Вас беспокоит MITM атака. которую еще надо организовать. Для этого понадобится либо наличие уязвимости на оборудовании / софте интернет-провайдера либо сообщник у них. При этом не беспокоит что на GMail Ваши данные лежат в открытом для оператора сервиса виде.
Если Вас беспокоит тема безопасности, то Вы можете проверить наличие в письме валидной DKIM подписи. Она гарантирует что письмо пришло непосредственно от ПС Гемотеста. А не было такого что письмо из Гемотеста ушло мошенникам, те прочитали его и потом отправили Вам, подставив адрес ПС Гемотеста. Например я получаю анализы по емейл от Инвитро и у них этой подписи нет. Пробовал писать им, причем даже комментарий писал для первой линии - вопрос технический по настройке почтового сервера - бесполезно. Прикладывал скриншоты заголовков, где виден ИНЗ (уникальный номер моего анализа в их системе) - бесполезно, даже не понимают о чем речь. Начинают запрашивать ФИО пациента, дату рождения и прочее что не имеет отношения к делу. Если у них есть DKIM подпись, но это именно мне так приходит без нее, ИНЗ достаточно, чтобы найти мой анализ, письмо с ним и разобраться с проблемой.