Как осуществляется аутентификация пользователя в розничной точке. Интеллектуальные карточки кроме памяти имеют собственный микропроцессор. Это позволяет реализовать различные варианты парольных методов защиты, например, многоразовые пароли, динамически ме

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

Идентификационные данные

Идентифицировать пользователя, запускающего приложение, можно за счет применения идентификационных данных (identity) . Класс WindowsIdentity позволяет представлять пользователя Windows. Помимо учетной записи Windows для идентификации пользователя можно также использовать другие классы, реализующие интерфейс IIdentity . Этот интерфейс позволяет получать доступ к имени пользователя, а также к информации о том, прошел ли данный пользователь аутентификацию, и о применяемом типе аутентификации.

Принципалом (principal) называется объект, в котором содержатся идентификационные данные пользователя и роли, к которым он принадлежит. Интерфейс IPrincipal имеет свойство Identity, которое возвращает объект Ildentity, и метод IsInRole, с помощью которого можно проверить, действительно ли пользователь является членом конкретной роли.

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

В.NET доступны следующие классы принципалов: WindowsPrincipal и GenericPrincipal . Однако помимо них также можно создавать собственные специальные классы принципалов, реализующие интерфейс IPrincipal.

В следующем примере демонстрируется создание консольного приложения, предоставляющего доступ к принципалу, которое, в свою очередь, позволяет получать доступ к лежащей в основе учетной записи Windows.

Сначала понадобится импортировать пространства имен System.Security.Principal и System.Threading. Далее нужно указать, что.NET должна автоматически подключать принципал к соответствующей учетной записи Windows, поскольку из соображений безопасности.NET автоматически не заполняет свойство потока CurrentPrincipal. Сделать это можно следующим образом:

Using System; using System.Collections.Generic; using System.Linq; using System.Security.Principal; using System.Threading; namespace ConsoleApplication1 { class Program { static void Main(string args) { AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal); } } }

Для получения доступа к деталям учетной записи Windows можно использовать метод WindowsIdentity.GetCurrent() , однако он больше подходит в ситуации, когда доступ к принципалу требуется получить лишь один раз. Если нужен многократный доступ к принципалу, лучше с помощью метода SetPrincipalPolicy установить политику так, чтобы текущий поток сам предоставлял доступ к принципалу. Этот метод указывает, что принципал в текущем потоке должен хранить объект Windows Identity.

Все предназначенные для идентификации классы, подобные Windows Identity, реализуют интерфейс IIdentity. Этот интерфейс имеет три свойства (AuthenticationType, IsAuthenticated и Name), которые должны быть обязательно реализованы во всех производных идентификационных классах.

Добавьте следующий код для получения доступа к свойствам принципала из объекта Thread:

WindowsPrincipal principial = (WindowsPrincipal)Thread.CurrentPrincipal; WindowsIdentity identity = (WindowsIdentity)principial.Identity; Console.WriteLine("Тип идентификации: " + identity.ToString()); Console.WriteLine("Имя: " + identity.Name); Console.WriteLine("Пользователи? " + principial.IsInRole(WindowsBuiltInRole.User)); Console.WriteLine("Администраторы? " + principial.IsInRole(WindowsBuiltInRole.Administrator)); Console.WriteLine("Аутентифицирован: " + identity.AuthenticationType); Console.WriteLine("Анонимный? " + identity.IsAnonymous); Console.WriteLine("маркер: " + identity.Token);

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

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

Декларативное обеспечение безопасности на основе ролей

Безопасность на основе ролей (role-based security) особенно полезна в ситуациях, когда получение доступа к ресурсам играет критически важную роль. Главным тому примером может служить сфера финансовой деятельности, где исполняемые сотрудниками роли определяют то, к какой информации они могут получать доступ, и какие действия они могут предпринимать.

Безопасности на основе ролей идеально подходит для применения вместе с учетными записями Windows или специальным каталогом пользователей для управления доступом к веб-ресурсам. Например, на веб-сайте незарегистрированным пользователям может предоставляться лишь ограниченный доступ к его содержимому, а платным подписчикам - напротив, дополнительный доступ к специальному содержимому.

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

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

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

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

Как и при защите доступа кода, запросы безопасности на основе ролей (например, такие как "пользователь должен обязательно находиться в группе администраторов") можно реализовать либо императивно за счет вызова метода IsInRole() из класса IPrincipal, либо с помощью атрибутов. Требования относительно полномочий можно задавать декларативно на уровне класса или метода с помощью атрибута .

