Для чего необходим алгоритм идентификации

18.04.202220.04.2022 admin 0 Comments

Как проводить идентификацию клиентов по 115-ФЗ

С 1 сентября вступают в силу поправки в «антиотмывочный» закон. Новая норма обяжет компании — субъекты 115-ФЗ отказывать в обслуживании клиентам, которые не предоставили идентификационные сведения.

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

В чем суть поправок

С 1 сентября вступает в силу норма, внесенная Федеральным законом от 30.12.2020 № 536-ФЗ. Если клиент не предоставил необходимые сведения, то компании — субъекты 115-ФЗ обязаны отказать ему в обслуживании. Например, если он не согласился раскрыть бенефициарного владельца организации, то банк не имеет права открыть счет такому клиенту.

Перечень сведений, которые нужно установить в отношении клиента, его представителя, выгодоприобретателя, бенефициарного владельца, достаточно большой. Он установлен Положениями Банка России № 444-П, № 499-П и Приказом Росфинмониторинга от 22.11.2018 № 366.

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

Ошибки при идентификации клиентов

Некоторые организации нарушают последовательность проведения идентификации, собирают неполный объем информации или не хранят анкеты клиентов — все это серьезные нарушения требований 115-ФЗ, которые могут привести к штрафам. Разберем типовые ошибки при идентификации клиентов подробнее.

Путают клиентов и контрагентов

Важно учитывать, что клиент и контрагент — не тождественные понятия. 115-ФЗ обязывает идентифицировать клиентов — юридических и физических лиц, иностранные структуры без образования юридического лица, но не контрагентов.

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

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

Используют копии документов

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

Не хранят анкеты клиентов

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

Анкета клиента в Контур.Призме соответствует необходимым требованиям нормативно-правовых актов о ПОД/ФТ и автоматически сохраняется в сервисе. Документ можно легко скачать и предъявить регулятору в случае проверки.

Не выявляют публичных должностных лиц

Бывает, что при идентификации не уточняют, является ли клиент или его родственниками публичными должностными лицами. Достаточно распространенная ситуация, когда в строке «Является ли клиент публичным должностным лицом», стоит прочерк или пустое место.

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

Проводят сверку с перечнями не в полном объеме

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

Не обосновывают уровень риска

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

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

Авторы: Павел Смыслов, учредитель Межрегионального учебного и консультационно-правового центра финансового мониторинга

Светлана Кирланова, эксперт Контур.Призмы по законодательству в сфере ПОД/ФТ и комплаенс-рискам

Не пропустите новые публикации

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

Источник

InfoQuark

Элементарные частицы информации

Статья об идентификации

Введение

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

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

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

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

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

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

Описание процедуры идентификации

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

— Получение или регистрацию данных об объекте (фиксацию данных об объекте),

— Получение идентификационных данных об объекте (распознание объекта),

— Извлечение собственных данных об объекте либо получение данных из внешних систем по идентификационным данным.

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

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

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

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

Регистрация данных об объекте

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

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

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

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

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

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

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

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

Пятая нормальная форма предполагает определенность (непротиворечивость) в значении свойств объекта.

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

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

Свойства, которые не должны быть идентифицирующими

— назначенные, но не переданные объекту свойства (например, признак налогового резидента или нерезидента страны, вычисленные по количеству дней пребывания – сам объект может не знать, является ли он или не является налоговым резидентом),

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

Использование внешних идентификаторов и назначение собственных идентификаторов

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

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

При назначении идентификаторов (суррогатных ключей) обычно применяются целые числа как счетчики либо случайные код с минимальной возможностью повторения (статистически уникальный – 3,4×10^38), например, GUID. Тем не менее, GUID, позволяя не отслеживать счетчик объектов, содержит достаточно большой код – 32 символа.

Классификация и идентификация

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

Процесс идентификации объекта состоит из нескольких шагов:

1) Определение типа (класса) объекта по свойствам, определяющим класс (например, легковой автомобиль)

2) Определение экземпляра объекта по идентифицирующим свойствам

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

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

Процедура классификации важна, если одна сущность (таблица) в базе данных и, соответственно, один первичный/альтернативный ключ используется для нескольких классов объекта. В таком случае идентификатор часто включает и класс объекта. Например, таблица запасы хранит данные по материалам, закупаемым компонентам, производимым компонентам и готовой продукции. В этом случае идентификатор может выглядеть как «xx-yyyyyy», где xx – класс запасов, а yyyyyy – идентификатор запасов (счетчик).

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

