Сноуден не нужен? - Страница 3 - Защита мобильных устройств - Форумы Anti-Malware.ru Перейти к содержанию

Recommended Posts

REVERSE
Читаю а далее

То есть получается вы контрольную сумму, сравниваете с открытым ключом, которые в свою очередь должны хранится возникает вопрос, знаете ли вы вообще, как асимметричное шифрование работает.

У вас чем дальше в лес, тем толще партизаны.

А подумать религия не позволяет? Попробую объяснить на пальцах:

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

2. Мы получили от сервера ключ, но не уверены, что он настоящий. Его же могли подменить на самом сервере?

3. Чтобы проверить, можно спросить другие сервера, находящиеся в других странах. Но они могут быть организованы немного по-другому, например, в виде DNS-серверов. Мы спрашиваем у них домен типа 31bb176e520a1757fe47fa4fbea59c17.example.com, а они нам айпишник из 4-ех байт, а это не айпишник, а crc32 от настоящего открытого ключа.

4. Мы делаем от полученного ключа crc32 и сверяем с "айпишником". Данная система с crc32 сделана только для упрощения системы и уменьшения трафика. Если таких дополнительных псевдо-dns серверов будет много по миру, то их невозможно будет контролировать всяким спецслужбам.

5. Если всё хорошо, то криптуем его открытым ключом и шлем сообщение.

Где при такой схеме возможна MitM? Мне правда интересно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
а если ничего не реализовывать то ничего и не изменится dry.gif

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

А потом лезть в мою личную переписку, чистыми руками. Раз уж это необходимо в борьбе с терроризмом.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
dot_sent
Последний раз отвечу, и хватит.

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

Протокол обмена ключами Диффи-Хеллмана.

А подумать религия не позволяет? Попробую объяснить на пальцах:

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

2. Мы получили от сервера ключ, но не уверены, что он настоящий. Его же могли подменить на самом сервере?

3. Чтобы проверить, можно спросить другие сервера, находящиеся в других странах. Но они могут быть организованы немного по-другому, например, в виде DNS-серверов. Мы спрашиваем у них домен типа 31bb176e520a1757fe47fa4fbea59c17.example.com, а они нам айпишник из 4-ех байт, а это не айпишник, а crc32 от настоящего открытого ключа.

4. Мы делаем от полученного ключа crc32 и сверяем с "айпишником". Данная система с crc32 сделана только для упрощения системы и уменьшения трафика. Если таких дополнительных псевдо-dns серверов будет много по миру, то их невозможно будет контролировать всяким спецслужбам.

5. Если всё хорошо, то криптуем его открытым ключом и шлем сообщение.

Где при такой схеме возможна MitM? Мне правда интересно.

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

Поделиться сообщением


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

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

Но на любую хитрую Ж ... можно передавать важную информацию частями по разным каналам. Если мониторится все у всех, то обнаружить и сопоставить части будет крайне сложно. SMS + email + HTTPS - тремя частями с произвольным интервалом времени между отправками от 1 до 30 секунд.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
REVERSE
Да хотя бы на маршрутизаторе вашего провайдера. Для простоты. Не говоря уже о возможности взять под контроль любой из упомянутых серверов.

Ага, подменять трафик они могут весь. Теоретически. Но только они не смогут прочитать что-то, зашифрованное открытым ключом сервера (зашитым в клиент), который находится не в этой стране. А сервер зашифровывает инфу моим открытым ключом. Как они могут что-то прочитать?

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

Поделиться сообщением


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

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

Ошибаетесь, причём целиком и полностью, нагуглить нагуглили, а понять написанное не смогли.

Вы в концептуальных, рамочных вещах путаетесь, не говоря уж о частностях.

Но на любую хитрую Ж ... можно передавать важную информацию частями по разным каналам. Если мониторится все у всех, то обнаружить и сопоставить части будет крайне сложно. SMS + email + HTTPS - тремя частями с произвольным интервалом времени между отправками от 1 до 30 секунд.

Именно это АНБ исправить и пытается, во всяком случае остаётся такое впечатление после чтения материалов на тему того, как у них сети связи развиваются и чем у них университеты занимаются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Pomka.

мне вот интересно вчера в новостях был вброс что АНБ читает слушает перехватывает всю инфу европейского правительства

там в Европе что совсем ничем не шифруют ? или тупо на что то надеются что всё что секретно не читаемо?

если правительство с такими возможностями не могут защитить свои данные то вообще что может сделать простой пользователь и тем боле как он может с этим бороться?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
REVERSE
Ошибаетесь, причём целиком и полностью, нагуглить нагуглили, а понять написанное не смогли.

Вы в концептуальных, рамочных вещах путаетесь, не говоря уж о частностях.

Именно это АНБ исправить и пытается, во всяком случае остаётся такое впечатление после чтения материалов на тему того, как у них сети связи развиваются и чем у них университеты занимаются.

Как-то голословно у вас это ВСЁ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
OlegAndr
согласно ч. 3 ст. 55 Конституции права и свободы человека и гражданина могут быть ограничены федеральным законом только в той мере, в какой это необходимо в целях защиты основ конституционного строя, нравственности, здоровья, прав и законных интересов других лиц, обеспечения обороны страны и безопасности государства.

Вот эта норма - она самая основополагающая в нашей конституции.

Сравните с

Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances

Поделиться сообщением


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

Нелегкая задача. Вот и получится почти как в анекдоте, что последним оплотом сопротивления слежке АНБ будет ... Почта России :lol:

мне вот интересно вчера в новостях был вброс что АНБ читает слушает перехватывает всю инфу европейского правительства

там в Европе что совсем ничем не шифруют ? или тупо на что то надеются что всё что секретно не читаемо?

если правительство с такими возможностями не могут защитить свои данные то вообще что может сделать простой пользователь и тем боле как он может с этим бороться?

Я думаю, что во-первых всю информацию из СМИ нужно подвергать критическому анализу. Мне он говорит о следующем: 1. Европу пытаются представить как набор потерявших электронный суверенитет государств 2. Европейцы давно знают о слежке и торгуют информацией со штатами 3. Простым юзерам внедряют мысль, что сделать ничего нельзя, если мол даже президентов читают.