Using System; using System.Security; using System.Security.Principal; using System.Security.Permissions; namespace ConsoleApplication1 { class Program { static void Main(string args) { AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal); try { ShowMessage(); } catch (SecurityException exception) { Console.WriteLine("Исключение " + exception.Message); } finally { Console.ReadLine(); } } static void ShowMessage() { Console.WriteLine("Текущий принципиал зарегистрировался локально и является членом группы Users"); } } }

При выполнении этого приложения в контексте пользователя, не являющегося членом локальной группы Windows под названием Users (Пользователи), метод ShowMessage() будет генерировать исключение.

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

Каждый вопрос экзамена может иметь несколько ответов от разных авторов. Ответ может содержать текст, формулы, картинки. Удалить или редактировать вопрос может автор экзамена или автор ответа на экзамен.

Идентификация

Для этого пользователь должен себя идентифицировать - указать своё «имя» (идентификатор). Таким образом,проверяется, относится ли регистрирующийся пользователь к пользователям, идентифицируемым системой. И в соответствии с введённым идентификатором пользователю будут сопоставлены соответствующие права доступа.

Аутентификация

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

Совокупность выполнения процедур идентификации и аутентификации принято называть процедурой авторизации

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

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

• на предъявлении пользователем пароля;
• на предъявлении пользователем доказательств, что он обладает секретной ключевой информацией;
• на ответах на некоторые тестовые вопросы;
• на предъявлении пользователем некоторых неизменных признаков, неразрывно связанных с ним;
• на предоставлении доказательств того, что он находится в определенном месте в определенное время;
• на установлении подлинности пользователя некоторой третьей, доверенной стороной.

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

подобного рода. Этот процесс называется авторизацией . Таким образом, вход пользователя в систему состоит из идентификации, аутентификации и авторизации. В процессе дальнейшей работы иногда может появиться необходимость дополнительной авторизации в отношении каких-либо действий.

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

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

