Доверие в сфере ИТ

Доверие в сфере информационных технологий

Термины и определения

Может показаться странным, но доверие ни что иное как основа безопасности. Это относится и к сфере информационных технологий в том числе. Как же так? Как эти понятия вообще могут сочетаться? С этими вопросами мы, как раз, и разберемся в этой статье.
Прежде всего было бы неплохо понять, а что же такое доверие. Если мы говорим, что оно и есть основа безопасности, то хотелось бы не только представлять не только, скажем так на «понятийном» уровне что это такое, но и получить четкое определение этого термина. Для этого обратимся к источникам. Можно определить этот термин так, как это делается в Энциклопедическом словаре Брокгауза и Эфрона (1890-1907) [1].
Доверие — так называется психическое состояние, в силу которого мы полагаемся на какое-либо мнение, кажущееся нам авторитетным, и потому отказываемся от самостоятельного исследования вопроса, могущего быть нами исследованным [1].
Казалось бы, определение дано на рубеже XIX-XX веков, когда люди еще не имели представления об информационных технологиях, вместе с тем, не потеряло актуальности и сегодня. Впрочем, скоро мы в этом убедимся.
В продолжении этого определения говорится
Доверие отличается как от веры, так равно и от уверенности. Вера превышает силу внешних фактических и формально логических доказательств. Доверие же касается вопросов, находящихся в компетенции человеческого познания; доверяется тот, кто не хочет или не может решить или сделать чего-либо сам, полагаясь или на общепризнанное мнение, или на авторитетное лицо. Уверенность есть сознание собственной силы и состоит в доверии к истинности своего знания или правоте своего дела, доверие, напротив, проистекает из сознания слабости, неуверенности в себе, признания авторитета. Доверие, как термин, имеет иногда значение юридическое (например, злоупотребление доверием) [1].

История вопроса

Если обратиться к истории, то мы увидим, что роль доверия огромна, например, в ране средневековые китайские источниках [2] говорится о существовании дощечек с такими надписями: «Серебряная дощечка для проезда на казенных лошадях по Государеву повелению».
Подобные символы доверия встречаются и у монголов. См. рис. 1.
В период правления Чингисхана и позже [3]. Так знатные чиновники первого ранга носили на поясе золотую дощечку с изображением тигровой головы, на которой китайскими иероглифами было написано: «Указ пожалованного Небом императора Чингиса. Должен вести дела по усмотрению!» Следующая по значимости — простая золотая дощечка, на которой сказано: «Указ пожалованного Небом императора Чингиса. Спешно!» Серебряная пластина с той же надписью являлась знаком третьего ранга.
Знаменитый путешественник Марко Поло [4] подробно описывал пайцзы, которые получали от хана Хубилая его военачальники:
• серебряная – давалась сотнику;
• золотая или серебряная с позолотой – тысячнику;
• золотая с львиной головой (весящая в два раза больше чем у сотника или тысячника) – командующему туменом. Это 10 000 воинов.
• серебряная с кречетом – князю, правителю, с властью, подобной хану (улусному правителю).
Некоторые пайцзы сохранились и представлены в музеях, например, можно увидеть некоторые из них в Эрмитаже, Историческом музее, музее Метрополитен.


Рисунок 1 Пайцза

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

Рисунок 2 Пайцза с надписями на трех языках

Если еще раз обратиться к определению, «мы полагаемся на какое-либо мнение, кажущееся нам авторитетным» и рассматривать наш первый пример с историей Чингиcхана, то в буквальном смысле доверие было завоевано силой оружия. Мало кто сомневался, что непослушание воле хана повлекло бы самые серьезные последствия, информирование завоеванного и не только населения было очень развито. Надо отдать должное «средствам массовой информации» монгольской империи. Доверенная третья сторона – сам Чингисхан.
В обычной жизни, мы также сталкиваемся с вопросами доверия и самый простой пример – нотариат. Оформляя какие-либо важные документы, например, договор купли-продажи квартиры или дома, мы заверяем их у нотариуса, который является доверенной третьей стороной для всех участников сделки, то есть ему априори должны доверять все участники взаимодействия. Для выполнения своей деятельности нотариус должен иметь образование и сдать экзамены, получить государственную лицензию установленного образца и назначение. Только после этого он сможет приступить к работе. Если нотариус потерял доверие, у него отозвали лицензию, то с заверенными им документами, возникают проблемы, но об этом чуть позже.
Мы использовали еще один термин – доверенная третья сторона – орган, подтверждающий всем участникам взаимодействия их легитимность.

