Файл: Интернет вещей безопасность Основные принципы, методы. Безопасности цифровой судебной экспертизе.doc

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 22.11.2023

Просмотров: 98

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.


(c) Информационная гранулярность: поставщик услуг может совершенствовать его поведение и данные, которые оно должно обеспечить согласно тому, что указано в маркере возможности. Рисунок 2.3 иллюстрирует использование основанного на возможности подхода управления доступом для управления простой ситуацией: Bob должен уехать в отпуск, и его дому нужно некоторое обслуживание, в то время как он отсутствует. Dave предложил заботиться о доме Bob's в течение периода своего праздника. Bob предоставляет Dave маркер доступа что: (a) определяет, что Dave дали право единственному предмету использовать маркер, (b) состояния, что Dave может на самом деле выполнить и (c) состояния для того, сколько дней Dave может сделать эти действия.

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



Рисунок 2.3 Пример ACL по сравнению с основанными на возможности моделями авторизации.

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

CapBAC архитектурные элементы может быть вскоре охарактеризован следующим образом (рисунок 2.4):

• Объект ресурса возможности (Обслуживают на рисунке 2.4); это могут быть определенные данные или устройство, сервис или любой доступный элемент, который может быть недвусмысленно определен и/или игровой на (как ресурс);

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


Возможность доступа Г1









Рисунок 2.4 Основанная на возможности авторизация архитектурные компоненты и их interactions.additional информация (например, срок действия возможности, условия XACML, и т.д.). Возможность авторизации допустима, как указано в самой возможности или пока она явно не отменяется;

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

• Запрос сервиса/операции является запросом на обслуживание, как предусматривается предоставленной услугой с единственными дополнительными характеристиками, чтобы отослать или включать, нековким способом, возможностью. Например, для УСПОКОИТЕЛЬНОГО сервиса, HTTP-запрос GET на одном из выставленных ресурсов REST должен просто включать возможность и ее доказательство владения для использования нашего механизма управления доступом;

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

• Менеджер ресурсов является сервисом, который управляет запросами сервиса/доступа на определенный ресурс. Менеджер ресурсов проверяет приемлемость маркера возможности, поставленного с запросом на обслуживание, а также законностью и конгруэтностью требуемого сервиса/операции против представленной возможности. Это действует как Точка осуществления политики (PEP) XACML, которая рассматривает результат проверки PDP;



• Сервис аннулирования отвечает за руководящие аннулирования возможности.

2.3.3 GAMBAS адаптивное промежуточное программное обеспечение (вклад GAMBAS)

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

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

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

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


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

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

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

2.3 Вклад из проектов FP7 31



2.3.4 Архитектура ЙОТЫ (вклад ЙОТЫ)

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


Эти технические возможности были проанализированы и организованы в Functional Groups (FG) и Функциональных компонентах (FC) в кадре WP1. Спецификации PS&T высокого уровня были интегрированы в кадре Архитектурной эталонной модели (ARM) ЙОТЫ и затем переданы вертикальному контакту WPs с протоколами связи (WP3), инфраструктурные услуги (WP4), а также аспекты аппаратного обеспечения (WP5). Из-за очень разнородной среды, обеспеченной IoT и огромным количеством подключенных, (автономных) устройств, предсказанных аналитиками, сильный фокус был помещен в масштабируемость и совместимость.

Документ [5] ARM прокладывает путь к пониманию и принятию открытой архитектуры ЙОТЫ, а также предоставляет полное определение безопасности IoT, конфиденциальности и доверительных стратегий проектирования, которые мы приняли. Затем в WP3 мы проанализировали безопасность коммуникации в периферийной части IoT и его влияния на полную коммуникационную архитектуру. В этом контексте мы исследовали HIP и протоколы HIP-BEX, а также рассмотрели проблемы как мобильность, совместное ключевое установление, и защищающий запись сети с PANA/EAP.

Затем в рамках WP4 [6] мы разработали безопасную инфраструктуру разрешения для ЙОТЫ. Это гарантирует конфиденциальность, и безопасность для разрешения функционирует и предлагает основание для других технических возможностей безопасности вне инфраструктуры разрешения. Это управляет доступом к ресурсам IoT к объектам реального мира, и к сопутствующей информации включая их соответствующие идентификаторы. Кроме того, инфраструктура разрешения также оказывает поддержку для псевдонимности: пользователь не должен показывать его идентификационные данные при использовании ресурса IoT или высокоуровневого сервиса. Для достижения всего этого различные компоненты безопасности были разработаны (рисунок 2.6). Они имеют дело с авторизацией и аутентификацией, ключевым обменом и управлением, доверием и репутацией и управлением идентификационными данными.

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



Рисунок 2.6 Компоненты для конфиденциальности и безопасности в инфраструктуре разрешения ЙОТЫ.

Функции PS&T архитектуры ЙОТЫ будут протестированы в предстоящей ЙОТЕ eHealth вариант использования.