Идентификация призвана каждому пользователю (группе пользователей) сопоставить соответствующую ему разграничительную политику доступа на защищаемом объекте.
Для этого пользователь должен себя идентифицировать - указать своё «имя» (идентификатор). Таким образом,проверяется, относится ли регистрирующийся пользователь к пользователям, идентифицируемым системой. И в соответствии с введённым идентификатором пользователю будут сопоставлены соответствующие права доступа.
Аутентификация предназначена для контроля процедуры идентификации. Для этого пользователь должен ввести пароль. Правильность вводимого пароля подтверждает однозначное соответствие между регистрирующимся пользователем и идентифицированным пользователем.
В общем случае, идентифицируются и аутентифицируются не только пользователи, но и другие субъекты доступа к ресурсам.
Совокупность выполнения процедур идентификации и аутентификации принято называть процедурой авторизации . Иногда не требуется идентифицировать пользователя, а достаточно только выполнения процедуры аутентификации. Например, это происходит когда требуется подтвердить текущего (уже зарегистрированного) пользователя при выполнении каких-либо действий, требующих дополнительной защиты. В свою очередь, не всегда требуется осуществлять контроль идентификации, то есть в некоторых случаях аутентификация может не производиться.
Процедура авторизации имеет ключевое значение при защите компьютерной информации, т.к. вся разграничительная политика доступа к ресурсам реализуется относительно идентификаторов пользователей. То есть, войдя в систему с чужим идентификатором, злоумышленник получает права доступа к ресурсу того пользователя, идентификатор которого был им предъявлен при входе в систему.
Требования к идентификации и аутентификации
Формализованные требования к данным механизмам защиты состоят в следующем:
. Должны осуществляться идентификация и проверка подлинности субъектов доступа при входе в систему по идентификатору (коду) и паролю условно-постоянного действия длиной не менее шести буквенно-цифровых символов (для классов защищенности 1Г и 1В по классификации АС)
. Система защиты должна требовать от пользователей идентифицировать себя при запросах на доступ.
. Система защиты должна подвергать проверке подлинность идентификации — осуществлять аутентификацию. Для этого она должна располагать необходимыми данными для идентификации и аутентификации.
. Система защиты должна препятствовать доступу к защищаемым ресурсам неидентифицированных пользователей и пользователей, подлинность идентификации которых при аутентификации не подтвердилась (для 5 класса защищенности по классификации СВТ). Для 3 класса защищенности по классификации СВТ вводится дополнительное требование: система защиты должна обладать способностью надежно связывать полученную идентификацию со всеми действиями данного пользователя.
Кроме ограничения «...паролю условно-постоянного действия длиной не менее шести буквенно-цифровых символов... » данные требования никак не формализуют подходы к реализации механизмов парольной защиты. Кроме того, данные требования не определяют, каким образом должны быть реализованы механизмы парольной защиты, а также не накладывают дополнительных ограничений, связанных с повышением стойкости пароля к подбору. В частности, они не регламентируют использование внешних носителей парольной информации — дискет, смарт-карт и т.д.
Дополнительные требования:
Существует целая группа угроз, связанная с некорректностью реализации процедуры авторизации в современных ОС, а также с наличием ошибок в реализации соответствующих механизмов защиты. Это обусловливает целесообразность рассмотрения механизмов авторизации с целью их добавочной защиты. Кроме того, механизмы идентификации и аутентификации являются важнейшими для противодействия НСД к информации, а значит, следует рассматривать возможные варианты их резервирования.
Кроме того, в рамках декларируемого системного подхода к проектированию системы защиты, при разработке механизмов авторизации следует рассматривать как явные, так и скрытые угрозы преодоления защиты.
Авторизация в контексте количества и вида зарегистрированных пользователей
Кого следует воспринимать в качестве потенциального злоумышленника/
1. В системе зарегистрирован один пользователь
Данный пользователь является и прикладным пользователем, и администратором безопасности. Здесь источником потенциальной угрозы является только сторонний сотрудник предприятия, а вся задача защиты сводится к контролю доступа в компьютер (либо в систему), т.е. к парольной защите.
Данный случай является вырожденным и нами далее не рассматривается, т.к. в соответствии с формализованными требованиями к защите информации от НСД даже при защите конфиденциальной информации предполагается обязательное наличие администратора безопасности.
2. В системе зарегистрированы администратор безопасности и один прикладной пользователь
Общий случай функционирования системы с одним прикладным пользователем — это наличие в системе администратора безопасности и только одного прикладного пользователя. В задачи администратора безопасности здесь входит ограничение прав прикладного пользователя по доступу к системным (администратора безопасности) и иным ресурсам компьютера. В частности, может ограничиваться набор задач, разрешенных для решения на компьютере, набор устройств, которые могут быть подключены к компьютеру (например, внешний модем, принтер и т.д.), способ сохранения обрабатываемых данных (например, на дискетах только в шифрованном виде) и т.д.
В данном случае потенциальным злоумышленником в части несанкционированного использования ресурсов защищаемого объекта может являться как сторонний сотрудник предприятия, так и собственно прикладной пользователь. Заметим, что прикладной пользователь здесь может выступать в роли сознательного нарушителя, либо стать «инструментом» в роли стороннего нарушителя, например, запустив по чьей-либо просьбе какую-нибудь программу).
3. В системе зарегистрированы администратор безопасности и несколько прикладных пользователей
Кроме администратора безопасности, в системе может быть заведено несколько прикладных пользователей. При этом ресурсами защищаемого компьютера могут пользоваться несколько сотрудников, решая различные задачи. Ввиду этого информационные и иные ресурсы защищаемого объекта должны между ними разграничиваться.
В данном случае к потенциальным нарушителям добавляется санкционированный прикладной пользователь, целью которого может служить НСД к информации, хранимой на защищаемом объекте другим пользователем.
При использовании компьютера (прежде всего, рабочей станции) в составе ЛВС, помимо локальных ресурсов защищаемого объекта, защите подлежат сетевые ресурсы.
В этом случае между пользователями могут разграничиваться права по доступу к серверам, сетевым службам, разделенным сетевым ресурсам (общим папкам и устройствам, например, к сетевым принтерам) и т.д.
Здесь злоумышленник (санкционированный пользователь) может осуществлять попытку получить НСД к сетевому ресурсу, к которому ему доступ не разрешен, с целью осуществления на него атаки с рабочей станции.
Рекомендации по построению авторизации, исходя из вида и количества зарегистрированных пользователей
Наиболее простой в реализации защитой является защита от стороннего сотрудника. В этом случае все мероприятия по защите возлагаются на использование механизма парольного входа.
Простота состоит в том, что, как увидим далее, в этом случае следует оказывать противодействие только явным угрозам преодоления парольной защиты, от которых защититься не представляет большого труда.
Однако основной угрозой служат преднамеренные или неумышленные действия санкционированного пользователя, который обладает возмож-ностью осуществления скрытой атаки на защищаемый ресурс (например, запустив какую-либо программу собственной разработки).
Механизмы идентификации и аутентификации должны предусматривать противодействие всем потенциальным злоумышленникам, т.е. как сторонним по отношению к защищаемому объекту, так и санкционированным пользователям, зарегистрированным на компьютере. При этом речь идет о прикладных пользователях, т.к. осуществить какую-либо защиту от НСД к информации от администратора безопасности невозможно, даже включая применение механизмов криптографической защиты (он сумеет снять информацию до момента ее поступления в драйвер шифрования).
С учетом сказанного можем сделать следующие выводы:
1. На защищаемом объекте, как правило, зарегистрированы, по крайней мере, два пользователя — прикладной пользователь и администратор безопасности. Поэтому в качестве потенциального злоумышленника при реализации механизмов парольной защиты в общем случае следует рассматривать не только стороннее по отношению к защищаемому объекту лицо, но и санкционированного пользователя, который преднамеренно либо неумышленно может осуществить атаку на механизм парольной защиты.
2. Рассматривая атаки на парольную защиту следует учитывать, что по сравнению со сторонним лицом, которое может характеризоваться явными угрозами парольной защите, защита от атак санкционированного пользователя качественно сложнее, т.к. им могут быть реализованы скрытые угрозы.
Классификация задач, решаемых механизмами идентификации и аутентификации (схема)
Классификация задач по назначению защищаемого объекта
Основу классификации задач, решаемых механизмами парольной защиты, составляет назначение защищаемого объекта (компьютера). Именно в соответствии с назначением объекта определяется перечень защищаемых ресурсов и источников угроз (потенциальных злоумышленников).

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