Зачем это делает? - ответ на этот вопрос неоднозначный. Политика.

OlegAndr, американское лицемерие уже становится притчей во языцех. Самая правильная конституция породила АНБ, коммерческие спецслужбы (бог знает чем занимающиеся), а также серию военных конфликтов, основанных на концепции нового фашизма об "американской исключительности".

  • Upvote 5

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Mr. Justice
Вот эта норма - она самая основополагающая в нашей конституции.

Эта норма не оригинальна. Возможность ограничения прав и свобод человека посредством текущего законодательства признается международным сообществом и закреплена в основополагающих актах международного права, таких как Всеобщая декларация прав человека, Международный пакт о гражданский и политических правах, Европейская конвенция о защите прав человека и основных свобод и т.д. Конституция РФ принималась с учетом международных стандартов в области прав человека.

Сравните с

Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances

Проблема в том, что Верховный Суд США (в США нет Конституционного Суда) наделен правом "широкого толкования" основного закона страны, основанном на концепции "живой Конституции". Это позволяет Верховному Суду толковать Конституцию в соответствии с меняющимся историческим контекстом и с учетом эволюции потребностей государства и общества, то есть по сути дела толковать основной закон страны выходя за рамки буквального текста конституции, когда в этом есть необходимость. Американцы гордятся своей конституцией, имеющей двухсотлетнюю историю - у них конституция древняя и стабильная (за более чем 200 лет внесено всего 27 поправок из более чем 1000 предложенных). У французов и русских действую пятые по счету конституции. Знаете почему? Потому, что русские и французы не стесняются вносить поправки и даже принимать новые конституции, отменяя устаревшие, а американцы предпочитают менять толкование основного закона страны, наделяя Верховный Суд, по сути дела, полномочиями законодателя и нарушая тем самым принцип разделения властей, закрепленный в основном законе США.

По приведенному Вами фрагменту из Конституции США приведу цитату из комментария известного специалиста в области конституционного права, бывшего Председателя Конституционного Суда РФ, профессора Баглая:

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

(М.В.Баглай. Конституционное право зарубежных стран, издание Московского государственный института международных отношений (Университет) МИД РФ).

  • Upvote 5

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy

Mr. Justice, спасибо за подробное объяснение.

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

Все ходатайства (принимать их или отклонять) находятся во власти судьи, и даже если удовлетворение ходатайства может пролить свет на суть дела, судья может отклонить ходатайство. Ключевое: без объяснения своих мотивов, чтобы потом можно было нормально аппеляцию подать. Поэтому суд более высшей инстанции может тоже отказать в том же самом ходатайстве. Тоже без объяснения мотивов. Такая вот система и толкование закона. И не докажешь, что идёт им (законом) злоупотребление.

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

Хотя в США тоже интересно. Везде есть декларативные основные принципы разделения властей. И есть реальность, имеющая с ними мало общего.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
SDA

Немного не по теме, но отличная характеристика "Оплота свободы", которым некоторые так восхищаются :lol:http://news.yandex.ru/yandsearch?cl4url=ww...g=ru&lr=213 добавим такие факты http://ru.fbii.org/investigations/836.html и чего уж там говорить про прослушку и слежение :facepalm:

Но на самом деле в цивилизованном обществе ничего подобного нет. Все вопросы решаются гражданами цивилизованным путём, в суде. :lol:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Mr. Justice
Mr. Justice, спасибо за подробное объяснение.

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

Все ходатайства (принимать их или отклонять) находятся во власти судьи, и даже если удовлетворение ходатайства может пролить свет на суть дела, судья может отклонить ходатайство. Ключевое: без объяснения своих мотивов, чтобы потом можно было нормально аппеляцию подать. Поэтому суд более высшей инстанции может тоже отказать в том же самом ходатайстве. Тоже без объяснения мотивов. Такая вот система и толкование закона. И не докажешь, что идёт им (законом) злоупотребление.

Далеко не всегда имеют место нарушения о которых ты пишешь. Иногда думаешь, что судья нарушил закон, но изучив проблему внимательно, понимаешь, что ошибся ты, а не судья. Потому, что ты относился к делу предвзято, а он нет, но тебе казалось, что суд был необъективен.

Кроме того, ты пытаешься сопоставить несопоставимое, сравнивая казуальное толкование с нормативным. Ты приводишь примеры казуального толкования, а я выше вел речь о нормативном толковании Конституции США Верховным Судом этой страны. Суть казуального толкования заключается в интерпретации норм применительно к конкретному делу, нормативное толкование рассчитано на последующее использование его результатов иными правоприменительными органами, включая суды. Ошибки и вольности в нормативном толковании более опасны и могут привести к более серьезным проблемам в правоприменительной практике по сравнению с аналогичными упущениями, допущенными в процессе казуального толкования. Ошибка нормативного толкования опасна тем, что она носит шаблонный характер и обязательно будет воспроизводиться в дальнейшем в правоприменительной практике. Кроме того, ты не учитываешь масштабы. Нельзя сравнивать ошибки и вольности допускаемые при толковании конституции (основного закона) и текущего (обычного) законодательства.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
Далеко не всегда имеют место нарушения о которых ты пишешь. Иногда думаешь, что судья нарушил закон, но изучив проблему внимательно, понимаешь, что ошибся ты, а не судья. Потому, что ты относился к делу предвзято, а он нет, но тебе казалось, что суд был необъективен.

Ну, ещё б они были всегда.

Вопрос в том, что часто суды не хотят истребовать в других органах государственной власти дополнительные сведения, которые могли бы помочь более объективно рассмотреть дело. Также существует и весьма распространено так называемое "телефонное право".

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

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

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

Хм. Спасибо, не знал.

Кстати, хотел ещё спросить. У нас можно вносить изменения в Конституцию Федеральным законом без референдума?

  • Upvote 5

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Mr. Justice
Кстати, хотел ещё спросить. У нас можно вносить изменения в Конституцию Федеральным законом без референдума?

