Войти
В компьютерная безопасность, сертификат атрибута или сертификат авторизации (AC) - это цифровой документ, содержащий атрибуты, связанные с держателем эмитентом. Когда связанные атрибуты в основном используются с целью авторизации, AC называется сертификатом авторизации . AC стандартизирован в X.509. RFC 5755 дополнительно определяет использование для авторизации в Интернете.
Сертификат авторизации работает вместе с сертификатом открытого ключа (PKC). В то время как PKC выдается центром сертификации (CA) и используется в качестве подтверждения личности его владельца, как паспорт, сертификат авторизации выдается (AA) и используется, чтобы охарактеризовать или дать право своему владельцу, как виза. Поскольку идентификационная информация редко меняется и имеет длительный срок действия, в то время как информация об атрибутах часто меняется или имеет короткий срок действия, необходимы отдельные сертификаты с разными уровнями безопасности, сроками действия и издателями.
AC похож на PKC, но не содержит открытого ключа, потому что верификатор AC находится под контролем эмитента AC, и, следовательно, доверяет эмитенту напрямую, имея предварительно установленный открытый ключ эмитента. Это означает, что после взлома закрытого ключа эмитента AC эмитент должен сгенерировать новую пару ключей и заменить старый открытый ключ во всех верификаторах под его контролем новым.
Для проверки AC требуется наличие PKC, который упоминается как держатель AC в AC.
Как и в случае с PKC, AC можно связать, чтобы делегировать атрибуцию. Например, сертификат авторизации, выданный Алисе, разрешает ей использовать определенную службу. Алиса может делегировать эту привилегию своему помощнику Бобу, выдав AC для PKC Боба. Когда Боб хочет использовать службу, он представляет свой PKC и цепочку AC, начиная с его собственного AC, выданного Алисой, а затем AC Алисы, выданного эмитентом, которому служба доверяет. Таким образом, служба может проверить, что Алиса делегировала свои привилегии Бобу и что Алиса была авторизована на использование службы эмитентом, который контролирует службу. RFC 3281, однако, не рекомендует использовать цепочки AC из-за сложности администрирования и обработки цепочки, а также из-за небольшого использования AC в Интернете.
Чтобы использовать службу или ресурс, которыми управляет издатель AC, пользователь представляет PKC и AC части службы или ресурса, которая функционирует как AC верификатор. Верификатор сначала проверит личность пользователя с помощью PKC, например, попросив пользователя расшифровать сообщение, зашифрованное открытым ключом пользователя в PKC. Если аутентификация прошла успешно, верификатор будет использовать предварительно установленный открытый ключ эмитента AC для проверки действительности представленного AC. Если AC действителен, верификатор проверит, соответствует ли PKC, указанный в AC, представленному PKC. Если он совпадает, верификатор проверит срок действия AC. Если AC все еще действителен, проверяющий может выполнить дополнительные проверки, прежде чем предлагать пользователю определенный уровень обслуживания или использования ресурсов в соответствии с атрибутами, содержащимися в AC.
Например, разработчик программного обеспечения, у которого уже есть PKC, хочет развернуть свое программное обеспечение на вычислительном устройстве, использующем DRM, например iPad, где программное обеспечение может быть запущен на устройстве только после утверждения программного обеспечения производителем устройства. Разработчик программного обеспечения подписывает программное обеспечение с помощью закрытого ключа PKC и отправляет подписанное программное обеспечение производителю устройства для утверждения. После аутентификации разработчика с помощью PKC и проверки программного обеспечения производитель может принять решение о выпуске AC, предоставляющего программному обеспечению базовую возможность установки и запуска, а также дополнительную возможность использовать устройство Wi-Fi в соответствии с принцип наименьших привилегий. В этом примере AC не ссылается на PKC разработчика в качестве держателя, а на программное обеспечение, например, путем сохранения подписи разработчика программного обеспечения в поле владельца AC. Когда программное обеспечение помещается в вычислительное устройство, устройство будет проверять целостность программного обеспечения с помощью PKC разработчика перед проверкой действительности AC и предоставлением программному обеспечению доступа к функциям устройства.
Пользователю также может потребоваться получить несколько AC от разных эмитентов, чтобы использовать определенную услугу. Например, компания предоставляет одному из своих сотрудников общекорпоративный AC, в котором в качестве рабочей области указывается инженерный отдел. Однако, чтобы получить доступ к инженерным данным, сотруднику также требуется AC допуска от начальника технического отдела. В этом примере ресурс технических данных должен быть предварительно установлен с открытыми ключами как для всей компании, так и для инженерного отдела эмитентов переменного тока.
Версия : версия сертификата.
Владелец : владелец сертификата.
Эмитент : издатель сертификата.
Алгоритм подписи : алгоритм подписания сертификата.
Серийный номер : уникальный номер выдачи, присвоенный эмитентом.
Срок действия : срок действия сертификата.
Атрибуты : атрибуты, связанные с держателем сертификата.
Значение подписи : подпись эмитента по всем приведенным выше данным.
Используя сертификат атрибута, сервис или ресурс хост не должны поддерживать список управления доступом, который потенциально может быть большим или слишком большим. всегда быть подключенным к сети для доступа к центральному серверу, как при использовании Kerberos. Это похоже на идею возможностей, в которой разрешение (или разрешения) на использование службы или ресурса сохраняется не в самой службе или ресурсе, а в пользователях, использующих защиту от взлома механизм.