Естественно, и аутентификацию, и авторизацию используют не только в процессе получения доступа к сетевым аккаунтам. Автоматизированные системы, EDI, передача данных, пластиковые банковские карты – мы не один раз в день проходим эти процедуры в автоматическом режиме.

В англоязычных системах путаницы с терминологией не возникает: пользователь вообще не задумывается, чем отличается аутентификация от авторизации, ведь обе процедуры от его глаз скрыты. Предлагается «войти в систему» – «log in, logging in».

Сравнение

Как проходит процедура аутентификации? Вот некий пользователь вознамерился прочитать свежий спам в своем электронном почтовом ящике. Он заходит на сайт почтового сервиса, читает рекламу и новости, но никаких писем ему пока не показывают – система не знает ни о его личности, ни о его намерениях. Когда в форму ввода логина и пароля он впишет свои «username/qwerty» и отправит эту информацию, начнется процесс аутентификации. Система проверит, существует ли пользователь с таким именем, совпадает ли введенный пароль с его учетной записью. Во многих случаях соответствия подобных идентификаторов достаточно, однако сервисы, где безопасность данных в приоритете, могут запрашивать и другие сведения: наличие сертификата, определенный IP-адрес или дополнительный код верификации.

Пройденная аутентификация означает, что пользователь действительно тот, кем представляется. Однако этого мало для предоставления ему доступа к данным – начинается процесс авторизации. В случае с почтовыми сервисами клиенты имеют равные права: каждый из них может просматривать письма и документы, редактировать их и создавать новые. А вот в социальных сетях или на форумах посетители принадлежат к определенной группе, и авторизация помогает системе определить, что позволено Юпитеру и не позволено быку. К примеру, у вас нет права писать сообщения пользователю, который добавил вас в черный список; вы не можете добавлять в сообщения ссылки на видео, пока не набрали определенное количество постов; вы можете просматривать фотографии человека, добавившего вас «в друзья». В локальных системах у учетной записи пользователя может не быть доступа к некоторым программам, стоять запрет на редактирование или копирование документов.

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

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

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

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

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

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

Наконец-то открывается заветная дверь, и охранник допускает сотрудника к определенной двери. Допуск получен — состоялась авторизация .

В виртуальном мире все практически так же, как в реальном. Только имена “персонажей” меняются. Сотрудник охраны — это сервер, контролирующий вход на сайт. А пришедший на работу менеджер — пользователь, который хочет попасть в свой аккаунт.

Следует добавить, что процедура будет повторяться каждый день — даже тогда, когда все охранники будут знать менеджера и в лицо, и по имени. Просто у охраны такая работа. У сервера тоже.

Все три понятия — этапы одного и того же процесса, который управляет доcтупом пользователей к их аккаунтам.

Чтобы выполнить какие-либо действия на сайте, клиент должен “представиться” системе. Идентификация пользователя — предъявление им оснований для входа на сайт или сервис. Обычно в роли идентификаторов выступают логин или адрес электронной почты, указанный при регистрации. Если сервер находит в своей базе данные, совпадающие с указанными, то происходит идентификация клиента.

Логин — это, конечно, прекрасно. Но где гарантия, что ввел его именно тот человек, который зарегистрирован на сайте? Чтобы окончательно убедиться в подлинности пользователя, система обычно проводит аутентификацию.

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

