Остальные материалы цикла:

• Аутентификация клиентов в сетевых службах при помощи цифровых сертификатов — подведение итогов

Данная серия постов заказана и оплачена благотворительным фондом винниклОлега Крылова и всех-всех-всех.

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

Password-based authentication background

Почти всю свою историю человек использует аутентификацию на основе комбинации логин и пароль. Логин уникально идентфицирует пользователя, а пароль (или секретное слово) подтверждает, что я — это я, а не Вася, который выдаёт себя за меня. Но давайте посмотрим слабые места парольной аутентификации в IT:

• Пароли очень короткие (5-8 символов);

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

• Пароли забываются;

Действительно пароль вида $gf)a90sfLq*wrF4 запомнить нелегко. С очень высокой долей вероятности, что пользователь после удачных выходных вряд ли в понедельник утром вспомнит его — звонок в тех.поддержку. Пока решается его вопрос с паролем, пользователь простаивает и ничего не делает, просто любуется экраном логона. Но можно выйти из ситуации и обойтись без звонка в тех.поддержку:

• Пароли записываются на бумажки и приклеиваются на монитор;

Я думаю, что многие администраторы с таким встречались. Поскольку наши пользователи очень современны, они часто обитают на различных интернет-ресурсах, форумах, чатах и прочих социальных сетях. Чтобы не сильно забивать себе голову паролями:

• Один и тот же пароль используется для множества сетевых ресурсов одновременно;

Нередко, когда пользователь зарегистрирован в десятке (а то и в десятках) мест, где используется один и тот же пароль. Потерял 1 пароль — потерял доступ всюду. Лично я не в состоянии удержать в голове все пароли от всех (да хотя бы топ-10) сайтов, где я бываю. Признаюсь, что у меня есть секретный текстовый файл, где я записываю все свои пароли и на сегодняшний день он имеет размер в 5кб. Я знаю, что это несекурно, но пока ничего лучше не придумал (если есть идеи, можете их озвучить в комментариях).

Об этом можно говорить долго и упорно, но смысла это не добавит, поэтому переходим дальше.

Introduction to certificate-based authentication

Цифровые сертификаты — это альтернативная форма идентификации пользователя. Здесь и далее я буду говорить про цифровые сертификаты в контексте Active Directory.

Цифровой сертификат — это документ, защищённый цифровой подписью (т.е. защищён от подделки), который содержит необходимую информацию о его владельце, которая позволяет уникально идентифицировать пользователя. Эта информация включает как минимум логонную информацию (адрес учётной записи в каталоге Active Directory или его User Principal Name — UPN). Поскольку цифровые сертификаты это часть инфраструктуры открытого ключа, они обязательно содержат открытый ключ.

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

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

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

Смарт-карта это устройство со встроенным микрочипом, который хранит цифровой сертификат и закрытый ключ от него. Микрочип устроен так, что извлечь закрытый ключ из него не представляется возможным, а получить доступ можно только путём ввода отдельного пароля, называемым PIN (Personal Identification Number). Ряд смарт-карт оборудуются дополнительным элементом физической защиты, при разрушении которой уничтожаются и хранимые на них ключи и сертификаты. Это защитная мера, которая предотвращает доступ к ключам и защищённой этими ключами информации при попытке физического доступа к микрочипу, что и есть главное условие безопасности.

Где можно применять аутентификацию пользователей по сертификатам?

В Microsoft Windows мы можем применять пользовательские сертификаты для:

• Интерактивного логона в домен (требуется смарт-карта);
• Логона на сервер терминалов при помощи Remote Desktop (требуется смарт-карта);
• Аутентификации на веб-странице;
• Аутентификации в VPN;
• Аутентификации в 802.11х сетях (они же wireless).
• Аутентификации в ActiveSync;
• и ещё по мелочам.

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