Да. Всенародное голосование необходимо только для принятия новой конституции в случае пересмотра ныне действующей Конституции РФ (не путать с внесением поправок и внесением изменений - это все разные понятия). Пересмотр предполагает отмену ныне действующей Конституции и принятие новой. Подробнее здесь http://base.garant.ru/10103000/9/#block_134

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин
Немного не по теме, но отличная характеристика "Оплота свободы", которым некоторые так восхищаются http://news.yandex.ru/yandsearch?cl4url=ww...g=ru&lr=213 добавим такие факты http://ru.fbii.org/investigations/836.html и чего уж там говорить про прослушку и слежение

Знаем, играли в GTA :)

Сорри, за оффтоп.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dr. Faust
Нелегкая задача. Вот и получится почти как в анекдоте, что последним оплотом сопротивления слежке АНБ будет ... Почта России :lol:

Ну в общем то да, юмор юмором, но на деле только американцы перед собой ставят такие глобальные задачи как, например, перехват, агрегация и анализ трафика, который идёт из других стран, нигде более включая Россию, ничего подобного даже в планах нет, всё ограничивается возможностью снимать информацию с конкретного оборудования, конкретного провайдера, масштаб максимум региональный, в других странах судя по всему тоже самое, имею ввиду их собственные, национальные аналоги. А вот янки и их кузены, молодцы да, широко шагают, как приняли ЕМНИП в 2001 стандарт по законному перехвату в ИП-сетях , так и двигаются как по рельсам, всё телекоммуникационное оборудование, которое выпускается для операторов связи изначально предполагает возможность подключения медиаторов систем перехвата, в качестве примера и на заметку законникам (http://www.cisco.com/en/US/technologies/tk583/tk799/mediation_device_suppliers.html), существующие сети связи модернизируют, параллельно решают задачи сбора данных со всех сетевых у-в в цепочке передачи, включая даже серверы приложений, далее, экспертные системы, с которыми уже операторы и аналитики работают. Не знаю выйдет ли толк, слишком много технических сложностей, включая даже фундаментальные, но то что они благодаря такому вот заделу, могут себе быть законодателями мод в области сетевых технологий и телекоммуникаций, то есть факт бесспорный. Где-то полгода назад слушал лекцию одного профессора из Калифорнийского технологического университета, его доклад был посвящён p2p трафику в сетях оператора, процентов 80 из того, что он говорил было посвящено тому, как бороться с торентами," не в том смысле чтобы полностью запретить, а в том, как ограничить, так чтобы они всю полосу не заняли, а вот в в числе оставшихся 20% он сказал, что в настоящее время они приближаются к возможности перехвата и анализа трафика в масштабах близких к реальному времени, говорил он это только про перехват с оборудования одного провайдера и только в пределах штатов, но тем не менее.

  • Upvote 5

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dr. Faust

Я попытаюсь в последний раз.

REVERSE, я напомню о чём шла речь, вы высказали тезис о том, что необходимо в обязательном порядке использовать шифрование трафика и считаете его некой панацей, я в свою очередь поинтересовался у вас - как это по-вашему должно работать и какой практический смысл процедура шифрования трафика должна нести для пользователя, Вас, меня, Сергея Ильина, Валерия Ледовского (простите если ошибся в написании фамилии) и других присутствующих и отсутствующих. Для меня странным был факт того, что вы начисто игнорируете общепринятую клиент — серверную модель межсетевого взаимодействия, то есть для того, чтобы обмениваться зашифрованными сообщениями и клиент и сервер могут только в том случае, когда это самое шифрование поддерживают и тот и другой, элементарный пример, если я зашифрую текст этого сообщения инкапсулирую его в IP-пакет и отправлю его на данный форум, исходный текст моего сообщения тут не появится. Перед тем как обмениваться зашифрованными сообщениями между клиентом и сервером должна пройти процедура согласования, о чём я вам и писал раньше. Но я то наивный думал, ну может у чувака есть оригинальные идеи относительно шифрования только полезной нагрузки допустим, или чувак имеет ввиду частный случай, скажем шифрование исключительно сообщения в электронной почте, контраргументы придумал, а вы оказывается просто азбуки не знаете, говорите о асимметричном шифровании, а понятий: закрытый ключ, пара ключей не звучало ни разу вместо этого

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

Открытый ключ, REVERSE, он потому и называется открытым, поскольку передаётся по незащищённому каналу и используется или для шифрования или для расшифровки, в зависимости от того про какой сервис мы говорим, где-то там его хранить или тем более куда-то "зашивать" не нужно абсолютно. Весь процесс взаимодействия, возможен только между теми участниками, у которых есть пара ключей: открытый и закрытый соответственно. На этом разговор можно было бы и закончить, но раз спрашиваете про Man in the middle, напишу, коротко не обессудьте.

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

Игнорируя глупости в в виде "спец запросов", "зашит в клиент" я наконец то понял почему вы везде лепите слово хеш, прочитали кусок про ЭЦП, не поняли и теперь лепите везде, так вот в ЭЦП получение хеша и его дальнейшее шифрование обусловлено ровно одним - сократить размер сообщения. Всё, других целей не преследуется.

2. Мы получили от сервера ключ, но не уверены, что он настоящий. Его же могли подменить на самом сервере?

Скорее мы не уверены что данный ключ прислан именно нужным нам сервером, именно поэтому существуют сертификаты.

3. Чтобы проверить, можно спросить другие сервера, находящиеся в других странах. Но они могут быть организованы немного по-другому, например, в виде DNS-серверов. Мы спрашиваем у них домен типа 31bb176e520a1757fe47fa4fbea59c17.example.com, а они нам айпишник из 4-ех байт, а это не айпишник, а crc32 от настоящего открытого ключа.

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

Юмор со схемой ваших псевдо-ДНС по всему миру, я оценил, но комментировать уже не буду, просто нет сил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
SDA

ОФФ

Авраам Линкольн дал людям свободу, а полковник Кольт уравнял их шансы :lol:

200px-SamuelColt.jpg

В другой интерпритации:

Господь Бог сотворил людей, а полковник Кольт сделал их равными

Пи.си.

единственная свобода в Оплоте свободе Отцов основателей , которой я симпотизирую ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
REVERSE
Я попытаюсь в последний раз.

REVERSE, я напомню о чём шла речь, вы высказали тезис о том, что необходимо в обязательном порядке использовать шифрование трафика и считаете его некой панацей, я в свою очередь поинтересовался у вас - как это по-вашему должно работать и какой практический смысл процедура шифрования трафика должна нести для пользователя, Вас, меня, Сергея Ильина, Валерия Ледовского (простите если ошибся в написании фамилии) и других присутствующих и отсутствующих. Для меня странным был факт того, что вы начисто игнорируете общепринятую клиент — серверную модель межсетевого взаимодействия, то есть для того, чтобы обмениваться зашифрованными сообщениями и клиент и сервер могут только в том случае, когда это самое шифрование поддерживают и тот и другой, элементарный пример, если я зашифрую текст этого сообщения инкапсулирую его в IP-пакет и отправлю его на данный форум, исходный текст моего сообщения тут не появится. Перед тем как обмениваться зашифрованными сообщениями между клиентом и сервером должна пройти процедура согласования, о чём я вам и писал раньше. Но я то наивный думал, ну может у чувака есть оригинальные идеи относительно шифрования только полезной нагрузки допустим, или чувак имеет ввиду частный случай, скажем шифрование исключительно сообщения в электронной почте, контраргументы придумал, а вы оказывается просто азбуки не знаете, говорите о асимметричном шифровании, а понятий: закрытый ключ, пара ключей не звучало ни разу вместо этого

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

Насчет всех ваших остальных слов - попробую еще раз полно показать предлагаемую мной схему. И конкретно скажу, никакого зашифрованного трафика между юзером и форумами НЕТ, только зашифрованные сообщения между пользователями. Аналог аськи, или почты, всё зависит только от реализации клиентской части - это даже могут быть плагины к миранде, Ткабберу и Thunderbird'у.

В упрощенном виде:

0. Используется ассиметричное шифрование! Да, с открытым и закрытым ключами!

1. Алиса хочет отправить сообщение Бобу, но не имеет его открытого ключа, имеет только почтовый адрес Боба.

2. Она добавляет (почтовый адрес) Боба в свой контакт-лист.

3. Клиент связывается с сервером, где лежат все открытые ключи зарегистрированных юзеров, по md5(bob@server.tld) узнаёт открытый ключ Боба.

4. Алиса пишет сообщение Бобу, клиент зашифровывает сообщение открытым ключом Боба, отправляет на сервер (хотя может узнать у сервера IP:Port Боба и послать ему напрямую, но это другой вопрос)

5. Боб получает с сервера сообщение, расшифровывает его своим закрытым ключом, видит, что оно от Алисы и читает текст.

Итак, такая схема, в упрощенном виде порождает массу вопросов, правда же? У кого-то уже отложена небольшая партия аккуратных крупных кирпичей.

Вопросы и ответы:

1. Если на проводе у Алисы сидит дядька в погонах, или хитрый админ, как ей быть уверенной, что полученный открытый ключ именно Боба?

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

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

2. Что, если к серверу допустили людей в погонах, и они аккуратно подменили ключ Боба в базе данных? Ведь сервер радостно отдаст его, и все вышеописанные процедуры будут насмарку!

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

Таким образом, когда клиент Алисы получил открытый ключ Боба, он делает запросы на НЕСКОЛЬКО серверов-сателитов, получает от них crc32 ключа Боба и может проверить правильность ключа, разве нет? (допускаем, что сгенерировать свой ключ, чтобы у него был такой же как у Боба crc32 почти нереально)

Если какое-то количество серверов выдало разную информацию, Алиса будет оповещена о том, что открытый ключ Боба ненадёжен.

Плюс к этому, сервера-сателиты регулярно обновляют инфу о ключах юзеров, и если какой-то из них изменился, отсылают Alert юзеру, что ключ был изменен. Юзер будет знать о таких изменениях в системе.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dr. Faust
Во-первых, я вас не обзывал, а вы меня обзываете чуваком, это как минимум не корректно, но как максимум показывает, почему вы не понимаете того, что я пишу - у вас огромная тяга к унижению и опровержению. А я ведь призываю к конструктивному диалогу, мы же с вами в одной лодке, как никак.

Нельзя призывать к тому, чего, не существует, REVERSE, ну а так да, я вообще прелесть, вот только не сидим мы с вами в одной лодке и даже в одном водоёме не сидим :D

Насчет всех ваших остальных слов - попробую еще раз полно показать предлагаемую мной схему. И конкретно скажу, никакого зашифрованного трафика между юзером и форумами НЕТ, только зашифрованные сообщения между пользователями. Аналог аськи, или почты, всё зависит только от реализации клиентской части - это даже могут быть плагины к миранде, Ткабберу и Thunderbird'у.

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

В упрощенном виде:

0. Используется ассиметричное шифрование! Да, с открытым и закрытым ключами!

1. Алиса хочет отправить сообщение Бобу, но не имеет его открытого ключа, имеет только почтовый адрес Боба.

2. Она добавляет (почтовый адрес) Боба в свой контакт-лист.

3. Клиент связывается с сервером, где лежат все открытые ключи зарегистрированных юзеров, по md5(bob@server.tld) узнаёт открытый ключ Боба.

4. Алиса пишет сообщение Бобу, клиент зашифровывает сообщение открытым ключом Боба, отправляет на сервер (хотя может узнать у сервера IP:Port Боба и послать ему напрямую, но это другой вопрос)

5. Боб получает с сервера сообщение, расшифровывает его своим закрытым ключом, видит, что оно от Алисы и читает текст.

Итак подобьём итог и исключим разночтения:

0. Теперь у вас наконец то появился закрытый ключ. Ок, хорошо тогда правильно ли я понимаю, что на этом вашем "сервере" хранятся исключительно открытые ключи всех пользователей, а закрытые ключи не хранятся на сервере нигде, никогда и ни в каком виде? Да/Нет?

1. Все пары закрытых/открытых ключей для каждого пользователя уникальны и неизменны с момента создания и навсегда? Да/Нет?

2. Зачем идентификация открытого ключа в вашей схеме сделана по md5? Считаете ли вы такую схему надёжной и стойкой к компрометации? Да/Нет?

3. При обмене ключами напрямую, проверка подлинности происходит, также, через общий сервер? Да/Нет?

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

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

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

Принимая во внимание всё написанное вами выше, скажите, правильно ли я понимаю, что именно сервер занимается расшифровкой этой тестовой строки? Так?

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

Таким образом, когда клиент Алисы получил открытый ключ Боба, он делает запросы на НЕСКОЛЬКО серверов-сателитов, получает от них crc32 ключа Боба и может проверить правильность ключа, разве нет? (допускаем, что сгенерировать свой ключ, чтобы у него был такой же как у Боба crc32 почти нереально)

Если какое-то количество серверов выдало разную информацию, Алиса будет оповещена о том, что открытый ключ Боба ненадёжен.

Плюс к этому, сервера-сателиты регулярно обновляют инфу о ключах юзеров, и если какой-то из них изменился, отсылают Alert юзеру, что ключ был изменен. Юзер будет знать о таких изменениях в системе.

Правильно ли я понимаю, что эти ваши серверы-сателлиты хранят лишь соответсвие user id - контрольная сумма открытого ключа? При этом клиент обращается к этим серверам напрямую типа: запрос (user id) - ответ от сервера crc, именно так?

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

Где можно ознакомится с вашими проектом или есть хотя бы какой то драфт?

ОФФ

Авраам Линкольн дал людям свободу, а полковник Кольт уравнял их шансы :lol:

200px-SamuelColt.jpg

В другой интерпритации:

Господь Бог сотворил людей, а полковник Кольт сделал их равными

Пи.си.

единственная свобода в Оплоте свободе Отцов основателей , которой я симпотизирую ;)

