Криптография, PKI и зоны безопасности

Запись у нас пошла. Сегодня у нас с вами 3 октября 2017 года, мы с вами на курсе IINS TR 0, 2 день курса, первый модуль. Мы продолжаем с вами говорить про основы сетевой безопасности. Мы вчера проговорили про много всего, на самом деле очень большой пласт знаний разобрали: про классификацию всего на свете поговорили — активы, угрозы, уязвимости, меры противодействия. Давайте кратко, сейчас очень кратко пробежимся по тем технологиям, которые существуют у нас для защиты от всяческих угроз. Эти технологии появились не вчера. Всё, что мы рассматриваем на этом курсе,

появилось достаточно давно, но я бы сказал, как я наблюдаю, наверное, в последние 10 лет продукты безопасности стали развиваться намного быстрее, чем в предыдущие годы. Если раньше firewall представлял собой обычные пакетные фильтры, то сейчас firewall — это уже такие монструозные вещи, включающие в себя всё на свете. Кратко пробежимся. Первое — firewall. Классический firewall, как я сейчас уже сказал, раньше был просто пакетным фильтром, который ничего, кроме обработки одиночных пакетов, не делал. Понятие firewall заключается именно в пакетной обработке. Я говорю про классический firewall. Мы дальше будем говорить про firewall NG — next generation,

следующего поколения, там уже комбайны. А когда мы говорим просто firewall, здесь, конечно, в первую очередь имеется в виду пакетный фильтр, который обрабатывает пакеты, либо может быть цепочки пакетов в некоторых случаях, которые работают с сохранением состояния — они смотрят, например, на сессии TCP и имеют это в виду. Firewall могут работать совместно, например, с NAT, чтобы также смотреть на состояние NAT. Вот это и есть firewall — это просто фильтры, которые стоят обычно на границах каких-то сегментов и занимаются пакетной фильтрацией. IPS/IDS — по большей части это почти одно и то же, мы с вами тоже будем про это говорить довольно подробно. IPS/IDS — в чём

различие? IPS — Intrusion Prevention System, а IDS — Intrusion Detection System, то есть система обнаружения угроз (IDS) либо система предотвращения угроз (IPS). Эти системы занимаются уже глубоким анализом трафика — так называемый DPI. Если вы видите такую аббревиатуру, я сейчас в чатик напишу: DPI — Deep Packet Inspection, глубокое инспектирование пакетов. Если вы это видите, скорее всего речь идёт про технологии IPS/IDS. Эти устройства — не обязательно железное устройство, может быть программное, неважно — занимаются глубокой инспекцией трафика вплоть до седьмого уровня, а иногда и до восьмого. В некоторых случаях в военное время, как вы понимаете, может доходить и до девятого уровня — это сейчас шутка была, не надо меня поправлять в чате. Эти устройства осуществляют очень

интеллектуальную фильтрацию трафика. Ещё раз: IDS — это устройство, которое просто занимается обнаружением, а IPS вдобавок к обнаружению какого-то вредоносного трафика ещё и фильтрует. Дальше — устройства контентной защиты. В настоящее время их развелось огромное количество, у каждого производителя, у каждого вендора есть какие-то свои устройства защиты контента. Здесь имеются в виду устройства, которые работают с конкретными протоколами. Например, вот здесь как пример у нас написано Cisco ESA и WSA — это Email Security Appliance и Web Security Appliance. Контентная защита — эти устройства будут работать с совершенно конкретными протоколами. Например, антиспам — прекрасный пример устройства или

программы именно контентной защиты, которая работает только с почтовым трафиком, занимается своим делом, фильтрует спам, может быть в каких-то случаях фильтрует вирусы. То же самое Cisco WSA или похожее устройство, которое занимается веб-фильтрацией — фильтрация по всяким URL, по нехорошим спискам сайтов и так далее. Это контентная фильтрация. Дальше — VPN. VPN — это тоже технология защиты от угроз, хотя люди, которые не занимаются безопасностью, часто говорят, что VPN — это в принципе не защита никакая. Ну как же не защита? VPN обеспечивает — сейчас вы мне должны подсказать — что она обеспечивает? Конфиденциальность, конечно, в первую очередь. И кстати, все три буквы может обеспечивать. VPN — это самый настоящий

инструмент защиты от угроз. Про VPN с вами будет разговор, и я думаю, что разговор будет обстоятельный. Для CCNA Security, для нашего уровня это будет интересно. Endpoint security — это класс технологий, которые работают на конечных хостах. Если всё, что мы видели в списке выше, у нас может работать в сети, то endpoint security — это программные решения, которые будут работать на хостах. В первую очередь — антивирус, персональные firewall, которые либо встроены в операционную систему — iptables в Linux, либо Windows Firewall, anti-malware (дурацкое слово, но нормальное, просто мне как-то не очень хорошо звучит, не знаю почему, немецкое такое), либо firewall, либо антивирус, либо антиспам, встроенный в почтовую программу — всё это относится к классу программ endpoint security. Логирование —

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

разговор. Поехали дальше. Принципы построения защищённой сети. Мы с вами всё говорили про безопасность, про безопасность, про безопасность, пока ещё мало обращались именно к сетевой безопасности. Сейчас будем говорить уже про сеть. Здесь я бы даже сказал шире — про инфраструктуру какого-либо предприятия или организации. Ниже перечисленные принципы очень важны, когда мы с вами проектируем либо настраиваем уже после проектирования сеть на предприятии, и вот этим заповедям надо следовать. Если мы забываем о каком-то из этих принципов, то получается в результате не очень хорошо. В нормальной, идеальной ситуации каждый из этих принципов должен применяться в живой

сети, в обеспечении безопасности инфраструктуры. Давайте по порядку. Откуда они? Глеб, я честно не могу сказать, откуда вот эти все принципы. Я знаю, откуда появились понятия, но не могу сказать, откуда взят этот список. Понятно, что это опыт — сын ошибок трудных. Конкретный этот список — мне не знаком стандарт, в котором он фигурирует, но я думаю, что он где-то фигурирует точно. Кое-что из рекомендаций NIST, кое-что из стандарта ISO. Мы про стандарты ISO чуть попозже поговорим с вами тоже, там описываются некоторые вещи. Но этот список хорош, поверьте

мне, просто надо его разобрать. Мы с вами чуть про это поговорим. Мы вчера тоже упоминали принцип эшелонированной защиты — defense in depth. Наверное, самый важный принцип. Помните, мы вчера говорили про то, что «у меня есть фаервол, мне больше ничего не надо»? На самом деле, я сказал, что это полная ерунда, и защита сети, защита инфраструктуры должна осуществляться на каждом из доступных уровней. На уровне — если даже взять нашу сетевую модель, то пусть на каждом из уровней сети — она уже оправдана. Защищайте уровень приложения, и канальный уровень по-своему следует защищать, и сетевой уровень тоже нуждается в своей защите. Если посмотреть шире, за пределы только сети, мы с вами говорили про endpoint security, защиту рабочих станций, и дальше — физическая защита. Нельзя

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

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

при каком-то более-менее серьёзном росте это обособление, это сегментирование просто необходимо. Его надо закладывать в проектирование с самого начала. Даже если у нас стоит в комнате три компьютера — Вася, Коля и Петя — они уже сидят в разных сегментах, потому что они обозначают собой разные структурные подразделения. Пусть даже в таком масштабе, но уже можно как-то сегментировать сеть, и потом, при росте, когда Вася, Коля и Петя станут большими начальниками и под их начальством будет по тысяче человек, это очень сильно пригодится. Принцип минимальных привилегий — говорит само за себя название. Здесь главный смысл в том, что не нужно давать пользователю или системе — я буду говорить «пользователь», на самом деле пользователем может быть приложение или другая система, неважно — не нужно давать пользователю привилегий больше, чем ему нужно,

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

то это будут не мои проблемы, это будут проблемы компании. Я лучше сделаю так, чтобы он не смог его удалить никогда, я не дам ему таких прав. Зачем? Минимальные привилегии должны быть. То же самое касается администраторов. Если в компании много администраторов, много технического персонала, у каждого из пользователей должны быть только те привилегии, которые ему нужны. Намного проще расширить привилегии какому-то пользователю, дать ещё какие-то права, чем их отобрать. Отбирать привилегии, отбирать права — это сложно, поверьте. Проще дать, выдать кому-то права. А если сразу назначить полные привилегии всем, пусть даже сначала доверенным пользователям, а потом отобрать — может быть даже невозможно. Так что имейте в виду. Принцип самого слабого

звена. Олег правильно сказал: у админа должны быть две учётки — одна с максимумом прав, другая админская. Ну в принципе да. Сюда же можно отнести утверждение — если кто-то работает с Unix-системами — там есть пользователь root, и есть очень правильное утверждение: никогда не работайте из-под пользователя root. Никогда ничего из-под этого пользователя не делайте, потому что каждая ошибка иногда приводит к катастрофе. Это опять же про это — потому что rm -rf и так далее. Принцип самого слабого звена звучит примерно так: уровень безопасности вашей системы будет равняться уровню самого слабого звена. Вы можете выбить у начальства кучу денег,

огромное количество денег, защитить периметр сети самыми классными, дорогими фаерволами, натыкать везде IPS, IDS поставить между сегментами, всё-всё-всё сделать, поставить крутые персональные антивирусы и всё. Но потом, когда придёт ребёнок генерального директора со своим непонятно каким ноутбуком и воткнётся в вашу сеть, чтобы в ВКонтакте зайти, — в этот момент защищённость вашей сети будет равняться вот этому самому ноутбуку ребёнка. Всё остальное, на что вы тратили деньги в последние годы и защищали вашу сеть, не имеет никакого значения, потому что у вас появилось слабое звено — вот этот самый ноутбук. Ну это как пример. Либо какой-то коммутатор непонятный — поставили времянку, надо было побыстрому

два провода бросить, или три провода, не хватает кабелей, давайте D-Link воткнём сейчас трёхпортовый, пока нормальный кабель не протянули, по-быстрому. И забыли про него. И вот он год стоит, два года стоит, три года стоит — вот это самое слабое звено. И на самом деле все остальные ваши усилия по безопасности будут просто бесполезны, потому что безопасность вашей сети будет на уровне вот этого самого D-Link. Ну, я не хочу обижать фирму D-Link, хорошая фирма. Ну к примеру, кто ещё маленькие коммутаторы делает. Поэтому это тоже очень важно понимать. Разделение и ротация обязанностей. Разделение обязанностей — мы ещё проект не говорим, я думаю, что вы все это прекрасно понимаете. Когда на предприятии, в организации есть штат административного персонала больше одного человека — это очень часто бывает, вы

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

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

порядке вещей. Но лучше как-то — бизнес тоже... Андрей говорил, что с директором тяжело спорить. Нас это нужно делать, нужно постоянно с бизнесом спорить в нормальном, позитивном ключе и постоянно объяснять, на что тратятся их деньги и почему всё-таки деньги эти нужны IT. Но это не тема нашего курса — как выбить деньги из начальства, я думаю, что есть отдельный курс. Вы меня понимаете, не будем на этом заострять внимание. Посреднический доступ. Посреднический доступ здесь объяснить очень просто. Хорошо было бы, когда в организации существует какая-то система управления доступом. Мы сейчас говорим про

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

важная штука. Отчётность и non-repudiation. Слово non-repudiation осталось в слайде не переведённым по той простой причине, что я тоже не знаю, как его перевести, и тот, кто редактировал слайды, тоже его не стал переводить. Я так понимаю, можно его перевести как «неотказуемость» — вот такой перевод даёт Google. Я сейчас объясню, что это такое. С отчётностью всё понятно — есть accounting, так называемый, тоже дисциплина, про неё тоже будет несколько слов. Отчёт о действиях пользователей в сети должен вестись, должна эта статистика куда-то собираться, обрабатываться. Что такое non-repudiation? Non-repudiation — это, если простыми словами сказать, когда вы не можете отмазаться от совершённого действия, не можете от него никаким образом

отказаться. Как приходите в банк, ставите подпись, и с вашего счёта снимают 1000 долларов, и потом вы не можете сказать «это не я, я ничего не подписывал» — тебе говорят: «Вот твоя подпись». Вот это non-repudiation — это когда невозможно отказаться от совершённых действий. Эта самая отчётность — когда, например, любое действие администратора на коммутаторе, всё, что он там конфигурирует, всё это записывается, и потом всегда можно предъявить ему то, что он что-то делал. Разница с логированием: логирование — это просто запись чего-либо. Смотрите: logging, журналирование — это запись событий, которые происходят на устройстве,

