механизмы управления доступом и аутентификации ос windows

Двухфакторная аутентификация в Windows и шифрование данных без центра сертификации и домена

Сегодня расскажем, как можно быстро и просто настроить двухфакторную аутентификацию и зашифровать важные данные, причем даже с возможностью использования биометрии. Решение будет актуально для небольших компании или просто для персонального компьютера или ноутбука. Важно, что для этого нам не потребуется инфраструктура открытых ключей (PKI), сервер с ролью центра сертификации (Certificate Services) и даже не потребуется домен (Active Directory). Все системные требования будут сводиться к операционной системе Windows и наличию у пользователя электронного ключа, а в случае биометрической аутентификацией еще и считывателю отпечатка пальцев, который, например, может быть уже встроен в ваш ноутбук.

Для аутентификации будем использовать ПО нашей разработки – JaCarta SecurLogon и электронный ключ JaCarta PKI в качестве аутентификатора. Инструментом шифрования будет штатный Windows EFS, доступ к зашифрованным файлам будет осуществляться также через ключ JaCarta PKI (тот же, который используется для аутентификации).

Напомним, JaCarta SecurLogon — сертифицированное ФСТЭК России программно-аппаратное решение компании Аладдин Р.Д., позволяющее осуществить простой и быстрый переход от однофакторной аутентификации на основе пары логин-пароль к двухфакторной аутентификации в ОС по USB-токенам или смарт-картам. Суть работы решения довольно проста — JSL генерирует сложный пароль (

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

EFS также как и JSL умеет работать в режиме standalone, не требуя кроме самой ОС ничего. Во всех операционных системах Microsoft семейства NT, начиная с Windows 2000 и новее (кроме home версий), существует встроенная технология шифрования данных EFS (Encrypting File System). EFS-шифрование основано на возможностях файловой системы NTFS и архитектуре CryptoAPI и предназначено для быстрого шифрования файлов на жестком диске компьютера. Для шифрования в EFS используется закрытый и открытый ключи пользователя, которые генерируются при первом использовании пользователем функции шифрования. Данные ключи остаются неизменными все время, пока существует его учетная запись. При шифровании файла EFS случайным образом генерирует уникальный номер, так называемый File Encryption Key (FEK) длиной 128 бит, с помощью которого и шифруются файлы. Ключи FEK зашифрованы мастер-ключом, который зашифрован ключом пользователей системы, имеющего доступ к файлу. Закрытый ключ пользователя защищается хэшем пароля этого самого пользователя. Данные, зашифрованные с помощью EFS, могут быть расшифрованы только с помощью той же самой учетной записи Windows с тем же паролем, из-под которой было выполнено шифрование. А если хранить сертификат шифрования и закрытый ключ на USB-токене или смарт-карте, то для доступа к зашифрованным файлам потребуется еще и этот USB-токен или смарт-карта, что решает проблему компрометации пароля, так как будет необходимо наличие и дополнительного устройства в виде электронного ключа.

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

Как уже отметили, для настройки не нужен AD или центр сертификации, нужен любой современный Windows, дистрибутив JSL и лицензия. Настройка проста до безобразия.

Нужно установить файл лицензии.

Добавить профиль пользователя.

И начать пользоваться двухфакторной аутентификацией.

Биометрическая аутентификация

Есть возможность использовать биометрическую аутентификацию по отпечатку пальца. Решение работает по технологии Match On Card. Хэш отпечатка записывается на карту при первичной инициализации и в дальнейшем сверяется с оригиналом. Из карты никуда не уходит, в каких-то базах не хранится. Для разблокировки такого ключа используется отпечаток или комбинация ПИН + отпечаток, ПИН или отпечаток.

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

В дальнейшем такое же окно будет всплывать перед входом в ОС.

В настоящем примере карта инициализирована с возможностью аутентификации по отпечатку или ПИН-коду, о чем и сообщает окно аутентификации.

После предъявления отпечатка или ПИН-кода, пользователь попадет в ОС.

Шифрование данных

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

Для выпуска сертификата шифрования и закрытого ключа откройте учетную запись пользователя, выберите — Управление сертификатами шифрования файлов. В открывшемся мастере, создайте самозаверенный сертификат на смарт-карте. Так как мы продолжаем использовать смарт-карту с BIO-апплетом, для записи сертификата шифрования нужно предъявить отпечаток или ПИН.

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

Далее система еще раз попросит ввести ПИН или предьявить отпечаток, произойдет непосредственный выпуск сертификата на смарт-карту.

Далее нужно настроить конкретные директории. В нашем примере — это папка Документы в хомяке пользователя. Откройте свойства папки и укажите — Шифровать содержимое для защиты данных.

Далее укажите применять настройки только к текущей папке или включить все вложенные поддиректории.

Сама шифрованная директория и файлы в ней будут подсвечены другим цветом.

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

На этом вся настройка окончена.

Можно использовать оба сценария (аутентификация и шифрование), можно остановиться на чем-то одном.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

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

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

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

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

Локальная аутентификация

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

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

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

LAN Manager (LM)

Протокол LAN Manager возник на заре зарождения локальных сетей под управлением Windows и впервые был представлен в Windows 3.11 для рабочих групп, откуда перекочевал в семейство Windows 9.х. Мы не будем рассматривать этот протокол, так как в естественной среде он уже давно не встречается, однако его поддержка, в целях совместимости, присутствует до сих пор. И если современной системе поступит запрос на аутентификацию по протоколу LM, то, при наличии соответствующих разрешений, он будет обработан.

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

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

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

NT LAN Manager (NTLM)

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

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

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

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

В случае получения доступа к третьим ресурсам схема также немного изменяется:

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

Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

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

NTLMv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

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

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

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

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Настройки безопасности

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

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

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

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

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

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

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник

Лекция 5. Протоколы сетевой аутентификации. Модели разграничения доступа. Вредоносное программное обеспечение.

Локальная аутентификация Windows

Локальная аутентификация в операционных системах Windows выполняется в следующей последовательности:

Рис. 1. Схема работы локальной аутентификации Windows

Протоколы сетевой аутентификации

Существует несколько различных протоколов, описывающих процесс аутентификации субъектов в локальной сети. В рамках операционных систем Windows компании Микрософт использовались протоколы:

Рассмотрим актуальные на данный момент протоколы аутентификации – NTLM v2 и Kerberos.

Протокол NTLM v2.

Схема работы протокола NTLMv2 с контроллером домена

Рис. 2. Схема работы протокола NTLMv2 с контроллером домена

Протокол аутентификации Kerberos

Протокол использует понятие Ticket (билет, удостоверение).

KDC состоит из двух компонент:

Рис. 3. Схема работы протокола Kerberos

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

В качестве примера реализации протокола Kerberos следует отметить доменную аутентификацию пользователей в операционных системах компании Microsoft, начиная с Windows 2000.

Протоколы аутентификации для удалённого доступа

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

Такими протоколами являются:

В качестве примера кратко рассмотрим работу протокола RADIUS.

Протокол аутентификации RADIUS

Протокол аутентификации Remote Authentication Dial-in User Service (RADIUS) 2 рассматривается как механизм аутентификации и авторизации удалённых пользователей в условиях распределённой сетевой инфраструктуры, предоставляющий централизованные услуги по проверке подлинности и учёту для служб удалённого доступа.

В рамках стандарта выделяются следующие роли:

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

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

Посредник RADIUS. Взаимодействие клиентов и серверов RADIUS осуществляется посредством специальных сообщений. В распределённых сетях клиент и сервер RADIUS могут быть разделены различными сетевыми устройствами (такими, например, как маршрутизатор). Под посредником RADIUS понимается сетевое устройство, способное осуществлять перенаправление сообщений протокола RADIUS.

Поддержка протокола RADIUS реализована на многих современных платформах, что позволяет использовать его в межплатформенных решениях.

В качестве примера сервера и посредника RADIUS можно привести реализованную в Windows Server 2003 службу проверки подлинности в Интернете (Internet Authentication Service, IAS). Эта служба позиционируется как механизм централизованной аутентификации и авторизации пользователей, использующих различные способы подключений к сети. Служба IAS интегрирована с другими сетевыми службами Windows Server 2003, такими, как служба маршрутизации и удалённого доступа и служба каталога Active Directory.

Авторизация – модели разграничения доступа

Для более подробного изучения механизмов авторизации рассмотрим следующие модели разграничения доступа:

Discretionary access control (дискреционная модель разграничения доступа)

Существуют два подхода к построению дискреционного управления доступом:

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

Mandatory access control (мандатная модель разграничения доступа)

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

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

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

Требования к мандатному механизму управления доступом:

Рис. 4. Чтение информации в мандатной модели

Рис. 5. Запись информации в мандатной модели

Достоинства.

Недостатки.

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

Role-based access control (ролевая модель разграничения доступа)

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

Если бизнес-правила одномерны и все действия можно распределить по ролям (бухгалтер, менеджер, администратор и т. п.), такого подхода будет достаточно. Тогда одному бизнес-правилу будет соответствовать одна роль.

Рис. 6. Распределение ролей по бизнес правилам в ролевой модели

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

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

Рис. 7. Рост многомерности бизнес правил

После каждого добавления нового значения атрибута придется добавлять новые роли. То есть, если появится филиал «Г», то придется добавить новые роли, такие как «Администратор филиала «Г», «Менеджер филиала «Г», «Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Это порождает много рутинного ручного труда.

Кроме этого, появляются и другие недостатки:

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

Рис. 8. Бизнес-правила с атрибутами, значения которых заранее не известны

Бизнес-правила, которые ограничивают доступ не к действиям, а к данным, также невозможно выразить с помощью ролевой модели:

Рис. 9. Бизнес-правила, которые ограничивают доступ не к действиям, а к данным

Attribute-based access control (модель разграничения доступа на основе атрибутов)

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

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

Можно явно выделить несколько категорий атрибутов:

Рис. 10. Несколько категорий атрибутов

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

Простые правила описываются простыми условиями.

Рис. 11. Пример простых бизнес правил

Многомерные правила в этой модели не становятся более сложными

Рис. 12. Пример многомерных бизнес правил

ABAC позволяет избежать проблем, которые появляются в RBAC:

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

Рис. 13. Пример бизнес правил с применением фильтра

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

Таблица 1. Сравнение ABAC и RBAC

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

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

Вредоносное программное обеспечение

Обзор актуальной вирусной активности на сайте https://news.drweb.ru/

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

Вредоносное ПО (malware – сокращение от malicious software) – это различные программы, которые могут наносить вред.

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

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

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

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

Признаки возможного заражения компьютера:

Категории угроз

Рекламные программы

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

Рекламное ПО/шпионское ПО

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

Приложение из неизвестного источника

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

Backdoor-программы

Для организации кражи данных или манипуляции с компьютером, backdoor-программа удаленного администрирования проникает в систему через черный ход, о чем пользователь, как правило, даже не догадывается. Через Интернет или ЛВС клиентская часть такой программы (Client) может управляться третьими лицами.

Файлы со скрытыми расширениями

Исполняемые файлы, скрывающие настоящие расширения файлов. Этот метод сокрытия часто используется вредоносным ПО.

Фишинг

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

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

# Личное имя и имя пользователя.

# Адрес и номер телефона.

# Паспортные данные или PIN-код.

# Номер банковского счета.

# Номер дебетовой или кредитной карточки.

# Код проверки карточки (CVC) или контрольное число карточки (CVV).

# Номер социального страхования.

Программы-шутки

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

Все симптомы таких развлекательных программ могут быть также имитированы вирусами или троянами.

Обманная программа

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

Bot-сети

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

Эксплойт

Скрытый майнер (stealth miner, майнер-бот, ботнет)

К данной категории относятся программы, которые в автоматическом режиме ведут майнинг криптовалют незаметно для пользователя. Это стороннее ПО, которое устанавливается на компьютер, использует его ресурсы и перечисляет все заработанные средства на криптовалютный кошелек разработчика.

Фарминг

Источник