Упрощение

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

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

Де-идентификация

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

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

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

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

Источник

Идентификация товаров: понятие, виды, методы, способы, обзор средств

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

Определение понятия идентификации

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

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

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

Виды и методы идентификации товаров: что это

Для полного понимания термина следует привести классификацию. Основных критериев всего четыре:

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

По установлению принадлежности чему-либо. Это обрывки тканей, обломки тарелок, отдельные детали или части, по которым можно провести проверку.

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

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

Источник

Идентификация, аутентификация и авторизация — в чем разница?

Объясняем на енотах, в чем разница между идентификацией и авторизацией, а также зачем нужна аутентификация, тем более двухфакторная.

Это происходит с каждым из нас, причем ежедневно: мы постоянно идентифицируемся, аутентифицируемся и авторизуемся в разнообразных системах. И все же многие путают значение этих слов и часто употребляют термин «идентификация» или «авторизация», когда на самом деле речь идет об аутентификации.

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

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

Итак, что же значат термины «идентификация», «аутентификация» и «авторизация» — и чем соответствующие процессы отличаются друг от друга? Для начала проконсультируемся с «Википедией»:

Объясняем идентификацию, аутентификацию и авторизацию на енотах

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

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

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

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

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

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

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

Источник

Идентификация и аутентификация. Так ли все просто?

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

Требования нормативных документов к механизму идентификации и аутентификации.

Прежде всего, обратимся к формализованным требованиям в области защиты информации, попробуем в них найти ответ на вопрос, какими же функциями должен быть наделен механизм идентификации и аутентификации? Формализованные требования к механизму идентификации и аутентификации пользователей задаются действующим сегодня нормативным документом «Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации».

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

Заметим, что в требованиях к СВТ 4-го класса защищенности вообще задачи идентификации и аутентификации пользователя при входе в систему и при запросе на доступ разделены на две самостоятельные задачи, кроме того, здесь появляется некое понятие «субъект» в общем виде.

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

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

Задача идентификации и аутентификации субъекта «пользователь» при запросах на доступ

Этапы идентификации и аутентификации пользователя, реализуемые ОС Windows

Этапы идентификации и аутентификации пользователя, реализуемые в системе (на примере ОС Windows), представлены на рис. 1.

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

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

Рис.1. Этапы идентификации и аутентификации пользователя

В порядке замечания отметим следующее. С одной стороны, это очень полезная опция, которая может быть использована в корпоративных приложениях, когда на одном компьютере требуется обрабатывать конфиденциальные и открытые данные. При этом предполагается, что для обработки данных различных категорий создаются различные учетные записи. Данная опция предполагает, что одновременно (без перезагрузки) можно обрабатывать данные различных категорий, например, под одной учетной записью обрабатывать необходимым приложением конфиденциальные данные, под другой учетной записью запустить Internet-приложение (у Вас на мониторе может быть открыто одновременно два окна). Естественно, что реализация данной возможности выставляет и дополнительные требования к СЗИ от НСД (например, при подобном запуске приложения ОС Windows между пользователями не изолируется буфер обмена, который в ОС является «принадлежностью» рабочего стола).

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

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

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

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

Рис.2. Укрупненный алгоритм идентификации и аутентификациипри запросе доступа к ресурсу

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

Ограничения возможности корректного решения задачи

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

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

Заметим, что в нормативном документе «Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации» вопросы контроля доступа пользователей к устройствам (начиная с СВТ 4-го класса защищенности) формируются в виде отдельного требования: КСЗ должен включать в себя механизм, посредством которого санкционированный пользователь надежно сопоставляется с выделенным ему конкретным устройством.