неважно каких, просто событий, которые происходят. Отчётность, accounting, про который будем говорить — это именно запись действий пользователей. Не то, что порт поднялся на коммутаторе, или OSPF у нас сошёлся — это всё попадает в логи. А вот accounting — это то, что делают администраторы на железе, например. Вот эта разница. Отчётность, accounting... Non-repudiation — это не подмножество logging. Logging — это просто техника записи сообщений. Accounting — это техника записи действий администратора. А non-repudiation — это не техника, это просто понятие, я не знаю, как перевести его на русский язык. Это концепция, это просто понятие, что вы не можете отказаться от совершённых действий. Достигается это с помощью отчётности. Мы с вами ведём какую-то

отчётность, и благодаря этой отчётности есть такое понятие, как non-repudiation — невозможность отозвать свои действия и отказаться от них. Вот такое интересное слово. Оно нередко встречается именно в источниках по безопасности. Мы будем про VPN говорить, когда там тоже будет этот non-repudiation — везде, где про цифровые подписи, везде она фигурирует. В англоязычных источниках вы его не раз ещё встретите, я уверен. Ну и третий — последний принцип в этом списке — это безопасность как процесс. Мы вчера с вами тоже про это говорили, когда мы говорили про политику безопасности: безопасность — это именно процесс, это не единичное действие, когда всё настроили, всё засекьюрили, всё у нас отлично, и мы можем расслабиться. Это процесс, он непрерывный, и

по-хорошему он не должен прерываться никогда. Да, Роман правильно сказал: положил uplink — безопасники увидели, что ты вводил команды — вот и всё, non-repudiation, ты отмазаться уже от этого не можешь. Вот такие принципы построения защищённой сети существуют. Я думаю, что мы собрали здесь самые основные принципы, без которых, наверное, безопасностью даже не стоит заниматься. Это нужно знать и нужно всё время держать в голове. Управление рисками — немножечко такая тема, может не то, что она мутная, она очень обширная. Вообще управление рисками — если кто-то учился в институте, связанном с экономикой, они знают, что огромные курсы читаются по этим дисциплинам.

Управление рисками — это целая отрасль, это не просто какой-то предмет в институте, это действительно целая отрасль, и огромное количество людей в этом заняты, и там творится космос отдельно совершенно. Но мы с вами просто проговорим, чтобы понимать вообще, что это такое, чтобы когда мы слышим «управление рисками», мы хоть примерно представляли себе эту область. Управление рисками — главная задача — это оценить влияние каждой конкретной угрозы. Мы про свою говорим контору — про сетевую безопасность. В нашем случае главная задача управления рисками — это оценить влияние угрозы на наши активы. Угроза направлена на активы. Есть два основных подхода к оценке рисков: количественный и качественный. Сразу скажу, что чаще в сетевой безопасности — я не буду говорить про

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

Зачем нужно оценивать риски? Про математическое ожидание потерь мы с вами немножко поговорили — что именно это математическое ожидание потерь. Деньги не сравниваются, Глеб, с качествами. Как деньги сравнивать с качеством? Никак. У нас есть качественный подход — здесь про деньги. Понятно, что потом всё можно выразить в деньгах в бизнесе. Здесь имеется в виду, что... Здесь имеется в виду, что мы будем считать конкретное время. Например, время простоя — вот что такое посчитать время простоя — это количественный подход. Мы будем считать какие-то совершенно конкретные цифры. А вот качественный подход — это когда собираются руководители предприятия и говорят: «А давайте посмотрим, у кого чей отдел самый важный. Кого мы будем в первую очередь защищать. Кто из нас самый

ценный сотрудник. У кого самое ценное направление». И, конечно, все встают и говорят: «Ну конечно же я». Главбух говорит: «Ну конечно же я. У меня три печати в столе». Генеральный директор говорит: «Да ты что, старуха». А потом встаёт начальник отдела продаж и говорит: «Ребята, конечно же я. Самое важное. Я деньги приношу». Ну, как они думают, продажники? Они же думают, что они деньги приносят. Ну вот. Да, Глеб правильно говорит: качественный подход — он такой, более абстрактный. Ну, как я понимаю. Я ещё раз говорю, я не специалист в оценке рисков. Это не моя прямая специальность, не моя работа. Зачем нужно оценивать риски? Прежде всего надо понять отношение ожидания потерь к стоимости защиты.

Мы должны понимать, сколько стоят наши активы. Мы вчера про активы говорили. Мы должны понимать, сколько мы можем потратить. Нет смысла тратить больше, чем стоят наши активы. Действительно. Нет смысла тратить больше, чем мы вообще можем потерять. Здесь про потери говорится. Мы посчитали, что если вдруг нас взломают, мы потеряем миллион рублей. Давайте больше миллиона рублей мы не будем тратить на наш фаервол. Вот такими вещами надо оперировать. Мы примерно прикинули, посчитали, что если у нас упадёт веб-сервер, мы не будем... 10 минут мы не сможем работать с нашим внутренним порталом. 10 минут мы не можем работать. И садится экономист и говорит, что за 10 минут компания потеряет 500 миллионов долларов. Давайте не будем тратить на защиту больше 500 миллионов долларов.

Вот такой должен быть подход. Определение уровня стресса от потери. Надо понимать, насколько наши потери затронут нашу компанию. При определённых величинах убытков где-то уже некоторые меры противодействия просто недопустимы. Мы про это ещё раз говорим. Если получается так, что убытков мы никаких не несём, даже если всё будет плохо, если у нас всё упадёт, всё сломается, а тратим на это огромное количество денег — это недопустимо. А зачем ещё нужно оценивать риски? Чтобы обосновывать затраты на оборудование, ПО. Затраты всегда должны быть обоснованы. И в то же время это даёт понимание, где нужно сосредоточить ресурсы для защиты. Пока мы не начнем считать, сколько стоят активы, какие у нас есть риски, направленные на эти активы,

мы не будем понимать, что нужно защищать в первую очередь. Что нужно защищать во вторую очередь. Где нужно посерьезнее отнестись к защите, а где не очень. До тех пор, пока активы не оценены — здесь в первую очередь про активы говорится. Пока активы не оценены, во вторую очередь пока риски, которые применяются к этим активам, тоже никак не оценены, сложно понять, куда всё-таки вкладывать деньги, где строить безопасность. Количественная оценка рисков. Давайте не будем прямо разбирать эти формулы. Если хотите, конечно, мы сейчас про них поговорим очень подробно. На самом деле эти формулы очень простые. Это один из миллионов примеров, которые можно придумать для оценки рисков. Вообще, как правило, есть такое понятие — это оценка ожидаемых потерь за год.

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

на следующий год на безопасность мы не выделяем. Считается, в принципе, очень просто. У нас есть asset value. Вам видно, как я рисую? Да, должно быть видно на экране. Мера риска — это стоимость актива, который мы потеряем при наступлении какого-то события. Например, если нам затопит серверную, мы потеряем стойку с серверами, которая стоит 100 тысяч долларов. К примеру. Потом есть такой фактор вероятности. Какова вероятность того, что у нас затопит серверную? Серверная у нас находится в центре здания, до крыши ещё пять этажей. Фактор у нас — если только цунами будет — 0,001%. Или наоборот, у нас серверная в подвале, который нам выделили по остаточному принципу.

И вполне вероятно, что в средней полосе России осенью идут сильные дожди, и, может быть, этой осенью нас затопит. Мы можем вывести какую-то вероятность этого события. И, соответственно, мы можем, просто перемножив это — это событие может случиться один раз в год. Например, затопление серверной. И в таком случае мы с вами потеряем 100 тысяч долларов. И мы с вами понимаем, что ожидание потери от единичного события составляет 100 тысяч долларов. Если мы прикидываем, что мы живём в Юго-Восточной Азии, где какой-нибудь сезон дождей, то можно представить, что серверную затопит несколько раз. Надо просто умножить эту цифру и всё. А дальше посчитать, сколько за год у нас получится. Формулы, на самом деле, очень простые,

но это просто пример, как можно посчитать риски. Не надо эти формулы брать за какую-то истину в последней инстанции. Я думаю, если вы откроете какой-нибудь учебник для институтов, где учатся экономисты, там будут намного более интересные формулы и намного более реалистичные. Хотя это тоже можно как реальность принимать. И может быть даже можно работать с этими формулами. Я не пробовал, честно. Требования регуляторов. Тема тоже неисчерпаемая. Мы с вами говорили про то, кто такие регуляторы. Это может быть государство. Это могут быть какие-то авторитетные организации, например, международные организации, которые могут от вас что-то потребовать.

Регуляторы могут требовать. Это нормально, когда кто-то от вас что-то требует. Мы все работаем в государстве. Государство имеет свои законы. Есть какие-то отраслевые стандарты, международные стандарты. В двух словах расскажу про те стандарты, которые есть в безопасности. На самом деле их больше. Но вот эти стандарты основные. Я думаю, что их стоит даже запомнить, просто потому что вдруг на экзамене спросят. Про российские точно на экзамене спросят. А про эти могут запросто. Самый основной стандарт, с которого всё пошло, это стандарт BS 7799.1. Это британский стандарт. В этом стандарте — этот документ такой очень увесистый, в нём, по-моему, 120 с чем-то механизмов контроля,

которые нужны для построения защищённых систем. И этот стандарт был выпущен давно. Он был выпущен в 2000 году. Это британский стандарт. Британский институт стандартов выпускал. Вторая версия была представлена в 99-м году. 7799-2. Вот самый главный британский стандарт, по которому работают многие организации, не только в Великобритании. PCI DSS. PCI DSS — я думаю, вы слышали, если кто-то из вас работает в сфере, связанной с финансами, то этот стандарт точно должны знать. Payment Card Industry Data Security Standard. Это стандарт безопасности данных, который принят в индустрии платежных карт.

Он был разработан платёжными системами Visa, MasterCard. По-моему, в середине 2000-х, может быть, раньше. Я думаю, что в Википедии каждый из нас может посмотреть. По-моему, в 2005-м или 2006-м году. Это тоже стандарт, на который не то что должны ориентироваться — смотрите, мы можем сказать, что в политике безопасности мы ориентируемся на этот стандарт. А можно сказать так, что этот стандарт обязателен к исполнению. Требования регуляторов — здесь говорится про то, что эти стандарты обязательны к исполнению. Например, тот же самый PCI DSS: если вы работаете в финансовой организации, вы обслуживаете банковские карты, то вы обязаны его соблюдать. Это не рекомендация, это стандарт.

Дальше. ISO 17799, 27001, 27002, 27003. Наверное, основной будет стандарт ISO 17799, он в 2005-м году был. Это организация ISO международная. Если знаете такую организацию — это международная организация по стандартизации. Его развитие — это как раз серия 2700. В этом стандарте, так же как и в британском стандарте, который у нас самый первый в списке, здесь тоже собрали так называемый best practice, самые лучшие технологии, самые лучшие рекомендации, которые обязательны к исполнению, и по этому стандарту живёт очень много организаций. В нём рассказывается и про то, как должна составляться политика безопасности.

Организация информационной безопасности, про управление активами, про безопасность персонала, про физическую безопасность, про коммуникации, про управление доступом — access-контроль, про управление инцидентами — тоже в этом стандарте есть. Этот стандарт — он такой самый объёмный, который всё-таки нужно изучать. И на основе этого стандарта был сделан — он просто переведён — наш ГОСТ Р ИСО/МЭК. Спасибо, Роман, написал про 2700. Наш ГОСТ — это на самом деле просто перевод этого стандарта, даже не адаптация, а перевод. Он у нас тоже работает. Стоит сказать ещё про 152-й федеральный закон.

Те, кто работает у нас в России, прекрасно про него знают. Это закон о персональных данных. Он был принят в июле 2006 года, наделал немало шума в своё время. До сих пор есть много споров вокруг этого закона, до сих пор много сопротивления, но на самом деле закон нужный. Я не буду ни критиковать его, ни что-либо — у всех своё отношение к работе с персональными данными. Просто надо знать, что есть такой закон 152-й, в него внесены изменения другими законами, например, 363-й, который скандальный, который всех операторов обязывает хранить эти персональные данные. Там очень сложная структура.