• одноразовый пароль или PIN-код;
• магнитные карты, смарт-карты, сертификаты с цифровой подписью;
• биометрические параметры: голос, сетчатка глаза, отпечатки пальцев.

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

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

Может быть как односторонней — когда только пользователь доказывает системе свою истинность, так и двусторонней — сервер и клиент взаимно подтверждают свою подлинность по системе “запрос-ответ”. Такой тип 2FA используется в токене Protectimus Ultra и позволяет, среди прочего, устранить риск попадания на фишинговые сайты.

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

Между терминами “авторизация” и “аутентификация” разница довольно значительна. Часто можно услышать или прочитать в интернете выражение “двухфакторная авторизация”, но оно, строго говоря, не является корректным. Ведь авторизация пользователя — это предоставление ему полномочий в какой-либо системе, окончательный ответ на вопрос: “Можно ли допустить этого человека к той или иной информации или функциям?”. И в силу своей однозначности авторизация никак не может быть двухфакторной.

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

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

В операционной системе Windows 7 реализовано новое поколение технологий безопасности для рабочего стола и одна из них аутентификация и авторизация. Часть технологий направлена на укрепление общей инфраструктуры Windows, а остальные на оказание помощи в управлении системой и пользовательскими данными.

Прежде чем устанавливать в Windows 7 эффективные меры безопасности, например, для совместного пользования файлами и папками, важно понимать используемые во время настройки безопасности типы учетных записей пользователей, и как сетевой протокол аутентифицирует и авторизует вход пользователей в систему.

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

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

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

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

Процесс авторизации и аутентификации.

Для получения доступа к файлам в сети пользователи для проверки их личности должны проходить аутентификацию. Это делается во время процесса входа в сеть. Операционная система Windows 7 для входа в сеть имеет следующие методы аутентификации:

• Протокол Kerberos версии 5: Основной метод аутентификации клиентов и серверов под управлением операционных систем Microsoft Windows. Он используется для проверки подлинности учетных записей пользователей и учетных записей компьютеров.
• Windows NT LAN Manager (NTLM): используется для обратной совместимости с операционными системами более старыми, чем Windows 2000 и некоторых приложений. Он менее гибок, эффективен и безопасен, чем протокол Kerberos версии 5.
• Сопоставление сертификатов: обычно используется для проверки подлинности при входе в сочетании со смарт-картой. Сертификат, записанный на смарт-карте, связан с учетной записью пользователя. Для чтения смарт-карт и аутентификации пользователя используется считыватель смарт-карт.

Новые функции аутентификации в Windows 7.

Целый ряд улучшений, связанных с процессами входа и проверки подлинности пользователя был добавлен еще в Windows Vista ®. Эти усовершенствования увеличили базовый набор функции проверки подлинности, чтобы помогло обеспечить лучшую безопасность и управляемость. В Windows 7 Microsoft продолжает начатые в Windows Vista усовершенствования, предоставляя следующие новые функции аутентификации:

• Смарт-карты
• Биометрия
• Интеграция личности в Интернете.

Смарт-карты.

Использование смарт-карт самый распространенный метод аутентификации. Для поощрения применения организациями и пользователями смарт-карт, Windows 7 предлагает новые возможности, облегчающие их использование и развертывание. Эти новые возможности позволяют использовать смарт-карты для выполнения разнообразных задач, включая:

• Смарт-карты Plug and Play
• Личные удостоверения проверки (PIV), стандарт национального института стандартов и технологий США (NIST)
• Поддержка для входа смарт-карты Kerberos.
• Шифрование дисков BitLocker
• Документы и электронная почта
• Использование с бизнес-приложениями.

Биометрия.

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

До сих пор в Windows не было стандартной поддержки биометрических устройств. Чтобы решить эту проблему, Windows 7 вводит Windows Biometric Framework (WBF). WBF предоставляет новый набор компонентов, поддерживающий снятие отпечатка пальца с помощью биометрические устройства. Эти компоненты увеличивают безопасность пользователей.

Windows Biometric Framework упрощает пользователям и администраторам настройку и управление биометрическими устройствами на локальном компьютере или в домене.

Интеграция личности в Интернете.

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

Интеграцией онлайн идентификации можно управлять политикой группы. Политика, настроенная как: “Сетевая безопасность: Позволить этому компьютеру при запросе идентификации PKU2U использовать ID онлайн”, управляет возможностью ID онлайн подтвердить подлинность этого компьютера при помощи протокола PKU2U. Этот параметр политики не влияет на способность учетных записей доменов или локальных учетных записей пользователей входить на этот компьютер.