Примеры доверия в ИТ сфере

Вернемся к нашей предметной области, оказывается, с точки зрения фундаментальных принципов, в IT сфере все происходит точно также. Нет, конечно, пока что без явного кровопролития, но основная схема такая же – использование доверенной третьей стороны, которой доверяют все участники взаимодействия. Если эта доверенная третья сторона, в силу тех или иных причин скомпрометирована, то все участники взаимодействия теряют возможность ее использования, но обо всем по-порядку.
Снова посмотрим на примеры из реальной жизни. Подключаясь к личному кабинету банка, для выполнения онлайн операций хотелось бы понимать, что это именно тот сайт, который нужен и передаваемые данные не будут перехвачены. Разумеется, в этой ситуации требуется доверять банку. Только вот напрямую это не работает. Откуда может возникнуть уверенность, что работа происходит с легитимным ресурсом и что данные не перехватываются злоумышленником? Репутация банка не гарантирует безопасной передачи информации, не говорит о том, что мы не ошиблись, набирая адрес в браузере, и, в конце концов, не обеспечивает выдачу правильной ссылки в поисковой системе. Получается, что доверять некоторому сайту, который, возможно, только притворяется легитимным, мы не можем. Нужен кто-то или что-то в ком мы абсолютно уверены, кто и подтвердит нам что сайт, к которому мы пытаемся подключиться, именно тот, что нам нужен и он не подменен и передача данных будет защищена.
Для этого служит доверенная третья сторона, роль которой исполняет удостоверяющий центр или как еще его называют центр сертификации, являющийся компонентом инфраструктуры открытых ключей [4].
Именно удостоверяющий центр выдаст и подпишет, тем самым подтвердив их легитимность, все сертификаты, которыми, в нашем примере мы и воспользуемся, чтобы проверить, что взаимодействуем с легитимным веб сайтом, и даст нам возможность обеспечить безопасный информационный обмен, гарантируя конфиденциальность и целостность передаваемой информации.
Вот эта доверенная третья сторона и становится для нас центром абсолютного доверия. Если мы получили от нее подтверждение, что сайт интернет магазина или банка, так скажем, «правильный», то для нас это означает, безопасность работы с ним. Получается, что не только банк, с которым мы работаем должен доверять удостоверяющему центру, выдавшему сертификат на его портал, но и клиенты банка также должны доверять этому же центру. Следует понимать, что на приобретение доверие требуется много времени и сил, а исчезнуть оно может очень быстро. Примеров краха крупных компаний вследствие потери доверия, более, чем достаточно. Так что роль доверенной третьей стороны чрезвычайно высока.
Технически, для клиента, доверие к публичным центрам сертификации уже реализовано в настройках самой операционной системы путем внесения сертификатов этих центров в параметрах настройки [5]. Так это выглядит в операционных системах Microsoft См. рис. 3
При желании, список можно изменить, например, добавить свой ЦС. Как это делается, мы увидим в серии статей о внедрении инфраструктуры открытых ключей. Надо отметить, что этот список может изменяться разработчиком в процессе установки обновлений.
Все это не дает ответа на вопрос: «На основании чего мы сами принимаем решение о том доверять или нет удостоверяющему центру?» Техническая реализация – это ответ на вопрос «как сделать или как сделано», но не на вопрос: «почему именно так».


Рисунок 3 Доверенные корневые удостоверяющие центры

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

Рисунок 4 Знакомство с политиками
Эта информация должна предоставляться в Certification Practice Statement, доступ к которому можно получить в свойствах цифрового сертификата. См. рис. 5


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

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

Статья опубликована в журнала «Системный Администратор»

Литература