Мы должны просто помнить, что 152-й закон в России есть и исполнение его обязательно. Конечно, мы работаем — вот я работаю, и в нашей компании, многие из ваших компаний — в российской юрисдикции. Это требование регуляторов. Так что прежде чем делать какие-то действия, например, писать политику безопасности, неплохо было бы ознакомиться с этими стандартами — в первую очередь международными — и ознакомиться со стандартами своего государства. Это тоже важная вещь. Поехали дальше. Зона безопасности. Ещё одна концепция, с которой нам придётся подружиться. Эта концепция у нас с вами будет ещё обсуждаться дальше по курсу.

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

Не понятием интерфейсов. Например, представьте, что у вас есть роутер или фейервол, цискласса. У него есть 10 интерфейсов. Нам нужно написать какие-то правила безопасности между интерфейсами. Если описывать правила безопасности и то, как применяются политики между каждым интерфейсом, этим интерфейсом и этим, можно с ума сойти. Честно скажу. Это будет очень сложно, будет очень запутанно, даже применительно к одному единственному фейерволу. А если у нас устройств безопасности много, то будет очень сложно. С другой стороны, разделение на зоны упрощает управление безопасностью. Когда мы можем сказать, что эти 5 интерфейсов смотрят в одну зону, эти два интерфейса смотрят в другую зону. и уже писать

те же правила firewall не для каждой пары интерфейсов, не для каждого интерфейса, а просто спокойно писать их для каждой зоны. Это очень классно. Это действительно очень такая хорошая концепция, нужная концепция. Общепринятые термины, которые будут встречаться и в нашем курсе, вы их везде встречаете и будете встречаться. Когда мы говорим outside, inside, интернет, intranet, интернет или outside, мы обычно говорим, применительно к интернету, к внешней сети, которая за нашей границей, за нашим фаерволом. Intranet или inside, то, что находится внутри нашей организации, внутри нашей сети. Есть еще такое понятие Extranet. Оно используется нечасто, но вы его тоже можете встретить.

Extranet это доверенная сеть за пределами нашей организации, например. К примеру, у нас есть какая-то сеть, наше предприятие и есть клиенты нашего предприятия, с которыми у нас хорошие доверительные отношения, с которыми мы... Да, Роман, все правильно, делаем, например, сайту сайту VPN, устанавливаем какие-то каналы связи, и вот их сеть, она вроде бы не особо наша, не под нашим административным управлением, но она доверенная. Мы пользуемся серверами в их сети, они пользуются серверами в нашей сети, то есть почти наши. Вот это называется Extranet. Такой есть термин, который, но он общепринят, вы его тоже где-то можете встретить. Ну и DMZ, демилитаризованная зона, это та зона, где будут размещаться общедоступные сервисы, которые должны быть видны снаружи,

но которые нужно защищать как-то по-другому, не как inside intranet, а по каким-то своим правилам. Мы с вами про это тоже будем говорить дальше. Это что касается зон безопасности. Дальше. разговор про функциональные уровни сети. Скажите пожалуйста, вот эти data plane, control plane на сессии вы изучали или нет? Вообще на сессии обычно идет разговор в таком ключе. Хотя я честно не помню в учебнике по сессии в официальном руководстве описано именно так или нет. ну ладно, давайте просто проговорим все это. На CCNP конечно это есть. Давайте расскажу. В принципе каждая сеть состоит из трех составляющих. Не просто каждое

сетевое устройство, вообще сеть. Мы возьмем сеть совокупность каких-то устройств. роутеры, коммутаторы, фаерволы, что угодно. Все сетевые устройства имеют три уровня, на которых происходит работа этой сети, работа сетевых устройств. Data plane называется plane, плоскость, можно так перевести это слово. Data plane это плоскость данных, это передача трафика. То есть на этом уровне будет именно идти обработка пакетов, перекладывание их например на коммутаторах из одного порта, из одного интерфейса в другой интерфейс. Вот это Data Plane это как Иннокентий в свое время объяснял делалка. То есть то, что делает работу. Есть Control Plane. Control Plane это думалка, управляющая плоскость. Это то, что говорит Data Plane как ему делать свою работу.

Здесь идет обмен какой-то управляющей информацией. Прежде всего сигнализации например. Сигнализация здесь можно протокол динамической маршрутизации. Это что сигнализация. Роутеры друг другу рассказывают что куда какой трафик куда направлять. Вот это все Control Plane. Вот здесь сосредоточена мозг самой главной сети. То есть например даже если вы будете дальше заниматься и например разбирать тему киос управления обслуживанием то вот Control Plane протоколы Control Plane например ну например протоколы маршрутизации они всегда имеют наивысший приоритет в сети даже когда вот устанавливаются какие-то приоритеты когда вы говорите что вот этот трафик более важный этот трафик менее важный вот

трафик Control Plane он считается самым важным даже ну можно сказать что важнее чем третья плоскость мы сейчас про это поговорим важнее чем административная потому что без Control Plane просто ничего просто работать ничего не будет сетевые устройства не буду знать как им передавать трафик это Control Plane есть еще Management Plane это административная плоскость здесь как раз дает ходит трафик который нужен для доступа к самим устройством всякие телнеты SSH вот это все Management Plane это трафик именно Management Plane и каждый уровень вот этот нужно защищать отдельно нужно это очень очень четко понимать и очень четко представлять мы все время разбиваем все классифицируем вот здесь на нашем курсе здесь тоже нужно четко классифицировать

что каждый уровень нуждаются в своей защите в отдельной защите то что применимо для Data Plane это как бы Control Plane мало имеет отношения и вот смотрите для Data Plane у нас есть Firewall у нас есть IPS есть VPN есть Content Security то есть то что будет фильтровать наши пакетики например фильтровать содержимое протоколов то есть вот этот самый боевой трафик собственно ради чего все это и затевается ради этого трафика боевого который фильтрует который вот работает на Data Plane на Data Plane нужно защищать по-своему Control Plane здесь свои механизмы есть встроенная защита протоколов мд5 есть специальный курс на том же ccna кстати простите меня пожалуйста я плохо помню курс ccna

поэтому я вас все время спрашиваю вы на нем были многие недавно вот Control Plane встроенная защита протоколов мд5 есть специальные механизмы для защиты control plane это вот вот вот вот вот вот вот это вот вот вот это ограничение например трафика который идет вот именно Control Plane это свои отдельные механизмы которые никаким образом с Data Plane пересекаться не будут например если ну как сказать Firewall мало спасет нас от поддельного сообщения о SPF скажем так или от поддельного сообщения там не знаю если с HRP вот

то есть Firewall работает на Data Plane он фильтрует пакет а вот чтобы за застраховаться от поддельных сообщений там из HRP у SPF например то нам нужно использовать другие механизмы вот именно на Control Plane вопрос есть на экзамене на сессийной security Роман да да да мы мы про это поговорим я не знаю насколько подробно но я объясню обязательно что это такое и seo pp и cpp мы про это обязательно поговорим потому что на экзамене но я думаю что встретиться это важная вещь конечно и есть еще Management Plane это именно управление нашими устройствами здесь тоже нужна своя защита тот же самый ааа мы про аааа будем разговаривать это очень интересный разговор я очень люблю эту тему это аааа это аутентификация авторизации и аккаунтинг те же самые

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

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

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

можно обеспечить ту самую конфиденциальность, про которую мы с вами говорили. Помните CIA triad? Вот это самое. Обеспечивается целостность тоже с помощью криптографии. Мы говорили про то, что целостность важна. Про доступность здесь речь не идёт, потому что доступность криптография не может обеспечить, доступность обеспечивается другими методами. Плюс к этим двум основным задачам криптография обеспечивает аутентификацию источника, с помощью некоторых криптографических инструментов мы можем убедиться, что источник — тот, за кого себя выдаёт. Это очень важная вещь — аутентификация. И тот самый non- repudiation, про который мы с вами говорили. Я уже переводить этот термин не буду. Это тоже можно обеспечить с помощью криптографических инструментов. В криптографии,

в нашей криптографии, будут два главных инструмента — это шифрование и хеширование. Слово «хеширование» на русский язык не переводится вообще. Вы понимаете, вы все были на сессии, что на русский язык тоже переводить всю программу курса невозможно и не нужно. Зачем всё переводить на русский? Шифрование отличается от хеширования — это два разных инструмента, это две разные математические сущности. Мы сейчас поговорим чуть попозже про это, чем они отличаются, но это разные вещи. Нельзя говорить, что шифрование и хэширование — одно и то же. Хотя можно сказать так, что хэширование — частный случай шифрования. Можно и так сказать, с натяжкой. Пару слов о криптоанализе. Мы с вами говорили уже вчера, когда было слово

«компрометация», и я говорил, что скомпрометированные данные — это не те данные, которые получены в результате криптоанализа. Криптоанализ — это целая наука, целая область науки, которая занимается расшифровкой информации. Скажем так, это очень упрощённое, но думаю точное определение — именно расшифровкой того, что было зашифровано. Это и есть криптоанализ. Шифрование — что такое шифрование? Шифрование — это изменение информации так, чтобы её не прочитали те, кто к ней доступа иметь не должен. Шифрование — сейчас у нас про хэширование дальше будет, чем хэширование отличается, позже расскажу.

Шифрование — просто изменение той самой информации. Самое главное то, что шифрование всегда обратимое, оно двустороннее. То, что мы зашифровали, можно расшифровать. Забегая вперёд скажу, что есть хэширование — это одностороннее шифрование. Эти вещи нельзя путать. Хэширование — это функция, тоже математическая функция, которая принимает на вход какие-то данные, выплёвывает другие данные, и то, что она выплюнула — этот шифр — его нельзя никак, как в мясорубке, прокрутить обратно фарш. Это хэширование, этим они отличаются. Шифрование — это всегда обратимый процесс, когда что-то мы изменили, зашифровали — можно расшифровать. Существует несколько видов шифров. Стоит сказать ещё, что обычно в шифровании применяется такая вещь, как ключ. Ключ — вещь

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

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

алгоритму символы просто переставляются, меняются местами, и в результате получается зашифрованное сообщение. Самый надёжный вид шифров считается — одноразовые блокноты. Концепция одноразовых блокнотов она довольно интересная. Я не очень хорошо знаком с историей криптографии, поэтому не могу сказать, когда это появилось, но просто нужно знать, что самое надёжное шифрование — это одноразовые блокноты. Когда у нас есть какой-то открытый текст, есть — мы так образно будем говорить — страница из блокнота, в ней столько же символов, сколько в этом тексте. Это вообще идеальный одноразовый блокнот — самый идеальный, когда у нас ключ равен тексту. Тогда это будет самое стойкое шифрование на свете. Есть какая-то страница из блокнота, она накладывается на наш открытый текст, и

получается зашифрованное сообщение. У другой стороны есть точно такая же страница из этого же самого блокнота, под копирку написана, с помощью которой этот кусок текста можно расшифровать. Всё, больше никогда и нигде эта страничка из блокнота не будет использоваться. Для новой порции текста будет использоваться новая страница из блокнота. Одноразовые блокноты — такие виды шифров самые надёжные считаются. Если кто-то очень хорошо понимает шифрование и криптографию — не обижайтесь на меня, что я говорю так мало, потому что совсем углубляться в эту тему нам не нужно. Поверьте, этого достаточно. Дальше — хэш-функции. Хэш-функция, как я уже сказал, — просто математическая функция. Здесь вся криптография — это чистая математика. Хэш-функция — это однонаправленный процесс, когда мы берём данные переменной длины, прогоняем эти данные через какую-то

математическую функцию. Что самое важное — результат всегда будет фиксированной длины. Мы можем взять один мегабайт файла текста, мы можем взять 10-гигабайтный файл — неважно, сколько этих данных, но на выходе мы всегда получим результат фиксированной длины, строку, вот такую небольшую, как правило, которая будет тоже являться своеобразным шифром. Это называется не шифр, это называется дайджест. Два хороших слова: дайджест, либо называют ещё fingerprint — отпечаток пальца. Либо даже в русских источниках очень часто называется «отпечаток». Если вы видите в каких-нибудь программах типа, не знаю, CryptoPro или где-то в русской версии Windows, когда смотришь сертификат, — тоже «отпечаток». Вот это слово используется. Это