Есть ещё третий вариант интерпритации:

Назовёте слово целиком или мы будем вращать барабан?(с) Полковник Кольт

По-моему очень подходит к ситуации :D а юноша в гугл убежал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
REVERSE
Итак подобьём итог и исключим разночтения:

0. Теперь у вас наконец то появился закрытый ключ. Ок, хорошо тогда правильно ли я понимаю, что на этом вашем "сервере" хранятся исключительно открытые ключи всех пользователей, а закрытые ключи не хранятся на сервере нигде, никогда и ни в каком виде? Да/Нет?

1. Все пары закрытых/открытых ключей для каждого пользователя уникальны и неизменны с момента создания и навсегда? Да/Нет?

2. Зачем идентификация открытого ключа в вашей схеме сделана по md5? Считаете ли вы такую схему надёжной и стойкой к компрометации? Да/Нет?

3. При обмене ключами напрямую, проверка подлинности происходит, также, через общий сервер? Да/Нет?

0. Естественно, есть закрытые ключи. Не надо считать всех дебилами сразу. Конечно, закрытый ключ хранится только у пользователя, никуда ни при каких условиях не передаётся (Хотел сначала написать, что они рандомно рассылаются по случайным адресам, но вспомнил, что у вас с пониманием, да и, наверно, с чувством юмора, не очень). При этом, файл с ключом зашифрован каким-нибудь AES'ом с паролем пользователя, чтобы трояны его не увели, пароль вводится в самом мессенджере при попытке считать файл (защиту оперативки пока оставим в стороне).