Чтобы понять суть существующих ограничений, проанализируем, как ОС Windows (в ОС семейства Unix рассматриваемые проблемы не столь критичны, т.к. устройства в них монтируются к файловой системе) работает с устройствами, и сразу натолкнемся на проблему (решения рассматриваемой задачи, реализуемые собственно ОС Windows, рассматривать не будем, т.к. они не удовлетворяют требованиям применения в корпоративных приложениях). Проблема здесь состоит в том, что многие устройства предполагают возможность взаимодействия с ними приложения не напрямую, а через драйвер. В этом случае запрос доступа к устройству осуществляется от лица пользователя System (варианты решения задачи на прикладном уровне рассматривать не будем, ввиду их априорной уязвимости). Возникает вопрос, а откуда взять идентификатор пользователя, который инициировал это обращение к устройству. Можно, конечно, «посмотреть», какой пользователь зарегистрирован в системе, и фильтровать запросы доступа применительно к его учетной записи (кстати говоря, подобный подход реализуется некоторыми специализированными средствами защиты). Но не будем забывать, что современные ОС Windows многопользовательские. Как отмечалось выше, начиная с Windows XP, возможность входа в многопользовательский режим уже вынесена в интерфейс (например, из проводника можно по правой кнопки мыши выбрать опцию запуска приложения с правами другого пользователя – получим многопользовательский режим). В многопользовательском режиме в системе одновременно зарегистрировано уже несколько пользователей, при этом выявление учетной записи, от которой осуществлен запрос доступа к устройству, становится неразрешимой (или, по крайней мере, весьма сложно корректно решаемой) задачей.

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

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

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

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

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

Задача идентификации и аутентификации субъекта «процесс» при запросах на доступ.

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

Однако на практике не менее актуальной является задача разграничения прав доступа к ресурсам для субъекта «процесс».В общем случае именно процесс следует рассматривать в качестве источника возникновения внешней ИТ-угрозы. Тому может быть несколько причин, что следует из приведенной классификации известных типов вирусов, положим их в основу классификации процессов, несущих в себе угрозу:

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

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

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

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

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

Заметим, что техническое решение, реализующее данный подход, нами запатентовано (А.Ю.Щеглов. Система разграничения доступа к ресурсам, патент №2207619, приоритет от 12.07.2001).

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

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

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

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

В предлагаемой нами реализации для локализации программной среды необходимо регламентировать права доступа к папкам (каталогам, подкаталогам), из которых пользователям разрешено (запрещено) запускать исполняемые файлы. С учетом принятых правил размещения приложений и необходимости запуска системных процессов, целесообразно разрешать выполнение программ только из каталогов \Program Files, куда следует устанавливать приложения, и \Winnt (WINDOWS). А чтобы предотвратить возможность модификации санкционированных исполняемых файлов, запись пользователям в эти каталоги, напротив, следует запретить.

Вопросы корректности идентификации объекта доступа

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

В NTFS файловый объект может быть идентифицирован различными способами:

1\»;
• файловые объекты, задаваемые русскими (либо в иной кодировке) буквами, также имеют короткое имя, которое формируется с использованием кодировки Unicode (внешне они могут существенно различаться), например короткое имя для каталога «C:\Documents and Settings\USER1\Главное меню» выглядит как «C:\Docume

1\». К этим объектам также можно обратиться как по длинному, так и по короткому имени;
• файловый объект идентифицируется не только именем, но и своим идентификатором (ID) – индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым объектам не по имени, а именно по ID.

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

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

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

Таким образом, проведя данное исследование, видим, насколько сложна задача идентификации и аутентификации как в своей постановке в общем виде, так и в решении, если, конечно, говорить о построении эффективного средства защиты информации, сколько механизмов защиты должно быть реализовано в составе СЗИ от НСД для решения данной задачи в общем виде. А если хотя бы одного из рассмотренных механизмов в средстве защиты нет – уже уязвимость! Кстати говоря, о термине «эффективность» в данных приложениях. Заметим, что СЗИ от НСД не может обладать высокой или низкой эффективностью (это не параметр производительности). СЗИ от НСД либо защищает, либо нет. Если существует хотя бы один канал обхода средства защиты, рано или поздно им воспользуется злоумышленник, как следствие, в этом случае правомерно утверждать, что данная СЗИ от НСД не обладает потребительской стоимостью (или просто бессмысленна для практического использования). Здесь невольно возникает вопрос (это уже в части формализации требований к СЗИ от НСД – сегодня очень актуальный вопрос), а как подразделять СЗИ от НСД на какие-либо классы или группы? СЗИ от НСД высокого класса обеспечивает защиту, а низкого нет (иного не дано)? Напрашивается вывод о том, что подобное разделение СЗИ от НСД на какие-либо группы или классы по функциональным возможностям и по набору механизмов защиты недопустимо! Тогда на основании чего могут быть введены классификационные признаки СЗИ от НСД?

Источник

Для чего мы создаем…

Для чего необходим алгоритм идентификации

Как проводить идентификацию клиентов по 115-ФЗ

В чем суть поправок