результат именно хэш-функции. Используется для контроля целостности в первую очередь и для аутентификации. Мы сейчас с вами будем рассматривать, как это всё работает, как с помощью такой достаточно простой функции можно и контролировать целостность, либо аутентифицировать. Это очень интересная штука. Стоит упомянуть — даже не стоит, необходимо сказать про avalanche-эффект. Есть такой эффект. Avalanche — это с английского «лавина», «камнепад», когда что-то падает большое. Эффект очень простой: данные, которые принимаются на вход, которые дали нам хэш, при изменении

хотя бы одного бита в этих данных, при малейших изменениях в этих данных, полученный дайджест, полученный отпечаток будет изменяться очень кардинально, очень сильно. Не так, например, что мы взяли, не знаю, даже маленькое значение на вход — берём 512 байт, взяли один бит, поменяли, и потом раз — у нас в дайджесте тоже один битик перевернулся. Нет, здесь так не будет. Здесь как раз хэш-функции подобраны и спроектированы таким образом, что они дают этот самый avalanche-эффект: при изменении хотя бы одного бита вы получите совершенно другой отпечаток, совершенно другой результат. Этим хэш- функции и хороши — что очень сложно понять, что же поменялось в исходном

тексте. По хэшу, по дайджесту невозможно догадаться. Мы сейчас поговорим про то, как можно пытаться догадываться. Невозможно догадаться, что же изменилось в исходном тексте. Это очень классные вещи. Что ещё сказать про хэш-функции, чем они ценны? Я так и сказал, что даже при малейшем изменении будут совершенно разные отпечатки. Даже если два файла отличаются всего лишь на один бит, то результаты у них будут совершенно точно разные. Хотя есть исключение — эти исключения называются коллизии. Бывает так, что два разных

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

хранить в хэшах — это нормальная общепринятая практика, потому что нельзя было обратно расшифровать. И единственный способ расшифровать этот хэш — это не расшифровать, а просто подобрать его. Роман правильно сказал: в Cisco есть команда service password-encryption, мы ещё будем про это тоже говорить, которая превращает пароли в хэш и высчитывает из всех паролей хэши, и хранит только хэши. Их расшифровать обратно, мы сказали, нельзя — это однонаправленный процесс. Единственное, что можно сделать — просто подобрать, подбирать значение. Обратимое — это значит не хэш, да, всё правильно. Подбирать значение входных данных — тот же самый пароль — просто подбирать пароль, каждый раз его хэшировать, то, что мы пробуем, и сравнивать хэш. Единственный способ — это подбор plaintext. Plaintext — это

входные данные, незашифрованные. Взяли, хэш посчитали, сравнили с тем, что есть. Не подошёл — другое слово из словаря взяли, если там атака по словарю, например. Представляете, насколько усложняется уже атака на пароли, когда приходится каждый раз слова, даже если по словарю, хэшировать — это же математическая операция, она затратна. Мы говорили, brute force — это когда по одному символу подбирается, либо может быть по словарю. Brute force — это просто один из способов. Атака по словарю — тот же самый brute force. Нужно хэшировать, понимаете, начинается — вычислять хэш, сравнивать этот хэш с тем, что хранится в базе, и так далее. Может быть, кто-то нагенерил мега-таблицу таких подобранных хэшей. Я думаю, что такие таблицы есть, я их не видел, я взломом паролей

не очень увлекаюсь, мне не до этого на работе. Что ещё сказать про хранение паролей, про обратимое шифрование? Андрей спросил — да, есть обратимое шифрование, так называемое. Это уже шифрование, когда если обратимое шифрование у пароля — значит, этот пароль можно расшифровать. Это не хэш-функция, а это именно функция шифрования была к паролю применена. Например, в Cisco иные — вы сталкивались с протоколом PAP? С аутентификацией PAP, с протоколом идентификации PAP. Или уже нет, все CHAP? PPP — я такой старый, уже не помню. CCNA — когда я CCNA сдавал, там был PPP, и PAP, и CHAP. Тот самый PAP — он требует незашифрованный пароль, если

помните. В системе, например, если мы будем использовать — мы, кстати, будем настраивать с вами RADIUS на Windows, и Windows тоже: PAP если работает, то в Windows есть такая функция — обратимое шифрование, или раньше было. Нужно обратимое шифрование, чтобы PAP мог расшифровать этот пароль, он по-другому не понимает. Поговорили. Пример использования хэш-функции — я думаю, все видели, а если кто-то не видел, то теперь будет это знать очень хорошо. Проверять целостность файлов: многие компании, когда выкладывают на своих официальных сайтах какие-то файлы — например, как делает Cisco, мы взяли самый простой пример. Cisco выкладывает образы операционной системы, Роман правильно, Cisco выкладывает образы операционной системы каких-то,

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

коллизия. Примеры коллизий — давайте вам в консоли покажу сейчас. Одну секунду. Хэш-функции — посмотрите, как работает хэш-функция и как могут быть коллизии. У меня есть пара файликов здесь — вот они: erase и hello. Это две программы, два разных файла, которые выполняют разные действия, вообще разные действия. Если мы посмотрим, то эти программы имеют — прошу прощения — они имеют одинаковый размер. Понятно, что две программки можно написать одинакового размера. Но самое интересное —

если посмотреть на хэш этих программок, даже MD5 обычный, то мы увидим, что два файла имеют абсолютно одинаковый отпечаток, абсолютно одинаковый дайджест у двух файлов. Мы ещё не знаем, что они разные. Кто знает — на самом деле это разные программы. Если мы запустим одну программу, она нам скажет одну информацию. Если мы запустим другую программу, то мы увидим совершенно другую работу, совершенно другой программы. Это действительно разные файлы и разные программы. Видите, даже они выполняют разные действия, но MD5-отпечатки у них одинаковые. Вот это называется коллизия хэшей. Это коллизия не случайная, это коллизия подобранная. Я честно сейчас

скажу, что не помню, но я потом, если кто-то интересуется, дам ссылку на автора этих файлов, который очень много объясняет про коллизии хэшей. И в принципе можно специально подобрать коллизию таким образом, что программа, которая является вредоносной, будет маскироваться под программу, которая совершенно легитимная. Вот такая штука. Так, теперь давайте разберёмся, как же аутентификацию мы можем с помощью хэш-функции осуществить. Как хэш-функции нам могут помочь понять, кто же сидит с той стороны? Это очень важно. Смотрите, для аутентификации — мы с вами говорили всё, я не буду повторяться, много повторяюсь — для аутентификации используется дополнительный ключ, который будет обрабатываться вместе с данными. Этот ключ известен

только двум сторонам — отправителю и получателю. Без этого ключа — во-первых, ключ помогает удостовериться в целостности, добавляет аутентификацию и делает невозможной атаку man-in-the-middle. При перехвате сообщения, не имея ключа для этого сообщения, злоумышленник никаким образом его изменить не может. Но если у него нет достаточных вычислительных возможностей — понятно, что все эти оговорки мы оставим за скобками, вынесем, потому что мы понимаем, что в криптографии там очень много нюансов. Мы будем говорить про реальный мир: если у злоумышленника нет ключа, который сидит у Евы, которая сидит посередине, то вряд ли она что-то сможет сделать.

Так, как работает аутентификация? Очень просто. Мы берём данные наши, сейчас указочку возьму. Мы берём данные, берём этот самый ключик, складываем — на самом деле давайте представим, что мы просто взяли битовый ключ и с битовыми данными, очень упрощённо, складываем ключик и данные, прогоняем всё это через хэш-функцию и получаем отпечаток. Вот такая мясорубка — получаем отпечаток и отправляем наши данные, реально наши данные, вместе с этим отпечатком. Мы отпечаток прикладываем, говорим: «Чувак, вот тебе файл, а вот его хэш. Я его подписал, так что всё нормально,

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

аутентификация. Здесь пример, который я сейчас рассказал на пальцах, здесь он в картинках. Я забыл переключить на картинку. Например, как аутентификация в динамической маршрутизации работает: тут берутся маршрутные обновления какие-то, берётся ключ, который вы указываете в конфигурации, вычисляется хэш и отправляется вместе с маршрутной информацией плюс этот хэш. Второй роутер точно такую же операцию делает и смотрит — хэши сошлись или не сошлись. Сошлись — всё нормально, целостность не нарушена, аутентификация подтверждена. Не сошлось — где-то проблема. Где проблема — мы догадаться не можем. Как мы догадаемся? Ключ неправильный, или целостность нарушена? Мы же говорили про то, что изменение даже одного бита колбасит этот хэш уже так, что не поймёшь. Это специально так сделано, конечно. И в полученном хэше уже не ясно, где побились данные или где было что-то неправильно. Но

мы просто говорим: извините, данные мы не принимаем, аутентификация не сработала. Это ясный момент для нас, я надеюсь, потому что на этом многие валятся. Давайте дальше. Чуть-чуть мы поговорим про алгоритмы хэширования. Сейчас, в настоящее время, есть три основных алгоритма. Их на самом деле много, этих математических алгоритмов, но так получилось, что отфильтровались ненужные, более слабые алгоритмы ушли куда-то в историю, и в настоящее время у нас используется три алгоритма: MD5, SHA-1, SHA-2. Некоторые говорят «SHA», некоторые говорят «ша» — можно и так, и так, кстати, говорить. В англоязычных источниках и так, и так говорят, точно вам скажу. MD5 — самый распространённый алгоритм. У него был

предшественник MD4. Вообще MD4 был популярным в своё время алгоритмом, который породил следующие поколения. В результате он даёт 128 бит хэша. Мы говорили, что хэш-функция даёт фиксированную длину — хэш-функция всегда, сколько бы данных вы в неё ни запихнули, как в эту воронку на предыдущем слайде, всё равно вылезет фиксированный хэш 128 бит, подвержен коллизиям, и сейчас этот алгоритм самый распространённый, потому что он самый можно сказать, уже пожилой, но его уже в новых инсталляциях не рекомендуется использовать. Если у вас есть возможность не использовать MD5, то не надо его использовать.

SHA-1 выдаёт результат 160 бит, он в принципе тоже наследник MD4, намного устойчивее, чем MD5, но он более медленный, так как алгоритм более сложный, он будет работать примерно на 25 процентов медленнее. Так что если нужна скорость — иногда бывает такая ситуация, что нужна скорость хэширования — вообще хэш-функции совершенно точно работают быстрее, чем алгоритмы шифрования. Больше для программистов: если есть выбор использовать шифрование или использовать хэширование в программировании, то лучше использовать хэширование — оно более быстрое, требует меньше вычислительных

ресурсов. SHA-1 тоже уже не рекомендуется для новых приложений, для новых инсталляций, он также подвержен коллизиям. SHA-2, который сейчас в настоящее время — мы будем дальше ещё про стандарты говорить — он принят как стандарт во многих отраслях, про FIPS 140 мы ещё сейчас поговорим. Он в принципе сейчас самый нормальный, он даёт разные результаты, то есть у SHA-2 есть несколько разновидностей: можно 224, 256, 384, 512. Это самый используемый сейчас алгоритм. Дальше сейчас есть SHA-3, который в 2012 году был принят тоже как стандартный, но реализация

его есть не везде. Вы понимаете, нам как сетевикам важно, чтобы всё оборудование реализовывало эти алгоритмы. Бывает зачастую так, что нельзя с ними работать, потому что где-то их нет. То же самое SHA-3 — куда было бы здорово его реализовать, но в этой операционной системе его нет, и в этой тоже нет. Пока он не получил достаточного распространения. С учётом того, что у нас в Российской Федерации с хэшированием нормально, а вот с шифрованием посложнее — мы сейчас будем про алгоритмы шифрования говорить дальше, и я упомяну про это. Как раз идёт разговор про шифрование — давайте сделаем перерыв небольшой. Поехали. С хэшированием мы познакомились, с тем как оно применяется — тоже познакомились. Оно будет

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

можно расшифровать. То есть мы получили какой-то повреждённый шифротекст, и из него получится повреждённый plain text — и такое тоже бывает. Поэтому за целостность отвечают хэши, и, как правило, в тех же VPN-технологиях — мы про IPsec будем дальше говорить, увидим всё это — они используются совместно: всегда используется шифрование и хэширование. Кстати, на том же самом CCNA вы тоже видели частный случай хэширования. Кто мне скажет, где вы это встречали? Не помните? С хэш-функциями конечно сталкивались, но они там не называются хэш-функциями. В TCP это именно хэш. Те же самые

