«Стой! Кто идет?»: аутентификация и авторизация в корпоративных системах

Открытый семинар для студентов в компании CUSTIS (22 октября 2015 года).
Лектор: Владислав Иофе, архитектор.

Transcript

1. 22 октября 2015 года Стой! Кто идет? Аутентификация и авторизация в корпоративных системах Владислав Иофе Архитектор
2. О компании 2/67 Проектирование Заказная разработка Бережное внедрение Масштабных IT-систем
3. О себе  В 2005 окончил мехмат Ташкентского государственного университета  С 2004 занимаюсь корпоративным программным обеспечением  В 2008 пришел в CUSTIS  Работал разработчиком, техлидом, тимлидом, сейчас занимаюсь архитектурой 3/67
4. Аннотация 4/67  При проектировании и реализации корпоративных систем всегда возникает целый ряд вопросов: нужно ли самим разрабатывать систему контроля доступа? Как аутентификация и авторизация встраиваются в архитектуру приложения? Возможно ли сделать вход в систему одновременно простым, удобным и безопасным? Что делать с паролями от сотен сайтов?!  На семинаре мы:  рассмотрим разные методы аутентификации и авторизации, попробуем обойти их  познакомимся с промышленными стандартами и современными трендами в этой сфере  дадим ответы на указанные вопросы с позиций проектировщика, пользователя, разработчика, тестировщика и инженера сопровождения  уделим особое внимание архитектуре и юзабилити  Семинар рассчитан на студентов и молодых специалистов, интересующихся проектированием, разработкой и сопровождением подсистем контроля доступа в корпоративных приложениях
5. Мотивация  Ни разу не специалист по информационной безопасности  Но в корпоративном ПО много «сквозной функциональности» (cross-cutting concerns)  Примеры:  Аутентификация (Authentication)  Авторизация (Authorization)  Кэширование (Caching)  Связь (Communication)  Обработка ошибок (Exception Management)  Журналирование (Logging)  Валидация (Validation) 5/67
6. Сквозная функциональность  Таких функциональностей много одновременно  Нам приходится знать, как они устроены  Мы хотим делать их удобными  Нам приходится думать, как их встраивать в приложение 6/67 Сегодня не будет  Математики  Криптографии  Информационной безопасности Зато будут  Методы  UX  Архитектура
7. План  Вступление, мотивация  Аутентификация  Терминология, способы и пр.  Протоколы  В атаку!  Single sign-on  Перерыв ☕  Аутентификация  UX  Настоящее и будущее  Авторизация  Виды  Архитектура  Зрелость модели контроля доступа  Заключение 7/67
8. Терминология  Идентификация (identification) – это установление идентификатора субъекта (пользователя или процесса). Иногда идентификацией называют сам факт присвоения идентификатора. 8/67
9. Терминология  Идентификация (identification) – это установление идентификатора субъекта (пользователя или процесса). Иногда идентификацией называют сам факт присвоения идентификатора.  Аутентификация (authentication, AuthN) – это проверка подлинности предъявленного субъектом идентификатора. В русском языке в термин вкрался досадный лишний слог. 8/67
10. Терминология  Идентификация (identification) – это установление идентификатора субъекта (пользователя или процесса). Иногда идентификацией называют сам факт присвоения идентификатора.  Аутентификация (authentication, AuthN) – это проверка подлинности предъявленного субъектом идентификатора. В русском языке в термин вкрался досадный лишний слог.  Авторизация (authorisation, authorization, AuthZ) – это определение и предоставление субъекту прав на выполнение определенных действий 8/67
11. Вопрос  Приведите примеры, в которых происходит идентификация без аутентификации? 9/67
12. Вопрос  Приведите примеры, в которых происходит идентификация без аутентификации? 9/67
13. Терминология и UX 10/67
14. Вопрос  Банк предоставляет услугу аренды сейфовой ячейки с анонимным доступом. Для доступа к ячейке достаточно предъявить специальную пластиковую карту (ранее выданную арендатору ячейки) и ключ 11/67
15. Вопрос  Банк предоставляет услугу аренды сейфовой ячейки с анонимным доступом. Для доступа к ячейке достаточно предъявить специальную пластиковую карту (ранее выданную арендатору ячейки) и ключ  Проводится ли в таком случае аутентификация? 11/67
16. Вопрос  Банк предоставляет услугу аренды сейфовой ячейки с анонимным доступом. Для доступа к ячейке достаточно предъявить специальную пластиковую карту (ранее выданную арендатору ячейки) и ключ  Проводится ли в таком случае аутентификация?  Кто несет ответственность при пропаже содержимого ячейки после посещения ячейки анонимным пользователем? 11/67
17. Способы аутентификации  Пароли  Public Key Infrastructure (PKI)  Токены – делегирование аутентификации 12/67
18. Парольная аутентификация  Очень распространенная  Очень уязвимая  48% пользователей сообщают пароли другим  3% – записывают на бумажке  60–70% – используют одинаковые пароли на всех сайтах  В среднем около десятка–двух паролей и ПИНов выдается каждому пользователю  … 13/67
19. Парольная аутентификация  Очень распространенная  Очень уязвимая  48% пользователей сообщают пароли другим  3% – записывают на бумажке  60–70% – используют одинаковые пароли на всех сайтах  В среднем около десятка–двух паролей и ПИНов выдается каждому пользователю  … 13/67 «Пароли мертвы…» Билл Гейтс, 2004
20. Повышение надежности  Срок действия пароля  Ограничения на длину снизу  Ограничения на символы  Прочие простые проверки  Не совпадает с логином  Не «123456789»  Не «qwerty»  Ограничение числа неудачных попыток ввода 14/67 http://goo.gl/Cc6vF7 СИМ-СИМ, ОТКРОЙСЯ! ХА! ТВОЙ ПАРОЛЬ ПРОСРОЧЕН! Квантовый скачок в «Тысяча и одной ночи»
21. 15/67 http://goo.gl/kyiefE Сообщения об ошибках, которые запутывают злоумышленников ПАРОЛЬ ВЕРНЫЙ, А ИМЯ ПОЛЬЗОВАТЕЛЯ НЕВЕРНОЕ!
22. Факторы аутентификации  Знание  Долговременный или одноразовый пароль, кодовое слово, ПИН, паспортные данные, … 16/67
23. Факторы аутентификации  Знание  Долговременный или одноразовый пароль, кодовое слово, ПИН, паспортные данные, …  Обладание  Мобильный, карта, … 16/67
24. Факторы аутентификации  Знание  Долговременный или одноразовый пароль, кодовое слово, ПИН, паспортные данные, …  Обладание  Мобильный, карта, …  Неотделимость  Отпечатки пальцев, радужная оболочка, сетчатка, голос, лицо, ДНК, подпись, … 16/67
25. Факторы аутентификации  Знание  Долговременный или одноразовый пароль, кодовое слово, ПИН, паспортные данные, …  Обладание  Мобильный, карта, …  Неотделимость  Отпечатки пальцев, радужная оболочка, сетчатка, голос, лицо, ДНК, подпись, …  Интегрированность в общество  Доверенные друзья 16/67
26. Многофакторная аутентификация  Требование нескольких факторов (часто разных категорий) существенно повышает стойкость 17/67
27. One-time Password (Single-use Password)  В составе двухфакторной аутентификации наиболее популярен  Защищает от утечки пароля или хэша 18/67
28. One-time Password (Single-use Password)  В составе двухфакторной аутентификации наиболее популярен  Защищает от утечки пароля или хэша 18/67  Навязчив → не подходит для типовых учетных записей
29. One-time Password (Single-use Password)  В составе двухфакторной аутентификации наиболее популярен  Защищает от утечки пароля или хэша 18/67  Навязчив → не подходит для типовых учетных записей  Компромисс – после ввода одноразового пароля сохранять для пары «пользователь-устройство» super-cookie
30. Risk-based authentication  В зависимости от степени риска проводимой операции или набора факторов может быть запрошена дополнительная аутентификация  Основной пароль для входа в интернет-банк, OTP для платежа  Ввод OTP на новом устройстве 19/67
31. Ау! Где мы? 20/67  Вступление, мотивация  Аутентификация  Терминология, способы и пр.  Протоколы  В атаку!  Single sign-on  Перерыв ☕  Аутентификация  UX  Настоящее и будущее  Авторизация  Виды  Архитектура  Зрелость модели контроля доступа  Заключение
32. Аутентификация в вебе: HTTP Basic  Логин и пароль передаются на сервер в открытом виде (base64 не в счет) 21/67
33. Аутентификация в вебе: HTTP Basic  Логин и пароль передаются на сервер в открытом виде (base64 не в счет) 21/67
34. В это время на сервере… 22/67
35. Аутентификация в вебе: HTTP Digest  Схема challenge-response  HA1=MD5(username:realm:password)  HA2=MD5(method:digestURI)  response=MD5(HA1:nonce:HA2) 23/67
36. Аутентификация в вебе: HTTP Digest  Схема challenge-response  HA1=MD5(username:realm:password)  HA2=MD5(method:digestURI)  response=MD5(HA1:nonce:HA2) 23/67
37. Аутентификация в вебе: Forms 24/67
38. Аутентификация в вебе: Forms 24/67
39. Аутентификация в вебе: Forms 24/67  Не стандартизована  Вы можете реализовать любой протокол передачи учетных данных сами!  После успешной аутентификации устанавливается сессия. Реализуется путем возврата с клиента выданного сервером authentication ticket-а (через cookie или в адресной строке)
40. Public and private key 25/67
41. Уязвимости 26/67 http://goo.gl/vmHsgw ВЫХОД НА ПОСАДКУ ГРАЖДАНКА! ВЫ ДОЛЖНЫ ВЫКИНУТЬ ЭТОТ ГЕЛЬ ДЛЯ РУК. В НЕМ 120 МЛ!
42. Атака Man-in-the-middle (MITM) 27/67 «Опочтарение» (англ. Going postal), 2010
43. Атака Man-in-the-middle (MITM) 28/67
44. Игра в MITM  Каждые два ряда делятся на три примерно равные команды  Каждая команда играет роли и Алисы, и Боба, и Мэллори  Реквизит  Пара ключей  Калькулятор (в режиме «Научный»)  Бумага и ручка 29/67 Онлайн калькулятор
45. Игра в MITM (2)  Задачи  Мэллори  Узнать пароль, который передала Алиса Бобу  Подменить пароль, передаваемый Бобу  Алисы и Боба  Честно шифровать и дешифровывать сообщения  E(e, n, m) = me mod n  D(d, n, c) = cd mod n  Вам выданы две пары ключей  Сообщение m от Алисы – это число от 2 до 9  Если вы скомпрометировали ваш закрытый ключ, вы можете запросить новую пару ключей у организаторов 30/67
46. Атака Man-in-the-middle (MITM) 31/67
47. Сертификат содержит:  Номер  Период действия  Владельца  Открытый ключ владельца  Реквизиты центра сертификации  Криптоалгоритм Public Key Infrastructure, сертификаты 32/67
48. Сертификат содержит:  Номер  Период действия  Владельца  Открытый ключ владельца  Реквизиты центра сертификации  Криптоалгоритм Public Key Infrastructure, сертификаты 32/67
49. Сертификат содержит:  Номер  Период действия  Владельца  Открытый ключ владельца  Реквизиты центра сертификации  Криптоалгоритм Public Key Infrastructure, сертификаты 32/67
50. Сертификат содержит:  Номер  Период действия  Владельца  Открытый ключ владельца  Реквизиты центра сертификации  Криптоалгоритм Public Key Infrastructure, сертификаты 32/67
51. Вопрос  А в чем может заключаться MITM-атака при digest-аутентификации? 33/67
52. Вопрос  А в чем может заключаться MITM-атака при digest-аутентификации? 33/67
53. Ау! Где мы? 34/67  Вступление, мотивация  Аутентификация  Терминология, способы и пр.  Протоколы  В атаку!  Single sign-on  Перерыв ☕  Аутентификация  UX  Настоящее и будущее  Авторизация  Виды  Архитектура  Зрелость модели контроля доступа  Заключение
54. Новые вводные  Передавать пароли кому попало – плохая идея! 35/67
55. Новые вводные  Передавать пароли кому попало – плохая идея!  Сколько же можно помнить и вбивать разных паролей?  Компрометация универсального пароля чревата 35/67
56. Новые вводные  Передавать пароли кому попало – плохая идея!  Делегирование аутентификации!  Сколько же можно помнить и вбивать разных паролей?  Компрометация универсального пароля чревата 35/67
57. Новые вводные  Передавать пароли кому попало – плохая идея!  Делегирование аутентификации!  Сколько же можно помнить и вбивать разных паролей?  Компрометация универсального пароля чревата  Single sign-on! 35/67
58. Kerberos 36/67  Сообщения между KDC и участниками шифруются  Сообщения от первой стороны для третьей стороны, передаваемое второй, шифруется общим ключом первой и третьей сторон  Двусторонняя аутентификация
59. Усиленная безопасность 37/67 http://goo.gl/HY9tbJ
60. Сильная аутентификация  Двухфакторная  Взаимная  Но односторонняя на сегодняшний день в вебе – норма 38/67
61. Central Authentication Service (CAS) Protocol 39/67
62. Single sign-out  Токен аутентификации / TGT действует довольно долго – например, рабочий день  Инвалидация токена аутентификации / TGT не приводит к мгновенному прекращению доступа к приложению  Так же инвалидация сессии приложения приведет к новой сессии (это же SSO!)  Инвалидация токена аутентификации / TGT приведет к запросу учетных данных при доступе к другому приложению в произвольный момент времени 40/67
63. Single sign-out  Токен аутентификации / TGT действует довольно долго – например, рабочий день  Инвалидация токена аутентификации / TGT не приводит к мгновенному прекращению доступа к приложению  Так же инвалидация сессии приложения приведет к новой сессии (это же SSO!)  Инвалидация токена аутентификации / TGT приведет к запросу учетных данных при доступе к другому приложению в произвольный момент времени  Конечно же, есть попытки обойти… Какие? 40/67
64. Неудобство и безопасность 41/67 http://goo.gl/6YIfa4 Все! Я автостопом! Контроль безопасности аэропорта Уберите жидкости, металлические предметы, снимите обувь и нижнее белье
65. Перерыв 42/67 ☕
66. Ау! Где мы? 43/67  Вступление, мотивация  Аутентификация  Терминология, способы и пр.  Протоколы  В атаку!  Single sign-on  Перерыв ☕  Аутентификация  UX  Настоящее и будущее  Авторизация  Виды  Архитектура  Зрелость модели контроля доступа  Заключение
67. Пользователи 44/67
68. Пользователи  Одни наедине с программой 44/67
69. Пользователи  Одни наедине с программой  Ленивы и любят комфорт 44/67
70. Пользователи  Одни наедине с программой  Ленивы и любят комфорт  Изобретательны в обходе неудобств 44/67
71. Пользователи  Одни наедине с программой  Ленивы и любят комфорт  Изобретательны в обходе неудобств  Хотят быть защищенными 44/67
72. Пользователи  Одни наедине с программой  Ленивы и любят комфорт  Изобретательны в обходе неудобств  Хотят быть защищенными  Самое слабое звено 44/67
73. Правило Что не так в юзабилити? Стремиться к согласованности Ok Уменьшать число действий в частых сценариях (например, «горячие клавиши») Пользователь не может использовать «горячие клавиши» Обеспечивать информативную обратную связь для каждого действия Невозможно/неудобно увидеть вводимый пароль Доводить диалоги до логического конца Ok Не провоцировать на ошибки и предлагать простую обработку ошибок Обычно системы только сообщают об успехе или неудаче. Была ли ошибка в логине или пароле или мы ошиблись в раскладке клавиатуры – узнать невозможно Разрешать отмену любого действия Системы отслеживают неудачные попытки и блокируют учетную запись Дать пользователю чувство управляемости системы и почувствовать ответственность Пользователь отвечает на запросы системы, а не является инициатором взаимодействий Кратковременную память загружать как можно меньше Пользователи должны помнить уйму правил: как часто менять пароль, сколько и каких символов, не забыть добавить специальные символы, раскладку и т. д. Authentication UX 45/67 Бен Шнейдерман, 1986
74. Правило Что не так в юзабилити? Стремиться к согласованности Ok Уменьшать число действий в частых сценариях (например, «горячие клавиши») Пользователь не может использовать «горячие клавиши» Обеспечивать информативную обратную связь для каждого действия Невозможно/неудобно увидеть вводимый пароль Доводить диалоги до логического конца Ok Не провоцировать на ошибки и предлагать простую обработку ошибок Обычно системы только сообщают об успехе или неудаче. Была ли ошибка в логине или пароле или мы ошиблись в раскладке клавиатуры – узнать невозможно Разрешать отмену любого действия Системы отслеживают неудачные попытки и блокируют учетную запись Дать пользователю чувство управляемости системы и почувствовать ответственность Пользователь отвечает на запросы системы, а не является инициатором взаимодействий Кратковременную память загружать как можно меньше Пользователи должны помнить уйму правил: как часто менять пароль, сколько и каких символов, не забыть добавить специальные символы, раскладку и т. д. А с точки зрения безопасности все эти меры предотвращают атаки по словарю, угадывание и социальную инженерию Authentication UX 45/67 Бен Шнейдерман, 1986
75. Сравнение видов аутентификации Вид Безопасность UX Пароли 2 2 Бесконтактные карты 3 3 Генераторы OTP 3 3 PKI (токены, УЭК и пр.) 5 3 Kerberos 5 3 Отпечатки, лицо и пр. 4 3 Подпись 3 3 Распознавание голоса 1 5 46/67
76. Настоящее и будущее: биометрия  Биометрия  Сетчатка  Радужная оболочка  Отпечатки пальцев  После терактов 9/11 IСAO (Международная организация гражданской авиации) разработала стандарты биометрических документов  Биометрическая аутентификация перспективна, но не может / не должна быть единственным способом 47/67
77. Настоящее и будущее: биометрия 48/67 Аутентификация жестом
78. Настоящее: протоколы, стандарты  CAS  SAML – SSO для веб, стандартизирует формат сообщений, а не метод аутентификации  OАuth – протокол аутентификации и авторизации. Можно использовать не только в веб, но он неинтероперабелен. В версии 2.0 за аутентификацию отвечает OpenID Connect. 49/67
79. Настоящее и будущее: FIDO Alliance Сосредоточен на разработке двух открытых расширяемых стандартов:  UAF – Universal Authentication Framework, беспарольная аутентификация с зарегистрированного устройства  U2F – Second Factor UX, двухфакторная аутентификация с помощью устройств и поддержкой браузера 50/67
80. Настоящее и будущее: FIDO Alliance 51/67
81. Ау! Где мы? 52/67  Вступление, мотивация  Аутентификация  Терминология, способы и пр.  Протоколы  В атаку!  Single sign-on  Перерыв ☕  Аутентификация  UX  Настоящее и будущее  Авторизация  Виды  Архитектура  Зрелость модели контроля доступа  Заключение
82. Этапы контроля доступа 53/67
83. Авторизация  Discretionary access control, DAC  Mandatory access control, MAC  Role-based access control, RBAC  Attribute-based access control, ABAC  Гибридные модели 54/67
84. Discretionary access control  Избирательное управление доступом  Для каждой пары субъект – объект задается перечисление допустимых разрешений (например: Read, Write, List, Execute)  Часто объект имеет привязанного субъекта-владельца. Владелец может устанавливать разрешения для других субъектов 55/67
85. Mandatory access control  Мандатное управление доступом  Объекты несут метку конфиденциальности  Субъект ограниченно управляет объектами, которыми владеет  Модель Белла – Лападулы  Субъекты также несут метку  “No read up”  “No write down” 56/67
86. Role-based access control  Управление доступом на основе ролей  Субъекту присваивается роль или роли  Выдаются разрешения заданным ролям  Реализует DAC и MAC  Может быть усложнен введением наследования ролей  Очень распространен в корпоративных приложениях  Пример: Пользователь может подтвердить заказ, если его роль – менеджер 57/67
87. Role-based access control  Управление доступом на основе ролей  Субъекту присваивается роль или роли  Выдаются разрешения заданным ролям  Реализует DAC и MAC  Может быть усложнен введением наследования ролей  Очень распространен в корпоративных приложениях  Пример: Пользователь может подтвердить заказ, если его роль – менеджер  Вопрос: Как ограничить менеджера только московскими заказами? 57/67
88. Attribute-based access control  Управление доступом на основе атрибутов  Субъекты и объекты наделяются атрибутами  Политики вычисляют условия, заданные через выражения атрибутов субъекта и объекта  Пример: Пользователь может подтвердить заказ, если подразделение пользователя равно подразделению, в котором создан заказ, и должность субъекта – менеджер 58/67
89. Сравнение методов контроля доступа 59/67 DAC RBAC ABAC Изменения без участия программиста ✔ ✔ ✔ Описание близко́ к бизнес-терминам ✘ ✔ ✔ Простота разработки ✔ ? ✘
90. Сравнение методов контроля доступа Кстати, в блоге CUSTIS на «Хабрахабре» вы можете найти статьи про ABAC:  http://habrahabr.ru/company/custis/blog/248649/  http://habrahabr.ru/company/custis/blog/258861/ 59/67 DAC RBAC ABAC Изменения без участия программиста ✔ ✔ ✔ Описание близко́ к бизнес-терминам ✘ ✔ ✔ Простота разработки ✔ ? ✘
91. Какая модель контроля доступа здесь используется? 60/67
92. Как сквозная функциональность «прорастает» 61/67
93. Как сквозная функциональность «прорастает» 61/67
94. Как можно улучшить (1) 62/67
95. Как можно улучшить (1) 62/67
96. Как можно улучшить (2) 63/67
97. Зрелость авторизации корпоративного ПО 64/67 Базовая Стандартная Усовершенствованная/ Федеративная Клиент-серверная архитектура N-уровневая архитектура Сервис- ориентированная архитектура Аутентификация как авторизация Обычно RBAC RBAC, доступны глобальные роли Каждое приложение реализует авторизацию Шлюз авторизации, возможна кроссплатформенная авторизация Контроль доступа на уровне ресурсов Контроль доступа на уровне приложения Авторизация через сервисную шину (ESB)
98. Другие смежные вопросы  Протоколы  SPNEGO/Negotiate  Темы  Identity and Access Management (IAM)  Access Management  User provisioning  Audit 65/67
99. Ау! Где мы? 66/67  Вступление, мотивация  Аутентификация  Терминология, способы и пр.  Протоколы  В атаку!  Single sign-on  Перерыв ☕  Аутентификация  UX  Настоящее и будущее  Авторизация  Виды  Архитектура  Зрелость модели контроля доступа  Заключение
100. Спасибо! Вопросы? 67/67 Владислав Иофе viofe@custis.ru