[1] Энциклопедическом словаре Брокгауза и Эфрона (1890-1907)
[2] Книга Марко Поло // История монголов / Д. Плано Карпини. Путешествие в восточные страны / Г. де Рубрук. Книга Марко Поло. — М.: Мысль, 1997. — ISBN 5-244-00851-Х.
[3] Мэн-да бэй-лу («Полное описание монголо-татар») / Примечания 484-499. Перевод Н. Ц. Мункуева. — М.: Наука, 1975. — 73-74 с
[4] Active Directory Certificate Services (AD CS) Public Key Infrastructure (PKI) Design Guide social.technet.microsoft.com/wiki/contents/articles/7421.active-directory-certificate-services-ad-cs-public-key-infrastructure-pki-design-guide.aspx
[5] Trusted Root Certification Authorities Certificate Store docs.microsoft.com/en-us/windows-hardware/drivers/install/trusted-root-certification-authorities-certificate-store
[6] Manage Trusted Root Certificates technet.microsoft.com/en-us/library/cc754841(v=ws.11).aspx
[7] Manage Trusted Root Certificates winintro.ru/certmgr.en/html/d84b0b2f-1338-4c36-b363-747a4c09f47e.htm

eToken жил, eToken жив, eToken будет жить.

В последнее время меня часто спрашивают, что случилось с ключами eToken и почему их перестали продавать. Так же наблюдается некоторая паника по этому поводу, ввиду того, что большинство мировых вендоров поддерживает данные ключи в своих продуктах, а заменить их, получается нечем.
Отставить панику! Ключи eToken никуда не исчезли, они продолжают выпускаться и продаваться на российском рынке. Да, они поменяли своё название и немного по-другому выглядят, но это всё те же eToken.

Читать дальше →

Проектирования Инфраструктуры Открытых Ключей на основе Microsoft PKI

Проектирования Инфраструктуры Открытых Ключей.
Часть № 2


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

Читать дальше →

Проектирования Инфраструктуры Открытых Ключей на основе Microsoft PKI

Часть № 1
Теоретические основы.


Безопасность сети формируется из комплекса элементов, один из важнейших – инфраструктура открытых ключей. Теоретические основы проектирования PKI [1] рассматривается в этой статье.

Читать дальше →

Аутентификация на основе одноразовых паролей в Active Directory. Теоретические основы.

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

Читать дальше →

Выбор средств двухфакторной аутентификации для Active Directory Domain Services

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

Введение

В «Системном Администраторе» а также в других изданиях, посвященных ИТ технологиям и вопросам информационной безопасности, неоднократно упоминалось о принципиальной ненадежности парольной аутентификации, а также крайней нежелательности использования запоминаемых паролей. Это особенно актуально в эпоху облачной эры, на пороге которой мы находимся. Вероятность компрометации конфиденциальной информации будет только возрастать. Разумным решением будет переход к более надежным методам доступа, а именно к двухфакторной аутентификации, причем вариантов технологических решений, как мы имели возможность убедиться в предыдущих материалах, множество. Здесь мы говорим и о технологиях асимметричной криптографии, о биометрическом доступе, использовании одноразовых паролей и т. д. На что же следует обратить внимания при выборе варианта двухфакторной аутентификации при том многообразии вендоров, которые существуют сегодня на рынке ИБ? Разумеется, я не буду рекомендовать конкретного поставщика решений.
Целью этой статьи является сделать обзор необходимых для корпоративного заказчика набора технологий, базируясь на которых можно выбрать конкретное решение для реализации в рамках службы каталога Active Directory. Рассмотрим аутентификацию на основе смарт карт и USB ключей.

Читать дальше →

Введение в инфраструктуру открытых ключей на примере Microsoft PKI

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

Читать дальше →

Двухфакторная аутентификация. Теоретические основы. Часть №2.

Внедрение двухфакторной аутентификации на основе асимметричной криптографии в AD DS


Служба каталога Active Directory поддерживает возможность аутентификации с помощью смарт карт, начиная с Windows 2000.
По сути своей, возможность аутентификации с помощью смарт карт заложена в расширении PKINIT (public key initialization — инициализация открытого ключа) для протокола Kerberos RFC 4556. См. [1]. Расширение PKINIT позволяет использовать сертификаты открытого ключа на этапе предаутентификации Kerberos.
Благодаря чему и появляется возможность использования смарт карт. Т. е. мы можем говорить о возможности двухфакторной аутентификации в системах Microsoft на основе штатных средств, начиная с ОС Windows 2000, т. к. уже реализована схема Kerberos + PKINIT.

Читать дальше →

Двухфакторная аутентификация. Теоретические основы. Часть 1.

Введение. Знакомство с терминологией.

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

Читать дальше →

Какие бывают OTP устройства?

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

Читать дальше →