чек-суммы пакетов или чек-суммы в Ethernet — это же тоже хэширование. CRC16 — то же самое, это один из частных случаев, и можно за уши притянуть и сказать, что это хэширование. Это тоже необратимая функция, и мы тоже всегда получаем разное значение. Целостность пакетов, целостность кадров в Ethernet, например, так и проверяется — тоже высчитывается по сути как хэш-функция, и если изменяется у нас кадр Ethernet, то и поменяется его чек-сумма. Так что это тоже штука такая, она везде есть. Окей, дальше про шифрование. Все алгоритмы шифрования можно разделить на две большие группы: симметричные и асимметричные. Симметричные алгоритмы — это когда у нас

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

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

на скорость. Но совершенно точно, что асимметричные алгоритмы будут работать намного медленнее. Ключ — это единственный закрытый компонент шифрования. Почему так написано? Есть такая аксиома в криптографии: сейчас сформулирую точно — все компоненты шифрования — алгоритм шифрования, его использование — они должны быть открыты. Только ключ должен быть закрытым, всё остальное должно быть публичным. Раньше, если взглянуть в историю шифрования, стойкость шифрования определялась именно алгоритмами, то есть придумывали

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

ослабит этот алгоритм — это станет известно всем, его просто перестанут использовать. Ключ — это единственный закрытый компонент шифрования. Длина ключа — это один из важнейших факторов стойкости системы: чем длиннее наш ключ, тем более стойкое шифрование у нас получается. Можно использовать ключ в два бита, но тогда и расшифровать будет намного проще. Разные алгоритмы используют ключ по-разному. Какие-то алгоритмы берут весь ключ. Как работает вообще шифрование очень упрощённо: генерируется какой-то ключевой материал — например, какая-то битовая каша. На самом деле генерация ключевого материала — это наверное самое сложное в современной компьютерной криптографии. Алгоритмы — это всё понятно, они

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

ключа — здесь уже на квантовом уровне всё делается. Она там супер- стойкая, самая главная задача — сгенерировать ключ, и передать этот ключ тоже очень важно. Там с одноразовыми блокнотами история, но тема интересная и довольно сложная для неподготовленных людей, поэтому углубляться не будем. Просто надо знать, что ключ — очень важная штука. Давайте дальше про шифрование говорим. Про криптоанализ у нас было пару слов — это область науки, которая занимается тем, что взламывает шифрованные сообщения. В чём разница между «взломали» и «скомпрометировали» — мы уже с вами говорили вчера, больше повторяться не будем. Чуть-чуть поговорим про криптографические

атаки — каким образом криптоанализ применяется на практике. Почему я здесь про это говорю — вероятно, в официальном руководстве по подготовке к экзамену это упоминается, и неплохо было бы это просто запомнить. Во-первых, атака brute force — мы про неё уже немножко говорили — она всегда успешна. Это единственная криптографическая атака, которая всегда оканчивается успехом. С оговорками: если у нас достаточно длинный ключ, то время, которое нужно потратить на brute force, стремится к бесконечности, и поэтому ничего не получится. В наших реалиях сейчас, если опять же следить за новостями науки и всё, что связано с квантовыми компьютерами, принять во внимание, то говорят — слышали — что тот, кто первый изобретёт

квантовый компьютер, кто первый его запустит в эксплуатацию, он похерит всю современную криптографию вообще. Потому что сейчас вся современная криптография опирается именно на время, которое нужно потратить для расшифровки сообщений. Тот же самый brute force ничем не ограничен, он просто будет занимать как бесконечное время. И говорят, что с внедрением квантовых компьютеров, которые оперируют не битами, а кубитами — четырёхразрядными — для того же brute force уже понадобится какое-то конечное время, и соответственно он точно будет успешен уже не просто в теории, а и на практике. Так что ждём выхода квантовых компьютеров. Какие ещё атаки есть? Бывает так называемая ciphertext-only — атака, когда

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

Это когда у нас есть шифрованный текст — в криптоанализе подразумевается, что шифрованный текст у нас всегда есть, нам его надо расшифровать — known plaintext: когда мы имеем какой-то кусок чистого текста, исходного текста, и криптоаналитик пытается этот исходный текст найти в зашифрованном тексте. Он берёт этот кусок исходного текста, шифрует по-разному, применяет к нему разные алгоритмы и смотрит — появился ли этот кусок исходного текста где-то в зашифрованном сообщении. Либо может быть у него полный текст — тогда криптоанализ бесполезен, если полный текст есть. Кусок текста — это именно known plaintext атака. Если возвращаться к истории — кто-нибудь знает историю про Enigma, как взломали её? Кино все смотрели?

Там очень просто — это как раз была атака. «Игра в имитацию» — посмотрите обязательно, отличное кино, хотя там не только про криптографию, но в основном про криптографию. Там была именно атака, когда был известен какой-то кусок открытого текста, то есть когда перехватывались сообщения с немецких подводных лодок, зашифрованные, естественно, и когда потом кто-то догадался, что обязательно в каждом сообщении будет идти сводка погоды — то есть какой-то кусочек незашифрованного исходного сообщения стал известен криптоаналитикам — и по этому кусочку сообщения, по этим кусочкам нашли закономерности и поняли алгоритм работы. Так что есть такая атака. Есть атака chosen plaintext и chosen ciphertext — это две атаки, которые намного

проще, чем когда у криптоаналитика какой-то непонятный кусочек текста. Здесь криптоаналитик уже точно знает — у него есть кусок чистого текста, и он точно знает, где он располагается в зашифрованном сообщении. Есть такие атаки — он точно знает, в каком месте надо его искать, она более простая. То же самое, когда он точно знает, где в зашифрованном тексте кусок чистого текста. Есть такие атаки. Иногда упоминается birthday attack — так называемая атака дня рождения. Есть такая — я думаю, кто-то про это знает — математическая штука: парадокс дня рождения. Это чисто комбинаторика, её сложно осознать —

из разряда математических парадоксов. Когда, например, есть небольшая группа людей — там 50 человек — и можно представить, что с какой-то долей вероятности у небольшой группы людей дни рождения совпадут. Дней в году 365, а в небольшой группе людей обязательно совпадают дни рождения — парадокс, как это объяснить. Там получается, по-моему, больше 50 процентов: берётся группа из 23 человек, и если 23 человека в группе, то по-моему есть 50 процентов вероятности, что у кого-то совпадут дни рождения. И есть атака, которая основана на таких совпадениях, это тоже brute force,

применяется на хэш-функции — когда brute force хэш-функцию, и хэш-функция вернёт значение, мы получим значение хэш-функции намного раньше, чем ожидаем. Meet-in-the-middle — «встречаемся на середине» — это на самом деле одна из разновидностей known plaintext, когда криптоаналитик знает порцию исходного текста и знает порцию шифрованного текста совпадающие. Тогда исходный текст будет шифроваться с каждым возможным ключом. Как вообще перебирается шифрованный текст — просто берутся и перебираются все возможные ключи. Мы

сейчас про ключи ещё поговорим. Берётся ключ — у нас есть ключ 8 бит, представим. Сколько у него будет возможных значений у этого 8-битового ключа? Вы знаете: 2 в 8-й степени — нам надо будет перебрать 256 вариантов этого ключа, и где-то мы точно остановимся. И meet-in-the-middle: с одной стороны будет шифроваться открытый текст, а с другой стороны будет расшифровываться с каждым возможным ключом шифрованный текст, и где-то посередине они встретятся — на половине перебора вариантов встретятся, и тогда получится точное соответствие. Давайте дальше, просто про это можно вечно разговаривать.

Симметричные алгоритмы шифрования — чуть-чуть поподробнее поговорим теперь про каждый, но не про каждый конкретный алгоритм, а про группы этих алгоритмов и зачем они нужны. Как я сказал, симметричный алгоритм шифрования — это шифрование с общим ключом, когда у нас есть один-единственный ключ, каким-то образом участники между собой его передали, распространили и зашифровывают-расшифровывают этим самым ключом. Алгоритмы эти считаются более простыми, я уже сказал, что они более простые — математические операции там используются более простые, они более эффективны и более быстрые, за счёт этого тратится меньше ресурсов процессора. Типичная длина ключа у них — от 56 до 512 бит. Симметричные алгоритмы шифрования больше не используют длинные ключи. Мы уже говорили

про то, что длина ключа — это всё-таки определяющая величина, от которой зависит стойкость шифрования. Но здесь можно выкрутиться по-другому: при симметричном шифровании — симметричное шифрование используется в потоке, когда мы быстро в том же VPN отправляем зашифрованные пакеты, с той стороны расшифровываем тем же самым ключом, отправляем, расшифровываем, и наоборот. Ключи же можно менять через какое-то время, правильно? То есть злоумышленник может, конечно, попытаться расшифровать, даже забрутфорсить какое-то наше зашифрованное сообщение, но он просто не успеет это сделать, потому что мы через пять минут этот ключ поменяем на другой, а потом через пять минут ещё раз поменяем на другой, ещё раз поменяем. Эта периодическая смена ключей

очень важна, и во всех современных технологиях шифрования она используется. Андрей, нет — менять надо скомпрометированный пароль, мы про это вчера говорили. Ключ шифрования — это совсем не пароль. Ключ шифрования — это набор бит, с помощью которых алгоритм будет получать зашифрованное сообщение. Мы с вами говорили: если злоумышленник перехватывает наши данные — а это вполне возможно, потому что в том же VPN, в тех же VPN-технологиях данные едут по интернету, по общедоступному — пожалуйста, читай, кто хочет, — и если у кого-то появится желание расшифровать наши данные, неважно каким образом, за brute force например, — криптоанализ требует очень больших мощностей и достаточного времени, — у злоумышленника просто не будет времени. Он может быть расшифрует наш пакет или кусок данных, которые

он перехватил, но он расшифрует это через два года. Ключ у нас будет меняться на новый через каждые десять минут, и он получит может быть ключ через какое-то время, но этот ключ уже будет бесполезен, потому что мы давным-давно ключи поменяли. Забегая вперёд, скажу, что во всех современных реализациях ключи можно менять, например, по времени. Когда два хоста устанавливают между собой какой-то site-to-site — без разницы какой, IPsec, например, — они могут менять ключи каждые 10 секунд, или каждый час, или, например, после того как передадут 10 мегабайт данных. Можно настроить таким образом, и в Cisco это точно есть — можно сказать, что после каждых переданных 10 мегабайт давай

договаривайся с той стороной, что будем ключи менять, и ключи заново генерируются, заново меняются. Так что особо длинные ключи здесь не используются — чем длиннее ключ, тем больше ресурсов процессора нам нужно потратить на шифрование. В симметричных алгоритмах это не нужно, просто не нужно — их можно менять. Какие есть сейчас современные алгоритмы, чуть-чуть про их сравнение. Во-первых, это DES. Они на самом деле тоже подразделяются на блочные и поточные, в математику углубляться не хочу, то есть без подробностей обойдёмся на этом курсе. Чем отличаются блочные от поточных шифров? Блочный алгоритм будет брать какие-то кусочки plain text,

зашифровывать их и отправлять — нарезать plain text какими-то кусками и отправлять. Причём разные алгоритмы работают с блоками по-разному: они, например, берут блок, шифруют, а потом берут следующий блок и будут его шифровать, используя предыдущий блок — там очень много всяких ухищрений, довольно сложно. Есть поточные алгоритмы, они на самом деле проще. RC — семейство алгоритмов RC2, RC4, RC5, RC6 — это поточные алгоритмы, которые будут просто брать поток битов и шифровать каждый битик. Они берут ключик, и первый бит из потока взяли, и первый бит из ключа взяли. Есть операция XOR — если кто-то знает, берём пример от процессора, логическое «или» —

из них получился бит другой. Следующий битик взяли и битик от ключа взяли — раз, XOR применили, и всё. И вот так потоковые шифры работают — это потоковый алгоритм, и считается, что они ещё быстрее. Рассказываю: DES — это самый слабый алгоритм, который сейчас уже точно не рекомендуется нигде. Он использует ключ 64 бита — на самом деле из этих 64 там только 56 бит истинных. У него несколько режимов работы. ECB и CBC: первый режим работы — он берёт каждый блок исходного текста и зашифровывает, используя

тот же самый 56-битный ключ. Если два блока будут одинаковые в сообщении, то и зашифрованные они будут тоже одинаковы. Представляете: если два слова в сообщении одинаковые, и с одним и тем же ключом 56 бит — результат будет одинаковый. А есть ещё второй режим, CBC называется, когда он берёт блок чистого текста и побитово XOR-операция с предыдущим блоком зашифрованного текста делается, и там получается уже нормальная каша, хорошая. DES в принципе уже надо забыть, хотя мы говорили с вами про то, что у нас в России сейчас есть конкретная проблема:

в нашу страну запрещён ввоз оборудования со стойкой криптографией, и DES — единственное, что мы можем использовать здесь легально без получения всяких разрешений. Законодательно такая проблема. Я с точки зрения обычного сетевого инженера и системного администратора — я бы лично не переживал. Например, в моём предприятии мы не передаём очень секретные данные по каким-то каналам связи между филиалами, например, у нас есть VPN — там хватит обычного алгоритма DES,

не проблема. Я рад бы шифровать только DES-ом, но дело в том, что, например, в роутерах Cisco нельзя включить только DES-алгоритм — там либо ты получаешь лицензию, включаешь всё шифрование, и тогда у тебя VPN начинает работать и всё остальное, либо тебе дают так называемый NPE — обрезанную прошивку, и там не работают даже функции VPN. А я могу даже не шифровать, дайте мне просто функции, чтобы VPN-канал построить. Но в наших обрезанных российских прошивках их просто нет. Это очень обидно. Фирма Cisco не идёт навстречу нам, чтобы — нельзя просто сделать VPN нешифрованный. Я рад бы вообще не шифровать, но просто операционная система не позволяет

это сделать. Такой парадокс есть. Дальше, какие ещё алгоритмы. 3DES — это развитие алгоритма DES, там уже будет трёхпроходное шифрование с тремя разными ключами. 3DES сейчас является минимумом, что можно использовать, если вы хотите использовать шифрование — опять же с условием того, что вы будете ключи менять исправно, постоянно. 3DES — это самый минимум, что можно использовать. Алгоритм AES — это сейчас на данный момент алгоритм, который рекомендован к использованию всеми, наверное, известными стандартами. AES, насколько я слышал, неплохо реализуется на уровне

железа, то есть процессора — даже в процессорах общего назначения, в Intel-овских, реализована поддержка AES уже на уровне железа, то есть аппаратное ускорение. Он тоже блочный алгоритм, берёт блоки побольше — 128 бит. Ключи там можно использовать разные: 128, 192, 256 бит, то есть можно как бы регулировать скорость этого алгоритма, подстраивать. Если вы видите, что ваш процессор не справляется с потоком шифрования, можно взять ключик поменьше, можно ещё меньше взять ключ. Этот алгоритм сейчас используется повсеместно и рекомендован. Законодательство не разрешает AES. Андрей, я бы вообще не стал рассказывать про наше законодательство, потому что я в нём не очень хорошо разбираюсь, я не юрист. У нас нужно получать — даже не так: закон на самом

деле рассказывает о том, что нельзя ввозить сюда устройства с шифрованием. Вроде бы шифровать-то можно — никто не запрещает использовать, например, программное шифрование, насколько я знаю. Не обязательно ГОСТовое — любой алгоритм. Нельзя устройства сюда ввозить со стойким шифрованием. Хотя я могу ошибаться. Эта тема очень сложная, я не видел прямых запретов и от коллег не слышал, что нельзя, например, взять, поставить два компьютера с операционной системой Linux или Windows, между ними запустить IPsec и шифровать AES-ом, например, 256-битным ключом — на уровне программного обеспечения. Запрещён ввоз оборудования с шифрованием,

поэтому все эти законодательные ограничения у нас крутятся вокруг оборудования — роутеров, коммутаторов, точек доступа и так далее. Именно железо. На программном уровне — я не знаю, я просто не буду врать, тем более в рамках чтения курса. Надо спрашивать у юристов. Такая скользкая тема. Есть ещё куча других алгоритмов: Blowfish, SEAL, ГОСТовский наш «Кузнечик». ГОСТ — он разрешён, пожалуйста, можно шифровать. «Кузнечик» — это название алгоритма ГОСТ 34.13. Никто не говорит, что «Кузнечик» с бэкдорами — мы же не знаем. Он разрешён, и если он разрешён, значит государство уверено, что всё нормально с этим

алгоритмом. Но на самом деле я не работаю в госорганах, я не работаю с государственной тайной. С какой-то особой коммерческой тайной в компаниях, где я работаю либо с которыми сотрудничаю, тоже не передаётся секретной информации. Поэтому с алгоритмами шифрования сложилась очень простая дружба — их мало использую. Давайте дальше, теперь про асимметричные. Я призываю к порядку и к дисциплине, а то сейчас мы в чатике развернём параллельную дискуссию про то, как сюда Cisco привозить и что делается, чтобы шифровать. Давайте поговорим про асимметричные алгоритмы шифрования. Я говорил о том, что случайно на них наткнулись, и это было очень значительное открытие в мире криптографии.

Ещё по-другому называется шифрование с открытым ключом — public key cryptography. Почему открытые-закрытые — эти названия: самая главная идея, что у нас есть пара ключей. Первый — открытый, это ключ, который мы можем всем рассказать, всем раздать — не проблема: вот мой ключ шифрования, пожалуйста, храните у себя сколько хотите. И закрытый ключ — закрытый ключ мы держим только у себя, мы его никому не должны показывать, это приватный ключ. Самый прикол асимметричного шифрования, что если мы зашифровали закрытым ключом, то расшифровать можем только открытым ключом. И наоборот. Скажем, я сделал себе ключевую пару — открытый и закрытый, два ключа. Один ключ, открытый, я раздам всем вам. Вы не сможете друг с другом обмениваться шифрованными

сообщениями — только с этим ключом вы можете зашифровать, но другой из вас, кому пришло сообщение, с этим же ключом не расшифрует. Вот так это работает. В этом виде шифрования мы можем обеспечивать и конфиденциальность, и аутентификацию. Ключи здесь будут более длинные — от 512 до 4096 бит. Как правило, это сложные алгоритмы шифрования. Понимаете, если в симметричных алгоритмах один ключ и не надо — ну, как не надо, надо, конечно, очень сильно думать, чтобы придумать такой алгоритм, — то здесь это ещё сложнее, потому что разработка алгоритма асимметричного шифрования требует больших усилий научного сообщества. Примеры таких алгоритмов, которые мы будем использовать, — это RSA, DSA и Эль-Гамаль. Где-то используется. Давайте дальше,

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

Боба. Алиса берет какой-то текст, зашифровывает его открытым ключом Боба и отправляет Бобу. Боб может расшифровать только со своим закрытым ключом. Здесь обеспечивается конфиденциальность, мы точно уверены, что только Боб может расшифровать наше сообщение, потому что мы зашифровали его открытым ключом. Если Алиса отправит это сообщение и кто-нибудь по дороге перехватит это сообщение — у них есть открытый ключ Боба, и что? Они с ним ничего сделать не могут. Только Боб может расшифровать это сообщение только своим закрытым ключом. Если закрытый ключ его попадет в чьи-то руки, то всё — какая криптография, тут уже ключ скомпрометирован, всё, до свидания, ключи надо менять. Вся асимметричная криптография, всё асимметричное шифрование

берет за главный принцип то, что закрытый ключ, приватный, он никогда никуда никому не известен. Как только он кому-то известен — всё, до свидания, ничего не получается, надо ключи переделывать. Вот так обеспечивается конфиденциальность. Если Боб зашифрует своим закрытым ключом и передаст Алисе — здесь никакой конфиденциальности не получится. Обратите внимание, имейте в виду: если кто-то перехватит это сообщение — у него есть открытый ключ, он его расшифрует. Конфиденциальность в случае асимметричного шифрования она односторонняя. Это до всех дошло точно, или надо еще раз рассказать? Я могу еще раз повторить, еще раз рассказать. Это достаточно простая вещь, просто это не запоминается

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

что только Алиса прочитает это сообщение. Вот вам конфиденциальность — здесь совершенно точно будет двусторонний обмен, когда у них есть открытые ключи друг друга. Теперь аутентификация. Если шифровать наоборот, здесь получится аутентификация. Смотрите, давайте теперь: Алиса сгенерила ключевую пару, отдала свой ключ Бобу, всё нормально. Теперь Алиса зашифровывает свое сообщение своим закрытым ключом и отправляет его Бобу. На самом деле неважно кому она отправляет — у всех же есть открытый ключ, правильно. Она зашифровала свое сообщение своим ключом и отправила Бобу, может быть она кому угодно отправила. Здесь конфиденциальность уже не соблюдается, понимаете — кто угодно может расшифровать. Но тот, кто расшифрует, он будет стопроцентно знать, что это Алиса. Он ее

аутентифицировал. Дошло? Вообще весь кайф этой асимметричной криптографии, что ее можно по-разному использовать. Мы получили сообщение от Алисы, у нас есть ее публичный ключ, получилось расшифровать — значит это точно она зашифровала своим закрытым ключом, это точно Алиса. Алиева, которая там перехватила сообщение, что-то попыталась сделать... Андрей, так, аутентификация — процесс односторонний. Аутентификация — процесс односторонний: один спрашивает пароль, другой пароль предъявляет. Это всегда односторонний процесс. Если надо в другую сторону запустить — пожалуйста, можно обменяться публичными ключами и в другую сторону запустить процесс, так что здесь никаких проблем. Просто запоминайте, я

боюсь, что на экзамене точно попадется, потому что может быть такая штука: вас просят — если зашифровывается закрытым ключом, приватным, это что — аутентификация будет или будет конфиденциальность? Вам надо просто прокрутить в голове эту картину: что у кого есть, какие ключи, и еще раз вот эти все картинки, вот этот мой рассказ вспомнить. Эта штука важная, на этом построено огромное количество технологий и очень много всего. Сейчас мы про это дальше будем эту тему развивать. Мне самое главное, чтобы до вас это всё дошло, чтобы вы поняли саму идею асимметричного шифрования. Где используется асимметричное шифрование? Смотрите, на самом деле в современных технологиях — мы сейчас про SSH будем говорить, но не только в SSH, а много где: в SSL, там

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

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

передает на сервер. Понимаете, что здесь обеспечивается конфиденциальность — никто, кроме сервера, вот этот сессионный ключ расшифровать не может. Ни у кого же нет закрытого ключа сервера. Прекрасно. Сервер получает это зашифрованное сообщение, своим закрытым ключом расшифровывает и — класс, у меня теперь тоже есть ключ для нашей сессии! И начинает передавать данные, уже зашифровывая AES, 3DES, уже используя вот этот ключ, который ему клиент прислал. Один ключ шифруется другим. Вам вот этот механизм понятен, или еще раз проговорить? Вообще самая сложная задача, как я уже говорил, я повторюсь — это именно передать друг другу ключи. Олег, еще раз смотрите: самая сложная задача — передать друг другу ключи шифрования.

Не публичные-приватные, мы сейчас не про это говорим. Основной обмен данными идет с помощью симметричных алгоритмов. Внутри, возьмем DES, который быстрый — симметричный алгоритм должен быть у обеих сторон один и тот же ключ, это важно. Мы понимаем, но его же надо как-то согласовать, как-то передать. Более старшие протоколы — мы посмотрим, как они делают немножко по-другому, но здесь вот с помощью асимметричного шифрования сделано. Нам нужно как-то получить одинаковый ключ, чтобы быстро передавать данные с помощью 3DES, симметричного шифрования. Очень просто: сервер отдает свой публичный ключ клиенту. Клиент постучался, говорит: я здесь. Сервер: отлично, вот тебе мой ключ. Клиент придумывает вот этот самый секретный ключ, который потом будет использоваться для быстрой передачи данных —

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

сессионный ключ, будет использоваться для дальнейшего шифрования. Оно будет симметричное уже, быстро — и 3DES или AES для сессии. Всё, дальше уже он там спрашивает логин-пароль, потому что там зашифрованным всё передается. Дальше уже всё остальное пошло. Но самое главное — вот процесс установки соединения, здесь используется асимметричное шифрование. Так, Андрей задал: ключи открытые-закрытые одинаковой длины, но могут ли использоваться в обоих направлениях? Я не понял — могут использоваться в обоих направлениях? Только в обратном не имеет смысла. Я не понял вопрос. Длина здесь вообще не имеет никакого значения. Длина ключей — они одинаковые, хотя могу соврать. Зашифровать можно только закрытым, и только открытым можно расшифровать, и наоборот.