1. Уникальность никак не проверяется, её и не должно быть. Разве у паролей есть такое требование? Юзер может сменить свою пару ключей по своему желанию (В данном случае есть некоторые трудности, но не критичные).

2. MD5 приведен только как пример. Введено это для того, чтобы при перехвате трафика не было видно, кто с кем общается. Хэш может быть длиннее, или состоять из пары-тройки разных хэшей, по разным алгоритмам. Конечно, коллизий не избежать полностью, но это и не нужно. (Gravatar ищет аватарки по md5 от мыла, никто еще от этого не умер)

3. Что за обмен ключами, и что значит напрямую? Я, кажется, о таком не писал.

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

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

Принимая во внимание всё написанное вами выше, скажите, правильно ли я понимаю, что именно сервер занимается расшифровкой этой тестовой строки? Так?

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

Правильно ли я понимаю, что эти ваши серверы-сателлиты хранят лишь соответсвие user id - контрольная сумма открытого ключа? При этом клиент обращается к этим серверам напрямую типа: запрос (user id) - ответ от сервера crc, именно так?

Да.

Где можно ознакомится с вашими проектом или есть хотя бы какой то драфт?

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

По-моему очень подходит к ситуации :D а юноша в гугл убежал.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dr. Faust
0. Естественно, есть закрытые ключи. Не надо считать всех дебилами сразу. Конечно, закрытый ключ хранится только у пользователя, никуда ни при каких условиях не передаётся (Хотел сначала написать, что они рандомно рассылаются по случайным адресам, но вспомнил, что у вас с пониманием, да и, наверно, с чувством юмора, не очень). При этом, файл с ключом зашифрован каким-нибудь AES'ом с паролем пользователя, чтобы трояны его не увели, пароль вводится в самом мессенджере при попытке считать файл (защиту оперативки пока оставим в стороне).

Итак, вы ответили да, что закрытый ключ храниться только у пользователя. Зафиксируем это.

1. Уникальность никак не проверяется, её и не должно быть. Разве у паролей есть такое требование? Юзер может сменить свою пару ключей по своему желанию (В данном случае есть некоторые трудности, но не критичные).

Вы не поняли, у каждого пользователя вашей системы, будет собственная, уникальная пара ключей, соответственно в рамках системы ключи уникальны, теперь скажите чётко, помимо уникальности, пара ключей не изменяется, исключая случаи когда пользователь (человек) сам хочет сгенерировать новую пару ключей, всё именно так?

2. MD5 приведен только как пример. Введено это для того, чтобы при перехвате трафика не было видно, кто с кем общается. Хэш может быть длиннее, или состоять из пары-тройки разных хэшей, по разным алгоритмам. Конечно, коллизий не избежать полностью, но это и не нужно. (Gravatar ищет аватарки по md5 от мыла, никто еще от этого не умер)

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

3. Что за обмен ключами, и что значит напрямую? Я, кажется, о таком не писал.

Ну как же это не писали, а вот это вот как понимать:

4. Алиса пишет сообщение Бобу, клиент зашифровывает сообщение открытым ключом Боба, отправляет на сервер (хотя может узнать у сервера IP:Port Боба и послать ему напрямую, но это другой вопрос)

Написано ясно - может послать ему напрямую, из контекста следует, что ключ. Так?:)

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

Вы всё время всё то намекаете, то упрощаете :D А от вас требуется ответить на простой вопрос, который имеет самое прямое касательство, к обсуждаемому вопросу, вы можете это сделать или нет? Итак я напомню как звучал вопрос.

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

Жду ваш ответ.

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

Ответ зафиксирован и принят

Да.

Ответ принят.

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

Я почему то именно так и предполагал. Ну покажите что есть, есть же у вас хоть какие-нибудь черновики, схемы, вот схемы интересно, или всё в голове?:)

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
REVERSE
Итак, вы ответили да, что закрытый ключ храниться только у пользователя. Зафиксируем это.

Вы не поняли, у каждого пользователя вашей системы, будет собственная, уникальная пара ключей, соответсвенно в рамках системы ключи уникальны, теперь скажите чётко, помимо уникальности, пара ключей не изменяется, исключая случаи когда пользователь (человек) сам хочет сгенерировать новую пару ключей, всё именно так?

Так.

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

В общем случае - нет (из-за возможных коллизий). В случае коротких строк, "похожих" на мыло, - да.

Ну как же это не писали, а вот это вот как понимать:

"4. Алиса пишет сообщение Бобу, клиент зашифровывает сообщение открытым ключом Боба, отправляет на сервер (хотя может узнать у сервера IP:Port Боба и послать ему напрямую, но это другой вопрос)"

Написано ясно - может послать ему напрямую, из контекста следует, что ключ. Так?:)

Нет, сообщение. Рекомендую капитальный ремонт парсера. Открытый ключ другого пользователя получается только с сервера. Диффи-Хеллмана пока реализовывать не хочу.

Вы всё время всё то намекаете, то упрощаете :D А от вас требуется ответить на простой вопрос, который имеет самое прямое касательство, к обсуждаемому вопросу, вы можете это сделать или нет? Итак я напомню как звучал вопрос.

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

Жду ваш ответ.

Нет.

Я почему то именно так и предполагал. Ну покажите что есть, есть же у вас хоть какие-нибудь черновики, схемы, вот схемы интересно, или всё в голове?:)