Если зашифровать открытым — открытым не расшифруешь. Всё, вот такая схема. Но согласитесь, красиво, элегантно. Это просто очень красивая схема, как обменяться каким-то секретом, секретным ключом для сессии и дальше уже гнать данные по защищенному каналу. Это SSH1, еще один алгоритм используется в SSH2, мы сейчас будем дальше говорить, там Диффи-Хеллман уже будет. Давайте перерыв сделаем, заболтались. Дальше будет тема жирная. Продолжаем. Мы с вами выяснили самые главные понятия асимметричного шифрования, симметричного. Самое главное, что мы теперь знаем, что вот эти два типа шифрования в современных протоколах используются вместе. Как правило, сначала с помощью асимметричного шифрования производятся какие-то действия, как например обмен сессионным ключом,

а потом уже вступает в бой тяжелая артиллерия — симметричное шифрование, большие данные и так далее. Продолжаем. Теперь давайте про цифровые подписи и PKI будем рассуждать, будем разговаривать. Этим мы подойдем к концу первого модуля, я сегодня мы обязательно закончим уже такую — основные вещи разбирать. Сначала познакомимся с цифровой подписью. Мы с вами уже поговорили о том, что алгоритмы асимметричные обеспечивают аутентификацию, они позволяют удостовериться, что на том конце провода тот, кто нам нужен. Они будут в принципе использоваться и здесь, но что у нас не обеспечивают

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

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

юридически признается так же, как и подпись обычного человека. Так что инструмент действительно мощный, инструмент интересный. Давайте еще раз просто уже на слайде посмотрим, как всё это работает, еще раз проговорим механизм вот этой электронной подписи. У нас есть Алиса с Бобом. Алиса берет какой-то документ — раз подпись цифровая, значит это уже документ, лучше применять слово — высчитывает из него хэш. SHA-1, MD5, неважно — просто хэш. Берет этот хэш и шифрует своим закрытым ключом — получается подпись. Она прикрепляет эту подпись к документу и отправляет Бобу. Кто угодно может перехватить этот документ. Этот документ не зашифрованный, обратите внимание — документ не шифруется, только подписывается. У нас не стоит задача

зашифровать документ, у нас стоит задача обеспечить аутентификацию. Кто угодно может его перехватить, но изменить-то он его не может — он подписан подписью Алисы. Дальше Боб, который получает этот документ, что он будет делать? Он берет подпись, расшифровывает ее открытым ключом Алисы — конечно же, у него есть открытый ключ Алисы — и получает этот самый хэш документа, вот он — отпечаток. Потом берет документ исходный и точно так же высчитывает из него хэш. Он сравнивает хэш, который он сам посчитал от документа, и хэш, который он расшифровал с помощью открытого ключа Алисы. Если эти хэши одинаковые — значит, да, действительно Алиса подписала этот документ, именно она

рассчитала хэш и именно она своим приватным ключом его зашифровала. Вот так работает цифровая подпись. Я думаю, вот это точно должно быть всем понятно. Вы просто мне пожалуйста сразу говорите, если что-то непонятно, чтобы я еще раз рассказал. Мне важно знать, что вы это поняли, что до вас это доходит. Давайте дальше. Это справа вот — цифровая подпись. Так, переключил. Давайте продолжать. Обзор PKI. Давайте я разовью немножко тему про цифровую подпись. Это здорово — подписывать документы своей цифровой подписью, это здорово обмениваться такими документами до того момента, когда, например, ключ будет скомпрометирован, приватный. Но

Алиса потеряла свой приватный ключ, просто у нее компьютер сгорел, жесткий диск в нем сгорел, и всё — потеряла. Что делать? Как удостовериться? Либо кто-нибудь украл у нее — как удостовериться, что Алиса новый ключ выпустила, или это до сих пор она? Вот что делать в таких ситуациях? Просто электронная подпись не предусматривает всего этого. Для этого была придумана такая замечательная вещь, как PKI — Public Key Infrastructure, инфраструктура открытых ключей. Это PKI — это набор просто набор разных компонентов, служб, средств для поддержки управления вот этими самыми ключами. Дальше — сейчас дальше поймете на следующих слайдах, следующем рассказе.

Нам нужен какой-то механизм, чтобы менять ключи, чтобы точно подтверждать, что это точно была Алиса, что ее подпись до сих пор действует, не волнуйтесь, всё нормально, или наоборот рассказать всем, что извините, Алиса потеряла свой ключ, поэтому если вы получите от нее документ с подписью — не доверяйте, это не она. Вот этим занимается PKI. PKI как раз будет решать все задачи безопасности: и конфиденциальность, и целостность, и доступность. Теперь немножечко по терминологии, что такое PKI — думаю, вы знаете уже. В PKI есть еще одна сущность — это CA, Certificate Authority, вот он. CA — это удостоверяющий центр, это кто-то,

кому все доверяют. А мы уже говорили про то, я немножечко говорил про то, что вообще в безопасности очень многие вещи построены на доверии. Вот, какой бы сложный ни был механизм, сколько бы там ни было уровней доступа, проверок, каких угодно — всё равно должно упереться в то, что есть кто-то или что-то, которому мы безоговорочно доверяем. Всё. Если понимаете, просто как безопасность построена — если никто никому не доверяет, то вообще ничего не получится. Вообще ничего не получится. Должен быть один какой-то верховный судья, который скажет: доверяйте мне, как я скажу — так и будет. По-другому в безопасности просто не бывает. Если общее недоверие, то вообще ничего не сложится, картина мира.

Поэтому в PKI есть так называемый удостоверяющий центр. Это центр, которому все доверяют. Договорились так, что вот эта организация — мы ей все доверяем. Если они скажут, что Алиса — это Алиса, значит так. Если они скажут, что Алиса — это не Алиса, мы тоже примем это за правду. Всё, это не обсуждается. Удостоверяющих центров на самом деле много. В каждой стране есть удостоверяющий центр, и не один — много. Есть и удостоверяющие центры, которым есть доверие во всём мире. Это не так важно. Бывает так, что удостоверяющий центр есть, а у него есть подчиненные центры, которым тоже все должны доверять, которым он делегирует свои задачи. Мы немножечко про это тоже скажем. Дальше — цифровой сертификат. Если до этого мы говорили просто про цифровую подпись — да, хэш взяли, зашифровали

приватным ключом, прикрепили к документу, отправили — то цифровой сертификат — это в принципе та же самая цифровая подпись плюс еще некоторые данные. Вот это такой документ, в котором сама подпись содержится, наш ключ публичный, и плюс сведения о субъекте сертификата — там имя веб-сервера или имя Алисы, какие-то данные, там адрес ее электронной почты, например. Дальше, удостоверяемая информация — открытый ключ Алисы обязательно там должен быть, и сведения об удостоверяющем центре. Вот этот сертификат — на самом деле еще раз, этот сертификат — это подпись Алисы плюс это какие-то данные об Алисе: что ее зовут Алиса, что у нее email alice@alice.com,

вот. Ее открытый ключ едет вместе с подписью, там же в пачке. И сведения об удостоверяющем центре — кто подтверждает ее подпись. Плюс там еще много всякой информации, с которой мы сейчас с вами познакомимся. Вот это и есть цифровой сертификат. В PKI-структуре есть много разных стандартов. Есть так называемый PKCS — я забыл, как расшифровывается, честно скажу. Сейчас одну секундочку... Public Key... Стандарт, сейчас секундочку, я прошу вас одну секунду.

Как же PKCS расшифровывается... Ладно. Кто-то мне подскажет? До криптографии — public key криптографии стандарт. Спасибо большое. И Глеб, спасибо. Итак, PKI — это... PKI описывается в нескольких стандартах. Для тех, кто хочет сдавать экзамен, будет печальная новость, что лучше всё это запомнить. Все эти стандарты — я не уверен, но вдруг вас об этом спросят на экзамене. В каком-то стандарте будет описываться именно про криптографию. Где-то будет описываться про Диффи-Хеллман. Про Диффи-Хеллман мы ещё с вами поговорим. Про пароли и про сами сертификаты будет написано в отдельном стандарте. Про криптографические сообщения, про то, какие должны быть приватные ключи.

Этих стандартов много. PKCS #10 надо запомнить, что это запрос сертификата, я точно помню. Обмен персональной информации, про эллиптические кривые — там тоже есть. Просто этот слайд как-то зафиксируйте глазами, а потом на записи ещё раз посмотрите. Эта пачка стандартов в PKCS описывает всё поведение инфраструктуры PKI. Может быть, я не думаю, что нужно наизусть учить. Я, например, наизусть это не помню. Я просто знаю, что они есть и что они всё описывают. Если надо, можно всегда посмотреть документацию. Теперь про сами сертификаты. Есть такой стандарт X.509. X.509 — это именно стандарт, который определяет содержимое сертификата. Сертификат — это не просто слепленные вместе цифровая подпись, открытый ключ и всё остальное. Нет, это структурированный документ, в нём есть определённое количество полей, и в каждом поле обязательно записаны свои данные.

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

Обязательно открытый ключ вложен в сертификат. Правильно же — с помощью него надо расшифровывать сообщение от отправителя. Там будет и сам открытый ключ, и написано, какой алгоритм открытого ключа, чтобы мы знали, как расшифровать. Идентификатор издателя, идентификатор субъекта. Дальше будет подпись самого сертификата. Сейчас я расскажу дальше. Этот сам сертификат он тоже будет, в свою очередь, подписан цифровой подписью удостоверяющего центра. Вот так. Не запутались? Или запутались? Сейчас будем картинки рисовать, если запутались. Это просто пример сертификата. Я думаю, что все эти сертификаты видел каждый из вас.

Их можно посмотреть, рассмотреть. Я думаю, что сейчас мы с вами закончим это занятие, а завтра на свежую голову вы вспомните про то, что я говорил, откроете какой-нибудь сертификат и внимательно его поизучаете. И вы будете уже знать, какие поля в нём что обозначают и зачем нужен сертификат. Иногда понимания, что такое сертификат, у людей нет — я вам точно скажу. Как выдаётся сертификат. Смотрите, у нас есть Боб, который запрашивает сертификат. Что он будет делать? Он возьмёт свой открытый ключ, возьмёт свои какие-то данные — скажет, что меня зовут Боб, мой адрес электронной почты такой-то, какие-то ещё про себя данные расскажет. Обращаю внимание, что здесь может быть не Боб — здесь может быть веб-сервер или почтовый сервер. Сертификат не обязательно для человека выдаётся, наоборот — чаще сертификат выдаётся какой-то системе, какому-то сервису. Например, веб-сервер скажет, что моё имя — cisco.com.

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

Они сами находят мой телефон, звонят на работу мне, говорят: «Здравствуйте», спрашивают, кто вы, у секретаря спрашивают. Могут даже приехать. Всё зависит от того, для чего будет использоваться сертификат. Каким-то образом сертификационный центр удостоверяется. Да, Кирилл, там много проверок может быть. Чем серьёзнее сертификат запрашивается, тем серьёзнее будут проверки, но это обязательно. Когда CA удостоверяется, что вы — это вы, он делает очень просто. Говорит: «Ага, всё нормально», берёт ваш запрос, подписывает его своим закрытым ключом, туда ещё свой открытый ключ положит обязательно — он нужен обязательно, туда положит свой ключ.

Подписывает его своей подписью — берёт хеш от этого сертификата, шифрует его своим закрытым ключом, прилепляет всё вместе и говорит: «Всё, сертификат выдан». На этом моменте сертификат готов, он подписан цифровой подписью CA. Что делать, если у вас нет денег, например, и вы не можете заплатить сертификационному центру за такую работу? Хотя есть бесплатные сертификационные центры — в последние годы они появляются и их всё больше. Другое дело, что им не все доверяют. Я говорил, что всё упирается в доверие к CA. Можно сертификат самому подписать — никто не запрещает. Вы взяли, выпустили сертификат — вот мой открытый ключ, вот мои данные,

берёте, сами их подписываете. Называется самоподписанный сертификат — просто взяли, сами подписали, сказали: «Я CA, я подписываю свой сертификат» — на 20 лет. На самом деле это очень часто используется, но внутри организации. Очень часто используются самоподписанные сертификаты, чтобы их не перегенерировать, денег за них не платить. Делают внутри организации такие сертификаты. Но если вы этот сертификат будете использовать в каких-то внешних каналах, во внешней работе, то такому самоподписанному сертификату никто не будет доверять. Кто его подписал? CA? Чья это цифровая подпись? Кто это такие? Это ты сам подписал? До свидания. Не будут просто доверять тому, кто сам подписал себе сертификат. В настоящее время это не очень дорого, и я думаю, что любая компания может себе это позволить.

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

Потому что смотрите — я бы нарисовал на слайде, ну ладно, я на пальцах объясню. CA может просто не справляться со своей работой, например, либо у него такое количество клиентов и запросов, что неплохо было бы расширить как-то свою сеть, и он может разрешить кому-то ещё подписывать сертификаты от своего имени. Именно таким образом — есть ещё промежуточные центры сертификации. В свою очередь, их удостоверяет CA, а эти промежуточные центры сертификации выдают ещё кому-то сертификаты. Получаются цепочки сертификатов. Точно так же — более старший подписывает сертификат более младшего. Бывают такие цепочки — даже два промежуточных центра. Бывают такие цепочки сертификатов.

Это всё работает на основе электронной цифровой подписи. Самый верхний подписывает сертификаты нижестоящих своей электронной подписью. Они уже, в свою очередь, своей подписью подписывают. Если вы доверяете CA, доверяете автоматически всем промежуточным. Да, всё правильно, потому что всё равно вы упрётесь куда-то наверх — у вас есть CA, и если вы видите, что сертификат промежуточного центра выдал CA, которому вы доверяете, значит и всем остальным доверяйте. В сертификате веб-сервера требуется цепочка сертификатов, до, исключая самого верхнего. Ну, и так тоже бывает, потому что самый верхний не обязательно включать — вы его можете отдельно проверить, потому что CA этого верхнего знаете.

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

Откуда у вас есть открытый ключ CA? Смотрите. Чтобы проверить электронную подпись CA, вам нужен его открытый ключ. Открытый ключ CA — как его взять? Он есть у самого CA, можно скачать с его сайта, например. Можно просто положиться на выбор создателей операционной системы, в которой вы работаете, — и там уже эти сертификаты есть. Например, фирма Microsoft — она знает, что есть там 100–200 сертификационных центров, она им доверяет, и в операционную систему Windows сразу включает все их сертификаты с открытыми ключами. И всё. Когда Алиса вам присылает свой сертификат, вы смотрите:

а там написано, что подписал этот сертификат удостоверяющий центр, ну не знаю, StartSSL, например. Вы смотрите: а доверяю ли я этому StartSSL? А есть ли у меня его публичный ключ вообще? Кто это такие? Покопались там в операционной системе — ага, есть их сертификат у меня, и он у меня лежит в хранилище. Знаете, что в операционной системе есть хранилище доверенных корневых центров? Он лежит в этом хранилище. Значит, всё нормально, значит, я буду доверять этому сертификату. Всё нормально, вы его проверили. У вас уже должен быть сертификат CA. Если у вас нет сертификата удостоверяющего центра, а вам Алиса пришлёт свой сертификат, вы посмотрите — а я не знаю, кем он подписан, вообще непонятно кем, я не могу эту подпись расшифровать, публичного ключа нет. Что делать? И вы говорите — или ваш браузер вам говорит:

«Извините, этот сайт недоверенный» — там красным цветом он вам светит. Видели сто раз, да? Не может проверить сертификат — просто непонятно, кем он подписан, или самоподписанный сертификат прислали, но у вас нет сертификата удостоверяющего центра, вы не знаете, кто его подписал. Поэтому браузер Chrome вам говорит: «Ничего не знаю, ошибка SSL, всё, работать не будем с этим сайтом. Но если вы очень хотите, мы, конечно, представим, что этот сертификат правильный». Здесь вопросов нет. Давайте дальше. Теперь как у нас работает отзыв сертификатов. Кто-нибудь меня слышит вообще? У нас такая тишина в чате, я боюсь, что просто меня не слышат. Хорошо, давайте дальше тогда. Теперь про отзыв сертификата.

Мы говорили про пример на Хабре — я просто не в курсе, я не знаю, про что там говорится. Я здесь расскажу своими словами и теми словами, которые написаны в курсе, я думаю, что вы поймёте — там ничего сложного нет. Мы говорили про то, что цифровая подпись — она классно работает до тех пор, пока нам не нужно её отозвать или пока мы не потеряли приватный ключ, и так далее. В PKI есть такой механизм отзыва сертификатов. Если у нас скомпрометирован закрытый ключ, либо бизнес сказал, что нам больше не нужен ключ, мы больше не используем сертификаты — нужно как-то отозвать. Мы же не можем по всей планете разослать электронное письмо и сказать: «Ребята, мы этот сертификат больше не используем, пожалуйста, не верьте, если придёт письмо с нашей цифровой подписью».

Конечно, мы не можем. Мы будем обращаться к централизованному процессу. В структуре PKI есть такой механизм, называется отзыв сертификата. Есть два метода проверки отозванного сертификата. Я сразу скажу, что когда удостоверяющий центр подписывает сертификат для кого-то, он туда ещё напишет строчку, где можно посмотреть отзыв этого сертификата. Это очень важная штука. Он туда напишет, например, что по такому-то адресу будет лежать список — и там гляньте, вдруг этот сертификат уже отозванный. В самом сертификате уже содержится информация о том, где можно проверить, отозван сертификат или нет.

Есть два метода проверки. Первый метод — это CRL. Это просто текстовый файл с серийными номерами сертификатов, которые были отозваны. Этот текстовый файл подписан самим удостоверяющим центром, его цифровой подписью. Есть базовый CRL — такой полный список, и ещё иногда через некоторые промежутки времени публикуется дельта CRL, то есть такой дифференциальный список — разница между базовым списком и на настоящий момент сколько добавилось отозванных сертификатов. Участники PKI — если кто-то вам прислал свой сертификат, чтобы начать обмен сообщениями, или он с помощью него что-то пытается подписать, какой-то документ, — то вы посмотрите в этом сертификате, там будет прямо написано, что CRL находится по такому-то адресу — там ищите.

Ваш браузер зайдёт по этому адресу, посмотрит, нет ли там серийного номера этого сертификата. И если там ничего нет — значит, сертификат надёжный, значит, ему можно доверять. Если он видит серийный номер — значит, этот сертификат был отозван, всё, по разным причинам, неважно по каким, но отозванный сертификат — мы не принимаем, мы с ним вообще не работаем, до свидания. Существует вероятность — CRL обновляется, он обновляется теоретически быстро, но вы не каждый раз будете проверять этот CRL. У вас есть этот сервис — вы приняли сертификат от кого-то, от какого-то сайта, через неделю опять пошли на этот сайт, и ещё через неделю пошли на этот сайт. С CRL не при каждом посещении сайта будете обращаться. Не знаю, какая периодичность — это всё зависит от операционной системы, например, или от браузера.

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

OCSP работает другим немножко способом. Это база, к которой можно обратиться в реальном времени. Не весь список CRL скачивать, а просто послать запрос: «Пожалуйста, скажите, вот этот серийный номер — он отозван или нет?» Вам оттуда сразу скажут: «Всё нормально, он не отозван». OCSP работает в реальном времени. Он намного эффективнее, чем CRL. Конечно, там возрастает доля обмена служебными сообщениями, но это не страшно — это всё копеечный трафик. Поэтому OCSP, конечно, предпочтительнее. Конечно, когда делаете самоподписанные сертификаты или у вас своя инфраструктура, которую вы только начинаете осваивать и развивать, — OCSP не сразу появляется, потому что тоже надо какие-то усилия приложить, чтобы он заработал.

По поводу SSL — давайте быстренько пробежимся, как работает SSL. Мы с вами уже смотрели, как работает SSL. Здесь та же самая история, по большому счёту, SSL работает почти так же. Нужен сессионный ключ — временный ключ для одной сессии, который мы будем использовать с симметричным шифрованием, чтобы шифровать уже боевой трафик. Но для того чтобы этот ключ получить, его надо как-то передать. Здесь будет всё то же самое, практически. Клиент устанавливает соединение с сервером, сервер ему выдаёт свой сертификат. В этом сертификате есть открытый ключ сервера, есть цифровая подпись CA. Дальше клиент проверяет этот сертификат — он смотрит подпись удостоверяющего центра, убеждается, что сертификат нормальный,

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

Здесь в принципе то же самое. Просто в SSH, как вы помните, сервер тупо отдавал свой публичный ключ — вот тебе мой публичный ключ, и давай мне уже сессионный ключ, им зашифровав, передавать. Здесь просто сервер отдаёт свой сертификат, и клиент дополнительно проверяет идентичность сервера — он проверяет его сертификат. А потом всё то же самое — берёт из него публичный ключ серверный, шифрует, и у сервера есть сессионный ключ. И уже потом этим сессионным ключом шифруются боевые данные — быстрое симметричное шифрование используется. Схема похожа: сначала асимметричное шифрование с публичными ключами, потом симметричное врубается на полную катушку — и погнали. Ну и на сегодня последний небольшой разговор про ключи шифрования. Такая заметка — здесь не полноценная будет лекция, просто заметка о том,

что управление ключами — достаточно важная задача в криптографии и безопасности. Мы понимаем, что ключи — это главное, что может быть в криптографической защите, поэтому к ним надо относиться с должным почтением. Наша задача — это генерация ключей. Генерация ключей, я уже говорил, — достаточно сложный момент. Именно по теме генерации ключей учёные ломают голову — это самое сложное, что есть в криптографии. Как сделать такой ключ, чтобы он точно-точно был прямо уникальный? В этой уникальности — самая главная задача. Верификация ключей. Хранение ключей — хранить ключи тоже нужно безопасно, где-то в таком месте, чтобы и сисадмин какой-нибудь не удалил их по неосторожности, и чтобы они в руки неприятеля не попали.

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

что хранить ключи вот таким образом. Больше от администратора не требуется. Все программы, там компоненты программ, они сами обмениваются ключами, сами их отзывают, сами перегенерируют заново через какое-то время. Мы про это тоже с вами уже говорили. Так что эта задача она конечно очень важна. Что такое пространство ключа — я уже немножко про это говорил вам. Каждый ключ имеет так называемое пространство — это набор всех возможных его значений. Можно упростить: у нас если есть ключик 8 бит, мы знаем, что 2 в 8 степени возможных значений — 256 значений у этого ключа, его можно перебрать просто за 256 операций. Вот это называется пространство ключа. Каждый алгоритм имеет слабые ключи. Есть

такие условия — либо специальные, либо это бывают какие-то аппаратные сбои может быть, когда генерируются слабые ключи. В криптографии такая штука есть. Потому что нет, Андрей, просто пространство — это не длина ключа. Длина ключа — это просто длина битовой строки: 8 бит, там 512 бит. А пространство включает все возможные значения, которые можно запихнуть в это количество бит. Вспоминайте: в одном байте, в одном октете, эти 8 бит — 256 значений. Всё. Поэтому именно слабые ключи — вот вся проблема, одна из основных проблем криптографии — это стойкость ключа. Поэтому при ручном создании ключей возможны проблемы. Я уже говорил — можно руками создавать ключ, просто

писать всякую фигню на клавиатуре. Никто вам это не запрещает. Хотите создать ключ шифрования — просто берёте, бьёте по клавиатуре как попало. Но возможно, что вы создадите слабый ключ, потому что статистически может так сложиться, что это будет слабый ключ. Так что и такое тоже бывает. Мы говорили про брутфорс. Ещё раз здесь нам напоминается, что защита современных алгоритмов она всё-таки опирается на длину ключа. Чем длиннее ключ, тем лучше. Добавление всего лишь одного бита ключу увеличивает пространство вдвое. Надо понимать, что 128-битный ключ он не в два раза лучше, чем 64-битный, — он в 2 в 64-й степени лучше, больше пространство у него. Один битик добавили — сразу пространство вдвое увеличивается. Теперь смотрите, я ещё раз повторюсь, что

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

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

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

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

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

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

во все основные темы. Я надеюсь, что вам понравилось, и надеюсь, что я доступно вам всё объясняю. Завтра будем продолжать, уже пойдём по техническим вещам, по таким именно уже по технике пойдём. Но всё, что мы с вами изучили за эти два дня, будет преследовать вас до конца курса, имейте в виду. Поэтому если что-то вдруг непонятно — можете сейчас спрашивать, я ещё никуда не ухожу, там минут 15–20. Можете писать там в чатик наш, разберёмся. Или пересмотрите запись — запись я сегодня Иннокентию отправлю, и он её выложит.