Первым сообщением с описанием системы я преследовал именно эту цель - донести до заинтересованных придуманную мной схему.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • Ego Dekker
      Домашние антивирусы для Windows были обновлены до версии 19.2.10.
    • PR55.RP55
      1) Ситуация когда нет доступа к virustotal.com ( и другим ресурсам ) Что предлагаю: а) На примере Firefox 155 - Happy Eyeballs v3: подключение сразу несколькими путями *Браузер больше не выбирает маршрут до сайта заранее, а пробует несколько вариантов подключения параллельно и работает через тот, который отозвался первым. Выигрыш заметнее всего в сетях, где IPv4 или IPv6 работает медленно либо нестабильно: раньше браузер мог упереться в неотвечающий адрес и ждать таймаута, теперь соединение уходит по резервному пути без паузы. б) Если сайт полностью не доступен - то, при потоковой проверке файлов не заставлять пользователя "бесконечно" ждать... 2) Драйвер фаервола - при проверке. По хорошему программа сама должна знать какие файлы её, какие нет и всякий раз не лезть к ним и не пытаться получить доступ к собственному файлу ?  
    • AM_Bot
      «Инфосистемы Джет» активно развивает концепцию антихрупкости. Эта компания разработала инструменты для её практического применения — первый Фреймворк антихрупкой ИТ-архитектуры и Индекс антихрупкости для построения киберустойчивого бизнеса.      1. Введение2. Что такое антихрупкость ИТ-архитектуры3. Назначение инструментов, разработанных компанией «Инфосистемы Джет»3.1. Фреймворк антихрупкой ИТ-архитектуры3.2. Индекс антихрупкости4. Как проходит оценка4.1. Заполнение профиля компании4.2. Построение бенчмарка4.3. Прохождение опроса4.4. Оценка результатов5. ВыводыВведениеРезонансные атаки на крупнейшие российские компании, которые мы регулярно освещаем, вскрыли системную проблему: реальная операционная готовность к инцидентам остаётся на низком уровне, даже если система защиты формально выстроена. Как показало недавнее исследование компании «Инфосистемы Джет», пережить кибератаку не готовы 64 % из 50 российских компаний. Хуже всего ситуация обстоит в госсекторе и ритейле — при этом именно эти отрасли входят в число наиболее атакуемых.Защита, которая создавалась, чтобы остановить злоумышленника, теперь может лишь его замедлить — и одной способности «не пустить» стало недостаточно. Закупленные СЗИ создают иллюзию надёжности: организация выглядит защищённой, но в момент реальной атаки оказывается уязвимой.В условиях массовых взломов и эволюции атакующих стратегий на первое место выходит принцип управляемого ухудшения ситуации. Взлом с большой вероятностью произойдёт, но мы должны уметь работать под атакой, управлять кризисом и быстро восстановиться. Также необходимо выстроить зрелые процессы реагирования на угрозы, восстановления после инцидентов и обеспечения непрерывности бизнеса даже в условиях атаки. В ответ на этот вызов ИТ-компания «Инфосистемы Джет», работающая на российском рынке с 1991 года, предложила использовать концепцию антихрупкой ИТ-архитектуры.Её суть заключается в том, что ИТ-инфраструктура должна не просто выдерживать сбои, атаки и неблагоприятные обстоятельства, а по-настоящему быть к ним готовой, эффективно их преодолевать и даже извлекать из них пользу, становясь надёжнее и укрепляя свои позиции среди конкурентов.Что такое антихрупкость ИТ-архитектурыКонцепция антихрупкости впервые была предложена учёным Нассимом Талебом, статистиком, бывшим трейдером и риск-менеджером, который прославился изучением влияния случайных и непредсказуемых событий на мировую экономику и биржевую торговлю. В книге «Чёрный лебедь. Под знаком непредсказуемости» (The Black Swan), вышедшей в 2007 году, он ввёл сам термин «чёрный лебедь» для описания редких и маловероятных событий, имеющих огромные последствия, и пришёл к выводу, что вместо попыток их предсказания логичнее создавать системы, способные не просто пережить хаос, но и становиться после него сильнее. Именно это понимание легло в основу идеи антихрупкости, которая уже была детально раскрыта Талебом в книге 2012 года «Антихрупкость. Как извлечь выгоду из хаоса» (Antifragile: Things That Gain From Disorder).Вдохновившись концепцией антихрупкости, аналитики компании «Инфосистемы Джет» решили развивать эти идеи и продвигать их в России. Антихрупкая ИТ-архитектура — не гонка за новыми инструментами. Она строится вокруг способности пережить полный жизненный цикл атаки: подготовиться к ней, замедлить злоумышленника, обнаружить вторжение, сократить ущерб, восстановить бизнес и перестроиться после инцидента. Для практической реализации концепции антихрупкости «Инфосистемы Джет» разработали первый Фреймворк антихрупкой архитектуры и Индекс антихрупкости, позволяющие выявить слабые места и сформировать дорожную карту усиления защиты.Назначение инструментов, разработанных компанией «Инфосистемы Джет»Как же перейти от понимания концепции антихрупкости к её реализации? В этом помогут разработанные вендором инструменты, которые мы рассмотрим ниже.Фреймворк антихрупкой ИТ-архитектурыФреймворк антихрупкой ИТ-архитектуры представляет собой открытый и практичный инструмент, который объединил опыт инженеров, аудиторов, консультантов и экспертов-практиков по защите сети и построению ИТ-инфраструктуры. Он разработан командой «Инфосистемы Джет» во главе с руководителем отдела развития консалтинга по ИБ Александром Морковчиным.Сценарии использования фреймворка охватывают три ключевые рыночные потребности. Первая — оценка текущего уровня киберустойчивости с помощью единой измеримой «линейки» для сопоставления с конкурентами и отраслевыми лидерами. Вторая — планирование развития на основе каталога проверенных практик и выбор вектора роста. Третья — трансформация: пошаговый переход от фактического состояния к целевому уровню киберустойчивости. Фреймворк имеет иерархическую логику: он строится по каскадной модели «в крупную клетку», т. е. на высоком уровне абстракции, без погружения в мелкие детали. Всего существует пять уровней детализации, где каждый следующий уровень конкретизирует предыдущий. Это позволяет последовательно двигаться от общего видения (стратегии) по уровням детализации к конкретным действиям (практике), сохраняя гибкость и системность.Фреймворк доступен на официальном сайте и не требует установки дополнительных расширений. Рисунок 1. Каскадная модель фреймворка антихрупкой ИТ-архитектуры Разберём каскад по уровням:Уровень 0. ДистанцииДистанции описывают фазы жизненного цикла относительно кибервторжения.Уровень 1. Цели («Чего хотим достичь»)Здесь выделяется семь стратегий. Это верхнеуровневые направления для достижения антихрупкости: например, «подготовка и прогнозирование», «адаптация и перестройка». Их цель — сформировать киберустойчивый каркас, дополнив классическую ИБ тем, чего часто не хватает в реальной атаке: связью с ИТ-архитектурой, непрерывностью, восстановлением, кризисным управлением и постоянным улучшением. Таблица 1. Семь стратегий антихрупкостиСтратегияВопрос, на который она отвечаетСистемное развитие и контрольРазвивается ли ИБ оправданно с точки зрения бизнеса?Подготовка и прогнозированиеПонимаем ли мы, как нас будут атаковать и какое звено сломается первым?Вовлечение и нападениеЗнаем ли мы, кто и как готовится нас атаковать — и можем ли перехватить инициативу?Защита, замедление, сдерживаниеЧто не даст атакующему быстро развить успех после проникновения?Обнаружение и реагированиеПоймём ли мы, что враг уже внутри, до того как он ударит?ВосстановлениеЕсть ли у бизнеса «План Б» на случай потери инфраструктуры?Адаптация и перестройкаСтанет ли компания сильнее после инцидента? Уровень 2. Правила реализации («Как себя ведём»)Здесь выделяется 10 принципов. Принципы связывают стратегии с действиями: это установки, задающие поведение. Например, принцип «нулевого доверия» или «безопасности по умолчанию». Уровень 3. Области применения («Где развиваем способности») Здесь выделяются 33 домена — тематические области, группирующие практики по функциональной принадлежности. Каждый домен описывает определённую способность организации. Уровень 4. Конкретные действия («Что делаем»)Здесь выделяется 390+ практик. Практики — конкретные меры и действия, которые организация должна реализовать для достижения целей киберустойчивости. Рисунок 2. Распределение стратегий антихрупкости по четырём дистанциям Вышеописанная схема является интерактивной: кликнув на домен, можно ознакомиться с относящимися к нему практиками. Рисунок 3. Информация о входящих в домен «Обнаружение и реагирование» практиках Также можно использовать строку поиска для выделения интересующих вас практик. Рисунок 4. Результат поискового запроса Фреймворк можно выгрузить в виде файла формата XLS, в котором также представлен инструмент самооценки. Рисунок 5. Фрагмент фреймворка в формате XLS Индекс антихрупкостиИндекс антихрупкости — показатель, позволяющий оценить в процентном соотношении, насколько компания готова к «чёрным лебедям», т. е. труднопредсказуемым событиям. Индекс построен на базе фреймворка и отвечает на вопрос: способна ли компания пережить кибератаку, продолжать работу в её условиях и восстановиться после неё. Итог оценки — индекс антихрупкости от 0 до 100 %, разбор по направлениям защиты и сравнение с другими участниками индустрии. Отраслевой уровень обновляется автоматически по мере накопления ответов респондентов.Индекс не заменяет регуляторные оценки, а дополняет их в областях, которые проверяют реальную киберустойчивость: восстановление и непрерывность бизнеса, кризис-менеджмент, threat hunting, безопасная разработка, безопасность ИИ, отказоустойчивость, культура киберучений и другие. Разберём, как пользоваться инструментом оценки.Как проходит оценкаС сервисом можно ознакомиться на официальном сайте. Вы отвечаете на сто коротких вопросов о том, какие практики киберустойчивости есть в компании. Оценка полностью анонимна: контактные данные и название компании не запрашиваются. У каждой оценки есть только уникальный идентификатор — он понадобится, если вы захотите задать вопрос по полученным результатам. Рисунок 6. Расчёт Индекса антихрупкости (приветственное окно) Заполнение профиля компанииДля получения оценок, релевантных профилю вашей организации, необходимо указать параметры из выпадающего списка: Сфера деятельности компании.Общее количество сотрудников.Число ИБ-сотрудников.Число ИТ-сотрудников.Оценку формирует руководитель ИБ или тот, кто отвечает за информационную безопасность в компании. Часть вопросов затрагивает смежные зоны — резервное копирование, непрерывность бизнеса, безопасную разработку, взаимодействие с юристами и PR. Если по ним нет уверенности, лучше уточнить у коллег: точность ответов напрямую определяет пользу результата. Рисунок 7. Пример заполненного профиля организации Заполнив все поля, можно переходить к следующему шагу. Для этого нажмите кнопку «Посмотреть показатели по отрасли».Построение бенчмаркаВ следующем разделе нам становится доступен бенчмарк, отражающий индекс антихрупкости и оценку в разрезе стратегий антихрупкой ИТ-архитектуры в среднем по отрасли. В качестве примера мы выбрали сферу деятельности «финансовый сектор». Рисунок 8. Экспресс-оценка показателей киберустойчивости по отрасли Ниже приводится оценка по стратегиям в табличном виде. Рисунок 9. Индекс антихрупкости в разрезе стратегий и практик по отрасли Прохождение опросаДля расчёта своего индекса антихрупкости пользователю предлагается пройти опрос по 100 практикам, каждая из которых имеет пять вариантов ответа:«Да» (выполняется системно).«Частично» (с ограниченным охватом).«Нет» (не выполняется или выполняется ad hoc, т. е. разово или под конкретную задачу).«Неприменимо» (не используется в организациях данного типа). Этот ответ следует выбрать, если, например, в организации нет такого процесса или системы. При выборе этого варианта метрика исключается из расчёта.«Не знаю» (затрудняюсь оценить). Метрика исключается из расчёта. Рисунок 10. Опрос в рамках стратегий и практик Результат отображается сразу после ответа на последний вопрос. Для расчёта индекса необходимо выбрать «Показать результаты». В том случае, если не все практики были оценены, появится окно с предупреждением и расчёт будет проведён с ограничениями. Рисунок 11. Предупреждение пользователя Оценка результатовНа вкладке «Результаты» отображается текущий уровень киберустойчивости организации, а также сопоставление этого уровня с показателями по отрасли в виде шкалы и радарной диаграммы («диаграммы-паука»). Рисунок 12. Экспресс-оценка киберустойчивости в виде шкал Рисунок 13. Экспресс-оценка киберустойчивости в разрезе стратегий При сравнении учитываются только критерии, по которым даны ответы. Ознакомиться с ними можно ниже в табличном виде. Рисунок 14. Оценка антихрупкости в разрезе доменов — групп практик Информацию по экспресс-оценке киберустойчивости организации можно скачать в виде готового отчёта. Он доступен в формате PDF и представляет собой готовый буклет для ознакомления в электронном виде или печати на бумаге. Рисунок 15. Выгрузка готового отчёта Рисунок 16. Фрагмент отчёта экспресс-оценки киберустойчивости организации ВыводыАнтихрупкость сегодня — ключевая стратегия выживания и роста компаний в условиях постоянных рисков: кибератак, ухода вендоров, сбоев инфраструктуры, регуляторных изменений и т. п. Она не заменяет классическую ИБ — она дополняет её способностью пережить успешную атаку.В современном ИТ‑ландшафте недостаточно просто держаться на плаву, нужно заранее готовиться к тому, чего нельзя предсказать. Именно поэтому антихрупкость становится центральным элементом зрелой ИТ‑стратегии и обязательным ориентиром при проектировании архитектуры, управлении инцидентами и планировании цифровой трансформации.Компания «Инфосистемы Джет» переводит концепцию антихрупкости на язык конкретных инженерных и управленческих решений. Она даёт бизнесу рабочие инструменты — собственный Фреймворк антихрупкой ИТ‑архитектуры, помогающий выстроить понятный путь от стратегии к конкретным действиям, и Индекс антихрупкости, который помогает увидеть, насколько компания реально готова к сбоям, атакам и внезапным переменам.Компания планирует и далее развивать Фреймворк: адаптировать его к специфике различных отраслей, разработать вариативные сценарии применения в зависимости от контекста.Достоинства:Открытая методология, доступная любому пользователю без оплаты и регистрации.Каскадная, понятная архитектура с чёткой логикой: семь стратегий достижения антихрупкости, 10 принципов, 33 домена и 390+ практик.Наличие веб-сервиса для оценки антихрупкости ИТ-архитектуры, в котором прохождение полного опроса по 100 критериям оценки занимает в среднем 20 минут.Возможность ознакомиться с показателями антихрупкости в среднем по отрасли.Представление результатов оценки в графическом и табличном формате.Формирование готового отчёта по итогам экспресс-оценки киберустойчивости с возможностью его выгрузки на компьютер.Недостатки:Ценность фреймворка сложно понять, если предварительно не ознакомиться с теорией антихрупкой ИТ-архитектуры.Для точной оценки индекса антихрупкости рекомендуется располагать полной информацией о деятельности компании и не пропускать ни одного критерия оценки. По уровню детализации Фреймворк антихрупкой ИТ-архитектуры относится к стратегическому и методическому уровню. Детальные технические регламенты, архитектурные стандарты, требования к настройке конкретных систем должны разрабатываться на следующем уровне детализации.Читать далее
    • demkd
      возможность есть, гляну, размер переменных окружения действительно 32767 максимум, но конкретно path больше 4095 это уже может стать проблемой.
    • Ego Dekker
      ESET Online Scanner 4.0.1  (Windows 10/11, 64-разрядная)
                                                                                  ●
              Руководство пользователя ESET Online Scanner 4  (PDF-файл)
×